[00:18] doko, infinity - it built \o/ i guess something somewhere were fixed. [00:35] -queuebot:#ubuntu-release- New binary: deal.ii [amd64] (bionic-proposed/universe) [8.5.1-1] (no packageset) [00:46] slangasek: there's a typo in your cinnamon-desktop hint [00:49] ("force-badtest cinammon-desktop/3.6.2-1" should probably be "force-badtest cinnamon-desktop/3.6.2-1") [02:28] -queuebot:#ubuntu-release- New binary: deal.ii [arm64] (bionic-proposed/universe) [8.5.1-1] (no packageset) [02:35] xnox: maybe we can drop it. or keep the infrastructure and build a python3 package instead [02:36] -queuebot:#ubuntu-release- New: accepted mate-desktop [amd64] (bionic-proposed) [1.20.1-0ubuntu1] [02:36] -queuebot:#ubuntu-release- New: accepted mate-desktop [armhf] (bionic-proposed) [1.20.1-0ubuntu1] [02:36] -queuebot:#ubuntu-release- New: accepted mate-desktop [ppc64el] (bionic-proposed) [1.20.1-0ubuntu1] [02:36] -queuebot:#ubuntu-release- New: accepted python-gitlab [sync] (bionic-proposed) [1:1.3.0-1] [02:36] -queuebot:#ubuntu-release- New: accepted mate-desktop [arm64] (bionic-proposed) [1.20.1-0ubuntu1] [02:36] -queuebot:#ubuntu-release- New: accepted mate-desktop [s390x] (bionic-proposed) [1.20.1-0ubuntu1] [02:36] -queuebot:#ubuntu-release- New: accepted mate-desktop [i386] (bionic-proposed) [1.20.1-0ubuntu1] [02:37] -queuebot:#ubuntu-release- New: accepted libnatpmp [amd64] (bionic-proposed) [20150609-2] [02:37] -queuebot:#ubuntu-release- New: accepted libnatpmp [armhf] (bionic-proposed) [20150609-2] [02:37] -queuebot:#ubuntu-release- New: accepted libnatpmp [ppc64el] (bionic-proposed) [20150609-2] [02:37] -queuebot:#ubuntu-release- New: accepted libnatpmp [arm64] (bionic-proposed) [20150609-2] [02:37] -queuebot:#ubuntu-release- New: accepted libnatpmp [s390x] (bionic-proposed) [20150609-2] [02:37] -queuebot:#ubuntu-release- New: accepted libnatpmp [i386] (bionic-proposed) [20150609-2] [02:37] -queuebot:#ubuntu-release- New: accepted atril [amd64] (bionic-proposed) [1.20.1-0ubuntu1] [02:37] -queuebot:#ubuntu-release- New: accepted atril [armhf] (bionic-proposed) [1.20.1-0ubuntu1] [02:37] -queuebot:#ubuntu-release- New: accepted atril [ppc64el] (bionic-proposed) [1.20.1-0ubuntu1] [02:37] -queuebot:#ubuntu-release- New: accepted atril [arm64] (bionic-proposed) [1.20.1-0ubuntu1] [02:37] -queuebot:#ubuntu-release- New: accepted atril [s390x] (bionic-proposed) [1.20.1-0ubuntu1] [02:37] -queuebot:#ubuntu-release- New: accepted atril [i386] (bionic-proposed) [1.20.1-0ubuntu1] [02:40] -queuebot:#ubuntu-release- New binary: python-gitlab [amd64] (bionic-proposed/none) [1:1.3.0-1] (no packageset) [02:43] -queuebot:#ubuntu-release- New: accepted python-gitlab [amd64] (bionic-proposed) [1:1.3.0-1] [02:57] -queuebot:#ubuntu-release- New binary: wxpython4.0 [s390x] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset) [03:08] -queuebot:#ubuntu-release- New binary: wxpython4.0 [ppc64el] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset) [03:29] -queuebot:#ubuntu-release- New binary: wxpython4.0 [i386] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset) [03:30] -queuebot:#ubuntu-release- New binary: wxpython4.0 [amd64] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset) [03:38] jbicha: fixed thanks [04:10] -queuebot:#ubuntu-release- New binary: wxpython4.0 [armhf] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset) [04:11] -queuebot:#ubuntu-release- New binary: wxpython4.0 [arm64] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset) [08:09] -queuebot:#ubuntu-release- New binary: bpfcc [amd64] (bionic-proposed/universe) [0.5.0-5ubuntu1] (no packageset) [08:27] doko, it built fine =) so onto more important things, like python2.7 failing autopkgtests with openssl 1.1.1 and tls1.3 [08:28] slangasek, freeipa is a "regression" due to unable to find the source package in release pocket.... maybe it needs hinting over? [08:28] slangasek, or did you mean for freeipa to get stuck in bionic-proposed? [08:33] nacc, is the new nodejs likely to land? or who is working on landing it? [08:34] ginggs, tsimonq2 - are you working on landing the new nodejs? [08:37] slangasek, puma too -> i am not sure why they are "regressions" if they do not exist in release pocket. Unless that is correct behaviour. [09:29] xnox, tsimonq2: aye [09:31] xnox, taking puma as an example, it used to pass its tests and no longer does, how is that not a regression -- regardless of which pocket it is in [09:31] i assume it has been demoted to -proposed somewhen which is how we have this combination [09:32] apw, right, in the bileto silo the autopkgtests are a lot more weird "source not found puma" i assume, since it looks into release pocket only. [09:33] xnox, that does not seem correct, if you build in a PPA for devel should you not be building against proposed still ? [09:33] else the binaries you produce are not suitable for copying to -proposed in bionic [09:33] apw, i do build against proposed, but the autopkgtests for the bileto silo, trigger the tests right; but not the right pockets - e.g. against release pocket only. [09:33] with openssl from the bileto ppa [09:34] which perhaps is correct, ok ... so ? [09:34] but not adding -proposed for packages that only exist in proposed [09:34] ok so the issue is we are testing things which are not in -release only using release [09:34] but then it claims regression =) when puma has not regressed in release pocket, because of new openssl in the PPA, since puma does not exist in the release pocket =) [09:34] let me get the url again [09:35] https://bileto.ubuntu.com/excuses/3217/bionic.html [09:35] so we should not be testing things not in -release, if we are testing only against release [09:35] 404 [09:35] freeipa is one of these things - W: Unable to locate package freeipa [09:35] bah [09:36] i was looking at a cached version, now refreshed, now i get 404 as well [09:36] quality in the making and no mistake [09:36] apw, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3217-excuses/2018-03-27_09:15:02/3217_bionic_excuses.html [09:37] those that are "pkg/unknown" do not exist in release but got triggered, hence i got confused. [09:37] i guess these will not be triggered by the real britney in the real bionic-proposed -> release [09:37] so it all adds up they are regressions because they have worked, they cannot work because they don't exist [09:37] so you get a regression and sad [09:38] i would expect real britney to make the same mistake [09:38] and then they will have to be hinted, or run with a trigger to get the proposed one, or something [09:46] hey there [09:47] there is something weird that happened to a package migration [09:47] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [09:47] gnome-shell-extension-appindicator (18.04 to 18.10) [09:47] Not touching package as requested in bug 1759180 on Tue Mar 27 09:01:36 2018 [09:47] Not considered [09:47] bug 1759180 in gnome-shell-extension-appindicator (Ubuntu) "[proposed] 18.10 new version is wrong, should be 18.04.1" [Undecided,New] https://launchpad.net/bugs/1759180 [09:47] but yet it seems it is migrating [09:47] or at least according to https://launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+publishinghistory [09:47] it has been deleted from proposed and is pending publication in bionic [09:48] did that block didn't work / update_excuses was wrong for some reason? [09:48] hang on [09:48] 08:43:43.log:Copying: gnome-shell-extension-appindicator/18.10 [09:49] I think that happened before the bug was filed [09:49] so update_excuses.html doesn't have the correct status? [09:49] there's some published latency here and proposed-migration is looking at an out of date archive [09:50] right the bug says files 50m ago, and the britney copy is shown as more than one hour ago [09:50] publisher* [09:50] I think [09:50] Laney, i concur with that [09:50] the timestamp at the top of update_excuses is quite old too [09:50] so the block didn't work because it was entirely too late, and yes the britney status is wrong now, and will sort itself when the publication completes [09:51] of course that is the last thing you want [09:52] ah well [09:52] appindicator users can enjoy being in the future :-) [09:52] we have a very small window now, where we could consider blowing it away [09:53] you can kill pending publications? [09:53] no too late [09:53] it is already published sadly [09:53] it just changed [09:53] but for future reference... you can? [09:53] i beleieve if it is in pending it can go to deleted yes [09:54] without being a thing that is on disk anywhere [09:54] interesting [09:54] if we were to stop the mirrors now, we might be able to stop it going out, not sure [09:54] cjwatson, ^ you would know if we are entirely too late no [09:54] nwo [09:54] haha [09:55] the publisher run must have just started running to flip those bits, to it isn't quite published yet [09:55] It's not an emergency worthy of that [09:55] but that might be interesting academically [09:55] so i think if we had reacted in that 2m window we cvould have deleted it [09:55] but i think we are committed now, barring someone getting their finger in the gears no [09:55] now [09:56] didrocks, ^ some version fun for you to deal with [09:56] if it's not too late, happy to reupload [09:57] i think you should assume it is too late [09:57] ok, so nothing to deal with in the end [09:57] it's just a number, due to being tired and preparing/testing this on a late train :p [09:57] well i guess you need to decide what you are going to call this going forward [09:57] I'll link the conversation on the bug report [09:58] so you don't have to deal with it in 18.10 [09:58] perhaps 18.10.0.1 or something [09:58] apw: we could copy back an older version [09:58] cjwatson, we could if we arn't worried about upgraders [09:58] yeah, seeing the amount of features every 6 months, it will mostly be the same code anyway [09:59] apw: well, if we could stop it reaching mirrors that'd be OK. I don't know if it's worth the effort in this case though [09:59] same, the worst thing is people opening bugs, but I think it's OKish [09:59] cjwatson, well the publisher is grinding on it now, so it would be a stop publisher job i think [09:59] apw: I could temporarily cowboy out the sync to mirrors [09:59] it's definitely *possible* [10:00] if you feel it's better and worth the effort, feel free and I'll reupload with correct version [10:00] i am ambivalent, it is work for you and risk .. [10:00] cjwatson, so i'd say only do it if you feel it is safe [10:01] https://paste.ubuntu.com/p/fKj8XFTXHc/ is in place [10:01] cjwatson, ack thanks, i'll get that removed and the older copied back in [10:01] didrocks, feel free to upload the right version [10:01] thx cjwatson. apw: ping me once the old version is copied and I'll reupload the new one [10:02] I'm not *absolutely* certain that some internal mirrors won't sync anyway, but I *think* the internal ones are all push [10:02] note that the 18.10 version is still burned [10:02] didrocks, ^ for when you open cathartic carrot [10:03] yeah, we'll move directly to 18.10.0 if any upload on that package :) [10:03] well, someone will probably upload with .0, get a reject and bump [10:06] 18.04.1 uploaded [10:06] thx! [10:06] -queuebot:#ubuntu-release- New source: gnome-shell-extension-appindicator (bionic-proposed/primary) [18.04.1] [10:07] -queuebot:#ubuntu-release- New sync: gnome-shell-extension-appindicator (bionic-release/primary) [18.04] [10:09] -queuebot:#ubuntu-release- New sync: gnome-shell-extension-appindicator (bionic-release/primary) [18.04] [10:11] -queuebot:#ubuntu-release- New: accepted gnome-shell-extension-appindicator [sync] (bionic-release) [18.04] [10:11] -queuebot:#ubuntu-release- New: rejected gnome-shell-extension-appindicator [sync] (bionic-release) [18.04] [10:24] <_hc> hey all, I'm part of the Debian Android Tools Team. We do a dev push before each Ubuntu LTS release, then make sure that it all gets synced properly in Ubuntu LTS, so I'm checking in now on the final details [10:24] <_hc> most of it is already included, there are just two outstanding packages, androguard and fdroidserver [10:24] Laney, for clarity, if we had reacted faster and removed it in pending state that would have been sufficient to prevent it making it out [10:24] <_hc> rbasak already got android-sdk-meta into bionic for us, the sync requests for androguard and fdroidserver are still open [10:25] <_hc> the fdroidserver update requires the androguard update, so that's the place to start 1758199 [11:07] no AA can process https://bugs.launchpad.net/ubuntu/+source/bpfcc/+bug/1750765 ? [11:07] Ubuntu bug 1750765 in bpfcc (Ubuntu) "bpfcc: please remove on i386 s390x and armhf [NBS]" [Undecided,New] [11:10] btw, gtk+2 gtk+3 glib2, can migrate without regressing release, you need to ignore some tests unfortunately [11:10] they are all regressed in release, except for something that is regressed in proposed too [11:15] (double checking is appreciated, because I can't run some tests against -release completely) [11:16] glib2.0's tests are properly regressed [11:37] publisher uncowboyed [11:39] -queuebot:#ubuntu-release- New: accepted gnome-shell-extension-appindicator [source] (bionic-proposed) [18.04.1] [11:42] -queuebot:#ubuntu-release- New: accepted bpfcc [amd64] (bionic-proposed) [0.5.0-5ubuntu1] [12:05] doko, I presume the gcc fix was not worth the effort since you fixed meson in another way? [12:05] you should not presume in the first place [12:06] mmm so what was the reason? [12:06] I would like to understand my mistake :) [12:06] look at the backlog, "working with upstream on a solutin" [12:07] ack probably I did miss because of BNC [12:09] I can't find it, but I'm happy if the hint was good at the end [12:32] _hc: I think you need to follow https://wiki.ubuntu.com/FreezeExceptionProcess on bug 1758199 and then ask the release team to look at that request. [12:32] bug 1758199 in androguard (Ubuntu) " Sync androguard 3.1.0rc2-1 (universe) from Debian testing (main) " [Undecided,Confirmed] https://launchpad.net/bugs/1758199 [12:33] <_hc> thanks [12:33] _hc, androguard is sync'd just stuck in -proposed ? [12:33] <_hc> right now, I'm looking for feedback about whether this is a request that is likely to be reviewed. Then I'm happy to put whatever work it needs into it. [12:34] <_hc> My experience with freeze processes is that if no one is interested, all my work won't change anything [12:34] <_hc> apw: there is an issue on s390x, other than that, its ready to go [12:34] <_hc> I dind't know until now that Ubuntu supports s390x [12:35] <_hc> I can fix that right now [12:37] <_hc> apw: oops sorry, you're right, its just stuck in -proposed. fdroidserver is the package with the s390x issue [12:37] so i am confused what you are asking, it has already been sync'd so it doesn't need an FFE for the version that is there; if you are intending on fixing that then it ought to migrate when you do [12:37] if you are indeed asking to upload the final release of it, that needs consideration if it contains features (it may not) [12:37] apw, the binary on s390x has been removed in Debian, why didn't the removal came in ubuntu too? isn't this something automatic or semi automatic? [12:38] as far as i am aware only full removals are detected [12:38] Oh, sorry. [12:38] I didn't realise it had autosynced before FF. [12:38] rbasak, don't be ... this mess is utterly confusing like spagetti [12:38] I reviewed the sync request assuming it was still needed, and declined on the basis that it appeared to violate FF. [12:40] _hc, if it has been removed in debian, we likely will follow suit [12:40] rbasak, I closed it :p [12:42] <_hc> oh, I guess I'm confused by what -proposed is. Will that be automatically included then? I thought that packages had to be synced into bionic from -proposed [12:42] <_hc> I've been going on this https://packages.ubuntu.com/bionic/androguard which shows the old version, not the version in -proposed [12:43] <_hc> its in Debian/testing: https://packages.debian.org/testing/androguard [12:43] _hc, the version goes from proposed to release automatically unless problems shows up [12:43] in this case, britney (the tool that does the copy from proposed to release), won't allow that, because the version in bionic release has a binary for s390x [12:43] so, letting it migrate will regress that architecture [12:44] _hc, https://launchpad.net/ubuntu/+source/androguard [12:44] removing that binary from s390x will make the migration not worse wrt archive status and binaries, so it will probably land (assuming eventual autopkgtests will be happy, and the installability of reverse-deps will be ok too) [12:45] <_hc> ah, that's the blocker then. Debian already removed the s390x binary package [12:46] _hc, you can request removal of androguard, on s390x, from bionic-release -> file a bug report and subscribe ubuntu-archive team [12:46] xnox, if the package has already been removed on debian, pinging here is usually fine too :) [12:47] <_hc> xnox: I know that page, I'm not sure what you're pointing me to [12:47] <_hc> FYI, the s390x package never worked, we just enabled the test suite in the package, and found that out with this release [12:47] _hc, this is the page you need to understand the situation http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html [12:47] <_hc> ok, thanks [12:47] <_hc> ping :-) [12:47] <_hc> happy to file the bug if that's helpfuil [12:47] _hc, on that page you can see what is published in bionic-proposed, what is published in bionic-release, and clicking on the packages, you can see for which architectures they are published, and drill into publication record from there [12:48] _hc, packges.ubuntu.com does not show such information, and launchpad is the authoritative source of information [12:49] also, rmadison helps (since you seem to be already a DD, you should have that tool) [12:49] rmadison -u ubuntu androguard -s bionic,bionic-proposed [12:49] androguard | 2.0-3 | bionic/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x [12:49] androguard | 3.1.0~rc2-1 | bionic-proposed/universe | source, amd64, arm64, armhf, i386, ppc64el [13:00] <_hc> bug filed 1759261 [13:04] LP: #1759261 [13:04] Launchpad bug 1759261 in androguard (Ubuntu) "request removal of androguard s390x binary package" [Undecided,New] https://launchpad.net/bugs/1759261 [13:04] thanks ubot5 :) [13:35] _hc thanks for the detail, already processed, bug updates [14:03] looks like the snapcraft autopkgtests are broken again, something to do with maven AFAICT [14:05] will mark it as badtest for now so it doesn't hold things [14:06] can you file a bug please? [14:09] bug 1759283 [14:09] bug 1759283 in snapcraft (Ubuntu) "snapcraft adt broken on maven test" [Undecided,New] https://launchpad.net/bugs/1759283 [14:14] ta [14:54] -queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.12 => 1:16.04.13] (core) [15:13] xnox: i have no idea re: nodejs [15:31] I can't understand what happened to androguard on s390x, still not disappeared, even if other removals processed at the same time did went successful [15:37] -queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [163-1~ubuntu17.10.1 => 164-1~ubuntu17.10.1] (no packageset) [15:38] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [164-1~ubuntu17.10.1] [15:38] -queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [163-1~ubuntu16.04.1 => 164-1~ubuntu16.04.1] (no packageset) [15:39] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [164-1~ubuntu16.04.1] [15:41] xnox: it's correct behavior; these packages were in releases previously, now they have failing autopkgtests, they shouldn't just be allowed back into the release [18:49] hi all, I filed this FFe out of caution: all new features are not applicable for bionic, but I need them in the devel release for an upcoming xenial sru: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1759280 [18:49] Ubuntu bug 1759280 in ubuntu-advantage-tools (Ubuntu) "[bionic] [FFe] ubuntu-advantage-tools version 17: FIPS updates" [Undecided,New] [19:05] RAOF: hey can you take a look at getting LP: #1756939 into the release pocket? [19:05] Launchpad bug 1756939 in snapcraft (Ubuntu Artful) "[SRU] New stable micro release 2.40" [Undecided,Fix committed] https://launchpad.net/bugs/1756939 [19:07] -queuebot:#ubuntu-release- Unapproved: plymouth (xenial-proposed/main) [0.9.2-3ubuntu13.2 => 0.9.2-3ubuntu13.3] (core) [19:14] slangasek: thanks for the FFe [19:14] ahasenack: n/p [19:28] smoser: ubuntu-server is still the expected team subscriber for split-out grub-legacy-ec2, correct? [19:34] slangasek: well, no. it should be foundations i think. [19:34] one of the points of the excercise was to get it out of my ownership :) [19:34] smoser: hmm ;) [19:35] slangasek: can I bug you with LP: #1756939 ? Getting snapcraft into xenial-updates and artful-updates ? [19:35] Launchpad bug 1756939 in snapcraft (Ubuntu Artful) "[SRU] New stable micro release 2.40" [Undecided,Fix committed] https://launchpad.net/bugs/1756939 [19:45] hi there, I'm already a couple of hours waiting to my sec-update be copied to the publishers (zsh pkg update) and till now nothing. Seems it's not being copied at all. Any clue about that? [19:45] it's actually the automatic copy from -security to -updates that's not happening [19:50] cjwatson: any ideas? ^ [20:51] hmm, is there some kind of problem with the publisher? [20:52] looks like it's not done much publishing in the past 6 hours or so [20:53] stgraber: mdeslaur was just asking about that for security -> -updates as well [20:53] yep, [20:53] stgraber: i wonder if it's more widespread [20:54] looking, just a moment [20:54] oh dear, I might have broked it [20:54] cjwatson: thanks! [20:54] :) [20:55] it appears to have spent a lot of time running and then dropped a trace [20:56] it's a regression from my refactoring of how signing works [20:56] working out what to do [20:56] oh is that one of the safeties kicking in to stop random files getting signed ? [20:56] no [20:58] I've reverted the tree to the previous revision (r18573) for now [20:58] that should get us back in business until I have a chance to fix it properly [21:01] -queuebot:#ubuntu-release- New binary: linux-gcp [amd64] (bionic-proposed/main) [4.15.0-1002.2] (kernel) [21:11] basically I was trying to extend a particular abstraction that had never been used on the primary archive before to start being so used, and I missed a detail [21:12] slangasek: Do you have objections to me uploading Qt 5.9.5 as soon as it's ready? It's binary-compatible with the Qt already in the archive and is bugfix-only but it looks like with the way the release is coming along upstream that it won't land until after Bionic's final freeze. [21:12] slangasek: (With your release team hat on, of course.) [21:13] So, it wouldn't need a Feature Freeze Exception but I don't want to surprise attack anyone. :) [21:13] need to work out how to adjust the abstraction to cope [21:14] (the primary archive is published into a temporary dists tree and then moved into place, which my code didn't handle) [21:15] slangasek: To give a feel on timing, upstream says "after Easter," their next meeting is on the third of April, and it takes me at minimum two days to get the transition squared away in Bileto (which is doable if there's a time crunch on it). [21:15] ("their" = the Qt release team) [21:27] mdeslaur,stgraber: the publisher is working again after the temporary reversion, btw [21:28] thanks [21:33] tsimonq2: I don't think that we should take a new upstream version of Qt, even bugfix-only, post final freeze, without an explicit reason to [21:35] slangasek: ooc what's your reasoning? [21:35] tsimonq2: the fact that it's final freeze [21:35] :) [21:36] https://wiki.ubuntu.com/FinalFreeze [21:36] slangasek: So, what about with your SRU Team hat? :P [21:37] slangasek: It seems compatible with the SRU policy but not the Final Freeze policy then, I guess. [21:37] tsimonq2: I don't generally pre-approve SRUs before seeing what's actually changed [21:38] tsimonq2: if you want to follow the normal SRU process, then you get to create a bug report and a test case for each bugfix included from upstream [21:38] tsimonq2: if you want an SRU exception process, then you have to negotiate that with documentation [21:38] slangasek: ack [21:39] slangasek: https://blog.qt.io/blog/2017/05/11/introducing-long-term-support-qt-5-9/ <-- upstream says that "During the first 6 months after release day, an LTS release receives a lot of fixes, including low-priority ones. Then the LTS release enters a ‘strict’ phase where only critical bugs and security issues are addressed. This will ensure the stability of the LTS releases. During the final [21:39] year of an LTS release the commit policy is ‘very strict’, at which phase we only address severe security issues." [21:39] slangasek: So, while I do plan on manually reviewing the changes, it should, in concept, be fine to go through as a regular SRU. [21:39] slangasek: If it's determined when I go through the paperwork that it isn't, then I'll apply for an exception. [21:40] tsimonq2: again, a regular SRU means that every single change from upstream gets a separate bug report with a regression test [21:40] slangasek: I disagree that it's a policy which has always been followed. [21:41] slangasek: Kubuntu's done updates en masse like this for years. [21:41] * tsimonq2 finds examples [21:41] finding examples that didn't follow the policy doesn't mean it isn't the policy [21:42] slangasek: I believe this clause can be exercised: https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases [21:43] Specifically: "it is also acceptable to upload new microreleases with many bug fixes without individual Launchpad bugs for each of them (~ubuntu-sru will make the final decision). The upstream QA process must be documented/demonstrated and linked from the SRU tracking bug. In other cases where such upstream automatic testing is not available, exceptions must still be approved by at least one [21:43] member of the Ubuntu Technical Board." [21:43] yes, the operant clause is "ubuntu-sru will make the final decision"; all of which is an SRU exception [21:44] How is this an exception to the policy rather than part of the policy? [21:45] there are no exceptions that are not part of the policy, the policy is that the SRU team has to approve the SRU ;) [21:46] I guess I'm disagreeing with you when you said that each individual bug fixed needs its own report. [21:46] That clause states otherwise, and it's what I've known as practice in appropriate cases. [21:46] Sure, the SRU team needs to approve it, as always. [21:47] I'm just arguing against it needing it to be in many different bug reports. [21:47] slangasek: Is this incorrect? [21:49] thanks cjwatson! [21:50] tsimonq2: I'm saying that if you're going the microrelease process, that is an exception, not a "normal" SRU. which is fine [21:51] slangasek: OK. [21:51] slangasek: Thanks. [21:57] any SRU team members around have insight to why snapd-glib is sitting in unapproved for 19 weeks? [21:57] that suggests something's wrong with it, but I couldn't work it out by looking at the bug [22:17] -queuebot:#ubuntu-release- New source: kubuntu-wallpapers (bionic-proposed/primary) [18.04.0] [22:18] slangasek: That source package is very small, it'd be good to get a review real quick ^^^^ [23:10] -queuebot:#ubuntu-release- New binary: xapp [amd64] (bionic-proposed/universe) [1.0.4-2fakesync1] (no packageset)