19:06:18 #startmeeting 19:06:18 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:06:34 #chair waldi bwh 19:06:34 Current chairs: bwh carnil waldi 19:07:07 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 sounds good 19:07:31 as salsa is flaky right now I take what I have from the git clone bit earlier today 19:08:18 #topic trixie freeze approaching, fixing on kernel version: features to enable, concerns? 19:08:42 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 Two items came to my mind while thinking about it: 19:09:39 - 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 What I've done previously is to go through the symbols listed by 'make listnewconfig' as we approach the freeze 19:10:16 (only on amd64; I leave other architecture-specific symbols to their respective porters) 19:10:36 I can try to do that at some point but I can be a big task 19:10:44 it can be a big task 19:11:01 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 I can go through make listnewconfig for arm64 19:11:29 bwh: I'm willing to help in this task to share workload 19:12:02 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 or just split it in 2 to start with 19:12:39 I don't know when I will have time to do that though 19:12:48 sound good, and ema looks at arm64 specific ones? 19:13:01 yup 19:13:15 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 #action bwh will look through symbols listed by listnewconfig before freeze 19:13:54 #action carnil will look through symbols listed by listnewconfig before freeze 19:13:54 #action bwh, ema and carnil work through symbols listed by 'make listnewconfig' to check what is sensible to be enabled 19:14:02 sorry 19:14:06 ah no problem :) 19:14:49 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 We should drop i386 due to limited upstream support 19:15:56 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 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 do you think we should raise that first informal in private with the release team? 19:16:44 ukleinek: no jitsi, we're on irc due to salsa issues 19:16:57 ukleinek: it's continuing in IRC as jitsi is not working reliably 19:17:08 carnil: \o/ 19:17:13 * ukleinek reads backlog 19:17:28 I would also like to cut down the mips64el flavours but would need to check which of them are broken 19:18:10 carnil: This was discussed last year in Cambridge 19:18:43 Still it needs to be announced a little before we do it 19:19:30 I think it would be important to do that step then really soon now, correct? 19:19:36 yes 19:20:07 Anyone willing to take the lead and stand on "front"? 19:20:17 Sure, I can do that 19:20:30 I'm glad you have the courage :) 19:20:37 I will formulate two actions: 19:22:06 #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 #action bwh checks which mips64el flavours could be cut down 19:22:38 ^^ bwh hope that matches well 19:22:44 OK 19:22:59 if you will need help and support from others please *do* cry 19:23:19 next topic from the free form list? or has anyone something to add to this? 19:23:32 does that mean the i386 architecture will die? 19:23:58 (in the sense that it will not be a release arch for Debian 13?) 19:24:01 no 19:24:02 No the plan was to keep supporting it as a secondary architecture 19:24:10 * ukleinek nods 19:24:11 Fedora does not provide kernel/installer for i386. several packages (mostly libraries) are kept for 32bit compats 19:25:12 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 carnil: I think we can move on now... 19:25:55 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 I propose to move to the next topic 19:26:01 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 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 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 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 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 #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 bwh: thanks for merging 19:26:41 wontfix, python3 is already in Recommends not Depends 19:27:03 We got a request both here on IRC (gioele), and through #1013868 to make the scripts in a separate binary package 19:27:47 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 but I would be fine to just go ahead as you propose and mark it as wontfix with the rationale 19:28:11 Oh, sorry no it's in Depends on nfs-common 19:28:36 but Recommends in nfs-kernel-server (but that Depends on nfs-common so...) 19:28:56 There is a MR for it (claimed in the bug report) 19:29:01 mountstats is there in nfs-common which is python3 19:29:22 (and nfsiostat) 19:29:51 Let's move python3 to Recommends then 19:30:02 in nfs-common as well 19:30:40 us == ?? 19:31:05 bwh: so baseline would be: we try to avoid a separate package for the scripts 19:31:30 Yes it doesn't seem worth adding another package for 2 scripts 19:32:36 carnil: But as you have been doing most of the work on nfs-utils, please feel free to overrule my opinion :-) 19:33:34 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 OK 19:34:20 #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 time is running fast :( 19:34:48 #topic Next uploads of 6.10.y to unstable 19:35:10 First we have FTBFS, but this should be handled soon with the MR worked on 19:35:24 Yes the fixes are all available and just need to be merged 19:35:51 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 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 [riscv64] udeb: Ship mtd in kernel-image, drop mtd-core-modules and add it to to Provides of kernel-image. 19:35:57 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 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 #info Coordinate with kibi and Sledge for unstable uploads for src:linux for helping d-i uploads 19:36:32 What exactly is the concern here? 19:36:38 SB = secure boot? 19:36:46 yep 19:37:00 bwh: no concerns here, just informational that whoever works on unstable upload should coordinate with kibi and Sledge 19:37:09 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 So you need to get debian-installer to migrate along with linux, or? 19:37:51 so we'll to check everything else works, basically 19:38:11 there was some concern about older kernel versions and some arches 19:38:14 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 Oh, so there is currently nothing newer than stable 19:38:52 normally we're not too bothered as we don't try to do d-i releases until close(r) to freeze 19:39:06 but this is a little out of the normal cycle, basically 19:39:56 OK 19:40:51 hopefully no issues that will impinge on the kernel team 19:40:57 hrw: I can look into !1187, is !1186 the issue mentioned earlier with kernel-wedge? 19:41:15 ah, 1186 is alread merged 19:41:18 OK, so I guess all are aware now and move to next two topics, and then close the meeting 19:41:29 right 19:41:30 #topic Discuss the arm64 64k page size merge request with additional data input 19:41:31 ukleinek: thx 19:41:38 this is more on ema and waldi I believe :) 19:42:01 64k pagesize kernel is handy on bigger systems 19:42:04 right, I was asked to provide performance data about 64k page size on arm64 kernels 19:42:06 Context: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1169 19:42:22 I provided the data so now the question is whether we can go ahead with the MR :) 19:44:32 waldi: ping 19:45:11 the concerns in 20240821 were about long build times IIRC 19:45:26 i have no additional input over that 19:45:42 So let's drop the 16k flavour in favour of 64k 19:45:59 macbooks need 16k one 19:46:09 and they need drivers that don't exist upstream 19:46:15 yeah but the debian kernel doesn't run on macbooks 19:46:20 ok 19:46:44 so we ship neither 19:46:51 not 16k, nor 64k 19:47:21 is 64k pages a pure performance thing? There are no machines that require it, right? 19:47:22 I have 2 cents on i915 - is this a good time to share? 19:47:22 well, 64k has real world users benefiting from it 19:47:30 llenn: no 19:47:43 which is why all major distros ship a arm64 kernel with 64k page size 19:48:34 ..ooOO(That's wrong, Debian doesn't :-) SCNR) 19:49:04 I don't think we're going to come to a decision in this meeting 19:49:18 So longer build times are a concern, but we have two fronts, not to be resolved in next 10min 19:49:22 +1 for dropping 16k and adding 64k 19:49:48 (just my opinion, not trying to force a decision) 19:49:59 I do not have a way out of the cycle 19:50:03 I'm not sure I understand the concern frankly 19:50:31 +2 for discussing that not in the context of this meeting 19:50:53 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 #topic tech-ctte bug #1065416: Asking for input from kernel-team 19:51:44 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 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 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 I missed all the early discussion, have tried to catch up, and not yet finished 19:53:00 I can take an action to respond 19:53:10 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 ok then I make this as action 19:54:00 #action bwh goes through the discussion of #1065416 and will respond to the questions from tech-ctte 19:54:19 we are out if time 19:54:23 #topic AOB? 19:54:44 we did not look at current other issues, but I think this is fine this round 19:55:23 I was going to ask is debian/changelog needed per commit or per MR 19:55:34 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 I still have the todos from some weeks ago on my agenda and intend to tackle them until next week. 19:56:04 but 1186 had one per MR and bwh took it so I feel that both ways are fine 19:56:08 looks like it is my turn 19:56:11 hrw: So far as I am concerned, it is OK to add it per MR 19:56:30 waldi: then thank you if you take it 19:56:57 bwh: thanks. makes life easier as patches can be reordered etc efore submittion 19:57:19 (And I would really like to move to using gbp dch in future...) 19:57:49 does not support merge requests at all 19:58:06 I guess we can close now the meetng and discuss e.g. the changelog thing further 19:58:11 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 ema: Thank you 19:58:41 ema: thanks 19:58:56 np! 19:58:59 * hrw off 19:59:00 as for any contributing to the team bringing stuff forward! 19:59:08 #endmeeting