[13:54] <AsciiWolf> rbasak, hi, I am working on the Tor Browser Launcher SRU for Focal... one quick question: do I have to do some changes, custom changelog etc., or can I just do debdiff of old dsc compared to the new dsc from debian testing/ubuntu groovy?
[13:55] <AsciiWolf> there are many changes in the latest packages when compared to the old one, but I don't think that any of the changes breaks something on Focal... and I will test the package before submitting it
[14:11] <ItzSwirlz> AsciiWolf you have been pretty lucky getting the attention you need
[14:11] <ItzSwirlz> The MOTU's like to ignore people
[14:11] <ItzSwirlz> You need to make a .patch file, build it to create a debdiff
[14:11] <ItzSwirlz> Sign debian/changelog
[14:11] <rbasak> AsciiWolf: the SRU upload will need its own changelog entry stating "focal" with an appropriate version number (lower than groovy, higher than anything published in <=focal, etc). Any reasonable method you give to your sponsor to get to that upload is reasonable
[14:11] <ItzSwirlz> Then attach it to the bug report and pray MOTU's come for help
[14:12] <ItzSwirlz> (like they ever will)
[14:12] <rbasak> AsciiWolf: however note that SRUs need to be minimal. See https://wiki.ubuntu.com/StableReleaseUpdates for the policy
[14:12] <ItzSwirlz> version number is
[14:12] <rbasak> In general you'll have a harder time convincing anyone to take a new version wholesale over a cherry-pick, especially because reviewing and verifying the correctness of a cherry-pick is far easier.
[14:14] <ItzSwirlz> currentversionnumberforfocal-ubuntu0.1
[14:14] <ItzSwirlz> but if your requestingsync i doubt it will happen
[14:14] <ItzSwirlz> It kind of guarantees your SRU will NEVER get in there
[14:15] <ItzSwirlz> Anyways, anyone got updates on my patches?
[14:15] <ItzSwirlz> They are the cinnamon patches
[14:15] <rbasak> ItzSwirlz: provide something reasonable and simple and you'll find sponsors. Give reviewers a hard time and you won't.
[14:18] <AsciiWolf> rbasak, ah, ok, thanks!
[16:16] <AsciiWolf> rbasak, I have prepared the torbrowser-launcher SRU: https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/1896085 :)
[16:17] <ItzSwirlz> Ok I'll look at it
[16:17] <ItzSwirlz> Okay so-my advice about the Regression Potential
[16:17] <ItzSwirlz> Try to add detail in the case that IT CAN happen-
[16:17] <ItzSwirlz> In the case of say a key update a lot could change
[16:18] <ItzSwirlz> Through PGP/OpenGPG updates of the whole program thats what can happen
[16:18] <ItzSwirlz> It's assumed they are low but it's best to think what could happen in the case of a regression.
[16:26] <AsciiWolf> the key is used only when torbrowser-launcher is launched for a first time
[16:28] <AsciiWolf> it is used to verify torbrowser archive that is downloaded and unpacked (into user's home) when torbrowser-launcher is launched for a first time
[16:30] <AsciiWolf> as far as I know, torbrowser updates are then handled by torbrowser itself, not by torbrowser-launcher... so they work fine (in case torbrowser is already installed/configured by torbrowser-launcher) even if the devel public key used by torbrowser-launcher is wrong
[16:33] <rbasak> AsciiWolf: that's the sort of discussion/analysis that should go into the Regression Potential section please
[16:34] <rbasak> AsciiWolf: the point is to identify areas of behaviour that are most likely to regress if we're wrong, so that we know what areas to test
[16:34] <rbasak> AsciiWolf: apart from that your SRU looks fine.
[16:34] <rbasak> We'll need to find someone to sponsor because if I SRU-review it then someone else is supposed to sponsor.
[16:34] <AsciiWolf> rbasak, ok, I will update the Regression Potential :)
[16:35] <rbasak> Thanks!
[16:35] <AsciiWolf> np
[16:39] <AsciiWolf> rbasak, done :)
[16:41] <rbasak> AsciiWolf: thanks. As I say we'll need to find someone else to sponsor. One other thought: is there any evidence that the key being added is the correct key and not a compromised one?
[16:42] <rbasak> For example the commit link looks like it's to a fork and not the original project.
[16:42] <rbasak> Maybe it'd be a good idea to provide some evidence (or pointers to evidence) that it's the correct key in the bug.
[16:44] <AsciiWolf> well, the key is already used in Debian/Ubuntu Groovy and the patch was made by a Tor developer :)
[16:45] <AsciiWolf> https://salsa.debian.org/pkg-privacy-team/torbrowser-launcher/-/commit/72b87f502af0666954d9ae9f51b794d546e1ab6c
[16:45] <AsciiWolf> https://github.com/sysrqb seems to be an account of a Tor developer
[16:47] <AsciiWolf> the new key from this patch is also already used in Fedora, on Flathub and in many places :)
[16:48] <AsciiWolf> anyway, the patch file is the same that is already included in the source package in Ubuntu Groovy :)
[16:54] <AsciiWolf> rbasak, I have added comment with link to the Debian Salsa commit, mentioning that the patch file is already used in Groovy
[17:04] <rbasak> AsciiWolf: perfect. Thank you!
[17:04] <rbasak> A pointer to Debian's identical key is certainly sufficient since most of the time we rely on the Debian maintainer via syncs anyway
[17:57] <ItzSwirlz> So about my patches:
[17:57] <ItzSwirlz> I do have many patches and many more I can do but I don't want to mess up the versions in changelog
[17:57] <ItzSwirlz> But now that we are a month from release I am wondering if it's still worth the 20.04 SRU's now.
[18:08] <ItzSwirlz> So if anyones available to help that'd be great, I'll remain online.
[21:57] <ItzSwirlz> AsciiWolf: Is this similar to your problem? https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/1495986
[21:57] <ItzSwirlz> It seems all bugs here are to that issue: https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher