14:00:21 <el_cubano> #startmeeting
14:00:21 <MeetBot> Meeting started Thu Mar 27 14:00:21 2025 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:21 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:27 <santiago> hey!
14:00:29 <el_cubano> Hi! o/
14:00:30 <lamby> o/
14:00:33 <pochu> o/
14:00:38 <utkarsh2102> hello!
14:00:38 <tobi> \o
14:00:39 <el_cubano> oops
14:00:45 <el_cubano> #topic Roll Call
14:00:48 <el_cubano> Let's try that again.
14:00:50 <el_cubano> Hi! o/
14:00:50 <ta> hi
14:00:51 <tobi> \o
14:00:53 <utkarsh2102> \o
14:00:55 <Beuc> o/
14:00:57 <charles> o/
14:01:01 <ah[m]> o/
14:01:31 <guilhem> \a
14:01:46 <LucasKanashiro[m]> o/
14:02:39 <rouca> ho
14:02:44 <el_cubano> Also, we have apologies from bunk (in the agenda/notes)
14:03:01 <lamby> o.
14:03:03 <el_cubano> It looks like we are mostly all here.
14:03:13 <el_cubano> https://pad.riseup.net/p/lts-meeting-agenda
14:03:31 <pochu> o/
14:03:33 <el_cubano> Meeting agenda, in case anyone still needs to pull it up
14:04:34 <el_cubano> OK. We don't have a particularly full agenda, so this might be a short meeting
14:04:45 <el_cubano> (Of course, by saying that I have now doomed us all. Sorry.)
14:04:59 <el_cubano> #topic New team members
14:05:15 <el_cubano> We have a new contributor on the team: Carlos Henrique Lima Melara (prefers to go by: Charles)
14:05:22 <santiago> \O/
14:05:27 <el_cubano> charles: Did you want to introduce yourself to the team?
14:05:56 <charles> yes, but a very short one
14:06:12 <pochu> welcome charles!
14:06:18 <tobi> be welcome Charles :)
14:06:23 <utkarsh2102> hey, heeey. welcome, indeed!
14:06:26 <charles> my name is Carlos, but everyone knows me by Charles, so let's go by that
14:06:41 <charles> o/
14:06:49 <lamby> welcome :)
14:06:51 <rouca> welcome
14:07:02 <el_cubano> Is that "Charles" pronounced in the French, British, or American way?
14:07:05 <LucasKanashiro[m]> welcome again :)
14:07:10 <el_cubano> Or some other way? :-)
14:07:23 <charles> el_cubano: you can pick the one you prefer :-)
14:07:29 <el_cubano> haha!
14:07:44 <LucasKanashiro[m]> knowing him I'd say British is better :P
14:07:57 <utkarsh2102> however you pronounce "Charles" in Charles Leclerc :)
14:07:57 <santiago> I'd say 🇧🇷
14:08:26 <LucasKanashiro[m]> nice emoji
14:08:30 <charles> I'm mainly contributing to l10n-portuguese, helping some stuff around publicity team, maintaining neomutt, curl and some other small packages
14:08:49 <charles> and help mentoring newcomers with kanashiro
14:09:02 <pochu> el_cubano: irish? :-)
14:09:09 <charles> oh dear
14:09:16 <el_cubano> Nice! curl is an important package, so it will be nice to have your expertise on the team (as we occasionally have to work on it in LTS/ELTS)
14:09:31 <charles> cool!
14:09:39 <el_cubano> pochu: I'm not sure. I'll have to ask Colin to say it next time I see him since I can't imagine what that would sound like with an Irish accent.
14:10:03 <el_cubano> OK. We're not even 10 minutes in and I managed to already partly derail the meeting.
14:10:11 <el_cubano> Let's see if I can get us back on track.
14:10:32 <santiago> 🛤
14:10:59 <LucasKanashiro[m]> santiago is very emoji today :)
14:11:04 <el_cubano> Although technically not a new team member, Utkarsh is back after some months away. So, welcome back, utkarsh2102 !
14:11:18 <utkarsh2102> thank you! \o
14:11:24 <LucasKanashiro[m]> welcome back!
14:11:26 <charles> \o/
14:11:27 <santiago> \O/
14:11:37 <rouca> \O/
14:11:47 <el_cubano> /\O/\
14:11:54 <tobi> \o/
14:12:15 <el_cubano> OK. Next topic.
14:12:21 <el_cubano> #topic Action item review
14:12:32 <el_cubano> There was only one action item from last week's meeting.
14:12:56 <el_cubano> BTW, thanks to kanashiro and pochu for their help with last *month's* meeting when I wasn't available.
14:13:07 <el_cubano> Action: Start an email thread about autopkgtest/mmdesbstrap build images
14:13:15 <el_cubano> This was assigned to petn-randall
14:13:29 <el_cubano> petn-randall: I didn't see you announce yourself at the start of the meeting. Are you around just now?
14:14:11 <santiago> I believe that is https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/79
14:14:34 <LucasKanashiro[m]> this was more about starting a thread to share workflows and what not IIRC
14:14:36 <andrewsh> btw I’m around, I didn’t realise there was a meeting 😃
14:14:49 <Beuc> IIRC it was an opportunity for people to share how to test the packages
14:14:55 <el_cubano> santiago: Ah, yes. I went looking in the mailing list archives but I didn't find anything.
14:14:59 <el_cubano> I had missed the issue notification.
14:15:25 <santiago> and also #1099577
14:15:29 <el_cubano> Beuc: And IIRC I've seen that you have been updating the docs.
14:15:31 <Beuc> mainly isolated testing in throwable on-the-fly VMs vs. working with a VM
14:15:40 <LucasKanashiro[m]> we got to a conclusion that people do test packages very differently and it would be great to know what others are doing it
14:16:03 <Beuc> Yes updating the doc is part of that.
14:16:19 <el_cubano> Beuc: Thanks very much for your efforts to keep the docs updated.
14:16:22 <LucasKanashiro[m]> * we got to a conclusion that people do test packages very differently and it would be great to know what others are doing
14:16:53 <Beuc> https://lts-team.pages.debian.net/wiki/TestSuites/autopkgtest.html covers both running autopkgtest manually from within a complete VM, and creating throwable restricted VMs
14:16:54 <el_cubano> andrewsh: welcome to the meeting :-)
14:17:20 <el_cubano> Beuc: 'throwable' meaning 'disposable' in this context?
14:17:31 <Beuc> create&destroy
14:17:46 * el_cubano nods
14:18:01 <Beuc> And, more general feedback could be good, e.g. how people combine this with a git-buildpackage workflow, etc.
14:18:19 <el_cubano> OK. Anyone interested in this (local testing) is encouraged to visit the Salsa issue, the BTS, and the related team docs.
14:18:54 <el_cubano> Next topic
14:18:58 <el_cubano> #topic Number of maximum simultaneous claims
14:19:30 <el_cubano> This is a discussion I have wanted to have as a team for some time.
14:20:01 <el_cubano> My thought is to start the discussion now during the meeting, move it to the mailing list afterwards for any follow-ups, and then capture the concensus in docs/tooling updates.
14:20:09 <el_cubano> There are actually two aspects to consider.
14:20:23 <el_cubano> 1. The number of claims (we currently have the max as 3)
14:20:45 <el_cubano> 2. The length of time a claim is valid w/o any update to the Xla-needed.txt entry.
14:20:54 <el_cubano> So, let's see about 1.
14:21:32 <pochu> I think the current number has worked well for some time, hasn't it?
14:21:32 <el_cubano> I think that the limit is still useful. Does anyone have a thought about increasing the limit?
14:22:25 <Beuc> I believe it's enough, especially since there's one for LTS and a different one for ELTS.
14:22:42 <andrewsh> I try to not take more than two packages at any given time
14:22:44 <LucasKanashiro[m]> from the discussion in the last meeting (in the notes) it seems that 3 is fine
14:22:55 <andrewsh> usually only when I’m blocked on one or something, I take another
14:23:30 <el_cubano> OK. That's more or less what I expected.
14:23:38 <andrewsh> although I can imagine taking up to 3 may be useful sometimes
14:23:46 <Beuc> Provided it's not a hard-and-blind limit, e.g. not preventing to take 3 ruby2.* or even 6 python[23]* :)
14:23:54 <utkarsh2102> I think limiting to 3 is good. Enforces people to not take too many and make little progress. OTOH, if they're blocked, they're encouraged to start threads or write an entry to Xla-needed.txt file and drop it in favor of a new one.
14:24:34 <utkarsh2102> this was in reply to whether or not we should increase the limit^
14:24:53 <Beuc> s/6/4/
14:24:58 <utkarsh2102> no strong opinions, though, but 3 is good. exceptions can always be made on a case-by-case basis.
14:24:59 <andrewsh> to give an example, I’ve held onto nginx for a long time, as I had the update prepared, but to avoid regressions I also wanted to get these things patched in stable
14:25:27 <andrewsh> coupled with my hardware issues and being a bit more busy IRL recently, this has got a bit out of control though :D
14:25:54 <andrewsh> but last month I worked on other things too while nginx waited for a review from the maintainer
14:26:10 <el_cubano> Beuc: Currently it is something that the weekly report tooling warns about, but it requires manual action to do anything about it.
14:26:15 <LucasKanashiro[m]> I agree that something that could be more broadly advised is to always add entries in Xla-needed.txt explaning the status of the blocked packaged (maybe waiting for review) when claiming a new one
14:26:28 <andrewsh> +1
14:26:46 <andrewsh> yeah, maybe not necessarily dropping but writing a note
14:26:53 <el_cubano> LucasKanashiro[m]: Ack.
14:27:04 <andrewsh> I refrained from writing notes as it felt to me it’s something other people do
14:27:16 <andrewsh> I mean, people monitoring security issues
14:27:20 <el_cubano> OK. So there doesn't seem to be a "raise the limit" or "lower the limit" view being expressed.
14:27:22 <andrewsh> but well, I’m still new here
14:27:34 <tobi> yes, xla-needed.txt is a perfect place to document thos circumstances
14:27:38 <el_cubano> andrewsh: We use the Xla-needed.txt files differently from how secteam uses dsa-needed.txt
14:27:51 <el_cubano> We are much more verbose in the notes that we leave.
14:27:57 <andrewsh> ack
14:28:05 <el_cubano> So, yes, please do make notes and don't feel like they should be avoided.
14:28:14 <tobi> but otherwise I think it is better to work sequentially on packages, not in parallel (if there are no blockers)
14:28:21 <el_cubano> tobi: agreed
14:28:23 <andrewsh> NOTE: I was meant to write a note, but I forgot what that was
14:28:23 <andrewsh> :)
14:28:26 <LucasKanashiro[m]> +1
14:28:51 <el_cubano> OK. The second aspect, is the two week semi-automatic unclaim helpful, or is it more annoying?
14:29:09 <LucasKanashiro[m]> being python[2,3]* , rubyX.Y and friends exceptions
14:29:18 <andrewsh> el_cubano: useful, but maybe it could send a chat msg or an email?
14:29:21 <el_cubano> The way I am seeing it work is it generally functions as a reminder to make a note on a package. Granted, some people will simply reclaim without making a note
14:29:23 <pochu> I think it's good. what's annoying to me is when packages are re-claimed without dropping a status update
14:29:37 <andrewsh> el_cubano: I sometimes use shallow pull, and then it’s difficult to track it down
14:29:49 <pochu> andrewsh: it's mentioned in the weekly report
14:30:06 <andrewsh> pochu: what is?
14:30:10 <tobi> I think there should be a rule that re-claiming requires a note / status update in xla-needed.txt
14:30:13 <el_cubano> When packages are unclaimed
14:30:17 <andrewsh> oh
14:30:22 <andrewsh> I meant "before unclaiming"
14:30:28 <lamby> tobi: +1  (or at least a strong request)
14:30:37 <LucasKanashiro[m]> +1
14:30:38 <el_cubano> tobi: Yes, but there are some people who treat that more like a suggestion
14:30:38 <andrewsh> something like Let’s Encrypt did — hey, your cert is just about to expire
14:30:55 <guilhem> +1 for the auto unclaim
14:30:56 <el_cubano> andrewsh: The tooling doesn't really support that
14:31:09 <tobi> +1 for auto-unclaim as well.
14:31:32 <el_cubano> The process is to run a script that checks the claims and determines how long since the last activity, then unclaims those more than 2 weeks old.
14:31:54 <andrewsh> el_cubano: is it since the last time the entry was modified *or* since when it was claimed?
14:32:11 <andrewsh> e.g. if I add a NOTE: This is being worked on but ..., will it still unclaim after 2 weeks?
14:32:11 <tobi> el_cubano: maybe we can agree to  s/suggestion/required/s as a tean?
14:32:12 <el_cubano> I'd be open to implementing some sort of automated (CI-based or cron based) check+notification
14:32:12 <santiago> the tooling doesn't support it, but is that something that we would want?
14:32:16 <el_cubano> andrewsh: modification
14:32:22 <andrewsh> el_cubano: cool, thanks!
14:32:23 <tobi> *team
14:32:25 <pochu> maybe we should ask people not to reclaim a package if they haven't made significant progress, at least for a couple of days, in order to give others a chance to take it?
14:32:26 <guilhem> would it make sense to check activity on the repo's suite branch?
14:32:28 <andrewsh> then a NOTE will suffice
14:32:38 <pochu> and if they've made progress, that should be documented when reclaiming
14:33:12 <el_cubano> OK. These are good suggestions.
14:34:19 <el_cubano> Would someone be willing to (a) update the team docs to make this a bit more clear, and (b) write an issue (in lts-extra-tasks) for implementing an automated package claim age check + associated notifications?
14:34:54 <Beuc> I can do that :)
14:35:03 <el_cubano> Beuc: thanks!
14:35:32 <el_cubano> #action Beuc (a) update the team docs to make this [package claim/note policy] a bit more clear, and (b) write an issue (in lts-extra-tasks) for implementing an automated package claim age check + associated notifications?
14:36:06 <el_cubano> In the meantime, are we all OK with things continuing as they have been (automatic unclaim after 2 weeks of no update on a claim)?
14:36:42 <Beuc> +1
14:36:48 <guilhem> yep
14:36:49 <LucasKanashiro[m]> +1
14:36:51 <pochu> ack
14:37:00 <el_cubano> OK. Thanks.
14:37:02 <santiago> +1
14:37:10 <el_cubano> Next topic.
14:37:17 <tobi> +1
14:37:20 <el_cubano> #topic Max hours adjustments
14:37:25 <el_cubano> santiago: Do you want to take this one?
14:37:40 <santiago> sure
14:38:29 <santiago> as mentioned by email, it would be great to adjust the max hours according to something that matches more reality
14:38:45 <santiago> it is *not* to tell you reduce your work hours, at all
14:39:20 <santiago> actually, it is great when we can use all of our work hours
14:40:03 <santiago> but, it we have too many hours available, more than those that we can use, that creates an impact on the Extra hours pool, which currently is a little bit low
14:40:50 <santiago> so, we made an open call, to decrease *or increase* our hours
14:41:59 <tobi> just a procedural question: If I find that in a particular month that I won't reach my hours, can I "give back" hours before the end of the month?
14:42:10 <tobi> (so like the opposite of claiming additional hours)
14:42:11 <santiago> in a second step, we (el_cubano and myself) plan to poke specific contributors if we see some adjustments could make sense
14:42:40 <santiago> el_cubano, would you like to answer that question?
14:42:41 <el_cubano> tobi: Yes, you can do that.
14:42:58 <el_cubano> It's not strictly necessary, but certainly allowable.
14:43:16 <el_cubano> If you are sure you will likely be able to use the hours in the next month, then you can hold on to them.
14:43:49 <el_cubano> What we are specifically looking at is people who regularly only report 50% or less of the hours which have been allocated.
14:44:06 <el_cubano> The higher the 'max' value in contributors.yml, the more concerned we are.
14:44:37 <el_cubano> Someone w/ a max of 10 hours reporting 5 hours is much less impactful on this issue than someone w/ a max of 100 and reporting only 50 hours.
14:45:41 <santiago> again, this is not to penalize anybody, just to try to make a sensible use of the work-hours resource
14:46:30 <el_cubano> +1
14:47:11 <santiago> any other comment or question?
14:47:30 <pochu> I think it's clear
14:48:07 <rouca> ok
14:49:04 <el_cubano> OK. Next topic?
14:49:24 <santiago> let's move on.  don't hesitate to reach out later if there is any question
14:50:19 <andrewsh> el_cubano: what would be a ledger incantation to do the math and print the remaining number of hours for myself?
14:50:50 <el_cubano> andrewsh: ledger --no-color -f timekeeping.ledger balance ^Contributors:.*:YourNick
14:50:56 <andrewsh> thanks!
14:50:59 <el_cubano> np
14:51:15 <el_cubano> OK. Next topic.
14:51:19 <el_cubano> #topic AOB
14:51:26 <el_cubano> utkarsh2102: you're up
14:51:36 <utkarsh2102> hello! thanks
14:51:42 <utkarsh2102> this is about the musl update.
14:52:04 <Beuc> andrewsh, see also the top of the ledger file :)
14:52:08 <utkarsh2102> I prepared the updates, very similar to lamby and then I noticed his RFH.
14:52:14 <utkarsh2102> titled, "Please review musl 1.2.2-1+deb11u1 for bullseye LTS"
14:52:15 <andrewsh> Beuc: hah! thanks :D
14:52:25 <andrewsh> Beuc: I always only look at the last entries :D
14:52:32 <pochu> utkarsh2102: isn't there a note in dla-needed about it? :)
14:53:05 <andrewsh> who’s coming to the BSP in Vienna? MiniDebConf in Hamburg?
14:53:11 <andrewsh> MaxiDebConf in Brest? :)
14:53:38 <utkarsh2102> and it was relieving to see that I was also stuck on testing the CVEs. from how the thread goes: I am not sure but I was expecting Adrian to follow up with a reproducer?
14:54:54 <utkarsh2102> i am not sure what to expect there? do I follow up on the mail thread? it felt a bit heated and I don't intend to add more to it, of course.
14:55:04 <utkarsh2102> so just wanted to see what would be a reasonable path forward.
14:55:31 <utkarsh2102> lamby: did you make any progress on those? except for testing, is there anything blocking you?
14:55:49 <utkarsh2102> or something you were concerned about which prompted the RFH mail?
14:56:02 <utkarsh2102> and how d'you think i/we should proceed?
14:56:10 <utkarsh2102> EOF :)
14:56:58 <Beuc> maybe discuss this with lamby after the meeting?
14:57:05 <santiago> + myself
14:57:29 <utkarsh2102> sure, are you ok to stick around lamby for a few more minutes, please?
14:57:45 <utkarsh2102> and also, we can move on. don't want us to go over time.
14:57:55 <el_cubano> Agreed. That seems more appropriate for an after-the-meeting discussion, as it could get into the details.
14:58:08 <el_cubano> santiago: Salsa CI ARM runner?
14:58:44 <santiago> an early-as-possible notice: the machine where the Salsa CI ARM runner runs is planed to be decommissioned
14:59:01 <santiago> it's the same runner used by the lts-team/pipeline
14:59:10 <Beuc> which one, the Salsa one or the Freexian one?
14:59:15 <santiago> and FTR, for some ci.d.n workers
14:59:28 <santiago> Beuc, the salsa ci one
14:59:49 <el_cubano> santiago: In the agenda it says "in three months, or by June 2026?"
14:59:58 <el_cubano> In three months is June 2025.
15:00:12 <Beuc> (i.e. "salsaci-arm64-runner-01.debian.net" vs. "LTS Team ARM runner" - ok the former)
15:00:12 <el_cubano> So, is this trying to get at whether the decommissioning should be this year or next year?
15:00:21 <santiago> I thought we had until June 2026, but the sponsors just said they plan to shut it down in ~three months
15:00:51 <santiago> Beuc, it is the same machine
15:01:23 <Beuc> is it? ok.
15:01:36 <santiago> I don't want to take more time here, but I am looking for a solution
15:01:49 <santiago> including: https://salsa.debian.org/salsa/support/-/issues/468
15:02:25 <el_cubano> OK. That's good to know.
15:02:28 <el_cubano> Anything else?
15:03:15 <Beuc> Could Freexian be involved in the replacement? I'm not sure how much we use our own arm builders?
15:03:16 <santiago> we need to figure out what to do, probably this is a strong argument to move to a debusine-based workflow
15:03:50 <santiago> Beuc, I haven't to discuss (the three-months warning came yesterday late)
15:04:03 <santiago> but relying more on debusine is in our plans, anyway
15:04:46 <el_cubano> santiago: Anything else on this?
15:04:50 <santiago> npoe
15:04:54 <el_cubano> OK. Thanks.
15:05:00 <el_cubano> Anyone else for AOB?
15:05:13 <Beuc> I don't know the status of debusine atm, is it ready for our usage?
15:05:25 <Beuc> (or in 3 months time)
15:05:46 <santiago> I am happy to discuss about this later
15:05:49 <Beuc> k
15:05:50 <andrewsh> CVE-2020-36309 needs some more work, and I’m not sure I can do that
15:06:00 <andrewsh> so having someone else look at that would be great
15:06:07 <andrewsh> unless we say we ignore it
15:06:18 <andrewsh> the fix is there, but testing it is tricky
15:06:55 <santiago> andrewsh, it is already marked as <ignored> in bullseye (and buster)
15:07:01 <andrewsh> oh, is it
15:07:04 <andrewsh> cool
15:07:22 <el_cubano> Alright. That looks like the end of AOB.
15:07:22 <andrewsh> should I drop it from dla-needed then?
15:07:26 <el_cubano> Oops
15:07:31 <andrewsh> (I have previously re-added it with a NOTE)
15:07:33 <santiago> andrewsh, ubuntu has patches for it though: https://ubuntu.com/security/CVE-2020-36309
15:08:02 <andrewsh> santiago: should we trust they tested them and ship them then?
15:08:28 <santiago> andrewsh, of course not :-) we need to test them ourselves
15:08:40 <el_cubano> andrewsh: I don't know the details of that CVE, but based on previous experience that's not a good assumption.
15:08:46 <andrewsh> :)
15:08:49 <andrewsh> anyway, let’s keep it with the NOTE and see later
15:08:57 <utkarsh2102> i would trust that they tested them FOR ubuntu, we should test it FOR debian. :)
15:09:52 <el_cubano> OK. This looks like the actual end of AOB.
15:09:57 <el_cubano> Last chance for AOB
15:09:58 <Beuc> <andrewsh> who’s coming to the *DebConf in *? -> I plan to attend some of DebConf in Brest.
15:10:28 <andrewsh> I’m coming to Vienna and Hamburg, Brest is still to be decided
15:10:28 <utkarsh2102> we should try to get together, an LTS BoF or even just socially?
15:10:35 <el_cubano> Ah, yes, I forgot to go back to that as well.
15:10:41 <utkarsh2102> like a Wednesday dinner or something.
15:10:49 <el_cubano> utkarsh2102: Do you mean at DebConf?
15:10:53 <utkarsh2102> yes!
15:11:16 <el_cubano> I plan to be there for DebCamp, it turns out I may not be able to attend for the week of DebConf. TBD.
15:11:37 <utkarsh2102> happy to help with polling and scheduling this if you'd like, el_cubano :)
15:11:55 <el_cubano> utkarsh2102: Sounds good! I'll ping you when I get to the point of that stuff.
15:12:02 <utkarsh2102> sure thingy!
15:12:02 <el_cubano> Alright, so let's wrap this up.
15:12:07 <santiago> we would like to plan a Sprint for DebCamp
15:12:07 <el_cubano> #topic Next meeting
15:12:23 <el_cubano> #topic AOB
15:12:40 <el_cubano> As santiago says, we would like to plan a sprint for DebCamp
15:12:52 <el_cubano> I'm focusing on security tracker stuff for that.
15:13:19 <el_cubano> I'll send more info to the mailing list when I have it.
15:13:26 <el_cubano> #topic Next meeting
15:13:31 <el_cubano> Next meeting: 2025-04-24 14:00 UTC [Location: Jitsi: https://jitsi.debian.social/LTS-monthly-meeting]
15:13:51 <el_cubano> So, next month's meeting will be via Jitsi.
15:13:58 <el_cubano> We'll see everybody then!
15:14:08 <el_cubano> Bye bye!
15:14:11 <utkarsh2102> thanks, see you next month everyone. o/
15:14:15 <Beuc> bye!
15:14:16 <el_cubano> #endmeeting