[05:44] <fenris> hi ... any planned on releasing signed kernel 6.x ?
[09:16] <ogayot> Hi, could somebody retry the builds for python-leidenalg 0.9.1-1? The package failed to build initially but should now succeed since python-igraph 0.10 is in -proposed. Thanks!
[09:17] <ogayot> https://launchpad.net/ubuntu/+source/python-leidenalg/0.9.1-1
[09:17] <seb128> ogayot, hey, doing so
[09:17] <ogayot> seb128: thank you!
[09:19] <seb128> np!
[09:53] <seb128> tsimonq2, hey, was it right to upload those casper changes when you get a -1 in review?
[14:06] <tsimonq2> seb128: The -1 in review was after I uploaded it, and his concern was around confusing the installer, which didn't change in behavior following the upload.
[14:06] <tsimonq2> seb128: I'd be happy to revert if it actually caused a regression or was causing a bug, this literally doesn't change the expected behavior.
[15:57] <enr0n> tsimonq2: thanks for the ping, looking at it now
[16:22] <tsimonq2> enr0n: Sounds good, let me know if you need testing help :)
[16:22] <enr0n> tsimonq2: thanks. Right now I think that changing casper is correct. I don't think it was ever right to statically allocate a UID/GID in that range
[16:24] <tsimonq2> paride: Hey! Just wanted to follow up on https://code.launchpad.net/~tsimonq2/+git/autodep8/+merge/436412 since I'm not sure you're subscribed - let me know if there's anything further I can do to help :)
[16:25] <tsimonq2> enr0n: I agree that changing casper was correct, but I think v_orlon might have a point about systemd as well :)
[16:26] <enr0n> tsimonq2: I believe it is conforming with the Debian policy actually. I left a comment on the bug
[16:30] <tsimonq2> enr0n: I think the part of Debian Policy that both systemd and casper violated is "Packages which need a user or group, but can have this user or group allocated dynamically and differently on each system, should use adduser --system to create the group and/or user."
[16:30] <tsimonq2> The most precise question I think can be asked is: does systemd statically set those UIDs/GIDs, and if so, is there a particular reason?
[16:31] <vorlon> we got away with it in casper because we knew there weren't going to be 899 IDs allocated in this range in the installer context, and the casper user goes away post-install
[16:32] <vorlon> systemd doesn't statically set them, it allocates them using "first available" ID at boot time; however, it seems to start checking "first available" from the other direction
[16:35] <vorlon> from a policy perspective, I think the biggest bug is: policy says to use adduser; adduser has a config file that lets the admin change the allowed range (to subset it, perhaps, for compatibility with "legacy" IDs shared across an authentication domain); systemd doesn't honor adduser.conf but instead has its limit hard-coded at build time
[16:38] <enr0n> vorlon: I'll look into the adduser.conf piece specifically. But note that we as a distro can configure systemd's boundaries at build time
[16:39] <vorlon> enr0n: yes, but the disconnect is with it not honoring changes specified by the admin at runtime
[16:39] <paride> tsimonq2, hi, thanks! that's on our radar
[16:40] <tsimonq2> paride: Sounds good! Thanks :)
[16:40] <tsimonq2> vorlon: Is this worth raising in Debian as well, maybe?
[16:40] <vorlon> tsimonq2: yes
[16:41] <vorlon> enr0n: fwiw this is not entirely theoretical for me, I have a multi-user system that in the dawn of time was installed as Red Hat which started its user uid range at 500 and we never renumbered after moving to Debian :-)
[16:44] <tsimonq2> (TIL someone has attempted to move a system from Red Hat to Debian... :) )
[16:44] <cjwatson> 500> so do I!
[16:45] <cjwatson> I reinstalled but kept the home directory.  In err 1999 I think ...
[16:45] <enr0n> vorlon: understood
[16:47] <vorlon> cjwatson: right! :)
[16:47] <tsimonq2> enr0n: Is reporting this to Debian something you'd like to take on, or should I take this as a fun learning experience? ;)
[16:47] <cjwatson> every time I have to do a conffile merge of adduser.conf I think "maybe I should get round to the giant pain of renumbering" and then don't
[16:48] <enr0n> tsimonq2: I'll start a conversation in #debian-systemd for starters I think
[16:48] <enr0n> I would like to see if this is something they have discussed already
[16:52] <tsimonq2> Sounds good :) thanks again enr0n!
[16:53] <Laibsch> How is an ordinary user these days supposed to nominate a bug for fix in a stable release?  I used to have that privilege as a member of bug-control or something like that but lost it when timing out when renewing for that group.
[16:53] <tumbleweed> you ask somebody on bug-control (e.g. here)  to nominate it for you
[16:54] <enr0n> tsimonq2: no problem
[16:54] <Laibsch> tumbleweed: I see. Thank you.
[16:56] <Laibsch> I'd like to nominate bug 2004098 for jammy.  I care for LTS quality.
[16:56] -ubottu:#ubuntu-devel- Bug 2004098 in anki (Ubuntu) "python 3.10 does stricter type checking" [Undecided, Fix Released] https://launchpad.net/bugs/2004098
[17:00] <tsimonq2> Laibsch: Hey! How about Kinetic?
[17:01] <Laibsch> tsimonq2: sure, be my guest
[17:01] <Laibsch> I'm happy to fix both at the same time
[17:01] <Laibsch> but I am really an LTS-only user
[17:01] <Laibsch> this should be very straight-forward as the previous version in all pockets is the same
[17:09] <tsimonq2> Laibsch: How about this - I'll meet you halfway. If you fill out the bug report the way the SRU Team wants it per https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template, I'll take care of the uploads :)
[17:12] <tsimonq2> RikMills: bug2004156
[17:12] <tsimonq2> bug 2004156
[17:12] -ubottu:#ubuntu-devel- Bug 2004156 in prison-kf5 (Ubuntu) "Please rebuild  5.101.0-0ubuntu1 against zxing-cpp 1.4" [Undecided, New] https://launchpad.net/bugs/2004156
[17:20] <Laibsch> tsimonq2: you got the easy stuff ;-)  But of course, that's what I was suggesting, anyhow.  I just need the ticket to be nomindated for the two release pockets.
[17:21] <tsimonq2> vorlon, cjwatson: (in case you're curious) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029785
[17:21] -ubottu:#ubuntu-devel- Debian bug 1029785 in systemd "systemd-sysusers doesn't respect SYS_UID_RANGE in /etc/login.defs" [Wishlist, Open]
[17:22] <tsimonq2> Laibsch: I'll do the nomination now.
[17:23] <enr0n> tsimonq2: was just going to link that bug here. That's what the debian folks pointed me to
[17:23] <tsimonq2> Same page :)
[17:50] <vorlon> tsimonq2: hmm login.defs is for groupadd not addgroup, the latter is what Debian Policy specifies
[18:01] <tsimonq2> Interesting. I'm curious to see what Nick comes up with. :)
[18:09] <enr0n> need to go AFK for a while, but I will keep looking into this
[18:14] <tsimonq2> Thanks again :)
[19:36] <mdeslaur> Skuggen: hi! Do you know if there are any changes planned for https://bugs.mysql.com/bug.php?id=109685 ? Or is the current status to leave it as-is?
[19:45] <vpa1977> Hi would it be possible to retry java-commons regression: https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=jsurf-alggeo&trigger=java-common%2F0.74 it looks like a race condition in a test - I've just tried, they pass locally.
[19:46] <Eickmeyer> vorlon: friendly reminder to reply to the edubuntu TB thread. :)
[19:46] <vorlon> ecack
[19:46] <vorlon> Eickmeyer: ack
[19:46] <Eickmeyer> :)
[19:47] <bdmurray> vpa1977: I can do that
[19:47] <vpa1977> bdmurray: Thank you !!!!!
[23:22] <dbungert> after a rejected upload, is it conventional that the fixed version has the same version number, or incremented?
[23:27] <jbicha> dbungert: either way is fine. Personally, I usually use a higher version number because I likely already pushed a git release tag for the version number and it's easy to use a higher number.
[23:27] <dbungert> jbicha: thanks!