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