19:01:15 <carnil> #startmeeting
19:01:15 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:36 <carnil> welcome for today's kernel-team meeting
19:01:46 <carnil> #chair waldi bwh carnil
19:01:46 <MeetBot> Current chairs: bwh carnil waldi
19:02:29 <bwh> Hi
19:02:32 <carnil> 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 <carnil> I propose to look at the items listed in https://salsa.debian.org/kernel-team/meetings/-/wikis/20240703
19:03:45 <waldi> hi
19:03:46 <carnil> #topic Userspace use of linux-headers-* for bpftool export header
19:04:15 <carnil> 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 <carnil> and should we call for help to bluca to recieve input?
19:04:42 <bluca> you rang?
19:05:22 <bluca> </lurch>
19:06:12 <carnil> 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 <bluca> sure
19:07:29 <bluca> 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 <bluca> so much that it's noticeable when building build test envs
19:08:02 <bluca> I understand the issue it solves
19:08:15 <bluca> as explained by waldi in #1064976
19:08:34 <bluca> what I was wondering is if there was any other way to solve that issue, that doesn't involve a dep
19:08:54 <waldi> you loose the build-dependency
19:09:11 <bluca> and then I can't build BPF CO-RE programs anymore
19:09:26 <bluca> for background, the generated header is needed to build pre-compiled BPF CO-RE programs
19:09:41 <bwh> So can we add a linux-bpf-dev package that just has vmlinux.h?
19:09:45 <carnil> for reference in the discussion: the generated header is the vmlinux.h file right?
19:09:49 <carnil> right
19:09:50 <bluca> yes
19:09:58 <bluca> and yes, another package would be just fine by me
19:10:20 <bluca> the only other way to get that header or equivalent is from a running kernel, from sysfs
19:10:37 <bluca> getting that from a buildd is not a good solution and I think it's obvious why
19:10:48 <bluca> they might be running oldstable or oldoldoldoldstable and so on
19:11:11 <bwh> Indeed
19:11:43 <bluca> 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 <waldi> and of the wrong architecture
19:11:52 <bluca> also that
19:12:09 <bluca> don't worry about breaking compat with location etc, I don't mind changing things
19:12:27 <bwh> OK, so who wants to make that packaging change?
19:12:45 <bluca> 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 <waldi> 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 <bluca> 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 <bluca> again I don't mind changing that logic
19:13:44 <bluca> so if you give me some guidance, I can send a MR
19:13:49 <carnil> that was my next question if we have to worry about its exposed "API".
19:14:01 <waldi> do we need to version it? otherwise just put it in /usr/include/$multiarch/linux/$something?
19:14:04 <bluca> it's only in unstable/testing, so I don't think so
19:14:25 <bwh> waldi: As this is for user-space, I think we shouldn't version it
19:15:00 <bluca> so arch: any linux-bpf-dev package that installs /usr/include/$multiarch/linux/vmlinux.h ?
19:15:18 <waldi> something like that, yes
19:15:44 <bluca> ok, if that works for you all, I can send a MR that implements it
19:15:48 <carnil> should we formulate it as action to make a poc for that split out packaging as merge request? (who?)
19:15:56 <carnil> ok that answers my question
19:16:56 <carnil> #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 <carnil> #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 <carnil> bluca: I hope you are okay with the above wording
19:18:10 <carnil> any other input on that topic?
19:18:19 <waldi> not from m
19:18:31 <bwh> no
19:18:42 <carnil> ok the next three are just giving some summary about RC severity bugs
19:19:05 <carnil> #linux: ext4 corruption with symlinks (#1039883)
19:19:09 <carnil> sorry
19:19:12 <bluca> thanks
19:19:13 <carnil> #topic linux: ext4 corruption with symlinks (#1039883)
19:19:51 <carnil> 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 <bwh> It was submitted but not yet applied, and I would not want to apply a filesystem patch in that state
19:21:16 <carnil> 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 <bwh> So, I think there's nothing we can do other than maybe prod the ext4 maintainers
19:21:41 <carnil> 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 <carnil> I can do that unless you are saying we are not waiting too long yet
19:22:24 <carnil> (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 <bwh> It's been 2 weeks
19:22:59 <bwh> #action bwh to follow up patch for #1039883 upstream
19:23:38 <carnil> thanks
19:24:13 <carnil> #topic fat-modules: SD corruption upon opening file on Linux desktop (#1063754)
19:25:33 <carnil> 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 <bwh> 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 <carnil> an alternative proposal would be to ask the reporter once more to carry out the specific testing
19:28:31 <iam_tj[m]1> I've seen something similar several times over the years; usually its the SD being removed before a sync
19:29:35 <bwh> iam_tj[m]1: Huh, you could be right
19:30:02 <iam_tj[m]1> So many people think they can just unplug immediately the copy operation/whatever is done
19:31:09 <bwh> I think the reporter is knowledgeable enough not do that but it is a possibility
19:31:42 <bwh> 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 <bwh> Anyone?
19:34:25 <carnil> I can look through the bug the next days
19:34:34 <carnil> (unless iam_tj[m]1 feels in the mood)
19:35:02 <carnil> I guess not :)
19:35:38 <iam_tj[m]1> 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 <iam_tj[m]1> leave it open; ask for more detailed info on the "physical" procedure 🙂
19:36:02 <waldi> but on FAT, you don't get suddenly broken files
19:36:08 <carnil> #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 <carnil> so we have 10min left
19:37:02 <iam_tj[m]1> 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 <carnil> iam_tj[m]1: you seem to me to be an optimal candidate to ask some questions back to the reporter
19:38:24 <carnil> #topic linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive (#1057282)
19:38:47 <carnil> simple proposed action: ping elbrus, he might have not seen bwh reply in message 47
19:38:59 <bwh> right
19:39:40 <carnil> #action ping Paul Gevers on the the question to perform again testing with recent unstable or backports kernel
19:40:20 <bwh> Action for who?
19:40:23 <carnil> I will do that so it's not all on your shoulders
19:40:25 <bwh> OK
19:40:30 <carnil> #action carnil will ping Paul Gevers on the the question to perform again testing with recent unstable or backports kernel
19:40:59 <carnil> #topic linux: D-I's X fails to start under kvm -vga qxl (#1075713)
19:41:20 <carnil> this is a new bug/issue
19:41:31 <bwh> I can have a look into it
19:42:40 <carnil> 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 <bwh> #action bwh to investigate #1075713
19:42:47 <carnil> but let's document that action
19:43:13 <carnil> #topic Packaging: rebase master branch for 6.10-rcX
19:43:49 <carnil> since 6.9.7 is now uploaded to unstable we could import 6.10-rcX for preparing it to experimental.
19:44:34 <carnil> 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 <bwh> I may try it if I have the time and energy at the weekend
19:45:19 <bwh> no promises though
19:45:51 <carnil> 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 <iam_tj[m]1> bwh: I can do the leg-work on 1075713 if you like
19:46:27 <bwh> iam_tj[m]1: OK, happy to hand that off :-)
19:46:46 <iam_tj[m]1> it looks pretty straightforward 🙂
19:47:31 <carnil> 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 <carnil> so we are at the end of our 45min slot
19:47:45 <carnil> any last words/comments?
19:47:55 <waldi> not from me
19:48:16 <iam_tj[m]1> Just a note: the binutils issue upstream has been identified (DT_RELR) and being worked on
19:48:21 <carnil> otherwise we can close the meeting, next meeting in my undersanding would be again in jitsi and needs a chair :)
19:48:23 <iam_tj[m]1> it's a binutils issue
19:48:47 <bwh> I think it's my turn
19:49:00 <carnil> 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 <carnil> thanks bwh
19:49:53 <carnil> (for taking the next one)
19:50:06 <carnil> so let's close the meeting for today, thanks all for partecipating
19:50:16 <carnil> ukleinek: fwiw, would be nice if you can join the next one :)
19:50:27 <bwh> Thanks carnil
19:50:37 <carnil> #endmeeting