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