* meta-toolchain-sdk failure @ 2011-08-09 13:45 Kumar Gala 2011-08-09 13:58 ` Richard Purdie 0 siblings, 1 reply; 7+ messages in thread From: Kumar Gala @ 2011-08-09 13:45 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: meta-toolchain-sdk failure 2011-08-09 13:45 meta-toolchain-sdk failure Kumar Gala @ 2011-08-09 13:58 ` Richard Purdie 2011-08-09 15:32 ` Kumar Gala 0 siblings, 1 reply; 7+ messages in thread From: Richard Purdie @ 2011-08-09 13:58 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: meta-toolchain-sdk failure 2011-08-09 13:58 ` Richard Purdie @ 2011-08-09 15:32 ` Kumar Gala 2011-08-09 16:50 ` python automake dirs (was meta-toolchain-sdk failure) Kumar Gala 0 siblings, 1 reply; 7+ messages in thread From: Kumar Gala @ 2011-08-09 15:32 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* python automake dirs (was meta-toolchain-sdk failure) 2011-08-09 15:32 ` Kumar Gala @ 2011-08-09 16:50 ` Kumar Gala 2011-08-10 14:44 ` Khem Raj 0 siblings, 1 reply; 7+ messages in thread From: Kumar Gala @ 2011-08-09 16:50 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: python automake dirs (was meta-toolchain-sdk failure) 2011-08-09 16:50 ` python automake dirs (was meta-toolchain-sdk failure) Kumar Gala @ 2011-08-10 14:44 ` Khem Raj 2011-08-10 16:51 ` Kumar Gala 0 siblings, 1 reply; 7+ messages in thread From: Khem Raj @ 2011-08-10 14:44 UTC (permalink / raw) To: openembedded-core -----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----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: python automake dirs (was meta-toolchain-sdk failure) 2011-08-10 14:44 ` Khem Raj @ 2011-08-10 16:51 ` Kumar Gala 2011-08-10 17:22 ` Richard Purdie 0 siblings, 1 reply; 7+ messages in thread From: Kumar Gala @ 2011-08-10 16:51 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: python automake dirs (was meta-toolchain-sdk failure) 2011-08-10 16:51 ` Kumar Gala @ 2011-08-10 17:22 ` Richard Purdie 0 siblings, 0 replies; 7+ messages in thread From: Richard Purdie @ 2011-08-10 17:22 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-08-10 17:28 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-08-09 13:45 meta-toolchain-sdk failure Kumar Gala 2011-08-09 13:58 ` Richard Purdie 2011-08-09 15:32 ` Kumar Gala 2011-08-09 16:50 ` python automake dirs (was meta-toolchain-sdk failure) Kumar Gala 2011-08-10 14:44 ` Khem Raj 2011-08-10 16:51 ` Kumar Gala 2011-08-10 17:22 ` Richard Purdie
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.