19:06:18 <carnil> #startmeeting
19:06:18 <MeetBot> Meeting started Wed Sep  4 19:06:18 2024 UTC.  The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:18 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:06:34 <carnil> #chair waldi bwh
19:06:34 <MeetBot> Current chairs: bwh carnil waldi
19:07:07 <carnil> So after some starting issue, welcome to todays kernel team meeting, I would like to propose the agenda a bit different as last time as I got some feedbacks on topics to handle
19:07:28 <ema> sounds good
19:07:31 <carnil> as salsa is flaky right now I take what I have from the git clone bit earlier today
19:08:18 <carnil> #topic trixie freeze approaching, fixing on kernel version: features to enable, concerns?
19:08:42 <carnil> The first topic is actually a bigger one. Trixie freeze is approaching and the aimed kernel to take for it will be 6.12.y.
19:09:02 <carnil> Two items came to my mind while thinking about it:
19:09:39 <carnil> - Do we lack enabled features between versions 6.1.y and 6.10.y (6.11-rcX) and upcoming 6.12 which we want to have enabled?
19:09:48 <bwh> What I've done previously is to go through the symbols listed by 'make listnewconfig' as we approach the freeze
19:10:16 <bwh> (only on amd64; I leave other architecture-specific symbols to their respective porters)
19:10:36 <bwh> I can try to do that at some point but I can be a big task
19:10:44 <bwh> it can be a big task
19:11:01 <carnil> ok that sounds like a good plan. The alternative approach I had in mind was to look at the kernelnewbies release summaries and check what could be interesting.
19:11:22 <ema> I can go through make listnewconfig for arm64
19:11:29 <carnil> bwh: I'm willing to help in this task to share workload
19:12:02 <bwh> OK so if there are 2 people we can start from the beginning/end of the list and meet in the middle
19:12:11 <bwh> or just split it in 2 to start with
19:12:39 <bwh> I don't know when I will have time to do that though
19:12:48 <carnil> sound good, and ema looks at  arm64 specific ones?
19:13:01 <ema> yup
19:13:15 <carnil> bwh: yes right we do not need to start now, but I think it will be sensible latest when we start preparing 6.12-rcX in experimental
19:13:50 <bwh> #action bwh will look through symbols listed by listnewconfig before freeze
19:13:54 <bwh> #action carnil will look through symbols listed by listnewconfig before freeze
19:13:54 <carnil> #action bwh, ema and carnil work through symbols listed by 'make listnewconfig' to check what is sensible to be enabled
19:14:02 <bwh> sorry
19:14:06 <carnil> ah no problem :)
19:14:49 <carnil> The other subtopic here is controversial: Do we have concerns about current release architectures to support them in trixie? If so, we would need to approach release team even sooner
19:15:30 <bwh> We should drop i386 due to limited upstream support
19:15:56 <carnil> I have seen we had recurring issues in particular with 32bit architectures, FTBFS one hand, i386 seems of concern about as well lacking security fixes for various issues
19:16:27 <hrw> I have a question (will wait in queue)
19:16:30 * ukleinek is late, excuse = family business + broken internet. Trying to connect to jitsi ...
19:16:39 <carnil> do you think we should raise that first informal in private with the release team?
19:16:44 <ema> ukleinek: no jitsi, we're on irc due to salsa issues
19:16:57 <carnil> ukleinek: it's continuing in IRC as jitsi is not working reliably
19:17:08 <ukleinek> carnil: \o/
19:17:13 * ukleinek reads backlog
19:17:28 <bwh> I would also like to cut down the mips64el flavours but would need to check which of them are broken
19:18:10 <bwh> carnil: This was discussed last year in Cambridge
19:18:43 <bwh> Still it needs to be announced a little before we do it
19:19:30 <carnil> I think it would be important to do that step then really soon now, correct?
19:19:36 <bwh> yes
19:20:07 <carnil> Anyone willing to take the lead and stand on "front"?
19:20:17 <bwh> Sure, I can do that
19:20:30 <carnil> I'm glad you have the courage :)
19:20:37 <carnil> I will formulate two actions:
19:22:06 <carnil> #action bwh takes the lead for the announcement to drop i386 due to limited upstream support. Plan to do that was discussed last year in Cambridge. Make sure to announce the drop enough in advance and early in upcoming weeks
19:22:25 <carnil> #action bwh checks which mips64el flavours could be cut down
19:22:38 <carnil> ^^ bwh hope that matches well
19:22:44 <bwh> OK
19:22:59 <carnil> if you will need help and support from others please *do* cry
19:23:19 <carnil> next topic from the free form list? or has anyone something to add to this?
19:23:32 <ukleinek> does that mean the i386 architecture will die?
19:23:58 <ukleinek> (in the sense that it will not be a release arch for Debian 13?)
19:24:01 <waldi> no
19:24:02 <bwh> No the plan was to keep supporting it as a secondary architecture
19:24:10 * ukleinek nods
19:24:11 <hrw> Fedora does not provide kernel/installer for i386. several packages (mostly libraries) are kept for 32bit compats
19:25:12 <KGB> 03linux 05master 06Ben Hutchings * [update] merge request !1186: [arm64] udeb: fix duplicated modules * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1186
19:25:53 <bwh> carnil: I think we can move on now...
19:25:55 <KGB> 03linux 05master 06Ben Hutchings * [merge] merge request !1186: [arm64] udeb: fix duplicated modules * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1186
19:25:55 <carnil> I propose to move to the next topic
19:26:01 <KGB> 03linux 05master 30beefa 06Marcin Juszkiewicz (via 06Ben Hutchings) 10debian/installer/ 10(17 files in 16 dirs) * introduce drm-core-modules udeb * 14https://salsa.debian.org/kernel-team/linux/-/commit/30beefa
19:26:01 <KGB> 03linux 05master 9c28f45 06Marcin Juszkiewicz (via 06Ben Hutchings) 10debian/installer/ 10modules/arm64/kernel-image 10package-list 04modules/arm64/mtd-core-modules * [arm64] move mtd to kernel-image * 14https://salsa.debian.org/kernel-team/linux/-/commit/9c28f45
19:26:01 <KGB> 03linux 05master 2c876d7 06Marcin Juszkiewicz (via 06Ben Hutchings) 10debian/installer/modules/arm64/ 10kernel-image 10usb-modules * [arm64] move 'typec' to kernel-image * 14https://salsa.debian.org/kernel-team/linux/-/commit/2c876d7
19:26:04 <KGB> 03linux 05master a52d206 06Marcin Juszkiewicz (via 06Ben Hutchings) 10debian/changelog * provide changelog for this branch * 14https://salsa.debian.org/kernel-team/linux/-/commit/a52d206
19:26:08 <KGB> 03linux 05master 1594cd3 06Ben Hutchings 10debian/ 10(20 files in 17 dirs) * Merge branch 'fix-udebs' into 'master' * 14https://salsa.debian.org/kernel-team/linux/-/commit/1594cd3
19:26:25 <carnil> #topic nfs-utils: Split python scripts into a separate package to make small installations with nfs-kernel-server not pulling in python3
19:26:41 <hrw> bwh: thanks for merging
19:26:41 <bwh> wontfix, python3 is already in Recommends not Depends
19:27:03 <carnil> We got a request both here on IRC (gioele), and through #1013868 to make the scripts in a separate binary package
19:27:47 <carnil> bwh: yes maybe this is enought to say. I wonder if the focus of the reporter was due to recommends beeing installed by default
19:28:10 <carnil> but I would be fine to just go ahead as you propose and mark it as wontfix with the rationale
19:28:11 <bwh> Oh, sorry no it's in Depends on nfs-common
19:28:36 <bwh> but Recommends in nfs-kernel-server (but that Depends on nfs-common so...)
19:28:56 <ukleinek> There is a MR for it (claimed in the bug report)
19:29:01 <carnil> mountstats is there in nfs-common which is python3
19:29:22 <carnil> (and nfsiostat)
19:29:51 <bwh> Let's move python3 to Recommends then
19:30:02 <bwh> in nfs-common as well
19:30:40 <ukleinek> us == ??
19:31:05 <carnil> bwh: so baseline would be: we try to avoid a separate package for the scripts
19:31:30 <bwh> Yes it doesn't seem worth adding another package for 2 scripts
19:32:36 <bwh> carnil: But as you have been doing most of the work on nfs-utils, please feel free to overrule my opinion :-)
19:33:34 <carnil> I will bring this to the reporter and explaining we want to avoid a separate package for just those scripts and are going to propose the move the Depends on python3 to a Recommends
19:34:13 <bwh> OK
19:34:20 <carnil> #action carnil followups on #1013868 explaining we want to avoid a separate package for only the scripts and propose to move python3 from Depends to Recommends as python3 is not a strict dependency for nfs-common
19:34:38 <carnil> time is running fast :(
19:34:48 <carnil> #topic Next uploads of 6.10.y to unstable
19:35:10 <carnil> First we have FTBFS, but this should be handled soon with the MR worked on
19:35:24 <bwh> Yes the fixes are all available and just need to be merged
19:35:51 <KGB> 03linux 05sid 06Ben Hutchings * [merge] merge request !1185: riscv64: fix module duplication detected by kernel-wedge starting with version 2.106 * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1185
19:35:57 <KGB> 03linux 05sid bdf5af9 06Aurelien Jarno (via 06Ben Hutchings) 10debian/ 10changelog 10installer/modules/riscv64/kernel-image 10installer/package-list 04installer/modules/riscv64/mtd-core-modules * 14https://salsa.debian.org/kernel-team/linux/-/commit/bdf5af9
19:35:57 <KGB> [riscv64] udeb: Ship mtd in kernel-image, drop mtd-core-modules and add it to to Provides of kernel-image.
19:35:57 <KGB> 03linux 05sid 1ab553b 06Ben Hutchings 10debian/ 10changelog 10installer/modules/riscv64/kernel-image 10installer/package-list 04installer/modules/riscv64/mtd-core-modules * Merge branch 'riscv64-kernel-wedge-2.106' into 'sid' * 14https://salsa.debian.org/kernel-team/linux/-/commit/1ab553b
19:36:02 <carnil> what is important here is that kibi and Sledge approached to please sync with them when linux approaches time to move to testing, as they want to get in some d-i updates related to SB in to testing and unstable "soon"
19:36:30 <carnil> #info Coordinate with kibi and Sledge for unstable uploads for src:linux for helping d-i uploads
19:36:32 <bwh> What exactly is the concern here?
19:36:38 <ukleinek> SB = secure boot?
19:36:46 <Sledge> yep
19:37:00 <carnil> bwh: no concerns here, just informational that whoever works on unstable upload should coordinate with kibi and Sledge
19:37:09 <Sledge> we want to get a d-i release out which will allow us to fix some build-dep issues on our side
19:37:33 <bwh> So you need to get debian-installer to migrate along with linux, or?
19:37:51 <Sledge> so we'll to check everything else works, basically
19:38:11 <Sledge> there was some concern about older kernel versions and some arches
19:38:14 <hrw> I hope that next 6.10.x will have MR/1186 and MR/1187 merged so I will be able to finally install Debian ;D
19:38:47 <bwh> Oh, so there is currently nothing newer than stable
19:38:52 <Sledge> normally we're not too bothered as we don't try to do d-i releases until close(r) to freeze
19:39:06 <Sledge> but this is a little out of the normal cycle, basically
19:39:56 <bwh> OK
19:40:51 <Sledge> hopefully no issues that will impinge on the kernel team <fingers crossed>
19:40:57 <ukleinek> hrw: I can look into !1187, is !1186 the issue mentioned earlier with kernel-wedge?
19:41:15 <ukleinek> ah, 1186 is alread merged
19:41:18 <carnil> OK, so I guess all are aware now and move to next two topics, and then close the meeting
19:41:29 <bwh> right
19:41:30 <carnil> #topic Discuss the arm64 64k page size merge request with additional data input
19:41:31 <hrw> ukleinek: thx
19:41:38 <carnil> this is more on ema and waldi I believe :)
19:42:01 <hrw> 64k pagesize kernel is handy on bigger systems
19:42:04 <ema> right, I was asked to provide performance data about 64k page size on arm64 kernels
19:42:06 <carnil> Context: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1169
19:42:22 <ema> I provided the data so now the question is whether we can go ahead with the MR :)
19:44:32 <ema> waldi: ping
19:45:11 <carnil> the concerns in 20240821 were about long build times IIRC
19:45:26 <waldi> i have no additional input over that
19:45:42 <bwh> So let's drop the 16k flavour in favour of 64k
19:45:59 <hrw> macbooks need 16k one
19:46:09 <bwh> and they need drivers that don't exist upstream
19:46:15 <ema> yeah but the debian kernel doesn't run on macbooks
19:46:20 <hrw> ok
19:46:44 <waldi> so we ship neither
19:46:51 <waldi> not 16k, nor 64k
19:47:21 <ukleinek> is 64k pages a pure performance thing? There are no machines that require it, right?
19:47:22 <llenn> I have 2 cents on i915 - is this a good time to share?
19:47:22 <ema> well, 64k has real world users benefiting from it
19:47:30 <ukleinek> llenn: no
19:47:43 <ema> which is why all major distros ship a arm64 kernel with 64k page size
19:48:34 <ukleinek> ..ooOO(That's wrong, Debian doesn't :-) SCNR)
19:49:04 <bwh> I don't think we're going to come to a decision in this meeting
19:49:18 <carnil> So longer build times are a concern, but we have two fronts, not to be resolved in next 10min
19:49:22 <ukleinek> +1 for dropping 16k and adding 64k
19:49:48 <ukleinek> (just my opinion, not trying to force a decision)
19:49:59 <carnil> I do not have a way out of the cycle
19:50:03 <ema> I'm not sure I understand the concern frankly
19:50:31 <ukleinek> +2 for discussing that not in the context of this meeting
19:50:53 <carnil> ok let's raise one last item, which I expect as well we might not find an answer, but we need to look at it
19:51:24 <carnil> #topic tech-ctte bug #1065416: Asking for input from kernel-team
19:51:44 <KGB> 03linux 05sid 06Ben Hutchings * [open] merge request !1188: [arm64] udeb: fix duplicated modules * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1188
19:51:50 <carnil> Stefano pinged me today on IRC, if we can have a look at #1065416, and in particular to https://bugs.debian.org/1065416#239
19:52:26 <carnil> I was out of all this discussion, but Stefano asked if there might be possible that we give kernel-team's point of view on the questions raised in this message
19:52:42 <bwh> I missed all the early discussion, have tried to catch up, and not yet finished
19:53:00 <bwh> I can take an action to respond
19:53:10 <carnil> bwh and waldi I'm not sure if I'm asking to much, would it be possible that you both shortcut yourself to work out a reply?
19:53:19 <carnil> ok then I make this as action
19:54:00 <carnil> #action bwh goes through the discussion of #1065416 and will respond to the questions from tech-ctte
19:54:19 <carnil> we are out if time
19:54:23 <carnil> #topic AOB?
19:54:44 <carnil> we did not look at current other issues, but I think this is fine this round
19:55:23 <hrw> I was going to ask is debian/changelog needed per commit or per MR
19:55:34 <carnil> if there are any other short topics, last thing is next meeting next week will be on IRC, who will chair it?
19:55:59 <ukleinek> I still have the todos from some weeks ago on my agenda and intend to tackle them until next week.
19:56:04 <hrw> but 1186 had one per MR and bwh took it so I feel that both ways are fine
19:56:08 <waldi> looks like it is my turn
19:56:11 <bwh> hrw: So far as I am concerned, it is OK to add it per MR
19:56:30 <carnil> waldi: then thank you if you take it
19:56:57 <hrw> bwh: thanks. makes life easier as patches can be reordered etc efore submittion
19:57:19 <bwh> (And I would really like to move to using gbp dch in future...)
19:57:49 <waldi> does not support merge requests at all
19:58:06 <carnil> I guess we can close now the meetng and discuss e.g. the changelog thing further
19:58:11 <ema> just FTR last week we agreed I'd send an email to the submitter of #1021245 to figure out their RT use cases. I did, no answer yet
19:58:30 <bwh> ema: Thank you
19:58:41 <carnil> ema: thanks
19:58:56 <ema> np!
19:58:59 * hrw off
19:59:00 <carnil> as for any contributing to the team bringing stuff forward!
19:59:08 <carnil> #endmeeting