19:00:23 #startmeeting 19:00:23 Meeting started Wed Jul 23 19:00:23 2025 UTC. The chair is ukleinek. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:29 ukleinek: You should be sending an email to the list 19:01:02 bwh: is this only to inform the participants? Or is there something formal I'm missing? 19:01:33 Up to now I had the impression that you notice the things I write in here 19:02:04 ukleinek: Well, these are open to the public, so it's a reminder of the time and location, and a notice that the agenda is ready 19:02:31 ok, will do next time then. 19:03:18 ok, let's start, anything to talk about before we discuss the bug list? 19:03:44 I have a couple of extra issues I would like to discuss - the requested debug flavour, and making dracut the default initramfs builder - but not without carnil also present. They can wait until next week 19:04:05 i have nothing extra 19:04:08 bwh: are these topics from the mailing list? 19:04:22 The debug flavour is from the list; dracut is from discussions at DC 19:04:40 #topic #1109203 19:05:21 The reporter of #1109676 suggested that these two bugs (and a third one) might all be due to a single commit 19:06:17 I don't see the connection between these two... 19:06:19 In the mean time there is a 2nd guy who reported to have the problem described in #1109203. I asked for a bisection before I found the hint to #1109676 19:06:25 right 19:07:08 So I posted again suggesting to revert the offending commit of #1109676 before diving into the bisection. 19:07:17 IMHO nothing more to do for now. 19:07:20 agreed 19:07:33 #topic #1088522 19:07:58 There was a question about how to proceed debugging which I answered. 19:08:32 So here also waiting for a reply from the reporter 19:08:37 That seems sensible. Can you tag it moreinfo? 19:08:59 . 19:09:21 #topic #1104269 19:09:49 This is forwarded, waiting for upstream 19:10:21 I'm a little concerned that I'm not seeing mail to or from the original Debian reporter 19:10:55 Starting with #29 it's all to/from LEon Moser 19:11:23 so it's possible we're now going to be fixing a different issue 19:11:51 oh well 19:12:10 #action ukleinek Contact original reporter of #110426 to check if the progress is in the right direction for them 19:12:27 #action ukleinek Contact original reporter of #1104269 to check if the progress is in the right direction for them 19:12:58 #topic #1106411 19:13:47 The problem is clear, I tried to create a patch, but didn't understand all the details so only wrote a mail to upstream with my first approach and why it's probably insufficient 19:14:06 hi 19:14:24 Without deeper knowledge of iio and not system to test I didn't feel this to be sensible to continue 19:14:27 carnil: o/ 19:14:30 sorry for beeing late, had to bring kids to bed 19:14:41 carnil: No worries 19:15:07 carnil: don't you have sudo for your kids? ;-) 19:15:18 ukleinek: no ;-) 19:15:57 Back to #1106411: I think it's ok to wait a bit if Marek or someone else comes up with a patch. 19:16:11 ukleinek: I also have no IIO experience 19:16:13 ukleinek: re #1106411 I was hoping to see some traction on the reported upstream thread, think with you ping again things will go fly 19:16:14 right 19:16:54 I cannot provide a patch, but am in the loop in the thread, so might catch once there is something to test and can propose the reporter a test package 19:17:21 (if he cannot built himself one with the test-patches script) 19:17:41 carnil: If it were urgent for the reporter, I think the first patch by Marek would be sufficient to bring him back to a working state 19:18:05 03kernel-sec 05pipeline 06Ben Hutchings 896573 * [5 minutes and 32 seconds] running (issue-syntax: pending; python-static: pending) 19:18:21 #topic #1108860 19:18:41 The only change here is I tagged it moreinfo 19:18:59 this only made it to the list because upstream confirmed that they'd need a reproduction recipe 19:19:22 reporter promised to provide, but so far not happened, so need to wait 19:19:37 * ukleinek nods 19:19:50 #topic #1109116 19:20:02 03kernel-sec 05pipeline 06Ben Hutchings 896573 * [1 minute and 56 seconds] 03success (issue-syntax: success; python-static: success) 19:20:21 This is on me to reply to 19:20:23 That is the third bug I talked about earlier where the reporter of #1109676 suggested it might be related 19:21:10 #action bwh will still handle #1109116 19:21:24 #topic #1109628 19:21:27 that one is new 19:21:27 in #1109676 at least the reporter did a sucessful bisect, so I suggested there to report the issue as regression to upstream (did not found tit reported) 19:21:44 (but maybe you talked about it already earlier, so back to quiet mode) 19:21:49 carnil: ack, that one is further down on the list 19:22:34 So, we have a regression from bookworm, complicated by the fact that they also switched from nvidia to nouveau 19:22:46 re #1109628: we had one or two other bugs related to suspend/resume. Does someone see if they might be related? 19:23:24 bwh: though untypical, we could ask to retest with nvidia. I would be surprised however if that fixed the problem. 19:23:44 Well, suspend touches almost every driver so unless we know the same driver is involved I wouldn't expect them to be related 19:24:26 ukleinek: They say that the GPU isn't supported any more (I assume the required proprietary driver hasn't been updated for 6.12) 19:25:10 yeah, I somehow thought that they catched up, but that might be wrong 19:25:56 might also be worth to test the #1109676-hypothesis and revert that commit? 19:26:45 Nope, this system is too old 19:27:06 I suggest to prepare a kernel image with that commit reverted and offer that to the reporters of #1109116 and #1109203 19:27:22 bwh: ah, then I misunderstood 19:28:53 I don't have a beefy x86 machine to build a package, carnil maybe you can? 19:29:22 I should be able to easily built amd64 kernels yes 19:29:58 carnil: the commit to revert is fb5873b779dd5858123c19bbd6959566771e2e83 19:30:00 ukleinek: #1109116 is from an AMD system, so an intel_iommu patch can't fix it 19:30:16 #1109203, maybe 19:30:33 bwh: valid concern 19:31:20 #1109628 is from an Intel system but it's so old it's got an Nvidia chipset therefore no Intel IOMMU 19:32:08 #action bwh will ask reporter of #1109628 to go through PM debugging 19:32:11 Can we move on now? 19:32:22 #topic #1109664 19:32:27 bwh: thanks 19:32:56 this is just a request (at a too high severity I think) for CONFIG_SAMSUNG_GALAXYBOOK 19:33:10 No, important is correct for missing hardware support 19:33:26 The driver is under drivers/platform/x86, so you are correct that this is for amd64 only 19:34:15 I can prepare a MR if nobody else feels better suited than me 19:34:39 is this something we want as well in fature trixie upload? 19:34:39 #action ukleinek to prepare a MR for #1109664 19:34:51 carnil: The driver doesn't exist in 6.12 19:34:57 ah 19:35:12 #topic #1109666 19:35:24 bwh asked for a test with a newer kernel 19:35:43 Right, and I identified the likely fix that's already in 6.12 19:36:03 * ukleinek nods, so no action needed until the reporter replied 19:36:14 #topic #1100153 19:36:57 this is an older bug and someone suggested what the problem might be. Seems to be a bit out of the blue, but if they are right ... 19:38:05 tf is a La Jolla Cove adapter... 19:39:18 Seems to be a USB-attached adapter for slow buses. But why... 19:39:45 I think we wait for feedback from the reporter. That was the state of that bug already before that theory popped up 19:40:19 OK 19:40:25 agreed 19:40:33 #topic #1108168 19:41:02 bwh asked some questions, there is a reply now 19:41:20 #bwh will follow up #1108168 19:41:25 #action bwh will follow up #1108168 19:41:29 👍 19:41:38 #topic #1100153 19:41:47 oh, I went backwards 19:41:55 #topic #1109734 19:42:28 So, fixed in experimental but we need it fixed elsewhere too 19:42:31 fix isolated, it is in 6.1.146 and 6.12.39 but both not yet uploaded, fixed already in experimental. 19:42:45 IMHO it was too quick to already close that bug, but assuming it's fixed indeed by the commits pointed out, that's fine 19:43:21 Is this worth cherry-picking for bookworm/trixie, or do we wait for the upstream stable updates? 19:43:26 I opened that bug. I only applied the one line fix to 140 and hope it will work for 146 too. 19:43:33 just depends on when doing the next uploads. I aimed to do a 6.1.y DSA once we have as well the amd64-microcode fixes by Henrique, but that's as well yet open in unstable/trixie. 19:44:07 Wulf: I'd be optimistic here 19:44:08 Not very time critical for me, I can wait a bit longer 19:44:13 bwh: I do not think cherry-picking at this stage is woth, release team asked if there is no need to not do any further linux upload, but if we do then I would rather prefer 6.12.39 which has some additional fixes 19:44:19 so I would rather wait at this point 19:44:20 carnil: OK 19:44:30 Wulf: thanks for your feedback 19:44:47 #topic #1041484 19:44:51 in this case let's wait until the next upload with 6.12.y where 6.12.39+ 19:44:59 carnil: ack 19:45:18 bwh already forwarded #1041484, IMHO nothing to do currently 19:45:57 was bit irritated by this one 19:45:58 And the bug, if it is one, seems to be only that the message is at a high severity level 19:46:11 as this was an old bug, where we jsut got a followup yestrday 19:46:38 (from that followup person that they can reproduce it on trixie) 19:46:47 I would like to tag this wontfix and close it 19:46:51 any objections? 19:46:59 not from my side 19:47:07 for me: go ahead 19:47:20 #action bwh to close #1041484 as wontfix 19:47:27 #topic #1100105 19:47:53 the audio problem is fixed by a soft-reboot (i.e. userspace restart, keep kernel running) 19:48:02 (we need to bring again bit the curve down of https://qa.debian.org/data/bts/graphs/l/linux.png ;)) 19:48:20 Is this prove enough that this is a userspace issue then? 19:48:34 *proof* 19:48:41 Soft reboot *plus* removing/probing the module fixed it 19:48:58 oh, then I misread 19:49:09 oh, it says plugging and unplugging so maybe that means the physical module 19:49:54 I suspect that "just" unplugging and plugging the module would also work 19:49:54 #action ukleinek follows up asking for a minimal procedure to fix 19:50:16 bwh: No, that was tried before 19:50:19 weird 19:50:38 both kernel module reload and physical replug didn't help 19:51:25 * ukleinek will follow up to the reporter, next bug 19:51:33 #topic #1108496 19:51:53 I asked for information and the reporter has added it, so I should continue handlign this 19:52:26 #action bwh will continue handling #1108496 19:52:31 #topic #1109038 19:53:18 * ukleinek runs `bts tag 1108496 - moreinfo` 19:53:23 * carnil retitled the bug for s/breaksd/breaks/ 19:53:25 Another one of mine, though if anyone would like to take over ... 19:53:33 ukleinek: jinx 19:53:54 bwh: ? 19:53:59 I just did the same 19:54:45 bwh: then let's check who's mail will make the difference 🦾 19:55:15 it seems no volunteers ... 19:55:28 #action bwh will continue handling #1109038 19:55:55 bwh: thank you 19:56:08 bwh: also you won for 1108496 :-) 19:56:19 #topic #1109137 19:56:59 No action needed 19:57:18 this is a bug we discussed already last week. The only action since then was me asking for more info, no reply yet 19:57:38 side question: how does it come to "taint requested by userspace application" in #1109038? 19:57:57 carnil: I wondered about that one last week already. 19:58:05 * ukleinek <- doesn't know 19:58:12 carnil: Good question; I don't know what sets that 19:58:25 shouldn't be to hard to work out 19:58:51 #topic #1109676 19:58:51 Let's move on 19:59:30 That is the bug where the reporter already bisected and suggested that the same issue might be the cause for the two bugs discussed earlier 19:59:33 right 19:59:48 As carnil said, this report should go to upstream 20:00:03 Do we need to give a hint about where to send the report? 20:00:12 reporter did already the hard part of the work bisecting the breaking commit. Asked to report upstream (I think reporter should be able to given the knowledge) but if he does not I can help reporting it 20:00:26 Oh, that is already in carnil's message 20:00:29 I should have maybe made explicit the list of recipients 20:01:07 * ukleinek nods after pressing Ctrl-R 20:01:09 I think you probably gave enough information 20:01:12 I can followup on that if you thinkt its needed, but I think reporter can work that out 20:01:23 carnil: I agree it should be fine 20:01:29 ukleinek: You skipped #1076708 20:01:50 #topic #1076708 uh, right 20:02:13 The upstream issue for this was reopened just after your last message 20:02:33 oh 20:02:56 upstream still wants a new log 20:03:56 anyway I guess this should be tagged moreinfo? 20:04:08 * ukleinek nods 20:04:24 maybe point out in the mail that upstream waits for a log 20:05:17 #action ukleinek follows up on #1076708 pointing out the report was reopened and upstream is waiting for details 20:05:27 #topic #1109015 20:05:41 Last bug, bwh already forwarded it upstream 20:05:51 No change here and I don't see what we can do 20:06:35 #topic migrations + new upstream versions 20:07:07 ..ooOO(Was the discussion about #1109015 done?) 20:07:10 Everything is up-to-date in experimental 20:07:43 I have one question: ethtool has released 6.14.2, with one single fix c223c10d8d64 ("netlink: fix missing headers in text output") 20:08:08 bwh: what do you think is it enough that we fix that at some point in a trixie point release? I.e. do nothing now? 20:08:24 (we had no complain about it) 20:09:12 it was new to me that apparetnly upstream does some bugfix releases in earlier series/versions. 20:09:21 carnil: I think this is point release material 20:09:29 Given the time is already up, I suggest to not go through the MRs one by one. Is there need for discussion? 20:09:43 bwh: ack 20:10:16 #topic AoB 20:10:51 I had those 2 non-urgent issues which should go on next week's agenda: 20:11:05 1. Addition of a debug flavour as proposed on the list 20:11:19 2. Switching to dracut as default initramfs builder, discussed at DebConf 20:11:56 https://lists.debian.org/debian-kernel/2025/07/msg00125.html <- debug flavour 20:12:04 I should probably ask Benjamin Drung and Thomas Lange to attend for item 2 20:12:19 bwh: these two triggered the discussion? 20:12:40 yes though there were several other people at the BoF 20:12:44 * ukleinek would expect that bluca was also involved (if he was at DC) 20:12:57 I didn't see him so I don't think so 20:13:04 3. have we sufficiently documented the ppc64el page size change. AFIU the release-notes have yet an open MR? 20:13:07 https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/292 20:13:23 (I see ben is active in discussion) 20:13:43 I think that's getting close to finalised. We should probably update our NEWS entry based on the outcome of that 20:14:00 who will chair next week? 20:14:37 I can do it 20:15:06 ok thank you 20:15:29 ok, then thank you all for participating! 20:15:31 #endmeeting