Hi, On 03-09-2023 02:56, Michael Biebl wrote:
My main concern is to "stop the bleeding" quickly, so to speak, especially/mainly for debci.
I agree with you, but also consider that with this issue being there since ~ April 2023 we don't need to rush.
I guess we have three options here: a/ upgrade the kernels to the one from backports as suggested by Antoniob/ disable apparmor confinement for lxc on debci via some debci specific configuration c/ disable apparmor confinement for lxc in bookworm via a stable upload of the lxc package
That said, I would be fine with a/ and b/ as well, as this would buy us time to investigate this issue without being under the pressure of causing debci failures.
What I fear a bit, is that if we do either of the three, Debian infra is not affected anymore which removes some incentive to find the root cause.
Those debci failures are hard to debug and I would like to avoid having individual maintainers waste time on it.
a, b, or c means that Debian maintainers don't need to dive into it anymore, but who knows which downstream project (volunteers or paid alike) will need to look into the problem in the future if we don't fix it inside packaging?
Do the debci maintainers / lxc maintainers / release team have any preference regarding a/, b/ and c/ ?
One part of me likes the ci.d.n infrastructure to run stable as an example of "eat your own dogfood". Another part of me agrees with Antonio that it makes sense if it would run a backports kernel to be as close as possible to testing as we can reasonably (maintenance wise) can get. Because we have a known issue at hand, the balance goes to backports for me. If Antonio doesn't beat me to it, I'll get to it (although I don't know yet how to do that in our configuration [1] and exclude riscv64 too). I have manually upgraded the s390x host and rebooted, so that can serve as a test arch.
Paul [1] https://salsa.debian.org/ci-team/debian-ci-config
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature