[00:20] <vorlon> the i386 package whitelist for focal is now live.  in the short term, expect proposed-migration to slow down a little bit as manual binary removals from the release pocket are needed in order to let things migrate
[00:22] <vorlon> I will be doing a mass binary removal on i386, but before that I will be working on landing changes to make the autopkgtest runners test i386 on an amd64 base image, to reduce the testing impact of the removals (<-- cc: Laney juliank)
[00:31] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-72.81]
[00:31] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-72.81]
[06:16] -queuebot:#ubuntu-release- New: accepted libchipcard [amd64] (focal-proposed) [5.1.4rc1-3]
[08:15] <cpaelzer> RAOF: thanks for updating 1836929
[08:16] <cpaelzer> RAOF: I know we use block-proposed for things like an FTBFS fix where it makes sense. But on a autopkgtest failure I thought this will ahve to go to -release to be used automatically
[08:16] <cpaelzer> we could keep it in proposed which would let all tests fail but people could run a custom trigger to use the new version (which is better than not having it in proposed at all)
[08:16] <cpaelzer> I think this might be a new corner case to be discussed in the block-proposed context
[08:17] <cpaelzer> would you mind bringing this up with the SRU Team next time you meet?
[08:21] <RAOF> Don't autopkgtests run against the packages in proposed?
[08:22]  * RAOF forgets
[08:22] <RAOF> I will indeed bring that up.
[08:28] <RAOF> cpaelzer autopkgtests are documented as running with -proposed enabled, so having it in -proposed with block-proposed set should be exactly as useful as having it in -release?
[08:29] <mwhudson> vorlon: exciting times
[08:29] <mwhudson> RAOF: autopkgtests in general run with only the package being tested from proposed
[08:29] <RAOF> Unless people are running their autopkgtests locally *without* -proposed.
[08:30] <mwhudson> RAOF: "autopkgtests are documented as running with -proposed enabled" where did you find this lie?
[08:30] <mwhudson> :
[08:30] <mwhudson> :)
[08:30] <RAOF> mwhudson: Ah, I was indeed misreading that.
[08:31] <RAOF> Or, rather, *later* in the documentation it clarifies that “with proposed enabled” means “with certain packages from proposed” 😀
[08:31] <RAOF> (specifically, http://packaging.ubuntu.com/html/auto-pkg-test.html says both those things)
=== andrewc is now known as Guest57785
[09:01] <apw> technically it has proposed 'enabled' and pinning applied to make only a subset of packages desirable; so it is right and utterly missleading
[09:08] <mwhudson> well in that sense most of my systems have proposed enabled
[10:23] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-72.81~16.04.1] (kernel)
[10:23] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-72.81~16.04.1] (kernel)
[10:35] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-72.81~16.04.1]
[10:35] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-72.81~16.04.1]
[12:20] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [s390x] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)
[12:21] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)
[12:21] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)
[12:21] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)
[12:26] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.3.0-24.26~18.04.2]
[12:26] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.3.0-24.26~18.04.2]
[12:26] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.3.0-24.26~18.04.2]
[12:26] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [s390x] (bionic-proposed) [5.3.0-24.26~18.04.2]
=== andrewc is now known as Guest95169
[14:44] -queuebot:#ubuntu-release- Unapproved: ceilometer (eoan-proposed/main) [1:13.0.0-0ubuntu1 => 1:13.0.0-0ubuntu1.1] (openstack, ubuntu-server)
[14:57] -queuebot:#ubuntu-release- Unapproved: ceilometer (disco-proposed/main) [1:12.0.0-0ubuntu1 => 1:12.0.0-0ubuntu1.1] (openstack, ubuntu-server)
[15:58] <vorlon> huh.  all the dbus-triggered autopkgtests are failing on i386, I swear I didn't do that
[16:00] <Laney> curious
[16:01] <seb128> Laney, vorlon, dbus was just uploaded, looks like an arches mismatch?
[16:01] <Laney> but it shouldn't have been triggered until proposed-migration saw all of the builds were there
[16:07] <vorlon> furthermore, the error claims that some of the packages from the -proposed version on i386 are available but can't be installed due to dependencies
[16:08] <seb128> I just tried in a focal/i386 chroot and it's installable there...
[16:28] <Laney> just tried in scalingstack, still happening
[16:29] <Laney> whatTTTTTTTTTTTTTTTTTTtttt
[16:30] <vorlon> is it somehow refusing to upgrade packages that are part of the base image?  I'm not sure that would make sense
[16:39] <Laney> it's probably somehow or other to do with the pinning
[16:39] <Laney> but doesn't happen in a qemu vm locally :(
[16:58] <vorlon> tseliot: nvidia-graphics-drivers-340 didn't make it into the i386 whitelist because it doesn't ship versions of any of the libraries that were identified as required for i386-compatibility.  Is there any reason to care about i386 versions of the 340 libcuda* stuff being available, or should I just drop these i386 binaries?
[17:05] <tseliot> vorlon, the amd64 package already includes the i386 libraries (which should be enough for most uses), since it's not a proper multi-arch package. As for libcuda1-340, I doubt that the i386 libraries would be super useful
[17:07] <Laney> vorlon: https://paste.ubuntu.com/p/SfjZ2BxhsF/
[17:31] <Laney> I'm assuming we need to write pins for foreign arches too
[17:36] <vorlon> tseliot: ok removing those binaries then, cheers
[17:36] <vorlon> Laney: huh why is amd64 libdbus installed in that environment?
[17:37] <vorlon> Laney: I mean, the conclusion sounds correct but I'm still confused how we arrived at that point
[17:38] <Laney> thermald apparently
[17:39] <Laney> not sure where that comes from
[17:39] <vorlon> wow
[17:39] <Laney> oh ok, recommends from the kernel
[17:40] <vorlon> Laney: are you going to work on implementing that foreign-arch pinning? it may wind up needing some redoing shortly anyway as I'm hoping to move us from i386 images to amd64 images for focal by EOW
[17:41] <vorlon> Laney: fwiw rough sketch of what I'm planning: autopkgtest itself needs to grow an interface to know what arch it's being asked to test for, which we would then invoke unconditionally; this would translate to arch-qualified installation of all packages from this source, cross-build-aware installation of @builddeps@, and default host resolution of any other test deps.  Opinions?
[17:41] <Laney> not if I can help it ;-)
[17:42] <vorlon> Laney: ok then my plan instead is to badtest all of the dbus revdeps that are slated for removal, skiptest the rest, and move on ;)
[17:42] <vorlon> (and deal with the foreign-arch pinning as part of the migration)
[17:43] <Laney> vorlon: sounds sane at first glance; might want to run it past elbrus
[17:43] <Laney> what's the state of cross building random packages?
[17:45] <Laney> wip/mojo-juju-2's going to want some work for this too
[17:45] <Laney> i386/amd64 is treated as a special case there
[17:46] <vorlon> ah?
[17:46] <vorlon> Laney: elbrus> hmm he's not here, I thought he used to hang out.  Is there a recommended channel for upstream autopkgtest discussions?
[17:47] <Laney> #debci
[17:47] <Laney> probably OFTC?
[17:47] <vorlon> ack
[17:48] <Laney> special case> to handle using the same quota for both arches
[17:48] <Laney> Maybe we'll just have to further special case out image building
[17:51] <vorlon> well, my current approach was just to add i386 foreign-arch to the amd64 image and use that, which was a lot simpler than refactoring 3 layers of autopkgtest-cloud
[17:53] <vorlon> as far as quotas... with only 1700 source packages left on i386, it may just fit in the margin ;P
[17:58] <Laney> if I'm understanding correctly, autopkgtest-cloud changes are (1) don't build i386 autopkgtest cloud images any more, and (2) ask for the amd64 image when testing i386
[17:58] <Laney> should be fairly trivial in both branches (but different)
[17:59]  * vorlon nods
[22:37] <mwhudson> vorlon: er how would you feel about deleting livecd-rootfs/i386? :)
[22:38] <vorlon> mwhudson: ecstatic
[22:38] <mwhudson> vorlon: i guess this will poke people who are still building i386 images in the eye fairly obviously :)
[22:39] <vorlon> mwhudson: actually on that point it might be a bit awkward for me to delete it right before Thanksgiving and make the cpc team's builds all break.  Could I instead add livecd-rootfs to the package whitelist and have you upload it again to get it built?
[22:40] <mwhudson> vorlon: that would be fine too
[22:40] <mwhudson> (i would like it to migrate before the general mass binary removal)
[22:40] <mwhudson> vorlon: let me know when its safe to upload it
[22:42] <vorlon> mwhudson: should be good now
[22:44] <mwhudson> vorlon: ta
[22:44] <mwhudson> 4 attempts to type my gpg passphrase, not enough coffee or too much?
[22:54] <valorie> never too much coffee!
[22:54]  * valorie slides a glass of water to mwhudson
[22:59] -queuebot:#ubuntu-release- Packageset: Added livecd-rootfs to i386-whitelist in focal