[00:01] <tsimonq2> cpete: The only correction I had for that debdiff was, all of the whitespace diff pieces should be split into its own patch, if that still needs inclusion even.
[00:02] <tsimonq2> I'm not touching rsyslog with a ten foot pole, unless it goes unreviewed for too long. :P
[00:06] <tsimonq2> One of these days someone will accidentally sync over curl so we can get rid of that long changelog diff... ;P
[00:07] <arraybolt3> and then the world will come to an end XD
[00:08] <tsimonq2> hah :D
[00:09] <tsimonq2> @pilot out
[00:11] <tsimonq2> (grrr I'll deal with bluez in the morning, I'd appreciate a followup patch...)
[00:30] <cpete> tsimonq2: thanks for the sponsorship. I probably should have left a comment on the lp bug about the MR. Done now.
[00:33] <cpete> tsimonq2: The whitespace fix was just ride-along, but not really necessary or relevant for a patch thinking about it now. In future I'll remember to check for it and remove it. Thanks again!
[06:46] <juliank> vorlon: oops
[06:46] <juliank> @pilot out
[06:46] <juliank> Must have been piloting all break heh
[12:13] <athos> @pilot in
[13:07] <Photonic> any ubuntu pro devs around?
[13:13] <athos> Photonic: you can ask your question here and maybe someone will be able to help (I am not an ubuntu pro dev)
[13:14] <Photonic> there is a problem with ubuntu pro where its blocking the download of updates from the Universe repo in 20.04
[13:15] <Photonic> to work around the bug, to get the update you've gotta remove the package and reinstall it
[13:19] <athos> Photonic: would you mind filing a bug
[13:19] <athos> ?
[13:19] <Photonic> im too tired
[13:23] <athos> That would be the best way to get in contact with the ubuntu pro developers so we could assess the issue you have been experiencing
[13:23] <athos> you can always report one at https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools :)
[13:27] <sahnaseredini> Photonic could you please provide more info with clear steps to reproduce the issue?
[13:27] <sahnaseredini> as athos mentioned filing a bug is always the best path to take in these situations
[13:31] <Photonic> So, I don't subscribe to ubuntu pro. i get a notice in apt that a package (in universe) has a security vulnerability and i can get the update through ubuntu pro. if i then remove the package and reinstall it, the package comes patched because apt no longer gives me the notice
[13:32] <Photonic> and ubuntu pro should not even be blocking the update. the app is in the universe repo, which is support to be community-maintained
[13:32] <arraybolt3> Photonic: That doesn't sound right - the Ubuntu Pro patched packages are in a totally different repository.
[13:32] <arraybolt3> The updates aren't being blocked, they're separate updates altogether.
[13:33] <Photonic> well where the patches are coming from is irrelevant because the app is from the community universe, plus, this is on 20.04. its still within 5 years before extended security
[13:33] <arraybolt3> Universe is community maintained, but Canonical optionally lets you use their commercially maintained repos (which take a lot of effort to maintain and cost money for large-scale use for that reason). If you don't use them, you get the community maintenance.
[13:34] <Photonic> the app is from the community repo
[13:34] <arraybolt3> The commercially maintained repos are entirely separate from the normal archive. Nothing has changed with how the normal archive works, not even how well it's maintained.
[13:34] <arraybolt3> You're using the community repo, you're getting the community updates.
[13:34] <arraybolt3> apt is simply informing you that the commercial repo exists.
[13:34] <arraybolt3> If you dislike that, you can turn it off.
[13:35] <Photonic> for an app in the community sphere
[13:35] <rbasak> Could you provide some specifics please? Which package? Which version was installed when you got the notice? Which version was installed after you reinstalled it?
[13:35] <Photonic> anyway, fuck this. my time is not worthless. my debian download just finished
[13:35] <arraybolt3> Obvious troll, he wouldn't listen to anything we had to say.
[13:44] <rbasak> FWIW, I think the information about what additional updates are available from Pro are cached - both the apt lists, and the computation about which updates would apply to your system. So the message might not appear immediately. I wonder if that's what happened and they assumed that the lack of message meant no Pro update available, even though it was just cached from when the package was not
[13:44] <rbasak> installed.
[15:41] <athos> @pilot out
[15:45]  * tsimonq2 wonders where cpete went :)
[15:46] <tsimonq2> jbicha: Are you inclined in either direction on letting Daniel provide a new bluez diff?
[15:46] <tsimonq2> I don't plan on abandoning that, but I'd also like to see him learn from this.
[15:48] <jbicha> tsimonq2: yes, he'll follow up, but it's middle of the night there
[15:48] <tsimonq2> jbicha: Not a problem, let me know how I can help, thanks :)
[15:49] <jbicha> he should apply for uploader rights though
[15:49] <tsimonq2> ^^^^^
[15:56] <arraybolt3> tsimonq2: three-minute heads-up before takeoff
[15:57] <tsimonq2> "Flight attendants stand by for all call."
[15:59] <arraybolt3> And in 3...
[15:59] <arraybolt3> 2...
[15:59] <arraybolt3> 1...
[15:59] <arraybolt3> @pilot in
[15:59] <tsimonq2> @pilot in
[15:59] <arraybolt3> Resuming work on horst, I assume it's in the archive of Noble now, but I should check it.
[15:59] <tsimonq2> arraybolt3 wanted to come back for more, so I agreed :D
[16:00] <arraybolt3> oooh, horst in Noble is stuck on forensics-extra autopkgtesting
[16:00] <arraybolt3> that's... a metapackage... why does that have an autopkgtest
[16:01] <tsimonq2> Many autopkgtests these days are automagically generated.
[16:02] <tsimonq2> That *may* just be one of them.
[16:02] <arraybolt3> doesn't look like it, looking at the control file now
[16:02] <arraybolt3> it literally is an *installation* test to make sure everything installs properly
[16:02] <arraybolt3> which... is totally unnecessary because of Britney, right?
[16:03] <arraybolt3> although it does some testing to see if GUI packages ended up in the non-GUI half of the metapackage
[16:03] <arraybolt3> so I guess it's not *totally* pointless, but it's still very much odd to me.
[16:04] <arraybolt3> this is not the job autopkgtests are for I don't think
[16:05] <arraybolt3> I dunno, it looks a bit more involved than I initially thought
[16:06] <arraybolt3> but at any rate, a horst upload is most definitely *not* going to break it, and it's already passed on multiple arches and looks arch-independent, so if it breaks, it isn't horst's fault.
[16:07] <arraybolt3> tsimonq2: even if an SRU upload can't be *accepted* until the development release is fixed, can the patch at least be uploaded so it can be accepted later?
[16:08] <tsimonq2> arraybolt3: I'm fuzzy on the *correct* answer to that (ubuntu-sru please feel free to chime in), but IME it depends on the SRU Team member.
[16:08] <tsimonq2> I would personally not consider it a large blocker in this case, but I'd remind you both of migration-reference/0 and that SRUs also get stable autopkgtests ran.
[16:09] <arraybolt3> TIL about migration-reference/0
[16:09] <arraybolt3> nifty, I knew to look for info in the ProposedMigration wiki page :D
[16:09] <arraybolt3> anyway, *cracks knuckles and looks at diff*
[16:12] <arraybolt3> Packaging looks pristine to me (and I checked that version number quite closely), buuuut I forgot I needed to make an schroot for building so I'm a bit delayed
[16:15] <arraybolt3> buiding now
[16:15] <arraybolt3> *building
[16:16] <tsimonq2> arraybolt3: What is different about reviewing debdiffs for stable releases, compared to debdiffs for development releases?
[16:17] <arraybolt3> For development releases, you're just checking for correct packaging and the ability to build. For SRU debdiffs you have to make sure the diff adheres to the requirements in https://wiki.ubuntu.com/StableReleaseUpdates, which is mostly "fix just the bug you're going for and nothing else, not even Lintian gripes".
[16:17] <arraybolt3> Going for minimal changes to fix a well-documented bug or group of bugs.
[16:18] <arraybolt3> Also the package still has to be accepted by the SRU team before it goes into proposed, and then needs testing before it goes into updates, but those are separate from the review.
[16:18] <tsimonq2> Followup: would you rather do 100 changes in one update, or one change and 100 updates?
[16:18] <tsimonq2> (Intentional hyperbole.)
[16:19] <arraybolt3> beg your pardon? I can see how one update can make 100 changes, but not how one change could make 100 updates.
[16:20] <tsimonq2> Sorry, let me make it clearer: you have 100 SRUable changes to make. Would you rather do 100 uploads, or one upload, and why?
[16:20] <arraybolt3> At any rate I would usually strongly recommend making one change per update except in certain situations, sort of like how one would submit Linux kernel patches. If you have to make a group of related changes that all have to go together, though, do them all at once.
[16:20] <arraybolt3> ah, I think I just answered your question.
[16:21] <arraybolt3> For instance I one time (successfully) did an SRU that included fixes for two different bugs in lubuntu-update-notifier, but those two bugs and their fixes were tightly connected and the fixes had to go in together for them to work at all.
[16:22] <tsimonq2> arraybolt3: Just remember that stable users expect updates less frequently (and for a better reason) than development users.
[16:22] <tsimonq2> I don't think there's a firm right answer to that. :)
[16:22] <tsimonq2> Anyway, carry on.
[16:22] <arraybolt3> hmm, that's a good point.
[16:22] <arraybolt3> Currently fighting with my build system :P
[16:22] <arraybolt3> using -c instead of -d is still having unexpected results with sbuild
[16:22] <arraybolt3> so I've gone back to the old way
[16:24] <tsimonq2> As long as ... your boat floats :)
[16:24] <arraybolt3> tsimonq2: alright, horst_mantic.debdiff from https://bugs.launchpad.net/ubuntu/+source/horst/+bug/2045986 gets my stamp of approval.
[16:24] -ubottu:#ubuntu-devel- Launchpad bug 2045986 in horst (Ubuntu Noble) "[SRU] no WiFi card, ends with segfault" [Undecided, In Progress]
[16:25] <arraybolt3> I'm going to speed up the last three with the help of diff -u (if all the changes are identical except for a version number and release name, they're good from a packaging perspective and just need a test build)
[16:25] <arraybolt3> HOLD UP
[16:25] <arraybolt3> I made a fatal mistake.
[16:25] <arraybolt3> I forgot to actually apply the debdiff after reviewing it. 🤦
[16:26] <arraybolt3> sooooo... now that I've done that, let's try again
[16:26] <arraybolt3> and I think my -proposed enabler is wrong
[16:27] <arraybolt3> yep, I put noble-proposed into mantic 🥴
[16:28] <cpete> tsimonq2: I am back
[16:28] <arraybolt3> alright, finally it's working
[16:28] <arraybolt3> tsimonq2: sorry about the drama there
[16:30] <arraybolt3> tsimonq2: alright, builds properly, with patch, against mantic-proposed, horst_mantic.debdiff is ready to upload.
[16:31] <arraybolt3> initial review of horst_luanr.debdiff is spotless, preparing schroot
[16:31] <arraybolt3> I think this is the last one I'll be able to do today before having to leave for a meeting.
[16:34] <tsimonq2> arraybolt3: I got caught up in an IRL conversation, apologies.
[16:34] <arraybolt3> np, you missed a couple of fun fumbles
[16:34] <arraybolt3> anyway horst_mantic.debdiff is good, working on horst_lunar.debdiff now.
[16:34] <tsimonq2> I concur on the Mantic diff, uploading. :)
[16:36] <tsimonq2> cpete: On the whitespace I just wanted to tell you that I would have done the exact same thing to start. :)
[16:37] <tsimonq2> cpete: Also, if anyone from Debian flames you for the version number, please direct them to me, that was my mistake. (I uploaded a -3, tried to cancel it and upload -2.1, somehow my cancel failed despite repeated attempts, so they got both, which is not standard practice. I owe them apologies.)
[16:40] <arraybolt3> tsimonq2: horst_lunar.debdiff is ready to go
[16:40] <arraybolt3> (and yes I actually applied the patches this time)
[16:41] <arraybolt3> I already have a jammy schroot, sooo...
[16:41]  * arraybolt3 crams stuff in
[16:42] <tsimonq2> arraybolt3: Concur, uploading.
[16:43] <tsimonq2> (Lunar.)
[16:45] <arraybolt3> Jammy patch looks good (did a closer look since it wasn't a total clone of Mantic's patch, due to a slightly different version of horst in Jammy), building
[16:46] <tsimonq2> What's the meaningful difference between the two?
[16:46] <tsimonq2> (Backporting is part of SRU work, thus this is something that should be looked at. :) )
[16:47] <arraybolt3> Between the patches, there is no difference. Between the debdiffs, there's a *tiny* bit of difference resulting from the diff in the packaging between horst-5.1-2.1 and horst 5.1-3.
[16:49] <arraybolt3> that diff really boils down to slightly different build-depends
[16:49] <arraybolt3> anyway, not a concern, it builds fine.
[16:49] <tsimonq2> Concur, uploading
[16:50] <arraybolt3> also, to show I was paying attention, W: horst changes: debian-revision-not-well-formed 5.1-2.1ubuntu0.22.04.1 was spit out during the build, but that's because Lintian doesn't like that there's an NMU version number followed by an Ubuntu SRU version suffix.
[16:50] <arraybolt3> and with that,
[16:50] <arraybolt3> @pilot out
[16:50] <tsimonq2> hahahahahahahahahahahaha
[16:50] <arraybolt3> have to be to a meeting in ten minutes
[16:50] <tsimonq2> @pilot out
[16:50] <tsimonq2> arraybolt3: Have fun <3 there's still the Focal one to do later if you're up for it!
[16:51] <arraybolt3> thanks!
[16:51] <arraybolt3> will write a handoff post... probably now if I can cram it, otherwise in ~an hour and a half
[16:52] <cpete> tsimonq2: I was wondering what happened haha but I'm sure it'll be all good. Thanks for letting me know!
[16:52] <tsimonq2> cpete: Of course! btw, happy to help with those autopkgtest triggers if you need it :)
[16:56] <LocutusOfBorg> jbicha, thanks for rhythmbox!
[16:56] <LocutusOfBorg> do you also plan to merge in Ubuntu please?
[16:57] <LocutusOfBorg> (and als pulseaudio if possible thanks)
[16:57] <tsimonq2> LocutusOfBorg: People still use pulseaudio?
[16:57]  * tsimonq2 runs
[16:57] <LocutusOfBorg> alsa is the future?
[16:58] <arraybolt3> I still use ALSA on occasion :P
[16:58]  * arraybolt3 has flashbacks of KXStudio 14.04 where there was no Pulseaudio, just ALSA and JACK, wow that was fun to work with
[16:59] <sudip> arraybolt3: when you are running lintian, try passing "--profile=ubuntu" as an argument and it will not complain about the version number with ubuntu in it
[16:59] <arraybolt3> sudip: TIL, thanks!
[17:41] <cpete> tsimonq2: I will let you know if I do, thank you!