=== nicoz- is now known as nicoz [16:29] o/ [16:29] ddstreet: teward: o/ [16:32] ddstreet: should we start without teward ? [16:32] mapreri yep let's start, he can catch up [16:33] #startmeeting Ubuntu Backports Team [16:33] Meeting started at 16:33:09 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology [16:33] Available commands: action, commands, idea, info, link, nick [16:34] i'll run thru the previous action items first, assuming the ones marked done are done and just carrying over the rest, please stop me if there's anything we should discuss for them [16:34] #topic Previous Action Items [16:34] #subtopic ddstreet update tooling, requestbackport, backportpackage (carried over) [16:34] #action ddstreet update tooling, requestbackport, backportpackage (carried over) [16:34] ACTION: ddstreet update tooling, requestbackport, backportpackage (carried over) [16:34] #subtopic ddstreet update draft charter to point to team policies at single wiki page, create draft wiki page for team policies [16:34] done [16:34] #subtopic ddstreet send ML email after updating charter [16:34] done [16:34] #subtopic mapreri upload (more of) all the tools (carried over, in progress) [16:35] carrying over, i assume [16:35] ya [16:35] #action mapreri upload (more of) all the tools (carried over, in progress) [16:35] ACTION: mapreri upload (more of) all the tools (carried over, in progress) [16:35] #subtopic mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) [16:35] Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open] [16:35] #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) [16:35] same [16:35] ACTION: mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) [16:35] #subtopic (unassigned) review delegation email on ML [16:35] done? [16:35] no, but let's drop the action, since it's listed in the ML topics also [16:36] #subtopic (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:36] #action (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:36] ACTION: (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:36] #subtopic (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) [16:36] #action (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) [16:36] ACTION: (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) [16:36] ok that's the previous actions, hopefully after some of the more administrative tasks are behind us we'll have more time to address them [16:37] #topic Open Mailing List Threads [16:37] #subtopic clarification on specific wording for no-bug-required backport exceptions [16:37] I feel sorry for the whole #topic :S [16:37] as do i :( [16:38] i think we'll get to this one as well, but we should leave it in the list so we don't lose it [16:38] yes [16:38] hmm im not sure how to mark something other than 'action' with meetingology...i guess i'll just use 'action' and edit the agenda properly later [16:38] #action clarification on specific wording for no-bug-required backport exceptions [16:38] ACTION: clarification on specific wording for no-bug-required backport exceptions [16:38] there is #info I think? [16:39] ah ok lemme try that [16:39] #info clarification on specific wording for no-bug-required backport exceptions [16:39] or #idea or #agreed [16:39] however you should have likely #undo that one before? :P [16:39] #undo [16:39] Removing item from minutes: INFO [16:39] #undo [16:39] Removing item from minutes: ACTION [16:39] i'm not sure how info will appear in the minutes, but let's try it this time [16:39] #info clarification on specific wording for no-bug-required backport exceptions [16:40] don't you love experimenting with bots? :P [16:40] lol [16:40] now i'm excited to see the results after the mtg :) [16:40] anyway, I haven't misplaced the mails in my system, they are just piled up [16:40] as usual [16:40] #subtopic Ratifying a formal delegation [16:40] i think this one is superseded by the charter, so i think we can drop this one? [16:40] they are both a whole pageful away from the current line [16:41] yes [16:41] lol indeed my email inbox is pretty crazy [16:41] #subtopic suggestion to drop request for TB ratification and use simple team approval [16:41] I don't quite agree here [16:41] so, i sent this yesterday, not sure if you had a chance to read it [16:41] ok [16:41] I did [16:42] I'd like to find a better middle-ground between what the TB (→ rbasak, basically? I don't think anybody else answered iirc) would like to see, and what we'd like [16:42] I think his comments were basically saying that too much was in the charter? [16:42] yeah, i dont think anyone else on the TB even read the charter until (maybe) yesterday [16:43] what's with yesterday? [16:43] there was a TB meeting yesterday [16:43] they did not review or discuss the charter though unfortunately [16:43] i did put it on the TB agenda right after their mtg 2 weeks ago (or maybe before) [16:44] I'd find surprising if anybody ever look at a meeting agenda before a meeting [16:44] I sure don't :( [16:44] * rbasak is here but has no comment at the moment [16:44] i think the main thing for me is, i feel we (i.e. our team) has done the work to create the charter/rules/policies we want to use for running our team; i think we would all like for the TB to ratify it, but what I don't want to do is engage with the TB in any long discussions about various changes to the charter [16:45] But I'm happy to clarify anything if you'd like [16:45] i think our team should assume the charter is good, and move on with that assumption; the TB is totally able to review and ratify it at their own pace [16:45] If you think I'm proposing to change your charter, then you misunderstand [16:45] ddstreet: I don't think it's fair for you to expect somebody to ratify something but at the same time not giving them the right to express opinions on it [16:46] no that's not what i mean [16:46] expressing opinions is fine [16:46] but what i'd expect from the TB is specific requests for changes [16:46] as a whole, i.e. en banc [16:46] ok, I think I see your point [16:46] like, i'd expect the TB to have whatever discussion about our charter that they want [16:47] and then, come back to us saying 'we would liek you to cahnge XYZ...' [16:47] mind if I take some time to re-read the TB thread again, to better understand rbasak's views (I didn't really pay attention when I read before), and see if I can help move it forward somehow. [16:47] anyway, it's not like this is blocking our daily work [16:47] sure exactly [16:48] but please don't just drop it all [16:48] i do think it's important to *have* a charter our team agrees on, *preferably* that is ratified by our governing body, but our team should not get bogged down with lengthy discussions over the specific details of the charter [16:49] we've basically done that and we should move on with trying to fulfill our mission statement [16:49] agree, and I think we are on that route. We are hardly "bogged" when you can count the total emails over a month with your hands :) [16:49] ok so i'll drop this (i'll follow up to the ML too) [16:49] mh [16:50] well i'm trying to insulate everone else on our team from the administrivia of getting this charter finalized/ratified :) [16:50] can you add (or I'll later) a link to the TB thread instead? [16:50] sure let me add it here [16:50] #link https://lists.ubuntu.com/archives/technical-board/2022-March/002620.html [16:50] (I meant in the running agenda) [16:51] and for reference, this is the charter version submitted to the TB [16:51] #link https://wiki.ubuntu.com/UbuntuBackports/Charter?action=recall&rev=5 [16:51] ah right i'll add it there as well [16:51] #info https://lists.ubuntu.com/archives/technical-board/2022-March/002620.html [16:51] let's continue? [16:52] and also FYI, i did some rewording of the charter but i'll revert that back to the original version (as linked above, rev=5) [16:52] yep [16:52] ok that's all the ML threads [16:52] #topic open bugs [16:52] #subtopic update backportpackage and requestbackport scripts to behave according to new backport process [16:52] think this will get attention in the future as well [16:52] that's also in the actions… carried-over [16:53] yep, i'll remove from the open bugs list [16:53] meta-question, do you think we need a open bugs review section? [16:53] maybe not [16:53] we do, but I don't think we need to manually list all open bugs in the wiki… [16:53] like, I do have bugs I'd like to discuss/mention during a meeting, but I doubt we need all of them there [16:54] sounds good, let's just leave the section then and i won't add specific bugs [16:54] or one can add in advance the bugs he'd like to discuss, for example [16:54] but I doubt mass-copying them is useful use of your time :) [16:54] yep that sounds good [16:55] yeah it isn't, i was thinking that while i did it today :) [16:55] any you want to bring up? i think the only one for me is the debhelper i386 bug [16:55] on that note [16:55] yep [16:55] 2 things [16:56] 1) I just turned down (marked as "incomplete") 2 bugs (primecount and obfs4proxy) that were basically just plain requests for backports, rather than tracking bugs for things already uploaded/in the process of uploads. also the submitter had new lp accounts, so I guess they are not active contributors either. [16:57] should we highlight on the wiki more that we don't take those kind of requests? [16:57] probably so, though i'm not sure what the best guidance is for people who don't know how to get a sponsor [16:58] for those, it's "subscribe ~ubuntu-sponsors` [16:58] but that's not the case here, I think those are just power-users or somesuch [16:58] they didn't provide diffs, test cases, links to ppa, etc. [16:58] i think it's a problem for SRUs as well, hence the ubuntu-sponsors backlog https://reqorts.qa.ubuntu.com/reports/sponsoring/ [16:58] well, ~ubuntu-sponsors being backlogged is a separate matter [16:59] definitely [16:59] that page is not looking too bad tbh [16:59] but the pool of people who can provide sponsorship is basically the same [16:59] for srus or bpos [16:59] a few years ago when I was actively sponsoring things in ubuntu it was routinely much worse [16:59] a bit more red than i'd like, but yeah it's definitely smaller than it used to be [17:00] i guess the question of 'how to get a sponsor' isn't really something we can answer though [17:00] but that's not the problem [17:00] and i am +1 on highlighting that just opening a bug isn't enough, they need to do the work and get a sponsor [17:00] it's that those requests were not even from people who likely would even do the work *shrugs* [17:00] yep [17:01] I'll try to re-read our welcoming page, see if I can imagine how to highlight this detail. but if you have ideas do go ahead :) [17:01] do you want to edit the wiki to add that? i'm sure i will be fine with whatever wording you add [17:01] sounds good, should i add an action just to track it? [17:01] pls [17:01] you want to take it? [17:01] sure why not [17:01] thanks :) [17:02] #action mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor [17:02] ACTION: mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor [17:02] ok was there another thing before the debhelper bug? [17:02] 2) about memtest86+ and feeipmi. we should really decide what to do here. honestly, I'd feel quite bad at rejecting them. they do provide quite some value over the status quo, even if focal itself would stay buggier. [17:03] and it's not like rejecting them would convince the maintainer to produce patches [17:03] i agree, the new maintainer was pretty clear they weren't going to bother trying to patch the focal version [17:03] because of too many changes [17:03] which is fair [17:04] yep i was going to say the same thing [17:04] both packages were undermaintained/unmaintained before him, so they have a huge amount of changes in-between [17:04] i think we both are leaning towards approving the backports, but do you think we should try to have some kind of official policy before doing it? [17:04] or we could just decide it's a case-by-case basis [17:05] it's definitely a case-by-case basis [17:05] besides [17:05] we could just be tricked into them if the proposer would have listed a few new features "forgetting" to mention the fixed bugs... [17:06] lol that's certainly true [17:06] so +1 in accepting both of them? [17:06] since you like playing with the both, do you want to set up a vote? :P [17:06] bot * [17:06] lol sure let's do it :) [17:07] #vote accept memtest86+ backport [17:07] Please vote on: accept memtest86+ backport [17:07] Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') [17:07] +1 [17:07] +1 received from mapreri [17:07] +1 [17:07] +1 received from ddstreet [17:07] hurray! :) [17:07] #endvote [17:07] Voting ended on: accept memtest86+ backport [17:07] Votes for: 2, Votes against: 0, Abstentions: 0 [17:07] Motion carried [17:07] oh so fancy [17:08] freeipmi included, I guess? [17:08] i'd looked at it even before the backport was opened, it definitely needed updating, i was unable to get it working even in a VM [17:08] yep [17:08] I'll follow up on the bugs myself [17:08] #vote accept freeipmi backport [17:08] Please vote on: accept freeipmi backport [17:08] Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') [17:08] +1 [17:08] +1 received from mapreri [17:09] +1 i don't have as much previous experience with this, but agree to the backport [17:09] +1 i don't have as much previous experience with this, but agree to the backport received from ddstreet [17:09] #endvote [17:09] Voting ended on: accept freeipmi backport [17:09] Votes for: 2, Votes against: 0, Abstentions: 0 [17:09] Motion carried [17:10] well voting is fun :) [17:10] heh [17:10] ok you'll handle approving those? [17:10] I think you can use #voters in advance, iirc that also automatically closes the vote once everybody's done [17:10] yep, I'll take them [17:10] ah ok cool, i did not know that [17:10] #action mapreri handle approval for backports of memtest86+ and freeipmi [17:10] ACTION: mapreri handle approval for backports of memtest86+ and freeipmi [17:11] ok want to talk about debhelper for focal-i386? [17:11] that uh [17:11] well [17:11] for reference [17:11] #link https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800 [17:11] Launchpad bug 1965800 in debugedit (Ubuntu) "debhelper in focal-backports not usable for i386 package building (missing dependency)" [Undecided, New] [17:11] i guess, do we care about i386, is the first question? [17:12] well, I blame whoever decided it was a good idea to keep the arch half-alive. (to start :P) [17:12] lol indeed [17:12] I don't think it's a problem to backport debugedit, as it would just use (or we can make it use) focal's debhelper to build, not pulling the non-installable debhelper. [17:13] i personally dont care about i386 but i also think since it is 'half-alive' as you said, we shouldn't ignore it [17:13] hmm are you sure? [17:13] what I think might be a problem, is that I'm not sure if just doing it would trigger the i386 build, or whetever it would need an extra entry in the focal/i386-whitelist set [17:14] https://launchpad.net/~ddstreet/+archive/ubuntu/backport [17:14] mh [17:14] does the bpo archive have the same priority as the main archive in launchpad buildds? [17:14] that's unexpected [17:15] i think the problem is that the apt resolution doesn't do 'fallback' to older version(s) if the 'latest' (i.e. 'current') version isn't installable due to missing deps [17:15] but that's only if the bpo archive has the same priority, which really shouldn't be [17:16] since NotAutomatic+ButAutomaticUpgrades afaik makes apt consider that repo with a lower enough priority that it won't pull things from it automatically [17:16] so I wonder if launchpad is configured specially there [17:16] yeah, that i dont know [17:17] i guess we could either ask an archive admin in -devel channel, or we could just try backporting debugedit and see if it fails? [17:17] even then, that's workaroundable by "bootstrapping" it with a relaxed debhelper, then debugedit, then debhelper re-enabling that thing again [17:18] I think we could try uploading debugedit and see what happens. I'm mostly afraid of the i386-whitelist myself, than this. [17:18] so i guess separate from the bit about how specifically to backport debugedit, what do you think about either backporting it or removing its dep from the backported debhelper? [17:18] probably we should just backport it? [17:19] in the bug you mentioned you were for option 1 (remove the need for it from backported debhelper) [17:19] #link https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800/comments/2 [17:19] in generally, I am for option 1. [17:19] Launchpad bug 1965800 in debugedit (Ubuntu) "debhelper in focal-backports not usable for i386 package building (missing dependency)" [Undecided, New] [17:20] let's just do that than, it will remove the need for us to worry about how to backport debugedit [17:20] that case Matthias' mentions is very rare really, only about different packages building the same object in what are basically the same conditions... [17:20] it's, like.. very rare [17:20] I think I saw it a few times with a some plugin-like thing [17:20] want to do a vote on it? :) [17:20] #voters mapreri ddstreet [17:20] Current voters: ddstreet, mapreri [17:21] #vote adjust debhelper focal-backport to remove dep on debugedit [17:21] Please vote on: adjust debhelper focal-backport to remove dep on debugedit [17:21] Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') [17:21] (i think it's only needed in the focal-backport right?) [17:21] yes [17:21] +1 [17:21] +1 received from ddstreet [17:21] +1 [17:21] +1 received from mapreri [17:22] mh, so it's not closed after all? guess I misremember [17:22] come on meetingology i was promised you would automatically end the vote! ;-) [17:22] lol [17:22] #endvote [17:22] Voting ended on: adjust debhelper focal-backport to remove dep on debugedit [17:22] sooorrryyyy :( [17:22] Votes for: 2, Votes against: 0, Abstentions: 0 [17:22] Motion carried [17:22] alright, I'll revert that change for focal only. [17:23] sounds good, and i assume you'll use the latest debhelper for the updated backport, so that will cover lp:#1965758 also? [17:23] Launchpad bug 1965758 in debhelper (Ubuntu Impish) "[BPO] debhelper/13.6ubuntu1 from jammy to bionic, focal, impish" [Undecided, New] https://launchpad.net/bugs/1965758 [17:24] besides, I *think* (but I'm not sure) that debhelper in focal doesn't have that change of changing the build-id anyway. [17:24] so it's not like we'd be regressing thing "within" focal [17:24] and yes [17:24] ok i'll action it [17:25] #action mapreri handle debhelper backport including revert dep on debugedit for focal-backports [17:25] ACTION: mapreri handle debhelper backport including revert dep on debugedit for focal-backports [17:25] that's all the bugs, i think, unless you had any others to discuss [17:25] #topic AOB [17:25] nothing from me for AOB [17:25] and we're almost at the hour [17:26] so good timing i guess :) [17:26] anything else from you? [17:26] no, I'm good [17:26] awesome [17:26] we had what effectively was a non-rushed meeting, which was nice [17:26] yep, i think it was good :) [17:26] see you in 1 month again? [17:26] last topic, next meeting [17:26] yeah! :) [17:26] #action ddstreet schedule next mtg for 1 month [17:26] ACTION: ddstreet schedule next mtg for 1 month [17:27] great, thanks! [17:27] #endmeeting [17:27] Meeting ended at 17:27:04 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-04-06-16.33.moin.txt [17:27] thanks mapreri see you next month! :) [17:27] o/ thank you too! [17:29] ddstreet: looking at the generated minutes, I think you could use #info also when you say "done" in the action item reviews. that should drop a "done" sub-item in the list [17:30] ah good point ok! thanks [17:30] however I also see that https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-04-06-16.33.html doesn't really render a series of #subtopic properly, like it's not going back a level (always in the "previous action items" section) [17:32] i might have to play around with it in a fake meeting sometime :) [17:32] though, we don't *really* need as much formality as it provides...especially with just 2 of us ;-) [17:32] we don't, but ain't it fun!? :3 [17:34] yes! lol [18:06] ddstreet: all day training sorry for not emailimg sooner. 3rd day