Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#26919 closed defect (fixed)

gnome-doc-utils installation fails

Reported by: ivan@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: Cc:
Port: gnome-doc-utils

Description

Hi,

I've been trying to install empathy, however, gnome-doc-utils 0.20.2 fails during build (added just the relevant part):

:info:build Making all in examples
:info:build make[2]: Nothing to be done for `all'.
:info:build make[2]: Nothing to be done for `all-am'.
:info:build Making all in doc
:info:build Making all in gnome-doc-make
:info:build if ! test -d de/; then mkdir de/; fi
:info:build if [ -f "C/gnome-doc-make.xml" ]; then d="../"; else d="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.or
g_release_ports_gnome_gnome-doc-utils/work/gnome-doc-utils-0.20.2/doc/gnome-doc-make/"; fi; \
:info:build     mo="de/de.mo"; \
:info:build     if [ -f "${mo}" ]; then mo="../${mo}"; else mo="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_re
lease_ports_gnome_gnome-doc-utils/work/gnome-doc-utils-0.20.2/doc/gnome-doc-make/${mo}"; fi; \
:info:build     (cd de/ && \
:info:build       PYTHONPATH="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_gnome-doc-utils/
work/gnome-doc-utils-0.20.2/doc/gnome-doc-make/../../xml2po:/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_releas
e_ports_gnome_gnome-doc-utils/work/gnome-doc-utils-0.20.2/doc/gnome-doc-make/../../xml2po:" "/opt/local/var/macports/build/_opt_local_var_macports_
sources_rsync.macports.org_release_ports_gnome_gnome-doc-utils/work/gnome-doc-utils-0.20.2/doc/gnome-doc-make/../../xml2po/xml2po/xml2po" -m docboo
k -e -t "${mo}" \
:info:build         "${d}C/gnome-doc-make.xml" > gnome-doc-make.xml.tmp && \
:info:build         cp gnome-doc-make.xml.tmp gnome-doc-make.xml && rm -f gnome-doc-make.xml.tmp)
:info:build Traceback (most recent call last):
:info:build   File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_gnome-doc-utils/work/gnome
-doc-utils-0.20.2/doc/gnome-doc-make/../../xml2po/xml2po/xml2po", line 191, in <module>
:info:build     main(sys.argv[1:])
:info:build   File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_gnome-doc-utils/work/gnome
-doc-utils-0.20.2/doc/gnome-doc-make/../../xml2po/xml2po/xml2po", line 88, in main
:info:build     from xml2po import Main
:info:build   File "/opt/local/var/macports/build/_opt_local_var_macports_source
s_rsync.macports.org_release_ports_gnome_gnome-doc-utils/work/gnome-doc-utils-0.20.2/xml2po/xml2po/__init__.py", line 27, in <module>
:info:build     import libxml2
:info:build ImportError: No module named libxml2
:info:build make[2]: *** [de/gnome-doc-make.xml] Error 1
:info:build make[1]: *** [all-recursive] Error 1
:info:build make: *** [all-recursive] Error 1
:info:build shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_gnome-doc-utils/work/gnome-doc-utils-0.20.2" && /usr/bin/make all " returned error 2
:error:build Target org.macports.build returned: shell command failed
:debug:build Backtrace: shell command failed
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"

This quite possibly blocks installation of many packages originating from GNOME.

Change History (7)

comment:1 Changed 10 years ago by dbevans (David B. Evans)

Port: gnome-doc-utils added
Resolution: fixed
Status: newclosed

py26-libxml2 declared as a run dependency but should be a lib dependency

fixed in r72551.

You can do

sudo port selfupdate

to get the modified port in about an hour or just go ahead and install port py26-libxml2

Thanks for the report

comment:2 Changed 10 years ago by ivan@…

That was quick! Thanks.

comment:3 Changed 10 years ago by ivan@…

Thanks. But this didn't help:

The-Evil-MacBook:~ ivucica$ sudo port install py26-libxml2 ---> Computing dependencies for py26-libxml2 ---> Cleaning py26-libxml2 The-Evil-MacBook:~ ivucica$ sudo port install gnome-doc-utils---> Computing dependencies for gnome-doc-utils ---> Building gnome-doc-utils Error: Target org.macports.build returned: shell command failed Log for gnome-doc-utils is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_gnome-doc-utils/main.log Error: Status 1 encountered during processing. To report a bug, see <http://guide.macports.org/#project.tickets>

Even after trying to switch back to Python2.6 from MacPorts (I had a need to switch back to Apple's Python in the past): The-Evil-MacBook:~ ivucica$ sudo python_select python26

What did seem to help was reactivating Python and reinstalling py26-libxml2: The-Evil-MacBook:~ ivucica$ sudo port activate python26 @2.6.5_1+darwin ... The-Evil-MacBook:~ ivucica$ sudo port uninstall py26-libxml2 ; sudo port install py26-libxml2 ...

Hope this helps someone.

comment:4 Changed 10 years ago by dbevans (David B. Evans)

Aha! That's not cricket!

The MacPorts python ports use non-standard installation paths so that multiple versions can be installed at the same time. The python_select command manipulates links to select which one is linked to the default command name 'python'. Deactivating python26 will cause python_select's link to fail.

In general, the GNOME ports depend on python26 so that all python extensions etc will work together over the GNOME suite. So I suggest you stick with that if you want a consistent python experience.

More than this, the general MacPorts philosophy is to assume that all software to be used with our ports is installed by MacPorts and not manually elsewhere (like in /usr/local for instance). This helps us insure that everything works correctly and that software works the same over multiple versions of the OS.

Glad you got it working.

comment:5 Changed 10 years ago by jmroot (Joshua Root)

If the user has to python_select a particular version for a port to work, that port is doing it wrong.

comment:6 in reply to:  5 Changed 10 years ago by dbevans (David B. Evans)

Replying to jmr@…:

If the user has to python_select a particular version for a port to work, that port is doing it wrong.

Agreed and that is not an issue for this port. It appears to me that he miss installed py26-libxml2 somehow and now that is fixed.

comment:7 Changed 10 years ago by ivan@…

Indeed; I don't think MacPorts is to blame here (although apparently I did raise a valid point about the library not being a build requirement -- or did I?).

I had a very... particular situation. I had Python.org's Python2.5 for business needs, Apple's Python2.6 since it ships with MacOSX, and I wanted to install MacPorts software that was either a Python library, or depended on Python. I did some joggling with Python versions and that's what probably made the thing problematic.

Bugs should probably be filed with Python 2.x packages on MacPorts, to make switching easy not just to Apple's Python, but also to Python.org's Python. The latter is needed since only that way one can build a binary for-distribution with py2app and ship Python at the same time. And shipping Python is needed since end users (casual gamers in this case) must never know that we're shipping Python, and numerous modules built for it (various Python-Ogre modules). All that publishers accept and all that players accept (that is, all that end users accept) is a single .app bundle that launches the game immediately upon double-clicking.

Hence the need to have Python.org version of Python on one's machine. Hence the motivation to improve python_select to allow switching to other Python releases as well. These non-system releases are stored in /Library/Frameworks/Python.framework and these do a bit of redirection themselves.

However, I'm way off-topic here. All I tried to say is that I don't believe either myself nor MacPorts being at fault here. python_select might be improved, but that's not sufficiently relevant to this bug to require more discussion on my part.

(PS Shame on me for not previewing my previous comment and therefore breaking all the text that should have been monospaced.)

Note: See TracTickets for help on using tickets.