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