Opened 5 months ago

Closed 5 months ago

Last modified 5 months ago

#24912 closed defect (fixed)

Prepare tor-browser-build for building stable releases

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201801R
Cc: boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Up to now we used tor-browser-build to only build alpha and nightly bundles but we think it is mature enough to fully replace Gitian.

This bug tracks the changes we need to make to be able to build stable, alpha, and nightly bundles from the same branch.

If we think that gets too messy we move back to make dedicated maint-XX branches. We'd like to avoid that, though, as it has been confusing in the past for users that wanted to build Tor Browser.

Child Tickets

Change History (8)

comment:1 Changed 5 months ago by gk

Keywords: TorBrowserTeam201801R added; TorBrowserTeam201801 removed
Status: newneeds_review

If I see it right we want to disable

snowflake
win64
sandboxed tor browser
selfrando

on the stable series.

Additionally, we need to think about

the osx dmg images
dealing with different project versions for the stable and non-stable series

bug_24912 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/log/?h=bug_24912) has four patches for the four mentioned things above which we'd need anyway regardless whether we want to have a maint branch of not.

Please review while I think about the other two (and please come up with stuff I might have forgotten)

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

Replying to gk:

bug_24912 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/log/?h=bug_24912) has four patches for the four mentioned things above which we'd need anyway regardless whether we want to have a maint branch of not.

The four patches look good to me.

For the patch disabling selfrando, we could maybe define a var/selfrando to make it easier to disable/enable it (although the number of places to change is small, so maybe not worth it).

comment:3 Changed 5 months ago by gk

Thanks. I went with the patches as-is and committed them to master:

ba6ac61ef5a80eaf53dcc4f4b9622d2b9e12a9bb
dc51005d4944d6be9ca1c06331c3f9ee1cee51fc
563ebc0ab77bbc7b0e792fa29317de9dab278c9d
a1347df3ca9d094b53c2aee516a7c96111422d12

comment:4 Changed 5 months ago by gk

Okay, I pushed another commit onto the bug_24912 branch (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_24912&id=62f2dced863d2dfcd5076c101bda0f4c9c10d508) to deal with the osx sandbox situation, please review.

I think I'll go the maint-branch road as I am a bit unclear how to deal efficiently with having different versions per project depending on the stable/alpha series. I'd especially like to avoid the hassle coming from new toolchain versions during the next alpha cycle.

So, what is left then is the commit above, copying over the .dmg background etc. from maint-7.0 to the new maint-7.5 branch and then adjusting the version numbers for the stable accordingly.

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

Replying to gk:

dealing with different project versions for the stable and non-stable series

For the firefox part, I think we could do it like this:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_24912&id=cba351cf602ab2f62f0932ec7fc61b3e7cd5e888

$ ./rbm/rbm showconf --target release firefox git_hash
tor-browser-52.5.2esr-7.5-2-build2
$ ./rbm/rbm showconf --target alpha firefox git_hash
tor-browser-52.5.2esr-8.0-1-build1
$ ./rbm/rbm showconf --target nightly firefox git_hash
tor-browser-52.5.2esr-8.0-1

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

Replying to gk:

Okay, I pushed another commit onto the bug_24912 branch (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_24912&id=62f2dced863d2dfcd5076c101bda0f4c9c10d508) to deal with the osx sandbox situation, please review.

This commit looks good to me.

I think I'll go the maint-branch road as I am a bit unclear how to deal efficiently with having different versions per project depending on the stable/alpha series. I'd especially like to avoid the hassle coming from new toolchain versions during the next alpha cycle.

For the firefox part I think we can do it like this:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_24912&id=cba351cf602ab2f62f0932ec7fc61b3e7cd5e888

And for the tor part:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_24912&id=d26740383fe575111d72b953082367a4d3bc95c0

I think the torbutton, tor-launcher, openssl parts can be done in a similar way.

I am not sure about the toolchain updates yet. Maybe they will require lots of changes that would be a hassle to keep behind many [% IF ! c("var/release") %], but maybe it will only be a few lines of changes in just a few places.

I think it's nice to be able to see the versions of all channels from a single branch. Although I'm also fine with going the maint-branch road.

comment:7 Changed 5 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Okay, I applied my latest patch to master (commit 62f2dced863d2dfcd5076c101bda0f4c9c10d508).

Thanks for the suggestions. I think we should try the maint-branch idea this again and revisit the plan once we transition from the 8.0-alpha to the 8.5-alpha. We are still transitioning to tor-browser-build/rbm and this is a part of it (We'd need to find a sane way for having different torbrowser_version, torbrowser_build etc. values in rbm.conf`, too, fwiw).

comment:8 Changed 5 months ago by gk

I added a fixup to make sure to export SELFRANDO_write_layout_file= only in non-release builds into the Linux start script. It's commit a647027d20ee95355f1a5452f2b4586aeb54c68c on master and commit 2488ddcda9875f2c34c42fa0c3f10c9034c2b7e0 on maint-7.5.

Note: See TracTickets for help on using tickets.