20:00:24 #startmeeting 20:00:24 Meeting started Wed Mar 19 20:00:24 2025 UTC. The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:28 Hello 20:00:33 hi 20:00:34 welcome to todays meeting 20:00:37 #chair bwh carnil 20:00:37 Current chairs: bwh carnil waldi 20:00:45 anything we should handle first? 20:01:16 * ukleinek reminds about his question about #d-k-internal 20:02:02 I think for some coordinations a more private channel is useful, so I'd welcome usage of that channel 20:02:31 I joined, I often forget to re-invite myself ;-) 20:03:00 ack, joining automatically is a bit annoying. I didn't look into automating that, but I guess that would be possible. 20:03:33 I think I joined that channel and then forgot about it, and didn't include it in my configuration 20:04:02 I'm not very active on IRC generally at the moment though 20:04:11 If it helps I can work out a configuration snippet for irssi to autojoin. 20:04:51 ukleinek: would be nice if you find time, otherwise it's okay for as it is, other priorities first 20:07:44 should we move to the next topic? :) 20:07:54 #topic #1099655 - initramfs-tools 146 generates incorrect initramfs : does not boot, does not find root fs 20:08:20 reading through the report this only affects a self-compiled kernel, so the severity is excessive 20:08:26 I am handling this, and need to reply to the submitter 20:08:56 There is also a second person reporting a probably different bug there who I should redirect 20:08:56 the last reply is from the submitter 20:09:45 bwh: Eduard Block in #96 ? 20:09:50 yes 20:10:23 #action bwh is handling this 20:10:43 #topic #1076372 + #1090717 20:10:52 For the meeting sumary "this" isn't so helpful as it's quoted without topic as context 20:11:06 ukleinek: it is listed directly below the topic 20:11:22 glad if I'm wrong 20:11:49 There is a summary of actions which I think doesn't give that context though 20:11:51 there is an additional actions section which will be bit without context 20:13:27 on https://bugzilla.kernel.org/show_bug.cgi?id=219609 the last message ist still from some weeks ago and status did not change. STll think that the conclusion was that's on the BIOS vendor side to release a fix 20:13:37 but I might have a wrong understanding still 20:13:50 Nothing new in the bug logs either 20:14:23 Should we ask the reporter directly now whether the BIOS update addresses both bugs? 20:14:36 Does the BIOS update fix both bugs, or only the first? 20:14:44 unknown 20:15:21 so yes we should ask the reporter 20:15:55 * ukleinek still isn't at the top of his health, so I don't want to volunteer for much this week. 20:16:17 https://bugzilla.kernel.org/show_bug.cgi?id=219609#c111 20:16:28 there stefan say: 20:16:41 with that firmware ASRock can't reproduce the corruptions anymore. 20:16:52 but not clear to me out of the long context 20:17:02 Yes but Stefan wasn't able to test it at that point 20:17:59 so let's ask him directly if he was able to test the bios update and if it fixes all cases he did report 20:18:04 I can take this as action 20:18:18 in the hope we get an idea for the next meeting :) 20:18:51 #action carnil ask reporter of #1076372 + #1090717 if BIOS update was tested and if it fixes the reported corruptions 20:19:06 #topic #1100008 20:19:59 bwh did some change, but this needs documenting the interface he now cemented 20:20:02 I opened an MR to fix this. I was hoping for a review from bdrung but haven't had that yet. 20:20:25 waldi: I just saw your comment. I agree the behaviour should be documented. 20:20:39 MR for initramfs-tools, or one of the other affected packages? 20:20:45 for initramfs-tools 20:21:00 the problem is: the behaviour might be not really sensible 20:21:21 Indeed, it would actually make more sense to concatenate all the cpios and unpack them in one go 20:22:07 And it would make way more sense to do the processing in a C or Rust program, not shell, but I'm not going to do that before trixie release 20:23:05 Context: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/162 20:23:18 #action bwh will handle waldi's review comment 20:23:46 #topic #1025476 20:24:06 This is an old bug that received an entirely unrelated follow-up 20:24:33 I think the follow-up is just saying there's newer and better MT7921E firmware available upstream? 20:25:03 yes, it is 20:25:29 no response from submitter since last contact over a year ago. just close? 20:25:40 Yes I think it can be closed 20:25:49 #action waldi to close #1025476 20:25:56 #topic #1100694 20:26:07 * ukleinek saw a MR for that IIRC 20:26:16 it is merged 20:26:25 I have enabled it in debian/latest and intent to as well take as backport for 6.12.y upload 20:26:37 #topic #1100153 20:27:52 nothing conclusive during bisecting. carnil was last in contact 20:27:53 this needs some ideas. I asked the reporter to bisect, which he started with, but ended not indentifying a commit. But reporter noticed that same version upstream without Debian patches fail similarly. 20:27:59 the summary is in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100153#37 20:28:12 so if someone has ideas what to go trying next that would be helpful for brian 20:28:37 otherwise I will try to have a closer look again this week 20:28:57 I can take a look 20:29:17 #action ukleinek to look into #1100153 to provide further directions 20:29:40 #topic #1087326 20:30:19 was fixed in newer linux-firmware release 20:30:34 #topic #1100723 20:31:05 Not a bug, firmware-ralink was removed after buster 20:31:18 #action bwh will close #1100723 with explanation 20:31:35 #topic #1100733 20:31:47 #1087326 is properly handled? Does someone care for a newer linux-firmware release? 20:32:45 New versions of firmware-nonfree have CI problems due to the orig.tar.xz getting too big. We can discuss at the end. 20:32:53 ack 20:33:27 * ukleinek wonders about the 2nd boot succeeding in #1100733 20:33:30 this one is weird. fails after initrd rebuild, but not otherwise. would require logs 20:33:56 okay. i'm handling that 20:34:11 #action waldi to request further infos for #1100733 20:34:19 I suspect that it actually has nothing directly to do with initrd rebuild 20:34:30 yeah 20:34:43 #topic #1088739 20:35:04 should as well update to a current kernel 20:35:55 ukleinek: this was your action? 20:36:37 Given the emotions there I think the only sensible way forward is an upstream patch. 20:37:01 Someone would have to come up with a sensible patch for that ... 20:37:25 disable colors by default is a sensible patch 20:37:52 or alternatively switch back to the upstream default for the color selection (which is never) 20:37:53 * ukleinek would suspect this not to hit uniform acceptance 20:37:57 and then probably nobody is happy 20:38:38 --color Default color output configuration. Available options: 20:38:41 never: color output is disabled (default) 20:38:44 auto: color output is enabled if stdout is a terminal 20:38:47 always: color output is enabled regardless of stdout state 20:38:56 this is the default configure, and we override it with dh_auto_configure -- --color=auto 20:38:57 At a minimum, we should probably add support for the NO_COLOR environment variable to override this 20:40:03 Not sure how widely supported that is, but it's intended to be a general opt-out of coloured output 20:40:39 #action ukleinek looks into color handling for iproute2 (#1088739) 20:40:48 no promise about timely handling though. 20:41:04 so what are we doing _now_? 20:41:17 discussing the next bug? 20:41:20 this goes on for months. we decided here that it needs to be fixed 20:42:06 I'm not convinced we can (or should) force a "fix" 20:42:24 we represent the maintainer of this package. so yes we can 20:42:38 I guess I can take an action to support NO_COLOR, which I hope would be easy 20:43:33 Is that enough for now? 20:43:35 I guess coming up with a saner color choice than dark-blue on black also isn't that hard, just needs some time for evaluation. Bot would indeed be fine. 20:43:43 s/Bot/Both/ 20:43:57 For me this is good enough. 20:44:17 #action bwh will try to add NO_COLOR support to iproute2 20:44:30 okay 20:44:55 #topic #1054642 20:45:22 submitter considers this fixed 20:45:29 #action waldi to close #1054642 20:45:34 sort of 20:45:36 Only partly fixed, I thought? 20:45:38 there were two parts apparently 20:45:51 Quoting the reporter "I've retested the OP and confirming L2 path problem vanished, so from this perspective this case can be closed. Problem with reflecting (I originally called "duplicated") VM-ingress packets with VETH/MACVLAN setups is present." 20:46:02 the original problem is fixed, there is a 2nd issue. But that's hard to follow for me. 20:48:06 Either we ask the reporter to go upstream with the problem or someone has to understand the issue, e.g. by reproducing. 20:49:25 i think the submitter just describes macvlan. the traffic goes via the switch 20:50:49 he also uses that term 20:51:46 waldi: I agree this sounds like macvlan behaving as designed 20:52:06 i'll tell him 20:52:10 #topic #1100746 20:52:24 carnil was on this 20:52:44 yes I asked for more information (boot logs from both kernels), which reporter provided 20:52:56 have not yet found time to look at potential differences, but can continue handling it 20:53:13 #action carnil to continue on #1100746 20:53:18 is udisksctl still a right tool? 20:54:38 another relevant question seems to me: Is it udisksctl that is responible for mounting the card when it's replugged? 20:54:41 udisks is the stuff used by gnome and kde for handling removable disks 20:55:14 yes, it usually is. if not listed in fstab 20:55:23 I guess that's a normal tool for unprivileged users to use 20:55:40 waldi: I think you skipped bug #1100659? 20:56:18 #topic #1100659 20:57:37 is it relevant which network daemon is used, or is it already clear this is a kernel issue? 20:57:58 The PCI device is not coming out of suspend. It's not a user-space issue. 20:59:28 This could be a hardware, (system/device) firmware, or kernel bug 20:59:35 Would be nice to know if this is a regression 20:59:44 while it is another driver I wonder if this is a regression and if so iif it's the same as https://lore.kernel.org/regressions/415e7c31-1e8d-499b-911e-33569c29ebe0@gmail.com/T/#m80ed7853c8653195599cbe6a37afd4a6b73c8e22 20:59:49 right, that's one thing we could ask 21:00:30 while at it, we should also ask if rmmod + modprobe works fine on a fresh boot (i.e. without suspend) 21:00:31 carnil: That seems like a different problem to me, but it's possible 21:00:40 ukleinek: yes 21:01:17 there are older reports of this happening with r8169 21:01:41 yes, but there are about a million different chips supported by this driver 21:02:56 okay. we are out of time 21:03:21 Can I briefly ask for opinions on how to handle firmware-nonfree updates? 21:03:31 #topic firmware-nonfree updates 21:04:26 As previously discussed, the source package is nearly at the limit of what Salsa allows as a CI artifact 21:04:35 The next upstream version will go over that 21:04:48 I have asked for an increase but I don't know when or whether that will happen 21:05:27 you asked in #salsa I assume? Or via mail? 21:05:34 As an issue 21:06:13 ping the issue in #salsa? 21:06:35 Well my questions was whether I should wait, or try to test and merge MRs locally? 21:06:57 for context: https://salsa.debian.org/salsa/support/-/issues/465 21:07:03 * ukleinek would trigger a failure and then wail on irc 21:07:17 OK 21:07:33 #action bwh will raise the firmware-nonfree artifact size issue on #salsa 21:07:47 Thank you 21:07:50 #topic AoB 21:07:53 anything else? 21:08:31 who wants to chair next week? 21:08:43 Is it my turn? 21:08:59 * ukleinek was skipped, but I don't want to make up for it next week. 21:09:15 #action bwh will chair next weeks meeting 21:09:23 thank you everyone for joining 21:09:24 thank you all 21:09:30 #endmeeting