/srv/irclogs.ubuntu.com/2019/11/27/#ubuntu-release.txt

vorlonthe 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 migrate00:20
vorlonI 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:22
-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]00:31
-queuebot:#ubuntu-release- New: accepted libchipcard [amd64] (focal-proposed) [5.1.4rc1-3]06:16
cpaelzerRAOF: thanks for updating 183692908:15
cpaelzerRAOF: 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 automatically08:16
cpaelzerwe 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
cpaelzerI think this might be a new corner case to be discussed in the block-proposed context08:16
cpaelzerwould you mind bringing this up with the SRU Team next time you meet?08:17
RAOFDon't autopkgtests run against the packages in proposed?08:21
* RAOF forgets08:22
RAOFI will indeed bring that up.08:22
RAOFcpaelzer 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:28
mwhudsonvorlon: exciting times08:29
mwhudsonRAOF: autopkgtests in general run with only the package being tested from proposed08:29
RAOFUnless people are running their autopkgtests locally *without* -proposed.08:29
mwhudsonRAOF: "autopkgtests are documented as running with -proposed enabled" where did you find this lie?08:30
mwhudson:08:30
mwhudson:)08:30
RAOFmwhudson: Ah, I was indeed misreading that.08:30
RAOFOr, 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)08:31
=== andrewc is now known as Guest57785
apwtechnically it has proposed 'enabled' and pinning applied to make only a subset of packages desirable; so it is right and utterly missleading09:01
mwhudsonwell in that sense most of my systems have proposed enabled09:08
-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:23
-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]10:35
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [s390x] (bionic-proposed/main) [5.3.0-24.26~18.04.2] (kernel)12:20
-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:21
-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]12:26
=== andrewc is now known as Guest95169
-queuebot:#ubuntu-release- Unapproved: ceilometer (eoan-proposed/main) [1:13.0.0-0ubuntu1 => 1:13.0.0-0ubuntu1.1] (openstack, ubuntu-server)14:44
-queuebot:#ubuntu-release- Unapproved: ceilometer (disco-proposed/main) [1:12.0.0-0ubuntu1 => 1:12.0.0-0ubuntu1.1] (openstack, ubuntu-server)14:57
vorlonhuh.  all the dbus-triggered autopkgtests are failing on i386, I swear I didn't do that15:58
Laneycurious16:00
seb128Laney, vorlon, dbus was just uploaded, looks like an arches mismatch?16:01
Laneybut it shouldn't have been triggered until proposed-migration saw all of the builds were there16:01
vorlonfurthermore, the error claims that some of the packages from the -proposed version on i386 are available but can't be installed due to dependencies16:07
seb128I just tried in a focal/i386 chroot and it's installable there...16:08
Laneyjust tried in scalingstack, still happening16:28
LaneywhatTTTTTTTTTTTTTTTTTTtttt16:29
vorlonis it somehow refusing to upgrade packages that are part of the base image?  I'm not sure that would make sense16:30
Laneyit's probably somehow or other to do with the pinning16:39
Laneybut doesn't happen in a qemu vm locally :(16:39
vorlontseliot: 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?16:58
tseliotvorlon, 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 useful17:05
Laneyvorlon: https://paste.ubuntu.com/p/SfjZ2BxhsF/17:07
LaneyI'm assuming we need to write pins for foreign arches too17:31
vorlontseliot: ok removing those binaries then, cheers17:36
vorlonLaney: huh why is amd64 libdbus installed in that environment?17:36
vorlonLaney: I mean, the conclusion sounds correct but I'm still confused how we arrived at that point17:37
Laneythermald apparently17:38
Laneynot sure where that comes from17:39
vorlonwow17:39
Laneyoh ok, recommends from the kernel17:39
vorlonLaney: 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 EOW17:40
vorlonLaney: 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
Laneynot if I can help it ;-)17:41
vorlonLaney: 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:42
Laneyvorlon: sounds sane at first glance; might want to run it past elbrus17:43
Laneywhat's the state of cross building random packages?17:43
Laneywip/mojo-juju-2's going to want some work for this too17:45
Laneyi386/amd64 is treated as a special case there17:45
vorlonah?17:46
vorlonLaney: elbrus> hmm he's not here, I thought he used to hang out.  Is there a recommended channel for upstream autopkgtest discussions?17:46
Laney#debci17:47
Laneyprobably OFTC?17:47
vorlonack17:47
Laneyspecial case> to handle using the same quota for both arches17:48
LaneyMaybe we'll just have to further special case out image building17:48
vorlonwell, 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-cloud17:51
vorlonas far as quotas... with only 1700 source packages left on i386, it may just fit in the margin ;P17:53
Laneyif 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 i38617:58
Laneyshould be fairly trivial in both branches (but different)17:58
* vorlon nods17:59
mwhudsonvorlon: er how would you feel about deleting livecd-rootfs/i386? :)22:37
vorlonmwhudson: ecstatic22:38
mwhudsonvorlon: i guess this will poke people who are still building i386 images in the eye fairly obviously :)22:38
vorlonmwhudson: 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:39
mwhudsonvorlon: that would be fine too22:40
mwhudson(i would like it to migrate before the general mass binary removal)22:40
mwhudsonvorlon: let me know when its safe to upload it22:40
vorlonmwhudson: should be good now22:42
mwhudsonvorlon: ta22:44
mwhudson4 attempts to type my gpg passphrase, not enough coffee or too much?22:44
valorienever too much coffee!22:54
* valorie slides a glass of water to mwhudson22:54
-queuebot:#ubuntu-release- Packageset: Added livecd-rootfs to i386-whitelist in focal22:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!