[00:00] <arraybolt3> What's the process for "taking" a package, if someone has the time to fill me in? I'd be happy to add one person to the team of fixing things if it's something I can help with.
[00:00] <vladimirp> added update-excusefor pytest vs joblib: https://bugs.launchpad.net/ubuntu/+source/joblib/+bug/2059354
[00:00] -ubottu:#ubuntu-release- Launchpad bug 2059354 in pytest (Ubuntu) "proposed migration pytest 8.0.2-1 vs joblib/1.3.2-1" [Undecided, New]
[00:00] <arraybolt3> if it would take too much time to explain, don't, I want to help speed up not slow down
[00:01] <vladimirp> just look for the last 'taking <package>' in the channel and take the next one. post taking <package>, do analysis and ping in the channel your findings
[00:02] <arraybolt3> analysis = look at test results and see if it needs to be removed or hinted?
[00:02] <vladimirp> arraybolt3: yes
[00:03] <arraybolt3> Taking (or at least attempting to) pyzbar
[00:03] <dbungert> sil2100: please hint pyyaml.  s390x pyyaml is good and mad but consistently passing on retry
[00:03] <dbungert> taking qca2
[00:03] <sil2100> python-reportlab: lots of missing results and a single real failure, but none of those related to reportlab itself. Also, missing tests are highly unlikely to fail so hinting
[00:03] <sil2100> (since I have results for other arches)
[00:04] <dbungert> sil2100: please hint qca2
[00:04] <dbungert> taking qemu
[00:04] <sil2100> dbungert: ack pyyaml
[00:06] <arraybolt3> hint pyzbar, tests pass on ppc64el, armhf failure due to time_t64 libs
[00:06] <arraybolt3> taking qrencode
[00:07] <arraybolt3> definitely hint qrencode, passes on three arches, armhf included
[00:07] <sil2100> arraybolt3: if you have a moment, backlog from early today might help. Basically if the package you're taking is a no-change rebuild per what is in the archive, you can only care if the armhf tests are passing (either for the package or for all-proposed)
[00:07] <sil2100> arraybolt3: otherwise its'
[00:07] <sil2100> the usual analysis to see if the package is good to go
[00:07] <sil2100> arraybolt3: please hint me or vorlon for the hints!
[00:07] <arraybolt3> Got it, will do!
[00:08] <arraybolt3> to be clear ncrs should *pass* on armhf, right?
[00:08] <sil2100> Too much going on so we can only react due to direct pings! Looking at the pyzbar and qrencode
[00:08] <vladimirp> sil2100: added https://bugs.launchpad.net/ubuntu/+source/python-psutil/+bug/2059357 for python-psutil, regression on nipype. Block?
[00:08] -ubottu:#ubuntu-release- Launchpad bug 2059357 in python-psutil (Ubuntu) "proposed-migration: python-psutil  5.9.8-2 vs nipype 1.8.6-3" [Undecided, New]
[00:09] <sil2100> arraybolt3: yes, since no-change rebuilds are specifically for armhf, the release version had to be good to allow it migrating at some point
[00:09] <sil2100> But you need to make sure if that's really a ncrb per what's in release
[00:09] <vladimirp> taking qscintilla2
[00:11] <arraybolt3> sil2100: kk, I think I get it now. pyzbar failed on armhf but did not have an ncr so I think that's hint-worthy. If so, I think I can start attacking what I can.
[00:11] <vladimirp> sil2100: qscintilla2 - tests pass (superficial), hint?
[00:12] <vladimirp> taking qt6-base
[00:12] <arraybolt3> taking qtbase-opensource-src-gles
[00:12] <dbungert> sil2100: please hint qemu
[00:12] <sil2100> arraybolt3: pyzbar is certainly something worth looking for. The upload was not a ncrb, but the change was for armhf, however it still fails on armhf. So looking into what's going on there and then either maybe filling a bug and hinting, or maybe even removing? It's arch:all so needs to be removed wholly
[00:13] <mwhudson> vorlon: how do you tell when the new pytest is screwing things up?
[00:13] <dbungert> taking qtdeclarative-opensource-src
[00:13] <sil2100> arraybolt3: but qrencode done o/
[00:13] <arraybolt3> kk
[00:14] <sil2100> dbungert: qemu ack
[00:14] <sil2100> vladimirp: qscintilla2 ack
[00:14] <sil2100> vladimirp: looking at the block
[00:14] <arraybolt3> qtbase-opensource-src-gles is strange - lots of "Regression" but opening up the individual regressions show that they actually... passed?
[00:15] <arraybolt3> I've clicked like five random "Regressions" and see no errors...
[00:15] <vorlon> mwhudson: if I see pytest in the log and it's happening on all architectures... :P
[00:15] <vorlon> mwhudson: there's a LOT of pytest-related breakage
[00:15] <mwhudson> vorlon: it's only on armhf but the tests ran at wildly different times
[00:16] <sil2100> vladimirp: block added
[00:16] <vorlon> mwhudson: pytest has been in -proposed for a month
[00:16] <mwhudson> both after pytest hit proposed though hm
[00:16] <sil2100> arraybolt3: ah ha! So this is one thing you need to know:
[00:16] <dbungert> sil2100: please hint qtdeclarative-opensource-src
[00:17] <sil2100> arraybolt3: don't trust britney's 'Regression' state, instead always look into the list of tests for the arch. There was a bug at some moment that basically didn't test against -proposed and produced bogus results
[00:17] <arraybolt3> Got it, makes perfect sense.
[00:18] <sil2100> arraybolt3: so it's safest to just look into arch testing details and seeing if the package was *actually* tested either directly or with a run with all-proposed
[00:18] <vorlon> britney about to finish the latest run
[00:18] <sil2100> dbungert: wow, you've got some big ones, ack qtdeclarative-opensource-src
[00:18] <sil2100> brb in a few mins
[00:19] <vorlon> I'm going back to review some of the big ones from earlier in the alphabet that were skipped, to see if they pass muster vs having to be put in the big EOD bucket
[00:23] <vladimirp> qt6-base retried, skipping for now, not enough results
[00:23] <dbungert> vorlon: please hint qterminal
[00:23] <arraybolt3> sil2100: to be clear, I can't trust Britney's "regression status" but I can trust the logs it links to, correct?
[00:23] <vorlon> dbungert: done
[00:23] <dbungert> arraybolt3: sort of.  sometimes the "passing" test in the run is not the test that was needed at that moment.
[00:23] <vorlon> arraybolt3: no
[00:24] <vorlon> arraybolt3: click on the architecture name, NOT on the log
[00:24] <vladimirp> taking qterminal (line 352)
[00:24] <dbungert> qterminal done
[00:24] <vorlon> arraybolt3: and for figuring out if there's a regression, exclude test results in 'error' state marked as 'no-proposed=1 all-proposed=1' which is how we identify the mis-tests
[00:24] <vladimirp> taking qtltools ?
[00:24] <dbungert> vladimirp: I think our copy of the list is out of date, I have qterminal on line 292
[00:25] <dbungert> taking qtquickcontrols2-opensource-src
[00:25] <sil2100> arraybolt3: as vorlon and dbungert said already ;)
[00:25] <vladimirp> taking qtsvg-opensource-src
[00:25] <vladimirp> (refreshed list)
[00:26] <dbungert> sil2100: please hint qtquickcontrols2-opensource-src
[00:26] <dbungert> taking qtwebengine-opensource-src
[00:26] <sil2100> dbungert: ack qtquickcontrols2-opensource-src'
[00:28] <dbungert> sil2100: please hint qtwebengine-opensource-src
[00:28] <dbungert> taking qtx11extras-opensource-src
[00:29] <arraybolt3> do I ignore ones that are *only* "no-proposed=1" too or are those also worthwhilte to look into?
[00:29] <sil2100> dbungert: qtwebengine-opensource-src ack
[00:29] <sil2100> arraybolt3: ignore those, those are usually the broken ones as well. They basically test the release pocket
[00:30] <arraybolt3> that's what I figured, kk, I think I can stay out of everyone's hair now :)
[00:30] <sil2100> arraybolt3: no worries, ask questions if in doubt!
[00:30] <dbungert> vorlon: please hint qtx11extras-opensource-src
[00:31] <dbungert> taking qutebrowser
[00:31] <arraybolt3> i386, ignore strange toolchain failures? (I saw stuff about ignoring i386 way earlier in the backlog)
[00:32] <cpete> taking rapiddisk
[00:33] <vorlon> dbungert: done
[00:33] <vladimirp> sil2100: qtsvg-opensource-src - tests pass (some dependency failures), unrelated regression in plplot https://bugs.launchpad.net/ubuntu/+source/plplot/+bug/2059361, hint?
[00:33] -ubottu:#ubuntu-release- Launchpad bug 2059361 in plplot (Ubuntu) "proposed-migration plplot 5.15.0+dfsg2-9" [Undecided, New]
[00:34] <vladimirp> taking raptor2
[00:34] <dbungert> I'm not sure why pysatellites is marked as regressed on armhf when that has never passed
[00:34] <sil2100> vladimirp: qtsvg-opensource-src ack
[00:34] <vladimirp> sil2100: raptor2 - all tests pass with all-proposed, hint?
[00:34] <dbungert> sil2100: please hint qutebrowser
[00:35] <dbungert> taking rasterio
[00:35] <vladimirp> taking rawtran
[00:35] <sil2100> vladimirp: ack raptor2
[00:35] <sil2100> dbungert: qutebrowser ack
[00:36] <cpete> sil2100: please hint rapiddisk
[00:36] <vladimirp> sil2100: rawtran - tests pass except amd64 (listed as in progress, but nothing queued/running), no change rebuild, hint?
[00:36] <cpete> taking rasterio
[00:36] <cpete> wait am behind
[00:36] <cpete> taking r-base
[00:36] <vladimirp> taking r-bioc-rhtslib
[00:37] <sil2100> cpete: rapiddisk ack
[00:37] <cpete> oh no...
[00:37] <sil2100> vladimirp: good for a skiptest, ack rawtran
[00:39] <dbungert> ok r-base if 56 pages of regressions
[00:39] <dbungert> *is
[00:39] <sil2100> umm
[00:41] <sil2100> I think I saw some discussion at some point about the r-* packages
[00:41] <arraybolt3> 1902s /usr/bin/ld: cannot find -lplplot: No such file or directory
[00:41] <vladimirp> arraybolt3: https://bugs.launchpad.net/ubuntu/+source/plplot/+bug/2059361
[00:41] -ubottu:#ubuntu-release- Launchpad bug 2059361 in plplot (Ubuntu) "proposed-migration plplot 5.15.0+dfsg2-9" [Undecided, New]
[00:42] <arraybolt3> plplot looks broken everywhere (part of analyzing qtbase-opensource-src-gles
[00:42] <dbungert> sil2100: please hint rasterio
[00:42] <sil2100> dbungert: rasterio ack
[00:42] <cpete> well, I suppose I can at least look at the regressions and see if there are any bugs to file
[00:43] <dbungert> taking r-bioc-variantannotation
[00:45] <dbungert> all amd64 pages may be hosed at this point with "Error 'TypeError' object has no attribute 'exit_code' during handling of 'NoneType' object is not iterable"
[00:46] <mwhudson> oh is that for all amd64 pages?
[00:46] <mwhudson> yes seems so
[00:46] <arraybolt3> I hit that just a bit ago
[00:46] <sil2100> what the
[00:46] <cpete> oh fun
[00:47] <cpete> Getting the same thing
[00:47] <vladimirp> same
[00:47] <mwhudson> bdmurray: halp
[00:47] <vladimirp> also no test results for r-bioc-rhtslib (all are for the previous version)
[00:47] <dbungert> I need to be done anyways, yielding r-bioc-variantannotation
[00:48] <dbungert> afk
[00:48] <sil2100> dbungert: thanks for all the hard work!
[00:49] <dbungert> ty
[00:50] <arraybolt3> qtbase-opensource-src-gles looks good for all except mumble:arm64 and libcamera:ppc64el (the latter of which fails with `693s  libglib2.0-0t64 : Breaks: libglib2.0-0 (< 2.79.3-3ubuntu5)`).
[00:50]  * vladimirp afk 10 min
[00:50] <arraybolt3> vorlon: ^ hint or remove? I think hint, I'm about to file bugs for those two
[00:50] <vorlon> arraybolt3: mumble is a known problem with the version in -proposed
[00:51] <vorlon> arraybolt3: the glib error just means something was in a bad state when things were run
[00:51] <vorlon> arraybolt3: hinting
[00:51] <arraybolt3> awesome, I did one!
[00:51] <vorlon> Subject: [ubuntu/noble] pam 1.5.3-5ubuntu3 (Accepted)
[00:51] <vorlon> uh?
[00:52] <arraybolt3> I guess I'm taking r-bioc-variantannotation then since no one else picked it up
[00:52] <vorlon> oh right that's a non-transition
[00:52] <bdmurray> I'm here
[00:53] <vorlon> T minus 7 minutes
[00:55] <arraybolt3> vorlon: remove r-bioc-variantannotation, NCR with installability failures on armhf
[00:55] <arraybolt3> all other arches look OK
[00:55] <vorlon> 514 packages as of the last britney run (finished 23:38:32)
[00:55] <vorlon> arraybolt3: uh you're a couple days late on requesting removal of armhf binaries on that one
[00:55] <cpete> fwiw I see the same on r-bioc-ballgown related to r-bioc-rtracklayer
[00:56] <arraybolt3> heh, then I guess hint away
[00:56] <vorlon> https://launchpad.net/ubuntu/noble/arm
[00:56] <vorlon> https://launchpad.net/ubuntu/noble/armhf/r-bioc-variantannotation
[00:56] <vorlon> ok, 1 day
[00:57] <cpete> vorlon: for tests failing due to missing binaries would it be useful to create a bug to track?
[00:58] <vorlon> cpete: not usually
[00:58] <cpete> vorlon: ack, thanks
[00:58] <arraybolt3> going afk, looks like I came in just as it got too late to do much anyway but I got one :P
[00:59] <cpete> arraybolt3: it all helps!
[01:01] <sil2100> Oh no, T plus 1 minute!
[01:02] <cpete> Wait wouldn't it be T +<PHONE_NUMBER>
[01:02] <vladimirp> ok, I guess time to debug why openjdk build gets stuck on armhf
[01:04] <mwhudson> uh filed a few bugs wrt python-typing-extensions but i think it's mostly ok
[01:05] <arraybolt3> so what now? Continue analyzing so we catch things that were hinted but shouldn't have been?
[01:05] <cpete> ok so I got down to r-bioc-goseq in r-base and it mostly looks like installability issues due to missing binaries
[01:05] <cpete> I need to EOD
[01:06] <vorlon> arraybolt3: continued analysis is welcome to figure out if anything we're letting in is broken
[01:06] <vorlon> adding hints now for the remaining 430 packages
[01:06] <vorlon> thank you all for your persistent and heroic work here
[01:06] <sil2100> \o/
[01:07] <cpete> \o/
[01:09] <arraybolt3> I'll see if I can find anything broken once I get back, if so I'll ping. Thanks for teaching me what was being done!
[01:32] <vorlon> sil2100: um I see you just added a block hint for pango1.0. blocking pango1.0 is not an option
[01:32] <vorlon> sil2100: what's this about?
[01:32] <sil2100> vorlon: ah, it was a request from earlier from vladimirp
[01:33] <vorlon> sil2100: ok well a) it's not an optional part of the transition, b) the failed upload was for the in-archive build which was redundant with the bootstrap ppa build, c) if it was missing an armhf build it wouldn't be a candidate anyway and need blocked
[01:33] <arraybolt3> I can retry arbitrary Universe autopkgtests as a MOTU right?
[01:34] <vorlon> arraybolt3: yes
[01:34] <arraybolt3> looking at another r-cran package (r-cran-curl)
[01:34] <sil2100> So the armhf binaries are missing as they fail to upload
[01:34] <arraybolt3> kk great
[01:34] <sil2100> Ah, okay!
[01:34] <vorlon> sil2100: no they are not
[01:34] <sil2100> I see that
[01:34] <sil2100> hm
[01:34] <sil2100> Then where did I see that
[01:35] <sil2100> I think I was just confused when I checked that, let me drop the blocks
[01:36] <vorlon> sil2100: already dropped :)
[01:36] <sil2100> vorlon: thanks ;p
[01:37] <sil2100> And with this being said, let me also drop myself from in front of the keyboard
[01:38] <sil2100> o/
[01:38] <sarnold> gn8 :)
[01:38] <vorlon> letting the current britney finish running; it's been going for an hour now and should be done in about a half hour, and this will let livecd-rootfs in
[01:39] <vorlon> next run after that will include all of the hints, at which point I'll check that output is sane vs the notest run
[01:39] <vorlon> and the next run after that will include the change to not block on armhf installability
[01:42] <bdmurray> Browsing results should be good now but "Queued tests" is not accurate on a package page.
[01:44] <vorlon> bdmurray: thanks!
[01:48] <arraybolt3> I should still file bugs for legitimate autopkgtest failures that don't appear to be time_t64 related, right?
[01:49] <arraybolt3> I have a few genuine autopkgtest fails on r-cran-curl, and only two time_t64-related ones that look to not have anything to do with r-cran-curl itself.
[02:02] <tsimonq2> arraybolt3: Some variables go into that, but generally speaking, yes it's a good idea.
[02:03] <vorlon> well, I would say it's not worth your effort to in general file bugs about autopkgtest regressions
[02:03] <vorlon> because there are many, many failing autopkgtests
[02:03] <vorlon> and once the baseline regresses we don't generally commit effort to fixing them
[02:04] <vorlon> nor is it clear that a recently-regressed autopkgtest is a higher priority than the broader pool of failing tests
[02:04] <sarnold> so .. turn it off entirely?
[02:04] <vorlon> sarnold: uh no?
[02:04] <vorlon> sarnold: we don't normally let autopkgtests regress
[02:05] <vorlon> there we go https://launchpad.net/ubuntu/+source/livecd-rootfs/+publishinghistory
[02:05] <vorlon> I plan to kick off a round of image builds for all flavors once that's published
[02:06] <sarnold> vorlon: that sounds like recently regressed autopkgtests *are* a higher priority, then?
[02:06] <vorlon> sarnold: "regressed" means "regressed in the release pocket"
[02:06] <vorlon> sarnold: in the sense I was using t
[02:06] <vorlon> it
[02:06] <Eickmeyer> vorlon: A lot of image build failures have been due to nemo and cinnamon as well, and I see nemo hasn't yet migrated.
[02:07] <vorlon> sarnold: and if it's in -proposed you don't need to file a bug about it being regressed in -proposed
[02:07] <vorlon> sarnold: (except in the context of +1 maintenance where someone is actively working on fixing it and using a bug for tracking)
[02:07] <sarnold> vorlon: "no bug for -proposed" makes sense, heh
[02:07] <sarnold> .. except when it doesn't? :)
[02:07] <sarnold> just when I think I'm getting the hang of things around here..
[02:10] <vorlon> sarnold, arraybolt3 anyway, I would suggest that if you see a failed autopkgtest that points to a *runtime* regression, it's worth filing a bug.  But if it's just a *test* regression (... which is quite common) then likely not
[02:12] <vorlon> the next britney run is started as of 01:48
[02:14] <sarnold> vorlon: ah, that makes sense
[02:28] <vorlon> Eickmeyer: nemo and cinnamon> yes but I bet those flavors would also like to know that their images aren't now failing to build with a new and *different* error
[02:29] <vorlon> Eickmeyer: anyway this unblocks seed changes for ubuntu-desktop-bootstrap regardless
[02:29] <Eickmeyer> vorlon: Agreed.
[02:37] <vorlon> E: [2024-03-28T02:37:34+0000] - {'': (501, b'5.1.3 Bad recipient address syntax')}
[02:37] <vorlon> good job
[02:41] <vorlon> NBS removals done from -proposed
[02:45] <vorlon> (which happens to unblock mathgl and therefore 3depict on armhf)
[02:45] <mwhudson> vorlon: so an hour or two away from everything moving still?
[02:45] <vorlon> mwhudson: more like 3
[02:45] <mwhudson> vorlon: ack
[02:50] <vorlon> hmmm trying to get a head start on armhf uninstallables post-migration and a lot of these things are looking like they might sort themselves out immediately after
[02:50] <vorlon> so I'll wait for the noble_uninst report instead
[03:25] -queuebot:#ubuntu-release- Unapproved: accepted locust [sync] (noble-proposed) [2.24.0-1]
[03:25] -queuebot:#ubuntu-release- Unapproved: accepted mold [sync] (noble-proposed) [2.30.0+dfsg-1]
[03:28] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (noble-proposed) [24.1.3-0ubuntu1]
[03:28] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (noble-proposed) [24.04.1]
[03:28] -queuebot:#ubuntu-release- Unapproved: accepted r8125 [source] (noble-proposed) [9.011.00-4ubuntu1]
[03:28] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (noble-proposed) [1.537]
[03:29] -queuebot:#ubuntu-release- Unapproved: accepted lxd-agent-loader [source] (noble-proposed) [0.7]
[03:29] -queuebot:#ubuntu-release- Unapproved: accepted ukui-desktop-environment [source] (noble-proposed) [3.0.2]
[03:31] <vorlon> image rebuilds kicked
[03:32] <vorlon> going on an hour on the update_output phase this time
[04:02] <Eickmeyer> Horray for new failures!
[04:10] <Eickmeyer> vorlon: Kicking-off a new build of studio with a change for the failure.
[04:10] <vorlon> ok
[04:10] <vorlon> I would hope the workaround is unnecessary after the big migration
[04:10] <Eickmeyer> No meta update because the amount of armhf changes made me want to wait until morning.
[04:11] <Eickmeyer> workaround > Same.
[04:12] <vorlon> britney done, impatiently waiting for web caches to clear
[04:19] <Eickmeyer> Ok, that last studio build failure was on me. I forgot that we explicitly seed libfuse2 to deal with appimages, so switching to libfuse2t64.
[04:22] <vorlon> augh the linux-meta skiptest hint didn't get added because there was an existing hint for a previous version
[04:29] <vorlon> ok, pulling the trigger on BREAK_ARCHES
[04:31] <vorlon> new p-m run has started
[04:34]  * Eickmeyer crosses fingers, toes, and considers the wifi antennae
[04:41] <Eickmeyer> *sigh* It's osspd, which is pre-seeded for ubuntustudio-audio and ubuntustudio-video. It hard-depends on libfuse2. Until the version in proposed migrates, studio will not build.
[05:11] <vorlon> why did britney crash :|
[05:15] <vorlon> some sort of problem parsing EmailCache on disk; removing for the rerun
[05:28] <vorlon> autopkgtest queues are too short, doing a mass-retry right now of 'in progress' tests that are lost/discarded
[05:35] -queuebot:#ubuntu-release- Unapproved: ecl (noble-proposed/universe) [21.2.1+ds-4.1 => 21.2.1+ds-4.1ubuntu1] (no packageset)
[05:37] -queuebot:#ubuntu-release- Unapproved: accepted ecl [source] (noble-proposed) [21.2.1+ds-4.1ubuntu1]
[06:34] <vorlon> juliank: I've loaded up the autopkgtest queues with retries of 'In Progress' tests so that they're not sitting idle, but after this britney run feel free to dump anything left and replace it with something more useful
[06:48] <vorlon> having to remove the broken email cache means britney lost knowledge of any emails it did send previously, so is now basically re-sending for all packages, which adds to the runtime :/
[06:53] <vorlon> fossfreedom_: so I'm having a go at refactoring a lot of the code duplication in livecd-rootfs and I notice that you're using the 'get_seeded_languages' logic for Budgie which no other flavors do; but you actually don't have the seed names right so this is a no-op.  Before I go "fixing" this I thought I should check with you about intent
[06:54] <vorlon> fossfreedom_: you want the English language pack to be installed by default in the live image; but not included in the install when the user picks a language other than English; is that correct?
[07:32] <fossfreedom_> vorlon: correct. Yes.
[07:32] <vorlon> fossfreedom_: ok
[07:51] <vorlon> ok there goes the publishing
[07:57] <juliank> vorlon: ack
[07:59] <juliank> vorlon: should we kill all-proposed hacks now?
[07:59] <juliank> Or wait until they expire next week?
[07:59] <vorlon> juliank: the only reason I think it might matter, is that pytest is a mess in -proposed
[08:00] <vorlon> which might be enough reason to kill it
[08:00] <vorlon> juliank: but I'll leave that to Europe to decide :)
[08:01] <juliank> I think we have automatic all-proposed retry turned on if it fails on badpkg
[08:01] <juliank> It's the default surprisingly
[08:02] <vorlon> as always, a certain number of packages are failing to copy to the release pocket with launchpad api errors
[08:02] <vorlon> (21 so far)
[08:02] <juliank> Should patch Britney to copy alphabetically
[08:03] <juliank> My email would be easier to see progression
[08:03] <vorlon> heh
[08:03] <vorlon> because what britney needs is another sort operation
[08:04] <juliank> So what I want to do is after Britney is done queue what is left running, wait for glibc upload and that Britney run to schedule it's migration-reference/0 and then schedule for everything else
[08:04] <juliank> Oh but that waiting takes ages
[08:05] <juliank> Britney just doesn't check if we already have a migration-reference pending
[08:06] <juliank> Haven't figured out what happens if I trigger reference tests for source packages that built no binaries on a given architecture
[08:06] <juliank> There's no tool for doing that
[08:06] <juliank> Arguably I can ask the db if we ever had a test there
[08:08] <juliank> vorlon: is the freeze lifted again?
[08:08] <vorlon> juliank: no; I'll ask sil2100 to drive this
[08:08] <juliank> ack
[08:09] <vorlon> there was some other thing I thought we should wait for before lifting it but now I don't remember, so
[08:09] <vorlon> better to pass it to someone who's not already asleep
[08:10] <juliank> schopin: glibc seems to have migrated, do you have a new one ready to upload?
[08:10] <juliank> vorlon: heh I'm on a swap day really
[08:10] <juliank> Just nudging people today
[08:15] <RikMills> vorlon, juliank and MANY others: thanks for all that effort \o/
[08:35] <zhsj> please sync https://salsa.debian.org/go-team/packages/gopacket/-/commit/6bf8c7a0356e419f9797910e350492b285977aab for time_t
[08:35] -ubottu:#ubuntu-release- Commit 6bf8c7a in go-team/packages/gopacket "Update changelog for 1.1.19-5 release"
[08:52] <zhsj> oops, copy-past error.. need one line for fix for that ^
[08:54] <doko> zhsj: please remind somebody when it's visible in LP
[08:56] <bastif> This one seems ok now https://autopkgtest.ubuntu.com/packages/g/google-android-installers/noble/amd64, but is still errored in excuses... Is it really ok and will it finally pass, or are there really errors (in which case, where can I see them)?
[08:58] <vorlon> britney finally done publishing
[09:00] <vorlon> bastif: for promotion of google-android-installers itself, the test is still pending
[09:00] <vorlon> bastif: but also, https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#google-android-installers shows a lot of regressions still which require test requeuing which hasn't happened yet, this will shake out over the next days
[09:03] -queuebot:#ubuntu-release- Unapproved: gcc-9 (noble-proposed/universe) [9.5.0-5ubuntu1 => 9.5.0-6ubuntu1] (i386-whitelist)
[09:12] <bastif> vorlon: ok thanks for clarifying
[09:28] -queuebot:#ubuntu-release- Unapproved: gcc-10 (noble-proposed/universe) [10.5.0-3ubuntu1 => 10.5.0-4ubuntu1] (core, i386-whitelist)
[09:29] -queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (noble-proposed/main) [3.12.2-3ubuntu1.1 => 3.12.2-3ubuntu3] (core, i386-whitelist)
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted gcc-10 [source] (noble-proposed) [10.5.0-4ubuntu1]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (noble-proposed) [3.12.2-3ubuntu3]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (noble-proposed) [9.5.0-6ubuntu1]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted 3depict [source] (noble-proposed) [0.0.23-2build2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted python-xarray [sync] (noble-proposed) [2024.02.0-2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted binwalk [sync] (noble-proposed) [2.3.4+dfsg1-5]
[09:33] -queuebot:#ubuntu-release- Unapproved: accepted libquotient [source] (noble-proposed) [0.7.2-0ubuntu4]
[09:33] -queuebot:#ubuntu-release- Unapproved: accepted tgl [source] (noble-proposed) [2.0.1+git20160323.ffb04cac-3.1ubuntu2]
[09:33] -queuebot:#ubuntu-release- Unapproved: accepted watcher [source] (noble-proposed) [2:12.0.0~rc1-0ubuntu2]
[09:33] -queuebot:#ubuntu-release- Unapproved: accepted php-phar-io-manifest [source] (noble-proposed) [2.0.4-2ubuntu1]
[09:33] -queuebot:#ubuntu-release- Unapproved: accepted vdeplug-slirp [source] (noble-proposed) [0.1.0-2ubuntu1]
[09:33] -queuebot:#ubuntu-release- Unapproved: accepted click [source] (noble-proposed) [0.5.2-2ubuntu1]
[09:33] -queuebot:#ubuntu-release- Unapproved: accepted python-rq [sync] (noble-proposed) [1.16.1-1]
[09:33] -queuebot:#ubuntu-release- Unapproved: accepted gbrainy [sync] (noble-proposed) [1:2.4.6-2]
[09:34] -queuebot:#ubuntu-release- Unapproved: accepted r8168 [source] (noble-proposed) [8.052.01-1ubuntu1]
[09:34] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-550 [amd64] (noble-proposed) [550.67-0ubuntu1]
[09:34] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-550 [i386] (noble-proposed) [550.67-0ubuntu1]
[09:34] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-550 [arm64] (noble-proposed) [550.67-0ubuntu1]
[09:34] -queuebot:#ubuntu-release- New: accepted orchis-kde [amd64] (noble-proposed) [2024-01-08-0ubuntu1]
[09:35] -queuebot:#ubuntu-release- New: accepted dante [amd64] (noble-proposed) [1.4.2+dfsg-7.1~willsync1]
[09:35] -queuebot:#ubuntu-release- New: accepted dante [ppc64el] (noble-proposed) [1.4.2+dfsg-7.1~willsync1]
[09:35] -queuebot:#ubuntu-release- New: accepted dante [s390x] (noble-proposed) [1.4.2+dfsg-7.1~willsync1]
[09:35] -queuebot:#ubuntu-release- New: accepted dante [arm64] (noble-proposed) [1.4.2+dfsg-7.1~willsync1]
[09:35] -queuebot:#ubuntu-release- New: accepted dante [riscv64] (noble-proposed) [1.4.2+dfsg-7.1~willsync1]
[09:56] <sil2100> Once the kernel fully publishes, I'll also re-trigger a build of Ubuntu Desktop
[10:20] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (noble-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>ubuntu1] (desktop-core)
[10:28] <juliank> sil2100: Checking in, I think we need to wait for the current britney run to finish such that we get no more migrations in it, then purge queues and retry all RUNNING ones to get the meaningful tests in there, and then we can think about doing the bulk migration-reference/0 ones
[10:28] <sil2100> That's the plan
[10:29] <juliank> sil2100: +1
[10:29] <juliank> sil2100: I'm reachable here for double checking :)
[10:30] <juliank> I think publisher is overworked a bit with the mass migration :D
[10:31] <schopin> I said this elsewhere, but I'm repeating it here for the record: don't wait for glibc before rescheduling, it's currently FTBFS and it's not trivial to fix.
[10:32] <juliank> ack
[10:32] <juliank> And we have my queue merge script
[10:32] <juliank> so after the glibc upload one could use that to merge the queues again
[10:33] <juliank> which will re-order alphabetically
[10:33] <juliank> So it would alternate between glibc and migration-reference/0
[10:33] <juliank> Or we can requeue tests we did not get to
[10:33] <juliank> Which is easy with the database
[10:33] <juliank> i.e. we can cancel migration-refernce/0 retesting and resume any time
[10:35]  * juliank will check in again in an hour or so
[10:36] <sil2100> juliank: will reach out to you, for now waiting for the run to finish ;)
[10:44] <sil2100> Man, the publisher is really busy
[11:12] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (noble-proposed/main) [24.04.52 => 24.04.53] (desktop-core, i386-whitelist)
[11:32] <ricotz> hello, looks like libreoffice didn't made it, it got deleted from noble-proposed, but still not available in noble-release - https://launchpad.net/ubuntu/+source/libreoffice/4%3A24.2.2~rc2-0ubuntu1/+publishinghistory
[11:34] <juliank> ricotz: give it time
[11:34] <juliank> ricotz: absurd amounts of time
[11:35] <juliank> It's the same for other stuff
[11:36] <juliank> Publisher died or something
[11:37] <ricotz> yeah, although I didn't expect it to be lost between pockets though ;)
[11:40] <juliank> It always gets lost like that just much shorter
[11:40] <juliank> As long as it's pending it should be fine
[11:45] <ricotz> alright, time will tell :)
[11:49] <LocutusOfBorg> Cannot handle removal: libmicrohttpd12
[11:49] <LocutusOfBorg>  done
[11:49] <LocutusOfBorg> Thu, 28 Mar 2024 11:43:01 +0000
[11:49] <LocutusOfBorg> STATS:
[11:49] <LocutusOfBorg> Finished at: Thu, 28 Mar 2024 11:45:56 +0000
[11:49] <LocutusOfBorg> so maaaaaaaaaaaaaybe
[11:58] <sil2100> There's a LOT of packages being moved around by the publisher
[11:59] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (noble-proposed) [24.04.53]
[12:07] <sil2100> Before unfreezing noble, I'd really like to start seeing packages published in the release pocket
[12:10] <jbicha> 👍
[12:14] <jchittum> not sure if this is a good place to reach out, but i used to have access to edit the release notes pages, but I don't anymore. was going to update things for `cloud` while philroche is having fun
[12:24] <juliank> sil2100: When did we start time_t transition uploads? I was relaxing and it just occured to me I can add a filter for packages for which we ran tests since then (on any architecture) for the reference try since then
[12:24] <juliank> i.e. do something like AND test.package IN (SELECT package FROM test JOIN result ON test.id == result.test_id AND run_id >= "20240301")
[12:24] <juliank> I'm terrible at writing SQL to spec
[12:29] <schopin> juliank: sil2100: Matthias found a fix for the glibc FTBFS so it's back on the table if there's still time :)
[12:29] -queuebot:#ubuntu-release- Unapproved: libreoffice (mantic-proposed/main) [4:7.6.5-0ubuntu<IP_ADDRESS> => 4:7.6.6-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[12:32] <ahasenack> juliank: hi, 'morning. Do you have a quick tl;dr about the state of noble? I see a bunch of packages migrated overnight. Next step is the migration-reference/0 runs?
[12:34] <juliank> schopin: ship it
[12:34] <juliank> ahasenack: More or less, just narrowing down the runs right now, and some glibc and RUNNING retries to sort out too
[12:39] -queuebot:#ubuntu-release- Unapproved: gcc-13 (noble-proposed/main) [13.2.0-21ubuntu1 => 13.2.0-22ubuntu1] (i386-whitelist)
[12:42] -queuebot:#ubuntu-release- Unapproved: accepted gcc-13 [source] (noble-proposed) [13.2.0-22ubuntu1]
[12:42] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (noble-proposed) [1:<IP_ADDRESS>ubuntu1]
[12:45] <juliank> ahasenack: We need to run amd64:11634 arm64:11602 armhf:11254 i386:2284 ppc64el:11417 s390x:11185 migration-reference/0 tests fwiw
[12:45] <juliank> The script to calculate the tests needed is here: https://gist.github.com/julian-klode/eb730e8cfa7377eb8dddaca86c1e8143
[12:45] <ahasenack> just a normal day then
[12:45] <ahasenack> :)
[12:45] <juliank> You can resume it any time, and it only triggers packages that have been triggered since Feb 25
[12:46] <juliank> It also filters for packages that are actually still in the release pocket, and makes sure we had successful runs on that architecture before
[12:46] <juliank> It also is resumable; you can purge the queues and run the script again and it will issue the remaining ones again
[12:46] <juliank> But really it's just one big SQL query
[12:48] <juliank> Anyway that's down from 17k test runs, or I think initially it was 19k
[12:52] <juliank> amd64:404 arm64:54 armhf:4 i386:5 ppc64el:9 s390x:2
[12:52] <juliank> ^ Number of RUNNING tests per retry-autopkgtest-regressions
[12:55] <doko> juliank, schopin: we're having uninstallabilities on the buildds: https://launchpadlibrarian.net/721581802/buildlog_ubuntu-noble-armhf.gcc-13_13.2.0-22ubuntu1_BUILDING.txt.gz
[12:57] <juliank> doko: is it because removals have been published but release binaries haven't?
[12:58] -queuebot:#ubuntu-release- Unapproved: gcc-13 (noble-proposed/main) [13.2.0-21ubuntu1 => 13.2.0-22ubuntu3] (i386-whitelist)
[12:58] <ricotz> ahasenack, hello :), in case you will still have time for SRUs, there is https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2058687
[12:58] -ubottu:#ubuntu-release- Launchpad bug 2058687 in libreoffice (Ubuntu Mantic) "[SRU] libreoffice 7.6.6 for mantic" [Medium, In Progress]
[12:59] <ahasenack> ricotz: ok
[12:59] <doko> juliank: most likely. wait for another publisher run?
[12:59] -queuebot:#ubuntu-release- Unapproved: accepted gcc-13 [source] (noble-proposed) [13.2.0-22ubuntu3]
[13:00] <ricotz> ahasenack, thank you very much
[13:00] <juliank> doko: sounds like it
[13:01] <doko> yes, the packages that I accepted 2h ago built fine
[13:01] <doko> schopin: just upload glibc when you're ready
[13:01] <juliank> total "real" queue length, running + retries: amd64:599 arm64:294 armhf:113 i386:46 ppc64el:335 s390x:382
[13:01] <juliank> i.e. after purging and requeuing the tests
[13:02] <juliank> We want to get rid of the leftover no longer useful tests
[13:02] <juliank> But doing so now is pointless
[13:02] <juliank> We need to have binaries in the release pocket published :)
[13:03] <juliank> Note that we still test with all-proposed until beta
[13:03] <juliank> Unless we remove the hacks in britney and autopkgtest-cloud earlier
[13:05] <juliank> But as vorlon said pytest trouble in proposed
[13:07] <juliank> Checking back in an hour again; ping me here earlier if something interesting happens
[13:09] -queuebot:#ubuntu-release- Unapproved: usbguard (focal-proposed/universe) [0.7.6+ds-1build1 => 0.7.6+ds-1ubuntu1] (no packageset)
[13:15] -queuebot:#ubuntu-release- Unapproved: at (noble-proposed/universe) [3.2.5-2.1ubuntu1 => 3.2.5-2.1ubuntu2] (no packageset)
[13:16] -queuebot:#ubuntu-release- Unapproved: emacs (noble-proposed/universe) [1:29.2+1-2ubuntu4 => 1:29.3+1-1] (no packageset) (sync)
[13:18] -queuebot:#ubuntu-release- Unapproved: octave-control (noble-proposed/universe) [4.0.0-2ubuntu1 => 4.0.1-1] (no packageset) (sync)
[13:20] -queuebot:#ubuntu-release- Unapproved: notmuch (noble-proposed/universe) [0.38.2-1.1ubuntu2 => 0.38.3-1ubuntu1] (no packageset)
[13:28] -queuebot:#ubuntu-release- Unapproved: util-linux (noble-proposed/main) [2.39.3-9ubuntu2 => 2.39.3-9ubuntu3] (core, i386-whitelist)
[13:38] -queuebot:#ubuntu-release- Unapproved: xz-utils (noble-release/main) [5.4.5-0.3 => 5.4.5-0.3] (core, i386-whitelist) (sync)
[13:46] <doko> juliank: ^^^ all these show up in unapproved, because they are already removed, but the new ones not yet published
[13:47] <juliank> whoa
[13:53] <doko> wait, it's xz-utils only
[13:56] <seb128> xz-utils was a manual archive admin change
[13:57] -queuebot:#ubuntu-release- Unapproved: emacs (noble-proposed/universe) [1:29.2+1-2ubuntu4 => 1:29.3+1-1ubuntu1] (no packageset)
[13:58] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (jammy-proposed) [8.0.0-1ubuntu7.9]
[14:02] -queuebot:#ubuntu-release- Unapproved: accepted xz-utils [sync] (noble-release) [5.4.5-0.3]
[14:06] <doko> RikMills: why the at upload?
[14:11] <RikMills> doko: the version in proposed with some wanted changes can't migrate because 2 archs built against libpam0t64 which renaming was shortly after reverted to libpam0g
[14:12] <doko> ahh, ok. I was only looking at the armhf build
[14:13] -queuebot:#ubuntu-release- Unapproved: accepted at [source] (noble-proposed) [3.2.5-2.1ubuntu2]
[14:23] -queuebot:#ubuntu-release- Unapproved: liferea (noble-proposed/universe) [1.15.4-1build1 => 1.15.4-1ubuntu1] (no packageset)
[14:31] -queuebot:#ubuntu-release- Unapproved: glibc (noble-proposed/main) [2.39-0ubuntu6 => 2.39-0ubuntu7] (core, i386-whitelist)
[14:32]  * tsimonq2 waits at the edge of my seat for an archive unfreeze
[14:33] -queuebot:#ubuntu-release- Unapproved: rejected glibc [source] (noble-proposed) [2.39-0ubuntu7]
[14:35] <tsimonq2> Looking at one last batch of Cala + settings, and a software-properties upload fixing a bug
[14:36] <tsimonq2> These will be in before Monday.
[14:36] -queuebot:#ubuntu-release- Unapproved: glibc (noble-proposed/main) [2.39-0ubuntu6 => 2.39-0ubuntu7] (core, i386-whitelist)
[14:39] <LocutusOfBorg> publisher still running?
[14:40] <LocutusOfBorg> still missing some riscv64 and s390x binaries in release pocket...
[14:41] <LocutusOfBorg> e.g. https://launchpad.net/ubuntu/+source/3depict/0.0.23-2build2/+build/27966342
[14:42] <LocutusOfBorg> stuff like fltk1.3 was copied on some archs and not on some others...
[14:53] <doko> waiting, also the buildd chroots for armhf are still broken
[15:03] <vorlon> LocutusOfBorg: "on some archs and not on some others" copies don't work like that in launchpad
[15:05] -queuebot:#ubuntu-release- Unapproved: accepted glibc [source] (noble-proposed) [2.39-0ubuntu7]
[15:06] <LocutusOfBorg> vorlon, what do you mean?
[15:06] <LocutusOfBorg> that all archs should go together in the pocket?
[15:06] <LocutusOfBorg> in atomic way?
[15:07] <vorlon> LocutusOfBorg: the launchpad api always does a source copy
[15:07] <LocutusOfBorg> and for binaries?
[15:07] -queuebot:#ubuntu-release- Unapproved: software-properties (noble-proposed/main) [0.99.44 => 0.99.45] (core)
[15:08] <LocutusOfBorg> the question, whn 3depict will finally build on riscv64 and s390x?
[15:08] <LocutusOfBorg> should we keep retrying, or just wait for some more time?
[15:13] <Eickmeyer> Is it me or are the publishers stuck? And if so, is that a #launchpad question?
[15:14] <cjwatson> If they are stuck (which I don't know) then it's a #launchpad question
[15:14]  * Eickmeyer feels like his brain regressed about 4 years this morning
[15:14] <cjwatson> Other folks don't generally have enough log access to be able to determine anything useful
[15:15] <Eickmeyer> cjwatson: Thanks for the tip. They've got a new Matrix room which has been very helpful lately. :)
[15:17] <sergiodj> hi, I'm about to do a bugfix upload of libvirt.  just wanted to check if it's OK to go ahead given the temporary freeze mention in the topic
[15:22] <Eickmeyer> Ok, per Launchpad team, things are chugging along.
[15:32] <tsimonq2> choo choo
[15:38] <vorlon> LocutusOfBorg: the binaries all always come with the source copy (including binaries that have previously been deleted
[15:39] <vorlon> )
[15:39] <LocutusOfBorg> so, how could 3depict build everywhere except riscv64 and s390x?
[15:39] <vorlon> arraybolt3: since I saw you were doing some work on ubuntu-unity, you should be aware of LP: #2051343 which makes ubuntu-unity unreleasable
[15:39] -ubottu:#ubuntu-release- Launchpad bug 2051343 in unity (Ubuntu) "unity: FTBFS in Noble" [Critical, New] https://launchpad.net/bugs/2051343
[15:39] <LocutusOfBorg> fltk1.3 looks partially copied...
[15:40] <vorlon> arraybolt3: I tried to ping rs2009 on Matrix but didn't see any reply
[15:42] <tsimonq2> vorlon: I know it's on rs2009's radar, haven't heard back on if he's found the time yet.
[15:43] <vorlon> ok
[15:45] -queuebot:#ubuntu-release- Unapproved: libvirt (noble-proposed/main) [10.0.0-2ubuntu5 => 10.0.0-2ubuntu6] (ubuntu-server, virt)
[15:45] <sergiodj> ^ uploaded libvirt
[15:47] <vorlon> LocutusOfBorg: the build log says "is not installable", not "is not available"
[15:51] <arraybolt3> vorlon: rs2009 replied to you on Matrix, it seems you didn't see it?
[15:51] <arraybolt3> check the Ubuntu Flavors room
[15:51] <arraybolt3> he's working on it
[15:51] <vorlon> ok
[15:51] <vorlon> (did he reply recently? I don't leave a matrix client open because they're all terrible)
[15:51] <tsimonq2> Eickmeyer, sgmoore, arraybolt3: I'm reading that this software-properties update Just Migrated is intended to fix incompatibilities with a deb822-only system, let's give that another round of testing before diving in further...
[15:52] <Eickmeyer> 👍
[15:53] <arraybolt3> also, any ETA on the archive being unfrozen? I know things are in a state of churn, but there are some pre-Beta Freeze uploads we had planned that still need to move through the pipeline.
[15:53] <tsimonq2> vorlon: looks like he replied on Tues at 1:24 PM US Central
[15:54] <arraybolt3> obviously I don't expect it to be unfrozen right now, but some time before The Day Of Frozenness would be nice.
[15:54] <arraybolt3> (we = Lubuntu and probably other flavors)
[15:54] <tsimonq2> I'm still convinced Beta Freeze being on April 1st makes it an April Fool's joke. >:P
[15:54] <vorlon> arraybolt3: we should unfreeze as soon as the publishing is done
[15:55]  * tsimonq2 cheers on the publisher
[15:56] <tsimonq2> arraybolt3: cala settings in progress atm, we can follow up at the Lubuntu standup later today
[15:57] <arraybolt3> fantastic
[15:58] <LocutusOfBorg> Package libfltk1.3t64 is not available, but is referred to by another package.
[15:59] -queuebot:#ubuntu-release- Unapproved: accepted emacs [sync] (noble-proposed) [1:29.3+1-1]
[15:59] -queuebot:#ubuntu-release- Unapproved: accepted notmuch [source] (noble-proposed) [0.38.3-1ubuntu1]
[15:59] <LocutusOfBorg> vorlon, what does this mean then? I don't have on amd64, but I have on s390x
[15:59] -queuebot:#ubuntu-release- Unapproved: accepted emacs [source] (noble-proposed) [1:29.3+1-1ubuntu1]
[15:59] -queuebot:#ubuntu-release- Unapproved: accepted octave-control [sync] (noble-proposed) [4.0.1-1]
[16:04] <arraybolt3> vorlon: I'm about to look into the unity build failure, fyi
[16:04] <Eickmeyer> vorlon: Finding an oddity on Ubuntu MATE's .iso image. It seems that ubuntu-desktop-bootstrap isn't fully preseeding.
[16:05] <Eickmeyer> In fact, as far as the snap command is concerned, it's not installed at all, but it's there.
[16:05] <Eickmeyer> But it doesn't run correctly.
[16:09] <tsimonq2> Eickmeyer: IME that usually indicates that one of the snaps it depends on is not present. I'd find the delta between the snaps listed in the seed.yaml file and cross-ref that with the list snap install provides.
[16:10] <tsimonq2> Next cycle this will be better, because I have code that actually, properly grabs this list, just waiting on the latest snapd..............
[16:11] -queuebot:#ubuntu-release- Unapproved: dotnet8 (noble-proposed/universe) [8.0.103-8.0.3-0ubuntu1 => 8.0.103-8.0.3-0ubuntu2] (no packageset)
[16:11] <Eickmeyer> tsimonq2: It has no other dependencies. It's a classic snap which means it can use system dependencies.
[16:11] <tsimonq2> In fact, according to the snapd release cycle, this lands on Monday. There are hardly ways to communicate with the snapd team on this sort of timing unless I bug people to no end or post on the forums, neither of which I have had the spare energy to do.
[16:12] <tsimonq2> Eickmeyer: k so why would snap preseed fail, that's the next question
[16:13] <Eickmeyer> tsimonq2: Something wonky in livecd-rootfs. It's in the manifest but snap doesn't see it, but the command is available in /snap/bin.
[16:16] <tsimonq2> Eickmeyer: "in the manifest but snap doesn't see it" is what I mean by, the snap preseed failed
[16:16] <tsimonq2> bah I'll look myself
[16:17] <Eickmeyer> Found this in the build log: `helpers.go:146: error trying to compare the snap system key: system-key missing on disk` in the classic preseed.
[16:18] <Eickmeyer> tsimonq2: ^
[16:19] <tsimonq2> Eickmeyer: is this limited to Ubuntu MATE or all flavors of the sort?
[16:20] <Eickmeyer> That's my next step to figure out.
[16:21] <tsimonq2> Eickmeyer: do you know why we forgot to symlink the hook for Ubuntu MATE? https://git.launchpad.net/livecd-rootfs/tree/live-build
[16:22] <Eickmeyer> tsimonq2: Because we forgot and that's probably why. 🤦
[16:22] <Eickmeyer> MP incoming.... and I'm an idiot.
[16:23] <tsimonq2> https://git.launchpad.net/livecd-rootfs/tree/live-build/functions#n741
[16:23] <tsimonq2> that's where the code would live iff this does not work
[16:25] <tsimonq2> k out of time on this one, going back to cala
[16:37] <Eickmeyer> vorlon: At your earliest convenience: https://code.launchpad.net/~ubuntu-mate-dev/livecd-rootfs/+git/livecd-rootfs/+merge/463301
[16:39] <Eickmeyer> Or sil2100 if you're still awake (since your name is on the changelog) ^
[16:41] <dbungert> Eickmeyer: LGTM, merging
[16:41] <Eickmeyer> dbungert: Thanks! :D
[16:50] <vorlon> image builds look like they're all failing at the debootstrap stage, because of trying to unpack both t64 and non-t64 libs over each other.  Working on priority mismatches now to fix
[16:50] <vorlon> (https://ubuntu-archive-team.ubuntu.com/priority-mismatches.html)
[16:51] <seb128> how are priority being defined?
[16:54] <vorlon> LocutusOfBorg: where do you see "is not available"? I don't have that in the current log on either riscv64 or s390x for 3depict
[16:56] <LocutusOfBorg> vorlon, on local pbuilder s390x chroot
[16:56] <LocutusOfBorg> but also on https://launchpad.net/ubuntu/+source/3depict/0.0.23-2build2/+build/27966343 log
[16:57] <vorlon> LocutusOfBorg: ok. so anyway, rmadison currently doesn't see libfltk1.3t64 available on *any* arch.  I think these builds have just hit a race vs. the package disappearing from -proposed and reappearing in the release pocket, and are going to have to wait for the publisher to shake out
[16:58] <LocutusOfBorg> yeah while this is true, what I don't get is that amd64 arm64 armhf ppc64el are good since hours, like since 12h ago
[16:58] -queuebot:#ubuntu-release- Unapproved: netplan.io (noble-proposed/main) [1.0-1 => 1.0-2] (core) (sync)
[16:58] <LocutusOfBorg> 7h ago
[16:58] <LocutusOfBorg> anyway if you think publisher will sort it out by itself, even better
[16:59] <vorlon> LocutusOfBorg: they're *not* good
[16:59] <vorlon> LocutusOfBorg: those builds were lucky enough to happen before the package disappeared from -proposed
[16:59] <LocutusOfBorg> oh... ok then it makes sense
[17:00] <vorlon> seb128: sorry, what are you asking wrt priority? this is the Priority: field in the apt indices
[17:00] <vorlon> seb128: which debootstrap relies on
[17:02] <vorlon> seb128: it would sort of be helpful if we just never had runtime libraries at Priority: required in the archive, because then debootstrap installing "required packages and all their dependencies" would just DTRT
[17:22] <seb128> vorlon, yes, I was asking about that, I had no idea that's something we sometime needed to tweak or fix
[17:22] <vorlon> yep - NBS libraries at Priority: required will sometimes break debootstrap
[17:22] <vorlon> is this documented in the AA wiki?
[17:24] <vorlon> seb128: lol I covered this in my draft new-aa-member training guide
[17:24] <vorlon> which was shared with you for comment before I start porting anything there into the wiki ;)
[17:31] <doko> just updated a desktop to noble-release. only thing non upgradable yet: gnome-calendar
[17:31] -queuebot:#ubuntu-release- Unapproved: softhsm2 (noble-proposed/universe) [2.6.1-2.2ubuntu1 => 2.6.1-2.2ubuntu2] (i386-whitelist)
[17:33] <seb128> vorlon, ah, I need to read that one! :-)
[17:33] -queuebot:#ubuntu-release- Unapproved: accepted softhsm2 [source] (noble-proposed) [2.6.1-2.2ubuntu2]
[17:35] <vorlon> seb128: well I mention debootstrap but don't mention it can /break/ bootstrap
[17:36] <vorlon> (because conflicts are rare!)
[17:38] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (noble-proposed) [10.0.0-2ubuntu6]
[17:38] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (noble-proposed) [0.99.45]
[17:38] -queuebot:#ubuntu-release- Unapproved: accepted netplan.io [sync] (noble-proposed) [1.0-2]
[17:38] -queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (noble-proposed) [2.39.3-9ubuntu3]
[17:57] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (noble-proposed/main) [24.04.53 => 24.04.54] (desktop-core, i386-whitelist)
[18:10] <wxl> there are two versions of calamares in the noble release pocket. can we perhaps nix 3.3.4-0ubuntu1?
[18:11] -queuebot:#ubuntu-release- Unapproved: gopacket (noble-proposed/universe) [1.1.19-4build1 => 1.1.19-6] (no packageset) (sync)
[18:13] <juliank> vorlon: In stupid things, retry-autopkgtest-regression's "is this already queued" thing didn't actually work: https://code.launchpad.net/~juliank/ubuntu-archive-tools/+git/ubuntu-archive-tools/+merge/463305
[18:13]  * juliank patched his local one to check the queues for --state=RUNNING as well and then it had no effect because the stupid thing checked newlines
[18:15] <juliank> This was very surprising
[18:16] <wxl> ubuntu-archive actually there are two packages with two versions in the noble release pocket. please remove calamares 3.3.4-0ubuntu1 and calamares-settings-ubuntu 1:24.04.16
[18:31] <LocutusOfBorg> wxl, it should fix itself
[18:32] <LocutusOfBorg> publisher is getting some hard time to finish the big transition
[18:36] <cjwatson> Yeah, the dominator should work that out eventually if it isn't crashing or something
[19:09] <juliank> britney says:
[19:09] <juliank> awk: cmd. line:3: warning: command line argument `/home/ubuntu-archive/proposed-migration/var/data-b2/noble-proposed/Hints/kernel-testing-hints' is a directory: skipped
[19:10] <vorlon> juliank: long-term warning
[19:10] <vorlon> it's been there since kernel team hints were landed years ago
[19:10] <juliank> ack
[19:10] <vorlon> shrug
[19:11] <juliank> How is the publisher looking?
[19:11]  * juliank is anxiously awaiting the publisher to be done so his migration-reference/0 can be queued
[19:12] <juliank> maybe glibc can land first, but it fails with unsat build-depends on armhf which is annoying
[19:13] <juliank> And amd64 queues are still running at like 8 tests / hour
[19:13] <juliank> bdmurray: seems the partial amd64 fix was very partial
[19:13] <vorlon> I haven't taken the time look at publisher logs.  a few hours ago, LP team said things are running, it just has indigestion from trying to swallow too much at a time; previous publisher run clocked in at 4h and the one running at the time had already surpassed that
[19:14] <juliank> yeah
[19:14] -queuebot:#ubuntu-release- Unapproved: apt-clone (noble-proposed/universe) [0.4.3+nmu2 => 0.4.3+nmu2ubuntu1] (no packageset)
[19:14] <juliank> I'm taking glibc is in update_excuses as the right time to queue the tests
[19:15] <juliank> Or your EOD, whatever comes first?
[19:15] <juliank> Something like that
[19:15] <vorlon> yeah
[19:16] <juliank> I'll go back to actually trying to prep for guests tomorrow
[19:16] <vorlon> juliank: enjoy :)
[19:20] -queuebot:#ubuntu-release- Unapproved: accepted crun [source] (jammy-proposed) [0.17+dfsg-1.1ubuntu0.1]
[19:23] <vorlon> wow trying to figure out the grok build failure and uh bison+flex seem to be a real mess under -Werror=implicit-function-declaration
[19:23] <vorlon> also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065556 is completely different from the build failure I get here...
[19:23] -ubottu:#ubuntu-release- Debian bug 1065556 in src:grok "grok: FTBFS on armhf and armel: implicit declaration of function ‘asprintf’" [Serious, Open]
[19:24] <cjwatson> flex has been fine for me ...
[19:24] <cjwatson> I can imagine having to be a bit careful with %top or something
[19:28] <vorlon> cjwatson: well, the packaging is wonk because it build-depends on bison and flex and then never uses them at build-time; but if I force regenerate things I get a different set of implicit declaration problems
[19:28] <vorlon> conf.tab.c:1494:16: error: implicit declaration of function ‘yylex’ [-Werror=implicit-function-declaration]
[19:28] <vorlon> seems like uh that should have been declared
[19:29] <vorlon> there are also declaration failures in the code itself
[19:30] <vorlon> anyway it's ftbfs in Debian and blocks time_t and I think I'm just going to kick it out
[19:45] -queuebot:#ubuntu-release- Unapproved: accepted dotnet8 [source] (noble-proposed) [8.0.103-8.0.3-0ubuntu2]
[19:45] -queuebot:#ubuntu-release- Unapproved: accepted apt-clone [source] (noble-proposed) [0.4.3+nmu2ubuntu1]
[19:45] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (noble-proposed) [24.04.54]
[19:46] -queuebot:#ubuntu-release- Unapproved: python-build (jammy-proposed/universe) [0.7.0-2 => 0.7.0-2ubuntu0.1] (no packageset)
[19:58] <bdmurray> juliank: wow, it's always something
[20:06] <vorlon> juliank: so https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt is empty, and that's accurate right?
[20:07] <juliank> vorlon: it is complicated, it only tracks cross-pocket transitions right now, aka libfoo1 in release and libfoo1t64 in proposed
[20:07] <vorlon> aha
[20:08] <juliank> Actually we can make it track t64 again
[20:08] <juliank> But for others it doesn't know the old name
[20:08] <doko> yes, I checked that at least daily, and fixed stuff when it appeared. but during mass publishing it shows some issues from time to time
[20:10] <juliank> vorlon: now it should work reliably but I need a test case
[20:11] <juliank> vorlon: i.e. a t64 library we force migrated despite uninstallable rdeps on armhf (which may be in proposed)
[20:11] -queuebot:#ubuntu-release- Unapproved: accepted php8.1 [source] (jammy-proposed) [8.1.2-1ubuntu2.15]
[20:18] <juliank> vorlon: now it produces more results, I made it track transitions for every old library where we have a new one for
[20:18] <juliank> vorlon: based on your ftp map
[20:18] <juliank> this might miss some?
[20:19] <juliank> But of course rebuild-for only includes stuff that has armhf packages that need rebuilding
[20:19] <juliank> you can get an amd64 view too https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/global-ben.rebuild-for.txt
[20:29] <juliank> vorlon: It's reasonably good now, it gets fishy if libraries migrated more, but it's hard to figure out until we remove NBS pre-t64 libraries
[20:31] <vorlon> juliank: yeah so at this point the NBS report will pick up a lot of the slack too
[20:32] <juliank> So 2048-qt appears in the transition tracker because snapshot.ubuntu.com is already at a stage where the new build is not in proposed but not yet published in release
[20:32] <juliank> And stuff like that may of course appear in the rebuild trackers too
[20:33] <mwhudson> juliank: i think looking for patches with t64 in the name and Breaks is a better way than following the ftp-override map
[20:33] <mwhudson> er s/patches/packages/
[20:34] <juliank> mwhudson: It doesn't look at breaks yet but it will pick up appending any t64
[20:39] <juliank> mwhudson: vorlon OK now the non-armhf report is accurate too
[20:39] <juliank> the rebuild-for one, I had to make it track where t64 is in the release pocket too
[20:40] <juliank> Oh yeah and armhf too
[20:40] <juliank> It's huge now
[20:40] <juliank> Lots of broken packages in armhf I suppose
[20:40] <juliank> e.g. smplayer, Depends: mpv | mplayer, libc6 (>= 2.34), libgcc-s1 (>= 3.5), libqt5core5a (>= 5.15.1), libqt5dbus5 (>= 5.14.1), libqt5gui5 (>= 5.11.0~rc1) | libqt5gui5-gles (>= 5.11.0~rc1), libqt5network5 (>= 5.14.1), libqt5qml5 (>= 5.0.2), libqt5widgets5 (>= 5.15.1), libqt5xml5 (>= 5.0.2), libstdc++6 (>= 5), libx11-6, zlib1g (>= 1:1.1.4)
[20:40] <juliank> rebuild-for "libqt5core5t64, libqt5dbus5t64, libqt5gui5t64, libqt5network5t64, libqt5widgets5t64, libqt5xml5t64" smplayer
[20:40] <juliank> Go knock yourselves out
[20:41] <juliank> 4189 global-ben.rebuild-for.txt
[20:41] <juliank> amd64 shows:
[20:41] <juliank> 4781 global-ben.rebuild-for.txt
[20:41] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (focal-proposed) [2.664.53]
[20:42] <juliank> but yeah https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.txt is what we need to drive down (or at least biggest chunk of it) to get BREAK_ARCHES away for armhf
[20:43] <juliank> Note the report is pretty useless until the publisher is fully done
[20:43] <juliank> e.g. it says you need to rebuild libmatemixer; but that's because the new one is stuck between deletion from proposed and being published in release
[20:43] <juliank> i.e. it's just "lost" in the meantime
[20:44] <juliank> Revisit them tomorrow or on Monday or something
[20:44] <juliank> Not much that can be done now :(
[20:44] <juliank> Well we could hack in an old snapshot of proposed
[20:46] <juliank> Done that for armhf
[20:47] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (noble-proposed/main) [1:24.04.9 => 1:24.04.10] (core)
[20:47] <juliank> 387 packages to rebuild left
[20:48] <vorlon> juliank: BREAK_ARCHES> I already turned this off, we don't want to break more systematically now that the main cluster is through for beta
[20:48] <juliank> ack
[20:48] <juliank> vorlon: OK; reports should be actionable now, I injected the 20240327T235959Z snapshot
[20:49] <juliank> for proposed
[20:49] <juliank> Such that we don't have packages disappearing on us
[20:50] <juliank> I'll remove that again once people tell me publisher is down to 20 mins again :)
[20:50] <juliank> But in the meantime actionable is better :)
[20:54] <juliank> Ah shoot
[20:54] <juliank> I did not add deb-src
[20:55] <juliank> fixed
[20:56] -queuebot:#ubuntu-release- Unapproved: software-properties (noble-proposed/main) [0.99.45 => 0.99.46] (core)
[20:56] <juliank> It was ignoring cinnamon-control-center 6.something because the source for it was not published yet in real release pocket :)
[20:56] <juliank> because I did not have snapshot Sources file
[20:57] <juliank> Should be good now, more erronous rebuild-for sorted out
[20:57] <juliank> It does not get more accurate than that
[20:57] <juliank> Unless I do the t64 Breaks analysis thing of course :D
[20:58] <juliank> jak@magenta:/var/www/magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf$ wc -l global-ben.rebuild-for.txt
[20:58] <juliank> 135 global-ben.rebuild-for.txt
[20:58] <juliank> Reasonable
[20:58] <juliank> 453 for amd64 to get better upgrades
[20:58] <juliank> ciao!
[21:16] -queuebot:#ubuntu-release- Unapproved: interimap (noble-proposed/universe) [0.5.7-2ubuntu1 => 0.5.7-2ubuntu2] (no packageset)
[21:17] <juliank> I'll reboot magenta.jak-linux.org shortly, need to add some zswap to it, the dose-distcheck runs run out of memory
[21:17] <juliank> (cronjob gets killed)
[21:18] <juliank> OOh two parallel ones are running, that is no good
[21:21] <juliank> Ah it is running out of time because it checks the snapshot too for distcheck
[21:21] <juliank> I need to disable that, dose is slooow
[21:25] <juliank> And we're back online
[21:26] <juliank> I added a lock so we don't have concurrent runs
[21:28] <juliank> Ooh I forgot to enable zswap actually
[21:28]  * juliank did not run update-grub
[21:30] <juliank> Well anyway, reports should be working again
[21:31] <juliank> Doing an out-of-order run now manually
[21:31] <juliank> Enabled zswap at runtime :)
[21:33] <juliank> (thing has 2 vcores and 2GB  of RAM; dose-distcheck uses about 1.2GB of that...)
[22:13] -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (noble-proposed/universe) [24.04.2 => 24.04.3] (ubuntu-mate)
[22:23] <vorlon> so although the publisher was thought to be in working order, it is actually crashing
[22:23] <vorlon> the last 2 publisher runs (multi-hour long) have crashed
[22:23] <vorlon> I've escalated to the Launchpad team, but, well, it's the start of a holiday weekend
[22:39] <sarnold> s/end$//
[23:15] <sil2100> vorlon: ...multiple people from LP were looking at the logs and were telling me that they saw no errors :|
[23:15] <sil2100> Was I just unlucky with the runs they were looking at back then?
[23:17] <vorlon> sil2100: no.  The run that started at 11:05 UTC and finished at 16:45 UTC ended with a stack trace.  I do not know how this was not obviously apparent in the logs that people were looking at.
[23:18] <vorlon> (started at 11:08 UTC)
[23:19] <vorlon> there was a subsequent run starting at 16:48UTC and ending at 20:45UTC that failed with the same stack trace
[23:19] <arraybolt3> vorlon: I have a fix for the Unity FTBFS, but I was going to wait to upload until the archive was unfrozen. I get the feeling we're not going to be unfrozen until Beta Freeze hits though. How good or bad of an idea is it to upload now and ask for help?
[23:20] <vorlon> arraybolt3: you don't need to wait before uploading
[23:20] <arraybolt3> awesome, upload incoming now then
[23:20] <vorlon> arraybolt3: are you changing unity itself?  when I was discussing it this morning, it appeared unity had recently built successfully so that package was not affected, but all the others in the stack seemed to be
[23:21] <vorlon> i.e. the workaround from https://launchpad.net/ubuntu/+source/unity/7.7.0+23.04.20230222.2-0ubuntu4
[23:21] <arraybolt3> I was changing the unity package itself, I didn't realize any other packages were affected.
[23:21] <arraybolt3> It looks like I looked at the bug before the other packages were added.
[23:22] <arraybolt3> *sigh*
[23:22] <arraybolt3> or have the other packages been in that list all along and I just missed them?
[23:22] <vorlon> no those were added this morning based on discussion
[23:23] <vorlon> when it was communicated previously, it was said only that "unity" had a C++ standard incompatibility with its build-dep - not all the associated packages
[23:26] <arraybolt3> ah ok
[23:26] <arraybolt3> well crud, I guess that means we find out if all the other packages survive a C++14 build as smoothly as Unity itself did :P
[23:33] <arraybolt3> vorlon: I fear that the only reason Unity builds now when it didn't before is most likely because of some of the churn around packaging lately. I already know Unity builds with C++14, and while I couldn't test it due to the archive churn, it at least does indeed build. Do you think it's worth uploading Unity itself anyway?
[23:36] <vorlon> arraybolt3: what is it you've changed to upload?
[23:37] <vorlon> arraybolt3: since, per above, the incompatibility with googletest was already fixed in the archive by disabling the tests
[23:37] <arraybolt3> I changed the CMakeLists.txt file from building with C++11 to C++14. That was it.
[23:37] <vorlon> ok
[23:38] <vorlon> that's worth uploading if you're also re-enabling the tests
[23:38] <arraybolt3> it looks like the build failure for the other Unity applications is entirely unrelated sadly.
[23:38] <arraybolt3> "error: `Regex' is an ambiguous reference between `GLib.Regex' and `Posix.Regex'"
[23:39] <arraybolt3> which looks like something changed in Vala I guess, or maybe GLib
[23:50] <arraybolt3> well this is fine. Looks like this package hasn't been rebuilt since 2020 and now *something* is different in how things work with Vala or some such.
[23:58] -queuebot:#ubuntu-release- Unapproved: c2esp (noble-proposed/main) [27-11ubuntu3 => 27-11ubuntu4] (desktop-core)


[13:51] <lubuntuuser> hi
[13:52] <lubuntuuser> what is the name of the package containing the expert installer?
[13:52] <lubuntuuser> command-line also works, so i can search for content