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