| vorlon | http://autopkgtest.ubuntu.com/running#queue-huge-focal-amd64 looks good | 00:14 |
|---|---|---|
| vorlon | interesting, I didn't realize that britney schedules autopkgtests alphabetically by architecture. Maybe we should consider reordering that so that it schedules tests for the slowest arch first; or orders by (packagename,arch) instead of (arch,packagename). | 00:15 |
| vorlon | otoh at this rate it should only take maybe 20 minutes to schedule all the glibc tests on amd64, so perhaps a pointless microoptimization | 00:17 |
| mwhudson | vorlon: does it make sense to remove that perl from -proposed if it's pointless? or is it too late for that | 00:23 |
| vorlon | mwhudson: it's burned the version number, so if there were another reason later to do a no-change rebuild of perl (between now and focal release, basically), it would cause annoying rejects for people following the normal process | 00:24 |
| vorlon | but I've dumped the autopkgtests because I don't want the queues clogged with them right now | 00:24 |
| vorlon | and I don't care if they get rescheduled / if this package migrates | 00:24 |
| mwhudson | vorlon: oh right | 00:25 |
| vorlon | so anyway, it's out of the way and we might clean it up later | 00:25 |
| mwhudson | vorlon: yeah i was mainly thinking of the autopkgtest load | 00:25 |
| mwhudson | but if you have other ways of getting rid of that, yay! | 00:26 |
| -queuebot:#ubuntu-release- Unapproved: sg3-utils (eoan-proposed/main) [1.44-1ubuntu1 => 1.44-1ubuntu1.1] (core) | 01:01 | |
| Eickmeyer | vorlon: I'd like to apolotize for my earlier actions. I ended up doing what you said and split that file up into separate files for each group of wallpapers. Upload is building. | 02:12 |
| Eickmeyer | *apologize | 02:12 |
| vorlon | Eickmeyer: glad we found a solution that worked! I understand your frustration, and hope you feel better soon | 03:26 |
| vorlon | bdmurray: is the apport/amd64 autopkgtest failure with glibc 2.31 familiar to you? looks like it could be a real regression but I don't know why without digging https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/a/apport/20200310_002651_7e8b1@/log.gz | 03:36 |
| vorlon | cpaelzer: chrony autopkgtests regress with new upstream glibc because the testsuite tarball it downloads at test time from an external github url has incompatible prototyping of gettimeofday(); I'm going to badtest this rather than block glibc on it given the externality | 03:47 |
| vorlon | tjaalton: you synced xkeyboard-config 2.29 dropping the delta for xkb-data-i18n to be a separate package, but ubiquity still build-depends on it; what's the correct solution there? | 04:26 |
| tjaalton | vorlon: ouch.. i'll check how it's used and revive it if necessary | 04:38 |
| vorlon | cheers | 04:38 |
| tjaalton | and thanks for the suggestion, we'll go with bumping the upstream version on the dkms | 04:43 |
| tjaalton | sounds like the build-dep could be dropped, it's only to make sure the translations are there so kbdnames-maker works | 04:49 |
| vorlon | doko: why do you say that libc6 can't use a pre-depends on libcrypt1? | 05:07 |
| vorlon | doko: glibc autopkgtests show failures on ppc64el and s390x that aren't caused by bad triggers | 05:13 |
| cpaelzer | vorlon: thanks for the ping | 06:23 |
| cpaelzer | vorlon: there is https://github.com/mlichvar/clknetsim/commit/6e4714b8b1730e865bf0066b898a7787e148eac9 | 06:23 |
| cpaelzer | but there were other reasons to not go forward | 06:24 |
| cpaelzer | I'll pre-check the tests across arches and if the newer version will work I can give chrony a bump to have the tests work again | 06:24 |
| cpaelzer | I also had https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1863590 open | 06:25 |
| ubot5 | Ubuntu bug 1863590 in chrony (Ubuntu) "Chrony test hangs with libpcap2 1:2.31-1" [Undecided,Confirmed] | 06:25 |
| cpaelzer | need to check if bubblewrap and libcap2 migrated in the meantime | 06:25 |
| cpaelzer | as that was what it was waiting on | 06:25 |
| cpaelzer | ok, the old stuff is resovled - going for a test build with a fix for the chrony test ... | 06:38 |
| cpaelzer | Hiho, it might be just a follow on to https://lists.ubuntu.com/archives/ubuntu-devel/2020-March/040939.html but plenty of builders are either "disabled" or seem stuck in "cleaning" | 06:48 |
| cpaelzer | if someone is around who could give that a look that would be great | 06:48 |
| cpaelzer | thanks wgrant for redirecting me here | 06:49 |
| * cpaelzer keeps on wrongly asking in #launchpad for this, maybe because of the URL https://launchpad.net/builders ? | 06:49 | |
| cpaelzer | thanks for your patience with me wgrant | 06:49 |
| wgrant | Hold on | 06:49 |
| wgrant | That's not what I said :) | 06:50 |
| wgrant | The Launchpad build farm is an Ubuntu service. | 06:50 |
| wgrant | er | 06:50 |
| wgrant | is a Launchpad service | 06:50 |
| wgrant | But you linked to a thing about autopkgtest issues. Ubuntu's autopkgtest is an Ubuntu service. | 06:50 |
| cpaelzer | too-many-moving-pieces-exception ... ok, thanks wgrant :-) | 06:51 |
| wgrant | I'm addressing the Launchpad build farm. | 06:51 |
| wgrant | But any Ubuntu autopkgtest issue is a) probably unrelated, and b) out of my hands. | 06:51 |
| cpaelzer | now I see what you meant, yes that part of it is fine | 06:51 |
| cpaelzer | build queue started to drop fast now - thanks wgrant | 07:33 |
| -queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.0 [amd64] (bionic-proposed/main) [5.0.0-1013.18] (no packageset) | 08:20 | |
| Mirv | archive team: could you check component mismatches, promote libenchant-2-voikko binary to main and demote enchant source+binaries to universe? it seems my seed change was enough also for the latter to pop up. | 08:36 |
| doko | vorlon: I'm not saying it can't use it, but it will create a pre-dependency loop | 09:17 |
| doko | vorlon: did you white list llvm-toolchain-10/i386? | 09:17 |
| Laney | juliank: what's the tl;dr / current status on whatever happened yesterday? | 09:17 |
| juliank | Laney: I don't think there were errors in the build for todays images, so we're good so far? | 09:18 |
| Laney | don't plan on reading scrollback if it's all fixed | 09:18 |
| Laney | I dunno, you were on it, just checking in :-) | 09:19 |
| juliank | Laney: We need to remove the check in setup-testbed that prevents building images with libgcrypt1 installed once this is all working | 09:19 |
| juliank | Laney: I'm looking at today's images now, they seem to be created | 09:21 |
| juliank | they also do not have libcrypt1 installed | 09:25 |
| juliank | so I'm happy | 09:25 |
| doko | vorlon: these tests also fail on amd64. apparently not architecture specific | 09:28 |
| Laney | juliank: good. now then, could we have stopped this bad thing from migrating? | 09:30 |
| juliank | Laney: There seems to be a bug in britney somewhere that makes it ignore the Breaks+Replaces libcrypt1 has on libc6 | 09:34 |
| doko | Laney: the real problem was the libxcrypt imported from unstable not having tightened breaks/replaces | 09:40 |
| Laney | doko: ok, I was wondering if something was missed | 09:42 |
| Laney | like, no autopkgtests caught this? | 09:42 |
| juliank | there are two problems | 09:54 |
| doko | Laney: how? libxcrypt didn't even have autopkg tests | 09:54 |
| juliank | libxcrypt -ubuntu1 was broken | 09:54 |
| juliank | missing breaks/replaces | 09:54 |
| juliank | then libxcrypt ubuntu3 made it in, despite having breaks/replaces in place that should have prevented migration; breaking debootstrap (and keeping back packages on upgrade) | 09:55 |
| juliank | though libcrypt1 ubuntu1 was fine if you had a separate /usr | 09:56 |
| juliank | I have it installed, and everything is fine | 09:56 |
| doko | it was already the debian version which was broken | 09:57 |
| juliank | because libcrypt1 installs to /usr/lib, and libc6 to /lib | 09:57 |
| juliank | doko: but only for systems with merged user, so e.g. the buildd images don't care | 09:58 |
| juliank | because now you had to libcrypt1, but like who cares | 09:58 |
| doko | are you saying that the location changed? | 09:59 |
| doko | for libcrypt.so.1? | 09:59 |
| juliank | doko: yes | 09:59 |
| doko | ahh | 09:59 |
| juliank | libc6:amd64: /lib/x86_64-linux-gnu/libcrypt.so.1 | 09:59 |
| juliank | libcrypt1:amd64: /usr/lib/x86_64-linux-gnu/libcrypt.so.1 | 09:59 |
| Laney | ok, and that is the case for autopkgtest images too? | 10:01 |
| doko | apparently not? libcrypt.so.1 was removed when libc6 was updated to 2.31 | 10:02 |
| doko | we use the merged usr as default since eoan | 10:02 |
| Laney | hmmmmmmmmmmmmmmmmmmmmmmmmmmm | 10:09 |
| Laney | no indeed, it's not that | 10:09 |
| Laney | doesn't look like glibc's autopkgtests cause libcrypt1 to be installed | 10:13 |
| Laney | libxcrypt's new tests did fail, but then I guess that wouldn't have been a regression | 10:13 |
| doko | I added those long after it migrated | 10:14 |
| Laney | seems like there were two migration incidents | 10:17 |
| doko | juliank: please update the status of the testers on u-d (ML) | 10:18 |
| Laney | or it was ubuntu3 that caused problems | 10:18 |
| juliank | doko: oh | 10:18 |
| Laney | meh | 10:19 |
| Laney | none of the tests it triggered caused libcrypt1 to be installed | 10:19 |
| Laney | don't really have a suggestion apart from figure out why it was allowed to be migrated | 10:21 |
| LocutusOfBorg | tjaalton, can you please accept hedgewars/bionic again? https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1857363 | 10:48 |
| ubot5 | Ubuntu bug 1857363 in hedgewars (Ubuntu Bionic) "update hw to 1.0" [Undecided,In progress] | 10:48 |
| LocutusOfBorg | my ppa had backports enabled :/ | 10:48 |
| LocutusOfBorg | and debhelper12 is backports only | 10:48 |
| -queuebot:#ubuntu-release- Unapproved: hedgewars (bionic-proposed/universe) [1.0.0-4~ubuntu1.18.04.1 => 1.0.0-4~ubuntu1.18.04.2] (no packageset) | 10:49 | |
| -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-18.22] (core, kernel) | 12:09 | |
| -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-18.22] (core, kernel) | 12:09 | |
| -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-18.22] (core, kernel) | 12:10 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1005.5] (core, kernel) | 12:11 | |
| -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-18.22] (core, kernel) | 12:11 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1005.5] (core, kernel) | 12:12 | |
| === s8321414_ is now known as s8321414 | ||
| xnox | juliank: are our VMs broken? sudo: /tmp/autopkgtest-run-wrapper: command not found | 12:38 |
| juliank | xnox: idk | 12:40 |
| -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1build1] (core) | 12:40 | |
| === sergiusens_ is now known as sergiusens | ||
| -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1build1] (core) | 12:42 | |
| -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1build1] (core) | 12:42 | |
| ahasenack | why is debian-installer-udebs ubuntu606 depending on the 5.4.0-14 kernel instead of 5.4.0-18? It was built 14h ago | 12:54 |
| ahasenack | focal release has 5.4.0.14.17 | 12:54 |
| ahasenack | focal proposed has 5.4.0.18.22 | 12:54 |
| ahasenack | it just missed it? | 12:55 |
| ahasenack | * Rebuild against release pocket only + bind9-libs. | 13:02 |
| ahasenack | -- Dimitri John Ledkov <xnox@ubuntu.com> Mon, 09 Mar 2020 17:21:32 +0000 | 13:02 |
| ahasenack | xnox: ^ do you know why it's stuck now? autohinter complains about debian-installer-udebs | 13:02 |
| ahasenack | I'd guess the old kernel | 13:13 |
| xnox | ahasenack: because there were more udebs missing from -proposed that were needed. hence i have rebuild 607 this morning | 13:27 |
| xnox | so hoping 607 will migrate..... | 13:28 |
| ahasenack | yay for 607 | 13:28 |
| xnox | doko: do we need to rebuild gdb for glibc, or update apport gdb/glibc/abort test cases? | 13:28 |
| doko | xnox: I don't think we did in the past. the only thing I was aware of was valgrind | 13:29 |
| xnox | test_add_gdb_info_abort (__main__.T) | 13:30 |
| xnox | add_gdb_info() with SIGABRT/assert() ... WARNING: Please install gdb-multiarch for processing reports from foreign architectures. Results with "gdb" will be very poor. | 13:30 |
| xnox | WARNING: Please install gdb-multiarch for processing reports from foreign architectures. Results with "gdb" will be very poor. | 13:30 |
| xnox | FAIL | 13:30 |
| xnox | hm ok | 13:35 |
| xnox | doko: somebody will need to dig into apport test failures then | 13:35 |
| tjaalton | LocutusOfBorg: done | 13:52 |
| -queuebot:#ubuntu-release- Unapproved: accepted hedgewars [source] (bionic-proposed) [1.0.0-4~ubuntu1.18.04.2] | 13:53 | |
| doko | bdmurray: could you have a look at the apport test failures? | 14:13 |
| bdmurray | doko: to be clear the apport / glibc ones for Focal? | 14:24 |
| doko | bdmurray: yes | 14:25 |
| LocutusOfBorg | thanks | 14:54 |
| vorlon | doko: yes, llvm-toolchain-10 is in the whitelist | 15:33 |
| vorlon | doko: pre-dependency loop: I don't see a pre-dep loop, libcrypt1 only Depends libc6, and a pre-depends + depends is allowed (dpkg knows how to resolve this in the correct order). Did you try this and run into problems? Because I'm concerned that upgrade ordering could in some cases cause libc6 to still be unpacked before libcrypt1 and therefore cause libcrypt.so.1 to be missing from the system at | 15:34 |
| vorlon | critical times | 15:34 |
| vorlon | doko: we haven't run into this in focal yet because the set of packages we're upgrading is quite small within the devel series, but this could become a problem in dist-upgrades from bionic when apt has to calculate something more significant | 15:35 |
| vorlon | juliank: ^^ ? | 15:35 |
| * juliank in meeting | 15:35 | |
| doko | vorlon: see #debian-glibc. afaiu the perl (debconf) usage is optional. so maybe check if the ubuntu delta re-introduces this dependency | 15:36 |
| vorlon | I don't see how that's relevant to any of the current problems | 15:37 |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-1build1] | 15:38 | |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-1build1] | 15:38 | |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-1build1] | 15:38 | |
| vorlon | doko: the Debian workaround for perl being broken at preinst time, per bug #946599, is to test whether 'perl -e ""' succeeds and if not to skip debconf. I guess that's ok in that it makes libc6 more resilient, but it still doesn't address problems caused by unpack ordering of packages that are pre-dependencies of virtual packages | 15:51 |
| ubot5 | bug 946599 in inkscape (Ubuntu) "lindenmayer.py crashed with IOError in lxml.etree._FilelikeWriter.write (src/lxml/lxml.etree.c:92532)(): [Errno 32] Broken pipe" [Medium,Invalid] https://launchpad.net/bugs/946599 | 15:51 |
| vorlon | I think the Debian glibc package has gotten this completely wrong | 15:51 |
| vorlon | doko: in the current implementation, there is nothing that prevents apt+dpkg from unpacking new libc6 first before libcrypt1, thus removing libcrypt.so.1 from disk; then trying to unpack and configure some other essential package which also needs upgraded; then unpacking libcrypt1. There are some rules in apt now that make this less *likely*, but a later change in some other essential package | 16:02 |
| vorlon | could cause this to all fall over, because the libc6+libcrypt1 relationships are not per se correct | 16:02 |
| vorlon | juliank: ^^ if you want to sanity check me on any of this | 16:02 |
| xnox | juliank: vorlon: i think that libcrypt1 should conflict with older libc6 because of the undeclared file conflict between libc6 & libcrypt1. dpkg does not notice that /lib/ conflicts with /usr/lib thus old libc6 must be removed, before new libcrypt1 is unpacked. | 16:11 |
| xnox | juergh: vorlon: otherwise removal of old libc6 may remove the new libcrypt1's libcrypt.so.1 from disk | 16:12 |
| juliank | hmm | 16:12 |
| xnox | juergh: unping | 16:12 |
| xnox | juliank: vorlon: i was thinking to open an RC bug against libcrypt1 in debian, if there are no conflicts there. | 16:13 |
| juliank | So if libc6 Pre-Depends libcrypt1, doesn't that solve the issue as well? | 16:13 |
| juliank | I prefer positive solutions over negative ones | 16:13 |
| vorlon | xnox: but then the difficulty is that Conflicts means that libc6 MUST be unpacked before the new libcrypt1, which is the opposite of what we hope to accomplish with pre-depends | 16:14 |
| vorlon | xnox: wouldn't it be better to change libcrypt1 to use the same path as libc6 in the package so we can rely on dpkg for this | 16:14 |
| xnox | vorlon: i think using the same path is better. | 16:14 |
| juliank | libc6 Pre-Depends libcrypt1, libcrypt1 Breaks/Replaces old libc6 and change path ? | 16:15 |
| xnox | juliank: vorlon: the predepends & conflicts are for different libc6 versions. We conflict with old libc6, whilst only the new one predepends. imho we need both. | 16:15 |
| juliank | New libc6 needs to p-d on libcrypt1 | 16:15 |
| juliank | libcrypt1 needs to break/replace old libc6 | 16:15 |
| xnox | breaks/replaces means that it is ok to unpack new libcrypt1 whilst the old libc6 is unpacked on disk, and I am arguing that is not true. | 16:15 |
| juliank | it cannot conflict with old libc6 | 16:15 |
| juliank | because it does need the old libc6 unpacked | 16:16 |
| juliank | if it conflicted, we need to unpack the new libc6 first | 16:16 |
| vorlon | juliank: so you agree with my analysis that we should not rely, the way Debian currently does, on a depends being sufficient to ensure ordering during upgrade? | 16:16 |
| juliank | which is a loop | 16:16 |
| xnox | but then removal of old libc6 will remove libcrypt1's library and one is left _without_ any libcrypt.so.1 on disk? | 16:16 |
| vorlon | and that it should be a pre-depends | 16:16 |
| vorlon | xnox: no, because pre-depends + breaks means: deconfigure libc6; unpack libcrypt1 which takes over the files; configure libcrypt1; unpack libc6 | 16:17 |
| juliank | xnox: oh dear, that should be solved by changing the path in libcrypt1 | 16:17 |
| xnox | vorlon: ok | 16:17 |
| juliank | vorlon: Yes, we do want a pre-depends I think | 16:17 |
| xnox | vorlon: juliank: 1) change path in libcrypt1 2) have breaks+replaces in libcrypt1 (already done) 3) add predepends in the new libc6 | 16:17 |
| juliank | vorlon: I'm not 100% sure, but it seems reasonable | 16:17 |
| xnox | agreed plan of record? | 16:17 |
| juliank | ack | 16:17 |
| juliank | +1 | 16:17 |
| vorlon | ok | 16:17 |
| xnox | do we need bugs in debian about this? | 16:18 |
| juliank | it would be nice to tell them they're wrong | 16:18 |
| vorlon | doko: ^^ I am happy to drive the packaging changes for this; are you going to be looking into the glibc autopkgtest regressions? | 16:18 |
| vorlon | juliank: do you want to join #debian-glibc to talk about this? It might have more authority coming from the apt maintainer ;){ | 16:18 |
| juliank | I'm not super confident about the pre-depends thing that I could argue why it's the right thing to do | 16:19 |
| juliank | It just feels like the right thing to do | 16:19 |
| xnox | juliank: predepends is the right thing, because libc6 preinst uses libcrypt.so.1 via perl/debconf | 16:20 |
| juliank | ack | 16:20 |
| xnox | juliank: thus preinst expects to have a working perl / libcrypt / libc6 | 16:20 |
| juliank | I concur | 16:20 |
| vorlon | right, but Debian has worked around that specific thing by making a perl failure non-fatal | 16:20 |
| vorlon | my concern is unpack ordering of other packages within the Essential closure | 16:21 |
| juliank | right | 16:21 |
| vorlon | like, what else could require perl-base, between the time libc6 is unpacked and libcrypt1 is unpacked | 16:21 |
| juliank | If you have an essential package that needs libcrypt, what happens? | 16:21 |
| vorlon | yes, perl-base is such an essential package | 16:21 |
| vorlon | which, the no-change rebuild of perl has added a pre-depends, but that doesn't change the fact that something might try to use perl before the new version has been unpacked | 16:22 |
| vorlon | doko: https://wiki.ubuntu.com/DebianMaintainerField :P | 16:25 |
| xnox | vorlon: i wonder if we should have done switch to libxcrypt separate from upgrade to 2.31 | 16:26 |
| xnox | too late now | 16:26 |
| vorlon | xnox: if you mean switching to libxcrypt /before/ upgrading to 2.31, that sounds like it might've been useful, but yeah obviously didn't happen | 16:27 |
| vorlon | AIUI we can't defer it /beyond/ 2.31 | 16:27 |
| xnox | vorlon: yeah that. cause we could have done the libxcrypt migration whilst 2.31 was not available yet. | 16:27 |
| xnox | anyway, next time. | 16:28 |
| vorlon | seb128: seems the Ubuntu focal daily ISO is over the new size limit again | 16:31 |
| bdmurray | doko: I uploaded a new version of apport a bit ago | 16:34 |
| seb128 | vorlon, can you remind me where is the limit defined? also that's a discussion we are having with Wimpress this week in the context of langpacks to include so hopefully we have a decision then and can put a limit without having to keep revisiting | 16:36 |
| vorlon | seb128: buried in the ubuntu-cdimage tree.py code | 16:36 |
| seb128 | k :) | 16:36 |
| vorlon | size_limit() | 16:36 |
| seb128 | thanks for the pointer | 16:36 |
| vorlon | Laney: the DNS failure rate on the armhf container runners is still non-zero and annoying. did you have any more ideas on where to go with that? | 16:41 |
| vorlon | for so in $(DD)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so; do \ | 16:41 |
| vorlon | ln -sf /lib/$(DEB_HOST_MULTIARCH)/$$(basename $$(readlink -f $$s | 16:41 |
| vorlon | o)) \ | 16:41 |
| vorlon | xnox: ^^ you're welcome | 16:41 |
| vorlon | $$so; \ | 16:41 |
| Laney | vorlon: not really, perhaps we want to loop in someone from the lxd team? | 16:41 |
| vorlon | done | 16:41 |
| vorlon | I thought we had already implemented their recommendations | 16:41 |
| vorlon | but yeah, probably so | 16:41 |
| Laney | yes | 16:41 |
| Laney | but kind of abstractly / remotely | 16:42 |
| Laney | rather than here's access, go have a good time with it | 16:42 |
| Laney | I see that one person from this team already has the requisite access :> | 16:42 |
| vorlon | what the heck, why was http://autopkgtest.ubuntu.com/packages/l/linuxinfo/focal/amd64 triggered with all-proposed=1 | 16:45 |
| Laney | lol | 16:46 |
| Laney | I can guess | 16:46 |
| vorlon | ? | 16:46 |
| vorlon | because it matches the 'linux' regexp? | 16:46 |
| vorlon | :/ | 16:46 |
| Laney | https://git.launchpad.net/autopkgtest-cloud/tree/worker/worker#n427 | 16:47 |
| Laney | linuxyolo | 16:48 |
| vorlon | doko, xnox: libxcrypt 1:4.4.10-10ubuntu4 uploaded, this moves the library from /usr/lib to /lib from dpkg's perspective which will cause Replaces: to actually DTRT in the dpkg database | 16:48 |
| vorlon | doko: I'm happy to finagle the pre-depends from glibc, but I don't want to reupload until we have a plan for the regressed autopkgtests | 16:49 |
| vorlon | autopkgtest [14:32:18]: test run-unit-test: [----------------------- | 16:51 |
| vorlon | Your machine does not support AVX2. | 16:51 |
| vorlon | Please compile with SSE4.1 cmake -DHAVE_SSE4_1=1 | 16:51 |
| vorlon | autopkgtest [14:32:18]: test run-unit-test: -----------------------] | 16:51 |
| vorlon | .... | 16:51 |
| vorlon | how did this pass once | 16:51 |
| xnox | vorlon: we happened to run the test before on a Nova host node that did have avx2 | 17:01 |
| vorlon | I thought there was no avx2 in scalingstack for the foreseeable future | 17:02 |
| vorlon | :/ | 17:02 |
| -queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.0 [amd64] (bionic-proposed) [5.0.0-1013.18] | 17:02 | |
| cjwatson | vorlon: more no guaranteed avx2, I think | 17:06 |
| vorlon | k | 17:06 |
| cjwatson | We still have some Sandy Bridge in service for instance, which lacks AVX2; but we also have some things like Epycs | 17:08 |
| wgrant | Right. Scalingstack isn't designed to support live migration, and the available hardware changes, so the available instruction set extensions varies | 17:34 |
| apw | wgrant, do we not lie to the instances with a common possible subset? | 17:52 |
| wgrant | apw: we could, but the CPUs range in age by eight years so it would be a bit unfortunate | 17:54 |
| LocutusOfBorg | vorlon, would you mind kicking the can on gnupg2/i386 hint= | 18:01 |
| LocutusOfBorg | please? | 18:01 |
| LocutusOfBorg | also gpgme1.0 | 18:02 |
| doko | vorlon: I'll look at these tomorrow, they are common across all archs | 18:14 |
| vorlon | xnox: you retried the rtags test with a non-obvious trigger and it passed once and failed once. Do you have any insight or is this just a flaky test that needs the button to be hammered? | 18:28 |
| vorlon | LocutusOfBorg: the expectation is that people who upload packages that have had one-time hints added for i386 will deal with these regressions as part of their upload, not kick the can | 18:33 |
| vorlon | LocutusOfBorg: so unless you tell me that these autopkgtests can never work on i386, please fix them instead | 18:33 |
| vorlon | E: Essential packages were removed and -y was used without --allow-remove-essential. | 18:49 |
| vorlon | LocutusOfBorg: ^^ so that's the answer for gnupg, certainly that should be made an unversioned hint for i386 | 18:49 |
| vorlon | oh, or should that be diffutils:any | 18:49 |
| vorlon | or, you know, should we just not be pointlessly declaring a test dep on an essential package | 18:49 |
| vorlon | gnupg2 uploaded | 18:51 |
| LocutusOfBorg | thanks vorlon I tried to fix before asking | 19:26 |
| -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1035.39] (kernel) | 19:42 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1035.39] | 19:47 | |
| -queuebot:#ubuntu-release- Unapproved: sg3-utils (bionic-proposed/main) [1.42-2ubuntu1.18.04.1 => 1.42-2ubuntu1.18.04.2] (core) | 20:37 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!