As I mentioned earlier in this thread, you can just configure apt to run
as root to avoid
this problem.
Ah, I missed that. Thanks for the hint.
Unfortunately, the "uname: Bad address" doesn't appear in qemu. Looks
like I'll have to
debug 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 based
on 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