19:00:30 <bwh> #startmeeting
19:00:30 <MeetBot> Meeting started Wed Apr 16 19:00:30 2025 UTC.  The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:03 <carnil> hi
19:01:03 <bwh> Who's here?
19:01:31 <ukleinek> o/
19:01:33 * carnil pings waldi and ukleinek
19:01:54 <ukleinek> ..ooOO(bad latency on carnil's end :-)
19:02:00 <carnil> :)
19:02:21 <waldi> hi
19:02:27 <ukleinek> bwh: I like the new agenda format
19:02:43 <bwh> ukleinek: :-)
19:03:03 <bwh> #topic ethtool bug #1102647: (n, u) ethtool should not be user uninstallable via GUI
19:03:34 <carnil> I think we just have to wait that upstream commits the followup patch and then we can apply it as well
19:03:42 <bwh> OK
19:03:43 * ukleinek nods
19:04:13 <bwh> #topic initramfs-tools #778849: (w, ) Support restoring initrd on shutdown and pivoting into it
19:04:53 <bwh> This is wishlist only but probably not that difficult to fix
19:04:59 <iam_tj[m]> I didn't see your comments on this .. I can re-work it if it is wanted (issue 78 MR)
19:05:07 <bwh> iam_tj[m]: Yes please!
19:05:33 <bwh> Can I assign you an action to do that?
19:06:00 <ukleinek> this is just needed for zfs where shutdown needs additional action that requires the fs to be unmounted, right?
19:06:08 <iam_tj[m]> I use my patches for the last year or more across several different arches/hosts and it hasn't failed (that I know of!) so far. I just need to check on the systemd  facility that also does this and make sure they don't thread on each other's toes
19:06:38 <iam_tj[m]> Not just ZFS - some complex RAID/LVM/Device-mapper configs
19:06:47 <bwh> ukleinek: Also for full shutdown of RAID and LUKS
19:06:51 <iam_tj[m]> The latter was my use-case for writing it
19:07:18 <iam_tj[m]> bwh: yes, assign action to me
19:07:22 <ukleinek> I would be interested to learn when/why this is needed for LUKS, but that's off-topic for now
19:07:44 <bwh> #action iam_tj[m] will update MR initramfs-tools!78 to address bug #778849
19:07:57 <bwh> #topic iproute2 #1103242: (m, u) /bin/ip: "ip mon" does not exit when output is gone
19:08:32 <ukleinek> no action for us, right?
19:08:46 <bwh> right
19:09:18 <bwh> #topic linux #1102889: (S, u) linux-image-6.1.0-33-amd64: KVM GPU passthrough broken
19:09:36 <bwh> carnil: Was there any news on this today?
19:09:37 <carnil> okay, this one was a regression in my last upload
19:09:51 <carnil> so far I have not yet heard from upstream on the regression report
19:10:01 <carnil> so no no news from today
19:10:43 <bwh> OK. Is there anything we can do in the short term? Is it feasible to revert the breaking commit or would that make things worse?
19:10:45 <carnil> but this one is on top of my list to track, and I raised the severity to serious because RC is warranted, there might be enough people doing pci-passhrough for VMs
19:10:55 <ukleinek> Let's give upstream a bit more time and then ping next week when nothing happens
19:11:43 <ukleinek> Most of the upstream devs probably have holidays on Fri and Mon
19:11:57 <carnil> yes I would agree on that, if we see reports explode then we can take earlier action
19:12:41 <bwh> OK, but I suppose we can wait a while on upstream
19:12:46 <bwh> So, no action needed yet?
19:13:10 <carnil> no explicit action, but I will have this monitored and take action in case there is movement on the upstrema report
19:13:17 <bwh> Thanks
19:13:26 <ukleinek> 👍
19:13:33 <bwh> #topic linux #1101754: (i, uM) linux-image-amd64: HP P410 controller incompatibility; hpsa: lockup detected error
19:14:04 <bwh> This is actually still waiting for info from the reporter, so I think no action needed
19:14:08 <ukleinek> ack
19:14:19 <bwh> #topic linux #1102522: (i, ) linux-image-6.12.21-amd64: Fails to suspend Acer TravelMate Spin B311R-31
19:14:33 <iam_tj[m]> We could do with a full boot dmesg, and find out if the P410 is a NetRAID/PERC clone
19:15:14 <bwh> iam_tj[m]: See attachments to the initial report
19:15:47 <iam_tj[m]> I must be blind!
19:15:58 <bwh> However for #1102522 I think we do need to ask for a full boot log
19:16:10 * ukleinek hands iam_tj[m] a braille display
19:16:31 <ukleinek> ack for #1102522
19:16:57 <bwh> I guess I can take that action
19:17:05 <ukleinek> I wonder if there are some versions between 6.12.12 and 6.12.21-1 to test
19:17:07 <carnil> If I undestand the report correctly then it's quite confusing, reverting back to previously working version does not work anymore, is this correct?
19:17:12 <bwh> #action bwh will ask reporter of #1102522 for full boot log
19:17:47 <bwh> carnil: Yes that is weird
19:17:51 <ukleinek> carnil: needs a full power-off between tests maybe?
19:18:16 <bwh> I think the full BUG message is going to be the interesting thing though
19:18:18 <iam_tj[m]> ^^^ and ask if it is dual-booting with MS Windows
19:18:35 <bwh> #topic linux #1065819: (i, ) linux-source-6.6 cannot be rebuild according to debian documentation
19:18:38 <carnil> might it be related to a done firmware-nonfree update?
19:18:44 <bwh> carnil: Could be !
19:19:25 <bwh> So this bug didn't get any new information, but there is a duplicate #1070986 with some discussion
19:19:40 * ukleinek doubts the justification in that bug for "Severity: grave"
19:21:55 <bwh> If I understand correctly then the deb-pkg scripting just isn't working with compressed + signed modules
19:22:10 <ukleinek> this is about compressed modules and signing with unavailable keys?
19:22:12 <bwh> and that needs to be reported upstream, whether or not we document it
19:22:31 <iam_tj[m]> I think this is something I can test since I build mainline every day almost, but don't do signing
19:22:46 <waldi> bwh: yes
19:22:46 <ukleinek> maks: IIRC you handled upstream's deb-pkg target in the past?
19:23:09 <bwh> ukleinek: No I think signing is attempted with an uncompressed module filename that doesn't exist
19:23:43 <bwh> waldi: iam_tj[m]: Can one of you take an action to report this upstream?
19:23:56 <iam_tj[m]> it's the bindeb-pkg target handling it. I carry some local patches for the builddeb script
19:23:59 * ukleinek remembers that something about a keyring has to be changed when self-compiling based on Debian's .config. Probably mixed these two up
19:24:19 <iam_tj[m]> I'll take the action
19:24:28 <bwh> Thanks
19:24:45 <bwh> @action iam_tj[m] will forward #1065819 upstream
19:24:59 <bwh> #topic linux #1088522: (i, M) nouveau: Unable to boot with 3 monitors on Nvidia GPU
19:25:31 <iam_tj[m]> I've not a response from the reporter as yet
19:25:33 <carnil> no news I think, we are still waiting for feedback
19:25:40 <iam_tj[m]> ^had^
19:25:44 <bwh> OK, so no action
19:25:56 <bwh> #topic linux #1101944: (i, ) linux-image-6.1.0-32-amd64: list_del corruption ... kernel BUG at lib/list_debug.c:62!
19:25:58 <carnil> okay today I seem slow, maybe I should refrain from commenting
19:26:41 <bwh> ukleinek asked for a memory test, which passed, so we have to come up with some other test
19:26:47 <iam_tj[m]> I've had a close look at this one; I have a feeling the cause is in the network handling code
19:27:18 <ukleinek> bwh: I can hover some time over the kernel splat and work out details. Then probably report upstream
19:28:09 <bwh> iam_tj[m]: The initial BUG doesn't seem to relate to networking though
19:28:18 <iam_tj[m]> Also, note, as far as I can tell for that kernel we don't have CONFIG_LIST_HARDENED ?
19:28:30 <bwh> We have CONFIG_DEBUG_LIST though
19:28:48 <bwh> (I think that's the name)
19:28:57 <iam_tj[m]> No it isn't but I think the list 'belongs' to /is used by, the networking side
19:28:58 <bwh> ukleinek: Yes that would be helpful
19:30:10 <bwh> @action ukleinek will try to decode and forward #1101944
19:30:21 <bwh> #topic linux #1102175: (i, M) Repeated lockups in AMDGPU DRM driver
19:30:41 <ukleinek> ..ooOO(Does "@action .." has the intended effect?)
19:30:43 <carnil> should it be: #action ukleinek will try to decode and forward #1101944
19:30:50 <bwh> ukleinek: No it doesn't!
19:30:54 <bwh> #action ukleinek will try to decode and forward #1101944
19:31:01 <bwh> off-by-one key error
19:31:27 <bwh> #action iam_tj[m] will forward #1065819 upstream
19:31:58 <bwh> Bug #1102175 is waiting for more info, so no action needed
19:32:25 <bwh> (some day I will try to automatically filter out bugs where the last mail is from us...)
19:32:35 <bwh> #topic linux #1102422: (n, M) tpm tpm0: tpm_try_transmit: send(): error -62
19:32:55 <carnil> ema asked some questions, so we can add a moreinfo tag back
19:33:11 <bwh> It does have the tag
19:33:37 <bwh> No action needed on this either, I think
19:33:42 <ukleinek> ack
19:33:46 <carnil> ack
19:33:49 <bwh> #topic linux #1102518: (n, Mu) linux-image-6.1.0-32-amd64: Microhpone hotkey event stop working - Lenovo laptop
19:34:08 <bwh> Same for this one
19:34:25 <bwh> #topic linux #1102563: (n, M) usbhid error -71
19:35:17 <bwh> The reporter has replied but the "full kernel log" is not at all full, and they didn't use reportbug either
19:35:24 <carnil> this one is bit "frustrating", we still did not got the full kernel log.
19:35:31 <bwh> carnil: Are you OK with repeating the request?
19:35:43 <carnil> bwh: yes please assign this as action to me
19:35:57 <bwh> #action carnil will ask again for required info for #1102563
19:36:05 <bwh> Thank you
19:36:09 <bwh> #topic #1103277: (n, u) linux: CVE-2024-38541 for 6.1 branch
19:37:17 <carnil> first of all I do not see this as severe issue as apparently the security scanner used might classify it. Still we can apply it once upstream has applied it to 6.1.y as backport
19:37:27 <carnil> but I guess that will at this time not happen
19:37:41 <bwh> I see carnil has followed up to ask why this is critical. It looks like this is only exploitable with a malicious DTB, and there is no much worse you could do with a DTB
19:37:43 <carnil> there is the reason about the MAINTAINERS change back in october
19:38:06 <ukleinek> the reporter mentioned an upstream report, `bts forwarded` would be great
19:38:46 <ukleinek> I can look for the upstream report and follow up
19:38:55 <carnil> ukleinek: I have not found on lore.k.o archives, so might have been via private mail
19:39:14 <carnil> and as said have a look at the involved upstream maintainer and the change back in october
19:39:24 <bwh> carnil: Why is the MAINTAINERS change relevant?
19:39:33 <ukleinek> #action ukleinek triages #1103277
19:40:10 <carnil> bwh: because it's 6e90b675cf942e50c70e8394dfb5862975c3b3b2
19:40:13 <bwh> Oh right, original author is on the shitlist
19:40:52 <carnil> so I really do not see a point that we will apart of upstream take an action here
19:41:00 <bwh> right
19:41:09 <bwh> ukleinek: Thanks
19:41:14 <carnil> if Hideki wants to be bolt then discuss it with upstream but we should not get into the middle of this
19:41:19 <carnil> (is my opinion)
19:41:20 <bwh> #topic linux #993640: (n, +) Please turn on the SimpleDRM driver in 6.11
19:43:08 <bwh> I would like to make this change but we need to test to avoid reintroducing #1036019 outside of the installer
19:44:22 <bwh> I guess I should take an action to continue discussion on the MR?
19:44:33 <bwh> (https://salsa.debian.org/kernel-team/linux/-/merge_requests/1453)
19:44:43 <carnil> bwh: and I guess you would want to have it in the end as well in trixie, right?
19:44:57 <bwh> I think it is too late to do that
19:45:13 <carnil> bwh: if you have an overview, then taking an action/assigning it to you would be great if you have the capacity
19:45:35 <carnil> bwh: ok
19:45:48 <bwh> Would need to check with kibi for the possible installer impact, and I'm pretty sure the answer will be no
19:46:24 <bwh> #action bwh will continue discussion on linux!1453 to fix #993640
19:46:37 <bwh> #topic linux #1102639: (w, ) linux: Please enable CONFIG_SCHED_CLASS_EXT=y
19:47:05 <carnil> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1338 is the related MR
19:47:32 <carnil> there is the question open if we really need to switch to force BPF_JIT_ALWAYS_ON
19:48:20 <carnil> Is the proposal enough or do we need to really set all the force options, and if so do we want that.
19:48:51 <ukleinek> BPF_JIT_ALWAYS_ON=y seems to have the same effect as `echo 1 > /proc/sys/net/core/bpf_jit_enable` ?
19:50:00 <carnil> ukleinek:
19:50:00 <carnil> When CONFIG_BPF_JIT_ALWAYS_ON is enabled, /proc/sys/net/core/bpf_jit_enable
19:50:04 <carnil> is permanently set to 1 and setting any other value than that will
19:50:07 <carnil> return failure.
19:51:01 <carnil> so it's not anymore possible to disble it
19:51:06 <bwh> BPF_JIT_{DEFAULT,ALWAYS}_ON are not dependencies but I guess recommended
19:51:07 <carnil> there was for instance
19:51:34 <ukleinek> carnil: yupp, that description triggered my assumption
19:51:55 <carnil> some CVEs where as an intermediate workaround people could have disabled it until the fix deployed
19:52:09 <carnil> I'm searching one sample CVE, but do not find it right now
19:52:45 <carnil> might have been CVE-2021-29154
19:52:47 <bwh> We seem to have ARCH_WANT_DEFAULT_BPF_JIT=y on all the architectures that matter, which results in BPF_JIT_DEFAULT_ON=y
19:53:15 <bwh> So I don't think we need to set BPF_JIT_ALWAYS_ON...?
19:54:12 <ukleinek> we're considering only d/latest, right? Then we can keep BPF_JIT_ALWAYS_ON off and ask for feedback after enabling the scheduler item?
19:54:21 <carnil> yes just debian/latest
19:54:23 <bwh> right
19:54:56 <carnil> okay I can rebase the MR and merge it there, then ask the reporter to test with the upload
19:54:56 <bwh> I'll just comment on the MR
19:54:59 <carnil> ok
19:55:09 <ukleinek> bwh: thx
19:55:13 <carnil> bwh: thanks
19:56:16 <KGB> 03linux 05debian/latest 06Salvatore Bonaccorso * [update] merge request !1338: Draft: [RFC] kernel: preempt: Enable SCHED_CLASS_EXT (Extensible Scheduler Class) * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1338
19:56:17 <bwh> #topic linux-base #1092550: (w, ) procps: Addback/Provide example of sysctl.d/*.conf like the old sysctl.conf under /usr/share/doc/
19:56:28 <KGB> 03linux 05debian/latest 06Salvatore Bonaccorso * [update] merge request !1338: Draft: kernel: preempt: Enable SCHED_CLASS_EXT (Extensible Scheduler Class) * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1338
19:56:52 <ukleinek> the title sounds trivial
19:56:57 <bwh> I don't really want to do this but I'm not sure which package the example ought to be in
19:57:56 <carnil> yes I was struggling with the same, there is not much advantage of shipping an example in the linux-sysctl-defaults package
19:58:01 <ukleinek> you don't want to do it, but would consider it sensible?
19:58:17 <bwh> I don't think it belongs in linux-sysctl-defaults
19:58:41 <carnil> having somewhere some examples (which got lost) is sensible, but not in the linux-sysctl-defaults  package which is about setting the required defaults and nothing more
19:59:29 <bwh> If we think the examples actually should become defaults then we should make them the defaults
20:00:00 <ukleinek> Which package evaluates sysctl.d/*.conf ?
20:00:14 <bwh> I suppose we could add another trivial binary package that installs the example for real
20:00:27 <bwh> ukleinek: systemd, or procps if you use sysvinit
20:01:12 <ukleinek> then these should provide the examples?
20:01:23 <bwh> but that's 2 different packages
20:02:22 <ukleinek> yeaah, that would mean some duplication, but a small textfile might be ok.
20:03:08 <ukleinek> $ dpkg -S /etc/sysctl.d
20:03:08 <ukleinek> procps: /etc/sysctl.d
20:03:13 <ukleinek> or maybe only procps?
20:03:36 <bwh> systemd reads from there even if it doesn't ship the directory
20:03:41 <waldi> but example for what?
20:04:25 <bwh> The example file just seems to list variously sycsctls that commonly need to be tweaked
20:04:51 <bwh> It's all commented out and actually wouldn't make any sense to install
20:05:29 <ukleinek> systemd machines also tend to have procps, to if only one of systemd and procps should document that, procps should be it.
20:05:43 <bwh> yeah
20:05:58 <waldi> the network settings are taken over by systemd-networkd, and often don't work due to load order with modules
20:06:18 <bwh> #action bwh will discuss #1092550 with procps maintainer and whether examples should be readded to procps
20:06:42 <ukleinek> bwh: thx++
20:06:54 <bwh> #topic AOB
20:07:17 <iam_tj[m]> Yes!
20:07:19 <bwh> Unless someone particularly wants to discuss a new upstream or merge request?
20:08:01 <iam_tj[m]> The kernel-team has two confusing wiki pages for meetings - can we add a redirect link to the top of  https://salsa.debian.org/kernel-team/kernel-team/-/wikis/meetings
20:08:18 <iam_tj[m]> I always end up on that and get confused!
20:08:32 <bwh> Oh, I forgot all about that
20:09:01 <bwh> I suppose I can move that over to the new wiki
20:09:24 <bwh> #action bwh will move https://salsa.debian.org/kernel-team/kernel-team/-/wikis/meetings to the new wiki
20:09:32 * ukleinek was about to suggest that, but noticed before hitting enter
20:09:58 <bwh> Is it worth dicussing HFS/HFS+ further?
20:10:00 <ukleinek> Oh, TIL I alread attended a kernel meeting in 2018
20:10:49 <ukleinek> bwh: ISTR someone had a strong opinion about that
20:10:59 <carnil> bwh: no we can skip HFS/HFS+ for today
20:11:03 <bwh> OK
20:11:10 <bwh> Then, who's chairing next week?
20:11:16 <ukleinek> probably cbmuser
20:11:44 <carnil> ukleinek: I will make a mail to point out to the current upstream proposed patch to deprecate and remove HFS/HFS+ in 2025
20:11:58 <carnil> so they are ware and might chime in uupstream
20:12:14 * ukleinek nods, thanks
20:12:24 <carnil> (and yes was Adrian Glaubitz/cbmuser)
20:13:16 <bwh> Who will be chair next week?
20:13:30 <ukleinek> is it my turn?
20:13:52 <carnil> it would be waldi's turn I think, but if waldi cannot we can shift
20:14:50 * ukleinek holds his breath
20:15:41 <bwh> Looks like you're it
20:15:51 <ukleinek> ok, Ill do it.
20:16:02 <bwh> #action ukleinek will chair next week
20:16:06 <bwh> #endmeeting