Opened 10 months ago

Closed 7 months ago

#29319 closed defect (fixed)

Remove FTE support in Windows bundles

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, GeorgKoppen201902, TorBrowserTeam201905R
Cc: boklm Actual Points:
Parent ID: #29307 Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Change History (11)

comment:1 Changed 10 months ago by gk

Keywords: TorBrowserTeam201902R added; TorBrowserTeam201902 removed
Status: newneeds_review

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.

comment:2 Changed 10 months ago by 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.

comment:3 Changed 10 months ago by gk

Cc: boklm added

comment:4 in reply to:  2 Changed 10 months ago by 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.

comment:5 in reply to:  1 Changed 10 months ago by boklm

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?

comment:6 Changed 10 months ago by gk

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

comment:7 Changed 9 months ago by gk

Keywords: TorBrowserTeam201903R added; TorBrowserTeam201902R removed

February is gone.

comment:8 Changed 9 months ago by gk

Keywords: TorBrowserTeam201904R added; TorBrowserTeam201903R removed

Moving review tickets to April.

comment:9 Changed 8 months ago by gk

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.

comment:10 Changed 8 months ago by gk

Keywords: TorBrowserTeam201905R added; TorBrowserTeam201904R removed

No April anymore, moving review tickets to May.

comment:11 Changed 7 months ago by boklm

Resolution: fixed
Status: needs_reviewclosed

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

Note: See TracTickets for help on using tickets.