19:00:28 <bwh> #startmeeting
19:00:28 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:40 <waldi> hi
19:00:41 <carnil> hi
19:01:30 <kathara> hi
19:01:52 <bwh> The first bug on the list is #1118100, but is there any urgent issue besides that?
19:02:37 <waldi> not much to do left. we can upload -2 at some time and go back to normal
19:02:52 <bwh> #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 <bwh> 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 <waldi> yes, we need a -2 upload
19:04:51 <carnil> 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 <carnil> and 6.17.y is not yet ready to go to unstable
19:05:11 <bwh> What do you mean by "settle down"?
19:05:32 <waldi> see that we did not break something else
19:05:36 <bwh> OK
19:05:39 <carnil> 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 <carnil> (for some values of shortly)
19:06:02 <bwh> I support that
19:06:23 <bwh> waldi: I marked your 6.17 build fixes to auto-merge
19:07:06 <carnil> I'm just waiting for waldi to tell me we are ok, for the 'settle down' part
19:07:42 <waldi> carnil: lets wait until tomorrow, to be sure, okay?
19:07:44 <carnil> 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 <bwh> #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 <carnil> waldi: ack
19:08:36 <carnil> 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 <waldi> carnil: not really. it's a simply api breakage in an unversioned api
19:09:07 <bwh> 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 <bwh> See also the hundreds of warnings from the doc build
19:10:06 <bwh> Also this would have been no big deal without the dak bug
19:10:13 <waldi> yes
19:10:28 <bwh> #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 <carnil> had not had time yet to respond, but it's interesting
19:11:29 <carnil> I would have asked to provide the config from selfbuilt kernel to see if we spot differences
19:11:38 <carnil> but bwh you seem to already have an idea
19:11:38 <bwh> 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 <bwh> So you should ask to test with intel_iommu=on (I think that's the right boot parameter, but check)
19:12:48 <bwh> Does that make sense?
19:13:19 <carnil> bwh: it is already confirmed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112627#22
19:14:05 <bwh> but he has not tested that explicitly turning it on "breaks" the upstream kernel
19:14:07 <carnil> (with some other side effects)
19:14:25 <carnil> ah yes, I will ask that next
19:14:39 <carnil> and yes it make sense
19:15:26 <bwh> #action carnil will ask to test #1112627 on the upstream kernel with IOMMU explicitly enabled
19:15:45 <bwh> #topic #1114557: linux-image-6.12.43+deb13-amd64: Jieli touchscreen and stylus no longer supported
19:16:26 <waldi> nothing to do
19:16:38 <carnil> upstream has not yet settled on landing a patch, so right would agree
19:16:45 <bwh> 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 <bwh> Would it be worth asking to clarify this? Or should we just on upstream some more?
19:18:10 <bwh> OK, we'll leave it, then
19:18:17 <carnil> yes
19:18:18 <bwh> #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 <bwh> No information added since I last checked, so I think we can leave this with the reporter
19:19:09 <bwh> #topic #1117672: Debian trixie 13.1: Orangepi5b plus] linux-image-6.12.48+deb13-arm64: NVMe and PCIe issues
19:19:54 <bwh> 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 <bwh> It may at least be worth checking that we aren't missing some important config for this platform
19:21:17 <waldi> the device trees are broken
19:21:24 <bwh> Oh right?
19:21:37 <waldi> /pcie@fe190000/legacy-interrupt-controller
19:21:43 <waldi> /pcie@fe190000: Fixed dependency cycle(s) with
19:22:08 <waldi> so, are those provided by the firmware or linux?
19:24:00 <bwh> I think they must come from the SD card image
19:24:32 <bwh> So, someone could have a look at that and work out if it's the same one we build or not
19:24:51 <waldi> i can take a look
19:25:31 <waldi> #action waldi to take at the device tree and kernel config in #1117672
19:25:31 <bwh> #action waldi will investigate broken DT seen in #1117672
19:25:35 <bwh> sorry
19:25:53 <bwh> #topic #1111011: RTL8125D - link drops
19:26:47 <bwh> There's a new message that says turning autoneg off fixes it
19:27:11 <waldi> and 100MBit, so legacy support
19:27:19 <bwh> I'm trying to remember now whether EEE depends on autoneg or if it's yet another out-of-band thing
19:28:05 <bwh> I suppose we can just ask to check EEE status with ethtool
19:28:52 <bwh> #action bwh will ask reporter of #1111011 to check EEE status in the broken and working configs
19:29:08 <bwh> #topic #1116067: linux-image-6.1.0-32-amd64: btrfs compression quietly stopped around 60TB in
19:30:11 <bwh> 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 <bwh> Well, it doesn't seem exactly urgent anyway
19:31:17 <bwh> #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 <waldi> waiting for merge
19:31:50 <waldi> and then stable
19:31:54 <carnil> Jens has reverted in his tree, wainting to land in mainline and stable series
19:32:03 <carnil> ack
19:32:04 <bwh> carnil: Can you ask the reporter to test that the revert actually fixes it?
19:32:29 <bwh> I would expect so, but there could also be later changes that break it further
19:32:48 <carnil> yes sure, will do
19:33:45 <bwh> #action carnil will ask reporter to test the patch for #1116358
19:33:58 <bwh> #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 <bwh> carnil: This should go upstream, shouldn't it?
19:35:38 <carnil> 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 <carnil> should I forward it?
19:36:07 <bwh> I think the message before the splat makes it pretty clear what exactly is triggering it
19:36:12 <bwh> Please do forward it
19:36:43 <carnil> #action carnil forwards #1117002 report to upstream
19:36:59 <bwh> #topic #1117256: linux-image-6.12.48+deb13-amd64: Kernel can no longer activate ethernet on Dell WD19S docking station
19:37:39 <bwh> No information arrived since I last looked, so we are waiting for the reporter
19:37:58 <bwh> #topic #1117567: Held Package Still Updating
19:38:29 <waldi> not a bug for us
19:38:31 <bwh> This is either misfiled, or user error, but let's wait for a response
19:38:34 <carnil> I'm no really sure we should keep that open
19:39:28 <bwh> If they are correct then it is a real bug for apt, isn't it?
19:40:57 <bwh> #topic #1117599: linux-image-6.16.9+deb14-amd64: GPU hangs three times after starting chromium
19:41:01 <carnil> 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 <bwh> 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 <bwh> 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 <carnil> this, and maybe ask if the reporter can go further back versions to identify at which version it breaks
19:44:57 <carnil> 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 <bwh> Versions of what, the kernel? How do we know there is a good version?
19:45:47 <carnil> 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 <carnil> but I'm not sure it is fruitfu
19:46:12 <carnil> fruitful
19:46:33 <bwh> Another thing is: aren't old erGPUs inherently liable to hang because they don't have a  hardware scheduler?
19:48:34 <bwh> Wereally need someone on the team who knows more about graphics drivers...
19:50:07 <bwh> So is there anything we can usefully do here?
19:50:57 <waldi> no. there are two yellow flags: 18 year old hardware, xorg
19:51:48 <bwh> You're telling me 2007 is 18 years ago? That hurts
19:52:34 <bwh> but yes, this stuff is probably too old to expect much support
19:52:55 <bwh> #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 <bwh> I'm trying to digest what is this suggested cofnig doing
19:56:32 <bwh> Maybe one of us should just reply to ask...
19:58:04 <bwh> Looks like PP_STUTTER_MODE, whatever that is, is masked out
19:58:28 <bwh> Any ideas for what to do?
19:58:43 * carnil has no ideas on it right now
19:59:42 <carnil> asking to forward directly to  upstream it is an option, but on amdgpu related bugs we are still in bad position
19:59:48 <bwh> yes
20:00:39 <bwh> #action bwh will follow up #1117848, ask for more info about suggested workaround, and forward
20:00:59 <bwh> #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 <bwh> Nothing changed since I last looked; the reporter needs to go upstream
20:01:51 <bwh> #topic #1118025: USB mouse stops working after suspend on Debian 13 (usbhid error -71)
20:02:31 <carnil> do we need ore context from the log here?
20:02:33 <bwh> The workaround for non-working buttons on a USB mouse is to reload the psmouse module
20:02:47 <waldi> this means: no usb at all
20:03:15 <waldi> wait
20:03:17 <bwh> hmm, but why does psmouse affect that?
20:03:33 <waldi> weird ps2-usb emulation in the firmware?
20:03:47 <waldi> haven't seen that for a long time
20:04:00 <bwh> 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 <waldi> then just denylisting psmouse would work
20:04:34 <bwh> I think evtest could confirm that?
20:05:25 <waldi> and reportbug output would be useful
20:05:32 <bwh> yes
20:06:02 <bwh> Can you ask for that?
20:06:11 <waldi> i can do that
20:07:17 <bwh> #action waldi will follow up #1118025
20:07:25 <bwh> #topic #1117674: Please enable udebs for the 6.1 backport
20:08:08 <waldi> but why?
20:08:09 <bwh> 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 <waldi> if 6.1 works, use oldstable
20:09:06 <bwh> Yeah I don't know. I can discuss this with the LTS team
20:10:00 <bwh> #topic #1111052: Please increase default UDP receive buffer size (rmem_max)
20:10:12 <bwh> and also #1111657
20:11:21 <bwh> 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 <bwh> #topic Migration excuses
20:13:44 <bwh> I think linux is just blocked on #1118100 and the workaround for that, so already discussed
20:14:09 <bwh> #topic New upstream versions
20:14:56 <bwh> Besides linux which is updated in experimental, there are new version  of firmware-nonfree (again), ktls-utils, and wireless-regdb
20:15:28 <bwh> kathara: Would you like to handle this firmware-nonfree update as well?
20:15:45 <kathara> yes, will look into this
20:16:01 <bwh> #action kathara will update firmware-nonfree to upstream 20251011
20:16:20 <bwh> I will take the other 2 unless someone else wants to....
20:16:38 <kathara> i can look into those as well :)
20:17:15 <bwh> You can't easily do wireless-regdb though, as it requires signing with a key that's trusted by the kernel
20:17:27 <bwh> #action kathara will update ktls-utils to 1.3.0-rc1
20:17:41 <bwh> #action bwh will update wireless-regdb to 2025.10.07
20:17:45 <kathara> ooh, okkei
20:17:57 <bwh> #topic Merge requests
20:18:31 <bwh> Does anyone have a particular MR to discuss?
20:19:12 <waldi> i have the first package reorg patches finished, but will wait until after we have 6.17 in unstable
20:19:23 <waldi> nothing else
20:19:27 <bwh> Thanks, I will try to review that
20:19:30 <carnil> 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 <carnil> so if you have time you can correct me in either direction is needed
20:20:18 <bwh> I'll have a look
20:20:27 <bwh> #topic AOB
20:21:10 <waldi> nothing from me
20:21:26 <carnil> nothing from me either
20:21:52 <bwh> Who can chair next week?
20:23:18 <carnil> 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 <bwh> So let's provisionally say it's ukleinek
20:23:45 <carnil> I will ask him and if he is not available I will do
20:23:50 <bwh> Thanks
20:23:57 <bwh> #endmeeting