20:00:20 #startmeeting 20:00:20 Meeting started Wed Feb 25 20:00:20 2026 UTC. The chair is bwh. Information about MeetBot at https://wiki.debian.org/MeetBot. 20:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:20 hi 20:01:20 waldi: Are you here? 20:01:21 * ukleinek is not aware of anything to discuss before the regular agenda 20:01:36 yes 20:01:37 I only had one question ,but it only make sense if waldi is here 20:01:49 hi 20:01:53 6.19? 20:02:03 no it was about build-arm64 20:02:25 Go on 20:02:54 because of our salsa pipieline failure I was earlier today asking in #salsaci on the status of build-arm64, santiago said that he talked to Bastian and Alex about providing shared runner for arm64. 20:03:14 unfortunately he cannot attend todays meeting, so I try to formulate the question 20:03:59 is there still something we plan to do on google(?) cloud infrastructure, or has this become more complicated and should we disable the build-arm64 build job for now? 20:04:06 there where a lot of talk. right now the salsa people need to finish the runner setup upgrade 20:04:21 just build it on a amd64 root 20:04:39 (rustc is still broken, and maybe some python thing, but well) 20:05:12 after the new runner setup is in place, salsa can expand to provide arm64 build systems 20:05:25 Should we disable build-arm64 by default until that is done? 20:05:52 or you fix it to not care about the architecture of the underlying system 20:06:39 That sounds like a fair amount of work 20:07:01 it isn't, really. maybe sbuild is not suitable for the job, but otherwise that's easy 20:07:26 OK, but until that is done, would it make sense to disable build-arm64 so we don't have spurious failures due to lack of a runner? 20:07:31 yes 20:07:45 ok! 20:08:51 carnil: Are you OK with making that config change? 20:09:13 bwh: ok then I look into making this config change 20:09:49 #action carnil disables the build-arm64 job to work around ci failures 20:10:12 Any other urgent issues, before the bug list? 20:10:32 idk 20:10:38 6.19? 20:11:08 you want to move 6.19.y to unstable I guess you mean by that 20:11:21 yes. sorry 20:11:29 there is currently 6.19.4 in review, with a huge batch of commits (because the merge window) 20:12:02 not sure if we want to do only after 6.19.4, so with 6.19.5 or so the switch? 20:12:25 but I have not a strong opinion, 6.18.y would be a LTS branch so perfectly suitable to keep a bit longer in unstable if we think it helps 20:12:49 I have some weak arguments maybe to keep another bit so, but then we are blocked for 7.0-rcX to experimental 20:12:54 +1 for no strong opinion 20:12:56 i don't think it helps us really 20:13:31 okay, lets wait for .5 or so 20:13:33 if you want to move it to unstable soon (i.e. right now, then let me please do the last 6.18.y upload as prepared) 20:15:01 i have no hard feeling, just want to know a plan. because i don't want to do some changes right now 20:15:13 that looks decided then and we dive into the bugs? 20:15:18 yep 20:15:19 #agreed unstable will get at least one more 6.18.y upload 20:15:35 #agreed 6.19 should go into unstable starting with 6.19.5 20:15:46 I will upload 6.18.13-1 tonight or tomorrow 20:15:58 #topic #1127635: (i, M) linux-image-6.18.9+deb14-powerpc64: fails to boot on IBM 8204-E8A (POWER6 p550) LPAR, NULL deref in PCI MSI setup 20:16:30 that's a wait 20:16:33 No update in the last few hours, so this one is still waiting for moreinfo 20:16:40 #topic #1128396: (i, uM) linux-image-6.12.69+deb13-amd64: Black screen on boot with Intel Meteor Lake xe driver (PCI ID 7d55) 20:17:21 We got some logs but I think are still waiting on a bisection 20:17:42 should we ask again for the bisection? 20:17:42 ..ooOO(The reporter could install iwconfig ... :-) 20:17:59 carnil: That might be worth doing 20:18:04 (the last mail I got privately I did forward, none other since then) 20:18:19 #action carnil ask again for bisection for #1128396 issue 20:18:24 ukleinek: Or remove whatever ancient program wants iwconfig 20:18:32 bwh: I will ask again for the bisection then 20:18:35 #topic #1128632: (i, ) linux-image-6.12.73+deb13-amd64: boot failures, ACPI errors, and sleep issues on ASUS Sabertooth Z77 (i7-3770K) 20:19:56 This has some logs but I think we need kernel boot logs for both the old and new versions 20:20:09 "Failed to decompress kernel" is strange, I only know that from RAM problems, but given that earlier kernels are stable that is not likely 20:20:21 Yes that's very puzzling 20:21:01 the ACPI errors are probably not relevant 20:21:06 and "git log v6.12.69..v6.12.73 drivers/firmware/efi/ arch/x86/boot/" shows nothing 20:21:22 ukleinek: Yes that's why I think we need kernel logs from both to compare 20:22:08 #action bwh will ask for kernel boot logs for #1128632 20:22:19 👍 20:22:29 #topic #1121192: (n, M) kworker: Events_unbound, kworker processes, continually using CPU. 20:24:06 I still have an action from last week to respond to this 20:24:08 the 3 kworker processes are probably a red herring, other than that no idea. 20:24:50 so nouveau uses kworker, the proprietary driver does not 20:25:27 maybe stupid question, but the performance impating issues the user is seeing go away using the proprietary nvidia driver, but are present using nouveau 20:25:34 Well, nouveau with missing firmware. I'm not sure how that even works at all 20:25:46 carnil: That is my reading, yes 20:26:29 we don't even have a tu117 firmware in unstable if i checked that correctly 20:26:29 is nouveaudrmfb a fallback mode? 20:26:33 no 20:27:00 so maybe the user can test as well newer kernels from backports, or ideally even 6.19.3 in experimental and see if things are more smooth 20:27:12 bu reading the above, if we have firmware missing then this suggestion as well is moot 20:28:40 We do appear to have that firmware in current firmware-nvidia-graphics 20:29:48 with the firmware files the kernel locks up, that's why they are not installed. 20:29:55 However, firmware-nvidia-graphics doesn't trigger update-initramfs, which it should 20:30:56 So, we have at least 2 bugs here: nouveau locks up with firmware present, and firmware-nvidia-graphics doesn't trigger update-initramfs 20:31:30 +1 for letting him try backports and/or 6.19 20:31:33 #action bwh will fix firmware-nvidia-graphics to trigger update-initramfs 20:32:16 #action bwh will ask reporter of #1121192 to test with nouveau *and* firmware installed, on newer kernel versions 20:32:34 #topic #1126957: (n, u) kernel panic when repeatedly trying to mount an nfsv4 share with mtls and failing 20:33:24 This is waiting on a response from upstream, so nothing to do on our side I think? 20:33:42 unless someone feels I have done something wrong in my testing 20:33:55 but the ktls-utils autopkgtest was very helpful to get it reproduced as reported upstream 20:34:00 but from there no idea 20:34:10 so wait yes for upstream 20:34:15 * ukleinek didn't check what carnil did, so no feeling he did something wrong :-) 20:34:30 #topic #1127612: (n, u+) linux-image-6.12.69+deb13-amd64: hp_bioscfg mm/page_alloc.c:4802 warning 20:34:42 patch in the making upstream 20:35:33 ah very nice, and it has all we need to not miss it: 20:35:40 The patch author even forwarded the reporters tested-by 20:35:49 Cc: stable@vger.kernel.org and Closes: https://bugs.debian.org/1127612 20:36:03 I'm worried that there is a kfree somewhere that should now be kvfree 20:37:01 Unless kfree somehow automatically forwards to vfree now?? 20:37:32 yes, it is kfree 20:37:39 in hp_exit_enumeration_attributes 20:38:31 kfree forwarding to vfree would be news to me 20:38:35 right, and I see no sign that kfree is now equivalent to kvfree 20:38:44 #action bwh will reply to patch for #1127612 20:38:56 bwh: good catch 20:39:15 Easier to spot in a very small patch :-) 20:39:21 #topic #1127688: (n, M) linux-image-6.18.9+deb14-amd64: Crash to black screen with QR code to log 20:39:56 This is waiting for moreinfo 20:40:03 * ukleinek nods 20:40:10 non-canonical address. broken memory? 20:40:28 ah, yes 20:40:29 waldi: that's why I asked for memtest 20:40:36 #topic #1128397: (n, Mu) linux-image-6.18.10+deb14-amd64: open(/proc/$pid/maps) is empty after $pid exec()s, unless you read a partial line from the fd before, in which case it has the rest of the line only 20:40:47 wow 20:41:00 I updated this just before the meeting. Not convinced this is a bug at all 20:41:31 no, i don is no bug 20:41:53 no, i don't think this can count as bug. /proc is weird, but correct in this case 20:41:58 #topic #1128626: (n, u) btusb: add 2c4e:0115 (Mercusys MA530, RTL8761BU) 20:42:45 there were multiple attempts to submit a patch upstream and none was picked 20:42:49 There is an upstream patch, not yet applied I think? 20:42:55 OK 20:43:09 So we can wait for that to happen 20:43:20 #topic #1128834: (n, u) linux-image-6.1.0-43-amd64: NFS client regression in 6.1.162: large rsize/wsize (1MB) causes EIO 20:43:25 yes see the list of forwarded references, all got postings to upstream 20:44:12 oh I guess I should say something here and you are waiting on my input. 20:44:35 The problem is only reproducible with NFS server from EMC Dell 20:44:41 Right 20:45:02 Maybe that deserves some kind of workaround in the kernel, I don't know 20:45:19 does this count as we still should forward the issue? I think the reporter is right that the problem is more on the Powerscale OneFS NFs server side and they should handle it 20:45:44 maybe forward this as a question to linux-nfs and see what the experts there think 20:45:50 Right, I agree with that 20:46:08 I take a (low prio) action on that and make sure the question goes to linux-nfs 20:46:19 Thanks 20:46:38 #action carnil follows up for #1128834 with linux-nfs to see if a workaround needs/should be implemented on kernel side 20:46:41 "brilliant tutorial!" 20:46:50 #topic #1128861: (n, ) linux: when serving NFS, client attempts to lock served files fail with "No locks available" 20:46:51 ukleinek: I referred that it comes from you 20:47:09 \o/ 20:47:58 I think this is waiting on a response from upstream 20:48:13 * carnil nods 20:48:21 iam_tj[m]: thanks for working on that 20:48:37 #topic #1126710: (w, ) linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set (merged with #1128422) 20:49:17 I discussed this with carnil and I think we agreed this should be reverted for trixie-backports only 20:49:31 I still have an action to document the change in NEWS and release-notes 20:49:40 * carnil nods 20:49:50 can a v4 fs easily be upgraded to v5? 20:49:54 no 20:50:00 #action bwh will reenable CONFIG_XFS_SUPPORT_V4 for trixie-backports 20:50:10 (that is something to mention in the NEWS entry?) 20:50:11 ukleinek: full backup, restore cycle 20:50:17 ukleinek: yes 20:50:47 #topic #1124400: (n, u) update-initramfs no longer includes /lib/modules//updates directory 20:51:31 This was rejected upstream. We might need to carry a patch for it so switching initramfs-tools -> dracut doesn't regress. 20:51:59 Oh, wait, this is in dracut-install so both are affected 20:52:19 is there a reasoning from upstream about the 'not planned'? 20:52:34 There is some more discussion on the linked pull request 20:52:55 ah found it in the related pull request 20:52:56 thanks 20:53:35 #action bwh will discuss #1124400 with bdrung etc. 20:53:58 #topic #1128969: (n, +) dracut: autopkgtests fail on arm64 20:55:03 I didn't look into this so I don't have any opinion on whether it's a good change 20:56:03 I'm happy to leave this for bdrung to respond to 20:56:13 sounds good 20:56:21 #topic #1128598: (n, Uu) rtl8852bu: bluetooth audio suttering at random 20:56:40 if it were me, I'd find a qemu guy to explain cpu=max 20:56:42 firmware-nonfree is outdated in trixie-backports and I should fix that 20:57:06 #action bwh will update firmware-nonfree in trixie-backports 20:57:31 which I think would fix this bug but I'm not certain if the version is testing is new enough 20:57:48 #topic #1064620: (w, +) firmware-nonfree: suggestions for the packaging, gencontrol.py and debian/rules 20:58:13 This originally had far too many patches for me to properly review 20:58:27 let's ask the guy to create a MR instead of a patch list in a bug? 20:58:52 I might do that. From a quick look earlier I think what's left there is reasonable 20:59:07 #action bwh will review #1064620 and possibly ask to create an MR 20:59:18 #topic #1128562: (m, ) /usr/bin/linux-check-removal: Use of uninitialized value $_[2] in join or string at /usr/share/perl5/Debconf/Client/ConfModule.pm line 122. 20:59:37 bwh: it seems you have all the actions today, you wanna share a bit? 20:59:59 OK 21:00:15 I don't think I took many last week, and I am trying to move things along 21:00:48 but, if you want to take over a specific action... 21:01:16 bwh: I don't feel competent for many things, but I can look over your list once meetbot created it and take some of them. 21:01:25 OK, thanks 21:02:50 It seems like this bug report comes from using linux-check-removal, which wants to use debconf, without a debconf front-end 21:03:07 TIL linux-base provides linux-check-removal 21:03:37 I reduced severity but I think this should either be wontfix or result in a documentation change 21:04:16 Anyone else want to investigate this one? 21:04:39 * ukleinek wonders if this should better be located in /usr/lib/linux-base or similar instead of /usr/bin 21:04:59 Oh, maybe 21:05:05 but it's a bit late for that now 21:05:12 * ukleinek nods 21:05:35 #action bwh will investigate #1128562 21:05:37 sorry joining from alternative location, once again flaky/unreliable network 21:05:50 #topic Migration excuses 21:06:01 * ukleinek thinks #1128562 won't be among the bugs he can reasonably work on 21:06:29 hexagon-dsp-binaries is now updated in unstable, but no binary packages have been built so firmware-nonfree is still blocked 21:07:07 I opened #1129001 for that 21:07:30 Anything else to discuss on this topic? 21:07:49 no 21:08:00 no 21:08:06 #topic New upstream versions 21:08:40 I'm not sure why the experimental version is shown there for linux 21:09:28 We already discussed linux, which leaves firmware-nonfree needing an update 21:10:29 Well I will probably get around to that, but will not promise it on top of my other actions 21:10:36 #topic Merge requests 21:11:22 Do any of these need discussion? 21:11:49 I'll assume not 21:11:52 #topic AOB 21:11:53 no 21:11:55 the ci backport should be done soon?! 21:12:03 yes I do 21:12:03 yes 21:12:36 done already for debian/6.18/forky, picking them "soon" for debian/6.12/trixie and debian/6.1/bookworm 21:12:44 I started to look into the tracefs mount location and affected packages. Was too complicated for my available time then 21:12:47 bwh: has already cherry-picked for debian/5.10/bullseye-security afaics 21:13:11 For bookworm I expect there will probably be a conflict, but you should be able to follow my resolution for bullseye 21:13:51 OK, so who will chair next week? 21:14:26 it's jitsi, so I can do it unless someone else wants to 21:14:29 i would prefer to not chair, i'm still a bit unstable 21:14:59 ukleinek: would be appreciated, can half-promise to be able to pick then the next one 21:15:12 #action ukleinek will chair next week 21:15:23 OK, anything else before I close the meeting? 21:15:50 not from me 21:15:50 not from my side 21:15:51 not from my side 21:15:57 Thanks all! 21:15:59 #endmeeting