Source: nss Version: 2:3.103-1 Severity: important Tags: ftbfs patch Control: clone -1 -2 Control: reassign -2 src:nss-pem Control: clone 948523 -3 Control: reassign -3 src:nss-pem Control: clone -1 -4 Control: retitle -4 nss-pem: unregistered vendor copy of nss Control: tags -4 = Control: reassign -4 src:nss-pem
Hi, nss and nss-pem FTBFS on the reproducible builds infrastructure for armhf. For nss-pem, it was the second build that FTBFS. That got me looking and allowed me identifying the cause. It looks at the uname and when you build on an arm32 userland with a 64bit kernel, some features are detected differently (as it looks at uname -m) and then the build fails. We already pass OS_TEST for cross building where uname -m is a problem, so I suggest extending this to cover the arm case and overriding OS_TEST even for native builds. I'm attaching a patch for your convenience. As this bug also affects nss-pem, I am cloning the bug (as -2) for nss-pem and also cloning another bug (as -3) where nss-pem FTCBFS for ppc64el. I also observe that the vendoring of nss-pem is not registered in the security tracker https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies. Please unvendor nss from nss-pem or register your copy. This matter is tracked as bug -4. Helmut
--- nss-b/debian/rules +++ nss-a/debian/rules @@ -47,6 +47,11 @@ endif TOOLCHAIN += OS_TEST=$(DEB_HOST_GNU_CPU) TOOLCHAIN += KERNEL=$(DEB_HOST_ARCH_OS) +else +# Avoid misdetecting armhf as arm64 when built on a 64bit kernel. +ifeq ($(DEB_HOST_GNU_CPU),arm) +TOOLCHAIN += OS_TEST=arm +endif endif # $(foreach foo,$(list),$(call cmd,some command $(foo))) expands to
