19:00:36 <carnil> #startmeeting
19:00:36 <MeetBot> Meeting started Wed Oct 23 19:00:36 2024 UTC.  The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:36 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:46 <bwh> Hello
19:01:04 <waldi> hi
19:01:20 <ema> hey
19:01:22 * ukleinek waves
19:01:28 <carnil> hello everybody, I apolgies in advance for the bad preparation, just catched up this week with backlogs
19:01:34 <carnil> #chair bwh waldi
19:01:34 <MeetBot> Current chairs: bwh carnil waldi
19:01:53 <carnil> I would like to start with an issue not listed in the agenda, which I noticed afterwards
19:02:03 <carnil> #topic kconfigeditor2: Incorrectly places CONFIG_PREEMPT_RT=y outside "choice: Preemption Model"
19:02:29 <carnil> #link https://salsa.debian.org/kernel-team/kernel-team/-/issues/6
19:02:51 <carnil> diederik noticed that kconfigeditor2 does not seem to place anymore correctly CONFIG_PREEMPT_RT=y
19:03:20 <waldi> we talked about this last week
19:03:44 <waldi> or before? not sure right now
19:03:55 <bwh> Yes, last week
19:03:56 <waldi> what is the state of -rt in 6.12?
19:04:29 <bwh> As I said last week, it is mostly upstream in 6.12 but we still need patches to make it work on arm (32-bit) and with the i915 driver
19:05:10 <carnil> so if this was discussed already between you two, then we can coninue with the regular topics, I did just not found it in the minutes of the last meeting
19:05:18 * ukleinek wonders what introduced that regression? A change in kconfigeditor, or a change in the linux sources.
19:05:29 <bwh> I don't think we came to any conclusion about it
19:06:37 <waldi> ukleinek: unknown. usualy in linux. the parser this tool uses is a bit limited
19:07:57 <ukleinek> I would volunteer to bisect, but he guesses he's not up to creating a fix.
19:08:12 <waldi> okay
19:08:14 <carnil> so we ignore the kconfigeditor2 issue (for now) and just fix up things by hand when we need to cleanup config with it's help, we know we will still need patches to be applied separately
19:08:21 <waldi> carnil: lets go on
19:08:41 <ukleinek> #action ukleinek looks into https://salsa.debian.org/kernel-team/kernel-team/-/issues/6
19:08:47 <carnil> #topic #1063754 fat-modules: SD corruption upon opening file on Linux desktop
19:09:28 <carnil> I did read again today trough the bug and htere is one intersting statement which I was not aware until rereading: I'm understanding this issue does actually only affect 5.10.y and bullseye kernel?
19:10:31 <bwh> We don't know if it's due to a kernel or user-space change in bookworm
19:10:37 <ukleinek> "Before I upgraded to Bullseye, I encountered corruption" means bullseye isn't affected?
19:10:57 <bwh> It seems to be unknown currently
19:11:14 <carnil> okay so we wait for the reporter to test again under bullseye
19:11:20 <bwh> I jsut checked the folders I provided to the reporter for uploading and there's nothing there yet
19:11:43 <carnil> ok
19:11:49 <carnil> so no further action for now
19:12:04 <carnil> #topic #1076372  Corruption of Longsys/Lexar NM790 NVMe drive with Linux 6.5+
19:12:41 <carnil> Reporter did replied to me ~3 weeks ago he still had no time to further investigate, but did not logged that in the bugreport itself.
19:12:58 <bwh> I think we should close this now as it's been > 2 months and seems quite likely to be a firmware/hardware bug
19:13:01 <carnil> there is nothing we can do right now, it is just scary we have to keep with RC severity bugs open for that long without beeing able to take action
19:13:16 <bwh> It can always be reopened later
19:14:09 <carnil> #action carnil closes the bug #1076372 with explanations that is seems quite likely to be firmware/hardware bug and that it can be reopened later in case of further information from reporter
19:14:29 <carnil> #topic #1085425 linux-image-6.10.12-riscv64: dwmmc_starfive causes filesystem corruption on emmc
19:15:16 <carnil> this was investigated by aurel32, proposed a patch, but he updated me on query that the solution will likely be that the offending commit will be reverted upstream (and backported to the stable series which got the bug and introducing commit)
19:15:46 <carnil> so I think we should just wait until that lands in mainline first, and then either pick it up with the next 6.11.y update or cherry-pick the revert commit
19:16:15 <aurel32> the patch fixes the issue for the starfive case, but it seems it seems the broken commit also introduced and issue on some rk356x platforms
19:16:29 <aurel32> and my patch doesn't fix that, only the starfive issue
19:17:04 <bwh> So should we go ahead and revert already?
19:18:23 <bwh> Seems like that there would still be issues on non-4K page configs?
19:18:43 <aurel32> yes reverting it will reintroduced the non-4K page config issue
19:19:06 <aurel32> but i would recommend to revert it for stable kernels as we have some rk356x platforms supported (although the bug there is a crash and not a data corruption)
19:19:18 <bwh> right
19:19:46 <carnil> aurel32: can you take care of that?
19:20:08 <aurel32> in stable or in unstable?
19:20:56 <aurel32> that is the rk356x issue: https://lore.kernel.org/linux-mmc/CAC8uq=NNBCmtNamvcSHbdv7U99iE6L=teRz9eZ-nJDKx4PMuFw@mail.gmail.com/T/#t
19:22:05 <carnil> I would have said for unstable first, and then we can include it as well in the next stable update (cf. !1241 for current work on that)
19:22:20 <aurel32> ok
19:22:24 <carnil> for unstable I did import 6.11.5, so along with that revert we could make a new upload soon
19:22:58 <carnil> #action aurel32 prepares revert of offending commit introducing #1085425 to be included in next unstable upload
19:23:04 <carnil> ok with that action?
19:23:08 <aurel32> ack
19:23:45 <carnil> #topic #1084791, #1084820 firmware-realtek has an undeclared file conflict
19:24:22 <carnil> bwh: am I correct we are waiting here for confirmation that the firmware files are actually working ?
19:24:23 <bwh> This is fixed but I have been lazy and not yet uploaded
19:24:41 <bwh> #action bwh will upload firmware-nonfree to fix file conflicts
19:25:15 <carnil> thanks
19:25:23 <carnil> #topic #1085387 iwlwifi: wifi does not work at startup, starts working after 2-3 reboots and then works fine
19:25:34 <carnil> not sure what to do here, it is a bit scarce report
19:25:55 <carnil> scarce in the sense of available information
19:26:18 <bwh> I mostly ignore firmware bug reports like this
19:26:27 <ukleinek> yeah, some kernel logs or at least an indication what doesn't work would be nice.
19:27:30 * ukleinek will ask for more details and tag +moreinfo
19:27:39 <bwh> Thank you, you are more patient than me
19:27:56 <carnil> #action ukleinek will ask for more details for #1085387 and tag + moreinfo the bug
19:28:00 <carnil> thank you :)
19:28:05 <ukleinek> bwh: if you say so :-)
19:28:19 <carnil> #topic #1033058 Booting mini.iso : kernel hangs on ppc64el
19:28:48 <carnil> this was fixed in the past, but John Paul Adrian Glaubitz reopened the bug showing that the issue now re-appers
19:29:23 <carnil> and dropping the initially added patch fixes the issue.
19:29:47 <bwh> So, the bug either fixes or causes the bug...?
19:30:07 <ukleinek> s/bug/patch/
19:30:15 <bwh> uh yes
19:30:30 <bwh> I think this is an abuse of reopen
19:30:57 <bwh> and we should move glaubitz's problem to a new bug report
19:31:15 <carnil> bwh: have you capacity to deal with that bug?
19:31:39 <bwh> OK
19:31:59 <bwh> #action bwh will move new problem reported on #1033058 to a new bug report
19:32:53 <carnil> #topic #1084180 linux-image-6.1.0-26-amd64: Fails to boot. Kernel panic.
19:33:11 <carnil> I will still try to deal with that, have not yet followed up on the last anaswer
19:33:23 <carnil> #action carnil follows up on replies in #1084180
19:33:52 <carnil> #topic  #1085177 linux-image-6.11.2-amd64: kworker/0:0+events spin causes high (>1) cpu load due to qxl_fence_wait
19:33:56 <bwh> Let me know if you need help with asking questions about initramfs issues
19:34:12 <carnil> bwh: ok I will come back to you!
19:34:39 <carnil> feel free to just chime in in case you have input as well
19:35:50 <bwh> For this bug there are unanswered questions, so I think no action required at the moment
19:36:11 <ukleinek> bah, salsa 500s for me, ongoing upgrade as announced on debian-infrastructure-annount@l.d.o :-\
19:36:19 <carnil> so wait for furhter replies, no action
19:36:20 <waldi> but at least we know it is debian 11 and most likely it's qemu
19:37:27 <iam_tj[m]1> sounds like it could be related to the original 9pfs/netfs regression
19:37:28 <carnil> and we know reporter most likely could not do an update to stable in this particular setup
19:37:46 <iam_tj[m]1> there have been a few aborted attempts to fix it that have caused other regressions
19:40:13 <carnil> I think right now we can move on as time is progressing for the remaining topics, let's only briefly look at the next two important severity bugs if someone has ideas for those otherwise skim then through the MRs
19:40:36 <carnil> #topic #1085762 linux-image-6.1.0-26-amd64: Random crashes during pbuilder compile runs
19:41:17 <carnil> reporter claims this was introduced with the last stable update, so technically I should be looking at it as I might have cused ith with the 6.1.112-1 upload. But if someone has good imput on where to start here that would be appreciated
19:41:51 <bwh> This was reported against -amd64, but talks about building arm-trusted-firmware so I wonder if it's actually occurring on arm64?
19:41:51 <waldi> vbox
19:42:18 <bwh> (Could be cross-building, of course)
19:43:11 <waldi> and this system runs virtualbox, which we don't know if is it working correctly
19:43:20 <bwh> waldi: But this is reported against VMs and probably not *from* one of those VMs
19:43:49 <ukleinek> I read it that both are affected
19:44:08 <bwh> I think the first question to ask is which architecture are the VMs on
19:44:31 <ukleinek> and if it can be reproduced without vbox?
19:45:22 <waldi> it still is a not supported system: "merged-usr: no"
19:45:55 <bwh> Interesting but unlikely to be relevant to this bug
19:46:04 * ukleinek nods
19:46:32 <waldi> and no kernel log shown
19:46:36 <bwh> right
19:46:49 <bwh> Shall I ask the questions then?
19:47:02 <carnil> bwh: sure go ahead!
19:47:31 <bwh> #action bwh will ask for more info (affected arch, kernel log, etc.) on #1085762
19:47:48 <carnil> #topic  #1085160  linux-sysctl-defaults: apply setting after installation
19:48:00 <bwh> I have an action from last week to reply to this, and haven't done it yet
19:48:13 <carnil> ack
19:48:51 <carnil> #topic https://salsa.debian.org/kernel-team/linux/-/merge_requests/1242 config: Enable LAZY_RCU
19:49:09 <carnil> I think this make sense, but wanted to quickly raise it here for comments
19:49:52 <bwh> I'm not familiar with this setting but I can try to look at it
19:50:21 * ukleinek suspects the reporter was involved in the development of this option
19:50:27 <bwh> indeed
19:51:19 <carnil> bwh: more generally, will you handle the 6.12-rcX experimental upload and go through MR which are relevant for 6.12 upload?
19:51:44 <bwh> I will try to do that but I've been lacking in energy for Debian stuff over the past week
19:52:21 <aurel32> before doing a 6.12 upload, please have a look at !1234, the first commit fixes config things for more than riscv64
19:52:43 <aurel32> otherwise some users will end up without i2c
19:52:44 <ukleinek> A link between #1085262 and https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/138 would be nice. I assume they are related, but salsa doesn't work for me. At least the bug has no indication about the MR.
19:53:00 <bwh> aurel32: I do try to go through all the relevant MRs before uploading to experimental
19:53:42 <bwh> ukleinek: Salsa is up again for me
19:53:51 <ukleinek> Indeed
19:54:01 <aurel32> bwh: ok, thanks
19:54:15 <carnil> ok thanks, bwh if you want help with that, please let know, I should have now again more capacity
19:54:29 <carnil> last one shortly then AoB
19:54:38 <bwh> carnil: Any thoughtful review of MRs is helpful
19:54:51 <carnil> #topic https://salsa.debian.org/kernel-team/linux/-/merge_requests/1233 d/config: enable IPE LSM
19:55:10 <bwh> I saw this but I don't yet know what this LSM is
19:55:26 <ukleinek> !1234 looks fine on first glance. Can take a deeper look and approve (or merge)
19:55:33 <carnil> luca bocassi pinged about that and if we can enable it, but we can handle it while reviwing the other MRs, there should be no pressure I guess
19:55:58 <carnil> #action ukleinek can have deeper ook at MR!1234 and either approve or directly merge
19:56:07 <carnil> #topic AoB
19:56:13 <carnil> so sorry we are quite late
19:56:20 <carnil> anything else to discuss?
19:56:27 <waldi> i failed to write that email about branch renaming, still
19:56:45 <carnil> waldi: we will wait :)
19:57:05 <ukleinek> ..ooOO(Alcohol on Board?)
19:57:10 <bwh> carnil: Last week I had an item for miniDC Toulouse
19:57:15 <ema> I failed to go through make listnewconfig for arm64 as promised some meetings ago
19:57:25 <bwh> waldi isn't going; is anyone else?
19:57:26 <ema> will try to find some time later this week
19:57:32 <bwh> (I am)
19:58:07 <carnil> bwh: I'm still checking with family business if that can work out to come, but more likely I cannot
19:58:44 * ukleinek won't go
19:58:57 <carnil> but defintively would be good to meet again face to face between team members
19:59:14 <bwh> Yes it would be good
19:59:45 <bwh> I should maybe raise this further ahead in future, but I was a bit late making arrangements myself
20:00:44 <carnil> we can try to look ahead for the next minidebconfs which could be possible, and then discuss ahead to see if we can arrange things
20:01:00 <carnil> we can discuss this outside the meeting ;-)
20:01:05 <carnil> wo will chair the next meeting?
20:01:10 <carnil> s/wo/who/
20:01:15 <waldi> looks like it is my turn
20:01:38 <carnil> waldi: well maybe ukleinek or ema want to join the circle ;-)
20:01:51 <waldi> right
20:02:28 <carnil> but let's record it at such in the minutes and then end the meeting
20:02:30 * ukleinek feels better as normal participant. Let me join in that role for a few more meetings.
20:02:47 <carnil> #action waldi takes care of chair'ing the next team meeting
20:03:03 <ema> yeah same here :)
20:03:06 <carnil> waldi: thanks!
20:03:11 <carnil> #endmeeting