[00:18] mwhudson: flask is now a candidate, but by itself does not migrate; next notest report (post 2024.03.25 22:39:40) might show some new flask-related uninstallables [00:43] -queuebot:#ubuntu-release- New binary: singularity-container [amd64] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset) [01:01] mwhudson: had a thought while I was afk that oh, the only thing stopping flask from being a candidate before was tests... so it was already on notest... but not included in the mass hint because of a net increase in uninstallables. So we actually do have to resolve those revdeps [01:01] trying: flask onionshare flask-security [01:01] afk dinner [01:01] * amd64: python3-fava [01:07] -queuebot:#ubuntu-release- New binary: singularity-container [s390x] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset) [01:08] -queuebot:#ubuntu-release- New binary: singularity-container [armhf] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset) [01:11] vorlon: i'm almost done for now too [01:17] -queuebot:#ubuntu-release- New: accepted singularity-container [amd64] (noble-proposed) [4.1.1+ds2-1] [01:17] -queuebot:#ubuntu-release- New: accepted singularity-container [s390x] (noble-proposed) [4.1.1+ds2-1] [01:17] -queuebot:#ubuntu-release- New: accepted singularity-container [armhf] (noble-proposed) [4.1.1+ds2-1] [01:18] vorlon: remove fava from release? it is gone from testing and has no rdeps. looks like an upstream update may fix it but well [01:25] mwhudson: ack [01:26] mwhudson: fava removed [01:27] -queuebot:#ubuntu-release- New binary: singularity-container [arm64] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset) [01:28] -queuebot:#ubuntu-release- New: accepted singularity-container [arm64] (noble-proposed) [4.1.1+ds2-1] [01:40] -queuebot:#ubuntu-release- New binary: singularity-container [ppc64el] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset) [01:42] -queuebot:#ubuntu-release- New: accepted singularity-container [ppc64el] (noble-proposed) [4.1.1+ds2-1] [01:47] gtk4/armhf autopkgtest fails [01:51] -queuebot:#ubuntu-release- New binary: singularity-container [riscv64] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset) [02:04] -queuebot:#ubuntu-release- New: accepted singularity-container [riscv64] (noble-proposed) [4.1.1+ds2-1] === chris14_ is now known as chris14 [03:05] -queuebot:#ubuntu-release- New binary: ubuntukylin-default-settings [amd64] (noble-proposed/universe) [24.04] (ubuntukylin) [03:11] -queuebot:#ubuntu-release- New: accepted ubuntukylin-default-settings [amd64] (noble-proposed) [24.04] === alucardromero9 is now known as alucardromero === pushkarnk1 is now known as pushkarnk [06:12] rolled back gnome-shell to 46.0-0ubuntu2 in -proposed; 46.0-0ubuntu3 is a rebuild against mutter which is otherwise separable from the rest of the transition from what I see [06:19] only 87 new armhf leaf packages for removal in the lastest notest report [06:22] and filing bug reports for 8 of those which have new versions built in -proposed but not an armhf [06:24] oops correction 3 new bug reports [06:27] glib-networking autopkgtests seem to have a real regression on amd64 [06:38] haha noooo casper has an autopkgtest using losetup [06:46] 863s python-flask-restful-doc : Depends: sphinx (= 7.2.6-4) [06:46] what [07:56] tsimonq2: lubuntu has neofetch seeded, which recommends jp2a, which ftbfs on all archs in Ubuntu (no reported failure in Debian); so I'm removing it [07:58] 668s Mar 26 06:54:23 autopkgtest-lxd-xtxlvz nginx[1467]: 2024/03/26 06:54:23 [emerg] 1467#1467: module "/usr/share/nginx/modules/ngx_http_auth_pam_module.so" is not binary compatible in /etc/nginx/modules-enabled/50-mod-http-auth-pam.conf:1 [07:58] ... what do you mean "/usr/share" [08:12] Ah good amd64 queues are going down now, I can see the graph trending down [08:15] But like 2k items / day [08:16] Error rate is down a lot [08:16] Very happy [08:34] athos, I stolen your pacemaker merge. Turned out the FTBFS fix patch coming from Debian was better than mine [08:34] so, I grabbed it and reuploaded [09:46] several tests were inadvertently dropped on non-amd64 architectures, QA has rescheduled python tests for ppc64el and s390x, and scheduling of non-python tests is WIP. These are being queued into huge queue to allow you to do targeted retries of important blockers for the time_t transition, please don't abuse that [09:46] I am watching [09:55] going up the chain of dependencies, I'm going to look at pipewire and slurm-wlm for readline, and ngircd (missing build), libp11, gnutls28 for gnutls28 and for nettle; that's a lot so feel free to pick some of that [09:56] btw, I think diffoscope on armhf is high-reward too [10:00] -queuebot:#ubuntu-release- New binary: mathgl [riscv64] (noble-proposed/universe) [8.0.1-7.1] (no packageset) [10:14] requeuing of non python tests is done for ppc64el and s390x. Please note that they were requeued without all-proposed, compared to britney asking them **with** all-proposed [10:20] Skia: oh no, I guess I forgot that, that was not intentional [10:20] yeah, and I realized that after it run [10:21] Skia: so without all-proposed they'll fail too much to be useful I suppose [10:22] Skia: I think we ought to purge the huge queues again and redo the same dance with all-proposed [10:22] fine, I'll work on that [10:22] Skia: Sorry [10:22] no prob' :-) [10:23] when doing that, are you also dropping other tests? [10:23] also, if there's a window of opportunity to sneak in tests at the front of the queue, let me know... [10:24] but since you're putting stuff in the huge queue, that's fine actually [10:25] :) [10:25] The good thing is - one can just purge the huge queues and issue RUNNING tests again [10:25] it's not possible to lose tests that way [10:27] python scheduling in progress [10:32] ooh I really need a KPI for size of -proposed [10:32] my rewriter tells me this: Processed 7234 migrations; 2267 issues, 4673 blocked, 294 waiting. [10:33] Now do the past 30 days :) [10:33] my shell scrollback doesn't go back that far :P [10:33] I could actually talk to the snapshot service and figure that out [10:33] and I didn't even add these stats at the beginning of the scrollback ;-) [10:33] but does that look like what you'd be after? [10:34] more than what I'm after [10:34] I was looking for the first number only :D [10:34] but this is more informative [10:34] issues is test issues, blocked is Depends: on "not considered" packages, and 294 is britney attempting migration [10:36] March 22 morning, I had Processed 6842 migrations. [10:36] ok [10:36] and evening: Processed 7256 migrations; 3104 issues, 4005 blocked, 150 waiting. [10:37] 23rd early afternoon I guess: Processed 7258 migrations; 2287 issues, 4773 blocked, 198 waiting. [10:38] and yesterday evening: Processed 7269 migrations; 2210 issues, 4853 blocked, 206 waiting. [10:42] non-python scheduling in progress [10:48] I'm not sure we'll make progress, it seems a lot of tests are just running in the release pocket due to infrastructure issues [10:49] Regardless of any triggers, all-proposed flags, they don't necessarily do anything right now === pushkarnk1 is now known as pushkarnk === pushkarnk1 is now known as pushkarnk [11:19] Hi, Release team, please approve ukui-settings-daemon, ukui-control-center, ukui-power-manager, ukui-panel, ukui-media, peony from noble proposed. Thanks! [11:22] handsome_feng: the migration is automatic, but currently pretty much all of -proposed is blocked due to the time_t migration. See https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#ukui-settings-daemon [11:23] schopin: Got it, thanks! [11:32] ubuntu-archive: please RM confget, nsca, nsca-client binaries from armhf. confget is blocking perl on armhf (and nsca is its sole relevant rdep) [11:33] schopin, removed [11:35] hey ubuntu-archive! May I ask for armhf binaries of "dante" in Noble? https://bugs.launchpad.net/ubuntu/+source/dante/+bug/2059104 [11:35] -ubottu:#ubuntu-release- Launchpad bug 2059104 in dante (Ubuntu) "Please remove dante armhf binaries from Noble" [Undecided, New] [11:38] slyon, hey, removed [11:39] thanks! [11:40] np! [11:41] seb128: did you leave out dante-client on purpose? I think it should go as well [11:49] slyon, it's an arch all binary [11:50] ah, sure! [11:50] nvm [11:50] :) [12:02] -queuebot:#ubuntu-release- New: accepted nobodd [source] (noble-proposed) [0.4-0ubuntu1] [12:04] -queuebot:#ubuntu-release- New binary: nobodd [amd64] (noble-proposed/none) [0.4-0ubuntu1] (no packageset) [12:07] All test results since the 20th outside of armhf are wrong, so we are in the process of sorting this out with QA [12:08] Only armhf was actually using proposed [12:08] Current proposal is to hack up the autopkgtest.db to change their exit code from 0 to 20 (pass to error), deleete britney's cache and have it repopulate it from the db [12:09] > All test results since the 20th outside of armhf are wrong [12:09] what? [12:09] I just connected and don't have chat history [12:09] * ahasenack checks irc logs [12:10] ahasenack: This is just my PSA [12:11] might be worth an update to https://discourse.ubuntu.com/t/autopkgtest-service/34490/2 when someone has some time [12:12] ahasenack: updated [12:12] ahasenack: a simple case is https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386 which has been passing with a version lower than the trigger since the 19th [12:12] not sure when it really started [12:13] it's possibly it was the 18th after all [12:13] oh, I reported that in chat, it was not picking up the right version [12:13] yes and that happens for everything [12:14] and britney can only tell for tested package == trigger [12:14] because then it compares version tested against trigger and sees "old result" [12:14] talk about perfect storm [12:14] but e.g. stuff triggered by gnupg that's pass actually just tested gnupg in the release pocket [12:15] that happening now [12:15] Workers are off, bug is being fixed [12:43] autopkgtest.db has been updated with no-proposed=1 for hopefully most failures caused by the bug [12:43] I think there were oddly unrelated ones [12:44] -queuebot:#ubuntu-release- New: accepted nobodd [amd64] (noble-proposed) [0.4-0ubuntu1] [12:45] you can see now for example on https://autopkgtest.ubuntu.com/packages/python-apt/noble/s390x [12:45] tests have no-proposed=1 [12:45] and error [12:45] the no-proposed=1 flag has been added to all rewritten results [12:46] but like libvpx has a failure to get the latest version before the designated day and I'm not sure what that is about [12:47] we figured the cut-off day based on mojo run days, those happened 13th and 20th [12:49] -queuebot:#ubuntu-release- Unapproved: ubuntu-unity-backgrounds (mantic-proposed/universe) [23.10-0ubuntu1 => 24.04-0ubuntu1] (no packageset) [12:50] -queuebot:#ubuntu-release- Unapproved: sagemath (mantic-proposed/universe) [9.5-6ubuntu0.1 => 9.5-6ubuntu0.1.1] (no packageset) [12:52] sil2100, ubuntu-release: with the database now changed, next step is kill britney, mv autopkgtest-results.cache autopkgtest-results.cache.before-the-fiasko and start it again so it repopulates from fresh database [12:52] And I guess monitoring the output to see if it does any weird shenanigans [12:53] hm, let me try that === pushkarnk1 is now known as pushkarnk [12:54] Shit, I removed the crontab of archive-toolbox by a typo [12:55] oh, I hadn't read a debian bug report well: plenty of R packages to remove :) [12:55] maintainer had asked for removal of a few packages plus only direct dependencies [12:56] * adrien curses at debbugs [13:02] sil2100: oops, I suppose it has a backup? [13:03] ... [13:03] I'm afraid only Steve knows [13:04] :( [13:07] LocutusOfBorg: Thanks [13:08] ubuntu-archive: please remove the pngphoon leaf binary package on Noble/armhf, it FTBFS (on armhf only), due to time_t [13:13] I'll have close to 30 removal requests; shall I pastebin or launchpad that? [13:14] adrien: just pastebinit first and we can see [13:18] thanks [13:22] what about packages that are architecture: all and have their dependencies removed: do they need to be explicitly removed? [13:26] we cannot remove architecture: all binaries from armhf [13:26] you can only remove them from all architectures [13:31] makes sense; is there anything to do to get these out of the way for tests? there are failed ones for them on armhf [13:39] jamespage: python3-os-xenapi needs an update for Python 3.12 [13:51] ubuntu-archive: on armhf, please remove r-bioc-bsseq r-bioc-dss r-bioc-demixt ; see https://pastebin.ubuntu.com/p/6vTqmmmghG/ for details [14:07] doko: looking [14:15] doko: may be able to RM that - just testing now [14:21] Please reject ubuntu-unity-backgrounds from mantic queue. I didn't notice wrong series when sponsoring (should have been noble). [14:25] Hi sru-team (ubuntu-sru), I'm aware that we are currently in soft-freeze, but I would nevertheless kindly ask if an sru team member can have a look at socat in focal's unapproved queue: [14:25] https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=socat [14:25] (since this is related to a customer case). Thank you! [14:26] what soft freeze? [14:30] Well, aren't we usually in a kind of a soft-freeze at the end of a dev cycle that effects and impacts resources on other tasks like SRUs? (that is at least what I had in mind, well, if not, even better ;-) ) [14:30] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-unity-backgrounds [source] (mantic-proposed) [24.04-0ubuntu1] [14:32] doko: confirmed - os-xenapi can be dropped from the archive as all reverse-depends dropped support for xen some time ago [14:33] i've uploaded fixes for nova, ceilometer and neutron to drop the dependency [14:34] jamespage: ta, and vitrage ... [14:35] yeah we're working on that at the moment [14:35] watcher also has woes but not directly 3.12 related [15:22] ubuntu-archive: please remove the ruby-sigar leaf binary package on Noble/armhf, it FTBFS (on armhf only), due to time_t and blocks the libtirpc transition [15:23] juliank: did https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed.txt get updated to include seeded things minus meta? [15:25] slyon: done, can you file a bug about this and tag it time_t? [15:27] slyon: pngphoon removed; bug also please [15:28] adrien: arch: all packages with failed tests, a baseline retry will now also fail due to the missing dep, which gives us a record of the -proposed failure not being a regression [15:28] vorlon:, thanks! sure: https://bugs.launchpad.net/ubuntu/+source/ruby-sigar/+bug/2059137 – I tagged it "time-t" as "time_t" is invalid according to Launchpad [15:28] -ubottu:#ubuntu-release- Launchpad bug 2059137 in ruby-sigar (Ubuntu) "FTBFS on Noble/armhf, blocking libtirpc time_t transition" [Undecided, Fix Committed] [15:29] slyon: sorry that's what I meant :) [15:30] bdmurray: please also reject cloud-init 24.1.2 in unapproved queues for Focal, Jammy and Mantic looks like we've got one other upload for cloud-init 24.1.3 we'd prefer to get out instead of the unapproved 24.1.2. [15:30] adrien: ooi how do these r-bioc packages come to be on your radar given that they're not in -proposed? [15:32] https://bugs.launchpad.net/ubuntu/+source/pngphoon/+bug/2059139 [15:32] -ubottu:#ubuntu-release- Launchpad bug 2059139 in pngphoon (Ubuntu) "Please remove pngphoon on Noble/armhf" [Undecided, Fix Committed] [15:40] juliank: ok, should be happening now (with the cache) [15:45] doko: bug 2059141 [15:45] -ubottu:#ubuntu-release- Bug 2059141 in python-os-xenapi (Ubuntu) "RM: please remove python-os-xenapi from noble development" [Undecided, New] https://launchpad.net/bugs/2059141 [15:46] vorlon: r-bioc-demixt blocks r-base: https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-noble/noble/armhf/r/r-bioc-demixt/20240326_093034_23dcd@/log.gz and I missed these in a removal request yesterday for other R packages (I blame debbugs) [15:46] just isolated a time_t bug in softhsm2 (masked because doko disabled blocking on build-time test failures), last real regression for gnutls28 (seen in the libp11 autopkgtest) [15:53] vorlon: "because doko disabled blocking on build-time test failures" ??? [15:53] doko: see the softhsm2 changelog [15:58] we have quite a few openstack packages blocked on autopkgtests on armhf failure due to install issues - I don't want to double up on any general efforts in this area but is there anything my team should be doing to help in this area? [16:09] juliank: I've added statistics on https://adrien.dcln.fr/misc/update_excuses_2.html ; it's the three counts separately but I haven't yet seen a case where summing them didn't give the total count [16:10] ubuntu-archive: please rm filament (bug 2059145) [16:10] -ubottu:#ubuntu-release- Bug 2059145 in filament (Ubuntu) "please remove filament from noble" [Undecided, In Progress] https://launchpad.net/bugs/2059145 [16:11] jamespage: can you point me to a specific package at issue, so I can see exactly which bucket it falls into [16:12] "only" 2108 binary packages rendered uninstallable on armhf [16:13] and only one of them a candidate for removal according to https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed.txt [16:13] vorlon: since yesterday, I didn't check the section but task == name or "ubuntu-" + task == name [16:13] let me pick one from the 198 currently needing attention [16:14] sil2100: you mean, britney is repopulating its cache nwo? [16:14] juliank: ok. unfortunate! [16:14] vorlon: Should I print a log too of packages that are being kept? [16:15] then I can print their reverse deps in the log [16:15] juliank: (unfortunate that we don't get more candidates for removal) [16:15] Makes it easier to see if something is wrong somewhere [16:15] juliank: I'm not going to think about that right now [16:15] I'll just do it [16:15] juliank: if we break 2000 packages, we break 2000 packages [16:15] juliank: it should, yes [16:15] and then we'll have https://ubuntu-archive-team.ubuntu.com/proposed-migration/noble_uninst.txt as our post-beta work list [16:15] yeah 225 MB of logs [16:15] for britney [16:16] so that is good [16:17] My adhoc commandline parsers are killing me [16:17] vorlon: ignore me my view is out-of-date - the by-team report has not been regenerated since 22nd [16:23] -queuebot:#ubuntu-release- Unapproved: update-manager (jammy-proposed/main) [1:22.04.19 => 1:22.04.20] (core) [16:26] -queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.23 => 1:18.04.12] (core) [16:28] -queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.21 => 1:16.04.22] (core) [16:30] vorlon: eek the log is 150MB :D [16:30] I guess it prints every package 8 times [16:30] I'll make it smarter [16:30] Let it only print the first iteration [16:32] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.20 => 1:20.04.10.21] (core) [16:34] Hey y'all, I just noticed this: http://ftp.ubuntu.com/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ [16:35] symlink gone wild? [16:35] thought you should know, hope you're all doing well. bye now! [16:40] athos: please could you have a look at https://launchpad.net/ubuntu/+source/php-parser/5.0.2-2/+build/27898903 [16:42] vorlon, sil2100 is britney alive, it hasn't written in 10 minutes, but also not finished? [16:42] Let me see [16:43] juliank: the process seems alive [16:43] @room: FYI for those who are interested, we now have an Ubuntu Release room on Matrix. https://matrix.to/#/#release:ubuntu.com IRC bridging isn't active yet, but should be in the relatively near future. We already have a port of Queuebot operating in there (written by Nils Büchner a.k.a. ravage), so you can see archive and ISO activity just like in here. [16:44] juliank: and at least on the instance I see latest logs for the noble run from 2024-03-26T16:43:43+0000 [16:44] ok [16:45] sil2100: I can only look at https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/noble/2024-03-26/ I am not powerful enough [16:47] Oh god I should add another info message to britney [16:47] Because we only log matches pending request or not [16:48] but this run doesn't really have pending requests for all of them I suppose [16:48] but still it will record the test result [16:48] but it doesn't log that it did so :) [16:50] I guess the http log is updated by a 10 minutely cron job [16:50] or 15 minute [16:52] arraybolt3: is the release team in that room? [16:53] schopin: I just created it, so until they join, no [16:53] it's just part of getting the Matrix side of the Ubuntu community up-and-running. [16:53] once IRC bridging is on, then everyone will be there. [16:54] jamespage: ah indeed - I don't know why that's out of date [16:55] britney is requesting a bunch of migration-refernce/0 [16:56] amd64: 515 [16:56] i386: 45 [16:56] ppc64el: 349 [16:56] s390x: 633 [16:56] armhf: 0 [16:56] arm64: 301 [16:56] so far [16:56] Only 5 each that are not migration-reference [16:59] I just realized my queued branch is stupid, it iterates the entire queue each time when it wants to send a request. I should just visit the queues at the start and build a dict to then do O(1) lookup for each test I want to send [16:59] Again linear complexity vs more or less quadratic [17:01] heh we probably want to go through `reverse-depends src:faketime -a source [17:01] dgit autopkgtest fails because of it. I was just looking at osslsigncode build failure, and find it's on this list. [17:05] keep faketime rdeps=['epoptes', 'src:altos', 'src:debian-reference', 'src:devscripts', 'src:dkim-rotate', 'src:doxygen', 'src:fastdds', 'src:festival', 'src:genometools', 'src:jags', 'src:katarakt', 'src:libgfshare', 'src:macaulay2', 'src:mbedtls', 'src:mcabber', 'src:moon-buggy', 'src:oath-toolkit', 'src:ocl-icd', 'src:osslsigncode', 'src:pandas', 'src:postsrsd', 'src:pyacidobasic', [17:05] 'src:pyscanfcs', 'src:rauc', 'src:reprotest', 'src:sssd', 'src:sympy', 'src:x4d-icons'] may_remove=True [17:05] I wonder if reverse-depends agrees [17:06] probably no fancy provides on there [17:07] Please, drop package licheerv-rtl8723ds-dkms from the 24.04/noble archive. It is not needed anymore. LP #2059151 [17:07] -ubottu:#ubuntu-release- Launchpad bug 2059151 in licheerv-rtl8723ds-dkms (Ubuntu) "Drop package licheerv-rtl8723ds-dkms from 24.04 (Noble)" [Undecided, New] https://launchpad.net/bugs/2059151 [17:08] (from the new "keep" log file https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed.log) [17:09] (which is not regularly updated but a poc more or less) [17:10] I guess I could make my report a json file and you can query it with jq nicely [17:11] "15MB JSON file as an API" [17:16] vorlon: I guess packages in release pocket that *do not have a version in proposed* could become uninstallable as well, so joining uninstallables with the unfiltered report https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.txt may prove useful? [17:17] or will it always report the package migrating as the uninstallability [17:27] why do we have a two year old nvidia-settings package in noble? [17:27] for shits and giggles? [17:28] apw: ^^^ [17:28] doko, good question... will pass that on ... [17:30] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (mantic-proposed) [24.1.2-0ubuntu1~23.10.1] [17:31] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (focal-proposed) [24.1.2-0ubuntu1~20.04.1] [17:31] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (jammy-proposed) [24.1.2-0ubuntu1~22.04.1] [17:53] seb128: are there any plans for GTK2 removals, like in Debian? [17:55] doko: Yes (looking into php-parser) [18:01] doko, not at the moment, at least it's not something we have been actively looking at [18:16] juliank: packages in release pocket that do not have a version in proposed are either not candidates for removal because they are *transitively* uninstallable, or they *should* have versions in -proposed. [18:17] Hmm, I agree about the should but I'm not sure they necessarily all do [18:19] juliank: my point is they should get uploaded to -proposed and then they move to the other list [18:20] But can we find them? [18:20] if you care to [18:20] it's not the priority today [18:20] today the priority is: work through the set of packages that are included in the glib2.0 autohint on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt and analyze test failures to make them candidates for real [18:21] ooh britney finished [18:22] vorlon: I'm sure it looks much worse now? [18:22] what do you mean? [18:22] Waiting for a lot more tests than before we dropped broken passes [18:22] shrug [18:23] perl looks nice [18:23] at this point, missing amd64 test results are to be ignored, armhf regressions are to be analyzed [18:23] i386 regressions are to be yeeted [18:26] so much red [18:26] We dropped 2k tests on ppc64el 30 mins ago, why? [18:29] adrien: So I don't know why that is, it shouldn't treat 'error' as a regression, that's an infrastructure issue? [18:29] Well ok maybe it does [18:30] So we see red but we just tested the wrong version [18:31] This isn't optimal [18:32] Should we consider exit codes 16 (tmpfail) and 20 (error) as regressions? I don't know [18:32] red means someone needs to manually retry it [18:32] I feel like they should probably be neutral? [18:32] if the infra isn't going to retry it on its own then this is correct [18:32] neutral means it does not block migration [18:33] ok? [18:33] an infra failure is a regression vs a pass! [18:33] and should not be ignored [18:34] status: amd64: 2206 i386: 78 ppc64el: 1771 s390x: 2199 armhf: 230 arm64: 1913 [18:34] #regressions [18:35] is that the total number of i386 regressions? If so I should retry them all [18:36] vorlon: Normally that is all correct but now it makes it useless we don't see what we tested wrongly vs what actually failed, so we can't dig into the latter failures, and we don't have time for the former [18:36] vorlon: yes it is [18:36] juliank: uh no we just retry all of them, shrug [18:37] But we need to migrate them before we have the retries done [18:37] yes [18:37] we're NOT going to zero the amd64 test queue before tht [18:37] it's just not possible [18:38] hence why I said if we can see *real regressions* vs our messup, we'd have a better view of what is broken prior to migrating it [18:38] if you can get the messups moved to 'Test in progress' fine [18:38] If we just ignore the test results, we should cancel them all, and just do migration-reference/0 for everything after migration, and then we can build a migration-reference/0 dashboard [18:38] but the existing failures shouldn't be treated as neutral [18:39] we should cancel them all> [18:39] no [18:39] like nobody is going to see their results if they run after migration [18:40] Due to all-proposed the data quality is subpar too [18:40] queueing migration-reference/0 after migration will have better quality as you have a consistent set [18:41] let the queues run [18:41] I'm not going to engage this conversation further, it's a distraction from actually working on analyzing regressions [18:45] juliank: ah, makes sense; in any case it's clearly not differentiating [18:46] adrien: There's nothing we can do anymore, on import every result became PASS/NEUTRAL/FAIL :( [18:47] adrien: But we need to make sure to rerun them all, or run migration-reference/0 after migration on everything to ensure that future -proposed tests don't become "not a regression" [18:47] Because with everything red now due to messup, none of these will be regressions when we force migrated them and they get a new update [18:48] and like I said I prefer after the migration event to cancel the outstanding all-proposed tests and reschedule migration-reference/0 for everything to get an accurate gauge [18:48] or what is actually in the release pocket [18:48] ok cancelling them AFTER the migration is fine [18:49] I thought you meant to cancel them now :) [18:49] i don't give a duck now [18:51] openssl failures analyzed, unblocking [18:51] at last look that's the last transitive blocker for glib2.0; so britney runs are going to get slower now [18:52] for a while [18:52] sad britney [18:52] slower because they're going to have to report on a lot more uninstallables [18:53] vorlon: have you scheduled i386, or should I? I have the list and can just pipe [18:53] it [18:53] juliank: I had scheduled for openssl only [18:53] juliank: please go ahead [18:53] on it [18:54] funnily britney also scheduled migration-reference/0 tests for all our messup regressions of course [18:54] i386 retried. [18:55] the migration-reference are not a big issue tbh at least ppc64el and s390x are almost done with them [18:56] analyzing gtk+3.0 now [19:01] gtk+3.0 good, unblocking [19:04] analyzing at-spi2-core [19:05] at-spi2-core good [19:07] analyzing cups [19:12] cups analyzed, unblocking [19:13] that should be the glib2.0 + gtk2.0 stack unblocked, now the excitement begins [19:13] * juliank is more scared than excited [19:14] the scary part comes tomorrow; this is just making britney output more interesting in the meantime [19:14] vorlon: deadline is EOyourD tomorrow? [19:14] :D [19:14] yes [19:15] https://autopkgtest.ubuntu.com/packages/m/mumble/noble/armhf is interesting [19:15] oh [19:15] taking qtbase-opensource-src for analysis [19:15] mumble ^ so basically the package installation never completes? therefore gets marked as badpkg [19:15] will try to reproduce [19:15] I feel like it crashes somewhere? [19:16] It doesn't hang certainly [19:16] Maybe dpkg segfaults [19:16] the error says 'context deadline exceeded' [19:17] Yes for the dpkg-query analysis [19:17] quickly trying to reproduce [19:17] ah [19:17] But there's no time gap from where it stops installing to where it tries to analyse what is wrong [19:18] ok there is a 20s one [19:18] well dpkg itself succeeds [19:18] This tampermonkey script from QA folks adds line numbers and it confused me :D [19:18] confirmed locally [19:18] "context deadline exceeded" is a Go error string, no? [19:19] wth [19:19] And reverse-depends doesn't work for src:mumble [19:19] it has no output [19:19] fwiw mumble autopkgtest has been failing on armhf since 1.5.517-1 [19:20] so, not a time_t thing and I'm ignoring [19:20] the binaries are in your removal list [19:20] ah yes [19:20] kill it [19:20] or let it migrate [19:20] i don't care :D [19:20] not migrate [19:21] the one in -proposed is broken on ALL archs [19:21] so killing the binaries [19:21] ack [19:21] I think we just didn't test the other arches [19:21] the [19:21] these are all the infra messup regressions [19:22] juliank: yeah but there are failure logs on those archs from -1 as well [19:22] unblocking qtbase-opensource-src [19:23] taking libpng1.6 [19:23] ah yes I see 215s /tmp/autopkgtest.m5y5yl/build.WmN/src/debian/tests/smoke: 41: Syntax error: end of file unexpected (expecting ")") [19:23] breakage [19:23] libpng1.6 good, unblocking [19:25] right, afk for food [19:26] fwiw we have a report pending on the release team side to identify the set of packages that need this kind of analysis and I'm happy to have the analysis delegated to non-release-team members (the actual hinting being releaseteamonly) [19:40] taking pipewire [19:43] pipewire good [19:43] vorlon: when you say "unblocking ", what exactly do you mean? [19:43] taking libcanberra [19:44] ahasenack: adding a 'force-skiptest' hint to lp:~ubuntu-release/britney/+git/hints-ubuntu so that it will be considered in spite of incomplete or failing test results [19:44] libcanberra good [19:44] taking readline [19:48] what are you looking at? just trying to understand better because I saw hundreds of (mis-)reported regressions so that's a lot to go through and you're pretty quick [19:49] adrien: https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#readline only has 2 :) [19:49] and danilogondolfo already filed a bug about the one that matters [19:50] adrien: so far, I am looking at all of the regressions listed for any arch, and quickly pattern-matching on them to see if those particular regressions should be ignored [19:50] or if bugs need reported [19:50] (readline good) [19:50] adrien: if amd64 is "failed" but it's clearly an installability issue, ignore [19:51] adrien: if i386 is "failed" take a quick look but ultimately it's going to be ignored anyway [19:51] if armhf, dig in and see if it matches an issue I already know; and if bugs need filed to track the issue after migration [19:51] if failed on all archs, standard +1 maintenance triage [19:52] thanks; one thing: excuses for readline /had/ two but now there are all the cancelled ones reported too (maybe better don't refresh the page yet :D ) [19:53] and if the cause is mutter, ignore because mutter has a transition staged in -proposed that is not included in the current migration so it's going to be an uninstallable mess [19:53] adrien: oh lol ok [19:53] adrien: yes I won't refresh for a while then :D [19:53] gnome-desktop good [19:54] the old reports *are* still published, we could work off a previous one for a while [19:54] taking gst-plugins-good1.0 [19:54] sorry, I mean gst-plugins-base1.0 [19:58] anyway, the risk of real regressions on !armhf directly as a result of time_t is approximately nil, so it's not super important that I review all of the amd64 autopkgtest failures [20:00] there are some substantive changes with new upstream versions of some libraries (gnome stack), but it's very unlikely these would regress on amd64 but not arm64 (can't rely on ppc64el + s390x because they don't ship a full desktop) [20:06] thanks for all the details, and btw: how do we know there are ongoing transitions? are they recorded somewhere central? I wasn't aware for mutter for example (and that would have been useful) [20:07] adrien: it was discussed here [20:07] not otherwise documented [20:07] no good place to [20:08] vorlon: jp2a> ack, fix coming to archive today, we do need that. [20:08] here's the list of packages that need analysis of test failures: https://paste.ubuntu.com/p/49cbkr9C3V/ [20:08] tsimonq2: cheers [20:08]