19:00:03 #startmeeting 19:00:03 Meeting started Wed Sep 3 19:00:03 2025 UTC. The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:11 #chair bwh carnil ukleinek 19:00:11 Current chairs: bwh carnil ukleinek waldi 19:00:11 03kernel-sec 05master f70510e 06Salvatore Bonaccorso 10retired/CVE-2022-49493 * Update status for CVE-2022-49493 * 14https://salsa.debian.org/kernel-team/kernel-sec/-/commit/f70510e 19:00:13 03kernel-sec 05pipeline 06Salvatore Bonaccorso 927117 * pending (python-static: pending; issue-syntax: running) 19:00:14 03kernel-sec 05pipeline 06Salvatore Bonaccorso 927117 * running (issue-syntax: running; python-static: running) 19:00:17 hi 19:00:21 welcome 19:00:27 waldi: thanks for taking over the meeting preparation 19:00:46 i tried my best 19:00:54 Hi 19:01:19 anything we should talk about first? 19:01:31 Hi 😃 19:01:40 there is this version sorting question which was raised 19:02:00 03kernel-sec 05pipeline 06Salvatore Bonaccorso 927117 * [1 minute and 46 seconds] 03success (issue-syntax: success; python-static: success) 19:02:06 #topic version sorting 19:02:41 #info related as well https://uapi-group.org/specifications/specs/version_format_specification/ 19:02:44 I just replied to suggest using either '.' or a letter instead of the second '+'. I didn't yet test whehter test-patches handles that properly 19:04:35 We could of course go back to including a serial number in all cases, but I think waldi wanted to get away from that, and I think we will not often have multiple Debian uploads with the same upstream version and target release 19:05:13 just in urgent cases, the normal case would be to rebase to a new upstream version 19:05:20 right 19:05:46 but we need to be able to handle that, we had a couple of security updates or followup bugfixes in point releases to fix e.g. a regression without a new upstream version 19:06:13 a letter might work, have not checked however 19:06:53 it's just way less visible 19:07:05 What is less visible? 19:07:11 . might do weird things, as we have three version sorting algorithms 19:07:20 "deb13a" vs "deb13+1" 19:07:59 Ah, yes I didn't propose that but e.g. deb13u1 19:08:10 ah 19:08:29 this might break after 9 19:08:43 I don't think so 19:08:49 because not all version sorting algorithms split between text and digits 19:08:59 then they didn't work with our old ABI naming 19:09:28 they did, because there was a - in front 19:09:38 oh, you mean between letters and digits (instead of punctuation and digits) 19:09:41 yes 19:10:01 debian version comparison works with that, but others not 19:10:25 deb13u9 vs deb13u10 i meant 19:10:30 So we need to check with: linux-version sort, dpkg --compare-versions, and sort -V, right? 19:10:48 yes. or assume we will never get over 9 19:11:24 #action bwh will test sorting of the alternative version suffixes and report back 19:11:28 thx 19:11:47 anything else? 19:12:09 not from my side 19:13:01 okay 19:13:02 no 19:13:06 #topic #1112208 19:13:33 I took an action for this last week 19:13:42 or it's a duplicate bug 19:13:56 ah, was filled on wednesday 19:14:05 #topic #1111184 19:14:12 this just needs a close i think 19:14:55 in the ideal case we get as well a result on the fixing commit so it might be backported to 6.12.y 19:15:00 We discussed this last week. It stil needs to be fixed in trixie. 19:15:36 seems like the bts misses version information from trixie 19:15:38 The BTS doesn't show it because it doesn't know about security uploads 19:15:47 ah, security, yes 19:15:54 but as bts can handle multiple closes I think it is fine to close, but then tag it + trixie. I got distracted by other things but sitll can provide the reporter instructions on how to bisect 19:16:36 i.e. I had an action to help the reporter doing the last steps of bisection 19:17:28 #action carnil sends reporter instructiond to do the bisection on upstream versions to pinpoint fixing commit 19:17:29 So let's leave that with you? 19:17:33 OK 19:17:37 #topic #1108860 19:17:51 nothing to do right now 19:17:58 we still need a reproducer for upstream from reporter 19:18:01 ack 19:18:13 #topic #1110419 19:19:02 Nothing new in any Debian report or upstream 19:19:18 #topic #1111016 19:19:51 Nothing new, I just added the moreinfo tag last week 19:20:20 #topic #1111095 19:20:36 We discussed this last week... 19:20:56 #topic #1111722 19:21:04 I have an action to ask for more tests on the previous bug 19:21:42 nothing new on this. submitter asked for more information 19:21:44 right 19:21:53 #topic #1112288 19:22:48 I guess someone should look for patches and config changes in Liquorix (whatever that is) 19:24:54 I guess this is this one? https://liquorix.net/ 19:25:05 and there is package source at https://github.com/damentz/liquorix-package 19:25:14 (the install instructions are shoking ...) 19:25:56 but I only see one huge patch there: https://github.com/damentz/liquorix-package/blob/6.16/master/linux-liquorix/debian/patches/zen/v6.16.4-lqx1.patch 19:26:34 I guess https://github.com/zen-kernel/zen-kernel is the actual source 19:28:04 Anyway, I think the best we can do is ask the Liquorix devs to get fixes upstream, and forward this bug report upstream too 19:30:51 noone seems to be currently willing to work on that. so it can wait 19:31:30 OK 19:31:32 not necessarily, I think I would prepfer to focus on other things 19:31:32 #topic #1112333 19:31:49 no log information whatsoever 19:32:27 No log, no lspci, somehow they managed to bypass the bug script 19:32:49 Oh, no it turned into an attachment 19:33:29 So I see timeouts and GPU reset in the kernel log 19:34:39 So I think this needs to be forwarded upstream too. Maybe after testing 6.12.43 if that has amdgpu fixes 19:35:26 yes it has some 19:35:35 When is the point release? 19:35:41 on weekend 19:35:44 next weekend 19:35:49 OK 19:35:52 so lets wait until then 19:36:20 ok 19:36:21 #action bwh will ask submitter of #1112333 to test 6.12.43-1 after the point release 19:36:26 #topic #1112627 19:38:00 (Upstream bug report is from 2022, so unrelated) 19:38:56 this is iommu, so broken firmware. and we enable iommu by default, while others don't 19:39:07 No, it's a regression from 6.12 to 6.16 19:39:32 we might ask Francesco to bisect and report back on the breaking commit 19:39:44 right 19:40:29 The driver is snd_hda_intel which I thought would be quite old and stable, but maybe someone broke DMA mapping there... 19:40:40 carnil: Can you do that? 19:40:53 bwh: yes 19:41:20 #action carnil will ask reporter of #1112627 to bisect upstream changes to identify breaking commit 19:41:56 #topic #1112643 19:43:25 Possibly related to #1112048 but that is known to be a very recent regression 19:43:48 and we still have to get more info for that other report 19:44:18 Well the kernel log shows multiple oopses 19:44:38 Did we see this before? Oops in bmc150? 19:45:17 i don't think i have devices with this sensor 19:45:54 yes the oops bmc150 is familiar 19:45:57 wait a second 19:47:29 https://lore.kernel.org/linux-iio/aDtZqwjKtpyguppg@eldamar.lan/ , #1106411 19:47:44 we do not have yet a patch which got accepted upstream 19:47:49 and discussion stalled 19:48:04 patch proposal was at https://lore.kernel.org/linux-iio/20250613124648.14141-1-marek.vasut+bmc150@mailbox.org/ 19:49:14 disabling iio-sensor-proxy service and see if the problem still happens 19:49:49 OK, so I think we should ask to blacklist this driver and see if that also fixes the suspend 19:50:21 yes sounds good 19:51:02 #action bwh will ask reporter of #1112643 to test blacklisting bmc150 driver 19:51:25 #topic #1113765 19:52:03 fix is expected via stable@ 19:52:08 nothing to do 19:52:25 Seems like it might be serious enough to merit cherry-picking it, if it's not in the stable queue 19:52:49 no, it only applies to broadcast, which is used in exactly one location: dhcp server 19:53:53 So many VM hosts? 19:53:53 and it is in the review for next release 19:53:56 OK 19:54:51 whatever you want, I said to upload 6.16.4 to unstble, I can pick the commit if it already in the stable review vqueues, https://bugzilla.kernel.org/show_bug.cgi?id=220484#c28 though sounds like it is not yet 19:54:58 * carnil can check 19:55:04 It is in the queues 19:55:12 [PATCH 6.16 028/142] net: ipv4: fix regression in local-broadcast routes 19:55:13 I don't know if it went out for release 19:55:17 review 19:55:17 ah that is the one I already picked 19:55:18 OK 19:55:33 [ Salvatore Bonaccorso ] 19:55:33 * net: ipv4: fix regression in local-broadcast routes 19:55:41 so will just add a bug closer before uploading 19:55:51 good 19:56:13 #topic AoB 19:56:48 i started a secure boot policy for linux: https://salsa.debian.org/-/snippets/815, comments welcome 19:56:51 Nothing from me 19:57:00 03linux 05debian/6.16/forky b71c3c6 06Salvatore Bonaccorso 10debian/changelog * Add Bug closer for #1113765 * 14https://salsa.debian.org/kernel-team/linux/-/commit/b71c3c6 19:57:33 who wants to chair next week? 19:57:55 since I had to pass it this week, I can try again for next week 19:58:03 #action carnil to chair next week 19:58:12 i have nothing else 19:58:19 thank you all for joining 19:58:21 me neither, just a thank you to waldi again :) 19:58:24 #endmeeting