When attempting to build Samba-4 (I've tried 4.0.0, 4.0.9, 4.1.0 so far) I get an error when the man page smb.conf.5 is being generated. I've tried building by hand on my Gentoo system and on a Fedora machine. The Fedora machine doesn't fail even though key packages related to XML/XSLT match in version. This suggests either a bug with one of the Gentoo packages, or a USE flag needs changing. I'm putting this under Samba-4 so that the correct USE flag is requested in future ebuilds. === Package details === app-text/docbook-xml-dtd-4.1.2-r6 app-text/docbook-xml-dtd-4.2-r2 app-text-xmlto-0.0.24-r1: -latex dev-libs/libxml2-2.9.1-r1: ipv6 lzma -python readline dev-python/lxml-3.2.1: threads dev-libs/libxslt-1.1.28-r1: crypt -python Reproducible: Always Steps to Reproduce: Attempt to build the package with the above use flags set. Even when changing the -python to +python, the build of the man page still fails. Actual Results: I'll attach the full build log to explain exactly what occurred. In short: [3578/3664] Generating manpages/smb.conf.5 15:58:46 runner XML_CATALOG_FILES="file:///etc/xml/catalog file:///usr/local/share/xml/catalog file:///var/tmp/portage/net-fs/samba-4.1.0/work/samba-4.1.0/bin/default/docs-xml/build/catalog.xml" export XML_CATALOG_FILES /usr/bin/xsltproc --xinclude --stringparam noreference 0 -o default/docs-xml/manpages/smb.conf.5.xml --nonet /var/tmp/portage/net-fs/samba-4.1.0/work/samba-4.1.0/docs-xml/xslt/expand-sambadoc.xsl ../docs-xml/manpages/smb.conf.5.xml /usr/bin/xsltproc --nonet -o default/docs-xml/manpages/smb.conf.5 /var/tmp/portage/net-fs/samba-4.1.0/work/samba-4.1.0/docs-xml/xslt/man.xsl default/docs-xml/manpages/smb.conf.5.xml Waf: Leaving directory `/var/tmp/portage/net-fs/samba-4.1.0/work/samba-4.1.0/bin' Build failed: -> task failed (err #-7): {task: manpages/smb.conf.5 smb.conf.5.xml -> smb.conf.5} I initially added to a bug with the Samba Bugzilla (https://bugzilla.samba.org/show_bug.cgi?id=9515), but they've helped me to show that this is Gentoo specific, not an upstream issue.
Created attachment 360984 [details] Truncated build log Build log truncated to last 1000KB.
Comment on attachment 360984 [details] Truncated build log Please attach the entire (compressed) build log to this bug report.
Created attachment 361082 [details] Environment Environment file. Possibly not required.
Created attachment 361084 [details] emerge --info --verbose
Created attachment 361086 [details] build.log.gz Sorry for not uploading the compressed build log. I'm used to the Kernel mailing list where such things are not allowed.
I don't mind if you change the version details in the bug description, but I would really like this bug to reflect that the problem is building a man page. The issue is certainly not about building the binaries or some other portion of the build process. I'll let you decide what is best though rather than change it.
I've tried to rebuild this on a vanilla Gentoo build. This involved these steps: - Download 20131008 x86 minimal boot ISO and booting from this ISO - Download of 20131008 i686 stage 3 as a base and extracting - Download of portage-latest and extracting - Addition of appropriate KEYWORDS, USE flags and an unmask to suit samba-4.1.0 - Compile of samba-4.1.0 and required dependencies The build failed on merge because there is no /run directory populated within the chroot. This is unrelated to the bug at hand and would've succeeded in a more normal environment. I copied from my current build machine the files make.conf, package.use, package.unmask and package.keywords. After this I ran the following: - Fixed the /run directory problem from earlier - emerge -auvD --newuse world - emerge -av --newuse \=samba-4.1.0 The package merged successfully. Still not sure what the issue is as this doesn't seem to be related to a USE flags problem. Next step was to try the last two steps again on my current build machine which again failed. I found that the make profile on my build machine is for hardened/linux/x86, but the vanilla machine is default/linux/x86/13.0. So I performed the following on the vanilla machine: - Changed profile to hardened/linux/x86 - Re-built gcc, glibc and binutils - Ran emerge -euvD --newuse world This was done to rebuild the entire system as hardened. I realise there's probably more flags there than required. When this was run the build of samba-4.1.0 failed with the same error. I rebuilt the following packages with USE="-hardened" and a vanilla gcc (i686-pc-linux-gnu-4.7.3-vanilla on hardened profile): - virtual/libiconv - app-text/docbook-xml-dtd:4.2 - dev-libs/libxml2 - dev-libs/popt - dev-python/python-exec - dev-python/python:2.7 - dev-python/python:3.2 - dev-python/subunit The results were the same (failure of man page build). I then ran an emerge -e world with the vanilla gcc mentioned above. Samba-4.1.0 now built successfully. Conclusion: Something when it is built with a hardened compiler is causing samba-4 man page generation to fail. What that something is I don't yet know.
My plan is to run the xsltproc command manually on the failing and working machine with appropriate debugging/function tracing. Unfortunately I don't have experience doing debugging so I was hoping someone could suggest and appropriate process for this. From there I could probably open a new bug against the right package and maintainer so this can be resolved and no longer be an issue of the Gentoo Samba team. Assitance with debugging anyone?
This is repeat of debian #750593. The bug is in docbook-xslt, an inappropriate recursive function that causes a stack overflow. This patch allows Samba to build: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=66;filename=nonrecursive-string-subst.patch;att=1;bug=750593
So where to next. Is it ideal to have this patch included within the Samba 4 builds, or is it an upstream issue? I didn't see any obvious changes to the man page building from reading the release notes upstream. I can try a rebuild on a hardened box and see what the results are with this patch if you would like?
I can confirm that the patch in comment #9 causes Samba-4.1.20-r1 to build on an ~x86 system. There's some speculation in discussion on Debian bug 750593 about permissions of /dev/shm, but on my system /dev/shm is world-writeable. This appears to be a 32-bit platform-specific bug in app-text/docbook-xsl-stylesheets. Any hope of getting this issue resolved in the next couple of months?
I can confirm that the patch in comment #9 causes samba-4.2.7-r1 to build on a fresh install of gentoo-hardened on amd64. This also affects amd64 systems
(In reply to masterbase from comment #12) > I can confirm that the patch in comment #9 causes samba-4.2.7-r1 to build on > a fresh install of gentoo-hardened on amd64. > > This also affects amd64 systems I cannot reproduce it. Please share your build log and the output of the command qlist -Iv | egrep -i 'docbook|libxslt'
I looked at it again, it appears that on amd64 systems, the bug only occurs on systems that don't have a lot of ram (>1GB). If you're still interested I can test it again and share the result.
I can reproduce it on an ARMv7 hard-float system with only 1GB of RAM.
*** Bug 609528 has been marked as a duplicate of this bug. ***
*** Bug 600924 has been marked as a duplicate of this bug. ***
REFERENCE: Bug 635064 - net-fs/samba-[ 4.5.10-r1,4.6.8-r1,4.7.0-r1]: runtime error while generating man-pages *SOUTION* proposed // *PATCH* provided : https://bugs.gentoo.org/635064#c10
Also, seeing this bug on a new amd64 system w/ 2GB ram. Unable to build any recent version of samba w/o the patch. Haven't tried a complete world rebuild yet...that might be next step. But, it does look like redhat has this as an active bug in their db too...real issue. Not sure why it is not being addressed upstream.
ok, apparently the patch for this bug was included in =app-text/docbook-xsl-stylesheets-1.79.1-r2 as adding that package to packages.accept_keywords is all that is needed to get samba to install w/o breaking during the build of the manpages.
1) I was hit by this bug during "emerge -e @world" after switching to profile "default/linux/amd64/17.0/no-multilib". 2) I saw this bug on Samba 4.5.10-r1 and ~4.5.15. 3) I can confirm that upgrading to "docbook-xsl-stylesheets-1.79.1-r2" solves the problem. Thanks to Matthew Marlowe!
I filed a stabilization request in bug 639398.
I can confirm this bug on 32-bit PPC with samba-4.5.10-r1. Also confirm that upgrading to "docbook-xsl-stylesheets-1.79.1-r2" solves it! Damn, this package takes a million years to build on older machines. So glad I won't have to do this again for a while!
