[01:49] <vorlon> triggering first round of rebuilds for libqt6core6t64
[02:10] <vorlon> LocutusOfBorg: you mention fixing llvms... looks like qt6-tools blocks on libclang-15-dev
[02:11] <vorlon> LocutusOfBorg: anything I can do to help, or do you have it in hand?
[02:41] <vorlon> ah the openldap armhf test failure involves a time_t in a format string, because of course it does
[03:44] <RikMills> vorlon: do you know if we are near at all to having qt5 qtbase build on armhf?
[04:29] <arraybolt3> RikMills: 15:25 <vorlon> seb128: heh I just answered that question in parallel.  I'm currently estimating a week before we start getting the main clusters (freedesktop; qt) in a position to migrate.  But there's a lot of risk in that estimate, because we don't have all the bootstrap loops broken yet
[05:50] <vorlon> RikMills: qtbase is built on armhf
[05:51] <RikMills> vorlon: not according to https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.15.12+dfsg-3ubuntu3
[05:51] <RikMills> do you mean qt6?
[05:51] <vorlon> RikMills: you're reading it wrong
[05:51] <vorlon> there is a successful build and a failed build
[05:52] <RikMills> vorlon: that link is the lastes in proposed it seems
[05:52] <RikMills> *latest
[05:54] <RikMills> vorlon: do you mean a build in the bootstrap ppa?
[05:54] <vorlon> RikMills: no, look at that page you just linked to. armhf is listed twice
[05:54] <RikMills> ohhhhhh
[05:54] <RikMills> nevers seen that before
[05:55] <vorlon> one source package, two build records because it was buit in the bootstrap ppa and copied back over
[05:55] <RikMills> vorlon: right. didn't know that was possible. thanks!
[07:41] <LocutusOfBorg> vorlon, it was waiting lp to pick it up
[07:42] <vorlon> LocutusOfBorg: on llvm-15? because https://launchpad.net/ubuntu/+source/llvm-toolchain-15/1:15.0.7-13 shows a build failure on armhf
[07:42] <LocutusOfBorg> Source llvm-toolchain-15 -> noble/Proposed: current version 1:15.0.7-13, new version 1:15.0.7-14
[07:42] <LocutusOfBorg> Downloading llvm-toolchain-15_15.0.7-14.dsc from deb.debian.org (0.008 MiB)
[07:42] <LocutusOfBorg> I uploaded 10h ago on Debian
[07:42] <vorlon> ah , for lp to import the new Debian version so it could sync, ok
[07:44] <LocutusOfBorg> 14 15 16 17 18 should be ok in 12h or so
[07:44] <vorlon> perfect, thanks
[07:45] <vorlon> (also just found out we're waiting on 18 for doxygen)
[07:45] <LocutusOfBorg> hopefully
[07:45] <LocutusOfBorg> 18 is already mostly built=?
[07:45] <LocutusOfBorg> Noble: [FULLYBUILT] amd64 [BUILDING] arm64 [FULLYBUILT] armhf [FULLYBUILT] i386 [FULLYBUILT] ppc64el [BUILDING] riscv64 [FULLYBUILT] s390x
[07:46] <vorlon> LocutusOfBorg: for https://launchpad.net/ubuntu/+source/llvm-toolchain-18/1:18.1.0-1ubuntu2 ?
[07:46] <vorlon> if that's confirmed good I can upload doxygen now
[07:47] <vorlon> or would building with the previous version on arm64 and riscv64 cause misbuilds...
[07:53] <LocutusOfBorg> if previous you mean https://launchpad.net/ubuntu/+source/llvm-toolchain-18/1:18.1.0-1ubuntu1?
[07:53] <LocutusOfBorg> it was a run with no tests, but the code should be good
[07:53] <LocutusOfBorg> the ubuntu2 has spirv support
[08:02] <vorlon> LocutusOfBorg: ok I have no idea what the impact would be of building doxygen with an llvm without spirv support
[08:59] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (jammy-backports) [307-1~bpo22.04.1]
[08:59] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (jammy-backports) [311-1~bpo22.04.1]
[08:59] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-podman [source] (jammy-backports) [84-1~bpo22.04.1]
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (mantic-backports) [307-1~bpo23.10.1]
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (mantic-backports) [311-1~bpo23.10.1]
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-podman [source] (mantic-backports) [84-1~bpo23.10.1]
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted rpki-client [source] (jammy-backports) [9.0-1~bpo22.04.1]
[09:28] <LocutusOfBorg> vorlon, I would say none
[09:29] <LocutusOfBorg> (in any case spirv support was added just in that upload, we usually don't have spirv until spirv is available and built with older llvm, then we rebuild with it
[09:29] <LocutusOfBorg> e.g. in Debian llvm is still without it
[09:30] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (jammy-backports) [4:7.6.5-0ubuntu0.23.10.1~bpo22.04.1]
[09:34] <LocutusOfBorg> ok so now I need just to do ubuntu-build --batch --retry
[09:34] <LocutusOfBorg> nice indeed
[09:39] <LocutusOfBorg> I merged and updated changelog (with only a subset of your changes!)
[10:03] -queuebot:#ubuntu-release- New binary: pipewire [i386] (noble-proposed/main) [1.0.3-1.1ubuntu1] (desktop-core, i386-whitelist)
[10:05] -queuebot:#ubuntu-release- New binary: pipewire [amd64] (noble-proposed/main) [1.0.3-1.1ubuntu1] (desktop-core, i386-whitelist)
[10:06] -queuebot:#ubuntu-release- New binary: pipewire [arm64] (noble-proposed/main) [1.0.3-1.1ubuntu1] (desktop-core, i386-whitelist)
[10:08] -queuebot:#ubuntu-release- New binary: pipewire [ppc64el] (noble-proposed/main) [1.0.3-1.1ubuntu1] (desktop-core, i386-whitelist)
[10:13] -queuebot:#ubuntu-release- New binary: pipewire [s390x] (noble-proposed/main) [1.0.3-1.1ubuntu1] (desktop-core, i386-whitelist)
[10:27] -queuebot:#ubuntu-release- New: accepted pipewire [amd64] (noble-proposed) [1.0.3-1.1ubuntu1]
[10:27] -queuebot:#ubuntu-release- New: accepted pipewire [i386] (noble-proposed) [1.0.3-1.1ubuntu1]
[10:27] -queuebot:#ubuntu-release- New: accepted pipewire [s390x] (noble-proposed) [1.0.3-1.1ubuntu1]
[10:27] -queuebot:#ubuntu-release- New: accepted pipewire [arm64] (noble-proposed) [1.0.3-1.1ubuntu1]
[10:27] -queuebot:#ubuntu-release- New: accepted pipewire [ppc64el] (noble-proposed) [1.0.3-1.1ubuntu1]
[10:32] -queuebot:#ubuntu-release- Unapproved: php8.1 (jammy-proposed/main) [8.1.2-1ubuntu2.14 => 8.1.2-1ubuntu2.15] (i386-whitelist, ubuntu-server)
[11:49] -queuebot:#ubuntu-release- New: accepted libdfx [source] (noble-proposed) [2023.2-0ubuntu3]
[11:52] -queuebot:#ubuntu-release- New binary: libdfx [amd64] (noble-proposed/none) [2023.2-0ubuntu3] (no packageset)
[12:15] -queuebot:#ubuntu-release- New binary: libdfx [ppc64el] (noble-proposed/none) [2023.2-0ubuntu3] (no packageset)
[12:20] -queuebot:#ubuntu-release- New binary: libdfx [s390x] (noble-proposed/none) [2023.2-0ubuntu3] (no packageset)
[12:34] <doko> apw, xnox: we really need a linux build, making linux-tools-6.8.0-11 installable again
[12:34] <doko> on armhf
[12:35] <apw> arighi, ^^
[13:11] <arighi> doko, problem is that the build time is relly slow... we have a new build in progress in the c-k-t/bootstrap ppa (6.8.0-17.17)
[13:13] <doko> arighi: URL?
[13:13] <doko> arighi: is that PPA building against -proposed?
[13:16] <doko> arighi, apw: you have to ask people to bump scores. now done
[13:17] <arighi> doko, https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+sourcepub/15848070/+listing-archive-extra
[13:18] <arighi> doko, and yes, it's building against -proposed
[13:24] <doko> arighi: wtf, why do you have a b-d on a shared library? clang-17, libclang1-17  that cannot work
[13:24] <arighi> doko, we need clang-17 to enable Rust-for-linux
[13:25] <arighi> why it cannot work to depend on libclang?
[13:25] <doko> sure, but you don't need libclang1-17
[13:25] <doko> because the library was renamed
[13:26] <arighi> hm... we can try to remove the dep on libclang-17, but I'm not sure if rust is happy
[13:26] <doko> The following packages have unmet dependencies:
[13:26] <doko>  libllvm17t64 : Breaks: libllvm17 (< 1:17.0.6-9) but 1:17.0.6-5build1 is to be installed
[13:26] <doko> rust will be happy
[13:26] <arighi> ok I can remove the libclang dep
[13:26] <doko> arighi: do you also have that one as a dependency?
[13:27] <arighi> nope, we only have the dep on libclang
[13:29] <doko> just drop it, clang-17 depends on the correct library
[13:30] <arighi> alright so to recap, I'll keep the dep on clang-17 and drop libclang-17
[13:30] <doko> correct
[13:31] <doko> also note, the clang-17 package currently is uninstallable on riscv64, failing to build due to whatever instability, so that will also take a little bit longer
[13:31] -queuebot:#ubuntu-release- New binary: libdfx [armhf] (noble-proposed/universe) [2023.2-0ubuntu3] (no packageset)
[13:33] -queuebot:#ubuntu-release- New: accepted libdfx [amd64] (noble-proposed) [2023.2-0ubuntu3]
[13:33] -queuebot:#ubuntu-release- New: accepted libdfx [ppc64el] (noble-proposed) [2023.2-0ubuntu3]
[13:33] -queuebot:#ubuntu-release- New: accepted libdfx [armhf] (noble-proposed) [2023.2-0ubuntu3]
[13:33] -queuebot:#ubuntu-release- New: accepted libdfx [s390x] (noble-proposed) [2023.2-0ubuntu3]
[13:33] <arighi> doko, hm.. so we are not able to build the kernel because of that, we need to do some tricks or exclude riscv64
[13:34] <arighi> is it the same on armhf?
[13:34] <doko> arighi: no, just upload. the kernel will be buildable on riscv64, once llvm-toolchain-17 is built.
[13:35] <arighi> doko, ack
[13:35] <doko> the armhf build should work without the libclang1-17 b-d
[13:35] -queuebot:#ubuntu-release- New binary: libdfx [arm64] (noble-proposed/universe) [2023.2-0ubuntu3] (no packageset)
[13:36] -queuebot:#ubuntu-release- New: accepted libdfx [arm64] (noble-proposed) [2023.2-0ubuntu3]
[13:42] -queuebot:#ubuntu-release- Unapproved: pulseaudio (jammy-proposed/main) [1:15.99.1+dfsg1-1ubuntu2.1 => 1:15.99.1+dfsg1-1ubuntu2.2] (core, i386-whitelist)
[13:42] -queuebot:#ubuntu-release- Unapproved: pulseaudio (mantic-proposed/main) [1:16.1+dfsg1-2ubuntu4 => 1:16.1+dfsg1-2ubuntu4.1] (core, i386-whitelist)
[13:56] <arighi> doko, new kernel without the libclang b-d uploaded to the bootstrap ppa: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+sourcepub/15851940/+listing-archive-extra
[13:57] <doko> arighi: ta, at least armhf is building now
[14:00] -queuebot:#ubuntu-release- Unapproved: hexchat (mantic-proposed/universe) [2.16.1-1build2 => 2.16.1-1ubuntu0.1] (xubuntu)
[14:06] -queuebot:#ubuntu-release- Unapproved: hexchat (jammy-proposed/universe) [2.16.0-4build1 => 2.16.0-4ubuntu0.1] (xubuntu)
[15:16] -queuebot:#ubuntu-release- New: accepted freerdp3 [source] (noble-proposed) [3.3.0+dfsg1-0ubuntu1]
[15:20] -queuebot:#ubuntu-release- New binary: freerdp3 [amd64] (noble-proposed/none) [3.3.0+dfsg1-0ubuntu1] (no packageset)
[15:22] -queuebot:#ubuntu-release- New binary: freerdp3 [ppc64el] (noble-proposed/none) [3.3.0+dfsg1-0ubuntu1] (no packageset)
[15:22] -queuebot:#ubuntu-release- Unapproved: snapd (mantic-proposed/main) [2.60.4+23.10.1 => 2.61.3+23.10] (desktop-core, ubuntu-server)
[15:24] -queuebot:#ubuntu-release- New binary: freerdp3 [s390x] (noble-proposed/none) [3.3.0+dfsg1-0ubuntu1] (no packageset)
[15:24] -queuebot:#ubuntu-release- Unapproved: snapd (jammy-proposed/main) [2.58+22.04.1 => 2.61.3+22.04] (desktop-core, ubuntu-server)
[15:27] -queuebot:#ubuntu-release- Unapproved: snapd (focal-proposed/main) [2.58+20.04.1 => 2.61.3+20.04] (core)
[15:30] -queuebot:#ubuntu-release- New: accepted freerdp3 [amd64] (noble-proposed) [3.3.0+dfsg1-0ubuntu1]
[15:30] -queuebot:#ubuntu-release- New: accepted freerdp3 [s390x] (noble-proposed) [3.3.0+dfsg1-0ubuntu1]
[15:30] -queuebot:#ubuntu-release- New: accepted freerdp3 [ppc64el] (noble-proposed) [3.3.0+dfsg1-0ubuntu1]
[15:30] -queuebot:#ubuntu-release- New binary: freerdp3 [arm64] (noble-proposed/none) [3.3.0+dfsg1-0ubuntu1] (no packageset)
[15:31] -queuebot:#ubuntu-release- New: accepted freerdp3 [arm64] (noble-proposed) [3.3.0+dfsg1-0ubuntu1]
[15:51] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (mantic-proposed) [2.61.3+23.10]
[16:01] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (jammy-proposed) [2.61.3+22.04]
[16:20] -queuebot:#ubuntu-release- Unapproved: software-properties (xenial-proposed/main) [0.96.20.12 => 0.96.20.13] (desktop-core, ubuntu-server)
[16:59] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (focal-proposed) [2.61.3+20.04]
[19:41] <vorlon> bandali: hi, I see that you're on +1 maintenance this week, and wanted to give some guidance on priorities
[19:45] -queuebot:#ubuntu-release- New binary: libreoffice [amd64] (jammy-backports/main) [4:7.6.5-0ubuntu0.23.10.1~bpo22.04.1] (ubuntu-desktop)
[19:46] <vorlon> bandali: basically, the priority needs to be "getting t64 transition done".  So what that looks like is, starting chronologically from about 28Feb (currently '13 days old'), go through update_excuses and work out why those particular packages are not migrating; trigger no-change rebuilds as necessary, fix sources as necessary, get their build-deps built first if necessary, and if you find a
[19:46] <vorlon> build-dependency loop you can kick this to the Foundations Team to resolve
[19:53] <vorlon> and fwiw I just found the first package on the list was 'apophenia', which has been ftbfs in Ubuntu in a while but not in Debian.  I've ripped the package out of the release pocket peremptorily but left it in -proposed for now
[19:53] <vorlon> (no bug filed about the ftbfs; wild guess is that this is a mariadb vs mysql issue)
[19:55] -queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [amd64] (noble-proposed/universe) [1:19~++20240304085905+c7fdd8c11e54-1ubuntu2] (i386-whitelist)
[20:01] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [amd64] (noble-proposed) [1:19~++20240304085905+c7fdd8c11e54-1ubuntu2]
[20:03] <doko> The following packages have unmet dependencies:
[20:03] <doko>  libcom-err2 : Breaks: libcom-err2t64 (< 1.47.0-2.4~exp1ubuntu1)
[20:03] <doko> err, on arm64?
[20:05] <doko> dbungert, vorlon: ^^^ the reversion seems to be wrong
[20:05] <vorlon> it's correct to revert it
[20:05] <vorlon> because com-err2 does not have an ABI change
[20:06] <vorlon> but I just hit this in a build failure, haven't had a chance to look at why, currently in stand-up
[20:06] <vorlon> we do want to rebuild everything that has picked up a dependency on libcom-err2t64, to depend again on libcom-err2
[20:06] <vorlon> and libcom-err2 should Provides; libcom-err2t64 on all archs
[20:06] <doko> I think it should have a versioned Provides ...
[20:07] <doko> +Provides: libss2t64
[20:07] <doko> +Breaks: libss2t64 (<< ${source:Version})
[20:08] <doko> it doesn't know what is provided. Plus the breaks should be hard-coded
[20:08] <doko> the version in the breaks
[20:08] <dbungert> not sure but I can look in an hour.  if you know the correct answer doko feel free to take action.
[20:10] <bandali> hi vorlon, thanks for the tips, appreciate it
[20:10] <bandali> i'll keep them in mind and will try to organize my work accordingly
[20:12] <doko> dbungert: testing such changes before upload would be good ;p
[20:12] <doko> I'm trying something, can't make it worse
[20:13] -queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (jammy-backports) [4:7.6.5-0ubuntu0.23.10.1~bpo22.04.1]
[20:24] <vorlon> do we need to delete the existing package?
[20:26] <vorlon> I guess not; e2fsprogs doesn't have a self-build-dep so doesn't care
[20:30] <doko> so that's my guess: http://launchpadlibrarian.net/719023849/e2fsprogs_1.47.0-2.4~exp1ubuntu1_1.47.0-2.4~exp1ubuntu2.diff.gz
[20:30] <vorlon> 19 packages needing rebuilt for the revert; includes krb5 which I think is likely where things get hung up currently
[20:30] -queuebot:#ubuntu-release- New source: runc-app (mantic-proposed/primary) [1.1.12-0ubuntu2~23.10.1]
[20:31] <vorlon> going to go ahead and trigger those rebuilds, which can't hurt (either they build or they get bd-uninstallable failures)
[20:31] -queuebot:#ubuntu-release- New source: runc-app (focal-proposed/primary) [1.1.12-0ubuntu2~20.04.1]
[20:31] -queuebot:#ubuntu-release- New source: runc-app (jammy-proposed/primary) [1.1.12-0ubuntu2~22.04.1]
[20:51] <vorlon> doko: well, interestingly enough krb5 built fine on armhf switching back to libcom-err2, but has ftbfs on amd64 https://launchpad.net/ubuntu/+source/krb5/1.20.1-5.1build3
[20:52] <doko> I saw it. so the versioned provides is necessary, the change in the breaks harmless
[20:52]  * vorlon nods
[21:12] <doko> apw (arighi not here):
[21:12] <doko> # Compress kernel modules, on mantic+
[21:12] <doko> find debian/linux-image-6.8.0-18-generic-dbgsym -name '*.ko' -print0 | xargs -0 -n1 -P 4 -r zstd -19 --quiet --rm
[21:12] <doko> zstd: ../lib/compress/zstd_opt.c:722: ZSTD_insertBtAndGetAllMatches: Assertion `memcmp(match, ip, matchLength) == 0' failed.
[21:12] <doko> Caught SIGABRT signal, printing stack:
[21:12] <doko> xargs: zstd: terminated by signal 6
[21:12] <doko> make: *** [debian/rules.d/2-binary-arch.mk:567: binary-generic] Error 125
[21:12] <doko> so that fails for a different reason :-(
[21:12] <apw> doko, bah it is not our lifetime ... i also pinged him internally, so he is aware of the other issue.
[21:13] <apw> doko, will make sure he knows about this also.
[21:17] <doko> apw: looks like it's optional, so can be worked around by not compressing for a first build ...
[21:18] <apw> doko, i am sure we have been compressing for a very long time, so dunno why that has exploded today
[22:06] <arighi> doko, sorry I was offline and I may have missed some messages, about the zstd error (on the 6.8.0-18 armhf kernel build), I've seen it before, it happens when we're running out of disk space
[22:07] <arighi> and sometimes it can be solved by restarting the build... alternatively we could disable zstd compression, but it'd be quite bad to disable compression just because we don't have enough space on the armhf builders
[22:13] <doko> arighi: I figured out how to disable that. I'm building a package in one of my PPAs just to bootstrap bpfcc and bpftrace. but we really need a first build for the tools package.  you could even hack around before that compress line to remove some build stuff that isn't needed anymore. ugly, but it helps
[22:13] <doko> wgrant: ^^^ do we have armhf buildds with different disk sizes?
[22:20] <vorlon> doko: krb5 rebuilt now against libcom-err2, so everything should be sorted now I think
[22:21] <doko> ta
[22:22] <doko> that was using my e2fs upload?
[22:22] <vorlon> yes
[22:23] <vorlon> (it ftbfs with the ubuntu1)
[22:23] <doko> good, it works
[23:41] <vorlon> kanashiro: how is the ruby transition coming along?
[23:42] <vorlon> (I am reminded to ask because qtwebkit-opensource-src is ftbfs with a ruby issue, sigh)
[23:55] <vorlon> looking at afflib, preexisting ftbfs in Ubuntu but not Debian, part of the t64 transition with reverse-dependencies