On Sun, Feb 21, 2021 at 07:32:19PM +0100, Paul Gevers wrote: > On 21-02-2021 14:02, Jerome BENOIT wrote: > > please consider to tag #982719 as bullseye-ignore > > given that the issue is not a package issue but > > it seems rather related to an chroot issue. > > A fresh upload from mere hours ago built successfully on our buildd > infrastructure with > Kernel: Linux 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) > amd64 (x86_64)
No, it didn't. On that buildd server kernel.unprivileged_userns_clone must have been 0 which effectively disables the test suite as can be seen in the build log[1]: ... Making check in tests make[2]: Entering directory '/<<PKGBUILDDIR>>/tests' make check-local make[3]: Entering directory '/<<PKGBUILDDIR>>/tests' echo "Unprivileged user namespaces not enabled - not running tests" Unprivileged user namespaces not enabled - not running tests make[3]: Leaving directory '/<<PKGBUILDDIR>>/tests' make[2]: Leaving directory '/<<PKGBUILDDIR>>/tests' make[2]: Entering directory '/<<PKGBUILDDIR>>' make[2]: Nothing to be done for 'check-am'. make[2]: Leaving directory '/<<PKGBUILDDIR>>' make[1]: Leaving directory '/<<PKGBUILDDIR>>' ... The buildd admins need to decide if they want kernel.unprivileged_userns_clone to always be 1 or 0 before every build (or is it upon the package to specify that?). Otherwise this will introduce breakage randomly as the setting gets toggled. > Does that mean this bug is not yet fully understood? (Or did I miss > details, I didn't read the bug in *full* detail.) It's understood alright. The gist is that the test suite relies on a rather new system call named unshare(2) which cannot be used in a chroot environment when called with CLONE_NEWUSER -- at least that's what the manpage says. (I expect this issue to affect more packages in the future since unshare allows for convenient unit testing of network and firewall code without mockups). I read about an sbuild backend that uses unshare instead of schroot which could help, but the manpage called it "experimental". All this somewhat makes this an issue with the buildd environment itself, thus raising the question of how this bug should be handled. By disabling the test suite and reuploading, or through a bullseye-ignore? The latter would have the advantage of keeping this on the table for when others run into this. Regards, Dennis. 1: https://buildd.debian.org/status/fetch.php?pkg=firehol&arch=all&ver=3.1.7%2Bds-1&stamp=1613917812&raw=1
