[00:48] -queuebot:#ubuntu-release- New binary: intel-ipsec-mb [amd64] (impish-proposed/universe) [1.0-1] (kubuntu)
[07:56] <cpaelzer> Is there a known issue with autopkgtest.u.c to not pick up new testcase status/logs anymore?
[07:56] <cpaelzer> as an example in excuses I see qemu blocked by autopkgtest for casper/1.465: amd64: Regression
[07:57] <cpaelzer> and while the link behind "Regression" gets me to the log as expected, the link behind "amd64" gets me as usual to https://autopkgtest.ubuntu.com/packages/c/casper/impish/amd64 but there the test isn't listed
[07:57] <cpaelzer> I've had a few such cases, to me it seems sicne ~2 days no logs go into the pare-test-per-arch overview pages anymore
[07:57] <cpaelzer> I missed to read about it on ML or here, so is this a known issues and would anyone have a pointer to it for me?
[07:59] <cpaelzer> I've picked a bunch of random other ones - like https://autopkgtest.ubuntu.com/packages/a/alertmanager-irc-relay/impish/ppc64el not listing https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/a/alertmanager-irc-relay/20210819_040524_dc3cc@/log.gz for curl and so on
[07:59] <cpaelzer> so I guess everyone working on excuses should see it
[08:08] <sil2100> juliank: hey! Were you able to verify grub2's LP: #1937115 ?
[08:08] <sil2100> xnox: ^
[08:08] <sil2100> Whoops, wrong bug
[08:08] <sil2100> juliank, xnox: I meant LP: #1901553
[08:10] <juliank> sil2100: I haven't had the chance yet, it was too close to EOD yesterday, I just caught up with stuff and I can start now
[08:12] <sil2100> juliank: thanks!
[08:13] <sil2100> In the meantime I did a daily test install today on my Dell laptop and everything looks good + seeing all the positive reports re: the new shim and the lack of new issues on LP, I'll release the focal shims in a moment
[08:41] <juliank> sil2100, xnox I'm stuck verifying the initrdless documentation bug, as generic just boots fine without the initramfs for me, so I don't get fallback https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1901553
[08:42] <juliank> Maybe I need to setup the hard disk as a different type of device in qemu
[08:42] <juliank> However qemu refuses to boot from it when using virtio or virtio-scsi
[08:43] <juliank> Ah UEFI does the trick
[08:44] <juliank> sil2100: verified
[08:44] <juliank> This monster was the command-line: kvm -drive file=ubuntu-20.04-minimal-cloudimg-amd64.img,if=none,id=hd,format=qcow2 -device virtio-scsi-pci,id=scsi  -device scsi-hd,drive=hd -boot c -drive file=/tmp/x/nocloud.iso,format=raw -nic user,model=virtio-net-pci -nographic -m 2048 -cpu host -smp 4  -bios OVMF.fd
[08:44] <juliank> it was fun
[08:50] <sil2100> juliank: thanks for the verification!
[08:51] <sil2100> Releasing!
[08:51] <sil2100> Ok, this means we have everything \o/
[08:51] <sil2100> Let's wait for the publisher to do its thing and then kick our first 20.04.3 RCs
[08:52] <juliank> I was just thinking about shim udpates for xenial ESM
[08:52] <juliank> I'm not sure that works, because we need to get the shims signed with the archive key
[08:52] <juliank> I guess we could grab them from focal
[08:53] <juliank> every release having its own signed binaries is sorta confusing anyway
[09:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.3] (20210819) has been added
[09:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.3] (20210819) has been added
[09:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unleashed [Focal 20.04.3] (20210819) has been added
[09:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unmatched [Focal 20.04.3] (20210819) has been added
[09:47] <sil2100> Those are not yet candidate images ^
[09:47] <sil2100> Didn't spin those just yet
[10:14] <xnox> vorlon:  pinged them on mattermost; still awaiting response from sbeattie
[10:17] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.3] (20210819) has been added
[10:17] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.3] (20210819) has been added
[10:17] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.3] (20210819) has been added
[10:17] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.3] (20210819) has been added
[10:17] <sil2100> Same with this one ^
[10:18] <sil2100> Ok, I'll be spinning image builds now
[10:48] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.3] (20210819) has been added
[10:51] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.3] (20210819) has been added
[10:56] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.3] (20210819) has been added
[10:58] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.3] (20210819.1) has been added
[11:04] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.3] (20210819.1) has been added
[11:09] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.3] (20210819) has been added
[11:09] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.3] (20210819) has been added
[11:09] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.3] (20210819.1) has been added
[11:11] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.3] has been updated (20210819.1)
[11:11] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.3] has been updated (20210819.1)
[11:11] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.3] has been updated (20210819.1)
[11:11] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.3] has been updated (20210819.1)
[11:42] <cpaelzer> has anyone seen my call this morning (~4h ago) if anyone has-seen / is-working-on on autopkgtest results missing to be listed on autopkgtest-u-c?
[11:49] <paride> sil2100, hi! I spotted an ISO testing failure on s390x, I can't reproduce it manually but it always fails with the utah "preseeded" installs (answers.yaml)
[11:50] <paride> basically when the system reboots I get an initramfs prompt, I think it can't find the root filesystem or similar issues
[11:50] <paride> I've been working on this for a while now but still didn't get to the bottom of it
[11:53] <paride> interestingly the installation works if I take the utah-generated answers.yaml and feed it to the installer system it works
[11:53] <paride> with the very same ISO
[11:56] <laney> cpaelzer: I missed it, sorry, let me see
[11:56] <laney> I think one of the backends hasn't got a running download-results
[11:56] <laney> juliank: ^------------ future work to make sure that keeps running
[11:57] <cpaelzer> Thanks laney, can that be recovered only for future runs or will re-enabling that find and add all missed results?
[11:57] <laney> we have a job that can backfill missing stuff
[11:58] <laney> cpaelzer: if you edit your cookies using web developer tools and change SRVNAME to S1 then you can see them on the other node
[11:58] <laney> (might have to reauth to request.cgi then)
[12:01] <cpaelzer> no new auth needed, and indeed I see what I missed
[12:01] <cpaelzer> need to check if all I was missing is there now, but it sounds like the jobs will recover that in background - so maybe I just wait
[12:01] <laney> there you go, a peek under the covers
[12:01]  * cpaelzer feels like I learned a dark secret today
[12:03] <sil2100> paride: hey! When did that test failure start?
[12:04] <paride> sil2100, serial 20210814
[12:05] <paride> and the boot fails with: ALERT!  /dev/disk/by-path/ccw-0.0.0001-part1 does not exist.  Dropping to a shell!
[12:05] <paride> indeed it doesn't exist but /dev/disk/by-path/ccw-0.0.0000-part1 does
[12:05] <paride> and if I mount it there is the root filesystem
[12:18] <paride> I've got it booting by manually changing the disk "devno" in the libvirt xml
[12:19] <paride> so something changed somewhere, but images are probably fine. Now I need to find a proper fix
[12:21] <sil2100> paride: ok, thanks for the info, wanted to know if it was due to -proposed being disabled or not, but 0814 had already -proposed
[12:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.3] (20210819.1) has been added
[12:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.3] (20210819.1) has been added
[12:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.3] (20210819.1) has been added
[12:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.3] (20210819.1) has been added
[12:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Focal 20.04.3] (20210819.1) has been added
[12:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.3] (20210819.1) has been added
[12:37] <sil2100> Most flavor .3 images are now built! Please proceed with testing! http://iso.qa.ubuntu.com/qatracker/milestones/425/builds
[12:41] <paride> sil2100, I changed how the preseed image (the disk image containing subiquity's answers.yaml) is defined in the VM xml, so that when it's removed the "devno"s do not change, and the test passes now
[12:41] <paride> manually it did already pass. I'd say that the images are good, but I don't know what changed to trigger the problem
[12:47] <sil2100> \o/
[13:25] <xnox> paride:  updated qemu, has updated devices, with different numbers. you could manually specify the devno for the answers.yaml disk and pick a high one, such that there is enough room for other auto-enumerated devices.
[13:26] <xnox> paride:  then removal of it should not matter. I also wonder if we can, at all, dump the used numbers for devices => i.e. including those that qemu / libvirt autoenumerate
[13:26] <paride> sil2100, so to cross-check, this batch of images is the one we want to consider quasi-RCs, correct?
[13:27] <paride> xnox, thanks!
[13:31] <sil2100> Yes, these hopefully are our .3 images
[13:41] <paride> great
[13:42] <ricotz> hi :), could someone please accept the vala packages in the new queue of impish?
[13:44] -queuebot:#ubuntu-release- New: accepted intel-ipsec-mb [amd64] (impish-proposed) [1.0-1]
[13:48] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.3] has been updated (20210819.1)
[13:48] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.3] has been updated (20210819.1)
[13:48] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unleashed [Focal 20.04.3] has been updated (20210819.1)
[13:48] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unmatched [Focal 20.04.3] has been updated (20210819.1)
[13:53] <sil2100> ricotz: done!
[13:54] -queuebot:#ubuntu-release- New: accepted vala [amd64] (impish-proposed) [0.52.5-1~sync1]
[13:54] -queuebot:#ubuntu-release- New: accepted vala [armhf] (impish-proposed) [0.52.5-1~sync1]
[13:54] -queuebot:#ubuntu-release- New: accepted vala [ppc64el] (impish-proposed) [0.52.5-1~sync1]
[13:54] -queuebot:#ubuntu-release- New: accepted vala [s390x] (impish-proposed) [0.52.5-1~sync1]
[13:54] -queuebot:#ubuntu-release- New: accepted vala [arm64] (impish-proposed) [0.52.5-1~sync1]
[13:54] -queuebot:#ubuntu-release- New: accepted vala [riscv64] (impish-proposed) [0.52.5-1~sync1]
[13:54] -queuebot:#ubuntu-release- New: accepted vala [i386] (impish-proposed) [0.52.5-1~sync1]
[13:55] <ricotz> sil2100, thank you \o/
[13:57] <juliank> laney: Needs like restart on failure, but also start download-all-results
[14:01] <laney> juliank: looks like systemd never tried to start it after it got resized OH what it's not installed
[14:02]  * juliank can't parse second half of sentence
[14:03] <laney> systemctl enable download-results.service
[14:04] <laney> s/installed/enabled/ I guess
[14:06] <laney> we do have Restart=on-failure tho
[14:37] <sil2100> jibel: hey! Will you be able to add a WSL image to the isotracker?
[14:37] <sil2100> jibel: by that I mean a manual build, maybe somehow adjusting the download link? Do we have a test case..?
[15:04] <fossfreedom> sil2100: the iso tracker download link for the ubuntu budgie is invalid. Any ideas?
[15:07] <sil2100> fossfreedom: I can fix that! But I would expect it to be working correctly
[15:14] <sil2100> fossfreedom: ok, should be fixed now!
[15:14] <sil2100> Weirdly I think it was like this for .0, .1 and .2!
[15:15] <fossfreedom> Many thx.
[15:20] <jibel> sil2100, sure, I'll add it
[15:21] -queuebot:#ubuntu-release- Unapproved: curl (focal-proposed/main) [7.68.0-1ubuntu2.6 => 7.68.0-1ubuntu2.7] (core, i386-whitelist)
[15:23] <xypron> fftw3 3.3.8-2ubuntu7 is stuck in impish-proposed for 7 days: could you, please, indicate why migration failed.
[15:23] <xypron> There was no build failure when in impish-proposed.
[15:24] <schopin> xypron: not a build failure but an autopkgtest failure in one of its reverse dependencies.
[15:24] <bdmurray> It failed b/c the autopkgtest for xmds2 was was triggered by a new version of fftw3
[15:25] <bdmurray> and the xmds2 autopkgtest failed with the new version of fftw3
[15:27] <bdmurray> https://autopkgtest.ubuntu.com/packages/x/xmds2/impish/amd64 if you look in the triggers column you can see things which have caused xmds2's autopkgtests to run
[15:33] <bdmurray> xypron: ^^
[15:34] <xypron> bdmurray: saw your comment
[16:16] <sbeattie> vorlon: I've signed off on the openssl xenial-proposed update to go xenial-security in LP: #1928989, thanks. (cc xnox)
[16:47] <paride> sil2100, I submitted a the main test results for the 20210819.1 subiquity ISOs
[17:01] <vorlon> sbeattie, xnox: excellent, thank you
[17:10] <vorlon> laney, sil2100, juliank: ppc64el used to be one of our fastest autopkgtest architectures; are we still down a compute region?
[23:43] -queuebot:#ubuntu-release- New sync: gnome-shell-extension-sound-device-chooser (impish-proposed/primary) [38-2]