Bug 188856 - devel/py-gobject3 doesn't install on systems where ARCH != MACHINE_ARCH
Summary: devel/py-gobject3 doesn't install on systems where ARCH != MACHINE_ARCH
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Some People
Assignee: freebsd-gnome mailing list
URL:
Keywords: easy, needs-patch, regression
Depends on:
Blocks:
 
Reported: 2014-04-21 17:50 UTC by Justin Hibbits
Modified: 2014-12-09 16:01 UTC (History)
6 users (show)

See Also:


Attachments
devel/py-gobject3 patch for UNAME_M (1.03 KB, patch)
2014-12-03 02:41 UTC, Justin Hibbits
no flags Details | Diff
The correct UNAME_M patch (830 bytes, patch)
2014-12-03 15:52 UTC, Justin Hibbits
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Hibbits 2014-04-21 17:50:00 UTC
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.
Comment 1 Edwin Groothuis freebsd_committer 2014-04-21 17:50:05 UTC
Responsible Changed
From-To: freebsd-ports-bugs->gnome

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 markmigm 2014-05-16 16:59:53 UTC
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>
Comment 3 markmigm 2014-05-16 17:39:16 UTC
(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>
Comment 4 Justin Hibbits freebsd_committer 2014-06-30 05:40:06 UTC
If 'MACHINE' is usable, that would work.

...devel/py-gobject3> make -VARCH
powerpc64

...devel/py-gobject3> make -VMACHINE
powerpc
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2014-08-31 07:16:47 UTC
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.
Comment 6 Sean Bruno freebsd_committer 2014-09-10 15:08:01 UTC
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.
Comment 7 commit-hook freebsd_committer 2014-09-11 15:04:48 UTC
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
Comment 8 John Hein 2014-09-11 15:51:28 UTC
Using 'UNAME_M!= ${UNAME} -m' may not work well on cross builds.  Untested assertion - I haven't tried.  So that should probably be confirmed.
Comment 9 John Hein 2014-09-11 16:10:08 UTC
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.
Comment 10 John Hein 2014-09-11 16:18:06 UTC
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.
Comment 11 Justin Hibbits freebsd_committer 2014-12-01 04:58:12 UTC
This was re-broken with the GNOME3 import.
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2014-12-02 09:31:50 UTC
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
Comment 13 Justin Hibbits freebsd_committer 2014-12-03 02:41:36 UTC
Created attachment 150125 [details]
devel/py-gobject3 patch for UNAME_M

Virtually exact copy (except port version) to the committed patch referenced in here.
Comment 14 Justin Hibbits freebsd_committer 2014-12-03 02:42:22 UTC
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.
Comment 15 Justin Hibbits freebsd_committer 2014-12-03 15:52:01 UTC
Created attachment 150143 [details]
The correct UNAME_M patch
Comment 16 Dirk Heinrichs 2014-12-03 19:08:46 UTC
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.
Comment 17 commit-hook freebsd_committer 2014-12-09 15:56:18 UTC
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
Comment 18 Koop Mast freebsd_committer 2014-12-09 16:01:58 UTC
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.