19:01:15 #startmeeting 19:01:15 Meeting started Wed Jul 3 19:01:15 2024 UTC. The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:36 welcome for today's kernel-team meeting 19:01:46 #chair waldi bwh carnil 19:01:46 Current chairs: bwh carnil waldi 19:02:29 Hi 19:02:32 we were in similar situation as last week with almost empty agenda, so I short-minute added some items we might look at, but can skim over it as needed and time permits 19:03:09 I propose to look at the items listed in https://salsa.debian.org/kernel-team/meetings/-/wikis/20240703 19:03:45 hi 19:03:46 #topic Userspace use of linux-headers-* for bpftool export header 19:04:15 main question: has someone of the involved people had time too look in meanwhile at the issue or should we skip it? 19:04:29 and should we call for help to bluca to recieve input? 19:04:42 you rang? 19:05:22 19:06:12 bluca: yes we had not a conclusion last week on the mentioned issue from https://lists.debian.org/debian-kernel/2024/06/msg00228.html and maybe you can give us here an overview on the problem 19:06:59 sure 19:07:29 so the issue is that installing linux-headers-generic is a kitchen sink - it pulls in the image, builds an initrd, firmware etc 19:07:53 so much that it's noticeable when building build test envs 19:08:02 I understand the issue it solves 19:08:15 as explained by waldi in #1064976 19:08:34 what I was wondering is if there was any other way to solve that issue, that doesn't involve a dep 19:08:54 you loose the build-dependency 19:09:11 and then I can't build BPF CO-RE programs anymore 19:09:26 for background, the generated header is needed to build pre-compiled BPF CO-RE programs 19:09:41 So can we add a linux-bpf-dev package that just has vmlinux.h? 19:09:45 for reference in the discussion: the generated header is the vmlinux.h file right? 19:09:49 right 19:09:50 yes 19:09:58 and yes, another package would be just fine by me 19:10:20 the only other way to get that header or equivalent is from a running kernel, from sysfs 19:10:37 getting that from a buildd is not a good solution and I think it's obvious why 19:10:48 they might be running oldstable or oldoldoldoldstable and so on 19:11:11 Indeed 19:11:43 so if it's another package, and I have a way from the version or name or so to get the right directory, I am fine with that 19:11:47 and of the wrong architecture 19:11:52 also that 19:12:09 don't worry about breaking compat with location etc, I don't mind changing things 19:12:27 OK, so who wants to make that packaging change? 19:12:45 the only thing I need for src:systemd builds is basically a way to figure out the location that corresponds to the package pulled in, if the directory is versioned 19:13:12 i did not manage to do the last one i wanted to do, so no idea if i manage to find time 19:13:23 thisis how I do it right now: https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules?ref_type=heads#L211 19:13:32 again I don't mind changing that logic 19:13:44 so if you give me some guidance, I can send a MR 19:13:49 that was my next question if we have to worry about its exposed "API". 19:14:01 do we need to version it? otherwise just put it in /usr/include/$multiarch/linux/$something? 19:14:04 it's only in unstable/testing, so I don't think so 19:14:25 waldi: As this is for user-space, I think we shouldn't version it 19:15:00 so arch: any linux-bpf-dev package that installs /usr/include/$multiarch/linux/vmlinux.h ? 19:15:18 something like that, yes 19:15:44 ok, if that works for you all, I can send a MR that implements it 19:15:48 should we formulate it as action to make a poc for that split out packaging as merge request? (who?) 19:15:56 ok that answers my question 19:16:56 #agreed split out installing vmlinux.h header into a separate linux-bpf-dev package to address the problems from https://lists.debian.org/debian-kernel/2024/06/msg00228.html and #1064976 19:17:38 #action bluca will create a MR implementing the discussed approach to split out the header into a new binary package linux-bpf-dev for review 19:17:53 bluca: I hope you are okay with the above wording 19:18:10 any other input on that topic? 19:18:19 not from m 19:18:31 no 19:18:42 ok the next three are just giving some summary about RC severity bugs 19:19:05 #linux: ext4 corruption with symlinks (#1039883) 19:19:09 sorry 19:19:12 thanks 19:19:13 #topic linux: ext4 corruption with symlinks (#1039883) 19:19:51 I have re-read the bug today and my understanding is that Luis Henriques has a fix, confirmed by bwh but I have still not found it submitted/applied to mainline 19:20:21 It was submitted but not yet applied, and I would not want to apply a filesystem patch in that state 19:21:16 right, as long it does not land in (at least mainline, better if it get queued as well for stable series), then we should not apply it. 19:21:31 So, I think there's nothing we can do other than maybe prod the ext4 maintainers 19:21:41 my question was more focusing on if the submission felt trough the cracks and we can re-ping the thead or should simply wait longer 19:21:58 I can do that unless you are saying we are not waiting too long yet 19:22:24 (or any other person can prod, but want to take that as action so that we might get to a state to include the fix) 19:22:40 It's been 2 weeks 19:22:59 #action bwh to follow up patch for #1039883 upstream 19:23:38 thanks 19:24:13 #topic fat-modules: SD corruption upon opening file on Linux desktop (#1063754) 19:25:33 For this one I propose to close the bug as we cannot take any further action. The reporter has not followed up on the question from bwh trying to get the reporter to carry some specfic tests 19:27:16 I'm somewhat hesistant to do that because there may be a Linux bug here, but it's hard to see what the reporter's experiments actually tell us 19:28:23 an alternative proposal would be to ask the reporter once more to carry out the specific testing 19:28:31 I've seen something similar several times over the years; usually its the SD being removed before a sync 19:29:35 iam_tj[m]1: Huh, you could be right 19:30:02 So many people think they can just unplug immediately the copy operation/whatever is done 19:31:09 I think the reporter is knowledgeable enough not do that but it is a possibility 19:31:42 I'd like someone else to have another look through the bug log to see if they can make some sense, before taking any action 19:33:08 Anyone? 19:34:25 I can look through the bug the next days 19:34:34 (unless iam_tj[m]1 feels in the mood) 19:35:02 I guess not :) 19:35:38 it reads to me as if udisks is automounting but the device isn't being "safely unmounted" or ejected (I've already read through quite carefully) 19:35:59 leave it open; ask for more detailed info on the "physical" procedure 🙂 19:36:02 but on FAT, you don't get suddenly broken files 19:36:08 #action carnil will have another look through the bug log of #1063754, doublechecking with reporte that the reporte is not taking any action before/card removal before a sync happening 19:36:54 so we have 10min left 19:37:02 waldi: it is possible; I've seen it happen in that exact scenario (thumbnail generation trying to write onto a slow device whilst larger files are being copied off it at the same time) 19:37:37 iam_tj[m]1: you seem to me to be an optimal candidate to ask some questions back to the reporter 19:38:24 #topic linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive (#1057282) 19:38:47 simple proposed action: ping elbrus, he might have not seen bwh reply in message 47 19:38:59 right 19:39:40 #action ping Paul Gevers on the the question to perform again testing with recent unstable or backports kernel 19:40:20 Action for who? 19:40:23 I will do that so it's not all on your shoulders 19:40:25 OK 19:40:30 #action carnil will ping Paul Gevers on the the question to perform again testing with recent unstable or backports kernel 19:40:59 #topic linux: D-I's X fails to start under kvm -vga qxl (#1075713) 19:41:20 this is a new bug/issue 19:41:31 I can have a look into it 19:42:40 great thanks. I'm planning to import 6.9.8 after tomorrow's release but I have not checked in the queued commits if there might be something related which might help 19:42:45 #action bwh to investigate #1075713 19:42:47 but let's document that action 19:43:13 #topic Packaging: rebase master branch for 6.10-rcX 19:43:49 since 6.9.7 is now uploaded to unstable we could import 6.10-rcX for preparing it to experimental. 19:44:34 I will barely have time to do that (since doing mainly the stable imports), but just mentioning it here in case someone is in the mood and wants to pick it up 19:45:12 I may try it if I have the time and energy at the weekend 19:45:19 no promises though 19:45:51 we would have happy users, but one aspect we missed in some last round is if there are new features etc ... to be enabled. I'm not too close following upstream development to judge on that. Maybe those steps should be seprated. 19:45:55 bwh: I can do the leg-work on 1075713 if you like 19:46:27 iam_tj[m]1: OK, happy to hand that off :-) 19:46:46 it looks pretty straightforward 🙂 19:47:31 bwh: thanks, do not ake too much on your shoulders, let's not take it as action but just in case you will have time and energy to take it :) 19:47:39 so we are at the end of our 45min slot 19:47:45 any last words/comments? 19:47:55 not from me 19:48:16 Just a note: the binutils issue upstream has been identified (DT_RELR) and being worked on 19:48:21 otherwise we can close the meeting, next meeting in my undersanding would be again in jitsi and needs a chair :) 19:48:23 it's a binutils issue 19:48:47 I think it's my turn 19:49:00 iam_tj[m]1: correct, I think we mentioned it earlier this week on IRC, but it's good to have it in the node. Should have possibly a own topic item. 19:49:07 * ukleinek offers the three chairs in the dining room (and a bank!) 19:49:35 thanks bwh 19:49:53 (for taking the next one) 19:50:06 so let's close the meeting for today, thanks all for partecipating 19:50:16 ukleinek: fwiw, would be nice if you can join the next one :) 19:50:27 Thanks carnil 19:50:37 #endmeeting