19:00:13 <waldi> #startmeeting
19:00:13 <MeetBot> Meeting started Wed May 20 19:00:13 2026 UTC.  The chair is waldi. Information about MeetBot at https://wiki.debian.org/MeetBot.
19:00:13 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:21 <waldi> welcome to todays meeting everyone
19:00:26 <waldi> #chair bwh carnil ukleinek
19:00:26 <MeetBot> Current chairs: bwh carnil ukleinek waldi
19:00:27 <carnil> hi
19:00:29 <bwh> Hi
19:00:45 <waldi> anything we should discuss first?
19:01:28 <bwh> Do we want to apply the Bluetooth regression fix without waiting for stable?
19:01:32 <ukleinek> o/, nothing on my radar to discuss upfront
19:01:36 <waldi> i have something i wanted to give some report on, clang
19:01:48 <waldi> #topic bluetooth regression in stable
19:02:09 <bwh> I suppose that will show up in the bug section anyway, so no need to discuss it earlier actually :-)
19:02:15 <waldi> okay
19:02:19 <waldi> #topic clang status
19:02:31 <ukleinek> bluetooth should be #1136790 at al
19:02:37 <waldi> i had the action to take a look at clang
19:02:54 <waldi> it is actually quite easy, as clang is a single instance all targets setup
19:03:03 <waldi> but one showstopper: no multi-arch
19:03:29 <waldi> #link https://salsa.debian.org/kernel-team/linux/-/merge_requests/1940
19:03:58 <KGB> 03kernel-sec 05pipeline 06Salvatore Bonaccorso 1091589 * [3 minutes and 53 seconds] 03success (issue-syntax: success; python-static: success; pages: success)
19:03:58 <KGB> 03kernel-sec 05pipeline 06Salvatore Bonaccorso 1091589 * [3 minutes and 53 seconds] running (issue-syntax: success; python-static: success; pages: success)
19:04:02 <KGB> 03kernel-sec 05pipeline 06Salvatore Bonaccorso 1091589 * [3 minutes and 53 seconds] 03success (issue-syntax: success; python-static: success; pages: success)
19:04:07 <waldi> thats it i think
19:04:30 * ukleinek doesn't understand the issue, but that might not be that important.
19:04:43 <bwh> nice
19:04:52 <bwh> I will try to have a look at that later
19:04:57 <waldi> it means we need to build-depend on :native, we can't use it in modules builds without causing havoc
19:05:10 <waldi> s/modules/external modules/
19:05:42 <ukleinek> it's ok for me to believe you :-)
19:05:46 <waldi> in the past we have wrapper packages for gcc because of this
19:06:13 <waldi> okay, if there are no questions, lets dive into the bugs
19:06:33 <carnil> there is one thing bwh asked above and I want to comment:
19:07:13 <carnil> I do not object that we pick the single regression, but I would as usual prefer to see that upstrema land it. If upstrema does not consider it important enough then I would prefer as well to include it in the next update which will be around the corner
19:07:23 <waldi> carnil: i only see the bluetooth thing, and we'll come to that
19:07:37 <carnil> ah okay so let's discuss it when you handle it
19:07:40 <waldi> #topic #1126671
19:08:06 <waldi> still nothing happened from our side, bwh and waldi wanted to look at that
19:08:26 <bwh> I will get to this but I have been spending all my Debian time on security updates and the build system
19:08:44 <bwh> well, almost all
19:09:23 <waldi> okay
19:09:29 <waldi> #topic #1124075
19:09:46 <bwh> I think I need to ping Sudip because I have not had any response to my patch yet
19:10:01 <carnil> +1 please do
19:10:10 <bwh> #action bwh will ping upstream about #1124075
19:10:21 <waldi> #topic #1135235
19:10:41 <waldi> someone from google talked to the submitter
19:10:43 <carnil> I forwarded upstream Paolo and Christoph have some questions for the reporter
19:11:16 <bwh> OK so let's wait for the reporter to answer
19:11:26 <carnil> yes
19:11:48 <waldi> #topic #1135966
19:12:11 <ukleinek> wait
19:12:21 <bwh> right
19:12:23 <waldi> #topic #1136127
19:13:04 <waldi> this was last weeks action of ukleinek
19:13:11 <ukleinek> agenda is wrong, the action was for carnil 👼
19:13:55 <carnil> yes I can keep an aciton but similar to bwh my time was consumed by preparing security updates
19:14:18 <waldi> #action carnil to answer #1136127
19:14:22 <carnil> and I think I will keep the focus there ;-)
19:14:23 <waldi> okay, thx
19:14:59 <waldi> #topic #1136401
19:15:26 <ukleinek> is that related to #1126671 ?
19:15:54 <bwh> It could be
19:16:10 <ukleinek> (i.e. our longterm bug "Disconnect root (path=/) during heavy load on NvME, partial corruption on NTFS.crash soon but not yet")
19:16:26 <bwh> Just looking to see what model is involved in that
19:17:09 <ukleinek> vendor=KIOXIA
19:17:47 <bwh> It doesn't look like a similar model but perhaps they are built around similar controllers
19:18:09 <ukleinek> ah, the controller is KIOXIA, the nvme itself is Kingston
19:18:10 <bwh> I suppose I can take a look at this one as well, and try to find that out
19:18:33 <bwh> #action bwh will look at #1136401 and compare with #1126671
19:18:53 <waldi> #topic #1136790
19:19:21 <ukleinek> this is the bluetooth regression, right?
19:19:27 <waldi> we broke zwiebelbot…
19:19:28 <waldi> yes
19:19:59 <waldi> bwh: you wanted to know if we should fix that without upstream release?
19:21:03 <bwh> yes
19:21:05 <ukleinek> without having looked at the upstream status: I'd hesitate without the fix being at least in a maintainer tree
19:21:21 <carnil> I will check if the a revert or fix is in the next review queue, but I'm bit relucatant to onl yfix that, because i expect there will be anyway soonish be new rounds of security updates, then it can be squashed in there, but just going through the build, process trough NEW, linux-signed and push the button release for only the revert then I prefer to have included more in the update
19:21:51 <carnil> maybe this is wrong and it is good if we discuss it
19:22:02 <carnil> there seem to be enough people affected
19:22:06 <bwh> Well let me review the fix and I will take responsbiility if I add a broken fix
19:22:10 <ukleinek> is that 6.12.x only?
19:22:20 <carnil> no
19:22:27 <carnil> 7.1-rc3, 7.0.y and 6.12.y
19:22:46 <bwh> #action bwh will review and maybe apply candidate patch for #1136790
19:23:13 <ukleinek> bwh: thanks
19:23:16 <waldi> #topic #1127588: (n, ) linux-image-6.18.9+deb14-amd64: Cannot hibernate after some time of work
19:24:01 <waldi> this is an older report, never got a response from us. full swap
19:24:29 <ukleinek> maybe a memory leak?
19:24:54 <waldi> you can not swap kernel memory, or did something change there?
19:25:26 <bwh> Indeed you can't
19:25:42 <carnil> I checked and the fix is picked for the next round of updates:
19:25:43 <waldi> but yes, could be a memory leak, and the kernel swapping userspace
19:25:43 <carnil> https://lore.kernel.org/stable/20260520162124.798447239@linuxfoundation.org/
19:25:48 <ukleinek> but if there is a kernel memory leak, userspace will fill swap quickly?!
19:26:07 <bwh> carnil: Oh! I thought it was still waiting to go into the maintainer tree. Excellent
19:26:22 <bwh> yes
19:26:32 <waldi> #action waldi to answer #1127588
19:26:47 <waldi> #topic #1132343
19:27:15 <waldi> this waits on the submitter
19:27:41 <waldi> wait, this was the submitter, okay
19:27:41 <bwh> well, or for upstream to accept the patch
19:27:55 <bwh> either way I don't think we need to take action yet
19:28:01 <waldi> so wait
19:28:08 <waldi> #topic #1135748
19:28:37 <bwh> That hasn't changed from last week
19:29:04 <bwh> But I don't see any decision recorded in last week's minutes
19:29:12 <ukleinek> we're waiting for the crashlog?
19:29:24 <bwh> Oh sorry, no, Yunseong had an action for this
19:30:22 <ukleinek> right, #31 has a user question, so we should remove `moreinfo`
19:30:36 <bwh> I just did that
19:31:18 <ukleinek> yunseongkim[m]: are you still planing to act on this bug?
19:32:45 <ukleinek> #action ukleinek waits for reply by Yunseong, and on timeout looks into the details
19:32:55 <ukleinek> #action ukleinek waits for reply by Yunseong, and on timeout looks into the details of #1135748
19:33:01 <waldi> thx
19:33:08 <waldi> #topic #1136792
19:33:15 <waldi> this waits on the submitter
19:33:39 <bwh> I think the merge is incorrect?
19:34:00 <bwh> They might have the same cause but that's not obviously the case
19:34:12 <carnil> I did not merge those as they might be distinct propblem and suggested that the rporter first focus on the first one but I'm not sure
19:35:02 <ukleinek> they have the same reporter, so addressing one after another seems fine to me
19:35:55 <waldi> i see no indication why they are different. both act on address changes and drop temporary addresses
19:37:07 <ukleinek> IMHO no need to discuss that. When it's two bugs and the first is resolved, let's rely on the reporter to tell us
19:37:27 <waldi> #topic #1136800
19:37:52 <waldi> isn't this another occurance of the parport memory problem?
19:38:21 <bwh> yes, but I asked for confirmation of that
19:38:47 <waldi> so wait
19:38:53 <waldi> #topic #1136894
19:41:22 <ukleinek> does someone spot the OOT_MODULE offender?
19:41:23 <bwh> I suppose we can ask whether this happened only once, for a start
19:41:38 <bwh> ukleinek: v4l2loopback
19:41:39 <ukleinek> ah, v4l2loopback, not very suspicious
19:41:55 <ukleinek> (or is it?)
19:42:20 <waldi> i'll handle that
19:42:33 <waldi> #action waldi to answer #1136894
19:42:45 <waldi> #topic #1136947
19:43:35 <ukleinek> hmm, "System suspend still works normally when I explicitly launch it from menu.
19:43:38 <ukleinek> "
19:43:49 <ukleinek> is it obvious that this is a kernel problem?
19:44:07 <waldi> no. lid close actions are handled by userspace
19:44:15 <bwh> A kernel driver is responsible for sending the lid close event though
19:44:38 <waldi> and the report said at least the state changes
19:45:00 <waldi> ah, but no event itself, this is a kernel problem then
19:45:11 <ukleinek> I'd want to know if just booting an older kernel indeed fixes the issue
19:45:36 <bwh> "no problem on linux 6 series"
19:46:25 <ukleinek> bwh: I wouldn't bet that only means "A few weeks ago the problem didn't show, and since then at least the kernel was updated (and maybe more)"
19:46:52 <ukleinek> (that sentence was broken, but I guess you understood)
19:47:02 <bwh> Yes that could be true. And maybe the BIOS/EC got into a bad state around that time
19:47:40 <yunseongkim[m]> ukleinek: Sorry, It's a late, so I've been watching it since this week. I'll leave a action if there's an update.
19:48:00 <ukleinek> #action ukleinek ask for an explicit test with an older kernel for #1136947
19:48:43 <waldi> #topic #1025071
19:49:38 <bwh> I think this is blocked on gdb handling it gracefully...?
19:49:58 * carnil nods
19:50:08 <waldi> then lets make gdb RC buggy for it
19:50:36 <waldi> even fedora enables this, so it is not a problem overall
19:50:36 <bwh> #action bwh will open a bug on gdb for handling YAMA ptrace protection and block #1025071 with it
19:50:55 <waldi> thx
19:51:05 <waldi> #topic #1042818
19:51:45 <bwh> Nothing new since last week
19:51:54 <waldi> so lets ignore this
19:52:23 <waldi> #topic Migration excuses
19:52:47 <waldi> a lot of autopkgtest, did not look at them however
19:53:00 <bwh> I think this is mostly waiting on the autopkgtest backlog
19:53:06 <carnil> are they because they took longer becaouse of the loong64 rebuilds?
19:53:56 <bwh> I don't remember what was the cause of the backlog
19:54:23 <waldi> #topic New upstream versions
19:54:41 <waldi> firmware-free, is there something actaully new?
19:55:05 <waldi> and linux 7.0-rc4, which is done
19:55:22 <bwh> nothing new that's free, AFAICS
19:55:28 <waldi> ack
19:55:34 <waldi> #topic Merge requests
19:55:37 <bwh> maybe I should exclude it from this report
19:55:57 <waldi> #action bwh to exclude firmware-free from new upstream version report
19:56:17 <waldi> nothing really interesting for merge requests, it's pretty empty
19:56:43 <waldi> #topic AoB
19:56:54 <waldi> so, anything else we should discuss?
19:57:02 <waldi> who wants to chair next week?
19:57:03 <ukleinek> I think it's my turn to chair next week
19:57:15 <waldi> #action ukleinek to chair next week
19:57:41 <ukleinek> I won't be available in two weeks (2026-06-03)
19:58:12 <waldi> me neither
19:58:12 <carnil> I have a small question on nfs-utils
19:58:41 <bwh> yes?
19:58:56 <ukleinek> ..ooOO(That was a small question!)
19:59:10 <carnil> I addresed 1136535 for the tests, but in nfs-common we install still the init scriipts as well which use pidof
19:59:44 <carnil> should we add a Depends on procfs still in nfs-common binary package or ignore it assuming that who uses sysvinit pulls in procps as well to use pidof ?
20:00:28 <bwh> I don't think we should add a Depends
20:01:01 <carnil> ok
20:01:12 * ukleinek thought about converting to pgrep, but that is also in procps, so that doesn't help
20:01:16 <bwh> I wonder if there is a different command or shell function that is supposed to be used in init scripts...
20:01:41 <waldi> start-stop-daemon
20:02:38 <waldi> just drop the status command (or the whole init script)
20:02:55 <waldi> status was optional, or now?`
20:02:59 <waldi> s/now/not/
20:03:13 <bwh> We could take out status if anyone complains
20:03:38 <waldi> -T, --status
20:03:38 <waldi> Check for the existence of a specified process, and returns an exit status code, according to the LSB Init Script Actions (since version 1.16.1).
20:03:44 <carnil> ok so thanks for the input. 1. do not add Depends, and 2. if somoeone complains we either drop status or ask to provide an updated init script for the package
20:03:47 <bwh> Or use pidofproc if those daemons actually have pid files
20:03:48 <waldi> so start-stop-daemon is the answer
20:04:23 <waldi> okay. thank you all for attending
20:04:27 <bwh> Thanks waldi
20:04:29 <waldi> #endmeeting