zenity: what's taking so long?
This has been in my upgrade queue for a couple of days now: it seems to hang here. make all-recursive Making all in src make[2]: Nothing to be done for `all'. Making all in po make[2]: Nothing to be done for `all'. Making all in data make[2]: Nothing to be done for `all'. Making all in help if ! test -d bg/; then mkdir bg/; fi if [ -f "C/zenity.xml" ]; then d="../"; else d="/opt/local/var/db/ dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_gnome_zenity/work/zenity-2.18.2/help/"; fi; \ (cd bg/ && \ `which xml2po` -e -p \ "${d}bg/bg.po" \ "${d}C/zenity.xml" > zenity.xml.tmp && \ cp zenity.xml.tmp zenity.xml && rm -f zenity.xml.tmp) If I crank the debuig switches high enough, I this: Interrupted function callI/O warning : failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" But that is accessible: curl -O http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4658 100 4658 0 0 11009 0 --:--:-- --:--:-- --:--:-- 25774 What gives? -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem?
Hi Paul,
If I crank the debuig switches high enough, I this: Interrupted function callI/O warning : failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
But that is accessible:
curl -O http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4658 100 4658 0 0 11009 0 --:--:-- --:--:-- --:--:-- 25774
What gives?
I've never had any luck with ports trying to access DTDs over the network, but the recent spate of changes to DocBook-related ports should fix this by installing the DTD locally and enabling other programs to find it. Make sure that the dependencies of zenity are all up to date (in particular, docbook-xml, docbook-xsl, libxml2, libxslt, and their dependents scrollkeeper and gnome-doc-utils), then clean zenity and try again. Do let us know if you have any further problems. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org
On Jun 12, 2007, at 6:06 PM, Boey Maun Suang wrote:
docbook-xml, docbook-xsl, libxml2, libxslt, and their dependents scrollkeeper and gnome-doc-utils
would it make sense to set these as dependencies in the Portfile, assuming this works? And what's the mechanism for accessing the online entities? I realize this is outside the scope of MacPorts but it seems it could be more robust. -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem?
On Jun 12, 2007, at 6:06 PM, Boey Maun Suang wrote:
Do let us know if you have any further problems.
Well, same problems. Out of memory error. I don't think it's a network problem. for comparison I just build it on my FreeBSD 6.2 box. real 0m19.470s user 0m14.174s sys 0m3.893s No issues, no hesitation. It looks like whatever xml2po is doing isn't going well, but I have no idea what that's all about. I have gnome-doc-utils-0.10.3_1 there vs 0.10.3_0 on MacPorts, but I don't think there's any difference there. -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem?
On 13/06/2007, at 13:00, paul beard wrote:
docbook-xml, docbook-xsl, libxml2, libxslt, and their dependents scrollkeeper and gnome-doc-utils
would it make sense to set these as dependencies in the Portfile, assuming this works?
I'm not sure; it's a question of whether zenity genuinely depends only on whatever gnome-doc-utils provides, however that may change, or whether it also depends on specific versions of scrollkeeper, docbook-xsl, or whatever. If the latter is the case, there's not much work in making the requisite changes, but if the former is the case, we should keep the others out to keep the dependency listing simple, and moreover accurate.
And what's the mechanism for accessing the online entities? I realize this is outside the scope of MacPorts but it seems it could be more robust.
I don't know how xsltproc(1) and the like try to access URLs, but the way the docbook-xml-* ports work is to install local copies, then add entries to a local XML catalog that XML parsers read to handle the remapping from the canonical online URL to the local copy, so that (among other things) there's no need to access the online URLs and things still work if the network is unavailable. Until the recent revision to the libxml2 port, it and any libxslt built against it defaulted to looking for the XML catalog in /etc/xml/catalog rather than ${prefix}/etc/xml/catalog, so setting XML_CATALOG_FILES was necessary to override this. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org
participants (2)
-
Boey Maun Suang
-
paul beard