[00:39] -queuebot:#ubuntu-release- Unapproved: numpy (focal-proposed/main) [1:1.17.3-0ubuntu1 => 1:1.17.3-0ubuntu2] (no packageset) [00:39] vorlon, infinity: can one of you approve that pls? [01:37] -queuebot:#ubuntu-release- Unapproved: silo-llnl (focal-proposed/universe) [4.10.2.real-6build1 => 4.10.2.real-6ubuntu1] (no packageset) [02:57] mwhudson: humpty numpy accepted [02:58] -queuebot:#ubuntu-release- Unapproved: accepted numpy [source] (focal-proposed) [1:1.17.3-0ubuntu2] [02:59] infinity: looks to me like profphd is simply broken with new perl and should be removed along with predictprotein revdep (Debian bug #942064) [02:59] Debian bug 942064 in src:profphd "profphd: autopkgtest failure" [Important,Open] http://bugs.debian.org/942064 [05:05] -queuebot:#ubuntu-release- Unapproved: accepted silo-llnl [source] (focal-proposed) [4.10.2.real-6ubuntu1] [05:22] infinity: libextutils-parsexs-perl is present in Debian unstable; it is not present in Ubuntu or in testing (removed because it's the old version which is broken by new perl). The package's test uses upstream source data which lists which versions are broken/replaced/provided by perl. The upstream source data lists the version as '3.40'. [05:22] # the number of digits is a pain [05:22] # we use the current version in the Debian archive to determine [05:22] # how many we need [05:22] infinity: ^^ so the test relies on there being an available version of this package in the archive which can be compared against, in order to figure out how many 0s to stick at the end of the upstream version number when comparing with what's in debian/control. :P [05:22] so it's a bad test and I'm hinting it through for now [06:36] doko: hamlib autopkgtest broken on no-change rebuild by the dh-python move from python to python2 [07:02] -queuebot:#ubuntu-release- Unapproved: hamlib (focal-proposed/universe) [3.3-5build1 => 3.3-5ubuntu1] (no packageset) [07:03] vorlon, ^^ this fixes, but the last debian upload dropped the python2 library... it seems to be with no rdeps, so feel free to do the sync instead! [07:06] (this is why I can't open a Debian bug report) [07:14] vorlon: That test is fixed in (unreleased) 5.30-9, FWIW. [07:15] vorlon: https://salsa.debian.org/perl-team/interpreter/perl/commit/afc9c66ad31ca747d618d3109e94d54e55567bac [07:20] vorlon: Wow, that profphd bug is a rollercoaster. [07:23] vorlon: My favourite part is upstream deeming the bug so "hard" that pulling in a local copy of an 11-year old perl is a better option. [07:30] infinity, you mentioned a submittodebian crash, is it on which ubuntu-dev-tools version and ubuntu system? [07:30] I can reproduce with latest ubuntu-dev-tools version on bionic, but seems not in Debian [07:30] before opening I would like to know your opinion [07:31] fp.write(bug_body.encode('utf-8')) [07:31] TypeError: write() argument must be str, not bytes [07:31] I get this [07:32] LocutusOfBorg: Same thing here, running focal. [07:32] interestingly I opened a sid pbuilder environment and it works... :/ [07:34] LocutusOfBorg: locale-sensitive? Your pbuilder might be LANG=C [07:34] Hrm, nope, running under LANG=C doesn't help. :P [07:39] LocutusOfBorg: https://paste.ubuntu.com/p/sGZb6b8C45/ seems to fix it. [07:40] (I imagine dropping the .encode() would also fix it, but is less desirable) [07:59] -queuebot:#ubuntu-release- Unapproved: firefox (focal-proposed/main) [70.0+build2-0ubuntu1 => 70.0+build2-0ubuntu2] (mozilla, ubuntu-desktop) [08:19] hm so perl is going to migrate on this britney run? [08:24] mwhudson: Not quite. There are still some tests to sort out, I think. [08:24] mwhudson: Close, though. [08:26] mwhudson: When the set that I've retried get done, I'll diff the block from output and output_notest to see what's missing, cause I'm going cross-eyed trying to read all of excuses. :P [08:27] infinity: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses_by_team.html#foundations-bugs sez candidate [08:27] mwhudson: Yes, but not everything else that needs to migrate with it is a candidate. [08:27] ah [08:28] right [08:28] Like I said, iz close though. [08:28] almost time to start bouncing on retry for the python3-defaults things maybe [08:28] nginx is one of the ones I haven't poke yet. Might just need --all-proposed, or a well-crafted trigger. [08:29] And there's the usual "docker tests never work right at the opening of a series". [08:29] Which I'd like fixed, TBH. Could the docker tests maybe not rely on current series goodness all being in place? [08:30] Though it's a good checklist of things that need doing, since I think it relies on debootstrap, lxd, and lxd images all being sorted. [08:30] Maybe other bits too. [08:37] infinity, please accept hamlib so the testsuite is happy again and perl goes a little bit further? [08:38] btw opened debian bug 943385 with your patch [08:38] Debian bug 943385 in src:ubuntu-dev-tools "submittodebian: crash on startup [PATCH]" [Normal,Open] http://bugs.debian.org/943385 [08:38] infinity: there are lxd images now [08:40] error: requested a non-existing branch on 3.0/stable for snap "lxd": [08:40] ubuntu-20.04 [08:41] -queuebot:#ubuntu-release- Unapproved: accepted hamlib [source] (focal-proposed) [3.3-5ubuntu1] [08:41] mwhudson: Yeah, not sure if that's by design (and the deb needs updating) or an oops. Needs stgraber's input. [08:41] right [08:42] isn't that going to break making images too? [08:42] mwhudson: Nope, images seed from a different branch. [08:42] or is there a ubuntu-20.04 branch on other tracks [08:42] ok [08:42] Which isn't confusing at all. [08:43] it's bad enough on snaps where i can see all the branches :) [08:56] infinity: ok to upload a focal version of a fix I want for a eoan SRU at this stage? I don't believe it will entangle anything. If there was an issue, I would have no prob it being taken out of -proposed [08:58] RikMills: Or yuo can upload it and it'll just sit in the queue until we're ready to flush it. *shrug* [08:59] fair enough. just thought I better ask :) [09:04] -queuebot:#ubuntu-release- Unapproved: kate (focal-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.04.3-0ubuntu3] (kubuntu) [09:04] aha. the queue is NOT small. ok ;) [09:12] -queuebot:#ubuntu-release- Unapproved: libxml2 (focal-proposed/main) [2.9.4+dfsg1-7ubuntu4 => 2.9.4+dfsg1-7ubuntu5] (core) [09:12] sigh ^^ libxml2 failed its own autopkgtests because of python->python2 move (I opened a bug report already) [09:20] -queuebot:#ubuntu-release- Unapproved: accepted libxml2 [source] (focal-proposed) [2.9.4+dfsg1-7ubuntu5] [09:26] there are a few boost1.67 arm64 tests that are "running" but not really "running" [09:26] example [09:26] I would say all of them, according to update_excuses [09:26] aevol anbox aqsis autodock-vina [09:26] and so on [09:27] even its own autopkgtests autopkgtest for boost1.67/1.67.0-13ubuntu2: amd64: Pass, arm64: Test in progress (always failed), armhf: Test in progress (always failed), i386: Test in progress (always failed), ppc64el: Test in progress (always failed), s390x: Test in progress (always failed) [09:27] anbox {"triggers": ["boost1.67/1.67.0-13ubuntu2"]} [09:28] ok and what for other architectures? http://autopkgtest.ubuntu.com/packages/b/boost1.67/focal/i386 [09:28] it never run tests against itself... [09:28] The /running page shows it running on all arches. [09:29] Make that 4 arches. [09:29] basically - refresh ;-) [09:29] oh since 46 minutes, 12 hours ago when I looked, it was not on queue, neither on running... [09:30] did somebody use a stick in the meanwhile? [09:34] -queuebot:#ubuntu-release- Unapproved: gpgme1.0 (focal-proposed/main) [1.12.0-6ubuntu2 => 1.12.0-6ubuntu3] (core) [09:35] ^^ python->python2 move [09:40] -queuebot:#ubuntu-release- Unapproved: suricata (focal-proposed/universe) [1:4.1.2-2ubuntu3 => 1:4.1.5-2] (no packageset) (sync) [09:41] -queuebot:#ubuntu-release- Unapproved: accepted gpgme1.0 [source] (focal-proposed) [1.12.0-6ubuntu3] [09:41] -queuebot:#ubuntu-release- Unapproved: accepted suricata [sync] (focal-proposed) [1:4.1.5-2] [09:49] bad linux kernel not providing libbpf-dev ^^ and making this sync fail... [09:49] apw, ^^ any reason for this? [09:58] LocutusOfBorg, off the top of my head, no [09:59] -queuebot:#ubuntu-release- Unapproved: kate (eoan-proposed/universe) [4:19.04.3-0ubuntu2 => 4:19.04.3-0ubuntu2.1] (kubuntu) [10:00] apw: could you move nvidia 435 from multiverse to restriced (bionic)? [10:00] it's a new pkg [10:00] there [10:00] or any AA, really [10:01] apw, should I file a bug? [10:05] LocutusOfBorg, sure [10:05] tjaalton, sure [10:06] -queuebot:#ubuntu-release- Unapproved: suricata (focal-proposed/universe) [1:4.1.5-2 => 1:4.1.5-2ubuntu1] (no packageset) [10:06] infinity, ^^ since you did the sync... [10:07] -queuebot:#ubuntu-release- Unapproved: postgresql-common (focal-proposed/main) [204 => 204ubuntu1] (ubuntu-server) [10:10] LocutusOfBorg: Ta. [10:10] apw: Should we look into our kernel package producing some of the libraries that debian's does? [10:10] infinity, we should yes [10:11] apw: I guess it's just two, libbpf and libcpupower. [10:11] -queuebot:#ubuntu-release- Unapproved: accepted postgresql-common [source] (focal-proposed) [204ubuntu1] [10:11] we produce the second badly, and the first not at all iirc [10:11] -queuebot:#ubuntu-release- Unapproved: cdo (focal-proposed/universe) [1.9.7.1-4 => 1.9.8~rc2-1] (no packageset) (sync) [10:11] -queuebot:#ubuntu-release- Unapproved: accepted suricata [source] (focal-proposed) [1:4.1.5-2ubuntu1] [10:11] -queuebot:#ubuntu-release- Unapproved: python-microversion-parse (focal-proposed/main) [0.2.1-0ubuntu2 => 0.2.1-3] (ubuntu-server) (sync) [10:12] apw: Yeah, I feel like we've had bits of this conversation before. Just came up again rigfht now causew we stumbled on something with a libbpf dep in Debian. [10:12] In fact, the only thing with a libbpf dep in Debian, according to reverse-depends. [10:12] So hardly critical. [10:13] cpupower has a few more. [10:13] infinity, and i suspect from the way they are expressed that they ought to be buildable by a package outside the kernel consuming the -sources kind of thing [10:14] apw: Maybe, but I'm not sure where the value is in that. We'd want to bump that external package any time any source involved in those libs changes. [10:14] apw: So makes more sense to just produce them from master, like linux-libc-dev. [10:14] apw: thanks! [10:14] do we though, given they have abis and should only move forward slowly [10:14] anyhow, you are right we should think about it and do something in focal [10:16] apw: I mean, you're right that they probably don't NEED to be built on every master upload, but then we'd need a complicated thing to make sure that all the source (random internal headers, libbpf code itself, etc) hasn't changed and, if it has, force a rebuild of external package foo. [10:17] apw: That's a lot of effort to go to to avoid just building it on every kernel upload. [10:17] apw: And given the library's sizes compared to the kernel itself, I don't think it's a big deal to force it down the pipe when master updates. [10:18] (Honestly, I think the libs should ship WITH kernels, because upstream doesn't actually guarantee ABI stability, because of course they don't, but then how one even attempts to link to them is a mystery I can't solve) [10:19] (So, best to ship from master, have an ABI break checker in place, and bump SOVER when upstream breaks ABI, IMO) [10:19] Ish. [10:19] Ben's bumped SOVER on libcpupower a couple of times, it looks like, unless upstream's actually started behaving and has done that for him. [10:20] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849642 [10:20] Ubuntu bug 1849642 in linux (Ubuntu) "please provide a libbpf-dev library as debian does" [Undecided,New] [10:20] sforshee, ^^ [10:21] apw: Looks like Ben's doing the ABI tracking and SOVER mangling himself (maybe after I pointed out the problem to him a couple of years ago, I dunno). [10:21] apw: So probably want to look into what he's doing and be in sync. [10:22] apw: Or use our own ABI checking stuff to a similar end. [10:22] I tried to move the discussion on #ubuntu-kernel some minutes ago, sorry for not adding the bug there too [10:23] apw: Thankfully, names of the shared library packages are meaningless, it's only the dev packages that need to match, so we can go our own way on SONAMEs, even calling them libcpupowerubuntuisdifferent0master if we so choose. :P [10:23] LocutusOfBorg: Evidently, I fell out of #ubuntu-kernel at some point. [10:35] -queuebot:#ubuntu-release- Unapproved: python-msgpack (focal-proposed/main) [0.5.6-1ubuntu1 => 0.5.6-2] (ubuntu-desktop, ubuntu-server) (sync) [11:38] infinity, please to let suricata migrate hint on ppc64el and s390x the testsuite. [11:38] both smb and ikev2 tests are new in the release that started failing, and not available on ppc64el and s390x as features (kernel?) [11:38] :q [11:39] debdiffing 3.2-2ubuntu6 and 1:4.1.2-2ubuntu3 gives a clear picture about the new stuff that started making the test look sad [11:41] or maybe the two new features are broken on powerpc and s390x, not sure why [11:43] I don't know where is the upstream bug tracker [11:45] * apw idly wonders if :q got given emoji status just so people who use vi could cover their errors [11:46] * LocutusOfBorg would add also :w to that list! [12:17] -queuebot:#ubuntu-release- Unapproved: suricata (focal-proposed/universe) [1:4.1.5-2ubuntu1 => 1:4.1.5-2ubuntu2] (no packageset) [12:17] ^^ sigh, dropping the delta was premature, even if I don't understand why Debian doesn't fail... [12:22] infinity: oh right also need to open the branch on 3.0. We're going to want to switch that logic to 4.0 before the 20.04 release too but we need LXD 4.0 to happen first :) [12:25] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1024.24~18.04.1] (kernel) [12:25] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1047.50] (no packageset) [12:26] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-33.35~18.04.1] (kernel) [12:26] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-33.35~18.04.1] (kernel) [12:26] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1024.25~18.04.1] (kernel) [12:26] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-33.35~18.04.1] (kernel) [12:28] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1024.25~18.04.1] [12:28] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1047.50] [12:28] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-33.35~18.04.1] [12:28] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1024.24~18.04.1] [12:28] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-33.35~18.04.1] [12:28] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-33.35~18.04.1] [12:49] LocutusOfBorg: Have you confirmed that delta fixes it? The previous version (with that change) was failing in the same way. [12:52] -queuebot:#ubuntu-release- Unapproved: accepted suricata [source] (focal-proposed) [1:4.1.5-2ubuntu2] [12:52] LocutusOfBorg: If this upload of yours doesn't work, I'm tempted to revert to the release pocket version and rebuild that for libevent. [12:52] feel free to do it now [12:53] Because you're sure yours won't work? :P [12:53] I don't think it works, I looked at your change, it seemed good, but indeed there is a failed version in amd64 history [12:53] I thought our autopkgtest didn't have systemd installed [12:53] so moving it was healing the system [12:54] unfortunately old suricata fails with new python [12:54] :/ sad sadness here... I'm discussing on #suricata-dev the ppc64el and s390x failures, they seems to be related to cargo === alan_g is now known as alan_g_ [12:57] suricata has no rdeps, the easy solution here for today might be just to delete it from the release pocket. [12:58] considering how many days I already spent over there, +1 :) [12:59] Always puzzling when autopkgtests pass in Debian and not Ubuntu, though. :/ [12:59] will you let archive open but no autosync for some days, or you will enable it when you open? any ETA? [12:59] infinity, I'm already having a look at that... [13:00] LocutusOfBorg: auto-sync will be turned on when it's open. There'd be no point in delaying, certain people would just play manual auto-sync instead. [13:00] Which is not efficient. [13:00] the reason is to avoid a ton of useless rebuilds... [13:01] like proj and entangling too much stuff [13:01] sil2100: ubuntu-image fails its tests due to there being no ubuntu-20.04 track for snapcraft. Want to hunt down the right people to fix that? [13:02] there is a transition stat started yesterday in debian, like opencvc [13:02] LocutusOfBorg: If we allow a week for every transition, we'll be nowhere by feature freeze. [13:02] LocutusOfBorg: perl's a bit of a special snowflake, cause it reverberates so deeply through the archive (and cause it generally mostly works :P) [13:03] yes but opencv will make the archive sad since rdeps are not ready yet [13:03] LocutusOfBorg: "rdeps aren't ready yet" sound like you meant to say "can you blacklist opencv" not "can you not auto-sync". [13:10] if that works better yes please :D [13:11] infinity, sil2100: I was hunted down and created the ubuntu-20.04 channel branch [13:14] sergiusens: Yay. [13:14] sergiusens: yay \o/ [13:15] Thanks guys [13:17] * ogra praises the hunters [13:25] infinity, we might have suricata patches, please let the ubuntu1 in proposed if possible [13:26] meh also the ubuntu2 is fine, whatever [13:26] infinity, +1 for dropping suricata from release, also fever, the reverse recommends [13:26] LocutusOfBorg, we can fix suricata later, but thanks! [13:28] rbalint: No need to drop reverse-recommends, generally. Why would this one be special? [13:31] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1024.24] (core, kernel) [13:31] Looks like fever can do things without suricata being local. Also, if I artificially punted it out to proposed, it would just migrate back in anyway. So, leaving it where it is. [13:32] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1024.24] [13:41] -queuebot:#ubuntu-release- Unapproved: accepted sylpheed [source] (disco-proposed) [3.5.1-1ubuntu3.19.04.1] [13:42] -queuebot:#ubuntu-release- Unapproved: accepted sylpheed [source] (bionic-proposed) [3.5.1-1ubuntu3.18.04.1] [13:42] LocutusOfBorg: So my take is that the suricata test is just cracktastic, and it's a regression in the testsuite, not the software. [13:43] LocutusOfBorg: On the other hand, the new suricata causing suricata-update's tests to explode on ppc64el and s390x actually is a regression, so that should be looked at if anyone wants it to migrate again. [13:45] Weird combination of arches that. The only thing they really have in common is ibm-longdouble, which doesn't seem like a thing that would matter there. [13:47] jamespage: hey! Was looking at cinder for disco right now - I see two uploads of that, one sync with 2 bug fixes and a new upstream version [13:47] jamespage: should I reject the bileto sync and only consider the new upstream release? [13:49] infinity, ack, i thought dropping reverse recommends is preferred [13:59] -queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (disco-proposed) [2:10.3.10-1ubuntu0.19.04.1] [14:00] apw: as you know from having met me, i have two noses :wq [14:01] -queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (bionic-proposed) [2:10.3.10-1~ubuntu0.18.04.2] [14:03] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-20.21] (core, kernel) [14:03] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-20.21] (core, kernel) [14:03] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-20.21] (core, kernel) [14:03] -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-20.21] (core, kernel) [14:08] Odd_Bloke: Do you IRC from vi now? [14:17] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-20.21] [14:17] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-20.21] [14:17] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-20.21] [14:17] -queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-20.21] [14:23] [15:43:25] LocutusOfBorg: On the other hand, the new suricata causing suricata-update's tests to explode on ppc64el and s390x actually is a regression, so that should be looked at if anyone wants it to migrate again. [14:23] this is what I wrote above [14:23] there are new tests and a failure in detecting rust capabilities [14:34] infinity: I wish [14:44] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20191009.1-0ubuntu2 => 1:20191009.1-0ubuntu3] (no packageset) [14:45] -queuebot:#ubuntu-release- Unapproved: accepted flatpak [source] (bionic-proposed) [1.0.9-0ubuntu0.1] [14:45] -queuebot:#ubuntu-release- Unapproved: pysvn (focal-proposed/universe) [1.9.9-1build1 => 1.9.9-1ubuntu1] (no packageset) [14:48] -queuebot:#ubuntu-release- Unapproved: accepted pysvn [source] (focal-proposed) [1.9.9-1ubuntu1] [14:58] -queuebot:#ubuntu-release- Unapproved: xapian-bindings (focal-proposed/universe) [1.4.11-2build1 => 1.4.11-2ubuntu1] (kubuntu) [14:59] -queuebot:#ubuntu-release- Unapproved: accepted xapian-bindings [source] (focal-proposed) [1.4.11-2ubuntu1] [14:59] -queuebot:#ubuntu-release- Unapproved: python-microversion-parse (focal-proposed/main) [0.2.1-0ubuntu2 => 0.2.1-3] (ubuntu-server) (sync) [15:02] -queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [242-7ubuntu3 => 243-2ubuntu1] (core) [15:08] sil2100: corey and I may have clashed on that one [15:08] lemme peek [15:09] sil2100: ignore the sync, use the uploaded version [15:09] ignore/reject [15:14] jamespage: will do, thanks! ;) [15:15] -queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-7ubuntu3 => 242-7ubuntu3.1] (core) [15:28] -queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1.10] [15:37] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (bionic-proposed) [2.3.0-0ubuntu3.4] [15:45] -queuebot:#ubuntu-release- Unapproved: python-xlrd (focal-proposed/universe) [1.1.0-1 => 1.1.0-1ubuntu1] (no packageset) [15:45] -queuebot:#ubuntu-release- Unapproved: accepted python-xlrd [source] (focal-proposed) [1.1.0-1ubuntu1] [15:51] Looks like perl is 3 packages away from migrating. I think. Will drill to the bottom of that over the next hour. [15:53] infinity: do you think the lxd stuff is sorted to where the current docker.io retries will work? [15:53] vorlon: I sure hope so, cause I retried it. [15:54] vorlon: If stgraber didn't lie to us, it should be good. :) [15:54] ok [15:54] If he did, at least we know it was a little lie? [15:54] *rimshot* [15:55] Actually, to be fair, he didn't say he had opened the 3.0 channel, just that he needed to. But I took that as an "I'll do that now" thing. [15:55] stgraber: ^-- Confirm/deny? [15:56] infinity: and the third package (after vim and nginx) is postgresql-11. I've just retried psqlodbc/armhf and will look a bit deeper at psycopg2 right now [15:57] /usr/bin/pg_virtualenv: line 235: python3.8: command not found [15:57] cute [15:58] infinity: yeah, I ran a loop over 2.0, 3.0, latest on 16.04, 18.04, 19.04, 19.10 and 20.04 earlier today, so that should ensure everything is open [15:58] since there's no real way to tell :) [15:58] stgraber: Because of course there isn't. [16:20] why does the command-not-found autopkg test fail just on armhf? [16:21] it's missing a dependency and that happens to be satisfied on the lxd containers [16:21] (guess) [16:22] s/lxd containers/VMs/ [16:23] why everybody has decided to repeatedly retry it is also an interesting question [16:34] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-67.76~16.04.1] (kernel) [16:34] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-67.76~16.04.1] (kernel) [16:34] Laney: Any idea what dependency that might be? :P [16:34] Not in the slightest [16:34] Makes much more sense for a maintainer to look into it, IMO [16:36] stgraber: If you're still around, next hurdle: lxc autopkgtests no like focal. [16:37] stgraber: A lot of "ERROR: Couldn't find a matching image" [16:37] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20191009.1-0ubuntu3] [16:37] stgraber: Is that a fixable thing in the short term, or should I just skip that mess for now? [16:39] infinity: I added focal to our images about an hour ago [16:39] stgraber: Hah, so I re-ran this test maybe a few minutes too early. ;) [16:39] infinity: just kicked a new image build now, will likely take a couple of hours before they're available on the image servers: https://jenkins.linuxcontainers.org/job/image-ubuntu/987/ [16:39] Oh. [16:40] Let's just pretend I didn't re-run that test just now. [16:41] postgresql-11 sorted with the next run [16:41] \o/ [16:42] still waiting for a successful nova run to unblock nginx [16:44] could a release team member perhaps summarise the state of play? e.g. is it likely that the archive will open before the weekend? [16:44] I am not in a great hurry FWIIW [16:45] I'd *like* to open it after perl migrates (which is very soon), but doko might object strongly to that until a few more python3.8 things are settled. [16:46] ok. if that is as much as can be said, fair enough :) [16:47] vorlon: You haz nova success. [16:47] Well, I haz. [16:48] yep, at least autopkg tests itself shouldn't be broken, and having python3-defaults in -proposed is not much fun [16:48] infinity: \o/ [16:49] Tempted to stop the publisher and see if britney can dump this all in in one pass. [16:49] Though I guess it doesn't deeply matter with a mostly closed archive. [16:56] infinity, Laney: the issue is that for whatever reason, the armhf lxd containers are missing /var/lib/apt/lists/*Commands-*, so the database generation fails [16:57] http://archive.ubuntu.com/ubuntu/dists/focal/main/ [16:57] Not generated [16:57] ah [16:57] anyone who knows how that works should raise their hand now [16:57] That doesn't really explain why the other arches work? [16:57] but this doesn't affect the other archs? are we still using eoan copy-forward images? [16:57] Are they upgraded from eoan VMs that happen to have the bits? [16:58] Are there cloud images for focal now? [16:58] http://cloud-images.ubuntu.com/focal/ yes [16:58] but are they imported into scalingstack [16:58] Dunno [16:59] (is making sure of that on the release opening checklist) [16:59] If you think it'll be fruitful to dig into the two image build processes, feel free :-) [16:59] personally I'm not bothered about finding out exactly where the difference is on this fine point [16:59] well, how about we sort out the missing cnf databases first [16:59] yes [16:59] that's what I'd do [16:59] bdmurray: ^^ how do we get the Commands lists into the archive for focal? [17:01] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-67.76~16.04.1] [17:01] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-67.76~16.04.1] [17:01] $ rsync cnf-extractor.internal::cnf-data [17:01] drwxr-xr-x 4,096 2019/04/24 07:55:38 . [17:01] drwxr-xr-x 4,096 2018/11/21 10:10:50 disco-backports [17:01] drwxr-xr-x 4,096 2018/11/21 12:06:43 disco-proposed [17:01] drwxr-xr-x 4,096 2018/11/21 12:12:56 disco-security [17:01] drwxr-xr-x 4,096 2018/11/21 12:11:54 disco-updates [17:01] drwxr-xr-x 4,096 2018/11/22 03:55:27 disco [17:01] drwxr-xr-x 4,096 2019/04/24 07:30:01 eoan-backports [17:01] drwxr-xr-x 4,096 2019/04/24 07:51:49 eoan-proposed [17:01] drwxr-xr-x 4,096 2019/04/24 07:52:28 eoan-security [17:01] drwxr-xr-x 4,096 2019/04/24 07:52:09 eoan-updates [17:01] drwxr-xr-x 4,096 2019/04/24 12:03:02 eoan [17:02] So, yeah, no focal. [17:02] Now, what host is that really? [17:02] Some canonistack thing? [17:02] it's probably generated from a service on wendigo [17:03] Yes [17:03] Looks like only mvo has access to that [17:03] Methinks we should fix that. [17:04] And then get the fixing up process into NewReleaseCycleProcess. [17:04] Or it should be made to not need fixing up, ideally. [17:05] this is why I tagged bdmurray, there was a conversation about Foundations having access to this and not just mvo, I don't know if that got done yet [17:05] but I guess someone's checked the groups on wendigo and found that it hasn't [17:07] wendigo:~$ getent group prod-cnf-extractor [17:07] prod-cnf-extractor:x:3294:mvo [17:08] thanks for the confirmation ;-) [17:08] -queuebot:#ubuntu-release- Unapproved: fast5 (focal-proposed/universe) [0.6.5-2build2 => 0.6.5-2ubuntu1] (no packageset) [17:08] ok, night [17:08] vorlon: I imagine the group bit can be solved with a strongly-worded ticket, but I also suspect it might be nice to get a quick HOWTO from mvo. :P [17:09] (Or maybe it's super simple and obvious to dive into) [17:09] Actually, from what I remember of the code, it probably is rather obvious once you see it. [17:10] How urgent is this? Is mvo not around? [17:10] getting spammed with migration emails [17:11] This is not an emergency, so I think we can be polite and wait for Michael to be around tomorrow [17:11] ^ [17:11] Probably worth submitting an RT anyway [17:11] An RT CCed to mvo is a decent compromise between polite and getting stuff done. [17:12] Who are you going to nominate to get added to that group? adconrad,vorlon,laney,bdmurray? [17:12] -queuebot:#ubuntu-release- Unapproved: pygobject (focal-proposed/main) [3.34.0-1ubuntu1 => 3.34.0-1ubuntu2] (core) [17:13] I'll choose the first of those names based on alphabetical order [17:13] Maybe an LP person or two, if cjwatson or wgrant consent. [17:13] -queuebot:#ubuntu-release- Unapproved: accepted fast5 [source] (focal-proposed) [0.6.5-2ubuntu1] [17:13] -queuebot:#ubuntu-release- Unapproved: accepted pygobject [source] (focal-proposed) [3.34.0-1ubuntu2] [17:13] But fine, it can just be me for now. :P [17:16] infinity: I don't mind either way [17:17] bdmurray: There you go. Colin desperately wants to be a member of the group. [17:17] Bluff [17:31] infinity: I was going to suggest that it be some subset of ~ubuntu-archive given where the data is ultimately published [17:32] vorlon: Right, it should be people who have access to pepo (and occasionally use it). [17:32] vorlon: Hence my suggestion of LP folks who also happen to be AAs. [17:32] ah [17:33] so, I was going to suggest adconrad,doko,sil2100,vorlon based on union(foundations,ubuntu-archive) and see after a cycle if anyone complained at being blocked [17:34] I would rate "access to pepo" as less relevant here than ubuntu-archive [17:35] -queuebot:#ubuntu-release- Unapproved: gexiv2 (focal-proposed/main) [0.10.9-1 => 0.10.9-1ubuntu1] (ubuntu-desktop) [17:35] vorlon: Perhaps, though it's impossible to debug without. [17:35] impossible to debug the last mile, but you could hit the rsync endpoint from anywhere I suppose? [17:36] "anywhere" [17:36] vorlon: That said, we're working to get shells off of pepo entirely, so a fair point. [17:36] oh hey look, perl [17:37] vorlon: I'd smear it around so it's not just FOundations, but if you're asserting ownership... [17:37] vorlon: I'd prefer a set like adconrad,cjwatson,mvo,laney,vorlon (and a couple more, if you like) [17:37] infinity: foundations owns the client, and based on the discussion we already had with mvo, should also own the service [17:37] But it's not really a critical service that needs OMG RIGHT NOW response either, so I'm not super opinionated on the matter. [17:38] Alrighty. [17:38] I don't mind laney and cjwatson being in the list, but I also don't think it's their responsibility [17:38] * infinity nods. [17:40] vorlon, doko: More pressing matter, now that perl is migrat{ed,ing}, do we want to argue about what the go point is for thawing the archive and turning on auto-sync? python3-defaults migrated? Earlier? Later? [17:43] infinity: from what I can see, python3-defaults isn't entangled in a transition so I don't see any reason to hold up the archive opening until it migrates. doko? [17:46] -queuebot:#ubuntu-release- Unapproved: wslu (bionic-proposed/main) [2.0.0-0ubuntu2~18.04.1 => 2.3.2-0ubuntu2~18.04.0] (no packageset) [17:46] -queuebot:#ubuntu-release- Unapproved: wslu (eoan-proposed/main) [2.3.2-0ubuntu1 => 2.3.2-0ubuntu2~19.10.0] (core) [17:46] -queuebot:#ubuntu-release- Unapproved: wslu (disco-proposed/main) [2.0.0-0ubuntu2.19.04.0 => 2.3.2-0ubuntu2~19.04] (core) [17:47] -queuebot:#ubuntu-release- Unapproved: wslu (xenial-proposed/main) [2.0.0-0ubuntu2~16.04.1 => 2.3.2-0ubuntu2~16.04.0] (no packageset) [17:47] -queuebot:#ubuntu-release- Unapproved: wslu (focal-proposed/main) [2.3.2-0ubuntu1 => 2.3.2-0ubuntu2] (core) [17:50] infinity, vorlon: I'm fine with that, but I'd like to get some packages migrated. it's ugly to see stuff like the one I just pointed out on #u-d. so can we delay that until tomorrow? [17:52] "some packages" doesn't give us a goal to work toward. [17:52] Do you have specifics? :) [17:53] those from the lower tracker levels that are now built, and didn't yet migrate. [17:53] -queuebot:#ubuntu-release- Unapproved: last-align (focal-proposed/universe) [983-1 => 983-1ubuntu1] (no packageset) [17:54] infinity: distro-info maybe [17:55] distro-info will migrate in an hour or two when the lxc images are built. [17:55] good [17:56] -queuebot:#ubuntu-release- Unapproved: accepted gexiv2 [source] (focal-proposed) [0.10.9-1ubuntu1] [17:56] -queuebot:#ubuntu-release- Unapproved: accepted last-align [source] (focal-proposed) [983-1ubuntu1] [17:57] doko: are there any other packages then? [17:57] stgraber: Your i386/default build seems to have eaten itself near the end. [17:58] bdmurray: "those from the lower tracker levels that are now built, and didn't yet migrate" [17:58] link to the tracker in question? [17:59] https://people.canonical.com/~ubuntu-archive/transitions/html/python3.8-add.html [17:59] https://people.canonical.com/~ubuntu-archive/transitions/html/python3.8-add.html [17:59] infinity: yeah, looks like the kernel didn't like living much anymore, it's being retried now [18:00] infinity: what about libevent? [18:00] doko: libevent was entangled with perl, they should both have migrated together. [18:00] And indeed they did. [18:01] stgraber: I'm in first-round funding for my new startup whose mission statement is "we'll do literally anything you want us to do for money, as long as it doesn't involve a computer in any way", if you ever get sick of saying things like "the kernel didn't like living anymore". [18:03] :) [18:03] infinity: looks like it doesn't like the archive much now: https://jenkins.linuxcontainers.org/job/image-ubuntu/architecture=i386,release=focal,restrict=lxc-priv,variant=default/990/console [18:05] stgraber: Oh, the archive is probably broken for a publisher cycle or two, perl migration got split across runs. [18:05] yeah, looks like it, that package was just published as part of the perl migration [18:05] Maybe I should have stopped the publisher after all. Oh well. [18:06] so I guess I got lucky with the first round of images hitting just before those packages got published :) [18:06] Yep. [18:07] infinity: I know a guy looking to build walipini greenhouses in Portland, come on down [18:18] if we delay the archive opening until tomorrow and infinity is out, who can ensure that it gets opened? [18:20] Ping me, ping a GSA in #is if I'm not around, win. [18:27] stgraber: Looks like the publisher's settled down. I'm validating no copies got lost, but you're likely good to go to try again. [18:45] Oh look, we didn't lose any copies. perl migration complete. [18:46] -queuebot:#ubuntu-release- Unapproved: debhelper (focal-proposed/main) [12.6.1ubuntu2 => 12.7ubuntu1] (core) [18:54] who is usually looking at aptdaemon ? [18:54] 1 test failure [18:54] doko: The guy with all the broken arms. [18:56] ahh [19:04] -queuebot:#ubuntu-release- Unapproved: collectd (focal-proposed/universe) [5.8.1-1.3ubuntu1 => 5.8.1-1.3ubuntu2] (no packageset) [19:08] -queuebot:#ubuntu-release- Unapproved: accepted collectd [source] (focal-proposed) [5.8.1-1.3ubuntu2] [19:21] doko: beets autopkgtests look like a genuine regression with python3.8. What do you expect to happen with such things? (But also, why is the autopkgtest for an application testing against py3versions -s instead of py3versions -d) [19:21] vorlon: I saw this just in odil [19:22] at least in odil it's triggered by Testsuite: autopkgtest-pkg-python [19:24] Argument "2ubuntu1" isn't numeric in numeric eq (==) at /usr/share/lintian/checks/debian/changelog.pm line 160. [19:24] >_< [19:26] -queuebot:#ubuntu-release- Unapproved: python-fann2 (focal-proposed/universe) [1:1.1.2+ds-1build1 => 1:1.1.2+ds-1ubuntu1] (no packageset) [19:31] -queuebot:#ubuntu-release- Unapproved: tlsh (focal-proposed/universe) [3.4.4+20151206-1.1build1 => 3.4.4+20151206-1.1ubuntu1] (no packageset) [19:32] -queuebot:#ubuntu-release- Unapproved: accepted python-fann2 [source] (focal-proposed) [1:1.1.2+ds-1ubuntu1] [19:32] -queuebot:#ubuntu-release- Unapproved: polkit-qt-1 (focal-proposed/universe) [0.112.0-6 => 0.112.0-7.1] (kubuntu) (sync) [19:32] -queuebot:#ubuntu-release- Unapproved: accepted tlsh [source] (focal-proposed) [3.4.4+20151206-1.1ubuntu1] [19:32] -queuebot:#ubuntu-release- Unapproved: python-rjsmin (focal-proposed/main) [1.0.12+dfsg1-4ubuntu2 => 1.0.12+dfsg1-5ubuntu1] (ubuntu-server) [19:44] -queuebot:#ubuntu-release- Unapproved: accepted debhelper [source] (focal-proposed) [12.7ubuntu1] [19:44] -queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync) [20:15] omg perl migrated [20:16] stgraber: I'm in first-round funding for my new startup whose mission statement is "we'll do literally anything you want us to do for money, as long as it doesn't involve a computer in any way", if you ever get sick of saying things like "the kernel didn't like living anymore". [20:16] you might be 20 years or so too late for this to be practical, sadly [20:24] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (disco-proposed) [1.10ubuntu5.2] [20:29] -queuebot:#ubuntu-release- Unapproved: beets (focal-proposed/universe) [1.4.7-2 => 1.4.7-2ubuntu1] (no packageset) [20:29] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.12] [20:29] -queuebot:#ubuntu-release- Unapproved: rygel (eoan-proposed/main) [0.38.1-2ubuntu3 => 0.38.1-2ubuntu3.1] (desktop-extra) [20:31] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.4] [20:43] -queuebot:#ubuntu-release- Unapproved: accepted beets [source] (focal-proposed) [1.4.7-2ubuntu1] [20:57] vorlon, infinity: distroinfo/i386 still fails. is this expected? [20:58] lxc [21:04] doko: I thought I saw some further comment from infinity about that in scrollback, but I don't really know. From my POV probably nobody should be building i386 container images for 20.04 [21:10] so I'd like to see the following packages to migrate before the archive opening: pygobject, gpgme1.0, libxml2, disto-info, dbus-python, boost1.67, libselinux, pillow [21:10] -queuebot:#ubuntu-release- Unapproved: mu-editor (focal-proposed/universe) [1.0.2+dfsg-3 => 1.0.2+dfsg-3ubuntu1] (no packageset) [21:10] - pygobject and pillow will migrate [21:12] - gpgme1.0, libxml2, boost1.67, libselinux are blocked by a failing libreoffice autopkg test [21:12] - dbus-python is blocked by aptdaemon [21:12] - distro-info is blocked by lxc/i386 [21:13] aptdaemon should be a trivial rerun with --all-proposed (triggering this now) [21:13] ahh, libselinux is blocked by lxc, not libreoffice [21:14] from an archive and release POV I don't follow why it's appropriate to block the archive opening on these since they are not transitions [21:14] like python-apt? [21:15] ? [21:15] see #u-d [21:16] that doesn't explain [21:16] you gave a list of packages, which are not transitions; I posit that we should not block archive opening on their migration because they are not transitions; you name another unrelated package [21:16] how not? was the hinting premature? [21:22] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (focal-proposed/universe) [5.12.4+dfsg-4ubuntu1 => 5.12.5+dfsg-2] (kubuntu, qt5) (sync) [21:22] -queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-3] (kubuntu, qt5) (sync) [21:22] -queuebot:#ubuntu-release- Unapproved: qtlocation-opensource-src (focal-proposed/universe) [5.12.4+dfsg-1 => 5.12.5+dfsg-2] (kubuntu, qt5) (sync) [21:22] -queuebot:#ubuntu-release- Unapproved: qtsensors-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-2] (kubuntu, qt5) (sync) [21:22] -queuebot:#ubuntu-release- Unapproved: qttools-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-2] (kubuntu, qt5) (sync) [21:22] -queuebot:#ubuntu-release- Unapproved: qtwebchannel-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-2] (kubuntu) (sync) [21:22] -queuebot:#ubuntu-release- Unapproved: qtwebsockets-opensource-src (focal-proposed/universe) [5.12.4-1 => 5.12.5-2] (kubuntu, qt5) (sync) [21:22] -queuebot:#ubuntu-release- Unapproved: qtwebkit-opensource-src (focal-proposed/universe) [5.212.0~alpha3-3 => 5.212.0~alpha3-5] (kubuntu, qt5) (sync) [21:23] mitya57: ooooh :) [21:24] ↑: this is the part of Qt 5.12.5 that needed to be bootstrapped. The rest will be auto-synced when auto syncs are turned on. [21:28] mitya57: did that migrate in debian? [21:29] not yet [21:29] We are blocked on slow buildds, libreoffice autopkgtest failure and pyqt5 hitting NEW. [21:31] do we have the new pyqt5? [21:31] we are blocked on libreoffice anyway [21:46] mitya57: ^^^ [21:46] doko: what do you mean by new pyqt5? [21:47] 5.13? [21:47] mitya57: "... and pyqt5 hitting NEW" [21:47] It hit NEW for some unknown reason, only on mips64el. [21:48] ahh, so not in focal [21:48] So that doesn't affect us. [21:48] ok, and the current pyqt5 migrated for the python3.8 upload [21:50] I added python3.8 compatibility in a bit different way in Debian, but there is no need to sync it now. [21:52] -queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [sync] (focal-proposed) [5.12.5+dfsg-2] [21:52] -queuebot:#ubuntu-release- Unapproved: accepted qtlocation-opensource-src [sync] (focal-proposed) [5.12.5+dfsg-2] [21:52] -queuebot:#ubuntu-release- Unapproved: accepted qttools-opensource-src [sync] (focal-proposed) [5.12.5-2] [21:52] -queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [sync] (focal-proposed) [5.212.0~alpha3-5] [21:52] -queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src [sync] (focal-proposed) [5.12.5-3] [21:52] -queuebot:#ubuntu-release- Unapproved: accepted qtwebchannel-opensource-src [sync] (focal-proposed) [5.12.5-2] [21:52] -queuebot:#ubuntu-release- Unapproved: accepted qtsensors-opensource-src [sync] (focal-proposed) [5.12.5-2] [21:52] -queuebot:#ubuntu-release- Unapproved: accepted qtwebsockets-opensource-src [sync] (focal-proposed) [5.12.5-2] [21:53] -queuebot:#ubuntu-release- Unapproved: accepted mu-editor [source] (focal-proposed) [1.0.2+dfsg-3ubuntu1] [21:53] -queuebot:#ubuntu-release- Unapproved: fcitx (focal-proposed/universe) [1:4.2.9.6-5build1 => 1:4.2.9.6-6] (input-methods, kubuntu) (sync) [21:53] mitya57: ^^^ [21:53] thanks! [21:54] doko: I will do rebuilds when the rest of Qt 5.12.5 is auto-synced. [22:28] mwhudson: do you happen to have looked at the gyoto misbuild with python3.8? (/usr/lib/x86_64-linux-gnu/gyoto/7/libgyoto-python3.8.so not linked to libpython3.8) [22:28] vorlon: no [22:28] do you want to [22:28] :) [22:28] vorlon: i really need to do the cargo update for firefox but it can go on the list after that [22:29] ack [22:29] is there a python3.8-compatible django somewhere? [22:29] nfi [22:36] mwhudson: and psautohint appears to have entirely sensible packaging (it builds an extension only for the current python3 using a python3-dev build-dep), but autodep8 generates an autopkgtest that tries to test against python3.8. any thoughts? [22:37] vorlon: sounds like autodep8 shouldn't do that? [22:37] vorlon: but i don't know how it works in the slightest [22:37] right :) [22:38] the existing autogenerated test is correct for non-C modules [22:38] and I don't know how autodep8 should detect the difference between compiled extensions and not [22:39] (currently it calculates the test based only on the source package, it doesn't look at the binaries in the archive) [22:42]