19:00:03 <carnil> #startmeeting
19:00:03 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:17 <carnil> hi, welcome to todays meeting
19:00:26 <ukleinek> o/
19:00:42 <carnil> welcome ukleinek
19:00:53 <waldi> i'm here, a bit at least
19:01:00 <carnil> hi waldi
19:01:23 <carnil> #chair carnil ukleinek waldi
19:01:23 <MeetBot> Current chairs: carnil ukleinek waldi
19:01:42 <carnil> 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 <carnil> I have added one topic in advance to answer a question from ukleinek today on IRC
19:02:15 <carnil> #topic unique ABI names changes for trixie and later
19:02:38 <carnil> ukleinek: raised the question why the abi_suffix is not set to '', ukleinek correct me if I got it wrong.
19:02:48 <ukleinek> from my side "if you're convinced it is right, that's good enough for me." was honest
19:03:27 <waldi> well. because 6.6.1 << 6.6.1+deb13, so unstable/testing would be lower then backports
19:03:36 <carnil> 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 <carnil> right
19:03:52 <ukleinek> stable updates use ~deb13
19:04:05 <waldi> we don't have ~ in the abiname
19:04:14 <carnil> ukleinek: note this is not about choosen version, but about the abi name
19:04:23 <waldi> abinames are not quite, but mostly versions
19:05:03 <ukleinek> 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 <waldi> next topic: toxic(?) kernel cve handling
19:05:42 <carnil> 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 <ukleinek> carnil: ack
19:05:51 <carnil> #topic kernel CVE handling
19:06:02 <carnil> waldi: do you refer to the HFS+ discussion on oss-security?
19:06:05 * ukleinek misses context
19:06:10 <waldi> yes
19:06:25 <carnil> #link: https://www.openwall.com/lists/oss-security/2025/06/06/12
19:07:17 <waldi> 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 <carnil> we do rely on the vulns.git repository from the kernel CNA and map that to our versions in kernel-sec
19:08:40 <carnil> 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 <carnil> 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 <carnil> 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 <waldi> carnil: okay, thx
19:11:36 <carnil> 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 <carnil> 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 <ukleinek> 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 <waldi> 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 <waldi> but, well. okay
19:13:19 <carnil> 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 <carnil> do we want to move to the buglist? (although many are "wait for reply"?
19:13:58 <ukleinek> I think it's fine to benefit from the lists but don't forget the processes for bugs without a CVE
19:14:36 <waldi> no more questions on this
19:15:11 <ukleinek> ack
19:15:26 <carnil> #topic #1104269: linux-image-6.12.22-amd64: amdgpu flip_done and commit wait timeouts during normal use - causes session lockup
19:15:40 <carnil> 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 <carnil> Another reporter (Mathias Gibbens) reported he might have encountered the same or similar issue (and provided a set of logs)
19:16:21 <carnil> 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 <carnil> 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 <carnil> (and can take care of that as I was already assigned last time)
19:17:29 <carnil> #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 <carnil> #topic #1106411: linux-image-6.12.27-amd64: kernel NULL pointer dereference in bmc150_accel_core
19:17:47 <ukleinek> ack
19:18:26 <carnil> 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 <ukleinek> 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 <carnil> 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 <carnil> next topic? (wich is more complex intersected?)
19:20:23 * ukleinek nods
19:20:23 <carnil> or any other input on this?
19:20:37 <carnil> #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 <carnil> 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 <carnil> What we know so far is that reporter updated to trixie and he has no more issues there.
19:21:57 <carnil> 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 <carnil> ukleinek: you man about the claim it is fixed in trixe?
19:22:52 <ukleinek> yes
19:23:28 <carnil> 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 <ukleinek> 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 <carnil> ukleinek: this is fine with me
19:24:11 <carnil> #1107142: linux-image-6.12.27-amd64: mpt3sas LSI SAS2008 [1000:0072] probe failure - BAR 1 reservation error
19:24:16 <carnil> #topic #1107142: linux-image-6.12.27-amd64: mpt3sas LSI SAS2008 [1000:0072] probe failure - BAR 1 reservation error
19:24:41 <carnil> no reply from the reporter on the question, so wait
19:24:51 <ukleinek> who is lordy?
19:25:42 <ukleinek> wait, next?
19:26:03 <carnil> #topic #1107511: linux-image-6.1.0-37-amd64: Resume from supsend-to-disk fails
19:26:20 <carnil> we wait here to hear from the reporter
19:26:58 <carnil> 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 <carnil> -> wait
19:27:27 <carnil> #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 <carnil> finally a new report without waiting ;-)
19:28:13 <carnil> 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 <carnil> 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 <ukleinek> there are 7 patches to drivers/net/wireless/ath in that kernel interval
19:29:21 <ukleinek> s/6.1.22/6.12.22/
19:29:49 <ukleinek> might be worth to ask upstream already now?
19:30:00 <carnil> sorry for the version typo
19:30:39 <ukleinek> there are a few more ath changes in 6.12.27..6.12.$latest
19:30:48 <carnil> ukleinek: if you think we have already enough that might be the better option than asking to bisect
19:31:13 <ukleinek> with the additional changes let's ask the reporter first to test 6.12.$latest
19:31:27 <carnil> ukleinek: do you want to followup on the report?
19:31:52 <ukleinek> #action ukleinek asks reporter of #1107521 to test latest 6.12.y
19:31:57 <carnil> #action ukleinek follows up on #1107521 asking to test first newer kernel (possibly report then regression upstream)
19:32:00 <carnil> heh :)
19:32:19 <carnil> #topic #1106668: Waking up from suspend to RAM reproducibly leads to a hard freeze
19:32:41 <carnil> wait, ukleinek asked for test debugging and report back
19:32:48 <ukleinek> ack => wait
19:33:03 <carnil> #topic #1107299: kernel: watchdog: Watchdog detected hard LOCKUP on cpu
19:33:08 <carnil> new report.
19:33:28 <carnil> By quickly skimming over the log before the meeting: is the issue drm/i915 related?
19:34:17 <waldi> at least the cpu is blocked inside it
19:34:54 <ukleinek> i915 + rcu, yes
19:35:58 <ukleinek> there is one i915 in newer 6.12.y, but that seems unrelated
19:37:24 <ukleinek> ask if it is reproducible and if it occurs on 6.12.32
19:37:57 <carnil> okay I can take an action on that, and will search bit around on the lists if I find something similar
19:38:07 <ukleinek> sounds good
19:38:38 <ukleinek> the next three bugs are boring
19:38:41 <carnil> #action carnil asks reporter of #1107299 if issue appears in 6.12.32-1 as well, if yes new logs
19:38:58 <carnil> we can skip those, they are already handled
19:39:16 <carnil> the first one closed, the last as you noted pinged stable for backports to stable series
19:39:30 <carnil> #topic #1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
19:39:42 <carnil> got reassigned to us, which seems more sensible. But might be a HW issue
19:40:02 <carnil> Asked for full logs until up to triggering the problem to get a better clue
19:40:08 <ukleinek> seems to be a hang in mutex_lock? Does that count as hang at all?
19:40:15 <carnil> We have that in meanwhile but it is quite hard to read IMHO
19:41:16 <ukleinek> something ate the \n in the log
19:41:40 <ukleinek> proprietary module nvidia
19:42:23 <ukleinek> so: ask to reproduce without the nvidia module.
19:42:50 <ukleinek> #action ukleinek asks to reproduce without nvidia module and on latest kernel
19:42:58 <carnil> thanks
19:43:14 <carnil> #topic #872726: linux: apparmor doesn't use proper audit event ids
19:43:42 <ukleinek> wait++
19:43:51 <carnil> 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 <carnil> wait for now, see how it moves in the next weeks
19:44:19 <carnil> #topic #1107579: linux-image-6.1.0-37-amd64 hangs on resume from hibernate
19:45:35 <ukleinek> without looking at the affected kernel versions reminds me about #1106668
19:46:34 <carnil> it would be as well in 6.1.140-1
19:46:47 <ukleinek> #action ukleinek points reporter of #1107579 to #1106668 and the same debug procedure
19:47:13 <carnil> #topic #1106386: Bluetooth: btusb: Add RTL8851BE device 13d3:3601
19:47:26 <carnil> this is handled by ukleinek and will eventually land in Debian at some point
19:47:42 <carnil> 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 <ukleinek> ack for wait and close with experimental
19:48:46 <carnil> #topic initramfs-tools issues
19:48:58 <carnil> I assume bwh is taking care of those
19:49:04 <ukleinek> is it sensible to talk about these without bwh? I guess not
19:49:21 <carnil> #topic Migration excuses
19:49:44 <carnil> for linux we just have to wait (and talk to release team to lower miration time to e.g. 7 days)
19:50:00 <carnil> #action carnil keeps an eye on linux/6.12.32-1 migration to trixie
19:50:18 <carnil> #topic New upstream versions
19:50:37 <carnil> 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 <ukleinek> the table is outdated, we have 6.15.2 already in experimental B-)
19:50:50 <carnil> but at least one upload should be done
19:51:12 <carnil> #topic merge requests
19:51:54 <carnil> 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 <carnil> #topic AOB?
19:52:29 <ukleinek> the SIMPLE_DRM one might be actionable?
19:52:51 <ukleinek> volunteers for the next chair?
19:52:53 <carnil> ukleinek: yes but I believe bwh said he is taking care of that MR
19:52:53 * ukleinek looks around
19:53:13 <ukleinek> ok
19:53:16 <carnil> (and hopes that it can make trixie still)
19:53:46 <carnil> ukleinek: I will ask ben if it's still on the radar
19:54:03 <ukleinek> 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 <carnil> ack, great news :)
19:54:52 <ukleinek> failed to use the rj45 ethernet and the usbgadget ethernet, resorted to a usb-eth adapter
19:55:28 <carnil> ok
19:55:34 <ukleinek> 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 <carnil> ukleinek: thanks that would be great
19:55:59 <carnil> #action ukleinek will chair next weeks meeting
19:56:08 <carnil> so I think we are done for today
19:56:20 <ukleinek> \o/
19:56:21 <carnil> #endmeeting