On PowerPC64, devel/py-gobject3 fails to install with the following error: pkg-static: lstat(/usr/ports/devel/py-gobject3/work/stage/usr/local/lib/python2.7/site-packages/pygobject-3.8.1-pypython2.7-freebsd-11.0-CURRENT-powerpc64.egg-info): No such file or directory The file is actually named with 'powerpc' not 'powerpc64'. Fix: My guess is to use a different variable other than %%ARCH%% in the plist entry, which becomes $ARCH for most architectures, but 'powerpc' for any powerpc target. How-To-Repeat: Build devel/py-gobject3 for powerpc64.
Responsible Changed From-To: freebsd-ports-bugs->gnome Over to maintainer (via the GNATS Auto Assign Tool)
I got the same problem on 9.2-STABLE while trying to portmaster math/gnumeric. I found the following supporting details about the problem. First there was the cp command were the "freebsd-9.2-STABLE-powerpc" part of the file path in the copy ultimately comes from. It is from work/pygobject-3.8.1/Makefile.in involving: cp $(top_builddir)/PKG-INFO $(DESTDIR)$(pyexecdir)/$(EGG_NAME).egg-info where EGG_NAME = $(PACKAGE)-$(PACKAGE_VERSION)-py$(PYTHON_VERSION)-$(PLATFORM) and (from the configure file) PLATFORM=`$PYTHON -c "import sys; from distutils import util; sys.stdout.write(util.get_platform())"` That assignment does not agree with uname -p's "powerpc64" result as it is appearently/effectively used in pkg's file path generation for lstat. util.get_platform() is supposed to use os.uname()'s architecture (well, machine) tuple entry. Looking around I can not tell if it is always the same as platform.machine(). But in this context util.get_platform(), os.uname()[4], and platform.machine() all result in just "powerpc" (no 64). This may or may not be correct from python's definitions of intent: I'm no expert at that. I would *guess* that pkg sets the context here that py-gobject3 needs to agree with pkg's file path use for lstat. In other words: I guess that the above copy needs to change to use the file path shown in the error message: pkg-static: lstat(/usr/ports/devel/py-gobject3/work/stage/usr/local/lib/python2.7/site-packages/pygobject-3.8.1-pypython 2.7-freebsd-9.2-STABLE-powerpc64.egg-info): No such file or directory Some care is needed because EGG_NAME is also used with just ".egg" after its substitution, not just with ".egg_info" after it: There are at least 2 contexts of use. -- Mark Millard <markmigm at gmail.com>
(This is an extension to a prior note. But this written to largely stand on its own given the original defect report. This adds the relationship to uname -m vs. -p.) For the py-gobject3 configure file's PLATFORM=`$PYTHON -c "import sys; from distutils import util; sys.stdout.write(util.get_platform())"` the result corresponds to uname -m (i.e., powerpc): the so-called "hardware plaform" in uname terminology. util.get_platform(), os.uname()[4], and platform.machine() all result in just "powerpc" (unname -m result) as stands. The result during portmaster is a "....egg-info" file name based on PLATFORM that disagrees with the later check for the file's existence. (But PLATFORM has other uses as well and some may be correct ones for all I know.) The lstat "....egg-info" file path reported as missing corresponds to uname -p (i.e., powerpc64): the so-called "machine processor architecture" in uname terminology. I do not know if the 3 python calls are returning correct results for python's intent or not. But I would expect that py-gobject3's file naming for the "....egg-info" file reported as missing should be using uname -p style text in the file name in order to fit correctly in the overall ports environment. -- Mark Millard <markmigm at gmail.com>
If 'MACHINE' is usable, that would work. ...devel/py-gobject3> make -VARCH powerpc64 ...devel/py-gobject3> make -VMACHINE powerpc
Having looked at this with Justin ... Ultimately, we probably want a FreeBSD specific block in here if there is a convention that can be relied on now and into the future, and is better than, more reliable or beneficial than: http://hg.python.org/cpython/file/70990e795657/Lib/distutils/util.py#l67 Until then, or unless there's a more canonical or conventional way for gobject to be deriving and generating egg-info, it looks like %%MACHINE%% in pkg-plist might be the way to go, at least in the immediate term. Having said that, I also can't see or find any other ports special casing this mechanism for egg-info directory name generation, and that raises a flag. From a Python@ point of view, finding a root cause fix, that is upstreamable (if applicable) is highly desirable.
This problem also occurs on arm. The file created has an "arm" extension but the pkg-plist looks for one with an "armv6" extension. There is no exposure of the TARGET_ARCH (powerpc64, armv6, mips64) via uname structures in use by python, so I don't think that util.get_platform() has any way at this time to gather that information. Let's just modify the plist to use ARCH for now. This is the only package that I found in my builds on ARMv6 that has this issue.
A commit references this bug: Author: sbruno Date: Thu Sep 11 15:04:05 UTC 2014 New revision: 367946 URL: http://svnweb.freebsd.org/changeset/ports/367946 Log: This port does not use ${ARCH} to rename the egg info file that it creates. This causes the pkg-plist to break on architechtures where MACHINE and MACHINE_ARCH to differ. Assume that the upstream folks know what they are doing and create a UNAME_M variable to handle this in the pkg-plist. PR: 188856 Reviewed by: koobs Approved by: bdrewery (mentor) Changes: head/devel/py-gobject3/Makefile head/devel/py-gobject3/pkg-plist
Using 'UNAME_M!= ${UNAME} -m' may not work well on cross builds. Untested assertion - I haven't tried. So that should probably be confirmed.
I should add that I realize the pygobject3-common does a similar thing (uname -r for use in plist substituion), so it may be affected as well.
Scratch that. uname -r wouldn't matter for cross machine builds (cross release builds, but not cross arch). Sorry for the brief sidetrack - back to just uname -m in py-gobject3.
This was re-broken with the GNOME3 import.
So we can sort this out in quick order, please attach an updated patch to this issue (against head) and include poudriere output confirming successful resolution (again). Thanks for re-opening Justin
Created attachment 150125 [details] devel/py-gobject3 patch for UNAME_M Virtually exact copy (except port version) to the committed patch referenced in here.
I think devel/py3-gobject3 needs the same (similar) patch. I have one, waiting for poudriere to finish building, and I'll submit it as well.
Created attachment 150143 [details] The correct UNAME_M patch
I see the same on a 64bit VM: pkg-static: lstat(/usr/ports/devel/py-gobject3/work/stage/usr/local/lib/python2.7/site-packages/pygobject-3.14.0-py2.7-freebsd-10.0-RELEASE-p12-amd64.egg-info): No such file or directory *** Error code 74 However, the file name difference is not in the architecture part, but in the Python part: # ll /usr/ports/devel/py-gobject3/work/stage/usr/local/lib/python2.7/site-packages/ :( total 22 drwxr-xr-x 5 root wheel 40 3 Dez 19:53 gi/ -rw-r--r-- 1 root wheel 1013 3 Dez 19:53 pygobject-3.14.0-pypython2.7-freebsd-10.0-RELEASE-p12-amd64.egg-info drwxr-xr-x 2 root wheel 11 3 Dez 19:53 pygtkcompat/ It's py2.7 vs pypython2.7.
A commit references this bug: Author: kwm Date: Tue Dec 9 15:55:41 UTC 2014 New revision: 374402 URL: https://svnweb.freebsd.org/changeset/ports/374402 Log: Restore the UNAME_M fix which was accidently reverted in the gnome3 import. This fixes the build on architechtures where MACHINE and MACHINE_ARCH to differ. But put it in the -common port so it shared between both versions of py-gobject3. [1] Work around python plist issue [2] PR: 188856 [1], 195342 [2], 195738 [2], 195748 [2] Sumbitted by: sbruno [1], mva[2] Changes: head/devel/pygobject3-common/Makefile
This should be fixed now again. The gnome 3 patch was just too big and I missed it. I readded it in the pygobject3-common port so both py-gobject3 and py3-gobject3 can use it.