19:00:29 <waldi> #startmeeting
19:00:29 <MeetBot> Meeting started Wed Jun 19 19:00:29 2024 UTC.  The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:29 <MeetBot> bwh: Error: Can't start another meeting, one is in progress.
19:00:39 <waldi> #chair bwh carnil
19:00:39 <MeetBot> Current chairs: bwh carnil waldi
19:00:42 <bwh> waldi: I'm supposed to be chairing this
19:00:56 <waldi> ups
19:01:08 <waldi> please
19:01:45 <bwh> #topic Use of IRC vs Jitsi for future meetings
19:02:13 <bwh> We've tried both now, so what do people prefer?
19:03:20 <bwh> I'm OK either way, so long as we end up with notes of all decisions
19:04:19 <carnil> I see the advantage of the video meeting in quicker interaction and clarification of missunderstanding. OTOH, I liked for the IRC meetings that we have the logs and important notes to take already trough the meetbot, and not having to switch focus to take notes
19:04:43 <waldi> i have to say i prefer the jitsi one, as it makes for easier discussion. yes, i did make a pretty bad job with note keeping last week
19:04:50 <carnil> I would slightly lean towards IRC meetings, but I will not object by any means jitsi meetings
19:04:55 <waldi> we can also decide on a case by case basis
19:05:05 <bwh> We could alternate (like LTS team does)
19:05:49 <waldi> also okay
19:05:54 <carnil> fine with me too
19:06:07 <maks> notes are quicker to read, hence slight lean to irc, I am fine with both.
19:07:08 <bwh> #agreed Alternating between meetings on IRC and Jitsi
19:07:19 <bwh> #topic Rebases for 6.9.y (targetting unstable) and 6.10~rcX versions?
19:07:49 <bwh> We have 6.9 in experimental and I guess the next 6.9 upload should go to unstable, right?
19:08:35 <carnil> I think so, if we know 6.9.2-1~exp1 builds everywhere then since 6.8.y is EOL, we should move to 6.9.y to unstable soon(ish)
19:10:11 <waldi> just do it
19:10:51 <bwh> Then we have to work on the update to 6.10 in experimental
19:11:26 <carnil> I see two additional issues: 1. We are bit too slow to follow upstream on releases and 2. we do not really look what changes between major version in terms of wha should we additionally add in support, hardening, features. I do not know if someone follows closely enough development to keep track of it. But maybe first focus on trying to stay on track with the actual versions imports
19:12:12 <carnil> bwh: correct, if we manage to have earlier now 6.10~rcX in experimental that will likely help with the switch later on for the unstable uploads
19:12:43 <bwh> I have really not followed upstream development that closely for some time
19:13:38 <bwh> At the moment I am making more time for Debian work and might be able to look more closely
19:14:30 <bwh> Is there any decision to be made re 6.10, excluding the build script issue that's a separate item?
19:15:58 <bwh> Assuming not, so I'll move on
19:16:02 <bwh> #topic Discussion on trixie kernel maintenance
19:16:10 <bwh> #link https://salsa.debian.org/kernel-team/linux/-/issues/8
19:16:47 <waldi> puh
19:17:38 <waldi> bwh: this link is only readable for team members
19:17:38 <carnil> this is a problem. Do you think upstream is strict at those EOL timings? Or if there is enough interest in a particular LTS series that they might prolong the lifetime?
19:18:36 <bwh> I think they're going to be strict unless someone they consider suitable volunteers to take over the branch
19:19:06 <waldi> that would be my expectation as well
19:20:05 <bwh> I've done it before but I don't really want that responsibility again (and I've been disengaged from upstream development long enough that I might not be accepted)
19:20:31 <bwh> This is why I mentioned CIP as an option
19:20:57 <waldi> what was CIP?
19:21:02 <bwh> or, possible option, rather - that would need to be discussed with them since their support scope is currently much narrower
19:21:33 <bwh> Civial Infrastructure Platform - https://www.cip-project.org/
19:21:34 <waldi> ah, https://www.cip-project.org/
19:23:29 <waldi> okay. i have no real opinion right now
19:23:45 <carnil> bwh: I can understand not wanting to take such a responibility again, in terms of time investment I assume this took a substantial amount of you free time. Cooperation with others: I have no experience/knowledge what other might consider suitable.
19:24:34 <carnil> switching though a new version in mid of the release feels risky (even though I know we did in past add support for an additional kernel, and LTS has this option as well)
19:24:48 <waldi> we only added kernels, we did not replace them
19:26:36 <carnil> right, for the etch-and-half IIRC, and LTS adds as well just src:linux-5.10, src:linux-6.1 but keeps the src:linux version in the release. This is why I think replacing the kernel would be quite risky.
19:26:40 <waldi> bwh: where can i read about their support scope?
19:27:30 <waldi> carnil: we need to talk about ways to handle such things still in the future. what we currently do strands stable using people. but not today
19:28:11 <bwh> waldi: There's some information at <https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance#maintenance_scope>
19:28:35 <bwh> In particular "Kernel configuration files provided by Members will be used as a reference to limit the maintenance scope."
19:29:57 <bwh> carnil: For ELTS (yes, not really Debian), the kernel upgrade became mandatory since the original kernels went out of upstream support already
19:31:16 <bwh> Well let's all think about this and then maybe we can discuss it further next time
19:31:23 <waldi> yes
19:31:26 <carnil> ack
19:31:46 <bwh> #topic Discussion on maintainership of bpftool
19:31:54 <bwh> #link https://bugs.debian.org/1057290#10
19:32:47 <bwh> My position is already stated in message #30
19:33:08 <bwh> Does anyone have a problem with that?
19:33:41 <waldi> nope
19:33:52 <carnil> no
19:34:29 <bwh> So, we're happy to hand over to Sudip with packaging on Salsa but not under kernel-team?
19:35:19 <waldi> i would prefer under kernel team
19:35:29 <bwh> Yes but he didn't want to do that
19:35:35 <carnil> if it moves to salsa, yes it can be under his maintainerspace. I would not object if he wants to maintain both though under kernel-team namespace, which seems an appropriate space for it
19:35:36 <waldi> libbpf is not team maintained, so this needs to change anyway
19:36:23 <bwh> or maybe I misread that
19:37:21 <bwh> Yes I think I misread
19:38:32 <bwh> #agreed Split out bpftool to separate source package under kernel-team with Sudip as uploader/maintainer
19:39:03 <bwh> #action bwh to update bug #1057290
19:39:10 <waldi> thx
19:39:16 <bwh> #topic Where do sysctl defaults belong, request from systemd maintainer
19:39:25 <bwh> #link https://salsa.debian.org/systemd-team/systemd/-/merge_requests/187#note_496591
19:39:29 <waldi> i'm in favour of a new package
19:39:49 <bwh> Definitely a new binary package
19:39:50 <carnil> for the previous topic, sorry for beeing slow: fwiw, message #35 contains his statement from Sundip on not wanting to move under kernel-team space
19:39:59 <waldi> ping can then loose the capability/suid, but needs to pull in those sysctl changes
19:40:00 <carnil> A new binary package
19:40:16 <bwh> carnil: Oh, hmm
19:41:21 <bwh> Do we want to build this from linux-base source or add a new source package?
19:41:28 <waldi> linux-base
19:42:06 <carnil> I would build it from the existing linux-base as new produced binary package containg the settings files
19:42:23 <bwh> #agreed Ship sysctl defaults in new binary package built from linux-base
19:42:30 <bwh> #topic Adapting the Debian build scripts for the tools build framework, causing actual problems
19:42:37 <bwh> #link https://lists.debian.org/debian-kernel/2024/06/msg00059.html
19:43:20 <waldi> i'm not longer sure why ben changed that all those years ago for all tools. at least i think we did not wrap all build stuff for tools before
19:44:02 <waldi> we way longer had a wrapper for modpost, because we build four variants, but apart from that
19:44:04 <bwh> What change are you referring to?
19:44:36 <bwh> Some of the old tools are built with our own Makefiles carried over from linux-tools
19:45:03 <bwh> I think the hyperv tools are because they didn't have a good Makefile originally
19:45:06 <waldi> not sure
19:45:35 <waldi> but we would need to look at that on a case by case basis
19:45:48 <bwh> For the rest we have some intermediate makefiles to run the upstream build system with appropriate options
19:46:05 <bwh> In some cases it looks like we have a choice of 2 build systems now...?
19:47:17 <bwh> In any case, everything under debian/rules.d would benefit from some review
19:47:36 <waldi> yes
19:48:42 <bwh> waldi: Are you volunteering? :-)
19:49:04 <waldi> i can take a look
19:49:51 <bwh> Is that an #action?
19:51:01 <waldi> #action waldi to review debian/rules.d
19:51:05 <bwh> Thank you!
19:51:39 <bwh> #topic Any other business
19:52:03 <waldi> not right now
19:52:04 <carnil> nothing from my side for today which could be covered in some minutes
19:52:37 <bwh> I realise I didn't get an action for the sysctl defaults
19:53:18 <bwh> #action bwh to add the sysctl defaults package to linux-base
19:53:28 <maks> thank you for the exp firmware upload, will have a look to keep it recent.
19:53:34 <waldi> bwh: okay. do you also communicate to systemd maintainer?
19:53:41 <bwh> waldi: Yes
19:53:55 <carnil> thank you
19:54:06 <bwh> Also carnil correctly pointed out that Sudip really didn't want bpftool under the kernel-team group
19:54:19 <bwh> So, I would like to revise that #agreed
19:54:34 <waldi> then i object
19:54:55 <bwh> Then can you update the bug with your reasons?
19:55:18 <waldi> aye
19:55:53 <bwh> and then I'll follow up with the decision
19:56:10 <bwh> #endmeeting