14:00:24 <santiago> #startmeeting
14:00:24 <MeetBot> Meeting started Thu May 28 14:00:24 2026 UTC.  The chair is santiago. Information about MeetBot at https://wiki.debian.org/MeetBot.
14:00:24 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:39 <santiago> hello everybody
14:00:43 <charles> o/
14:01:13 <santiago> #rollcall
14:01:21 <eamanu> hello hello!
14:01:31 <paride> hello! o/
14:01:33 <charles> hi
14:01:39 <guilhem> hello
14:01:44 <santiago> (I am no longer sure #rollcall is a valid command...)
14:01:47 <slyon> \o
14:01:55 <santiago> anyway, please say hi if you are here :-)
14:01:56 <helmut> o/
14:01:57 <jochensp> Hi
14:02:25 <santiago> as usual, our meeting agenda is found at https://pad.riseup.net/p/lts-meeting-agenda
14:02:33 <tobi> hi
14:02:38 <Beuc> o/
14:03:05 <santiago> let's move ahead with our next actual topic
14:03:14 <santiago> #topic action item review
14:03:30 <santiago> we have four different items here
14:03:51 <santiago> #topic Follow-up to ML and Andreas concerning upload of nvidia-graphics-drivers
14:04:02 <LucasKanashiro[m]> o/
14:04:04 <santiago> tobi, have you been able to make any progress on your side here?
14:04:09 <santiago> (not me)
14:04:27 <tobi> unfortunaly not... /me takes note again
14:04:39 <santiago> is there something that could help us here?
14:05:04 <tobi> not sure, beside rolling own updates based on Andreas' work?
14:05:16 <tobi> let me ping him a final time...
14:05:52 <santiago> ok, let's carry this over again
14:06:19 <santiago> #action tobi and santiago: (carried over from last month) Follow-up to ML and Andreas concerning upload of nvidia-graphics-drivers
14:06:35 <santiago> #topic Start a discussion about debian-security-support being installed by default - Utkarsh to file a bug to discuss this publicly.
14:07:03 <santiago> jbicha, utkarsh2102, are you around?
14:08:08 <santiago> I guess no
14:08:18 <santiago> let's deffer this again one more time
14:08:28 <Beuc> If there isn't interest in this maybe let's drop this item.
14:09:11 <Beuc> This started last December, let's not pile-up indefinitely.
14:09:46 <santiago> yeap, let's do one thing: let's drop it, but let's "include it" again if jbicha and utkarsh2102 are able to make any progress
14:09:58 <slyon> maybe let's postpone one last time, to give utkarsh a chance to comment?
14:11:01 <santiago> we could add it after the meeting. we are not blocking this either
14:11:20 <charles> ack, seems sensible
14:11:28 <santiago> #topic (evolved from last month) tag-based scheduling on Debusine: figure out how to get changes into the service with the Debusine team and Freexian IT team; and make sure the proceedure is correctly documented
14:11:50 <santiago> that ^
14:12:00 <santiago> merged JIT
14:12:10 <Beuc> heh
14:12:22 <santiago> the documentation from the LTS team side was simple
14:13:05 <santiago> this just needs enough rights on debusine to make the changes
14:13:14 <santiago> any comments/questions?
14:13:50 <helmut> consider using guess_concurrency as a alternative
14:14:24 <guilhem> i don't understand what that means in practice; nothing unless “the package that you are preparing fails to build on Debusine because of resource limitations”?
14:14:25 <helmut> if a small worker works when scaling down concurrency, you may vendor guess_concurrency to avoid requiring tag-based scheduling and have it just work
14:14:33 <guilhem> (reading this for the first time)
14:15:17 <santiago> helmut, that's new to me. are you willing to document how to do that? :-)
14:15:29 <helmut> this does not help when lintian is the thing that goes OOM, you need tag-based scheduling there
14:16:26 <helmut> santiago: it's not specific to ELTS. a fair number of source packages have hacks for scaling down concurrency. guess_concurrency merely tries to make that easier
14:17:47 <santiago> guilhem, the Debusine instances have different kind of workers. The by-default workers may be too "slow" for some packages
14:18:28 <helmut> the problem is RAM typically. all workers have 8gb/core.
14:18:29 <santiago> if your are building e.g. linux, libreoffice, ... you may need that Debusine uses a larger worker, otherwise, your workflows fail
14:19:10 <petn-randall> o/
14:19:24 <guilhem> ah ok thx, i wonder if i stumbled into this for php earlier this month :-)
14:19:37 <helmut> sorry, 4gb per core.
14:20:27 <santiago> guilhem, yeah, probably. next time, you know you can reach out
14:20:34 <santiago> anything else?
14:21:23 <santiago> #topic Reach an agreement (with the rest of the team) and document what should be the "Non-maintainer upload"...
14:22:02 <slyon> This has landed via: https://salsa.debian.org/debian/devscripts/-/merge_requests/640
14:22:07 <slyon> It's included in devscripts (2.26.8) and also in the lts-team docs (referenced from above MR)
14:22:15 <santiago> slyon, just FYI, there is a small delay between your matrix bridge and IRC
14:22:35 <santiago> slyon, great, thanks for that!
14:22:39 <slyon> thank you all for the positive feedback on those MRs! We went with "LTS Team" instead of "LTS Security" team for the "Non-maintainer upload"
14:23:00 <slyon> uh oh? Good to know. But it looks like my messages still get through :)
14:23:34 <charles> and git-buildpackage was uploaded too, so you can gbp dch --lts now too (on unstable)
14:23:48 <santiago> \o/
14:24:04 <slyon> indeed. thanks for that charles
14:24:09 <santiago> we can move to next topic, I guess
14:24:38 <santiago> #topic Status of bookworm-lts (LTS takeover in June or July?)
14:25:27 <santiago> I will try to be concise here: we are waiting for feedback about opening the bookworm-security upload queue
14:25:36 <santiago> on June 11th
14:26:09 <santiago> but I guess I'll move the discussion to the mailing list, involving the different concerned teams
14:26:19 <santiago> (security, release, archive, lts)
14:27:00 <santiago> especially for the people who joined the LTS team after bullseye became LTS:
14:27:40 <santiago> the LTS team was unable to upload packages to bullseye-security between the moment we took over from the security team, and the final bullseye point release
14:28:01 <santiago> and there is a risk that the same situation will happen again with bookworm
14:28:41 <charles> ack, from contributors side, nothing to do but wait in that case, right?
14:29:12 <santiago> it seems there are concerns about the uploads that can arrive to -security and the final point release
14:29:21 <slyon> most importantly coordinate with the security team, I guess? So that they can hand over the repository with proper access permissions
14:30:03 <santiago> proper access permissions is the ability to upload to security master (the bookworm-security upload queue)
14:30:38 <slyon> is there any commitment from the LTS team side to start the LTS coverage at a certain date? Or could we just wait until after the final point release?
14:31:13 <santiago> slyon, the main issue is users stop receiving security updates
14:31:43 <santiago> since we have agreed that we take over 3 years after initial release, and the security team stops supporting the release
14:31:53 <slyon> oh ok.. so the security wouldn't cover that until the point release..
14:32:12 <santiago> and with the urgent updates happending recently, e.g. linux, it's a very real concern
14:32:36 <slyon> yes, agreed.
14:32:48 <santiago> anyway, my plan is to contact everybody by email by tomorrow
14:33:00 <arnaudr[m]> santiago: you said you'll move the discussion to the mailing list: which mailing list?
14:33:02 <Beuc> We can upload part of our work through bookworm OSPU :) But for urgent uploads we have a situation.
14:33:43 <santiago> proposing different alternatives, if we cannot upload immediately on June 12th
14:34:06 <santiago> arnaudr[m], the team mailing list, at first
14:34:13 <santiago> deblts-team
14:34:22 <santiago> Beuc, indeed, that's an option
14:34:27 <arnaudr[m]> OK. Just want to make sure I don't miss the discussion.
14:34:40 <santiago> any other question, comment, etc, before we move one?
14:34:48 <Beuc> Also for the first time we'll have both bullseye-lts and bookworm-lts, until September 1st. The tooling (DLA, front-desk, etc.) isn't handling this situation fully at the moment.
14:35:15 <Beuc> AFAIU this is one-time issue, so maybe we'll just have to work-around this for a couple months.
14:35:59 <santiago> Beuc, very good point. And I admit I thought we already had this situation (two simultaneous "LTS releases") before, but I was wrong
14:37:24 <santiago> Beuc, are you able to take a look at how broken our tooling would be (appart from the sec tracker) and see what changes would be needed?
14:37:49 <Beuc> santiago, OK I'll check next week.
14:38:00 <santiago> Beuc, big thanks!
14:38:39 <santiago> #action Beuc to look at the two simultaneous LTS releases support in the LTS tooling
14:38:42 <santiago> anything else?
14:39:24 <santiago> #topic New color for <ignored> CVEs in the tracker?
14:39:29 <santiago> arnaudr[m], this is yours
14:39:47 <arnaudr[m]> Heya! I don't know if anyone like this idea, so feedback welcome first.
14:39:50 <Beuc> santiago, We skipped the one about Extra hours
14:39:54 <arnaudr[m]> If it's only we, let's forget about it
14:40:00 <santiago> Beuc, oups, sorry
14:40:22 <santiago> arnaudr[m], any changes to the security tracer need to be discussed with the security team
14:40:23 <arnaudr[m]> Do I continue?
14:40:47 <Beuc> arnaudr[m], as I mentioned before the meeting: more generally there's been some work on the security tracker last year as part of https://salsa.debian.org/lts-team/lts-extra-tasks/-/work_items/87  --  many of them are still pending review sadly.
14:40:52 <arnaudr[m]> Yep I guess, but I wanted some feedback from LTS team first, to validate that it's indeed a good idea
14:41:26 <Beuc> There's a color-based MR already https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/223
14:41:27 <arnaudr[m]> Yep, I've seen this one: https://salsa.debian.org/security-tracker-team/security-tracker/-/work_items/25 about colors
14:42:19 <arnaudr[m]> Yes so maybe I can discuss my proposed changed over there, and maybe include it along the other changes?
14:43:03 <ah[m]> Can we have unimportant "folded in" by default? So they aren't even shown unless you click them.
14:43:45 <slyon> looking at the mockup in https://salsa.debian.org/arnaudr/security-tracker/-/work_items/1 I generally like the proposed change. As it makes it more clear that there's no action needed on the ignored ones.
14:43:52 <arnaudr[m]> My proposal is to give a different color to issue ignored, to avoid confusing it with postponed (they look very much alike if you don't pay close attention). I have screenshot of the change I propose at: https://salsa.debian.org/arnaudr/security-tracker/-/work_items/1
14:44:00 <santiago> let's discuss the color-related changes in the existing MR, and made a gentle ping. We need to ACK that the sec team is being busy
14:44:23 <santiago> and yes, I agree that a specific color for those is helpful
14:44:31 <arnaudr[m]> santiago: Sounds good to me
14:45:43 <santiago> not sure about "unfolding" the unimportant issues, but they are shown in another section in a package page
14:46:14 <santiago> if you have additional questions, would you mind discussing them after the meeting?
14:47:01 <santiago> I'll try to speed up a little bit, sorry
14:47:05 <santiago> #topic Increase Extra hours?
14:47:33 <santiago> Beuc, that was already in my head for next month
14:48:06 <santiago> is it bumping the Extra hours needed for the rest of *this* month?
14:48:30 <Beuc> santiago, I was thinking next month.
14:48:43 <santiago> good then
14:49:21 <santiago> #action santiago to look at requesting more Extra hours for next month
14:49:47 <santiago> #topic Info: The ssh host key of deb-master.freexian.com will change
14:50:01 <santiago> helmut?
14:50:03 <helmut> The machine will be moved to a different hosting provider
14:50:25 <helmut> the new one is deb-master-01.freexian.com, but you cannot do anything with it yet.
14:50:50 <helmut> the deb-master.freexian.com name will remain, we'll announce a precise date of change on the elts mailing list
14:51:17 <helmut> the move will incur an outage lasting several hours.
14:51:38 <helmut> Any questions?
14:52:12 <helmut> this is supposed to happen in June.
14:52:33 <petn-randall> Care to mention in 1-2 sentences why we're moving?
14:53:12 <helmut> petn-randall: we had a really bad experience when we rebooted it. 12h delay in hosting provider support and stuff.
14:53:28 <santiago> thanks helmut for the heads-up
14:53:58 <petn-randall> Oof. Fair move then. Thanks for the heads-up.
14:54:02 <santiago> if you all don't mind, let's move to the next topic
14:54:07 <santiago> #topic Discussion: Drop the explicit `debusine work-request sign` step for ELTS?
14:54:17 <santiago> helmut, the mic is your again
14:54:38 <helmut> Since Monday, Debusine will include Debusine-User: Debusine-Workflow: and Debusine-Workrequest: in generated .changes files
14:54:49 <helmut> this provides an auditing trace of who uploaded things to ELTS
14:55:19 <helmut> therefore, we no longer require .changes files to be signed by uploaders. Instead a signed Debusine-signed Debusine-User in the .changes file is good enough.
14:56:14 <helmut> We have several options from here: 1) Leave things as is and you continue to `debusine work-request sign`. 2) Uploads automatically move from Debusine to staging. 3) Uploads move conditionally from Debusine to staging.
14:56:43 <helmut> Conditionally can be: a) if you click some button Debusine or b) if QA passes or c) if QA passes or you click some button
14:57:11 <helmut> not sure those 3) options all work already. What's your preference? (dcut migrate remains)
14:57:25 <slyon> I guess I'd prefer option 3c. As I usually like to double-check the results, before having it uploaded to staging
14:57:54 <helmut> slyon: I mean you still can check things when they are in staging, right?
14:57:55 <slyon> or maybe 3a - if there's some known flaw in QA/testing, we might not want to block on it.
14:58:39 <slyon> helmut: correct. but removing from staging to do a re-upload is harder than kicking off another debusine workflow
14:59:02 <slyon> and I'm not sure if it would be burning version numbers in staging?
14:59:10 <helmut> You are not
14:59:15 <Beuc> Not 2), I often upload and change my mind after analyzing the tasks results; and sometimes I just use the 'upload-to-buster' workflow mid-work to test the current breakage, but I don't intend to move it to staging.
14:59:30 <Beuc> Manual validation/OK would be best.
14:59:53 <Beuc> especially since we plan to drop the current staging eventually.
15:00:17 <helmut> The next step in migration to Debusine would be creating a Debusine-side repository of packages (just additionally collecting stuff that gets uploaded to staging)
15:00:42 <Beuc> Not sure I understand the "signed Debusine-signed Debusine-User in the .changes file" I'll have to check in more details before giving my opinion.
15:00:46 <guilhem> don't that 2) and 3) remove the --local-file safe-guard/security guaranty?  https://wiki.debian.org/DebusineDebianNet#How_can_I_make_sure_that_debusine_work-request_sign_is_really_signing_the_correct_.changes_file.3F
15:00:48 <helmut> At some point, I want to replace the upload with deb-master pulling packages from a Debusine repo.
15:00:52 <guilhem> s/that/the/
15:01:16 <helmut> guilhem: yes, they do. they also mean that you no longer use your pgp key to sign elts uploads.
15:01:39 <helmut> (except for duct migrate until we also drop that)
15:03:15 <helmut> In a more distant future, upload-to-$elts shall add packages to a Debusine-internal suite and the dcut migrate step shall become a Debusine-internal suite copy operation.
15:03:35 <guilhem> have a preference for 1) then, as it allows ELTS users to trace uploads without relying on middleware infrastructure
15:03:51 <helmut> ELTS users do not get to see .changes files
15:03:52 <santiago> from the feedback above, I'd say that there is a preference for avoiding "automatic uploads"
15:04:09 <helmut> If you sign your .dsc, then that signature remains.
15:04:33 <guilhem> ah sorry, i understood that debusine would also sign the .dsc
15:05:09 <santiago> thanks helmut. any other feedback?
15:05:25 <santiago> we are already a few minutes pass the hour
15:05:44 <santiago> if you don't mind, let's move on
15:05:48 <helmut> #action helmut will look into conditional uploads.
15:05:58 <guilhem> i retract my preference then, no opinion 1) vs other
15:06:14 <santiago> #action helmut will look into conditional uploads.
15:06:38 <santiago> (not sure if the commands work for other than who's charing)
15:06:43 <santiago> #topic AOB
15:07:14 <santiago> I have a topic: thanks to charles who has volunteered to also chair the meetings
15:07:43 <santiago> hopefully starting next month ;-)
15:07:56 <santiago> anything else?
15:09:21 <santiago> #info charles to help with the 2-bus factor as team meeting chair
15:10:01 <santiago> to finish, next meeting is scheduled 2026-06-25 14:00 UTC on jitsi
15:10:50 <santiago> and that's the end of the regular meeting, if there is any technical question / issue to discuss, we have space for the meeting appendix
15:10:57 <santiago> thank you everybody!
15:10:57 <slyon> thank you santiago, all!
15:11:00 <Charles[mds]> Thanks santiago for chairing and all for the inputs!
15:11:11 <arnaudr[m]> thanks!
15:11:15 <eamanu> thanks santiago !
15:11:33 <santiago> #endmeeting