14:00:12 #startmeeting 14:00:12 Meeting started Thu Jul 24 14:00:12 2025 UTC. The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:20 #topic Roll Call 14:00:22 hi 14:00:25 Hi everyone! o/ 14:00:28 hello! 14:00:30 hi 14:00:34 Please announce yourself. 14:00:37 o/ 14:00:41 o/ 14:00:42 o/ 14:00:51 \o 14:01:29 o/ 14:01:30 \o 14:01:51 I did hear from tobi and rouca that neither one of them would be able to attend today. 14:03:59 OK. Thanks to everyone for that. 14:04:37 #topic New team members 14:04:45 No new team members this month. 14:05:20 #topic Action item review 14:05:43 It looks like Santiago[m] is still editing the first action item, so we'll come back to that. 14:05:58 (that was me editing it) 14:06:03 Oups :-) 14:06:26 Guilhem had an action to propose a docs update w/ guidance on data/next-point-update.txt 14:06:32 \o 14:06:42 That hasn't been done yet, so this action will be carried over for next month 14:06:52 o/ 14:06:53 there was some discussion in the MR but haven't had time to draft the document yet 14:06:55 right 14:07:12 guilhem: ack. and thanks for working on this 14:07:22 regarding porter machines, the issue has reached managers and is being discussed, though it's not like "yes go for it", but looking for compromises. 14:07:52 helmut: That's good to know. 14:08:10 Santiago[m] helmut do either of you want to add anything else on the first action? 14:08:39 would anyone feel bad if accessing a porter machine would happen via Debusine? 14:09:04 i.e. you'd create a work request that gives you acccess in some to-be-defined way 14:09:26 I posted a request to get SSH access to failed jobs, like SourceHut does: https://salsa.debian.org/freexian-team/debusine/-/issues/958 -- that works for me. 14:09:38 that would work for me 14:09:54 sgtm 14:09:56 My use case is debugging failed builds and autopkgtests, not run random tests. 14:10:30 However we may need something for the short term, unless debusine wants to make this ready next month ;) 14:10:33 in any case, the Debusine-based idea is not at all implemented and would be scheduled after package repositories. 14:10:56 Trupti: welcome! 14:11:09 short-term, I fear the work around is dispatching armhf debugging to developers with access. 14:11:13 if we can easily get access to a porterbox in a reliable way, then SGTM :) 14:11:25 LucasKanashiro[m]: +1 14:11:48 there is no short-term solution planned on the sysadmin side. 14:11:49 please, thumbs up https://salsa.debian.org/freexian-team/debusine/-/issues/958 if you agree with it 14:12:02 Let's add that my last hard debug issue was actually due to the specific arm elts buildd configuration, not arm itself. 14:12:30 helmut, would you be able to grant one of the contributors a one-time environment for debugging purposes? 14:12:34 so yeah, when you locate crazy elts build failures. do reach out to me via helmut@freexian.com 14:12:47 Beuc: I haven't looked at the issue write up to know if that is documented or not. Please make note of it in the issue if it isn't already there. 14:12:48 FWIW you can download the system images that debusine uses 14:12:54 Beuc: I don't think so 14:13:36 el_cubano, the arm configuration was fixed by helmut (thanks) and a report sent to the ML; nothing left to document since that particular issue is gone :) 14:13:40 helmut, ok, too bad. 14:13:44 Beuc: Ack 14:14:15 OK. So I think that this action item can be considered closed, as issues have been raised/documented and now it is a matter of coming up with a feasible solution. 14:14:26 The last action belongs to charles 14:14:46 I don't recall seeing a message to the list about a KGB instance configuration. 14:14:48 tumbleweed, instructions about how to download those images would be useful :-) 14:14:58 charles: Did you happen to send the email and I just missed it? 14:15:11 santiago: it's an input to the build 14:15:18 (follow the links in the UI) 14:15:48 not all inputs are properly linked in Debusine. sometimes you need to head to internals, copy the artifact and browse it. there is an issue asking to improve that 14:15:54 tumbleweed, santiago, arm emulation is too slow and bring more issues, cf. last meeting :) 14:16:33 Beuc, good point 14:16:55 OK. Not hearing from charles, I'll carry that action over to next month. 14:17:02 about KGB, as I mentioned in the issue, 14:17:06 https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/91 14:17:31 we have a commit notifications list, which wasn't documented (it now is in the info for new contributors) 14:17:41 deblts-commits@freexian.com 14:17:47 Beuc: Ack. Thanks. 14:17:56 santiago, I think you set it up, how many members are there in this list? 14:18:16 IIRC, its in the range of ~15 14:18:21 el_cubano: yeah, I got a bit overwhelmed with debconf 14:18:29 14 people 14:18:30 charles: No worries at all. 14:18:31 will do this week 14:18:37 ack. thanks. 14:18:56 OK. Last call on action item review. (I'd like to keep things moving so we don't go too much over time) 14:20:16 #topic Featured issue(s) of the month 14:21:05 We opened a lot of MRs during the DebCamp sprint, so if anyone is interested in pitching in to help with getting everything wrapped up, we have several open MRs. 14:21:22 We'll discuss in more detail on the next agenda item 14:21:47 #topic DebCamp25 Security Tracker sprint, post-game review 14:22:42 Thanks very much to everyone who participated in the sprint. We got an impressive amount done and once all the MRs are wrapped up, it will represent a substantial improvement to the overall funcitoning of the security tracker. 14:23:18 Beuc has noted in the agenda some details about the work that we did 14:23:36 Beuc and/or LucasKanashiro[m] , did you want to add anything? 14:23:44 we should have taken a picture of the sprint on-site, that's on me :/ 14:23:55 nothing to add here 14:24:18 el_cubano, most open MRs are waiting for a review from the security team (helped by pochu), 14:24:44 Ah, right. 14:24:45 yes, carnil and I will go over them, but it will take some time. please be patient 14:24:54 should we ping ourselves? do you intend to coordinate with them? :) 14:25:32 So anyone who is interested in helping should look at the issues which haven't progressed to the point of having an MR (modification of what I said a few minutes ago) 14:26:14 el_cubano: to improve the chances that something is accepted, it may be best to seek feedback in the issue itself before working towards a MR 14:26:26 pochu: +1 14:26:41 One other thing I'd like to note about the sprint is that we had participation from ~6 people from outside the regular LTS team 14:26:49 That was very encouraging 14:27:11 \o/ 14:27:14 nice 14:27:39 OK. Anything else concerning the sprint? 14:28:07 thanks for everyone participating on it! 14:29:18 OK. Next up. 14:29:26 #topic DebConf 25 debrief 14:29:37 Since I mixed up the days, I missed the LTS BoF :-( 14:29:46 Beuc: Do you want to talk about what was discussed? 14:30:14 el_cubano, you can find the agenda at https://debconf25.debconf.org/talks/106-debian-lts-bof/ 14:30:28 and thanks to Beuc, we had an informal meeting afterwards 14:31:05 I thought the BoF would be an informal meeting for the LTS Team, but actually it was a Q&A in the lecture hall, hosted by santiago and LucasKanashiro[m], so we had a quick meeting with the remaining members after that :) 14:31:32 The BoF mainly talked about introducing point releases in LTS. 14:31:57 The pad seems offline now, so we need to go to https://salsa.debian.org/debconf-team/public/data/dc25/-/raw/main/etherpad/txt/106-debian-lts-bof.txt 14:32:10 thanks 14:32:40 (again, sorry if we didn't involved more the other team members during the bof itself. it was not at all something aimed to be focus on kanashiro and myself) 14:34:06 Yeah just to clarify there wasn't a secret cabal meeting with contributors on-site ;) 14:34:29 +1 14:34:31 And if there had been, we certainly wouldn't tell you about it ;-) 14:35:00 I was under the same impression as Beuc, though things worked and it was nice to see people using LTS also asking questions 14:35:47 Agreed. As with having participants in the sprint from outside the team, it is nice to see LTS becoming more well known and more of a community growing up around it. 14:36:08 There was also a debusine conf (which I didn't attend, waiting for the vid) and a debusine BoF/Q&A. 14:36:46 https://salsa.debian.org/debconf-team/public/data/dc25/-/blob/main/etherpad/txt/30-debusine-workflow-bof.txt 14:36:57 The vids are already up, but I don't have the URL handy just now. If someone doesn't have it now, I'll make sure to post it later. 14:38:05 el_cubano: I did add the links in the meeting notes 14:38:14 just no 14:38:20 s/no/now/ 14:38:27 charles: Thanks! (I just saw them show up about 10 seconds ago) 14:38:51 OK. Anything else about DebCamp, DebConf, or the Debusine and LTS BoFs? 14:39:15 Nice seeing other LTS people for the 1st time :) 14:39:20 +1 14:39:43 indeed! 14:39:53 and signing GPG keys :) 14:40:44 OK. Moving on... 14:40:54 #topic High-performance 'git blame' for CVE history 14:41:05 This is something that Beuc and helmut collaborated on during the sprint 14:41:33 Basically, there is now a project in Salsa (https://salsa.debian.org/lts-team/cvehist) that gives each CVE as a separate file. 14:41:54 This makes 'git blame' effectivel instantaneous. 14:42:18 Beuc: I see that you changed "instantaneous" to "fast", but I stand by my original choice of word :-) 14:43:17 Yeah, 1-2s. 14:43:32 I wonder how fast it would be if there was one file per year 14:44:10 I think that was suggested in issue #1 in the security tracker project, but I don't know that the performance was measured by whoever made the suggestion. 14:44:26 With per-year file, it's much harder to understand the progression of a CVE 14:44:37 I mostly use it with git-log or gitk 14:44:39 I'd prefer to have one file per CVE 14:44:56 git blame is not that useful in this context 14:45:09 it makes easier to get data from a specific CVE 14:45:27 if ther sec team were to agree with one file per year, that would likely be good enough to me. 14:45:40 I've definitely found it to be extraordinarly convenient when using a single CVE file via 'git log -p' 14:46:22 I think I saw other distros tracking by CVE as well 14:46:52 I also found one file per CVE convenient 14:47:46 So the good news is that it's now automated, Freexian infra updates it 4 times a day :) 14:48:16 Agreed. That is good news. 14:48:19 thanks for your work Beuc and helmut 14:48:28 Anything else on this topic? 14:48:32 it makes very easy to check the "lifecycle" of that specific CVE, so thanks for that! 14:49:12 specially updates in the NOTES field :-) 14:50:50 OK. Moving on. 14:50:59 #topic Debusine-based workflows update 14:51:07 santiago: your turn 14:51:58 as you all may be aware, there are debusine-based LTS and ELTS workflows available 14:52:28 for LTS, we strongly encourage everybody to use them, in debusine.d.n 14:52:37 for ELTS, it will become the reference 14:53:14 Does anyone have objections to making ELTS uploads via Debusine mandatory? (i.e. disabling direct uploads to deb-master.f.c) 14:53:56 for now, the previous buildd-based workflow is still available, just in case, but we aim to decommission it 14:54:10 Do we have a plan for packages that fail to build with sbuild+unshare (debusine)? 14:54:20 TL;DR: what helmut is asking 14:54:34 That amounts to using debusine provide-signature where you may now (trixie) put up artifacts and sign the resulting changes. 14:54:44 jochensp: fix them one by one as the need arises 14:55:15 Is the binary-from-debusine signing issue eventually fixed? I think we were waiting on a new debusine-client being available (but blocked by the trixie freeze) before deploying the new source-signing workflow. 14:55:43 https://salsa.debian.org/freexian-team/debusine/-/issues/944 14:55:47 We'd disable the rebuildd infrastucture as a first step and only look into decomissioning them after a while of no issues. So initially, the disablement would be revertible. 14:56:18 helmut: seems very reasonable 14:56:23 +1 14:56:28 Beuc: the workflows have been updated. Debusine uses its own key for signing binary .debs. you're expected to remote sign the .dsc + .changes 14:57:45 autopkgtests remain with ci.f.c for a while still as regression tracking matures on the Debusine side 14:58:40 helmut: in principle I'm all for it. but I have recently hit an issue with the debusine builds, and may need to resort to manual uploads until it works reliably, see https://salsa.debian.org/freexian-team/debusine/-/issues/984 14:59:54 helmut, I'll need to try, my last experience with debusine provide-signature was effectively asking me to blind-sign whatever it got from the network, without even a way to inspect it. I think we don't have the related debusine-client changed in trixie yet? 15:00:01 pochu: we may hold off until that's sorted out 15:00:22 Beuc: I think it is, but I haven't tried it yet 15:00:29 Beuc: trixie has a debusine-client that works with local artifacts. please retry and report back. 15:01:00 actually bookworm-backports has 15:01:33 OK. Let's try to wrap this up. 15:01:49 Last call for questions/comments on the Debusine workflows matter. 15:02:09 to me this looks like, there still are concerns and we should push back disablement slightly. santiago, do you agree? 15:03:38 the only concern is see is from pochu, right? 15:04:07 well I'd like to have the opportunity to try a new source upload 15:04:11 and update the doc :) 15:04:11 also beuc needing to retry. 15:06:02 OK, I've checked that the updated workflows included signing a _source.changes file, but yeah, we can wait to confirm from Beuc 15:06:11 Beuc, do you have any pending update to try it? 15:06:29 Excellent. 15:06:35 santiago: Any final comment on this issue? 15:06:41 santiago, I'll reupload my aaapp/dddep experiment 15:07:11 and revise the 20250725 notes from the doc :) 15:07:21 *20250705 15:07:29 el_cubano, just to say that we don't want to keep both workflows available too much time 15:07:32 Beuc, thanks! 15:08:07 santiago: ack. Let's hope that by this time next month we've managed to move everything over. 15:08:13 Moving on... 15:08:20 #topic Any Other Business 15:08:35 Does anyone have something to bring up here? 15:09:46 [ELTS] jessie ELTS has reached EOL 15:11:54 OK. Last thing. 15:12:01 btw pochu you removed jessie from the ELTS tracker but I think the tracker code/config needs to be updated at freexian 15:12:01 #topic Next meeting 15:12:19 Beuc: yes I opened a ticket with sysadmin 15:12:20 do we want to keep release announcement in www.debian.org/News? Currently it's gone (as you probably know because the thread in debian-project) 15:12:40 sorry, I was searching which list the thread was going on 15:12:46 Beuc: yes, that's pending. 15:12:52 #topic Any Other Business 15:13:02 thx 15:13:03 (It looks like a moved on a little too quickly) 15:13:16 do we want to keep release announcement in www.debian.org/News? Currently it's gone (as you probably know because the thread in debian-project) 15:13:40 what is gone? 15:14:11 some web pages for old news 15:14:32 the bullseye announcement in the website - there is still the mail in the mailing lists 15:14:42 this is the bookworm one https://www.debian.org/News/2023/20230610 15:16:02 charles, well, IMO, it would be good to keep (old) release announcements 15:16:10 +1 15:16:11 and News 15:16:17 and to avoid breaking links 15:16:33 yeah, it's the same feeling for me 15:17:05 I did poke people at debconf about it and will try to follow-up 15:17:41 Anything else on this? 15:18:34 nothing more on my side 15:19:13 OK. 15:19:15 Thanks. 15:19:20 #topic Next meeting 15:19:23 Next meeting: 2025-08-28 14:00 UTC [Location: Jitsi: https://jitsi.debian.social/LTS-monthly-meeting] 15:19:44 With that, we are done. Thanks everyone for participating today! 15:19:58 \O 15:20:00 thanks everyone! 15:20:02 thanks o/ 15:20:06 o/ 15:20:08 Thanks ! 15:20:14 thanks! o/ 15:20:20 thank you, everyone! 15:21:36 #endmeeting