Bug 9512 - error building smb.conf.5
error building smb.conf.5
Status: RESOLVED FIXED
Product: Samba 4.0
Classification: Unclassified
Component: Build
4.0.0
All FreeBSD
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-18 17:29 UTC by David Boyd
Modified: 2013-01-18 11:55 UTC (History)
1 user (show)

See Also:


Attachments
configure and make full capture (364.92 KB, application/octet-stream)
2012-12-18 17:29 UTC, David Boyd
no flags Details
proposed fix (1.39 KB, patch)
2012-12-20 09:31 UTC, Björn Baumbach
no flags Details
proposed fix 2 (1.30 KB, patch)
2012-12-21 10:13 UTC, Björn Baumbach
no flags Details
proposed patch cherry-picked from master (1.39 KB, patch)
2013-01-15 20:18 UTC, Björn Baumbach
abartlet: review-
Details
now it is the proposed patch cherry-picked from master (1.57 KB, patch)
2013-01-15 22:31 UTC, Björn Baumbach
abartlet: review+
obnox: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Boyd 2012-12-18 17:29:58 UTC
Created attachment 8358 [details]
configure and make full capture

FreeBSD 8.3-STABLE amd64

configure

Checking for stylesheet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl : ok 

make
...

[3782/3863] Generating manpages/smb.conf.5
I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
compilation error: file /u/1/samba-4.0.0/docs-xml/xslt/man.xsl line 7 element import
xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
Waf: Leaving directory `/u/1/samba-4.0.0/bin'
Build failed:  -> task failed (err #5): 
	{task: manpages/smb.conf.5 smb.conf.5.xml -> smb.conf.5}
*** Error code 1

Attachment is full output of configure and make commands
Comment 1 Björn Baumbach 2012-12-19 09:16:12 UTC
The build system can not load the docbook.xsl file from sourceforge.net.

I/O error : Attempt to load network entity
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity

Typically systems use a local rewrite of this url that refer to a locally stored file.

On my Gentoo Linux I find this in /etc/xml/catalog with the referral to the /etc/xml/docbook file.

This is the entry:
<delegateURI uriStartString="http://docbook.sourceforge.net/release/xsl/" catalog="file:///etc/xml/docbook"/>
Comment 2 David Boyd 2012-12-19 17:20:03 UTC
You replied: "Typically systems use a local rewrite of this url that refer to a locally stored file."

I don't know what that means.

The "configure" portion of the build indicated:

Checking for stylesheet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl : ok 

and I didn't see any indication in the log that there was something misconfigured.

The "make" appears to be almost complete "[3782/3863]" before this error occurs.

Any hint about where to look or what to look for would be greatly appreciated.

System is FreeBSD...I have tried 8.3-RELEASE (32-bit and 64-bit) and 9.1-RELEASE (32-bit and 64-bit).

If I am missing some required library or package, there wasn't any obvious indication in the configure/make log(s).

Thanks for your assistance.
Comment 3 David Boyd 2012-12-19 22:45:48 UTC
Your response prompted me to dig into the build process.

It appears that every ./release-scripts/build-* has hard-coded a reference to "/etc/xml/catalog".

In the FreeBSD world, the xml catalog is in "/usr/local/share/xml/catalog" (the docproj package installation default).

Can the generation of ./release-scripts/build-* be changed to be aware of the operating system default destination for the xml catalog?
Comment 4 Björn Baumbach 2012-12-20 09:31:01 UTC
Created attachment 8361 [details]
proposed fix

Thank you for the information.

I attached a patch to this bug. Could you try this?
Comment 5 Björn Baumbach 2012-12-20 09:59:21 UTC
(In reply to comment #3)
> Can the generation of ./release-scripts/build-* be changed to be aware of the
> operating system default destination for the xml catalog?

Just for you information: the typical "make"-waf-build does not use the release scripts. These are optional scripts. My patch fixes only the waf build. I'll also fix the release scripts, if the proposed patch work.
Comment 6 David Boyd 2012-12-20 20:04:04 UTC
(In reply to comment #4)
> Created attachment 8361 [details]
> proposed fix
> 
> Thank you for the information.
> 
> I attached a patch to this bug. Could you try this?

The patch works for me.

Thanks.
Comment 7 David Boyd 2012-12-20 20:06:01 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > Can the generation of ./release-scripts/build-* be changed to be aware of the
> > operating system default destination for the xml catalog?
> 
> Just for you information: the typical "make"-waf-build does not use the release
> scripts. These are optional scripts. My patch fixes only the waf build. I'll
> also fix the release scripts, if the proposed patch work.

Thanks for the information.  I haven't gotten into Samba4 workings yet and this prompted me to start.

Thanks again.
Comment 8 Andrew Bartlett 2012-12-21 02:22:51 UTC
(In reply to comment #4)
> Created attachment 8361 [details]
> proposed fix
> 
> Thank you for the information.
> 
> I attached a patch to this bug. Could you try this?

Rather than testing on the OS, could you have the python code look in a few different locations, and use it if the directory (or the catalog we need) exists?
Comment 9 Björn Baumbach 2012-12-21 10:13:20 UTC
Created attachment 8363 [details]
proposed fix 2

(In reply to comment #8)
> Rather than testing on the OS, could you have the python code look in a few
> different locations, and use it if the directory (or the catalog we need)
> exists?

You're right. But we do not need to check if the file exists or not. The system ignores non-existent files.

Please see newly attached patch.
Comment 10 David Boyd 2012-12-22 14:42:15 UTC
(In reply to comment #9)
> Created attachment 8363 [details]
> proposed fix 2
> 
> (In reply to comment #8)
> > Rather than testing on the OS, could you have the python code look in a few
> > different locations, and use it if the directory (or the catalog we need)
> > exists?
> 
> You're right. But we do not need to check if the file exists or not. The system
> ignores non-existent files.
> 
> Please see newly attached patch.

The new patch works for me.

Thanks.
Comment 11 Björn Baumbach 2013-01-15 20:18:58 UTC
Created attachment 8435 [details]
proposed patch cherry-picked from master
Comment 12 Andrew Bartlett 2013-01-15 22:03:48 UTC
Comment on attachment 8435 [details]
proposed patch cherry-picked from master

There is a reason I objected to this going into master at the time.

You should *never* have a platform-specific if like this in core code such as the wafsamba.py file.

You need to detect if that file exists, and then add it to the list of possible files we build with, not check for freebsd.  The same will almost happen on DragonflyBSD, NetBSD, OpenBSD and any other platform build from source.

Also I don't see the cherry-pick reference (if cherry-picking, use -x so we can track the git commit).

I think this was just a mistake, as https://gitweb.samba.org/?p=samba.git;a=commitdiff;h=d61d2af3727a19cc4ddc88ec2faa8aafff9c7422 is much more reasonable.
Comment 13 Björn Baumbach 2013-01-15 22:31:43 UTC
Created attachment 8436 [details]
now it is the proposed patch cherry-picked from master


> I think this was just a mistake, as
> https://gitweb.samba.org/?p=samba.git;a=commitdiff;h=d61d2af3727a19cc4ddc88ec2faa8aafff9c7422
> is much more reasonable.

Oops, yes - wrong patch sorry! This was the old one.
I attached the new patch, reviewed by obnox, vl and tested by the reporter.
Comment 14 Michael Adam 2013-01-17 12:26:27 UTC
Comment on attachment 8436 [details]
now it is the proposed patch cherry-picked from master

ACK
Comment 15 Michael Adam 2013-01-17 12:28:03 UTC
==> Karolin for inclusion.
Comment 16 Karolin Seeger 2013-01-18 08:45:17 UTC
Pushed to autobuild-v4-0-test.
Comment 17 Karolin Seeger 2013-01-18 11:55:36 UTC
Pushed to v4-0-test.
Closing out bug report.

Thanks!