vorlonautopkgtest [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-testbed05: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-1105: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=,,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,ppa.launchpad.net'"'"'' --mirror=http://ftpmaster.internal/ubuntu05:43
* vorlon waits05:43
vorlon(for the test failure, since the i386 binaries have been removed ;P)05:45
vorlonwell hey, the pass rate for cross-tests of the remaining packages on i386 is > 0%: http://autopkgtest.ubuntu.com/packages/a/adduser/focal/i38607:15
vorlon(of course, this is an arch: all package anyway so it tells us nothing about quality)07:15
-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:16
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [207-1~ubuntu18.04.1 => 208-1~ubuntu18.04.1] (no packageset)07:17
LocutusOfBorghello cyphermox, nodejs merge please? a lots of nodejs packages are stuck...08:42
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)09:18
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-25.27] (core, kernel)09:19
-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:20
LocutusOfBorgnvm, syncing it09:44
-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:21
seb128can 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 updates10:43
apwseb128, that looks a lot like a dependant package for silx is broken with it or in and of itself11:02
apwseb128, if i am reading the trace back right ?11:02
-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:13
-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:14
seb128apw, which log are you looking at?11:21
seb128apw, 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 migrate11:23
seb128h5py is buggy in the release pocket and it's impacting on a number of other tests, would be nice to see that resolved11:23
apwseb128, so would just requesting a test of sixl and h5py not cause those to look happy ?11:33
seb128apw, that's the second entry on http://autopkgtest.ubuntu.com/packages/s/silx/focal/amd6411:33
seb128apw, that makes h5py happy but opencl fails with11:34
seb128pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident module'.11:34
seb128apw, 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 candidate11:35
seb128which would allow us to have the fixed h5py migrating11:35
seb128which would make other tests happier (and not having people like me chasing retries to add &trigger=h5py/2.10.0-2)11:35
seb128the opencl/silx problem still needs to be sorted out11:36
seb128but meanwhile it would make things easier to unblock the other ones11:36
seb128if that makes any sense?11:36
apwsome indeed11:37
apwseb128, ok so the logical hint is to hint python-fabio good as that does not randomly unblock other things which have not been eye-balled11:38
apwseb128, but you also have self-test failures for s390x11:38
seb128apw, ah, right :(11:40
seb128apw, thx for pointing that out, I'll have a look to that11:40
apwseb128, ack thanks11:40
RikMillscould someone with permissions do an imagemagick no change rebuild against libopenexr24? that should be one of the last things holding the ilmbase/openexr transition11:55
-queuebot:#ubuntu-release- Unapproved: pam (eoan-proposed/main) [1.3.1-5ubuntu1 => 1.3.1-5ubuntu1.19.10.0] (core)12:07
rbalintsil2100, please drop pam ^12:10
-queuebot:#ubuntu-release- Unapproved: rejected pam [source] (eoan-proposed) [1.3.1-5ubuntu1.19.10.0]12:18
seb128RikMills, k, doing now12:19
RikMillsseb128: thanks!12:20
seb128RikMills, freeimage has failing i386 tests (forge & freeimage) that should probably be marked badtest to make it candidate12:26
RikMillsseb128: yeah. was going to ask vorlon this morning before his eod in the USA, but forgot12:27
seb128RikMills, you can probably get any r-t member to merge a such mp if you send one12:28
seb128RikMills, just need to be added to the i386 section from https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/ubuntu-release I guess12:29
* RikMills shudders at doing a mp with bzr12:29
seb128RikMills, I can do it if you want?12:29
RikMillsseb128: that would be great. I don't have much time until later12:30
seb128RikMills, k, I do it, I've some other ones to add in that section anyway12:30
seb128if someone wants to review/merge that12:40
-queuebot:#ubuntu-release- Unapproved: pam (eoan-proposed/main) [1.3.1-5ubuntu1 => 1.3.1-5ubuntu1.19.10.0] (core)12:42
slashdo/ sil2100, could you please review the upload of 'stress-ng' in E/D/B when you have a moment ? Thanks in advance !12:48
slashdmfo, ^12:48
=== s8321414_ is now known as s8321414
sil2100slashd: hey o/ Sure12:54
sil2100Just need to finish the publishing to -updates12:54
mfoslashd, 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/12:57
-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:18
-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:19
-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:20
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1032.36]13:21
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (eoan-proposed) [0.10.07-1ubuntu2]13:36
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (disco-proposed) [0.09.57-0ubuntu4]13:46
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (bionic-proposed) [0.09.25-1ubuntu5]13:47
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (eoan-proposed/universe) [2.7.17~rc1-1 => 2.7.17-1~19.10] (kubuntu)14:40
-queuebot:#ubuntu-release- Unapproved: python2.7 (eoan-proposed/universe) [2.7.17~rc1-1 => 2.7.17-1~19.10] (kubuntu)14:42
-queuebot:#ubuntu-release- Unapproved: gcc-8 (eoan-proposed/universe) [8.3.0-23ubuntu2 => 8.3.0-26ubuntu1~19.10] (core)14:46
-queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8.3.0-6ubuntu1~18.04.1 => 8.3.0-26ubuntu1~18.04] (core)14:48
-queuebot:#ubuntu-release- Unapproved: gcc-7 (eoan-proposed/universe) [7.4.0-14ubuntu2 => 7.5.0-3ubuntu1~19.10] (core)14:51
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.4.0-1ubuntu1~18.04.1 => 7.5.0-3ubuntu1~18.04] (core)14:53
cpaelzerddstreet: 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 timeout15:01
cpaelzeris 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:01
cpaelzerLaney: cjwatson: ^^ FYI for your general great knowledge about the inner workings of autopkgtest.u.c15:02
ddstreetcpaelzer what do you mean 'vanish'?15:02
ddstreetthe result links are added on the PRs upstream, for the latest test run15:03
cpaelzerE.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
gitbotsystemd 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
cpaelzerlast time they just went away, no more mentioned15:03
cpaelzernot failed and not succeeded15:03
cpaelzerjust gone fromt he overview15:03
cpaelzerI thought I ask while the tests are still "active"15:03
cpaelzeras afterwards there might be not much to look after15:04
cpaelzerHere Lennard seems to mention that this "happens sometimes" https://github.com/systemd/systemd/pull/14167#issuecomment-56204365315:04
gitbotsystemd 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
cpaelzerthe question is can/should we do someting about it15:04
ddstreetall the old tests are still available, you just have to go thru pain to manually find them15:04
ddstreetthere was general infrastructure problems on dec 2, so i think a lot of Ubuntu ci jobs got dropped then15:05
ddstreetthat does happen sometimes15:05
cpaelzerok, I can wait until thesw work or timeout or disappear15:06
ddstreetbut normally all the ci jobs should complete and update github with the results and log.gz link15:06
cpaelzerjust wanted to be proactive while still debuggable15:06
ddstreethave you tried gathering the resutls with the autopkgtest-manager script?  that makes autopkgtest.u.c less painful to gather results from15:07
cpaelzerddstreet: I haven't looked for the systemd CI results via that15:08
cpaelzerthe current ones are still running, I'd look for them afterwards15:08
ddstreetmight be helpful15:08
cpaelzerbut I can try to find the old ones15:08
-queuebot:#ubuntu-release- Unapproved: base-files (eoan-proposed/main) [10.2ubuntu7 => 11ubuntu7.19.10.0] (core)15:09
ddstreeti set in my .bash_aliases export AUTOPKGTEST_MANAGER_CACHE_DIR="~/autopkgtest-manager"15:09
ddstreetand then i create /home/ddstreet/autopkgtest-manager-systemd-upstream -> autopkgtest-manager/autopkgtest-bionic-upstream-systemd-ci-systemd-ci/pr15:09
ddstreetmakes it a bit easier to review various systemd-upstream PR results15:09
seb128apw, 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
seb128FAILED (failures=5, errors=43, skipped=17)15:13
seb128Test suite failed15:13
seb128autopkgtest [02:20:39]: test python3-dbg: -----------------------]15:13
seb128autopkgtest [02:20:40]: test python3-dbg:  - - - - - - - - - - results - - - - - - - - - -15:13
seb128python3-dbg          PASS15:13
seb128apw, so basically it always failed, just the packaging was buggy before and not returning the error properly15:13
apwseb128, so it is random what it says, but it is always failed15:13
seb128so it's not a regression15:13
seb128they fixed it to properly error out15:14
seb128do we have a way to do an history reset of a test? like declare it always failed?15:14
apwwe have literally no way to do that, and it is the most annoying of things15:15
seb128seems annoying indeed :-/15:15
-queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.1.0-0ubuntu1.2 => 3:15.1.1-0ubuntu1] (openstack, ubuntu-server)15:17
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.2-0ubuntu1 => 2:14.0.3-0ubuntu1] (openstack, ubuntu-server)15:20
cjwatsoncpaelzer: I have no knowledge whatsoever about the internal workings of autopkgtest15:21
apwseb128, and so hinted15:21
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (disco-proposed/universe) [2:14.0.0-0ubuntu1 => 2:14.0.1-0ubuntu1] (openstack)15:22
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan 19.10.1] has been marked as ready15:27
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan 19.10.1] has been marked as ready15:27
-queuebot:#ubuntu-release- Unapproved: octavia (disco-proposed/universe) [4.0.0-0ubuntu1.2 => 4.1.0-0ubuntu1] (no packageset)15:29
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1031.34]15:33
seb128apw, thanks15:33
apwseb128, np, thanks for doing the legwork on the s390x regression marker15:36
-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:44
-queuebot:#ubuntu-release- Unapproved: lvm2 (disco-proposed/main) [2.02.176-4.1ubuntu4.1 => 2.02.176-4.1ubuntu4.2] (core)15:45
-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:51
-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)16:24
vorlonhappy i386 day https://paste.ubuntu.com/p/HvbrGHNYx3/18:01
vorloninfinity: re-ping on https://code.launchpad.net/~vorlon/ubuntu-archive-tools/update-i386-whitelist/+merge/37604218:10
vorlonseb128: ^^ 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 increase18:14
vorlonthe good news is we should reach steady state fairly quickly, we'll just need to badtest the arch: all packages with tests18:15
infinityvorlon: It has comments.  Do as you will with them.  I'm sick and wishy-washy today.18:24
vorloninfinity: do you have a link handy to the LP bug?18:27
ubot5Ubuntu bug 1855069 in Launchpad itself "PPAs should be able to toggle using PRIMARY's arch-{white,black}lists" [Undecided,New]18:28
infinityvorlon: 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:33
infinityvorlon: 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:34
vorloninfinity: in practice I download the file locally, do a --dry-run, and then commit :)18:37
vorlonbut 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 etc18:37
vorlonbut yeah I don't think this is sane to ever run without human oversight18:37
infinityvorlon: 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
vorlonsince one wrong package removal means germinate will shrink the packageset to 018:38
infinityA y/n with no --yes override, so it's clear it must be interactive. :P18:38
vorloninfinity: well you were wishy-washy and I've already merged it now without that... :)18:38
infinityHah.  Well, if you have "spare time".18:38
* vorlon nods :)18:39
infinityIt 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:39
vorloninfinity: done18:47
RikMillscould someone run the tests to see if cmake/3.13.4-1build1 is regressed in release please?19:00
RikMillsI have seen the finding of harfbuzz fail due to new pango in release, so the imagemagick cmake test fails look to be the same cause19:04
-queuebot:#ubuntu-release- Packageset: Added gcc-10 to i386-whitelist in focal19:17
vorlon8166 badtest hints added for i38619:24
vorlonthis is fine19:24
vorlonRikMills: 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:25
RikMillsvorlon: https://gitlab.kitware.com/cmake/cmake/issues/1953119:28
RikMillsdue to new pango 1.44 in -release19:29
vorlonRikMills: tests triggered19:31
RikMillsvorlon: pango1.0 1.44.7-1 published to -release on 21Nov, so may have been just after that successful test19:31
RikMillsvorlon: thanks!19:31
RikMillsI could be misreading it, but would be good to know :)19:32
RikMillsyeah, pango pubished 12+ hrs later19:34
RikMillsvorlon: may I ask what the rationale for triggering the cmake tests against 'gcc-defaults/1.185.1ubuntu1' is?19:53
vorlonRikMills: baseline retests against the release pocket require specifying a trigger which is a package with no version in -proposed19:54
vorlonI generally pick glibc, but there's currently a version in proposed19:55
RikMillsvorlon: so it would not work with the cmake version in release as a trigger?19:55
vorlonRikMills: no, because the autopkgtest code gets confused and winds up pinning against the version of cmake from -proposed anyway and testing that19:56
RikMillsvorlon: thanks. that is actually REALLY useful to know :)19:56
RikMillsrefreshing https://autopkgtest.ubuntu.com/running#pkg-cmake I just saw ppc64el win the race to a test fail in the way I expected20:10
RikMillsjust wait for the rest I guess, and results20:10
RikMills+ s390x20:13
RikMillsI'll shut up now....20:13
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1031.34~16.04.1] (kernel)20:38
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1031.34~16.04.1]20:51
-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:00
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (bionic-proposed) [2.02.176-4.1ubuntu3.18.04.2]21:02
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (eoan-proposed) [2.7.17-1~19.10]21:05
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (eoan-proposed) [2.7.17-1~19.10]21:14
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (bionic-proposed) [2.7.17-1~18.04]21:20
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (bionic-proposed) [2.7.17-1~18.04]21:21
vorlonxnox: 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:44
xnoxvorlon:  i had thoughts and no prayers21:45
xnoxvorlon:  does nodejs still ftbfs on i386 or is it ok?21:45
vorlonxnox: no idea21:45
vorlonxnox: it seems to be bfs, there's a version in -proposed synced today which has tests running21:46
xnoxvorlon:  wait21:46
xnoxwe don't care about -Indep21:46
xnoxwe only need -Indep on arch:amd6421:46
vorlonxnox: we don't /in principle/ care about indep but they're still being traversed currently21:46
xnoxbecause we build _all.deb packages on amd6421:46
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
xnoxdoes launchpad install Indeps for arch builds today?21:47
vorlonit does not21:47
vorlon(I just checked the log to confirm)21:47
xnoxso either selectively blacklist the whitelist21:48
vorlonxnox: so in principle it seems like this might be something that the no-follow-build-depends-all feature should handle21:48
xnoxnot "-all" but like "-indep"21:48
vorlonsince the packages listed in Build-Depends-Indep are the build-depends of an arch-all package21:48
vorlonno, I think it fits under the existing flag definition21:48
xnoxah, existing flag is "no-follow-build-depends"21:49
xnoxif i recall correctly21:49
vorlonno-follow-build-depends-all is the new flag I added (which cjwatson kindly merged)21:49
xnoxah, i see what you mean21:49
xnoxwell, there are corner cases21:49
vorlonand which we use to not pull all of rust etc into the i386 set :)21:49
xnoxas context of other packages in the same source package matter21:49
xnoxi.e. arch: i386 arch:all  => is only built on i386 and needs Indep21:50
xnoxwhich is a bad example21:50
vorlonI believe we still build the arch: all package on amd64 in that case also21:51
vorlonand 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:52
xnoxSo, you want to skip B-D-Indep on i386, correct?21:54
infinityI vaguely recall mentioning you'd need this. :P21:54
vorlonbut 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 having21:54
infinityIt'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
xnoxvorlon:  definately not.21:57
xnoxvorlon:  my MP is for entirely different thing unfortunately.21:57
xnoxit has no good way to transverse past arch:all, non-multiarched apps.21:58
infinityxnox: 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:00
xnoxinfinity:  we seed multiple amd64 versions, which have cross-arch recommends on the i386 versions22:02
xnoxinfinity:  it was intentional for me to _only_ introduce cross-arch resolution without any new seed syntax.22:03
infinityxnox: Oh, the recommends are from the nvidia packages?  Oh, right.  The release sprint is slowly coming back to me. :P22:03
xnoxinfinity:  because we definately do not want "nvidia-drivers [amd64:i386]" as that would then pull in the whole of i386 graphics stack22:03
infinityxnox: 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
xnoxinfinity:  we only want the libnvidiafooXYZ:amd64|i38622:04
xnoxexplicit seeding makes sence for truly i386 app, like wine22:04
xnoxwhich is M-A: nothing & arch:i386 and my current code cannot cope with that, past22:05
infinityWe might not need it now, but it feels like it would make the multi-arch handling more complete for future use.22:05
xnoxarch:all => arch:any deps boundary22:05
infinityAnyhow, not urgent, just something to ponder.22:05
infinityThe nvidia thing is definitely the current pain point.22:05
infinityAnd I can't wait to kill the static file hack in debian-cd.22:05
xnoxthe next pain point of mine, is to load all arches in one go22:05
xnoxsuch 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:06
infinityAhh yeah, the part where we only run for one arch there is confusing to people trying to examine why something is included.22:07
infinityI'll admit that it annoys me enough that I tend to use ftpmaster's copies instead, which are for all arches.22:07
infinityNot exactly an option for most people.22:08
* vorlon nods22:08
infinityWe 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:11
infinityIt's only for the devel series, but that's what most people care about.22:12
-queuebot:#ubuntu-release- Unapproved: update-notifier (eoan-proposed/main) [3.192.26 =>] (ubuntu-desktop, ubuntu-server)22:23
seb128RikMills, cmake needs that fix it looks like? https://gitlab.kitware.com/cmake/cmake/merge_requests/387723:06
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1065.70] (kernel)23:47

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