14:00:30 <santiago> #startmeeting
14:00:30 <MeetBot> Meeting started Thu Mar 26 14:00:30 2026 UTC.  The chair is santiago. Information about MeetBot at https://wiki.debian.org/MeetBot.
14:00:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:36 <eamanu> hello!
14:00:50 <ah[m]> Hi!
14:00:51 <santiago> #rollcall
14:00:55 <Beuc> o/
14:00:59 <santiago> please say hi if you are around
14:01:01 <ah[m]> o/
14:01:10 <eamanu> o/
14:01:11 <jochensp> hi
14:01:12 <guilhem> hi there
14:01:28 <ta> hi
14:01:31 <utkarsh2102> hi!
14:01:33 <slyon> o/
14:01:41 <santiago> as a reminder, that meeting agenda can be found at https://pad.riseup.net/p/lts-meeting-agenda
14:02:47 <petn-randall> hi
14:03:04 <santiago> let's move forward with the first topic:
14:03:13 <santiago> #topic new members
14:03:43 <charles> o/
14:03:56 <santiago> we have two people onboarded in the team since last month \o/: slyon and eamanu
14:04:04 <charles> welcome!
14:04:06 <rouca> hi
14:04:15 <jochensp> welcome :)
14:04:21 <petn-randall> hi and welcome! :)
14:04:23 <santiago> both Lukas and Emmanuel were on the loop since several months ago
14:04:24 <slyon> :) thanks, glad to be around!
14:04:39 <eamanu> \o/ thanks!
14:05:17 <santiago> they have both prepared their first DLAs (and other updates) during 2025
14:05:47 <jochensp> PSA: please add your name when adding topics to the pad
14:06:24 <jochensp> thx :)
14:06:26 <santiago> slyon, eamanu, anything to say here before we move on?
14:07:11 <eamanu> no from my side, only thanks! :-)
14:07:52 <slyon> thanks for the warm welcome. This month was a bit slow for me but I'm hoping to be fully up to speed soon.
14:08:18 <santiago> ACK. Welcome again to both of you!
14:08:59 <santiago> #topic Action item review
14:09:14 <santiago> let's review the action items from previous meeting
14:09:35 <santiago> - Follow-up to ML and Andreas concerning upload of nvidia-graphics-drivers
14:10:02 <santiago> I don't have news myself. tobi, are you around? do you have any updates here?
14:10:46 <santiago> I guess no, and we should carry this topic over again
14:11:32 <santiago> #action follow-up to ML and Andreas concerning upload of nvidia-graphics-drivers
14:11:59 <santiago> next item: Start a discussion about debian-security-support being installed by default - Utkarsh to file a bug to discuss this publicly.
14:12:21 <utkarsh2102> sigh, carry it over, please :(
14:12:31 <santiago> ack
14:12:57 <santiago> #action Start a discussion about debian-security-support being installed by default (carried over from last month)
14:13:32 <santiago> next item: update the documentation concerning work priorities and package queue management, to ensure we aren't using scarce hours resources to work on landing packages that "don't have any known user"
14:13:56 <santiago> Beuc, would you do the honor here?
14:14:29 <Beuc> We updated https://freexian.gitlab.io/services/deblts-team/documentation/lts/information-for-lts-contributors.html#lts-priorities
14:14:45 <slyon> Maybe related to this... (but we can also discuss in AOB): Should we do an ELA when a package is not listed in ela-needed? The backport I've been working on would be very easy (same version in buster and bullseye, but is only listed in dla-needed.txt, not ela-needed.txt)
14:14:58 <Beuc> (also I just dropped a few packages from dla-needed.txt, as FD this week)
14:15:29 <santiago> thank you, Beuc!
14:15:48 <slyon> according to ^ I assume I should ignore ELTS in this case?
14:16:15 <santiago> slyon, what is that package?
14:16:25 <slyon> asterisk
14:16:57 <Beuc> slyon, normally no ELTS update if not in packages-to-support*
14:17:13 <santiago> which is: nobody is using it
14:17:24 <slyon> ACK, fair enough
14:18:51 <santiago> As said during the previous meeting (on jitsi), I'd like to highlight that part of the reasons to avoid working on packages (on LTS) with no known users, is that, for consistency across the different debian releases, we would end up giving some work to other teams
14:20:02 <santiago> so we aim to be nice with other Debian teams, in those cases when a package doesn't warrant an update
14:20:30 <guilhem> exception is when a package is supported for release n but not n+1 right?  for instance mapserver was in stretch but not buster (and i fixed both)
14:21:53 <santiago> those are particular cases, especially because, in general, we aim to start working on the more recent releases while backporting the patches...
14:22:13 <slyon> I guess that makes sense to keep a consistent upgrade path
14:22:54 <santiago> but in those cases there are known users, at least in an old release
14:24:09 <santiago> anything else here?
14:25:04 <santiago> we have only one "regular" new topic then:
14:25:17 <santiago> #topic Debusine related updates
14:26:08 <santiago> giving updates is something that is usually done by helmut (and I don't intent to hijack the topic :-P)
14:26:23 <helmut> go ahead
14:26:46 <utkarsh2102> i have a question though - love regression testing - it's great but i'm not sure it's fully accurate?
14:26:47 <santiago> two news that are worth to be shared:
14:26:59 <helmut> we deferred regression tracking for so long and now it is there \o/ your experience with it?
14:27:12 <santiago> 1. that ^
14:27:38 <santiago> utkarsh2102, do you have more details please
14:28:24 <helmut> example: https://debusine.freexian.com/freexian/elts-staging/work-request/148935/
14:28:54 <charles> nice table!
14:29:07 <utkarsh2102> yes. i see items which were "failed" in last build and "failed" in the new upload - and it shows as regression without much details why.
14:29:29 <petn-randall> Somewhat on-topic: As I worked on ansible I noticed that there were some tests failing exclusively on debusine, and not on debci/salsaci. Should I file a bug report?
14:29:30 <helmut> hah. that's a funky detail. the presentation might improve
14:30:01 <jochensp> petn-randall: link=
14:30:06 <jochensp> s/=/?/
14:30:28 <utkarsh2102> and there's more - i can flag all of them after the meeting or async whenever that happens
14:30:30 <helmut> debusine tracks failures at a more granular level. e.g. for autopkgtest it tracks individual test cases. if there is a test case that succeeds in the reference and fails in the regression test, then it is considered a failure even if both of them have at least one failing test case
14:30:40 <petn-randall> I assume it's because of incus behaving differently under the hood. One sec.
14:31:07 <santiago> utkarsh2102, probably the best place to report this would be #debusine, or directly filing an issue
14:31:14 <helmut> petn-randall: ci.debian.net is in the process of switching from lxc to incus. your tests shall fail on ci.d.n soon
14:31:27 <utkarsh2102> but wanted to know if things are ready to be tested and report issues or if it's still in the early phase and it's being worked on?
14:31:30 <utkarsh2102> yep, definitely!
14:31:54 <petn-randall> https://debusine.debian.net/debian/developers/work-request/514790/
14:32:00 <helmut> utkarsh2102: yes, but there is a significant chance that the package is buggy rather than the infrastructure
14:32:27 <petn-randall> helmut: Oh, ok. Not sure if it's worth the work to patch up all the failing tests then.
14:32:38 <utkarsh2102> ok, super! in that case, would like to learn more and help imporve the presentation/information that's provided to the user.
14:32:49 <petn-randall> In (E)LTS I mean. For sid it surely makes sense.
14:32:50 <rouca> yes I wil like a transition view
14:33:04 <rouca> i have a problem with bind/buster
14:33:07 <buxy> utkarsh2102: https://salsa.debian.org/freexian-team/debusine/-/issues/1372
14:33:15 <utkarsh2102> because to me - it looks very odd to conclude something is a regression when it's failed in the past and in the newer upload.
14:33:46 <santiago> petn-randall, well, it depends. we rely on autopkgtest to verify we don't introduce regressions, so it may make sense to fix tests in LTS and ELTS too
14:33:48 <buxy> we are analysis at the individual test level, if you go from 1 failed tests to 2 failed tests it's a regression
14:33:58 <utkarsh2102> buxy: oh, yes, +1 -> i saw that too
14:34:01 <utkarsh2102> and was very confused
14:34:19 <utkarsh2102> hm, i see - is that something we can present somewhere better?
14:34:39 <utkarsh2102> we can obviously discuss outside this meeting in the #debusine channel
14:35:07 * LucasKanashiro[m] waves
14:35:23 <buxy> Yup, we certainly should try to present this better.
14:35:24 <petn-randall> At least for upstream ansible they've made clear that they don't want to put work on the tests running anywhere else than on github CI, so the burden would fall on Debian/Freexian to patch up the tests.
14:36:04 <charles> petn-randall: ouch...
14:36:44 <utkarsh2102> also just wanted to say: really love that feature - very helpful; thanks for working on this!
14:36:54 <helmut> petn-randall: e.g. facts_linux_network is possibly a broken test
14:37:29 <jochensp> helmut: agreed (though could also trigger due to a different autopkgtest configuration)
14:39:06 <helmut> petn-randall: maintaining a list of tests to be skipped might be feasible, no?
14:39:45 <petn-randall> helmut: We can always skip the sub-tests, but then that unit won't be tested at all.
14:40:04 <petn-randall> It's probably the route with the least work.
14:40:22 <petn-randall> Sorry, didn't want to derail the meeting with it.
14:40:42 <santiago> and for those that would be worth to fix, covering the burden costs is something that could be discussed, probably on a case-by-case basis
14:40:42 <helmut> ideally, we'd run amd64 tests (and that means arch:all tests in particular) on kvm, but we need more debusine features for that
14:41:27 <petn-randall> Is isolation-machine already a feature in debusine?
14:41:38 <santiago> petn-randall, yes, but it doesn't work for all the archs
14:41:47 <helmut> it is, but you can only select it for all archs and then you get stuck work requests
14:42:16 <helmut> what we need is a way to say "use isolation-machine for amd64 and incus otherwise"
14:42:45 <santiago> https://salsa.debian.org/freexian-team/debusine/-/issues/653
14:42:50 <helmut> ci.freexian.com did provide that (as long as it had arm workers)
14:44:13 <santiago> anything else regarding regression tracking?
14:44:27 <helmut> longer term, the elts repository itself shall move into debusine. deb.freexian.com would then become a mirror of the thing inside debusine.f.c
14:45:39 <santiago> 2. tag-based scheduling is now possible
14:46:12 <jochensp> is there documentation for it? ^
14:46:32 <santiago> packages that require high resources can be scheduled to large workers
14:46:42 <helmut> jochensp: ideally you should not need to interface with tag based scheduling. if you experience packages that fail to build due to insufficient resources, report them
14:47:03 <jochensp> ack (I assume it is an admin feature?)
14:47:55 <utkarsh2102> woooooo
14:47:57 <utkarsh2102> that's nice!
14:48:03 <utkarsh2102> +1 on asking for documentation^
14:48:05 <utkarsh2102> on how to do it, et al
14:48:09 <helmut> mostly so. you cannot change worker-provided nor worker-required tags. you can change task-provided and task-required tags to some extent in principle to influence choice of worker, but the main way to do this is task configuration which is administrative
14:49:33 <santiago> does this warrant a documentation update: what to do if you are working on a package that requires large resources (otherwise it fails to build...)?
14:49:53 <helmut> https://freexian-team.pages.debian.net/debusine/reference/tasks/task-configuration.html https://freexian-team.pages.debian.net/debusine/reference/devel-blueprints/tag-based-scheduling.html I don't think you want to go into that level of detal
14:50:17 <Beuc> are there other tag use-cases (besides "needs lotsa resources")?
14:50:18 <utkarsh2102> interesting
14:50:45 <helmut> Beuc: once we have cloud workers, tags can be used to ensure that package builds (as opposed to qa tasks) do not run on cloud workers
14:51:22 <helmut> debusine.d.n has cloud workers, also see https://salsa.debian.org/freexian-team/debusine.debian.net/support/-/issues/14
14:51:47 <Beuc> OK, so I guess nothing we should dwelve too deep into for LTS/ELTS.
14:52:21 <helmut> the takeaway should be, if your builds OOM or -ENOSPC, reach out and tag based scheduling is the feature that'll make your builds work
14:52:59 <Beuc> noted
14:54:08 <santiago> #action Document that is currently possible to use tag-based scheduling, reaching out to admins
14:54:20 <santiago> any volunteer for that?
14:54:53 <santiago> in the meantime, let's move on
14:54:57 <santiago> #topic AOB
14:55:02 <helmut> santiago: question: who manages the task configuration for elts at this time? Ideally that'd transition to elts coordinators. ;)
14:55:28 <santiago> helmut, indeed!
14:55:34 <santiago> that something I need to work on
14:56:08 <helmut> santiago: practically speaking the answer is cjwatson and buxy for now.
14:56:13 <santiago> slyon, is there anything else to be discussed about your AOB item?
14:56:29 <santiago> WRT the ELAs and ela-needed
14:56:35 <santiago> helmut, ack
14:56:59 <slyon> no, ELTS was all clarified above
14:57:08 <santiago> OK
14:57:38 <santiago> #topic Who's attending MiniDC Hamburg?
14:58:08 <santiago> I guess interested people could add their names into the list in the agenda :-)
14:58:29 <slyon> That's mostly me being curious, as I'm pondering going to Hamburg for the weekend and it would be nice meeting some of you folks
14:58:47 <santiago> sure, and that's a good question :-)
14:58:50 <petn-randall> I'll be in Hamburg all week.
14:58:50 <santiago> same for:
14:58:58 <santiago> #topic Who plans to attend DC26?
14:59:23 <petn-randall> NAK for DC26 :-/
14:59:45 <santiago> sorry for speeding up, but we're almost at 1h of meeting
14:59:55 <LucasKanashiro[m]> on the same topic "Who is attending MiniDC Campinas?" :)
15:00:07 <santiago> LucasKanashiro[m], o/
15:00:13 <charles> kanashiro: I will \o/
15:00:34 <santiago> #topic Why is CVE-2026-2007 (and others) marked as "<removed>" in data/CVE-EXTENDED-LTS/list?
15:00:49 <santiago> jochensp, is this already answered. anything else on this?
15:01:01 <Beuc> FTR "these are entries created by bin/elts-sync-renamed-packages, they need a new package-level entry for postgresql-<oldver>; <removed> means not in unstable"
15:01:10 <Beuc> also don't remove these :)
15:01:11 <jochensp> only a nit: when marking the package unaffected, should I keep the <removed> entry?
15:01:23 <santiago> Beuc, thanks
15:01:38 <Beuc> <removed> can be changed to <not-affected> if the whole version (all dists) is not-affected
15:01:49 <jochensp> ack, thanks :)
15:02:11 <Beuc> otherwise add dist-level entries  [buster] - blah <not-affected> (xxx)
15:02:11 <santiago> great, so that's seems to be everything on the "regular" agenda
15:02:45 <santiago> next meeting is scheduled for 2026-04-23 - during MiniDC Campinas (on jitsi)
15:02:56 <rouca> :)
15:03:28 <santiago> so we can conclude the meeting, and if you have anything else to be discussed for the appendix, please don't hesitate to speak up :-)
15:03:36 <santiago> #endmeeting