Opened 6 months ago

Closed 6 months ago

Last modified 5 months ago

#25339 closed task (fixed)

Install python 3.6 for building HTTPS-Everywhere

Reported by: boklm Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, TorBrowserTeam201803R, boklm201802, tbb-backported
Cc: legind Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The next HTTPSE release, to be released on monday, is converting all the toolings to python 3.6, including the components of the build script. To be able to build HTTPSE, we will need to install python 3.6.

To do that, we can either use a debian buster (testing) container, or build python 3.6 from sources.

Child Tickets

Change History (7)

comment:1 Changed 6 months ago by boklm

According to legind, Ubuntu Artful is an other option.

comment:2 Changed 6 months ago by gk

I think we don't want to go back to some Ubuntu version for any of our build projects. https://bugzilla.mozilla.org/show_bug.cgi?id=1388447 indicates that Mozilla won't switch to require Python 3.x before Firefox 61. So, we don't need to adapt our Python version used for the Firefox build.
I guess using buster for just building HTTPSE might be the least time-consuming change? If so, then we should do it.

comment:3 Changed 6 months ago by boklm

Keywords: TorBrowserTeam201802R added; TorBrowserTeam201802 removed
Status: newneeds_review

There is a patch for review in branch bug_25339_v2, using buster to build https-everywhere:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25339_v2&id=734a41c0f986989163ff7536ff84a2a03e00d5cc

However buster is not a stable release yet, so I am wondering how likely it is that an update, for instance on the zip package, would break the reproducibility of the build. Ubuntu Artful is a stable release, so it might be less likely to have big updates.

comment:4 in reply to:  3 ; Changed 6 months ago by gk

Keywords: TorBrowserTeam201803 added; TorBrowserTeam201802R removed
Status: needs_reviewneeds_revision

Replying to boklm:

There is a patch for review in branch bug_25339_v2, using buster to build https-everywhere:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25339_v2&id=734a41c0f986989163ff7536ff84a2a03e00d5cc

However buster is not a stable release yet, so I am wondering how likely it is that an update, for instance on the zip package, would break the reproducibility of the build. Ubuntu Artful is a stable release, so it might be less likely to have big updates.

Yes, that's true. However we would need to look for yet another solution to this bug in about three months as Ubuntu Artful is EOL in July 2018, not ideal. If you feel strongly here I am fine building Python 3.6 from source for 64bit Linux in the same container used for HTTPS-Everywhere. I feel the risk of breaking the reproducibility of HTTPS-Everywhere with buster is not very high given that it is "just" an extension. Either way I want to test the new process in an alpha anyway first (shipping the stable one time with a not up-to-date HTTPS-Everywhere seems to me acceptable given that we need to test a new build method in our environment first).

Looking at the patch we don't need the 32bit buster in the debootstrap config. Could you remove that part? Oh, and we might want to clean that config up anyway (in a different bug/commit) as there are still Ubuntu Precise things among others in it.

comment:5 in reply to:  4 Changed 6 months ago by boklm

Keywords: TorBrowserTeam201803R added; TorBrowserTeam201803 removed
Status: needs_revisionneeds_review

Replying to gk:

Yes, that's true. However we would need to look for yet another solution to this bug in about three months as Ubuntu Artful is EOL in July 2018, not ideal. If you feel strongly here I am fine building Python 3.6 from source for 64bit Linux in the same container used for HTTPS-Everywhere. I feel the risk of breaking the reproducibility of HTTPS-Everywhere with buster is not very high given that it is "just" an extension. Either way I want to test the new process in an alpha anyway first (shipping the stable one time with a not up-to-date HTTPS-Everywhere seems to me acceptable given that we need to test a new build method in our environment first).

I don't feel strongly about this, so I am fine using buster. We can still look for another solution later if it actually becomes a problem.

Looking at the patch we don't need the 32bit buster in the debootstrap config. Could you remove that part? Oh, and we might want to clean that config up anyway (in a different bug/commit) as there are still Ubuntu Precise things among others in it.

I removed the 32bit buster in branch bug_25339_v3:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25339_v3&id=7f6cb4caa95b7818e4482f41fd333f5a2a8d60f1

And I opened #25394 for more clean up.

comment:6 Changed 6 months ago by gk

Keywords: tbb-backport added
Resolution: fixed
Status: needs_reviewclosed

Thanks. Looks good. Let's test it in the next alpha and then think about a backport. Merged to master (commit 7f6cb4caa95b7818e4482f41fd333f5a2a8d60f1).

comment:7 Changed 5 months ago by gk

Keywords: tbb-backported added; tbb-backport removed

That got backported to maint-7.5 (commit a2510d82d0da7e2f4465c9954beef320e33c737c) and will be used in the build for Tor Browser 7.5.3.

Note: See TracTickets for help on using tickets.