[00:02] bumping various build scores; skipping over k* because it sounds like wgrant is already handling (hopefully on both s390x and riscv64?) [00:05] also skipping plasma-* [00:06] vorlon: Yep, I'm handling everything k* or building a libkf5* [00:06] wgrant: but not plasma? [00:06] Some of those have been caught up in it, but will check. [00:09] kanashiro, vorlon, dbungert: can someone requeue kcmutils build on riscv64? The build dep should be available now [00:09] doing [00:09] thanks [00:19] So I've been scanning through the no_hide_arches list looking for build failures or dependency waits. I've stopped at knotifyconfig and there's nothing actionable above that currently. afk for dinner and when I come back I'll see if there's something automated I can setup to consume Dan's lists [00:24] openimageio bootstrapped, will copy back to the archive once the armhf binaries are available [00:27] anyone fixing faketime? [00:28] (next actionable on list is sssd and its failing tests partially due to faketime) [00:31] openjdk-8 did not build in ppa, will try to solve it [01:00] vpa1977: lolno [01:00] vpa1977: we should XFAIL the tests [01:01] vpa1977 I think ahasenack was working on sssd, we can check the status with him tomorrow [01:01] dbungert: so a list of packages that are blocked by tests and marked permanent failure would be helpful, those are packages not blocked by queued tests but by failed tests which need analyzed [01:01] vorlon: that's a build time failure, we can run the build with nocheck on armhf [01:02] vpa1977: I don't think it's a good idea to nocheck the whole testsuite as opposed to XFAILing the specific tests that are failing due to faketime - and I think the other test failures are not yet fully analyzed [01:26] vorlon: makes sense, I'll do that next [02:30] I am checking libgpod and it is blocked in -proposed because libgpod-dev is depending on libimobiledevice-dev which is in universe in -proposed and -updates, but in main in the release pocket (and all previous ubuntu series). Not sure what I can do to fix this [03:00] mwhudson, kanashiro: so the buildd tarball also seems to have noble-updates enabled by default, but that appears to get overwritten for a livefs build, which explains the much longer list of uninstallables in our build log [03:07] vorlon: right yes, all builds of all kinds get some sources.list mangling i think? [03:07] yeah I expect so, though it's not part of the build log afaics [03:07] I'm not sure why noble-updates gets disabled here when it doesn't for stable releases, must be some magicking [03:17] > the buildd tarball also seems to have noble-updates enabled by default waaaaaat? [03:23] vorlon: You can see it in the override-sources-list invocation around line 13 of each build log. [03:29] For reference, this is Jammy's, which is probably what it should be for Noble: [03:29] RUN: /usr/share/launchpad-buildd/bin/in-target override-sources-list --backend=lxd --series=jammy --arch=amd64 LIVEFSBUILD-600220 'deb http://ftpmaster.internal/ubuntu jammy main universe' 'deb http://ftpmaster.internal/ubuntu jammy-security main universe' 'deb http://ftpmaster.internal/ubuntu jammy-updates main universe' 'deb http://ftpmaster.internal/ubuntu jammy-proposed main universe' [03:35] vorlon: something like this? https://paste.ubuntu.com/p/Qw3Btdds5J/ [03:42] vorlon: My best guess for this magic are lines 192-193 of lib/cdimage/livefs.py in ubuntu-cdimage, those make their way to the actual livefs.requestBuild() API call. [03:42] I can't find any such magic elsewhere, such as debian-cd or livecd-rootfs itself. [03:43] My *theory* is that commenting out those two lines as a cowboy would DTRT. [04:00] tsimonq2: have you looked at launchpad-buildd? [04:00] mwhudson: I have, and I didn't find anything useful in there. [04:00] ok [04:01] :) [05:08] -queuebot:#ubuntu-release- New binary: gnome-shell-pomodoro [s390x] (noble-proposed/universe) [0.25.1-0ubuntu1] (no packageset) === pushkarnk1 is now known as pushkarnk [06:17] -queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [s390x] (noble-proposed) [0.25.1-0ubuntu1] [08:05] s390x caught up, doing a mass give-back === alucardromero4 is now known as alucardromero [08:06] packages whose migration is currently on the critical path for livecd-rootfs: cdrkit openldap glib2.0 systemd parted qemu libpng1.6 snapd [08:06] there may be some others hidden under python deps which we'll be able to see more clearly after the next publication run [08:11] -queuebot:#ubuntu-release- New binary: gnome-shell-pomodoro [amd64] (noble-proposed/universe) [0.25.1-0ubuntu1] (no packageset) [08:16] I've scheduled retries of all autopkgtest failures for the above packages but there's going to need to be some manual review and overriding of failures here [08:17] I'm also going to schedule the blocking 'in progress' tests over to the regular queue ahead of the huge queue [08:29] I suppose there's no way for mortals to jump the autopkgtest queue? [08:30] no but we've put the mass of tests in the 'huge' queue which gets loadbalanced vs the regular queue [08:31] so anything that needs retried and is directly blocking someone working on this gets priority queuing [08:32] Ah cool [08:47] o/ [08:58] hello SRU team, please take a look at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2058687 [08:58] -ubottu:#ubuntu-release- Launchpad bug 2058687 in libreoffice (Ubuntu Mantic) "[SRU] libreoffice 7.6.6 for mantic" [Medium, In Progress] [08:59] one additions to that list now that python3 has migrated: python-apt [09:02] uh maybe apt itself should be in that list [09:52] vorlon, I am looking at parted [10:01] I'm tackling systemd vs ayatana-indicator-session [10:02] vorlon: do you have a list of packages temporarily removed from -proposed? [10:07] component-mismatches-proposed.txt has some strange binary-only promotions to main, mostly for old library binaries. but looking at recent builds, there are none. e.g. libprotobuf-lite32 for mysql-8.0 [10:11] -queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [amd64] (noble-proposed) [0.25.1-0ubuntu1] [10:22] Note that due to the removal of the previous release pocket versions of amd64 packages, apt/unattended-upgrades will now go and install -proposed versions for you, as your installed version is no longer present in a higher-pinned repository [10:22] Which is normally by design but a bit annoying right now [10:23] Note that it only upgrades packages you have currently installed that were removed to proposed [10:23] New installs would pull pre-t64 versions from -updates [10:24] And Architecture: all packages are still in the release pocket, so e.g. systemd-dev will have a candidate of 255.4-1ubuntu5 whereas it will try to upgrade systemd to proposed 255.4-1ubuntu6 (or -updates 255.2-3ubuntu2 if you did not have the t64 version installed) [10:29] systemd/255.4-1ubuntu6 is skiptested, so I think we should ignore those regressions and focus on glib2.0 instead (which is blocking systemd migration) [10:35] About parted regressions: All were retried or are tests are already requested by vorlon except 2 [10:36] - livecd-rootfs/24.04.55. Should I request a retest with parted/3.6-4build1 or use every currently problematic pkgs as triggers? [10:37] (on amd64) [10:37] I am looking into cdrkit [10:37] - nova/3:29.0.0~rc1-0ubuntu2: a retest for amd64 is already queued but without parted/3.6-4build1. Should I request one with parted/3.6-4build1 as trigger? or wait for the other one to succeed? [10:39] upils: just parted/3.6-4build1 if you think the other pkgs could cause unrelated regressions. But all of them if you're confident that it will pass (e.g. from looking at the test history or running local tests). [10:41] upils: wrt nova: Yes, queue a test for nova vs parted/3.6-4build1 [10:42] thanks! [10:42] taking qemu [10:43] what are the critereas, investigate each test failure, including i386? [10:44] sil2100: ^ [10:48] retriggered most tests for cdrkit. [10:48] looking at snapd now. [10:52] Can we consider that a test is OK if all-proposed run is good, like last week? [10:53] I triggered livecd-rootfs migration-reference/0 to let them fail. then snapd should migrate. [10:57] bdrung: did you do it on all archs? [11:00] schopin, yes [11:00] thanks :) [11:10] I'll starting working through openldap [11:20] I'll start looking at glib2.0 from the bottom up [11:22] openldap has a long list, I have started from the top (balsa) [11:24] triggered sbuild with migration-reference/0 for qemu migration [11:24] for qemu, cinder/i386 and isa-support/i386 are badpkg, I've retriggered cryptsetup/arm64 with the last succesful trigger list, and the rest (up to livecd-rootfs) are either in progress or already solved. [11:25] The rest of the list is with ravikant_ :) [11:25] I'll circle back to qemu after I get some grub. [11:26] Please restore amd64 builds of shim-signed 1.57+15.8-0ubuntu1 in noble release pocket and remove shim-signed from updates [11:27] In all hilariousness this was actually built in mantic [11:27] for qemu, nova is bad-pkg, open-iscsi is a pass, osk-sdl is flaky. [11:30] qemu is not blocked by autopkgtests [11:31] "Should wait for tests relating to qemu 1:8.2.1+ds-1ubuntu9, but forced by ubuntu-release " [11:31] it is blocked by [11:31] Depends: qemu libpng1.6 (not considered) [11:31] Depends: qemu glib2.0 (not considered) [11:40] can we clean out the -updates packages that have newer versions in release again now? === pushkarnk1 is now known as pushkarnk [11:47] Did we just break Depends in amd64 release pocket? [11:48] libkpim5kmanagesieve5 4:23.08.5-0ubuntu3 has Depends: libqt5core5t64 and migrated, but libqt5core5t64 is only in proposed at least here [11:48] (launchpad is too slow to say anything) [11:49] Is it again a problem of non-atomic migration [11:58] I'm debugging EDSP files with upgrade failures that people on reddit send me [11:59] s/upgrade failures/packages being removed/ [12:15] ginggs: damned, I missed that line! [12:16] ginggs: could you update the force-skiptest hint for the new gnome-remote-desktop version? (armhf was removed last week but is back in -updates with the older version) [12:18] jbicha: looking [12:20] * schopin wonders why we have inkscape on i386????? [12:22] heh [12:26] inkscape is a build dependency but it might be possible to rearrange packaging to not need it on i386 [12:28] Probably just a matter of adding a :native somewhere. [12:29] jbicha: i added a force hint for gnome-remote-desktop/46.0-2 [12:32] Would someone like to give me a task to work on? [12:36] rbasak: trying to get glib2.0 and/or libpng1.6 migrated, e.g. picking a random spot in their autopkgtest regressions and working down from there. [12:36] rbasak, my dishes need doing ... want to come over ? [12:36] 😛 [12:37] ogra_: would that be a Noble cause :-P [12:37] those two libs are currently on the critical path [12:37] slyon: looking [12:37] rbasak, yeah, that would be extremely noble of you 😉 [12:37] thanks! [12:38] OK I'll start looking from glib2.0's gphotofs entry and work my way down from there [12:38] I'm currently at glib2.0 vs libgepub [12:44] and i am working my way up on glib2.0 and currently at webp-pixbuf-loader [12:48] I keep seeing installability issues for linux-libc-dev on i386, but I can't figure out why. Does anyone has a clue? [12:49] schopin, IIRC i have seen that on amd64 in a chroot as well. can you point to an example? [12:49] https://autopkgtest.ubuntu.com/packages/z/zvbi/noble/i386 [12:50] bdrung: ^ [12:59] schopin, sorry, i fail to explain that [13:09] the last britney run (10:34) failed due to the brief launchpad outage [13:09] looking at libpng1.6, moving up from zvbi [13:19] for libpng, zvbi, wxwidgets3.2, vlc, visp, sox, poppler, openjdk-8, opencv, odin, are FAIL badpkg. openjdk-23 is flaky. [13:22] A lot of these (under glib2.0) seem to already have autopkgtests queued? [13:23] For nova/3:29.0.0~rc1-0ubuntu2 on amd64, blocking livecd-rootfs I have unmet dependencies (see https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/n/nova/20240404_114824_7e32f@/log.gz) on libvirt-daemon-system I do not understand why. Binaries for libvirt-daemon-* version 10.0.0-1ubuntu1 are still published in main (updates) [13:24] ravikant_: are you triggering corresponding tests to resolve the badpkg situation? [13:24] rbasak: yes. I'd suggest skipping over those that have (releveant) tests queued already [13:24] OK [13:24] slyon: I did not. What should I use as Trigger? [13:25] libpng1.6 in this case? [13:25] I meant libpng1.6/1.6.43-5build1 [13:26] IMHO if it's only on i386 we shouldn't waste too much time on it. [13:27] ravikant_: It always depends a little bit on the apt output from the respective logfile. Sometimes it can be the package to be migrated itself (if there's a newer version in -proposed), or there can be anohter hint at the end of the logfile, which might be worth checking for a newer version in -proposed. A last resort would be &all-proposed=1 (that's what I did on i386, as I didn't want to waste too much time on int) [13:28] ok, I'll try that. [13:29] So https://autopkgtest.ubuntu.com/packages/g/graphviz/noble/i386 for example seems to have a bunch of attempts and hasn't resolved. [13:29] Should I investigate deeper? What does not wasting time on it mean exactly? [13:40] rbasak: our short term goal being to be able to build images, if it's a badpkg issue and not an actual test failure I think hint through the failure is acceptable. [13:40] -queuebot:#ubuntu-release- New sync: python-influxdb-client (noble-proposed/primary) [1.40.0-1] [13:40] -queuebot:#ubuntu-release- New sync: python-reactivex (noble-proposed/primary) [4.0.4-1] [13:47] I don't know what was vorlon's recommendation for this, but I'd like for someone at least to take a look at the badpkg issue? Since I'd be curious what's up [13:48] I'm trying to figure out the linux-libc-dev thing but I'm actually having issues just having a suitable i386 environment to begin with :/ [13:49] https://autopkgtest.ubuntu.com/packages/g/graphviz/noble/i386 -> that one has all-proposed=1 badpkg :/ [13:50] Are we working in any specific list ATM? [13:50] those two syncs above are to support a sync for cloudkitty to 20.0.0 which is currently blocking autopkgtests in noble (as its the old release which is not compatible with the oslo's in noble). [13:54] New britney run just finished \o/ waiting for the new update_excuses [13:55] athos: cdrkit openldap glib2.0 systemd parted qemu libpng1.6 snapd apt python-apt [13:56] but beware: some are hinted/skiptest already. So ignore those [14:00] huh, weird, snapd still doesn't want to migrate even the reference tests failed, let me just hint it to save time [14:00] doko: abseil; mpg123; . [14:04] apt is interesting since it is hindering mksbuild usage (for noble schroots) is it hinted. it seems taht steve is getting those fixed now. === pushkarnk1 is now known as pushkarnk [14:12] If anyone hasn't done so already, remember to refresh your excuses page :) [14:14] It's getting shorter every moment [14:14] I am bit lost about the test failure for nova (as explained above). The same error is also happening on i386. Anyone available to quickly check and tell me if this is something obvious? (like something we should hint for now) [14:15] upils: I don't see nova on the new excuses. [14:16] I do :D (but maybe I am looking in the wrong place -> https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#parted) [14:16] Ah, you mentioned it blocking livecd-rootfs earlier. [14:18] upils: I'd start with an all-proposed=1 run [14:18] > Ah, you mentioned it blocking livecd-rootfs earlier. [14:18] I did, yeah, my bad [14:19] ok, will do, thanks, but I do not understand why it would fix the issue [14:21] upils: looking that that nova failure [14:22] upils: it wouldn't fix the root issue, but it could potentially allow the tests to run. [14:23] upils: I think the package install is confused by the mismatch of 'all' and 'amd64' package versions between noble-updates and nobel{-proposed} [14:24] I've also seen a few of these but I've stopped hitting recheck until rebuilds are all through [14:24] jamespage, thanks. You think that because you see `522s Get:143 http://ftpmaster.internal/ubuntu noble-updates/main amd64 libvirt0 amd64 10.0.0-1ubuntu1 [1822 kB]` ? [14:25] schopin, oh ok. So I guess it could at least unblock the situation [14:26] upils: I think so - only the amd64 binaries got removed from the release pocket so we're in this weird mismatched version position right now [14:26] this exploded my laptop this morning :) [14:26] doing a retrigger now of all failed tests for the key packages for livecd-rootfs just in case [14:27] juliank: cleaning out -updates requires freezing and unfreezing the archive, so no [14:27] jbicha, schopin: :native is not relevant to how we build packages, so no [14:28] schopin: auotpkgtest runners are cross-arch, launchpad builds are not [14:28] oh? TIL. [14:29] upils: https://dpaste.com/5JFPVHJZY - fairly easily reproduced locally [14:30] rbasak: glib2.0 tests queued> tests will be queued but no guarantee they'll pass on a retry! so analysis needed [14:30] rbasak: we will ignore i386 test failures liberally [14:32] I'm uploading gtk+2.0 now, because gtk+2.0 already migrated for xz-utils. This will allow overlay-scrollbar to build on armhf [14:32] sil2100: badpkg issue> which one? [14:32] vorlon: hmm, isn't it just for package in packagesd; if version is newer in release pocket; then remove-package -s noble-updates package; fi; done [14:33] juliank: we *cannot remove packages from -updates* [14:34] without freezing the archive [14:34] sounds peculiar [14:34] vorlon: a lot of i386 tests are failing due to installability problems [14:35] schopin: if those are the only tests blocking, ask the release team to skiptest hint the package [14:35] but if there are tests pending, we wouldn't hint yet [14:35] also now queuing --no-proposed retests for all failing tests [14:39] I think KDE stacks are finallt geting there. thank you for being patient and letting our retry script do its job [14:39] *finally [14:40] yes, the archive mails for KDE stack landing in the release pocket have been promising [14:40] now if only we could get glib2.0 in ;) [14:40] Like I said this morning EU time [14:40] > libkpim5kmanagesieve5 4:23.08.5-0ubuntu3 has Depends: libqt5core5t64 and migrated, but libqt5core5t64 is only in proposed at least here [14:40] qa-help: the last two attempts on https://autopkgtest.ubuntu.com/packages/a/adios2/noble/arm64 seem to be an infra failure? [14:40] juliank: sure, so someone (on Kubuntu) could run the qtbase-opensource-src blocking tests to ground [14:41] i.e. KDE PIM stuff migrated *before* the Qt it depends on [14:41] Well this unsat dependency is making apt just remove plasma-desktop [14:42] why did we migrate it in teh wrong order? [14:42] I'd have expected us to not break amd64 dependencies harder [14:42] only if it didn't increase net uninstallability on amd64 [14:42] Maybe the LP outage interrupted the publisher? [14:43] Nah I don't think Qt is ready to migrate yet [14:43] juliank: it could have been either noble-updates nonsense because britney looks at it; or because we removed amd64 binaries from release pocket but not arch: all, which britney counts uninstallibilities of specifically on amd64 [14:44] Ah so everything is horrible basically [14:44] yay, webkit2gtk finished building [14:44] orig: 20349+0: a-3297:a-3167:a-4876:i-266:p-2940:r-2912:s-2891 [14:45] looking at libvirt to try and possibly unblock parted [14:45] that's a lot of packages britney says are uninstallable on baseline :P [14:46] the only meaningful blocking test for cdrkit is nova, which is blocked by installability of test deps [14:47] livecd-rootfs ignorable, ubiquity ignorable (on arm64 heh), i386 ignorable, all other tests pass on amd64 [14:47] vorlon, that is what I am trying to solve [14:47] so hinting [14:47] (the installability of test deps for nova) [14:47] schopin: sorry, was in a call [14:47] looking [14:48] upils: fixing it is not the requirement, vs analyzing it and making sure it doesn't pose a real risk of regression [14:48] upils: (the installability should *also* be fixed but async) [14:48] Skia: it's not just that package either, I've seen this on a couple of others too. [14:49] looking into libpng1.6 vs gtk4 (looks like a real regression) [14:49] yes, those look like infra failures [14:49] we can re-enable retries if you'd like, though that may slow down our throughput [14:50] schopin: yeah, that definitely looks like an infra issue, and I've had other issues with the infra today. I currently have an open RT about those, even though not on bos02. IS also told us that the Launchpad fire earlier got them quite busy, so maybe related. [14:50] andersson1234: are the three usual retries disabled? [14:51] yes, let me double check [14:51] andersson1234: okay, I missed that. That may be worth mentionning on our status page. [14:52] yes, since 28th march https://git.launchpad.net/autopkgtest-cloud/commit/?id=17dc61a0867ebf23d482fd7d6e0d695849ec343b [14:53] -ubottu:#ubuntu-release- Commit 17dc61a in autopkgtest-cloud "Merge remote-tracking branch 'andersson123/reduce-retries'" [14:53] (and then your amendment after) - I will add it to our status page [14:55] vorlon: quick question about apt in noble-proposed - I see that it's actually a no-change rebuild - I'm probably missing context, but any reason not to skiptest it? [14:55] sil2100: I don't have any reason not to - it just was missed by my scripts because it was a double-rebuild (oops) [14:56] Let me do that then [15:19] hmm the curl autopkgtest failure on openldap looks bad, it's not caused by openldap but random rebuild ordering means something still depends on libelf1 instead of libelf1t64 on amd64 and makes a sad [15:20] oh but that's in the release pocket too [15:20] so maybe fixed by migrations alone [15:22] vorlon: I guess its debugedit [15:22] looks like it may be, yes [15:28] pushkarnk: interestingly, debugedit is blocked in -proposed by a similar installation failure on debhelper [15:28] I'll just hint it through [15:29] ok [15:29] wait, ehm [15:32] ok weird debugedit was uploaded on March 1 but wasn't built on amd64 until March 30 so missed the xz-utils window?! [15:32] and the new debugedit still depends on libelf1 because of the random rebuild ordering heh [15:33] vorlon: Could there be other double-rebuilds that are missing? [15:35] bdmurray: yes but I don't have a good way to systematically detect them without changelog parsing etc because in some cases the first rebuild will be for time_t so not automatically ignorable by the policy we have so far agreed [15:35] -queuebot:#ubuntu-release- New binary: libqofono [amd64] (noble-proposed/universe) [0.122-2] (no packageset) [15:35] -queuebot:#ubuntu-release- New binary: libqofono [ppc64el] (noble-proposed/universe) [0.122-2] (no packageset) [15:35] so anyway, debugedit reuploaded [15:35] and curl vs openldap ignorable [15:36] I've been looking at openldap vs freedombox btw, as well as a few others [15:40] -queuebot:#ubuntu-release- New binary: libqofono [armhf] (noble-proposed/universe) [0.122-2] (no packageset) [15:40] pushkarnk: where are you up to on openldap? [15:41] -queuebot:#ubuntu-release- New binary: libqofono [s390x] (noble-proposed/universe) [0.122-2] (no packageset) [15:43] andersson1234: curl, to be honest. I did run through some other packages test failures, but didn't really spend quality time on them [15:43] i am looking at mtd-utils now [15:44] andersson1234, pushkarnk: so anyone tried to reproduce the lighttpd/amd64 autopkgtest failure? (a priority because it's amd64) [15:45] vorlon: I think we should badtest gtk4/4.14.1+ds-0ubuntu2 (and ubuntu1), see LP: #2059158 [15:45] -ubottu:#ubuntu-release- Launchpad bug 2059158 in gtk4 (Ubuntu) "proposed-migration for gtk4 4.14.1+ds-0ubuntu1" [Critical, New] https://launchpad.net/bugs/2059158 [15:46] schopin: badtest, or baseline retest? [15:47] logs: missingbuild log with arch filtering https://paste.ubuntu.com/p/F4C3G5RMhb/ [15:47] missingbuild, no arch filtering https://paste.ubuntu.com/p/KNWWhPHWB8/ [15:47] vorlon: Well, on amd64 baseline would succeed since the tests are properly executable in the -updates version. [15:47] autopkgtests in a PERMAFAIL state (regressions) https://paste.ubuntu.com/p/fb3t7VQ7pF/ [15:47] blocked chains https://paste.ubuntu.com/p/SjyHTxmjhY/ [15:49] schopin: I don't think the baseline pulls from -updates? [15:49] schopin: yes, nteodosio also recognized the executable problem for autopkgtests but I don't think we were intending to upload until gtk4 migrated first [15:49] https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/22 [15:49] -ubottu:#ubuntu-release- Merge 22 in gnome-team/gtk4 "Make installed-tests executable." [Closed] [15:49] schopin: correct me if I'm wrong [15:50] jbicha: I figured, and yes I think it'd be bad to upload just to fix that right now :) [15:51] vorlon: experience tells me that when we disagree I'm usually the one being wrong. [15:51] schopin: well let's look at the logs :) [15:52] schopin: https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/l/lighttpd/20240404_002824_ea614@/log.gz the one I'm looking at shows noble-updates so you're right [15:52] but where would the gtk package be pulled from in baseline if not from updates? [15:52] schopin: badtesting now [15:52] schopin: well if it failed to be pulled in at all then the tests would also definitely fail! [15:52] heh [15:53] -queuebot:#ubuntu-release- New binary: libqofono [arm64] (noble-proposed/universe) [0.122-2] (no packageset) [15:54] schopin: so did you want this badtested on amd64 or on all archs? [15:55] schopin: it *fails* on all archs but the baseline should fail the same way on !amd64 [15:55] well there you go, amd64 only. [15:55] ok [16:07] 2725s Duplicate config variable in conditional 0 global: server.name [16:07] ok lighttpd failure is Not Our Fault [16:09] do we have a wiki or discourse page that summarizes the time_t effort, for public consumption? [16:09] no [16:12] ahasenack_: is https://autopkgtest.ubuntu.com/packages/n/nfs-utils/noble/s390x interesting to the Server Team [16:12] 938s mount.nfs: mount system call failed for /mnt [16:12] yes [16:14] even a simple mount seems to be failing, not just kerberos [16:15] andersson1234, pushkarnk: I'm hinting openldap now [16:15] freedombox vs ufw Breaks is not an openldap regression [16:15] oh, s390x only [16:15] well, that's easier than armhf to get a VM on [16:15] and it looks like it passed when andersson1234 retried the test [16:15] ahasenack_: :) [16:16] ahasenack_: I have a machine available if you need [16:16] sergiodj: armhf? [16:16] looking at glib2.0 now [16:16] ahasenack_: s390x [16:17] glib2.0 a bit trickier because I see a lot of armhf test failures and this isn't a no-change rebuild [16:17] vorlon: I'm a bit out of the loop (meeting right now), but is there any openldap problem that needs to be investigated? [16:17] note to all: the regular autopkgtest queue is empty, don't be shy about triggering retries of failing tests if you need to [16:18] sergiodj: no, openldap hinted, all failing revdep tests are analyzed or cleared via retry [16:18] vorlon: ack, thanks [16:20] vorlon: I saw on https://bugs.launchpad.net/ubuntu/+source/bpftrace/+bug/2052809 you only promoted -release, but the versions not -updates and -proposed. Would those not also be needed to not set back the component when it migrates? [16:20] -ubottu:#ubuntu-release- Launchpad bug 2052809 in bpftrace (Ubuntu) "[MIR] bpftrace" [Undecided, Fix Released] [16:20] oh, I see ubuntu-server images are building successfully on non-amd64, confirming that remaining bootstrap issues are amd64-only, excellent [16:20] cpaelzer: -proposed yes, -updates will be deleted so doesn't matter. Can you take care of it? [16:20] I will [16:21] also I'll do the same for src:bpfcc so that this mismatch isn't a migration blocker anymore [16:21] vorlon: is there a list of issues you guys are using today? [16:21] cpaelzer: sorry, no real way from the component-mismatches reports to see that packages need promoting in both pockets [16:21] sergiodj: I think https://paste.ubuntu.com/p/SjyHTxmjhY/ [16:22] sergiodj: the remaining packages for stage 1 that need to get migrated asap are: glib2.0 systemd parted qemu libpng1.6 snapd [16:22] schopin: thanks [16:22] sergiodj: see scrollback for information about any blocking test failures that people are already investigating [16:22] vorlon: thanks, will do [16:23] once those are all cleared, the list schopin points to is good [16:23] Has anyone seen such kind of failure? https://bugs.launchpad.net/ubuntu/+source/mtd-utils/+bug/2060214 [16:23] -ubottu:#ubuntu-release- Launchpad bug 2060214 in mtd-utils (Ubuntu) "mtd-utils 1:2.1.6-1build1 FTBFS" [Undecided, New] [16:25] someone could go deep on https://autopkgtest.ubuntu.com/packages/a/ayatana-indicator-session/noble/armhf to see what's still pulling in libelf1 on armhf instead of libelf1t64, and get that resolved in the release pocket [16:27] let me check ayatana-indicator-session and leave mtd-utils to someone else. [16:27] vorlon: bdrung: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/release.txt says debugedit:armhf depends on libelf1, cuasing lots of unsat build-depends [16:27] analyzed armhf test failures against glib2.0 of ayatana-indicator-session, booth, cjs, cpdb-backend-file, dbus-test-runner, all ignorable for promotion [16:28] juliank: well I just uploaded debugedit [16:28] juliank: because it was depending on libelf1 on amd64 after the latest rebuild and breaking things; when that migrates to the release pocket it should be cleaner? [16:29] I think retrying with new debugedit should clear it out? [16:29] if it's published yet [16:29] but wild guess [16:29] juliank: the existing debugedit on armhf should already have been built against libelf1t64 [16:30] That said I can actually run dose against debugedit on the release pocket [16:30] juliank: https://launchpad.net/ubuntu/noble/armhf/debugedit/1:5.0-5build1 confirms, the rebuild from the beginning of March already has the libelf1t64 dep [16:31] But my report from release pocket also says: [16:31] * ayatana-indicator-session build-depends on missing cmake-data:armhf (= 3.28.3-1build5) via cmake:armhf, but not a regression [16:31] did you kill cmake entirely in the release pocket? [16:32] I probably had to kill cmake-data:all because of cmake self-build-depends, so that it could pull the older version from -updates [16:32] zeah so ugh [16:33] Also the build log says debugedit -> libelf1t64 in https://launchpadlibrarian.net/723142362/buildlog_ubuntu-noble-armhf.debugedit_1%3A5.0-5build2_BUILDING.txt.gz [16:33] nothing that has cmake in build/depends and tests having buildddeps in it is going to pass [16:33] vorlon: FYI the bpfcc and bpftrace component mismatches are fixed now [16:33] cpaelzer: cheers [16:33] debugedit | 1:5.0-5 | noble | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x [16:33] debugedit | 1:5.0-5build1 | noble-proposed | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x [16:33] debugedit with the rebuild against t64 never left proposed [16:34] So yes, broken cmake and debugedit still broken [16:34] oh, fwiw i386 autopkgtests can fail because of multi-arch: same libraries not being installable because i386 and amd64 have different versions available: https://autopkgtest.ubuntu.com/packages/d/dbus/noble/i386 [16:34] which just reinforces that we should be ignoring i386 right now [16:34] Yes [16:35] I figured as much when I read lots of i386 failures earlier [16:35] juliank: yeah debugedit curiously was ftbfs (dep-wait?) on amd64 for a month, so missed xz-utils entirely and didn't have to be removed, *but* when it finally built it built against libelf1 instead of libelf1t64 :P so now that's fixed and it should be migratable today [16:35] So realistically you need to drop *all* cmake binaries from the release pocket [16:35] I haven't looked at cmake it's not critical path [16:35] juliank: no because old cmake in -updates on armhf is not t64 [16:35] i.e. they are not installable due to = cmake-data depends [16:36] juliank: where are you seeing problems from this? [16:36] vorlon: that's the other half of why the autopkgtest is failing [16:36] vorlon: good to hear the test passed, I'm going to try and reproduce the lighttpd/amd64 test now [16:36] juliank: "the" autopkgtest? [16:36] And if you were to try apt in the release pocket it would fail too [16:37] vorlon: the one you mentioned ayatana-indicator-session [16:37] andersson1234: I reproduced lighttpd/amd64 and it's a garbage test harness in lighttpd, generates a bogus config file for lighttpd itself [16:37] Like I said, the same applies to e.g. apt migration-reference/0 tests - they would fail now [16:37] juliank: ok cool - so the only action here is to make sure cmake gets promoted [16:37] very urgently [16:38] not as urgently as unblocking image builds [16:38] vorlon: okay i'll hold off on that and continue looking at regressions [16:38] before britney goes retries migration-reference/0 tests of packages depending on it and just migrates all [16:38] but if migrating cmake makes a lot of other tests pass so we don't have to manually deal with them that's a good thing [16:39] juliank: tests for cmake are currently not queued at all since it's not seeded in any images. Feel free to queue up those tests now to move cmake forward [16:40] bdmurray, andersson1234: do we still have horrible shell code in autopkgtest-cloud/autopkgtest to compute the list of binary packages to set a pin for, and if so should we replace that with Pin: src:$sourcepackage which I think didn't exist at the time this was first implemented [16:41] Atriggered [16:43] paride: ^^ [16:43] ww/quit [16:44] Hem. Disregard this :) [16:45] someone please take care of util-linux [16:49] well gst-omx/armhf autopkgtest failures are ignorable, that package was removed from release this week as a Debian removal [16:50] juliank: fwiw this is an argument for prioritizing --all-proposed retests right now instead of --no-proposed [16:53] I wish I could help more but the time_t stuff and DST kind of killed much of me [16:54] I stayed up later and later during time_t and it's all broken now :( [16:54] tackling openldap vs krb5 [16:54] seb128, jbicha: libgdata autopkgtest failures on armhf and ppc64el are concerning, mention of sysprof vs libsoup here [16:57] seb128, jbicha: similar failure for libsoup2.4 itself https://autopkgtest.ubuntu.com/packages/libs/libsoup2.4/noble/armhf looks to me like libsoup2.4 has an undeclared dependency on sysprof, that was masked by glib2.0 depending on it, which has now been backed out [16:58] what about krb5? I might be able to help, between sssd debugging sessions [17:00] I haven't looked but if it hasn't migrated yes that's important [17:00] can't have an amd64 server build without it :) [17:00] (and probably not desktop) [17:01] looking at https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#krb5, seeing some reds [17:01] some double listed packages in different versions, usually a sign that a new run could clarify things [17:02] openldap vs nfs-utils (s390x) looks like a legitimate test failure, nothing I can amend with additional triggers or all-proposed [17:02] I filed a bug about the nfs-utils failure on s390x [17:03] ahasenack_: https://paste.ubuntu.com/p/F4C3G5RMhb/ is the list of seeded packages with build failures that need resolved, but https://paste.ubuntu.com/p/fb3t7VQ7pF/ is the list of all seeded packages that need tests resolved; I don't see krb5 listed there so maybe dbungert needs to refresh something [17:03] andersson1234: I already hinted openldap, see above [17:03] I'm setting up hosting of the logs at https://people.canonical.com/~dbungert/ausrede/ [17:06] ack [17:06] excuses is a bit old [17:06] ahasenack_: current runtime is ~2h [17:06] ~2h [17:06] ok [17:06] so you should see an update soon [17:09] almost done reviewing glib2.0 blocking tests [17:11] I thought I saw/heard mention somewhere of issues with tracker? [17:11] tracker/armhf has a SIGABRT in its autopkgtest. Won't block on this [17:13] looking at python-apt vs breezy-debian [17:13] I've started working on a script to parse the ausrede output and query the launchpad api for missing builds. my first attempt looks something like this https://paste.ubuntu.com/p/CdM7XzrRkm/ [17:14] everything else is either built or building [17:14] would anyone else find this useful? [17:16] doko: I don't understand the dbusada/s390x failure [17:17] doko: (autopkgtest) [17:17] bdmurray: ^^ maybe you can remind me what 'erroneous package: rules extract failed' points to? [17:18]