Robie,
To cherry pick this would require extensive reverse engineering of the
code to figure out which pieces apply to the *older* versions of
torbrowser-launcher. Unfortunately, since there are no *bugfix*
releases of torbrowser-launcher upstream and everything is interspersed
among larger-scale feature changes, this prevents us from easily
cherrypicking the code. Essentially, to reverse engineer this patch
would take much MUCH more time and effort to make functional.
However, we have a second consideration point. With torbrowser-launcher
0.3.6, we have a major *upstream* change from Tor Browser itself (which
is downloaded by torbrowser-launcher and installs it in userspace as Tor
Browser prefers to live in) which involves the loss of all localization
packages and one unified package for Tor Browser. To nitpick *those*
fixes is equivalent to a large feature change that is well-ingrained in
the 0.3.5 -> 0.3.6 codebase change, and reverse engineering that from
what I've attempted to do initially for Tor Browser is a nightmare.
Which leaves us with, really, two choices:
1. Backport 0.3.6-2 in -updates to the older releases
2. Won't Fix 277 and other bugs which will make the package
unusuable (effectively: Critical bugging the older version which a lot
of people use, because it's "no longer supported").
This is tantamount to Bitcoin from the history where Bitcoin would make
hard forks or major non-reverse-compatible changes that can't be
backported and in turn would require the newer version to be backported
in order for `bitcoin` to even function. The only difference between
Bitcoin and torbrowser-launcher (and Tor Browser) is that this is the
first major *historically breaking* change in upstream Tor Browser that
prohibits simply 'backporting' these changes.
The two-line fix for launch window is minor, and we could theoretically
survive that. However, the URL fix is nontrivial to backport within the
code, hence the request for a one-time special SRU to backport 0.3.6 to
all current releases (except 18.04 because that's approaching it's EoSS
date) in order to make everything function in the currently supported
releases.
Thomas
On 4/6/23 15:55, Robie Basak wrote:
Hi Thomas,
Thank you for caring for this package in Ubuntu!
I'm not sure I follow why this is difficult to fix by cherry-picking
fixes. It seems to me that there are two bugs mentioned - one which is a
two line fix, and one which refers to upstream URLs changing, which
presumably is a change in a constant somewhere or similar.
Will cherry-picking or rewriting these trivial fixes not be enough to
fix the reported bugs? If not, why not?
Robie
On Sun, Mar 19, 2023 at 07:55:48PM -0400, Thomas Ward wrote:
I'm following up on this today, because Debian finally got off their lazy
butt and uploaded 0.3.6-2 to Debian that addresses the core problems in
Debian.
However, that does not solve the problems for everything in Ubuntu. With
the blessing of the Release team, I did a sync last night (forced) of
0.3.6-2 from Debian Unstable to Ubuntu Lunar, which addresses
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277
in Lunar.
Unfortunately the fix that is applied for this in 0.3.6-2 is interwoven with
all the changes from 0.3.3 to 0.3.6 upstream which includes new features.
I have not heard back from the Release team on this, or the SRU team, so I'm
re-asking this. Is the SRU / Release team willing to let us do a one-time
backport from Lunar of 0.3.6-2 to the older releases currently supported (to
Bionic but no further backwards)?
Thomas
On 2/1/23 14:26, Thomas Ward wrote:
Hello, release team.
Pursuant to a recent change for torbrowser-launcher and Tor Browser, we
have a little bit of a conundrum that is leading to a one time request for
SRUing the latest `torbrowser-launcher` to all currently supported
releases.
With Tor Browser 12 (TB12 for short here), upstream tor browser no longer
uses locales, requiring folder cleanup from TB12 and download URL changes
in order for things to properly function. Unfortunately, the code changes
necessary to implement the changes to torbrowser-launcher are not easily
nitpicked and include more than just these fixes, as it has new changes
and such to make it work properly. Refer to
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277
as the current bug on this.
Debian is behind on updating upstream, so later today I will be preparing
a package for Lunar that will have a -0ubuntu1 prefix for the latest
upstream version. That works fine in Lunar. It also works fine in
Kinetic and in initial tests in Jammy. I’m installing test environments
for Focal and Bionic.
The problem here is, though, we have a mix of “new features” and “bug
fixes” together – there is no ‘major version bump’ for feature branches
vs. ‘bugfix’ branches, making it a comingled problem of “new features” and
“bug fixes”. Therefore, I’d like
