meta-toolchain-sdk failure

meta-toolchain-sdk failure

[Kumar Gala]

Seeing the following when trying to do a meta-toolchain-sdk build w/latest git.  Guessing we're missing a depend of some sort:

| error: Failed dependencies:
| 	telepathy-python is needed by task-core-standalone-gmae-sdk-target-1.0-r13.ppc64e5500

I think the reset of this is noise:

| error: LOOP:
| error: removing dbus-lib-1.4.12-r0.ppc64e5500 "Requires(hint): dbus" from tsort relations.
| error: removing dbus-1.4.12-r0.ppc64e5500 "Requires: dbus-lib >= 1.4.12" from tsort relations.
| error: LOOP:
| error: removing libcamel-dev-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc64e5500 "Requires(hint): eds-dbus-dev" from tsort relations.
| error: removing eds-dbus-dev-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc64e5500 "Requires(hint): libebook-dev" from tsort relations.
| error: removing libebook-dev-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc64e5500 "Requires(hint): libcamel-dev" fromERROR: Function 'do_populate_sdk' failed (see /local/home/galak/git/poky/build-p5020/tmp/work/ppc64e5500-poky-linux/meta-toolchain-gmae-1.0-r5/temp/log.do_populate_sdk.23223 for further information)
|  tsort relations.
| error: LOOP:
| error: removing libc6-dev-2.13-r12+svnr14157.ppc64e5500 "Requires(hint): bash-dev" from tsort relations.
| error: removing bash-dev-4.1-r2.ppc64e5500 "Requires(hint): libc6-dev" from tsort relations.
| error: LOOP:
| error: removing eglibc-dbg-2.13-r12+svnr14157.ppc64e5500 "Requires(hint): bash-dbg" from tsort relations.
| error: removing bash-dbg-4.1-r2.ppc64e5500 "Requires(hint): eglibc-dbg" from tsort relations.
| error: LOOP:
| error: removing libudev-164-r3.ppc64e5500 "Requires: udev = 164-r3" from tsort relations.
| error: removing udev-164-r3.ppc64e5500 "Requires: libudev >= 164" from tsort relations.
| error: LOOP:
| error: removing bluez4-dbg-4.82-r0.ppc64e5500 "Requires(hint): bluez-hcidump-dbg" from tsort relations.
| error: removing bluez-hcidump-dbg-2.0-r0.ppc64e5500 "Requires(hint): bluez4-dbg" from tsort relations.
| error: LOOP:
| error: removing bluez-hcidump-dev-2.0-r0.ppc64e5500 "Requires(hint): bluez4-dev" from tsort relations.
| error: removing bluez4-dev-4.82-r0.ppc64e5500 "Requires(hint): bluez-hcidump-dev" from tsort relations.
| error: LOOP:
| error: removing libcap-dev-2.22-r0.ppc64e5500 "Requires(hint): libpam-dev" from tsort relations.
| error: removing libpam-dev-1.1.4-r1.ppc64e5500 "Requires(hint): coreutils-dev" from tsort relations.
| error: removing coreutils-dev-8.12-r3.ppc64e5500 "Requires(hint): libcap-dev" from tsort relations.
| error: LOOP:
| error: removing libedata-book-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc64e5500 "Requires: libebook >= 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f" from tsort relations.
| error: removing libebook-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc64e5500 "Requires(hint): libedata-book" from tsort relations.
| error: LOOP:
| error: removing udev-dbg-164-r3.ppc64e5500 "Requires(hint): libudev-dbg" from tsort relations.
| error: removing libudev-dbg-164-r3.ppc64e5500 "Requires(hint): udev-dbg" from tsort relations.
| error: LOOP:
| error: removing libecal-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc64e5500 "Requires(hint): libedata-cal" from tsort relations.
| error: removing libedata-cal-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc64e5500 "Requires: libecal >= 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f" from tsort relations.

- k

Re: meta-toolchain-sdk failure

[Richard Purdie]

On Tue, 2011-08-09 at 08:45 -0500, Kumar Gala wrote:
> Seeing the following when trying to do a meta-toolchain-sdk build w/latest git.  Guessing we're missing a depend of some sort:
> 
> | error: Failed dependencies:
> | 	telepathy-python is needed by task-core-standalone-gmae-sdk-target-1.0-r13.ppc64e5500
> 
> I think the reset of this is noise:

It is, yes.

Did telepathy-python build at all (you can check if any stamps are
present)? Are there any packages generated (in the deploy/rpm
directory)?

I'm trying to work out if this wasn't present because it didn't build,
because it did build but didn't package correctly or whether the rootfs
code just isn't seeing the package...

Cheers,

Richard

Re: meta-toolchain-sdk failure

[Kumar Gala]

On Aug 9, 2011, at 8:58 AM, Richard Purdie wrote:

> On Tue, 2011-08-09 at 08:45 -0500, Kumar Gala wrote:
>> Seeing the following when trying to do a meta-toolchain-sdk build w/latest git.  Guessing we're missing a depend of some sort:
>> 
>> | error: Failed dependencies:
>> | 	telepathy-python is needed by task-core-standalone-gmae-sdk-target-1.0-r13.ppc64e5500
>> 
>> I think the reset of this is noise:
> 
> It is, yes.
> 
> Did telepathy-python build at all (you can check if any stamps are
> present)? Are there any packages generated (in the deploy/rpm
> directory)?
> 
> I'm trying to work out if this wasn't present because it didn't build,
> because it did build but didn't package correctly or whether the rootfs
> code just isn't seeing the package...

Seems it build but no package:

build-p5020/tmp/deploy/rpm/ppc64e5500/telepathy-python-dev-0.15.19-r2.ppc64e5500.rpm
build-p5020/tmp/deploy/rpm/ppc64e5500/telepathy-python-dbg-0.15.19-r2.ppc64e5500.rpm

Looking at log.do_package

WARNING: For recipe telepathy-python, the following files were installed but not shipped in any package:
WARNING:   /usr/lib/python2.6/site-packages/telepathy/__init__.pyo
WARNING:   /usr/lib/python2.6/site-packages/telepathy/utils.py
WARNING:   /usr/lib/python2.6/site-packages/telepathy/utils.pyc
WARNING:   /usr/lib/python2.6/site-packages/telepathy/interfaces.py
WARNING:   /usr/lib/python2.6/site-packages/telepathy/errors.py
WARNING:   /usr/lib/python2.6/site-packages/telepathy/_version.pyo
WARNING:   /usr/lib/python2.6/site-packages/telepathy/__init__.py
WARNING:   /usr/lib/python2.6/site-packages/telepathy/_version.py
WARNING:   /usr/lib/python2.6/site-packages/telepathy/__init__.pyc
WARNING:   /usr/lib/python2.6/site-packages/telepathy/_version.pyc
WARNING:   /usr/lib/python2.6/site-packages/telepathy/constants.pyc
...

Since this build is with 64-bit we should be in /usr/lib64 but are not.

I believe there are other python packages that aren't respecting ${libdir}

There was a patch to xcb, but that still had issues as for some reason aclocal.m4 is getting regnerated and overriding PYTHON_LIB_PREFIX.

- k

python automake dirs (was meta-toolchain-sdk failure)

[Kumar Gala]

On Aug 9, 2011, at 10:32 AM, Kumar Gala wrote:

> 
> On Aug 9, 2011, at 8:58 AM, Richard Purdie wrote:
> 
>> On Tue, 2011-08-09 at 08:45 -0500, Kumar Gala wrote:
>>> Seeing the following when trying to do a meta-toolchain-sdk build w/latest git.  Guessing we're missing a depend of some sort:
>>> 
>>> | error: Failed dependencies:
>>> | 	telepathy-python is needed by task-core-standalone-gmae-sdk-target-1.0-r13.ppc64e5500
>>> 
>>> I think the reset of this is noise:
>> 
>> It is, yes.
>> 
>> Did telepathy-python build at all (you can check if any stamps are
>> present)? Are there any packages generated (in the deploy/rpm
>> directory)?
>> 
>> I'm trying to work out if this wasn't present because it didn't build,
>> because it did build but didn't package correctly or whether the rootfs
>> code just isn't seeing the package...
> 
> Seems it build but no package:
> 
> build-p5020/tmp/deploy/rpm/ppc64e5500/telepathy-python-dev-0.15.19-r2.ppc64e5500.rpm
> build-p5020/tmp/deploy/rpm/ppc64e5500/telepathy-python-dbg-0.15.19-r2.ppc64e5500.rpm
> 
> Looking at log.do_package
> 
> WARNING: For recipe telepathy-python, the following files were installed but not shipped in any package:
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/__init__.pyo
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/utils.py
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/utils.pyc
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/interfaces.py
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/errors.py
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/_version.pyo
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/__init__.py
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/_version.py
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/__init__.pyc
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/_version.pyc
> WARNING:   /usr/lib/python2.6/site-packages/telepathy/constants.pyc
> ...
> 
> Since this build is with 64-bit we should be in /usr/lib64 but are not.
> 
> I believe there are other python packages that aren't respecting ${libdir}
> 
> There was a patch to xcb, but that still had issues as for some reason aclocal.m4 is getting regnerated and overriding PYTHON_LIB_PREFIX.

So the root of this seems to stem from the following in automake's python.m4:

am_cv_python_pythondir=$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages
am_cv_python_pyexecdir=$PYTHON_EXEC_PREFIX/lib/python$PYTHON_VERSION/site-packages

So the question at hand is how to fix this?

Do we patch automake to respect libdir setting for these?

something like:

--- python.m4.orig	2011-08-09 11:46:19.511163337 -0500
+++ python.m4	2011-08-09 11:49:43.623022930 -0500
@@ -88,12 +88,13 @@
     [am_cv_python_version=`$PYTHON -c "import sys; sys.stdout.write(sys.version[[:3]])"`])
   AC_SUBST([PYTHON_VERSION], [$am_cv_python_version])
 
-  dnl Use the values of $prefix and $exec_prefix for the corresponding
-  dnl values of PYTHON_PREFIX and PYTHON_EXEC_PREFIX.  These are made
+  dnl Use the values of $prefix, $libdir and $exec_prefix for the corresponding
+  dnl values of PYTHON_PREFIX PYTHON_LIB_PREFIX, and PYTHON_EXEC_PREFIX.  These are made
   dnl distinct variables so they can be overridden if need be.  However,
   dnl general consensus is that you shouldn't need this ability.
 
   AC_SUBST([PYTHON_PREFIX], ['${prefix}'])
+  AC_SUBST([PYTHON_LIB_PREFIX], ['${libdir}'])
   AC_SUBST([PYTHON_EXEC_PREFIX], ['${exec_prefix}'])
 
   dnl At times (like when building shared libraries) you may want
@@ -122,7 +123,7 @@
        am_py_prefix=$prefix
      fi
      am_cv_python_pythondir=`$PYTHON -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='$am_py_prefix'))" 2>/dev/null ||
-     echo "$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages"`
+     echo "$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages"`
      case $am_cv_python_pythondir in
      $am_py_prefix*)
        am__strip_prefix=`echo "$am_py_prefix" | sed 's|.|.|g'`
@@ -132,7 +133,7 @@
        case $am_py_prefix in
          /usr|/System*) ;;
          *)
-	  am_cv_python_pythondir=$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages
+	  am_cv_python_pythondir=$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages
 	  ;;
        esac
        ;;
@@ -160,7 +161,7 @@
        am_py_exec_prefix=$exec_prefix
      fi
      am_cv_python_pyexecdir=`$PYTHON -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='$am_py_exec_prefix'))" 2>/dev/null ||
-     echo "$PYTHON_EXEC_PREFIX/lib/python$PYTHON_VERSION/site-packages"`
+     echo "$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages"`
      case $am_cv_python_pyexecdir in
      $am_py_exec_prefix*)
        am__strip_prefix=`echo "$am_py_exec_prefix" | sed 's|.|.|g'`
@@ -170,7 +171,7 @@
        case $am_py_exec_prefix in
          /usr|/System*) ;;
          *)
-	   am_cv_python_pyexecdir=$PYTHON_EXEC_PREFIX/lib/python$PYTHON_VERSION/site-packages
+	   am_cv_python_pyexecdir=$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages
 	   ;;
        esac
        ;;



- k

Re: python automake dirs (was meta-toolchain-sdk failure)

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> So the root of this seems to stem from the following in automake's
> python.m4:
> 
> am_cv_python_pythondir=$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages
>
> 
am_cv_python_pyexecdir=$PYTHON_EXEC_PREFIX/lib/python$PYTHON_VERSION/site-packages
> 
> So the question at hand is how to fix this?
> 
> Do we patch automake to respect libdir setting for these?
> 

yes seems sane to me

> something like:
> 
> --- python.m4.orig	2011-08-09 11:46:19.511163337 -0500 +++ python.m4
> 2011-08-09 11:49:43.623022930 -0500 @@ -88,12 +88,13 @@ 
> [am_cv_python_version=`$PYTHON -c "import sys;
> sys.stdout.write(sys.version[[:3]])"`]) AC_SUBST([PYTHON_VERSION],
> [$am_cv_python_version])
> 
> -  dnl Use the values of $prefix and $exec_prefix for the
> corresponding -  dnl values of PYTHON_PREFIX and PYTHON_EXEC_PREFIX.
> These are made +  dnl Use the values of $prefix, $libdir and
> $exec_prefix for the corresponding +  dnl values of PYTHON_PREFIX
> PYTHON_LIB_PREFIX, and PYTHON_EXEC_PREFIX.  These are made dnl
> distinct variables so they can be overridden if need be.  However, 
> dnl general consensus is that you shouldn't need this ability.
> 
> AC_SUBST([PYTHON_PREFIX], ['${prefix}']) +
> AC_SUBST([PYTHON_LIB_PREFIX], ['${libdir}']) 
> AC_SUBST([PYTHON_EXEC_PREFIX], ['${exec_prefix}'])
> 
> dnl At times (like when building shared libraries) you may want @@
> -122,7 +123,7 @@ am_py_prefix=$prefix fi 
> am_cv_python_pythondir=`$PYTHON -c "import sys; from distutils import
> sysconfig;
> sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='$am_py_prefix'))"
> 2>/dev/null || -     echo
> "$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages"` +     echo
> "$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages"` case
> $am_cv_python_pythondir in $am_py_prefix*) am__strip_prefix=`echo
> "$am_py_prefix" | sed 's|.|.|g'` @@ -132,7 +133,7 @@ case
> $am_py_prefix in /usr|/System*) ;; *) -
> am_cv_python_pythondir=$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages
>
> 
+	
am_cv_python_pythondir=$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages
> ;; esac ;; @@ -160,7 +161,7 @@ am_py_exec_prefix=$exec_prefix fi 
> am_cv_python_pyexecdir=`$PYTHON -c "import sys; from distutils import
> sysconfig;
> sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='$am_py_exec_prefix'))"
> 2>/dev/null || -     echo
> "$PYTHON_EXEC_PREFIX/lib/python$PYTHON_VERSION/site-packages"` +
> echo "$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages"` case
> $am_cv_python_pyexecdir in $am_py_exec_prefix*) 
> am__strip_prefix=`echo "$am_py_exec_prefix" | sed 's|.|.|g'` @@
> -170,7 +171,7 @@ case $am_py_exec_prefix in /usr|/System*) ;; *) -
> am_cv_python_pyexecdir=$PYTHON_EXEC_PREFIX/lib/python$PYTHON_VERSION/site-packages
>
> 
+	
am_cv_python_pyexecdir=$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages
> ;; esac ;;
> 
> 
> 
> - k _______________________________________________ Openembedded-core
> mailing list Openembedded-core@lists.openembedded.org 
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


- --
> 
- -Khem
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5CmWUACgkQuwUzVZGdMxRKIwCeIMURyalficv+nODveSc0q1uE
ldkAnjBjNrI7Un528uulbm4sowLgiclj
=AyDt
-----END PGP SIGNATURE-----

Re: python automake dirs (was meta-toolchain-sdk failure)

[Kumar Gala]

On Aug 10, 2011, at 9:44 AM, Khem Raj wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
>> So the root of this seems to stem from the following in automake's
>> python.m4:
>> 
>> am_cv_python_pythondir=$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages
>> 
>> 
> am_cv_python_pyexecdir=$PYTHON_EXEC_PREFIX/lib/python$PYTHON_VERSION/site-packages
>> 
>> So the question at hand is how to fix this?
>> 
>> Do we patch automake to respect libdir setting for these?
>> 
> 
> yes seems sane to me

posted some patches in which I do this via python-dir.bbclass which I think is better

- k

Re: python automake dirs (was meta-toolchain-sdk failure)

[Richard Purdie]

On Wed, 2011-08-10 at 11:51 -0500, Kumar Gala wrote:
> On Aug 10, 2011, at 9:44 AM, Khem Raj wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> >> So the root of this seems to stem from the following in automake's
> >> python.m4:
> >> 
> >> am_cv_python_pythondir=$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages
> >> 
> >> 
> > am_cv_python_pyexecdir=$PYTHON_EXEC_PREFIX/lib/python$PYTHON_VERSION/site-packages
> >> 
> >> So the question at hand is how to fix this?
> >> 
> >> Do we patch automake to respect libdir setting for these?
> >> 
> > 
> > yes seems sane to me
> 
> posted some patches in which I do this via python-dir.bbclass which I think is better

I think I'm in favour of changing the m4 files in this case now I better
understand the problem...

Cheers,

Richard