16:33 <ddstreet> #startmeeting Ubuntu Backports Team
16:33 <meetingology> Meeting started at 16:33:09 UTC.  The chair is ddstreet.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
16:33 <meetingology> Available commands: action, commands, idea, info, link, nick
16:34 <ddstreet> 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 <ddstreet> #topic Previous Action Items
16:34 <ddstreet> #subtopic ddstreet update tooling, requestbackport, backportpackage (carried over)
16:34 <ddstreet> #action ddstreet update tooling, requestbackport, backportpackage (carried over)
16:34 * meetingology ddstreet update tooling, requestbackport, backportpackage (carried over)
16:34 <ddstreet> #subtopic ddstreet update draft charter to point to team policies at single wiki page, create draft wiki page for team policies
16:34 <ddstreet> done
16:34 <ddstreet> #subtopic ddstreet send ML email after updating charter
16:34 <ddstreet> done
16:34 <ddstreet> #subtopic mapreri upload (more of) all the tools (carried over, in progress)
16:35 <ddstreet> carrying over, i assume
16:35 <mapreri> ya
16:35 <ddstreet> #action mapreri upload (more of) all the tools (carried over, in progress)
16:35 * meetingology mapreri upload (more of) all the tools (carried over, in progress)
16:35 <ddstreet> #subtopic mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
16:35 <ubottu> Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open]
16:35 <ddstreet> #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
16:35 * meetingology mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
16:35 <mapreri> same
16:35 <ddstreet> #subtopic (unassigned) review delegation email on ML
16:35 <mapreri> done?
16:35 <ddstreet> no, but let's drop the action, since it's listed in the ML topics also
16:36 <ddstreet> #subtopic (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
16:36 <ddstreet> #action (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
16:36 * meetingology (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
16:36 <ddstreet> #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 <ddstreet> #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 * meetingology (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 <ddstreet> 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 <ddstreet> #topic Open Mailing List Threads
16:37 <ddstreet> #subtopic clarification on specific wording for no-bug-required backport exceptions
16:37 <mapreri> I feel sorry for the whole #topic :S
16:37 <ddstreet> as do i :(
16:38 <ddstreet> 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 <mapreri> yes
16:38 <ddstreet> 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 <ddstreet> #action clarification on specific wording for no-bug-required backport exceptions
16:38 * meetingology clarification on specific wording for no-bug-required backport exceptions
16:38 <mapreri> there is #info I think?
16:39 <ddstreet> ah ok lemme try that
16:39 <ddstreet> #info clarification on specific wording for no-bug-required backport exceptions
16:39 <mapreri> or #idea or #agreed
16:39 <mapreri> however you should have likely #undo that one before? :P
16:39 <ddstreet> #undo
16:39 <meetingology> Removing item from minutes: INFO
16:39 <ddstreet> #undo
16:39 <meetingology> Removing item from minutes: ACTION
16:39 <ddstreet> i'm not sure how info will appear in the minutes, but let's try it this time
16:39 <ddstreet> #info clarification on specific wording for no-bug-required backport exceptions
16:40 <mapreri> don't you love experimenting with bots? :P
16:40 <ddstreet> lol
16:40 <ddstreet> now i'm excited to see the results after the mtg :)
16:40 <mapreri> anyway, I haven't misplaced the mails in my system, they are just piled up
16:40 <mapreri> as usual
16:40 <ddstreet> #subtopic Ratifying a formal delegation
16:40 <ddstreet> i think this one is superseded by the charter, so i think we can drop this one?
16:40 <mapreri> they are both a whole pageful away from the current line
16:41 <mapreri> yes
16:41 <ddstreet> lol indeed my email inbox is pretty crazy
16:41 <ddstreet> #subtopic suggestion to drop request for TB ratification and use simple team approval
16:41 <mapreri> I don't quite agree here
16:41 <ddstreet> so, i sent this yesterday, not sure if you had a chance to read it
16:41 <ddstreet> ok
16:41 <mapreri> I did
16:42 <mapreri> 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 <mapreri> I think his comments were basically saying that too much was in the charter?
16:42 <ddstreet> yeah, i dont think anyone else on the TB even read the charter until (maybe) yesterday
16:43 <mapreri> what's with yesterday?
16:43 <ddstreet> there was a TB meeting yesterday
16:43 <ddstreet> they did not review or discuss the charter though unfortunately
16:43 <ddstreet> i did put it on the TB agenda right after their mtg 2 weeks ago (or maybe before)
16:44 <mapreri> I'd find surprising if anybody ever look at a meeting agenda before a meeting
16:44 <mapreri> I sure don't :(
16:44 * rbasak is here but has no comment at the moment
16:44 <ddstreet> 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 <rbasak> But I'm happy to clarify anything if you'd like
16:45 <ddstreet> 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 <rbasak> If you think I'm proposing to change your charter, then you misunderstand
16:45 <mapreri> 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 <ddstreet> no that's not what i mean
16:46 <ddstreet> expressing opinions is fine
16:46 <ddstreet> but what i'd expect from the TB is specific requests for changes
16:46 <ddstreet> as a whole, i.e. en banc
16:46 <mapreri> ok, I think I see your point
16:46 <ddstreet> like, i'd expect the TB to have whatever discussion about our charter that they want
16:47 <ddstreet> and then, come back to us saying 'we would liek you to cahnge XYZ...'
16:47 <mapreri> 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 <mapreri> anyway, it's not like this is blocking our daily work
16:47 <ddstreet> sure exactly
16:48 <mapreri> but please don't just drop it all
16:48 <ddstreet> 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 <ddstreet> we've basically done that and we should move on with trying to fulfill our mission statement
16:49 <mapreri> 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 <ddstreet> ok so i'll drop this (i'll follow up to the ML too)
16:49 <mapreri> mh
16:50 <ddstreet> well i'm trying to insulate everone else on our team from the administrivia of getting this charter finalized/ratified :)
16:50 <mapreri> can you add (or I'll later) a link to the TB thread instead?
16:50 <ddstreet> sure let me add it here
16:50 <ddstreet> #link https://lists.ubuntu.com/archives/technical-board/2022-March/002620.html
16:50 <mapreri> (I meant in the running agenda)
16:51 <ddstreet> and for reference, this is the charter version submitted to the TB
16:51 <ddstreet> #link https://wiki.ubuntu.com/UbuntuBackports/Charter?action=recall&rev=5
16:51 <ddstreet> ah right i'll add it there as well
16:51 <ddstreet> #info https://lists.ubuntu.com/archives/technical-board/2022-March/002620.html
16:52 <mapreri> let's continue?
16:52 <ddstreet> 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 <ddstreet> yep
16:52 <ddstreet> ok that's all the ML threads
16:52 <ddstreet> #topic open bugs
16:52 <ddstreet> #subtopic update backportpackage and requestbackport scripts to behave according to new backport process
16:52 <ddstreet> think this will get attention in the future as well
16:52 <mapreri> that's also in the actions… carried-over
16:53 <ddstreet> yep, i'll remove from the open bugs list
16:53 <ddstreet> meta-question, do you think we need a open bugs review section?
16:53 <ddstreet> maybe not
16:53 <mapreri> we do, but I don't think we need to manually list all open bugs in the wiki…
16:53 <mapreri> 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 <ddstreet> sounds good, let's just leave the section then and i won't add specific bugs
16:54 <mapreri> or one can add in advance the bugs he'd like to discuss, for example
16:54 <mapreri> but I doubt mass-copying them is useful use of your time :)
16:54 <ddstreet> yep that sounds good
16:55 <ddstreet> yeah it isn't, i was thinking that while i did it today :)
16:55 <ddstreet> any you want to bring up? i think the only one for me is the debhelper i386 bug
16:55 <mapreri> on that note
16:55 <mapreri> yep
16:55 <mapreri> 2 things
16:56 <mapreri> 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 <mapreri> should we highlight on the wiki more that we don't take those kind of requests?
16:57 <ddstreet> 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 <mapreri> for those, it's "subscribe ~ubuntu-sponsors`
16:58 <mapreri> but that's not the case here, I think those are just power-users or somesuch
16:58 <mapreri> they didn't provide diffs, test cases, links to ppa, etc.
16:58 <ddstreet> i think it's a problem for SRUs as well, hence the ubuntu-sponsors backlog https://reqorts.qa.ubuntu.com/reports/sponsoring/
16:58 <mapreri> well, ~ubuntu-sponsors being backlogged is a separate matter
16:59 <ddstreet> definitely
16:59 <mapreri> that page is not looking too bad tbh
16:59 <ddstreet> but the pool of people who can provide sponsorship is basically the same
16:59 <ddstreet> for srus or bpos
16:59 <mapreri> a few years ago when I was actively sponsoring things in ubuntu it was routinely much worse
16:59 <ddstreet> a bit more red than i'd like, but yeah it's definitely smaller than it used to be
17:00 <ddstreet> i guess the question of 'how to get a sponsor' isn't really something we can answer though
17:00 <mapreri> but that's not the problem
17:00 <ddstreet> 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 <mapreri> it's that those requests were not even from people who likely would even do the work *shrugs*
17:00 <ddstreet> yep
17:01 <mapreri> 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 <ddstreet> do you want to edit the wiki to add that? i'm sure i will be fine with whatever wording you add
17:01 <ddstreet> sounds good, should i add an action just to track it?
17:01 <mapreri> pls
17:01 <ddstreet> you want to take it?
17:01 <mapreri> sure why not
17:01 <ddstreet> thanks :)
17:02 <ddstreet> #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 * meetingology 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 <ddstreet> ok was there another thing before the debhelper bug?
17:02 <mapreri> 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 <mapreri> and it's not like rejecting them would convince the maintainer to produce patches
17:03 <ddstreet> i agree, the new maintainer was pretty clear they weren't going to bother trying to patch the focal version
17:03 <ddstreet> because of too many changes
17:03 <mapreri> which is fair
17:04 <ddstreet> yep i was going to say the same thing
17:04 <mapreri> both packages were undermaintained/unmaintained before him, so they have a huge amount of changes in-between
17:04 <ddstreet> 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 <ddstreet> or we could just decide it's a case-by-case basis
17:05 <mapreri> it's definitely a case-by-case basis
17:05 <mapreri> besides
17:05 <mapreri> 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 <ddstreet> lol that's certainly true
17:06 <mapreri> so +1 in accepting both of them?
17:06 <mapreri> since you like playing with the both, do you want to set up a vote? :P
17:06 <mapreri> bot *
17:06 <ddstreet> lol sure let's do it :)
17:07 <ddstreet> #vote accept memtest86+ backport
17:07 <meetingology> Please vote on: accept memtest86+ backport
17:07 <meetingology> 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 <mapreri> +1
17:07 <meetingology> +1 received from mapreri
17:07 <ddstreet> +1
17:07 <meetingology> +1 received from ddstreet
17:07 <ddstreet> hurray! :)
17:07 <ddstreet> #endvote
17:07 <meetingology> Voting ended on: accept memtest86+ backport
17:07 <meetingology> Votes for: 2, Votes against: 0, Abstentions: 0
17:07 <meetingology> Motion carried
17:07 <mapreri> oh so fancy
17:08 <mapreri> freeipmi included, I guess?
17:08 <ddstreet> 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 <ddstreet> yep
17:08 <mapreri> I'll follow up on the bugs myself
17:08 <ddstreet> #vote accept freeipmi backport
17:08 <meetingology> Please vote on: accept freeipmi backport
17:08 <meetingology> 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 <mapreri> +1
17:08 <meetingology> +1 received from mapreri
17:09 <ddstreet> +1 i don't have as much previous experience with this, but agree to the backport
17:09 <meetingology> +1 i don't have as much previous experience with this, but agree to the backport received from ddstreet
17:09 <ddstreet> #endvote
17:09 <meetingology> Voting ended on: accept freeipmi backport
17:09 <meetingology> Votes for: 2, Votes against: 0, Abstentions: 0
17:09 <meetingology> Motion carried
17:10 <ddstreet> well voting is fun :)
17:10 <mapreri> heh
17:10 <ddstreet> ok you'll handle approving those?
17:10 <mapreri> I think you can use #voters in advance, iirc that also automatically closes the vote once everybody's done
17:10 <mapreri> yep, I'll take them
17:10 <ddstreet> ah ok cool, i did not know that
17:10 <ddstreet> #action mapreri handle approval for backports of memtest86+ and freeipmi
17:10 * meetingology mapreri handle approval for backports of memtest86+ and freeipmi
17:11 <ddstreet> ok want to talk about debhelper for focal-i386?
17:11 <mapreri> that uh
17:11 <mapreri> well
17:11 <ddstreet> for reference
17:11 <ddstreet> #link https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800
17:11 <ubottu> Launchpad bug 1965800 in debugedit (Ubuntu) "debhelper in focal-backports not usable for i386 package building (missing dependency)" [Undecided, New]
17:11 <ddstreet> i guess, do we care about i386, is the first question?
17:12 <mapreri> well, I blame whoever decided it was a good idea to keep the arch half-alive.  (to start :P)
17:12 <ddstreet> lol indeed
17:12 <mapreri> 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 <ddstreet> 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 <ddstreet> hmm are you sure?
17:13 <mapreri> 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 <ddstreet> https://launchpad.net/~ddstreet/+archive/ubuntu/backport
17:14 <mapreri> mh
17:14 <mapreri> does the bpo archive have the same priority as the main archive in launchpad buildds?
17:14 <mapreri> that's unexpected
17:15 <ddstreet> 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 <mapreri> but that's only if the bpo archive has the same priority, which really shouldn't be
17:16 <mapreri> 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 <mapreri> so I wonder if launchpad is configured specially there
17:16 <ddstreet> yeah, that i dont know
17:17 <ddstreet> 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 <mapreri> even then, that's workaroundable by "bootstrapping" it with a relaxed debhelper, then debugedit, then debhelper re-enabling that thing again
17:18 <mapreri> I think we could try uploading debugedit and see what happens.  I'm mostly afraid of the i386-whitelist myself, than this.
17:18 <ddstreet> 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 <ddstreet> probably we should just backport it?
17:19 <ddstreet> in the bug you mentioned you were for option 1 (remove the need for it from backported debhelper)
17:19 <ddstreet> #link https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800/comments/2
17:19 <mapreri> in generally, I am for option 1.
17:19 <ubottu> Launchpad bug 1965800 in debugedit (Ubuntu) "debhelper in focal-backports not usable for i386 package building (missing dependency)" [Undecided, New]
17:20 <ddstreet> let's just do that than, it will remove the need for us to worry about how to backport debugedit
17:20 <mapreri> 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 <mapreri> it's, like.. very rare
17:20 <mapreri> I think I saw it a few times with a some plugin-like thing
17:20 <ddstreet> want to do a vote on it? :)
17:20 <ddstreet> #voters mapreri ddstreet
17:20 <meetingology> Current voters: ddstreet, mapreri
17:21 <ddstreet> #vote adjust debhelper focal-backport to remove dep on debugedit
17:21 <meetingology> Please vote on: adjust debhelper focal-backport to remove dep on debugedit
17:21 <meetingology> 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 <ddstreet> (i think it's only needed in the focal-backport right?)
17:21 <mapreri> yes
17:21 <ddstreet> +1
17:21 <meetingology> +1 received from ddstreet
17:21 <mapreri> +1
17:21 <meetingology> +1 received from mapreri
17:22 <mapreri> mh, so it's not closed after all?  guess I misremember
17:22 <ddstreet> come on meetingology i was promised you would automatically end the vote! ;-)
17:22 <ddstreet> lol
17:22 <ddstreet> #endvote
17:22 <meetingology> Voting ended on: adjust debhelper focal-backport to remove dep on debugedit
17:22 <mapreri> sooorrryyyy :(
17:22 <meetingology> Votes for: 2, Votes against: 0, Abstentions: 0
17:22 <meetingology> Motion carried
17:22 <mapreri> alright, I'll revert that change for focal only.
17:23 <ddstreet> sounds good, and i assume you'll use the latest debhelper for the updated backport, so that will cover lp:#1965758 also?
17:23 <ubottu> 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 <mapreri> 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 <mapreri> so it's not like we'd be regressing thing "within" focal
17:24 <mapreri> and yes
17:24 <ddstreet> ok i'll action it
17:25 <ddstreet> #action mapreri handle debhelper backport including revert dep on debugedit for focal-backports
17:25 * meetingology mapreri handle debhelper backport including revert dep on debugedit for focal-backports
17:25 <ddstreet> that's all the bugs, i think, unless you had any others to discuss
17:25 <ddstreet> #topic AOB
17:25 <ddstreet> nothing from me for AOB
17:25 <ddstreet> and we're almost at the hour
17:26 <ddstreet> so good timing i guess :)
17:26 <ddstreet> anything else from you?
17:26 <mapreri> no, I'm good
17:26 <ddstreet> awesome
17:26 <mapreri> we had what effectively was a non-rushed meeting, which was nice
17:26 <ddstreet> yep, i think it was good :)
17:26 <mapreri> see you in 1 month again?
17:26 <ddstreet> last topic, next meeting
17:26 <ddstreet> yeah! :)
17:26 <ddstreet> #action ddstreet schedule next mtg for 1 month
17:26 * meetingology ddstreet schedule next mtg for 1 month
17:27 <ddstreet> great, thanks!
17:27 <ddstreet> #endmeeting