[00:26] <mwhudson> vorlon: i think you forgot to push the tag when you uploaded livecd-rootfs
[00:27] <vorlon> mwhudson: I didn't forget, but maybe there was a failure I didn't pay attention to
[00:27] <vorlon> $ git push --tags
[00:27] <vorlon> Everything up-to-date
[00:27] <mwhudson> vorlon: well ok. ubuntu/master has 2.895 as UNRELEASED
[00:28] <vorlon> um
[00:28] <mwhudson> which i realize isn't quite what i first said
[00:29] <vorlon> mwhudson: oh I see, I failed to commit it, so pushing did nothing
[00:29] <vorlon> this is all git-ubuntu's fault
[00:29] <vorlon> (for not being able to replace our standalone livecd-rootfs branch ;)
[00:30] <mwhudson> well
[00:30] <mwhudson> i suppose i should make my out of control shell script i use for uploading things work nicely with git-ubuntu repos
[00:32] <vorlon> oh no Debian is removing stale i386-only packages that emulate game consoles
[00:35] <vorlon> not sure Debian should keep the i386 arch around at all if it's not needed for zsnes, really
[08:00] <schopin> RikMills: there's something going on in Debian in plasma vs glibc 2.37 in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040140 . Do you know if we had similar reports for Lunar?
[08:00] -ubottu:#ubuntu-devel- Debian bug 1040140 in libc6 "libc6: upgrade libc6 to version 2.37-3 break plasma desktop (X11/Wayland)" [Important, Open]
[11:01] <slyon> @pilot in
[15:15] <halves> hello ubuntu-devel! I'm a little confused on a version for an SRU I'm working on, and would like to double check it with a more experienced dev. it's for adsys on Kinetic, which currently has version 0.9.2. given this is a native Ubuntu package, what would the next version string look like for an SRU?
[15:16] <slyon> @pilot out
[15:16] <halves> if I follow the security team's "UpdatePreparation" page/table, it seems a candidate would be 0.9.2ubuntu0.1. I've looked at the other stable releases for adsys, and noticed that they seem to follow the pattern of "~YY.MM.X" (e.g. 0.9.2~20.04.1 for focal)
[15:17] <halves> so I'm wondering if for the next Kinetic update, we should follow this same version scheme as well. does that make sense?
[15:17] <slyon> hey halves! There's some nice documentation on that, which you can find here: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[15:17] <slyon> let me check your specific case..
[15:17] <halves> slyon thanks! that's the page I was looking at, the table there is quite helpful indeed
[15:18] <halves> it does seem to suggest a different version scheme for the other releases though, which is where my confusion started (i.e. 0.9.2ubuntu0.1 vs 0.9.2~22.10.1)
[15:18] <slyon> halves: do I understand correctly that the SRU contains just some small fixes for adsys 0.9.2, not any new upstream version, right?
[15:19] <halves> slyon that's correct
[15:20] <slyon> we use the ~22.10.1 suffix usually when we "backport" a newer version from a more recent Ubuntu version. E.g. Lunar might contain 0.9.2 while kinetic might contain 0.9.2~22.10.1
[15:20] <slyon> in this case it's not a backport (just some small fixes) and recent Ubuntu version have newer upstream versions of adsys already, so I'd rule out the ~22.10.1 suffix
[15:21] <slyon> And go with 0.9.2ubuntu0.1 instead
[15:22] <halves> awesome! that makes sense, thank you slyon!
[15:22] <slyon> Oh, we even have that special case with the Jammy version here.
[15:23] <slyon> Having 0.9.2~22.04.1 (jammy) < 0.9.2ubuntu0.1 (kinetic) < 0.11.0 (lunar) should work just fine!
[15:26] <halves> yes, for this specific SRU though we're also targeting jammy, but it won't break the version ordering
[15:27] <halves> thanks again, slyon!
[15:29] <slyon> halves: right. To apply similar fixes to Jammy, you'd just continue with the existing versioning scheme, e.g.: 0.9.2~22.04.2
[15:31] <slyon> Or alternatively, do a full backport of your previous Kinetic SRU, which would lead do: 0.9.2ubuntu0.1~22.04.1 -- both cases would work, but the former is more common
[17:03] <kanashiro[m]> @pilot in
[17:18] <gilles_> Hi, I was looking to get a package, namely mailman3, that was excluded from 22.04 due to now-resolved compatability issues back into Ubuntu, preferably in 22.04 itself. I'm not really familiar with packaging though, I was wondering if anyone had some pointers as to where I could start with this?
[17:32] <kanashiro[m]> gilles_: at this point, you need a good reason to introduce a package to a stable release. I am not familiar with the mailman3 package, but I think you might have dependency issues on the way
[17:34] <bluca> slyon: did you have any luck looking at the netplan.io autopkgtest failures?
[17:34] <bluca> they are blocking both systemd and iproute2 now
[17:45] <gilles_> kanashiro[m]: I believe it should work without too many dependency issues, see https://bugs.launchpad.net/ubuntu/+source/mailman3/+bug/1999197/comments/7 (+ some of my own poking around as to why it was removed and what has changed)
[17:45] -ubottu:#ubuntu-devel- Launchpad bug 1999197 in mailman3 (Ubuntu) "mailman3 package missing in jammy, however mailman3 package from Debian 11 works with the other mailman3 packages from Jammy" [Undecided, Confirmed]
[17:45] <gilles_> But yes, I'm not completely clear on what the procedures for this would even be, and I can't really get a properly clear image of what is or isn't possible from the wiki
[17:58] <kanashiro[m]> gilles_: as you may have seen this was the reason of mailman3 removal: LP #1960547 . If you check the Debian's tracker page (https://tracker.debian.org/pkg/mailman3) you will see that it is still looking for help, and at the moment it is marked for autoremoval by the end of the month. I am not sure the situation described in the removal bug changed that much.
[17:58] -ubottu:#ubuntu-devel- Launchpad bug 1960547 in mailman3 (Ubuntu) "please remove mailman3, mailman-hyperkitty" [Undecided, Fix Released] https://launchpad.net/bugs/1960547
[18:02] <gilles_> kanashiro[m]: Thanks for pointing that out, I had missed it completely. I'll dig a little more to see if it's something I (or my org) can work on or if we should look into other options. Thanks!
[18:03] <kanashiro[m]> I just pulled the mailman3 version from mantic and rebuilt it in jammy, it works without any issue, so that's a good sign at least
[18:06] <kanashiro[m]> gilles_: since a straight backport of the version in mantic works in Jammy we have increased our chances to get it back in jammy :) we can try a one-time SRU to re-introduce the package. I am running autopkgtest locally to see if I can spot any issue
[18:18] <kanashiro[m]> gilles_: all tests are passing, I think we can give it a try if you are still interested. You could do the paper work which means updating the bug description (LP #1999197) to add the SRU bug template (https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template), and I can handle the package changes for you. Be aware that some action from you will be required to test the package in case the archive admins/SRU team decide to accept
[18:18] <kanashiro[m]> the package (Test plan section in the SRU bug template).
[18:18] -ubottu:#ubuntu-devel- Launchpad bug 1999197 in mailman3 (Ubuntu) "mailman3 package missing in jammy, however mailman3 package from Debian 11 works with the other mailman3 packages from Jammy" [Undecided, Confirmed] https://launchpad.net/bugs/1999197
[18:19] <kanashiro[m]> If you decide to do so, let me know, once you update the bug, I can review it and prepare the package to be uploaded
[18:27] <gilles_> kanashiro[m]: I'm definitely interested in doing the paperwork, might take a while but I'll update you once I've done it. Thanks for helping me get started!
[18:28] <kanashiro[m]> gilles_: great! You are more than welcome :)
[21:04] <kanashiro[m]> @pilot out
[21:58] <mwhudson> er
[21:58] <mwhudson> livecd-rootfs in proposed is broken?
[22:16] <mwhudson> ah https://code.launchpad.net/~mwhudson/livecd-rootfs/+git/livecd-rootfs/+merge/446003