On Thu, Mar 02, 2017 at 01:36:23AM +0000, James Clarke wrote: > Currently systemd FTBFS on the buildds. Looking at the failure, this seems to > be because the kernel running on the buildds (4.9.12-titan-p1+) does not have > CONFIG_USER_NS enabled.
Sigh... systemd. OK, thanks, I'll add CONFIG_USER_NS to the build. Oh, the p1+ refers to a number of my patches on the kernel. One for reverting some OSF1 symantics that break the clone syscall under Linux on SMP systems but one person objected to not being able to run their Tru64 Unix OSF1 executables under Linux so the patch didn't get applied upstream. The others are to work around relocation errors in linking which have been suggested upstream but never applied. It astonishes me that the Debian build actually succeeds the link, but maybe it is because almost everything is built as modules. > Also, is there > a reason why src:linux isn't building the CONFIG_TITAN (SMP and non-SMP) > versions, which would avoid this in future? Debian source builds a generic UP and SMP kernel only that can be run on any Alpha hardware (except some early ones that required the "legacy" kernel which we no longer build). Titan is a particular Alpha hardware that I suspect most of our users do not run so not a good idea to build Debian specifically for that. I had been running Debian kernels on the buildds to give the kernel a bit of work-out but at some point the kernels failed to boot, so to keep things moving along I reverted to building a Titan variant kernel specific to the buildd architecture. It is time that we re-tried running a Debian kernel but the Debian kernel will still have that commit that was causing all the random segfaults so, on second thoughts, that's not such a hot idea. Cheers Michael