19:00:17 <waldi> #startmeeting
19:00:17 <MeetBot> Meeting started Wed May 14 19:00:17 2025 UTC.  The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:17 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:20 <ukleinek> o/
19:00:24 <waldi> welcome
19:00:28 <carnil> hi
19:00:32 <bwh> Hi
19:01:12 <waldi> i does not seem we have any special topics today?
19:01:42 * ukleinek wondered if that pagesize on powerpc is something that we need to discuss, but I think we don't?
19:02:50 <waldi> i don't see any open questions
19:02:53 <bwh> I'm not sure what specific issue you're referring to
19:02:55 * ukleinek nods
19:03:09 <ukleinek> bwh: a bit earlier today in here
19:03:13 <bwh> ah
19:03:22 <ukleinek> @1747241629
19:04:37 <ukleinek> then I agree there is nothing specific upfront and we can dive into the bug list
19:04:45 <waldi> #topic #1105164
19:05:01 <waldi> we decided to ignore that until the next update, right?
19:05:06 <bwh> yes
19:05:24 <waldi> super
19:05:29 <bwh> It would be good to root-cause it but I am not offering to do so
19:05:31 <carnil> what I need to assure when releasing the DSA upcoming is that we do not trigger again that problem
19:06:14 <carnil> if they get released via security-master I could at least fetch first the linux-signed-* and double check and in case reject the upload and ask ftp-master to redo the stuff that should work I guess
19:06:57 <waldi> i don't think it is possible to redo the signing step, this needs then a new upload
19:06:58 <ukleinek> given that we have to live a bit longer with bookworm and 6.1 I wonder if we should implement a test
19:07:00 <carnil> better would maybe if the signing still do some basic checking that no sig file is 0 size, but not meaning to try to do that
19:07:25 <ukleinek> not only checking for size=0 but to verify that the signatures match the cert
19:07:34 <bwh> I think the signing service ought to do that
19:08:33 <bwh> better there than in individual source packages
19:08:42 <ukleinek> Where is the source for that signing service?
19:08:52 <carnil> the offlist comment from ansgar was that hte stuff doing the signing is far from perfect and we should at some point get rid of the 'expect' setup IIUC, but then it is ftp-master area I guess or at least someone with enough knowledge of the signing service might look into it
19:08:55 <waldi> ftp-team/code-signing or so
19:08:58 <bwh> ukleinek: https://salsa.debian.org/ftp-team/code-signing
19:09:13 <waldi> we should get rid of signing modules with it, because sign-file is urgs
19:09:24 <bwh> yes it is
19:09:35 <waldi> the elf signing path is different
19:09:41 <waldi> s,elf,efi,
19:10:58 <ukleinek> carnil: is that something we can delegate to/ask the ftpteam to do that?
19:11:20 <bwh> The FTP team is short of time as it is, so  don't hink so
19:11:51 * ukleinek would have been surprised
19:12:26 <carnil> am I correct, the thing which would need a better error handling for the time beeing would be the wrapper https://salsa.debian.org/ftp-team/code-signing/-/blob/master/sign-file-wrap?ref_type=heads
19:12:31 <bwh> So does anyone volunteer to try implementing a check for this, in either place?
19:13:34 <ukleinek> I can at least take a look, if my time and knowledge is enough to produce a fix is something we will see
19:13:48 <carnil> I will try to have a look, or at least try to circle it thrugh ftp-master contacts as I was already this week chatting about the problem with SRM and ansgar
19:14:07 * ukleinek steps back then
19:14:24 <waldi> #action carnil to look into a test for #1105164
19:14:28 <ukleinek> carnil: if you need a 2nd pair of eyes, prod me
19:14:33 <carnil> ack!
19:14:52 <waldi> #topic #1103397
19:15:32 <bwh> Fix is identified, so we could backport it but I don't know if it's worth doing
19:15:45 <waldi> okay, then let's ignore that
19:15:57 <waldi> #topic #1104327
19:16:19 <carnil> bwh: what I did not understand, will it be queued for stable series or will the fix land just somehen in 6.16?
19:17:00 <bwh> carnil: It does not have a Fixes: or Cc: stable pseudo-header, so we may need to request it for stable
19:17:06 <bwh> Currently it is heading for 6.16 only
19:17:21 <carnil> ok
19:19:11 <bwh> For this next bug, we now have the kernel log showing a WARN on suspend
19:19:31 <bwh> So I guess this can be forwarded now?
19:20:30 <ukleinek> bwh: that's what I thought
19:21:15 <ukleinek> #action ukleinek to forward #1104327
19:22:49 <waldi> for me this looks like a logic bug. that variable is supposed to be cleared at the end of resume, so resume is aborted early
19:22:57 <waldi> okay, next
19:23:01 <waldi> #topic #1104732
19:23:23 <bwh> This was forwarded upstream and I don't think any action is needed from us currently
19:23:35 <waldi> i concur
19:23:43 <waldi> #topic #1105211
19:23:48 <carnil> yes (fwiw, no update upstream yet)
19:26:17 <ukleinek> #1105211 is strange
19:26:54 <waldi> yes. that clc stuff is also deviced by region
19:27:19 <waldi> or i read this wrong, also possible
19:27:25 <waldi> no idea
19:27:45 <ukleinek> a quick look in the source: that parameter is defined in drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
19:28:01 <ukleinek> so it's mt7921-common that takes the option
19:28:06 <bwh> yes
19:28:14 <waldi> yep, and it disables loading some firmware
19:28:17 <bwh> No surprise that setting it on mt7921e doesn't work
19:28:19 <ukleinek> that makes me wonder why `modprobe mt7921e disable_clc=1` helps
19:28:41 <bwh> What helps, most likely, is reloading the module and resetting everything
19:28:48 <bwh> "Have you tried turning it off and on again?"
19:29:06 <waldi> ukleinek: it does not, this parameter does not exist
19:29:26 <ukleinek> waldi: ack, but the reporter claims it helps
19:29:55 <waldi> so it is just a reset
19:30:08 <ukleinek> and modprobe ignores unknown parameters?
19:30:43 <bwh> yes this was changed some time back so that if a module parameter is removed it doesn't cause module loading to fail
19:31:18 <ukleinek> but in modprobe.d it makes the module fail to load?
19:31:21 <bwh> (in the kernel, not modprobe)
19:32:06 <bwh> I don't see any eveidence of that
19:32:49 <ukleinek> then it's hit-and-miss if a HW reset (via a module reload) works or not and the diagnosis that it only works without that file in modprobe.d is likely wrong?
19:33:46 <bwh> Possibly the "CLC", whatever it is, is sticky so you can get away with not reloading it the second time
19:33:46 <waldi> yes. who does want to tell him?
19:33:55 <waldi> i'll do it
19:34:09 <waldi> #action waldi to answer #1105211
19:34:20 <waldi> #topic #1103399
19:34:29 <waldi> duplicate
19:34:36 <waldi> #topic #1104909
19:35:03 <bwh> Seems to be a system firmware bug and has been closed
19:35:05 <waldi> fixed, intel me broken, should be cloded
19:35:13 <waldi> #action waldi to close #1104909
19:35:15 <ukleinek> is already closed
19:35:19 <carnil> waldi: it got already closed by the reporter
19:35:20 <waldi> good
19:35:37 <waldi> #topic #1014299
19:35:45 <bwh> Waiting for more info
19:35:50 <waldi> yep
19:35:57 <waldi> #topic #1102518
19:36:27 <bwh> carnil: Does this still need more info from the submitter?
19:36:46 <ukleinek> nvidia: module license 'NVIDIA' taints kernel.
19:37:23 <ukleinek> does "stopped working" indicate this is a regression?
19:37:37 <bwh> Yes it's reported as working in 6.1.129-1
19:37:39 <ukleinek> ah it does
19:37:54 <bwh> although that's also the version it was originally reported in...
19:38:20 <carnil> there was some missunderstanding, initially he said it regressed upgrading to 6.1.129 (my missunderstanding of the initial report maybe, but explicitly asked) then later claimed it is working in 6.1.129
19:38:56 <carnil> so either me or him is confused about where it got introduced, but at least confirms that the issue is present up to 6.1.137-1 from bookworm-proposed-updates
19:40:00 <ukleinek> so ask for a bisection?
19:40:24 <carnil> in any case I asked in the first repsonse if he is willing to bisect, but he might need some guidance since that was not replied to
19:41:11 <bwh> Do we have any idea which driver is involved?
19:41:13 <carnil> so might just ask that again, but do the bisect between 6.1.129-1 and 6.1.135-1 instead
19:42:02 <ukleinek> finding out with driver is involved might make the bisection unnecessary.
19:42:58 <ukleinek> `ls -l /sys/class/input` on good and bad kernel might give an insight here
19:43:10 <bwh> On my laptop it appears to be thinkpad_acpi but I don't see that in the modules list
19:43:29 <waldi> because this uses ideapad_acpi
19:44:01 <bwh> I don't see that in the list either...?
19:44:25 <ukleinek> it appears in the kernel-log however
19:44:29 <waldi> or the module is called ideapad_laptop
19:44:41 <waldi> yes, it is
19:45:10 <bwh> Sorry I had the wrong search options selected
19:46:12 <bwh> Well, there are no changes in ideapad-laptop between those version
19:47:48 <ukleinek> would be interesting to know if ideapad-laptop isn't loaded on the broken kernel, or fails to bind, or binds fine and just doesn't report events
19:48:32 <bwh> Most likely this is system firmware being unreliable from boot to boot, and there has been no change to the kernel
19:48:53 <ukleinek> hmm, is userspace involved at all for these keys? Or does the driver (or hardware) cope for the effect directly?
19:49:00 <waldi> a complete log of the failing variant would be good as well
19:49:51 <waldi> okay, who wants?
19:49:59 <ukleinek> so ask for a few tries with cold-boot and always the same kernel to check if it really depends on the kernel version, let them check for a biosupdate?
19:50:37 <bwh> ukleinek: Might be worth a try
19:50:43 <carnil> ukleinek: sounds good, and maybe still a full kernel log as well for one boot where things does not work
19:51:27 <ukleinek> #action ukleinek asks for details and further debug actions (#1102518)
19:52:20 <waldi> skipping a few
19:52:22 <waldi> #topic #1104745
19:52:44 <waldi> (why is every debian service currently slow as hell?)
19:53:14 <waldi> this is not building the package, but using the source with other configs
19:53:25 <waldi> so no bug on it's own
19:53:36 <bwh> This should be forwarded upstream
19:54:08 <carnil> what is surpising is the reporter claims it works with gcc-15 upstream but not with the Debian variant on any source, but doko said that upstream ask to report to src:linux upstream
19:54:22 <bwh> I suppose firstly to whoever maintians the gcc plugins, then potentially they can forward to gcc
19:55:14 <ukleinek> they are not even using the debian kernel sources but plain upstream
19:55:18 <bwh> I suppose this should be checked with gcc-snapshot
19:56:12 <bwh> That would tell us whether the breakage is in gcc mainline or only in whatever got backported to gcc-15
19:56:41 <bwh> #action bwh will ask reporter of #1104745 to test with gcc-snapshot
19:56:53 <waldi> and please close it at the same time
19:56:58 <ukleinek> that might or might not easily reproducible
19:57:18 <waldi> anyway, we are out of time
19:57:21 <waldi> #topic AOB
19:57:32 <waldi> who wants to chair next week?
19:57:43 * ukleinek still thinks that #debian-kernel-internal is useful at times
19:58:01 <bwh> Is it my turn again?>
19:58:30 <waldi> i think it might be ukleineks
19:58:33 * ukleinek probably cannot attend next week, but I apply for chairing in two weeks
19:58:39 <waldi> a yes
19:58:48 <waldi> okay, bwh got it
19:58:55 <waldi> #action bwh to chair next week
19:59:06 <bwh> OK
19:59:17 <ukleinek> I think for bwh only an autojoin is missing for #debian-kernel-internal
19:59:43 <bwh> oh right
19:59:54 <ukleinek> For waldi I don't know how to create a somewhat reliable invitation
20:00:40 <waldi> and i don't see a reason for this channel, sorry
20:00:51 <carnil> ukleinek: I could take it as well in two weeks so that I do not have to do again the jitsi one ;-)
20:00:59 <waldi> and i clearly have too many anyway
20:01:38 <carnil> anyway while we are at some AOB, tike for a quick question about a MR/bug?
20:01:48 <waldi> sure
20:02:17 <ukleinek> waldi: for some topics a more private discussion room is useful
20:02:46 <carnil> #960935 / https://salsa.debian.org/kernel-team/linux/-/merge_requests/1506 as this was a quick change on request of the reporter i did prepare a MR, sparc64 is only in ports. How are we handling arch in ports, only accept a MR if there are people aring of it and proposing the change themself?
20:03:11 <carnil> i.e. should we still accept the change from the MR ore since the arch is not an official supported one close the MR as well?
20:03:45 <carnil> I obviously have no way to test that one
20:04:06 <carnil> just went trough some older bug requests enabling config options
20:04:41 <bwh> This one seems like a sensible change
20:05:11 <bwh> I merged it
20:05:12 <KGB> 03linux 05debian/latest 06Ben Hutchings * [merge] merge request !1506: [sparc64/smp] Enable NUMA * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1506
20:05:13 <KGB> 03linux 05debian/latest c4f340f 06Salvatore Bonaccorso (via 06Ben Hutchings) 10debian/ 10changelog 10config/kernelarch-sparc/config-smp * [sparc64/smp] Enable NUMA * 14https://salsa.debian.org/kernel-team/linux/-/commit/c4f340f
20:05:13 <KGB> 03linux 05debian/latest 76ebe67 06Ben Hutchings 10debian/ 10changelog 10config/kernelarch-sparc/config-smp * Merge branch 'enable-sparc64-numa' into 'debian/latest' * 14https://salsa.debian.org/kernel-team/linux/-/commit/76ebe67
20:05:48 * ukleinek doesn't understand https://bugs.debian.org/960935#31
20:06:52 <carnil> ok thank you, I have some others prepared, but I guess we are now really out of time, end meeting and discuss other off-meeting? I would have questions to some others as well
20:07:10 <waldi> #endmeeting