20:00:01 <carnil> #startmeeting
20:00:01 <MeetBot> Meeting started Wed Nov 26 20:00:01 2025 UTC.  The chair is carnil. Information about MeetBot at https://wiki.debian.org/MeetBot.
20:00:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:05 <carnil> hi
20:00:23 <bwh> Hi
20:00:28 <ukleinek> o/
20:00:30 <bwh> Sorry for flaking last week
20:00:35 <carnil> #chair bwh ukleinek waldi
20:00:35 <MeetBot> Current chairs: bwh carnil ukleinek waldi
20:00:51 <carnil> bwh: welcome back :)
20:01:10 <ukleinek> bwh: we were flaky, too. We talked in German and didn't go through all the bugs :-D
20:01:32 <carnil> before we start, is there anything which you would like to bring on the table for discussion?
20:01:57 <bwh> Nothing urgent from me
20:02:43 <carnil> okay then let's just start with what is on the agenda
20:02:52 <carnil> #topic Removal of iptables-legacy
20:03:00 <ukleinek> looking at the calendar, do we skip the meeting on 2025-12-24 and 2025-12-29, or do we pick another day in these weeks?
20:03:46 <bwh> Last time I think we just skipped 12-25 and 01-01
20:03:58 <ukleinek> s/29/31/
20:04:09 <waldi> hi
20:04:24 <ukleinek> I think skipping is fine
20:04:24 <carnil> ukleinek: ah yes I cannot immagine that any of us prefers a jitsi/irc meeting on 24th instead of staying away from computer :)
20:04:49 <bwh> Whoever prepares the agenda for the following meeting should take care to tell find-recent-urgent to look back a larger number of days
20:05:05 <ukleinek> ack
20:05:32 <carnil> ack, let's not forget to plan for that in the upcoming meetings and fill as well in the dates for the next year
20:06:02 <carnil> so we already drifted away from the topic :)
20:06:12 <ukleinek> I wonder if looking back one week for normal meetings is sensible, I assume things fall through the cracks. But I don't have a better proposal ...
20:06:40 <bwh> OK, so from the feedback it seems like there are a number of false positives for code paths that would use iptables-legacy but are not execued
20:07:23 <bwh> waldi: Do you think you can exclude those, manually or automatically?
20:07:23 <ukleinek> less packages = better, so \o/
20:07:44 <carnil> #link https://lists.debian.org/debian-devel/2025/11/msg00303.html
20:08:14 <waldi> bwh: i have to recheck all anyway, as i did not note what they actually do
20:08:55 <carnil> so the plan would be to do a refinement and check all first, then re-propose the MBF with the dd-list
20:08:58 <carnil> ?
20:09:04 <waldi> no, then write the bugs
20:09:18 <ukleinek> sounds sensible
20:09:27 <carnil> or so, though another feedback loop would make sense, but fine
20:09:56 <carnil> #action waldi rechecks all candidates and then fills bugs for the iptables-legacy removal
20:09:58 <ukleinek> if the set of packages is strictly less than announced I don't see a need to reannounce
20:10:07 <bwh> I agree
20:10:30 <waldi> all the detection is loosy anyway, as we don't have dependencies to check, but just code that uses it or in most cases runs update-alternatives automatically
20:11:22 * ukleinek nods and holds his breath for the next topic
20:11:32 <carnil> the bug list
20:11:46 <carnil> #topic #1105211: mt7921e: stuck at low transmit power
20:12:27 <carnil> while re-reading the bug I realized there might have just been some confusion on how to properly pass the parameter to the right module. I might be wrong. But asked some questions back to the reporter and gave hints on possible workaround configuration.
20:12:28 <ukleinek> sounds like a wait
20:12:31 <carnil> I propose to wait
20:12:41 <bwh> agreed
20:12:55 <carnil> #topic #1106558: linux-image-6.12.22+bpo-amd64: Wifi module fails to load
20:13:06 <carnil> wait; asked back if still reproducible with 6.12.57-1 as in trixie
20:13:24 <carnil> #topic #1116554: linux-image-6.12.43+deb12-amd64: hard freeze during normal operation with stacktraces in the syslog
20:13:43 <carnil> wait :-/ Asked back if still reproducible with the newest 6.12.57-1 in trixie. Asked as well for tests with kernel in unstable. -> wait now for feedback from reporter
20:13:57 <bwh> OK
20:14:21 <carnil> #topic #1116643: UBSAN: shift-out-of-bounds in .../drivers/gpu/drm/display/drm_dp_mst_topology.c (shift exponent -1)
20:14:55 <carnil> Found potential right upstream report with a proposed patch. Asked Vincent if problem easy reproducible and if he can test the patch. But maybe if someone has spare cycles it would be good to double check that seems a potential good candidate. In any case if Vincent is able to reproduce he will try to test the patch.
20:15:03 <ukleinek> sounds easy
20:15:25 <carnil> ukleinek: so you are going to double check :)
20:15:26 <ukleinek> (that is, to look at the upstream patch and judge if it fixes the problem)
20:15:43 <carnil> ukleinek: yes please do
20:15:46 <ukleinek> #action ukleinek looks at #1116643
20:16:06 <carnil> #topic #1118437: linux-image-6.17.2-amd64: kernel crash in interrupt after receiving an ip packet on veth from xsk from user space
20:16:25 <carnil> we are at v7 of proposed patchset -> Wait for fixes to land IMHO
20:16:43 * ukleinek nods
20:17:09 <carnil> #topic #1120554: linux-image-6.12.48+deb13-amd64: SOF driver fails on Intel Comet Lake - CSE_IPC_RESET_PHASE_1 timeout
20:17:36 <carnil> ukleinek: asked questions back (in particular to confirm firmware-sof-signed is installed and if not install it and test with it)
20:17:59 <carnil> Additionally to test with newer kernels, but so far no reply from reporter
20:18:06 * ukleinek nods again
20:18:18 <carnil> So with as many of our bugs: wait for feedback
20:18:24 <bwh> We should add that to the bug control file
20:18:46 <ukleinek> having many bugs that don't need an action is good1
20:19:06 <carnil> bwh: you mean the information on firmware-sof-signed?
20:19:17 <bwh> #action bwh will add firmware-sof-signed and other firmware packages to Package-Status field of the reportbug control file
20:19:28 <carnil> +1 sounds good
20:19:44 <ukleinek> ..ooOO(Can I have an irssi pluging that simplifies nodding?)
20:20:07 <bwh> carnil: I think we have a (possibly outdated) list of firmware binaries built from firmware-{non,}free but not those from elsewhere
20:20:37 <waldi> should we retrieve all binary packages from non-free-firmware and just add them?
20:21:08 <bwh> That might make sense but I'm not sure whether everything from there is relevant
20:21:11 <ukleinek> maybe review that list.
20:21:24 <bwh> I will certainly start with that list
20:21:37 <ukleinek> /nod
20:21:49 <waldi> does it matter if some not completely relevant packages show up in this list?
20:22:17 <waldi> we talk about 49 right now
20:22:23 * carnil has no idea how long the list is
20:22:27 <carnil> ok
20:23:04 <bwh> Next bug?
20:23:11 <carnil> I guess it would be a good stat and then refine it as needed
20:23:12 <carnil> yes
20:23:14 <ukleinek> it doesn't really hurt, but obviously useless packages (if any) should still be skipped. I think it's easy to spot those
20:23:29 <carnil> #topic #1120598: nfs: ls input/output error ("NFS: readdir(/) returns -5") on krb5 NFSv4 client using SHA2
20:24:35 <carnil> patch in progress upstream (and the problem is only relevant under certain conditions where as Chuck Lever describes it in the proposed patch. So we can simply wait here that patch lands in mainline and then goes to the stable series as needed.
20:24:57 <carnil> #topic #1120602: hyper-v: BUG: kernel NULL pointer dereference, address: 00000000000000a0
20:25:10 <carnil> patch submitted to stable (already in 6.12.58) and pending for 6.1.y
20:25:22 <carnil> so will be in the next uploads
20:25:34 <carnil> -> wait and make sure to add bug closer on stable series import
20:25:42 <bwh> So this can be tagged patch fixed-upstream, right?
20:26:25 <carnil> ah hes potentially. it has not landed yet in older stable series than 6.12.y and it did not affect mainline or upper stable series
20:26:41 <carnil> s/hes/yes/
20:26:44 <bwh> Well I will tag it patch anyway
20:26:51 <carnil> thanks
20:27:04 <ukleinek> [x] done
20:27:26 <ukleinek> (patch + fixed-upstream)
20:27:27 <carnil> #topic #1120718: linux-image-6.12.43+deb13-amd64: hung tasks on mutex acquisition during rtnetlink ops
20:27:48 <carnil> reporter should try to identify last kernel without problems (has hints on snapshot.d.o service)
20:28:01 <carnil> -> wait for user feedback
20:28:08 <bwh> Did you find out what the OOT module is there?
20:28:29 <bwh> The hang messages should OE taint but no module with those flags is in the module list
20:29:34 <ukleinek> firmware-nvidia-graphics is installed
20:29:34 <carnil> oh I might have missed that because the module list does not contain the information.
20:30:00 <ukleinek> hmm, but that might be autoinstalled?!
20:30:08 <bwh> Oh the later log has not tainted, so never mind
20:31:07 <carnil> ok so we remain with that single action to first wait for the reporter
20:31:30 <bwh> agreed
20:31:38 <carnil> #topic #1121006: linux: reported optimal_io_size from mpt3sas devices results in 4GB raid10 optimal_io_size
20:32:51 <carnil> this one is intersting, there is a upstream thread relating to the problem but which stalled. I was planning to ping mpt3sas folks about it and see if they can chime in and get I/O people's attention. But I was wondering if someone else in the team has other ideas to tackle apart form that path.
20:33:31 <carnil> I believe it would be best to get Christoph's Hellwig's attention on that thread again
20:33:50 <carnil> and best thing I can immagine is to try to bring the people again on that thread
20:33:57 <carnil> it stalled in august afaics
20:34:12 <bwh> yes I think that's a good plan
20:34:46 <carnil> Then I take care of it (as I was in contact for it with Filippo and Moritz Muehlenhoff)
20:34:52 <ukleinek> How das Christoph Hellwig come into play, he's in the stalled upstream thread I assume?
20:34:56 <bwh> yes
20:35:39 <carnil> #topic #1121227: linux-image-6.12.48+deb13-amd64: Black screen with Nouveau TRAP_PROP [RT-FAULT] on NVIDIA GT 230M (GT216M)
20:35:53 <carnil> I think we need a bit to "handhold" the reporter here to get to the information we need
20:36:25 <carnil> Asked to followup with the reportbug collected information but we got then another bugreport against general withouth information
20:36:43 <carnil> se we have neither full kernel logs nor information on other components of the system
20:37:14 <carnil> but can we deduce already something here from the information posted in the first message?
20:37:28 <bwh> I think they might be confused by your not top-posting
20:38:13 <bwh> So, maybe try asking again but without quoting...?
20:38:46 <carnil> and maybe give the concrete commands to run so we get the info on the next message
20:39:18 <carnil> if I should speed up things let me know
20:39:40 <ukleinek> #action ukleinek tries to handhold for #1121227
20:40:02 <carnil> ukleinek: ok perfect, I just cancelled the action was formulating :)
20:40:18 <carnil> #topic #1100105: linux-image-amd64: Issues with Framework audio module
20:40:44 <carnil> this one confuses me tbh. S "now" it work with 6.12.48-1 but fails with newer versions from testing/unstable if my interpretation of the bug log is correct
20:41:29 <bwh> I really think this is flakiness and not any software fix being added or removed
20:41:58 <ukleinek> matches my suspicion
20:41:59 <bwh> Every reboot brings a different random state of the hardware
20:42:52 <bwh> I suppose it's also possible that some quirk not directed at this specific hardware module is also affecting it
20:42:56 <ukleinek> Hmm, that means that finding the problem (or a fix) is really hard
20:43:02 <bwh> yes
20:43:45 <bwh> Has there ever been any upstream contact about this bug?
20:44:07 <ukleinek> the reporter talked to the laptop vendor
20:44:38 <ukleinek> I think upstream wasn't involved yet.
20:44:41 <bwh> right
20:44:53 <bwh> #action bwh will forward #1100105 upstream
20:44:59 <ukleinek> thanks
20:45:05 <carnil> thank you
20:45:21 <carnil> #topic #1116251: linux-image-6.12.48+deb13-rpi: Raspberry Pi Zero W does not boot
20:45:38 <carnil> there is some progress now, bdrung followed up and we have now output from the boot
20:46:02 <carnil> #link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116251#42
20:46:18 <ukleinek> right, I intended to look what changed between these kernels regarding CMA but didn't manage to actually do it
20:46:25 <carnil> I skimmed over the changes in the stable series, but found only 46efab01648a04082266115a8e917c3b26b97fa8
20:46:34 <carnil> would that make sense?
20:46:48 <carnil> cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116251#49
20:47:37 <ukleinek> letting bdrung test with that commit reverted definitively brings us forward
20:48:48 <carnil> okay so we wait for bdrung now to see if the commit reverted fixes the problem
20:49:17 <carnil> #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:49:36 <carnil> commit is in next, wait that it lands in mainline (and it is candidate for stable series and trickles down)
20:49:52 <bwh> OK
20:49:57 <carnil> #topic #1118349: Hanging the radeon video on AMD APU, reopening #879992
20:49:59 * ukleinek agrees to "Thank you so much Salvatore"
20:50:21 <carnil> closed now, as we really were not able to get on the same page with the reporter :(
20:50:43 <carnil> #topic #1119093: linux-image-6.16.3+deb13-amd64: UBSAN array-index-out-of-bounds in ath5k driver
20:50:53 <carnil> Fix submitted upstream. Wait for landing and monitor for inclusion in the stable series as needed.
20:50:56 <carnil> -> wait
20:51:25 <carnil> #topic #1120280: linux-image-6.12.57+deb13-amd64-unsigned: BUG: ENTRY_TRAMPOLINE stack guard page was hit at (maybe related with usage of make --load-average)
20:51:41 <carnil> questions from ukleinek, wait for feedback from reporter
20:51:47 <ukleinek> /nod
20:51:54 <carnil> #topic #1120854: linux-image-arm64: Enable dma engine for Renesas RZ platform
20:52:04 <carnil> this has a MR associated
20:52:11 <carnil> #link https://salsa.debian.org/kernel-team/linux/-/merge_requests/1720
20:52:17 <bwh> Yes and I should go and review that
20:52:28 <carnil> someone with better knowledge than me for arm64 feels to take care of reviewing it?
20:52:34 <carnil> ah bwh :)
20:53:00 <carnil> #action bwh reviews MR (!1720) for #1120854
20:53:23 <carnil> #topic #1121032: thunderbolt_net: missing ndo_set_mac_address prevents bonding mode 802.3ad
20:53:25 <ukleinek> Is bwh for Renesas now? The footer in the last mail suggests that :-D
20:53:35 <ukleinek> s/for/working for/
20:53:50 <bwh> Huh?
20:54:10 <carnil> proposed patch waits for confirmation from reporter, but IMHO looks promising. So wait for feedback and wait it lands in mainline
20:54:23 <ukleinek> bwh: ah, no, the renesas guy uses strange quoting and so his footer looks like it was added by you
20:54:25 <carnil> ukleinek: really?
20:54:42 <carnil> #1121211: UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/drivers/clk/samsung/clk-exynos-clkout.c:178:18
20:54:49 <carnil> #topic #1121211: UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/drivers/clk/samsung/clk-exynos-clkout.c:178:18
20:54:52 <carnil> (sorry)
20:55:02 <carnil> reported upstream, patch tested, will be in 6.19
20:55:26 <carnil> (will later be backported to stable series, but not urgent, needs just monitoring for adding bug closer)
20:55:43 <bwh> I just added a patch tag to the last 2
20:55:43 <carnil> and just in time before the 1h exceeds we are done with the bug list :)
20:56:00 <carnil> bwh: thanks, I seem to have been bit negligent on proper tagging :(
20:56:09 <ukleinek> \o/, thanks carnil, great preparation
20:56:16 <carnil> #topic Migration excuses
20:56:33 <carnil> we are waiting for firmware-nonfree (too-young) and src:linux (as well to young, uploaded today)
20:56:42 <carnil> #topic New upstream versions
20:56:46 <carnil> nothing?! ;-)
20:56:58 <bwh> I think this may be broken due a uscan change (discussed on d-devel)
20:57:20 <ukleinek> 🙈
20:57:31 <bwh> but we might also really be up-to-date
20:57:46 <bwh> firmware-free should definitely be there even though none of the upstream changes are relevant to it
20:58:52 <carnil> yes right, that suprised me but I did not bother to look what might have been the cause. Se we might double check with the uscan change.
20:59:18 <carnil> #topic Merge requests
20:59:38 <carnil> the only one additionally which I see ready yet would be !1670
20:59:54 <bwh> waldi: Please answer my last comment on !1615
21:00:19 * ukleinek forgot what we said about a debug flavor. Did we consider that a good idea?
21:00:32 <KGB> 03linux 05debian/latest 06Bastian Blank * [update] merge request !1615: Support for drivers in Rust * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1615
21:00:59 <bwh> waldi: Thank you!
21:01:15 <bwh> Then I think I can rebase and merge that one now?
21:01:18 <waldi> ukleinek: it makes sense, but IMHO we need to wait until we can get rid of the extra -cloud build
21:01:29 <carnil> ukleinek: maybe we should put that on the agenda topic as separate item to have a proper look?
21:02:06 <waldi> bwh: i would like to check again. i can then merge it
21:02:20 <bwh> waldi: OK
21:02:20 <ukleinek> if waldi has a strong opinion on the debug kernel, that's fine for me
21:02:38 <waldi> ukleinek: it's more the extra build time and most important space
21:02:53 <waldi> we break buildds
21:03:06 <ukleinek> IIRC I had doubts about its usefulness
21:04:05 <carnil> and some concerns about beeing clear to users that it's not used by default. But IIRC this was clarified how we can deal with it.
21:05:08 <carnil> ok but I guess most MRs are ongoing yet, and thanks bwh and waldi for the "support for drivers in rust" one
21:05:19 <carnil> anything else on the MRs?
21:05:24 <bwh> not from me
21:05:29 <waldi> not from me
21:05:32 <carnil> #topic AoB
21:05:46 * ukleinek still has 1337 on his list, but is stuck in contacting MediaTek
21:05:52 <bwh> My turn to chair?
21:06:26 <carnil> I hear no objections
21:06:32 <bwh> :-)
21:06:41 * ukleinek was about to ask the same, but it seems its my turn in two weeks then.
21:06:51 <carnil> thank you bwh!
21:07:04 <carnil> so I think we can conclude the meeting
21:07:10 <bwh> Thanks carnil
21:07:13 <carnil> #endmeeting