| -queuebot:#ubuntu-release- New binary: rust-shadow-rs [riscv64] (lunar-proposed/universe) [0.20.0-1] (no packageset) | 00:29 | |
| -queuebot:#ubuntu-release- New binary: libdfu-ahp [riscv64] (lunar-proposed/universe) [1.0~git20221215.dd2df39-1] (no packageset) | 00:33 | |
| === chris15 is now known as chris14 | ||
| === chris14_ is now known as chris14 | ||
| === chris15 is now known as chris14 | ||
| -queuebot:#ubuntu-release- Unapproved: autopkgtest (kinetic-proposed/main) [5.25ubuntu1 => 5.25ubuntu1.1] (core) | 01:02 | |
| -queuebot:#ubuntu-release- Unapproved: rejected autopkgtest [source] (kinetic-proposed) [5.25ubuntu1.1] | 01:08 | |
| === chris14_ is now known as chris14 | ||
| -queuebot:#ubuntu-release- Packageset: 30 entries have been added or removed | 06:48 | |
| -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [sync] (jammy-proposed) [2.06-2ubuntu14] | 07:42 | |
| -queuebot:#ubuntu-release- Unapproved: libreoffice (kinetic-proposed/main) [1:7.4.3-0ubuntu0.22.10.1 => 1:7.4.4-0ubuntu0.22.10.1] (ubuntu-desktop) | 09:18 | |
| -queuebot:#ubuntu-release- Unapproved: libinput (jammy-proposed/main) [1.20.0-1ubuntu0.1 => 1.20.0-1ubuntu0.2] (desktop-core, i386-whitelist) | 09:46 | |
| -queuebot:#ubuntu-release- Unapproved: libinput (kinetic-proposed/main) [1.21.0-1 => 1.21.0-1ubuntu1] (desktop-core, i386-whitelist) | 09:46 | |
| tjaalton | sil2100: llvm has built, time to recover mesa backport from the jammy rejected list :) | 10:53 |
|---|---|---|
| -queuebot:#ubuntu-release- New binary: php-maxminddb [amd64] (lunar-proposed/none) [1.11.0-4] (no packageset) | 11:21 | |
| -queuebot:#ubuntu-release- New binary: php-mcrypt [s390x] (lunar-proposed/none) [3:1.0.5-4] (no packageset) | 11:21 | |
| -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [ppc64el] (lunar-proposed/none) [3.2.18-2] (no packageset) | 11:21 | |
| -queuebot:#ubuntu-release- New binary: php-mcrypt [amd64] (lunar-proposed/none) [3:1.0.5-4] (no packageset) | 11:21 | |
| -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [amd64] (lunar-proposed/none) [3.2.18-2] (no packageset) | 11:21 | |
| -queuebot:#ubuntu-release- New binary: php-maxminddb [s390x] (lunar-proposed/none) [1.11.0-4] (no packageset) | 11:22 | |
| -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [s390x] (lunar-proposed/none) [3.2.18-2] (no packageset) | 11:22 | |
| -queuebot:#ubuntu-release- New binary: php-mcrypt [ppc64el] (lunar-proposed/none) [3:1.0.5-4] (no packageset) | 11:22 | |
| -queuebot:#ubuntu-release- New binary: php-maxminddb [ppc64el] (lunar-proposed/none) [1.11.0-4] (no packageset) | 11:23 | |
| -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [armhf] (lunar-proposed/none) [3.2.18-2] (no packageset) | 11:23 | |
| -queuebot:#ubuntu-release- New binary: php-mcrypt [armhf] (lunar-proposed/none) [3:1.0.5-4] (no packageset) | 11:23 | |
| -queuebot:#ubuntu-release- New binary: php-maxminddb [arm64] (lunar-proposed/none) [1.11.0-4] (no packageset) | 11:24 | |
| -queuebot:#ubuntu-release- New: accepted libdfu-ahp [amd64] (lunar-proposed) [1.0~git20221215.dd2df39-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted libdfu-ahp [armhf] (lunar-proposed) [1.0~git20221215.dd2df39-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted libdfu-ahp [riscv64] (lunar-proposed) [1.0~git20221215.dd2df39-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted numba [amd64] (lunar-proposed) [0.56.4+dfsg-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted numba [armhf] (lunar-proposed) [0.56.4+dfsg-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted numba [s390x] (lunar-proposed) [0.56.4+dfsg-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted php-maxminddb [arm64] (lunar-proposed) [1.11.0-4] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted php-maxminddb [s390x] (lunar-proposed) [1.11.0-4] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted php-mcrypt [armhf] (lunar-proposed) [3:1.0.5-4] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted php-mcrypt [s390x] (lunar-proposed) [3:1.0.5-4] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted libdfu-ahp [arm64] (lunar-proposed) [1.0~git20221215.dd2df39-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted libdfu-ahp [s390x] (lunar-proposed) [1.0~git20221215.dd2df39-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted numba [ppc64el] (lunar-proposed) [0.56.4+dfsg-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted php-maxminddb [ppc64el] (lunar-proposed) [1.11.0-4] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted php-mcrypt [ppc64el] (lunar-proposed) [3:1.0.5-4] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [armhf] (lunar-proposed) [3.2.18-2] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [s390x] (lunar-proposed) [3.2.18-2] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [arm64] (lunar-proposed) [0.20.0-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [ppc64el] (lunar-proposed) [0.20.0-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [s390x] (lunar-proposed) [0.20.0-1] | 11:28 | |
| -queuebot:#ubuntu-release- New: accepted libdfu-ahp [ppc64el] (lunar-proposed) [1.0~git20221215.dd2df39-1] | 11:29 | |
| -queuebot:#ubuntu-release- New: accepted php-maxminddb [amd64] (lunar-proposed) [1.11.0-4] | 11:29 | |
| -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [amd64] (lunar-proposed) [3.2.18-2] | 11:29 | |
| -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [amd64] (lunar-proposed) [0.20.0-1] | 11:29 | |
| -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [riscv64] (lunar-proposed) [0.20.0-1] | 11:29 | |
| -queuebot:#ubuntu-release- New: accepted numba [arm64] (lunar-proposed) [0.56.4+dfsg-1] | 11:29 | |
| -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [ppc64el] (lunar-proposed) [3.2.18-2] | 11:29 | |
| -queuebot:#ubuntu-release- New: accepted php-mcrypt [amd64] (lunar-proposed) [3:1.0.5-4] | 11:29 | |
| -queuebot:#ubuntu-release- New: accepted rust-shadow-rs [armhf] (lunar-proposed) [0.20.0-1] | 11:29 | |
| -queuebot:#ubuntu-release- New binary: rust-clap-derive-3 [arm64] (lunar-proposed/none) [3.2.18-2] (no packageset) | 11:32 | |
| -queuebot:#ubuntu-release- New binary: php-maxminddb [armhf] (lunar-proposed/none) [1.11.0-4] (no packageset) | 11:34 | |
| -queuebot:#ubuntu-release- New binary: php-mcrypt [arm64] (lunar-proposed/none) [3:1.0.5-4] (no packageset) | 11:34 | |
| schopin | athos: sorry, my week has been unusually meeting-intensive so far, I haven't been pulling my +1 weight. I'm currently looking into nipype (needs a patch for new numpy) and will then move onto matplotlib. | 11:38 |
| ricotz | sil2100, hello :), it would great if you have time to look at this libreoffice SRU for kinetic - https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2001911 | 12:13 |
| -ubottu:#ubuntu-release- Launchpad bug 2001911 in libreoffice (Ubuntu Kinetic) "[SRU] libreoffice 7.4.4 for kinetic" [High, In Progress] | 12:13 | |
| sil2100 | ricotz: o/ | 12:44 |
| ricotz | sil2100, o/ | 12:48 |
| sil2100 | ricotz: while we're at it, I see the previous libreoffice SRU in -propsoed had some discussion re: the s390x test regressions. Will this upload suffer from the same problems? | 12:48 |
| ricotz | this is basically superseding https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1997333 | 12:48 |
| -ubottu:#ubuntu-release- Launchpad bug 1997333 in libreoffice (Ubuntu Kinetic) "[SRU] libreoffice 7.4.3 for kinetic" [High, Fix Committed] | 12:48 | |
| ricotz | sil2100, I have added a patch to skip those on s390x, and the test-run of autopkgtest on s390x succeeded | 12:49 |
| sil2100 | Excellent | 12:50 |
| sil2100 | ricotz: by skipping you mean the single tests that were failing, not the whole suite, right? | 12:50 |
| ricotz | sil2100, https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=wip/kinetic-7.4&id=2fc53a0c2d178b7193d2f069ea140d1c3fb8e088 | 12:51 |
| -ubottu:#ubuntu-release- Commit 2fc53a0 in ~libreoffice/ubuntu/+source/libreoffice "autopkgtests: Skip two failing tests on s390x" | 12:51 | |
| sil2100 | Awesome | 13:01 |
| -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (kinetic-proposed) [1:7.4.4-0ubuntu0.22.10.1] | 13:03 | |
| ricotz | thank you \o/ | 13:06 |
| === esembee_ is now known as esembee | ||
| athos | schopin: nice. some packages failed w/ a weird error (seems to be a autopkgtest infra error). I retriggered some of those and am looking for the netx package to work on | 13:42 |
| tjaalton | sil2100: dunno if the bot spam scrolled my comment out of sight, but jammy-proposed is now clear for mesa, it's on the rejected list if it can be resurrected from there, or I'll upload again | 14:00 |
| sil2100 | \o/ | 14:00 |
| sil2100 | Looking | 14:00 |
| sil2100 | tjaalton: is that both kinetic and jammy, or just jammy? | 14:00 |
| tjaalton | just jammy, kinetic has it already | 14:01 |
| sil2100 | tjaalton: 22.0.5-0ubuntu0.4, correct? | 14:02 |
| tjaalton | no 22.2.x | 14:03 |
| tjaalton | 22.2.5-0ubuntu0.1~22.04.1 | 14:05 |
| tjaalton | sil2100: did you find it?-) | 14:31 |
| athos | schopin: I will handle foolscap now and will move to dovecot then :) | 14:32 |
| schopin | Great, thanks! | 14:32 |
| tjaalton | sil2100: btw, there's this bug for linux-firmware which concerns the point-release as well: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1999406 | 14:52 |
| -ubottu:#ubuntu-release- Launchpad bug 1999406 in linux-firmware (Ubuntu Lunar) "Update firmware for hwe/oem kernel migrations" [High, In Progress] | 14:52 | |
| sil2100 | tjaalton: hmm, I'm confused by this here: https://launchpad.net/ubuntu/jammy/+queue?queue_state=4&queue_text=mesa | 14:53 |
| tjaalton | we discussed this a bit in Prague, and this approach is the middle-ground for updating the firmware that we know are needed for the newer kernels. the other option was to just backport it all as-is | 14:53 |
| tjaalton | sil2100: yes, there were bogus uploads, forget about 0.4.. we decided to remove directx-headers instead of patching mesa | 14:53 |
| sil2100 | tjaalton: so I should take the ~22.04.1, right? Why were there 3 other uploads rejected afterwards? ANd the ~22.04.1 has a rejection message of "Rejected in favor of 22.0.5-0ubuntu0.3" | 14:53 |
| tjaalton | to fix the build | 14:53 |
| sil2100 | Ah, ok! | 14:54 |
| tjaalton | yeah that was because the review tooling was confused aiui | 14:54 |
| tjaalton | it only saw the oldest upload or something | 14:55 |
| sil2100 | Reviewing now o/ | 14:55 |
| tjaalton | excellent | 14:55 |
| -queuebot:#ubuntu-release- New binary: python-epimodels [amd64] (lunar-proposed/universe) [0.4.0-1] (no packageset) | 17:22 | |
| ricotz | vorlon, hi, I will upload the next libreoffice 7.5 upstream release candidate for lunar this week, I noted the amd64 autopkgtest failures for now, but I won't try to fix them with that upload yet | 17:25 |
| vorlon | ricotz: if you're not fixing the autopkgtest failures, what possible point is there to uploading? | 17:26 |
| vorlon | it's just going to waste a bunch of resources and then get stuck in -proposed | 17:26 |
| ricotz | vorlon, as I said this is the next release candidate including a lot of changes | 17:27 |
| vorlon | ricotz: but why should it be in the archive instead of in a ppa? | 17:27 |
| ricotz | vorlon, and yes, I don't want to waste resources even with PPA build | 17:28 |
| vorlon | fyi folks, per discussion w/ ginggs and bdmurray we've dumped everything in the s390x 'huge' autopkgtest queue and are requeuing based on the versions that proposed-migration is *currently* waiting for. This e.g. gets rid of tests that were triggered for the /previous/ version of perl whose results we no longer care about | 17:28 |
| vorlon | the requeuing is not the speediest, however :) | 17:29 |
| ricotz | great :) | 17:29 |
| vorlon | (at present: 4700 of 10k tests re-queued) | 17:30 |
| -queuebot:#ubuntu-release- New: accepted php-maxminddb [armhf] (lunar-proposed) [1.11.0-4] | 17:31 | |
| -queuebot:#ubuntu-release- New: accepted python-epimodels [amd64] (lunar-proposed) [0.4.0-1] | 17:31 | |
| -queuebot:#ubuntu-release- New: accepted php-mcrypt [arm64] (lunar-proposed) [3:1.0.5-4] | 17:31 | |
| -queuebot:#ubuntu-release- New: accepted rust-clap-derive-3 [arm64] (lunar-proposed) [3.2.18-2] | 17:31 | |
| ricotz | vorlon, do you know if the "pkgstripfiles dead-lock" has got some investigation in the past? I am seeing this currently with libreoffice/riscv64 https://launchpad.net/ubuntu/+source/libreoffice/1:7.5.0~rc1-0ubuntu2/+build/25425185 | 17:34 |
| vorlon | ricotz: why do you think it's a deadlock? | 17:35 |
| vorlon | I don't remember why pkgstripfiles can't be run in parallel across different binary packages, but given that it takes a while to run it for even *one* package, it's probably sensible regardless. I've never seen it deadlock, it's just slow on large packages | 17:36 |
| ricotz | vorlon, I had a small talk with cj_watson some time ago, bascially it can finished after some days, but usually the build just dies before that | 17:36 |
| vorlon | ok, I don't know anything about that | 17:36 |
| ricotz | this is independent from the arch, I saw this happening on amd64 too | 17:37 |
| ricotz | (without leaving a build log) | 17:38 |
| vorlon | pkgstripfiles timing out on riscv64 for libreoffice seems plausible to me without being a deadlock | 17:38 |
| ricotz | I see, is it possible to skip this for specific packages/archs? | 17:39 |
| vorlon | yes | 17:39 |
| vorlon | the consequence will be not having dbgsym packages for that package/arch | 17:39 |
| vorlon | let me check the syntax for skipping it | 17:40 |
| ricotz | hmm, oh, isn't that archive build specific | 17:41 |
| ricotz | sorry, I assumed this is the "pkgmangler" which strips translations and optimizes image files | 17:42 |
| vorlon | oh, actually I don't even see in the code that this is the bit that handles dbgsym files | 17:43 |
| vorlon | anyway, are there a lot of .png files in the libreoffice tree? that's usually the expensive bit | 17:43 |
| vorlon | which NO_PNG_PKG_MANGLE=1 will avoid | 17:43 |
| ricotz | yes, the help files contain a lot of images, and a lot of svg files | 17:44 |
| vorlon | this is all in the pkgbinarymangler package in the archive if you want to have a look around | 17:44 |
| ricotz | thanks for the gint | 17:44 |
| ricotz | *hint | 17:44 |
| vorlon | right - optimizing the png files is expensive | 17:44 |
| vorlon | ok, s390x huge queue refilled. https://autopkgtest.ubuntu.com/running will take a bit yet to catch up | 17:50 |
| cjwatson | vorlon,ricotz: I have to say, https://paste.ubuntu.com/p/ZpxxZBZdn7/ looks a bit like a deadlock to me | 18:14 |
| ricotz | cjwatson, any chance to investigate it with that build? | 18:16 |
| ricotz | I assume skipping the png optimization only would not help then | 18:16 |
| cjwatson | I'm happy for people to suggest things I might check | 18:16 |
| cjwatson | Because I do see suspicious things like this on the build farm from time to time, and cleaning them up manually is tedious | 18:17 |
| cjwatson | https://paste.ubuntu.com/p/HZHspvVw35/ - current lock file contents | 18:21 |
| ricotz | cjwatson, looks like a similar case https://launchpad.net/ubuntu/+source/libreoffice/1:7.4.4-0ubuntu0.22.10.1/+build/25478191 | 18:27 |
| ricotz | but probably still alive | 18:27 |
| cjwatson | Possible clue, further back in the build log I see "gzip: stdin: unexpected end of file" and "tar: Unexpected EOF in archive" and then dpkg-deb exiting non-zero | 18:31 |
| cjwatson | I wonder if it's bad error handling in pkgbinarymangler, so if it hits ENOSPC or something then it never recovers and spins forever | 18:32 |
| cjwatson | The "waiting for lock" stuff starts right after those errors | 18:32 |
| cjwatson | I don't have the same tools available to me to poke about inside ppc64el builds | 18:33 |
| cjwatson | (Ideally I wouldn't even for riscv64 builds, but with the way things are set up right now, I do) | 18:33 |
| vorlon | cjwatson: thanks for the added context. ENOSPC, what are the chances of that happening intermittently due to parallel builds? Also, pkgstripfiles itself doesn't look like it should be disk-intensive... | 18:36 |
| cjwatson | https://paste.ubuntu.com/p/9yJ28Q4xyN/ | 18:38 |
| cjwatson | intermittent ENOSPC is certainly a possibility. Right now this particular builder has 47G free, but that might not mean much if there are a lot of temporaries | 18:39 |
| cjwatson | It's not unambiguously ENOSPC, that just seems like a good guess for this particular kind of failure | 18:39 |
| cjwatson | I think pkgstriptranslations is the thing that's actually failing, and that might use non-trivial space maybe? | 18:40 |
| cjwatson | But maybe somebody can sit down and think hard about the locking arrangements here given that context | 18:40 |
| cjwatson | Or actually maybe it's dpkg-deb --build that's failing | 18:41 |
| vorlon | pkgstriptranslations also just moves .po or .mo files around, doesn't it? would surprise me if that used a lot of disk either | 18:41 |
| cjwatson | That's kind of what the log suggests | 18:41 |
| vorlon | ah | 18:41 |
| vorlon | *that* would use more disk :) | 18:41 |
| cjwatson | https://paste.ubuntu.com/p/F6G4TQJnxv/ is perhaps also relevant information since that indicates which dpkg-deb runs actually succeeded | 18:49 |
| cjwatson | aaaaalso I think there might be a fundamental logical incompatibility between pkgbinarymangler's locking strategy and debhelper's parallelism, although I haven't completely thought it through | 18:53 |
| cjwatson | debhelper's dh_builddeb calls on_items_in_parallel, which divides up the list of packages to operate on into batches and calls a provided sub with each batch | 18:54 |
| cjwatson | The provided sub walks through the batch in order and calls dpkg-deb --build on each item | 18:54 |
| cjwatson | Meanwhile, pkgbinarymangler's dh_builddeb diversion writes out the list of packages to a file | 18:55 |
| cjwatson | (the lock file) | 18:55 |
| cjwatson | pkgstripfiles then only processes a package once it finds it on the first line of the lock file, and deletes it from the lock file once it's done | 18:55 |
| cjwatson | As I say I haven't completely thought this through, but that strategy feels pretty fragile. If there's any disagreement at all between the order that debhelper works in and the order that pkgstripfiles works in, it seems as though it will deadlock, since there's no completely obvious guarantee that a package that's actually having dpkg-deb --build called on it - and is not e.g. waiting for an | 18:57 |
| cjwatson | earlier package in the batch to finish - will ever reach the top of the lock file | 18:57 |
| cjwatson | That said, the enforcing of ordering is probably deliberate due to https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/893826 | 18:58 |
| -ubottu:#ubuntu-release- Launchpad bug 893826 in qt4-x11 (Ubuntu Precise) "symlinked docs are different between architectures, depending on dpkg-deb package order" [High, Fix Released] | 18:58 | |
| cjwatson | So maybe it does make sense, but it hurts my brain | 18:58 |
| cjwatson | I can't see how pkgbinarymangler's dh_builddeb would have got as far as calling dpkg-deb --build on the main libreoffice package without first calling pkgstripfiles on it; but there's an error message for dpkg-deb --build on that package, and it's still in the pkgstripfiles lock file | 19:04 |
| cjwatson | Same goes for several other binary packages there | 19:05 |
| cjwatson | Can anyone see anything I'm missing there? I probably need to eat | 19:06 |
| Eickmeyer | ubuntu-archive: Does anybody have a spare cycle to review edubuntu-installer in NEW? It's not a system installer, it's more akin to ubuntustudio-installer in that it's a metapackage installer. | 19:16 |
| vorlon | hopefully not too much like ubuntustudio-installer which afaik has been out of compliance with TB guidance around third-party repositories for years. | 19:36 |
| Eickmeyer | vorlon: No third-party repo stuff. | 19:36 |
| vorlon | ok, I'll try to get to it later this afternoon (but dotnet7 has been awaiting bootstrapping so takes priority) | 19:37 |
| Eickmeyer | vorlon: Understandable. :) | 19:38 |
| vorlon | xypron, xnox: linux-allwinner-5.17 and linux-starfive-5.17 FTBFS in lunar and appear to be superseded by the non-5.17 kernel flavors, should these be removed from lunar? | 19:41 |
| arraybolt3 | vorlon: (re: out of compliacne with TB guidance around third-party repositories) Partially out of curiosity, and partially to further my own knowledge, is the TB guidance you mention documented anywhere public, and if so, could I have a link to it? (If you're too busy now, no problem, I'll try and find it.) | 19:58 |
| vorlon | arraybolt3: well it was in TB minutes at least, so "public but difficult to discover" probably | 20:02 |
| vorlon | cpaelzer_: I'm still unhappy about the tabular output formatting, but it's good for dopamine hits from being able to remove packages without having to think deepyl | 20:16 |
| vorlon | *deeply | 20:16 |
| xypron | @vorlon: The generic kernel does not support the Nezha D1, Lichee RV, VisionFive. esmil: has rebasing the -allwinner and -starfive flavors on his agenda. | 20:33 |
| vorlon | xypron: there are 5.19-based linux-allwinner and linux-starfive source packages in lunar that don't fail to build | 20:38 |
| vorlon | so isn't 5.17 obsolete for lunar? | 20:38 |
| xypron | vorlon: then 5.17 should be obsolete. | 20:39 |
| -queuebot:#ubuntu-release- Unapproved: autopkgtest (kinetic-proposed/main) [5.25ubuntu1 => 5.25ubuntu1.1] (core) | 20:57 | |
| bdmurray | The amd64 queue experienced a processing hiccup but should be better now | 21:50 |
| -queuebot:#ubuntu-release- New binary: tideways [amd64] (lunar-proposed/universe) [5.0.4-15] (no packageset) | 23:21 | |
| -queuebot:#ubuntu-release- New binary: libahp-gt [amd64] (lunar-proposed/none) [1.6.0-1] (no packageset) | 23:22 | |
| -queuebot:#ubuntu-release- New binary: tideways [ppc64el] (lunar-proposed/universe) [5.0.4-15] (no packageset) | 23:22 | |
| -queuebot:#ubuntu-release- New binary: libahp-gt [ppc64el] (lunar-proposed/none) [1.6.0-1] (no packageset) | 23:23 | |
| -queuebot:#ubuntu-release- New binary: libahp-gt [arm64] (lunar-proposed/none) [1.6.0-1] (no packageset) | 23:24 | |
| -queuebot:#ubuntu-release- New binary: libahp-gt [armhf] (lunar-proposed/none) [1.6.0-1] (no packageset) | 23:24 | |
| -queuebot:#ubuntu-release- New binary: tideways [armhf] (lunar-proposed/universe) [5.0.4-15] (no packageset) | 23:24 | |
| -queuebot:#ubuntu-release- New binary: tideways [arm64] (lunar-proposed/universe) [5.0.4-15] (no packageset) | 23:25 | |
| -queuebot:#ubuntu-release- New binary: libahp-gt [s390x] (lunar-proposed/universe) [1.6.0-1] (no packageset) | 23:31 | |
| -queuebot:#ubuntu-release- New binary: tideways [s390x] (lunar-proposed/universe) [5.0.4-15] (no packageset) | 23:34 | |
| -queuebot:#ubuntu-release- New: accepted libahp-gt [armhf] (lunar-proposed) [1.6.0-1] | 23:54 | |
| -queuebot:#ubuntu-release- New: accepted tideways [arm64] (lunar-proposed) [5.0.4-15] | 23:54 | |
| -queuebot:#ubuntu-release- New: accepted tideways [s390x] (lunar-proposed) [5.0.4-15] | 23:54 | |
| -queuebot:#ubuntu-release- New: accepted libahp-gt [s390x] (lunar-proposed) [1.6.0-1] | 23:54 | |
| -queuebot:#ubuntu-release- New: accepted tideways [armhf] (lunar-proposed) [5.0.4-15] | 23:54 | |
| -queuebot:#ubuntu-release- New: accepted libahp-gt [amd64] (lunar-proposed) [1.6.0-1] | 23:55 | |
| -queuebot:#ubuntu-release- New: accepted libahp-gt [ppc64el] (lunar-proposed) [1.6.0-1] | 23:55 | |
| -queuebot:#ubuntu-release- New: accepted tideways [ppc64el] (lunar-proposed) [5.0.4-15] | 23:55 | |
| -queuebot:#ubuntu-release- New: accepted libahp-gt [arm64] (lunar-proposed) [1.6.0-1] | 23:55 | |
| -queuebot:#ubuntu-release- New: accepted tideways [amd64] (lunar-proposed) [5.0.4-15] | 23:55 | |
| -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [sync] (kinetic-proposed) [2.06-2ubuntu14] | 23:58 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!