14:00:07 <el_cubano> #startmeeting 14:00:07 <MeetBot> Meeting started Thu May 22 14:00:07 2025 UTC. The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:07 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:12 <el_cubano> Greetings everyone! 14:00:17 <el_cubano> Agend is here: https://pad.riseup.net/p/lts-meeting-agenda 14:00:17 <spwhitton> Good afternoon. 14:00:21 <el_cubano> #topic Roll Call 14:00:21 <ta> hi 14:00:24 <tobi> \o 14:00:24 <spwhitton> Hello 14:00:28 <santiago> o/ 14:00:29 <Beuc> o/ 14:00:31 <santiago> good morning! 14:00:40 <el_cubano> Please identify yourself so that we have a record of your participation. 14:00:44 <el_cubano> o/ 14:00:47 <helmut> good afternoon 14:00:53 <jochensp> moin 14:00:55 * LucasKanashiro[m] waves again 14:01:12 <charles> o/ 14:01:17 <guilhem> hi 14:03:06 <el_cubano> OK. It looks like this might be everyone. 14:03:14 <el_cubano> So, let's get started. 14:03:24 <el_cubano> #topic New team members 14:03:44 <el_cubano> There were no new members joining the team in the last month. 14:04:02 <el_cubano> #topic Action item review 14:04:22 <el_cubano> There were no action items from last month's meeting or outstanding action items from prior meetings 14:04:40 <el_cubano> #topic Reminder: Check your FD assignments 14:05:10 <el_cubano> I dispatched FD slots yesterday, so please check your assignments (if you have made yourself available for FD) 14:06:11 <el_cubano> As noted in my email, if you find that you were assigned a week that conflicts with something (e.g., summer holidy or family holiday), please either seek to swap with someone else's assignment, or let the coordinators know and we can help. 14:07:25 <el_cubano> OK. It looks like there are no comments/questions about FD assignments 14:07:30 <el_cubano> #topic Reminder: please, beta-test debusine 14:07:40 <el_cubano> santiago: I moved your item up to have the reminders together 14:07:47 <santiago> ok! 14:08:18 <santiago> thanks to all of you who have tested the LTS (and ELTS) workflows available 14:08:39 <helmut> In case of issues with Debusine, don't hesitate to approach me directly (via this channel), though do not expect autopkgtests to work at this point. 14:09:01 <santiago> the call for testing remains open. and please, report any issue that you find out to the debusine team + myself 14:09:22 * petn-randall waves again. 14:09:42 <santiago> we aim to move our workflows to debusine by the end of June, so testing now is very welcome 14:09:53 <spwhitton> santiago: wow! 14:10:00 <spwhitton> that's soon! 14:10:00 <helmut> We also have known issues with piuparts/lintian in jessie, but I don't think we're going to fix jessie-related stuff 14:10:08 <charles> are there any other obious thing that is know to not be working aside from autopkgtest? Just so we don't over report a very well-known problem 14:10:29 <santiago> spwhitton, I've mentioned that, at least, in the previous meeting and by email 14:10:45 <tobi> (or reframing charles wording, is there an issue tracker?) 14:10:46 <spwhitton> santiago: somehow I missed it, sorry. it's exciting :) 14:11:02 <tobi> *rephrasing 14:11:06 <santiago> https://salsa.debian.org/freexian-team/debusine/-/issues/ 14:11:24 <helmut> Since suites are mirrored now, running reverse dependency autopkgtests should technically work now, but the actual test tends to have network issues and tmpfails. Also regression testing is not implemented. 14:11:50 <charles> ack, thanks helmut 14:12:07 <santiago> and uploads to elts still require to include the .orig.tar.* (-sa) 14:12:30 <helmut> right. if you upload without -sa (to debusine), it'll likely build and stuff and then fail uploading to staging 14:12:39 <el_cubano> and ELTS uploads still require the 'dcut extended-lts migrate ...' step 14:13:32 <jochensp> and you can ignore the repo mails with "try harder" 14:13:38 <tobi> imho the dcut .. migrate is a feature, will it stay? 14:13:56 <santiago> tobi, the migrate feature will remain, for now 14:14:09 <el_cubano> I actually think it is redundant with the 'debusine provide-signature' step. 14:14:28 <helmut> tobi: the goal is to move autopkgtests into debusine and then to move the repository into debusine. at that point you prepare each update in your own workspace and adding your packages to the main repo (collection) is a step of explicit acknowledgement 14:14:39 <helmut> tobi: it's no longer dcut migrate, but it remains explicit 14:15:01 <helmut> el_cubano: it is not yet, because debusine does not do meaningful autopkgtests yet 14:15:02 <tobi> thanks helmut, that's great 14:15:44 <charles> santiago: your email calling for beta-testers has crucial info for setting up debusine for ELTS uploads, are they documented somewhere else? 14:15:54 <el_cubano> helmut: Sorry, I was referring to the explicit step of accepting the upload. 14:15:58 <helmut> once autopkgtests work, we consider having debusine upload to the main (non-staging) repo directly and then "debusine provide-signature" may serve as "dcut migrate" 14:16:06 <el_cubano> I understand that they do two different things. 14:16:22 <santiago> charles, not yet, I am preparing a MR for that, waiting for a more stable setup 14:16:37 <charles> santiago: ack 14:17:05 <spwhitton> What is the signature provided with provide-signature over? 14:17:22 <spwhitton> Let me rephrase that: what is the provided signature a signature over? 14:17:59 <jochensp> spwhitton: you sign the changes file, as normal 14:18:06 <jochensp> (just automated via debusine) 14:18:16 <helmut> spwhitton: debusine provide-signature downloads the things you usually sign (buildinfo, dsc, changes), uses your gpg key to sign them and hands back the signatures to debusine 14:18:23 <santiago> and related: https://salsa.debian.org/freexian-team/debusine/-/issues/816 14:18:55 <spwhitton> #816 seems important 14:19:27 <santiago> don't hesitate to upvote the issues you find important 14:20:12 <spwhitton> I am not sure whether it is okay to discuss this right now, but downloading something and immediately signing it does not make sense to me as a use of PGP. 14:20:46 <spwhitton> I think that I would need to generate a separate PGP key for ELTS work. 14:22:13 <el_cubano> I have a feeling that this requires a fairly in depth discussion, which is not really well suited to this meeting. 14:22:37 <el_cubano> THe debusine team have considered this, and I'm sure that they would be happy to discuss any concerns you have offline. 14:22:53 <el_cubano> Is there anything else on the debusine topic? 14:23:07 <el_cubano> santiago: Do you have any final remarks? 14:23:15 <santiago> not really 14:23:17 <buxy> But I'm eager to hear more about what can be done. Maybe an optional "show the files that are going to be signed" step could help too. 14:23:53 <spwhitton> buxy: showing a diff against the locally-built .dsc and .changes would probably be enough. 14:24:25 <santiago> and showing the checksums 14:24:43 <helmut> Note that for ELTS, you are signing the built .debs. 14:24:45 <spwhitton> only the .dsc checksum should change, right? 14:25:10 <helmut> The .dsc checksum should not change at all. The .changes file changes (as a result of adding binary .debs) 14:25:17 <jochensp> (do we actually need an extra gpg signature? for things hosted by Freexian it feels strange) 14:25:40 <spwhitton> I doubt I am the only person who is not okay with using their DD key to sign .debs produced by a third party machine 14:25:59 <jochensp> +1 14:26:06 <tobi> +1 14:26:08 <spwhitton> Generating new PGP keys is fine, but we need warning to sort it out. 14:26:25 <petn-randall> The question is what the value of that is. If the binary debs are generated on the debusine infra and never tested locally, what is the purpose of signing them off? 14:26:28 <utkarsh2102> +1^ 14:26:35 <helmut> Technically speaking, Debusine can perform gpg signatures. It has a signing worker. It has signing tasks. It could authorize you to sign with its key. Using that approach has the downside that we loose the connection of who performed the upload. This is why raphael requested using the DD signature for now. 14:26:39 <buxy> jochensp: at some point, we will use a debusine managed key for ELTS, yes, but we'd rather keep the original signature for now for tracking purpose until we have more experience with debusine's ability to keep track of who uploaded what 14:26:56 <tobi> yeah, why does the binary debs needs signing, can't we do a source-only upload? 14:26:58 <rouca> sorry being late 14:27:46 <helmut> buxy: isn't the .dsc signature sufficient? 14:27:56 <el_cubano> OK. While appreciate that this is an important discussion, I want to get the meeting back on track. 14:28:01 <tobi> I'm fine to sign the source dsc uploaded to debusine and let debusine do the rest. 14:28:13 <petn-randall> +1 14:28:43 <petn-randall> Or the _source.changes 14:28:59 <buxy> yeah, happy to have that conversation later and separately 14:29:08 <el_cubano> buxy: Thanks! 14:30:12 <el_cubano> OK. So, the main thing here that Santiago wanted to highlight at the start is that we still need some beta testing of the debusine workflows. If you are willing and able to help, that would be splendid and will result in a better overall experience when we transition our workflows over entirely. 14:30:27 <helmut> For the time being, the old infrastructure is still available. You may build and test on debusine and then perform a source-only upload to staging in place of provide-signature. 14:30:27 <el_cubano> For those of you that have concerns, the debusine team is engaged and willing to listen. 14:30:50 <el_cubano> helmut: Ah, yes, excellent point. Thanks for mentioning that. 14:30:56 <rouca> debusine is nice it help a lot for js, need only experimental track 14:31:11 <el_cubano> OK. Let's move on. 14:31:18 <el_cubano> #topic Handling "package removed from Xla-needed, but unstable/stable work remains" 14:31:34 <el_cubano> This came up either in the last meeting or on the mailing list (I don't recall which). 14:31:49 <spwhitton> Originally it was on the deblts-team alias. 14:31:55 <el_cubano> Ah, thanks! 14:32:23 <el_cubano> Basically, we use our Xla-needed files to capture "work that needs to be done in (E)LTS". 14:32:44 <el_cubano> As it happens, we often do the stable bits (or unstable, if applicable) first. 14:33:19 <el_cubano> However, in the case where the LTS (or ELTS) bits are completed and there are outstanding stable/unstable bits, it wasn't clear how to handle this. 14:34:02 <el_cubano> My thought is is remove the packae from Xla-needed (with the reservation of the DLA/ELA), and once it is removed then create an issue in the lts-updates-tasks project in Salsa. 14:34:15 <el_cubano> In the future this guidance may evolve. 14:34:40 <spwhitton> The context switch is a bit unfortuante. 14:34:51 <rouca> el_cubano: does it include PU in waiting ? 14:35:01 <spwhitton> For a lot of us the salsa issues are something we engage with only sporadically, but we're always engaging with the Xla-needed. 14:35:05 <spwhitton> Not a big deal, just to mention it. 14:35:08 <el_cubano> rouca: Personally, I don't think so. 14:35:19 <el_cubano> spwhitton: I agree that it's not ideal. 14:36:00 <el_cubano> It may be that as part of the security tracker sprint (next topic) we may define a more robust Xla-needed (or even a replacement) which would handle this in a cleaner way. 14:37:35 <el_cubano> Any other questions on this? 14:37:37 <guilhem> el_cubano: you mean this is not needed for -pu because there is already some trace of ongoing work in the bts? i normally send the debdiff to maintainers first and wait a few days before submitting a bug to r.d.o, isn't there a risk of double work then? 14:37:57 <petn-randall> Personally I do the higher releases first, to avoid situations where users upgrade and run into a regression because of this. 14:38:06 <el_cubano> guilhem: Yes, there is a slight risk 14:38:18 <el_cubano> petn-randall: And this precisely is our preferred approach 14:38:46 <tobi> petn-randall: this is ideal, but in real world often not working properly, as relying on other parties. 14:38:52 <el_cubano> In fact, we should encounter this situation (stable work remaining after LTS work complete) not very often 14:39:03 <utkarsh2102> el_cubano: do we not want to issue an update in unstable first? and then go back to stable, lts, elts, in that order? 14:39:09 <petn-randall> I guess I was lucky with my packages so far. :) 14:39:21 <rouca> el_cubano: I get it often due to PU process 14:39:24 <spwhitton> utkarsh2102: generally. but we wouldn't delay releasing the DLA just because the PU is still waiting. 14:39:39 <utkarsh2102> well, upload to pu should suffice. 14:39:48 <utkarsh2102> we don’t have to wait for its acceptance. 14:39:50 <tobi> adittionally, PU is in the 20% rule, while LTS not. 14:39:59 <spwhitton> tobi: not anymore. 14:40:13 <tobi> seems I've missed that 14:40:13 <el_cubano> IME, the RMs are fairly responsive, so if I put together something for SPU, upload, file the unblock then by the time I am done w/ the LTS bits then the OK has come in from SRM. 14:40:28 <utkarsh2102> i thought doing unstable -> pu -> lts -> elts is preferred when things aren’t fixed in any suite. 14:40:41 <el_cubano> tobi: That's another bit of documentation that needs updating. 14:41:04 <utkarsh2102> lts -> elts -> pu is OK when things are fixed in unstable and testing however. 14:41:18 <el_cubano> utkarsh2102: That's true. But there is the consideration that you might upload to SPU up to 8 weeks before a point release. 14:41:32 <el_cubano> We don't want to sit on (E)LTS updates that long. 14:41:54 <el_cubano> So, my practice has been, upload to SPU and once the OK is received from the RMs, then continue with the (E)LTS studd. 14:41:57 <tobi> I've also had packages (freerdp2) that were confirmed by SRM but still missed last point release. 14:42:00 <el_cubano> s/studd/stuff/ 14:42:08 <el_cubano> tobi: really? 14:42:12 <utkarsh2102> el_cubano: and hence the above bit, right? what i mean is, fixes to unstable should be higher prio and then to other stable releases in whatever reasonable order the uploader might choose. 14:42:19 <el_cubano> tobi: I wasn't aware such a thing could happen. 14:42:20 <utkarsh2102> given the time of the cycle, etc, etc. 14:42:53 <el_cubano> utkarsh2102: That partly depends on the responsiveness of the maintainer, if help is needed with unstable, etc. 14:43:03 <spwhitton> utkarsh2102: you're right, but that's precisely the original problem. if all the LTS suites are done there may be PU left. And in the original problem case, it was a whole different source package in stable (libsoup3 vs libsoup2.4) 14:43:10 <el_cubano> This definitely falls under "use your best judgment" 14:43:36 <el_cubano> spwhitton: I had forgotten about the detail that it was a different source package. 14:43:38 <utkarsh2102> it’s generally rare to miss something in spu after an ack from srm but cases like this happen once in a while. 14:43:45 <tobi> (#1054915) 14:43:54 <el_cubano> In that case I would go straight to an issue lts-updates-tasks. 14:44:23 <utkarsh2102> el_cubano: okey-dokey, thanks. been waiting on my package for that. can issue an update in that case in a bit. 14:44:25 <tobi> (https://salsa.debian.org/lts-team/lts-updates-tasks/-/issues/187) 14:44:31 <el_cubano> So, there are definitely corner cases. We do our best to keep an eye open and ensure that we don't miss work that needs to be done. 14:45:02 <Beuc> el_cubano, I had asked about our current _priority_ policy for SPUs (in the libsoup e-mail thread where you suggested I update docs). Here it looks like this is now mandatory and same priority as LTS itself. Do you confirm? 14:45:07 <el_cubano> Use your best judgment on these things and if you end up not sure about how to proceed with something, just ask on the LM. 14:45:10 <el_cubano> s/LM/ML/ 14:45:25 <el_cubano> Beuc: 'mandatory' is a strong word :-) 14:45:29 <petn-randall> It might also be relevant to note that your name in data/dla-needed.txt does not mean that no one else is working on the package update. 14:46:08 <el_cubano> I think the answer is "ideally, we would help to provide updates to unstable (should be somewhat uncommon) and stable (more common) and (E)LTS (in all cases)." 14:46:43 <el_cubano> That is, we are still the *(E)LTS* Team, but our remit includes helping out beyond just (E)LTS. 14:47:54 <santiago> a minor comment to note that the SPU (and unstable) work mostly mostly relate to minor / no-dsa issues. 14:48:27 <el_cubano> Beuc: Perhaps the better way to thik of it is "we help w/ unstable and SPU on a best effort basis" (taking into account what Santiago just said about minor/no-dsa). 14:48:49 <spwhitton> I mean, there are specific reasons for each case. 14:49:00 <Beuc> If we push a workflow were SPU needs to be done first, that becomes basically mandatory. Hence why I ask :) 14:49:03 <spwhitton> For unstable it's because of the principle that we want fixes to be tested in unstable before sending them to anyone else 14:49:30 <spwhitton> For stable, well, it will become an LTS dist eventually, so if we don't think the maintainer is going to fix it, we'll only be doing it ourselves in ~1.5y, why not do it now. 14:49:58 <Beuc> Since we have lots of longstanding packages in ./find-work there's the question of spending time on SPUs vs. tackling those. Especially for minor/no-dsa issues. 14:50:03 <el_cubano> Beuc: Sure, and if a maintainer or secteam is already working on a stable update and says "no thanks" to our offer of help, then we continue with the (E)LTS work as usual 14:50:54 <el_cubano> spwhitton: That's the logic we are applying. 14:50:57 <pochu> I feel like we're giving ourselves too much work by tackling no-dsa issues on LTS, then forcing ourselves to fix them in stable. maybe we need to revisit our no-dsa policy 14:51:12 <el_cubano> pochu: I actually have that exact item on my TODO list. 14:51:38 <LucasKanashiro[m]> agreed 14:51:39 <santiago> there is question of a broader discussion, and I need to we need to include the severity of the open CVEs so we can prioritize our work 14:51:50 <rouca> think also about maintainer that said : it should be first fixed in stable before LTS 14:52:04 <rouca> I have a few package like this 14:52:12 <utkarsh2102> pochu: well, we’re doing it for the future selves :) 14:52:27 <utkarsh2102> but i agree, revisiting it is a good idea. 14:52:31 <el_cubano> OK. I don't want this discussion to continue going of track. At the moment, we should continue as we have been, modulo the guidance I gave a bit earlier. 14:52:35 <LucasKanashiro[m]> but if it is no-dsa... 14:52:45 <el_cubano> s/of track/off track/ 14:53:01 <utkarsh2102> Lucas Kanashiro: then shouldn’t warrant a fix in lts/elts also :) 14:53:19 <LucasKanashiro[m]> yes, that's why we need to revisit the policy 14:53:36 <LucasKanashiro[m]> maybe it shouldn't be fixed 14:54:01 <el_cubano> OK. We are getting close to the 1 hour mark, so let's table this discussion (or better yet, take it to the mailing list). 14:54:14 <el_cubano> Moving on to the next topic 14:54:23 <el_cubano> #topic DebCamp25 sprint update 14:54:55 <el_cubano> For a variety of reasons I have been delayed in getting the plan for the long-awaited DebCamp25 security tracker sprint put together 14:55:22 <el_cubano> Shortly before this meeting started I published the issue list and sent out a public announcement relating to the sprint. 14:55:37 <el_cubano> I will follow with some added guidance for paid contributors later today. 14:56:15 <el_cubano> In one sentence: We want to improve the data/tools used by the LTS Team, and along the way we'd like the security tracker to benefit as well. 14:57:15 <el_cubano> I would very much appreciate plenty of feedback on the proposed issues and the announcement, and a robust discussion around all of this. 14:57:30 <el_cubano> It would help to make the sprint as beneficial as possible. 14:58:22 <el_cubano> OK. It looks like there are no comments/questions about this. 14:58:30 <el_cubano> So, next topic 14:58:35 <el_cubano> #topic Any other business 14:58:44 <el_cubano> Does anyone have anything to bring up for AOB? 14:58:50 <spwhitton> May I ask if there are any updates about refreshing the extra hours pools? 14:59:20 <el_cubano> spwhitton: There has been some internal discussion. Nothing has been decided as of yet, apart from the one-time refresh of the ELTS extra hours pool last week. 14:59:29 <spwhitton> Cool, thanks. 14:59:52 <el_cubano> I am quite aware that we are essentially operating at a deficit when it comes to hours. 15:00:05 <spwhitton> What makes you say "deficit"? 15:00:11 <el_cubano> And Santiago and I are seeing what can be done. 15:00:36 <el_cubano> spwhitton: That might not be the best word. Basically, we have people available and willing to work more hours than we have available to dispatch. 15:00:50 <spwhitton> I see, okay. 15:00:55 <spwhitton> Thank you for continuing to work on it. 15:01:00 <el_cubano> Ack. 15:01:09 <Beuc> There was mention about ensuring/allocating enough time for the sprint IIRC, anything in particular about that? :) 15:01:33 <el_cubano> Not yet. I need to coordinate w/ buxy about that, but I haven't had an opportunity yet. 15:01:44 <el_cubano> Look for more on that later today or tomorrow. 15:01:56 <Beuc> OK nice. 15:01:56 <el_cubano> Anyone else or anything else for AOB? 15:02:21 <rouca> no thanks 15:03:01 <el_cubano> OK. Then last item. 15:03:22 <el_cubano> #topic Next meeting 15:03:27 <el_cubano> Next meeting: 2025-06-26 [Location: Jitsi: https://jitsi.debian.social/LTS-monthly-meeting] 15:03:46 <el_cubano> And that is everything for today. 15:04:00 <ta> ok, thanks and byebye 15:04:05 <pochu> o/ 15:04:06 <el_cubano> Thanks very much to everyone for participating and for the robust discussions! 15:04:06 <spwhitton> thank you. 15:04:07 <jochensp> cu 15:04:09 <el_cubano> o/ 15:04:13 <charles> thanks everyone! 15:04:14 <santiago> thank you el_cubano, thank you everybody! 15:04:14 <petn-randall> cheers, until next time o/ 15:04:40 <tobi> bye everyone! 15:04:41 <LucasKanashiro[m]> thank you all o/ 15:05:07 <utkarsh2102> thanks! 15:05:22 <el_cubano> #endmeeting