[01:47] <blackboxsw> sil2100 woot! figured it'd be worth catching you with a request :)
[03:22] -queuebot:#ubuntu-release- New sync: oem-somerville-gendry-meta (focal-proposed/primary) [20.04~ubuntu1]
[07:12] <jamespage> bdmurray: hey - could we get the focal update for ceph thats in proposed released to updates today?
[07:12] <jamespage> https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1933410
[07:12] <jamespage> would be good to get that clear this week if possible
[08:00] -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (hirsute-proposed/main) [3.38.1-3ubuntu3 => 3.38.1-3ubuntu3.1] (ubuntu-desktop)
[08:07] -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (focal-proposed/main) [3.36.1-0ubuntu1 => 3.36.1-0ubuntu1.1] (ubuntu-desktop)
[08:16] -queuebot:#ubuntu-release- Unapproved: shadow (hirsute-proposed/main) [1:4.8.1-1ubuntu8 => 1:4.8.1-1ubuntu8.1] (core, i386-whitelist)
[08:20] -queuebot:#ubuntu-release- Unapproved: shadow (focal-proposed/main) [1:4.8.1-1ubuntu5.20.04 => 1:4.8.1-1ubuntu5.20.04.1] (core, i386-whitelist)
[09:33] -queuebot:#ubuntu-release- Unapproved: shim (focal-proposed/main) [15.4-0ubuntu5 => 15.4-0ubuntu7] (core) (sync)
[09:33] -queuebot:#ubuntu-release- Unapproved: shim (hirsute-proposed/main) [15.4-0ubuntu5 => 15.4-0ubuntu7] (core) (sync)
[09:33] <juliank> sil2100: could you approve the signing tarball for shim in impish?
[09:34] <juliank> * tarballs
[09:34] -queuebot:#ubuntu-release- Unapproved: shim (bionic-proposed/main) [15+1552672080.a4a1fbe-0ubuntu2 => 15.4-0ubuntu7] (core) (sync)
[09:58] -queuebot:#ubuntu-release- Unapproved: shim (xenial-proposed/main) [15.4-0ubuntu5 => 15.4-0ubuntu7] (core) (sync)
[10:28] -queuebot:#ubuntu-release- New: accepted oem-somerville-gendry-meta [sync] (focal-proposed) [20.04~ubuntu1]
[10:31] -queuebot:#ubuntu-release- New binary: oem-somerville-gendry-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[10:36] -queuebot:#ubuntu-release- New: accepted oem-somerville-gendry-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[10:51] <sil2100> juliank: done o/
[10:52] <juliank> sil2100: thanks!
[12:16] <schopin> Hi there :) Is there an archive admin that could look at and possibly unblock the s390-tools-signed upload ?
[12:27] <sil2100> schopin: hello! Is it an SRU, or for impish?
[12:27] <sil2100> Ok, I saw some binary in the NEW queue, approved that for now
[12:28] -queuebot:#ubuntu-release- New: accepted s390-tools [s390x] (impish-proposed) [2.17.0-0ubuntu1]
[12:31] <schopin> sil2100: thanks :)
[13:44] <jawn-smith> sil2100: can we turn on unmatched daily builds for focal?
[13:53] -queuebot:#ubuntu-release- Unapproved: shim-signed (focal-proposed/main) [1.40.5 => 1.40.6] (core)
[13:54] -queuebot:#ubuntu-release- Unapproved: shim-signed (focal-proposed/main) [1.40.5 => 1.40.6] (core)
[13:55] <juliank> ^ first shim-signed 1.40.6 did not get -v passed during changelog, so reuploaded
[14:03] <juliank> cjwatson: something odd seems to be going on, sil2100 accepted (in impish) shim signing tarballs ~3hours ago for both amd64 and arm64, but arm64 are still not published
[14:03] <juliank> I think we had this before
[14:03] <cjwatson> juliank: will get back to you after this meeting
[14:09] <xnox> laney:  juliank: vorlon: is there NBS report for -proposed ? aka old binaries left.
[14:10]  * juliank leaves that to AAs
[14:12] <xnox> i thought it was https://people.canonical.com/~ubuntu-archive/NBS/ over here.... but that's empty
[14:13] <seb128> there isn't afaik, but that would be handy since those are a reason for things not migrating
[14:13] <laney> not as far as I know
[14:13] <laney> usually it's reported on excuses in a more or less cryptic fashion
[14:14] <xnox> i'll try to make something. cause at the moment all of kernels are stuck because of that.
[14:23] -queuebot:#ubuntu-release- Unapproved: sosreport (hirsute-proposed/main) [4.1-1ubuntu1.1 => 4.1-1ubuntu1.2] (ubuntu-desktop, ubuntu-server)
[14:38] -queuebot:#ubuntu-release- Unapproved: sosreport (groovy-proposed/main) [4.1-1ubuntu0.20.10.2 => 4.1-1ubuntu0.20.10.3] (ubuntu-desktop, ubuntu-server)
[14:50] -queuebot:#ubuntu-release- Unapproved: sosreport (focal-proposed/main) [4.1-1ubuntu0.20.04.2 => 4.1-1ubuntu0.20.04.3] (ubuntu-desktop, ubuntu-server)
[14:57] <cjwatson> juliank: So where were you looking for the signing tarballs?
[14:58] <juliank> cjwatson: So the build log says:
[14:58] <juliank> https://launchpadlibrarian.net/548571056/buildlog_ubuntu-impish-amd64.shim-signed_1.49_BUILDING.txt.gz
[14:58] <juliank> https://launchpadlibrarian.net/548571056/buildlog_ubuntu-impish-amd64.shim-signed_1.49_BUILDING.txt.gz
[14:58] <cjwatson> I wonder if you made the same mistake I did when first looking
[14:58] <juliank> um
[14:58] <juliank> Downloading http://ftpmaster.internal/ubuntu/dists/impish/main/signed/shim-amd64/current/signed.tar.gz ... found
[14:58] <juliank> Extracting 15.4-0ubuntu5 ...
[14:58] <juliank> I tried from an instance in scalingstack (stg-proposed-migration) and got the right one, before that build:
[14:58] <juliank> $ curl -s http://ftpmaster.internal/ubuntu/dists/impish/main/signed/shim-arm64/current/signed.tar.gz | tar tz  | head -1
[14:58] <juliank> 15.4-0ubuntu7/
[14:59] <juliank> hmm wrong build log
[14:59] <juliank> but same idea :D
[14:59] <juliank> So it seems to be there on anonster, but then it still downloads the old one on the builder, so is there a proxy in between with caching?
[15:00] <juliank> The right log is at https://launchpadlibrarian.net/548598797/buildlog_ubuntu-impish-arm64.shim-signed_1.49_BUILDING.txt.gz
[15:00] <cjwatson> Not on amd64
[15:00] <juliank> cjwatson: Right, amd64 fetch was OK, arm64 one is broken/delayed
[15:00] <juliank> cjwatson: I typoed at the top :)
[15:01] <cjwatson> OK, so there is a proxy for bos02 builds
[15:01] <cjwatson> It's part of the LFP mitigations for running builds on the wrong side of the Atlantic
[15:01] <cjwatson> It might be a good idea to have the download script send cache-busting headers
[15:01] <cjwatson> "Pragma: no-cache" at least
[15:02] <juliank> it knows the version, so why it requests current/ instead of version/ is another topic
[15:02] <cjwatson> Or else fetch by version, indeed
[15:02] <cjwatson> If it fetched by version then it would probably just work
[15:02] <juliank> maybe there is an issue with encoding of ~ or something
[15:03] <cjwatson> I wouldn't have thought so
[15:03] <cjwatson> It may just have been based on previous code that didn't know the version ...
[15:03] <cjwatson> (The mistake I made when first looking for whether it was published was to look on archive.ubuntu.com, which caused me to scratch my head for a bit until I realized I needed to look at ports.ubuntu.com in this case)
[15:04] <cjwatson> https://wiki.canonical.com/InformationInfrastructure/ISO/ScalingStack#BOS01.2FBOS02_LFP_workaround (internal only) if you want the sad story of why the proxy is there
[15:05]  * cjwatson files a bug on universe: c is too small
[15:05] <juliank> cjwatson: the archive.u.c thing also confused me for a bit, yes :D
[15:05] -queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [4.1-1ubuntu0.18.04.2 => 4.1-1ubuntu0.18.04.3] (ubuntu-desktop, ubuntu-server)
[15:08] -queuebot:#ubuntu-release- New: accepted libmbim [amd64] (focal-proposed) [1.24.8-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libmbim [armhf] (focal-proposed) [1.24.8-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libmbim [ppc64el] (focal-proposed) [1.24.8-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libmbim [s390x] (focal-proposed) [1.24.8-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libqmi [arm64] (focal-proposed) [1.28.6-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libqmi [i386] (focal-proposed) [1.28.6-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libqmi [riscv64] (focal-proposed) [1.28.6-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libmbim [arm64] (focal-proposed) [1.24.8-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libmbim [riscv64] (focal-proposed) [1.24.8-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libqmi [armhf] (focal-proposed) [1.28.6-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libqmi [s390x] (focal-proposed) [1.28.6-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libmbim [i386] (focal-proposed) [1.24.8-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libqmi [ppc64el] (focal-proposed) [1.28.6-1~20.04]
[15:08] -queuebot:#ubuntu-release- New: accepted libqmi [amd64] (focal-proposed) [1.28.6-1~20.04]
[15:15] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (focal-proposed) [1.40.6]
[15:27] -queuebot:#ubuntu-release- New: accepted ceph [amd64] (impish-proposed) [16.2.5-0ubuntu2]
[15:33] <sil2100> juliank: oh my aptdaemon ADT tests in hirsute started failing in release, huh
[15:33] <juliank> sil2100: they are fairly flake
[15:33] <juliank> * flaky
[15:36] <xnox> sil2100:  without https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/1936370 we cannot roll kernel to v5.11 in focal for the point release.
[15:38] <juliank> ooh that's the parser bug in aptdaemon
[15:38] <juliank> sil2100: so it fails because the ubuntu-advantge-tools config file for apt is missing ;
[15:39] <juliank> sil2100: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1930741
[15:40] <juliank> maybe ping server to fix it
[15:42] <bdmurray> juliank: I think there is a u-a-t SRU in the queue already
[15:42] <juliank> hopefully it fixes it
[15:42] <juliank> it does, but the bug isn't mentioned in the changelog :/
[15:42] <juliank> (or the change for that matter)
[15:43] <bdmurray> +  * Cherrypick upstream pr #1681 to unbreak many migrations. LP: #1930741
[15:48] <juliank> ooh down there
[16:35] <sil2100> xnox: oh shit, lovely
[16:46] <blackboxsw> hrm, yes we have a xnox's fix queued for 1930741 in the current u-a-t upload that is awaiting -proposed
[16:49] <blackboxsw> juliank: thank you for adding the missing "regression-update" tag, it prompted me to read about the meaning.https://wiki.ubuntu.com/StableReleaseUpdates#Regressions
[17:15] <sil2100> Will review that in a moment!
[18:08] <sil2100> blackboxsw: hey! Reviewing ubuntu-advantage-tools right now
[18:09] <blackboxsw> excellent sil2100~
[18:09] <sil2100> Looking at the debian/control changes, any reason why the "| distro-info (= 0.14ubuntu0.2)" dep is = and not the usual >=? I know xenial is frozen basically, but what if there's a new distro-info package pushed?
[18:11] <sil2100> blackboxsw: ^
[18:11] <blackboxsw> sil2100 re-reading that commit and the original Bug now
[18:15] <sil2100> Since I can understand why the versioned dep and why the | alternative has been given, but I think it's not correct to hard-depend on another package who's version can change with security updates
[18:16] <sbeattie> we have pushed distro-info updates to the ESM archives, IIRC.
[18:17] <sbeattie> or at least the data files.
[18:19] <blackboxsw> sil2100 I think the issue here is that on Bionic for instance we need to require at least (>= 0.18ubuntu0.18.04.1)
[18:20] <blackboxsw> if we don't match that contraint on bionic, but bionic distro-info is at  0.18 we would still match the 2nd clause
[18:20] <blackboxsw> via the match >= 0.14ubuntu0.2
[18:20] <blackboxsw> so maybe it's worth a conflicts 0.18 clause?
[18:21] <blackboxsw> to make sure a too old bionic distro-info is disallowed ?
[18:21] <sil2100> blackboxsw: yeah, I think in this case that seems more appropriate, as otherwise we force u-a-t to need a re-upload everytime a new distro-info is released
[18:26] <sil2100> Anyway, I'll reject it for now, since as-is this doesn't feel like the right way to solve this!
[18:26] <blackboxsw> sil2100: I'm not really sure how we'd express that in debian/control?   a new Conflicts: ubuntu-distri (=0.18)   ?
[18:27] <blackboxsw> I just don't want to reject installation  on anything but known difficient ubuntu-distro
[18:33] <sil2100> hm, wonder if maybe The dep for >= 0.18ubuntu0.18.04.1 + a Breaks or Conflicts < 0.14ubuntu0.2 would do the trick?
[18:36] <blackboxsw> basically, I'm not sure how to properly express  Requires: distro-info (>= 0.18ubuntu0.18.04.1) | distro-info (>= 0.14ubuntu0.2 && < 0.18)    .... yeah
[18:36] <lucasmoura> sorry sil2100, I may be missing something, but if the dep is >= 0.18ubuntu0.18.04.1, wouldn't we fail on xenial ?
[18:37] <lucasmoura> Also, since we have new versions of that package published to esm, is there any situation were we would upload a new version of that package directly into updates/security ?
[18:37] <blackboxsw> "wouldn't we fail on xenial" ... we would not match that dep on xenial so safe on the first part.... but if xenial bumps to a version 0.14ubuntu0.3 then ua-tools would also not match/succeed to meet the requires declaration
[18:38] <lucasmoura> that's fair, my only doubt here is if that update is feasible
[18:38] <lucasmoura> since it seems we are now uploading that package into the esm pocket
[18:38] <blackboxsw> lucasmoura: sbeattie mentioned above that they have uploaded distro-info to esm archives before. so it's possible that a xenial upgrade on distro-info can/will occur
[18:39] <blackboxsw> "we have pushed distro-info updates to the ESM archives, IIRC.... or at least the data files"
[18:39] <lucasmoura> oh, I thought this meant we were updating it on the esm pocket only now
[18:39] <lucasmoura> If not, my mistake here
[18:43] <blackboxsw> if updated in distro-info is updated in esm pocket... new ua-tools would fail to install on xenial if distro-info goes > 0.14ubuntu0.2. which is an "if" but it could happen. In that case our strict requires will break and disallow either ua-tools or distro-info from being installed
[18:50] <blackboxsw> sil2100: what do you think about us generating a xenial-only SRU that would make that contraint flexible at just Requires: distro-info (>= >= 0.14ubuntu0.2) I think the problem comes from us trying to share the same debian/control on all releases
[18:50] <blackboxsw> that way we can reject just the xenial SRU and sort the proper/specific deb/control for that release
[18:55] <blackboxsw> "hm, wonder if maybe The dep for >= 0.18ubuntu0.18.04.1 + a Breaks or Conflicts < 0.14ubuntu0.2 would do the trick?" Hrm.... the problem with only expressing >= 0.18ubuntu0.18.04.1 is that Xenial will not have a deb match clause that could be met as xenial-updates currently sits at 0.14ubutu0.2.
[19:39] <sil2100> blackboxsw: sorry, yeah, I'm a bit AFKish now but yes, if that's acceptable from your POV that's best, as this is how we do it for all other projects - per-series delta
[19:39] <sil2100> So I would love that the most actually
[19:40] <blackboxsw> +1 sil2100 thanks let's reject Xenial, and we are talking about uploading to X ua-t with a specific xenial-only d/control file since we keep bumping against this complexity problem
[19:40] <blackboxsw> We'll put up another xenial upload with this fix so we don't have to deal with that X > 0.14 and B > 0.18 ranges
[19:41] <blackboxsw> and we'll work toward separation of d/control, on B and greater in future releases
[20:29] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (xenial-proposed) [27.2~16.04.1]
[20:57] -queuebot:#ubuntu-release- Unapproved: rejected dwarves-dfsg [sync] (groovy-proposed) [1.21-0ubuntu1~ubuntu20.10.1]
[20:57] -queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (groovy-proposed) [3.38.3-2ubuntu0.20.10.1]
[20:57] -queuebot:#ubuntu-release- Unapproved: rejected libbpf [sync] (groovy-proposed) [0.4.0-1ubuntu1~ubuntu20.10.1]
[20:57] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (groovy-proposed) [4.1-1ubuntu0.20.10.3]
[21:38] <vorlon> xnox: right, no NBS for -proposed, just gets worked out via update_excuses