[05:43] <vorlon> autopkgtest [05:42:11]: host juju-prod-ues-proposed-migration-machine-11; command line: /home/ubuntu/autopkgtest/runner/autopkgtest --output-dir /tmp/autopkgtest-work.d7k492al/out --timeout-copy=6000 -a i386 --setup-commands /home/ubuntu/autopkgtest-cloud/worker-config-production/setup-canonical.sh --setup-commands /home/ubuntu/autopkgtest/setup-commands/setup-testbed
[05:43] <vorlon> --apt-pocket=proposed=src:liblouis --apt-upgrade liblouis --env=ADT_TEST_TRIGGERS=liblouis/3.11.0-3 -- ssh -s /home/ubuntu/autopkgtest/ssh-setup/nova -- --flavor autopkgtest --security-groups autopkgtest@lgw01-23.secgroup --name adt-focal-i386-liblouis-20191205-054210 --image adt/ubuntu-focal-amd64-server --keyname testbed-juju-prod-ues-proposed-migration-machine-11
[05:43] <vorlon> --net-id=net_ues_proposed_migration -e ''"'"'http_proxy=http://squid.internal:3128'"'"'' -e ''"'"'https_proxy=http://squid.internal:3128'"'"'' -e ''"'"'no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,ppa.launchpad.net'"'"'' --mirror=http://ftpmaster.internal/ubuntu
[05:43]  * vorlon waits
[05:45] <vorlon> (for the test failure, since the i386 binaries have been removed ;P)
[07:15] <vorlon> well hey, the pass rate for cross-tests of the remaining packages on i386 is > 0%: http://autopkgtest.ubuntu.com/packages/a/adduser/focal/i386
[07:15] <vorlon> (of course, this is an arch: all package anyway so it tells us nothing about quality)
[07:16] -queuebot:#ubuntu-release- Unapproved: cockpit (eoan-backports/universe) [207-1~ubuntu19.10.1 => 208-1~ubuntu19.10.1] (no packageset)
[07:16] -queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [207-1~ubuntu19.04.1 => 208-1~ubuntu19.04.1] (no packageset)
[07:17] -queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [207-1~ubuntu18.04.1 => 208-1~ubuntu18.04.1] (no packageset)
[08:42] <LocutusOfBorg> hello cyphermox, nodejs merge please? a lots of nodejs packages are stuck...
[09:18] -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)
[09:19] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)
[09:20] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)
[09:20] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)
[09:44] <LocutusOfBorg> nvm, syncing it
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [208-1~ubuntu19.04.1]
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (eoan-backports) [208-1~ubuntu19.10.1]
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [208-1~ubuntu18.04.1]
[10:43] <seb128> can someone ignore the silx failure to let python-fabio and xorg-server migrate?  something changed which makes opencl fail, looks like toolchain or kernel but it's not due to those updates
[10:43] <seb128> http://autopkgtest.ubuntu.com/packages/s/silx/focal/amd64
[11:02] <apw> seb128, that looks a lot like a dependant package for silx is broken with it or in and of itself
[11:02] <apw> seb128, if i am reading the trace back right ?
[11:13] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1027.28~18.04.1] (kernel)
[11:13] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1028.30] (core, kernel)
[11:13] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1010.11] (core, kernel)
[11:14] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1027.28~18.04.1]
[11:14] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1028.30]
[11:14] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1010.11]
[11:21] <seb128> apw, which log are you looking at?
[11:23] <seb128> apw, if you are refering to the h5py errors, look at the python-fabio/0.9.0+dfsg-4 h5py/2.10.0-2 one rather. It's one of the reasons I want python-fabio to be marked as candidate, it's needed for the fixed h5py to migrate
[11:23] <seb128> h5py is buggy in the release pocket and it's impacting on a number of other tests, would be nice to see that resolved
[11:33] <apw> seb128, so would just requesting a test of sixl and h5py not cause those to look happy ?
[11:33] <seb128> apw, that's the second entry on http://autopkgtest.ubuntu.com/packages/s/silx/focal/amd64
[11:34] <seb128> apw, that makes h5py happy but opencl fails with
[11:34] <seb128> pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident module'.
[11:35] <seb128> apw, I'm stating that it doesn't look like a python-fabio problem so if the failing results could be ignored to make python-fabio a candidate
[11:35] <seb128> which would allow us to have the fixed h5py migrating
[11:35] <seb128> which would make other tests happier (and not having people like me chasing retries to add &trigger=h5py/2.10.0-2)
[11:36] <seb128> the opencl/silx problem still needs to be sorted out
[11:36] <seb128> but meanwhile it would make things easier to unblock the other ones
[11:36] <seb128> if that makes any sense?
[11:37] <apw> some indeed
[11:38] <apw> seb128, ok so the logical hint is to hint python-fabio good as that does not randomly unblock other things which have not been eye-balled
[11:38] <apw> seb128, but you also have self-test failures for s390x
[11:40] <seb128> apw, ah, right :(
[11:40] <seb128> apw, thx for pointing that out, I'll have a look to that
[11:40] <apw> seb128, ack thanks
[11:55] <RikMills> could someone with permissions do an imagemagick no change rebuild against libopenexr24? that should be one of the last things holding the ilmbase/openexr transition
[12:07] -queuebot:#ubuntu-release- Unapproved: pam (eoan-proposed/main) [1.3.1-5ubuntu1 => 1.3.1-5ubuntu1.19.10.0] (core)
[12:10] <rbalint> sil2100, please drop pam ^
[12:17] <sil2100> Ok
[12:18] -queuebot:#ubuntu-release- Unapproved: rejected pam [source] (eoan-proposed) [1.3.1-5ubuntu1.19.10.0]
[12:19] <seb128> RikMills, k, doing now
[12:20] <RikMills> seb128: thanks!
[12:20] <seb128> np!
[12:26] <seb128> RikMills, freeimage has failing i386 tests (forge & freeimage) that should probably be marked badtest to make it candidate
[12:27] <RikMills> seb128: yeah. was going to ask vorlon this morning before his eod in the USA, but forgot
[12:28] <seb128> RikMills, you can probably get any r-t member to merge a such mp if you send one
[12:29] <seb128> RikMills, just need to be added to the i386 section from https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/ubuntu-release I guess
[12:29]  * RikMills shudders at doing a mp with bzr
[12:29] <seb128> RikMills, I can do it if you want?
[12:30] <RikMills> seb128: that would be great. I don't have much time until later
[12:30] <seb128> RikMills, k, I do it, I've some other ones to add in that section anyway
[12:34] <RikMills> ty
[12:40] <seb128> https://code.launchpad.net/~seb128/britney/extra-i386-badtests/+merge/376400
[12:40] <seb128> if someone wants to review/merge that
[12:42] -queuebot:#ubuntu-release- Unapproved: pam (eoan-proposed/main) [1.3.1-5ubuntu1 => 1.3.1-5ubuntu1.19.10.0] (core)
[12:48] <slashd> o/ sil2100, could you please review the upload of 'stress-ng' in E/D/B when you have a moment ? Thanks in advance !
[12:48] <slashd> mfo, ^
=== s8321414_ is now known as s8321414
[12:54] <sil2100> slashd: hey o/ Sure
[12:54] <sil2100> Just need to finish the publishing to -updates
[12:57] <mfo> slashd, sil2100  thanks guys!  this upload is not high priority, so i haven't checked about them yet; i planned to follow up next week just in case, but if it can be worked on sooner, that's great :)  thanks again. o/
[13:18] -queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1010.11~18.04.1] (no packageset)
[13:19] -queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1027.28~18.04.1] (kernel)
[13:19] -queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.0 [amd64] (bionic-proposed/main) [5.0.0-1009.14~18.04.1] (no packageset)
[13:20] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1010.11~18.04.1]
[13:20] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.0 [amd64] (bionic-proposed) [5.0.0-1009.14~18.04.1]
[13:20] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1027.28~18.04.1]
[13:20] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1032.36] (no packageset)
[13:21] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1032.36]
[13:36] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (eoan-proposed) [0.10.07-1ubuntu2]
[13:46] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (disco-proposed) [0.09.57-0ubuntu4]
[13:47] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (bionic-proposed) [0.09.25-1ubuntu5]
[14:40] -queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (eoan-proposed/universe) [2.7.17~rc1-1 => 2.7.17-1~19.10] (kubuntu)
[14:42] -queuebot:#ubuntu-release- Unapproved: python2.7 (eoan-proposed/universe) [2.7.17~rc1-1 => 2.7.17-1~19.10] (kubuntu)
[14:46] -queuebot:#ubuntu-release- Unapproved: gcc-8 (eoan-proposed/universe) [8.3.0-23ubuntu2 => 8.3.0-26ubuntu1~19.10] (core)
[14:48] -queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8.3.0-6ubuntu1~18.04.1 => 8.3.0-26ubuntu1~18.04] (core)
[14:51] -queuebot:#ubuntu-release- Unapproved: gcc-7 (eoan-proposed/universe) [7.4.0-14ubuntu2 => 7.5.0-3ubuntu1~19.10] (core)
[14:53] -queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.4.0-1ubuntu1~18.04.1 => 7.5.0-3ubuntu1~18.04] (core)
[15:01] <cpaelzer> ddstreet: xnox: rbalint: Upstrem systemd CI runs on http://autopkgtest.ubuntu.com/running#pkg-systemd-upstream seem odd to me. They hang after "dpkg-buildpackage: info: binary-only upload (no source included)" and then from upstream POV vanish after a timeout
[15:01] <cpaelzer> is that a known issue of any kind and/or is there something that we can do about it?
[15:01] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1031.34] (kernel)
[15:02] <cpaelzer> Laney: cjwatson: ^^ FYI for your general great knowledge about the inner workings of autopkgtest.u.c
[15:02] <ddstreet> cpaelzer what do you mean 'vanish'?
[15:03] <ddstreet> the result links are added on the PRs upstream, for the latest test run
[15:03] <cpaelzer> E.g. 49219b5c is an upstream PR of mine https://github.com/systemd/systemd/pull/14167 - currently those tests are there as "pending - autopkgtest running"
[15:03] <gitbot> systemd issue (Pull request) 14167 in systemd "Fix memory_deny_write_execute on x86 and s390 with libseccomp 2.4.2" [Good-To-Merge/Waiting-For-Ci 👍, Seccomp, Tests, Open]
[15:03] <cpaelzer> last time they just went away, no more mentioned
[15:03] <cpaelzer> not failed and not succeeded
[15:03] <cpaelzer> just gone fromt he overview
[15:03] <cpaelzer> I thought I ask while the tests are still "active"
[15:04] <cpaelzer> as afterwards there might be not much to look after
[15:04] <cpaelzer> Here Lennard seems to mention that this "happens sometimes" https://github.com/systemd/systemd/pull/14167#issuecomment-562043653
[15:04] <gitbot> systemd issue (Pull request) 14167 in systemd "Fix memory_deny_write_execute on x86 and s390 with libseccomp 2.4.2" [Good-To-Merge/Waiting-For-Ci 👍, Seccomp, Tests, Open]
[15:04] <cpaelzer> the question is can/should we do someting about it
[15:04] <ddstreet> all the old tests are still available, you just have to go thru pain to manually find them
[15:05] <ddstreet> there was general infrastructure problems on dec 2, so i think a lot of Ubuntu ci jobs got dropped then
[15:05] <ddstreet> that does happen sometimes
[15:06] <cpaelzer> ok, I can wait until thesw work or timeout or disappear
[15:06] <ddstreet> but normally all the ci jobs should complete and update github with the results and log.gz link
[15:06] <cpaelzer> just wanted to be proactive while still debuggable
[15:07] <ddstreet> have you tried gathering the resutls with the autopkgtest-manager script?  that makes autopkgtest.u.c less painful to gather results from
[15:08] <cpaelzer> ddstreet: I haven't looked for the systemd CI results via that
[15:08] <ddstreet> https://git.launchpad.net/ubuntu-support-tools/tree/autopkgtest-manager/autopkgtest-manager
[15:08] <cpaelzer> the current ones are still running, I'd look for them afterwards
[15:08] <ddstreet> might be helpful
[15:08] <cpaelzer> but I can try to find the old ones
[15:09] -queuebot:#ubuntu-release- Unapproved: base-files (eoan-proposed/main) [10.2ubuntu7 => 11ubuntu7.19.10.0] (core)
[15:09] <ddstreet> i set in my .bash_aliases export AUTOPKGTEST_MANAGER_CACHE_DIR="~/autopkgtest-manager"
[15:09] <ddstreet> and then i create /home/ddstreet/autopkgtest-manager-systemd-upstream -> autopkgtest-manager/autopkgtest-bionic-upstream-systemd-ci-systemd-ci/pr
[15:09] <ddstreet> makes it a bit easier to review various systemd-upstream PR results
[15:13] <seb128> apw, can you mark the silx tests to skip for python-fabio as well as python-fabio/s390x itself? the python-fabio/s390x failure is just stupid, from a scucess log (the most recent)
[15:13] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/p/python-fabio/20191130_022051_d9d4c@/log.gz
[15:13] <seb128> FAILED (failures=5, errors=43, skipped=17)
[15:13] <seb128> Test suite failed
[15:13] <seb128> autopkgtest [02:20:39]: test python3-dbg: -----------------------]
[15:13] <seb128> autopkgtest [02:20:40]: test python3-dbg:  - - - - - - - - - - results - - - - - - - - - -
[15:13] <seb128> python3-dbg          PASS
[15:13] <seb128> apw, so basically it always failed, just the packaging was buggy before and not returning the error properly
[15:13] <apw> seb128, so it is random what it says, but it is always failed
[15:13] <seb128> so it's not a regression
[15:13] <apw> ok
[15:13] <seb128> right
[15:14] <seb128> they fixed it to properly error out
[15:14] <seb128> do we have a way to do an history reset of a test? like declare it always failed?
[15:15] <apw> we have literally no way to do that, and it is the most annoying of things
[15:15] <seb128> seems annoying indeed :-/
[15:17] -queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.1.0-0ubuntu1.2 => 3:15.1.1-0ubuntu1] (openstack, ubuntu-server)
[15:20] -queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.2-0ubuntu1 => 2:14.0.3-0ubuntu1] (openstack, ubuntu-server)
[15:21] <cjwatson> cpaelzer: I have no knowledge whatsoever about the internal workings of autopkgtest
[15:21] <apw> seb128, and so hinted
[15:22] -queuebot:#ubuntu-release- Unapproved: neutron-lbaas (disco-proposed/universe) [2:14.0.0-0ubuntu1 => 2:14.0.1-0ubuntu1] (openstack)
[15:27] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan 19.10.1] has been marked as ready
[15:27] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan 19.10.1] has been marked as ready
[15:29] -queuebot:#ubuntu-release- Unapproved: octavia (disco-proposed/universe) [4.0.0-0ubuntu1.2 => 4.1.0-0ubuntu1] (no packageset)
[15:33] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1031.34]
[15:33] <seb128> apw, thanks
[15:36] <apw> seb128, np, thanks for doing the legwork on the s390x regression marker
[15:44] -queuebot:#ubuntu-release- Unapproved: lvm2 (bionic-proposed/main) [2.02.176-4.1ubuntu3.18.04.1 => 2.02.176-4.1ubuntu3.18.04.2] (core)
[15:45] -queuebot:#ubuntu-release- Unapproved: lvm2 (disco-proposed/main) [2.02.176-4.1ubuntu4.1 => 2.02.176-4.1ubuntu4.2] (core)
[15:51] -queuebot:#ubuntu-release- Unapproved: lvm2 (bionic-proposed/main) [2.02.176-4.1ubuntu3.18.04.1 => 2.02.176-4.1ubuntu3.18.04.2] (core)
[16:24] -queuebot:#ubuntu-release- Unapproved: vaultlocker (disco-proposed/universe) [1.0.3-0ubuntu2 => 1.0.4-0ubuntu0.19.04.1] (no packageset)
[16:24] -queuebot:#ubuntu-release- Unapproved: vaultlocker (eoan-proposed/universe) [1.0.3-0ubuntu2 => 1.0.4-0ubuntu0.19.10.1] (no packageset)
[18:01] <vorlon> happy i386 day https://paste.ubuntu.com/p/HvbrGHNYx3/
[18:10] <vorlon> infinity: re-ping on https://code.launchpad.net/~vorlon/ubuntu-archive-tools/update-i386-whitelist/+merge/376042
[18:14] <vorlon> seb128: ^^ fyi, over the course of today the number of 'missing build on i386' problems should drop to zero (it'll take some time to remove all the binaries, so far I'm down to 'ac' :P), but the number of autopkgtest regressions will probably increase
[18:15] <vorlon> the good news is we should reach steady state fairly quickly, we'll just need to badtest the arch: all packages with tests
[18:24] <infinity> vorlon: It has comments.  Do as you will with them.  I'm sick and wishy-washy today.
[18:24] <vorlon> ta
[18:27] <vorlon> infinity: do you have a link handy to the LP bug?
[18:28] <infinity> https://bugs.launchpad.net/launchpad/+bug/1855069
[18:28] <ubot5> Ubuntu bug 1855069 in Launchpad itself "PPAs should be able to toggle using PRIMARY's arch-{white,black}lists" [Undecided,New]
[18:33] <infinity> vorlon: Oh, and given that there's no real input validation here (and, honestly, I'm not sure how one would do any), I assume there's no intent to ever run this automated without dry-run?
[18:34] <infinity> vorlon: Actually, the lack of input sanity checking means the dry-run could tell you plausibly good things, then the next run to commit could blow up in your face.  Maybe this needs a confirmation between printing and acting.
[18:37] <vorlon> infinity: in practice I download the file locally, do a --dry-run, and then commit :)
[18:37] <vorlon> but also if it does blow up in your face, it will still tell you it has blown up in your face so read the output etc
[18:37] <vorlon> but yeah I don't think this is sane to ever run without human oversight
[18:38] <infinity> vorlon: Fair enough, but I don't think the tool itself implies that's how it should/could be used, so I still think a y/n after the dry-run check makes sense.
[18:38] <vorlon> since one wrong package removal means germinate will shrink the packageset to 0
[18:38] <infinity> A y/n with no --yes override, so it's clear it must be interactive. :P
[18:38] <vorlon> infinity: well you were wishy-washy and I've already merged it now without that... :)
[18:38] <infinity> Hah.  Well, if you have "spare time".
[18:39]  * vorlon nods :)
[18:39] <infinity> It literally doesn't matter until someone other than you runs it, I suspect, but it's a public tool now, so you know someone will eventually.
[18:47] <vorlon> infinity: done
[19:00] <RikMills> could someone run the tests to see if cmake/3.13.4-1build1 is regressed in release please?
[19:04] <RikMills> I have seen the finding of harfbuzz fail due to new pango in release, so the imagemagick cmake test fails look to be the same cause
[19:17] -queuebot:#ubuntu-release- Packageset: Added gcc-10 to i386-whitelist in focal
[19:24] <vorlon> 8166 badtest hints added for i386
[19:24] <vorlon> this is fine
[19:25] <vorlon> RikMills: awkward to construct that command, and anyway there was a pass of cmake on 21Nov, what do you think would have changed since then that would regress cmake's own tests?
[19:28] <RikMills> vorlon: https://gitlab.kitware.com/cmake/cmake/issues/19531
[19:29] <RikMills> due to new pango 1.44 in -release
[19:31] <vorlon> RikMills: tests triggered
[19:31] <RikMills> vorlon: pango1.0 1.44.7-1 published to -release on 21Nov, so may have been just after that successful test
[19:31] <RikMills> vorlon: thanks!
[19:32] <RikMills> I could be misreading it, but would be good to know :)
[19:34] <RikMills> yeah, pango pubished 12+ hrs later
[19:53] <RikMills> vorlon: may I ask what the rationale for triggering the cmake tests against 'gcc-defaults/1.185.1ubuntu1' is?
[19:54] <vorlon> RikMills: baseline retests against the release pocket require specifying a trigger which is a package with no version in -proposed
[19:55] <vorlon> I generally pick glibc, but there's currently a version in proposed
[19:55] <RikMills> vorlon: so it would not work with the cmake version in release as a trigger?
[19:56] <vorlon> RikMills: no, because the autopkgtest code gets confused and winds up pinning against the version of cmake from -proposed anyway and testing that
[19:56] <RikMills> vorlon: thanks. that is actually REALLY useful to know :)
[20:10] <RikMills> refreshing https://autopkgtest.ubuntu.com/running#pkg-cmake I just saw ppc64el win the race to a test fail in the way I expected
[20:10] <RikMills> just wait for the rest I guess, and results
[20:13] <RikMills> + s390x
[20:13] <RikMills> I'll shut up now....
[20:38] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1031.34~16.04.1] (kernel)
[20:51] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1031.34~16.04.1]
[21:00] -queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (disco-proposed) [2.02.176-4.1ubuntu4.2]
[21:00] -queuebot:#ubuntu-release- Unapproved: rejected lvm2 [source] (bionic-proposed) [2.02.176-4.1ubuntu3.18.04.2]
[21:02] -queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (bionic-proposed) [2.02.176-4.1ubuntu3.18.04.2]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (eoan-proposed) [2.7.17-1~19.10]
[21:14] -queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (eoan-proposed) [2.7.17-1~19.10]
[21:20] -queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (bionic-proposed) [2.7.17-1~18.04]
[21:21] -queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (bionic-proposed) [2.7.17-1~18.04]
[21:44] <vorlon> xnox: I happened to notice that nodejs is in the i386 whitelist as a build-dep-indep of ffmpeg, which is not critical but annoying.  did you have anything that would help with this?
[21:45] <xnox> vorlon:  i had thoughts and no prayers
[21:45] <xnox> vorlon:  does nodejs still ftbfs on i386 or is it ok?
[21:45] <vorlon> xnox: no idea
[21:46] <vorlon> xnox: it seems to be bfs, there's a version in -proposed synced today which has tests running
[21:46] <xnox> vorlon:  wait
[21:46] <xnox> we don't care about -Indep
[21:46] <xnox> we only need -Indep on arch:amd64
[21:46] <vorlon> xnox: we don't /in principle/ care about indep but they're still being traversed currently
[21:46] <xnox> because we build _all.deb packages on amd64
[21:47] <xnox> .... i guess we transverse them, because we do not have strictly knowledge that things build from source as arch builds without Indep installed?
[21:47] <xnox> does launchpad install Indeps for arch builds today?
[21:47] <vorlon> it does not
[21:47] <vorlon> (I just checked the log to confirm)
[21:48] <xnox> so either selectively blacklist the whitelist
[21:48] <vorlon> xnox: so in principle it seems like this might be something that the no-follow-build-depends-all feature should handle
[21:48] <xnox> not "-all" but like "-indep"
[21:48] <vorlon> since the packages listed in Build-Depends-Indep are the build-depends of an arch-all package
[21:48] <vorlon> no, I think it fits under the existing flag definition
[21:49] <xnox> ah, existing flag is "no-follow-build-depends"
[21:49] <xnox> if i recall correctly
[21:49] <vorlon> no-follow-build-depends-all is the new flag I added (which cjwatson kindly merged)
[21:49] <xnox> ah, i see what you mean
[21:49] <xnox> oh
[21:49] <xnox> ok
[21:49] <xnox> well, there are corner cases
[21:49] <vorlon> and which we use to not pull all of rust etc into the i386 set :)
[21:49] <xnox> as context of other packages in the same source package matter
[21:50] <xnox> i.e. arch: i386 arch:all  => is only built on i386 and needs Indep
[21:50] <xnox> which is a bad example
[21:51] <vorlon> I believe we still build the arch: all package on amd64 in that case also
[21:52] <vorlon> and while there were designs for being able to specify build arch affinity for arch: all packages, there are zero such packages in practice (and I wouldn't expect there to ever be any specifying i386)
[21:53] <xnox> Ack
[21:54] <xnox> So, you want to skip B-D-Indep on i386, correct?
[21:54] <vorlon> yeah
[21:54] <infinity> I vaguely recall mentioning you'd need this. :P
[21:54] <vorlon> but I mean, I can hack on this, I was just wondering if this would happen to fall out of the other germinate MP you already having
[21:56] <infinity> It's probably a 1-2-liner (and test), if you find the place where it merges BD and BDI and conditionalise it on the no-blah-all flag being set.
[21:56] <vorlon> yep
[21:57] <xnox> vorlon:  definately not.
[21:57] <xnox> vorlon:  my MP is for entirely different thing unfortunately.
[21:58] <xnox> it has no good way to transverse past arch:all, non-multiarched apps.
[22:00] <infinity> xnox: Oh, so I noticed your foreign arch MP follows foreign arch deps, but what I didn't see (or maybe I'm blind) is a way to explicitly seed " * foo [amd64:i386]" or " * foo:i386 [amd64]" (not sure which syntax I like better, might need a bikeshed with Colin), but I suspect that might come in handy.  It's entirely a fluke that the nvidia issue is "solved" by transitive deps.
[22:00] <infinity> (And, actually, is it? ... The deps will only pull in one, surely not all)
[22:02] <xnox> infinity:  we seed multiple amd64 versions, which have cross-arch recommends on the i386 versions
[22:03] <xnox> infinity:  it was intentional for me to _only_ introduce cross-arch resolution without any new seed syntax.
[22:03] <infinity> xnox: Oh, the recommends are from the nvidia packages?  Oh, right.  The release sprint is slowly coming back to me. :P
[22:03] <xnox> infinity:  because we definately do not want "nvidia-drivers [amd64:i386]" as that would then pull in the whole of i386 graphics stack
[22:04] <infinity> xnox: So, fair enough to land them as two different things indeed.  Just noting that the explicit seeding thing might be needed too at some point.
[22:04] <xnox> infinity:  we only want the libnvidiafooXYZ:amd64|i386
[22:04] <xnox> explicit seeding makes sence for truly i386 app, like wine
[22:05] <xnox> which is M-A: nothing & arch:i386 and my current code cannot cope with that, past
[22:05] <infinity> We might not need it now, but it feels like it would make the multi-arch handling more complete for future use.
[22:05] <xnox> arch:all => arch:any deps boundary
[22:05] <infinity> Anyhow, not urgent, just something to ponder.
[22:05] <infinity> The nvidia thing is definitely the current pain point.
[22:05] <xnox> indeed
[22:05] <infinity> And I can't wait to kill the static file hack in debian-cd.
[22:05] <xnox> the next pain point of mine, is to load all arches in one go
[22:06] <xnox> such that s390-tools [s390x] opal-foo [ppc64le] util-linux => show up in the parsed ubuntu-server seed forexample from a single run on people.u.c/~ubuntu-archive/..../germinate.output/
[22:07] <infinity> Ahh yeah, the part where we only run for one arch there is confusing to people trying to examine why something is included.
[22:07] <infinity> I'll admit that it annoys me enough that I tend to use ftpmaster's copies instead, which are for all arches.
[22:08] <infinity> Not exactly an option for most people.
[22:08]  * vorlon nods
[22:11] <infinity> We have a copy of ftpmaster's germinate run on snakefruit that we mirror literally every minute.  We could publish that in public_html if that would be helpful.
[22:12] <infinity> It's only for the devel series, but that's what most people care about.
[22:23] -queuebot:#ubuntu-release- Unapproved: update-notifier (eoan-proposed/main) [3.192.26 => 3.192.26.1] (ubuntu-desktop, ubuntu-server)
[23:06] <seb128> RikMills, cmake needs that fix it looks like? https://gitlab.kitware.com/cmake/cmake/merge_requests/3877
[23:47] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1065.70] (kernel)