20:00:09 <carnil> #startmeeting
20:00:09 <MeetBot> Meeting started Wed Dec 17 20:00:09 2025 UTC.  The chair is carnil. Information about MeetBot at https://wiki.debian.org/MeetBot.
20:00:09 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:20 <carnil> #chair bwh ukleinek waldi
20:00:20 <MeetBot> Current chairs: bwh carnil ukleinek waldi
20:00:28 <carnil> hi welcome to todays kernel-team meeting
20:00:40 <bwh> Hi
20:00:49 <bdrung> hi
20:00:50 <carnil> Is there anything no yet on the agenda which you would like to discuss first?
20:00:53 <Mealman1551> Hi
20:01:06 <ukleinek> ..ooOO(/whois Mealman1551)
20:01:26 <bdrung> Is this meeting purely on IRC?
20:01:30 <carnil> otherwise I'm glad to see bdrung is here so I guess we can start with the topic we shifted last week
20:01:31 <ukleinek> bdrung: yes
20:01:35 <carnil> bdrung: yes this one is on IRC
20:01:47 <carnil> bdrung: we o alternate beween IRC and Jitsi
20:01:56 <Mealman1551> just a developer watching the conversation for some information
20:02:03 <carnil> s/o/do/
20:02:41 <ukleinek> carnil: nothing from my side to discuss
20:02:54 * carnil waits a couple of seconds
20:03:26 <carnil> #topic project: Switch from initramfs-tools to dracut as default initramfs generator
20:04:09 <ukleinek> there is a single blocking bug, i.e. flash-kernel not working with dracut. I intended to look into that, but didn't find much OSS time
20:04:16 <carnil> bdrung: so we wondered were we are right now at this project and what the next steps are to make the switch happen for forky, and bwh last time proposed that we talk about it.
20:04:55 <ukleinek> the bug about flash-kernel is #1115470
20:05:26 <bwh> Yes and the maintainer said that that functionality wasn't that important, so I don't think it needs to be a blocker
20:06:05 <bwh> So, are we ready to go ahead with the switch?
20:06:21 <ukleinek> I use it on my arm64 NAS (bootloader=barebox)
20:06:43 <bwh> You use flash-kernel, or you depend on the initramfs hook?
20:06:53 <ukleinek> I use flash-kernel
20:07:27 <bdrung> the flash-kernel package depends on initramfs-tools.
20:07:45 <ukleinek> and even if vagrantc thinks there is no work to do because arm64 does set root= correctly (right in my case) I cannot uninstall initramfs-tools
20:08:06 <bwh> OK, so we probably want to change that as well, but I  still don't think that's a blocker?
20:08:12 <bdrung> (i.e. flash-kernel declares the dependency)
20:08:12 <carnil> fwiw, I was not able to test the switch on each one box where the (admitelly maybe legacy approach) with yubikey-luks is used, and one other where dropbear-initramfs  is used. But I guess that should not be considered blocker scenarios
20:08:42 <ukleinek> carnil: notn able to test = didn't work?
20:08:50 <carnil> ukleinek: no lack of time
20:09:15 <ukleinek> ..ooOO(no; lack of time)
20:09:17 <carnil> i.e. not able to test = not able to find time to reproduce the setup and test if it can work with dracut instead of initramfs-tools
20:10:11 <carnil> but in particular for the later case I think there use case is frequently used
20:10:20 <ukleinek> bdrung: are there additional blockers you are aware of?
20:11:10 <ukleinek> I intend to work on the NAS on Friday, among others on dracut vs. flash-kernel
20:11:26 <bwh> As I see it, the other packages depending on initramfs-tools, that actually have a decleared dependency shouldn't be a blocker for us to change the default
20:11:43 <bwh> If there are packages that assume use of initramfs-tools by default, and don't have a declared dependency, that would be a problem
20:11:51 <ukleinek> then maybe someone should add support for dracut in the installer soon?
20:11:58 <bwh> yes that's also needed
20:12:02 <bwh> I'm happy to work on that
20:12:18 <bdrung> no. there are 77 packages shipping initramfs-tools hooks. users of those might not be able to switch easily (see https://discourse.ubuntu.com/t/spec-switch-to-dracut/54776 for a list) but that should not be a blocker.
20:12:48 <ukleinek> bdrung: do these packages depend on initramfs-tools?
20:14:01 <bdrung> ukleinek, probably not in most cases. in some cases dracut comes with support already (e.g. lvm2 or dmraid)
20:14:33 <bdrung> so shipping an initramfs-tools hook does not mean that it requires it.
20:14:47 <bwh> right
20:15:24 <ukleinek> maybe as a first step make dracut optional then (similar to systemd-boot being offered in the installer instead of grub)
20:15:51 <carnil> bdrung: for instance dropbear ther is dracut-support: no, not found in source, the not found in source means: someone who wants support for it needs to implement the feature first in dracut? sorry for aksing that again but would like to undestand what that means for those packages listed there while not beeing blockers what needs to be achieved to make them work with dracut. The support should be
20:15:57 <carnil> directly in src:dracut and not in separate drop ins?
20:16:24 <bwh> ukleinek: You mean, with a (low-priority) question for which to use?
20:16:44 <ukleinek> bwh: yes
20:17:23 <ukleinek> to at least make it possible to stick to initramfs if missing dracut supports becomes a blocker for a user
20:17:25 <bdrung> for supporting dracut there are two upstream blessed ways: 1. add support for the tool in the upstream dracut project or 2. add support for dracut to the project itself by shipping a dracut module there
20:19:26 <ukleinek> I wonder how much the list of packages in bdrung's link applies to Debian.
20:20:02 <bdrung> probably most of them since most hooks in Ubuntu come from Debian.
20:20:17 <ukleinek> dracut covers the usecase provided by yubikey-luks (though maybe through a different algorithm, I'm using fido to unlock my hd)
20:22:25 <ukleinek> I think Debian doesn't have jasper-initramfs, kubuntu-settings, ubuntukylin-theme, ubuntustudio-default-settings and probably a few more
20:22:35 <ukleinek> bdrung: how far is Ubuntu with the switch?
20:22:47 <carnil> so what are our next steps? (we have heard above adding installer support, maybe making the same list of packags shipping initramfs-tools hooks/integration, etc ...)
20:24:20 <bdrung> dracut is the default on the desktop in 24.10 and we work on making it the default on server as well (see https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2125790). the blocker on the server is src:cloud-initramfs-tools which looks like an Ubunutu invention.
20:25:00 <bwh> I think it's something like (1) Switch the order in the initramfs generator dependency (2) Move dracut under kernel-team maintenance (3) Update installer and other packages
20:25:23 <bwh> But the order doesn't matter that much I think, as long as we get this done within this release cycle
20:25:43 <bdrung> and (4) see what pulls in initramfs-tools after (1) and port those
20:27:59 <carnil> ok. I someone volunterring to take the lead to make thos steps happing and supervisioning it? And maybe we can have a little part of the team meetings with reports about this project?
20:29:01 <bwh> I won't have time to go through all the other packages but I should be able to deal with the installer
20:29:10 <carnil> I do not feel competent to be that person, so maybe lead should be bdrung, bdrung or ukleinek :) but I agree with Ben that it should start now to make it really happend in the release cycle and not too much toward the forky freeze
20:29:21 <ukleinek> (1) would be something like https://dpaste.com/AZYYE5UGW ?
20:29:39 * ukleinek votes for bdrung or bdrung :-)
20:30:03 * bdrung votes for ukleinek together with bdrung
20:30:13 <ukleinek> ok
20:30:43 <bwh> ukleinek: We probably want dracut | initramfs-tools | linux-initramfs-tool, so either of the "big" generators is preferred over more special-purpose tools
20:31:01 <bdrung> i can compile the list of packages that ship initramfs-tools hooks. where should i publish this?
20:31:01 <ukleinek> bwh: sounds good
20:31:13 <ukleinek> bdrung: in a mail to d-kernel@
20:31:31 <bdrung> "dracut | initramfs-tools | linux-initramfs-tool" looks correct to me
20:31:37 <ukleinek> (and prod me on irc as I don't read that list)
20:32:12 <carnil> okay I summarize as follows: 1. switch the  order in the initramfs generator dependency (ukleinek will look into this), 2. benh looks into adding support into the d-i, 3. bdrung compiles a list of packages that ship initramfs-tools hooks
20:32:25 <carnil> (maybe 4. move dracut already to kernel-team maintenance)
20:32:28 <ukleinek> from my side adapting the dependency can be done real soon, maybe for experimental first
20:33:20 <carnil> ukleinek: well in any case in experimental first :)
20:33:33 <ukleinek> bdrung: do we need a versioned dependency or is plain "dracut" fine?
20:33:47 <carnil> do we agree on the above summary and want to move the the bug lists for today? or anything else e want to cover here first?
20:34:06 <bwh> I agree and would like to move on :-)
20:34:11 * ukleinek nods
20:34:27 <carnil> okay we move to the bug list
20:34:44 <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:02 <carnil> last week we had, that bwh wants to research it further, bwh can we keep the action to you?
20:35:12 <bwh> Yes that's fine
20:35:16 <bdrung> ukleinek, plain "dracut" is fine (the dracut package is the equivalent to the initramfs-tools package)
20:35:26 <carnil> #action bwh further researches the problem around #1121227
20:35:44 <ukleinek> bdrung: I'll create a MR and will add you as a reviewer
20:35:49 <carnil> #topic #1122340: I/O scheduler shows "[mq-deadline] none" on AHCI SATA drives
20:36:05 <bwh> Again, I'm happy to keep the action for this
20:36:21 <carnil> so far no reply to ukleinek's question. From last meeting bwh wanted to debug further, but I wonder if the bug has actually real validity but we will see
20:36:40 <carnil> #action bwh keeps the actiion to debug #1122340 together with the reporter
20:36:56 <carnil> #topic #1122975:  amdgpu: flip_done timed out on Ryzen 5700U (Wayland) causing system freeze
20:37:25 <carnil> Once again flip_done amdgpu related bug. Recurring. Asked if this a regression. And if yes maybe we get some luck out of bisection. So wait now for the reporter or any other ideas?
20:37:29 <ukleinek> wait for reporter feedback
20:38:01 <bwh> right
20:38:07 <carnil> #topic #1123046: linux-image-6.17.11+deb14-amd64: amdgpu kernel oops (regression) in 6.17.11, not in 6.17.9
20:38:27 <carnil> reporter did bisect, I woul like to check if this regression is known based on that knowledge and then otherwise forward it upstream
20:38:41 <bwh> Sounds good
20:38:46 <carnil> #action carnil double-checks if regression for #1123046 already known or otherwise forwards to upstream
20:39:01 <carnil> #topic #1120058: linux-image-6.16.12+deb14+1-amd64: suspend-to-RAM results in hang (AMD Ryzen 5 5625U)
20:39:08 <carnil> Issue identified, known and worked on upstream. Reported tested proposed patch and confirmed to solve the problem.
20:39:13 <carnil> Wait for upstream fix to land and make its way to the required stable series.
20:39:21 <ukleinek> /nod
20:39:27 <bwh> good
20:39:30 <carnil> #topic #1120831: linux: failed command: READ FPDMA QUEUED after boot
20:39:46 <carnil> this was confusing the last meetings but reporter now confirmed it is present without nvidia modules
20:40:07 <carnil> so I think that would be optimal candidate to get the reporter do the bisect beween the two known good and bad versions
20:40:16 <carnil> I asked back that today on the bug, we will see how the reporter reacts?
20:40:20 <bwh> OK
20:40:22 <ukleinek> did we consider a dying disk ast time around? ask for SMART data?
20:40:51 <bwh> Well if the disk is dying we should see the bisect says everything is bad
20:40:57 <carnil> ukleinek: the suprising thing is though that if the reporter switches back to the old kernel the error is not logged
20:42:05 <ukleinek> hmm, so maybe the older kernel isn't as demanding and so doesn't show the dying symptoms (yet). But I agree a bisect is the right idea.
20:43:06 <carnil> okay so we for now stay on that position
20:43:21 <carnil> #topic #1121718: linux-image-6.17.8+deb14-amd64: Logitech C920 HD Pro Webcam shows flickering artifacts (sometimes)
20:43:54 <carnil> some updates from today where reporter did "bisect" the Debian versions so the problem seems to appear between 6.13(.11) -> 6.14.6
20:43:54 <ukleinek> #action ukleinek still intends to forward #1121718
20:44:01 <carnil> perfect :)
20:44:14 * ukleinek also noticed the new info
20:44:16 <carnil> there were some followups where maybe you can comment as well when doing so
20:44:38 * ukleinek nods
20:44:49 <carnil> #topic #1122106: linux-image-amd64: UBSAN create a systematic trace in DRM driver (merged with #1122154)
20:45:32 <carnil> Confirmed patch as proposed upstream "supresses" the warning, last followup from upstream: will submit the patch for mainline -> wait until "fix" propagrates, it is considered a false-positive upstream and the patch will supress the warning.
20:45:47 <carnil> #topic #1122193: linux-image-amd64: usb hid descriptor requirements are rejecting hardware
20:46:11 <carnil> forwarded upstream, patch developed by upstream, patch tested by reporter -> wait that it lands in mainline and propagates to stable series
20:46:34 <carnil> #topic #1122357: linux: Please update udeb packages to use non-aliased paths
20:46:35 <ukleinek> what is "linux-image-6.12.25+rpt-rpi-v8"?
20:46:52 <bwh> waldi is working on this
20:46:58 <bwh> I think?
20:47:29 <bwh> Also I was going through my old local branches and found my earlier work on this
20:48:03 <carnil> there is at least the wip on kernel-wedge from Bastian in https://salsa.debian.org/installer-team/kernel-wedge/-/merge_requests/4
20:48:51 <bwh> I'm still pretty sure it's not needed, but waldi tested more recently than me...
20:49:30 <ukleinek> waldi was silent up to now, I guess he's not at his keyboard
20:49:37 <carnil> okay but I guess if he stays on top of it, thinks will eventually be solved.
20:49:47 <carnil> ukleinek: yes he said last time he won't be around today
20:49:57 * ukleinek wasn't sure
20:50:39 <carnil> so maybe we can look at the next meeting on the status of this bug, but we might look more back for find-recent-urgent for the next meeting as we will skip some weeks.
20:51:21 <ukleinek> ok. so let's assume waldi is on top of things and go to the next bug?
20:51:23 <carnil> let's assume it is in good hands and then review/ask if it get "stuck" (as well not sure how urgent it is, but is aimed as well to be done in this release cycle)
20:51:27 <bwh> right
20:51:40 <carnil> #topic #1122521: linux-image-6.17.11+deb14-amd64: nvmet_rdma causes null pointer dereference
20:51:57 <carnil> New report, no feedback from us so far. Reporter might not be able to reproduce without OOT modules but maybe not related to the problem.
20:52:23 <carnil> should it be still be forwarded (but upstream might reject the report bdcause of the involved zfs OOT modules?)
20:53:45 <ukleinek> maybe if the backtrace is decoded the issue becomes simple to diagnose
20:54:07 <bwh> Yes it might be
20:54:16 <ukleinek> #action ukleinek looks into #1122521 and forwards if appropriate
20:54:25 <carnil> thanks ukleinek
20:54:43 <carnil> #topic #1122788: linux: Please remove/replace usage of dh_movetousr
20:55:00 <bwh> waldi is working on that too
20:55:07 <ukleinek> there is also a MR for that IIRC
20:55:37 <carnil> ukleinek: but mbiedl closed it to leave it to be done as waldi would like to have it (unless I missed something recent)
20:55:45 <carnil> so as per above, assume waldi is looking into it :)
20:56:24 <ukleinek> TIL #debian-usrmerge
20:56:27 <carnil> we have a couple of other bugs which we nee to cover: namely
20:56:29 <carnil> #
20:56:30 <carnil> #1122755: (n, ) firmware-free: Please remove/replace usage of dh_movetousr
20:56:37 <carnil> #1122756: (n, ) iproute2: Please remove/replace usage of dh_movetousr
20:56:39 <carnil> and
20:56:45 <carnil> #1122785: (n, ) wireless-regdb: Please remove/replace usage of dh_movetousr
20:56:54 <carnil> I assume iproute2 one will be handled by bluca
20:57:07 <carnil> the others are to be done by someone of us
20:57:15 <ukleinek> the others should be comparably simple
20:57:44 <bwh> It is a pain for wireless-regdb as that gets backported to all stable suites
20:58:42 <carnil> :(
20:58:43 <bwh> But I can just ignore the bug for wireless-regdb until dh_movetousr is actually going to be removed
20:59:07 <ukleinek> is dh_movetousr relevant for backports?
20:59:46 <bwh> Yes because the move to /usr should not be done in backports
21:00:00 <ukleinek> bwh: so it's fine if dh_movetousr is dropped?!
21:00:24 <bwh> No, I want to run dh_movetousr when building for trixie or forky
21:01:45 <ukleinek> but we need a proper solution for that for forky+1 anyhow and that proper solution would work already today
21:02:32 <ukleinek> (well, that proper solution doesn't need to cover bullseye and bookworm maybe, but the tricky part is trixie anyhow)
21:02:47 <bwh> Well, I'm starting to wonder why it is important to remove dh_movetousr and whether that will actually happen so soon
21:03:24 <bwh> If that happens then I will do the necessary conditional stuff direcrtly in wireless-regdb, but until then I would prefer to leave the bug unfixed
21:03:25 <ukleinek> "If this means an undue burden on your
21:03:26 <ukleinek> workflow our recommendation is to postpone this cleanup."
21:03:33 <carnil> the manpage says: dh_movetousr shall be removed from debhelper during forky+1 is release cycle. so depends on what you mean by soon.
21:04:55 <bwh> Please just assume I will fix this when it is actually needed
21:05:14 <carnil> ok so let's move on
21:05:21 <ukleinek> would it be a problem if oldstable had wireless-regdb installed in /usr?
21:05:43 <carnil> time is over anyway will try to move a bit faster to the remaining bits
21:05:49 <carnil> #migration excuses
21:05:50 * ukleinek nods
21:06:12 <carnil> linux, well riscv64 is building, I think autopkgtest reason was again a flaky test, at least I do not see something on the tracker which is relevant
21:06:20 <ukleinek> did we discuss #999485 ?
21:06:38 <carnil> ukleinek: ups
21:06:46 <carnil> yes I unintentionally skipped it
21:06:57 <bwh> These firmware files are not present in linux-firmware
21:07:12 <carnil> #topic
21:07:12 <carnil> #999485: (n, u) Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
21:07:16 <bwh> So, I suppose I should respond to this bug to ask why and see if that can be fixed
21:07:19 <carnil> #topic #999485: (n, u) Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
21:07:57 <bwh> #action bwh will respond to bug #999485 to determine whether the files can go into linux-firmware/firmware-nonfree
21:08:04 <carnil> thanks!
21:08:15 <carnil> #topic new upstream versions
21:08:33 <carnil> I think the only relevant one is firmware-nonfree for which kathara is working on and has a MR open
21:08:36 <bwh> right
21:08:47 <carnil> so work in progress and in hands
21:09:00 <carnil> #topic merge requests
21:09:13 <carnil> anything which is is needed to be discussed about the current ones?
21:09:22 <ukleinek> there are two MRs for the update of firmware-nonfree?
21:09:54 <bwh> yes, but !135 will be updated to only deal with the move of files to another source package
21:10:13 <ukleinek> ok
21:12:27 <carnil> for the ports related MR, I tried to convince to use git-format-for-debian and update the MR, will see if that happens. And I'm not sure I properly explained the salsa ci part, if someone of you both has spare cycles maybe you can have a second pair of eyes for both MRs and in case comment to John Paul Adrian
21:12:28 <bwh> carnil: I still have to look at the linux MRs but I don't think any discussion is needed here
21:12:35 <carnil> so last topic
21:12:48 <carnil> #topic AoB and decision on chair for next meeting
21:13:09 <carnil> according to our wiki the next meeting will be on 2026-01-07
21:13:33 <carnil> any volunteers? It is a jitsi one (ukleinek ;-))
21:14:10 <bwh> I think it is my turn (or waldi's, but he's not here...)
21:14:12 <bdrung> i just tested https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116251 and this kernel provided by carnil does not boot.
21:14:49 * ukleinek would be ok with bwh or waldi chairing next time :-)
21:15:30 <bdrung> i won't attend on 2026-01-07 since i will be on a German train at that time (at least that is the plan)
21:15:31 <carnil> bwh: so can you take it and maybe double-check with waldi if he wants to take it from you?
21:15:46 <ukleinek> I hope our users won't use the xmas holidays to report many bugs, or the next session will get a marathon
21:15:47 <bwh> OK
21:16:01 <ukleinek> s/get/become/
21:16:09 <carnil> bdrung: re the bug: ok bad :( Can you followup with that to the bug so the test is recorded and we know on the BTS it was not sucessful
21:16:39 <carnil> #action bwh will chair the next meeting on 2026-01-07
21:16:48 <carnil> so I guess we can close the meeting :)
21:16:53 <ukleinek> \o/
21:17:11 <bwh> Thank you carnil
21:17:22 <carnil> thanks to all for partecipating, and wish you all good vacation time :)
21:17:32 <carnil> holidays
21:17:40 <carnil> #endmeeting