19:00:16 <ukleinek> #startmeeting
19:00:16 <MeetBot> Meeting started Wed Apr  2 19:00:16 2025 UTC.  The chair is ukleinek. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:16 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:30 <ukleinek> #chair bwh carnil waldi
19:00:30 <MeetBot> Current chairs: bwh carnil ukleinek waldi
19:00:46 <waldi> hi
19:01:01 <carnil> hi
19:01:30 <ukleinek> #topic Linux MR #1359 https://salsa.debian.org/kernel-team/linux/-/merge_requests/1359 bpf header location
19:02:03 <ukleinek> From my side this can still be merged
19:02:35 <ukleinek> I didn't understand why waldi closed the MR and if there is a better reason than bluca's DAM warning.
19:03:33 <waldi> we decided on an interface before. now it wants to be changed unilateral
19:04:30 <waldi> an interace that reduces the possibility of conflicts with future linux headers
19:05:18 <ukleinek> waldi: and that would be /usr/include/$triplet/linux/bpf/vmlinux.h ?
19:05:41 <waldi> <linux/bpf/vmlinux.h>
19:05:47 <bwh> Hi, sorry I'm late
19:06:09 <ukleinek> bwh: hi, sorry we didn't wait for you :-) Welcome
19:06:18 <bwh> I think the MR should be merged
19:07:36 <bwh> waldi: On the MR you seemed to object to putting BPF headers under /usr/include/$triplet/linux entirely. Has that changed?
19:08:40 <waldi> bwh: i object on putting it directly into an existing directory in the include path. that's why we ended up with <linux/bpf/vmlinux.h>, this directory is unused by linux
19:10:07 <bwh> So your concern is we might later have a /usr/include/linux/vmlinux.h that is UAPI and would conflcit with this?
19:10:14 <waldi> yes
19:10:27 <bwh> OK, then please say so on the MR
19:10:37 <ukleinek> he did
19:11:30 <bwh> I can't see that
19:12:32 <carnil> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1359#note_581905 but it's not explicitly worded as above I think
19:13:58 <waldi> better? https://salsa.debian.org/kernel-team/linux/-/merge_requests/1359#note_601242
19:14:20 <bwh> Thank you
19:14:41 <KGB> 03linux 05debian/latest 06Ben Hutchings * [unapproved] merge request !1359: linux-bpf-dev: install header to linux/ subdirectory * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1359
19:15:52 <ukleinek> better, IMHO the argument is weak because vmlinux.h is in the same way in the linux UAPI namespace as bpf/vmlinux.h. But I agree that in the bpf directory the probability for a conflict is smaller.
19:16:27 <bwh> yes
19:16:37 <carnil> so in summary we are doing ok already and maybe ubuntu can be approached to hilight the problem on their header location so they might think of a Ubuntu side transition (well possibly unlikely as it is settled in a release)
19:16:44 <ukleinek> So having the choice between <linux/bpf/vmlinux.h> and <linux/vmlinux.h>, I'd prefer the former, but something completely different would still be better.
19:17:17 <bwh> carnil: We could suggest to Ubuntu to move it and leave a compatibility wrapper at <linux/vmlinux.h> temporarily
19:17:33 <ukleinek> compat wrapper or symlink
19:17:44 <bwh> I don't know who would be a good contact on that side...
19:17:59 <ukleinek> bluca should know?
19:18:01 <waldi> ubuntu-kernel@lists.ubuntu.com
19:18:03 <waldi> i think
19:18:21 <waldi> err, kernel-team@lists.ubuntu.com
19:20:22 <carnil> https://wiki.ubuntu.com/KernelTeam
19:20:29 <ukleinek> Who would reach out to them? One of us, or is that something we let bluca act on as he and/or the systemd team has the interest here?
19:21:18 <bwh> I don't expect he'll want to do that
19:21:29 <bwh> I can take an action to do it
19:21:40 <ukleinek> that's nice
19:21:58 <bwh> #action bwh will contact the Ubuntu kernel team about aligning installation of vmlinux.h
19:22:05 <waldi> bwh: thank you. otherwise i can do that as well
19:22:16 <ukleinek> One thing I still want to say on that topic is, that I found https://salsa.debian.org/kernel-team/linux/-/merge_requests/1359#note_601049 inappropriate
19:22:16 <waldi> sorry for opening such a mess
19:22:47 <bwh> ukleinek: I have to agree
19:23:24 <waldi> okay. i'll try to do better
19:23:32 <bwh> Thank you
19:23:37 <carnil> thank you
19:23:42 <ukleinek> Ah, and BTW, I privmsg with Luca and mentioned there that I felt his ping was received by me as a try to sidestep waldi's concerns.
19:23:52 <carnil> and I undestood things were already escalated
19:24:14 <carnil> at that point
19:24:23 <ukleinek> then let's continue to the bug list?
19:24:27 <carnil> ukleinek: yes the pings on various times in the MR felt that way
19:24:28 <bwh> Yes please
19:24:30 <carnil> ukleinek: yes please
19:24:49 <ukleinek> #topic #1086175
19:25:17 <ukleinek> Nothing really new here, just another guy who reported to also have this problem.
19:26:08 <ukleinek> That bug has a history, I wanted to reproduce and when I failed (due to not finding the time) carnil intended to take over.
19:26:09 <bwh> I think we believe this to be reproducible, but no-one has had time to track it down yet, right?
19:26:14 <carnil> at some point I though I could reproduce the issue, but I could not assert to be correct. I can tentatively try to reboostrap that triage
19:26:50 <waldi> don't we have more related bug reports and even hetzner showing up?
19:26:51 <carnil> so if nobody feels to want to look at the issue I take action to try to reliably reproduce it in a VM setup
19:26:57 <carnil> yes
19:27:08 <carnil> that is the merged bug
19:27:08 <waldi> ah, #1089158 is from hetzner
19:27:59 <ukleinek> would be good to resolve that
19:28:49 <iam_tj[m]> This is an area I specialise in so if you'd like me to reproduce/diagnose I can, take some load off you guys
19:28:49 <bwh> The latest message links to an upstream thread with some fixes discussed
19:28:50 <carnil> if nobody objects, assign it as action to me to try to get a proper reproducing scenario
19:28:59 <carnil> or that :)
19:29:16 <bwh> iam_tj[m]: That would be very helpful, thank you
19:29:27 <iam_tj[m]> OK, I'll do that
19:29:39 <ukleinek> iam_tj[m]: do you coordinate with carnil?
19:29:57 <ukleinek> ah, or just do it and no action for carnil
19:30:09 <iam_tj[m]> I can; i generally post a lot of my progress into bug reports to capture state/progress too
19:30:09 <carnil> right I'm fine with that
19:30:19 <ukleinek> #action iam_tj[m] to look into #1086175
19:30:24 <ukleinek> iam_tj[m]: thanks!
19:30:32 <ukleinek> #topic #1088522
19:30:39 <carnil> my interst is to see that it lands ultimately in 6.1.y upstream so we get the fix into bookworm
19:30:49 <ukleinek> ack
19:31:04 <carnil> we got bootlogs from the reporter with 2 and 3 screens attache
19:31:12 <ukleinek> in #1088522 the reporter provided bootlogs, so this is actionable on our side again
19:31:28 <carnil> the action was assigned to me but since the reply from yestrday providing those I was not yet able to look at those
19:31:46 <carnil> (as an excuse they just arrived yesterday)
19:31:49 <ukleinek> IMHO that's completely fine and there is no need for an excuse
19:32:02 <iam_tj[m]> I could look at this one too - I have a system with an nvidia NVS420 with 4 monitors
19:33:22 <ukleinek> carnil, iam_tj[m]: Do you coordinate such that there is no doubled effort?
19:33:59 <iam_tj[m]> Sure - I'll catch up with the bug and then make sure I can reproduce
19:34:09 <carnil> same as above, if iam_tj[m] has a similar hw setup it is even more approriate if he can give input and look, I'm sure we won't waste time as discussion will happen on the bugreport
19:34:31 * iam_tj[m] nods
19:34:41 <ukleinek> #action iam_tj[m] to also look into #1088522
19:34:57 <ukleinek> iam_tj[m]: thanks++
19:35:07 <ukleinek> #topic #1100928
19:35:29 <ukleinek> IMHO there is nothing to do for us. There was a patch provided by upstream
19:35:48 <carnil> convinced the reporter to not give up, provided alsa logs, upstream proposed a patch + similar effect parameter, and waiting for reporter to ack the fix
19:36:07 <ukleinek> Earlier today it wasn't applied in next, but I guess they are waiting for an ack ... exactly what carnil said
19:36:44 <ukleinek> maybe ping in a week or so if the reporter doesn't continue
19:36:52 <carnil> ack
19:36:54 <ukleinek> #topic #1101203
19:37:31 <ukleinek> This turned out to be the same problem as #1094767
19:37:43 <bwh> So we seem to have an answer: AMD proprietary stuff doesn't uninstall properly
19:38:08 <ukleinek> Is it worth to tell them?
19:38:24 <bwh> We could try
19:39:04 <ukleinek> Who is the right addressee? Maybe the amd upstream guys could know?
19:39:55 <bwh> I don't know. It will take some time to actually look through their packages to see what's broken
19:40:15 <ukleinek> Is my theory that adding the blacklist entry only takes effect after a regeneration of the initramfs?
19:40:36 <ukleinek> s/?/ right?
19:40:52 <bwh> Yes because plytmouth is installed by default on desktops, so the amdgpu driver gets loaded in the initramfs
19:41:03 * ukleinek nods
19:41:13 <bwh> and the modprobe config change has no effect until the initramfs is regenerated
19:41:14 <waldi> hmpf. i wanted to add modprobe.d via bug scripts to directly see such problems
19:41:39 <ukleinek> waldi: would still be welcome!
19:41:46 <waldi> yeah, i just forgot
19:41:58 <bwh> I think that would be sensible
19:42:03 <ukleinek> Given we had 3 (or 4?) people affected by that, I bet these won't be the last.
19:42:20 <waldi> #action waldi to try (again) to add {/etc|/run|/usr/lib}/modprobe.d via bug scripts
19:42:44 <bwh> #action bwh will investigate AMD proprietary graphics drivers leaving amdgpu blacklisted after uninstallation
19:43:39 <ukleinek> bwh: thanks. There is #nouveau which might be a nice first contact while searching for the right address to report the issue.
19:44:25 <ukleinek> #topic #1101207
19:45:04 <ukleinek> I shortly wondered if this is another instance of a blacklisted amdgpu module, but the symptoms are different
19:45:41 <ukleinek> Anyhow, we asked for logs and it's up to the reporter to reply, so no action item on our side
19:46:01 <waldi> i see a log
19:46:23 <iam_tj[m]> "failed to load ucode" suggests a system problem
19:46:58 <carnil> yep got provided today
19:47:15 <bwh> iam_tj[m]: We discussed this last week. This error message is for failure to load microcode from system RAM into the GPU, not failure to load from disk into RAM
19:47:42 <carnil> Quoting last message from today: So far, I'm unable to reproduce this problem!.
19:47:49 <carnil> :-/
19:48:07 <bwh> So let's mark it unreproducible for now, and if it doesn't return we can close it eventually
19:48:19 <ukleinek> ack
19:48:25 <iam_tj[m]> I understand that - it looks like a GPU issue. My first step would be to unplug and reconnect the GPU adapter!
19:48:58 <ukleinek> iam_tj[m]: it seems a proper power cycling was enough
19:49:22 <ukleinek> #topic #1100153
19:50:08 * ukleinek double checks if "waiting for reporter" is still accurate
19:50:10 <carnil> that is an intersting one :(. But I think we need brian to further try what ukleinek has suggested
19:50:20 <carnil> yes I think so
19:50:29 * ukleinek nods, so no action for us
19:50:41 <ukleinek> #topic #1101754
19:51:09 <ukleinek> another one where we're waiting for reporter feedback.
19:51:38 <ukleinek> #topic #1100105
19:52:05 <ukleinek> Does someone know if the Ubuntu kernel package is just installable on a Debian system?
19:53:25 <waldi> should be. i would not try it inside a system i want to keep, but AFAIK they use the same initramfs api
19:54:08 <ukleinek> So it's at least worth a try.
19:54:36 <ukleinek> #ukleinek to suggest to try installing an Ubuntu kernel
19:54:41 <ukleinek> #action ukleinek to suggest to try installing an Ubuntu kernel
19:54:57 <ukleinek> #topic #1101733
19:55:18 <waldi> we talked about that and someone wanted to abstract that away via a script in linux-base
19:55:18 <bwh> ukleinek: Can you actually test that it mostly works in a VM first?
19:55:26 <bwh> waldi: yes
19:55:31 <ukleinek> bwh: yupp
19:55:53 <waldi> secure boot will not work
19:56:05 <bwh> indeed
19:56:47 <bwh> So for the hooks, yes I do want to implement this in linux-base and linux in trixie, so other packages can rely on this in forky
19:57:13 <bwh> I did forget about it so I haven't started work on it yet
19:58:05 <ukleinek> bwh: so it's you who will do it and you need an occasional reminder?
19:58:14 <bwh> something like that :-)
19:58:32 <carnil> we need a new section in our meeting template ;-)
19:58:48 <waldi> better issue handling…
19:59:15 <bwh> #action bwh will implement support for hooks in /usr in src:linux-base and src:linux
19:59:27 * ukleinek already thought in the past that some forwarding from the last week would be useful
19:59:33 <ukleinek> bwh: thanks
19:59:42 <waldi> bwh: thx
19:59:49 <ukleinek> #topic #1072495
20:00:00 <bwh> Already closed
20:00:03 <carnil> yes it was just a joke. But honestly, his is as well why I tried to close that many old bugs to get again a bug list which is actionable on regularly. It is still too much but having a couple of houndreds bugs does not help to keep an overview
20:00:12 <carnil> (anyway offtopic, sorry)
20:00:40 <ukleinek> carnil: nope, not off-topic.
20:00:50 <ukleinek> #topic #1101670
20:00:59 <carnil> REgarding #1072495, yes the closure was done by me. The reporter claimed the issue is fixed in the given version, so just made sure the BTS tracks it as closed
20:01:32 <ukleinek> IMHO #1101670 isn't actinoable, at least I don't understand it like this.
20:01:57 <waldi> it might even be an invalid email adress
20:02:30 <bwh> It sounds very fake to me
20:02:31 <waldi> yes, it is. so just close it
20:02:36 <waldi> noemail.com
20:02:37 <waldi> is a disposable email domain
20:03:06 <ukleinek> ack, who does it?
20:03:18 <waldi> i do it
20:03:27 <bwh> I understand "Pre-boot DMA protection" to mean that the system firmware enables the IOMMU
20:03:43 <ukleinek> waldi: great, thanks
20:04:06 <ukleinek> bwh: sounds reasonable, but includes more guesswork than should be necessary for a bug report
20:04:10 <carnil> the item "Pre-boot DMA protection" is shown if you run fwupdmgr security
20:04:10 <bwh> That by definition is outside the control of the kernel but it might be that the kernel is reporting the status differently
20:04:15 <bwh> ukleinek: I agree
20:05:24 <ukleinek> So we go on and waldi closes, ideally with a nice message about the possibility to reopen with more details.
20:05:32 <ukleinek> #topic #1101370
20:06:12 <ukleinek> another "Whole bugreport is in the subject" bug
20:06:13 <waldi> ukleinek: we are slightly out of time
20:06:21 <ukleinek> oh, indeed
20:06:52 * ukleinek was surprised that the bug script emitted a bunch of iproute2 bugs
20:07:02 <ukleinek> #topic other stuff
20:07:35 <bwh> ukleinek: I triaged some older iproute2 bugs
20:07:55 <ukleinek> bwh: ah, that explains it, thanks
20:08:05 <ukleinek> (for the hint and the triaging)
20:08:43 <ukleinek> Who chairs next time? Something else to discuss?
20:09:36 <carnil> I'm not sure is it again my turn?
20:09:45 <waldi> nothing from me. it would be carnil's turn i think
20:09:46 * ukleinek would have guessed bwh
20:10:06 <ukleinek> ah no, he did last week
20:10:11 <carnil> I will do
20:10:20 * ukleinek nods
20:10:25 <ukleinek> #endmeeting