| === chris14_ is now known as chris14 | ||
| -queuebot:#ubuntu-release- Unapproved: libheif (lunar-proposed/universe) [1.14.2-1 => 1.14.2-1ubuntu1] (i386-whitelist, kubuntu) | 09:32 | |
| -queuebot:#ubuntu-release- Unapproved: gdm3 (jammy-proposed/main) [42.0-1ubuntu7.22.04.2 => 42.0-1ubuntu7.22.04.3] (desktop-core) | 10:49 | |
| -queuebot:#ubuntu-release- Unapproved: gdm3 (lunar-proposed/main) [44.0-1ubuntu1 => 44.0-1ubuntu2] (desktop-core) | 11:03 | |
| -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-450-server (jammy-proposed/restricted) [450.236.01-0ubuntu0.22.04.1 => 450.236.01-0ubuntu0.22.04.2] (core, i386-whitelist) (sync) | 11:42 | |
| -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-450-server [sync] (jammy-proposed) [450.236.01-0ubuntu0.22.04.2] | 13:16 | |
| freyes | hello all, I just wanted to check if anyone from the SRU team could take a look to this bug http://pad.lv/1996229 , the package upload was sponsored by coreycb , it has been in the unapproved queue for some weeks now - https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=python-magnumclient | 13:38 |
|---|---|---|
| -ubottu:#ubuntu-release- Launchpad bug 1996229 in python-magnumclient (Ubuntu Focal) "[SRU] magnum ui can not delete the coe cluster" [High, Triaged] | 13:38 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (lunar-proposed/main) [2.06-2ubuntu16 => 2.06-2ubuntu17] (core, i386-whitelist) (sync) | 14:09 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (focal-proposed/main) [2.06-2ubuntu14.1 => 2.06-2ubuntu14.2] (no packageset) (sync) | 14:09 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (kinetic-proposed/main) [2.06-2ubuntu14.1 => 2.06-2ubuntu14.2] (core, i386-whitelist) (sync) | 14:09 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (jammy-proposed/main) [2.06-2ubuntu14.1 => 2.06-2ubuntu14.2] (core, i386-whitelist) (sync) | 14:09 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-signed (lunar-proposed/main) [1.192 => 1.193] (core) (sync) | 14:09 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.187.3~20.04.1 => 1.187.4~20.04.1] (core) (sync) | 14:10 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-signed (kinetic-proposed/main) [1.187.3 => 1.187.4] (core) (sync) | 14:10 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-signed (jammy-proposed/main) [1.187.3~22.04.1 => 1.187.4~22.04.1] (core) (sync) | 14:10 | |
| vorlon | freyes: it had been blocked because there was a previous version of python-magnumclient in -proposed that had not been set to verified. It is the responsibility of the uploaders to verify the SRU bugs on their package. In this case when I looked the SRU bugs were about build failures so I marked them done and it's promoted; now the new version can be reviewed | 14:11 |
| freyes | vorlon, oh, I see, I missed that bit, much appreciated for cleaning that up, I will take note of this check for future sru requests | 14:12 |
| juliank | The grub2-unsigned/signed in lunar are awkward I admit, they have non SRU version because they were built way before the release but the signing took time | 14:15 |
| juliank | It's fine though, it's already copied into mantic, and the next mantic upload just continues with ubuntu18 | 14:16 |
| juliank | oh vorlon, can I resurrect https://launchpad.net/ubuntu/+source/grub2/2.06-2ubuntu17 into mantic somehow? copy-package -b -e 2.06-2ubuntu17 --from-suite lunar-proposed --to-suite mantic-proposed grub2 only resurrects the source it says | 14:18 |
| juliank | We dropped it from lunar-proposed because the signed bits weren't ready for it | 14:18 |
| juliank | but now we want it back in mantic-proposed | 14:19 |
| vorlon | juliank: it only *says* it resurrects source but it actually includes the binaries | 14:19 |
| juliank | ah | 14:19 |
| * juliank tries, thanks | 14:19 | |
| juliank | Oh one thing that's interesting about the signing delay is that grub2-unsigned in lunar is going to be ubuntu17.x whereas grub2 is ubuntu16.x | 14:21 |
| juliank | I think that's what we want, that they develop separately | 14:21 |
| juliank | otherwise we'd end up with ubuntu16.0.1 and ubuntu16.1 or sth | 14:22 |
| juliank | because same version with different content would be confusing, and same content we don't usually want | 14:22 |
| juliank | (consider the MM changes, we don't want to ship them to BIOS or POWER systems) | 14:23 |
| -queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu9.9 => 2.31-0ubuntu9.10] (core, i386-whitelist) | 14:23 | |
| enr0n | ubuntu-sru: The remaining tests blocking systemd (https://ubuntu-archive-team.ubuntu.com/proposed-migration/focal/update_excuses.html#systemd) in Focal do not appear to be related to systemd. The fwupd failure is known and fixed by a fwupd upload in focal-proposed, and the linux- tests are failing with badpkg, which seems to be related to toolchain dependency issues. | 15:10 |
| rbasak | enr0n: could you document that somewhere please? https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions has some suggestions. | 15:28 |
| rbasak | Because we need to add hints based on that to get the report clean before releasing it, etc. | 15:28 |
| enr0n | rbasak: thanks, I will comment this on the appropriate bug report | 15:29 |
| vorlon | rbasak: doing a one-off run of sru-autosubscribe now | 15:39 |
| vorlon | hmMmm looking at proxy setup wrt keyserver.u.c | 15:41 |
| vorlon | rbasak: so you add a debug log for empty upload.changes_file_url, but then proceed to pass it to find_changes_bugs() which proceeds to try to urlopen(None)? | 15:52 |
| vorlon | rbasak: anyway, no .changes link on https://api.launchpad.net/devel/ubuntu/lunar/+upload/31233593 because sync etc; I'll amend the code | 16:00 |
| rbasak | Ah was there a missing return or something? | 16:01 |
| rbasak | I'm aware of that edge case because I've hit it in various other situations. But it's hard to test. It worked at the time! | 16:02 |
| vorlon | rbasak: yeah missing continue | 16:03 |
| vorlon | rbasak: ok run successfully now | 16:08 |
| vorlon | and I can confirm it's subscribed me to some bugs ;) | 16:09 |
| rbasak | Thank you for handling that! Let's see how it goes. | 16:12 |
| vorlon | rbasak: now I'm subscribed to all the ubuntu-dev-tools bugs of the past 3 years <sob> - which maybe is a pointer that I should not use -v for the SRU changelogs | 16:41 |
| rbasak | Ha | 16:41 |
| rbasak | -v does seem reasonable | 16:41 |
| rbasak | But we do overload Launchpad-Bugs-Fixed a little in that we assume that each will need SRU verification | 16:42 |
| vorlon | yeah | 16:42 |
| rbasak | But that's not the case here. Yet it will look like that in the report. | 16:42 |
| vorlon | I could hand-hack the .changes file | 16:42 |
| vorlon | (and reupload) | 16:42 |
| rbasak | This kind of thing has come up before. I wonder if we could find a solution that doesn't require hackery, because it's a source of confusion for uploaders generally I think. | 16:43 |
| vorlon | in the meantime, the sru-autosubscribe behavior is beneficial :) | 16:46 |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-dev-tools [source] (kinetic-proposed) [0.193ubuntu4~22.10.1] | 16:46 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (kinetic-proposed/universe) [0.191 => 0.193ubuntu4~22.10.1] (no packageset) | 16:46 | |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-dev-tools [source] (jammy-proposed) [0.193ubuntu4~22.04.1] | 16:48 | |
| rbasak | I'll post to ubuntu-devel@ to explain the autosubscribe thing | 16:49 |
| vorlon | juliank: are you verifying the bugs on fwupd*/bionic? | 16:49 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (jammy-proposed/universe) [0.189 => 0.193ubuntu4~22.04.1] (no packageset) | 16:49 | |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-dev-tools [source] (focal-proposed) [0.193ubuntu4~20.04.1] | 16:50 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (focal-proposed/universe) [0.187~bpo20.04.1 => 0.193ubuntu4~20.04.1] (no packageset) | 16:50 | |
| vorlon | grub2 (2.06-2ubuntu16 to 2.06-2ubuntu17) in proposed for 100 days | 16:57 |
| vorlon | mmhmm | 16:57 |
| -queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (lunar-proposed) [44.0-1ubuntu2] | 17:36 | |
| -queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (jammy-proposed) [42.0-1ubuntu7.22.04.3] | 17:36 | |
| bdmurray | rbasak: Is there a reason uploaders aren't also subscribed to SRU bugs? | 17:50 |
| juliank | vorlon: I think I already did verify the binaries on bionic end to end before the copy but need to boot the other laptop again | 18:12 |
| juliank | Tomorrow, did not make it today | 18:13 |
| rbasak | bdmurray: they are - it's just whoever signed the dsc | 18:38 |
| rbasak | (that the script could match) | 18:38 |
| rbasak | Sorry I didn't make that clear. | 18:38 |
| jbicha | rbasak: does it also subscribe the sponsee? | 18:54 |
| vorlon | jbicha: no, there's no reliable way to identify sponsorees' launchpad IDs | 18:54 |
| seb128 | hum, it's annoying that there was no discussion about that change before to push it down on people | 19:01 |
| -queuebot:#ubuntu-release- Unapproved: osinfo-db (lunar-proposed/universe) [0.20230308-1ubuntu2 => 0.20230518-1ubuntu0.23.04.1] (no packageset) | 19:01 | |
| seb128 | I try to help and sponsor things, but if I'm going to be punished by getting extra email spamming from laun chpad in return I might reconsider helping, which I think is not what we want there | 19:02 |
| seb128 | rbasak, ^ | 19:02 |
| -queuebot:#ubuntu-release- Unapproved: osinfo-db (kinetic-proposed/universe) [0.20220830-1 => 0.20230518-1ubuntu0.22.10.1] (no packageset) | 19:03 | |
| -queuebot:#ubuntu-release- Unapproved: osinfo-db (jammy-proposed/universe) [0.20220214-1ubuntu2.1 => 0.20230518-1ubuntu0.22.04.1] (no packageset) | 19:05 | |
| rbasak | seb128: the SRU team considered just asking sponsors to subscribe a while ago. But then we realised that we could do it automatically. | 19:06 |
| rbasak | seb128: I believe it's the position of the SRU team that sponsors _are required to_ keep driving the SRU by responding to questions. If they don't do that, then it's impossible, and SRU team would be wasting their time reviewing them in the first place. | 19:07 |
| rbasak | seb128: so if a sponsor is not prepared to spend the time doing the required follow up, then they shouldn't be sponsoring it in the first place. | 19:08 |
| rbasak | seb128: if they're required to follow up, then why would they object to being subscribed? | 19:08 |
| rbasak | seb128: another way of looking at it: sponsoring and then not responding to review questions is hindering, not helping. | 19:09 |
| rbasak | seb128: since that ties up the SRU team's time when they could be spending that time on other SRUs that will actually land. | 19:09 |
| -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (focal-proposed) [1:14.2.0-0ubuntu2] | 19:10 | |
| seb128 | rbasak, I'm fine helping and being point of contact, I've no interest in being spammed by every user following up on random issues just because I helped getting the fix uploaded | 19:22 |
| seb128 | rbasak, the SRU team define their process and their expectation of course, and as a team you probably have interest in seeing less uploads going through to lower workload so it somewhat makes sense from that perspective, it doesn't mean the outcome is right for the project | 19:24 |
| bdmurray | How long does the sponsor need to be subscribed for? Maybe until it is in -updates? | 19:26 |
| seb128 | rbasak, we somewhat are back to the email I need to send to the TB, the default position for core teams is to have discussions behind closed door, not take input and announce things afterfact | 19:26 |
| bdmurray | s/-updates/-proposed/ | 19:26 |
| vorlon | the SRU team's goal is not to reduce the number of uploads, it's to reduce the number of stalled SRUs | 19:26 |
| vorlon | when no one accountable is watching the bug, SRUs stall | 19:27 |
| seb128 | well as a a regular sponsor that decision is going to reduce my involvement | 19:27 |
| seb128 | I might not be the only one | 19:27 |
| seb128 | just stating one opinion, you do what you want from the data | 19:27 |
| vorlon | nothing stops you from unsubscribing from the bug after the package has been accepted; you won't be resubscribed | 19:27 |
| seb128 | it's still annoyance and manual work I didn't ask for | 19:28 |
| seb128 | I wish that kind of policy impacting everyone would have a public decision before being pushed down on the project | 19:28 |
| seb128 | decision->discussion | 19:28 |
| === orndorffgrant4 is now known as orndorffgrant | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!