Remove FTE support in Windows bundles

We have FTE support in our 32bit bundles but lack it for 64bit Windows ones (#24195 (moved)). Given that FTE support is going away soon and that we want to fix #29307 (moved) for our mingw-w64/clang toolchain we rip out FTE from 32bit bundles as well.

Trac:
Parent Ticket: #29307 (moved)

added GeorgKoppen201902 TorBrowserTeam201905R component::applications/tor browser owner::tbb-team parent::29307 priority::medium resolution::fixed severity::normal status::closed tbb-rbm type::defect labels

bug_29319 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_29319&id=3fc6bfc9d8df2bb558261c05c5e0c6d9bb69e942) has a patch for review.

Note: we should start deploying that on master once we'll prepare for the first 9.0 alpha.

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201902 deleted, TorBrowserTeam201902R added

boklm: One thing that made me wonder while preparing the patch is the pycrypto build for Linux. In particular:

./configure --build=i686-linux-gnu [% c("var/configure_opt") %]

Do you know why we have this line setting --build unconditionally to a 32bit system? We don't have it in our old Gitian descriptor at least.

Trac:
Cc: N/A to boklm

Replying to gk:

boklm: One thing that made me wonder while preparing the patch is the pycrypto build for Linux. In particular: {{{ ./configure --build=i686-linux-gnu [% c("var/configure_opt") %] }}} Do you know why we have this line setting --build unconditionally to a 32bit system? We don't have it in our old Gitian descriptor at least.

I don't remember why we have this. But it looks like an error. It seems we don't have the any configure line in Gitian.

Replying to gk:

bug_29319 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_29319&id=3fc6bfc9d8df2bb558261c05c5e0c6d9bb69e942) has a patch for review.

This patch looks good to me.

Note: we should start deploying that on master once we'll prepare for the first 9.0 alpha.

Should we create a branch for 8.5, and merge this to master? Or wait before merging?

I think we should wait a bit to not create too much extra work.

February is gone.

Trac:
Keywords: TorBrowserTeam201902R deleted, TorBrowserTeam201903R added

Moving review tickets to April.

Trac:
Keywords: TorBrowserTeam201903R deleted, TorBrowserTeam201904R added

Please re-check if you are still fine with my changes. There are two commits now for this bug on bug_29307_v7 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/log/?h=bug_29307_v7): b8c497a4eb16f8ea80914d6def714115977b6c11 and 0c23af0c8c287a79a195de3df97bb70488e6ab23.

No April anymore, moving review tickets to May.

Trac:
Keywords: TorBrowserTeam201904R deleted, TorBrowserTeam201905R added

This looks good to me. I merged those commits to master with commit b00d30e8a5a91533d8fc8c7786793b72348638cf.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #30319 (moved)

mentioned in issue #33299 (moved)

mentioned in issue #29307 (moved)

mentioned in issue tpo/anti-censorship/bridgedb#33299 (closed)

moved to tpo/applications/tor-browser#29319 (closed)

mentioned in issue tpo/applications/tor-browser#30319 (closed)