[09:21] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.15.14 => 20.04.15.15] (core)
[09:45] <seb128> tjaalton, hey, could you review bug #1934439 (SRU uploads to focal and bionic). Do we need an upload to impish if the feature actually only makes sense on LTS series? (no livepatch on non LTS)
[09:56] -queuebot:#ubuntu-release- Unapproved: shim-signed (hirsute-proposed/main) [1.48 => 1.49] (core) (sync)
[10:18] -queuebot:#ubuntu-release- Unapproved: rejected gnome-settings-daemon [source] (hirsute-proposed) [3.38.1-3ubuntu3.1]
[10:18] -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (hirsute-proposed/main) [3.38.1-3ubuntu3 => 3.38.1-3ubuntu3.1] (ubuntu-desktop)
[10:20] -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (focal-proposed/main) [3.36.1-0ubuntu1 => 3.36.1-0ubuntu1.1] (ubuntu-desktop)
[11:00] <juliank> sil2100, tjaalton: can one of you do me a favor and approve the shim binary copies for all (hirsute+LTS) releases (and the signing tarballs after that?); I want to have the signing tarballs in place a bit before uploading the shim-signed, so they don't FTBFS trying to fetch them
[11:01] <juliank> oh well, I binary-copied shim-signed to hirsute, that one is OK too :D
[11:01] <juliank> But the  focal upload will ftbfs for a day if uploaded too early :)
[11:02] <juliank> (same for bionic/xenial)
[11:02] <juliank> I'll fix that next round (download-signed downloads signing tarball from current/ symlink and that gets cached for multiple hours)
[11:02] <juliank> but I don't want to respin now
[11:08] <juliank> or well, maybe I should respin, it's not accepted yet anyway, but I'
[11:10] <juliank> let me respin that
[11:36] -queuebot:#ubuntu-release- Unapproved: shim-signed (focal-proposed/main) [1.40.5 => 1.40.6] (core)
[11:36] <juliank> please reject the shim-signed/focal 1.40.6 from _yesterday_, I reuploaded :D
[12:08] -queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.8 => 1.37~18.04.9] (core)
[12:10] -queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.9 => 1.33.1~16.04.10] (core)
[12:15] -queuebot:#ubuntu-release- Unapproved: shim-signed (hirsute-proposed/main) [1.48 => 1.50] (core) (sync)
[12:16] <juliank> sorry, reuploading shim-signed/xenial with more complete .changes file
[12:17] -queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.9 => 1.33.1~16.04.10] (core)
[12:32] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (hirsute-proposed/universe) [20.04.0+git20200908-5build1 => 20.04.0+git20200908-6~ubuntu21.04.1] (ubuntu-desktop)
[13:20] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (focal-proposed/main) [20.04.0-3~ubuntu20.04.1 => 20.04.0-3~ubuntu20.04.2] (ubuntu-desktop)
[13:31] <sil2100> juliank: ok, on it!
[13:31] <sil2100> tjaalton: ^
[13:42] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons-ng (hirsute-proposed/main) [0.15.0-0ubuntu4.1 => 0.15.0-0ubuntu4.2] (no packageset)
[14:14] <seb128> sil2100, if you do SRU reviews could you perhaps check the one Imentioned earlier? bug #1934439 for which I also had a question on whether we need to land something in impish or if that's not needed since the change is only making sense for LTS series
[14:30] -queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.4.0-0ubuntu1 => 2:16.4.0-0ubuntu2] (openstack, ubuntu-server)
[14:33] <icey> it would be very much appreciated if the version of Neutron in focal-proposed be superceded by the version just uploaded :)
[15:06] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [sync] (hirsute-proposed) [1.49]
[15:11] <bdmurray> seb128: re bug 1934439 I think adding it to Impish makes sense so we have it ready for J.
[15:11] -queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (hirsute-proposed) [15.4-0ubuntu7]
[15:12] <bdmurray> I'll review neutron later today
[15:12] <seb128> bdmurray, agreed but Robert argued that the current implementation will be deprecated before J so that it doesn't make sense
[15:13] <seb128> bdmurray, anyway if someone from the SRU team would comment on the bug to state one way or the other so we are sure to not block the SRU that would be nice
[15:14] <icey> thanks bdmurray
[15:15] <bdmurray> seb128: I don't see anything about "will be deprecated" rather comment #11 mentions "it will be replaced at some point"
[15:15] <seb128> bdmurray, that's what I meant
[15:16] <bdmurray> okay, I'll think about it and comment on the bug
[15:16] <seb128> bdmurray, thanks
[15:16] <seb128> either way is fine, I just want Robert to upload to impish if that's going to block the SRU
[15:16] <seb128> and he's arguing with me so maybe he will listen to someone from the SRU team ;)
[15:16] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (hirsute-proposed) [1.50]
[15:20] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (focal-proposed) [1.40.6]
[15:22] -queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (focal-proposed) [15.4-0ubuntu7]
[15:27] <juliank> sil2100: ^ what went on there, that's a binary copy from impish (which got binary copied from hirsute ppa), as is hirsute
[15:27] <juliank> or did I forget -b for this one?
[15:28] <juliank> Also why does launchpad queue say "Accepted 6 minutes ago by Łukasz Zemczak" - it's confused :D
[15:29] <sil2100> Uh
[15:29] <sil2100> Yeah, something wrong went with this upload, I accepted it and was awaiting for the signed binaries to appear
[15:29] <sil2100> ...and they didn't
[15:29] <sil2100> Accept the package into -proposed? [yN] y
[15:29] <sil2100> Accepted
[15:30] <sil2100> I have no idea what happened!
[15:30] <juliank> maybe signing service crashed :D
[15:31] <sil2100> cjwatson: hey! Could you maybe help out? I accepted a bin-copy of shim into focal-proposed, but it seems like Launchpad is a bit confused? I don't see the signing tarballs, queuebot mentioned it as rejected but LP says it's accepted
[15:31] <juliank> email says: shim 15.4-0ubuntu7 in impish (same version has unpublished binaries in the destination archive for Hirsute, please wait for them to be published before copying)
[15:31] <juliank> which is odd, they are all published in impish
[15:32] <cjwatson> I'm very nearly EOW, not sure I'll have time right now
[15:33] <cjwatson> But from https://launchpad.net/ubuntu/+source/shim/+publishinghistory it looks like there's a successful publication in hirsute-proposed
[15:33] <juliank> Shall we try copying over it again?
[15:33] <cjwatson> Why?  It seems to be published
[15:33] <juliank> The signing tarballs don't appear
[15:34] <cjwatson> The rejection you're talking about was for focal-proposed
[15:34] <juliank> ah yes
[15:34] <juliank> but it's listed as accepted on the list of rejected stuff
[15:35] <cjwatson> The copier seems a bit cross about you trying to copy to both hirsute-proposed and focal-proposed in the same publisher run, not sure why, but you should be able to solve that by waiting for a publisher run
[15:35] <juliank> makes sense
[15:36] <cjwatson> Maybe the accepted/rejected logging goes a bit wrong if the queue entry is a copy and then the copy fails; it's possible we never tested that edge case
[15:36] <cjwatson> You should be able to try accepting from the rejected queue again once the hirsute-proposed publication has completed
[15:36] <cjwatson> Which I think it has now
[15:36] <juliank> sil2100: ^
[15:37] <cjwatson> And ubuntu/dists/hirsute-proposed/main/signed/shim-{amd64,arm64}/15.4-0ubuntu7 exists on ftpmaster.internal
[15:38] <cjwatson> No signing service issue AFAICS
[15:39] <juliank> yeah we just got confused by focal accepted/rejected superposition :D
[15:40] <juliank> "cat state" apparently is the proper team
[15:41] <sil2100> \o/ Thanks!
[15:43] <sil2100> uh, "FAILED: shim (Can't resurrect rejected syncs)"
[15:43] <sil2100> juliank: guess can you bin-sync it again?
[15:44] -queuebot:#ubuntu-release- Unapproved: shim (focal-proposed/main) [15.4-0ubuntu5 => 15.4-0ubuntu7] (core) (sync)
[15:44] <juliank> sil2100: ^ there you go
[15:44] <sil2100> THanks! I'll just press accept on it now and hope for the best!
[15:45] -queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (focal-proposed) [15.4-0ubuntu7]
[15:51] -queuebot:#ubuntu-release- Unapproved: broadcom-sta (focal-proposed/multiverse) [6.30.223.271-12 => 6.30.223.271-12ubuntu0.1] (kernel-dkms)
[15:57] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.4.0-0ubuntu2]
[16:07] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (focal-proposed) [1.40.6]
[18:02] <blackboxsw> sil2100: on further discussion with the team yesterday about ua-tools and better Xenial distro-info support,  we realized we didn't actually need distro-info as a Build-Depends. This gives us a chance to use substvars via debian/rules to set Xenial Depends: "distro-info  (>= 0.14ubuntu0.2)" and Bionic or later as (>= 0.18ubuntu0.18.04.1)
[18:02] <blackboxsw> https://github.com/canonical/ubuntu-advantage-client/commit/4d35b5c4445dc6dba28f7daa3f11ba8c212ea6b2
[18:03] <blackboxsw> so we are queueing new SRU uploads of ua-tools 27.2....2  for all series after our upload to impish is complete. Probably past your EOW though
[18:16] <bdmurray> blackboxsw: nice
[18:17] <blackboxsw> :) thx, just wanted to raise that point as it slightly diverged from how my conversation ended w/ sil yesterday
[19:35] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (xenial-proposed/main) [27.1~16.04.1 => 27.2.1~16.04.1] (no packageset)
[19:36] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (bionic-proposed/main) [27.1~18.04.1 => 27.2.1~18.04.1] (core)
[19:38] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (focal-proposed/main) [27.1~20.04.1 => 27.2.1~20.04.1] (core)
[19:39] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (hirsute-proposed/main) [27.1~21.04.1 => 27.2.1~21.04.1] (core)
[19:43] <blackboxsw> Hey folks, any SRU vanguard around that might be able to take a look at ubuntu-advantage-tools uploads in the unapproved queue for X,B,F,H?  we have some fixes in there that would be helpful in mitigating foundation's autopkg test failures per https://launchpad.net/bugs/1930741, which may unblock some of x-nox's kernel SRUs into focal
[19:46] <blackboxsw> Hey folks, any SRU vanguard around that might be able to take a look at ubuntu-advantage-tools uploads in the unapproved queue for X,B,F,H?  We have some fixes in there that would be helpful in mitigating foundation's autopkg test failures per https://launchpad.net/bugs/1930741, which may unblock some of x-nox's kernel SRUs into focal.
[19:48] <blackboxsw> our SRU process bug is https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1934902 and was originally rejected on Xenial by sil2100 for a too strict Depends:  distro-info (=0.14ubuntu0.2)  instead of (>=0.14ubuntu0.2).
[19:49] <vorlon> blackboxsw: looking (though, autopkgtest regressions in -updates are meant to not block SRUs, they just need hinting FTR)
[19:49] <blackboxsw> we have mitigated that review concern using debian/rules and substvars for injecting only Xenial-specific Depends or Bionic++ depends
[19:49] <blackboxsw> +1 vorlon thanks for the context. I just don't like adding undue burden to what Foundations already does :/
[19:50] <vorlon> I see hirsute-proposed has multiple uat uploads in it, you want me to jettison the previous one?
[19:50] <vorlon> blackboxsw: also ftr, xnox is kernel team now, not foundations ;)
[19:50] <blackboxsw> please hirsute bionic and focal all have dupes  from yesterday
[19:51] <bdmurray> he's been disavowed
[19:51] <blackboxsw> vorlon: and ack on xnox. yeah.... once foundations always foundations.... you can change a team but not the heart :)
[19:51] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (hirsute-proposed) [27.2~21.04.1]
[19:52] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (bionic-proposed) [27.2~18.04.1]
[19:52] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (focal-proposed) [27.2~20.04.1]
[19:52] <blackboxsw> thx again, and for our process we will be following the template https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates for or verification/review of all changes
[19:55] <vorlon> which has still not been ratified as an official sru policy exception, blocked on me, cough ;)
[19:58] <blackboxsw> ..... didn't really want point that out so publicly :)
[19:58] <blackboxsw> though we've also passed this through rbasak too in the same sort of light
[19:58] <blackboxsw> needs some sort of formal review "sometime" on the process
[19:58] <vorlon> yeah well this is as good a time as any
[19:59] <blackboxsw> not only on the hook for a full SRU review, but a process exception review.... we keep you busy
[20:01] <vorlon> blackboxsw: I want to suggest that the CI should explicitly cover not just LTS to LTS upgrades, but also taking a ua action after upgrade; thoughts?
[20:02] <blackboxsw> vorlon: you me B attached; upgrade to  F ; ua enable/disable something; assert success?
[20:02] <vorlon> yes
[20:02] <blackboxsw> *you mean
[20:02] <vorlon> and also for the B unattached case
[20:03] <blackboxsw> vorlon: +1 we can add that to our verifcation on this SRU (and the docs right now)(
[20:04] <blackboxsw> we perform a very non-intrusive check across upgrade: https://github.com/canonical/ubuntu-advantage-client/blob/main/features/ubuntu_upgrade.feature#L62-L66
[20:04] <blackboxsw> but can perform a state changing operation
[20:05] <blackboxsw> and will add unattached upgrade case too
[20:05] <vorlon> blackboxsw: ok.  I've made some minor changes to https://wiki.ubuntu.com/StableReleaseUpdates, please let me know if you have concerns; but with that + the above addition to verification, approval from me as a standing exception
[20:08] <blackboxsw> vorlon: "and appropriate separate test cases provided" +1 that makes sense will specifically add that to the SRU verification responsibilities for this round
[20:09] <blackboxsw> .... for packaging changes/deps changes etc  ^
[22:03] <xnox> vorlon:  blackboxsw: all I did is unblock _kernel_ migrations which showed adt regressions due to u-a-t being buggy. hence that upload from me to devel-proposed.... it was strictly +1 maintainance driven upload =)
[22:05] <blackboxsw> ahh roger. makes sense. I was just uncertain about the overall impact in general since the original bug on impish was considered "Critical" Per 1930741
[22:05] <blackboxsw> which is not strictly related to the kernel migrations I assume