[00:27] <vorlon> Laney: I've hinted gobject-introspection past the libreoffice/{arm64,s390x} autopkgtests, which have a high chance of failing after a long time and telling us nothing new
[00:59] <vorlon> doko: I've taken care of what I know how to with autopkgtests blocking python3-defaults, the others seem to be either hairy upstream incompatibilities with 3.8, or breakages I can't parse like meson.  How should we handle these from here?
[01:26] <vorlon> Laney: and gobject-introspection is through, I'm going to do a no-change rebuild myself since I've got a few other things I'm waiting on behind that fix
[03:24] -queuebot:#ubuntu-release- New: accepted hdrmerge [amd64] (focal-proposed) [0.5+git20200117-2]
[03:24] -queuebot:#ubuntu-release- New: accepted salt [amd64] (focal-proposed) [2019.2.3+dfsg1-2]
[03:24] -queuebot:#ubuntu-release- New: accepted oasis3 [amd64] (focal-proposed) [3.mct+dfsg.121022-14]
=== pieq_ is now known as pieq
[07:06] <ginggs> tarzeau: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#colmap
[07:06] <ginggs> missing build on ppc64el: libcolmap-dev (from 3.5-1build1)
[07:07] <ginggs> needs to build on ppc64el or file a bug requesting removal on that architecture
[07:07] <tarzeau> libcolmap-dev got dropped with later versions
[07:07] <tarzeau> nothing ever used/linked against it
[07:08] <tarzeau> so how can i file a bug requesting removal of libcolmap-dev on ALL architectures?
[07:08] <tarzeau>   * d/control: drop libcolmap-dev package. 5/nov/19
[07:08] <ginggs> file a bug and subscribe ~ubuntu-archive
[08:14] <infinity> ginggs, tarzeau: Removal of libcolmap-dev isn't the issue, the issue is that it's not building on ppc64el, thus the old version's binaries still exist there.
[08:14] <infinity> No need to file bugs to ask us to remove packages that are no longer built.
[08:15] <ginggs> infinity: if colmap is never going to build on ppc64el, it still needs removal
[08:15] <infinity> Do we know it's "never going to build"?
[08:15] <infinity> I saw no mention of that.
[08:15] <ginggs> infinity: tarzeau is the maintainer
[08:16] <infinity> Yes, and?
[08:16] <infinity> He didn't say anything about ppc64el, did he?
[08:16] <ginggs> infinity: so he can tell you, but i can see it doesn't build in debian
[08:17] <ginggs> hence "needs to build on ppc64el or file a bug requesting removal on that architecture"
[08:17] <infinity> Right, but then the conversation got mistakenly derailed into being about libcolmap-dev.
[08:17] <infinity> Which is what I was commenting on.
[08:18] <ginggs> infinity: ack
[08:20] <infinity> Seems to now depend on ceres-solver, which is FTBFS on ppc64el due to a few test failures that I imagine someone could sort out in minutes if they knew the code.
[08:39] <tarzeau> infinity: i see
[08:40] <tarzeau> no i haven't said anything about ppc64el, and i don't have access to such hardware either, i can report it upstream but (such reports already got ignored in the past)
[08:40] <tarzeau> aha last sentence of infinity makes sense
[08:40] <tarzeau> thanks!
[09:02] <Laney> vorlon: thanks
[09:18] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-2 => 1.3.7-2] (core)
[09:21] <jibel> sil2100, Hey, with 18.04.4 I do in installation with SB enabled but then, after installation, the system always boots in insecure mode. Could someone else test it?
[09:21] <jibel> s/in/an/
[09:26] <jibel> sil2100, I've a second machine but it doesn't boot at all with latest build
[09:27] <sil2100> jibel: hey, uh, that doesn't sound good - could you check if you have the same result with 18.04.3?
[09:27] <sil2100> I'll try finding someone to test this as well
[09:28] <sil2100> jibel: as for the second machine, is it only the RC that it doesn't boot?
[09:28] <jibel> sil2100, on machine 2, with quiet splash disabled, I get "EFI stub: UEFI Secure Boot is enabled." and it hangs there forever
[09:29] <jibel> ill try in legacy mode
[09:34] <sil2100> jibel: thanks
[09:34] <sil2100> jibel: so far looking at the manifests, I don't see anything between .3 and .4 that could have caused a regression in this area
[09:35] <sil2100> That's why it would also be good to see if .3 had the same issues
[09:36] -queuebot:#ubuntu-release- New binary: exiv2 [amd64] (focal-proposed/main) [0.27.2-8] (ubuntu-desktop)
[09:38] -queuebot:#ubuntu-release- New binary: exiv2 [ppc64el] (focal-proposed/main) [0.27.2-8] (ubuntu-desktop)
=== andrewc is now known as Guest63251
[09:52] <jibel> sil2100, machine 2 boots with SB on and .3
[09:53] -queuebot:#ubuntu-release- New binary: exiv2 [arm64] (focal-proposed/main) [0.27.2-8] (ubuntu-desktop)
[09:53] -queuebot:#ubuntu-release- New binary: exiv2 [armhf] (focal-proposed/main) [0.27.2-8] (ubuntu-desktop)
[09:56] <sil2100> jibel: and the failure to boot with .4 is always reproducible, yes?
[09:57] <sil2100> I guess we'd need someone that knows these parts better
[09:58] <sil2100> jibel: if those are constantly reproducible with the .4 RCs, please fill in a bug
[09:58] <sil2100> Need to figure out who picked up the SB stuff after Matt
[10:00] <jibel> yes always. I'm finishing the installation of .3 to verify how key enrollment works on .3 and try on the other machine
[10:00] <apw> sil2100, odd, if the kernel didn't boot in secure-boot you would think we would have seen that in the archive upgrades
[10:03] <sil2100> Yeah...
[10:04] <sil2100> Wonder what happened, looking at the diff it feels like only the kernel really changed from things that could have any effect here
[10:09] <apw> jibel, your ".4 fails to boot with secure boot enabled" was that the iso fails to boot, or the installed system
[10:10] <jibel> apw, on one machine the iso fails to boot, on the other machine, it always boots with SB mode disabled
[10:10] <apw> do you have a kernel log from the sb-mode-disabled one ?
[10:11] <jibel> I mean on the second machine installation is successful but SB is disabled on boot.
[10:11] <jibel> apw, yes, I'll file a bug and attach the logs
[10:11] <apw> jibel, right, that one
[10:23] <sil2100> jibel: hm, I guess you were doing some testing of the -proposed bionic dailies as well earlier, did you try those on the same machines?
[10:24] <jibel> I cannot even do another installation with SB on, I get "mmx64.efi not found" on boot of the iso
[10:24] <jibel> sil2100, not secure boot
[10:24] <apw> that is presumably something before the kernel
[10:24] <apw> being a .efi thing
[10:25] <sil2100> jibel: on the one that always booted with SB mode disabled?
[10:25] <jibel> redoing an installation of .3 without network so it doesn't pull the latest kernel
[10:26] <jibel> sil2100, yes
[10:27] <apw> sil2100, what is mok called when it is the thing that efi boots
[10:28] <apw> sil2100, ok the file which is missing there is a shim file
[10:29] <apw> so booting without secureboot might then make sense
[10:35] <sil2100> I think we need to get all the info into bugs so that we get a good overview of the situation
[10:36] <jibel> on it, just be patient
[10:49] <sil2100> jibel: anyway, if it tried to find and load mmx64.efi, this means the MokManager was meant to be booted
[10:49] <sil2100> I guess it didn't attempt to boot the iso even
[10:59] -queuebot:#ubuntu-release- New binary: exiv2 [s390x] (focal-proposed/main) [0.27.2-8build1] (ubuntu-desktop)
[11:00] -queuebot:#ubuntu-release- New binary: exiv2 [amd64] (focal-proposed/main) [0.27.2-8build1] (ubuntu-desktop)
[11:01] -queuebot:#ubuntu-release- New binary: exiv2 [ppc64el] (focal-proposed/main) [0.27.2-8build1] (ubuntu-desktop)
[11:05] -queuebot:#ubuntu-release- New binary: exiv2 [armhf] (focal-proposed/main) [0.27.2-8build1] (ubuntu-desktop)
[11:08] <LocutusOfBorg> seb128, ^^ I syncd but we can wait for python to clear before rebuilding, so AA please don't accept it yet?
[11:10] <LocutusOfBorg> (I syncd because of digikam and opencv sadness, but it is a proposed-only pocket package for now, so it doesn't entangle too much)
[11:10] -queuebot:#ubuntu-release- New binary: exiv2 [amd64] (focal-proposed/main) [0.27.2-8ubuntu1] (ubuntu-desktop)
[11:10] -queuebot:#ubuntu-release- New binary: exiv2 [s390x] (focal-proposed/main) [0.27.2-8ubuntu1] (ubuntu-desktop)
[11:10] -queuebot:#ubuntu-release- New binary: exiv2 [ppc64el] (focal-proposed/main) [0.27.2-8ubuntu1] (ubuntu-desktop)
[11:11] -queuebot:#ubuntu-release- New binary: exiv2 [arm64] (focal-proposed/main) [0.27.2-8ubuntu1] (ubuntu-desktop)
[11:11] -queuebot:#ubuntu-release- New binary: exiv2 [armhf] (focal-proposed/main) [0.27.2-8ubuntu1] (ubuntu-desktop)
=== pfsmorigo is now known as Guest84982
[11:20] -queuebot:#ubuntu-release- New binary: vmfs6-tools [amd64] (eoan-backports/none) [0.1.0-3~ubuntu19.10.1] (no packageset)
[11:20] -queuebot:#ubuntu-release- New binary: vmfs6-tools [i386] (eoan-backports/none) [0.1.0-3~ubuntu19.10.1] (no packageset)
=== andrewc is now known as Guest7207
[11:36] <jibel> sil2100, bug 1861794
[11:36] <ubot5> bug 1861794 in linux-signed-hwe (Ubuntu) "[18.04.4] System boots in insecure mode after an installation with SB on" [Undecided,New] https://launchpad.net/bugs/1861794
[11:39] <sil2100> jibel: thank you
[11:39] <sil2100> xnox: ^ in case you have any ideas ;)
[11:39] <jibel> sil2100, it might be a firmware issue
[11:42] <xnox> Wimpress:  vorlon:  did we have non-dkms / non-mok / l-r-m pre-signed nvidia modules in eoan/focal only? or bionic too?
[11:44] <tseliot> xnox, we are going to have more nvidia l-r-m in bionic-proposed soon. sforshee apw ^^
[11:44] <apw> tseliot, more in what sense ?
[11:45] <tseliot> apw, I think we only have -390 in -updates (in bionic), but we are SRUing more drivers
[11:45] <tseliot> like -440
[11:46]  * sil2100 didn't manage to NEW review -440 :<
[11:46] <sil2100> I'll try doing that today
[11:46] <tseliot> oh
[11:46] <tseliot> thanks
[11:48] <xnox> tseliot:  ok, but do we have matching installer changes =)))))))
[11:49] <xnox> jibel:  sil2100: in general I expect secureboot to still boot securely, whilst the kernel to be "tainted" as it loaded nvidia. I should be able to recreate/verify that locally ( i do have secureboot & nvidia stuff handy)
[11:51] <jibel> okay, and I cannot reproduce the hang I had on the other machine previously. It seems that the installation of .3 "fixed" it
[11:52] <sil2100> jibel: maybe the EFI vars were somehow invalidly set, causing a hang
[11:52] <sil2100> xnox: oh
[11:55] <sil2100> tseliot: ok, looking now at -440 in bionic, comparing it with -440 in focal
[11:56] <tseliot> xnox, I don't think so. I the installer calls the "ubuntu-drivers" tool, it will still get the dkms packages. This is something that might be worth looking into, though. Calling ubuntu-drivers --gpgpu will look for the l-r-m, but will also install a different metapackage (with fewer dependencies). The code is already there, so I could just make the l-r-m the default for the default installation
[11:56] <apw> tseliot, yes, i would expect those to be added to lrm over time, indeed the reviews i am doing is adding something
[11:56] <sil2100> tseliot: probably not a big deal, but in the diff between those two I see that ebian/libnvidia-gl-440.preinst still has "package_name=libnvidia-gl-435" in it
[11:57] <sil2100> *debian/
[11:57] <tseliot> apw, that's good
[11:57] <apw> oh no that is just updating the 390 version, anyhow, yes i expect we would do that
[11:58] <tseliot> sil2100, that file is regenerated by the files in debian/templates, but I can have a look
[11:58] <sil2100> tseliot: yeah, debian/templates/libnvidia-gl-flavour.preinst.in also has package_name=libnvidia-gl-435 instead of -440, not sure how much relevance this variable has though
[11:59] <sil2100> tseliot: the same for the eoan -440
[12:00] <xnox> tseliot:  hm, i was under the impression that someone somewhere told me that l-r-m switch has already happened, but your statement sounds that it was not. It means that obviously for 18.04.4 i should expect the Mok enroll instead.
[12:02] <LocutusOfBorg> infinity, debhelper merge please? something is depending on >=12.8
[12:02] <tseliot> sil2100, right, I don't know why that is. It all ends up in an unused variable ("this_version"). It doesn't really affect anything but still I did not see that.
[12:03] <tseliot> xnox, no, with only the 390 legacy driver being available as l-r-m in 18.04 (for now), there is no way we can rely on that, until the SRU is done
[12:06] <xnox> gotcha
[12:06] <sil2100> tseliot: ok, as long as it's not used anywhere, that's good
[12:06] <sil2100> Thanks
[12:07] <tseliot> :)
[12:09] <doko> component mismatches and update_excuses are not updated
[12:15] <cjwatson> doko: I was just about to unstick that by killing a process that had been running for some hours, but it looks like somebody else already did, so it may make progress soon
[12:15] <Laney> p-m is about to finish
[12:15] <Laney> it's taken several hours ...
[12:18] <cjwatson> When I looked it seemed to be talking to AMQP
[12:20] <Laney> I'm going by the tail of https://people.canonical.com/~ubuntu-archive/proposed-migration/log/focal/2020-02-04/07:47:39.log (don't click, large file)
[12:22] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1051.54+signed1] (no packageset)
[12:24] <Laney> now it is updated
[12:27] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1051.54+signed1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [amd64] (focal-proposed) [0.27.2-8]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [armhf] (focal-proposed) [0.27.2-8]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [amd64] (focal-proposed) [0.27.2-8build1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [ppc64el] (focal-proposed) [0.27.2-8build1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [amd64] (focal-proposed) [0.27.2-8ubuntu1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [armhf] (focal-proposed) [0.27.2-8ubuntu1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [s390x] (focal-proposed) [0.27.2-8ubuntu1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [arm64] (focal-proposed) [0.27.2-8]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [armhf] (focal-proposed) [0.27.2-8build1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [arm64] (focal-proposed) [0.27.2-8ubuntu1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [ppc64el] (focal-proposed) [0.27.2-8]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [ppc64el] (focal-proposed) [0.27.2-8ubuntu1]
[12:41] -queuebot:#ubuntu-release- New: accepted exiv2 [s390x] (focal-proposed) [0.27.2-8build1]
[14:16] -queuebot:#ubuntu-release- New sync: llvm-toolchain-10 (focal-proposed/primary) [1:10~++20200121023453+de4b2a7fad6-1~exp1]
[14:18] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [sync] (focal-proposed) [1:10~++20200121023453+de4b2a7fad6-1~exp1]
[14:24] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1032.35] (kernel)
[14:24] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1012.13] (core, kernel)
[14:24] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1011.12] (core, kernel)
[14:24] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1009.10] (core, kernel)
[14:25] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1068.78] (kernel)
[14:26] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1068.78]
[14:26] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1032.35]
[14:26] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1011.12]
[14:26] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1009.10]
[14:26] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1012.13]
=== jdstrand_ is now known as jdstrand
[14:56] -queuebot:#ubuntu-release- New binary: digikam [s390x] (focal-proposed/universe) [4:6.4.0+dfsg-1] (kubuntu)
[15:14] -queuebot:#ubuntu-release- New binary: digikam [amd64] (focal-proposed/universe) [4:6.4.0+dfsg-1] (kubuntu)
[15:32] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.7-2]
[15:32] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.7-2]
[15:32] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.7-2]
[15:35] <vorlon> xnox: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/1856414
[15:35] <ubot5> Ubuntu bug 1856414 in linux-restricted-modules (Ubuntu) "installing linux-modules-nvidia does not remove nvidia-dkms, and the kernel prioritizes the wrong version of the module from disk" [High,New]
[15:35] <xnox> vorlon:  delicious! thanks
=== M_hc[m] is now known as _hc
[16:00] <sil2100> tseliot: uh oh! Just noticed one thing, could you re-upload the -440 ones for eoan and bionic with a # in the bug number? SInce it's not in the .changes again :)
[16:01] <sil2100> jibel, xnox, apw: ok guys, got a bit preempted just now, did we get anywhere with the SecureBoot bug?
[16:11] <tseliot> sil2100, oh, let me have a look
[16:12] <cyphermox> secureboot bug?
[16:13] <tseliot> sil2100, if you reject them, I will re-upload
[16:13] <xnox> cyphermox:  not as dramatic as it sounds =) as if secureboot is off after mok enrolled + nvidia boot on 18.04.4 RC images
[16:13] <bdmurray> plars: Did you really follow the test case here? http://iso.qa.ubuntu.com/qatracker/milestones/410/builds/207260/testcases/1464/results
[16:13] <cyphermox> xnox: ah, ok
[16:14] <sil2100> tseliot: re-upload now, there can be multiple same-version packages in the queue if anything ;) I'll reject them in a moment
[16:14] <plars> bdmurray: no, I was under the impression that was being rewritten. I used our automated tests for rpi2/3, and the set of things we did for eoan on rpi4
[16:15] <bdmurray> plars: Okay, yeah I was going to rewrite it but then I saw you had tested it and was confused / surprised.
[16:16] <plars> bdmurray: yeah, in general I try to exceed what's in that anyway
[16:16] -queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440 (eoan-proposed/primary) [440.44-0ubuntu0.19.10.1]
[16:17] <tseliot> sil2100, ok, re-uploaded. Thanks again
[16:17] -queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440 (bionic-proposed/primary) [440.44-0ubuntu0.18.04.1]
[16:17] <sil2100> tseliot: thanks! Will be accepting those shortly
[16:18] -queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-440 [source] (bionic-proposed) [440.44-0ubuntu0.18.04.1]
[16:18] -queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-440 [source] (eoan-proposed) [440.44-0ubuntu0.19.10.1]
[16:19] <tseliot> :)
[16:27] <teward> can an aa sync xca from unstable to Focal?  The Ubuntu delta can be dropped (as I applied it in the Debian package upstream).  It's got a new version.
[16:27] <teward> (I'm the package maintainer in Debian now for it heh)
[16:28] <teward> or someone.  i'm not at my computer with my keys today...
[16:35] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440 [source] (eoan-proposed) [440.44-0ubuntu0.19.10.1]
[16:35] -queuebot:#ubuntu-release- New binary: vmfs6-tools [ppc64el] (eoan-backports/universe) [0.1.0-3~ubuntu19.10.1] (no packageset)
[16:36] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440 [source] (bionic-proposed) [440.44-0ubuntu0.18.04.1]
[16:36] <teward> nevermind, I managed to execute the sync request myself heh
[16:37] <teward> now that i'm at my computer with my keys.
[16:50] -queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440 [i386] (eoan-proposed/multiverse) [440.44-0ubuntu0.19.10.1] (no packageset)
[16:51] -queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440 [i386] (bionic-proposed/multiverse) [440.44-0ubuntu0.18.04.1] (no packageset)
[16:51] <sil2100> plars: ...in the meantime, could you perform our usual release-validation of the raspi3 classic images for arm64 and armhf?
[16:52] <plars> sil2100: you mean the rc server images from yesterday? (20200203.1) - I already did and recorded results on iso tracker. Or is there a new one coming today?
[16:55] <sil2100> plars: ah, no, those are it! Thanks :)
[16:56] -queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440 [amd64] (bionic-proposed/multiverse) [440.44-0ubuntu0.18.04.1] (no packageset)
[16:57] -queuebot:#ubuntu-release- New binary: vmfs6-tools [s390x] (eoan-backports/universe) [0.1.0-3~ubuntu19.10.1] (no packageset)
[17:04] -queuebot:#ubuntu-release- New binary: digikam [arm64] (focal-proposed/universe) [4:6.4.0+dfsg-1] (kubuntu)
[17:13] -queuebot:#ubuntu-release- New binary: digikam [armhf] (focal-proposed/universe) [4:6.4.0+dfsg-1] (kubuntu)
[17:34] -queuebot:#ubuntu-release- New: accepted digikam [amd64] (focal-proposed) [4:6.4.0+dfsg-1]
[17:34] -queuebot:#ubuntu-release- New: accepted digikam [armhf] (focal-proposed) [4:6.4.0+dfsg-1]
[17:34] -queuebot:#ubuntu-release- New: accepted digikam [arm64] (focal-proposed) [4:6.4.0+dfsg-1]
[17:34] -queuebot:#ubuntu-release- New: accepted digikam [s390x] (focal-proposed) [4:6.4.0+dfsg-1]
=== Guest84982 is now known as pfsmorigo
[18:07] <sil2100> paride: hey! Thank you for the server image testing o/ Will you be also able to test the arm64 d-i based server images?
[18:08] <powersj> dannf, ^ if you have any spare cycles, some help there woudld be nice
[18:09] <sil2100> powersj: thanks!
[18:09] <sil2100> :)
[18:12] <dannf> powersj: yeah, we have a checklist of systems/cases we run through for every point release - should have at least one test done soon, others by tomorrow
[18:12] <dannf> powersj: (and all recorded on hte iso tracker)
[18:12] <powersj> dannf, thank you!
[19:08] <sil2100> jibel: hey! Once you're up tomorrow, could you take a look into reproducing LP: #1861912 ? I guess it's only on i386, but apparently it wasn't in .3
[19:08] <ubot5> Launchpad bug 1861912 in ubiquity (Ubuntu) "file system creation in partition failed in auto-resize install 18.04.4" [Undecided,New] https://launchpad.net/bugs/1861912
[19:09] <sil2100> mwhudson: hey, poking you as I think you're the TIL person for any partman related packages in bionic - could you also take a look just in case? ^
[19:10] <sil2100> mwhudson: it's probably highly unlikely that the wipe-superblocks change had anything to do with it, but I guess it's best if you can assess that
[19:16] -queuebot:#ubuntu-release- New binary: llvm-toolchain-10 [amd64] (focal-proposed/universe) [1:10~++20200121023453+de4b2a7fad6-1~exp1] (no packageset)
[19:29] <vorlon> doko, xnox: I'm not sure where we stand on the tryton stuff that's blocking python3-defaults.  It's a big pile of packages, and I don't see that bugs have been filed in Debian yet against them (either RC bugs to prompt testing removal, or requests for removal from the archive; e.g. http://bugs.debian.org/src:tryton-modules-account is empty)
[19:29] <bdmurray> plars: I've updated the pi test case at the iso tracker.
[19:33] <doko> vorlon: I haven't looked at these yet, but all of that is scheduled for removal
[19:33] <doko> in Debian
[19:35] <plars> bdmurray: nice! looks like I need to resubmit my results, I'll do that now
[19:36] <plars> bdmurray: I did notice that it breaks the formatting of things like the netplan yaml, not sure if there's a way to have it treat that as a preformatted string or something
[19:36] <sil2100> bdmurray: thank you o/
[19:37] <bdmurray> plars: I noticed the issue with the netplan yaml too but wasn't going to worry about it too much.
[19:38] <bdmurray> I'm going to add the serial, flash-kernel change devices, and USB hub keyboard a separate run once tests since they require additional hardware
[19:49] <vorlon> doko: where do you see "scheduled for removal"?  as I said, no bugs filed
[19:50] <doko> https://tracker.debian.org/pkg/tryton-modules-account
[19:50] <doko> marked for removal ...
[19:53] <bdmurray> plars: I've added them now
[19:54] <vorlon> doko: ah ok
[19:55] <vorlon> doko: thanks, I can work with that
[19:55] <vorlon> mutter grumble double-conversion maintainer took my patch to make autopkgtests cross-friendly then landed whole new not-cross-friendly autopkgtest on top
[20:11] <mwhudson> sil2100: let's have a look
[20:13] <mwhudson> sil2100: well certainly the wipe superblocks path should not be taken in this case...
=== sergiusens_ is now known as sergiusens
[21:51] -queuebot:#ubuntu-release- Unapproved: ec2-instance-connect (bionic-proposed/universe) [1.1.12+dfsg1-0ubuntu1~18.04.0 => 1.1.12+dfsg1-0ubuntu2~18.04.0] (no packageset)
[21:51] -queuebot:#ubuntu-release- Unapproved: ec2-instance-connect (xenial-proposed/universe) [1.1.12+dfsg1-0ubuntu1~16.04.0 => 1.1.12+dfsg1-0ubuntu2~16.04.0] (no packageset)
[21:52] -queuebot:#ubuntu-release- Unapproved: ec2-instance-connect (eoan-proposed/universe) [1.1.12+dfsg1-0ubuntu1~19.10.0 => 1.1.12+dfsg1-0ubuntu2~19.10.0] (no packageset)
[21:53] <mwhudson> sil2100: reproduced that ubiquity bug
[21:57] <mwhudson> oh wait it's trying to install onto the install media
[21:57] <wxl> is that the problem????
[21:58] <mwhudson> i think so
[21:58] <mwhudson> "The ext4 file system creation in partition#5 of SCSI3 (0,0,0) (sdb) failed."
[21:58] <mwhudson> sdb is usually the install media, right
[21:58] <wxl> i saw another rather confused bug from someone else that sounded like they couldn't select their target drive
[21:58] <mwhudson> ?
[21:58] <mwhudson> it certainly is here
[21:58] <mwhudson> i don't think i was actually being offered the autoresize option
[21:58] <wxl> hm
[22:00] <vorlon> this sounds similar to the symptom that was being reported at 19.10 launch about two disks and ubiquity going sideways
[22:01] <vorlon> I'm trying to find the tail of that
[22:02] <vorlon> well, this was the 19.10 bug https://bugs.launchpad.net/bugs/1847898
[22:02] <ubot5> Ubuntu bug 1847898 in ubiquity (Ubuntu Focal) "System doesn't boot after installation - Legacy mode / 2 disks" [High,Triaged]
[22:02] <mwhudson> vorlon: but that was all tied up with the casper changes to mount sdb1 vs sdb, which aren't in bionic?
[22:02] <mwhudson> but yes, it does sound similar
[22:02] <vorlon> yeah, so I don't know
[22:02] <vorlon> regardless, trying to install to the source media is >_<
[22:03] <mwhudson> i know let's stop using partman
[22:03] <wxl> i think the phrase you're looking for is "not good"
[22:04] <vorlon> I endorse this sentiment but am unclear how partman is to blame for wrong disk selection
[22:04] <mwhudson> if only the logs were being autosaved to the install media
[22:05] <wxl> XD
[22:05] <wxl> what about doing something crazy like piping the logs out through nc and having some other machine grab them?
[22:05] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [amd64] (focal-proposed) [1:10~++20200121023453+de4b2a7fad6-1~exp1]
[22:07] <mwhudson> is there some way to make ubiquity more verbose about all this
[22:07] <wxl> beyond --debug?
[22:08] <mwhudson> no that sounds like what i want
[22:09] <mwhudson> oh righ debug-ubiquity on kernel command line
[22:28] <mwhudson> hm hm i add that to the command line and this time it is offering me the resize option
[22:32] -queuebot:#ubuntu-release- New source: lxd-agent-loader (focal-proposed/primary) [0.1]
[22:36] <mwhudson> vorlon:
[22:36] <mwhudson>  (and that seems to be working)
[22:42] <vorlon> well, lovely
[22:45] <mwhudson> vorlon: managed to reproduce, attached a tarball to the bug
[22:46] <wxl> mwhudson: how did you get it to reproduce when you couldn't before?
[22:46] <vorlon> mwhudson: which bug?
[22:46] <mwhudson> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1861912
[22:46] <ubot5> Ubuntu bug 1861912 in ubiquity (Ubuntu) "file system creation in partition failed in auto-resize install 18.04.4" [Undecided,New]
[22:46] <mwhudson> wxl: reflashed the install media
[22:46] <mwhudson> the failed installs manage to create the partition but not the filesystem on it
[22:47] <wxl> ah
[22:48] <mwhudson> i find the partman logs so incomprehensible
[22:49] <wxl> btw lubuntu has this problem, too. i betcha you get through a lubuntu install faster than mate.
[22:49] <mwhudson> well i have to go away for a bit
[22:51] <wxl> ok well if anyone has insight on this i have the OP on that bug on telegram if we need him to try something
[22:59] -queuebot:#ubuntu-release- Unapproved: knot-resolver (eoan-proposed/universe) [3.2.1-3 => 3.2.1-3ubuntu0.19.10.1] (no packageset)
[23:14] <RikMills> xnox: are you looking at the initramfs breakage from the proposed pocket version?
[23:22] <xnox> RikMills:  the cannot find libgcc_s? or even more breakage on top of it?
[23:23] <xnox> ha, all the tests red cannot be good
[23:23] <xnox> RikMills:  thanks for the pointer
[23:25] <xnox> RikMills:  it works for me, but i do have 30 versions of libgcc_s.so available on my system =( https://paste.ubuntu.com/p/f7gt7HyY2m/
[23:25] <xnox> need to test something cleaner
[23:25] -queuebot:#ubuntu-release- New binary: python-rq [amd64] (focal-proposed/none) [1.1.0-2] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: r-cran-bookdown [amd64] (focal-proposed/none) [0.16+dfsg-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: r-cran-unitizer [amd64] (focal-proposed/none) [1.4.8-1] (no packageset)
[23:26] <RikMills> update-initramfs: Generating /boot/initrd.img-5.4.0-13-generic
[23:26] <RikMills> E: /usr/share/initramfs-tools/hooks/btrfs failed with return 1.
[23:26] <RikMills> ^^ xnox
[23:27] <xnox> the original bug report is for cryptsetup, but i guess it affects lots of them, the fix is to be done in the initramfs-tools
[23:27] <xnox> the one i uploaded so far looks broken, let me try to fix it up
[23:27] -queuebot:#ubuntu-release- New: accepted python-rq [amd64] (focal-proposed) [1.1.0-2]
[23:27] -queuebot:#ubuntu-release- New: accepted r-cran-unitizer [amd64] (focal-proposed) [1.4.8-1]
[23:27] -queuebot:#ubuntu-release- New: accepted r-cran-bookdown [amd64] (focal-proposed) [0.16+dfsg-1]
[23:27] <RikMills> some people on a forum daft enough to use proposed all get that error
[23:28] <RikMills> I got it when I tried to run a test against a PPA with all-proposed=1
[23:28] -queuebot:#ubuntu-release- New binary: nanopb [amd64] (focal-proposed/none) [0.4.1-1] (no packageset)
[23:29] -queuebot:#ubuntu-release- New binary: nanopb [s390x] (focal-proposed/none) [0.4.1-1] (no packageset)
[23:29] -queuebot:#ubuntu-release- New binary: nanopb [ppc64el] (focal-proposed/none) [0.4.1-1] (no packageset)
[23:30] -queuebot:#ubuntu-release- New binary: pyrit [s390x] (focal-proposed/universe) [0.5.1+git20180801-2] (no packageset)
[23:30] -queuebot:#ubuntu-release- New binary: pyrit [amd64] (focal-proposed/universe) [0.5.1+git20180801-2] (no packageset)
[23:30] -queuebot:#ubuntu-release- New binary: pyrit [ppc64el] (focal-proposed/universe) [0.5.1+git20180801-2] (no packageset)
[23:36] <xnox> urgh
[23:52] <xnox> RikMills:  ok, uploaded something that should work with both old and new libgcc1 & libgcc-s1 => i got lucky because i have too many things installed on my machine
[23:56] <vorlon> mwhudson: so is this a regression vs 18.04.3?
[23:57] <wxl> vorlon: the OP tested against 18.04.3 and couldn't reproduce, therefore i would say so
[23:58] <RikMills[m]> <xnox "RikMills:  ok, uploaded somethin"> Thanks