19:04:45 <bwh> #startmeeting
19:04:45 <MeetBot> Meeting started Wed Jul 10 19:04:45 2024 UTC.  The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:04:45 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:05:08 <bwh> #topic Bug #1039883: linux: ext4 corruption with symlinks
19:05:42 <bwh> Fix for this is in the ext4 repository, but not released. I would want to wait for it to get some wider testing before cherry-picking it
19:06:08 <bwh> Any other comments on this one?
19:06:31 <carnil> I agree, I think we even can wait until after it's applied in mainline, that it is picked up for the stable series, then we have some additional assurance
19:06:48 <carnil> in short it does not matter now if it fixed within 1 week or maybe two in the end
19:07:03 <bwh> #topic Bug #1063754
19:07:30 <carnil> I had this one on my action list to followup with the reporter but I failed to do so
19:07:48 <bwh> Can you take that as an action again this week?
19:08:11 <carnil> yes I can take it again and will try to do it in this week to not have it lingering around further
19:08:22 <bwh> Thank you!
19:08:40 <bwh> #action carnil will review and follow up bug #1063754
19:08:56 <bwh> #topic Bug #1057282
19:09:28 <bwh> This is waiting on elbrus to test, but at least he's replied now
19:09:58 <carnil> correct, for reference of the meeting notes his reply in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057282#57 he will try with a 6.8.y based version
19:10:29 <carnil> though if he depends on it using it from backports it might be worth asking backports team to move it out of backports-new and process it?
19:10:40 <bwh> Right
19:10:50 <bwh> I'll take that since I'm the uploader
19:11:03 <carnil> thank you
19:11:07 <bwh> #action bwh to request processing of linux packages in backports-NEW
19:12:04 <bwh> This is really 2 bugs (unexplained init failure, and double free on init failure). I am working on a reply to it.
19:12:41 <bwh> The regression is somewhere between 6.1.y and 6.6.15
19:13:07 <waldi> and some wrong firmware options on the machine, at least there are complains about ASPM
19:13:50 <bwh> Yes possibly, but everything has firmware bugs
19:14:25 <bwh> #action bwh to send reply to #1075855
19:14:38 <bwh> #topic Bug #1074217
19:15:05 <bwh> I think this is actually a duplicate of an older bug requesting a 4 kiB page size
19:15:27 <waldi> move to 4k alltogether. and add a separate 16k for arm64 and 64k for ppc64*?
19:15:43 <waldi> or ignore ppc64 and only provide 4k
19:15:58 <waldi> arm64 needs a 16k, as some hardware does not longer support 4k
19:16:00 <bwh> I think some people wanted 4 kiB on ppc64 as well
19:16:26 <waldi> yes, move it to 4k and stop providing 64k
19:16:31 <bwh> It sure would be nice if Arm wouldn't make everything optional
19:17:11 <bwh> I'm OK with doing 2 page sizes on ppc64{,el} as we only have one flavour there
19:17:35 <waldi> so switch the default one to 4k and add a separate 64k one
19:17:41 <bwh> Less happy with doing that on arm64 since we have multiple flavours and I fear we will then need to double the number
19:18:15 <waldi> no, would be only one new
19:18:46 <bwh> What if someone wants to use RT on a machine that requires 16K pages?
19:19:52 <waldi> *shrug*
19:20:23 <waldi> the RT kernels by default do not run of EFI
19:21:44 <bwh> That's odd, but not sure why it's relevant
19:21:59 <waldi> i would ignore RT for 16k arm64 until this hardware gets more common
19:22:49 <bwh> OK, so we need to add the 16K option for arm64, and the 4K option for ppc64 and ppc64el
19:23:27 <bwh> If we change the default for ppc64* we need to be careful to not switch page size on upgrade
19:23:33 <waldi> why?
19:23:37 <waldi> what breaks if we do?
19:24:14 <bwh> Some filesystems are unmountable with block size > page size
19:24:59 <bwh> Also I think the swap partition would become invalid
19:26:55 <bwh> So, does anyone want to work on this?
19:28:30 * carnil cannot take it
19:28:36 <waldi> i can take this
19:28:49 <waldi> and we have release notes
19:29:08 <bwh> Release notes don't help unstable users
19:29:53 <waldi> i just checked popcon. we talk about .003% of installations
19:30:07 <waldi> anyway
19:30:27 <bwh> #action waldi will handle #1074217 and also look at similar needs for arm64
19:30:49 <bwh> #topic Bug #1075770
19:31:39 <bwh> Mystery i915 regression. I haven't investigated it. Probably needs to be forwarded to the upstream bug tracker
19:32:18 <bwh> Actually it might not be a regression
19:32:30 <bwh> Can anyone take care of that?
19:32:55 <carnil> Can we ask actually the reporter to fill the issue upstream and keep downstream in the loop in this case? (If needed with some guidance)
19:33:23 <bwh> Yes I think that is what is needed
19:33:28 <carnil> I think Francesco would be skilled enough and we would just be in the middle
19:34:44 <bwh> So will you reply to the bug?
19:34:49 <carnil> I will take him to reply on the bug
19:35:05 <carnil> aehm, I wanted to say: Yes I will take it and reply to the bug
19:35:30 <bwh> #action carnil will handle #1075770
19:35:47 <bwh> #topic Bug #1075780
19:36:08 <bwh> The plain text of this report is unreadable but the HTML version is OK
19:36:24 <bwh> Anyway - might be an initramfs-tools bug, but it's not yet clear
19:36:58 <waldi> "not executable" is weird
19:37:11 <bwh> No that's normal
19:38:55 <bwh> I guess I will need to handle this one, but if anyone has any ideas about what to ask I would appreciate it
19:39:04 <bwh> #action bwh will handle #1075780
19:39:48 <bwh> I believe I understand the bug and can go ahead and fix it
19:40:38 <bwh> So I'll take this one as well
19:40:46 <bwh> #action bwh will handle #1074359
19:41:18 <iam_tj[m]1> Shouldn't the ORDER files only be /in/ the initrd.img and contain the concatenated content of each of the scripts in that stage?
19:41:50 <bwh> iam_tj[m]1: Correct, but I *think* the log message changes the reported path
19:42:28 <iam_tj[m]1> ahhh, as in one of the scripts to be included isn't executable?
19:44:03 <bwh> No that's not it
19:44:17 <bwh> Let's discuss that after the meeting
19:45:03 <bwh> For bug #894906, there is (effectively) a patch provided, so that needs a review
19:45:37 <bwh> Does anyone have time to look at that and turn it into an MR?
19:45:40 <waldi> this does not look like a proper solution
19:45:57 <waldi> i might be able to get to that
19:47:02 <bwh> That sounds like a "maybe", so I won't make that an action
19:47:19 <bwh> #topic New upstream versions
19:48:14 <bwh> wireless-regdb would be a pain for anyone else to handle, so I will take care of that
19:48:29 <bwh> Would anyone like to update ktls-utils?
19:48:49 <bwh> #action bwh will update wireless-regdb
19:48:53 <carnil> I can "maybe"(!) take ktls-utils, but defintively would like to focus on containing looking at the src:linux stable imports as they get needed
19:49:08 <carnil> s/containing/continuing/
19:49:42 <carnil> so not to make it an action unless someone is found who has time for it, and then I might come to it
19:50:10 <bwh> OK, I doubt it's urgent
19:50:25 <bwh> #topic Any other business
19:50:39 <waldi> not today
19:50:59 <bwh> I didn't get any review comments for MR 1115 (Update to 6.10-rc7). Should I go ahead and merge that myself?
19:51:18 <carnil> not any other topics for today but we need to appoint the next chair, which should be waldi (but see private mail)
19:51:31 <carnil> bwh: for me yes go ahead
19:52:16 <waldi> i should be available next week
19:52:57 <bwh> And are we trying Jitsi again next week?
19:53:11 <carnil> works for me to try it again
19:53:45 <waldi> i'll try to see what broke
19:54:13 <bwh> Is that a yes?
19:54:34 <waldi> yes
19:54:58 <bwh> #agreed Next meeting on Jitsi; waldi will chair
19:55:04 <bwh> Thanks all
19:55:06 <bwh> #endmeeting