[10:08] <adrien> hey, is it possible to sync from experimental? xz 5.6.0 got released and decompression is massively faster (+60% on my intel and amd machines; unchanged on my pi5 but configure options could help) and I'd like to get that in
[10:45] <bluca> hi, any chance the SRU for dpkg in jammy could be looked at, please? it fixes using build profiles and we need that for the systemd CI - thanks
[10:46] <bluca> https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=dpkg
[11:27] <xnox> bdmurray: schopin: for the glibc autopkgtest with user namespace mitigation, i do wanter if on the autopkgtest instance types you should undo /usr/lib/sysctl.d/10-apparmor.conf
[11:27] <xnox> in /etc
[11:27] <xnox> with like
[11:27] <xnox> # If it is desired to disable this restriction, it is preferable to create an
[11:27] <xnox> # additional file named /etc/sysctl.d/20-apparmor.conf which will override this
[11:27] <xnox> # current file and sets this value to 0 rather than editing this current file
[11:27] <xnox> kernel.apparmor_restrict_unprivileged_userns = 1
[11:27] <xnox> as mentioned inside that file.
[11:27] <xnox> if you want it to = 0 in /etc then things will work as before and hopefully we can start getting glibc autopkgtest as passing; whilst we figure out how to do this more fine grained
[11:28] <schopin> xnox: I thought I'd *already* fixed the userns namespace thing!
[11:30] <schopin> The testsuite now gracefully handles EACCES on unshare(CLONE_USER) to mark the tests as UNSUPPORTED. This worked fine with 6.6, did the policy change with 6.8?
[11:32] <xnox> schopin: we see "regressions" in the v6.8 autopkgtest test result
[11:32] <xnox> schopin: maybe something else? https://ubuntu-archive-team.ubuntu.com/proposed-migration/noble/update_excuses.html#linux-meta
[11:33] <schopin> Yeah that's my point, it sounds like userns isn't the culprit.
[11:34] <xnox> autopkgtest for glibc/2.39-0ubuntu2: amd64: Regression ♻
[11:34] <xnox> ah
[11:35] <xnox> hmmmm..... given it's my last day, i don't want to read glibc tests logs https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-noble/noble/amd64/g/glibc/20240225_094321_7d892@/log.gz =) can you please tell me if it's kernel or glibc problem?
[11:35] <xnox> apw: schopin says it's likely not yet still apparmor thing again.... but something new
[11:42] <schopin> xnox: apw: hard to tell at a glance (although the tests were fine with 6.6 ;) ) and I can't reproduce locally just yet because autopkgtest is uncooperative. I figure the mount namespace failure might be apparmor again?
[11:45] <xnox> schopin: we did get "newer patch set"
[11:48] <georgiag> the behavior did change, unfortunately. now when there's an unconfined unprivileged userns, there's a transition to the unprivileged_userns profile which doesn't allow capabilities (if the /etc/apparmor.d/unprivileged_userns file/profile exists)
[11:49] <georgiag> so if the test needs capabilities after unshare(CLONE_USER), that's when it will fail
[11:57] <georgiag> I just looked and there's no mount permissions in the unprivileged_userns profile, so that's my best guess on why it's failing.
[12:03] <bluca> is launchpad having the monday blues?
[12:08] <ahasenack> yes, check status.canonical.com
[12:08] <ahasenack> it's recovering now
[12:15] <schopin> georgiag: where could I find some actual documentation on the topic? Best I have is https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces which is for the previous behavior.
[12:18] <georgiag> schopin: https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction
[12:18] <ahasenack> :q
[12:18] <ahasenack> ops
[12:18] <ahasenack> always gets me
 autopkgtest for dh-ada-library/8.9: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Not a regression, ppc64el: Pass, s390x: Pass
 juliank, ??
 287s standard-gpr         FAIL stderr: dpkg-shlibdeps: warning: diversions involved - output may be incorrect
 this looks like something done by glibc?
[12:34] <LocutusOfBorg> * KGB-2 (~kgb@kgb-2.bot.oftc.net) has joined
 for now I did migration-reference/0 and debhelper should migrate next run, but I don't know if we should ignore stderr, patch dpkg to emit just stdout instead of stderr, or whatever
 any idea?
[12:34] <LocutusOfBorg> juliank, ^^ please lets discuss here :D
[12:35] <schopin> georgiag: any documentation on the capabilities that are restricted? Just so that I don't play whack-a-mole when fixing the glibc test suite.
[12:42] <georgiag> schopin: all of them are denied. and anything that needs capabilities to work (like mount needs CAP_SYS_ADMIN). sorry but I don't have an explicit list, but capabilities(7) lists all capabilities and what uses it. I'll work on the apparmor documentation to improve this
[12:48] <juliank> LocutusOfBorg: possibly the DEP17 M4 protective diversions in base-files
[12:59] <schopin> georgiag: thanks, I should have realised we were talking about *those* capabilities.
[13:03] <schopin> I'm a bit amused that unshare(CLONE_NEWUSER | CLONE_NEWNS) seems to work, though. Presumably {unshare(CLONE_NEWUSER); unshare(CLONE_NEWNS);} would fail?
[13:42] <LocutusOfBorg> juliank, so where is the bug?
[13:45] <juliank> LocutusOfBorg: Where is what bug?
[13:46] <juliank> It is currently being evaluated over the next days whether the diversions are actually necessary, if they are, packages that weirdly get broken by it like this would need fixing
[13:47] <juliank> The reason they are there is such that when the last binary from /bin is moved to /usr/bin, dpkg doesn't go and delete your /bin symlink because it got confused by having it recorded as a directory (now empty) [and a symlink, now in noble]
[13:47] <juliank> Hence /bin is diverted to /bin.usr-is-merged
[13:49] <LocutusOfBorg> autopkgtest for dh-ada-library/8.9: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Not a regression, ppc64el: Pass, s390x: Pass
[13:49] <LocutusOfBorg> the bug is dh-ada-library autopkgtest regression in release for arm*
[13:49] <LocutusOfBorg> I don't like migration-reference/0 when the bug is release too, because nobody will ever look at it to fix :)
[13:50] <juliank> Rest assured it will get resolved in March in Debian
[13:50] <LocutusOfBorg> but if this is already something you are working on, I'm really happy to hear
[13:50] <LocutusOfBorg> and I move to next package on update_excuses page :D
[13:50] <LocutusOfBorg> debhelper just migrated, so I'm already happy
[14:04] <juliank> LocutusOfBorg: Please do report more such issues, you may also choose to report them to Debian directly, I just sent one for this instance to https://bugs.debian.org/1064840
[14:04] -ubottu:#ubuntu-devel- Debian bug 1064840 in src:dh-ada-library "dh-ada-library: Tests will fail after glibc DEP17 migration" [Normal, Open]
[14:05] <LocutusOfBorg> I wasn't sure about where the bug was located (and if it was Debian or Ubuntu only)
[14:07] <juliank> LocutusOfBorg: It *will be* a Debian bug :D
[14:07] <LocutusOfBorg> and this is really a good news
[15:57] <gps> Hi!  I am looking for pointers on the best way to get a package update into Ubuntu for 24.04.  I filed https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/2054895 requesting package update.
[15:57] -ubottu:#ubuntu-devel- Launchpad bug 2054895 in lighttpd (Ubuntu) "please upgrade: lighttpd 1.4.74" [Undecided, New]
[15:58] <gps> Any additional steps that I can take?  Thank you.  (I am a lighttpd developer (upstream))
[16:07]  * sudip can see https://bugs.debian.org/1064572 is waiting for a sponsor
[16:07] -ubottu:#ubuntu-devel- Debian bug 1064572 in sponsorship-requests "RFS: lighttpd/1.4.74-1 -- light, fast, functional web server" [Normal, Open]
[19:01] <cgmb> I'm trying to determine why roct-thunk-interface 5.7.0-1 failed to build on noble (amd64). There are no logs linked, so it's unclear to me what the problem was. https://launchpad.net/ubuntu/+source/roct-thunk-interface/5.7.0-1
[19:04] <cgmb> Just FYI, the Debian Sync Freeze will probably occur while the Debian ROCm packages are halfway through the process of being updated from clang-15 to clang-17. If Noble is to ship with working GPU compute libraries for AMD hardware, there will probably need to be somebody helping to bring Debian updates into Noble.
[19:06] <ginggs> cgmb: no log usually means the builder died
[19:07] <ginggs> i've retried roct-thunk-interface on amd64 and riscv64
[19:09] <cgmb> ginggs: Thanks! If I spot other stuck packages, is the best way to get them moving to ping chat here, or is there a better way for me to help?
[19:11] <ginggs> cgmb: i think pinging here should work
[19:12] <ginggs> if there are updated packages in debian after feature freeze, you can always requestsync https://wiki.ubuntu.com/SyncRequestProcess#requestsync
[20:08] <bluca> anyone who can approve SRUs around? would be great to have this fix in jammy: https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=dpkg