19:04:45 #startmeeting 19:04:45 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:05:08 #topic Bug #1039883: linux: ext4 corruption with symlinks 19:05:42 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 Any other comments on this one? 19:06:31 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 in short it does not matter now if it fixed within 1 week or maybe two in the end 19:07:03 #topic Bug #1063754 19:07:30 I had this one on my action list to followup with the reporter but I failed to do so 19:07:48 Can you take that as an action again this week? 19:08:11 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 Thank you! 19:08:40 #action carnil will review and follow up bug #1063754 19:08:56 #topic Bug #1057282 19:09:28 This is waiting on elbrus to test, but at least he's replied now 19:09:58 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 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 Right 19:10:50 I'll take that since I'm the uploader 19:11:03 thank you 19:11:07 #action bwh to request processing of linux packages in backports-NEW 19:12:04 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 The regression is somewhere between 6.1.y and 6.6.15 19:13:07 and some wrong firmware options on the machine, at least there are complains about ASPM 19:13:50 Yes possibly, but everything has firmware bugs 19:14:25 #action bwh to send reply to #1075855 19:14:38 #topic Bug #1074217 19:15:05 I think this is actually a duplicate of an older bug requesting a 4 kiB page size 19:15:27 move to 4k alltogether. and add a separate 16k for arm64 and 64k for ppc64*? 19:15:43 or ignore ppc64 and only provide 4k 19:15:58 arm64 needs a 16k, as some hardware does not longer support 4k 19:16:00 I think some people wanted 4 kiB on ppc64 as well 19:16:26 yes, move it to 4k and stop providing 64k 19:16:31 It sure would be nice if Arm wouldn't make everything optional 19:17:11 I'm OK with doing 2 page sizes on ppc64{,el} as we only have one flavour there 19:17:35 so switch the default one to 4k and add a separate 64k one 19:17:41 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 no, would be only one new 19:18:46 What if someone wants to use RT on a machine that requires 16K pages? 19:19:52 *shrug* 19:20:23 the RT kernels by default do not run of EFI 19:21:44 That's odd, but not sure why it's relevant 19:21:59 i would ignore RT for 16k arm64 until this hardware gets more common 19:22:49 OK, so we need to add the 16K option for arm64, and the 4K option for ppc64 and ppc64el 19:23:27 If we change the default for ppc64* we need to be careful to not switch page size on upgrade 19:23:33 why? 19:23:37 what breaks if we do? 19:24:14 Some filesystems are unmountable with block size > page size 19:24:59 Also I think the swap partition would become invalid 19:26:55 So, does anyone want to work on this? 19:28:30 * carnil cannot take it 19:28:36 i can take this 19:28:49 and we have release notes 19:29:08 Release notes don't help unstable users 19:29:53 i just checked popcon. we talk about .003% of installations 19:30:07 anyway 19:30:27 #action waldi will handle #1074217 and also look at similar needs for arm64 19:30:49 #topic Bug #1075770 19:31:39 Mystery i915 regression. I haven't investigated it. Probably needs to be forwarded to the upstream bug tracker 19:32:18 Actually it might not be a regression 19:32:30 Can anyone take care of that? 19:32:55 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 Yes I think that is what is needed 19:33:28 I think Francesco would be skilled enough and we would just be in the middle 19:34:44 So will you reply to the bug? 19:34:49 I will take him to reply on the bug 19:35:05 aehm, I wanted to say: Yes I will take it and reply to the bug 19:35:30 #action carnil will handle #1075770 19:35:47 #topic Bug #1075780 19:36:08 The plain text of this report is unreadable but the HTML version is OK 19:36:24 Anyway - might be an initramfs-tools bug, but it's not yet clear 19:36:58 "not executable" is weird 19:37:11 No that's normal 19:38:55 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 #action bwh will handle #1075780 19:39:48 I believe I understand the bug and can go ahead and fix it 19:40:38 So I'll take this one as well 19:40:46 #action bwh will handle #1074359 19:41:18 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 iam_tj[m]1: Correct, but I *think* the log message changes the reported path 19:42:28 ahhh, as in one of the scripts to be included isn't executable? 19:44:03 No that's not it 19:44:17 Let's discuss that after the meeting 19:45:03 For bug #894906, there is (effectively) a patch provided, so that needs a review 19:45:37 Does anyone have time to look at that and turn it into an MR? 19:45:40 this does not look like a proper solution 19:45:57 i might be able to get to that 19:47:02 That sounds like a "maybe", so I won't make that an action 19:47:19 #topic New upstream versions 19:48:14 wireless-regdb would be a pain for anyone else to handle, so I will take care of that 19:48:29 Would anyone like to update ktls-utils? 19:48:49 #action bwh will update wireless-regdb 19:48:53 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 s/containing/continuing/ 19:49:42 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 OK, I doubt it's urgent 19:50:25 #topic Any other business 19:50:39 not today 19:50:59 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 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 bwh: for me yes go ahead 19:52:16 i should be available next week 19:52:57 And are we trying Jitsi again next week? 19:53:11 works for me to try it again 19:53:45 i'll try to see what broke 19:54:13 Is that a yes? 19:54:34 yes 19:54:58 #agreed Next meeting on Jitsi; waldi will chair 19:55:04 Thanks all 19:55:06 #endmeeting