[00:00] <sil2100> I'll take a look at some of the failures for glibc then
[00:01] <vorlon> nb the util-linux security update is to the 'wall' command, chances of this regressing any revdeps are ~ 0
[00:03] <vorlon> vpa1977: thanks for opening those bug reports on the regressed util-linux revdeps. hinting util-linux through now
[00:03] <vorlon> that leaves only (trivial, insignificant, you'll barely notice it's missing) glibc from the Priority: required set
[00:04] <sil2100> Ok, so I see glibc's abseil and ableton-link failures seem to be badpkg cmake-data related, which as I understand correctly is just a matter of migrating cmake?
[00:05] <vorlon> good lord, flavors are pulling in gdebi -> lintian -> build-essential -> gcc in their desktops?
[00:05] <sil2100> Looking at the adsys regression
[00:05] <vorlon> sil2100: or of retesting with all-proposed, which is queued but will take time
[00:06] <vorlon> sil2100: but see also my doc above with triage notes :)
[00:07] <vorlon> "if a test fails because of uninstallability of test deps, but there is at least one architecture on which the test passes, this is ignorable"
[00:07] <vorlon> sil2100: please also feel free to /sanity check/ my triage notes, but these are the principles I'm currently following, I think
[00:08] <sil2100> +1 on those!
[00:08] <sil2100> Ok, adsys regression seems to be hm, unrelated to glibc. It fails the same way on other packages, was failing the same way in the past as well
[00:08] <sil2100> So more like ignore/hint material
[00:08] <sil2100> Moving on
[00:09] <kanashiro> thanks for the notes, that's helpful
[00:09] <sil2100> Looking at alsa-lib regression... actually not, i386, moving on
[00:09] <sil2100> Looking at anet
[00:11] <sil2100> Okay, anet also unrelated, package was failing similar with the release glibc
[00:12] <sil2100> I'll hint it since it will just continue to fail, I'll get a bug as well
[00:16] <sil2100> Looking at apparmor
[00:16] <vorlon> afk for dinner
[00:17] <sil2100> apparmor glibc regressions look like badpkg, so ignoring as per current policy! Other arche is okay
[00:17] <sil2100> Looking apt
[00:18] <sil2100> apt = badpkg, mostly cmake, non-blocking
[00:18] <kanashiro> I took a look at libgpod and I sent a message here but I am not sure if people noticed it. It is in main and depends on libimobiledevice-dev, the libimobiledevice-dev is in main in all arches but amd64 (not sure why) in the release pocket. And in universe in all arches in -updates
[00:18] <kanashiro> https://chat.debianbsb.org/file/3/W5wVK5Qn6sYJX5VL
[00:19] <sil2100> Looking arrayfire on glibc
[00:19] <kanashiro> any hint on that?
[00:22] <sil2100> arrayfire another badpkg on cmake, nonblockable
[00:22] <sil2100> Checking authd
[00:23] <sil2100> uuuu, this looks worse
[00:26] <sil2100> Then again, the same test passed for 2.39-0ubuntu7, which is the actual new version of glibc. So I'd say it non-blockable as well, we can ignore that
[00:27] <sil2100> Checking auto-multiple-choice
[00:27] <sil2100> ...badpkg, passed with ubuntu7
[00:27] <sil2100> Ignoring
[00:28] <sil2100> DChecking ayatana-indicator-session
[00:28] <sil2100> badpkg, fine on other arches, moving on
[00:28] <sil2100> Checking benchmark
[00:29] <sil2100> Another badpkg
[00:29] <sil2100> Checking binutils
[00:30] <sil2100> Actually passed with an additional trigger, moving on
[00:30] <sil2100> bliss
[00:32] <sil2100> I queued up a migration reference test, I assume it's just broken, so I'd ignore it (non-blocking)
[00:32] <sil2100> Checking boost1.74
[00:33] <sil2100> Testbed errors, but passed fine on ubuntu7, so non-blocking
[00:34] <sil2100> Checking booth
[00:35] <sil2100> badpkg, other arches fine, non-blocking
[00:35] <sil2100> Checking brlaser
[00:35] <sil2100> All proposed passed, moving on
[00:35] <sil2100> bruteforce-wallet...
[00:36] <sil2100> Timed out, but I see it timed out similarly in the past - also, passed for ubuntu7, ignoring
[00:37] <sil2100> Checking burp, tests still running but I see that it already passed for ubuntu7
[00:37] <sil2100> soooo, ignoring
[00:37] <sil2100> burrow passed
[00:37] <sil2100> bustools passed for ubuntu7
[00:38] <sil2100> bwa same, passed for ubuntu7
[00:38] <sil2100> Checking c2esp
[00:39] <sil2100> Constantly failing, wouldn't block on this, unrelated to glibc
[00:39] <sil2100> c2x passed for ubuntu7
[00:40] <sil2100> cadaver... always neutral, even for ubuntu7, skip
[00:40] <sil2100> calculix-ccx passed
[00:41] <vpa1977> calibre passes
[00:41] <vpa1977> camlpdf - passes
[00:41] <sil2100> Yep, badpkg on 2 arches, passed on one, all good
[00:42] <sil2100> (I'm also looking at the Test in progress ones)
[00:42] <vpa1977> looking capnproto
[00:42] <sil2100> Looking at camlzip
[00:42] <sil2100> ...passed on ubuntu7, we can ignore
[00:43] <sil2100> Checking casa-formats-io
[00:43] <vpa1977> canproto - passed with ubuntu7
[00:43] <sil2100> casa-formats-io passed with ubuntu7, no reason why it should fail for a no-change rebuild
[00:44] <sil2100> Looking at cataclysm-dda
[00:44] <vpa1977> looking at cbatticon
[00:44] <sil2100> cataclysm-dda badpkg, good on other arches, skipping
[00:45] <sil2100> Checking cbm
[00:45] <vpa1977> cbatticon - passed with ubuntu7
[00:45] <sil2100> neutral with ubuntu7, all good
[00:45] <vpa1977> looking cccolutils
[00:45] <sil2100> Darn, that's a lot of autopkgtests
[00:46] <vpa1977> cccolutils - neutral with ubuntu7
[00:46] <sil2100> hm
[00:46] <vpa1977> pick a letter and go all the way with it ?
[00:47] <sil2100> I wonder if it would be possible to somehow query the ADT db and check the test results for ubuntu7 and then scratch out all the failures/in-progress for ubuntu8
[00:47] <sil2100> I'll take
[00:47] <sil2100> 'e' for now
[00:47] <sil2100> I'll need to EOD soon but at least that'll be a few more packages
[00:48] <sil2100> I'm looking at all 'e' starting autopkgtests for glibc - I'll grind through them and then put a summary (not to spam)
[00:49] <vpa1977> continuing with c then
[00:53] <sil2100> Ok, all 'e' tests looking good, non-blockable
[00:54] <sil2100> bdmurray: hey hey! Do you maybe have enough autopkgtest-db-foo to maybe figure something out here? We're looking at all glibc ubuntu8 test regressions - and basically since it's a no-change rebuild, I feel like we should ignore all tests that fail but passed on the ubuntu7 version
[00:55] <sil2100> bdmurray: do you think there would be an easy way to query the DB for that? aka. grabbing all ubuntu8 failures, comparing with ubuntu7 results and if ubuntu7 passes, than informing that it's all good?
[00:55] <sil2100> vorlon: ^
[00:56] <sil2100> Ok, I'll be EODing now, please be sure to leave a message for me and others on where this stands - if I wake up and need to continue, please let me know where
[00:56] <sil2100> I get the feeling that glibc is hintable, but I guess it would be best to cut through some more tests
[00:59] <sil2100> o/
[01:13] <vorlon> I think we dumped most of the tests from the queue for 0ubuntu7 without ever getting results tho
[01:27] <vpa1977> failing and test-in-progress links for glibc https://paste.ubuntu.com/p/PQyW2sPyjB/ (7152 items). We probably need a script
[01:27] <vpa1977> *lines
[01:35] <mwhudson> back
[01:36] <bdmurray> I'll try and query the test results for the previous glibc ubuntu7 run as that seems achievable
[01:52] <bdmurray> Alright, you could use this as a basis for comparison.
[01:52] <bdmurray>  $ sqlite3 autopkgtest.db "SELECT distinct(result.run_id), result.exitcode, package, result.triggers FROM test, result WHERE te
[01:52] <bdmurray> st.id = result.test_id AND release ='noble' AND result.triggers IN ('glibc/2.39-0ubuntu7') ORDER BY package;" | pastebinit
[01:52] <bdmurray> https://dpaste.com/35GAWZFWP
[01:52] <vpa1977> are those are passed tests?
[01:53] <bdmurray> No you'd want to modify the query to include result.exitcode = 0
[01:55] <bdmurray> https://dpaste.com/82SBLX2KF
[01:56] <bdmurray> Oh, the arch would be helpful too
[01:58] <bdmurray> https://dpaste.com/9VHU32AZA
[02:02] <vpa1977> accountservice is missing from the second paste
[02:02] <vpa1977> https://autopkgtest.ubuntu.com/packages/a/accountsservice/noble/amd64
[02:08] <mwhudson> it hasn't succeeded in a long time though?
[02:09] <vpa1977> yes, but it was in the first paste ...
[02:17] <mwhudson> the second column in the first paste is exit code?
[02:19] <vpa1977> yes
[02:19] <vpa1977> It would be nice to pick up also neutral packages
[02:24] <bdmurray> do you know the neutral exit code?
[02:25] <vpa1977> no :(
[02:28] <bdmurray> Looks like 8
[02:28] <bdmurray> https://dpaste.com/9SPF9KGHN see achilles
[02:34] <vpa1977> https://dpaste.com/BXZY5HQ2A-preview
[02:35] <vpa1977> filtered list of failures that did not have successful or neutral ubuntu7 run
[02:35] <vpa1977> and something wrong with paste again - chiark-tcl is not in paste
[02:42] <vpa1977> same highlighting amd64 and armhf
[02:42] <vpa1977> https://dpaste.com/2KM8TUHWX-preview
[02:48] <vorlon> ummm where did the graph of autopkgtest throughput go https://ubuntu-release.kpi.ubuntu.com/d/yIC34LpGk/ubuntu-metrics?orgId=1
[02:49] <vorlon> oh here we go https://ubuntu-release.kpi.ubuntu.com/d/76Oe_0-Gz/autopkgtest?viewPanel=10&orgId=1&refresh=1m
[02:50] <vpa1977> raising bug for cura-engine (buffer overflow)
[02:50] <vpa1977> (its already there)
[02:51] <vpa1977> dnsmasq - always fail amd64
[02:52] <vpa1977> docker.io-app - always fail
[02:54] <vpa1977> eztrace - existing bug https://bugs.launchpad.net/ubuntu/+source/eztrace/+bug/2059183
[02:54] -ubottu:#ubuntu-release- Launchpad bug 2059183 in eztrace (Ubuntu) "autopkgtest failure on eztrace/2.1-7ubuntu3" [Undecided, New]
[02:55] <vpa1977> fence-agents - false positive, passed on ubuntu7
[02:57] <vpa1977> fitsverify - https://bugs.launchpad.net/ubuntu/+source/fitsverify/+bug/2059185
[02:57] -ubottu:#ubuntu-release- Launchpad bug 2059185 in fitsverify (Ubuntu) "fitsverify is uninstallable on Noble" [Undecided, New]
[02:58] <vpa1977> flatpak, fuse-zip - neutral
[02:58] <vpa1977> gdcm - https://bugs.launchpad.net/ubuntu/+source/gdcm/+bug/2060243
[02:58] -ubottu:#ubuntu-release- Launchpad bug 2060243 in util-linux (Ubuntu) "proposed migration  util-linux 2.39.3-9ubuntu4 vs  gdcm/3.0.22-2.1build2" [Undecided, New]
[03:03] <vpa1977> globalplatform - ftbfs, retrying
[03:05] <vpa1977> globalplatform - raised ftbfs https://bugs.launchpad.net/ubuntu/+source/globalplatform/+bug/2060262
[03:05] -ubottu:#ubuntu-release- Launchpad bug 2060262 in globalplatform (Ubuntu) "globalplatform fails to build from source" [Undecided, New]
[03:07] <vorlon> did anyone analyze the regression of contourpy on arm64?
[03:14] <vpa1977> it appears it fails tests assuming more than one core. I will try it locally
[03:14] <cpete> yes
[03:14] <cpete> vorlon: do some of the autopkgtest works sometimes only have 1 thread? I filed https://bugs.launchpad.net/ubuntu/+source/contourpy/+bug/2060250
[03:14] -ubottu:#ubuntu-release- Launchpad bug 2060250 in contourpy (Ubuntu) "autopkgtests are flaky due to threadedness" [Undecided, New]
[03:15] <vorlon> cpete: all the autopkgtest runners should have multiple (virtual) cores
[03:16] <vorlon> dipy/arm64 doesn't look good
[03:16] <vorlon> but also looks kinda flaky
[03:19] <vpa1977> gslang - raised https://bugs.launchpad.net/ubuntu/+source/glslang/+bug/2060263 - autopkgtest needs to be updated
[03:19] -ubottu:#ubuntu-release- Launchpad bug 2060263 in glslang (Ubuntu) "autopkgtest fails due to removal of OGLCompiler" [Undecided, New]
[03:19] <cpete> vorlon: for whatever reason those tests always fail on s390x and ppc64el, and sometimes on arm64
[03:34] <cpete> eod. After hacking away at numpy today I got down to mdp and found or filed bugs for regressions in: astroml, asymptote, contourpy, cython-legacy, and mdp. (ignoring i386 regressions). There may be more regressions before mdp but tests have still been queued on amd64.
[03:52] <pushkarnk> What does this autopkgtest error generally mean?
[03:52] <pushkarnk> badpkg: rules extract failed with exit code 1
[03:55] <vorlon> cpete: cheers!
[03:55] <vorlon> pushkarnk: AIUI that usually means the package that's supposed to be tested doesn't actually have binaries on the arch in question
[03:56] <pushkarnk> vorlon: ack, thanks
[03:56] <vorlon> but that should be confirmed by looking at the archive, I guess
[03:56] <pushkarnk> ack
[04:12] <vorlon> did anybody look at gitbatch/armhf? "but cgo is not enabled" - clearly not caused by glibc, but
[04:37] <vorlon> glibc revdep autopkgtest failures reviewed down to libz, all cleared
[04:38] <vorlon> taking down through m now to review
[04:47] <vorlon> cleared through m
[04:47] <vorlon> afk for a bit
[04:58] <vorlon> ugh why did libtirpc-common 1.3.4+ds-1build1 get left behind in noble release
[04:58] <vorlon> well, fixed that blocker for server image bootstrap on riscv64 now
[04:59] <wgrant> Because libtirpc3 is still published and NBS
[04:59] <vorlon> darnit you're right
[05:00] <vorlon> and fails to show up on the NBS report because noble-updates, sigh
[05:00] <wgrant> Ahh heh
[05:00] <vorlon> well anyway, libtirpc3 is uninstallable now, take that
[05:00] <vorlon> reviewing n-o autopkgtest failuers
[05:00] <wgrant> We must be very close to being able to clear out noble-updates.
[05:01] <vorlon> we're close to being able to freeze the archive for beta, ish
[05:01] <vorlon> clearing it out completely will increase uninstallability count and make britney sadder again, tho
[05:02] <wgrant> Ah, true.
[05:03] <vorlon> vpa1977: I've forgotten what the solution was supposed to be for '507s Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-21-openjdk-s390x/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file: No such file or directory'
[05:03] <vorlon> (nncp/s390x)
[05:05] <vorlon> hmmm nodejs looks quite unhappy yet somehow there's been no discussion of nodejs here since the 27th
[05:06] <vorlon> lots of SIGABRT
[05:09] <vpa1977> vorlon: install openjdk-21-jdk. We have made a patch to issue a warning, but it is merged only in openjdk-22 and -23. Which package is it ?
[05:09] <vorlon> vpa1977: nncp/s390x
[05:10] <vorlon> haha and nodejs itself fails its autopkgtests because it needs distutils
[05:12] <vpa1977> vorlon: ah, no, also in -21: 507s Please install the openjdk-*-jre package or recommended packages for openjdk-*-jre-headless.
[05:13] <vpa1977> plantuml needs upload - change binary dependency to -jre
[05:19] <vorlon> n-o cleared
[05:21] <vorlon> checking p-q
[05:32] <vorlon> cleared p-q, and calling it there; still plenty of test failures of various stripes but nothing pointing to a glibc regression and nothing to block on at this point. hinting glibc
[05:33] <vorlon> stopping current britney and restarting
[05:39] <vorlon> seeing chroot upgrade failures on amd64 that seem likely to be due to systemd depending on libssl3 instead of libssl3t64, so uploading
[05:48] <vorlon> hinting at-spi2-core (unblocks gnome-shell)
[06:03] <upils> vorlon, libvirt 10.0.0-2ubuntu7 is now back in release (main). Can we remove the 10.0.0-1ubuntu1 version from updates?
[06:19] <upils> I just read the IRC logs, so forget about it vorlon, I understand the removal will have to wait
[06:28] <vorlon> flushing the remainder of glibc out of the queues, requeuing retries for remaining blocking tests
[06:28] <vorlon> upils: good morning. is libvirt in -updates blocking something?
[06:32] <upils> googd morning :). No, but I suspected having a "older" version in updates vs main could be problematic
[06:32] <upils> *good
[06:43] <vorlon> juliank: after jettisoning the rest of the queued tests for glibc, we're down to ~1000 tests total in the queue now, which is all the tests for all the seeded packages currently in -proposed.  What should be the next thing in the queue?
[06:43] <vorlon> that includes both --all-proposed retries of failed tests (in regular queue) and --all-proposed give-backs of 'running' tests (in huge queue)
[06:48] <vorlon> hmm systemd takes 4 hours to build on riscv64; not waiting that long for a fix for amd64, hinting harder
[06:51] <vorlon> juliank: my inclination is to next load up --all-proposed retries of all other failed tests not tied to seeded packages, then retries of running tests that were dumped from the queue, both of these in the huge queue; wdyt?
[06:51] <vorlon> the latter should not be done on amd64+armhf due to lack of deduping for --state=RUNNING
[07:00] <vorlon> well the uninstallable count on amd64 is down below the uninstallable count on armhf, so that's progress.  Unfortunately that includes noble-updates tho
[07:06] <vorlon> dbungert: I notice that https://people.canonical.com/~dbungert/ausrede/permafail.log includes packages that already have amd64 packages in the release pocket; e.g. bash which had to have a no-change rebuild in -proposed but whose release version was actually ok from before xz-utils. I guess we really want to filter the list for packages currently missing amd64 in the release pocket, rather than
[07:06] <vorlon> just using the original list of bad packages
[07:06] <vorlon> hmm britney thinking really, really hard right now about whether to remove libnorm1/amd64 :P
[07:07] <vorlon> "really hard" as in for the past 10 minutes
[07:08] <vorlon> and as in 100% CPU
[07:08] <vpa1977> uploaded plantuml.
[07:15] <vorlon> hinting cairo
[07:15] <vorlon> britney finally unstuck
[07:33] <vorlon> hinting librsvg
[07:34] <vpa1977> update excuses seems a bit strange, e.g. for cmake: alglib is listed as in-progress, but the last time the test was run is 31 of march also nothing is queued https://autopkgtest.ubuntu.com/packages/a/alglib/noble/amd64 -
[07:36] <vorlon> hinting policykit-1
[07:37] <vorlon> vpa1977: I think there's a race condition where tests have finished so drop out of 'running' but don't show up yet in the results
[07:37] <vpa1977> alglib is more than 1 week old ...
[07:37] <vorlon> oh
[07:38] <vorlon> well yes, we dropped all 'in progress' tests for packages that aren't seeded
[07:38] <vpa1977> for cmake magic-enum/0.9.5-2 was not triggered.
[07:38] <vorlon> cmake is not seeded on any images
[07:38] <sil2100> o/
[07:38] <vorlon> so we should retry all "in progress" tests for cmake
[07:39] <vorlon> doing now
[07:39] <vpa1977> I think there is a bug somewhere, I tried it and the test does not appear in the queue
[07:39] <vpa1977> since it is already in progress
[07:39] <vorlon> how did you requeue it?
[07:39] <vorlon> I'm doing: retry-autopkgtest-regressions --all-proposed --state=RUNNING |grep cmake | xargs -rn1 -P10 curl --cookie ~/.cache/autopkgtest.cookie -o /dev/null --silent --head --write-out '%{url_effective} : %{http_code}\n'
[07:40] <sil2100> How are we looking? Did anyone find any real issues with the new glibc?
[07:40] <vorlon> sil2100: I called it at 'q' and hinted glibc
[07:40] <sil2100> I see a skiptest \o/
[07:40] <vpa1977> vorlon: similar - just output chromium <url> to a shell script
[07:40] <vorlon> there are still reported regressed tests later in the alphabet visible in update_excuses if someone wanted to look at them
[07:41] <sil2100> vorlon: btw. you mentioned there not being that much ubuntu7 tests but I disagree. When working from a to e maybe even half of the running/regressed tests had passes for ubuntu7
[07:41] <sil2100> Anyway, good that we're letting it through
[07:42] <vorlon> sil2100: yeah there was some work later in the evening to try to identify which tests had no pass with either ubuntu7 or ubuntu8; but I noticed some things missing so didn't end up working from that list but visually checking in the browser
[07:42] <vorlon> vpa1977: my attempts to queue these tests appear to be working
[07:43] <vpa1977> vorlon: I do not see alglib in the list of queued tests at https://autopkgtest.ubuntu.com/running
[07:43] <vorlon> vpa1977: well my requeuing is still in progress maybe that's why
[07:43] <vpa1977> vorlon: ack. Sorry :(
[07:44] <vorlon> I can at least confirm that the number of references to 'cmake/' is currently increasing :)
[07:44] <vpa1977> ah, here it is =) alglib {"all-proposed": "1", "requester": "vorlon", "submit-time": "2024-04-05 07:40:52", "triggers": ["cmake/3.28.3-1build6"], "uuid": "1f486378-9113-49ee-8e45-b7064453244e"}
[07:47] <andersson1234> update_excuses seems to have not updated for over three hours
[07:48] <vorlon> andersson1234: I killed one in-progress run to let glibc through; and the current run is taking a strangely long time on deciding whether or not to remove particular individual binaries
[07:48] <vorlon> I don't know what that's about really
[07:54] <vorlon> sil2100: ok here's roughly what the path to an installable ubuntu-desktop looks like right now: https://paste.ubuntu.com/p/KWCmDcXRBB/
[07:54] <vorlon> note that I've just hinted at-spi2-core, cairo, librsvg, policykit-1
[07:55] <vorlon> looking now at gobject-introspection
[07:56] <sil2100> I'll poke people on the first standup to also contribute and then I'll join you
[07:57] <vorlon> hinting gobject-introspection
[07:59] <vorlon> andersson1234, sil2100: fwiw I think we're at the point now that noble-updates is confusing britney and slowing it down unnecessarily wrt binary package removals.  If someone wanted to patch britney to not look at -updates for the devel series, that would likely speed up subsequent runs today
[08:00] <sil2100> vorlon: I can try looking o/
[08:00] <vorlon> looking at man-db
[08:00] <juliank> vorlon: fwiw, I regularly patch my retry script to look for dupes in the queues for RUNNING tests too, that's how I found the bug :D
[08:00] <vorlon> aha
[08:00] <vorlon> juliank: meanwhile, I've gone as far as retrying all the failed tests for all packages
[08:01] <juliank> Sounds alright
[08:01] <vorlon> I leave it to you to work with Europe folks to sort out queuing of the non-seeded RUNNING tests
[08:01] <juliank> I'm not sure why we explicitly disable the dedup of running tests
[08:02] <vorlon> hinting man-db because no I don't believe it regressed lintian or apparmor :P
[08:02] <vorlon> sil2100: and hinting at-spi2-core should also unblock gnome-shell ftr
[08:03] <juliank> Ooh gnome-shell would be nice
[08:04] <vorlon> eh. libplist3 means rebuilds against libplist-2.0-4, triggering now
[08:05] <vorlon> looking at libgudev
[08:05] <vorlon> hinting libgudev
[08:06] <vorlon> looking at pygobject
[08:07] <sil2100> Ok, standup over, foundations people should be popping up to help in a moment, looking at britney
[08:07] <vorlon> hinting pygobject
[08:08] <vorlon> libhandy-1 also unblocked by at-spi2-core
[08:09] <vorlon> looking at webkit2gtk
[08:09] <vorlon> hinting
[08:10] <vorlon> looking at vte2.91
[08:10] <vorlon> already hinted and only blocked by at-spi2-core
[08:11] <vorlon> yelp unblocked by at-spi2-core
[08:11] <pushkarnk> vorlon: are we referring to https://paste.ubuntu.com/p/KWCmDcXRBB/ or is there another list?
[08:11] <vorlon> pushkarnk: that's what I'm working off
[08:12] <pushkarnk> thx
[08:12] <vorlon> am confused by rfkill, I thought we already pushed util-linux through
[08:13] <vorlon> ok I said I was hinting util-linux but seems missing from the hints repo, gar; hinting for real now
[08:15] <vorlon> gnome-control-center is already a candidate but blocked by samba apparently regressing installability
[08:16] <vorlon> could somebody look into this please ^
[08:17] <vorlon> sssd is related, hinting that to ignore noble-updates
[08:18] <vorlon> hinting ubuntu-advantage-desktop-daemon
[08:19] <vorlon> hinting shared-mime-info
[08:20] <vorlon> afk for a bit and waiting for britney
[08:21] <vorlon> fwiw llvm-toolchain-17 probably needs a force hint since riscv64 is still building
[08:23] <sil2100> vorlon: ok, trying to wrap my head around britney code - where is the slowdown exactly so that I know where to start? Are we talking britney2 or britney1?
[08:23] <vorlon> sil2100: I do not know
[08:23] <pushkarnk> looking at samba
[08:23] <sil2100> ...digging further then!
[08:25] <ravikant_> pushkrank: samba vs freedombox, I looked at armhf history, tests pass.
[08:25] <ravikant_> samba vs adsys, test retried.
[08:26] <vorlon> samba is already skiptest hinted, the test results don't matter what matters is why it shows regressions in installability on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output.txt
[08:26] <pushkarnk> ack
[08:26] <ravikant_> vorlon: ack
[08:26] <vorlon> specifically, why does promoting it make libsmbclient and smbclient uninstallable
[08:26] <vorlon> since these are from the same package
[08:27] <pushkarnk> so, shouldn't that unblock gnome-control-center?
[08:27] <vorlon> yes, once samba is actually migratable without increasing the uninstallable count which is what happens now
[08:29] <pushkarnk> ok
[08:29] <pushkarnk> ok
[08:30] <sil2100> Ok, I think I found *something* in b1, just need to understand better if that's indeed what can disable -updates consideration
[08:31] <vorlon> I: [2024-04-05T08:30:26+0000] - trying: glibc
[08:31] <vorlon> progress
[08:31] <sil2100> \o/
[08:32] <vorlon> I: [2024-04-05T08:31:16+0000] - accepted: glibc
[08:32] <vorlon> I: [2024-04-05T08:31:16+0000] -    ori: 4449+0: a-1308:a-433:a-1869:i-108:p-257:r-240:s-234
[08:32] <vorlon> I: [2024-04-05T08:31:16+0000] -    pre: 2886+0: a-846:a-355:a-1127:i-9:p-187:r-186:s-176
[08:33] <pushkarnk> gnome-autoar seems to be blocked by libarchive, taking a look
[08:34] <pushkarnk> ah cmake
[08:35] <vpa1977> [Errno 2] No such file or directory: '/run/amqp-status-collector/running.json'
[08:35] <vpa1977> autopkgtest died?
[08:35] <upils> QA explained this issue yesterday on MM and should have deployed a fix for it
[08:35] <vorlon> vpa1977: rabbitmq did. is that current?
[08:36] <vorlon> andersson1234: ^
[08:36] <vpa1977> vorlon: it was just restarted
[08:36] <vorlon> k
[08:36] <pushkarnk> afk
[08:37] <LocutusOfBorg> vorlon, FYI mpg123 needs a transition, I'm driving it
[08:38] <vorlon> LocutusOfBorg: ack, thanks (had earlier backed out mpg123 to let the previous version migrate and unbreak amd64)
[08:38] <vorlon> LocutusOfBorg: btw I saw a lot of node-* packages whose autopkgtests were dying with SIGABRT, is nodejs in -proposed in decent shape?
[08:39] <vorlon> britney finishing now
[08:43] <pushkarnk> ok, libarchive is hinted
[08:44] <pushkarnk> so gnome-autoar should sail through
[08:44] <pushkarnk> and perhaps gnome-shell-extension-desktop-icons-ng
[08:45] <vorlon> libarchive is not hinted?
[08:45] <vorlon> hmmm another case of me claiming I was hinting but failing!
[08:45] <vorlon> hinting now
[08:45] <pushkarnk> it is, you hinted it
[08:46] <pushkarnk> (I meant I saw it in the IRC logs :) )
[08:46] <vorlon> pushkarnk: I *said* I hinted it but there was no hint in the hint repo, so thanks for pointing this out
[08:47] <vorlon> pushkarnk: if I had actually committed it 8 hours ago you should've seen a line about this in update_excuses ;)
[08:47] <pushkarnk> oh, right
[08:50] <upils> should we also hint mutter to unblock gnome-shell?
[08:52] <vorlon> mutter is blocked only by at-spi2-core which has been hinted
[08:53] <upils> so it should now migrate at the next run?
[08:53] <vorlon> yes
[08:53] <upils> ok thanks
[08:53] <pushkarnk> accountsservice is blocked by ayatana-indicator-session for which tests have recently passed
[08:54] <pushkarnk> so that should hopefully unblock language-selector-common
[08:56] <sil2100> grrr, why can't I push my bzr branch
[08:57] <upils> can I see somewhere when will be the next britney run?
[08:57] <vorlon> upils: it's triggered every 2 minutes, there's one running now
[08:57] <vorlon> the completion time however is variable
[08:57] <schopin> I'm wondering if there isn't a britney running right now?
[08:58] <upils> where can I check this?
[08:58] <upils> vorlon, thanks
[08:58] <sil2100> grrr, LP down?
[09:04] <schopin> Bots are resurrected!
[09:05] <sil2100> Back to the grind everyone! ;)
[09:06] <schopin> sil2100: there a potential glibc regression, would you rather have me investigating it or focus on overall migration?
[09:06] <sil2100> schopin: what do you mean by regression?
[09:07] <sil2100> I'd prefer overall migration, but also depends on how big of a regression we talking right now
[09:07] <schopin> Dunno yet, glibc vs fastqtl filed by steve. Only on armhf though, so I think it can wait.
[09:12] <juliank> Everything that's seeded has a Task field :D
[09:12] <andersson1234> autopkgtest is back.
[09:12] <philroche> indeed when trying to install that version of coreutils I get error `coreutils breaks usrmerge (<< 39)`
[09:13] <ravikant_> I am looking at uninstallable packages, the list (Newly uninstallable packages in the target suite:) is empty. https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output.txt
[09:13] <juliank> I wanted to do the /lib.usr-is-merged -> /.lib.usr-is-merged and so on renames for the diversions for merged-usr for the beta but frankly I did not get to it
[09:15] <juliank> Report for uninstallable release binaries is ready now: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/release-binaries.txt
[09:15] <juliank> But surprisingly it only shows you libc6
[09:15] <juliank> well perhaps unsurprisingly
[09:16] <juliank> So waiting for publisher run with the glibc published and it should get actionable insights hopefully
[09:16] <schopin> isn't glibc hinted in the current britney run?
[09:16] <juliank> It migrated yesa
[09:16] <juliank> Not published yet
[09:16] <schopin> BTW has someone checked that it's still running despite the LP issues?
[09:16] <andersson1234> looking at policy-kit1 vs colord
[09:39] <vpa1977> gnome-shell fails to install
[09:39] <ravikant_> vpa1977: ok, I'll try gnome-shell and go from there.
[09:41] <juliank> FWIW, if we do this again, stage old packages in -security instead of -updates so that the UEFI signing pipeline can still build signed artefacts :D
[09:44] <sil2100> I think LP is back
[09:46] <juliank> people.canonical.com is back too
[09:47] <juliank> even mattermost is
[09:47] <sil2100> b1 change pushed, -updates should be ignored by britney now (hopefully)
[09:48] <juliank> FWIW I haven't mentioned this yet, but I'd be interested in for 24.10 changing seeding to not add Task: field to dependencies of seeds, and only to explicitly seeded packages :)
[09:49]  * juliank is distracting a bit, sorry
[09:49] <schopin> sil2100: does that mean that future excuses reports will show the installability issues we're hunting for?
[09:49] <upils> sil2100, and does that mean a new report is running?
[09:50] <schopin> juliank: I wouldn't get my hopes up on the actual resolution of the incident, it has flickered a couple of times already.
[09:50] <sil2100> I'm checking right now, since previous britney run of course had timeout issues
[09:50] <sil2100> Maybe best to just kill b2 and wait for a rerun
[09:51] <sil2100> Yeah, it was hanged, killed and waiting for the next run
[09:56] <upils> so right now the last missing piece of the puzzle to install ubuntu-desktop is gnome-shell, which should be unblocked at the next britney run, correct?
[10:02] <sil2100> I did not check the status just yet, let me see
[10:04] <juliank> 24.10 action item: Move britney from cronjob to systemd timer
[10:04] <juliank> Then you can just restart britney2.service :D
[10:04] <sil2100> Okay, high chances are that gnome-shell will migrate soonish indeed, I see it was blocked by at-spi2-core which was hinted
[10:04] <ravikant_> I was able to install gnome-shell/46.0-0ubuntu3.1 in a noble chroot.
[10:05] <sil2100> ravikant_: \o/ without -proposed?
[10:05] <ravikant_> yes
[10:05] <juliank> it at least needs mutter from proposed
[10:05] <ravikant_> I do not have proposed enabled in apt sources.
[10:06] <upils> which should be unblocked too due to the hint on  at-spi2-core
[10:06] <sil2100> ravikant_: so how did you install gnome-shell 46.0-0ubuntu3.1 which is in -proposed
[10:06] <upils> so, what is next?
[10:07] <ravikant_> sil2100: apt install gnome-shell, and then verified version with dpkg -l|grep -i gnome-shell
[10:08] <sil2100> And without -proposed enabled it pulled in 46.0-0ubuntu3.1 for you?
[10:09] <ravikant_> I may have done something wrong. This is the same chroot I use for sbuild noble-amd64.
[10:09] <ravikant_> I entered using schroot -c noble-amd64 -u root and simply ran apt update and apt install ...
[10:11] <schopin> ravikant_: we usually have -proposed enabled in our sbuild (since we want to stay close to the buildd configuration)
[10:12] <ravikant_> sorry, I am looking at apt logs, it did pull some things from -proposed.
[10:12] <ravikant_> let me disable -proposed and try again.
[10:15] <sudip> bdrung: added a debdiff in LP: #2060214 for the ftbfs you mentioned yesterday
[10:15] -ubottu:#ubuntu-release- Launchpad bug 2060214 in mtd-utils (Ubuntu) "mtd-utils 1:2.1.6-1build1 FTBFS" [Undecided, Confirmed] https://launchpad.net/bugs/2060214
[10:18] <bdrung> thanks sudip. i'll sponsor it.
[10:19] <sudip> thanks
[10:25] <sil2100> ...is LP having problems again? Britney is timing out on LP calls
[10:26] <bdrung> ask on #launchpad - we had issues some time ago today
[10:27] <sil2100> I know we did
[10:28] <sil2100> (as per the backlog here ^)
[10:29] <sil2100> Guessing it's the haproxy outage
[10:32] <schopin> ... meanwhile in #launchpad someone said it appears to be back up again.
[10:32] <danilogondolfo> the internal dashboard is not showing anything weird I think
[10:33] <schopin> do you mean status.c.c? Because it was all green while MM was still down.
[10:34] <danilogondolfo> no, the grafana dash
[10:34] <danilogondolfo> weeeel now it kinda is showing weird things
[10:36] <sil2100> Ok, I think the haproxy bit is sorted, I can access git from the toolbox
[10:36] <lotuspsychje> (just for info, we added canonical status rss to #techrss for those who are interested)
[10:36] <sil2100> Fingers crossed that that's enough to get britney moving forward
[10:38] <schopin> Is there a way for us mere mortals to follow britney's progress?
[10:39] <sil2100> eh, only looking at the logs, but I noticed there's always a lag for those being synced to http
[10:39] <ravikant_> creating new noble chroot fails for me with "chroot: failed to run command '/bin/true': No such file or directory"
[10:39] <sil2100> So aka https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/noble/2024-04-05/
[10:40] <schopin> even if laggy, I'll take it.
[10:43]  * juliank is waiting for glibc to be published
[10:43] <juliank> As of release Release file: Fri, 05 Apr 2024  8:21:29 UTC
[10:44] <sil2100> eh, still timeouts?!
[10:44] <juliank> I don't think the issues are fully resolved yet
[10:44] <juliank> There are network losses across PS5 or something
[10:44] <juliank> Hence sometimes it oopses out
[10:48] <sil2100> It consntantly oopses out, I think it might be on some LP API queries. Sadly, b1 is a confusing beast. Trying some of its inline python commands
[10:50] <schopin> you've mentioned b1 and b2 already. Are those the hosts where britney run?
[10:51] <sil2100> No, it's shorthand for britney1 and britney2
[10:51] <sil2100> britney2 is the one that runs autopkgtests and policies, but it's started by britney1 which is much older and a mess of bash+python code
[10:53] <sil2100> ...okay, I think it's indeed a typical infra issue, since I get the same failure locally here (so not proxy related)
[10:55]  * ravikant_ breaking for lunch
[11:02] <sil2100> eh, it's infra flakyness
[11:03] <sil2100> I'm thinking of temporarily disabling excuse bugs
[11:03] <schopin> +1 on that.
[11:07] <sil2100> Problem is, the same queries are needed for blocking bugs
[11:07] <sil2100> And disabling those might be dangerous..? I guess?
[11:08] <schopin> It would, but I'd still disable excuse bugs. Since the issues seem to be intermittent we might get lucky and get through.
[11:08] <sil2100> +1, I actually see we had a few cases of going through the blocks successfully
[11:08] <sil2100> On it
[11:11] <sil2100> Disabled
[11:13] <schopin> Crossing fingers.
[11:19] <sil2100> britney passed the LP API queries \o/
[11:19] <sil2100> It's running!
[11:20] <schopin> 🎉
[11:36] <sil2100> Not sure how promising it is or not, but when I run `apt install ubuntu-desktop perl gnome-shell/noble-proposed gir1.2-mutter-14/noble-proposed gnome-shell-common/noble-proposed mutter-common/noble-proposed mutter-common-bin/noble-proposed`, it seems to proceed correctly - which really makes me feel like gnome-shell (+ mutter) is the only hting left to unblock ubuntu-desktop
[11:40] <sil2100> Okay, I'll keep monitoring ubuntu-desktop, in the meantime I need to get back to a few other work-items. Please continue looking at installability problems
[11:50] <sil2100> hm, I'll retrigger some no-livefs ubuntu-server builds, since I see those should have been working
[11:50] <sil2100> MIght be the outage breaking those
[11:51] <sil2100> ah, no, chroot problem
[11:51] <sil2100> Firing amd64 only
[11:55] <LocutusOfBorg>  libsdl2-mixer-dev | 2.8.0+dfsg-1build3  | noble-proposed/universe | amd64, arm64, i386, ppc64el, riscv64, s390x
[11:55] <LocutusOfBorg> meh, armhf finished almost 4h ago
[11:55] <LocutusOfBorg> still not there... any issue?
[11:58] <sil2100> Maybe due to the outage?
[11:59] <LocutusOfBorg> question is: will it auto heal?
[12:00] <LocutusOfBorg> also interesting, ffmpeg is not shown on this transition tracker https://ubuntu-archive-team.ubuntu.com/transitions/html/auto-mpg123.html
[12:13] <sil2100> ugh, wait, what?
[12:13] <sil2100> The following packages have unmet dependencies:
[12:13] <sil2100>  init : PreDepends: systemd-sysv but it is not going to be installed
[12:17] <upils> sil2100, tested with proposed or not?
[12:17] <upils> I do not know if this is a reliable way to check but the package is still present https://launchpad.net/ubuntu/noble/amd64/systemd-sysv/255.4-1ubuntu6
[12:17] <sil2100> That's without, should be fine since we migrated systemd to release 16 hours ago
[12:18] <sil2100> Yes, but that one seems to be a time_t change, while this is on amd64
[12:19] <sil2100> I don't know how the buildd's work exactly, but maybe it's a problem with them?
[12:20] <upils> you meant the package I linked?
[12:20] <sil2100> Yes
[12:20] <sil2100> Ah, no
[12:21] <sil2100> nvm, I misunderstood, anyway, trying to figure out what's wrong
[12:23] <sil2100> I don't see any obvious installability problems on my chroot
[12:24] <sil2100> I'll check the update-debian-chroot code to see what it's actually doing
[12:29] <upils> I also tried a debootstrap. It fails with:
[12:29] <upils> libsemanage2:amd64 depends on libaudit1 (>= 1:2.2.1); however:
[12:29] <upils>   Package libaudit1 is not installed.
[12:29] <upils> I thought vorlon hinted audit
[12:32] <sil2100> huh, checking, indeed it's still in -proposed
[12:32] <upils> what does it mean when a package is a "candidate" on the excuses (by team) page?
[12:32] <sil2100> upils: ok, so I see it's a fresh thing, should migrate next run
[12:33] <sil2100> Because of the outage we didn't have full runs yet
[12:33] <sil2100> aha
[12:33] <sil2100> Of course britney crashed
[12:33] <sil2100> AssertionError: NUNINST OUT OF SYNC
[12:33] <sil2100> I don't even know what NUNINST is!
[12:34] <cjwatson> "number uninstallable" IIRC
[12:34] <cjwatson> why it might be out of sync I have no idea
[12:35] <ahasenack_> do we know if we will have to do some sort of dump/reload of databases hosted on armhf when ugprading to noble, due to the time_t size change?
[12:36] <ahasenack_> and any kind of persisted binary data
[12:36] <sil2100> It's crashing constantly, trying to figure out where that's coming from
[12:37] <sil2100> Hope it's not because of our change to ignore -updates
[12:37] <sil2100> I'm feeling maybe just-in-case I should revert that
[12:44] <sil2100> I reverted that, seeing that it was one of the few changes we did
[12:47] <danilogondolfo> I'm also seeing these "504: Gateway Time-out" from our github workflows when trying to reach PPAs...
[12:50] <dbungert> vorlon: ack, I'll look into it
[12:51] <sil2100> I don't know what the notest run is doing
[12:51] <sil2100> I mean, the current notest run
[12:51] <sil2100> Since it feels a bit stuck
[12:51] <sil2100> I'd love for britney to be a bit more verbose, now I don't know if I should kill it or give it a moment still
[12:51] <jbicha> mutter/gnome-shell causing ubuntu-desktop uninstallability was left over from the time_t transition
[13:05] <sil2100> huh, I don't understand this
[13:05] <sil2100> Somehow the notest run now succeeded, but the regular run failed again on nuninst list
[13:06] <sil2100> I'
[13:06] <sil2100> I'm leaving the revert in place for now
[13:07] <sil2100> THe run will be slower but at least minus one possible case of what could cause the crash
[13:07] <sil2100> vorlon: ^
[13:30]  * sil2100 afk for lunch
[13:31] <sil2100> (britney still going, fingers crossed that this time no nuninst issue)
[13:37] <andersson1234> we recently had an issue that had our armhf autopkgtest throughput affected - for the last couple hours. The issue should be amended soon
[13:45] <juliank> https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/release-binaries.txt now has everything blocked on libaudit1 fwiw
[13:46] <juliank> which should migrate next run?
[13:46] <juliank> should have migrated?
[13:47] <upils> it should next run yes, see above
[13:48] <juliank> I don't see anythign above
[13:48] <juliank> It was supposed to migrate, but migration failed as it increased uninstallability count
[13:49] <juliank> It's not like it didn't try
[13:49] <upils> We talked about libaudit1 with sil2100 and came to the conclusion it should indeed migrate and that it is currently blocking (I tried to run debootstrap)
[13:49] <juliank> trying: audit
[13:50] <juliank> skipped: audit (1110, 14, 491)
[13:50] <juliank>     got: 2924+0: a-868:a-356:a-1141:i-9:p-187:r-187:s-176
[13:50] <juliank>     * amd64: libauparse0
[13:50] <juliank> But it didn't
[13:50] <juliank> This isn't down to some launchpad errors, it skipped it
[13:50] <schopin> I can't really parse this :/
[13:50] <juliank> trying: -libaudit1/amd64
[13:50] <juliank> skipped: -libaudit1/amd64 (1110, 15, 490)
[13:51] <juliank>     got: 10004+0: a-7948:a-356:a-1141:i-9:p-187:r-187:s-176
[13:51] <juliank> Who can really say they can read that?
[13:51] <schopin> If nobody can read this why do we bother printing it out?
[13:51] <juliank> schopin: Oh v orlon can
[13:51] <cjwatson> That's odd, that's complaining that it makes libauparse0 uninstallable, but the version of audit in -proposed only has libauparse0
[13:52] <cjwatson> er only has libauparse0t64, I mean
[13:52] <cjwatson> but libauparse0 has an exact dependency on libaudit1, ugh
[13:52] <juliank> They are all in the same source package
[13:52] <cjwatson> so it's true, it does make installability worse, but there may not be much that can be done other than force it through and work to get libauparse0 to NBS
[13:52] <juliank> I guess it's unhappy because libauparse0 is in updates
[13:53] <cjwatson> yeah, I can imagine that causing some confusion
[13:53] <juliank> It should be fine because libauparse0t64 provides libauparse0
[13:53] <juliank> but britney may be confused
[13:54] <juliank> forcing it through with an force hint probably is a nice idea
[13:54] <cjwatson> I guess britney1 mustn't be setting things up quite right for britney2 to treat "testing" as the union of noble and noble-updates
[13:54] <cjwatson> (I think that's the division of labour here)
[13:54] <juliank> yes it pulls -updates into data/noble
[13:54] <juliank> normally that's fine
[13:54] <schopin> there aren't that many rdeps on libauparse0 outside of src:audit
[13:55] <cjwatson> schopin: there must be none otherwise they would be listed in that "* amd64:" line
[13:55] <cjwatson> schopin: that means "these packages would be made uninstallable on amd64 by this change"
[13:55] <cjwatson> none, or only ones that are also happy with the Provides, anyway
[13:55] <juliank> Anyway normally -updates should be part of "testing" as that's where packages migrate in the releases
[13:56] <cjwatson> yeah, I guess this must be basically confusion when the set of binary package names between noble and noble-updates aren't the same
[13:56] <cjwatson> weird special-case situation, best to force
[13:57] <cjwatson> like, in a stable release you wouldn't want to make packages in the release pocket uninstallable
[13:57] <cjwatson> but in this situation it's fine if they're going to be NBS afterwards
[13:57] <juliank> sil2100: did reverting the "not use -updates" https://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/389 actually help?
[13:58] <juliank> or can it be reverted again?
[14:01] <juliank> Arguably with the infrastructure being whacky and britney's last successful run being 8 hours ago, maybe just whack audit into the release pocket with copy-package
[14:02] <schopin> I can't help but think that could potentially make things worse.
[14:02] <juliank> Because I can generate new reports that will tell me the next biggest uninstallability
[14:02] <juliank> schopin: It's no different from whacking it in with a force hint, just faster
[14:10] <juliank> total-packages: 69227
[14:10] <jbicha> yay, more things are migrating (mutter etc)
[14:10] <juliank> broken-packages: 68866
[14:10] <juliank> FWIW, how much worse can it get
[14:12] <juliank> total-packages: 8620
[14:12] <juliank> broken-packages: 265
[14:13] <juliank> Running only on main, with -updates enabled
[14:14] <juliank> total-packages: 8626
[14:14] <juliank> broken-packages: 265
[14:14] <juliank> pushing in src:audit
[14:15] <juliank> release pocket only, migrating src:audit:
[14:15] <juliank> total-packages: 5750
[14:15] <juliank> broken-packages: 1745
[14:16] <juliank> before src:audit:
[14:16] <juliank> total-packages: 5744
[14:16] <juliank> broken-packages: 5744
[14:16] <juliank> oh
[14:16] <juliank> I guess I should pass --latest 1
[14:17] <juliank> total-packages: 8620
[14:17] <juliank> broken-packages: 164
[14:17] <juliank> with updates
[14:17] <jbicha> there are several packages listed as "missing build on i386" like pidgin-gnome-keyring which should not have been built on i386 noble-updates (no rdepends!) & it looks like the hint is not strong enough
[14:18] <jbicha> also affects some with "missing build on armhf"
[14:18] <juliank> With audit:
[14:18] <juliank> total-packages: 8626
[14:18] <juliank> broken-packages: 164
[14:18] <juliank> (and updates)
[14:18] <juliank> release pocket:
[14:18] <juliank> total-packages: 5744
[14:18] <juliank> broken-packages: 5646
[14:19] <juliank> migrating audit:
[14:19] <juliank> total-packages: 5750
[14:19] <juliank> broken-packages: 1731
[14:19] <juliank> I'll go write a helper
[14:20] <juliank> i.e. you can have a script try-migrate and it will run dose-distcheck with packages migrated before and after and show you new unsat?
[14:25] <jbicha> juliank: I want to add your suggested Breaks to gst-plugins-good1.0 (once it migrates) but I'm having trouble finding your list
[14:31] <juliank> jbicha: Breaks: libv4l-0 (<< 1.26.1-4build1) to gstreamer1.0-plugins-good
[14:31] <juliank> Breaks: libv4lconvert0 (<< 1.26.1-4build1) to either libv4l-0t64 or gstreamer1.0-plugins-good; otherwise it tries to keep back libv4l-0 instead of removing libv4lconvert0 in favor of libv4lconvert0t64
[14:31] <juliank> [201~
[14:34] <jbicha> new excuses page posted
[14:36] <sil2100> Back
[14:36] <sil2100> Looks like it helped!
[14:37] <sil2100> Did the new gnome-shell migraet?
[14:38] <jbicha> sil2100: yes
[14:38] <sil2100> ...yes! Just probably needs publishing
[14:38] <sil2100> \o/
[14:38] <sil2100> aka. a full publisher run
[14:38] <mclemenceau_> good to hear
[14:39] <schopin> \o/
[14:40] <sil2100> hm, so audit didn't migrate yet, wonder what happened
[14:40] <schopin> see backlog
[14:40] <schopin> I didn't really understand, but the tl;dr is that it might be easier to just force it through.
[14:41] <sil2100> Checking
[14:43] <sil2100> hm, indeed interesting, I don't see a 'Moving' entry for it
[14:45] <sil2100> Wonder if a force hint will help
[14:46] <sil2100> juliank: are we sure that it's just britney being confused with audit?
[14:48] <sil2100> hm, in theory I wonder if we can double check the crashed logs of the non-updates runs to see if audit is fine there
[14:51] <jbicha> juliank: may I use Breaks: libv4l-0 (<< 1.46.1-4~) instead? (so it can be pushed to Unstable)
[14:54] <juliank> sil2100: yes, looking just at the release pocket, no new uninstallabilities appear
[14:54] <juliank> sil2100: Checking release +updates now (for the whole archive, main only is above already)
[14:55] <juliank> sil2100: Yes full archive release + updates also does not regress
[14:55] <sil2100> Ok, looking at update_output and checking in a chroot seems to be good, since update_output had python3-audit mentioning issues
[14:55] <sil2100> But it looks fine
[14:55] <sil2100> Ok then, forcing and actally doing the copy-package
[14:56] <juliank> I created a Packages file containing src:audit from proposed and ran dose-distcheck
[14:56] <juliank> :D
[14:56] <juliank> This is just super slow so not the best analysis tool :)
[14:56] <sil2100> But first, does audit have anything in -proposed that needs to go with it?
[14:56] <juliank> No
[14:56] <juliank> Well not on amd64 at least
[14:56] <sil2100> Then time to commando this shit!
[14:57] <ravikant_> XD
[14:57] <schopin> Do we know if the LP wonkiness is over?
[14:59] <juliank> OK my script for full archive analysis was broken, but main at least was happy
[14:59] <sil2100> Copies requested
[14:59] <juliank> 68866 broken packages down to 23398
[15:00] <juliank> And yup release+updates remains at 542 broken ones
[15:01] <schopin> juliank: is that before or after this afternoon's migration?
[15:01] <sil2100> That's a nice improvement. Now hoping that the reminder 23398 ones are not any that are seeded!
[15:01] <juliank> This is the live state of launchpad archive
[15:01] <juliank> I'm literally using whatever the publisher currently has
[15:01] <juliank> by using snapshot.ubuntu.com/ubuntu as the mirror
[15:02] <juliank> Python's yaml parser is super slow is there a faster one
[15:02] <schopin> ah so if I use that mirror I won't have to wait for the publisher run?
[15:02] <juliank> Well you need to wait for the publisher run
[15:02] <schopin> juliank: you can tell it to use libyaml instead of the default pure Python implementation.
[15:02] <juliank> how?
[15:03] <juliank> What you don't need to wait is the mirror run :)
[15:03] <schopin> > In order to use LibYAML based parser and emitter, use the classes CParser and CEmitter.
[15:04] <ogayot> juliank: yaml.load(..., Loader=yaml.CSafeLoader) if you wan't to keep the "safe" aspect
[15:06] <dbungert> I think that's still OK - "SafeLoader(stream) supports only standard YAML tags and thus it does not construct class instances and probably safe to use with documents received from an untrusted source"
[15:07]  * sil2100 impatiently waits for audit to publish so he can trigger some image builds for testing
[15:08] <philroche> sil2100: Can you ping when you have successfully built images and I can try the same for cloud images?
[15:09] <sil2100> philroche: sure thing! Not suer about the successfully though ;p
[15:09] <juliank> OK I did not see that but audispd-plugins Depends libgssapi-krb5-2 (>= 1.17) becomes unsatisfiable, but don't ask me why, I think this is a reporting issue .D
[15:09] <sil2100> philroche: let's say I have a low confidence level that even with all this we're ready to successfully build images. Maybe at least to properly start the build, yes
[15:15] <juliank> report after audit migration https://magenta.jak-linux.org/bin/438ca99f33491433c6cc8088b372e814-after-audit.txt
[15:15] <juliank> but it may have missed some other migrations
[15:15] <juliank> (i.e. I fake migrated audit)
[15:15] <juliank> Probably should only list seeded packages
[15:17] <juliank> certainly better than before: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/release-binaries.txt
[15:19] <philroche> sil2100: understood.
[15:19] <ahasenack_> once https://launchpad.net/ubuntu/+source/sssd/2.9.4-1.1ubuntu5 is published, we can also rebuild autofs and that will close https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/2058964
[15:19] -ubottu:#ubuntu-release- Launchpad bug 2058964 in autofs (Ubuntu) "proposed-migration for autofs 5.1.9-1ubuntu2" [High, In Progress]
[15:30] <juliank> Oh god I see linux-libc-dev
[15:30] <juliank> We don't actually have a kernel in the release pocket
[15:30] <juliank> I guess the images could build with the kernel from updates
[15:30] <juliank> but eww
[15:31] <sil2100> There was some talk about the kernels by vorlon, but I didn't really follow that. So I'd leave it for when vorlon is back
[15:31] <bdrung> https://launchpad.net/ubuntu/+source/linux claims that 6.8.0-20.20 is in the release pocket
[15:32] <bdrung> but not rebuilt since then. Now I get it.
[15:36] <juliank> ok these are the seeded packages in current publisher run + libaudit migration: https://magenta.jak-linux.org/bin/c969889f85df2bbb268302e42e4bca27-after-audit.txt
[15:37]  * juliank tries to migrate krb5
[15:39] <juliank> that needs libverto1t64
[15:40] <juliank> Which needs libevent
[15:41] <schopin> which only started its t64 transition last week.
[15:42] <sil2100> We can ignore the t64 transition for now
[15:42] <juliank> Migrating those 3 only causes 3 new uninstallabilities for amd64 and fixes 4034
[15:42] <sil2100> Let's concentrate on amd64
[15:42] <juliank> (counting I believe only seeded packages)
[15:42] <sil2100> Looking at libevent then
[15:42] <schopin> looking at libevent vs openmpi
[15:44] <juliank> Oh it does count more than seeded packages, I have not finished restricting it to not care about broken unseeded packages
[15:44] <juliank> But it's hard because germinate ran in between and like libaudit1 is without a Task field
[15:45] <juliank> or rather I guess it only runs in the release pocket
[15:45] <juliank> certainly not in proposed
[15:46] <juliank> I guess it depends, sil2100 , do we want to build the beta using packages in -updates, or should all be done for the beta?
[15:47] <juliank> I guess all seeded packages should have migrated to the release pocket
[15:48] <sil2100> I think we need to build out of release, but we can deal with the updates->release migration after we get something building
[15:48] <juliank> So hence release pocket + updates view is kind of irrelevant
[15:48] <schopin> the amd64 openmpi test passes locally
[15:48] <juliank> This is after migrating audit, with -updates included https://magenta.jak-linux.org/bin/f80c802e1ad3ba5062e4cb314048a579-after-audit-updates.txt
[15:49] <sil2100> schopin: excellent, I'll hint it
[15:49] <sil2100> libnfs is unrelaetd
[15:50] <sil2100> I'm looking at krb5 now
[15:50] <juliank> I'd wager images should build now with -updates enabled looking at that report
[15:51] <juliank> Ah but they may not be bootstrappable
[15:51] <sil2100> hm, actually, krb5 is a no-change rebuild and is already skiptesetd
[15:51] <sil2100> So we should be good to go when libevent migrates
[15:51] <sil2100> \o/
[15:52] <juliank> sil2100: i.e. if we can run debootstrap and then have updates we should be able to build images?
[15:53] <juliank> mmdebstrap failed because something pulled in libapt-pkg.60
[15:54] <juliank> ooh I think it is just stupid
[15:54] <juliank> libapt-pkg6.0 should not have important priority but optional presumably because it's a library
[15:58] <juliank> Ah of course I don't think we can build images without freezing the archive and removing mutter from updates
[15:58] <juliank> i.e. we install seeded packages using task^
[15:59] <juliank> i.e. we essentialyl do `apt install ubuntu-desktop^ standard^ minimal^`
[15:59] <juliank> this will expand to libmutter-13-0 which is the old mutter lib
[15:59] <juliank> (in -updates)
[16:00] <sil2100> Are we still using tasks? Not seeds directly?
[16:00] <upils> I thought mutter was supposed to migrate at the last run. Why is it still blocked?
[16:01] <sil2100> We had issues with using tasks always, there was a big push for using seeds or metapackages instead
[16:01] <sil2100> upils: it migrated from what I saw?
[16:01] <sil2100> upils: we're talking about the -updates pocket
[16:01] <sil2100> The -updates pocket, for noble (for the xz transition), has old 'previous version' staged right now
[16:02] <sil2100> So it's not really a real updates pocket, more like a 'revert pocket'
[16:02] <juliank> sil2100: hopefully we are, or expanding ourselves
[16:02] <schopin> juliank: what's the semantic of the ^ suffix? I can't find it in the apt manpage.
[16:02] <juliank> We may be expanding from fresh geerminate itself
[16:02] <juliank> schopin: It matches on the Task: field in the Packages files
[16:02] <sil2100> juliank: I recall mwhudson making some changes to livecd-rootfs at least
[16:03] <juliank> Yeah but it still expands I believe
[16:03] <juliank> otherwise it ends up picking packages from universe potentially
[16:03] <schopin> Ah, and so this'll match both the old and new mutter since it changed binary names.
[16:03] <juliank> ubuntu-desktop is installable in a chroot with release and updates
[16:04] <juliank> To be specific, I can `install ubuntu-desktop ubuntu-standard ubuntu-minimal colord` in an empty chroot with all pockets enabled
[16:04] <jbicha> btw, sugar just migrated even though sugar-session is uninstallable for Debian bug 1063419 (sugar-session is arch: all)
[16:04] -ubottu:#ubuntu-release- Debian bug 1063419 in src:sugar-artwork "sugar-artwork: Please package version 0.121 needed by sugar-session" [Serious, Open] https://bugs.debian.org/1063419
[16:04] <juliank> But proposed at -1
[16:04] <juliank> um 100
[16:04] <juliank> Inst libcdio19t64 (2.1.0-4.1ubuntu1 Ubuntu:24.04/noble-proposed [amd64])
[16:04] <juliank> Inst libcdio-cdda2t64 (10.2+2.0.1-1.1build2 Ubuntu:24.04/noble-proposed [amd64])
[16:04] <juliank> Inst libcdio-paranoia2t64 (10.2+2.0.1-1.1build2 Ubuntu:24.04/noble-proposed [amd64])
[16:04] <juliank> These are the only packages actually pulled in from proposed
[16:05] <sil2100> Ok guys, I need to AFK now, still waiting for audit to be fully published
[16:05] <juliank> Removing proposed entirely works
[16:05] <juliank> So awkward
[16:06] <sil2100> juliank: is there a way for you to check how the installability would look like after audit, krb5, libevent and libverto looks like?
[16:06] <juliank> Indeed
[16:06] <sil2100> Since maybe people could continue on hacking if there's more seeded packages that are uninstallable
[16:06] <sil2100> Thanks!
[16:08] <juliank> sil2100: this is that report: https://magenta.jak-linux.org/bin/1aa0632eb8b9f139112eb2772cc319f9-after-audit-and-co.txt
[16:08] <sil2100> oh man this looks awesome
[16:08] <juliank> note the mutter one makes no sense it's not actually installed itself
[16:08] <juliank> sil2100: oof, hang on that is with -updates
[16:08] <juliank> sil2100: this is without -updates: https://magenta.jak-linux.org/bin/252e364050e95c426bc360155c80d6bc-after-audit-and-co.txt
[16:09] <sil2100> I like the one with updates better
[16:10] <juliank> I am curious what happens now if you trigger an image build for ubuntu desktop
[16:10] <juliank> It looks like it should be installable with -updates enabled, which should be enabled in the build process
[16:10] <juliank> Also why don't we build images with proposed enabled for testing?
[16:10] <sil2100> vorlon, bdmurray: status update - we're migrating some key packages right now, libevent, audit etc. Once those are done, there are a few others that popped up, see juliank's report. There's also the thing with -updates needing to be enabled
[16:11] <sil2100> But...
[16:11] <sil2100> That is a story for later IMO
[16:11] <schopin> sil2100: aren't you supposed to be AFK? :P
[16:11] <sil2100> I think we should just embrace building something with -updates for now
[16:11] <sil2100> schopin: yes! Going afk now, please continue cutting through the uninstallable packages as per the list (maybe the one with -updates enabled for now)
[16:11] <sil2100> It's only a small set
[16:11] <sil2100> o/
[16:12] <schopin> will do.
[16:12] <schopin> wait, with or without updates?
[16:13] <schopin> taking libcdio-cdda2 (well, its srcpkg)
[16:14] <schopin> ugh, it's just waiting on tests.
[16:15] <juliank> schopin: I looked at the depends for that and it's being pulled in by Recommends only (gvfs-backends is optional for ubuntu-desktop); but it causes stupid resolving issues I suppose
[16:17] <juliank>  gvfs-backends : Depends: libcdio-cdda2t64 (>= 10.2+2.0.0) but it is not installable
[16:17] <juliank>                  Depends: libcdio-paranoia2t64 (>= 10.2+2.0.0) but it is not installable
[16:17] <juliank>                  Depends: libcdio19t64 (>= 2.1.0) but it is not installable
[16:17] <juliank>  ibus-table : Depends: ibus (>= 1.5.22-2~)
[16:17] <juliank> These are the errors when I try to install ubuntu-desktop^ standard^ minimal^
[16:17] <juliank> oh and
[16:17] <juliank>  network-manager-config-connectivity-ubuntu : Depends: network-manager (>= 1.45.90-1ubuntu3) but 1.45.90-1ubuntu1 is to be installed
[16:17] <schopin> qa-help: would it be possible to move the tests triggered by libcdio out of the huge queue and into the normal one?
[16:18] <juliank> What happened there
[16:18] <juliank> Ah network-manager-config-connectivity-ubuntu is Architecture: all
[16:18] <juliank> So yes libcio-*, ibus, and network-manager I suppose are the blockers for installing the full desktop seed
[16:19] <juliank> Not sure why I don't see ibus-table in the dose-distcheck report
[16:22] <bdmurray> schopin: you could add them to the normal queue using retry-autopkgtest-regressions and then I can drop them from the huge queue
[16:23] <dbungert> vorlon: to filter out the published source packages, would checking for non-empty output from this be a sensible query? `rmadison --url ubuntu --suite noble --architecture amd64 -S $srcpkg`
[16:24] <schopin> bdmurray: wouldn't retry-autopkgtest-regressions refuse to queue them since they're already queued?
[16:25] <bdmurray> It should...
[16:26] <juliank> So anyway, if images build with -updates, they should start building after libcdio-paranoia, ibus, and network-manager migrated
[16:28] <juliank> oh and libcdio
[16:28] <schopin> -paranoia is just waiting on libcdio
[16:29] <juliank> this installs fine with those migrated: ubuntu-desktop^ standard^ minimal^  linux-generic shim-signed grub-pc
[16:29] <juliank> which is a good sign
[16:29] <juliank> Arguably it would be nice to get a new kernel in proposed
[16:29] <juliank> apw: is this on anyone's mind that the kernel got removed from noble release pocket and needs to be respun?
[16:30] <schopin> bdmurray: the tests are queued in the normal queue, you can drop them from huge.
[16:30] <schopin> TIL about --state=RUNNING :)
[16:31] <juliank> And then hopefully we have a working image, albeit a nasty looking one :)
[16:31] <bdmurray> schopin: well the web frontend should still stop the duplicate request
[16:32] <schopin> ¯\_(ツ)_/¯
[16:32] <schopin> What can I say, they're queued :)
[16:36] <bdmurray> schopin: the ones from the huge queue have been dropped
[16:37] <juliank> FWIW this is the script to play britney with dose-distcheck https://people.canonical.com/~jak/dose-migrate.py
[16:38] <ahasenack_> new excuses just published
[16:38] <juliank> run it as dose-migrate.py package1 package2 ...
[16:38] <juliank> The run https://people.canonical.com/~jak/human-report.py
[16:38] <juliank> like human-report.py root/release-migration.yml  "release pocket + audit, krb5, libevent and libverto" > after-audit-and-co.txt
[16:38] <juliank> use release-updates-migration.yml to look at release+updates
[16:39] <juliank> The output of dose-distcheck will also tell you any new unsatisfied seeded packages
[16:39] <juliank> uh dose-migrate
[16:40] <juliank> but the yml and the human-report will give you the full archive state after
[16:40] <juliank> i.e. if a package changed reason for uninstallable, you'll only see it there
[16:41] <apw> juliank, yes, there are replacement kernels on their way ... problems with arm64 taking over 14 hours to build is slowing us up.
[16:42] <juliank> ah good
[16:43] <schopin> ah that's why the linux-libc-dev issue on i386, got it.
[16:44] <juliank> oh I suppose I did not check i386 installabilites and the images may need some of that
[16:47] <bdmurray> The autopkgtest capacity for armhf is somewhat reduced due to a host in bos03 being down or having run away
[16:47] <juliank> here is now the global (non-seeded too) output for uninstallable binaries in release+updates: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/updates-binaries.txt
[16:48] <schopin> I think ibus can be skiptest, it's only waiting on armhf test for budgie-desktop.
[16:48] <schopin> (which will take a while to get to given the current queue)
[16:50] <schopin> the t64-related changes had already reached the release pocket last week.
[16:51] <bdmurray> I'll look at hinting ibus
[16:52] <schopin> *sigh* network-manager is waiting on quite a few armhf tests too.
[16:54] <bdmurray> ibus hinted
[16:57] <schopin> thanks
[17:00] <juliank> news! https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/updates-binaries.txt and https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/release-binaries.txt now also show tasks
[17:00] <juliank> e.g.  * task:cloud-minimal                       depends on missing libgssapi-krb5-2:amd64 (>= 1.17) via libcurl4t64
[17:00] <juliank> for the release pocket
[17:00] <juliank> from updates-binaries.txt:
[17:00] <dbungert> ausrede logs updated to drop packages that appear to have been published.  missingbuild logs now empty, permafail and blockedtree have stuff
[17:01] <juliank>   * task:ubuntu-desktop                      depends on missing libcdio-cdda2t64:amd64 (>= 10.2+2.0.0) via gvfs-backends
[17:01] <juliank>   * task:ubuntu-desktop                      depends on missing network-manager:amd64 (>= 1.45.90-1ubuntu3) via network-manager-config-connectivity-ubuntu
[17:01] <juliank> this works nicely
[17:01] <juliank> If a bit repetetive
[17:02] <vorlon> dbungert: that rmadison query will also report packages of architecture: all which are published on amd64
[17:03] <vorlon> dbungert: also querying rmadison is slow, you should use a local Packages file at least
[17:03] <vorlon> krb5 is blocked by libverto and libevent; libevent is a transition; but libverto is only used by krb5-kdc.  Forcing krb5 in to help make the base set installable (libtirpc3t64 -> libgssapi-krb5-2)
[17:03] <vorlon> sil2100: ^^
[17:04] <vorlon> sil2100: btw a 'force' hint only causes britney to consider a package a candidate in spite of policy (so moving it to the update_output phase for consideration).  If you want to override an increase in uninstallables you need 'force-hint'.
[17:04] <dbungert> vorlon: ack
[17:04] <juliank> vorlon: should we focus on getting images built with -updates enabled vs focusing on migrating to release pocket first? Latter is waiting for kenrel anyway
[17:05] <vorlon> juliank: I don't really want to build images out of -updates, anything that's in -updates is old
[17:05] <vorlon> (as is obvious by the name, heh)
[17:06] <sil2100> vorlon: whoops! Then in that case, good thing I just copied it over forcefully
[17:06] <juliank> yes but we can get images to build with updates today I suppose and then/in parallel work on migrating further
[17:06] <vorlon> sil2100: you mean bypassing britney? :)
[17:06] <sil2100> Of course
[17:06] <vorlon> haha ok
[17:06] <juliank> britney was down all the time, so copy-package it was
[17:06] <sil2100> #ontheedge
[17:07] <vorlon> juliank: my today is a lot longer than yours; and I don't consider building images today with month-old packages to be a useful milestone
[17:08] <juliank> heh
[17:08] <sil2100> Well, most of those packages (at least the seeded ones) will be overriden by the ones we migrated to release, right?
[17:08] <juliank> but not sure you get kernels today
[17:08] <vorlon> I'm aware about the kernel situation but that's pretty far down the image build pipeline, if we get to the point that kernels in release pocket are the only thing blocking then I'm pretty happy
[17:08] <vorlon> and I can make old kernels in release pocket happen
[17:08] <vorlon> the other architectures don't really need kernels, do they
[17:09] <sil2100> Did a test build of a server image to get a better idea of the situation, we're still not there: https://launchpadlibrarian.net/723345962/buildlog_ubuntu_noble_amd64_ubuntu-server-live_BUILDING.txt.gz
[17:09] <juliank> well the list I created earlier, seeded packages with unsat depends after migrating krb5 and libvert and so on https://magenta.jak-linux.org/bin/252e364050e95c426bc360155c80d6bc-after-audit-and-co.txt
[17:09] <sil2100> (those are built without -updates btw.)
[17:10] <juliank> curl https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/release-binaries.txt | grep task: will show all uninstallable tasks fwiw
[17:10] <juliank> but this has not faux-migrated krb5 yet
[17:11] <juliank> It disagrees with dbungert's ausrede, maybe, which doesn't show libllvm17 which is the biggest uninstallability in tasks
[17:11] <juliank> or at least will be
[17:11] <dbungert> my list is overfiltered at the moment
[17:11] <juliank> you can't see it yet
[17:13] <juliank> Anyway this updates hourly based on latest publisher run :)
[17:13] <juliank> well not the one with hashes
[17:13] <juliank> that was manual faux migration :)
[17:13] <schopin> sil2100: you can skiptest network-manager: it's a NCR, tests we're waiting on are either useless, already passed on the previous version, or passed when ran manually on a Pi.
[17:14] <schopin> ugh, the armhf queue is *really* slow, I'll just run the libcdio tests manually too.
[17:15] <vorlon> schopin: really slow or really long?
[17:15] <juliank> so missing llvm-toolchain-17 causes the most uninstallabilites right now
[17:15] <schopin> vorlon: slow. We're a host short apparently.
[17:16] <juliank> or rather will be after krb5 :D
[17:16] <vorlon> juliank: well I mentioned 8 hours ago it would need a hint <shrug>
[17:16] <juliank> It probably was hinted
[17:16] <vorlon> nope
[17:16] <juliank> It was skiptested
[17:16] <juliank> but not forced
[17:17] <juliank> it's also still building on riscv64
[17:17] <juliank> lol
[17:17] <vorlon> yes, that's what the force is for
[17:17] <vorlon> force hint added now
[17:17] <vorlon> it also blocks on abseil (still?)
[17:18] <juliank> I'd just skiptst abseil
[17:18] <juliank> I don't care about ycmd
[17:18] <vorlon> verifying now whether that's sensible
[17:18] <vorlon> yeah hinting
[17:18] <vorlon> no-change rebuilds
[17:19] <juliank> ycmd is one too lol
[17:19] <vorlon> so I have krb5, llvm-toolchain-17, abseil to go in on the next britney run. anything else?
[17:20] <juliank> have a look at https://magenta.jak-linux.org/bin/252e364050e95c426bc360155c80d6bc-after-audit-and-co.txt maybe
[17:20] <vorlon> doing network-manager
[17:21] <schopin> vorlon: it can be skiptest (I pinged Lukasz but I guess he's still AFK)
[17:21] <vorlon> schopin: yeah that's what I meant by "doing" sorry
[17:21] <schopin> no worries
[17:21] <vorlon> accountsservice has the wrong version skiptested
[17:21] <juliank> Yeah so if I just want ubuntu-desktop installable *now* (with updates, on existing machines basically) I need only
[17:21] <juliank> src:libcdio src:libcdio-paranoia src:ibus src:network-manager
[17:22] <schopin> I'm on the first, the second only needs the first to migrate, and the other 2 are already hinted (or in the process of)
[17:22] <vorlon> juliank: I want it installable now without -updates, where's that list
[17:23] <vorlon> tracker?
[17:23] <vorlon> gnome-control-center
[17:23] <juliank> vorlon: that's the file https://magenta.jak-linux.org/bin/252e364050e95c426bc360155c80d6bc-after-audit-and-co.txt
[17:23] <juliank> vorlon: ok well
[17:23] <juliank> vorlon: that's all seeded packages
[17:23] <vorlon> so nobody fixed samba
[17:24] <vorlon> ravikant_: did you investigate why libsmbclient is listed as uninstallable?
[17:24] <schopin> I think he's EOW
[17:24] <juliank> I could give a view for that
[17:24] <juliank> maybe
[17:25] <juliank> Ah vorlon
[17:25] <jbicha> vorlon: please hint gvfs since it's just a rebuild
[17:25] <juliank> vorlon: we had that earlier with libaudit0, britney considers the old binary that will be NBS uninstallable (here libsmbclient which is replaced by libsmbclient0)
[17:26] <vorlon> jbicha: yes doing
[17:26] <juliank> vorlon: i.e. it seems utterly useless for installability checking if there's a t64 transition in the same package between updates and proposed
[17:26] <vorlon> juliank: ok but it also listed *smbclient* as uninstallable which is not a lib and not NBS?
[17:26] <juliank> hence why we forced audit through
[17:27] <juliank> Let me run dose-migrate
[17:27] <juliank> also adding the other packages you just hinted
[17:27] <vorlon> ok force-hint'ing samba+sssd+gnome-control-center
[17:28] <juliank> heh I'm still checking samba but ok :D
[17:30] <juliank> vorlon: uninstallable depends report for release binaries + audit  krb5 llvm-toolchain-17 abseil samba: https://magenta.jak-linux.org/bin/18aaeaa56f231489717e3a65e81acfbf-release-migration.txt
[17:31] <juliank> smbclient seems fine
[17:31] <juliank> or maybe it's not
[17:31] <schopin> vorlon: libcdio can be skiptest, all tests passed on the Pi.
[17:31] <juliank> but this only shows seeded packages :D
[17:31] <vorlon> mmk
[17:31] <juliank> Otherwise this takes *ages* to run
[17:32] <vorlon> schopin: that's an awful lot of manual testing to have to do
[17:32] <vorlon> schopin: hinting
[17:32] <schopin> I'm just making sure that waveform isn't too cold in his office by making hi Pi run :)
[17:33] <vorlon> ok britney has finished
[17:33] <vorlon> well. still generating stats
[17:33] <ahasenack_> my pi4 has been super useful in these times
[17:33] <ahasenack_> only place where I could get an armhf environment
[17:34] <juliank> I should make my reports on the server actually fetch the britney hints and then calculate the state after transitons
[17:37] <juliank> The other report I can provide is: All packages in proposed that fail to install in release pocket
[17:38] <juliank> here's a full report with unseeded packages too after the faux migration https://magenta.jak-linux.org/bin/d1f7e92fa62323d28d7c0423945225bf-release-migration.txt
[17:38] <juliank> but this is silly to try all the time because so slow
[17:38] <juliank> I don't see smbclient in there so that seems good
[17:40] <jbicha> vorlon: please hint bash since it's also just a rebuild
[17:40] <schopin> juliank: were you working on llvm17 ?
[17:41] <vorlon> jbicha: you don't need bash
[17:41] <juliank> schopin: No, I think vorlon just hinted that though
[17:41] <schopin> ack, thanks.
[17:42] <vorlon> jbicha: tracker 3.7.1-1 regressed its autopkgtests.  is this something I should let through or not?
[17:45] <jbicha> vorlon: yes for tracker, I will file a bug upstream about it now
[17:46] <vorlon> ok done
[17:47] <juliank> and I will try to eat
[18:19] <vorlon> upower hinted
[18:23] <sudip> bdrung: if you are still around, LP: #2060262 has similar problem as mtd-utils, debdiff attached.
[18:23] -ubottu:#ubuntu-release- Launchpad bug 2060262 in globalplatform (Ubuntu) "globalplatform fails to build from source" [Undecided, Confirmed] https://launchpad.net/bugs/2060262
[18:27] <vorlon> juliank, sil2100: britney has been spending > 30m on "Building the list of non-installable packages for the full archive", where in all previous runs today this has taken on the order of 2-3 minutes. Any ideas?
[18:28] <bdrung> sudip, i'll have a look
[18:28] <sudip> thanks bdrung
[18:29] <juliank> hello
[18:29] <juliank> funny
[18:29] <juliank> vorlon: I do think it gets quite hard now, I don't suppose there's network in there
[18:29] <vorlon> network?
[18:30] <vorlon> if you're asking whether there are network operations involved in the uninstallable calculation, no
[18:30] <juliank> it doesn't need to query launchpad or so to calculate
[18:30] <vorlon> this is against the local indices
[18:31] <sergiodj> hi, is https://people.canonical.com/~dbungert/ausrede/blockedtree.html a good place to start helping?
[18:31] <juliank> no idea then
[18:32] <vorlon> I'm killing other jobs on the system to free up CPU since there seems to be a bit of contention here
[18:32] <juliank> vorlon: I reiterate my ask to copy shim-signed on amd64 back into the release pocket; this was built on mantic by accident anyhow (a new one will come monday presumably)
[18:32] <schopin> sergiodj: fwiw, at least those packages have been hinted already I think.
[18:32] <juliank> i.e. we did the mantic build with the wrong version number and copied it to devel rather than throw it away
[18:33] <schopin> but britney is not cooperating.
[18:33] <sergiodj> schopin: ah, OK. anything else I can help with, then?
[18:33] <vorlon> sergiodj: I suggest you: 1) get the launchpad chroot tarball from 'manage-chroot -s noble -a armhf get'; 2) import into sbuild or such to get a chroot environment; 3) try to 'apt-get install ubuntu-server' and see what's missing
[18:33] <bdrung> sudip, diff looks good. sponsored. thank for the help.
[18:33] <vorlon> juliank: sorry, I don't think I saw you ask for this previously. looking
[18:33] <sergiodj> vorlon: will do
[18:34] <vorlon> juliank: copied
[18:34] <juliank> After "ubuntu-server" you can also try "install ubuntu-server^" to make sure you catch all packages in the task (like otherwise maybe it ignores some which are uninstallble right now)
[18:34] <juliank> sergiodj: ^
[18:34] <juliank> Or like A|B depends get satisfied by B in universe suddenly
[18:34] <sergiodj> juliank: OK
[18:35] <juliank> vorlon: ta
[18:36] <dbungert> sergiodj: things on that list should be good but I'm a bit underreporting right now, fixing
[18:37] <sergiodj> dbungert: that's OK, I'll be busy checking the chroot thing for a while now :)
[18:37] <dbungert> cool
[18:38] <vorlon> sil2100, bdmurray: fyi I've disabled proposed-migration on all series other than noble for right now as ubuntu-archive-toolbox seems to be struggling
[18:39] <vorlon> I think something's wrong though, I don't know why it's taking so long to calculate uninstallability
[18:39] <bdmurray> vorlon: noted. I was wondering about disabling autopkgtests for everything but noble...
[18:40] <sergiodj> I'm trying to reserve an armhf machine here.  will let you know (on mattermost) if I succeed, in case anyone needs access to one
[18:40] <vorlon> sergiodj: what does that mean?
[18:41] <schopin> fighting with canonistack, I guess?
[18:41] <sergiodj> vorlon: just that I'm reserving an arm machine to be able to debug any problems
[18:41] <vorlon> but there are no armhf machines in canonistack
[18:41] <sergiodj> internal MAAS
[18:41] <sergiodj> sorry, arm64 machine capable of running armhf containers
[18:41] <sergiodj> should've been more clear :)
[18:44] <vorlon> bdmurray: it's possible we'll need to do a partial cleanup of noble-updates just to make britney not take forever
[18:45] <bdmurray> vorlon: sounds reasonable
[18:47] <schopin> glibmm2.4/2.66.7-1build1 can be skiptest (NCR, only failure is badpkg and passed on all-proposed=1)
[18:50] <schopin> although I'm a bit puzzled how it ended up in dbungert's report in the first place? It's not seeded nor are the mentioned rdeps.
[18:51] <schopin> oh, cryfs is.
[18:53] <vorlon> schopin: glibmm2.4 done
[18:53] <vorlon> I was also puzzled why it's in the list; though I see there are Task fields on it in mantic
[18:59] <cpete> Lists are looking pretty small today! I guess I'll go back to investigating numpy regressions unless there's something more pressing?
[19:06]  * schopin EODs
[19:17] <sergiodj> juliank: I realize now that I didn't fully understand your suggestion here: "After "ubuntu-server" you can also try "install ubuntu-server^" to make sure you catch all packages in the task (like otherwise maybe it ignores some which are uninstallble right now)"
[19:18] <vorlon> sergiodj: 'apt install ubuntu-server' may succeed but be missing recommended packages that are present but not installable
[19:18] <sergiodj> I just attempted to "install ubuntu-server" and everything seems to be under control (krb5 is the only missing piece, and has been hinted according to vorlon)
[19:18] <sergiodj> ah, right
[19:18] <vorlon> whereas 'apt install ubuntu-server^' tries to install the task and will complain about those
[19:18] <sergiodj> well, it didn't succeed
[19:19] <vorlon> yes, that's the point, drill down into why it didn't succeed
[19:19] <sergiodj> it's the krb5 thing we discussed already
[19:19] <vorlon> db was also mentioned, did you see what that was about?
[19:20] <sergiodj> you're right, sorry, missed that one
[19:21] <sergiodj> I was trying to understand why "apt install ubuntu-server^" was giving me a "E: Couldn't find task 'ubuntu-server'" and totally missed the db one...  bleh
[19:37] <sergiodj> so the libdb5.3 problem is exactly the same one described here: https://irclogs.ubuntu.com/2024/02/29/%23ubuntu-release.html#t09:19
[19:38] <sergiodj> vorlon: juliank: ^
[19:38] <vorlon> noble temporarily frozen for a round of cleanup of superseded packages from noble-updates; hoping this will unstick britney
[19:38] <vorlon> sergiodj: which packages specifically depend at present on libdb5.3 instead of libdb5.3t64 on amd64 in noble?
[19:38] <sergiodj> I don't see any uploads by juliank on Debian at that date, but I do see one from vorlon
[19:39] <sergiodj> *pam uploads
[19:39] <sergiodj> vorlon: this is on armhf btw, but I'll check
[19:39] <vorlon> sergiodj: armhf is not a useful reference for this!
[19:39] <vorlon> we're trying to unstick amd64 image builds
[19:39] <sergiodj> OK, checking amd64
[19:42] <vorlon> 7140 source packages currently in noble-updates; >4000 source packages to be removed
[19:42] <sergiodj> according to reverse-depends (not sure if its output can be fully trusted), https://paste.ubuntu.com/p/7ds792Mnbv/
[19:43] <sergiodj> I'm checking them
[19:45] <vorlon> sergiodj: so perl and cyrus-sasl2 need rebuilds; neither of these packages are currently in -proposed, could you do no-change rebuilds of these?
[19:53] <sergiodj> vorlon: yes
[19:53] <sergiodj> (sorry, I lost connection for a bit and didn't see the message)
[20:01] <sergiodj> OK, no-change rebuilds for perl and cyrus-sasl2 uploaded
[20:01] <vorlon> thanks
[20:02] <vorlon> the other revdeps should also get NCRs but I haven't had a chance to verify whether any of those are in -proposed already and should not be clobbered
[20:05] <vorlon> 6199 source packages of 7140 to be removed from noble-updates
[20:06] <vorlon> this will take a while before we unfreeze
[20:06] <vorlon> hunting down queuebot
[20:06] <ahasenack> what's NCR?
[20:06] <ahasenack> ah, n/m
[20:06] <ahasenack> no change rebuild
[20:06] <vorlon> yeah sorry
[20:07] <bdmurray> Can we run the removals in parallel?
[20:07] <vorlon> bdmurray: yes
[20:07] <vorlon> bdmurray: https://paste.ubuntu.com/p/zz5T8VcBFt/
[20:07] <vorlon> pipe it to tac and start from the other end?
[20:08] <bdmurray> Which arguments with remove-package?
[20:09] -queuebot:#ubuntu-release- Unapproved: chrony (noble-proposed/main) [4.5-1ubuntu3 => 4.5-1ubuntu4] (core)
[20:10] <vorlon> bdmurray: I think I pasted that to you in the private message
[20:12] <bdmurray> I see
[20:12] <juliank> vorlon: fyi * task:standard                            depends on missing python3-gdbm:amd64 via python3-commandnotfound
[20:13] <vorlon> juliank: thanks
[20:13] <juliank> i.e. command-not-found requires python3-stdlib-extensions to migrate
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (noble-proposed) [2.31.0-0ubuntu4]
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (noble-proposed) [4.5-1ubuntu4]
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted linuxptp [source] (noble-proposed) [4.0-1ubuntu1]
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted cyrus-sasl2 [source] (noble-proposed) [2.1.28+dfsg1-5ubuntu3]
[20:14] -queuebot:#ubuntu-release- Unapproved: accepted perl [source] (noble-proposed) [5.38.2-3.2build2]
[20:14] <juliank>   * task:ubuntu-desktop                      depends on missing libplist3:amd64 (>= 2.2.0) via upower
[20:14] <juliank>   * task:ubuntu-desktop                      depends on missing libtracker-sparql-3.0-0:amd64 (>= 3.1.1) via grilo-plugins-0.3-base
[20:14] <juliank>   * task:ubuntu-desktop                      depends on missing libgpod4:amd64 (>= 0.8.2-4) via rhythmbox-plugins
[20:14] <juliank> (why do we still pull in rhythmbox?)
[20:15] <juliank>   * task:ubuntu-desktop                      depends on missing libavcodec60:amd64 (>= 7:6.0) via libcanberra-pulse and pipewire-pulse:amd64 | pulseaudio:amd64 -> libasound2-plugins:amd64
[20:15] <juliank>   * task:ubuntu-desktop                      depends on missing ure:amd64 via libreoffice-common
[20:15] <juliank>   * task:ubuntu-desktop                      depends on missing gstreamer1.0-plugins-good:amd64 via [various things]
[20:15] <juliank> And I think that's all interesting ones I haven't heard about yet
[20:15] <juliank> I think accountsservice somebody looked at
[20:16] <juliank> And the rest is network-manager/libcdio/tracker/llvm
[20:17] <juliank> (these are all teh interesting blockers for minimal, standard, ubuntu-desktop-minimal, ubuntu-desktop; taken directly from https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/release-binaries.txt)
[20:19] <vorlon> accountsservice needed its hint bumped
[20:26] <kanashiro> re libgpod: it depends on libimobiledevice-dev which is in main in all arches but amd64 (not sure why) in the release pocket. In the -updates pocket it is in universe everywhere. In previous releases it is in main everywhere.
[20:26] <kanashiro> libgpod-dev is in main
[20:27] -queuebot:#ubuntu-release- Unapproved: ubuntucinnamon-environment (noble-proposed/universe) [24.04 => 24.04.1] (no packageset)
[20:29] <vorlon> kanashiro: in standup, will look in a minute
[20:31] <vorlon> kanashiro: I noticed a component-mismatch earlier this week, don't know why it wound up there but I probably fixed it only in release pocket at the time
[20:32] <kanashiro> vorlon but libimobiledevice-dev is still in universe on amd64 in the release pocket
[20:32] <vorlon> britney finally unstuck; it heard me threatening on the standup call to reboot the node
[20:32] <kanashiro> libimobiledevice-dev | 1.3.0-8.1build3                       | noble/universe         | amd64
[20:33] <vorlon> kanashiro: yes, I'm saying that package wasn't there at the time I did the component override
[20:33] <kanashiro> ah ok
[20:33] <vorlon> promoting it now
[20:33] <kanashiro> thanks!
[20:36] <sergiodj> vorlon: I'm waiting for perl/cyrus-sasl2 to rebuild/republish, but let me know if there's anything else needed
[20:36] <vorlon> hinting coreutils, bdmurray we should dump the associated tests (NCR)
[20:36] <cpete> Alright I am going to mimic what sergiodj is doing but for lubuntu. I believe the right meta package is lubuntu-desktop correct?
[20:37] <vorlon> cpete: afaik! (whatever 'apt source lubuntu-meta' shows - some flavors are different)
[20:37] <cpete> vorlon: ack. thanks!
[20:37] <vorlon> sergiodj: one thing I had forgotten to mention was to do a dist-upgrade in the chroot first, too - you may find that gives usefully-different results
[20:38] <vorlon> (the libdb5.3 finding was useful in its own right)
[20:38] -queuebot:#ubuntu-release- Unapproved: tzdata (noble-proposed/main) [2024a-1ubuntu1 => 2024a-2ubuntu1] (core, i386-whitelist)
[20:38] <sergiodj> ACK, will do
[20:38] <cpete> is debootstrap working or should I do a mantic chroot then upgrade?
[20:38] <cpete> I guess I should go try
[20:38] <vorlon> cpete: use the 'manage-chroot' command to pull the launchpad chroot tarball
[20:38] <cpete> vorlon: oh right. I should have doubled check scrollback. thanks
[20:38] <vorlon> 'manage-chroot -s noble -a armhf get', from ubuntu-archive-tools
[20:39] <vorlon> (debootstrap still fails until after the current run migrates krb5)
[20:39] <vorlon> ... which it's slowly calculating right now
[20:40] <vorlon> I: [2024-04-05T20:33:04+0000] - Trying force-hint from vorlon: krb5/1.20.1-6ubuntu2
[20:40] <vorlon> I: [2024-04-05T20:33:04+0000] - start: 3394+0: a-992:a-276:a-1749:i-105:p-102:r-84:s-86
[20:40] <vorlon> I: [2024-04-05T20:33:04+0000] - orig: 3394+0: a-992:a-276:a-1749:i-105:p-102:r-84:s-86
[20:40] <vorlon> [...]
[20:41] <cpete> vorlon: but why '-a armf' and not amd64?
[20:41] <vorlon> oh damn
[20:41] <vorlon> no wonder sergiodj went down the wrong path
[20:41] <sergiodj> :(
[20:41] <sergiodj> I've been misled
[20:41] <vorlon> muscle memory
[20:42] <vorlon> sorry, it absolutely should've been amd64
[20:42] <sergiodj> :)
[20:42] <sergiodj> that's OK
[20:42] <sergiodj> (and it makes things slightly easier because I don't have to resort to binfmt now)
[20:42] <cpete> ack. glad I asked lol
[20:43] -queuebot:#ubuntu-release- Unapproved: trace-cmd (noble-proposed/universe) [3.2-1 => 3.2-1ubuntu1] (no packageset)
[20:45] <vorlon> cpete: thank you for taking my advice to ask questions ;)
[20:46] <cpete> vorlon: no dumb questions right :)
[20:46] <vorlon> cpete: yep, only dumb fingers
[20:49] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (noble-proposed) [2024a-2ubuntu1]
[20:49] -queuebot:#ubuntu-release- Unapproved: accepted ubuntucinnamon-environment [source] (noble-proposed) [24.04.1]
[20:50] -queuebot:#ubuntu-release- Unapproved: accepted trace-cmd [source] (noble-proposed) [3.2-1ubuntu1]
[20:52] -queuebot:#ubuntu-release- Unapproved: tzdata (mantic-proposed/main) [2024a-0ubuntu0.23.10 => 2024a-0ubuntu0.23.10.1] (core, i386-whitelist)
[20:52] <sergiodj> vorlon: OK, both kanashiro and I were able to "apt install ubuntu-server" using the amd64 chroot (after a dist-upgrade)
[20:52] <sergiodj> "apt install ubuntu-server^" keeps erroring
[20:52] <sergiodj> E: Couldn't find task 'ubuntu-server'
[20:55] <vorlon> I don't understand why that would be
[20:55] <vorlon> juliank: ^
[20:55] <ahasenack> fwiw, same here
[20:56] <sergiodj> ubuntu-server-minimal succeeded
[20:56] <kanashiro> FWIW ubuntu-desktop is also installing ok here
[20:56] <vorlon> oh
[20:56] <vorlon> the task is called 'server'
[20:56] <vorlon> not ubuntu-server
[20:57] <sergiodj> ok
[20:57] <kanashiro> that works :)
[20:57] <sergiodj> installing...
[20:57] <sergiodj> everything installed fine
[20:57] <juliank> heh
[20:57] <juliank> some tasks are weird yeah, sorry
[20:57] <ahasenack> I don't think I ever installed tasks or used that syntax
[20:58] <ahasenack> I just install "ubuntu-server", or "ubuntu-desktop"
[20:58] <juliank> It has subtle differences in how alternatives are resolved
[20:59] <juliank> i.e. if we seed B in desktop (I think, maybe just more base seeds - it's hard to say at 11pm) and server has a package depending A|B; apt install ubuntu-server installs A; whereas ubuntu-server seed expands to B
[20:59] <juliank> And the full expansion of the seed is recorded in the Task: field
[21:00] <juliank> Hence apt install server^ would install B but ubuntus-erver would install A
[21:00] <juliank> It doesn't practically work sensibly
[21:00] <vorlon> however if we had seeds in practice that had such differing behavior we should also consider that a bug
[21:01] <vorlon> (in the dependencies of the packages in the archive)
[21:01] <juliank> I think desktop has at least one
[21:01] <juliank> But I did the analysis a year or so ago
[21:01] <bdmurray> filtering (amqp) coreutils
[21:01] <juliank> Also if you installed B before, server^ still installs A (and removes B if they conflict)
[21:01] <vorlon> juliank: I think there might be some cases here around notification-daemon alternatives
[21:02] <juliank> Very likely yes
[21:02] <juliank> solver hints will provide a better solution for those maybe
[21:02] <ahasenack> britney still chugging along? excuses is from 17h utc
[21:02] <vorlon> rmadison dead yay
[21:02] <vorlon> ahasenack: yes :|
[21:02] <vorlon> still waiting for the calculation on krb5 quoted above
[21:03] <ahasenack> so cpu is pegged?
[21:03] <vorlon> which has now been running for exactly a half hour
[21:03] <vorlon> ahasenack: yes
[21:03] <ahasenack> ok
[21:03] <juliank> The solver3 design also resolves differently so it would see any notification-daemon depends after it saw a specific one from a seed meta package
[21:03] <juliank> :D
[21:04] <juliank> But yeah solver hints would eventually allow you to say "if installing foo, install bar"
[21:05] <juliank> That's a really bad example for them tbh
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [sync] (mantic-proposed) [1.197.2]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [sync] (mantic-proposed) [2.12~rc1-10ubuntu4.2]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [sync] (mantic-proposed) [2.12~rc1-10ubuntu4.2]
[21:06] <juliank> Another example is cloud-minimal seeding systemd-timesyncd | time-daemon
[21:06] <juliank> cloud-minimal^ would always install systemd-timesyncd (hence image building is reliable)
[21:07] <cpete> vorlon: alright so can I just unpack this tarball in a tempdir and use as is or is there anything else I need to know?
[21:07] <juliank> but you can later modify it to install chrony
[21:07] <juliank> (which is what some cloud images do)
[21:07] <vorlon> cpete: that's it
[21:07] <cpete> perfect. thanks
[21:07] <juliank> *magic*
[21:08] <juliank> Anyway please do *not* use task^ irl, it marks every transitively seeded package as manually installed - image building has a separate step to mark everything reachable from metapackages automatic again
[21:09] <juliank> There's some issues teaching apt how to do correct automatic marking, as ^ is essentially a macro that expands to the full list
[21:09] <juliank> (and we do not record the "key" package, aka ubuntu-cloud-minimal or so, as such in the package itself, no field for it yet)
[21:09] <ahasenack> and looks way too much like a regexp :)
[21:12] <vorlon> afk for a bit
[21:25] -queuebot:#ubuntu-release- Unapproved: cups (noble-proposed/main) [2.4.7-1.2ubuntu3 => 2.4.7-1.2ubuntu4] (core, i386-whitelist)
[21:32] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (noble-proposed) [2.4.7-1.2ubuntu4]
[21:55] -queuebot:#ubuntu-release- Unapproved: tzdata (jammy-proposed/main) [2024a-0ubuntu0.22.04 => 2024a-0ubuntu0.22.04.1] (core)
[21:56] -queuebot:#ubuntu-release- Unapproved: shim-signed (noble-proposed/main) [1.57 => 1.58] (core) (sync)
[21:56] -queuebot:#ubuntu-release- Unapproved: shim (noble-proposed/main) [15.8-0ubuntu1 => 15.8-0ubuntu1] (ubuntu-desktop) (sync)
[21:56] <juliank> the shim-signed is valid but of course I forgot shim is already published in noble so redundant :D
[21:57] <juliank> so please delete shim itself from unapproved
[21:57] <juliank> ta
[21:57] <juliank> and good night
[22:08] <cpete> okay so for lubuntu: network-manager needs to migrate from proposed to pick up the new build against libnetplan1. autopkgtests look good
[22:10] <cpete> as previously reported upower is uninstallable because libplist3 is missing. Launchpad says 2.3.0-1~exp2build2 published today but I don't see it here https://launchpad.net/ubuntu/noble/amd64/libplist3 it available
[22:13] <cpete> lastly, libffmpegthumbnailer4v5 is uninstallable because of missing libavcodec60, libavfilter9, and libavformat60 (>= 7:6.0) but it should still be in -updates or is that purged already?
[22:13] <cpete> s/it/they
[22:16] <bdmurray> It doesn't look like libplist builds libplist3 any more
[22:17] <bdmurray> `libplist3 => libplist-2.0-4`
[22:19] <bdmurray> v_orlon upload upower with `No-change rebuild against libplist-2.0-4
[22:19] <bdmurray> so upower should be fine cpete
[22:21] <cpete> bdmurray: ahh I didn't catch the rename. I know now to look in the built packages section. thank you.
[22:22] <bdmurray> the more you know
[22:23] <cpete> I wish you could send gifs on irc
[22:23] -queuebot:#ubuntu-release- Unapproved: tzdata (focal-proposed/main) [2024a-0ubuntu0.20.04 => 2024a-0ubuntu0.20.04.1] (core)
[22:34] <dbungert> more packages are visible now in ausrede, I belive the over-filtered problem is resolved
[22:37] <cpete> alright, I looked over the autopkgtests for upower, network-manager, and ffmpeg. Other than a potential regression in arm64 that I'll hunt down and make a bug for, lubuntu should be gtg once things migrate
[22:38] <cpete> *a potential arm64 regression in upower
[22:38] <dbungert> cpete: would you write up your process for chroot analysis in the google doc?
[22:39] <cpete> dbungert: sure
[22:45] <cpete> dbungert: if you have a better process for unpacking the chroot tarball lmk
[22:46] <bdrung> ahasenack, here is the SRU to address the issue found by the last tzdata 2024a update: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2055718 - this diff is bigger than initially expected but the consistency check uncovered more cases.
[22:46] -ubottu:#ubuntu-release- Launchpad bug 2055718 in tzdata (Ubuntu Mantic) "timezone changed unexpectedly from EST to America/Adak or America/Indiana/Indianapolis" [Undecided, New]
[22:47] <ahasenack> bdrung: nice!
[22:47] <ahasenack> wow, excuses still didn´t update (timestamp: 17 utc)
[22:47] <bdmurray> dropping some old ffmpeg queued tests
[22:48] <vorlon> copying krb5 directly to noble.  britney is still running, but still very slow for whatever reason and the output leaves me unsure if it is even considering krb5 accepted.
[22:50] <dbungert> cpete: no that's completely fine, these should be enough to follow
[22:51] <bdrung> ahasenack, at least 75% of the jammy/focal diff is the test code. and we should have enough time for this fix. there is no upcoming urgent timezone upstream release
[22:56] <vorlon> bdmurray: it looks like we've met in the middle on noble-updates
[22:57] <vorlon> and britney is still being useles
[22:57] <vorlon> s
[22:57] <vorlon> I'm going to wait until after the current publisher run, but then reboot the node
[22:59] <bdmurray> vorlon: ah great!
[23:01] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (noble-proposed) [1.58]
[23:01] -queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (noble-proposed) [15.8-0ubuntu1]
[23:01] <vorlon> ok looking more closely yes it has accepted krb5 but OTOH still no telling how long until it's done
[23:02] -queuebot:#ubuntu-release- Unapproved: cups (noble-proposed/main) [2.4.7-1.2ubuntu4 => 2.4.7-1.2ubuntu5] (core, i386-whitelist)
[23:02] <vorlon> by the same measure, going to manually copy samba sssd gnome-control-center to the release pocket
[23:03] <bdmurray> Noble is unfrozen again
[23:08] <vorlon> publisher currently running and picking up the above-mentioned changes
[23:09] <jbicha> vorlon: I have a gnome-control-center upload staged so let me know when I'm clear to upload it
[23:09] <vorlon> jbicha: the copy is done so it's safe now
[23:13] <vorlon> current publisher run is going to take a while to work through all the noble-updates removals
[23:18] <ahasenack> vorlon: just so I understand, for example, sssd "migrated", but without triggering any tests anywhere?
[23:18] <ahasenack> because it was copied manually?
[23:18] <vorlon> ahasenack: it triggered tests but because britney is being daft I've done an archive copy to bypass it
[23:19] <ahasenack> ok, I can still get to them via the current excuses page, and see they are green
[23:20] <ahasenack> autofs was also waiting on that sssd build, specifically armhf
[23:38] <vorlon> kanashiro: also it turns out libgpod-dev is in component-mismatches for demotion which I didn't see before (maybe because component-mismatches was incoherent at the time), so, well, that explains libimobiledevice-dev having been in the wrong pocket
[23:39] <vorlon> something unexpected happening with various desktop -dev packages
[23:40] <vorlon> 2024-04-05 23:40:11 DEBUG   Ciao
[23:40] <vorlon> and of course britney has started moving again leading me on
[23:51] <vorlon> removals of libhwy1 seem to make britney particularly angry.  doing no-change rebuilds of revdeps (revdep) so we can NBS remove it and maybe that helps too
[23:57] <jbicha> vorlon: the desktop -dev is because of https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=0d0e9dbe some of those were demoted but not all & we opted to revert glib's sysprof integration for now
[23:57] -ubottu:#ubuntu-release- Commit 0d0e9db in ~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu "Extra-Excluded: add libglib2.0-dev and its rdepends in main"
[23:58] <vorlon> I see