Created attachment 170840 [details] Patches for some packages removing the --nonet option Some packages build their manpages by calling the xsltproc tool using the --nonet option. This option leads to a fatal error because the entity cannot be loaded. Here's the message: 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" cannot parse http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl I wrote some patches that remove the --nonet option (attachment) but this is only a workaround. What is the real solution?
The proper solution is to add a build dependency on docbook-xsl like this: BUILD_DEPENDS= docbook-xsl>=0:textproc/docbook-xsl
Thanks for your submission. Please attach patches in plain text format (and check the "Patch" checkbox) so they can be (re)viewed quickly through bugzilla.
Created attachment 170862 [details] Patches for some packages removing the --nonet option
(In reply to Tijl Coosemans from comment #1) > The proper solution is to add a build dependency on docbook-xsl like this: > BUILD_DEPENDS= docbook-xsl>=0:textproc/docbook-xsl Sorry, but this won't help. The files devel/gvfs/Makefile security/libsecret/Makefile already contain this line and the build crashes regardless of that.
I wasn't comfortable pinging multiple maintainers for a single PR, but it looks like it's just two. I'd advise separating such issues into own PRs, it's easier to track and we can name individual ports in the summary so they're easily searched for issues. BTW, as a quick test I looked at security/libsecret thinking it'll pull in least amount of deps, but that port does not have any patches nor a files directory. Are these fixes against the latest SVN head?
Looks like those are actual patch files to add in, my bad. I would recommend submitting svn diffs, it's easier to understand whats being added. ;)
(In reply to Vladimir Krstulja from comment #5) > Are these fixes against the latest SVN head? They are against the latest Git head. commit 854f4802fabe2fad94916060578dedd25ab352a0 Author: tijl <tijl@FreeBSD.org> Date: 2016-05-31 12:09:49 +0000
Yeah, my bad, you are adding the patchfiles, not modifying existing (which I thought you were). Btw, FWIW, I tried building security/libsecret and it builds just fine in a clean jail, without your patch. The only things I had to do was install m4 and libiconv manually (configure phase failed at those), but that's another issue... 10.3, svn head checked out in a jail.
(In reply to Vladimir Krstulja from comment #8) > I tried building security/libsecret and it builds just fine in a clean jail, > without your patch. I'm compiling it in a virgin jail, too. Do you have any suggestions how I could debug it?
(In reply to software from comment #9) Try with poudriere, that should be a truly isolated build.
(In reply to software from comment #9) > (In reply to Vladimir Krstulja from comment #10) > > > I'm compiling it in a virgin jail, too. Do you have any suggestions > > how I could debug it? > Try with poudriere, that should be a truly isolated build. I asked how I could _debug_ it. Installing poudriere would be only another workaround. Besides that, I will _not_ install yet another monster as long as the first monster refuses to run properly. I did the following: "pkg delete" every package until only the base system was left. "make clean" in in every /usr/ports/*/* where a "work" directory existed. I already mentioned that I'm in a jail where noting else gets done except ports and packages. "security/libsecret" fails again...
I suggested poudriere because if it builds just fine then it means your jail is polluted by something. However, I think there's something else going on, as I've noticed some ports failing for missing packages when built in a clean jail with only subversion, porttools and bootstrapped pkg, but the missing packages _are_ specified as dependency and otherwise the port builds fine in poudriere. I'll file a PR once I can replicate the issue and make sure it's not my fault.
(In reply to Vladimir Krstulja from comment #12) So my issue was with porttool's "port test" which would not trigger installation of some build time dependencies, not with running regular "make" in the port's directory. I don't know now what to suggest for debugging this except to make sure all the tools and required dependencies are up to date. Note that default pkg repo is quarterly and in a clean new jail you have to override it unless you're installing everything from ports. In a 10.3-p5 jail with bootstrapped pkg, installed subversion+porttools+vim-lite from latest pkg repo, I can't build security/libsecret by running "port test" in its port dir, due to missing intltool (which I can install manually but then there's another issue, etc...), but running "make install" builds it and installs it fine.
It's even worse. In devel/xdg-utils I give the --skip-validate option. Then, there happens the following: Catalog error : Detected recursion in catalog (null) Catalog error : Detected recursion in catalog (null) Catalog error : Detected recursion in catalog (null) Catalog error : Detected recursion in catalog (null) ... (for minutes, then it succeeds or fails) The xsltproc tool does not only do not work properly, it further does not tell me what went wrong or even what it tried to do. I strongly recommend to ban this tool from FreeBSD until they learned how to write software. The attached patch removes every xsltproc call I encountered.
Created attachment 171456 [details] Remove calls to xsltproc
software@, can you please attach some build logs? Preferably Poudriere's? Default devel/xdg-utils with default options on all dependencies builds just fine for me. Also please note libxslt will update to 1.1.29, that version carries a lot of fixes: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210298