[02:11] ddstreet: mapreri: anything for the backporters meeting in ~14 hours from now, or no? Asking 'cause FT job (and a law enforcement partner!) dropped a meeting on my schedule i gotta be present on. [02:11] at the same time slot === genii is now known as genii-core === mfo_ is now known as mfo === sem2peie- is now known as sem2peie === jelmer_ is now known as jelmer [09:26] doko: I have apparently forgotten to add the openssl-3.0.1-version-check.diff line to d/p/series in python3.{9,10}, hence the autopkgtest failures. Sorry :/ [09:38] didn't notice that test_ssl was disabled in d/rules [09:55] teward: sigh, actually not, I don't have any news myself. :| [09:55] ddstreet: ↑ [10:57] Hi sil2100, the language pack generation for jammy seems still be broken. [10:58] wow, still? Looking [10:59] What the heck [10:59] Ah, shit [11:00] sil2100: I take it that you are about to fix it soon. ;) [11:00] Yes, yet *another* missing empty directory due to the bzr -> git migration it seems :| [11:00] Let me run through the bzr tree and see if there's any more [11:04] sil2100, urg, sorry, that's my fault since I did the conversion :-/ [11:04] seb128: it's fine, it's git that's at fault here ;p [11:05] sil2100, it's quite an annoying property of git indeed, not the first time it bites me at least :-/ [11:05] eh, same... [11:08] dear archive-admins, could you please have a look at 'libzpc' in jammy's new queue - and consider it for acceptance? [11:09] fheimes, hey, I can do that for you :) [11:13] fheimes, I'm not going to reject due to that but several source use ' Copyright IBM Corp. 2021' so please update the debian/copyright to list 2021 in the next upload [11:13] slyon: i see some pings about systemd testing .... from over christmas.... was that sorted with bluca or not? [11:14] fheimes, and 2019 [11:14] xnox: yes some of the upstream CI/autopkgtest were blocked. I think I saw juliank working on this yesterday and they resolved it IIRC [11:15] fheimes, there are several other years, please grep for Copyright and update the list as needed [11:15] hallyn: MS did manage do self-signed sbat testing end to end; by building shim in devel mode which uses alternative variables...... doing that testing resulted in discovering authenticated variable handling issues. [11:15] vorlon: I see that half of the tests fail somehow, but can't say what the issue is [11:16] hmm - mainly just took this over from upstream - I'll make sure it's adjusted with the next upload [11:16] (doing a grep now ...) [11:16] I mean, OK, worker 10.44.124.16 has disk I/O errors [11:16] fheimes, accepted [11:16] and lxd-armhf-10.44.124.143 has a dead lxd [11:17] seb128: many thx (also for the feedback) [11:17] Jan 12 11:16:58 lxd-armhf10 lxd.daemon[26303]: error: error renaming /var/snap/lxd/common/lxd/logs/lxd.log.7.gz to /var/snap/lxd/common/lxd/logs/lxd.log.8.gz: No space left on device [11:17] hooray [11:18] this makes no sense [11:18] :D [11:18] ah ok, it makes sense /dev/vda2 43G 42G 872K 100% /var/snap/lxd/common [11:19] fheimes, oh, and another piece of feedback, there is a tests dir so would be nice to have those run as part of the build which doesn't seem the case atm? [11:20] fheimes, it built and I NEWed the binaries now [11:20] seb128: to get that test going a test framework needs to be pulled down during build from Google - and what I've heard is that this is a nogo ... [11:20] we really ought to get to the point where we only keep lxd workers for a month or so and them rotate to avoid them piling up crap [11:22] fheimes, alright, I didn't investigate, the test documentation refers only to googletest which we have in the archive but I don't know the specifics of the project, I figured out I would mention it anyway :) [11:25] seb128: ok (I had that test once in, but reviewer didn't like that things are pulled from external sources during build - I plan to start a discussion with upstream to find a better was ...) [11:25] somebody is running too many big tests at the moment, running the nodes out of space, breaking lxd [11:26] the lxd nodes need to be completely redone, IMO [11:28] also why do we use btrfs but then not lxd btrfs support, weird [11:30] (we don't use the fast subvolume based btrfs support, but setup lxd using the basic directory support...) [11:32] btrfs sub delete is a lot faster than rm -rf dirs :D [11:34] : failure: ['lxc', 'delete', '--force', 'lxd-armhf-10.44.124.14:autopkgtest-lxd-wgklwr'] failed (exit status 1, stderr 'Error: Stopping the instance failed: Instance "stop" operation timed out after 30 seconds\n') [11:34] Well duh [11:35] rm -rf might take a few minutes [11:35] should convert them all to btrfs storage pools [11:48] xnox: interesting, thanks. Are those logged some place public? [11:48] hallyn: are you on keybase? [11:48] hallyn: i think there were things on mailing lists too. [11:49] hallyn: but at the moment we still do not use authenticated var. [11:53] xnox: not on keybase :( [11:56] supposed to be a more user friendly version of kernel dev key web i guess? hadn't seen it before. [12:00] hallyn: oh no, the gpg stuff is aweful inside it. but it does have e2e encrypted team git, chat, and file share. Which is useful for private development and disclosures. [12:03] So lxd-armhf10 (10.44.124.143) has a shot lxd database [12:04] Going to drop that worker [12:08] I am going to destroy that server and build up a new one [12:08] we really should have a public RT for autopkgtest cloud admin [12:20] ooh, bugs in the provisioning script too [12:49] looking for kind sponsors for LP: #1957170 and LP: #1957100 [12:49] Launchpad bug 1957170 in libio-socket-ssl-perl (Ubuntu) "libio-socket-ssl-perl depends on obsolete libssl1.1" [Undecided, New] https://launchpad.net/bugs/1957170 [12:49] Launchpad bug 1957100 in lintian (Ubuntu) "Merge lintian 2.114.0 from Debian unstable" [Wishlist, New] https://launchpad.net/bugs/1957100 [12:54] ok, we are a bit screwed right now on armhf [12:55] as in we can't build lxd contaienrs for jammy or impish [12:56] stgraber: autopkgtest-cloud uses images:ubuntu/$release/armhf to build images across all releases; those do not exist on impish and jammy since dec 12 or so, so things are somewhat broken [12:57] stgraber: going to move that topic to #lxc [13:01] laney: sorry to distrub, but do you remember why we use images:ubuntu/ instead of ubuntu-daily:? [13:05] GunnarHj: new langpacks are there \o/ [13:05] Finally working as expected [13:07] let's just try ubuntu-daily: what could possibly go wrong [13:10] ah so the images: come without cloud-init [13:22] sil2100: Great, thanks! [13:23] I forget, can a main package `Recommends` a universe one? [13:48] ahasenack, no [13:52] figured, thx === klebers_ is now known as klebers [14:09] teward mapreri unfortunately nothing new from me either re: backporters mtg, let's cancel this week and i'll schedule another in 2 weeks? i think the holidays pushed this to the bottom of the todo list, but hopefully we can get back into it by next mtg [14:15] schopin, it's applied in 3.9, but not in 3.10. now uploaded the lastter [14:15] are armhf dep8 testers overloaded? [14:15] or hung? [14:16] doko: oh right, the 3.9 failure seems unrelated to openssl [14:31] oops sorry, everything fails right now [14:31] ddstreet: ack, pls do [14:34] OK, so hopefully the lxd workers will work a bit better now, albeit we lost 2 out of 11 [14:39] bah, librsvg fails to build on arm64 only, https://launchpadlibrarian.net/579855597/buildlog_ubuntu-jammy-arm64.librsvg_2.52.5+dfsg-1ubuntu1_BUILDING.txt.gz [14:39] 'libtool: error: object name conflicts in archive: .libs/librsvg-2.lax/librsvg_c_api.a//<>/librsvg-2.52.5+dfsg/./.libs/librsvg_c_api.a' [14:39] Going to record the state of autopkgtest-cloud work here: [14:39] 1. I disabled the lxd-armhf10 worker, and built up a new one. It's waiting for impish and jammy lxd images to be published again (images: remote) [14:39] 2. I disabled the worker 10.44.124.16, as it has disk/IO errors. It needs to be deployed from scratch again as well [14:39] 3. I replaced use of `lxc delete -f` with `lxd stop`, as the former has a 30s stop timeout which is too low for us (as we used `dir` storage pool). Can be reverted eventually once all nodes use btrfs backend [14:39] 4. New lxd-armhf nodes use the btrfs storage backend, which is substantially faster to create/delete instance. [14:39] We should now be operating at 9/11 capacity. [14:40] thanks [14:45] mwhudson, hey, that librsvg error I just mentioned is discussed in https://gitlab.gnome.org/GNOME/librsvg/-/issues/787 and seems to be a rust bug, any chance we cherry pick the fix to ubuntu? seems to be https://github.com/rust-lang/compiler-builtins/commit/06497726 [14:45] Issue 787 in GNOME/librsvg "'Unknown attribute kind' on M1(arm) macbook" [Opened] [14:45] Commit 0649772 in rust-lang/compiler-builtins "Merge pull request #444 from Amanieu/lse_o" === genii-core is now known as genii [14:58] It seems the change from delete to stop was incomplete, figuring out if this is fixable [15:01] xnox: ok, so I suppose mwhudson and doko are on it, right? [15:01] xnox: eh, wrong channel [15:20] mwhudson, I opened https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1957186 about it [15:20] Launchpad bug 1957186 in rustc (Ubuntu) "librsvg fails to build on arm64" [Undecided, New] [15:32] we are down to 8/11 capacity, another one ran out of disk and presumably corrupted its lxd database [15:33] We made the fatal mistake of placing /var/snap/lxd/common on the same disk as the storage pools, allowing tests to corrupt the database and DoS the infra just by writing to much data [15:36] maybe 40ish GB is not enough for 3 parallel tests, but also why do we have like 20 containers on the hosts [15:37] I shutdown lxd cloud entirely, and am going to clean up all the nodes first === genii is now known as genii-core === genii-core is now known as genii [17:31] tjaalton: hi, did I ever talk to you about submitting this sssd patch to debian? https://git.launchpad.net/ubuntu/+source/realmd/tree/debian/patches/dont-add-services-line.patch [17:32] tl;dr it's about realmd not adding a nss,pam services line to the config, since our (debian/ubuntu) sssd is socket activated [17:33] sent to the mailing list for discussion: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/JC3N3DBSMHZSA66IPLGAMBSXLCTYXWJR/ [17:33] it's to fix https://bugs.launchpad.net/ubuntu/+source/realmd/+bug/1880157 [17:33] Launchpad bug 1880157 in realmd (Ubuntu) "realmd generates wrong 'services' section in sssd.conf during joining to AD" [Low, Fix Released] === diddledani_ is now known as diddledani === nicolasbock_ is now known as nicolasbock === davdunc_ is now known as davdunc === toddr_ is now known as toddr === jamespage_ is now known as jamespage === Trevinho_ is now known as Trevinho === rpittau_ is now known as rpittau === tomreyn- is now known as tomreyn === oerheks_ is now known as oerheks === ogra` is now known as ogra [18:39] ahasenack: I'd rather not keep sssd socket activated and get rid of these patches to sssd/realmd/freeipa [18:39] well, just one patch [18:39] which can be removed if we go back on the socket activation thing [18:39] (talking about realmd only, don't know which other patches are out there) [18:40] sssd itself is patched, and freeipa-client so that the config it creates doesn't have those lines [18:42] I tried to look back and see why it was made this way, but am not sure === tomreyn_ is now known as tomreyn [18:50] well, I submitted that to debian now, it makes sense as long as sssd is socket-activated [18:50] if we drop socket activation, then we can drop this patch [19:02] sure === lucas_ is now known as lucas [20:44] seb128: going to be bumping to 1.57 soon, is it fixed there? [20:44] mwhudson, no idea [20:45] doesn't look like it from the gnome gitlab [20:47] hm well [20:53] seb128: could you file a bug on the rustc source package about this? [20:54] mwhudson, https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1957186 as mentioned earlier ;-) [20:54] Launchpad bug 1957186 in rustc (Ubuntu) "librsvg fails to build on arm64" [Undecided, New] [20:54] seb128: ah hah [20:54] * mwhudson waits for caffeine to kick in === locutusofborg_ is now known as LocutusOfBorg === stgraber_ is now known as stgraber === RikMills__ is now known as RikMills [22:25] jawn-smith: does your jammy schroot for sbuild have proposed enabled? i see a new shellcheck in proposed? [22:27] mwhudson: I did try that using the --extra-repos flag, but I do think the new shellcheck is probably the reason [22:28] So I'll just add all the quotes it wants [22:29] jawn-smith: imo your default schroots should have proposed enabled always [22:29] seems reasonable