Hi, On 2023-11-25 12:37, Wookey wrote: > For debian we'll keep an eye on it, do a belated rebuild to see how > much of a problem we really have, and then decide if we should revert > it too until some stuff if fixed.
I now finally have some data to share. In total, out of the whole Debian archive, 4 packages fail to build because of stackclash on armhf and 2 on armel. Additionally, 5 packages have failing autopkgtests. The main issue really is the open valgrind bug on armhf when checking programs built with stack-clash-protection: https://bugs.debian.org/1061496 No problem on armel, given that valgrind is not supported at all there. The procedure I followed to get the FTBFS data was starting from the list of build failures kindly gather by Lucas with his archive rebuild last month (see http://qa-logs.debian.net/2024/01/11/). I've rebuilt all packages that failed, and it turns out that most failed due to transient issues at the time. Then starting from the list of my failed rebuilds I performed another build - this time without stackclash. Note that of the 4 armhf FTBFS, 2 are due to the fact that the build process uses valgrind (#1061496). Additionally, the valgrind issue caused autopkgtest failures in 5 packages: apt, libgd2, libgssglue, libvorbis, and sndfile-tools. The workaround I've been suggesting for the FTBFS is to disable stackclash on armhf or armel for the few packages that fail building. For packages using valgrind in autopkgtest, I've been suggesting either to skip the tests that fail or disabling stackclash - on armhf only of course. For all of the above, I have filed bugs with the usertag 32bit-stackclash: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=32bit-stackclash
