[03:13] -queuebot:#ubuntu-release- Unapproved: blueman (focal-proposed/universe) [2.1.2-1ubuntu0.2 => 2.1.2-1ubuntu0.3] (ubuntu-mate, ubuntukylin, ubuntustudio, xubuntu)
[04:43] -queuebot:#ubuntu-release- Unapproved: ruby-mysql2 (focal-proposed/universe) [0.5.2-1ubuntu3 => 0.5.2-1ubuntu3.20.04.1] (no packageset)
[05:24] -queuebot:#ubuntu-release- Unapproved: ruby-mysql2 (hirsute-proposed/universe) [0.5.2-1ubuntu3 => 0.5.2-1ubuntu3.21.04.1] (no packageset)
[06:01] -queuebot:#ubuntu-release- Unapproved: libvirt (focal-proposed/main) [6.0.0-0ubuntu8.13 => 6.0.0-0ubuntu8.14] (ubuntu-server, virt)
[06:07] <cpaelzer> RAOF: hiho, I read that you are on SRU rota today
[06:08] <cpaelzer> There is an regression-update case that people worked on the last few hours and that now is ready
[06:08] <cpaelzer> That is in bug 1943481
[06:08] <cpaelzer> the queuebot ping above is the related upload into focal-unapproved
[06:08] <RAOF> cpaelzer: Hey, lo! *Technically*, I observe North American Tuesday, but I'm happy to be pinged :)
[06:09] <cpaelzer> RAOF: since we do not want to loose too mcuh time on regression updates I wanted to ping if you could have a look
[06:09] <cpaelzer> Oh I thought you observe your tuesday and thought that is some kind of "after noon, but not too late to ping" - in any case thanks in advance for having a look
[06:10] <cpaelzer> and if you can't make it let me know so that I can ping others later today
[06:15] <RAOF> I'm always happy to receive pings in working hours. It's 16:15 here, so that's fine :)
[06:15] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (focal-proposed) [6.0.0-0ubuntu8.14]
[06:15] <RAOF> That seems perfectly sensible. Accepted.
[06:16] <cpaelzer> Thank you so much RAOF!
[08:21] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [amd64] (impish-proposed) [2.04-1ubuntu47]
[08:23] -queuebot:#ubuntu-release- New source: xlnx-kria-firmware (impish-proposed/primary) [0.6]
[08:25] -queuebot:#ubuntu-release- New: rejected xlnx-kria-firmware [source] (impish-proposed) [0.5]
[08:27] -queuebot:#ubuntu-release- New source: xlnx-kria-firmware (impish-proposed/primary) [0.6]
[08:28] -queuebot:#ubuntu-release- New: rejected xlnx-kria-firmware [source] (impish-proposed) [0.6]
[08:28] -queuebot:#ubuntu-release- New: accepted xlnx-kria-firmware [source] (impish-proposed) [0.6]
[08:36] -queuebot:#ubuntu-release- New binary: xlnx-kria-firmware [arm64] (impish-proposed/universe) [0.6] (no packageset)
[08:45] -queuebot:#ubuntu-release- New: accepted xlnx-kria-firmware [arm64] (impish-proposed) [0.6]
[09:59] -queuebot:#ubuntu-release- New source: xlnx-kria-firmware (focal-proposed/primary) [0.6~20.04.1]
[10:08]  * enyc meows
[10:37] <paride> sil2100, hi! How will you handle the fact that 18.04.6 are only going to be released for a subset of the archs? Is it just a matter of not manually blessing the ppc/s390x .6 images as released?
[10:41] -queuebot:#ubuntu-release- Unapproved: xrt (focal-proposed/universe) [202020.2.8.726-0ubuntu7~20.04 => 202020.2.8.743-0ubuntu1~20.04] (no packageset)
[10:42] <guiverc> sil2100, when is 18.04.6 (likely?) to be released?   (I see the request for testing RC; wondering about ubuntu_news post..)
[10:45] <paride> guiverc, see https://lists.ubuntu.com/archives/ubuntu-devel/2021-September/041613.html
[10:46] <guiverc> yeah thanks, I have the quality one, but it was release date (or ETA) that interested me... if in UWN it won't publish till next Monday for example.. no point if already released...
[10:48] <paride> that's another email and it says: our estimated release date is this Thursday (16th of September)
[10:49] <guiverc> thanks, yep that's the date I was interested in.. (I missed the ETA email).. thank you paride
[10:50] <paride> yw!
[11:06] <sil2100> paride: hey! The publication scripts offer quite some freedom in which arches we want to publish, so we can do it only for a subset
[11:07] <sil2100> I'm still trying to reach Steve to see if he's okay with just releasing amd64 and arm64
[11:07] <sil2100> Anyway, looks like there might be a respin for the desktop images at least, because I think I found a bug related to ubuntu-drivers
[11:15] <ricotz> sil2100, hey, "expat" went through without issues
[11:38] <paride> sil2100, the old "MinimalVirtual" install now exceeds what we set to be the limit for Bionic (limit was: 2080MB, installed size is now: 2162MB)
[11:39] <paride> that's something we stopped checking when the d-i server images were phased out
[11:40] <paride> however for Focal the limit was 2360MB
[11:44] <paride> sil2100, this ~80MB difference looks physiological (general increase of package size over the years), but before bumping the test limit I'd like an ACK
[11:44] <paride> just in case we wanted that to be a harder limit for any reason
[11:59] <sil2100> ricotz: \o/
[12:00] <sil2100> paride: I think that's fine, we also saw a size increase for desktop but didn't see anything malicious with that
[12:00] <paride> sil2100, good! thanks
[12:00]  * paride goes to tweak the limits
[12:16] <paride> sil2100, we're all green in platform-qa \o/
[12:32] <sil2100> \o/
[13:42] <seb128> hum, is that an autopkgtest bug that the first try on https://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/impish/amd64 which has triggers 'glib2.0/2.68.4-1build1 libffi/3.4.2-1ubuntu3' is blocking the new glib but not libffi?
[13:43] <seb128> https://autopkgtest.ubuntu.com/packages/d/dbus-python/impish/amd64
[13:43] <seb128> https://autopkgtest.ubuntu.com/packages/b/bolt/impish/amd64
[13:44] <seb128> checking those it seems more likely than libffi is creating the regressions than glib
[13:44] <seb128> yet the update_excuse for libffi flags none of those, which means it could probably migrate despite the issues?
[13:45] <seb128> @juliank, ^
[13:51] <juliank> seb128: that vrsion of libffi is no longer in proposed
[13:51] <juliank> seb128: presumably libffi is not a trigger for those packages
[13:52] <juliank> seb128: but the new python3.9 needs new libffi to migrate, so it becomes added to set of triggers
[13:52] <seb128> juliank, I guess that's because it's through a transient package?
[13:53] <seb128> juliank, would doing a manual trigger get those failures added to the libffi section?
[13:53] <juliank> seb128: I don't know
[13:53] <juliank> seb128: try it out with -1ubuntu4 and see?
[13:53] <seb128> juliank, k, trying, thanks
[14:11] <sil2100> grrrr git clone of ubiquity taking ages
[14:11] <seb128> someone mentioned slowness issues on ~Launchpad
[14:12] <seb128> juliank, do you know how we get libffi updates to trigger tests, for example gjs? (without adding a depends manually that would encode a soname)
[14:25] <juliank> seb128: with a depends
[14:26] <seb128> juliank, depends on what? we don't want to hardcode the soname there...
[14:26] <juliank> seb128: just test depend on libffi-dev?
[14:26] <seb128> I guess that would work despite being a bit hackish?
[14:27] <juliank> that's the way it goes :D
[14:27] <seb128> alright, thanks for the advice ;-)
[14:39] <bdmurray> sil2100: I wrote some code to look at the sizes of the packages in the manifest files and I didn't see anything overly large in them.
[14:39] <sil2100> bdmurray: hey! I fixed one critical issue in ubiquity for 18.04.6 - https://git.launchpad.net/ubiquity/commit/?id=28779054c060dea4fe2376b8e7275a634fbfa949
[14:39] <sil2100> bdmurray: I'm filling in a bug with another critical issue, but for that one maybe I'll poke around for help
[14:40] <ginggs> seb128: juliank: there's a better way: 'Restrictions: hint-testsuite-triggers' https://salsa.debian.org/apparmor-team/apparmor/-/blob/debian/master/debian/tests/control#L9
[14:40] <bdmurray> sil2100: nice
[14:41] <juliank> ginggs: nice
[14:42] <sil2100> bdmurray: I'll report it but first I need to check if it's a new bug or an old one
[14:45] <seb128> ginggs, thanks, it seems a bit more complicated than adding a depends but I guess it has the advantage of not imposing extra unneeded depends to the tests and making it clearer why they are listed
[14:45] <ginggs> seb128: also adding an extra depends might hide a missing depends
[14:45] <seb128> right
[15:36] <cpaelzer> are there shorter aging periods for regression updates like https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1943481
[15:36] <cpaelzer> or would that be like removing the current -updates restoring the former, and then once aged enough push the new one?
[15:44] <bdmurray> cpaelzer: in the event that an update is fixing a regression there can be shorter aging periods
[15:58] <bdmurray> cpaelzer: has there been any additional testing besides the test case in that bug?
[16:06] <sil2100> eh, so many issues
[16:11] <vorlon> ?
[16:11] <sil2100> bdmurray, vorlon: hey, do you guys remember if in bionic it was possible to install nvidia drivers without network enabled? Asking since right now (after my fixes) this fails as there is no nvidia drivers on the cd pool (and cannot be fetched)
[16:11] <sil2100> I tried looking at the .list for 18.04.5 and didn't see nvidia drivers there either
[16:12] <vorlon> I believe that was something that was addressed in focal
[16:12] <bdmurray> I don't think it was possible and something we fixed in Eoan
[16:12] <bdmurray> The last time we were in London
[16:12] <vorlon> hence all the late-in-release bugs in focal around making sure we always install matching nvidia drivers and kernel
[16:12] <vorlon> ok, eoan then :)
[16:12] <sil2100> Ok, phew, then not a regression!
[16:13] <sil2100> I got confused since the damn isotracker test-case mentions to use offline mode for this test, but we possibly modified the test case for future releases and it just stayed this way
[16:13] <vorlon> right, because we were never going to release bionic again so we didn't care ;p
[16:14] <sil2100> ;)
[16:14] <sil2100> Ok, so the only real blocker (or at least worth investigation) IMO is this:
[16:14] <sil2100> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1943614
[16:15] <sil2100> I'll update the tracking document
[16:15] <sil2100> This I confirmed does seem to be a regression, as it seemed to work for .5, but I only briefly looked at it
[16:15] <vorlon> výborně
[16:15] <sil2100> It's not very important, but then again people from Poland installing drivers will just fail and have to do it on their own ;)
[16:16] <sil2100> And I assume more languages like these are affected
[16:16] <sil2100> Only similar bug in the past I saw was LP: #1797579, but that one is a bit different
[16:17] <sil2100> Since there's no removals from what I see
[16:20] <vorlon> do you have a minimum reproducer from the commandline for the ubuntu-drivers crash?
[16:20] <vorlon> 'ubuntu-drivers autoinstall' here in a bionic chroot just spits out 'No drivers found for installation'
[16:20] <vorlon> maybe I need to enable restricted
[16:21] <bdmurray> I thought Martin Pitt had a way of faking hardware that requires restricted
[16:21] <vorlon> well I do have nvidia hardware outside the chroot, so now that I've added restricted, things are happening
[16:21] <vorlon> but no crashes yet
[16:23] <vorlon> possibly all thanks to the python3 "is this in utf8 or ascii mode? depends on if it's a tty or a file" nonsense
[16:24] <vorlon> oh, but the error message is even weirder, "you exported a locale but it doesn't exist"
[16:25] <vorlon> ok yes I can reproduce it with 'LANG=pl_PL.UTF-8 ubuntu-drivers autoinstall' when I *don't* install the locale
[16:26] <vorlon> hairy
[16:26] <bdmurray> hirsute?
[16:26] <vorlon> yes
[16:51] -queuebot:#ubuntu-release- Unapproved: accepted ruby-mysql2 [source] (hirsute-proposed) [0.5.2-1ubuntu3.21.04.1]
[16:53] -queuebot:#ubuntu-release- Unapproved: accepted ruby-mysql2 [source] (focal-proposed) [0.5.2-1ubuntu3.20.04.1]
[16:54] <vorlon> problem not reproducible for me on hirsute, yet I don't see any relevant code differences in python3-click or ubuntu-drivers-common...
[16:57] <vorlon> hmm but installing hirsute versions of python3-click and ubuntu-drivers-common on bionic, I can still reproduce it
[17:01] <vorlon> python3 behavior change, whee
[17:01] <vorlon> (newer python3 falls back to C.UTF-8 automatically on invalid locale)
[17:02] <vorlon> so not really a solution for bionic
[17:05] <bdmurray> vorlon: which issue are you looking at?
[17:05] <vorlon> bdmurray: LP: #1943614
[17:05] <vorlon> and I have a prospective patch
[17:06] <bdmurray> Oh, I thought it meant a literal click! I should have looked at the bug. ;-)
[17:12] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.17]
[17:12] <vorlon> bdmurray, sil2100: I've uploaded my proposed workaround for ubuntu-drivers-common; please have a look.  If you think this is something we need to fix in ubiquity instead, more digging required
[17:12] <vorlon> (I found it a lot easier to make ubuntu-drivers not crash than to figure out why ubiquity is generating locales at the wrong point in time, but if the latter has other knock-on effects we should revisit)
[17:13] <vorlon> bah ok my upload was rejected because tseliot's git tree seems to be out of date vs the archive
[17:13] <vorlon> rebasing
[17:14] <vorlon> in the meantime, perhaps you can look at the PR and weigh in
[17:15] -queuebot:#ubuntu-release- Unapproved: stress-ng (focal-proposed/universe) [0.11.07-1 => 0.11.07-1ubuntu1] (no packageset)
[17:22] <sil2100> vorlon: looking!
[17:23] -queuebot:#ubuntu-release- Unapproved: stress-ng (hirsute-proposed/universe) [0.12.06-1 => 0.12.06-1ubuntu1] (no packageset)
[17:26] <sil2100> vorlon: ok, code wise looks good, but let me give it a spin
[17:50] <vorlon> sil2100: ok, reuploading
[17:50] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.9.0~0.18.04.3 => 1:0.9.0~0.18.04.4] (desktop-core, ubuntu-server)
[18:06] <bdmurray> vorlon: what's this .orig file?
[18:11] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (hirsute-proposed) [2.0.2-1ubuntu5.2]
[18:24] <sil2100> vorlon: ok, seems to work as expected!
[18:25] <sil2100> So I'm +1 on this change, tho it would be nice to have the .orig cleaned up!
[18:25] <sil2100> bdmurray: since vorlon is busy, I'll re-upload this with the orig removed
[18:27] <bdmurray> sil2100: okay, let me know when to review it
[18:29] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.9.0~0.18.04.3 => 1:0.9.0~0.18.04.4] (desktop-core, ubuntu-server)
[18:30] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.9.0~0.18.04.4]
[18:31] <sil2100> bdmurray: ready ^
[18:31] <sil2100> Ok, in that case I'll also upload ubiquity with that other fix
[18:31] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (focal-proposed) [0.11.07-1ubuntu1]
[18:34] <bdmurray> sil2100: aw man, there already is an ubuntu-drivers-common in bionic-proposed and its very underverified
[18:34] <sil2100> Aw come ooon
[18:34] <sil2100> Same version?
[18:35] <sil2100> Ah, .3
[18:35] <sil2100> grrr
[18:35] <sil2100> I feel as if in this case we should just drop .3 from -proposed, upload .4 with *ONLY* the change from vorlon and then ask tseliot to rebase on top
[18:36] <bdmurray> I'm looking at some of the bugs
[18:37] <sil2100> Uploaded ubiquity just now, if you could take a look at that one too
[18:37] -queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.16 => 18.04.14.17] (core)
[18:38] <bdmurray> I'm a +1 for dropping .3 from -proposed.
[18:44] <bdmurray> sil2100: autoinstall seems like it should still work given the ubuntu-drivers code
[18:44] <sil2100> bdmurray: sadly it doesn't, because the current ubuntu-drivers version fails when you give --package-list option to it
[18:45] <sil2100> I didn't dive into the details, but since it's deprecated anyway I didn't feel like debugging the deprecated command!
[18:45] <sil2100> bdmurray: it basically crashes with the error '--package-list unknown argument' or something like that
[18:45] <bdmurray> okay
[18:46] <sil2100> I vaguely remember us having a similar issue during some release already, hm
[18:47] <bdmurray> oh the @click.option() list is much smaller for the autoinstall function
[18:48] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.17]
[18:56] <sil2100> bdmurray: eh, so the ubuntu-drivers-common thing won't be that easy - the version that's in -updates is an older version number
[18:57] <sil2100> 1:0.8.6.3 instead of 1:0.9.0
[18:57] <sil2100> So we'd have to do a dummy version with the whole .is. or similar notation
[18:58] <sil2100> hm, or guess I could just remove it from -proposed like with remove-package
[18:59] <sil2100> And just push a 1:0.8.6.3~0.18.04.2
[18:59] <sil2100> vorlon: ^
[19:00] <sil2100> I'll start preparing that
[19:07] <bdmurray> sil2100: but then people with the current version from -proposed installed won't have an upgrade path until a new ubuntu-drivers-common is uploaded right? I guess we could just do the upload early next week
[19:08] <sil2100> bdmurray: yeah, we could do that. It's not the first time when we get a new upstream version to -proposed and then drop it for the previous one and just continue from there
[19:08] <sil2100> I suppose it's the risk of -proposed
[19:09] <vorlon> furthermore, they probably don't need an upgrade path for this issue; having a locale set in the environment but not existing seems like very niche behavior outside of this ubiquity issue
[19:12] <sil2100> Ok, pushed the old version with vorlon's change on top + removing the old sru with sru-remove
[19:12] <bdmurray> vorlon: I mean the people who already have the version of the package from -proposed installed
[19:13] <vorlon> bdmurray: of course; I'm saying that if we remove that, and replace it with this one change, there's nothing currently that they /need/ to upgrade to, and we can merge the two after .6
[19:14] <bdmurray> vorlon: got it, we just need to remember to do the merge after .6!
[19:15]  * vorlon nods
[19:17]  * sil2100 needs to wait for the removal to be processed before pushing the new version to the queue
[19:18] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.8.6.3~0.18.04.1 => 1:0.8.6.3~0.18.04.2] (desktop-core, ubuntu-server)
[19:21] <bdmurray> I'm rejecting the older one
[19:22] <sil2100> Yes plz
[19:23] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.9.0~0.18.04.4]
[19:31] <sil2100> Let's get those reviewed and building in -proposed - if someone could help with the verification of the -proposed packages, that would be awesome as well
[19:31] <sil2100> I need to AFK now, but I'll be back later :)
[19:33] <sil2100> Updated the tracking document as well
[19:34] <bdmurray> I'm reviewing the package now
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:0.8.6.3~0.18.04.2]
[21:38] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (hirsute-proposed) [0.12.06-1ubuntu1]
[21:38] -queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.18 => 20101020ubuntu543.19] (core)
[21:38] <vorlon> bdmurray: ^^
[21:42] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.19]
[21:58] <bdmurray> Oh testing ubuntu-drivers-common it became clear what added python3-click and python3-colorama to the bionic ioss
[21:58] <bdmurray> isos
[22:02] <vorlon> :)
[22:10] -queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [sync] (bionic-proposed) [3.5.18-1ubuntu1.5]
[22:17] -queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [sync] (xenial-proposed) [3.4.10-4ubuntu1.9]
[22:20] <vorlon> ^ useful to include gnutls28 in 18.04.6, so that apt on the image can access https sources
[23:31] <sil2100> List of changes keeps on growing ;) But +1 for that one
[23:31] <sil2100> o/