eggdbus calls xsltproc with -nonet: how is that supposed to work?

[Jeremy Messenger]

On Wed, Dec 29, 2010 at 12:27 PM, Paul Beard <paulbeard at gmail.com> wrote:
>
> On Dec 29, 2010, at 10:02 AM, Jeremy Messenger wrote:
>
>> I can't reproduce it. It ran perfect fine here, so to our tinderboxes
>> and pointyhat.
>
>
> How could xsltproc -nonet possibly work? It makes a request for a networked resource with the network explicitly disabled. If this command is specified as part of the build, it shouldn't work anywhere: "WORKSFORME" would never apply. If it isn't in the build process everywhere, what are the criteria that turn it on or off?
>
> Your example doesn't show if/how the file being used as the stylesheet is made available. Again, if it's not present on the local filesystem and it cannot be fetched, how can it work? If you have it on the local filesystem, as I did when I re-ran the build after I saw why it was failing, of course it worked.

------------------------------
% xsltproc -v -nonet
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
eggdbus-binding-tool.xml
creating dictionary for stylesheet
reusing dictionary from
file:///usr/local/share/xsl/docbook/manpages/docbook.xsl for
stylesheet
xsltParseStylesheetProcess : found stylesheet
exclude result prefix exsl
xsltPrecomputeStylesheet: removing ignorable blank node
Reusing dictionary for document
creating dictionary for stylesheet
reusing dictionary from
file:///usr/local/share/xsl/docbook/html/docbook.xsl for stylesheet
xsltParseStylesheetProcess : found stylesheet
exclude result prefix db
[...]
------------------------------

Here's a bit of devel/eggdbus's build log:

------------------------------
Making all in man
gmake[3]: Entering directory
`/usr/ports/devel/eggdbus/work/eggdbus-0.6/docs/man'
/usr/local/bin/xsltproc -nonet
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
eggdbus-binding-tool.xml
Warn: meta author : no refentry/info/author
eggdbus-binding-tool
Note: meta author : see http://docbook.sf.net/el/author
eggdbus-binding-tool
Warn: meta author : no author data, so inserted a fixme
eggdbus-binding-tool
Note: Writing eggdbus-binding-tool.1
gmake[3]: Leaving directory `/usr/ports/devel/eggdbus/work/eggdbus-0.6/docs/man'
Making all in tests
------------------------------

It writes eggdbus-binding-tool.1 just fine.

------------------------------
# find work -name \*.1
work/eggdbus-0.6/docs/man/eggdbus-binding-tool.1

# cat work/eggdbus-0.6/docs/man/eggdbus-binding-tool.1
'\" t
.\"     Title: eggdbus-binding-tool
.\"    Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
.\"      Date: December 2008
.\"    Manual: eggdbus-binding-tool
.\"    Source: EggDBus
.\"  Language: English
.\"
.TH "EGGDBUS\-BINDING\-TO" "1" "December 2008" "EggDBus" "eggdbus-binding-tool"
.\" -----------------------------------------------------------------
[...]
------------------------------


> As for the suggestion that my network is somehow too slow for GNOME to work, I can't tell if you're trying to be funny or just obnoxious. I'm not actually using GNOME, just trying to build one of the myriad dependencies it has. How long before GNOME itself is a dependency for the kernel?

It's not about GNOME is being slow nor even about if you are using
GNOME. The URL that tell to do the FQDN correct that I have pointed
you is for in general all across OSs. It was just one of my guess to
see if it will solve your issue or not. If you are not willing to try
and help then I will have to close the PR.

> Obviously (?) I have network access, 3Mbits of it, as best the local telco can cobble together, or csup wouldn't work. This is a headless box that lives in a closet in my basement. It doesn't need GNOME as a UI. I don't have xorg installed, just two pkgs that lots of other pkgs depend on.
>
> Seriously, most of the port mgmt issues I run into stem from GNOME ports. Maybe I miss stuff in UPDATING but this telepathy-glib fustercluck was just another example of something somewhere not being validated/verified. As many reports as there were of gobject and friends balking on a header file, blaming it on pilot error seems hard to defend. The MacPorts project on OS X has similar issues where WORKSFORME is the default response from developers/porters whose systems never seem to have the same problems as the people who actually use the stuff.
>
> Enough. I'll just use send-pr from now on.

Send to PR is not going to make any difference. I have closed one of
your PR because you didn't give us the email address correct and you
have refused my requests.

You can install devel/eggdbus with NO_INSTALL_MANPAGES=yes and it will
skip to try to create a manpage with that xsltproc.

Cheers,
Mezz


> --
> Paul Beard
>
> Are you trying to win an argument or solve a problem?


-- 
mezz.freebsd at gmail.com - mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gnome at FreeBSD.org