[00:25] <Eickmeyer> vorlon, or anybody on ubuntu-release: Can I get a rebuild of Edubuntu triggered? Latest attempt failed: `error: Post "https://api.snapcraft.io/v2/snaps/refresh": dial tcp: lookup api.snapcraft.io on 10.189.128.2:53: server misbehaving`. Server needs to behave, I guess.
[00:25] <tsimonq2> Eickmeyer: You can't trigger your own rebuilds? :)_
[00:25] <tsimonq2> *:)
[00:25] <Eickmeyer> tsimonq2: Known bug that if you trigger a rebuild and it fails, you can't trigger one again until a successful build completes. Everyone knows that. :P
[00:26] <Eickmeyer> Really, it's a limitation of the iso tracker interface.
[00:27] <Eickmeyer> And a bug therein.
[00:28] <tsimonq2> Eickmeyer: Touché. ;)
[01:14] <Eickmeyer> ubuntu-release: Disregard rebuild request. Getting too close to cronjob time.
[02:33] <vorlon> Eickmeyer: running
[02:34] <Eickmeyer> vorlon: Oh, thanks! The cronjob runs about 30 minutes from now so I was just going to wait for that.
[02:34] <vorlon> ah well
[02:35] <Eickmeyer> Also, looks like somebody (or something else) triggered it about 1/2 hour ago. ¯\_(ツ)_/¯
[02:39] <vorlon> without mentioning? hmph
[02:39] <Eickmeyer> Yeah. smh
[05:09] <Eickmeyer> vorlon: Are you aware of a removal bug for mypaint?
[05:10] <vorlon> Eickmeyer: no.  complete list of removal bugs is https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-archive&field.status=NEW&field.status=Confirmed&field.status=Triaged&field.status=INPROGRESS&field.status=FIXCOMMITTED&field.status=INCOMPLETE_WITH_RESPONSE
[05:10] <Eickmeyer> vorlon: Right. Reason I was asking is because it's suddenly missing from noble.
[05:10] <vorlon> https://launchpad.net/ubuntu/+source/mypaint/+publishinghistory
[05:11] <vorlon> deleted by doko, referencing a Debian bug
[05:12] <Eickmeyer> Right. So, I thought it was standard practice to talk to flavor leads before doing that?
[05:12] <vorlon> he asserted in the removal that it had no revdeps
[05:13] <Eickmeyer> That would be false. ubuntustudio-graphics had it.
[05:13] <vorlon> yes, so he apparently overlooked this
[05:15] -queuebot:#ubuntu-release- New binary: cgsi-gsoap [amd64] (noble-proposed/universe) [1.3.11-4] (no packageset)
[05:17] <vorlon> so while the justification for the removal is wrong, it would still block the python3.12 transition due to failing to build, and having for whatever reason a versioned dependency on python3 (<< 3.12), python3 (>= 3.11~).  While the ordering is wrong, you'll still need to get a fix for the build failure to have it in the noble release
[05:22] <Eickmeyer> vorlon: That's understood, but nobody was even given a chance to fix it. I know quite a few artists that are going to be a little more than put-off by this removal.
[05:23] <vorlon> you have a chance to fix it now; and please don't use me as a proxy for arguing with doko for his oversight
[05:25] <Eickmeyer> I do not have a fix for it now, but I wasn't even able to go to upstream with the issue as I wasn't made aware until I just now did a meta update and, much to my surprise (and alarm), it was removed.
[05:26] <Eickmeyer> It does appear as though there is an upstream issue opened, but I'm not sure how fast they'll fix it.
[05:31] <Eickmeyer> https://github.com/mypaint/mypaint/issues/1228 FWIW
[05:31] -ubottu:#ubuntu-release- Issue 1228 in mypaint/mypaint "Building: Migrate away from distutils" [Open]
[05:31] <Eickmeyer> Looks like 1-2 weeks out, at the most.
[05:35] -queuebot:#ubuntu-release- New binary: starpu [amd64] (noble-proposed/universe) [1.4.3+dfsg-2] (no packageset)
[05:38] -queuebot:#ubuntu-release- New binary: starpu-contrib [amd64] (noble-proposed/multiverse) [1.4.3+dfsg-2] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: starpu [armhf] (noble-proposed/universe) [1.4.3+dfsg-2] (no packageset)
[05:40] -queuebot:#ubuntu-release- New binary: starpu [ppc64el] (noble-proposed/universe) [1.4.3+dfsg-2] (no packageset)
[05:41] <Eickmeyer> vorlon: And my apologies, I was mostly venting, not meaning to proxy-argue via you.
[05:46] -queuebot:#ubuntu-release- New binary: starpu-contrib [ppc64el] (noble-proposed/multiverse) [1.4.3+dfsg-2] (no packageset)
[05:48] -queuebot:#ubuntu-release- New: accepted cgsi-gsoap [amd64] (noble-proposed) [1.3.11-3]
[05:48] -queuebot:#ubuntu-release- New: accepted python-aiohttp-retry [amd64] (noble-proposed) [2.8.3-1]
[05:48] -queuebot:#ubuntu-release- New: accepted starpu-contrib [ppc64el] (noble-proposed) [1.4.3+dfsg-2]
[05:48] -queuebot:#ubuntu-release- New: accepted starpu [armhf] (noble-proposed) [1.4.3+dfsg-2]
[05:48] -queuebot:#ubuntu-release- New: accepted cgsi-gsoap [amd64] (noble-proposed) [1.3.11-4]
[05:48] -queuebot:#ubuntu-release- New: accepted starpu [amd64] (noble-proposed) [1.4.3+dfsg-2]
[05:48] -queuebot:#ubuntu-release- New: accepted starpu-contrib [amd64] (noble-proposed) [1.4.3+dfsg-2]
[05:48] -queuebot:#ubuntu-release- New: accepted starpu [ppc64el] (noble-proposed) [1.4.3+dfsg-2]
[06:00] -queuebot:#ubuntu-release- New binary: starpu [arm64] (noble-proposed/universe) [1.4.3+dfsg-2] (no packageset)
[06:39] -queuebot:#ubuntu-release- New: accepted starpu [arm64] (noble-proposed) [1.4.3+dfsg-2]
[07:45] <vorlon> ginggs: on next refresh, https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#perl should be clean except for exim4, I think.  are there any other bits of the perl transition in particular that I should look at?
[07:48] <ginggs> vorlon: below the autopkgtest results, there are still a handful of Implicit dependency: perl xxxx (not considered)
[07:48] <vorlon> yah - wondering if there are any in particular you would like me to focus on :)
[07:48] <ginggs> which have their own autopkgtest regressions
[07:49] <LocutusOfBorg> vorlon, we were also hoping to do a ghc transition before freeze, but time_t is probably more important
[07:49] <LocutusOfBorg> maybe I'll just try in a bileto...
[07:49] <vorlon> LocutusOfBorg: I think we'll be able to do both.  ghc and time_t transitions should be disjoint
[07:49] <vorlon> the only overlap would be autopkgtest resources, and , well
[07:50] <vorlon> hmm to be fair there are some haskell bindings that need to be rebuilt for time_t
[07:50] <vorlon> but only, you know, 56 of them
[07:51] <vorlon> (and this probably causes their provides to also change and therefore require rebuilds... omg)
[07:51] <ginggs> vorlon: there are none in particular i know of
[07:55] <doko> vorlon: you need to remove libsys-virt-perl 10, and restore the older version
[07:56] <doko> a new libvirt upload/merge was promised, but never realized
[07:56] <vorlon> doko: ok; that's not something I'm going to get to tonight
[07:56] <doko> ok
[07:57] <doko> do you want to force python3-defaults as well before starting time_t?
[07:57] <vorlon> I want it done before time_t; I don't want to have to apply too much force :)
[07:58] <doko> just filed yesterday 100+ more issues for Debian. but there we still don't have the -defaults change done yet. time_t seems to be in the way ;p
[07:59] <vorlon> oh well then
[08:08] <vorlon> bluesabre: hi, have you seen that xubuntu dailies are oversized in noble?
[08:22] <LocutusOfBorg> so vorlon maybe we do them together?
[08:23] <vorlon> that's not my preference
[08:23] <vorlon> but we'll see
[08:23] <LocutusOfBorg> vorlon, ack!
[08:24] <vorlon> LocutusOfBorg: oh sorry you were talking about ghc still, and not the conversation with doko about python?
[08:24] <LocutusOfBorg> ghc
[08:24] <vorlon> I think it's ok to try to do the ghc transition in parallel in noble
[08:24] <LocutusOfBorg> but debian is waiting for it :/
[08:24] <vorlon> hmm well
[08:24] <LocutusOfBorg> on #debian-haskell they are asking to hold
[08:24] <LocutusOfBorg> I can sync from experimental maybe
[08:24] <LocutusOfBorg> this way we can at least start it
[08:24]  * LocutusOfBorg is afk
[09:24] <cpaelzer_> doko: hi, there is a regression by upstream in the new libvirt which held it back, sergiodj is even considering to upload it with the known issue to fix it later to unblock you and others that are waiting. This hasn't been forgotten, just not as smooth as one would want :-/
[09:52] <fheimes> Hello, is there an Archive Admin (#archive-admins) out there that can help getting an s390-tools* upload approved that is stuck in noble for 10+d? (It req. special approval, as usual, since signing is required).
[09:52] <fheimes> https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#s390-tools
[09:52] <fheimes> see 'unapproved' here:
[09:52] <fheimes> https://launchpad.net/ubuntu/+source/s390-tools/2.30.0-0ubuntu1
[10:47] <doko> Eickmeyer: s**t happens, but thanks for removing it from the seed for now
[10:56] -queuebot:#ubuntu-release- New source: gcc-14-cross-ports (noble-proposed/primary) [1ubuntu1]
[10:58] -queuebot:#ubuntu-release- New: accepted gcc-14-cross-ports [source] (noble-proposed) [1ubuntu1]
[11:01] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (noble-proposed) [2.30.0-0ubuntu1]
[11:01] <seb128> fheimes, hey, s390-tools binaries accepted now ^, thanks for the ping we don't review dev unapproved often since it's usually empty (so feel free to ping again next time you do an upload which ends up there)
[11:16] <fheimes> many thx seb128 !
[11:16] <seb128> np!
[11:28] -queuebot:#ubuntu-release- Packageset: Added gcc-14-cross-ports to i386-whitelist in noble
[11:28] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-18 to i386-whitelist in noble
[11:29] -queuebot:#ubuntu-release- New binary: python-cassandra-driver [amd64] (noble-proposed/none) [3.29.0-1] (no packageset)
[11:39] -queuebot:#ubuntu-release- New binary: python-cassandra-driver [ppc64el] (noble-proposed/universe) [3.29.0-1] (no packageset)
[12:05] -queuebot:#ubuntu-release- Unapproved: linux-firmware (jammy-proposed/main) [20220329.git681281e4-0ubuntu3.25 => 20220329.git681281e4-0ubuntu3.26] (core, kernel)
[12:07] -queuebot:#ubuntu-release- New binary: python-cassandra-driver [arm64] (noble-proposed/universe) [3.29.0-1] (no packageset)
[12:17] -queuebot:#ubuntu-release- New binary: python-cassandra-driver [armhf] (noble-proposed/universe) [3.29.0-1] (no packageset)
[12:20] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (jammy-proposed) [20220329.git681281e4-0ubuntu3.26]
[12:34] <kanashiro> heads-up: we had some priority changes and I am planning to start the ruby 3.2 transition today (it was initially planned to start at the beginning of the month). I'd like to announce this here since there are some ongoing transitions at the moment.
[13:30] <fossfreedom_> hi ubuntu-release - how often does the update-excuses get refreshed?  I thought it was once an hour but it seems not refreshed for a few hours now. https://ubuntu-archive-team.ubuntu.com/proposed-migration/noble/update_excuses.html
[14:07] <doko> kanashiro: can you wait a day until vorlon is back here and at perl is migrating?
[14:07] <doko> .. at least
[14:11] -queuebot:#ubuntu-release- New: accepted python-cassandra-driver [amd64] (noble-proposed) [3.29.0-1]
[14:11] -queuebot:#ubuntu-release- New: accepted python-cassandra-driver [armhf] (noble-proposed) [3.29.0-1]
[14:11] -queuebot:#ubuntu-release- New: accepted python-cassandra-driver [arm64] (noble-proposed) [3.29.0-1]
[14:11] -queuebot:#ubuntu-release- New: accepted python-cassandra-driver [ppc64el] (noble-proposed) [3.29.0-1]
[14:50] -queuebot:#ubuntu-release- Unapproved: dns-root-data (focal-proposed/main) [2019052802 => 2023112702~ubuntu0.20.04.1] (desktop-core, ubuntu-server)
[14:50] -queuebot:#ubuntu-release- Unapproved: dns-root-data (mantic-proposed/main) [2023010101 => 2023112702~ubuntu0.23.10.1] (desktop-core, ubuntu-server)
[14:50] -queuebot:#ubuntu-release- Unapproved: dns-root-data (jammy-proposed/main) [2021011101 => 2023112702~ubuntu0.22.04.1] (desktop-core, ubuntu-server)
[15:07] <kanashiro> doko: yes, I can.
[15:18] <jbicha> fossfreedom_: I believe the slow excuses is because the autopkgtest infrastructure is having some issues (but it's being worked on)
[15:30] <Eickmeyer> doko: Not actually removing it from the seed, but keeping it in as a recommends which shouldn't bother anything. Working with upstream developer and Debian developer on a patch.
[15:31] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.51 => 2.664.52] (desktop-core, i386-whitelist)
[15:32] <vorlon> fossfreedom_: "as often as it can be".  Once the report finishes, it immediately kicks off another run
[15:34] <vorlon> kanashiro: it seems ruby3.2 isn't in Debian unstable yet?  What's the plan there?
[15:35] <vorlon> kanashiro: note that libruby is affected by the time_t ABI change.  Can I suggest that you manually opt in to 64-bit time_t when uploading ruby3.2 to unstable or noble, so that we don't have to transition it twice in 2 weeks?
[15:35] <vorlon> kanashiro: DEB_BUILD_OPTIONS=abi=time64
[15:37] <vorlon> kanashiro: I think it's ok to start the ruby transition before the time_t transition.  How long do you expect it to take to clear -proposed?
[15:41] <vorlon> jbicha: I see nothing in my history about "autopkgtest infrastructure having some issues", what's your source for this?  currently update_excuses is ~2h old, which is not unusual for a proposed-migration run when there are a lot of tests to be queued or queried (in this case it would have to be "queued", as there are only 634 "test in progress" on the page currently which is not a lot)
[15:42] <seb128> speaking of transition, I know there is no 'good' time but any recommendation on when to/not to upload libglib 2.79 from GNOME (we don't expect breakages from it but from experience it sometime leads to some work and rdepends fixing)
[15:49] <vorlon> seb128: juggling; personally no strong opinion off the top of my head; will put it on agenda to discuss @ release team meeting in .5h
[15:51] <kanashiro> vorlon: I am going ahead of Debian to finish it before FF. I will be syncing ruby-defaults from experimental. And yes, I can add the time64 option. My expectation is around 2 weeks to get everything ready to migrate
[15:52] <vorlon> kanashiro: ok how soon can you do it, can you do it today
[15:53] <kanashiro> vorlon: yes, I can start today
[15:54] <vorlon> kanashiro: oh.  is there a common build-depend where you're able to export DEB_BUILD_OPTIONS for all the ruby *reverse-depends*? because otherwise you'd have ABI skew, which could manifest as runtime failures (picked up by tests etc)
[15:55] <kanashiro> vorlon: I will take a look if we can do that in gem2deb
[15:55] <vorlon> kanashiro: thanks
[15:56] <vorlon> you might also still have ABI skew if some of ruby's build-deps are time-t-sensitive libraries
[15:56] <vorlon> but you'll catch that sooner if so
[15:56] <kanashiro> +1
[15:59] <vorlon> (like hopefully you would catch that in ruby3.2 build/autopkgtests, long before changing ruby-defaults)
[16:06] <kanashiro> yeah, I will start with ruby3.2 and see how it goes
[16:13] -queuebot:#ubuntu-release- New binary: gcc-14-cross-ports [s390x] (noble-proposed/universe) [1ubuntu1] (i386-whitelist)
[16:31] <athos> ja ta rolando ate discurso motivacional
[16:32] <athos> obviously WC :)
[16:39] <LocutusOfBorg> doko, planning to sync llvm-18 from experimental, or waiting for actual builds to finish first?
[16:39] <LocutusOfBorg> I'm wondering what happens if a build finishes in release pocket while something is in proposed
[17:14] <jbicha> vorlon: Canonical QA channel. Yes it would be helpful for autopkgtest issues to be discussed at least generally here instead
[17:15] <vorlon> jbicha: I am on that channel and see nothing that describes an infra issue that would impact proposed-migration
[17:16] <vorlon> seb128: +1 for uploading libglib 2.79 this week whenever you're ready
[17:16] <tsimonq2> jbicha: https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/noble/2024-01-30/13:55:28.log
[17:16] <jbicha> excuses was updating much more frequently until yesterday around when the autopkgtest issues started happening
[17:16] <tsimonq2> jbicha: Nothing is broken. It's still running. ;)
[17:16] <jbicha> I said slow, not broken
[17:17] <tsimonq2> Nothing new there. Eventually(tm) it should be migrated to use a more scalable database than SQLite... that day probably won't come until the 24.10 cycle if I have something to do with it. :)
[17:17] <tsimonq2> Also, it's doing a lot of scanning for pending tests.
[17:17] <tsimonq2> Anyway, it's a few different things, I don't see anything particularly *unusual*
[17:17] <vorlon> jbicha: ... which had zero discussion on the internal channel yesterday, so this is not a question of the QA team failing to communicate on public channels
[17:18] <jbicha> vorlon: I have a timestamp of 12:55 pm yesterday my time. Anyway, not trying to argue now
[17:19] <tsimonq2> (No offense intended or anger from my end, it's just the second time I've linked someone to this in the past few weeks... so obviously something needs to be either fixed or communicated better. Not something I'll urgently get on myself.)
[17:20] <vorlon> tsimonq2: linked someone to what?
[17:20] <tsimonq2> vorlon: https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/noble/2024-01-30/13:55:28.log
[17:20] <tsimonq2> Or similar.
[17:20] <tsimonq2> We've had the discussion ad nauseum about *why*, not sure that was communicated more than just here.
[17:20] <vorlon> I don't know how pointing to proposed-migration logs means "something needs to be fixed"
[17:21] <jbicha> tsimonq2: yes & you can see the slowdown started yesterday
[17:22] <tsimonq2> Looking from a documentation perspective; some people don't even know those logs exist. Anyway, not interested in bikeshedding much earlier than 24.10 archive opening, just making a general suggestion since d_oko was wondering a bit ago as well.
[17:22] <vorlon> so the current log does show a problem with things being slow, the intervals between the log lines are not reasonable.  trying to see now if there's information that would help us pinpoint where the bottleneck is
[17:23] <vorlon> because most of what I'm seeing that is being slow is *not* trying to schedule new autopkgtest requests
[17:25] <jbicha> my theory was it is slow in reading the autopkgtest results
[17:25] <vorlon> ok nothing in the logs jumps out at me.  I'm going to try to dig into this later; it'll be afternood before I can get to it
[17:26] <vorlon> jbicha: which is read from a local copy of the autopkgtest.db
[17:26] <vorlon> so no
[17:26] <vorlon> at least, if it's slow, it has nothing to do with autopkgtest infra
[17:26] <ahasenack> is that the 1.4Gb+ sqlite db?
[17:27] <vorlon> yes
[17:27] <vorlon> a) it's still faster than doing REST calls for each and every test, b) I don't know of any reason it should've suddenly gotten slower
[17:28] <vorlon> but again, I'll look into it but it'll have to be later
[17:36] -queuebot:#ubuntu-release- Unapproved: gdm3 (jammy-proposed/main) [42.0-1ubuntu7.22.04.3 => 42.0-1ubuntu7.22.04.4] (desktop-core)
[18:04] <vorlon> don't have time to dig into it further, but I did just check the ubuntu-archive server and it's neither CPU nor memory bound right now
[18:05] <vorlon> britney is spending a lot of time reading from autopkgtest.db
[18:05] <vorlon> so it's possible we need to optimize the database somehow
[18:05] <vorlon> oh and it's 1.8GiB now
[18:13] <doko> LocutusOfBorg: please wait a day or two. new binary packages are accepted into -proposed, and would be rejected
[18:14] <LocutusOfBorg> ack doko
[18:14] <LocutusOfBorg> maybe we can sync on bileto?
[18:15] <LocutusOfBorg> not sure why it is that slow
[18:16] <doko> yes, riscv64 finishing that long before is odd
[18:16] <vorlon> ok just checked w/ qa team internally, it sounds like this is a known problem with the database - so not really an autopkgtest infrastructure problem, but a problem that the database we're syncing is borked in a way that causes slow reads whoever is doing the reading
[18:16] <ahasenack> dump+reload?
[18:16] <vorlon> the database is currently being regenerated from scratch and that is estimated to complete tomorrow
[18:16] <vorlon> (UK time)
[18:35] <LocutusOfBorg> ack thanks
[19:22] <tsimonq2> This is legit: https://lists.ubuntu.com/archives/technical-board/2024-January/002864.html
[20:40] <sarnold> forkbuntu! finally a flavor for everyone :)
[21:15] <seb128> vorlon, re libglib, ack and thanks!
[22:05] <LocutusOfBorg> damn
[22:05] <LocutusOfBorg> cpete, sorry continuing here
[22:05] <LocutusOfBorg> I got silenced due to bad copypaste
[22:05] <LocutusOfBorg> ubuntutools/test/test_running_autopkgtests.py
[22:05] <LocutusOfBorg> what is this test supposing to test?
[22:06] <LocutusOfBorg> there is no documentation, and if you check noble autopkgtest queues, what should happen once noble is EOL, so that autopkgtest queues are not available anymore? will the package fail in testing?
[22:06] <LocutusOfBorg> we have enough time bombs in the package already
[22:07] <LocutusOfBorg> maybe instead of hardcoding "noble" we can think about using some distro-info --devel
[22:07] <LocutusOfBorg> output
[22:55] -queuebot:#ubuntu-release- New binary: gcc-14-cross-ports [amd64] (noble-proposed/universe) [1ubuntu1] (i386-whitelist)
[23:21] -queuebot:#ubuntu-release- New binary: mypaint [amd64] (noble-proposed/none) [2.0.1-10] (ubuntustudio)
[23:22] <Eickmeyer> Oh hey! Look at that! ^
[23:27] -queuebot:#ubuntu-release- New binary: mypaint [ppc64el] (noble-proposed/universe) [2.0.1-10] (ubuntustudio)
[23:29] -queuebot:#ubuntu-release- New binary: mypaint [arm64] (noble-proposed/universe) [2.0.1-10] (ubuntustudio)
[23:33] -queuebot:#ubuntu-release- New binary: mypaint [armhf] (noble-proposed/universe) [2.0.1-10] (ubuntustudio)
[23:44] -queuebot:#ubuntu-release- New binary: mypaint [s390x] (noble-proposed/universe) [2.0.1-10] (ubuntustudio)