19:00:03 #startmeeting 19:00:03 Meeting started Wed Jun 11 19:00:03 2025 UTC. The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:17 hi, welcome to todays meeting 19:00:26 o/ 19:00:42 welcome ukleinek 19:00:53 i'm here, a bit at least 19:01:00 hi waldi 19:01:23 #chair carnil ukleinek waldi 19:01:23 Current chairs: carnil ukleinek waldi 19:01:42 so let's start, do not know if bwh will be present as well 19:01:46 * ukleinek has a fishy internet connection. good that we don't do jitsi today, for irc it should work 19:02:03 I have added one topic in advance to answer a question from ukleinek today on IRC 19:02:15 #topic unique ABI names changes for trixie and later 19:02:38 ukleinek: raised the question why the abi_suffix is not set to '', ukleinek correct me if I got it wrong. 19:02:48 from my side "if you're convinced it is right, that's good enough for me." was honest 19:03:27 well. because 6.6.1 << 6.6.1+deb13, so unstable/testing would be lower then backports 19:03:36 my argument here is: unstable versions are maint to migrate to testing, thus the abi_suffix would be need to be set to that target to have the expectations on abi names e.g. for backports as well correct modulo some exceptions. 19:03:43 right 19:03:52 stable updates use ~deb13 19:04:05 we don't have ~ in the abiname 19:04:14 ukleinek: note this is not about choosen version, but about the abi name 19:04:23 abinames are not quite, but mostly versions 19:05:03 waldi: if you thought about it and that's what you came up for and even considered ~debX etc that's fine. next topic 19:05:31 next topic: toxic(?) kernel cve handling 19:05:42 okay so if you are convinced let's switch to the next topic, but I wanted to make sure we have it discussed 19:05:50 carnil: ack 19:05:51 #topic kernel CVE handling 19:06:02 waldi: do you refer to the HFS+ discussion on oss-security? 19:06:05 * ukleinek misses context 19:06:10 yes 19:06:25 #link: https://www.openwall.com/lists/oss-security/2025/06/06/12 19:07:17 and i wanted some input on the current state of cve handling in debian linux package. i know that carnil and bwh are doing the work, but i don't know how and what time it requires 19:08:15 we do rely on the vulns.git repository from the kernel CNA and map that to our versions in kernel-sec 19:08:40 more specifically on those dyad files which got implemented (mostly after I asked Greg if we can have the data in a parseable format) 19:09:43 given the amount of CVEs we do not really have the time to assess the severity of each, so mostly if say a LPE appears by other channels we migh prioritize an upload via -security. But other than that we "just" go mapping the CVes to Debian's versions 19:10:20 I have a own set of scripts for that, which are very imperfect and me and bwh aim to reimplement those properly as kernel-sec scripts in python. 19:10:49 * ukleinek skimmed the mail in the link and sees social drama. He wonders if the technical side is already solved. 19:11:30 carnil: okay, thx 19:11:36 ukleinek: on the tecnical side the commit landed in all stable series I believe and we are not affected by the issue anymore, no mather if it has the original CVE from ubuntu, the re-assigned one (by mistake again by kernel CNA) or got retired then again 19:12:15 and if upstream does not want to assign CVEs for this class of issues we have to accept that I think, important is that the fixes land in the stable series and we pick them up accordingly 19:12:39 that's great, so the next question is: Is there a take away from the drama? Anything we want to change or comment? 19:13:04 my stance after seing this toxic behaviour would be: we should not do anything about those CVE and only record the upstream version, but nothing else. so drop all lists and such 19:13:17 but, well. okay 19:13:19 ukleinek: I did not got tricked yet into chiming in nto that thread even if I got explicitly mentioned ;-) and I do not plan to reply there 19:13:55 do we want to move to the buglist? (although many are "wait for reply"? 19:13:58 I think it's fine to benefit from the lists but don't forget the processes for bugs without a CVE 19:14:36 no more questions on this 19:15:11 ack 19:15:26 #topic #1104269: linux-image-6.12.22-amd64: amdgpu flip_done and commit wait timeouts during normal use - causes session lockup 19:15:40 No reply from reporter on question if the issue persists with more recent kernel which had a bunch of amdgpu related fixes. 19:16:04 Another reporter (Mathias Gibbens) reported he might have encountered the same or similar issue (and provided a set of logs) 19:16:21 I'm not sure though we should remove the moreinfo tag as we still wait from the original reporter 19:16:38 * ukleinek would keep moreinfo 19:16:42 so I suggest the action to reping original reporte to see if he can test with 6.12.32-1 which ahd a series of amdgpu related fixes 19:17:01 (and can take care of that as I was already assigned last time) 19:17:29 #action carnil pings again reporter of #1104269 to ask to retest with a current 6.12.32-1 kernel and report back 19:17:45 #topic #1106411: linux-image-6.12.27-amd64: kernel NULL pointer dereference in bmc150_accel_core 19:17:47 ack 19:18:26 Issue is reported upstream, no reply yet from there, aka IMHO wait (we know that it can be triggered by ioo-sensor-proxy) 19:18:35 ah, I remember I wanted to take a deeper look into the splat, might do that 19:18:56 * ukleinek makes a note in his todo list 19:19:34 ukleinek: ok thanks a lot. If you find something please followup as well on the upstream report, maybe that get better traction. 19:20:15 next topic? (wich is more complex intersected?) 19:20:23 * ukleinek nods 19:20:23 or any other input on this? 19:20:37 #topic #1106498: linux-image-6.1.0-37-amd64: sound device occasionally doesn't appear after last microcode/kernel update on Lenovo Yoga Laptop 19:21:00 we have here actually two related bugreports from the same reporter, the other one is #1102518. 19:21:01 * ukleinek 's todo list is a mess, looks like append-only :-\ 19:21:23 What we know so far is that reporter updated to trixie and he has no more issues there. 19:21:57 but so he did not really (or cannot anyore) answer the questions from ukleinek and carnil about if it makes a difference on cold boot vs. reboot 19:22:13 * ukleinek doesn't believe that yet, but IMHO there is nothing to do until he confirms the cold vs. warm boot suspicion 19:22:40 ukleinek: you man about the claim it is fixed in trixe? 19:22:52 yes 19:23:28 ok, then let's wait and maybe re-state that we really need to know to test both on the current setup cold boot vs. reboots behaviour and your other questions. 19:23:29 My mail with the questions is ~ a week old, I suggest to wait another week and if nothing happens close it with trixie's kernel version 19:23:48 ukleinek: this is fine with me 19:24:11 #1107142: linux-image-6.12.27-amd64: mpt3sas LSI SAS2008 [1000:0072] probe failure - BAR 1 reservation error 19:24:16 #topic #1107142: linux-image-6.12.27-amd64: mpt3sas LSI SAS2008 [1000:0072] probe failure - BAR 1 reservation error 19:24:41 no reply from the reporter on the question, so wait 19:24:51 who is lordy? 19:25:42 wait, next? 19:26:03 #topic #1107511: linux-image-6.1.0-37-amd64: Resume from supsend-to-disk fails 19:26:20 we wait here to hear from the reporter 19:26:58 for transparency got an offlist mail from him that he will do as in the followup questions and then report back (respectively to upstream and link back the report) 19:27:09 -> wait 19:27:27 #topic #1107521: linux-image-6.12.27+bpo-amd64: ath12k_pci errors and eventual kernel panic starting with linux-image-6.12.27+bpo-amd64 19:27:34 finally a new report without waiting ;-) 19:28:13 this is new, I see two immediate possible actions, 1. ask if still happens with a more recent kernel from the 6.12.y series to have a baseline for an upstream report 19:28:37 2. if the reporter can, bisect the changes beween 6.1.22 and 6.12.27 as it is claimed the issue is introduced after that switch (AFAIU) 19:28:48 there are 7 patches to drivers/net/wireless/ath in that kernel interval 19:29:21 s/6.1.22/6.12.22/ 19:29:49 might be worth to ask upstream already now? 19:30:00 sorry for the version typo 19:30:39 there are a few more ath changes in 6.12.27..6.12.$latest 19:30:48 ukleinek: if you think we have already enough that might be the better option than asking to bisect 19:31:13 with the additional changes let's ask the reporter first to test 6.12.$latest 19:31:27 ukleinek: do you want to followup on the report? 19:31:52 #action ukleinek asks reporter of #1107521 to test latest 6.12.y 19:31:57 #action ukleinek follows up on #1107521 asking to test first newer kernel (possibly report then regression upstream) 19:32:00 heh :) 19:32:19 #topic #1106668: Waking up from suspend to RAM reproducibly leads to a hard freeze 19:32:41 wait, ukleinek asked for test debugging and report back 19:32:48 ack => wait 19:33:03 #topic #1107299: kernel: watchdog: Watchdog detected hard LOCKUP on cpu 19:33:08 new report. 19:33:28 By quickly skimming over the log before the meeting: is the issue drm/i915 related? 19:34:17 at least the cpu is blocked inside it 19:34:54 i915 + rcu, yes 19:35:58 there is one i915 in newer 6.12.y, but that seems unrelated 19:37:24 ask if it is reproducible and if it occurs on 6.12.32 19:37:57 okay I can take an action on that, and will search bit around on the lists if I find something similar 19:38:07 sounds good 19:38:38 the next three bugs are boring 19:38:41 #action carnil asks reporter of #1107299 if issue appears in 6.12.32-1 as well, if yes new logs 19:38:58 we can skip those, they are already handled 19:39:16 the first one closed, the last as you noted pinged stable for backports to stable series 19:39:30 #topic #1107479: util-linux: blkid hangs forever after inserting a DVD-RAM 19:39:42 got reassigned to us, which seems more sensible. But might be a HW issue 19:40:02 Asked for full logs until up to triggering the problem to get a better clue 19:40:08 seems to be a hang in mutex_lock? Does that count as hang at all? 19:40:15 We have that in meanwhile but it is quite hard to read IMHO 19:41:16 something ate the \n in the log 19:41:40 proprietary module nvidia 19:42:23 so: ask to reproduce without the nvidia module. 19:42:50 #action ukleinek asks to reproduce without nvidia module and on latest kernel 19:42:58 thanks 19:43:14 #topic #872726: linux: apparmor doesn't use proper audit event ids 19:43:42 wait++ 19:43:51 we discussed that quickly last week, upstream did quickly answered that "we are a handfull patches away to implement that" but I'm not reall ywilling to keep that open for another 7 years :) 19:44:02 wait for now, see how it moves in the next weeks 19:44:19 #topic #1107579: linux-image-6.1.0-37-amd64 hangs on resume from hibernate 19:45:35 without looking at the affected kernel versions reminds me about #1106668 19:46:34 it would be as well in 6.1.140-1 19:46:47 #action ukleinek points reporter of #1107579 to #1106668 and the same debug procedure 19:47:13 #topic #1106386: Bluetooth: btusb: Add RTL8851BE device 13d3:3601 19:47:26 this is handled by ukleinek and will eventually land in Debian at some point 19:47:42 wait and close when it lands first in experimental, IMHO? 19:47:53 * ukleinek wonders if it will be included in 6.16 as it hit next before 6.16-rc1, but detail alarm 19:48:21 ack for wait and close with experimental 19:48:46 #topic initramfs-tools issues 19:48:58 I assume bwh is taking care of those 19:49:04 is it sensible to talk about these without bwh? I guess not 19:49:21 #topic Migration excuses 19:49:44 for linux we just have to wait (and talk to release team to lower miration time to e.g. 7 days) 19:50:00 #action carnil keeps an eye on linux/6.12.32-1 migration to trixie 19:50:18 #topic New upstream versions 19:50:37 linux: for the 6.12.y stable series still on it, will need to talk to release team when it's time to stop uploading 19:50:49 the table is outdated, we have 6.15.2 already in experimental B-) 19:50:50 but at least one upload should be done 19:51:12 #topic merge requests 19:51:54 on the merge requests, anything we need to discuss today? I believe most are in hands (or known to the respetive requestor that work is to be done yet) 19:52:03 * ukleinek nods 19:52:14 #topic AOB? 19:52:29 the SIMPLE_DRM one might be actionable? 19:52:51 volunteers for the next chair? 19:52:53 ukleinek: yes but I believe bwh said he is taking care of that MR 19:52:53 * ukleinek looks around 19:53:13 ok 19:53:16 (and hopes that it can make trixie still) 19:53:46 ukleinek: I will ask ben if it's still on the radar 19:54:03 for the mediatek one: I finally succeeded to install Debian on my mt board, will check tomorrow if I have similar issues as it's a different board 19:54:16 ack, great news :) 19:54:52 failed to use the rj45 ethernet and the usbgadget ethernet, resorted to a usb-eth adapter 19:55:28 ok 19:55:34 I can chair next week again (karma points++), my family is on vacation so I should have some time to prepare the meeting 19:55:51 ukleinek: thanks that would be great 19:55:59 #action ukleinek will chair next weeks meeting 19:56:08 so I think we are done for today 19:56:20 \o/ 19:56:21 #endmeeting