Opened 8 months ago

Closed 8 months ago

#32676 closed enhancement (fixed)

Consider publishing a tarball with all Tor Browser langpacks

Reported by: intrigeri Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: AffectsTails, tbb-rbm, TorBrowserTeam201912R
Cc: anonym, boklm Actual Points:
Parent ID: Points:
Reviewer: gk Sponsor:

Description

At the moment, during a build of Tails, we download all Tor Browser Linux x86_64 tarballs, in order to grab every langpack XPI, which we then all ship in our images. This causes trouble for 2 categories of Tails contributors:

  • The Tails release manager has to semi-automatically download all these tarballs and then upload them to the Tails infrastructure (that's because at this time, the tarballs are available only on people.torproject.org, and later they will disappear from there; we need a stable URL that we can encode in our Git tree, for convenience and reproducibility purposes); this consumes time, bandwidth, and storage.
  • After a new Tor Browser has been imported into Tails, next time any Tails developer wants to build Tails, as part of the build, downloads each of these tarballs. This consumes time, bandwidth, and patience.

One possible solution for these problems would be to publish, on Tor Browser team's side, an additional tarball, that contains all langpack XPIs, and nothing else. According to boklm, this tarball would about 16 MB large.

Then, the Tails release manager would only have to import the en-US tarball and this all-langpacks tarball. Similarly, Tails developers would also have to download only these 2 files.

This is _not_ a duplicate of #17400 nor #12967, which are about providing end-users a multi-lingual Tor Browser.

Child Tickets

Attachments (2)

Change History (16)

comment:1 Changed 8 months ago by intrigeri

Keywords: TorBrowserTeam201912R added
Status: newneeds_review

comment:2 Changed 8 months ago by intrigeri

Note: the attached patch is a first, untested draft. Thanks boklm for helping me create something that has a vague chance to work, though :)

comment:3 Changed 8 months ago by sysrqb

Reviewer: boklm

Thanks for the patch, intrigeri!

comment:4 Changed 8 months ago by boklm

The patch looks good to me, and works fine.

The patch is in my branch bug_32676_v2:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_32676_v2&id=717bfab21f38279e9d991c52f6135ed4552d00be

After running make alpha-linux-x86_64 it created the file alpha/unsigned/9.5a3-build1/langpacks-tor-browser-9.5a3.tar.xz which is 15M.

However as I participated in writing this patch, maybe someone else should review it too.

comment:5 Changed 8 months ago by gk

Reviewer: boklmgk

comment:6 Changed 8 months ago by gk

Status: needs_reviewneeds_information

Looks mostly good to me. I am struggling a bit with the scope of the patch. Right now we'd publish the tarball for every nightly build and alpha + stable release. At least the nightly part seems to be excessive to me as this is a Tails feature for the release process. IIRC Tails would only need stable tarballs for that. So, how about scoping that feature to only release builds? Or if that's really necessary to alpha builds in addition to that?

comment:7 in reply to:  6 Changed 8 months ago by intrigeri

Replying to gk:

So, how about scoping that feature to only release builds? Or if that's really necessary to alpha builds in addition to that?

As far as I'm concerned, I think it's totally fine to start with release builds only: it'll give us the expected benefits in the cases when it matters most.

Then we'll see how much we miss it in the rarer cases when we include an alpha, and we can get back to you if needed; meanwhile you'll also have data/feelings about the cost of this extra tarball on your side. So I prefer postponing this discussion about alphas to a time when we'll have less hypothetical info to reason about :)

Should I try to update the patch to only trigger on release builds? Or is it cheaper for you to do it yourself than to review an untested fixup patch from me?

comment:8 Changed 8 months ago by cypherpunks

Should I try to update the patch to only trigger on release builds?

Yes.

comment:9 Changed 8 months ago by boklm

Status: needs_informationneeds_review

I added this fixup commit to only generate the langpacks tarball on stable release builds:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_32676_v2&id=bc17dfb5c15e4668934ad952593c45cce91feedf

And squashed it in branch bug_32676_v3:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_32676_v3&id=7289cf72181734c04fb74a9d696f844aadb87bc5

Since it's a quite simple patch, and doesn't do anything on alpha, should we merge this directly to the stable branch?

comment:10 Changed 8 months ago by cypherpunks

Since it's a quite simple patch, and doesn't do anything on alpha, should we merge this directly to the stable branch?

After adding "Linux x86_64" to the tarball's name.

comment:11 in reply to:  10 Changed 8 months ago by gk

Keywords: TorBrowserTeam201912 added; TorBrowserTeam201912R removed
Status: needs_reviewneeds_revision

Replying to cypherpunks:

Since it's a quite simple patch, and doesn't do anything on alpha, should we merge this directly to the stable branch?

After adding "Linux x86_64" to the tarball's name.

That's a good idea, yes.

comment:12 in reply to:  9 Changed 8 months ago by gk

Replying to boklm:

[snip]

Since it's a quite simple patch, and doesn't do anything on alpha, should we merge this directly to the stable branch?

It will land on master as everything should land on master and at some point the alphas built there will be stables, too. But, yes, my plan is to cherry-pick it to maint-9.0, too, as the patch seems simple enough and it would be nice to help the Tails people as soon as possible.

comment:13 Changed 8 months ago by boklm

Keywords: TorBrowserTeam201912R added; TorBrowserTeam201912 removed
Status: needs_revisionneeds_review

comment:14 Changed 8 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Looks good now. Merged to master (commit f01757118ffd65096a66d73dec47cb747b0ac6a4) and cherry-picked to maint-9.0 (commit 26d96cf4284c524f1b620bcd59b370fb0f3001db).

Note: See TracTickets for help on using tickets.