[02:45] <mwhudson> RAOF: i seem to recall that i was talking to you when i added what's now part 4 of this bugs test case: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1951033
[02:45] <mwhudson> RAOF: do you remember what this was about?
 "RAOF (he/his): do you remember..." <- I believe that was about graphics drivers in snaps linking to the core glibc and sometimes getting broken by it?
[02:53] <mwhudson> RAOF: hm ok, do you know a snap like that off the top of your head?
[02:53] <RAOF> The test case would be something like “run some GL-using snaps, on each of the supported graphics drivers”
[02:54] <RAOF> Any flutter snap should suffice, I think?
[02:54] <RAOF> That's probably the simplest option.
[02:54] <mwhudson> ok
[02:54] <mwhudson> so we still need a core20 snap with the new glibc in first?
[02:55] <RAOF> Maybe?
[02:55] <RAOF> Yes.
[02:56] <RAOF> The host graphics drivers get copied in, but not the glibc, right?
[02:56] <mwhudson> i don't know!
[02:57] <mwhudson> i'm still an ubuntu server developer at heart :)
[03:00] <RAOF> I think that's how it works 😬
[03:00] <Unit193> I still think of you as the golang guy.
[03:06] <RAOF> mwhudson: are you familiar with using the testflinger infrastructure? That might be the easiest way to smoke-test the {all supported releases} × {all supported drivers} matrix.
[03:06] <mwhudson> Unit193: that's mostly William (Wilson) now!
[03:07] <mwhudson> RAOF: no, mabye i should become familiar with that
[03:07] <mwhudson> well more familiar, i have heard of it
[03:07] <mwhudson> but first it's time to go into the big blue room for a bit
[08:40] <serkan_> hi. any ideas how to preseed Ubuntu 21.04 and 22.0 desktop! ISO for autoinstall. with older ISOs my solution works since those ISOs still have isolinux folder. I pass preseed file to kernel command line in isolinux config. it works. doing the same in grub config file in 22.x and 21.x does not seem to work.
[09:44] <RikMills> \o/ this now exists https://lists.ubuntu.com/mailman/listinfo/kinetic-changes
[09:45] <Unit193> Last I looked it didn't exist on LP/the mirrors. :3
[09:45] <RikMills> one step at a time
[09:46] <Unit193> (I'm waiting for the repo so I can add it to ubottu.)
[09:56] <mwhudson> RikMills: not sure my subscription attempt went anywhere when i tried to subscribe earlier though
[10:14] <cjwatson> Unit193: initializing it at the moment
[10:14] <Unit193> Nice, will add it my tomorrow then.  Thanks.
[10:14] <RikMills> mwhudson: it subscribe me ok just a little while ago. or at least appeared to. I got the right responses back
[10:46] <mwhudson> RikMills: hmm tried again and it worked. maybe i typoed the email address earlier :)
[11:31] <RikMills> and kinetic is here http://archive.ubuntu.com/ubuntu/dists/
[11:33] <ricotz> you stalking a kudu ;P
[11:34] <RikMills> ppa builds also seem to work....
[11:34] <RikMills> ricotz: it seems so
[11:37] <ricotz> so switching the sources.list already works :)
[11:53] <laney> but who will be the first to dist-upgrade..?
[11:54] <ricotz> just keep it rolling ...
[12:24] <ahasenack> hi, the mariadb build in launchpad is failing, and this looks like is the problem:
[12:24] <ahasenack> 2022-04-14  8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required)
[12:24] <ahasenack> it builds fine in a lxd container in a bare metal machine I have access to
[12:24] <ahasenack> so the question is, does it need a "bigger" builder vm? How can that be done?
[12:24] <ahasenack> https://launchpad.net/ubuntu/+source/mariadb-10.6/1:10.6.7-3/+build/23488405
[12:32] <ahasenack> looks like it needs a slightly higher limit for memlock
[13:34] <ddstreet_away> ahasenack or maybe it should be fixed to handle failing to memlock, that's a problem with a few 'special' applications that think they should be exempt from ever swapping any of their memory, e.g. bug: #1911904
[13:34] <ahasenack> I'm trying a build with some measurements, to see if it's even trying to raise the limit
[13:34] <cjwatson> ahasenack: there are no bigger builder vms, that's not a thing
[13:35] <cjwatson> memlock limit may be tweakable with some effort, but also what ddstreet_away said
[13:36] <ddstreet> ahasenack raising the limit will likely only delay the crash, and probably is the wrong approach
[13:37] <ahasenack> this is for a test it runs during build
[13:37] <ddstreet> if you read that bug, i laid out the issue in some detail
[13:37] <ahasenack> I will, thanks
[13:37] <ddstreet> but i am pretty sure simply raising its limit is the wrong thing to do
[13:38] <ahasenack> hilariously, it builds on the problematic architectures, like armhf and rsync :)
[13:38] <ahasenack> er, s/rsync/riscv64/
[13:38] <ahasenack> armhf I know is in lxd, risc I don't know
[13:46] <ddstreet> ahasenack it looks like there is a --memlock param so i assume that's what is failing the test case, and from a quick 60 second scan of the code it seems like it only locks current memory (not future) in which case simply raising the RLIMIT_MEMLOCK would work, however that's not always possible inside (unprivileged) containers
[13:46] <ddstreet> in any case, good luck with it :)
[13:46] <ahasenack> I think it's a change that came with uring support
[13:47] <ahasenack> in any case, `262144 bytes required` doesn't seem like a lot
[13:52] <ddstreet> mariadb seems to try to provide a systemd service override too, to increase the LimitMEMLOCK, maybe that just is defaulting too low
[13:53] <ddstreet> so maybe bumping that is all that's needed, at least until it hits the new limit later ;-)
[13:56] <ahasenack> during the test I doubt it uses systemd
[13:56] <ahasenack> it's launched directly I bet
[13:58] <ahasenack> huh, ulimit -l shows 64 just before the test starts
[13:58] <ahasenack> that's lower than even the ubuntu default, on a fresh jammy vm
[14:12] <seb128> bdmurray, hey, the http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-<nn>-incoming-bug-tasks.html for bb, ff, ii have no desktop section which seems weird, is there any known issue with those?
[14:19] <schopin> Dumb question: is the kk archive opened for uploads?
[14:22] <ahasenack> check the #topic in #ubuntu-release, but no, not yet open
[15:35] <cjwatson> ahasenack: "armhf I know is in lxd"> that's for autopkgtest, not for Launchpad builds
[15:35] <cjwatson> ahasenack: all .deb package builds in Launchpad run in chroots of the appropriate Ubuntu series inside focal VMs
[15:36] <cjwatson> (at present)
[15:38] <ahasenack> ah, right
[15:38] <ahasenack> (armhf lxd)
[16:42] <bdmurray> enr0n: there is an #ubuntu-mirrors channel
[17:46] <enr0n> bdmurray: cool, thanks
[18:13] <bdmurray> seb128: I don't see desktop-packages in rls-ii but then I don't see foundations-bugs there either because they are no bugs which are tagged rls-ii-incoming for those teams
[18:13] <bdmurray> I do see desktop-packages in rls-ff-incoming
[18:46] <ahasenack> schopin: hi, during the openssl3 transition, did you encounter sendmail patches by any chance?
[18:47] <ahasenack> or a git repo from upstream?
[18:47] <schopin> That doesn't sound familiar, no.
[19:35] <ahasenack> schopin: did you have a tag for openssl3 related build failures?
[19:57] <vorlon> hallyn: heya - so this was not on my radar, but I can take care of merging the new upstream version early in kinetic cycle.  I'll let the current version hit the release pocket first though, to get rid of krb5 dependencies
[19:58] <hallyn> vorlon: great, thanks