As I mentioned earlier in this thread, you can just configure apt to run as root to avoidthis problem.
Ah, I missed that. Thanks for the hint.
Unfortunately, the "uname: Bad address" doesn't appear in qemu. Looks like I'll have todebug this on the actual hardware after all. Is this a known issue?Not that I know of. However, I would just bisect the issue in nss.FWIW, I know that there is going to be a new SPARC machine in the GCC compile farm basedon a SPARC T4-2 that should become available soonish.
Since gcc102 is available right now, I tested the libnss build on that machine. libnspr4-dev isn't installed, but the build got sufficiently far to compare output with the Debian build machines.
Unfortunately, the uname issue does not occur there, which leads me to believe something is different between gcc102 and the Debian build hosts[1].
gcc102 has coreutils 9.1-1, libc6 2.36-4 and uname reports:Linux gcc102.fsffrance.org 6.1.0+ #1 SMP Tue Dec 13 08:35:29 CST 2022 sparc64 GNU/Linux
[1] sompek and nvg5120 : https://buildd.debian.org/status/logs.php?pkg=nss&ver=2%3A3.85-1&arch=sparc64