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