20:01:12 <ukleinek> #startmeeting
20:01:12 <MeetBot> Meeting started Wed Jan 22 20:01:12 2025 UTC.  The chair is ukleinek. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:12 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:01:42 <bwh> waldi: Hope you feel better soon
20:02:35 <ukleinek> Anything to talk about before diving in the bug list?
20:03:10 <ukleinek> #chair carnil bwh
20:03:10 <MeetBot> Current chairs: bwh carnil ukleinek
20:03:46 <ukleinek> #topic #1087807
20:04:10 <ukleinek> bwh: I assume this is still on your todo list?
20:04:28 <bwh> Yes, I was looking at it just before the meeting but haven't sent an update yet
20:04:52 <ukleinek> ok, continuing with the next bug then
20:05:02 <ukleinek> #topic #1093243
20:05:35 <ukleinek> That's a new regression, mariadb hangs in some futex operation
20:05:36 <carnil> just before the meeting I acked the bug, and asked if someone is able to reproduce under lab conditions so we are able to biscect the 6.1.y changes
20:05:52 <ukleinek> carnil: great, thanks
20:06:01 <carnil> so I expect we could identify the breaking upstream change once this is more clear how to trigger it
20:06:11 * ukleinek nods
20:06:20 <carnil> unless someone has already an idea on which upstream change could have produced it
20:07:06 * ukleinek didn't
20:07:07 <carnil> I might be wrong but I do not see immediately something futex related between v6.1.119..v6.1.123
20:07:26 <carnil> but there was a big stable series inbetween
20:07:34 <carnil> so there are ~1000 commits
20:07:51 <bwh> We don't know that this is futex-related, only that many threads waited on a futex
20:08:43 <ukleinek> I guess we wait if carnil's questions for a reproducer yields some info?
20:09:14 <bwh> right
20:09:26 <ukleinek> #topic #1076372 + #1090717
20:09:47 <ukleinek> There is nothing new on our side, but some progress upstream (for the first one)
20:10:20 <ukleinek> I think keeping an eye on it and no further action is the thing to do here.
20:10:26 <carnil> right and even more people able to reproduce it if I understood correctly
20:10:45 * ukleinek nods and continues to the next bug
20:11:05 <ukleinek> #topic #1086028
20:11:16 <ukleinek> .oO(huh, cut-n-paste is hard)
20:11:49 <ukleinek> I didn't look into that, but that one affects the buildds it seems.
20:12:22 <carnil> help from the mips* porters would be welcome here I guess
20:12:34 <ukleinek> There are 3 reporters for different failing packages
20:12:58 <ukleinek> ack, escalating to the mips people sounds good.
20:13:10 <bwh> All involving Cargo though
20:13:30 <ukleinek> ah, didn't spot they have that in common, but makes sense.
20:13:45 <ukleinek> At least one of the bugs was assigned to cargo previously
20:14:17 <ukleinek> #action ukleinek forwarding #1086028 to debian-mips
20:14:20 <bwh> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093200#50 mentions some non-Cargo cases
20:15:03 <ukleinek> #topic #1093734
20:15:47 <ukleinek> That might be hard to work on, carnil tried to reproduce but it didn't trigger. Might also depend on clients.
20:15:52 <carnil> I was not able to reproduce this, but we discussed in one of the recent meetings that there might be race conditions in the services restarts for nfs-utils. I still have reassigned it to src:linux because of the NULL pointer dereference
20:16:33 * ukleinek wondered if that is really severity=serious?
20:16:37 <carnil> I hope the reporter can 1. test as well under 6.12.10 (or 6.12.11 once it comes) or able to reproduce it again
20:17:04 <ukleinek> carnil: so you keep an eye on that bug?
20:17:29 <carnil> ukleinek: I did not want to play to much severity ping-poing and left it as RC severity for now because of the NULL pointer dereference
20:17:34 <carnil> ukleinek: yes I plan to keep an eye on it
20:17:44 * ukleinek provides an ear if carnil wants to talk about annoyances
20:17:51 <ukleinek> carnil: ok, thx
20:18:03 <ukleinek> #topic #1088159
20:18:36 <ukleinek> carnil already asked for logs, I think no further action needed until these are provided
20:18:56 <carnil> For that one I got confirmation that it does not happen when not booting into Xen, so I actually suspect this might be related to the seocnd bug relating to Xen as well. I asked additional for logs which the reporter hopefully can provide
20:19:17 <ukleinek> second bug?
20:19:20 <bwh> I'm wondering if it could be related to #1087807 which is a Xen-specific regression in the same version
20:19:26 <carnil> bisect might be harder if that are production machines but asked still as well. There are in fact Xen related changes between that version
20:19:47 <bwh> I don't see the swiotlb error message though
20:19:53 <ukleinek> also it might be reproducible on a non-production machine?
20:20:17 <carnil> bwh: I actually suspected it might be related to same underlying issue as #1093371
20:20:28 <carnil> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088159#39
20:20:42 <bwh> plasubile
20:20:46 <bwh> plausible even
20:21:27 <ukleinek> ok, seems this bug is well cared for.
20:21:42 <ukleinek> #topic #1091788
20:22:39 <bwh> Reassign to nvidia
20:23:11 <carnil> ukleinek: can I ask first something on the previous bug, can it be for instance related to 1bd4e5a74da9855af7a9c4a0ad9c715fe05a148f ("xen/swiotlb: fix allocated size") or 6434af166441a998644ce961a630948ed5b986ba ("xen: use correct end address of kernel for conflict checking")
20:23:16 <carnil> ah okay let's move on
20:23:24 <ukleinek> in dubio contra reo
20:23:40 <ukleinek> #topic #1092189
20:24:31 <ukleinek> This was forwarded upstream, though the reporter mostly said "here is a link to the Debian report", not sure how motivated upstream will be from that
20:24:59 <bwh> Can you mark it forwarded then?
20:25:21 <ukleinek> I'd say wait a while, and maybe provide some more info on the ML next week?
20:26:05 <ukleinek> #action ukleinek searches for an archive link and marks as forwarded
20:26:20 <bwh> Sounds good
20:26:28 <ukleinek> #topic #1086175
20:27:20 <ukleinek> I inteded to learn how to start the installer on qemu, but failed to find the time. carnil (again!) jumped in and started to look
20:27:27 <carnil> I was able to reproduce it and my next step would be to create a test setup where I can bisect the changes
20:27:50 <ukleinek> carnil: I'd be interested in your setup.
20:27:51 <carnil> ukleinek: oh I do not want to take it away from you if you want to care about it
20:28:19 <ukleinek> Given that I don't have notes about how to do that, I'm not keen on keeping it
20:28:36 <ukleinek> So if you find the time to care, that's great
20:28:43 <bwh> ukleinek: I always use virt-manager for this. It makes it very easy to run an installer
20:28:57 <carnil> ukleinek: I'm trying to do it independly of the installer, lowering dev.raid.speed_limit_max and dev.raid.speed_limit_min so to get enough time between creating the array and rebooting while it's syncing and it seems to trigger even not on a rootfs
20:29:06 <carnil> but I was at really early stage when I commented on the bug
20:29:34 <carnil> and it might yet be a false positive in my tests
20:29:35 <ukleinek> bwh: the missing bit for me is then still: How to create an installer with a custom built kernel
20:30:16 <bwh> ukleinek: Oh, yes that would be a bit harder
20:30:22 <ukleinek> bwh, carnil: Setting something like that up for me can better be handled asynchronously
20:31:05 <ukleinek> carnil: so you keep going?!
20:31:43 <carnil> ukleinek: I will try to do in the next days and report back if my test was really triggering the same issue (if yes then we can handle it outside of installation) but as said not yet 100% sure
20:31:58 <bwh> ukleinek: I guess you can use net-boot to load a custom kernel and existing installer initramfs
20:32:07 <bwh> or even direct boot
20:32:35 <ukleinek> bwh: I somehow have to get the needed kernel modules into the initramfs, but yes
20:32:36 <bwh> but you'd have to change the kernel config to build-in everything
20:32:42 <ukleinek> carnil: 👍
20:32:51 <ukleinek> #topic #1093371
20:33:21 <ukleinek> Is this another incarnation of the (maybe single) Xen problem?
20:33:28 <carnil> see above, I think it could be the same issue as #1088159
20:34:02 <ukleinek> ah, I only saw the connection between two bugs before, so it's actually (maybe) three
20:34:12 <carnil> so the questions asked to the reporter still holds to narrow down the problem, if reporter can bisect that would be even better
20:34:31 <carnil> (but they have not yet replied)
20:34:37 * ukleinek nods
20:35:07 <ukleinek> so nothing to do until we get feedback
20:35:13 <ukleinek> #topic #1093390
20:35:34 <carnil> so many regressions in stable series :(
20:35:55 <ukleinek> ack, that's what I thought, too, when looking through the bug list
20:36:11 <bwh> Why do people still need snd_pcm_oss in 2025 AD
20:37:13 <ukleinek> "Asterisk/app_rpt uses the snd_pcm_oss module for USB device access."
20:38:36 <carnil> I have no idea about asterisk, but if https://community.asterisk.org/t/what-about-app-rpt/68140/2 is correct then I guess app_rpt is already longer "dead"/unmaintained/not-to-be-used?
20:38:52 <carnil> but again I have no clue about asterisk
20:39:36 <ukleinek> The most recent change (seen from stable/linux-6.1.y) to sound/core/oss/pcm_oss.c was in tags/v6.1-rc1~158^2~1^2~19
20:40:54 <ukleinek> So maybe encourage the reporter to find a different setup, but still ask for bisection/upstream reporting?
20:42:05 <carnil> ukleinek: yes sounds good, at least the second part can be asked directly. for the former I think needs someone to at least know something about asterisk
20:42:34 <ukleinek> carnil: mentioning the link you found to hint in that direction sounds fine?
20:42:42 <bwh> This could also be a sound/usb change that interacts badly with the OSS emulation or with something this application is doing
20:43:11 <ukleinek> #action ukleinek responds to #1093390
20:43:21 <carnil> ukleinek: thank you!
20:43:34 <ukleinek> #topic #1093435
20:43:58 <ukleinek> another regression with nvidia proprietary stuff
20:44:59 <ukleinek> carnil asked for a few things to test, no reply yet
20:45:02 <carnil> there was a followup yesterday: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093435#29
20:45:33 <carnil> he will test the most recent kernel, and claims as well that with 6.12.9 recently id does not "fail as often"
20:45:54 <carnil> but reporter said to come back again
20:45:59 <carnil> maybe can remove the moreinfo tag?
20:46:15 <carnil> and then wait for a followup update from reporter
20:46:31 <ukleinek> the nvidia code seems to just be still more broken on recent kernels than usual
20:46:34 <bwh> Why is 'loaded modules' missing from the initial report?
20:47:24 <bwh> It's almost as if the reporter was trying to hide the proprietary crap
20:48:29 <ukleinek> In that case he failed to cencor "Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE" :-)
20:49:00 <bwh> or maybe I misremember how we handle the report being done while running a different kernel version
20:49:01 <carnil> but right, maybe there was more than the nvidia modules
20:49:49 <ukleinek> anyhow, ack for "wait for a followup update from reporter"
20:50:05 <ukleinek> #topic #1093775
20:50:21 <bwh> carnil: The kernel log mentions rni4 and rm14 which don't seem to match any  upstream driver
20:50:46 <bwh> but the driver and module names might be different
20:51:39 <ukleinek> bwh: I wondered if the kernel log was ocr'd from a photo, there are a few strange things in it
20:52:16 <bwh> ukleinek: Ooh, good thinking. Those could actually be rmi4 which is in-tree
20:52:36 <KGB> 03linux 05debian/latest 06Aurelien Jarno * [update] merge request !1331: riscv64 config update for 6.13 * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1331
20:55:40 <ukleinek> bwh: ack for continuing with #1093775?
20:55:51 <bwh> OK
20:56:29 <ukleinek> #1093775 seems to be easy to care for. Enabling the SND_USB_AUDIO_MIDI_V2 seems fine for me.
20:56:48 <ukleinek> (Ignoring the harsh demand from the reporter)
20:57:57 <bwh> I'm not sure what you think is harsh
20:58:15 * ukleinek rechecks, maybe I mix that up with a different bug
20:58:41 <ukleinek> ack, not very nice, but still ok.
20:59:07 <carnil> ukleinek: maybe you confused it with another one from today ;-)
20:59:10 <bwh> Anyway I see no reason not to enable this
20:59:25 <carnil> from technical aspect: https://docs.kernel.org/sound/designs/midi-2.0.html has a section 'kernel configuratio'
20:59:31 <ukleinek> was this config enabled for some time? Was it disabled on purpose?
20:59:36 <carnil> which other options needs/should(?) be enabled as well?
20:59:46 <bwh> It was only added in 6.5 and I think we just hadn't got around to enabling it
21:01:07 <carnil> ok so go for it and enable it for debian/latest and maybe cherry-pick support back as well into debian/6.12/trixie
21:01:19 <bwh> right
21:02:12 <ukleinek> I can care about that, maybe asking the reporter for their needs if I get doubts on the way
21:02:29 <carnil> ok!
21:02:31 <ukleinek> #action ukleinek to care for #1093775
21:03:01 <ukleinek> We're done with severity >= important and our usual hour is over
21:03:18 <ukleinek> There is an impressive list of open MRs
21:04:00 <bwh> Well, half of them are initramfs-tools
21:04:11 <bwh> and the wireless-regdb one is merged
21:04:44 <ukleinek> There are two bug reports about https://salsa.debian.org/kernel-team/linux/-/merge_requests/1324 (Enable ROCKCHIP_DW_HDMI_QP for arm64)
21:05:30 <bwh> I will look at all the MRs, but probably not today
21:05:46 <ukleinek> "not today" is totally fine!
21:05:54 <carnil> thank you bwh
21:06:08 <ukleinek> I can care for the ROCKCHIP_DW_HDMI_QP on
21:06:09 <ukleinek> e
21:06:45 <ukleinek> also 1331 (riscv64 config update for 6.13) is one I feel competent to care for.
21:07:25 <ukleinek> 1333 is about PCI_P2PDMA which we talked about last week and waldi intended to care
21:09:34 <ukleinek> ah, there is another arm one (https://salsa.debian.org/kernel-team/linux/-/merge_requests/1167)
21:11:15 <ukleinek> Who will chair next week?
21:12:19 <carnil> I guess if we do not know about waldi if he will be fine then it's again my turn
21:12:59 * ukleinek nods and heartly thanks carnil for all his efforts
21:13:15 <carnil> let's assign it to me
21:13:18 <bwh> Thanks ukleinek and carnil
21:13:34 <carnil> ukleinek: thanks for leading through the items today!
21:13:52 <ukleinek> carnil: we can coordinate with waldi early next week if he wants to chair
21:13:58 <ukleinek> #endmeeting