[00:13] <vorlon> dbungert: ok don't filter out rejected_permanently, those are *more* likely to require attention
[00:14] <vorlon> RAOF: indeed, fine to remove things that should be removed
[00:14] <dbungert> vorlon: got it, fixing
[00:15] <dbungert> cpete: this list may be more actionable as it is more focused on regressions and less on missing builds https://paste.ubuntu.com/p/KBtbw5Hctr/
[00:17] <cpete> dbungert: great, thanks!
[00:29] <vpa1977> ppp is missing include for sif6down. Anyone working on it?
[00:37] <mwhudson> cpete: so are you working on a package?
[00:37] <cpete> looking at accountsservice
[00:38] <mwhudson> should this be like the pre-armhf thing where we say in here which package we are looking at?
[00:38] <cpete> works for me
[00:39] <vpa1977> mmm, taking cdrkit?
[00:39] <mwhudson> oh that's a fairly short list!
[00:39] <dbungert> oh, needs to be longer sorry
[00:39] <dbungert> https://paste.ubuntu.com/p/G4spdRJ55X/
[00:39] <mwhudson> didn't cjs get removed on armhf?
[00:39] <mwhudson> dbungert: boo!
[00:39] <cpete> I skipped abseil because I think I read something in scrollback about updates to it? needs checking
[00:40] <dbungert> mwhudson: I need a newer yaml
[00:40] <dbungert> missingbuild only entries are likely to have been retried
[00:40] <mwhudson> ah but cjs has binaries in updates now
[00:41] <mwhudson> vorlon: remove cjs/armhf from noble-updates?
[00:45] <dbungert> I wonder if I should filter missingbuild entirely, it seems unhelpful and people's retry scripts seem effective enough there
[00:48]  * mwhudson glares at i386 regressions
[00:49] <mwhudson> eh these just need to be retried i think
[00:49] <mwhudson> (looking at alsa-lib)
[00:51] <dbungert> taking alsa-utils
[00:52] <arraybolt3> another armhf evaluation party?
[00:53] <dbungert> looking at actionable things related to seeded packages.  The definition of "actionable" is still being worked out
[00:53] <mwhudson> arraybolt3: this is more amd64 focused thanks to xz-utils
[00:53] <dbungert> this list might be pretty good: https://paste.ubuntu.com/p/ktsBMt4rmT/
[00:54] <vorlon> mwhudson: can't remove from noble-updates because launchpad lolz, but I will hint it, thanks
[00:55] <dbungert> taking apache2
[00:56] <liushuyu> Are we having another combing through the -proposed?
[00:56] <mwhudson> vorlon: hnngh
[00:56]  * arraybolt3 is wondering the same thing - preparing to try and help with it if possible
[00:57] <liushuyu> Also I proposed the SRU for a GDB fix (regression since GDB 10) https://code.launchpad.net/~liushuyu-011/ubuntu/+source/gdb/+git/gdb/+merge/463546 ...
[00:57] <liushuyu> ... the accompanying SRU bug: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856
[00:57] -ubottu:#ubuntu-release- Launchpad bug 2059856 in gdb "gdb 10.0 fails to examine any global variables in D programs" [Medium, Confirmed]
[00:58] <dbungert> arraybolt3: liushuyu: the list I posted has autopkgtest regressions blocking seeded packages.  Consider looking at those regressions - do they just need a retest click?  Do they have a queued test already?  Real regression?
[00:58] <arraybolt3> awesome
[00:58] <arraybolt3> I'll tentatively grab apparmor then
[00:58] <mwhudson> haha awesome is a source package but not on the list
[00:58] <liushuyu> dbungert: okay, so it's indeed the same activity, with a different set of packages
[00:58] <vpa1977> ok, grabbing appstream
[00:58] <mwhudson> i'll look at apr
[00:59] <liushuyu> taking apr-util
[00:59] <arraybolt3> update-excuses is more trustworthy than last time this time I assume?
[00:59] <mwhudson> yes
[01:02] <arraybolt3> apparmor seems to be hung up trying to install libvirt 10.0.0-2ubuntu6 rather than 10.0.0-2ubuntu7
[01:02] <arraybolt3> in the arm64 autopkgtest
[01:02] <arraybolt3> so I *think* it probably needs retried against all-proposed since the time it was triggered by the newer libvirt, it passed
[01:04] <vpa1977> appstream, tests queued.
[01:04] <vpa1977> taking apt (line 8)
[01:04] <liushuyu> for apr-util: I think it's LP was having a stroke at that moment, some packages have mismatched versions
[01:04] <arraybolt3> and the i386 regressions are just a mess, tons of installability weirdness
[01:05] <arraybolt3> (for apparmor)
[01:05] <liushuyu> are we going to have a re-test or ask someone to hint the test?
[01:05] <arraybolt3> who do I ping to ask for a test retry in a Main package?
[01:06] <sarnold> is there a 386 apparmor? o_O
[01:06] <arraybolt3> sarnold: yup :)
[01:06] <sarnold> I wonder if that's intentional :)
[01:06] <sarnold> sure there's a libapparmor for things but I thought our 386 packages in noble basically existed just for games or something like that
[01:06] <liushuyu> arraybolt3: many people in this channel can do that. Just ask away
[01:07] <arraybolt3> sarnold: well games need confined too don't you think? (not sure if apparmor works that way but whatever)
[01:09] <liushuyu> taking aptitude
[01:10] <mwhudson> taking argyll
[01:10] <arraybolt3> Please retest against all-proposed apparmor. Looks like it's missing needed deps that are still in -proposed.
[01:10] <arraybolt3> taking aribb24
[01:10] <liushuyu> Hmm... Are we just going to re-queue the tests this time?
[01:10] <liushuyu> arraybolt3: Will re-try your test
[01:11] <liushuyu> arraybolt3: ... also against which trigger/package?
[01:12] <arraybolt3> all-proposed?
[01:12] <arraybolt3> ah, I guess you need a trigger package too
[01:12] <arraybolt3> in that case trigger it against libvirt
[01:14] <liushuyu> arraybolt3: done. Retried apparmor/4.0.0-beta3-0ubuntu2 vs 4.0.0-beta3-0ubuntu2 w/ all-proposed=1 on i386
[01:14] <sarnold> I clicked a few buttons onthe apparmor thing let me know if I clicked the right ones or not :)
[01:15] <liushuyu> ... also done on amd64
[01:16] <arraybolt3> liushuyu: I think it also needs done on arm64 and s390x
[01:16] <vorlon> are these regressed tests being retried?
[01:16] <arraybolt3> and armhf
[01:17] <arraybolt3> These are all regressed, yes.
[01:17] <arraybolt3> amd64 actually wasn't regressed, and i386 wasn't going to be considered a regression, I was looking at other things testing against apparmor with my comments about i386 earlier
[01:17] <arraybolt3> sorry, I should have been more clear
[01:19] <liushuyu> arraybolt3: someone else probably already queued those
[01:19] <vorlon> sarnold: you can look at the germinate output if you want to see why apparmor is there on i386; basically we have to have the closure of build-deps of the things we actually care about
[01:20] <liushuyu> aptitude tests retried w/ all-proposed=1
[01:20] <arraybolt3> aribb24 seems to not need any action, all the failures look to be because of other archive in-flux issues
[01:21] <wgrant> Gardened the riscv64 build farm a bit, and we're now looking at about 21h to clear the queue. s390x about 15h.
[01:22] <liushuyu> taking arpack
[01:22] <arraybolt3> taking atkmm1.6
[01:22] <vpa1977> apt - tests failing due to uninstallability, retried with all-proposed
[01:23] <vpa1977> taking at-spi2-core
[01:23] <liushuyu> arpack retried w/ all-proposed=1 due to archive fluctuations
[01:23] <liushuyu> taking "audit"
[01:24] <arraybolt3> atkmm1.6 seems to have nothing that's directly its fault going on, moving on
[01:24] <arraybolt3> taking avahi
[01:28] <liushuyu> retried tests from "audit" w/ all-proposed (unable to install test-depends)
[01:28] <arraybolt3> (I'm assuming a package only needs action taken if there's something directly wrong with *it* causing problems - I think that might not be right in retrospect?)
[01:28] <arraybolt3> (like should I be asking for mass retries for things where all the regressions are just because of badpkg fails?)
[01:29] <liushuyu> arraybolt3: some of those badpkg fails are hard to tell (it might get past the package installation step and failed somewhere in the actual test)
[01:30] <liushuyu> taking base-files
[01:30] <vpa1977> retried all-proposed for at-spi2-core
[01:30] <vpa1977> taking bash
[01:31] <vpa1977> bash/dkim-rotate is failing on armhf due to faketime, please mark as non-regression
[01:31] <liushuyu> base-files tests retried
[01:31] <liushuyu> taking bc
[01:34] <liushuyu> arraybolt3: asking for mass retries for things where all the regressions are just because of badpkg fails? > on the second thought, this may work, although I am unsure it's acceptable to just blindly retry them w/ all-proposed=1
[01:37]  * arraybolt3 just remembered that for non-main things I can actually do retries myself
[01:43] <mwhudson> i'm yet to see a "real" failure tbh
[01:44] <arraybolt3> just threw aribb24's fails back into the fray, some with all-proposed and one with targeted triggers
[01:44] <vpa1977> bash is failing tests due to faketime, badpkg regressions retried with all-proposed
[01:45] <vpa1977> taking bind9
[01:50] <mwhudson> tempted to say we should take the list, mash retry and go to bed
[01:51] <dbungert> mwhudson: that may well be correct.  I went through a lot of filter iterations before I came to something that was actionable at all
[01:53] <arraybolt3> Pretty much everything I'm doing is mashing retry
[01:54] <arraybolt3> I found *one* strange-looking lxc thing a bit ago but I wasn't sure if it was a false positive or not
[01:55] <arraybolt3> Need someone to hit libreoffice:armhf with an all-proposed hammer with trigger avahi
[01:57] <liushuyu> arraybolt3: done
[02:00] <dbungert> mwhudson: so you tell me - do you think we should feed this list into a query on retry-autopkgtest-regressions ?
[02:01] <mwhudson> dbungert: i don't know. the queues are pretty long already :/
[02:01] <arraybolt3> also need nss-mdns:i386 retried, trigger avahi/0.8-13ubuntu5, all-proposed=1
[02:01] <mwhudson> dbungert: but i also don't feel like this analysis is doing anything useful
[02:02] <arraybolt3> ditto with pulseaudio
[02:02] <vpa1977> i kind of seeing badpkg, retry with all-proposed ...
[02:02] <dbungert> ok, pull the plug I say, I'll try to slice the data another way
[02:03] <vpa1977> arraybolt3: done
[02:04] <arraybolt3> ty
[02:04]  * arraybolt3 waits to snag a package until the next list revision appears
[02:05] <dbungert> arraybolt3: see mwhudson's comments above, I think the suggestion is to pause and see if we can get better data
[02:06] <arraybolt3> that sounds like a decent idea
[02:06] <arraybolt3> there are an awful lot of tests in progress, I was starting to wonder if I was just going to bog down the already slammed infra more
[02:06] <arraybolt3> (part of me wishes I had a local build farm and fiber internet so I could do things locally and know if they were going to work or not in the archive. Alas, I don't have either of those :P)
[02:07] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (focal-proposed) [6.0.0-0ubuntu8.18]
[03:19] <vorlon> dbungert, mwhudson: is https://paste.ubuntu.com/p/ktsBMt4rmT/ still the list being worked from?
[03:20] <vorlon> vpa1977: fwiw bash was resurrected in the release pocket so is not critical path anymore
[03:23] <mwhudson> vorlon: i think so
[03:43] <dbungert> vorlon: when I excluded autopkgtests the missingbuild items remaining were largely in a state of build pending or in progress.  AFAICT update_excuses.yaml isn't showing something that FTBFS.  And if I focus on autopkgtest to the exclusion of missingbuild, people felt like it was retry bait.  I found one lone item which didn't fit these two categories, libgpod which looks like it needs a MIR
[03:43] <dbungert> on a dependency.
[03:47] <vorlon> which probably means what it actually needs is a change backed out, since it's late to be introducing new MIRs
[03:47] <vorlon> ?
[03:47] <vorlon> but hang on, libgpod is a no-change rebuild vs the release pocket
[03:48] <dbungert> libgpod-dev/amd64 in main cannot depend on libimobiledevice-dev in universe
[03:48] <vorlon> so how does it have this dep now if it didn't before
[03:49] <vorlon> it did have it before so how did it get into the release pocket like this
[03:49] <vorlon> dig dig
[03:50] <vorlon> it was in main, and doko demoted it; unfortunately there's no 'reason' field for override changes. I'll put it back to main
[04:00] <vorlon> so the thing about the missingbuild packages all being build pending or in progress is that they're likely to be in that state because I'm retrying the builds hourly... but that doesn't mean they're going to succeed any time soon.  I think I'm going to back that off now to 4 hours
[04:02] <vorlon> done. I can bring it back up to 1h after folks have had a chance to actually look at the build failures; but at this point I suspect it's probably only the riscv64 qt dep chain that will fix itself with blind retries and everything else needs attention
[04:02] <mwhudson> having them be in needs build all the time does make diagnosing issues hard
[04:02] <mwhudson> anyway i have to go collect a child
[04:03] <dbungert> ok, I can produce a new report of those missingbuild items
[04:04] <vorlon> I also appear to have a list of 3000+ packages that are no-change rebuilds against the release pocket and so are candidates for hinting through without waiting for tests
[04:16] <vorlon> make that 4200
[04:17] <vorlon> and that list is missing some
[04:20] <dbungert> so if we wanted to chase those missing builds then something like this: https://paste.ubuntu.com/p/Zr4r2PvXfV/
[05:05] -queuebot:#ubuntu-release- Unapproved: accepted nullboot [source] (jammy-proposed) [0.5.0-0ubuntu0.22.04.1]
[05:10] <vorlon> ok, now 4907 packages
[05:14] <dbungert> https://paste.ubuntu.com/p/jFkWdk9k5X/ - build focus, urls, explanation of the filter
[05:14] <vorlon> here is the list of packages I'm proposing to skip tests for based on them being no-change rebuilds vs the release pocket. I have not cross-checked this against the list of seeded packages https://code.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/+merge/463559
[05:28] -queuebot:#ubuntu-release- Unapproved: cockpit-podman (jammy-backports/universe) [84-1~bpo22.04.1 => 86-1~bpo22.04.1] (no packageset)
[05:28] -queuebot:#ubuntu-release- Unapproved: cockpit-podman (mantic-backports/universe) [84-1~bpo23.10.1 => 86-1~bpo23.10.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit (jammy-backports/universe) [311-1~bpo22.04.1 => 314-1~bpo22.04.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit (mantic-backports/universe) [311-1~bpo23.10.1 => 314-1~bpo23.10.1] (no packageset)
[05:36] <vorlon> this looks like britney queuing tests in a loop again. :/ https://autopkgtest.ubuntu.com/packages/a/apache2/noble/arm64
[06:14] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (xenial-proposed) [0.96.20.13]
[06:37] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (jammy-proposed) [0.140ubuntu13.5]
[06:47] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (focal-proposed) [0.136ubuntu6.8]
[07:18] <wgrant> I'm manually chasing the ppc64el/riscv64/s390x KDE build chains this evening, as they're going to take a couple of weeks otherwise.
[07:32] <RikMills> wgrant: kubuntu has a semi smart retry script that I can set going on a loop
[07:32] <RikMills> https://people.ubuntu.com/~rikmills/pdf/2024-04-03-08:26:54-904142.pdf
[07:37] <wgrant> RikMills: Oh, handy :)
[07:38] <RikMills> our build stacks have so many tiers that we need that to get things built in a reasonable time
[07:39] <wgrant> Yeah, I've run into it when bootstrapping new archs. Glad there's some automation now!
[07:41] <RikMills> set it to check and retry candidate builds every hour for now
[07:45] <RikMills> may result in some email spam where things are ftbfs due to deps instead of reporting a depwait in LP
[07:46] <wgrant> Heh, I'm already getting about 1000 failure emails an hour anyway :)
[07:46] <RikMills> that figures!
[09:18] <jamespage> Hi release team - I am working through issues in the openstack package set and I need to sync cloudkitty from debian experimental - along with two new deps which are both in unstable already - to resolve incompatility with python-oslo.db >= 15.0.0 (as in noble)
[09:19] <jamespage> I've tested everything here - https://launchpad.net/~james-page/+archive/ubuntu/caracal/+packages
[09:20] <jamespage> OpenStack Caracal also releases today so I'll be working through final release uploads for the leaf packages in the OpenStack package set this week
[11:16] <RikMills> beta delated until 11th https://discourse.ubuntu.com/t/noble-numbat-beta-delayed-xz-liblzma-security-update/43827
[11:23] <sil2100> I need to coordinate with other release team members, but the Beta freeze will be delayed by a week possibly as well (...so till Monday?)
[11:23] <sil2100> But I need to double check with everyone
[11:24] <sil2100> For now the rebuilds are looking fine, we're trying to migrate them swiftly
[11:24] <sil2100> It's another huge huge huge effort, so it's hard to say anything for certain. But we aim to get the archive cleared our till Friday
[11:26] <sil2100> cjwatson: hey hey! Do you still have the powers to moderate ubuntu-devel-announce@?
[11:26] <sil2100> Since I think my mail is stuck there in moderation
[11:27] <cjwatson> sil2100: done
[11:31] -queuebot:#ubuntu-release- Unapproved: tracker-miners (jammy-proposed/main) [3.3.3-0ubuntu0.20.04.2 => 3.3.3-0ubuntu0.20.04.3] (ubuntu-desktop, ubuntugnome)
[11:58] <jbicha> gnome-tweaks migrated yesterday out of noble-proposed even though it depends on pygobject 3.48 which didn't migrate yet. I guess it's because tweaks is arch:all & some guardrails were turned off for arch:all for xz-utils mitigation
[12:00] <jbicha> I guess amd64 has widespread uninstallability so probably not much of a concern since we should be able to resolve things later this week
[12:27] <wgrant> vorlon: Turns out that t* onwards actually never got to build because of the frequent retries. I'm giving everything with a reasonable score that hasn't ever been dispatched a score bump.
[12:37] <wgrant> KDE is nearly there -- kwallet-kf5 is building now and kxmlgui will build after this publisher run, which gives us kio.
[14:03] -queuebot:#ubuntu-release- New source: lxml-html-clean (noble-proposed/primary) [0.1.0-0ubuntu1]
[14:30] -queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [source] (noble-proposed) [0.25.1-0ubuntu1]
[14:30] -queuebot:#ubuntu-release- New: accepted jami [sync] (noble-proposed) [20231201.0~ds2-1]
[14:34] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [source] (noble-proposed) [3.50.1-0ubuntu1]
[14:38] -queuebot:#ubuntu-release- New binary: gnome-online-accounts-gtk [amd64] (noble-proposed/none) [3.50.1-0ubuntu1] (no packageset)
[14:39] -queuebot:#ubuntu-release- New binary: gnome-online-accounts-gtk [armhf] (noble-proposed/none) [3.50.1-0ubuntu1] (no packageset)
[14:41] -queuebot:#ubuntu-release- New binary: gnome-online-accounts-gtk [arm64] (noble-proposed/none) [3.50.1-0ubuntu1] (no packageset)
[15:09] <kanashiro> RAOF I am not sure if you saw the ping from Steve about the runc-app package in NEW for Jammy, Focal and Mantic, would you have the time to take a look at it in your next shift? TIA!
[15:16] <athos> Hi ubuntu-archive, could anyone please remove php-oscarotero-gettext from the sync blocklist? This no longer FTBFS and blocks symfony migration. https://code.launchpad.net/~athos-ribeiro/+git/sync-blocklist/+merge/463602
[15:19] -queuebot:#ubuntu-release- New binary: gnome-online-accounts-gtk [ppc64el] (noble-proposed/universe) [3.50.1-0ubuntu1] (no packageset)
[15:56] <LocutusOfBorg> athos, https://launchpad.net/ubuntu/+source/php-oscarotero-gettext/4.8.7-2
[15:56] <LocutusOfBorg> I didn't unblocklist
[15:56] <LocutusOfBorg> just syncd
[15:59] <athos> Thanks, LocutusOfBorg
[16:08] <schopin> where can I find the list of packages that are allowed to build on i386?
[16:09] <schopin> a11y-profile-manager is blocked in noble-proposed because of a missing i386 build but according to LP, it was never attempted.
[16:11] <Eickmeyer> schopin: It's a packageset, I believe. i386-whitelist.
[16:12] <schopin> ALright, subsidiary question: how does one look at packagesets on LP? I don't believe I've ever needed to before.
[16:13] <Eickmeyer> Huh, that's an excellent question! (I forgot!) XD
[16:14] <cjwatson> edit-acl in lp:ubuntu-archive-tools can show them
[16:14] <cjwatson> edit-acl -S noble -P i386-whitelist query
[16:15] <schopin> thanks!
[16:15] <cjwatson> It's built from lp:~ubuntu-core-dev/ubuntu-seeds/+git/i386
[16:15] <cjwatson> (I believe)
[16:15] <schopin> Ah, perfect, exactly the info I wanted.
[16:18] <schopin> Since it's computed from seeds, I'm wondering if the whole binary removal  didn't screw it up somehow?
[16:18] <Eickmeyer> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386/tree/i386?h=noble
[16:19] <Eickmeyer> It's probably just not there yet?
[16:19] <Eickmeyer> But I don't see it in the seed.
[16:20] <Eickmeyer> Probably needed by something that's seeded there but isn't built yet.
[16:20]  * Eickmeyer is guessing
[16:21] <schopin> Maybe.
[16:23] <RikMills> schopin: you can also see the generated packagesets here; https://ubuntu-archive-team.ubuntu.com/packagesets/noble/
[16:25] <Eickmeyer> ^Thats what I couldn't remember!
[16:25] <Eickmeyer> sil2100: BTW, I locked your post on discorurse as is customary for announcements (noticed you couldn't?).
[16:26] <Eickmeyer> BTW, my spelling for discourse was horrible right then.
[16:30] <sil2100> Eickmeyer: thank you! Yes, I seemed to have no powers to do that!
[16:30] <sil2100> Or at least lacking in knowledge on how to do it, but all the places where I'd expect to see the features were missing it
[16:31] <Eickmeyer> sil2100: Right, I'm showing you have no moderator privileges there, which is required to lock posts.
[16:32] <Eickmeyer> I'll fix that to give you mod privs in the Announcements category.
[16:35] <Eickmeyer> sil2100: Strange, as a member of the release team, you should've been able to do it using the wrench icon in the lower left-hand corner of the post. Either way, it's done.
[16:49] <vorlon> cpaelzer: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/lubuntu/+build/600219
[16:50] <schopin> tsimonq2: are you on top of calamares-settings-ubuntu FTBFS ? I have zero experience in golang...
[16:51] <vorlon> fyi I'm going through https://paste.ubuntu.com/p/fTBTWsTBnD/ and looking at the packages blocked on i386 only, these are likely noble-updates issues that need hinting, so confirming and adding those hints
[16:54] <schopin> if anyone is looking at that list, I've already taken care of accountsservice and am looking at calamares-settings-ubuntu
[17:09] <ahasenack_> vorlon: I'm trying to troubleshoot https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2058576, but I can't get the noble build-deps installed in armhf, either release or proposed pocket
[17:09] -ubottu:#ubuntu-release- Launchpad bug 2058576 in sssd (Ubuntu) "FTBFS: armhf: build-time test failures" [High, In Progress]
[17:09] <ahasenack_> wait a bit more? Or is there a trick?
[17:13]  * ahasenack_ -> bbl, dentist
[17:27] <bdmurray> I jumped down the list and mpg123 ftbfs on armhf again after a retry
[17:27] <bdmurray> If somebody could take an in depth look at it that would help
[17:30] <liushuyu> bdmurray: seems to be due to time_t transition: debhelper is complaining that it can't find the expected 32-bit symbols
[17:43] <schopin> bdmurray: I'll take a look.
[17:53] <doko> looking at ppp
[17:59] <liushuyu> are we looking at this FTBFS list from top to bottom or picking items at random?
[17:59] <bdmurray> I picked something at random so don't follow my lead. ;-)
[18:00] <doko> haruna/riscv64 is waiting on KDE
[18:00] <liushuyu> opencv failed to build due to numpy removing numpy.distutils (Python 3.12 transition), a patch is needed
[18:03] <vorlon> I've stopped my rebuilds in a loop. Especially if the Kubuntu team have a smarter script, it's better at this point to just run that, and triggering other retries at this point just gets in the way
[18:04] <doko> synced vorbis-tools
[18:04] <doko> ginggs: ^^^ could you look at opencv?
[18:04] <ginggs> doko: sure
[18:06] <liushuyu> doko: if it is not a very big ask, can you update the gdb 15 snapshot to b1741ab0dafd899889faab6e862094a325a6b83c (committed 22 hours ago)? It contained at least two regression fixes
[18:08] <liushuyu> Also, can anyone from the SRU team take a look at https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856?
[18:08] -ubottu:#ubuntu-release- Launchpad bug 2059856 in gdb (Ubuntu) "gdb 10.0 fails to examine any global variables in D programs" [Undecided, New]
[18:12] <liushuyu> Okay... I am going to go through the list from top to bottom
[18:13] <liushuyu> ... accountsservice: time_t 64-bit issue on armhf, patch required
[18:13] <doko> synced sdl-mixer1.2
[18:13] <liushuyu> appstream-glib: i386 not built (not on the allowlist)
[18:13] <liushuyu> ark: still building
[18:14] <liushuyu> audiocd-kio: still building
[18:14] <doko> liushuyu: this one not good enough? https://launchpad.net/ubuntu/+source/gdb/15.0.50.20240403-0ubuntu1
[18:15] <liushuyu> doko: let me check, one second
[18:15] <schopin> liushuyu: accountsservice is already fixed.
[18:15] <schopin> see backlog :)
[18:16] <liushuyu> doko: This one is good enough, sorry did not check the snapshot version
[18:16] <liushuyu> bluedevil: still building
[18:21] <liushuyu> schopin: Okay, the backlog is a bit messy this time around due to non-alphabetic ordering
[18:21] <doko> synced qm-dsp
[18:22] <liushuyu> https://launchpad.net/ubuntu/+source/gst-plugins-good1.0/1.24.0-1ubuntu6/+build/27980479 needs a retry, no log output provided
[18:23] <ginggs> liushuyu: retried
[18:24] <liushuyu> ginggs: Thanks!
[18:26] <doko> merging policykit-1
[18:33] <vorlon> athos: php-oscarotero-gettext unblocked
[18:35] <vorlon> ahasenack_: surely the sssd build-deps should be installable from the union of (noble,noble-updates,noble-proposed) since it built on all other archs?
[18:36] <vorlon> all the packages that were blocked by missing i386 builds have been hinted now.  These are cases where copying to noble-updates brought back i386 binaries which had been deleted, which britney now sees; and they can't be deleted from -updates.
[18:38] <kanashiro> Is there anything specifically that I can help with? Or should I just go through the list and pick something?
[18:38] <vorlon> kanashiro: help figure out why livecd-rootfs is uninstallable in livefs builds https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/lubuntu/+build/600219
[18:38] <vorlon> RUN: /usr/share/launchpad-buildd/bin/builder-prep
[18:38] <vorlon> livecd-rootfs itself isn't seeded in images so isn't currently on the list of targets
[18:39] <vorlon> and in my noble chroot it is installable so I have too much stuff preinstalled to reproduce this
[18:39] <vorlon> maybe you can reproduce it using https://cloud-images.ubuntu.com/buildd/daily/noble/current/
[18:39] <kanashiro> vorlon ack, let me try to reproduce the build failure
[18:47] <doko> fixing openldap
[18:47] <schopin> fixed mpg123 (and started its t64 transition)
[18:48] -queuebot:#ubuntu-release- New binary: mpg123 [amd64] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:48] -queuebot:#ubuntu-release- New binary: mpg123 [ppc64el] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:48] -queuebot:#ubuntu-release- New binary: mpg123 [i386] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:50] <schopin> liushuyu: were you working in order? Which package are you at? :)
[18:50] <vorlon> schopin: I'm going to back this upload out for right now and instead break mpg123 on armhf
[18:50] <vorlon> schopin: then restore your build
[18:50] <RikMills> kde frameworks is getting there: https://people.ubuntu.com/~rikmills/pdf/2024-04-03-19:21:43-933666.pdf
[18:50] -queuebot:#ubuntu-release- New binary: mpg123 [armhf] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:50] <liushuyu> schopin: Yes, I am currently starting from color-kde
[18:50] -queuebot:#ubuntu-release- New binary: mpg123 [s390x] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:51] <schopin> vorlon: ACK, fair enough.
[18:51] <vorlon> schopin: but we don't have time to do these things in the "clean" order
[18:51] <liushuyu> I am trying to find a way to filter out all the pending builds
[18:51] <vorlon> schopin: sorry, I should've realized the reason you were asking about this is because it's seeded
[18:51] <schopin> indeed.
[18:52] <vorlon> schopin: so, in particular DON'T start doing any no-change rebuild uploads for the new abi :)
[18:52] <schopin> :-D
[18:53] <schopin> So does that mean that when the armhf build is broken we just hint it through somehow?
[18:53] <vorlon> yeah
[18:53] <vorlon> in britney this is a 'force' hint
[18:53] <vorlon> there's also a 'force-hint' hint, which means not just to ignore out-of-dateness but to ignore regressions in installability
[18:54] -queuebot:#ubuntu-release- New binary: mpg123 [arm64] (noble-proposed/main) [1.32.5-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [amd64] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [armhf] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [ppc64el] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [arm64] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [s390x] (noble-proposed) [1.32.5-1ubuntu1]
[18:57] -queuebot:#ubuntu-release- New: accepted mpg123 [i386] (noble-proposed) [1.32.5-1ubuntu1]
[18:58] <sergiodj> hello, I can spare some time now to help with whatever is needed.  is there anything I can do?
[19:02] <dbungert> sergiodj: I'm working on some update_excuses analysis focusing on seeded packages.  Here is a list of "missing" builds as of the last excuses run - https://paste.ubuntu.com/p/pM3FvW55Xm/
[19:02] <schopin> engrampa should be hinted, armhf-only FTBFS. I think it only needs a 'force' rather than 'force-hint'
[19:02] <vorlon> kanashiro: if you need it, apparently https://launchpadlibrarian.net/694289600/livecd.ubuntu-base.rootfs.tar.gz is the actual tarball currently in use by launchpad (livefs builds happen in a container rather than a chroot but the contents should be the same)
[19:02] <schopin> do we have a RT member to ping for quick hinting?
[19:03] <sergiodj> dbungert: thanks, I can take one from the list.
[19:03] <dbungert> sergiodj: cheers
[19:03] <schopin> all the Ds as well as elisa-player are waiting on builds
[19:03] <sergiodj> let me check what's not being worked on (based on the backlog)
[19:04] <schopin> sergiodj: I've just finished engrampa
[19:04] <sergiodj> schopin: ACK.
[19:04] <schopin> evolution-data-server is a case of ghost i386, skipping.
[19:04] <sergiodj> I can take fcitx-cloudpinyin
[19:04] <kanashiro> vorlon thanks for the pointer, I started by trying to install livecd-rootfs in a clean lxd container and it worked, I am starting to take a look at the git repo that builds the images. I'll play with this tarball
[19:05]  * schopin takes a food break.
[19:05] <sergiodj> schopin: oh, is fcitx-cloudpinyin also a case of ghost i386?
[19:05] <sergiodj> let me check
[19:06] <bryceh> vorbis-tools 1.4.2-1build5 FTBFS looks like it should be resolved by 1.4.2-2 which is already in -proposed, but pending publication on riscv64
[19:06] <sergiodj> it seems to be; there's no i386 build failure for fcitx-cloudpinyin on LP.  moving on to "folks" (I skipped fcitx-fbterm because I don't have easy access to an armhf)
[19:08] <schopin> sergiodj: see my conversation with Steve around 15mn ago wrt armhf FTBFS :)
[19:10] <sergiodj> schopin: reading
[19:10] <sil2100> dbungert, vorlon, schopin: are we going in a particular order? Are we coordinating work here?
[19:11]  * schopin goes back to cooking.
[19:11] <sil2100> Or should I just go through the list and act on the first thing I see?
[19:11] <schopin> sil2100: alphabetically.
[19:11] <sil2100> Are we doing the same 'taking' approach? ;)
[19:11] <schopin> but some folks skipped ahead.
[19:11] <doko> so, I synced all packages, which were marked ftbfs on armhf, and had a patch in Debian
[19:11] <doko> and merged a few
[19:12] <doko> scored l-z* packages up on riscv64 and s390x
[19:13] <sil2100> Is folks the last one?
[19:13] <sil2100> Taking geary
[19:14] <sergiodj> I'm starting to look into folks
[19:18] <sergiodj> vorlon: fcitx-fbterm is FTBFSing on armhf and apparently we're supposed to force-hint these cases, so here's a heads up
[19:18] <sergiodj> let me know if you'd like me to look further into the failure
[19:18] <doko> we can't hint ftbfs
[19:18] <schopin> might want to open a bug
[19:19] <bryceh> hi, I can spare some time too, would you like my help with anything?
[19:19] <sergiodj> schopin: according to your conversation with steve above: "So does that mean that when the armhf build is broken we just hint it through somehow?", and the answer was "yes"
[19:19] <doko> sergiodj: removing the fcitx-fbterm armhf binaries, no rdeps
[19:19] <sergiodj> I'm probably misunderstanding something then
[19:19] <sergiodj> doko: thanks
[19:20] <sergiodj> I guess that will do it
[19:20] <doko> wait, https://launchpad.net/ubuntu/+source/fcitx-fbterm/0.2.0-5 I just synced it
[19:21] <sil2100> Ok, geary is actually blocked on folks it seems, so hopefully sergiodj can resolve that and it should just build normally
[19:21] <sergiodj> doko: ah, even better then
[19:21] <sergiodj> and I see that armhf built there
[19:21] <sergiodj> nice
[19:21] <doko> sil2100, sergiodj: I had ignored test results, but then reverted that. maybe do it again?
[19:21] <doko> folks
[19:22] <schopin> sergiodj: I think I used slightly wrong terminology. Steve probably meant "if there are armhf test failure", as in "if the armhf package is broken"
[19:22] <sil2100> I'll take geocode-glib in the meantime
[19:23] <sergiodj> doko: how much effort should we put into fixing these tests? ignoring the failures seems like a last resort, but if that's the recommended action now then I'm OK doing it
[19:23] <sil2100> doko: you mean there was a skiptest?
[19:23] <sergiodj> schopin: ah, thanks for the clarification :)
[19:23] <schopin> sergiodj: we need to build images as soon as possible
[19:24] <schopin> If a test is failing, open a bug and hint it.
[19:24] <schopin> (unless it seems REALLY bad)
[19:24] <sergiodj> this is not a case of hinting, but rather a case of override_dh_auto_test
[19:24] <sergiodj> but yeah, I get what you mean
[19:25] <sergiodj> OK, let me see what I can do here
[19:25] <vpa1977> Good morning, what list are we working off?
[19:26] <sil2100> vpa1977: hello! Welcome to the fun!
[19:26] <sil2100> vpa1977: https://paste.ubuntu.com/p/pM3FvW55Xm/
[19:26] <schopin> sergiodj: I think we don't want to skip the broken tests in d/rules, but rather to just hint that specific version through. Again, unless it's really bad.
[19:27] <sil2100> vpa1977: basically we want to resolve the FTBFSes for the listed packages there, since ADT's we'll most likely hint
[19:27] <sil2100> But we need to deal with other stuff that blocks migration, starting with lack of binaries
[19:27] <sergiodj> schopin: but the package is FTBFSing. without ignoring the test results on d/rules, there's no way to hint the package, right?
[19:27] <vpa1977> looking at gimp-plugin-registry, then
[19:27] <athos> bryceh: from what I understood, we are going through https://paste.ubuntu.com/p/pM3FvW55Xm/ top-down
[19:27] <sergiodj> schopin: that's what I understood when doko said he had ignored test results from the package
[19:28] <jbicha> sergiodj: I did open a bug upstream for folks so I think ignoring the test results for now is ok-ish
[19:28] <athos> last one taken is gimp-plugin-registry, you take the next and let ppl know here :)
[19:28] <sergiodj> jbicha: ACK, thanks
[19:28] <jbicha> bug 2060073
[19:28] -ubottu:#ubuntu-release- Bug 2060073 in folks (Ubuntu) "folks build test failures with glib 2.80" [High, Triaged] https://launchpad.net/bugs/2060073
[19:28] <sil2100> Ah, from what I see all i386 based issues we can handle as resolved, right?
[19:28] <sil2100> Then I'll be moving on
[19:28] <vpa1977> athos: ack, taking gnome-contacts
[19:28] <sergiodj> OK, I'm running a test build here and should be ready to upload soon
[19:28] <athos> I am joining the fun as well I suppose :)
[19:29] <athos> vpa1977: I used that as the last one taken becaouses you took it :x hhehe
[19:29] <sil2100> gnome-desktop is i386 related, skipping
[19:29] <sil2100> Taking gnome-remote-desktop
[19:30] <vpa1977> athos: ok, a race condition - would you like contacts, or plugin-registry? =)
[19:30] <athos> vpa1977: pick one, I will have the other
[19:30] <vpa1977> gnome-contacts - build dep on folks, which is being worked on
[19:30] <vpa1977> athos,
[19:30] <vpa1977> athos: plugin registry for me then
[19:31] <sergiodj> OK, folks uploaded. test results ignored for now. thanks schopin jbicha doko for the discussion
[19:32] <athos> ack, taking gnome-contacts here
[19:33] <athos> someone re-triggered those (build is running). skipping gnome-contacts for now
[19:34] <schopin> It's fine to remove armhf binaries when the only rdep is lxqt, right?
[19:34] <sergiodj> gnome-shell seems to be resolved, too
[19:35] <sergiodj> gnome-desktop doesn't have an i386 FTBFS listed (I think that's what schopin meant with "ghost i386")
[19:35] <sil2100> jbicha: hey! Just to know some context: https://bugs.launchpad.net/ubuntu/+source/gnome-remote-desktop/+bug/2059076 <- is anyone on the desktop team working on the FTBFS on armhf?
[19:35] -ubottu:#ubuntu-release- Launchpad bug 2059076 in gnome-remote-desktop (Ubuntu) "proposed-migration for gnome-remote-desktop 46~rc-0ubuntu2" [Undecided, New]
[19:36] <sil2100> I guess I can unblock it anyway, I see the previous version got pushed to the release pocket without armhf as well
[19:37] <jbicha> sil2100: yeah, gnome-remote-desktop was removed on armhf for time_t so maybe that helps?
[19:37] <sergiodj> someone retriggered gst-plugins-good1.0/arm64.  we'll have to wait and see if the new build fails
[19:37] <jbicha> sergiodj: that was me, gst good has a flaky test that passes eventually :(
[19:37] <liushuyu> I quickly cobbled together a script to scrape the latest build status in that FTBFS list, here is the result: https://pastebin.ubuntu.com/p/33yQPKk95C/
[19:37] <bryceh> I'll look at gtk-sharp3
[19:37] <sergiodj> jbicha: ACK, thanks
[19:38] <sergiodj> looking at gtk2-engines-murrine
[19:38] <liushuyu> (here is the script: https://pastebin.ubuntu.com/p/x8RmJMSSVs/)
[19:38] <sil2100> jbicha: ah, indeed! Thanks
[19:38] <athos> looging at gtkmm2.4
[19:39] <athos> ghost i386
[19:39] <bryceh> are there tips for handling armhf specific issues?
[19:40] <athos> taking krita
[19:40] <liushuyu> bryceh: They need to be handled on a case-by-case basis, there is unfortunately no silver bullet or one-size-fits-all solution
[19:41] <liushuyu> taking gwenview
[19:41] <schopin> bryceh: for that one I'd add the relevant -Werror flag to DEB_CFLAGS_MAINT_APPEND on amd64 to fix it locally.
[19:41] <liushuyu> gwenview was being re-queued
[19:41] <liushuyu> taking indicator-bluetooth
[19:42] <liushuyu> this one is fully built
[19:42] <bryceh> gtk-sharp3 issue matches deb #1067940
[19:42] <schopin> ... which doesn't have a patch :)
[19:42] <bryceh> schopin, ok thx
[19:43] <liushuyu> plasma-framework: dependency problem on riscv64
[19:43] <sergiodj> schopin: I have a tentative patch for gtk2-engines-murrine, are you guys using PPAs to check before uploading, or just upload to the archive and deal with failures as they occur?
[19:44] <sergiodj> (asking because I don't want to impose more on the infrastructure, but OTOH I don't have an armhf machine to test things locally)
[19:44] <schopin> I upload directly.
[19:44] <sergiodj> OK
[19:44] <schopin> Your PPA is on the same infra, after all :)
[19:44] <athos> krita was waiting on libimath-3-1-29; retrying and moving on
[19:47] <sergiodj> exactly why I asked :D
[19:47] <sil2100> Ok, libgweather4, liboauth, liboobs and libphonenumber are all i386, skipping
[19:47] <sil2100> Taking libquicktime
[19:49] <lvoytek> I can also join in now :)
[19:50] <liushuyu> libreoffice: riscv64 waiting on KF5 stuff
[19:50] <sergiodj> gtk2-engines-murrine uploaded
[19:51] <doko> just skip the riscv64/s390x stuff for now, the kde stack is not yet ready, and people are running kde specific retries. see backlog
[19:52] <lvoytek> taking thin-provisioning-tools
[19:52] <liushuyu> taking libcdio
[19:53] <sergiodj> taking mpg123
[19:53] <liushuyu> libcdio seems to be a time_t issue
[19:54] <doko> liushuyu: then make it a transition
[19:54] <doko> sergiodj: no, in NEW
[19:54] <sergiodj> doko: OK, moving on
[19:54] <cpete> still going through?
[19:54] <cpete> if so I'll take nas
[19:55] <athos> taking opencolorio
[19:55] <sergiodj> taking opencv
[19:55] <cpete> oops paste didn't work but seems like it!
[19:55] <schopin> taking openimageio
[19:56] <doko> sergiodj: I was wrong about mpg123. and ginggs fixed opencv
[19:57] <schopin> sergiodj: I had to start the t64 for mpg123, maybe by now the new binaries are published and we can start uploading rebuilds of rdeps?
[19:58] <sil2100> Okay, syncing libquicktime to fix the armhf issue, basically a patch for the missing include
[19:58] <doko> vorlon removed the new mpg123 upload instead, to let the existing package migrate
[19:59] <sergiodj> schopin: sure
[19:59] <sergiodj> schopin: sorry, where are the new binaries?
[19:59] <sergiodj> I only see 1.32.5-1build2 on LP
[19:59] <doko> removed
[20:00] <sergiodj> ah, OK
[20:00] <schopin> oh well :)
[20:00] <sergiodj> OK, moving on, then
[20:00] <sergiodj> opencv is fixed according to doko.  taking openldap
[20:01] <vorlon> and I've now added the hint to ignore the missing armhf binaries
[20:01] <schopin> athos: I think yours is waiting on mine.
[20:01] <jbicha> bryceh: I can take gtk-sharp3
[20:01] <athos> yup, just realized that
[20:01] <athos> I will move on then, schopin
[20:02] <bryceh> @jbicha, ok thanks
[20:02] <athos> taking overlay-scrollbar
[20:03] <sergiodj> I'm retriggering openldap's armhf build because it's failing due to the testsuite, which is a bit flaky on armhf
[20:03] <bryceh> taking policykit-1
[20:03] <schopin> vorlon: could you hint opencolorio and openimagio? I think they need bootstrapping on armhf.
[20:03] <vorlon> eew? how can they still need bootstrapping
[20:03] <vorlon> I'll take a look at them but am currently in standup, and then I need to redo my script for requeuing tests to make it not terrible
[20:04] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [amd64] (noble-proposed) [3.50.1-0ubuntu1]
[20:04] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [armhf] (noble-proposed) [3.50.1-0ubuntu1]
[20:04] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [arm64] (noble-proposed) [3.50.1-0ubuntu1]
[20:04] -queuebot:#ubuntu-release- New: accepted gnome-online-accounts-gtk [ppc64el] (noble-proposed) [3.50.1-0ubuntu1]
[20:04] <sergiodj> taking ppp
[20:06] <sergiodj> I'll sync ppp from experimental.  it seems to fix the problem we're seeing in Ubuntu
[20:06] <sergiodj> s/sync/merge/
[20:09] <sil2100> python-wrapt is i386, skip
[20:09] <sil2100> Taking qm-dsp
[20:09] <doko> sergiodj: already fixed.
[20:09] <doko> sil2100: already fixed
[20:09] <sil2100> doko: thanks!
[20:09] <sergiodj> doko: ppp?
[20:09] <sil2100> Taking sdl-mixer1.2
[20:09] <doko> sil2100: already fixed
[20:10] <doko> sergiodj: yes
[20:10] <vorlon> sergiodj: woah. why do we need to get a sync from experimental to fix a problem with a no-change rebuild?
[20:10] <sergiodj> ah, I see, thanks
[20:10] <sil2100> doko: can you mark those already fixed somehow?
[20:10] <sil2100> Maybe create another list?
[20:10] <doko> how?
[20:10] <doko> sil2100: are you subscribed to noble-changes?
[20:10] <bryceh> ok policykit-1 needs a patch already in debian.  Could either be cherrypicked, or the new version merged.
[20:11] <doko> bryceh: already fixed
[20:11] <sil2100> ok, nvm then
[20:11] <bryceh> doko, oh?
[20:11] <sil2100> Taking thunderbird
[20:12] <doko> bryceh: https://launchpad.net/ubuntu/+source/policykit-1/124-2ubuntu1
[20:12] <sergiodj> taking vorbis-tools
[20:12] <doko> sergiodj: already fixed
[20:12] <sergiodj> hah
[20:12] <sergiodj> OK
[20:12] <sil2100> sergiodj: check noble-changes to see if package is fixed
[20:12] <bryceh> doko, alright
[20:12]  * bryceh --> lunch
[20:12] <sergiodj> alright, only sssd remains.  I'll have to get an armhf to debug that one
[20:14] <dbungert> here is a different sort of log, it shows packages that block other packages, presumably on ADT regressions.  It's a bit different than the previously posted autopkgtest log I did.
[20:14] <dbungert> https://paste.ubuntu.com/p/6TSDHt4g6N/
[20:14] <sil2100> I'll force thunderbird, the set of binaries built in -proposed = the ones in release (+ amd64 of course)
[20:14] <sergiodj> I know ahasenack_ is looking into sssd, so I'll defer to him
[20:18] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [sync] (noble-proposed) [1.3.1-1]
[20:18] <ahasenack_> back
[20:21] <schopin> Alright, new list then :)
[20:21] <schopin> Looking into peony
[20:21] -queuebot:#ubuntu-release- New binary: rust-proc-macro-crate-1 [amd64] (noble-proposed/none) [1.3.1-1] (no packageset)
[20:22] <dbungert> I think there was one straggler from the last list, xsynth-dssi, unless someone has that
[20:23] <schopin> I think it's another case of removed i386 binary.
[20:24] <dbungert> nice.  I'll post an updated missingbuild log when this updates https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.yaml.xz
[20:24] <sergiodj> .xz!!
[20:24] <vorlon> yeah xsynth-dssi is done
[20:24] <sergiodj> ;)
[20:24] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [amd64] (noble-proposed) [1.3.1-1]
[20:24] <schopin> peoni is waiting for riscv64 and s390x builds.
[20:25] <schopin> taking libplist
[20:27] <dbungert> schopin: I should be able to drop waiting/blocked items from the autopkgtest list, would that help?
[20:28] <schopin> I think waitdep could be of value, but those only waiting for builders should probably be dropped.
[20:29] -queuebot:#ubuntu-release- New binary: rust-proc-macro-crate-1 [arm64] (noble-proposed/none) [1.3.1-1] (no packageset)
[20:29] -queuebot:#ubuntu-release- New binary: rust-proc-macro-crate-1 [armhf] (noble-proposed/none) [1.3.1-1] (no packageset)
[20:30] -queuebot:#ubuntu-release- New binary: rust-proc-macro-crate-1 [ppc64el] (noble-proposed/none) [1.3.1-1] (no packageset)
[20:33] <mwhudson> vorlon, kanashiro: livecd-rootfs seems to be installable now https://launchpadlibrarian.net/723008228/buildlog_ubuntu_noble_amd64_test_BUILDING.txt.gz
[20:34] <vorlon> mwhudson: oh, hurray
[20:37] <schopin> do we just skiptest packages when the rdep tests fail because of badpkg?
[20:38] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [arm64] (noble-proposed) [1.3.1-1]
[20:38] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [ppc64el] (noble-proposed) [1.3.1-1]
[20:38] -queuebot:#ubuntu-release- New: accepted rust-proc-macro-crate-1 [armhf] (noble-proposed) [1.3.1-1]
[20:38] <schopin> Also, do we want to re-enable all-proposed?
[20:40] <kanashiro> mwhudson vorlon yay. It is not installable in the chroot I am running with the tarvall Steve gave me, but if it is working on LP that's good enough I guess
[20:41] <mwhudson> kanashiro: i had to remember to set up the preferences to allow it to install packages from -proposed but after that it appears to be installable locally
[20:42] <kanashiro> Yeah, I installed it fine in a lxd container and I think it was configured that way
[20:42] <vorlon> schopin: I wouldn't say that we should categorically skiptest rdep failures.  I'd like to see what things look like after we properly requeue running tests without duplicates; any retries of failed tests are going to end up queued behind those anyway...
[20:42] <vorlon> schopin: (and the only tests I'm requeuing are precisely those that block seeded packages)
[20:47] <schopin> libsmf can be skiptest, the denemo tests passed with the new version installed (the runner gave up with pinning and enabled all proposed)
[20:48] <doko> vorlon: libphonenumber had dependencies on the removed libabsl20230802, blocking libreoffice. please could you check on other deps on libabsl20230802? I'm afk now
[20:52] <ahasenack_> is "do-release-upgrade -d" from mantic to noble blocked, perhaps by accident due to the current state of affairs?
[20:53] <bdmurray> Not by accident
[20:53] <ahasenack_> ok, so since canonistack has no noble images, just mantic... no arm64 in canonistack for me
[20:53] <mwhudson> well you can always edit sources.list
[20:53] <ahasenack_> noble arm64, that is
[20:54] <bdmurray> After juliank's emails and the flux in the archive due to xz-utils we disabled dist-upgrades
[20:54] <mwhudson> with a freshly booted mantic that should work
[20:54] <bdmurray> also yes, remember the old ways
[20:54] <ahasenack_> mwhudson: ok, will try that
[20:57] <vpa1977> I have launched canonistack mantic and then ubuntu-daily:noble lxc container
[20:58] <ahasenack_> ah, indeed, I think I don't need the noble kernel for these tests
[21:02] <doko> vorlon, mwhudson, vpa1977: please after kbookmarks is available on riscv64, retry kdeclarative, then when this is available, retry haruna and libreoffice
[21:02] <doko> now really afk
[21:03] <mwhudson> doko: ak
[21:07] <athos> jbicha: overlay-scrollbar ftbfs due to an implicit declaration introduced in a patch we carry in gtk+2.0 adding some ubuntu_* functions. Have you handled these ones in some specific fashion (supposing we saw the same issue somewhere else)?
[21:08] <jbicha> athos: I wasn't aware of that issue yet. I can add it to my plate though
[21:10] <dbungert> updated missingbuild log, https://paste.ubuntu.com/p/nDWDp3jJqv/   7 insertions(+), 85 deletions(-)
[21:11] <dbungert> no new packages, just build state changes on a few, and many disappeared so nice work
[21:14] <vorlon> schopin: so the problem with "opencolorio and openimagio need bootstrapping" is that I already bootstrapped them :| where did that go
[21:15] <athos> ack; thanks, let me know if you want me to file a bug or just declare those in that gtk+2.0 patch :)
[21:16] <athos> ack qm-dsp
[21:16] <athos> oh, it was taken :)
[21:19] <liushuyu> libcdio fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/libcdio/+git/libcdio/+merge/463629
[21:22] <liushuyu> For the new list: dep wait packages: cinnamon krita geary opencolorio
[21:25] <vpa1977> retried kdeclarative https://launchpad.net/ubuntu/+source/kdeclarative/5.115.0-0ubuntu5/+build/27974520
[21:27] <liushuyu> taking overlay-scrollbar
[21:29] <jbicha> liushuyu: I'm handling overlay-scrollbar
[21:29] <liushuyu> more recent build state table https://pastebin.ubuntu.com/p/Nhn8zwh7rH/
[21:29] <liushuyu> jbicha: ah sorry, I will find another one
[21:30] <jbicha> athos: I believe we want gtk+2.0 to migrate first before doing another upload. I suggest we also remove overlay-scrollbar/armhf for now since it has no rdepends, only 1 reverse recommends
[21:33] <vpa1977> jbicha: same for gimp-plugin-registry? I have a fix now, but it will impact the migration.
[21:33] <sergiodj> btw, openldap/armhf is built
[21:34] <liushuyu> gnome-system-tools seems another GTK+ API change
[21:34] <liushuyu> should I hand this over to the desktop people?
[21:36] <liushuyu> It seems like we have cleared the current list
[21:36] <jbicha> vpa1977: gimp-plugin-registry also only have reverse recommends (& it has an autopkgtest) so yes I suggest it be removed on armhf for today
[21:37] <jbicha> gst good has passed its build tests now
[21:39] <jbicha> vpa1977: you can take gnome-system-tools if you want. I have enough for today and it's not a desktop owned package
[21:39] <vpa1977> jbicha: ack
[21:54] <cpete> unexpected afk. Back now. nas looks good.
[21:55] <cpete> liushuyu: >cleared the list. are we on to missing builds then?
[21:55] <vorlon> schopin: opencolorio reuploaded to https://launchpad.net/~canonical-foundations/+archive/ubuntu/archive-bootstrap/+packages
[21:58] <vorlon> doko: I don't see any other revdeps of libabsl20230802
[21:58] <ahasenack_> vpa1977: that lxd trick didn't work in canonistack :/
[21:58] <ahasenack_> $ lxc launch ubuntu-daily:noble/armhf n-armhf
[21:58] <ahasenack_> Creating n-armhf
[21:58] <ahasenack_> Error: Failed instance creation: Failed creating instance record: Requested architecture isn't supported by this host
[21:59] <liushuyu> cpete: the list was about missing builds, all of the items are now either held by someone in this channel for further investigation or already done
[21:59] <ahasenack_> oh, wait a sec
[21:59] <cpete> liushuyu: ack thanks
[22:05] <lvoytek> solved the issue with thin-provisioning-tools, I'll upload the fix
[22:08] <vorlon> ahasenack_: ... on arm64?
[22:09] <ahasenack_> no, that was the mistake. Bitten by shell history, I thought I was just trying again to launch the arm64 instance that had failed before, but I actually launched ppc64el
[22:09] <vorlon> :)
[22:09] <mwhudson> heh
[22:20] <jbicha> gtk+2.0 is staged for upload after proposed gtk+2.0 migrates to fix overlay-scrollbar/armhf build
[22:21] <liushuyu> jbicha: It's very strange that the -Werror is only triggered on armhf (the same warnings are also present on other architectures)
[22:21] <vorlon> hmm why was rasqal on the latest list, I thought I hinted it for i386
[22:22] <vorlon> oh, no, I tried to use a 'forec' hint
[22:23] <vorlon> I don't see anyone mentioning they were looking at caja-extensions?
[22:23] <jbicha> liushuyu: that's intentional to try to limit how much work we have to do right now. it will be an error on all architectures for 24.10 and already is for Debian Unstable
[22:24] <liushuyu> jbicha: I see
[22:24] <vorlon> caja-extensions fixed in Debian, looking at a sync
[22:25] <vorlon> doko already did without mentioning, ok
[22:27] <liushuyu> vorlon: so all that we can do is to wait at the moment?
[22:28] <vorlon> kicking off image builds for all flavors so we can possibly get some interesting build logs
[22:28] <vorlon> liushuyu: I don't know
[22:28] <vorlon> I don't have a big picture view at the moment to say what can or can't be dune
[22:28] <vorlon> done
[22:29] <vorlon> the last list from dbungert is 2 hours old :)
[22:29] <vorlon> wait no 1 hour old
[22:29] <dbungert> right, I updated shortly after the new update_excuses was available
[22:29] <dbungert> the missingbuild log looks pretty good, people here took action on the entire list
[22:31] <vorlon> dbungert: does that mean everything else that's blocked is blocked by tests, not by missing builds?
[22:32] <dbungert> vorlon: for the missingbuilds log, I only reported if there were missing builds on things other than risc-v or s390x.
[22:32] <dbungert> I can remove that filter but the result is probably many cases of waiting for those two arches.
[22:32] <vorlon> dbungert: well I'd like to see that list, s390x is not slow and I can bump build priorities
[22:33] <vorlon> mwhudson: so there may have been one livefs build that got past livecd-rootfs uninstallability but not this one? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/ubuntukylin/+build/600290
[22:33] <vorlon> mwhudson: were you building with -proposed
[22:33] <mwhudson> oh maybe i wasn't
[22:33] <vorlon> mwhudson: well I'm wondering if -proposed is what made your build *work*
[22:33] <jbicha> vorlon: please remove gtk-sharp3 & gbrainy on armhf; they were removed last week for time_t . I have gtk-sharp3 on my todo list for tomorrow
[22:34] <mwhudson> vorlon: oh
[22:34] <mwhudson> vorlon: no proposed here https://launchpad.net/~mwhudson/+livefs/ubuntu/noble/test/+build/600274
[22:34] <liushuyu> according to LP stats, arm64 has a backlog of 935 jobs; armhf 450 jobs; ppc64el 24 jobs; riscv64 1421 jobs; s390x 1600 jobs
[22:34] <mwhudson> there was a ppa enabled though
[22:34] <jbicha> vorlon: please remove overlay-scrollbar/armhf & gimp-plugin-registry/armhf as discussed here
[22:34] <vorlon> jbicha: removed last week from where?
[22:34] <mwhudson> don't think it took any packages from there though
[22:34] <jbicha> vorlon: removed from noble/universe (release)
[22:35] <dbungert> vorlon: https://paste.ubuntu.com/p/zgkBwkCbNk/ - missingbuild log with the risc-v / s390x arch filtering removed
[22:35] <jbicha> vorlon: oops I misread. But could you remove them?
[22:37] <vorlon> jbicha: well gbrainy/armhf is already removed from noble, it grew back in noble-updates and is built in noble-proposed; but yes I'll remove gtk-sharp3 since it has no other revdeps
[22:39] <vorlon> jbicha: didn't I remove gimp-plugin-registry once before?
[22:39] <vorlon> jbicha: I did - that's another case of it growing back in noble-updates. so needs a hint rather than a removal; doing
[22:39] <mwhudson> vorlon: well i don't know what's going on. https://launchpad.net/~mwhudson/+livefs/ubuntu/noble/test/+build/600274 says "pocket release" the build log is clearly looking at updates and proposed
[22:41] <mwhudson> vorlon: if i restrict my local chroot to release only i get a failure like the one in that build log
[22:41] <vorlon> mwhudson: possibly related to the configuration of the ppa you're building in?
[22:41] <vorlon> if your devirt ppa says 'depends on proposed' that probably does it
[22:41] <mwhudson> it does
[22:41] <mwhudson> but i am still a bit surprised that would make the difference
[22:42] <vorlon> well I expect livecd-rootfs to be installable with -proposed enabled
[22:42] <vorlon> given that we've already rebuilt ~everything
[22:43] <mwhudson> so the question i guess is which packages does livecd-rootfs depend on that are not on images
[22:43] <mwhudson> like one of the issues is wget, but that's seeded
[22:44] <mwhudson> gnupg2 might be one of the interesting ones?
[22:44] <mwhudson> ah no gnupg is seeded
[22:44] <vorlon> maybe there's random perl modules
[22:44] <vorlon> debhelper showed up in the list?
[22:46] <mwhudson> it does?
[22:46] <mwhudson> i can't see any dependencies not covered by other work in a few minutes of poking
[22:47] <vorlon> oh sorry, debootstrap not debhelper
[22:47] <mwhudson> deboostrap is because wget
[22:47] <mwhudson> +t as usual
[22:48] <kanashiro> maybe devscripts' dependencies?
[22:48] <kanashiro> there are some perl modules
[22:49] <mwhudson> kanashiro: it's only complaining about gnupg{,2} and python3:any
[22:49] <kanashiro> FWIW this was the installability error I was getting when trying to install livecd-rootfs: https://paste.ubuntu.com/p/MnWv73bJxN/
[22:53] <vorlon> hmmm why did initramfs-tools not end up in my skiptest hint list
[22:54] <vorlon> because a bug means it doesn't handle multi-digit extensions sigh
[22:55] <kanashiro> mwhudson is there a way to check the logs of the error you are seeing? I am not proficient regarding image building but I can try to help/spot something
[22:55] <vpa1977> fixed gnome-system-tools - will upload after testing ppa build
[22:56] <vorlon> ok more skiptest hints incoming (wget is already skiptested)
[22:57] <vorlon> +force-skiptest activity-log-manager/0.9.7-0ubuntu31
[22:59] <kanashiro> are you guys still using this list? https://paste.ubuntu.com/p/fTBTWsTBnD/
[22:59] <kanashiro> is there an order to pick packages?
[22:59]  * vpa1977 afk lunch
[22:59] <cpete> vorlon, dbungert: So is there anything I can do right now to help with xz related rebuild things?
[23:00] <cpete> I think the list has been cleared
[23:01] <dbungert> cpete: So here is a missingbuild log that added builds only missing on risc-v / s390x.  It's bound to be very noisy but there may be some real things in there.  https://paste.ubuntu.com/p/zgkBwkCbNk/
[23:02] <kanashiro> cpete thanks for the info (and good news :)
[23:05] <dbungert> cpete: I also have this log of test regressions that could be analyzed.  I'm still iterating on that log to see if I can filter for more interesting things   https://paste.ubuntu.com/p/fyKKh92r7s/
[23:11] <cpete> dbungert: Thanks for the lists. I'll start combing through.
[23:19] <kanashiro> I am going through the first list and so far I think just folks can be fixed (failing everywhere)
[23:19] <kanashiro> but I recall someone looking at it earlier today, not sure about the outcome
[23:20] <cpete> Looking at the same list. I think calamares-settings-ubuntu needs a rebuild on riscv64
[23:20] <kanashiro> most of the packages are waiting for build on s390x and riscv64
[23:21] <dbungert> kanashiro: yes, that's expected in this more recent list.  The one I posted earlier had those filtered out, where it seemed to be just waiting for s390x/riscv64.
[23:22] <wgrant> Ugh sorry, power failure overnight killed my libkf* rescoring loop, but should be making progress again now.
[23:29] <kanashiro> cpete not sure if someone triggered the rebuild of calamares-settings-ubuntu on riscv64 but it is already in the queue
[23:30] <kanashiro> I triggered some rebuilds on riscv64 which seem to be solved already
[23:30] <cpete> kanashiro: must've, I see it queued now! thanks for the bump
[23:31] <kanashiro> cpete if you need something feel free to ping me, I'll be working a bit more tonight
[23:32] <cpete> kanashiro: Thanks! Will do. I have couple hours left in my day still
[23:42] <mwhudson> kanashiro: i have just beem mutating the sources.list in the noble chroot and running "chroot . apt-get install --dry-run $foo"
[23:42] <kanashiro> I went through the list and apparently what requires more attention is folks and opencv which are failing in all arches
[23:42] <mwhudson> kanashiro: i thought someone uploaded an "ignore the test results" version of folks?
[23:43] <mwhudson> yeah https://launchpad.net/ubuntu/+source/folks/0.15.9-1ubuntu5
[23:43] <sergiodj> mwhudson: I did
[23:43] <sergiodj> opencv is also fixed, btw
[23:43] <mwhudson> opencv is bulding
[23:43] <kanashiro> ah ok :) the report did not catch that yet
[23:44] <kanashiro> so I think we just need time to make it all build
[23:44] <sergiodj> the list is pretty much done.  they're now working on another list which refers to autopkgtest problems
[23:44] <kanashiro> mwhudson I'll try to reproduce that in a chroot
[23:45] <kanashiro> sergiodj do you mean this list? https://paste.ubuntu.com/p/fyKKh92r7s/
[23:45] <sergiodj> kanashiro: yes, I think that's the last version of it
[23:46] <cpete> that looks right. I've been going through the first list but I think Kanashiro's analysis is correct. just waiting on builds for those packages
[23:46] <kanashiro> it was good to make another pass in the first list because I found some build failures on riscv64 which required a rebuild
[23:47] <kanashiro> well, I am going to have dinner now and then get back to this
[23:47] <sergiodj> me too
[23:52] <vorlon> dbungert: https://paste.ubuntu.com/p/zgkBwkCbNk/ generated right before update_excuses published again
[23:52] <dbungert> sure, I'll redo both versions
[23:55] <dbungert> missingbuild with riscv64 / s390x hide_arches https://paste.ubuntu.com/p/dZTF4sN2V9/
[23:55] <dbungert> without https://paste.ubuntu.com/p/Kggk7HvBdJ/
[23:55] <vorlon> btw initramfs-tools and gnupg2 both got picked up in the new list for skiptesting so maybe livecd-rootfs will be clear after this
[23:56] <dbungert> awesome
[23:56] <vorlon> dbungert: hmm that still looks out of date, alsa-plugins was in particular the one I noticed was no longer missing a build
[23:56] <dbungert> err, I had old data
[23:56] <dbungert> yea
[23:58] <dbungert> correction: hide arches https://paste.ubuntu.com/p/tmfydV9SSs/
[23:58] <dbungert> no hide arches https://paste.ubuntu.com/p/H8dDpTvFRN/