[02:11] <teward> 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] <teward> at the same time slot
[09:26] <schopin> 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] <schopin> didn't notice that test_ssl was disabled in d/rules
[09:55] <mapreri> teward: sigh, actually not, I don't have any news myself. :|
[09:55] <mapreri> ddstreet: ↑
[10:57] <GunnarHj> Hi sil2100, the language pack generation for jammy seems still be broken.
[10:58] <sil2100> wow, still? Looking
[10:59] <sil2100> What the heck
[10:59] <sil2100> Ah, shit
[11:00] <GunnarHj> sil2100: I take it that you are about to fix it soon. ;)
[11:00] <sil2100> Yes, yet *another* missing empty directory due to the bzr -> git migration it seems :|
[11:00] <sil2100> Let me run through the bzr tree and see if there's any more
[11:04] <seb128> sil2100, urg, sorry, that's my fault since I did the conversion :-/
[11:04] <sil2100> seb128: it's fine, it's git that's at fault here ;p
[11:05] <seb128> sil2100, it's quite an annoying property of git indeed, not the first time it bites me at least :-/
[11:05] <sil2100> eh, same...
[11:08] <fheimes> dear archive-admins, could you please have a look at 'libzpc' in jammy's new queue - and consider it for acceptance?
[11:09] <seb128> fheimes, hey, I can do that for you :)
[11:13] <seb128> 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] <xnox> slyon:  i see some pings about systemd testing .... from over christmas.... was that sorted with bluca or not?
[11:14] <seb128> fheimes, and 2019
[11:14] <slyon> 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] <seb128> fheimes, there are several other years, please grep for Copyright and update the list as needed
[11:15] <xnox> 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] <juliank> vorlon: I see that half of the tests fail somehow, but can't say what the issue is
[11:16] <fheimes> hmm - mainly just took this over from upstream - I'll make sure it's adjusted with the next upload
[11:16] <fheimes> (doing a grep now ...)
[11:16] <juliank> I mean, OK, worker 10.44.124.16 has disk I/O errors
[11:16] <seb128> fheimes, accepted
[11:16] <juliank> and lxd-armhf-10.44.124.143 has a dead lxd
[11:17] <fheimes> seb128: many thx (also for the feedback)
[11:17] <juliank> 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] <juliank> hooray
[11:18] <juliank> this makes no sense
[11:18] <juliank> :D
[11:18] <juliank> ah ok, it makes sense /dev/vda2        43G   42G  872K 100% /var/snap/lxd/common
[11:19] <seb128> 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] <seb128> fheimes, it built and I NEWed the binaries now
[11:20] <fheimes> 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] <juliank> 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] <seb128> 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] <fheimes> 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] <juliank> somebody is running too many big tests at the moment, running the nodes out of space, breaking lxd
[11:26] <juliank> the lxd nodes need to be completely redone, IMO
[11:28] <juliank> also why do we use btrfs but then not lxd btrfs support, weird
[11:30] <juliank> (we don't use the fast subvolume based btrfs support, but setup lxd using the basic directory support...)
[11:32] <juliank> btrfs sub delete is a lot faster than rm -rf dirs :D
 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] <juliank> Well duh
[11:35] <juliank> rm -rf might take a few minutes
[11:35] <juliank> should convert them all to btrfs storage pools
[11:48] <hallyn> xnox: interesting, thanks.  Are those logged some place public?
[11:48] <xnox> hallyn:  are you on keybase?
[11:48] <xnox> hallyn:  i think there were things on mailing lists too.
[11:49] <xnox> hallyn:  but at the moment we still do not use authenticated var.
[11:53] <hallyn> xnox: not on keybase :(
[11:56] <hallyn> supposed to be a more user friendly version of kernel dev key web i guess?  hadn't seen it before.
[12:00] <xnox> 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] <juliank> So lxd-armhf10 (10.44.124.143) has a shot lxd database
[12:04] <juliank> Going to drop that worker
[12:08] <juliank> I am going to destroy that server and build up a new one
[12:08] <juliank> we really should have a public RT for autopkgtest cloud admin
[12:20] <juliank> ooh, bugs in the provisioning script too
[12:49] <schopin> looking for kind sponsors for LP: #1957170 and LP: #1957100
[12:54] <juliank> ok, we are a bit screwed right now on armhf
[12:55] <juliank> as in we can't build lxd contaienrs for jammy or impish
[12:56] <juliank> 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] <juliank> stgraber: going to move that topic to #lxc
[13:01] <juliank> laney: sorry to distrub, but do you remember why we use images:ubuntu/ instead of ubuntu-daily:?
[13:05] <sil2100> GunnarHj: new langpacks are there \o/
[13:05] <sil2100> Finally working as expected
[13:07] <juliank> let's just try ubuntu-daily: what could possibly go wrong
[13:10] <juliank> ah so the images: come without cloud-init
[13:22] <GunnarHj> sil2100: Great, thanks!
[13:23] <ahasenack> I forget, can a main package `Recommends` a universe one?
[13:48] <seb128> ahasenack, no
[13:52] <ahasenack> figured, thx
[14:09] <ddstreet> 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] <doko> schopin, it's applied in 3.9, but not in 3.10. now uploaded the lastter
[14:15] <ahasenack> are armhf dep8 testers overloaded?
[14:15] <ahasenack> or hung?
[14:16] <schopin> doko: oh right, the 3.9 failure seems unrelated to openssl
[14:31] <juliank> oops sorry, everything fails right now
[14:31] <mapreri> ddstreet: ack, pls do
[14:34] <juliank> OK, so hopefully the lxd workers will work a bit better now, albeit we lost 2 out of 11
[14:39] <seb128> 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] <seb128> 'libtool:   error: object name conflicts in archive: .libs/librsvg-2.lax/librsvg_c_api.a//<<BUILDDIR>>/librsvg-2.52.5+dfsg/./.libs/librsvg_c_api.a'
[14:39] <juliank> Going to record the state of autopkgtest-cloud work here:
[14:39] <juliank> 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] <juliank> 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] <juliank> 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] <juliank> 4. New lxd-armhf nodes use the btrfs storage backend, which is substantially faster to create/delete instance.
[14:39] <juliank> We should now be operating at 9/11 capacity.
[14:40] <ahasenack> thanks
[14:45] <seb128> 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:58] <juliank> It seems the change from delete to stop was incomplete, figuring out if this is fixable
[15:01] <sil2100> xnox: ok, so I suppose mwhudson and doko are on it, right?
[15:01] <sil2100> xnox: eh, wrong channel
[15:20] <seb128> mwhudson, I opened https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1957186 about it
[15:32] <juliank> we are down to 8/11 capacity, another one ran out of disk and presumably corrupted its lxd database
[15:33] <juliank> 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] <juliank> maybe 40ish GB is not enough for 3 parallel tests, but also why do we have like 20 containers on the hosts
[15:37] <juliank> I shutdown lxd cloud entirely, and am going to clean up all the nodes first
[17:31] <ahasenack> 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] <ahasenack> 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] <ahasenack> sent to the mailing list for discussion: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/JC3N3DBSMHZSA66IPLGAMBSXLCTYXWJR/
[17:33] <ahasenack> it's to fix https://bugs.launchpad.net/ubuntu/+source/realmd/+bug/1880157
[18:39] <tjaalton> ahasenack: I'd rather not keep sssd socket activated and get rid of these patches to sssd/realmd/freeipa
[18:39] <ahasenack> well, just one patch
[18:39] <ahasenack> which can be removed if we go back on the socket activation thing
[18:39] <ahasenack> (talking about realmd only, don't know which other patches are out there)
[18:40] <tjaalton> sssd itself is patched, and freeipa-client so that the config it creates doesn't have those lines
[18:42] <tjaalton> I tried to look back and see why it was made this way, but am not sure
[18:50] <ahasenack> well, I submitted that to debian now, it makes sense as long as sssd is socket-activated
[18:50] <ahasenack> if we drop socket activation, then we can drop this patch
[19:02] <tjaalton> sure
[20:44] <mwhudson> seb128: going to be bumping to 1.57 soon, is it fixed there?
[20:44] <seb128> mwhudson, no idea
[20:45] <mwhudson> doesn't look like it from the gnome gitlab
[20:47] <mwhudson> hm well
[20:53] <mwhudson> seb128: could you file a bug on the rustc source package about this?
[20:54] <seb128> mwhudson, https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1957186 as mentioned earlier ;-)
[20:54] <mwhudson> seb128: ah hah
[20:54]  * mwhudson waits for caffeine to kick in
[22:25] <mwhudson> jawn-smith: does your jammy schroot for sbuild have proposed enabled? i see a new shellcheck in proposed?
[22:27] <jawn-smith> mwhudson: I did try that using the --extra-repos flag, but I do think the new shellcheck is probably the reason
[22:28] <jawn-smith> So I'll just add all the quotes it wants
[22:29] <mwhudson> jawn-smith: imo your default schroots should have proposed enabled always
[22:29] <jawn-smith> seems reasonable