Dear maintainers, src:libqb currently fails to build on loong64 buildds because of a linux kernel OOPS. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1145111#35 As migration of libqb is stalled because of this, can you maybe upload a new version that either doesn't run the test suite on loong64? Or if you know which test is causing the OOPS, maybe skip that one on loong64. Once the kernel is fixed, the change can be reverted of course. The rustc package did something similar: https://salsa.debian.org/rust-team/rust/-/commit/8fb12a317768d55ac880a97f989c04919763c23b Paul
Paul Gevers <elbrus@debian.org> writes: Hi Paul, I've been keeping an eye on that bug since the latest libqb upload. Honestly, I don't understand why it affects the loong64, powerpc, ppc64 and sparc64 buildds only. Credential passing over UNIX sockets is core functionality of libqb. Skipping the libqb build time (and autopkg-) tests would certainly be possible, but I'm worried that the built library would trigger the same OOPS running the tests of the entire HA stack above it (kronosnet, corosync, pacemaker, and so on). The current libqb package (2.0.9-1+b1) apparently did not fail the latest corosync build for example, but like above, I don't understand why and thus I don't know what to expect from disabling the tests. Can you perhaps provide some additional insight here?
Hi Ferenc, I don't think I have additional insight. Except that I'm wondering if it's worth holding back the update of libqb for this kernel issue on an architecture we haven't release with yet. Do you think this could be a mis-compilation that we would slip into testing? I was expecting/hoping this is a kernel issue, so it might affect the version of libqb in testing already if the kernel it runs on is affected. Also Aurelien showed he can trigger the issue on all architectures, but apparently only testsuites on loong64 trigger it in the wild. I just ran the autopkgtest in testing on ci.d.n manually, it passes. I also run an autopkgtest from an unpacked source version 2.0.10-1, which means that autopkgtest builds the binaries and runs the autopkgtests. They pass. Build time tests are skipped by autopkgtest builds though. loongson@ci-worker-loong64-01:~$ uname -a Linux ci-worker-loong64-01 7.2.11+deb14-loong64 #1 SMP PREEMPT Debian 7.2.11-1 (2026-10-15) loongarch64 GNU/Linux Paul
Paul Gevers <elbrus@debian.org> writes: Clearly not, I fully agree. And PowerPC and Sparc buildds, if I read the report correctly. But why these buildds? Do they run a different kernel version of use some alternative apparmor settings? Thanks for this info. I still worry a little about breaking the build time tests or autopkgtests of the downstream packages, but we'll see, I guess. I'm uploading a new libqb with its build time tests disabled.
Hi, Thanks, but for avoidance of doubt, I hope only on the affected architectures. Paul