20:00:01 <carnil> #startmeeting
20:00:01 <MeetBot> Meeting started Wed Feb 11 20:00:01 2026 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:06 <ukleinek> o/
20:00:07 <carnil> hi all
20:00:26 <carnil> #chair bwh carnil ukleinek
20:00:26 <MeetBot> Current chairs: bwh carnil ukleinek
20:01:27 <carnil> I have assembled the recent bugs in the agenda as usual, is htere anything we need to talk beforehand going to the bug list?
20:01:43 <ukleinek> nothing from my side
20:02:11 <bwh> Hello
20:02:19 <carnil> hi Ben
20:02:44 <bwh> Nothing urgent from me
20:02:48 <carnil> okay then let's move to the buglist
20:03:06 <carnil> #topic #1126671: (S, ) linux-image-6.17.13+deb13-amd64: Disconect root (path=/) during heavy load on NvME, partial corruption on NTFS.crash soon but not yet
20:03:36 <ukleinek> agree that's a wait for reporter
20:03:41 <carnil> I had an action last time here to followup, which I did but only recently. Gave instructions to gather more information via netconsole, so I think we now have to wait
20:03:55 <carnil> #topic #1127597: (S, uM) linux-image-6.12.48+deb13-amd64: GRE6 decap fails (merged with #1127599)
20:04:33 <carnil> I believe this one is now in good hands. Tj did with reporters a debugging session isolating the breaking commit, there is an upstream thread as well and Greg plans to queue the fix for the next round of updates
20:04:49 <ukleinek> sounds good
20:05:38 <bwh> Yay, an API change that causes silent breakage
20:05:46 <carnil> action for me at least: decide on when to release the next update again via a DSA to fix this regression (but likely at least move as well to 6.12.70 and 6.1.163 + fixes). I have not checked if this affects as well 5.10.249-1?
20:06:10 <bwh> I think it may...
20:06:29 <carnil> it is bit frustrating that on each update you can expect at least a regression with some major impact :( but I think we have to deal with it. TEsting all possible scenarios is impossible.
20:06:44 <bwh> Yes same breakign commit is in 5.10.249
20:07:06 <carnil> okay, should we add this as found version for 5.10.249-1 in the BTS?
20:07:17 <ukleinek> re "API change that causes silent breakage": Well, only affects incomplete backports, that's not user visible
20:07:29 <bwh> carnil: Yes but the BTS never sees that
20:07:41 <bwh> ukleinek: It is in a static inline function exposed to OOT modules
20:08:00 <ukleinek> ..ooOO(yeah, but OOT modules)
20:08:32 <bwh> There is no stable kernel API for OOT modules, *but* API changes are supposed to be made in such a way that unconverted modules fail to build
20:09:00 <bwh> for example that function could have been renamed when the meaning of its return value was changed
20:09:10 <ukleinek> bwh: yeah, no promise is to be made, but with a bit of thought the procedure can be improved.
20:09:34 <bwh> (and that would also make such incomplete backports less likely)
20:11:02 <bwh> anyway, the API change happened a while back upstream, so the damage is done
20:11:13 <carnil> as we have seen ;-)
20:11:35 <carnil> okay to move to the next item, I think this is in hands now on the various fronts
20:11:57 <carnil> I just have added founds versions on 6.1.162-1 (I though I did already but apparently not) and 5.10.249-1
20:12:42 <carnil> I interpret the silence as yes
20:12:48 <carnil> #topic #948243: (i, ) linux-image-5.4.0-1-amd64: Fails to boot into graphical mode on Radeon RX 5700 XT, amdgpu: [powerplay] failed send message
20:12:57 * ukleinek doesn't say anything to not change carnil's interpretation
20:13:08 <carnil> this is actually an old bug but only recently someone pinged the bug.
20:13:30 <carnil> I'm uncertain: is the problem really related or should we rather ask the second reporter to fill a new bug?
20:13:51 <bwh> I think they should make a new bug report if they are seeing the bug, and the original report should be closed
20:13:55 <ukleinek> This is about an external amdgpu driver?
20:14:22 <bwh> What makes you think that?
20:14:54 <ukleinek> The gitlab.fd.o has: AMD official driver version: amdgpu-dkms 1:6.16.13.30300000-2278356.24.04
20:15:53 <carnil> so for reference we are talking about the mention of https://gitlab.freedesktop.org/drm/amd/-/issues/3659#note_3324746
20:15:59 <bwh> right
20:16:53 <ukleinek> we could offer reaching out to us if Quazgar needs help for bisection
20:16:59 <bwh> yes and reportbug shows amdgpu(OE)
20:18:02 <bwh> so we have one reporter who didn't respond and another who's using the OOT driver, so I don't think we need any open bug reports...?
20:18:16 <ukleinek> The version suggests that the dkms package contains a backport from mainline 6.16.13?
20:18:28 <carnil> so ignore the followup or respond that we think that they are unrelated problems
20:19:21 <ukleinek> the latter
20:19:34 <bwh> If you want to respond, say it's probably unrelated and also amdgpu-dkms does not come from us => not our bug
20:19:47 <carnil> I will respond something along the above lines
20:20:11 <carnil> #action carnil gives feedback on unrelated problem for #948243 followup
20:20:18 <carnil> #topic #1113861: (i, uM) linux-image-6.12.41+deb13-amd64: Most Flatpaks don't launch, cause kernel oops in nouveau module
20:20:25 <ukleinek> and if they want a newer amdgpu and amdgpu-dkms is just the driver from a newer mainline version, they could try a backport kernel
20:20:39 <carnil> as reminder this was folowed up by another reporter which was able to reproduce the problem without flatpak
20:21:08 <bwh> Nothing changed since last week. I think someone took an action then
20:21:12 <carnil> waldi took last time an action, I guess it fine to keep that, but I can ask him off-meeting later if someone else should look into it
20:21:16 <carnil> so nothing to do for now
20:21:21 * ukleinek nods
20:21:53 <carnil> bwh: yes waldi aimed to look into the details, I think we can keep this if he finds time in the next weeks for it
20:22:05 <carnil> #topic #1126090: (i, u) linux-image-6.12.57+deb12-amd64: Firewire-ohci module crashes
20:22:24 <carnil> two news: upstream responded and asked/gave some instructions for further debugging
20:22:29 <ukleinek> wait on reporter
20:22:33 <carnil> and Tj suggested to install latest firmware first
20:22:42 <carnil> so in both cases we can wait for the repoter to followup
20:22:55 <carnil> #topic #1126149: (i, u) linux: usb enumeration fails with error -32 for Krom Kreator keyboard
20:23:21 <carnil> The tentative patch was without success, so removed the patch tag again.
20:23:39 <carnil> In meanwhile I wonder if this could indicate some HW issues as the keyboard works on other hardware
20:24:00 <carnil> I'm out of ideas and am usure the information is in a stage where we can forward something
20:24:07 <ukleinek> These USB messages usually mean flaky hardware. (Cable, device or controller)
20:24:08 <carnil> any ideas on how to proceed on this?
20:25:06 <ukleinek> hmm, it does work on the same hardware in windows and the bios
20:25:53 <ukleinek> unplugging all other usb devices, and using (or not using) a hub might help (but not enlighten us so much)
20:26:19 <bwh> Just grepping for -32 in the log of quirks.c shows some other quirk flags that may be useful
20:26:42 <bwh> I'm trying to remember if there's a way to add quirks without rebuilding the kernel...
20:27:49 <ukleinek> ..ooOO(Vicboom18 doesn't know about reply-to-all in their MUA)
20:27:52 <carnil> usbhid has:
20:27:53 <carnil> parm:           quirks:Add/modify USB HID quirks by specifying  quirks=vendorID:productID:quirks where vendorID, productID, and quirks are all in 0x-prefixed hex (array of charp)
20:28:14 <bwh> and there's usbcore.quirks for USB-level quirks
20:28:14 <carnil> would that help?
20:28:42 <carnil> ukleinek: yes the reporter wrote me always privately, that was tedious
20:29:55 <bwh> carnil: I think a USB-level quirk is required since I don't think the HID driver is even looking at the device
20:29:59 <carnil> bwh: so we might ask the reporter to test further used from the grepping of commit logs in quirks.c to see if any has a positive effect?
20:30:06 <carnil> ah right
20:30:14 <bwh> Right. I can take an action to do that
20:30:21 <carnil> bwh: thank you!
20:30:57 <bwh> #action bwh will suggest trying other USB quirks to fix #1126149
20:31:04 <ukleinek> bwh: if you need a form-letter link, I always use https://people.kernel.org/tglx/notes-about-netiquette  :-D
20:31:12 <carnil> ah good you were faster :)
20:31:33 <carnil> #topic #1127635: (i, ) linux-image-6.18.9+deb14-powerpc64: fails to boot on IBM 8204-E8A (POWER6 p550) LPAR, NULL deref in PCI MSI setup
20:31:57 <carnil> as I understand this is powerpc specific, should we involve the porters?
20:32:29 <ukleinek> it hangs in the initramfs I think?
20:32:29 <bwh> yes
20:33:10 <ukleinek> the kernel log contains a null pointer exception
20:33:38 <ukleinek> #action ukleinek looks into #1127635, falling back to forwarding to the powerpc porters
20:33:48 <carnil> thanks ukleinek
20:33:59 <carnil> #topic #1127659: (i, u) linux-image-6.12.69+deb13-rt-amd64: chrony 4.6.1 cannot configure extpps for PHC refclocks due to new permission check
20:34:31 <carnil> bwh commented today, upstream might not want to consider reverting it as it is a security fix (afaik no CVE was yet assigned from kernel CNA)
20:34:44 <carnil> so the fix should probably go in all affected suites into chrony
20:35:00 <carnil> questions:
20:35:02 <bwh> That was my thinking - previously write-like ioctl()s did not require write permission
20:35:17 <carnil> - is the fix easily backportable to older versions?
20:35:22 <ukleinek> should we revert for a while?
20:35:40 <carnil> - should we reassign the bug to chrony (updating metadata) and help getting that in
20:35:41 <ukleinek> I didn't check, but I assume it's just s/O_RDONLY/O_RDWR/
20:35:52 <bwh> It's a bit more extensive than that
20:36:16 <bwh> because it actually becomes conditional
20:36:31 <carnil> ukleinek: I would rather prefer not if upstream does not plan as well to revert temporarily in stable series branches, but that is a bit my exagerated view on following the stable series
20:37:34 <ukleinek> I see it as a service to our users to not break chrony until it is fixed in a point release.
20:37:35 <carnil> but I wonder if upstream might consider reverting it temporarily as well with considering the report from Jan Luebbe
20:37:59 <bwh> ukleinek: Well, in principle we can fix it through -updates
20:38:15 <carnil> ukleinek: there is as well stable updates which can issue updates before a point release, my thinking was: if it can go in point relesee, ask for srm as well to issue a SUA for it
20:38:27 <bwh> We should discuss with SRM, I think
20:39:04 <ukleinek> according to https://lore.kernel.org/all/CAHk-=wheQNiW_WtHGO7bKkT7Uib-p+ai2JP9M+z+FYcZ6CAxYA@mail.gmail.com/ that commit should be reverted
20:40:14 <bwh> I know but security fixes have always been an exception
20:40:15 <ukleinek> +1 for SRM and keeping an eye on upstream
20:41:28 <carnil> I will take an action to keep an eye on how this evolves, try to have a look at backporting the crhony fix to trixie, possibly already bookworm, and approach SRM for discussion, will take bit of time though
20:41:34 <ukleinek> ... and a bug for chrony. (Don't care if we reassign, or clone and reassign)
20:41:42 <carnil> s/I will/I can/ if there are no objections
20:42:07 * ukleinek never objects if someone else volunteers to do the things we agreed on :-D
20:42:30 * ukleinek also doesn't object the s///
20:42:49 <carnil> #action carnil takes care of following #1127659 (keep an eye on upstream decision on the report, consider backports for chrony and approach SRM for bugfixes in trixie and bookworm)
20:43:07 <carnil> time moves fast :(
20:43:16 <bwh> carnil: FWIW the upstream patch does not apply cleanly even to trixie's chrony
20:43:16 <carnil> #topic 1120831: (n, u+) linux: failed command: READ FPDMA QUEUED after boot
20:43:25 <carnil> bwh: arg :(
20:43:32 <carnil> bad
20:44:05 <carnil> so this will require maybe non-negligible work on backporting?
20:44:34 <carnil> #topic #1120831: (n, u+) linux: failed command: READ FPDMA QUEUED after boot
20:44:57 <ukleinek> carnil: I think Jan might be able to help with the backport
20:45:28 <bwh> What the reporter is saying doesn't make a lot of sense...
20:45:49 <carnil> there is some confusion on #1120831, the fix has defintively not yet landed, so I wonder how the problem get fixed for the reporter
20:46:06 <carnil> are the udev rules not included in the initramfs?
20:46:09 <bwh> I think there is some unpredictable factor that triggers the bug. Pretty sure it's not "rebuilding the initramfs"
20:46:25 <bwh> Oh, yeah they are. So that *would* explain it
20:46:33 <carnil> if so I think the user might have build initramfs with the udev added but removed it later from system, and now get incosistent reporting back
20:47:18 <carnil> I intent to keep the bug open until the upstream fix really lands and then close it with that update
20:47:21 <bwh> right
20:47:27 * ukleinek nods
20:47:45 <carnil> but so we can followup to the reporter explaining that the udev rule is likely in the rebuild initramfs and he can check with lsinitramfs
20:48:01 <carnil> #topic #1121192: (n, M) kworker: Events_unbound, kworker processes, continually using CPU.
20:48:10 <carnil> bwh: asked some questions -> wait?
20:48:14 <bwh> yes
20:48:18 * ukleinek nods again
20:48:27 <carnil> #topic #1126499: (n, u) linux-image-6.17.13+deb14-amd64: ovpn NULL pointer dereference and lockup under heavy load
20:48:52 <carnil> we are still waiting the fix to land in mainline. Asked the reporter to make an explicit test with the prooposed patch so a Tested-by can be added
20:49:00 <carnil> -> wait
20:49:11 <carnil> #topic #1126911: (n, ) linux-image-6.12.63+deb13-amd64: wacom_serial4 doesn't work. Probe fails with error -1.
20:49:13 <ukleinek> maybe offer a .deb?
20:49:23 <bwh> I don't think you explicitly asked them to test the patch...?
20:50:23 <carnil> bwh: oh well yes I was meaning it as Jon is included in the conversation but you are right I should ask more explicitly
20:50:29 <carnil> will do so it is clear
20:50:30 <carnil> sorry
20:50:47 <ukleinek> ..ooOO(No need to be sorry)
20:51:07 <carnil> on #1126911, ben can we keep the action on you?
20:51:11 <bwh> yes
20:51:52 <carnil> #action bwh will ask questions on #1126911 (comment from previous meeting: Driver strange as .probe() returns -1 instead of an error code.)
20:52:08 <carnil> #topic #1126957: (n, u) kernel panic when repeatedly trying to mount an nfsv4 share with mtls and failing
20:52:22 <carnil> this is a new report, ktls is involved
20:53:19 <carnil> I aimed late last week to build a test environment as I will be intersted in using ktls in future, but I failed, so from me no insight in this yet.
20:53:37 <bwh> You failed to make it work, or you failed to make it crash?
20:53:41 <ukleinek> carnil: is it clear to you how to reproduce? You failed because ENOTIME, or you tried and didn't see the failure?
20:53:49 <carnil> bwh: no I failed to find time to make a proper test setup
20:54:17 <bwh> There is an autopkgtest test case in ktls-utils
20:54:54 <carnil> ukleinek, bwh  for clarity: I failed because in the end ENOTIME
20:55:03 <bwh> OK
20:55:20 <bwh> As the person who has seen this wroking, let me take the action
20:55:25 <carnil> so if someone wants to already progress on it, just take an action. I'm still intersted into looking at least later in ktls setups.
20:55:31 <carnil> bwh: perfect :)
20:55:39 <bwh> #action bwh will try to reproduce #1126957 and update the bug
20:55:57 <ukleinek> ..ooOO(bwh has seen this wracking?)
20:56:11 <carnil> are you okay if we do the last 3 linux bugs or do you want to skip given the time?
20:56:23 <ukleinek> ok for me
20:56:28 <bwh> OK
20:56:40 <carnil> #topic #1127588: (n, ) linux-image-6.18.9+deb14-amd64: Cannot hibernate after some time of work
20:57:19 <carnil> new report, have not looked at the details
20:57:36 <carnil> (altough is is relatively brief/short on those)
20:57:38 <bwh> So I think it's reasonable that hibernation fails because there is not much swap available. But since swap didn't fill up before, then I think there's a memory leak.
20:57:53 <ukleinek> 2704661 pages is a lot?
20:59:10 <bwh> ~10 GiB? Yes it's quite a lot!
21:00:21 <ukleinek> Does that mean hibernate needs these 10 GiB more space than the available swap?
21:00:36 <bwh> I think that's what it means
21:00:37 <iam_tj[m]> Release is forky/sid and "APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable')" ... is that... usual?
21:01:01 <ukleinek> iam_tj[m]: that's the default if you have no pining and no default release
21:01:05 <iam_tj[m]> ukleinek:  Yes, that is what it means. It's not uncommon
21:01:44 <bwh> I suppose we should ask for information from /proc/slabs and /proc/meminfo to get some idea of where the memory is going
21:01:49 <ukleinek> ask for more xz and zstd? If there is a memory leak it will eventually crash?!
21:02:16 <iam_tj[m]> This would need some idea of the existing and terminated processes, uptime, and so on. There's not much free RAM either that suggests the system is/has been heavily taxed
21:02:18 <ukleinek> bwh: ah, if you can decode these, that's even better
21:03:38 <bwh> iam_tj[m]: Right, an obvious question would be whether those memory consuming programs have actually released any memory
21:04:18 <bwh> #action bwh will respond to #1127588 requesting info about memory usage
21:04:24 <iam_tj[m]> bwh: exactly what I was thinking
21:04:24 <carnil> thanks
21:04:44 <carnil> #topic #1127612: (n, u) linux-image-6.12.69+deb13-amd64: hp_bioscfg mm/page_alloc.c:4802 warning
21:05:21 <carnil> another regression from 6.12.63->6.12.69, I intent to help the reporter identifying the breaking commit
21:05:26 <carnil> and then check/report upstream
21:05:50 <ukleinek> sounds good
21:05:51 <carnil> alghough I think there is one commit mentioning hp_bioscfg
21:06:12 <carnil> so the first step would be to check to revert that commit
21:06:14 <bwh> The most recent commit is to make the driver auto-load
21:06:33 <bwh> So, most likely this driver was always broken but didn't load
21:06:58 <ukleinek> so the obvious test is to load it on 6.12.63 and/or blacklist on 6.12.69
21:07:05 <bwh> right
21:07:57 <ukleinek> #action ukleinek suggests a few tests for #1127612
21:08:19 <carnil> thanks ukleinek
21:08:30 <carnil> #topic #1126710: (w, ) linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set
21:08:41 <bwh> I think I have an action to write the text for this?
21:08:50 <carnil> action is/was on bwh only question: should we clone the bug and reassign it as well for release-notes?
21:08:54 <carnil> bwh: yes
21:09:22 <bwh> I can take care of the cloning as well
21:09:56 * ukleinek wanted to suggest a patch doing s/Depricated/Deprecated/ but it's only the reporter who got that wrong :-)
21:10:06 <carnil> #action bwh keeps the action to write the text for NEWS and release notes to address #1126710 (XFS V4 support removal)
21:10:20 <carnil> ukleinek: I'm full confident it will be right with bwh beeing a native speaker :)
21:10:39 <carnil> ok we are done with the linux bugs
21:11:11 <carnil> I propose to skip now, there is one firmware-nonfree bug about asking to support updates from *-backports
21:11:12 * ukleinek looks up "to bee"
21:11:49 <carnil> #topic Migration excuses
21:12:28 <carnil> when I looked up today the tracke there was as well a genext2fs autopkgtest regression mentioned for linux
21:14:21 <bwh> It's a weird one
21:14:32 <carnil> maybe should look at that tomorrow, because it would be good to have 6.18.9-1 migrating to testing
21:14:34 <ukleinek> the runs from today are green?!
21:15:09 <carnil> ukleinek: so it yet just the tracker not having updated the status, and the tests might be flaky?
21:15:36 <carnil> https://ci.debian.net/packages/g/genext2fs/testing/amd64/
21:16:04 <ukleinek> TIL this pages needs a login
21:16:20 <bwh> That's a recent change to reduce load from scrapers
21:16:31 <ukleinek> that's what I thought
21:16:51 <carnil> ukleinek: https://lists.debian.org/debian-devel-announce/2026/02/msg00001.html
21:17:13 <ukleinek> So we ignore the genext2fs failure and assume it will pass very soon?
21:17:39 <carnil> ok then linux should migrate tomorrow or the day after, the signed packages need one more day
21:17:44 <carnil> ok
21:18:18 <carnil> #topic new usptream versions
21:18:40 <carnil> a small note on nfs-utils: have not done the update as upstream has released a new version but not tagged in git, have asked back
21:19:13 <bwh> I just started on the wireless-regdb update
21:19:31 <ukleinek> and fireware-free isn't relevant as usual?
21:19:37 <carnil> bwh: thanks, IIRC that has the signing key from you embedded and needs to be done by you anyway righ? :)
21:19:48 <carnil> #topic Merge requests
21:19:55 <carnil> anything on MR's to discuss specifically?
21:20:11 <bwh> ukleinek: I should probably double-check that there isn't anything new that's free, but no I think it's not relevant
21:20:15 * ukleinek looked over a few arm64 ones, but not all yet. Intend to continue next week
21:20:32 <carnil> ukleinek: that is great, thank you
21:20:41 <bwh> No I still have an action to test out simpledrm and figure out a safe upgrade path
21:21:14 <carnil> bwh: if you additionally have some spare cycles and can review my https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/36 that would be great as well. But if you have not that is fine.
21:21:50 <carnil> #topic AoB
21:22:07 * ukleinek already announced last week that he can take the chair for next week
21:22:23 <carnil> #action ukleinek will chair next week team meeting
21:22:46 <carnil> perfect, I think we are done, and sorry it got that late, we overrun by almost 25min :-/
21:22:50 <carnil> did not expect that
21:23:04 <bwh> Well, I think we had more and trickier bugs
21:23:05 <carnil> #endmeeting