[07:52] <utkarsh2102> cjwatson: hello, I guess bootstrap-package is only available for each package uploads & not for the entire PPA?
[07:53] <utkarsh2102> what I mean is, I uploaded a new version of symfony to my PPA, **hopefully** fixing the dependency issue but it complains about missing php-twig now.
[07:53] <utkarsh2102> cf: https://launchpad.net/~utkarsh/+archive/ubuntu/symfony-bootstrap/+build/21630239
[07:54] <utkarsh2102> can we enable that bootstrapped package (php-twig) for the entire PPA or something? So that I can just upload newer versions of symfony & they'll just work; this way I can check stuff on my own and won't have to annoy other people.
[08:13] <seb128> rbasak, hey, so following on the SRU discussion from yesterday, it feels like the GNOME exception discussion isn't active, is there anything we can do to help resuming it? also meanwhile if items are ignored in the queue because the SRU team feels like they are wrongly using a GNOME exception justification could it be stated on the bug or rejected so the uploader understands why it's stucked?
[08:15] <seb128> RAOF, bdmurray, tjaalton, ^ you might also be interested (unsure if there is a SRU team alias defined to use to ping you)
[08:16] <RAOF> I don't think there is an SRU team alias; at least, I don't have anything set to highlight.
[08:18] <RAOF> Huh. I didn't see that backscroll. (Relatedly, I thought I had processed a gupnp upload recently?)
[08:20] -queuebot:#ubuntu-release- Packageset: 6615 entries have been added or removed
[08:22] <tjaalton> my understanding was that the exception was acked?
[08:23] <seb128> it seems there is still disagreement on the list of components
[08:23] <seb128> also rbasak said gupnp was ignored since april because it's not on the list
[08:24] <seb128> but silently ignoring items is just confusing, it makes the queue still longer and harder to review for you guys and isn't obvious to the upload what is happening and why
[08:26] <RAOF> I think some of this is a limitation of the tools we're using for SRU process - the queue doesn't have anywhere for us to write notes, other than the linked bugs, and if we do it there it's on one of the possibly-many bugs.
[08:27] <RAOF> I think rbasak has set up some Trello integration, which I really mean to use, but have forgotten the URL to 😐️
[08:29] <RAOF> As far as I'm aware, there hasn't been any advance over https://discourse.ubuntu.com/t/scope-of-gnome-mru/18041/8?u=raof and https://discourse.ubuntu.com/t/scope-of-gnome-mru/18041/9?u=raof for the list of GNOME projects.
[08:30] <rbasak> RAOF: https://trello.com/b/XgBxtrZ9/sru
[08:30] <rbasak> I need to be afk for a bit, but I appreciate the ping and I have stuff to say about this. I'll get back to this thread in 2-3 hours.
[08:31] <seb128> thx
[08:31] <seb128> RAOF, why is it stucked and how to we get the discussion to reach a conclusion?
[08:31] <rbasak> One big issue here, and something I've been unhappy about for a long time, is how the SRU team's workflow means that we're forced to cherry-pick items to process from the various queues, and so stuff just gets ignored without any conclusion.
[08:32] <rbasak> Sort of what RAOF is alluding to also I think, and indeed that's why I made the Trello board but I'm the only one using it :-/
[08:32] <RAOF> I am going to add a link to that Trello board to the StableReleaseUpdates wiki. Just as soon as I can work out how to log into trello again!
[08:32] <rbasak> I added this issue (stuff languishing with nobody on point to make sure that everything gets a decision promptly) to the SRU team's meeting agenda a month or two ago but we haven't got to that yet.
[08:33] <rbasak> Anyway, bbl.
[08:38] <RAOF> seb128: So, if you think the list we have on that Discourse link is missing things, we need to work out a principled way to add things to the list.
[08:39] <seb128> RAOF, I do, see my most recent comment on that discourse
[08:39] <seb128> GNOME games have been consider as GNOME components for ever and we never had issues with those
[08:40] <seb128> also they are games and not high risk, I would prefer to be able to keep having the SRU process light for them if possible
[08:41] <seb128> also https://bugs.launchpad.net/ubuntu/+source/gnome-chess/+bug/1925771 is another example of SRU blocked since april, on that one bdmurray commented at least, but then I replied and nothing since
[08:41] <ubot3> Launchpad bug 1925771 in gnome-chess (Ubuntu Focal) "SRU the current 3.36.2 stable update" [Undecided, New]
[08:41] <RAOF> So, the list I generated was from the GNOME BuildStream thing.
[08:41] <RAOF> I agree that the GNOME games are low-risk, and should have a light SRU process. But I'm not actually the one deciding the SRU process; that's the Tech Board.
[08:42] <RAOF> We need to work out what *is8
[08:42] <RAOF> We need to work out what is covered by the GNOME MRE; that needs to be solidified into a list of packages we can check against.
[08:42] <seb128> right
[08:42] -queuebot:#ubuntu-release- Unapproved: linux-base (hirsute-proposed/main) [4.5ubuntu5.1 => 4.5ubuntu5.2] (core, i386-whitelist)
[08:42] <seb128> my point is that games have been approved under MRE for a decade
[08:43] <seb128> why do we need to make things problematic now?
[08:43] <seb128> what changes that made us consider that those things were ok and are not anymore?
[08:43] <RAOF> I think it has became less clear what "part of GNOME" means.
[08:45] <seb128> should I bring it to the TB to approve the list we propose then?
[08:45] <RAOF> That would be a good idea, I think.
[08:45] -queuebot:#ubuntu-release- Unapproved: linux-base (focal-proposed/main) [4.5ubuntu3.4 => 4.5ubuntu3.5] (core, i386-whitelist)
[08:46] <RAOF> I think an even better outcome would be to work out the process for how we determine whether something is a part of GNOME or not, and take that to the TB.
[08:46] <seb128> RAOF, k, thanks for the input and replies!
[08:47] <RAOF> But I'm not sure if there is a process that could be formalised there? There seems to be a fair amount of “well, it was historically like that” and “this package looks like it might be a part of GNOME, but isn't”, and “this package doesn't follow the GNOME release cycle or version numbering, but should be considered a part of GNOME”…
[08:47] <seb128> well, it's going to be difficult to have a process since GNOME doesn't really provide lists matching what we need there
[08:47] -queuebot:#ubuntu-release- Unapproved: linux-base (bionic-proposed/main) [4.5ubuntu1.5 => 4.5ubuntu1.6] (core)
[08:48] <seb128> historically afaik the intend was to say 'we have confidence in components that follow GNOME freezes and testing and release schedule'
[08:49] <xnox> apw:  never ending linux-base srus that now fix the last regression of not honoring link_in_boot setting, which should now cover all bases. Uploaded with correct -v for each series. Can you please sru-accept them in bionic, focal, hirsute please? (it has migrated to impish release now)
[08:49] <seb128> the respect of freezes is probably the most important part there, it ensure that's bug fix only, no string change, etc
[08:49] <RAOF> That, and the testing.
[08:50]  * RAOF goes to pick up Zoë.
[08:50] <RAOF> Night, seb128!
[08:50] <seb128> RAOF, night, thanks again for eds and for the replies there, I will wait for rbasak to comment later and see how we move forward!
[09:14] <cjwatson> utkarsh2102: Technically possible but I don't have tools for that at present, so I've just bootstrapped that one build again
[09:20] <cjwatson> utkarsh2102: https://launchpad.net/~utkarsh/+archive/ubuntu/symfony-bootstrap/+build/21630239 is dep-wait again
[09:28] <utkarsh2102> cjwatson: ah, so I'll need to keep asking you for bootstrapping everytime?
[09:29] <utkarsh2102> cjwatson: I am not sure about the internals of LP, when vorlon pushed php-twig to the bootstrap repo, does it somehow generate the debs, etc?
[09:30] <utkarsh2102> If I can get those debs, then I can fix this issue via local sbuild (using --extra-package) and then would need to only ask one time at the end, where I'll know it'll work.
[09:32] <utkarsh2102> yet another question: when vorlon pushed php-twig to the bootstrap repo, did php-twig use the existing symfony in the -proposed pocket?
[09:33] <utkarsh2102> I ask this because the patch should've worked on some parts of the dependency resolution and it didn't, which makes me thing that it comes from php-twig's side, which means when php-twig was bootstrapped, existing symfony was used, which is problematic, as we can see in the logs.
[09:37] <utkarsh2102> s/thing/think
[09:51] <cjwatson> utkarsh2102: asking> yes, afraid so
[09:51] <cjwatson> utkarsh2102: Usually the idea is that you prepare things externally and then ask for a procedure you've checked to work, rather than doing it incrementally by experiment
[09:53] <cjwatson> utkarsh2102: The point of the bootstrap repo is to inject debs that have been built somewhere else for use as build-dependencies.  You can point apt to "deb [trusted=yes] https://people.canonical.com/~ubuntu-archive/bootstrap/amd64 impish main" or so to test with it
[09:54] <utkarsh2102> cjwatson: ack, thank you! However, this link is 403 for me; don't have access.
[10:01] <cjwatson> utkarsh2102: It's 403 in a browser because the index isn't visible, but should work if you put that line in a sources.list.
[10:01] <utkarsh2102> perfect, thanks!
[11:10] <rbasak> seb128: o/ I think we're all agreed that what we need is a straightforward unambiguous documented definition of what is and is not covered by the GNOME MRE.
[11:11] <rbasak> IMHO the lack of that is what has been causing the most issues. Even if was always the way it's been done and that continues to be acceptable, there's no reasonable way for new SRU team members to be able to keep things consistent without a documented definition.
[11:12] <rbasak> The Discourse thread is the path to fixing this so we need to get that concluded. Until then, I think we'll be stuck in some confusion, so let's focus our efforts there.
[11:15] <rbasak> I'm not familiar with the existing undocumented criteria, so I've not been looking at GNOME MREs pending getting some better documentation on what is and isn't covered. I'm not sure how I can be expected to do otherwise.
[11:27] <seb128> rbasak, my understand was that desktop team was trusted in defining that when doing a SRU, but fine if that assumption changed
[11:28] <seb128> rbasak, how do we reach consensus on what is acceptable for the list? should desktop describe what we think should be allowed under GNOME MRE and submit to the TB for approval as R_AOF suggested earlier?
[11:48] <rbasak> seb128: I've never understood that to be true. My understanding is that there's some specific approval granted (formerly by the TB, now sometimes by the TB and sometimes by the SRU team depending on specifics) and it's a requirement that the SRU team checks for compliance with that policy as part of the SRU review.
[11:49] <rbasak> seb128: ideally we'd update https://wiki.ubuntu.com/StableReleaseUpdates/GNOME with agreement from all parties that clears up everything so that there is no doubt when you upload one of these MREs that it is covered by that document.
[11:50] <rbasak> seb128: from a policy perspective it doesn't matter who writes the update, so long as it gets approved by the SRU team (and/or the TB if needed). But yes, it'd probably be most useful if you/the desktop team could make suggestions there.
[11:50] <rbasak> Or you could try drafting an update in Discourse if you prefer as that's where the discussion is.
[11:53] <seb128> rbasak, well, Chris made a list, Marco and I had things we would like to see added, what's the processus to decide if those are ok or not, is that something the SRU team should talk about? something to bring to the TB?
[11:54] <seb128> or should be just make the list what we think it should be and submit to approval to <....>?
[11:54] <rbasak> seb128: I suggest you post your proposed list additons to the Discourse thread, and then we can discuss there?
[11:56] <rbasak> Sorry I'm being vague. I'm trying not to dictate any particular method and want to be flexible and accommodating in how any discussion happens. Ultimately I want to see an update to https://wiki.ubuntu.com/StableReleaseUpdates/GNOME but we're not there yet.
[12:06] <laney> bdmurray: rbasak: FYI I've just fixed™ the m-r-package-team-mapping script, the py2 fork, to use the list in lputils.py from lp:ubuntu-archive-tools so updates to that should be reflected in the report again.
[12:10] <seb128> rbasak, T_revinho did suggest addition in comment #9 in septembre but we didn't really manage to get those acked or nacked since, I feel like the SRU team needs to be the one owning moving things forward at this point
[12:26] <rbasak> laney: thank you!
[12:35] <rbasak> seb128: I commented in the thread.
[12:37] <seb128> rbasak, thanks
[13:02] <seb128> someone in ubuntu-archive want to review that trivial change, https://code.launchpad.net/~seb128/ubuntu-archive-scripts/report-team-email/+merge/395129
[14:12] <laney> seb128: do you have access to deploy that?
[14:19] <Eickmeyer[m]> Has anybody taken a look at SRU bug 1928146?
[14:19] <ubot3> Bug 1928146 in nvidia-modprobe (Ubuntu Hirsute) "Please SRU nvidia-modprobe 465.24" [High, Fix Committed] https://launchpad.net/bugs/1928146
[14:31] <seb128> laney, sorry I missed that reply, I might have access but I miss the knowledge ... there is a checkout to manual update?
[14:32] <laney> yes, go to snakefruit, sudo to ubuntu-archive, pull/update in ~/bin/ there
[14:32] <seb128> ah ok, I checked there but for an ubuntu-archive-scripts dir and there was only tools
[14:32] <seb128> thx
[14:34] <seb128> and done now
[14:38] <laney> 👍
[14:44] <seb128> laney, another one you can maybe help with, https://code.launchpad.net/~seb128/britney/+git/britney/+merge/403622 , that's a follow up from the discussion we had some time ago
[15:07] <seb128> laney, thanks
[15:09] <laney> np
[15:40] -queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (hirsute-proposed) [3.38.2.1-3ubuntu1]
[17:49] <erlon> hey folks, I have an SRU that is untouched for quite a while (https://bugs.launchpad.net/cloud-archive/+bug/1832021), who should I talk to get that one rolling?
[17:49] <ubot3> Launchpad bug 1832021 in neutron (Ubuntu Bionic) "Checksum drop of metadata traffic on isolated networks with DPDK" [Medium, New]
[18:09] <bdmurray> erlon: I might be able to help. Can you be more specific about what needs doing?
[18:10] <bdmurray> erlon: Oh, it looks like you need somebody to sponsor a neutron upload to bionic for you.
[18:10] <erlon> bdmurray: yes
[18:11] <bdmurray> However, looking at the debdiff its for bionic-rocky which isn't part of the official Ubuntu archive.
[18:11] <bdmurray> So you'd need to talk to whoever maintains that.
[18:12] <bdmurray> coreycb: ^
[18:16] <coreycb> erlon: rocky is end of life but we do still patch as needed if fixes are required for upgrading through rocky. is a fix needed in bionic (queens)?
[18:18] <erlon> coreycb: bionic queens is right above. I uploaded rocky because someone told me it would be needed
[18:19] <erlon> Comment #26
[18:38] <coreycb> erlon: thanks for the patches, I'll get those uploaded. mind if I add your full name to the changelogs?
[18:47] -queuebot:#ubuntu-release- Unapproved: procps (hirsute-proposed/main) [2:3.3.16-5ubuntu3 => 2:3.3.16-5ubuntu3.1] (core, i386-whitelist)
[18:49] -queuebot:#ubuntu-release- Unapproved: rejected procps [source] (hirsute-proposed) [2:3.3.16-5ubuntu3.1]
[18:51] -queuebot:#ubuntu-release- Unapproved: rejected procps [source] (groovy-proposed) [2:3.3.16-5ubuntu2.2]
[18:51] -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (hirsute-proposed/universe) [0.180 => 0.180ubuntu0.21.04.1] (no packageset)
[18:51] -queuebot:#ubuntu-release- Unapproved: procps (groovy-proposed/main) [2:3.3.16-5ubuntu2.1 => 2:3.3.16-5ubuntu2.2] (core, i386-whitelist)
[18:53] -queuebot:#ubuntu-release- Unapproved: procps (focal-proposed/main) [2:3.3.16-1ubuntu2.1 => 2:3.3.16-1ubuntu2.2] (core, i386-whitelist)
[18:54] -queuebot:#ubuntu-release- Unapproved: rejected procps [source] (focal-proposed) [2:3.3.16-1ubuntu2.2]
[19:13] <bdmurray> jamespage: Did you sil2100's ping in bug 1929179?
[19:13] <ubot3> Bug 1929179 in ceph (Ubuntu Groovy) "[SRU] ceph 15.2.12" [High, Triaged] https://launchpad.net/bugs/1929179
[19:24] <erlon> coreycb: done, I edited it manually right? I mean, there was no need to do all package buildind like I did first to generate it
[19:30] <coreycb> erlon: actually I think that should match what's in your gpg key so let's not fiddle with it. probably worth updating in the future though.
[19:42] -queuebot:#ubuntu-release- Unapproved: accepted alsa-ucm-conf [source] (focal-proposed) [1.2.2-1ubuntu0.8]
[19:46] -queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (focal-proposed) [20.04.11.1]
[20:01] -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (hirsute-proposed) [1.0.0~rc95-0ubuntu1~21.04.1]
[20:05] -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (groovy-proposed) [1.0.0~rc95-0ubuntu1~20.10.1]
[20:06] -queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.1.1-0ubuntu7 => 2:12.1.1-0ubuntu8] (openstack, ubuntu-server)
[20:10] -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (focal-proposed) [1.0.0~rc95-0ubuntu1~20.04.1]
[20:12] -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (bionic-proposed) [1.0.0~rc95-0ubuntu1~18.04.1]
[20:32] <erlon> coreycb: so, my GPG key only had my first name as well. I had that updated, thanks
[20:33] <coreycb> erlon: ok great, thanks
[21:06] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.1.1-0ubuntu8]
[21:51] <vorlon> bdmurray: autopkgtest regressions listed for ubuntu-release-upgrader/hirsute on https://people.canonical.com/~ubuntu-archive/pending-sru.html ?
[21:55] <bdmurray> vorlon: that's a precise removal thing, I've fixed it in impish https://launchpadlibrarian.net/540619289/ubuntu-release-upgrader_1%3A21.10.2_1%3A21.10.3.diff.gz
[22:07] <bdmurray> vorlon: oh, I see I missed the ports in the test change when SRU'ing it. That's why it passed on amd64 and not on other arches.
[22:11] <vorlon> bdmurray: were you going to mark v-done on LP: #1929449?
[22:11] <bdmurray> vorlon: I can do that.
[22:43] <bdmurray> vorlon: dbungert has also verified the fix on a macbook
[23:20] -queuebot:#ubuntu-release- Unapproved: rejected nfs-utils [source] (groovy-proposed) [1:1.3.4-2.5ubuntu6.1]