[00:46] <Unit193> Hrm, any idea when riscv will be available for PPAs?
[00:56] <sarnold> Unit193: I've got a checkbox on one of my ppas, though maybe I have that due to magic powers
[00:56] <Unit193> My box is all grayed out.
[00:56] <sarnold> oh :(
[00:57] <Unit193> Which normally I don't care about riscv at all, but something is failing only there, and for some silly reason it's not migrating.
[00:57] <sarnold> Unit193: probably the way to find out if you can have it flipped is to file a question on the launchpad questions section
[00:57] <sarnold> Unit193: I think some of the biletto ppas have it enabled too, would that be any help?
[00:57] <Unit193> sarnold: Well...I don't really want special treatment if it's not really ready yet. :3
[00:57] <sarnold> (I've never tried these)
[00:57] <Unit193> I have no idea how to use those either. :D
[00:57] <sarnold> hehe
[01:24] <sarnold> Unit193: heh, was it failing package tests? https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1891686
[01:40] <Trevinho> mwhudson: if it helps, this is the diff of what has been installed in gjs (+ proposed) vs the failing one: https://paste.ubuntu.com/p/VDTQpzVWQT/
[01:40] <Trevinho> mwhudson: gobject-introspection amd64 1.64.1-1build2 looks to be a good candidate
[01:42] <mwhudson> Trevinho: yeah, sounds plausible
[01:43] <Trevinho> mwhudson: you can probably do a build1 with that, or I can but tomorrow
[01:43] <mwhudson> Trevinho: well it's also part of the libffi transition so they will migrate together
[01:43] <Trevinho> yeah, sure,  I mean if we need to have a specific b-d for britney happyness
[01:44] <mwhudson> i don't think so
[01:44] <mwhudson> thanks for checking though!
[02:23] <Unit193> sarnold: FTBFS.
[07:04] <rs2009> Hi, I noticed that the filesystem.squashfs in the Groovy Gorilla daily builds have /boot/vmlinuz and /boot/initrd.img as broken symlinks. They point to initrd.img-* and vmlinuz-*, which do not exist. I was building a custom Ubuntu ISO from an existing Ubuntu 20.10 daily ISO using the chroot method. I copied the initramfs from the /casper/ directory
[07:04] <rs2009> in the custom disk and installed the linux-image in the chroot, as I needed to change the plymouth logo. I then ran update-initramfs -u -k all inside the chroot. I copied /boot/initrd.img to /casper/ and built the ISO. When I booted the ISO in a VM, it showed the plymouth boot screen for one second, after which it dropped to the BusyBox initramfs
[07:04] <rs2009> prompt. Did something change in 20.10? I'm not aware of any change apart from the switch to GRUB for both BIOS and UEFI.
[12:08] <ddstreet> Laney i think the autopkgtest armhf lxd-worker needs to be restarted to pick up a worker.conf change, to make haveged a long_test; it is still running it with the default timeout, though haveged was added to long_tests a week or so ago
[12:08] <ddstreet> could you check it when you have a chance?
[12:08] <Laney> ddstreet: it does, who deployed it?
[12:08] <Laney> they might need some education
[12:08]  * Laney brings out the education stick
[12:08] <ddstreet> Laney you mean who deployed autopkgtest? this is on the official builders https://autopkgtest.ubuntu.com/packages/h/haveged/groovy/armhf
[12:08] <Laney> who merged the config change
[12:09] <ddstreet> oh, i think vorlon
[12:09] <ddstreet> https://git.launchpad.net/autopkgtest-cloud/commit/?id=5763aed3a3a1c1eb3839bf74263f885ae979527e
[12:10] <Laney> right, missed being done on armhf
[12:10] <Laney> done now
[12:10] <ddstreet> thanks!
[15:02] <xnox> rs2009: is this desktop or server?
[15:03] <xnox> rs2009:  did you also specify environmental variable to trigger casper initrd to be generated with uuid checks?
[15:18] <rs2009> xnox: This is the desktop variant. I wasn't building a daily image, rather was chrooting into the ISO and making some changes, and then rebuilding the ISO.
[15:19] <xnox> rs2009:  when rebuilding initrd you must set CASPER_GENERATE_UUID environment variable.
[15:19] <xnox> rs2009:  or have grub.cfg to have boot=casper
[15:19] <xnox> in kernel commandline.
[15:20] <rs2009> xnox: I already have boot=casper in the kernel commandline.
[15:20] <xnox> rs2009:  by default we build initrd for the iso with CASPER_GENERATE_UUID=y set, matching uuid committed on the iso in .disk/, and with clean kernel commandline.
[15:20] <xnox> rs2009:  in that case i don't know why your boot failed. and you do not give enough information for me to suggest antyhing to you.
[15:21] <xnox> rs2009:  it sounds like you have missbuilt your kernel/initrd pair, and it doesn't match the rest of the iso.
[15:23] <rs2009> xnox: I was building a custom Ubuntu ISO from an existing Ubuntu 20.10 daily ISO (using the chroot method) when I saw that /boot/initrd.img and /boot/vmlinuz are broken symlinks in filesystem.squashfs. I copied the initramfs from the /casper/ directory in the custom disk and installed the linux-image in the chroot, as I needed to change the
[15:23] <rs2009> plymouth logo. I then ran update-initramfs -u -k all inside the chroot. I copied /boot/initrd.img to /casper/ and built the ISO. When I booted the ISO in a VM, it showed the plymouth boot screen for one second, after which it dropped to the BusyBox initramfs prompt.
[15:28] <rs2009> xnox: the daily ISO has 5.4.0-42-generic (checked in /lib/modules) and the initrd kernel version corresponds to it.
[15:33] <rs2009> xnox: This issue does not happen with the default initramfs, rather with an initramfs built with update-initramfs
[15:33] <Laney> rbalint: https://launchpadlibrarian.net/495890903/buildlog_ubuntu-groovy-armhf.mozjs78_78.2.0-1~fakesync1_BUILDING.txt.gz does this interest you?
[15:34] <Laney> also, I saw your ping on that autopkgtest-cloud MR, will review this week
[15:34] <xnox> rs2009:  you should have no need to install linux-image.... as that one might be different from the rest of iso.
[15:34] <xnox> rs2009:  and you should restore initrd&vmlinuz from casper into where the broken links point to.
[15:35] <xnox> rs2009:  and you should generate new initrd for that same kernel version, not any other different one.
[15:35] <xnox> rs2009:  calling update-initramfs without environment variables set, and without correct kernel version as installed in the chroot, will not generate a complete nor valid initrd usable for cd boot.
[15:37] <rs2009> xnox: The issue happens without linux-image as well. I had restored the initrd and vmlinuz to where the broken links point to. I was building the initramfs for the kernel in the ISO only. I did not know that it was mandatory to build with CASPER_GENERATE_UUID=y set. I thought it wasn't required if boot=casper was being added to the command line.
[15:39] <xnox> rs2009: and how did you rebuild the initrd? which kernel version did you specify?
[15:40] <xnox> rs2009:  after you build with CASPER_GENERATE_UUID=y you also need to copy out the same uuid into the iso. otherwise there will be uuid-missmatch and you will fail to boot.
[15:41] <rs2009> xnox: I used update-initramfs and specified 5.4.0-42-generic which I found in /lib/modules/.
[15:42] <xnox> rs2009:  yeap that's the right version number, so that should have worked.
[15:42] <rs2009> xnox: I'm trying out CASPER_GENERATE_UUID=y right now
[15:42] <xnox> generate initrd with UUID, copy it out and place it on the iso in .disk/ dir, remaster the iso and hopefully things will start working
[15:43] <xnox> if they don't, edit kernel cmdline and append ignore_uuid to ignore uuid missmatch, to doulbe check if that's what's causing the failure to boot
[15:59] <rs2009> xnox: ignore_uuid works, so it looks to be an issue with the UUID. I couldn't find the UUID in the output of update-initramfs.
[16:33] <xnox> rs2009:  it's inside the initrd.... one has to unpack it to copy it into the .disk/uuid
[16:34] <rs2009> xnox: Yes, I was doing that :) Thank you for your help!
[19:54] <rbalint> Laney, re: MR, thanks! re: mozjs, no, sorry, i'd like to get glibc rounds done first