On Wed, 8 Apr 2020, Michael Biebl wrote: >> Is this workaround permanent or will systemd FTBFS again in the future?
It is not inherently permanent. If a new libseccomp version gets uploaded it will pop back up. In these cases, I’ll most likely notice it due to Multi-Arch skew (my x32 system has libudev1:i386 and libudev1:x32 installed, so when the former shows up in apt’s output of “not updated” packages I’ll know), and it’s a matter of maybe half an hour to bring the hack back, and I’ve got permissions to give-back the systemd package so the buildds will build it. >> If seccomp support on x32 is causing so much trouble, we can just as >> well disable it in systemd for the time being by dropping libseccomp-dev >> from Build-Depends. My hope is to get this fixed in the kernel headers instead; it seems like a straight-forward fix, aligns x32 more with other architectures and seems to be the technically more correct solution, plus other packages might be similarily affected (but don’t show it as they don’t build with -Werror=format). >... on x32 only, of course. Yes, of course. >> Let me know what you prefer. For now, don’t take any action in systemd, and we’ll hope some kernel developer picks it up, but thanks for the offer. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
