| === genii is now known as genii-core | ||
| 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:05 |
| seb128 | sil2100, yes, sounds like we need stable/ubuntu-20.04 created for gnome-3-38-2004 | 08:07 |
| seb128 | sil2100, I did that now, could you retry a build? | 08:12 |
| sil2100 | seb128: will do! One moment o/ Thanks a lot! | 09:02 |
| seb128 | sil2100, np! | 09:03 |
| juliank | genii-core: | 09:41 |
| juliank | Oops sorry | 09:41 |
| juliank | Autocomplete + typo | 09:41 |
| 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:42 |
| juliank | GunnarHj: that seems to be part of the openssl transition that schopin is working on | 09:43 |
| 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:44 |
| juliank | laptop is just recording a screencast for Google atm (build log crashing chrome), so can't interfere there | 09:45 |
| 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:46 |
| 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:47 |
| schopin | Yes, no, and nice! | 09:48 |
| juliank | Already on it | 09:48 |
| juliank | Already synced | 09:48 |
| 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:49 |
| schopin | Any taker for bug #1945768 ? :) | 09:51 |
| 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:52 |
| GunnarHj | schopin: As regards 1945768, why didn't you subscribe ubuntu-sponsors? | 09:56 |
| 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! | 09:58 |
| GunnarHj | schopin: Done. | 10:14 |
| schopin | \o/ | 10:15 |
| seb128 | sil2100, build worked :) | 10:21 |
| sil2100 | Yaay | 10:23 |
| 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:49 |
| schopin | 'checking whether the C compiler works... no' Well. That's a problem allright. | 10:50 |
| schopin | xypron: does this kind of failure ring any bell? ^ | 10:51 |
| GunnarHj | schopin: I just retried the riscv64 build. | 10:56 |
| === cpaelzer_ is now known as cpaelzer | ||
| GunnarHj | schopin: Looks like that error didn't repeat itself in the retried build. | 11:34 |
| 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:33 |
| 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:39 |
| mitya57 | So try symlinking it manually to /usr/share/javascript/clipboard.js/clipboard.js | 12:40 |
| mitya57 | dh_sphinxdoc simply tries to make sure that all files included in <script> tags really exist. | 12:41 |
| doko | looking ... | 12:43 |
| 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:23 |
| doko | looking ... | 13:39 |
| doko | ... and uploaded | 13:49 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| juliank | then we can see how those stack up | 15:25 |
| === genii-core is now known as genii | ||
| === alan_g__ is now known as alan_g | ||
| 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:15 |
| 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:25 |
| 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:26 |
| juliank | But as you mentioned it needs a lot of places | 16:27 |
| 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:21 |
| mwhudson | i care about the compression level during installs :) | 20:23 |
| 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:12 |
| mwhudson | RAOF: ok, do you have any idea how to formalize that? :) | 22:13 |
| RAOF | Oh, no! | 22:14 |
| mwhudson | i should probably email ubuntu-devel about this | 22:14 |
| mwhudson | added a note to the bug | 22:15 |
| RAOF | I might try and dump some thoughts there, too. | 22:17 |
| mwhudson | thanks | 22:19 |
| sergiodj | RAOF: hey, could you please reject two uploads for me? | 22:22 |
| sergiodj | RAOF: ubuntu-advantage-tools on Impish and Hirsute | 22:22 |
| RAOF | sergiodj: Sure! | 22:23 |
| sergiodj | thank yoU! | 22:23 |
| RAOF | Done. | 22:24 |
| sergiodj | RAOF: thank you very much | 22:24 |
| sergiodj | I'll fix and reupload them soon | 22:24 |
| 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:41 |
| 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] | 22:57 |
| mwhudson | i hope some of the fixes in this glibc update are worth the stress :) | 23:13 |
| 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:14 |
| 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:15 |
| 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:35 |
| 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:37 |
| mwhudson | shout out to first replier for boomer energy | 23:38 |
| 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:40 |
| mwhudson | not necessarily | 23:41 |
| mwhudson | people do, for some reason, use locales other than C :) | 23:41 |
| amurray | oh.. | 23:41 |
| 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:42 |
| mwhudson | ... maybe? autopkgtests in general are not good for detecting changes betwen versions | 23:44 |
| 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 | 23:49 |
| === genii is now known as genii-core | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!