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:20 |
---|---|---|
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: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 | |
cpaelzer | RAOF: thanks for updating 1836929 | 08:15 |
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:16 |
cpaelzer | would you mind bringing this up with the SRU Team next time you meet? | 08:17 |
RAOF | Don't autopkgtests run against the packages in proposed? | 08:21 |
* RAOF forgets | 08:22 | |
RAOF | I will indeed bring that up. | 08:22 |
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:28 |
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:29 |
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:30 |
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) | 08:31 |
=== andrewc is now known as Guest57785 | ||
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:01 |
mwhudson | well in that sense most of my systems have proposed enabled | 09: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 | |
vorlon | huh. all the dbus-triggered autopkgtests are failing on i386, I swear I didn't do that | 15:58 |
Laney | curious | 16:00 |
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:01 |
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:07 |
seb128 | I just tried in a focal/i386 chroot and it's installable there... | 16:08 |
Laney | just tried in scalingstack, still happening | 16:28 |
Laney | whatTTTTTTTTTTTTTTTTTTtttt | 16:29 |
vorlon | is it somehow refusing to upgrade packages that are part of the base image? I'm not sure that would make sense | 16:30 |
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:39 |
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? | 16:58 |
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:05 |
Laney | vorlon: https://paste.ubuntu.com/p/SfjZ2BxhsF/ | 17:07 |
Laney | I'm assuming we need to write pins for foreign arches too | 17:31 |
vorlon | tseliot: ok removing those binaries then, cheers | 17:36 |
vorlon | Laney: huh why is amd64 libdbus installed in that environment? | 17:36 |
vorlon | Laney: I mean, the conclusion sounds correct but I'm still confused how we arrived at that point | 17:37 |
Laney | thermald apparently | 17:38 |
Laney | not sure where that comes from | 17:39 |
vorlon | wow | 17:39 |
Laney | oh ok, recommends from the kernel | 17:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:45 |
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:46 |
Laney | #debci | 17:47 |
Laney | probably OFTC? | 17:47 |
vorlon | ack | 17:47 |
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:48 |
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:51 |
vorlon | as far as quotas... with only 1700 source packages left on i386, it may just fit in the margin ;P | 17:53 |
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:58 |
* vorlon nods | 17:59 | |
mwhudson | vorlon: er how would you feel about deleting livecd-rootfs/i386? :) | 22:37 |
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:38 |
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:39 |
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:40 |
vorlon | mwhudson: should be good now | 22:42 |
mwhudson | vorlon: ta | 22:44 |
mwhudson | 4 attempts to type my gpg passphrase, not enough coffee or too much? | 22:44 |
valorie | never too much coffee! | 22:54 |
* valorie slides a glass of water to mwhudson | 22:54 | |
-queuebot:#ubuntu-release- Packageset: Added livecd-rootfs to i386-whitelist in focal | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!