[06:18] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-17 to i386-whitelist in mantic
=== cpaelzer_ is now known as cpaelzer
[06:28] <cpaelzer> I seem to be too blind to see, but maybe someone has a better idea here
[06:29] <cpaelzer> I got a ping that rmadison doesn't show -updates and such non-release on some requests
[06:29] <cpaelzer> I found the cgi that backs it to confirm it
[06:29] <cpaelzer> for example https://ubuntu-archive-team.ubuntu.com/madison.cgi?package=samba&a=source&c=&s=lunar-updates is empty
[06:29] <cpaelzer> while https://launchpad.net/ubuntu/+source/samba shows us there should be something
[06:30] <cpaelzer> interestingly it works for older things liek trusty https://ubuntu-archive-team.ubuntu.com/madison.cgi?package=samba&a=source&c=&s=trusty-updates
[06:30] <cpaelzer> I've logged into the system backing this up and ran the madison-lite command that I expect it to run
[06:30] <cpaelzer> and `/srv/ubuntu-archive/bin/madison-lite -a source -s lunar-updates samba` gave me the right answer
[07:18] -queuebot:#ubuntu-release- Packageset: Added oem-stella-aron-meta to canonical-oem-metapackages in focal
[07:18] -queuebot:#ubuntu-release- Packageset: Added oem-stella-cascoon-rpl-meta to canonical-oem-metapackages in focal
[07:18] -queuebot:#ubuntu-release- Packageset: Added oem-stella-aron-meta to canonical-oem-metapackages in jammy
[07:18] -queuebot:#ubuntu-release- Packageset: Added oem-stella-cascoon-rpl-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-asobo-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-bergmite-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-chiko-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-graveler-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-kuku-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-purrloin-rpl-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-romi-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-sensei-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-yoshio-meta to canonical-oem-metapackages in focal
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-asobo-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-bergmite-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-chiko-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-graveler-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-kuku-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-purrloin-rpl-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-romi-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-sensei-meta to canonical-oem-metapackages in jammy
[07:48] -queuebot:#ubuntu-release- Packageset: Added oem-stella-yoshio-meta to canonical-oem-metapackages in jammy
[07:50] -queuebot:#ubuntu-release- Unapproved: snapd (focal-proposed/main) [2.58+20.04.1 => 2.60.2+20.04] (core)
[07:50] -queuebot:#ubuntu-release- Unapproved: snapd (lunar-proposed/main) [2.59.1+23.04ubuntu1.1 => 2.60.2+23.04] (desktop-core, ubuntu-server)
[07:50] -queuebot:#ubuntu-release- Unapproved: snapd (jammy-proposed/main) [2.58+22.04.1 => 2.60.2+22.04] (desktop-core, ubuntu-server)
[07:54] -queuebot:#ubuntu-release- New sync: oem-stella-aron-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:55] -queuebot:#ubuntu-release- New sync: oem-stella-asobo-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:55] -queuebot:#ubuntu-release- New sync: oem-stella-cascoon-rpl-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:55] -queuebot:#ubuntu-release- New sync: oem-stella-kuku-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:56] -queuebot:#ubuntu-release- New sync: oem-stella-romi-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:56] -queuebot:#ubuntu-release- New sync: oem-stella-bergmite-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:56] -queuebot:#ubuntu-release- New sync: oem-stella-chiko-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:57] -queuebot:#ubuntu-release- New sync: oem-stella-graveler-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:57] -queuebot:#ubuntu-release- New sync: oem-stella-sensei-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:58] -queuebot:#ubuntu-release- New sync: oem-stella-yoshio-meta (jammy-proposed/primary) [22.04~ubuntu1]
[07:58] -queuebot:#ubuntu-release- New sync: oem-stella-purrloin-rpl-meta (jammy-proposed/primary) [22.04~ubuntu1]
[08:47] <LocutusOfBorg> hello, why is auto-sync stopped instead of running in dry-run mode? https://ubuntu-archive-team.ubuntu.com/auto-sync/
[09:03] <seb128> LocutusOfBorg, hey, what would dry mode provide? feels like it would waste resources for little benefit?
[09:04] <LocutusOfBorg> I use it, I check all the "new version packages" compare with and what we have in proposed and check one by one if Debian has a patch to make it migrate
[09:05] <LocutusOfBorg> (maybe it can made be run daily or so)
[09:39] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (jammy-proposed) [2.765.24]
[09:42] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.765.23 => 2.765.24] (desktop-core, i386-whitelist)
[09:45] <zhsj> hi, the proposed-migration hasn't been updated for 10 hours. no logs in https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/mantic/2023-08-21/
[09:52] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.765.23 => 2.765.24] (desktop-core, i386-whitelist)
[09:54] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (jammy-proposed) [2.765.24]
[09:55] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.765.24]
[10:00] -queuebot:#ubuntu-release- Unapproved: libfprint (jammy-proposed/main) [1:1.94.3+tod1-0ubuntu2~22.04.04 => 1:1.94.3+tod1-0ubuntu2~22.04.05] (ubuntu-desktop)
[11:38] <cjwatson> seb128: we always used to run it in dry-run mode during freeze periods; my question would be why that process was changed
[11:39] <seb128> cjwatson, ah ok, I didn't know
[11:39] <cjwatson> zhsj: there was a firewall outage overnight; I've killed the stuck job
[15:47] <vorlon> LocutusOfBorg, seb128, cjwatson, sil2100: yes, I've re-enabled auto-sync in --dry-run mode per convention
[15:53] <LocutusOfBorg> thanks!
[15:55] <LocutusOfBorg> vorlon, for sure, obligatory xkcd reference https://xkcd.com/1172/
[15:56] <sil2100> vorlon: we need to update the checklist item then
[15:56] <sil2100> vorlon: since it mentioned 'comment out'
[15:56] <sil2100> vorlon: ...so I did, even though the crontab itself was pointing more to running in dry-run mode
[16:29] <vorlon> sil2100: ack
[16:30] <vorlon> sil2100: whoops AttributeError: 'Config' object has no attribute 'subtree'
[16:30] <vorlon> (ubuntu-server/jammy build failure)
[16:32] <sil2100> WHoops!
[16:32] <sil2100> hmmm
[16:32] <sil2100> Why didn't the tests fail on that?
[16:33] <sil2100> Looking what failed
[16:33] <sil2100> aa, simplestreams
[16:33] <sil2100> Fixing
[16:33] <sil2100> vorlon: no worries, it's just simplestreams, so the builds still succeed
[16:34] <vorlon> ack
[16:39] <sil2100> vorlon: aaaah, ok, this was just a transient issue I think
[16:39] <sil2100> vorlon: I mean, the most likely reason is that it was a build that was already running and I modified the code underneath the build
[16:40] <vorlon> heh ok
[16:40] <sil2100> vorlon: which would explain why it couldn't find config.subtree, as the new simplesteams.py was looking for it
[16:48] <vorlon> zhsj: -Wl,-z,defs > bwahaha
[16:51] <vorlon> cpaelzer: have you made any progress on diagnosing rmadison? I've seen the problem reported elsewhere and also see it myself
=== RAOF_ is now known as RAOF
[21:24] -queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.4.2-0ubuntu6.2 => 2:16.4.2-0ubuntu6.3] (openstack, ubuntu-server)
[21:25] -queuebot:#ubuntu-release- Unapproved: systemd (jammy-proposed/main) [249.11-0ubuntu3.9 => 249.11-0ubuntu3.10] (core, i386-whitelist)
[21:33] -queuebot:#ubuntu-release- Unapproved: docker.io-app (jammy-proposed/universe) [20.10.25-0ubuntu1~22.04.2 => 24.0.5-0ubuntu1~22.04.1] (no packageset)
[21:33] -queuebot:#ubuntu-release- Unapproved: docker.io-app (lunar-proposed/universe) [20.10.25-0ubuntu1~23.04.1 => 24.0.5-0ubuntu1~23.04.1] (no packageset)
[21:37] -queuebot:#ubuntu-release- Unapproved: docker.io-app (focal-proposed/universe) [20.10.25-0ubuntu1~20.04.2 => 24.0.5-0ubuntu1~20.04.1] (no packageset)
[21:42] <liushuyu> Hi release team, I am currently going through the update_excuses page and I found a lot of Node.js packages are failing due to incorrect migration order, where `node-signal-exit` package should be migrated last (it migrated first in our case)
[21:43] <liushuyu> Is there a way to unpublish `node-signal-exit` temporarily before all the other Node.js packages could be migrated first?
[21:47] <vorlon> $ rmadison -s mantic,mantic-proposed -S node-signal-exit
[21:47] <vorlon> $
[21:47] <vorlon> <shakes fist<
[21:47] <vorlon> <shakes fist>
[21:50] <vorlon> liushuyu: can you point me to an example of a package whose autopkgtests fail because of node-signal-exit?
[21:52] <liushuyu> https://launchpadlibrarian.net/683058466/buildlog_ubuntu-mantic-amd64.node-istanbul_0.4.5+repack10+~cs98.25.59-1_BUILDING.txt.gz
[21:52] <liushuyu> Search for "node-signal-exit : Breaks:"
[21:53] <vorlon> ah so it's a build problem not an autopkgtest problem
[21:53] <liushuyu> Oh, it looks like some packages need to rebuild as well
[21:53] <liushuyu> vorlon: It's both a build problem and an autopkgtest problem
[21:54] <vorlon> makes sense; node-signal-exit temporarily removed from mantic-proposed to let other node packages build
[21:54] <vorlon> liushuyu: well autopkgtests don't by default pull other packages from -proposed
[21:56] <vorlon> liushuyu: anyway, removal done, so an uploader can retry the failed builds after the next archive publisher cycle
[21:56] <liushuyu> Okay, I took another look at those packages. It looks like the root cause is that because newer version of `node-istanbul` isn't in the archive
[21:56] <liushuyu> ... which is due to `node-istanbul` was not built
[21:59] <liushuyu> vorlon: Thank you! How should I know the publication is done?
[22:03] <vorlon> liushuyu: check what shows up in the contents of the mantic-proposed Packages file after an apt update
[22:03] <liushuyu> Okay
[22:03] <vorlon> (you should be able to check rmadison... but.)
[22:23] <liushuyu> Okay, now it's unpublished. Can someone retry the build https://launchpad.net/ubuntu/+source/node-istanbul/0.4.5+repack10+~cs98.25.59-1/+build/26523404 ?
[22:23] <liushuyu> The node-tap dependency wait is also caused by node-signal-exit, so the build can't auto-start
[22:28] <vorlon> liushuyu: retried
[22:33] <liushuyu> and failed again. Strange, now node-tap installs fine on my local device (with m-p repository enabled)
[22:43] -queuebot:#ubuntu-release- New sync: rust-gtk-macros (mantic-proposed/primary) [0.3.0-1]
[22:44] -queuebot:#ubuntu-release- New sync: rust-lcms2-sys (mantic-proposed/primary) [4.0.1-1]
[22:44] -queuebot:#ubuntu-release- New sync: rust-libheif-sys (mantic-proposed/primary) [1.14.2-1]
[22:44] -queuebot:#ubuntu-release- New sync: rust-mdns (mantic-proposed/primary) [3.0.0-1]
[22:45] -queuebot:#ubuntu-release- New sync: rust-memfd (mantic-proposed/primary) [0.6.3-1]
[23:01] <vorlon> liushuyu: https://launchpadlibrarian.net/683081033/buildlog_ubuntu-mantic-amd64.node-istanbul_0.4.5+repack10+~cs98.25.59-1_BUILDING.txt.gz shows:
[23:01] <vorlon>  node-foreground-child : Depends: node-signal-exit (>= 4) but 3.0.7+~3.0.1-1 is to be installed
[23:01] <vorlon>  node-write-file-atomic : Depends: node-signal-exit (>= 4) but 3.0.7+~3.0.1-1 is to be installed
[23:01] <vorlon> and that's the version you just had me remove
[23:02] <vorlon> do we need to sync a different version of node-signal-exit >= 4 and < 4.1?
[23:02] <liushuyu> Those are in -proposed as well, let me check
[23:02] <vorlon> the breaks: was added in 4.1.0-4 in Debian
[23:04] <liushuyu> Okay, so Debian did the bootstrap process between -3 and -4
[23:04] <liushuyu> so what should we do in this case?
[23:05] <liushuyu> upload a -3 first, migrate the others and then upgrade to -5?
[23:20] <vorlon> we can sync -3 first yes
[23:24] <liushuyu> Then let's try this route
[23:25] <vorlon> liushuyu: sync triggered
[23:25] <liushuyu> vorlon: Thanks!