20250409.md

@@ -63,9 +63,9 @@ Chair: @carnil
 
 * [\#1088522](https://bugs.debian.org/1088522):
 
-Situation:  RasperryPi, OOT lkrg module, requires config setting enabled, amd64 is enabled.
+Situation: RaspberryPi, OOT lkrg module, requires config setting enabled, amd64 is enabled.
 
-Surprised that is is not consistent enabled.
+Users are surprised that it is not consistently enabled.
 
 Concerns about enabling it, since kconfig help explicitly tells that if concerned about memory, increased size of image.
 
@@ -73,19 +73,19 @@ Concerns about enabling it, since kconfig help explicitly tells that if concerne
 
 Remark: Config is enabled on amd64 because we enabled livepatch on amd64.
 
-Is livepatch for all architctures? Just going for arm64 does not sound right. (ppc64el, s390x, ... major architectures)
+Is livepatch available for all architectures? Just going for arm64 does not sound right. (ppc64el, s390x, ... major architectures)
 
-@benh: We could ask people ask people (@santiago, @eamanu) working on livepatch implementation.
+@benh: We could ask people (@santiago, @eamanu) working on livepatch implementation.
 
 @ema: livepatch only supported on amd64, but they will need as well the option on arm64 when its ready.
 
 livepatch: is patching arbitrary code and needs know where it is located.
 
-@ema: kprobes as well as arguments to enable the option.
+@ema: kprobes as well is an argument to enable the option.
 
-@ukleinek: Is it already techincally possible that depending bootparameter to get all symbols or not?
+@ukleinek: Is it already technically possible that depending on a boot parameter to get all symbols or not?
 
-@benh: possibly there is not not (yet) an option for that. Don't know if there is a mechanism for that.
+@benh: possibly there is not (yet) an option for that. Don't know if there is a mechanism for that.
 
 @ema: technically possible, but there is no bootparameter for that.
 
@@ -93,9 +93,9 @@ livepatch: is patching arbitrary code and needs know where it is located.
 
 @ema: All the other distros have it on.
 
-@enh: Main reason is for debugging and tracing, so enable it on all architectues where we have BTF enabled?
+@benh: Main reason is for debugging and tracing, so enable it on all architectures where we have BTF enabled?
 
-Agreement: enable it on all architecutes where BTF is enabled. @benh followsup on the MR, @ema will take care.
+Agreement: enable it on all architectures where BTF is enabled. @benh followsup on the MR, @ema will take care.
 
 
 * [\#1101207](https://bugs.debian.org/1101207)
@@ -106,11 +106,11 @@ Action: close the bug
 
 @ukleinek: maybe a hardware problem with RAM? Can be.
 
-@ema: could be a memeory problem.
+@ema: could be a memory problem.
 
 -> Try a memory checker, to see if they have some bad ram.
 
-@benh: we could disaselble the code.
+@benh: we could disassemble the code.
 
 We could look deeper in the code, look into exact failure but first to test hardware
 
@@ -144,9 +144,9 @@ Action. (@carnil ask for the above informations)
 
   - more information about full kernel log
 
-  - ask if it is a regresson? (maybe it is ....)
+  - ask if it is a regression? (maybe it is ....)
 
-  - do noewer kernel work?
+  - do newer kernels work?
 
   - error reported is quite uncommon.
 
@@ -156,7 +156,7 @@ Action: @ema take action to ask for more information.
 
 * [\#1101546](https://bugs.debian.org/1101546)
 
-@waldi: firware possiblly not loaded?
+@waldi: firmware possibly not loaded?
 
 @benh: suspect BIOS update did reset things harder and made wifi work again
 
@@ -164,9 +164,9 @@ Action: @ema take action to ask for more information.
 
 Action: possible ask for kernel log for working system and nonworking state?
 
-@waldi: the reporter does not have the correct firmware, fails to load every firmware it tries? Linux is not able to load the firwware.
+@waldi: the reporter does not have the correct firmware, fails to load every firmware it tries? Linux is not able to load the firmware.
 
--> We do not have  log for a nonowrking state.
+-> We do not have  log for a nonworking state.
 
 Linux tries to detect the HW and fails with timeout.
 
@@ -180,19 +180,19 @@ User should use first reportbug
 
 Ask for a proper report, if nothing comes back close the bugreport
 
-(maybe close the bug as fixed in bookworm-backports)
+mark as fixed in bookworm-backports)
 
 @ukleinek takes action.
 
 * [\#1101940](https://bugs.debian.org/1101940)
 
-amdgpu is not only thing broken, we need more logs
+amdgpu is not the only thing broken, we need more logs
 
 should get more information / full.
 
 upstream issue which look similar.
 
-related issues are linked, not not resolution as far we can see.
+related issues are linked, no resolution as far we can see.
 
 @benh: amdgpu dkms found bug about the adding of modprobe file, filled upstream
 
@@ -204,8 +204,6 @@ related issues are linked, not not resolution as far we can see.
 
 Close the bug, there is nothing to do with with that
 
--> close the bug.
-
 -> Action: close the bug (@carnil)
 
 ### New version 6.15
@@ -222,15 +220,15 @@ Close the bug, there is nothing to do with with that
 
 * modprobe.d bug report
 
-one problem: implementation either requires debianutils from trixie or `modprobe -c`
+one problem: implementation either requires debianutils from trixie (for multi-directory support in run-parts) or `modprobe -c`
 
 considering about `modprobe -c` and filter out things out.
 
-`run-parts` does not properly skip directories which does not exist -> @waldi has to fill a bug
+`run-parts` does not properly skip directories that do not exist -> @waldi has to fill a bug
 
 * @ukleinek takes arm64 specific MRs
 
-  - @ukleinek: [arm64] Enable `ARM_CCA_GUEST` as module important for both flawours? -> so mostly usefull for cloud images but neabled for both.
+  - @ukleinek: [arm64] Enable `ARM_CCA_GUEST` as module important for both flawours? -> so mostly useful for cloud images so should be enabled for both.
 
 * Enable `CONFIG_HZ_1000`
 
@@ -240,7 +238,7 @@ So just take into consideration just for `debian/latest` not trixie.
 
 Keep it out of trixie
 
-@benh: not saying we should defintively enable them as suggested. They should just be considered as well.
+@benh: not saying we should definitively enable them as suggested. They should just be considered as well.
 
 Not urgent, we can see how it moves on.