=== genii is now known as genii-core
[08:05] <sil2100> seb128: hey! We still get build errors, we might need to get the 20.04 track recreated?
[08:05] <sil2100> Fetching snap "gnome-3-38-2004"
[08:05] <sil2100> error: cannot download snap "gnome-3-38-2004": no snap revision available as specified
[08:07] <seb128> sil2100, yes, sounds like we need stable/ubuntu-20.04 created for gnome-3-38-2004
[08:12] <seb128> sil2100, I did that now, could you retry a build?
[09:02] <sil2100> seb128: will do! One moment o/ Thanks a lot!
[09:03] <seb128> sil2100, np!
[09:41] <juliank> genii-core:
[09:41] <juliank> Oops sorry
[09:41] <juliank> Autocomplete + typo
[09:42] <GunnarHj> Hi juliank, will you handle the libnet-ssleay-perl merge (bug #1951993)?
[09:42] <ubottu> Bug 1951993 in libnet-ssleay-perl (Ubuntu) "libnet-ssleay-perl FTBFS" [Undecided, New] https://launchpad.net/bugs/1951993
[09:43] <juliank> GunnarHj: that seems to be part of the openssl transition that schopin is working on
[09:44] <GunnarHj> juliank: Ok, so we can just wait a bit then?
[09:44] <juliank> Sorry for the delay, my laptop is busy and I went to the chromebook, but it's just resumed and slow too
[09:44] <schopin> ... and I'm in need of a sponsor for #1952208
[09:44] <juliank> schopin: I can sponsor that shortly if nobody beats me to it
[09:45] <juliank> laptop is just recording a screencast for Google atm (build log crashing chrome), so can't interfere there
[09:46] <juliank> Now
[09:46] <schopin> To be clearer : bug #1952208 is the resolution for the libnet-ssleay-perl woes :)
[09:46] <ubottu> Bug 1952208 in libnet-ssleay-perl (Ubuntu) "Sync libnet-ssleay-perl 1.91.01-1 (main) from Debian experimental (main)" [Wishlist, New] https://launchpad.net/bugs/1952208
[09:47] <GunnarHj> schopin: Is a sync from experimental all that needs? Is the existing patch not needed any longer? In that case I can do that.
[09:48] <schopin> Yes, no, and nice!
[09:48] <juliank> Already on it
[09:48] <juliank> Already synced
[09:49] <schopin> Some patches wait months for sponsors, while I have two competing for the same bug \o/
[09:49] <juliank> schopin: openssl transition is top priority :D
[09:51] <schopin> Any taker for bug #1945768 ? :)
[09:52] <ubottu> Bug 1945768 in erlang (Ubuntu) "erlang: Fail to build against OpenSSL 3.0" [Undecided, New] https://launchpad.net/bugs/1945768
[09:52] <GunnarHj> You beat me juliank. :/
[09:56] <GunnarHj> schopin: As regards 1945768, why didn't you subscribe ubuntu-sponsors?
[09:58] <schopin> I forgot it wasn't. For the initial patch, I deliberately didn't subscribe because I was waiting for us to be ready to upload OpenSSL3, and...
[09:58] <GunnarHj> schopin: Ok. Let me sponsor it.
[09:58] <schopin> Thanks!
[10:14] <GunnarHj> schopin: Done.
[10:15] <schopin> \o/
[10:21] <seb128> sil2100, build worked :)
[10:23] <sil2100> Yaay
[10:49] <GunnarHj> schopin: Did you see this:
[10:49] <GunnarHj> https://launchpadlibrarian.net/570712076/buildlog_ubuntu-jammy-riscv64.erlang_1%3A24.1.5+dfsg-1ubuntu1_BUILDING.txt.gz
[10:50] <schopin> 'checking whether the C compiler works... no' Well. That's a problem allright.
[10:51] <schopin> xypron: does this kind of failure ring any bell? ^
[10:56] <GunnarHj> schopin: I just retried the riscv64 build.
=== cpaelzer_ is now known as cpaelzer
[11:34] <GunnarHj> schopin: Looks like that error didn't repeat itself in the retried build.
[12:33] <doko> mitya57: any idea about https://paste.ubuntu.com/p/NPg4N9vPmH/ ? there's no reference to clipboard.min.js in the sources, only in the generated docs
[12:39] <mitya57> doko: I'm away from my laptop now, but wild guess: it's coming from sphinx-copybutton and our package has this patch: https://sources.debian.org/src/sphinx-copybutton/0.4.0-2/debian/patches/system-clipboard-js.patch
[12:40] <mitya57> So try symlinking it manually to /usr/share/javascript/clipboard.js/clipboard.js
[12:41] <mitya57> dh_sphinxdoc simply tries to make sure that all files included in <script> tags really exist.
[12:43] <doko> looking ...
[13:23] <schopin> Looking for a sponsor, another openssl3 related upload: bug #1945764
[13:23] <ubottu> Bug 1945764 in crda (Ubuntu) "crda: Fail to build against OpenSSL 3.0" [Undecided, New] https://launchpad.net/bugs/1945764
[13:23] <schopin> Perhaps someone from the kernel team would like to take a look?
[13:39] <doko> looking ...
[13:49] <doko> ... and uploaded
[15:15] <xnox> juliank:  update-initramfs: Generating /boot/initrd.img-5.13.0-19-generic
[15:15] <xnox> No lz4 in /usr/bin:/sbin:/bin, using gzip => is odd in autopkgtests in jammy on s390x, because initrd should be using zstd compression in like hirsute and jammy.
[15:15] <xnox> juliank:  as if the base image needs to be rebuilt form scratch / did not get upgraded correctly to the latest initramfs-tools config.
[15:16] <juliank> xnox: no, we override the compression
[15:16] <xnox> juliank:  /o\ without installing lz4?!
[15:16] <juliank> xnox: apparently
[15:16] <xnox> juliank:  cause initramfs-tools dropped lz4 dep, when i changed it to zstd. Yeah, if you want lz4 for speed, then yeah, it needs to be installed as well.
[15:16] <juliank> xnox: we should really fix the zstd compressino level to be usable
[15:17] <juliank> I think -15 was 10% larger but compressed a couple times faster
[15:17] <juliank> Right now, it's slower than xz at compressing
[15:17] <juliank> or sameß
[15:18] <juliank> I think installing lz4 is probably not a good idea vs just using gzip
[15:18] <juliank> but I don't know, I haven't really measured how much the speed difference is
[15:20] <juliank> I mean, we now boot like 0.1s faster but need a couple minutes more to install kernel upgrades
[15:20] <juliank> so anyway, I guess installing lz4 works too, it will make image builds slightly slower, but initrd rebuidls in tests faster
[15:22] <xnox> juliank:  i can see the point of tweaking initrd compression level especially the ones that are built on the end user machine.
[15:22] <juliank> should we have different levels for pre-built kernels vs initrd built on upgrade?
[15:22] <xnox> the initrds that we prebuild can be set to infinity (i.e. the ones created during livecd-rootfs)
[15:22] <juliank> I think that would work
[15:22] <juliank> well
[15:23] <juliank> you want -19 on those
[15:23] <juliank> -20, -21, the --ultra levels are slower to decompress too
[15:23] <xnox> right, cdimage/livecd-root/ubuntu-core-initrd should be using -19
[15:23] <xnox> whilst initramfs-tools default for end user systems should be like -15
[15:23] <xnox> would be nice if we could autodetect that somehow, or export the right env variable somewhere. I bet we'd have to patch this in 7+ places
[15:24] <juliank> when building in a chroot -> build at -19
[15:24] <juliank> otherwise -> build at -15
[15:24] <juliank> hacky whacky idea
[15:24] <juliank> I can recompress my initrd at all levels and make a level, speed, size table
[15:25] <juliank> then we can see how those stack up
=== genii-core is now known as genii
=== alan_g__ is now known as alan_g
[16:15] <xnox> but our installers run in a chroot, so when subiquity/ubiquity chroot /target update-initramfs => should that be -19 or -15?
[16:15] <xnox> i err on the side of -15
[16:15] <xnox> (aka like the subsequent updates will be)
[16:25] <juliank> xnox: doesn't matter much at install time
[16:25] <juliank> xnox: in terms of relative time use
[16:25] <juliank> I think
[16:26] <juliank> more concerned with ugliness of it all
[16:26] <juliank> adding an option for the compression level and then override in conf.d where we wnat it to be 19 might be a good idea
[16:27] <juliank> But as you mentioned it needs a lot of places
[20:21] <mwhudson> anyone have thoughts on my plans for testing the glibc 20.04 sru? https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1951033
[20:21] <ubottu> Launchpad bug 1951033 in glibc (Ubuntu) "20.04 SRU" [Undecided, New]
[20:23] <mwhudson> i care about the compression level during installs :)
[22:12] <RAOF> mwhudson: I think you should explicitly call out testing *graphical* snaps on a variety of drivers/hardware (mesa, amdpro, nvidia), as that's been troublesome in the past.
[22:13] <mwhudson> RAOF: ok, do you have any idea how to formalize that? :)
[22:14] <RAOF> Oh, no!
[22:14] <mwhudson> i should probably email ubuntu-devel about this
[22:15] <mwhudson> added a note to the bug
[22:17] <RAOF> I might try and dump some thoughts there, too.
[22:19] <mwhudson> thanks
[22:22] <sergiodj> RAOF: hey, could you please reject two uploads for me?
[22:22] <sergiodj> RAOF: ubuntu-advantage-tools on Impish and Hirsute
[22:23] <RAOF> sergiodj: Sure!
[22:23] <sergiodj> thank yoU!
[22:24] <RAOF> Done.
[22:24] <sergiodj> RAOF: thank you very much
[22:24] <sergiodj> I'll fix and reupload them soon
[22:41] <RAOF> tjaalton: What sort of support does the proprietary amdgpu stack have from us? I don't have a workstation GPU, so it's hard to check :)
[22:57] <mwhudson> hm i can't reproduce https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379
[22:57] <ubottu> Launchpad bug 1926379 in glibc (Ubuntu) "stack smashing attack detected in bash host tab completion" [Undecided, Confirmed]
[23:13] <mwhudson> i hope some of the fixes in this glibc update are worth the stress :)
[23:14] <mwhudson> sarnold: hiya, did you ever understand what was going on in https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379 ?
[23:14] <ubottu> Launchpad bug 1926379 in glibc (Ubuntu) "stack smashing attack detected in bash host tab completion" [Undecided, Confirmed]
[23:15] <mwhudson> sarnold: i'm trying to work up if upgrades from the dodgy 0ubuntu9.3 to a planned 0ubuntu9.4 really need to be prevented
[23:15] <mwhudson> *work out
[23:35] <amurray> mwhudson: speaking of glibc, is this https://twitter.com/jer_s/status/1463709224697950210 something we should try and avoid/detect/automatically handle in affected packages (ie somehow trigger postgres to automatically rebuild indexes or somesuch on upgrades of glibc?)
[23:37] <mwhudson> amurray: it's something we and our users need to be aware of for sure
[23:37] <mwhudson> amurray: not sure about triggering index rebuilds on updates, that sounds _fairly_ hair raising
[23:38] <mwhudson> shout out to first replier for boomer energy
[23:40] <mwhudson> amurray: i have _very carefully_ checked that the C.utf8 locale that is now upstream collates the same way as the one we currently ship, fwiw :)
[23:40] <amurray> awesome - thanks, so does that mean going forward it should be less of a problem?
[23:41] <mwhudson> not necessarily
[23:41] <mwhudson> people do, for some reason, use locales other than C :)
[23:41] <amurray> oh..
[23:42] <amurray> ah right.. of course - so then I wonder if we should have an autopkgtest to try and detect changes so that we can then warn users on upgrades which we know could be problematic?
[23:44] <mwhudson> ... maybe? autopkgtests in general are not good for detecting changes betwen versions
[23:49] <amurray> I guess I was thinking we could generate a set of known data from the current version, and then do the same in the test and check it still matches or somesuch
=== genii is now known as genii-core