Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
Am 25.06.20 um 17:49 schrieb Thorsten Glaser: > Michael Biebl dixit: > >> Is this workaround permanent or will systemd FTBFS again in the future? > > I’ve just verified that the upstream-merged fix, appearing in > linux-libc-dev 5.7.6-1 in sid, fixes this permanently. > Great, thanks Thorsten. Michael signature.asc Description: OpenPGP digital signature
Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
Michael Biebl dixit: >Is this workaround permanent or will systemd FTBFS again in the future? I’ve just verified that the upstream-merged fix, appearing in linux-libc-dev 5.7.6-1 in sid, fixes this permanently. 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
Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
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
Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
Am 08.04.20 um 09:56 schrieb Michael Biebl: > 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 ... on x32 only, of course. signature.asc Description: OpenPGP digital signature
Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
Am 07.04.20 um 14:26 schrieb Thorsten Glaser:
> retitle 954294 linux: __X32_SYSCALL_BIT being defined as UL constant breaks
> userspace
> reassign 954294
> found 954294 5.5.13-2
> thanks
>
> Dixi quod…
>
>>> -#define SCMP_SYS(x) (__SNR_##x)
>>> +#define SCMP_SYS(x) ((int)__SNR_##x)
>>
>> Ouch, this hasn’t worked:
>>
>> ../src/shared/seccomp-util.c: In function ‘seccomp_restrict_sxid’:
>>
>> ../src/shared/seccomp-util.c:1977:5: error: missing binary operator before
>> token "("
>> 1977 | #if SCMP_SYS(open) > 0
>>
>> | ^~~~
>>
>
> Turns out that __X32_SYSCALL_BIT is OR’d into the __NR_* things
> and defined, by default, as unsigned long constant.
>
> /usr/include/x86_64-linux-gnux32/asm/unistd.h:#define __X32_SYSCALL_BIT
> 0x4000UL
>
> I’ve uploaded a workaround (attached); reassigning.
Is this workaround permanent or will systemd FTBFS again in the future?
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.
Let me know what you prefer.
Michael
signature.asc
Description: OpenPGP digital signature
