[02:45] 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] Launchpad bug 1951033 in glibc (Ubuntu Focal) "20.04 SRU" [Undecided, Fix Committed] [02:45] RAOF: do you remember what this was about? [02:52] "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] RAOF: hm ok, do you know a snap like that off the top of your head? [02:53] The test case would be something like “run some GL-using snaps, on each of the supported graphics drivers” [02:54] Any flutter snap should suffice, I think? [02:54] That's probably the simplest option. [02:54] ok [02:54] so we still need a core20 snap with the new glibc in first? [02:55] Maybe? [02:55] Yes. [02:56] The host graphics drivers get copied in, but not the glibc, right? [02:56] i don't know! [02:57] i'm still an ubuntu server developer at heart :) [03:00] I think that's how it works 😬 [03:00] I still think of you as the golang guy. [03:06] 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] Unit193: that's mostly William (Wilson) now! [03:07] RAOF: no, mabye i should become familiar with that [03:07] well more familiar, i have heard of it [03:07] but first it's time to go into the big blue room for a bit [08:40] 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. === sem2peie- is now known as sem2peie [09:44] \o/ this now exists https://lists.ubuntu.com/mailman/listinfo/kinetic-changes [09:45] Last I looked it didn't exist on LP/the mirrors. :3 [09:45] one step at a time [09:46] (I'm waiting for the repo so I can add it to ubottu.) [09:56] RikMills: not sure my subscription attempt went anywhere when i tried to subscribe earlier though [10:14] Unit193: initializing it at the moment [10:14] Nice, will add it my tomorrow then. Thanks. [10:14] mwhudson: it subscribe me ok just a little while ago. or at least appeared to. I got the right responses back [10:46] RikMills: hmm tried again and it worked. maybe i typoed the email address earlier :) [11:31] and kinetic is here http://archive.ubuntu.com/ubuntu/dists/ [11:33] you stalking a kudu ;P [11:34] ppa builds also seem to work.... [11:34] ricotz: it seems so [11:37] so switching the sources.list already works :) [11:53] but who will be the first to dist-upgrade..? [11:54] just keep it rolling ... [12:24] hi, the mariadb build in launchpad is failing, and this looks like is the problem: [12:24] 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] it builds fine in a lxd container in a bare metal machine I have access to [12:24] so the question is, does it need a "bigger" builder vm? How can that be done? [12:24] https://launchpad.net/ubuntu/+source/mariadb-10.6/1:10.6.7-3/+build/23488405 [12:32] looks like it needs a slightly higher limit for memlock [13:34] 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] Bug 1911904 in corosync (Ubuntu Hirsute) "corosync locks all its current and future memory" [Medium, Fix Released] https://launchpad.net/bugs/1911904 [13:34] I'm trying a build with some measurements, to see if it's even trying to raise the limit [13:34] ahasenack: there are no bigger builder vms, that's not a thing [13:35] memlock limit may be tweakable with some effort, but also what ddstreet_away said === ddstreet_away is now known as ddstreet [13:36] ahasenack raising the limit will likely only delay the crash, and probably is the wrong approach [13:37] this is for a test it runs during build [13:37] if you read that bug, i laid out the issue in some detail [13:37] I will, thanks [13:37] but i am pretty sure simply raising its limit is the wrong thing to do [13:38] hilariously, it builds on the problematic architectures, like armhf and rsync :) [13:38] er, s/rsync/riscv64/ [13:38] armhf I know is in lxd, risc I don't know [13:46] 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] in any case, good luck with it :) [13:46] I think it's a change that came with uring support [13:47] in any case, `262144 bytes required` doesn't seem like a lot [13:52] mariadb seems to try to provide a systemd service override too, to increase the LimitMEMLOCK, maybe that just is defaulting too low [13:53] so maybe bumping that is all that's needed, at least until it hits the new limit later ;-) [13:56] during the test I doubt it uses systemd [13:56] it's launched directly I bet [13:58] huh, ulimit -l shows 64 just before the test starts [13:58] that's lower than even the ubuntu default, on a fresh jammy vm [14:12] bdmurray, hey, the http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls--incoming-bug-tasks.html for bb, ff, ii have no desktop section which seems weird, is there any known issue with those? [14:19] Dumb question: is the kk archive opened for uploads? [14:22] check the #topic in #ubuntu-release, but no, not yet open [15:35] ahasenack: "armhf I know is in lxd"> that's for autopkgtest, not for Launchpad builds [15:35] ahasenack: all .deb package builds in Launchpad run in chroots of the appropriate Ubuntu series inside focal VMs [15:36] (at present) [15:38] ah, right [15:38] (armhf lxd) [16:42] enr0n: there is an #ubuntu-mirrors channel [17:46] bdmurray: cool, thanks [18:13] 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] I do see desktop-packages in rls-ff-incoming [18:46] schopin: hi, during the openssl3 transition, did you encounter sendmail patches by any chance? [18:47] or a git repo from upstream? [18:47] That doesn't sound familiar, no. [19:35] schopin: did you have a tag for openssl3 related build failures? [19:57] 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] vorlon: great, thanks