19:00:28 #startmeeting 19:00:28 Meeting started Wed Oct 15 19:00:28 2025 UTC. The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:40 hi 19:00:41 hi 19:01:30 hi 19:01:52 The first bug on the list is #1118100, but is there any urgent issue besides that? 19:02:37 not much to do left. we can upload -2 at some time and go back to normal 19:02:52 #topic Bug #1118100: linux: FTBFS on 'all' buildd: Could not import extension kernel_include (exception: No module named 'docutils.utils.error_reporting') 19:04:02 I think carnil wanted 6.16.12 to get into testing, which I think can't happen until there is a successfull build for all on buildds 19:04:44 yes, we need a -2 upload 19:04:51 bwh: I can upload 6.16.12-2 with the backported fix, but we agreed we wait until things settle down now, as waldi has uplaoded the arch:all one 19:05:02 and 6.17.y is not yet ready to go to unstable 19:05:11 What do you mean by "settle down"? 19:05:32 see that we did not break something else 19:05:36 OK 19:05:39 so my proposal would be to do the 6.16.12-2 one to sid shortly, stabliize 6.17.y further more but move it soon to unstable (as 6.16.y is EOL) 19:05:54 (for some values of shortly) 19:06:02 I support that 19:06:23 waldi: I marked your 6.17 build fixes to auto-merge 19:07:06 I'm just waiting for waldi to tell me we are ok, for the 'settle down' part 19:07:42 carnil: lets wait until tomorrow, to be sure, okay? 19:07:44 we got hit quite badly with this python-docutils (upload of 0.22.2 to unstable), wonder if we can try to avoid such breakage in future 19:07:47 #agreed carnil will upload 6.16.12-2 to unstable once we are confident that there isn't further breakage from the temporary linux-libc-dev removal 19:07:48 waldi: ack 19:08:36 but apparently upstream as well only got it quite late in mainline, while it was deprecated already for quite a long time (since python 3.6?) 19:09:03 carnil: not really. it's a simply api breakage in an unversioned api 19:09:07 I think the problem is no-one cares about doc builds upstream besides Jonathan Corbet, and he has another job to do 19:09:25 See also the hundreds of warnings from the doc build 19:10:06 Also this would have been no big deal without the dak bug 19:10:13 yes 19:10:28 #topic #1112627: linux-image-6.16.3+deb14-amd64: Intel audio no longer works: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] ... non-zero reserved fields in PTE 19:11:01 had not had time yet to respond, but it's interesting 19:11:29 I would have asked to provide the config from selfbuilt kernel to see if we spot differences 19:11:38 but bwh you seem to already have an idea 19:11:38 The latest result here is that v6.13-rc6 uptream "works", but I think that is because CONFIG_INTEL_IOMMU_DEFAULT_ON_INTGPU_OFF (in our config) does not exist upstream, so the result is ONFIG_INTEL_IOMMU_DEFAULT_OFF 19:12:08 So you should ask to test with intel_iommu=on (I think that's the right boot parameter, but check) 19:12:48 Does that make sense? 19:13:19 bwh: it is already confirmed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112627#22 19:14:05 but he has not tested that explicitly turning it on "breaks" the upstream kernel 19:14:07 (with some other side effects) 19:14:25 ah yes, I will ask that next 19:14:39 and yes it make sense 19:15:26 #action carnil will ask to test #1112627 on the upstream kernel with IOMMU explicitly enabled 19:15:45 #topic #1114557: linux-image-6.12.43+deb13-amd64: Jieli touchscreen and stylus no longer supported 19:16:26 nothing to do 19:16:38 upstream has not yet settled on landing a patch, so right would agree 19:16:45 The last message from the patch author refers to the same serial number (which was part of the ID used to match) on "another microphone device", but I'm not sure whether this means another instance of the same model, or a different model 19:17:03 Would it be worth asking to clarify this? Or should we just on upstream some more? 19:18:10 OK, we'll leave it, then 19:18:17 yes 19:18:18 #topic #1114884: linux-image-6.1.0-39-amd64: AMD Ryzen 9 7950X, linux-image-6.1.0-39-amd64 hangs on boot while 6.1.0-37-amd64 works fine 19:18:46 No information added since I last checked, so I think we can leave this with the reporter 19:19:09 #topic #1117672: Debian trixie 13.1: Orangepi5b plus] linux-image-6.12.48+deb13-arm64: NVMe and PCIe issues 19:19:54 This apparently works in the Armbian kernel, but I looked at Armbian and its kernel build process once and was horrified so ... 19:20:27 It may at least be worth checking that we aren't missing some important config for this platform 19:21:17 the device trees are broken 19:21:24 Oh right? 19:21:37 /pcie@fe190000/legacy-interrupt-controller 19:21:43 /pcie@fe190000: Fixed dependency cycle(s) with 19:22:08 so, are those provided by the firmware or linux? 19:24:00 I think they must come from the SD card image 19:24:32 So, someone could have a look at that and work out if it's the same one we build or not 19:24:51 i can take a look 19:25:31 #action waldi to take at the device tree and kernel config in #1117672 19:25:31 #action waldi will investigate broken DT seen in #1117672 19:25:35 sorry 19:25:53 #topic #1111011: RTL8125D - link drops 19:26:47 There's a new message that says turning autoneg off fixes it 19:27:11 and 100MBit, so legacy support 19:27:19 I'm trying to remember now whether EEE depends on autoneg or if it's yet another out-of-band thing 19:28:05 I suppose we can just ask to check EEE status with ethtool 19:28:52 #action bwh will ask reporter of #1111011 to check EEE status in the broken and working configs 19:29:08 #topic #1116067: linux-image-6.1.0-32-amd64: btrfs compression quietly stopped around 60TB in 19:30:11 There's a new message from the reporter that also went to upstream, but still no response from upstream. I'm not sure what we can do about that 19:31:08 Well, it doesn't seem exactly urgent anyway 19:31:17 #topic #1116358: linux-image-6.12.48+deb13-amd64: LVM snapshots causing I/O errors in KVM guest with aio=io_uring set 19:31:43 waiting for merge 19:31:50 and then stable 19:31:54 Jens has reverted in his tree, wainting to land in mainline and stable series 19:32:03 ack 19:32:04 carnil: Can you ask the reporter to test that the revert actually fixes it? 19:32:29 I would expect so, but there could also be later changes that break it further 19:32:48 yes sure, will do 19:33:45 #action carnil will ask reporter to test the patch for #1116358 19:33:58 #topic #1117002: 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 19:35:03 carnil: This should go upstream, shouldn't it? 19:35:38 bwh: yes I think so. I was hoping to see something more by testing a more recent kernel, but now it might just go to upstream as it is 19:35:44 should I forward it? 19:36:07 I think the message before the splat makes it pretty clear what exactly is triggering it 19:36:12 Please do forward it 19:36:43 #action carnil forwards #1117002 report to upstream 19:36:59 #topic #1117256: linux-image-6.12.48+deb13-amd64: Kernel can no longer activate ethernet on Dell WD19S docking station 19:37:39 No information arrived since I last looked, so we are waiting for the reporter 19:37:58 #topic #1117567: Held Package Still Updating 19:38:29 not a bug for us 19:38:31 This is either misfiled, or user error, but let's wait for a response 19:38:34 I'm no really sure we should keep that open 19:39:28 If they are correct then it is a real bug for apt, isn't it? 19:40:57 #topic #1117599: linux-image-6.16.9+deb14-amd64: GPU hangs three times after starting chromium 19:41:01 yes right, then we really need the requested information about the apt upgrade log. We can wait and see if we get a reply. 19:42:23 This bug is now known to be reproducible with 6.12 and current chromium as well. But not with an older chromium version. 19:42:58 It should probably be marked "found" for some specific 6.12 package version but the reporter doesn't seem to have said what version was tested 19:44:32 this, and maybe ask if the reporter can go further back versions to identify at which version it breaks 19:44:57 but it might be that it existed already for a long time (because it is now just hit with the chromium change) 19:45:00 Versions of what, the kernel? How do we know there is a good version? 19:45:47 bwh: the reporter said, updating the chromium package triggers the problem, so updating the crhomium package to v141.0 and then go versions back of the kernel was my suggestion) 19:46:06 but I'm not sure it is fruitfu 19:46:12 fruitful 19:46:33 Another thing is: aren't old erGPUs inherently liable to hang because they don't have a hardware scheduler? 19:48:34 Wereally need someone on the team who knows more about graphics drivers... 19:50:07 So is there anything we can usefully do here? 19:50:57 no. there are two yellow flags: 18 year old hardware, xorg 19:51:48 You're telling me 2007 is 18 years ago? That hurts 19:52:34 but yes, this stuff is probably too old to expect much support 19:52:55 #topic #1117848: linux-image-6.12.48+deb13-amd64: After a few hours of desktop operation under kde the amdgpu driver crashes 19:56:18 I'm trying to digest what is this suggested cofnig doing 19:56:32 Maybe one of us should just reply to ask... 19:58:04 Looks like PP_STUTTER_MODE, whatever that is, is masked out 19:58:28 Any ideas for what to do? 19:58:43 * carnil has no ideas on it right now 19:59:42 asking to forward directly to upstream it is an option, but on amdgpu related bugs we are still in bad position 19:59:48 yes 20:00:39 #action bwh will follow up #1117848, ask for more info about suggested workaround, and forward 20:00:59 #topic #1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration 20:01:30 Nothing changed since I last looked; the reporter needs to go upstream 20:01:51 #topic #1118025: USB mouse stops working after suspend on Debian 13 (usbhid error -71) 20:02:31 do we need ore context from the log here? 20:02:33 The workaround for non-working buttons on a USB mouse is to reload the psmouse module 20:02:47 this means: no usb at all 20:03:15 wait 20:03:17 hmm, but why does psmouse affect that? 20:03:33 weird ps2-usb emulation in the firmware? 20:03:47 haven't seen that for a long time 20:04:00 I was thinking that psmouse is reporting buttons stuck down and that is merged with the USB mouse so the buttons are never seen as clicked 20:04:34 then just denylisting psmouse would work 20:04:34 I think evtest could confirm that? 20:05:25 and reportbug output would be useful 20:05:32 yes 20:06:02 Can you ask for that? 20:06:11 i can do that 20:07:17 #action waldi will follow up #1118025 20:07:25 #topic #1117674: Please enable udebs for the 6.1 backport 20:08:08 but why? 20:08:09 This is for bullseye LTS, so I will handle it. I'm not sure if it's a suitable change for (oldold)stable though 20:08:27 if 6.1 works, use oldstable 20:09:06 Yeah I don't know. I can discuss this with the LTS team 20:10:00 #topic #1111052: Please increase default UDP receive buffer size (rmem_max) 20:10:12 and also #1111657 20:11:21 I think these changes probably aren't suitable for Debian stable or upstream stable. And since mainline has changed, there should be nothing to do in linux-base... 20:12:59 #topic Migration excuses 20:13:44 I think linux is just blocked on #1118100 and the workaround for that, so already discussed 20:14:09 #topic New upstream versions 20:14:56 Besides linux which is updated in experimental, there are new version of firmware-nonfree (again), ktls-utils, and wireless-regdb 20:15:28 kathara: Would you like to handle this firmware-nonfree update as well? 20:15:45 yes, will look into this 20:16:01 #action kathara will update firmware-nonfree to upstream 20251011 20:16:20 I will take the other 2 unless someone else wants to.... 20:16:38 i can look into those as well :) 20:17:15 You can't easily do wireless-regdb though, as it requires signing with a key that's trusted by the kernel 20:17:27 #action kathara will update ktls-utils to 1.3.0-rc1 20:17:41 #action bwh will update wireless-regdb to 2025.10.07 20:17:45 ooh, okkei 20:17:57 #topic Merge requests 20:18:31 Does anyone have a particular MR to discuss? 20:19:12 i have the first package reorg patches finished, but will wait until after we have 6.17 in unstable 20:19:23 nothing else 20:19:27 Thanks, I will try to review that 20:19:30 bwh: not neceesarily in the meeting, but I would like to finish https://salsa.debian.org/kernel-team/linux/-/merge_requests/1636 and I'm not sure my understanding in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1636#note_664224 is correct 20:19:44 so if you have time you can correct me in either direction is needed 20:20:18 I'll have a look 20:20:27 #topic AOB 20:21:10 nothing from me 20:21:26 nothing from me either 20:21:52 Who can chair next week? 20:23:18 I read that ukleinek is interested/can take the 22th, if that does not hold I can take it as I think it would be next again my turn 20:23:42 So let's provisionally say it's ukleinek 20:23:45 I will ask him and if he is not available I will do 20:23:50 Thanks 20:23:57 #endmeeting