20:02:11 <bwh> #startmeeting
20:02:11 <MeetBot> Meeting started Wed Dec  3 20:02:11 2025 UTC.  The chair is bwh. Information about MeetBot at https://wiki.debian.org/MeetBot.
20:02:11 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:02:53 <bwh> Does anyone have an urgent topic before we get into the bug list?
20:03:02 * ukleinek doesn't know
20:03:15 * carnil not
20:03:33 <bwh> OK then
20:03:43 <bwh> #topic #1109268: (i, ) ath11k_pci may trigger prompt for nonexistent firmware file during installation
20:04:29 <ukleinek> ah, that is the bug where both me and bwh intended to look into?
20:04:56 <bwh> Yes. There's now a 3rd user who says there's a problem after the firmware load failure, but I suspect that's actually a separate issue
20:05:26 <ukleinek> #action ukleinek asks 3rd reporter in #1109268 if this is really the same problem
20:05:33 <bwh> Thank you!
20:05:41 <bwh> #topic #1114884: (i, M) Console hangs on 6.1.0-39 while 6.1.0-37 works fine
20:06:09 <ukleinek> The reporter doesn't want to invest time and skill to bisect and has a work around, I vote for closing
20:06:20 <bwh> Right, I agree
20:06:44 <ukleinek> #action ukleinek closes #1114884 with an explanation
20:06:51 <carnil> same, ack
20:07:02 <bwh> #topic #1116251: (i, M) linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot
20:07:18 <bwh> I think this is now with bdrung to test?
20:07:22 <carnil> yes
20:07:32 <ukleinek> ack
20:07:39 <bwh> #topic #1121006: (i, u) linux: reported optimal_io_size from mpt3sas devices results in 4GB raid10 optimal_io_size
20:08:05 <bwh> carnil: Did you get any response to this that missed the bug log somehow?
20:08:14 <carnil> bwh: no no response so far
20:08:35 <bwh> OK, so nothing much we can do at the moment
20:08:51 <bwh> #topic #1121227: (i, Mu) linux-image-6.12.48+deb13-amd64: Black screen with Nouveau TRAP_PROP [RT-FAULT] ...
20:08:53 <carnil> right
20:09:38 <ukleinek> No feedback from reporter yet (at least not in the bug report 😄)
20:09:45 <bwh> This is waiting on the reporter to run reportbug properly
20:10:18 <bwh> #topic #1121822: (i, ) linux: ThinkPad T460s: poweroff leaves FnLock active with Intel PTT (Debian 13, 6.12.57-1)
20:10:27 <bwh> Finally, a new bug
20:11:43 <bwh> I would ask "is this a regression", "do you have the latest BIOS", and "what is wrong with using the external TPM"
20:11:45 <ukleinek> unrelated side note: On my new thinkpad the fans occasionally run for a few minutes still when the machine is already in suspend
20:12:09 <waldi> and "full bug info with reportbug"
20:12:35 <ukleinek> sounds like a firmware issue not (or very little) related to the kernel?
20:12:56 <bwh> waldi: Yes though I don't know how much it can tell us about a bug on power off
20:13:04 <bwh> ukleinek: indeed, hence the questions
20:13:30 <bwh> #action bwh will follow up on #1121822
20:13:34 <waldi> bwh: it can tell us much more about the machine. including those bios versions
20:13:40 <bwh> waldi: Ah, yes
20:13:44 <waldi> and efi vs bios
20:15:13 <bwh> #topic #1113996: (n, uM) linux-image-amd64: self-tests for sha256 using sha256-padlock-nano failed
20:15:23 <ukleinek> waiting on upstream
20:15:43 <carnil> upstream (the ones from the specific cpu) do not seem to care :(
20:15:45 <bwh> Nothing really new, reporter is just getting more annoyed at the vendor
20:15:58 <bwh> #topic #1117002: (n, uM) linux-image-6.12.48+deb13-amd64: warning in arch/x86/kernel/cpu/cpuid-deps.c:117 do_clear_cpu_cap on Intel Atom N450
20:17:24 <ukleinek> it seems upstream doesn't want to fix and the reporter is mostly ok with it
20:17:40 <bwh> I feel like this warning ought to be quirked away because it doesn't really matter, but I also can't be bothered to fix it
20:17:56 <carnil> the remark is valid I think. While the warning might be harmless, it taints the kernel and thus might cause valid reports to get ignored/rejected. So maybe Dave Hansen can be convinced to "fix"/workaround the problem for the specific cases
20:18:19 <ukleinek> ah indead, the last sender != reporter
20:18:21 <carnil> we should maybe just wait to see how the upstream thread evolves?
20:18:26 <bwh> At the least it could be changed to a TAINT_FIRMWARE (or whatever that is called)
20:18:36 <bwh> I'm happy to wait a bit longer
20:18:45 <ukleinek> +1
20:19:01 <bwh> #topic #1120058: (n, u) linux-image-6.16.12+deb14+1-amd64: suspend-to-RAM results in hang (AMD Ryzen 5 5625U)
20:19:40 <bwh> There is a bisection result but I don't really see how it would be responsible
20:20:26 <bwh> The reporter did have an idea but I don't know if it is plausible: "I suspect, but haven't verified, that the X server in the container somehow
20:20:26 <bwh> uses the FUSE-emulated filesystem in the container to create a file that is
20:20:26 <bwh> used with mmap (perhaps to create shared pages as frame buffers)."
20:21:53 <carnil> I have not followed up on purpose to the bug yet, to see if someone here has a clue. But should we still start to loop in the people from the identified commit to see if they can make something out of the information provided?
20:22:26 <carnil> the reproducing case is not really "minimimal", so that does not make it easier
20:22:26 <bwh> That's probably worth trying already, yes
20:22:50 <carnil> okay I can continue to take care to interact with the reporter and do that
20:22:57 <ukleinek> \o/
20:23:19 <bwh> Thank you
20:23:31 <ukleinek> there are two patches basing on that commit, which is why it cannot be reverted easily
20:23:42 <ukleinek> s/two/at least two/
20:23:58 <carnil> #action carnil follows up on #1120058 and involves upstream people
20:24:16 <bwh> ukleinek: Do they have a "Fixes:" trailer referring to it?
20:24:48 <ukleinek> no, that's what I checked. it's only "After commit xyz removed that, we can do this"
20:24:53 <bwh> OK
20:24:57 <bwh> #topic #1120831: (n, M) eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot
20:25:37 <bwh> So the last message says "I disabled the module in grub (module_blacklist=nvidia)". But I don't think that's correct syntax...?
20:26:41 <ukleinek> ack, I think it needs module_blacklist=nvidia_modeset,nvidia_drm
20:27:06 <ukleinek> (and a confirmation after having booted using `lsmod | grep nvidia`)
20:28:08 <ukleinek> #action ukleinek follows up on #1120831 pointing out the right module_blacklist syntax
20:28:26 <carnil> ukleinek: thanks
20:28:35 <ukleinek> (unless carnil wants to continue caring)
20:28:35 <bwh> Although - if the other modules depend on "nvidia" then blacklisting just that one might work...?
20:28:47 <carnil> ukleinek: it's fine to do team work :)
20:29:41 <bwh> I'm just looking at the modprobe config for nvidia modules in the initial report, which is strange (but presumably just what the NV installer writes there)
20:29:56 <bwh> Well, I will let ukleinek figure it out
20:30:05 <bwh> #topic #1121032: (n, u+) thunderbolt_net: missing ndo_set_mac_address prevents bonding mode 802.3ad
20:30:06 <carnil> I surely missed to point out to check the loaded modules afterwards, so think we should have reporter really checked that the modules are not loaded anymore explicitly.
20:30:39 <carnil> ongoing upstream development
20:30:41 <bwh> There's some ongoing discussion here but it seems to be moving to a solution
20:31:04 <bwh> So, nothing needed from us right now, I think?
20:31:08 <ukleinek> ack
20:31:10 <carnil> right
20:31:15 <bwh> #topic #1121535: (n, Mu+) linux-image-6.17.8+deb14-amd64: array-index-out-of-bounds trace during boot (...ctamixer.c:347:48)
20:31:30 <bwh> This is waiting on the reporter to test
20:31:44 <carnil> I wonder if it would help if I build a test kernel here as well for the reporter
20:32:03 <carnil> the reporter said to have never compiled a own kernel, so maybe the hint to our docs is not enough
20:32:19 <carnil> but I asked if he needs more help
20:32:32 <carnil> so maybe just wait to see if reporter responds and requests more help
20:32:32 <ukleinek> I think with such an offer you considerably increase the chance to get test results
20:32:35 <waldi> i have problems. now there are two magic constants in this piece of code
20:33:13 <ukleinek> waldi: so you want unsigned char idx[9]? :-D
20:33:46 <ukleinek> I would expect that the final patch looks a bit nicer once it's confirmed to fix the issue
20:33:51 <waldi> yeah
20:34:03 <bwh> carnil: I would suggested not to get sucked into spending too much time on the bug
20:34:23 <bwh> #topic #1121718: (n, M) linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes)
20:35:15 <carnil> I understand bisecting the problem is time intensive here but I have no better idea :(
20:35:18 <bwh> I think we either need to suggest some other way that this might be reproducible, or give up on this bug
20:35:46 <bwh> So if anyone has some ideas for how to exercise a camera driver
20:36:08 <ukleinek> the hardcore option is to wireshark the usb traffic and send that upstream
20:36:19 <ukleinek> not sure someone is willing to look at that ...
20:36:54 <ukleinek> but that might help to create a more reliable reproducer
20:37:11 <bwh> Can you ask the reporter to do that then?
20:37:24 <ukleinek> (for someone who knows more about cameras and usb than me)
20:37:52 <ukleinek> #action ukleinek suggests to wireshark usb traffic for #1121718
20:38:01 <bwh> Thank you
20:38:08 <waldi> TAINT_CPU_OUT_OF_SPEC
20:38:08 <bwh> #topic #1114542: (w, M) linux kernel 6.x : enable all DSA feature for Radxa e54c and others switchs
20:39:11 <carnil> bwh: maybe I'm too conservative here, but I feel just enable all options is wrong; thus I made clear we would like to know which ones are explicitly useful (and tested) by the reporter
20:39:27 * ukleinek agrees with carnil and suggests to wait for more detailed user feedback
20:39:30 <bwh> waldi: Oh, huh. I don't know what sets that on a modern system
20:39:51 <bwh> carnil: I agree and I'm happy to keep waiting for the reporter to specify
20:39:53 <waldi> bwh: but google knows: out of date microcode
20:40:24 <ukleinek> out of date microcode in which bug?
20:40:29 <waldi> the previous
20:40:38 <waldi> but unrelated to the problem i would say
20:40:52 * ukleinek will mention that in his reply anyhow
20:40:52 <bwh> I expect so, yes
20:41:01 <bwh> #topic #1121542: (n, ) iwlwifi: iwlwifi crashes when using Wifi7
20:41:18 <bwh> This was reported against firmware-nonfree and it is showing a firmware crash, so that's probably correct
20:41:47 <waldi> first test: latest firmware package?
20:41:48 <bwh> Either way I think I need to forward it to iwlwifi upstream
20:41:59 <ukleinek> sounds right
20:42:07 <bwh> waldi: Latest version for trixie
20:43:14 <bwh> #action bwh will forward #1121542 to upstream
20:43:23 <bwh> #topic #1080340: (n, +) initramfs-tools does not use include firmware named in the devicetree
20:43:42 <bwh> This is an old bug that I forgot about but should probably actually implement
20:43:48 <ukleinek> TIL firmware filenames in device trees
20:45:03 <bwh> #action bwh will review proposed patch in bug #1080340
20:45:15 <ukleinek> oh wow, that is really a thing: $ git grep firmware-name Documentation/devicetree/ | wc -l
20:45:18 <ukleinek> 118
20:46:03 <bwh> #topic Migration excuses
20:46:28 <waldi> ukleinek: search in arch/arm64/boot/dts …
20:46:40 <carnil> riscv64 is still in Needs-Build for src:linux, rest is done and need waiting
20:46:45 <bwh> linux is/was blocked waiting for the riscv64 build and an autopkgtest failure for cryptsetup
20:47:44 <bwh> Ah, I triggered a retry for cryptsetup which seems to have worked. So a flaky test then
20:48:23 <ukleinek> is 219 packages in the needs-build queue for riscv a big number?
20:49:03 <bwh> There is also a piuparts regression showing on the tracker, but from the log it looks like the package wasn't in APT's lists during the test that failed
20:49:10 <waldi> the debian riscv64 hardware is aweful slow
20:49:47 <ukleinek> m68k only has 54 :-)
20:50:13 <waldi> m68k is not built on real hardware
20:51:10 <bwh> So, do we need to do anything about piuparts?
20:52:20 <carnil> there are ongoing transitions right now, so "might" explain the additional backlog for riscv64
20:52:53 <carnil> (glibc-2.42, gnat-14-abi and python3.14-add afaics)
20:53:44 <bwh> Well, I'm going to move on
20:53:56 <bwh> #topic New upstream versions
20:54:28 <bwh> There's a real new version for firmware-nonfree, and an incorrect version comparison for ktls-utils
20:54:32 <ukleinek> ktls looks strange. Debian is newer than upstream?
20:54:54 <bwh> I think I haven't correctly configured mapping -rc to ~rc
20:55:11 <ukleinek> that's what I was about to suspect
20:55:11 <waldi> 1.3.0-rc1 > 1.3.0-1, which is correct. so yet, version mapping
20:56:11 <bwh> #action bwh will fix watch file for ktls-utils to handle -rc correctly
20:56:36 <bwh> kathara: Would you be interested in integrating the new upstream for firmware-nonfree?
20:58:52 <bwh> OK, I'll do it then
20:59:00 <bwh> #action bwh will update firmware-nonfree to 20251125
20:59:12 <bwh> #topic Merge requests
20:59:55 <bwh> There's only one open that changed since last week, linux!1723
21:00:00 <ukleinek> /usr-merge isn't optional any more, so we don't need to consider that in !1723, right?
21:00:16 <waldi> i want to postpone that, as it touches udebs
21:00:39 <waldi> we have two ways to build them and thats rarely tested
21:00:40 <bwh> It's not a consideration for Debian, only for Freexian ELTS and any other downstream that does backports further than us
21:01:09 <bwh> waldi: You mean building from linux and from linux-signed-*?
21:01:28 <waldi> bwh: yes
21:01:40 <ukleinek> on a quick glance the change looks fine
21:01:50 <waldi> i want to clean this up first, before we do shifting stuff around
21:02:17 <ukleinek> would be nice to let mbiebl know
21:02:21 <waldi> bwh: even freexian elts is free to drop support for non-merged systems first
21:02:24 <waldi> ukleinek: yes
21:03:35 <bwh> waldi: Does it matter that much what order this is done in?
21:04:11 <waldi> bwh: my stance is that this MR must not change the output of the packages. aka no shifting of udebs to /usr
21:04:19 <bwh> Why not?
21:05:22 <bwh> (see https://lists.debian.org/debian-boot/2024/12/msg00003.html)
21:05:40 <waldi> bwh: because this mixes two different changes
21:05:53 <waldi> and udebs are fragile enough as it is
21:06:46 <ukleinek> Is usr-merging udebs adding any fragility, given that the installer is usr-merged, too?
21:07:53 <bwh> I guess I need to a proper review of this one
21:08:04 <bwh> #topic AOB
21:08:18 <ukleinek> It's my turn to chair next week, will do.
21:08:42 <ukleinek> #action ukleinek will chair the 2025-12-10 meeting
21:08:44 <carnil> thank you
21:08:49 <bwh> Thanks ukleinek
21:09:46 <bwh> OK, well thanks all for coming
21:09:50 <bwh> #endmeeting