20:00:20 <bwh> #startmeeting
20:00:20 <MeetBot> Meeting started Wed Feb 25 20:00:20 2026 UTC.  The chair is bwh. Information about MeetBot at https://wiki.debian.org/MeetBot.
20:00:20 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:20 <carnil> hi
20:01:20 <bwh> waldi: Are you here?
20:01:21 * ukleinek is not aware of anything to discuss before the regular agenda
20:01:36 <waldi> yes
20:01:37 <carnil> I only had one question ,but it only make sense if waldi is here
20:01:49 <waldi> hi
20:01:53 <waldi> 6.19?
20:02:03 <carnil> no it was about build-arm64
20:02:25 <bwh> Go on
20:02:54 <carnil> because of our salsa pipieline failure I was earlier today asking in #salsaci on the status of build-arm64, santiago said that he talked to Bastian and Alex about providing shared runner for arm64.
20:03:14 <carnil> unfortunately he cannot attend todays meeting, so I try to formulate the question
20:03:59 <carnil> is there still something we plan to do on google(?) cloud infrastructure, or has this become more complicated and should we disable the build-arm64 build job for now?
20:04:06 <waldi> there where a lot of talk. right now the salsa people need to finish the runner setup upgrade
20:04:21 <waldi> just build it on a amd64 root
20:04:39 <waldi> (rustc is still broken, and maybe some python thing, but well)
20:05:12 <waldi> after the new runner setup is in place, salsa can expand to provide arm64 build systems
20:05:25 <bwh> Should we disable build-arm64 by default until that is done?
20:05:52 <waldi> or you fix it to not care about the architecture of the underlying system
20:06:39 <bwh> That sounds like a fair amount of work
20:07:01 <waldi> it isn't, really. maybe sbuild is not suitable for the job, but otherwise that's easy
20:07:26 <bwh> OK, but until that is done, would it make sense to disable build-arm64 so we don't have spurious failures due to lack of a runner?
20:07:31 <waldi> yes
20:07:45 <carnil> ok!
20:08:51 <bwh> carnil: Are you OK with making that config change?
20:09:13 <carnil> bwh: ok then I look into making this config change
20:09:49 <ukleinek> #action carnil disables the build-arm64 job to work around ci failures
20:10:12 <bwh> Any other urgent issues, before the bug list?
20:10:32 <ukleinek> idk
20:10:38 <waldi> 6.19?
20:11:08 <carnil> you want to move 6.19.y to unstable I guess you mean by that
20:11:21 <waldi> yes. sorry
20:11:29 <carnil> there is currently 6.19.4 in review, with a huge batch of commits (because the merge window)
20:12:02 <carnil> not sure if we want to do only after 6.19.4, so with 6.19.5 or so the switch?
20:12:25 <carnil> but I have not a strong opinion, 6.18.y would be a LTS branch so perfectly suitable to keep a bit longer in unstable if we think it helps
20:12:49 <carnil> I have some weak arguments maybe to keep another bit so, but then we are blocked for 7.0-rcX to experimental
20:12:54 <ukleinek> +1 for no strong opinion
20:12:56 <waldi> i don't think it helps us really
20:13:31 <waldi> okay, lets wait for .5 or so
20:13:33 <carnil> if you want to move it to unstable soon (i.e. right now, then let me please do the last 6.18.y upload as prepared)
20:15:01 <waldi> i have no hard feeling, just want to know a plan. because i don't want to do some changes right now
20:15:13 <ukleinek> that looks decided then and we dive into the bugs?
20:15:18 <waldi> yep
20:15:19 <bwh> #agreed unstable will get at least one more 6.18.y upload
20:15:35 <bwh> #agreed 6.19 should go into unstable starting with 6.19.5
20:15:46 <carnil> I will upload 6.18.13-1 tonight or tomorrow
20:15:58 <bwh> #topic #1127635: (i, M) linux-image-6.18.9+deb14-powerpc64: fails to boot on IBM 8204-E8A (POWER6 p550) LPAR, NULL deref in PCI MSI setup
20:16:30 <ukleinek> that's a wait
20:16:33 <bwh> No update in the last few hours, so this one is still waiting for moreinfo
20:16:40 <bwh> #topic #1128396: (i, uM) linux-image-6.12.69+deb13-amd64: Black screen on boot with Intel Meteor Lake xe driver (PCI ID 7d55)
20:17:21 <bwh> We got some logs but I think are still waiting on a bisection
20:17:42 <carnil> should we ask again for the bisection?
20:17:42 <ukleinek> ..ooOO(The reporter could install iwconfig ... :-)
20:17:59 <bwh> carnil: That might be worth doing
20:18:04 <carnil> (the last mail I got privately I did forward, none other since then)
20:18:19 <carnil> #action carnil ask again for bisection for #1128396 issue
20:18:24 <bwh> ukleinek: Or remove whatever ancient program wants iwconfig
20:18:32 <carnil> bwh: I will ask again for the bisection then
20:18:35 <bwh> #topic #1128632: (i, ) linux-image-6.12.73+deb13-amd64: boot failures, ACPI errors, and sleep issues on ASUS Sabertooth Z77 (i7-3770K)
20:19:56 <bwh> This has some logs but I think we need kernel boot logs for both the old and new versions
20:20:09 <ukleinek> "Failed to decompress kernel" is strange, I only know that from RAM problems, but given that earlier kernels are stable that is not likely
20:20:21 <bwh> Yes that's very puzzling
20:21:01 <ukleinek> the ACPI errors are probably not relevant
20:21:06 <bwh> and "git log v6.12.69..v6.12.73 drivers/firmware/efi/ arch/x86/boot/" shows nothing
20:21:22 <bwh> ukleinek: Yes that's why I think we need kernel logs from both to compare
20:22:08 <bwh> #action bwh will ask for kernel boot logs for #1128632
20:22:19 <ukleinek> 👍
20:22:29 <bwh> #topic #1121192: (n, M) kworker: Events_unbound, kworker processes, continually using CPU.
20:24:06 <bwh> I still have an action from last week to respond to this
20:24:08 <ukleinek> the 3 kworker processes are probably a red herring, other than that no idea.
20:24:50 <waldi> so nouveau uses kworker, the proprietary driver does not
20:25:27 <carnil> maybe stupid question, but the performance impating issues the user is seeing go away using the proprietary nvidia driver, but are present using nouveau
20:25:34 <bwh> Well, nouveau with missing firmware. I'm not sure how that even works at all
20:25:46 <bwh> carnil: That is my reading, yes
20:26:29 <waldi> we don't even have a tu117 firmware in unstable if i checked that correctly
20:26:29 <ukleinek> is nouveaudrmfb a fallback mode?
20:26:33 <waldi> no
20:27:00 <carnil> so maybe the user can test as well newer kernels from backports, or ideally even 6.19.3 in experimental and see if things are more smooth
20:27:12 <carnil> bu reading the above, if we have firmware missing then this suggestion as well is moot
20:28:40 <bwh> We do appear to have that firmware in current firmware-nvidia-graphics
20:29:48 <ukleinek> with the firmware files the kernel locks up, that's why they are not installed.
20:29:55 <bwh> However, firmware-nvidia-graphics doesn't trigger update-initramfs, which it should
20:30:56 <bwh> So, we have at least 2 bugs here: nouveau locks up with firmware present, and firmware-nvidia-graphics doesn't trigger update-initramfs
20:31:30 <ukleinek> +1 for letting him try backports and/or 6.19
20:31:33 <bwh> #action bwh will fix firmware-nvidia-graphics to trigger update-initramfs
20:32:16 <bwh> #action bwh will ask reporter of #1121192 to test with nouveau *and* firmware installed, on newer kernel versions
20:32:34 <bwh> #topic #1126957: (n, u) kernel panic when repeatedly trying to mount an nfsv4 share with mtls and failing
20:33:24 <bwh> This is waiting on a response from upstream, so nothing to do on our side I think?
20:33:42 <carnil> unless someone feels I have done something wrong in my testing
20:33:55 <carnil> but the ktls-utils autopkgtest was very helpful to get it reproduced as reported upstream
20:34:00 <carnil> but from there no idea
20:34:10 <carnil> so wait yes for upstream
20:34:15 * ukleinek didn't check what carnil did, so no feeling he did something wrong :-)
20:34:30 <bwh> #topic #1127612: (n, u+) linux-image-6.12.69+deb13-amd64: hp_bioscfg mm/page_alloc.c:4802 warning
20:34:42 <ukleinek> patch in the making upstream
20:35:33 <carnil> ah very nice, and it has all we need to not miss it:
20:35:40 <ukleinek> The patch author even forwarded the reporters tested-by
20:35:49 <carnil> Cc: stable@vger.kernel.org and Closes: https://bugs.debian.org/1127612
20:36:03 <bwh> I'm worried that there is a kfree somewhere that should now be kvfree
20:37:01 <bwh> Unless kfree somehow automatically forwards to vfree now??
20:37:32 <waldi> yes, it is kfree
20:37:39 <waldi> in hp_exit_enumeration_attributes
20:38:31 <ukleinek> kfree forwarding to vfree would be news to me
20:38:35 <bwh> right, and I see no sign that kfree is now equivalent to kvfree
20:38:44 <bwh> #action bwh will reply to patch for #1127612
20:38:56 <ukleinek> bwh: good catch
20:39:15 <bwh> Easier to spot in  a very small patch :-)
20:39:21 <bwh> #topic #1127688: (n, M) linux-image-6.18.9+deb14-amd64: Crash to black screen with QR code to log
20:39:56 <bwh> This is waiting for moreinfo
20:40:03 * ukleinek nods
20:40:10 <waldi> non-canonical address. broken memory?
20:40:28 <waldi> ah, yes
20:40:29 <ukleinek> waldi: that's why I asked for memtest
20:40:36 <bwh> #topic #1128397: (n, Mu) linux-image-6.18.10+deb14-amd64: open(/proc/$pid/maps) is empty after $pid exec()s, unless you read a partial line from the fd before, in which case it has the rest of the line only
20:40:47 <waldi> wow
20:41:00 <bwh> I updated this just before the meeting. Not convinced this is a bug at all
20:41:31 <waldi> no, i don is no bug
20:41:53 <waldi> no, i don't think this can count as bug. /proc is weird, but correct in this case
20:41:58 <bwh> #topic #1128626: (n, u) btusb: add 2c4e:0115 (Mercusys MA530, RTL8761BU)
20:42:45 <carnil> there were multiple attempts to submit a patch upstream and none was picked
20:42:49 <bwh> There is an upstream patch, not yet applied I think?
20:42:55 <bwh> OK
20:43:09 <bwh> So we can wait for that to happen
20:43:20 <bwh> #topic #1128834: (n, u) linux-image-6.1.0-43-amd64: NFS client regression in 6.1.162: large rsize/wsize (1MB) causes EIO
20:43:25 <carnil> yes see the list of forwarded references, all got postings to upstream
20:44:12 <carnil> oh I guess I should say something here and you are waiting on my input.
20:44:35 <carnil> The problem is only reproducible with NFS server from EMC Dell
20:44:41 <bwh> Right
20:45:02 <bwh> Maybe that deserves some kind of workaround in the kernel, I don't know
20:45:19 <carnil> does this count as we still should forward the issue? I think the reporter is right that the problem is more on the Powerscale OneFS NFs server side and they should handle it
20:45:44 <carnil> maybe forward this as a question to linux-nfs and see what the experts there think
20:45:50 <bwh> Right, I agree with that
20:46:08 <carnil> I take a (low prio) action on that and make sure the question goes to linux-nfs
20:46:19 <bwh> Thanks
20:46:38 <carnil> #action carnil follows up for #1128834 with linux-nfs to see if a workaround needs/should be implemented on kernel side
20:46:41 <ukleinek> "brilliant tutorial!"
20:46:50 <bwh> #topic #1128861: (n, ) linux: when serving NFS, client attempts to lock served files fail with "No locks available"
20:46:51 <carnil> ukleinek: I referred that it comes from you
20:47:09 <ukleinek> \o/
20:47:58 <bwh> I think this is waiting on a response from upstream
20:48:13 * carnil nods
20:48:21 <ukleinek> iam_tj[m]: thanks for working on that
20:48:37 <bwh> #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 (merged with #1128422)
20:49:17 <bwh> I discussed this with carnil and I think we agreed this should be reverted for trixie-backports only
20:49:31 <bwh> I still have an action to document the change in NEWS and release-notes
20:49:40 * carnil nods
20:49:50 <ukleinek> can a v4 fs easily be upgraded to v5?
20:49:54 <carnil> no
20:50:00 <bwh> #action bwh will reenable CONFIG_XFS_SUPPORT_V4 for trixie-backports
20:50:10 <ukleinek> (that is something to mention in the NEWS entry?)
20:50:11 <carnil> ukleinek: full backup, restore cycle
20:50:17 <bwh> ukleinek: yes
20:50:47 <bwh> #topic #1124400: (n, u) update-initramfs no longer includes /lib/modules/<kver>/updates directory
20:51:31 <bwh> This was rejected upstream. We might need to carry a patch for it so switching initramfs-tools -> dracut doesn't regress.
20:51:59 <bwh> Oh, wait, this is in dracut-install so both are affected
20:52:19 <carnil> is there a reasoning from upstream about the 'not planned'?
20:52:34 <bwh> There is some more discussion on the linked pull request
20:52:55 <carnil> ah found it in the related pull request
20:52:56 <carnil> thanks
20:53:35 <bwh> #action bwh will discuss #1124400 with bdrung etc.
20:53:58 <bwh> #topic #1128969: (n, +) dracut: autopkgtests fail on arm64
20:55:03 <bwh> I didn't look into this so I don't have any opinion on whether it's a good change
20:56:03 <bwh> I'm happy to leave this for bdrung to respond to
20:56:13 <carnil> sounds good
20:56:21 <bwh> #topic #1128598: (n, Uu) rtl8852bu: bluetooth audio suttering at random
20:56:40 <ukleinek> if it were me, I'd find a qemu guy to explain cpu=max
20:56:42 <bwh> firmware-nonfree is outdated in trixie-backports and I should fix that
20:57:06 <bwh> #action bwh will update firmware-nonfree in trixie-backports
20:57:31 <bwh> which I think would fix this bug but I'm not certain if the version is testing is new enough
20:57:48 <bwh> #topic #1064620: (w, +) firmware-nonfree: suggestions for the packaging, gencontrol.py and debian/rules
20:58:13 <bwh> This originally had far too many patches for me to properly review
20:58:27 <ukleinek> let's ask the guy to create a MR instead of a patch list in a bug?
20:58:52 <bwh> I might do that. From a quick look earlier I think what's left there is reasonable
20:59:07 <bwh> #action bwh will review #1064620 and possibly ask to create an MR
20:59:18 <bwh> #topic #1128562: (m, ) /usr/bin/linux-check-removal: Use of uninitialized value $_[2] in join or string at /usr/share/perl5/Debconf/Client/ConfModule.pm line 122.
20:59:37 <ukleinek> bwh: it seems you have all the actions today, you wanna share a bit?
20:59:59 <bwh> OK
21:00:15 <bwh> I don't think I took many last week, and I am trying to move things along
21:00:48 <bwh> but, if you want to take over a specific action...
21:01:16 <ukleinek> bwh: I don't feel competent for many things, but I can look over your list once meetbot created it and take some of them.
21:01:25 <bwh> OK, thanks
21:02:50 <bwh> It seems like this bug report comes from using linux-check-removal, which wants to use debconf, without a debconf front-end
21:03:07 <ukleinek> TIL linux-base provides linux-check-removal
21:03:37 <bwh> I reduced severity but I think this should either be wontfix or result in a documentation change
21:04:16 <bwh> Anyone else want to investigate this one?
21:04:39 * ukleinek wonders if this should better be located in /usr/lib/linux-base or similar instead of /usr/bin
21:04:59 <bwh> Oh, maybe
21:05:05 <bwh> but it's a bit late for that now
21:05:12 * ukleinek nods
21:05:35 <bwh> #action bwh will investigate #1128562
21:05:37 <carnil_> sorry joining from alternative location, once again flaky/unreliable network
21:05:50 <bwh> #topic Migration excuses
21:06:01 * ukleinek thinks #1128562 won't be among the bugs he can reasonably work on
21:06:29 <bwh> hexagon-dsp-binaries is now updated in unstable, but no binary packages have been built so firmware-nonfree is still blocked
21:07:07 <bwh> I opened #1129001 for that
21:07:30 <bwh> Anything else to discuss on this topic?
21:07:49 <waldi> no
21:08:00 <carnil_> no
21:08:06 <bwh> #topic New upstream versions
21:08:40 <bwh> I'm not sure why the experimental version is shown there for linux
21:09:28 <bwh> We already discussed linux, which leaves firmware-nonfree needing an update
21:10:29 <bwh> Well I will probably get around to that, but will not promise it on top of my other actions
21:10:36 <bwh> #topic Merge requests
21:11:22 <bwh> Do any of these need discussion?
21:11:49 <bwh> I'll assume not
21:11:52 <bwh> #topic AOB
21:11:53 <carnil> no
21:11:55 <ukleinek> the ci backport should be done soon?!
21:12:03 <carnil> yes I do
21:12:03 <bwh> yes
21:12:36 <carnil> done already for debian/6.18/forky, picking them "soon" for debian/6.12/trixie and debian/6.1/bookworm
21:12:44 <ukleinek> I started to look into the tracefs mount location and affected packages. Was too complicated for my available time then
21:12:47 <carnil> bwh: has already cherry-picked for debian/5.10/bullseye-security afaics
21:13:11 <bwh> For bookworm I expect there will probably be a conflict, but you should be able to follow my resolution for bullseye
21:13:51 <bwh> OK, so who will chair next week?
21:14:26 <ukleinek> it's jitsi, so I can do it unless someone else wants to
21:14:29 <waldi> i would prefer to not chair, i'm still a bit unstable
21:14:59 <carnil> ukleinek: would be appreciated, can half-promise to be able to pick then the next one
21:15:12 <ukleinek> #action ukleinek will chair next week
21:15:23 <bwh> OK, anything else before I close the meeting?
21:15:50 <waldi> not from me
21:15:50 <ukleinek> not from my side
21:15:51 <carnil> not from my side
21:15:57 <bwh> Thanks all!
21:15:59 <bwh> #endmeeting