[15:00] @pilot in === JanC is now known as Guest9792 === JanC_ is now known as JanC [15:10] Can a core dev please retry these: `retry-autopkgtest-regressions -s focal --blocks util-linux | grep -v ubiquity`? The systemd failure is often flaky, and the nfs-utils passed for me locally so it should be retried. [15:31] enr0n: done [15:31] vorlon: thanks! [16:17] I wonder if we can expand the set of people who can trigger autopkgtest regressions. Does it need to be restricted to core devs? [16:17] who can trigger autopkgtest retries I mean. Please do not trigger regressions :) [16:24] rbasak: yeah, I think that would be very helpful. IIRC the foundations team spent some time talking about this in Prague. I think there was an idea to have a team (similar to ubuntu bug control) where members would have permission to retry tests. [16:24] Yes [16:30] What's the necessary criteria? Would ~ubuntu-developer-members do? [16:31] (or a superset of that by all means) [16:31] But ~ubuntu-uploaders + ~ubuntu-developer-members would make it easy, and I'm not sure there's much risk of there being a problem caused by that? [16:38] rbasak: I thought autopkgtest checks uploader permissions? [16:45] I thought it was core dev only [16:45] (rather than checking per-package permissions and enforcing that) [16:45] Either way its a smaller group of people than is useful [16:45] Right === JanC_ is now known as JanC [16:59] I'm not core dev and have (in the increasingly distant past) been able to retrigger tests on packages I could upload. [17:02] Thanks. Maybe it was implemented and I'm remembering a previous state of affairs. But I agree with Brian that we should consider expanding the set of "retriers" further - there's no need to limit it to the package uploader IMHO as negative consequences wouldn't be as severe. Just a DoS? So anyone we can trust and who has a chance of understanding our expectations, IMHO. [17:03] I guess the concern with using pre-existing teams would be if someone in those teams thought they were being helpful but were in fact just DoS'ing the runners, then there wouldn't be a(n easy Launchpad-driven) way of stopping them, short of revoking a much broader set of privileges. [17:05] We trust them though, so we could just ask. If they're not around and left a script running, I think temporarily removing them from a team until they can interact with us, as an emergency measure, would be OK. [17:05] My criteria would be those that can filter third party requests because they either know the details, or know who to ask or where to look to answer that question. [17:06] if it's a DoS bad enough for us to care, the autopkgtest admins can delete requests from the queue and slap the responsible party with a fish [17:06] So anyone we know to be a real person and not a sockpuppet, and eg. knows about this channel. [17:07] But that's hard to define and manage, but I hoped ~ubuntu-uploader and ~ubuntu-developer-members would be acceptable as a subset of that. As well as any other teams that clearly meet these criteria. [17:09] * rbasak EODs [17:10] no disagreement, I think it's just a matter of working through the details === JanC_ is now known as JanC [19:18] It's essentially the ability to run arbitrary code - with some level of internet access (as opposed to PPA builds) - inside ScalingStack, that's why the ACL was set up as it was. The same ACL lets, or did let, you trigger for packages from PPAs. But you only need to be able to trigger /one/ package to be able to do that. The other small risk is being able to add new triggers can cause packages to [19:18] migrate but not necessarily with the new ... [19:18] ... trigger, it's something that should be done with care. [19:19] But not insurmountable stuff. Huh, why did irssi break the lines like that [19:38] laney: irc has line length limits (the limit for any given message changes with the channel or user that the message is being sent to, since that's part of the message) -- some clients just drop all the rest of it on the floor, irssi splits the messages so the whole thing gets sent [19:44] @pilot out [19:46] sarnold: yeh, it just split it in a silly way [19:49] laney: did you insert the ... breaks yourself? or did you get two automatic line breaks? [19:59] laney: I opened bug 2022958 if you want to comment there [19:59] -ubottu:#ubuntu-devel- Bug 2022958 in Auto Package Testing "More people should be able to trigger autopkgtests" [High, Triaged] https://launchpad.net/bugs/2022958 [20:33] Can a core dev please trigger this PPA autopkgtest? https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=cron&ppa=enr0n/proposed-migration&trigger=cron/3.0pl1-162ubuntu1~ppa1 [20:42] enr0n: done [20:42] sergiodj: thanks! [20:42] my pleasure! [21:05] Unit193: ^ bot broken? It didn't change the topic when v_orlon signed in and out today :-/ [21:06] laney: thanks - that's useful background, and yeah the arbitrary code thing makes it equivalent to someone who can upload _something_ I guess, so if that's hard to change then it's equivalent to ~ubuntu-uploaders maybe? [21:13] sarnold: irssi did it all [21:15] laney: okay that's weird :) [21:16] @pilot in [21:17] Huh! :o [21:17] laney: there's a splitlong.pl on https://scripts.irssi.org/ that uses "..." markers by default; maybe you've got that installed? [21:17] something's wrong with SSH, it keeps dying after a minute so I'll probably park investigating for now [21:18] and just say... rbasak: yes, for the code execution part :-) [21:18] oh, and the bot thing is probably because of mode +t, I would remove that [21:20] rbasak, Unit193: Well, as it turns out somehow ubottu got reset and the UdevTopic plugin isn't even loaded anymore currently. :o [21:33] Well that's fantastic... [21:34] sarnold, laney: A number of years ago irssi didn't split long messages, so people used splitlong.pl to fix that problem. It has since become a core feature and anyone that still has splitlong.pl now splits in two places.