=== JanC_ is now known as JanC [15:25] amurray: hey, we bpo team will have a meeting in half an hour. Personally I'd be fine if you could join. (I just replied to your email). [15:25] I'm sorry I didn't get back to you much earlier! [15:36] Ubuntu backports meeting today? [15:41] luna: Check /topic for your answer. [15:42] well its on the calendar for in 18 minutes [15:43] luna: Then there's your answer. [15:59] o/ [16:00] \o [16:00] btw i'm kinda sick today, so i may go slower than usual this mtg [16:00] hello everybody! [16:00] also sick :( [16:00] hi [16:01] shall we wait for teward and (maybe?) amurray [16:01] i need a coffee refill anyway, brb [16:03] ok back [16:03] i guess no teward yet? [16:03] so it seems [16:04] well let's get started [16:04] #startmeeting Ubuntu Backporters Team [16:04] Meeting started at 16:04:15 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology [16:04] Available commands: action, commands, idea, info, link, nick [16:04] I'll go thru the previous action items, but I've been busy and sick the last 2 weeks so I haven't got anything done [16:04] #topic previous action items [16:05] #subtopic ddstreet update tooling, requestbackport, backportpackage (carried over) [16:05] I also had some troubles in the past month :( [16:05] #action ddstreet update tooling, requestbackport, backportpackage (carried over) [16:05] ACTION: ddstreet update tooling, requestbackport, backportpackage (carried over) [16:05] hold on [16:05] ok [16:05] ah sorry that did see some work didn't it [16:06] I think this is actually done? Probably need a check, and I'm aware of one bug in backportpacakge (uses the wrong -v value for dpkg-gencahgnes) [16:06] #undo [16:06] Removing item from minutes: ACTION [16:06] my right hand is quicker than my left hand today, looking at those typos :3 [16:06] so we should just add an action for someone to verify that then right? [16:06] imho yep [16:06] lol [16:06] i'm here [16:06] hey teward ! [16:06] 6 min late but i aws having some issues [16:07] i was* [16:07] (had to reboot router) [16:07] hey! and we were just about to assign it to you since you were gone xD [16:07] assign what lol [16:07] ahah [16:07] we think the tooling (backportpackage, etc) has been updated, just need one of us to verify it's good, you want to take that? [16:08] [01 05:05:59 PM] […]I'm aware of one bug in backportpacakge (uses the wrong -v value for dpkg-gencahgnes) [16:08] yeah i'll take verification ,just send me the list of what all in the tooling needs verified/tested [16:08] because without the list i'm going to not be 100% accurate [16:08] well… [16:09] *is running on 75% mental capacity after migraines all day yesterday* [16:09] can relate to migranes :( [16:09] I'd just want to say "make sure there are NO bugs" :P [16:09] ;P [16:10] mapreri: "backportpackage, etc." is vague, do you have the full list of tooling? [16:10] backportpackage and what else? (dead) [16:10] backportpackage and requestbackport, are the two tools [16:10] ok so i'll action teward looking at those 2 tools [16:10] check i'll poke it, updated in Lunar you mean or updated elsewhere? just making sure i have the right target versions when i test in containers [16:10] yes, lunar [16:11] #action teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) [16:11] ACTION: teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) [16:11] #subtopic ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:12] anyone else want this one? i will get to it eventually but it's been carried a while [16:12] I'll leave it with you :3 [16:12] ok :) [16:12] #action ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:12] ACTION: ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:12] #subtopic ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) [16:13] #action ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) [16:13] ACTION: ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) [16:13] #subtopic ddstreet update policies wiki page to remove 'draft' header (done) [16:13] done [16:13] #subtopic ddstreet add link to policies wiki page, to main wiki page https://wiki.ubuntu.com/UbuntuBackports (done) [16:13] also done [16:13] #subtopic ddstreet schedule next mtg 2023-02-15 same time (done) [16:13] done, obviously :) [16:13] #subtopic mapreri upload (more of) all the tools (carried over, in progress) [16:14] aye [16:14] this probably will be carried over for a while right? [16:14] carried over still [16:14] #action mapreri upload (more of) all the tools (carried over, in progress) [16:14] ACTION: mapreri upload (more of) all the tools (carried over, in progress) [16:14] #subtopic mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) [16:14] -ubottu:#ubuntu-meeting- Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open] [16:15] #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) [16:15] ACTION: mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) [16:15] right, I need to poke this some more… I wonder if I'll get to dirty my hands and write a patch eventually… [16:15] #subtopic mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) [16:16] yeah, haven't done that sorry [16:16] #action mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) [16:16] ACTION: mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) [16:16] #subtopic mapreri start thread on ML about how to use bug status to define meaing in process (carried over) [16:16] #action mapreri start thread on ML about how to use bug status to define meaing in process (carried over) [16:16] ACTION: mapreri start thread on ML about how to use bug status to define meaing in process (carried over) [16:16] i havent' seen an email so will assume it's carried [16:16] I would like to carry this over some more until at least I get back on track with my pile of unread emails [16:16] ack [16:16] #subtopic mapreri to look into backporting dh-python (see unit193 and yt-dlp) [16:16] otherwise I'm just going to add water to my own drowning self [16:17] you want to keep this or just let it drop? [16:17] pls keep it [16:17] ack [16:17] #action mapreri to look into backporting dh-python (see unit193 and yt-dlp) [16:17] ACTION: mapreri to look into backporting dh-python (see unit193 and yt-dlp) [16:17] (carried over) [16:17] ah right, i'll add that to the agenda when i edit it, thanks [16:17] #subtopic mapreri draft response email re: charter to TB [16:17] well, the TB was quicker than me, so drop this i guess [16:18] guess TB in this case is not Thunderbird? [16:18] sounds good; if amurray is around, we could discuss it now some [16:18] luna: technical board [16:18] ah [16:18] ok that's all the previous items [16:18] #topic open mailing list threads [16:19] #subtopic clarification on specific wording for no-bug-required backport exceptions [16:19] no movement on this one i think [16:19] (see above thing about unread mails…) [16:19] yep [16:19] i'll add an action to reply on this thread just to keep it alive [16:20] #action ddstreet reply to no-bug-required backport exception ML thread to keep thread alive [16:20] ACTION: ddstreet reply to no-bug-required backport exception ML thread to keep thread alive [16:20] #subtopic TB mailing list charter email [16:20] did you have a chance to read my reply from 1h ago? [16:20] so i see amurray and mapreri have followed up on this thread [16:21] yep, i think we are in agreement [16:21] I'd like to understand if my opinion is too different from yours [16:21] opinion*s* [16:21] for reference: [16:21] #link https://lists.ubuntu.com/archives/technical-board/2023-March/002713.html [16:22] #link https://lists.ubuntu.com/archives/technical-board/2023-March/002714.html [16:22] https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023027.html [16:22] right thanks, i was linking to TB list [16:22] #link https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023027.html [16:23] mapreri I think your summed-up proposal sounds perfect [16:24] teward you have a chance to review the emails? [16:24] I'll take that as some praise :3 [16:24] mapreri++ i'd give you karma if we had a karma bot here :) [16:24] ddstreet: as they've come in yes, but i haven't had any objections or complaints so my non-voice on the emails can be treated as acceptance without objection [16:24] having ddstreet claim some propositions are "perfect", duh ^^ [16:24] so JGTM [16:24] LGTM* [16:24] ffs keyboard. [16:24] !cookie | mapreri [16:24] mapreri: Wow! You're such a great helper, you deserve a cookie! [16:24] :D [16:25] lol nice [16:25] read the email now and LGTM [16:25] ddstreet: technically my irc bouncer then runs pisg on the log, so the ++ does mark it as karma there :P [16:26] so i guess we can wait for amurray response on the ML then and continue the discussion there, if needed [16:26] +1 [16:26] I think so, yes. [16:26] although [16:26] one detail that popped out in my reply, I forgot whether we discussed it already before: do we want to write done a SLA somewhere? [16:27] i think it would definitely be helpful - both to us, as well as uploaders [16:27] should we figure out one now? [16:28] my first though is something like at least 2 weeks, though that (probably) seems long to uploaders [16:28] that's going to be awkward right now. please add a note of some kind and let's come back to this later on. especially perhaps after somebody from TB comments on my mail [16:28] personally i only check the upload queue once a week though [16:28] sounds good [16:28] * mapreri mumbles something about Debian's NEW [16:29] #action (unassigned) consider documenting an SLA for reviewing uploaded backport packages [16:29] ACTION: (unassigned) consider documenting an SLA for reviewing uploaded backport packages [16:29] what's debian's new? [16:29] the new queue [16:29] ddstreet: newly packages uploaded to ftp.debian i think [16:29] where new packages pending ftp-master review stay [16:29] ah [16:29] luna: well, you are right :) [16:30] doesn't ubuntu queue have that also? [16:30] yes [16:30] but Debian's queue doesn't have any expectations [16:30] there have been packages pending for more than 1 year sometimes [16:30] oh wow [16:30] heh [16:30] as a contributor you really need to have faith sometimes [16:30] though i think some of ubuntu's queue still have old-timers in them as well [16:31] yeah, e.g.: https://launchpad.net/ubuntu/bionic/+queue?queue_state=0&queue_text= [16:31] normally those in ubuntu get stuck because of some reason, however, not because "nobody feels like reviewing this [for many many months]" [16:31] poor networking-mlnx, been there for 2.5 years [16:31] true [16:32] anyway, any other topic? :) [16:32] i think we're on to open bugs [16:32] #topic open bugs needing discussion [16:32] i think the only open one is memtest86+ [16:32] #link https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/1998834 [16:32] -ubottu:#ubuntu-meeting- Launchpad bug 1998834 in memtest86+ (Ubuntu) "[BPO] memtest86+/6.10-2 to Jammy" [Undecided, Confirmed] [16:32] i believe this just needs a sponsor? [16:33] exactly [16:33] sigh, I really don't like if the absence of sponsors in this case reflects poorly on us :( [16:33] but I also don't want to give expectations that we are happy to sponsor whoever comes along :\ [16:34] how vexing. [16:34] indeed, though i think that's a more widespread issue than just backports bugs [16:34] yes, totally [16:35] i can volunteer to sponsor this one, though i agree it would be great if ubuntu-sponsors got more active [16:35] #action ddstreet sponsor lp: #1998834 [16:35] ACTION: ddstreet sponsor lp: #1998834 [16:35] -ubottu:#ubuntu-meeting- Launchpad bug 1998834 in memtest86+ (Ubuntu) "[BPO] memtest86+/6.10-2 to Jammy" [Undecided, Confirmed] https://launchpad.net/bugs/1998834 [16:35] thank you [16:35] yep np [16:36] are there any other backport bugs i missed? [16:36] none afaik [16:36] nope [16:36] #topic AOB [16:36] I have one AOB. [16:37] So, unit193 brought to my attention that he accidentally did a gallery-dl bpo to kinetic, whom somebody approved. Now, I don't think that's problematic per se, although we decided to forbid general bpos to non-LTSs. [16:38] wasn't me who poked it, but it might've been someone else [16:38] i think i approved that [16:38] but did we decide to not approve anything to non-lts? [16:38] now, in this case I'd just say it's really not something problematic, but this made me wonder if somebody checked whether we have the ability to, say, remove a package from the bpo pocket? [16:38] ddstreet: we did, yes [16:38] * ddstreet makes a note of that [16:38] sorry :) [16:39] "Backports to non-LTS are not accepted (with exceptions)." is on our wiki page :) [16:40] back to my question, do anybody know if that's something that comes from our ACL, or do we need to poke AA in case we ever wants to remove something? [16:40] yep [16:40] sorry 'yep' was to comment about wiki [16:40] re: removal i don't know, but i assume we would need to poke AA [16:41] should we see if we can remove the gallery-dl in kinetic? [16:42] that was my implied question [16:42] also, how we would even try? :3 [16:42] i'm not even sure how to do it, probably a cli would be needed [16:42] should we bother investigating? [16:42] i dont see any way looking at the LP web pages [16:42] or just live happy for now? [16:42] I'd expect to be some API, at least [16:43] yeah i'm sure it's possible with the LP api [16:43] since we don't care about non-LTSes, I'd say we can just leave it there [16:44] and I will be sure not to look at the non-LTS queues anymore (or just reject stuff in them :-) [16:44] indeed, let's just forget for now then ^^ [16:44] it's a trivial problem anyway [16:45] any other business from anyone? besides next mtg date? [16:45] not from me [16:46] ok for next mtg, if we're going out 4 weeks as usual, i can't make Mar 29 [16:46] same [16:46] let's do 5th apr then? [16:46] works for me [16:46] i can't do that either, i could do Apr 12? [16:46] or i could go earlier, Mar 22? [16:47] both 5th and 12th April works for me (22th March does not) [16:47] if we want to stick to Wed [16:47] that *might* be problematic for (I might have some construction workers at home, not sure yet), but otherwise fine for me [16:47] should we push to Apr 19? [16:47] I think we could go with 12th [16:47] ok sounds good [16:47] teward: ? :) [16:48] either day works [16:48] #ddstreet sched next mtg Apr 12 [16:48] oops [16:48] #action ddstreet sched next mtg Apr 12 [16:48] ACTION: ddstreet sched next mtg Apr 12 [16:48] ddstreet turns into a bot command [16:49] easier to summon [16:49] *notes in my Google calendar* [16:49] summer time then right? [16:49] lol i would not want to see myself as a bot, i would not be helpful :) [16:49] so 17:00 UTC instead of 16 UTC [16:49] alright, I'll sign off, I have another mtg in another channel in 10 mins /o\ [16:49] or am i thinking wrong? [16:49] oh, damn DST [16:49] yep we've been using USA DST schedule so it will be DST [16:49] let me check a thing [16:50] 1 hour earlier or later? [16:50] DST always screws me up [16:50] 15:00 utc [16:50] thanks [16:50] if this becomes 15 UTC it should be fine [16:50] added to my google calendar [16:50] great, thanks everyone! [16:50] #endmeeting [16:50] Meeting ended at 16:50:49 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-03-01-16.04.moin.txt [16:51] later! o/ [16:52] ddstreet: btw, it seems like you are sending the invite to both mapreri@u.c. and mapreri@g.c ? Could you pick just one? (probably it integrates a little better with @g.c) [16:53] sure will do, i already sent the next invite out but i'll remove @u.c so the next one should be right [16:54] ta (I remember to tell you because I saw the invite ^^) [16:54] poof [16:54] and teward i have you on there with 3 email addrs, do you want me to just use one of them? [16:54] use two - teward@thomas-... and my tward@... [16:55] one's my personal calendar and the other shows in my work calendar which properly reminds me xD [16:55] done! [16:55] next time the invite should go out to the right addr(s) to both of you [17:12] ddstreet: yep, i think you sent to all three (the other being my ubuntu address) because i wanted to make sure it got to my email on MS365 [17:12] my work is my work email so :P