Re: Special One-Time SRU Handling request for torbrowser-launcher
On Wed, Apr 19, 2023 at 12:30:04PM +0100, Robie Basak wrote: > Here's the minimal patch for Focal, with thanks to the respective > upstream authors: Sorry, I think I might have missed the change that drops language from the composition of tarball_filename when I generated this patch. But hopefully you get the idea. signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Special One-Time SRU Handling request for torbrowser-launcher
On Thu, Apr 06, 2023 at 04:11:23PM -0400, Thomas Ward wrote:
> 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.
I took a look at what this would take, and got to a minimal patch for
Focal within about an hour (including environment setup) that seems to
work fine. See below.
This needs cleaning up, packaging, attribution, adapting for the other
stable releases, and so on. But as it stands, it seems to me that the
usual approach is the appropriate way to fix this in our stable
releases.
Is there something I'm missing about how this approach is broken? Of
course if there are other bugfixes you want to take from upstream, you
could include them in this SRU in the usual way.
Note that there is no hard reason to cherry-pick. It's perfectly
acceptable to come up with an independent minimal fix, informed but not
directly drawn from upstream changes. SRU policy says this:
> ...the requirements for stable updates are not necessarily the same as
> those in the development release. When preparing future releases, one
> of our goals is to construct the most elegant and maintainable system
> possible, and this often involves fundamental improvements to the
> system's architecture, rearranging packages to avoid bundled copies of
> other software so that we only have to maintain it in one place, and
> so on. However, once we have completed a release, the priority is
> normally to minimise risk caused by changes not explicitly required to
> fix qualifying bugs, and this tends to be well-correlated with
> minimising the size of those changes. As such, the same bug may need
> to be fixed in different ways in stable and development releases.
Here's the minimal patch for Focal, with thanks to the respective
upstream authors:
--- common.py.orig 2023-04-19 12:09:12.723867908 +0100
+++ common.py 2023-04-19 12:09:06.647653367 +0100
@@ -58,6 +58,7 @@
self.default_mirror = 'https://dist.torproject.org/'
self.discover_arch_lang()
self.build_paths()
+self.torbrowser12_rename_old_tbb()
for d in self.paths['dirs']:
self.mkdir(self.paths['dirs'][d])
self.load_mirrors()
@@ -151,12 +152,12 @@
'version_check_url':
'https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US',
'version_check_file': tbb_cache + '/download/release.xml',
'tbb': {
-'changelog': tbb_local + '/tbb/' + self.architecture +
'/tor-browser_' +
- self.language +
'/Browser/TorBrowser/Docs/ChangeLog.txt',
+'changelog': tbb_local + '/tbb/' + self.architecture +
'/tor-browser' +
+ '/Browser/TorBrowser/Docs/ChangeLog.txt',
'dir': tbb_local + '/tbb/' + self.architecture,
-'dir_tbb': tbb_local + '/tbb/' + self.architecture +
'/tor-browser_' + self.language,
-'start': tbb_local + '/tbb/' + self.architecture +
'/tor-browser_' +
- self.language + '/start-tor-browser.desktop'
+'dir_tbb': tbb_local + '/tbb/' + self.architecture +
'/tor-browser',
+'start': tbb_local + '/tbb/' + self.architecture +
'/tor-browser' +
+ '/start-tor-browser.desktop'
},
}
@@ -165,6 +166,21 @@
'tor_browser_developers':
'EF6E286DDA85EA2A4BA7DE684E2C6E8793298290'
}
+# Tor Browser 12.0 no longer has locales. If an old TBB folder exists with
locals, rename it to just tor_browser
+def torbrowser12_rename_old_tbb(self):
+if not os.path.exists(self.paths["tbb"]["dir"]):
+return
+for filename in os.listdir(self.paths["tbb"]["dir"]):
+abs_filename = os.path.join(self.paths["tbb"]["dir"], filename)
+if filename.startswith("tor-browser_") and
os.path.isdir(abs_filename):
+os.rename(abs_filename, self.paths["tbb"]["dir_tbb"])
+print(
+_("Renamed {0} to {1}").format(
+abs_filename, self.paths["tbb"]["dir_tbb"]
+)
+)
+break
+
# create a directory
@staticmethod
def mkdir(path):
signature.asc
Description: PGP signature
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Special One-Time SRU Handling request for torbrowser-launcher
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
Re: Special One-Time SRU Handling request for torbrowser-launcher
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 to request a one-time exception for SRU > >processes to accept the same version packaged for each release using Lunar > >as a base, and adjusting the packaging as needed accordingly for older > >releases. That is, this will be an SRU, but it will accept the ‘new > >features’ that’re part of torbrowser-launcher that were not present in > >Bionic or Focal but are present in later releases. > > > >Most of the ‘feature’ changes allow choosing additional options, etc. but > >nothing that as far as I can tell changes the core functionality of the > >package. > > > >I’m happy to discuss this further with the SRU and Release teams (IRC is > >always a way to reach me heh), but given the complexities of including the > >fixes and changes just to make tor browser 12 work with the older > >launchers, it’d make more sense and ease of fixing this “breaks the > >launcher tool entirely” issue by simply taking the current version and > >making it match in the entire packaging structure. > > > >I’m happy to spearhead this, but I wanted to put this to the Release Team > >and the SRU team for consideration before I go through the process of > >building all this for the SRU/MRE/Version Bump processes as well. > > > >A full changelog upstream is available on their GitHub - > >https://github.com/micahflee/torbrowser-launcher > > > >Thomas > > > >LP: https://launchpad.net/~teward > > > >Ubuntu Core Developer > > > > > -- > Ubuntu-release mailing list > ubuntu-rele...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Special One-Time SRU Handling request for torbrowser-launcher
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 to request a one-time exception for SRU processes to accept the same version packaged for each release using Lunar as a base, and adjusting the packaging as needed accordingly for older releases. That is, this will be an SRU, but it will accept the ‘new features’ that’re part of torbrowser-launcher that were not present in Bionic or Focal but are present in later releases. Most of the ‘feature’ changes allow choosing additional options, etc. but nothing that as far as I can tell changes the core functionality of the package. I’m happy to discuss this further with the SRU and Release teams (IRC is always a way to reach me heh), but given the complexities of including the fixes and changes just to make tor browser 12 work with the older launchers, it’d make more sense and ease of fixing this “breaks the launcher tool entirely” issue by simply taking the current version and making it match in the entire packaging structure. I’m happy to spearhead this, but I wanted to put this to the Release Team and the SRU team for consideration before I go through the process of building all this for the SRU/MRE/Version Bump processes as well. A full changelog upstream is available on their GitHub - https://github.com/micahflee/torbrowser-launcher Thomas LP: https://launchpad.net/~teward Ubuntu Core Developer -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
