Re: [yocto] Supporting upcoming distribution releases
update accroding your suggestion.
This patch is for bitbake indeed, but bitbake is not part of
openembedded. Is it RIGHT?
diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..acf4e96 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,34 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ #the 'python -V' need redirect to stdout
+ #once we can ensure every distribution has 'python2' (currently,
except
+ #ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ #and remove this patch.
+ # precondition:
+ #$BUILDDIR is not NULL, but I doubt when it will be NULL.
+ #user have not made the file $BUILDDIR/python by himself.
+ if [ -z `/usr/bin/env python -V 21|grep '^Python 2\.'` ]; then
+ PYTHON2_BIN=
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n `$PY_BIN -V 21|grep '^Python 2\.'` ]; then
+PYTHON2_BIN=$PY_BIN
+break
+ fi
+ done
+ if [ -n $PYTHON2_BIN ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH=$BUILDDIR:$PATH
+ echo NOTE: poky will use '$PY_BIN' to execute python code.
+ else
+ echo ERROR: unable to find Python 2.x, BitBake requires
Python 2.6 or
+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n $BUILDDIR ] cd $BUILDDIR
fi
On Wed, 2011-07-20 at 09:13 +0800, Joshua Lock wrote:
On Thu, 2011-07-14 at 09:34 +0800, NiQingliang wrote:
new version
diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0fe1b5e 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,35 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ #the 'python -V' need redirect to stdout
+ #once we can ensure every distribution has 'python2' (currently,
except
+ #ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ #and remove this patch.
+ # precondition:
+ #$BUILDDIR is not NULL, but I doubt when it will be NULL.
+ #user have not made the file $BUILDDIR/python by himself.
+ if [ -z `/usr/bin/env python -V 21|grep '^Python 2\.'` ]; then
+ echo WARNING: your default python is not 2.x, so autodetect...
I'm not sure we need to print this.
+ PYTHON2_BIN=
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n `$PY_BIN -V 21|grep '^Python 2\.'` ]; then
+PYTHON2_BIN=$PY_BIN
+break
+ fi
+ done
+ if [ -n $PYTHON2_BIN ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH=$BUILDDIR:$PATH
+ echo WARNING: poky will use '$PY_BIN' to execute python
code.
I can live without this message but if we do leave it in we should
probably call it a NOTE rather than WARNING.
+ else
+ echo ERROR: poky can't find python 2.x.
Perhaps make this a little more informative?
ERROR: unable to find Python 2.x, BitBake requires Python 2.6 or 2.7.
+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n $BUILDDIR ] cd $BUILDDIR
fi
I can verify that this works as expected (i.e. does nothing) on my
Fedora 15 machine with Python 2.7.1.
Could you submit the patch to the openembedded-core mailing list so that
it can be considered for inclusion in the Yocto project's shared
upstream?
Thanks,
Joshua
--
Joshua Lock
Yocto Project Johannes factotum
Intel Open Source Technology Centre
--
倪庆亮
TEL:13588371863
E-MAIL: niqingli...@insigma.com.cn
BLOG: http://niqingliang2003.wordpress.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
Oh, sorry, I have found the git tree of openembedded-core.
On Wed, 2011-07-20 at 10:31 +0800, NiQingliang wrote:
update accroding your suggestion.
This patch is for bitbake indeed, but bitbake is not part of
openembedded. Is it RIGHT?
diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..acf4e96 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,34 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ #the 'python -V' need redirect to stdout
+ #once we can ensure every distribution has 'python2' (currently,
except
+ #ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ #and remove this patch.
+ # precondition:
+ #$BUILDDIR is not NULL, but I doubt when it will be NULL.
+ #user have not made the file $BUILDDIR/python by himself.
+ if [ -z `/usr/bin/env python -V 21|grep '^Python 2\.'` ]; then
+ PYTHON2_BIN=
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n `$PY_BIN -V 21|grep '^Python 2\.'` ]; then
+PYTHON2_BIN=$PY_BIN
+break
+ fi
+ done
+ if [ -n $PYTHON2_BIN ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH=$BUILDDIR:$PATH
+ echo NOTE: poky will use '$PY_BIN' to execute python code.
+ else
+ echo ERROR: unable to find Python 2.x, BitBake requires
Python 2.6 or
+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n $BUILDDIR ] cd $BUILDDIR
fi
On Wed, 2011-07-20 at 09:13 +0800, Joshua Lock wrote:
On Thu, 2011-07-14 at 09:34 +0800, NiQingliang wrote:
new version
diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0fe1b5e 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,35 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ #the 'python -V' need redirect to stdout
+ #once we can ensure every distribution has 'python2' (currently,
except
+ #ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ #and remove this patch.
+ # precondition:
+ #$BUILDDIR is not NULL, but I doubt when it will be NULL.
+ #user have not made the file $BUILDDIR/python by himself.
+ if [ -z `/usr/bin/env python -V 21|grep '^Python 2\.'` ]; then
+ echo WARNING: your default python is not 2.x, so autodetect...
I'm not sure we need to print this.
+ PYTHON2_BIN=
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n `$PY_BIN -V 21|grep '^Python 2\.'` ]; then
+PYTHON2_BIN=$PY_BIN
+break
+ fi
+ done
+ if [ -n $PYTHON2_BIN ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH=$BUILDDIR:$PATH
+ echo WARNING: poky will use '$PY_BIN' to execute python
code.
I can live without this message but if we do leave it in we should
probably call it a NOTE rather than WARNING.
+ else
+ echo ERROR: poky can't find python 2.x.
Perhaps make this a little more informative?
ERROR: unable to find Python 2.x, BitBake requires Python 2.6 or 2.7.
+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n $BUILDDIR ] cd $BUILDDIR
fi
I can verify that this works as expected (i.e. does nothing) on my
Fedora 15 machine with Python 2.7.1.
Could you submit the patch to the openembedded-core mailing list so that
it can be considered for inclusion in the Yocto project's shared
upstream?
Thanks,
Joshua
--
Joshua Lock
Yocto Project Johannes factotum
Intel Open Source Technology Centre
--
倪庆亮
TEL:13588371863
E-MAIL: niqingli...@insigma.com.cn
BLOG: http://niqingliang2003.wordpress.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
倪庆亮
TEL:13588371863
E-MAIL: niqingli...@insigma.com.cn
BLOG: http://niqingliang2003.wordpress.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
first sorry about that, indeed I don't know how to commit a patch, so
just paste the diff result here.
diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0da8bc0 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,20 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python version 2.x
+ # the 'python -V' need redirect to stdout
+ # precondition:
+ #$BUILDDIR is not NULL, but I doubt when it will be NULL.
+ #user have not made the file $BUILDDIR/python by himself.
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n `$PY_BIN -V 21|grep '^Python 2\.'` ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH=$BUILDDIR:$PATH
+ break
+ fi
+ done
+
[ -n $BUILDDIR ] cd $BUILDDIR
fi
On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
/usr/bin/env python2
/usr/bin/env python2.7
These are both valid on Fedora 15, iirc before distributions started
shipping Python 3 they were less common though...
both of them are ok for archlinux, but I don't know which is ok for
other distributions, maybe both are not.
maybe we can make a shell script to detect the python version, and make
a symbollink to the right one in some directory, and add the directory
into env var PATH.
Patches welcome :-)
I looked at it briefly and the work would require more time than I have
spare right now just to ensure it worked on all required distributions.
If you'd like to work on a patch I'd be happy to help test and review.
Cheers,
Joshua
--
Joshua Lock
Yocto Project Johannes factotum
Intel Open Source Technology Centre
--
倪庆亮
TEL:13588371863
E-MAIL: niqingli...@insigma.com.cn
BLOG: http://niqingliang2003.wordpress.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
new version
diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0fe1b5e 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,35 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ #the 'python -V' need redirect to stdout
+ #once we can ensure every distribution has 'python2' (currently,
except
+ #ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ #and remove this patch.
+ # precondition:
+ #$BUILDDIR is not NULL, but I doubt when it will be NULL.
+ #user have not made the file $BUILDDIR/python by himself.
+ if [ -z `/usr/bin/env python -V 21|grep '^Python 2\.'` ]; then
+ echo WARNING: your default python is not 2.x, so autodetect...
+ PYTHON2_BIN=
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n `$PY_BIN -V 21|grep '^Python 2\.'` ]; then
+PYTHON2_BIN=$PY_BIN
+break
+ fi
+ done
+ if [ -n $PYTHON2_BIN ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH=$BUILDDIR:$PATH
+ echo WARNING: poky will use '$PY_BIN' to execute python
code.
+ else
+ echo ERROR: poky can't find python 2.x.
+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n $BUILDDIR ] cd $BUILDDIR
fi
On Thu, 2011-07-14 at 01:01 +0800, Darren Hart wrote:
On 07/13/2011 01:04 AM, NiQingliang wrote:
first sorry about that, indeed I don't know how to commit a patch, so
just paste the diff result here.
diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0da8bc0 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,20 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
Before searching manually, we should attempt to use whatever is set in
the environment.
--
Darren
+ # find the python version 2.x
+ # the 'python -V' need redirect to stdout
+ # precondition:
+ #$BUILDDIR is not NULL, but I doubt when it will be NULL.
+ #user have not made the file $BUILDDIR/python by himself.
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n `$PY_BIN -V 21|grep '^Python 2\.'` ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH=$BUILDDIR:$PATH
+ break
+ fi
+ done
+
[ -n $BUILDDIR ] cd $BUILDDIR
fi
On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
/usr/bin/env python2
/usr/bin/env python2.7
These are both valid on Fedora 15, iirc before distributions started
shipping Python 3 they were less common though...
both of them are ok for archlinux, but I don't know which is ok for
other distributions, maybe both are not.
maybe we can make a shell script to detect the python version, and make
a symbollink to the right one in some directory, and add the directory
into env var PATH.
Patches welcome :-)
I looked at it briefly and the work would require more time than I have
spare right now just to ensure it worked on all required distributions.
If you'd like to work on a patch I'd be happy to help test and review.
Cheers,
Joshua
--
Joshua Lock
Yocto Project Johannes factotum
Intel Open Source Technology Centre
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
倪庆亮
TEL:13588371863
E-MAIL: niqingli...@insigma.com.cn
BLOG: http://niqingliang2003.wordpress.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
I think Archlinux is the preferred choice.-_- Just joke. I doubt why the bitbake need python2.x but just use /bin/env python. I think If it need a specific version python, it should write it in the shebang. e.g. /bin/env python2.6 On Wed, 2011-07-13 at 05:08 +0800, Richard Purdie wrote: On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote: On 07/12/2011 11:51 AM, Joshua Lock wrote: In our technical team call today we spent some time discussing how to support distribution releases that are due to happen around the time of Yocto 1.1. Yocto 1.1 is scheduled for release on October 6th[1], the same month in which both Ubuntu and Fedora have new releases planned[2,3]. OpenSUSE doesn't have a release scheduled until November 10th[4]. We should accommodate for these releases in our planning around 1.1 as we need to ensure that Yocto 1.1 can be used on the new versions of the chosen supported distros. I had initially suggested we have people doing test and any relevant development around the beta cycles of Ubuntu and Fedora: Fedora Beta (2011-09-20) Ubuntu (2011-09-01) In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which afaict (based on the 6th milestone being followed by an RC) should roughly equate to a beta. However this aligns with our RC period at which point we may not want to accept large patches? To meet our stabilise complete goal of August 29th we'd have to have people testing with: Fedora Alpha (2011-08-16) Ubuntu Alpha 3 (2011-08-04) OpenSUSE Milestone 4 (2011-08-11) What are peoples thoughts on this? At the very least a sanity test to know which sorts of issues we'll hit with these would be valuable. However, I believe our policy is N-1, and not N+1,N,N-1, so supporting not-yet released versions isn't something I think we should spend too much time on. Minor fixes to support these post release seem like good candidates for a point release. Much as I'd like to agree with you, traditionally this does tend to bite us hard. The fixes some of the releases have needed are sometimes not so minor too :(. The reason is that we have a community with a significant portion of people who do stay close to the edge as far as distros go. They'll take latest releases and expect Yocto to work on them even if the releases come out at the same time. Its not often realised how far in advance trees get frozen for stabilisation. So summary is I'm in favour of trying to identify problems early and then doing what we can to address them... As such, this time around I'll update my build machine to latest Ubuntu at the beginning of August Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
OK, I will do it.:) On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote: On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote: /usr/bin/env python2 /usr/bin/env python2.7 These are both valid on Fedora 15, iirc before distributions started shipping Python 3 they were less common though... both of them are ok for archlinux, but I don't know which is ok for other distributions, maybe both are not. maybe we can make a shell script to detect the python version, and make a symbollink to the right one in some directory, and add the directory into env var PATH. Patches welcome :-) I looked at it briefly and the work would require more time than I have spare right now just to ensure it worked on all required distributions. If you'd like to work on a patch I'd be happy to help test and review. Cheers, Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dependency gui problem
according my understanding, the parseXX serials events is used for parsing recipes window, and the cacheXX serials events is used for loading cache window. The two windows is mutual-excluded. thanks!!! I will ask the bitbake developer, and will show you if I got the answer. On Fri, 2011-07-01 at 16:44 +0800, Cui, Dexuan wrote: NiQingliang wrote: I have changed that code section, and solved my problem, but I don't know if it is the right way. if isinstance(event, bb.event.CacheLoadCompleted): pbar.hide() continue ... if isinstance(event, bb.event.ParseCompleted): pbar.hide() continue On Fri, 2011-07-01 at 10:45 +0800, NiQingliang wrote: I have looked the fiel depexp.py, and have some doubt: why in ParseCompleted, the progress bar will hide, but in CacheLoadCompleted, it will not??? I guess there should be a ParseCompleted event after the CacheLoadCompleted event(?), but on your host, the ParseCompleted doesn't happen somehow? I'm not sure your change is ok, because if it's a generic issue, why can't I reproduce the issue? I don't think these two events need different process. if isinstance(event, bb.event.CacheLoadCompleted): gtk.gdk.threads_enter() pbar.update(progress_total, progress_total) gtk.gdk.threads_leave() continue ... if isinstance(event, bb.event.ParseCompleted): pbar.hide() continue Thanks, -- Dexuan -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] mpc8315 ubifs fail
hello, does any one tested rootfs formats execpt the default tar.gz on mpc8315? I added follow sentence in mpc8315e-rdb.conf IMAGE_FSTYPES += ubifs and get follow error. NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Started ERROR: '/media/Datum/yocto/poky/meta/recipes-core/images/core-image-minimal.bb' failed ERROR: Logfile of failure stored in: /media/Datum/yocto/build_mpc8315erdb/tmp/work/mpc8315e_rdb-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.10589 Log data follows: | Generating solve db for /media/Datum/yocto/build_mpc8315erdb/tmp/deploy/rpm/mpc8315e_rdb... |total: 1 0.00 MB 1.442006 secs |fingerprint: 819 0.008270 MB 0.031820 secs |install: 273 0.00 MB 0.320556 secs |dbadd: 273 0.00 MB 0.312151 secs |dbget:2695 0.00 MB 0.004221 secs |dbput: 273 1.428948 MB 0.257721 secs |readhdr: 2731 2.793536 MB 0.377335 secs |hdrload: 1365 4.161236 MB 0.006957 secs |hdrget: 49433 0.00 MB 0.041538 secs | Generating solve db for /media/Datum/yocto/build_mpc8315erdb/tmp/deploy/rpm/ppc603e... |total: 1 0.00 MB 7.484153 secs |fingerprint: 3612 0.072922 MB 0.153439 secs |install: 1204 0.00 MB 1.590757 secs |dbadd:1204 0.00 MB 1.560741 secs |dbget: 26715 0.00 MB 0.025684 secs |dbput:1204 7.017472 MB 1.366692 secs |readhdr: 12041 13.942562 MB 3.227930 secs |hdrload: 7446 28.703306 MB 0.034632 secs |hdrget: 222565 0.00 MB 0.179700 secs | Generating solve db for /media/Datum/yocto/build_mpc8315erdb/tmp/deploy/rpm/all... |total: 1 0.00 MB 0.072481 secs |fingerprint:18 0.24 MB 0.000227 secs |install: 6 0.00 MB 0.023966 secs |dbadd: 6 0.00 MB 0.021870 secs |dbget: 19 0.00 MB 0.61 secs |dbput: 6 0.018276 MB 0.003660 secs |readhdr:61 0.036768 MB 0.014909 secs |hdrload:33 0.061968 MB 0.000142 secs |hdrget:983 0.00 MB 0.002318 secs | Generating solve db for /media/Datum/yocto/build_mpc8315erdb/tmp/deploy/rpm/all... | Processing task-core-boot... | error: LOOP: | error: removing eglibc-dev-2.13-r3+svnr14157.ppc603e Requires: /lib/libnss_hesiod.so.2 from tsort relations. | error: removing eglibc-extra-nss-2.13-r3+svnr14157.ppc603e Requires: eglibc-dev = 2.13 from tsort relations. | error: LOOP: | error: removing busybox-udhcpc-1.18.4-r4.ppc603e Requires(post): /bin/sh from tsort relations. | error: removing busybox-1.18.4-r4.ppc603e Requires(hint): busybox-udhcpc from tsort relations. | error: LOOP: | error: removing eglibc-dev-2.13-r3+svnr14157.ppc603e Requires: /lib/libcidn.so.1 from tsort relations. | error: removing libcidn1-2.13-r3+svnr14157.ppc603e Requires: eglibc-dev = 2.13 from tsort relations. | error: LOOP: | error: removing busybox-syslog-1.18.4-r4.ppc603e Requires(post): /bin/sh from tsort relations. | error: removing busybox-1.18.4-r4.ppc603e Requires(hint): busybox-syslog from tsort relations. | error: LOOP: | error: removing eglibc-dev-2.13-r3+svnr14157.ppc603e Requires: eglibc = 2.13-r3+svnr14157 from tsort relations. | error: removing eglibc-2.13-r3+svnr14157.ppc603e Requires: eglibc-dev = 2.13 from tsort relations. | error: LOOP: | error: removing eglibc-dev-2.13-r3+svnr14157.ppc603e Requires: /lib/libthread_db.so.1 from tsort relations. | error: removing libthread-db1-2.13-r3+svnr14157.ppc603e Requires: eglibc-dev = 2.13 from tsort relations. | error: LOOP: | error: removing libudev0-164-r2.ppc603e Requires: udev = 164-r2 from tsort relations. | error: removing udev-164-r2.ppc603e Requires: libudev0 = 164 from tsort relations. | Manifest: /media/Datum/yocto/build_mpc8315erdb/tmp/work/mpc8315e_rdb-poky-linux/core-image-minimal-1.0-r0/rootfs/install/install.manifest | error: LOOP: | error: removing eglibc-dev-2.13-r3+svnr14157.ppc603e Requires: /lib/libnss_hesiod.so.2 from tsort relations. | error: removing eglibc-extra-nss-2.13-r3+svnr14157.ppc603e Requires: eglibc-dev = 2.13 from tsort relations. | error: LOOP: | error: removing busybox-1.18.4-r4.ppc603e Requires(hint): busybox-udhcpc from tsort relations. | error: removing busybox-udhcpc-1.18.4-r4.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing eglibc-dev-2.13-r3+svnr14157.ppc603e Requires: /lib/libcidn.so.1 from tsort relations. | error: removing libcidn1-2.13-r3+svnr14157.ppc603e Requires: eglibc-dev = 2.13 from tsort relations. | error: LOOP: | error: removing
Re: [yocto] dependency gui problem
I'm using python2.7 I have setup a new file named python in build dir, whose content like that: #!/bin/bash /usr/bin/env python2 $@ and add the build dir in env var PATH. If the python version error, I don't think I can see the GUI of bitbake. after manually closed gui, the shell output is like attachement. and I tried like this: if I change some file in poky's recipes for the conf file, the loading cache window will work normally, and I can see the progress bar rolling. but if I issue the cmd second time, it will hang. On Fri, 2011-07-01 at 07:55 +0800, Saul Wold wrote: On 06/29/2011 08:18 PM, NiQingliang wrote: I have added -DDD -v, after close window loading cache manually, the bitbake exited, and then I can see some DEBUG info on shell, but there is no clue. how to dig out where it hangs:-( Can you capture the log and send it. I noticed you are running on ArchLinux, can you confirm which version of Python you are using and which version of Poky you have? You have to be using 2.6 or 2.7 Python. Sau! On Thu, 2011-06-30 at 10:57 +0800, Cui, Dexuan wrote: NiQingliang wrote: once builded, is after executed bitbake core-image-minimal and generated the final image. I tried that just now on recent poky.git's master branch but can't reproduce the issue. :-( You may need to dig out where it hangs... On Thu, 2011-06-30 at 10:18 +0800, Cui, Dexuan wrote: , and set env, follow cmd works normally. bitbake -g -u depexp core-image-minimal but once builded, the cmd works abnormal, the symptom like that: What does once builded mean? Thanks, -- Dexuan -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com DEBUG: Using cache in '/media/Datum/yocto/build_sa735/tmp/cache/bb_codeparser.dat' for codeparser cache DEBUG: Clearing SRCREV cache due to cache policy of: clear DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/sanity.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/sanity.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/sanity.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/license.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/license.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/license.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/sstate.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/sstate.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/sstate.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/devshell.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/devshell.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/devshell.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/debian.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/debian.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/debian.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/insane.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/insane.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/insane.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/image-prelink.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/image-prelink.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/image-prelink.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/image-mklibs.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/image-mklibs.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/image-mklibs.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/package_ipk.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/package_ipk.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/package_ipk.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/prserv.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/prserv.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/prserv.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/packagedata.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/packagedata.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/packagedata.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/package.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/package.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/package.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/package_rpm.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/package_rpm.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/package_rpm.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/rm_work.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/rm_work.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/rm_work.bbclass DEBUG: LOAD /media/Datum/yocto/poky/meta/classes/logging.bbclass DEBUG: BB /media/Datum/yocto/poky/meta/classes/logging.bbclass: handle(data, include) DEBUG: BB :0: inheriting classes/logging.bbclass DEBUG: LOAD
Re: [yocto] dependency gui problem
Oh, sorry, I have fixed some bug in my description:-) I'm using python2.7 I have setup a new file named python in build dir, whose content like that: #!/bin/bash /usr/bin/env python2 $@ and add the build dir in env var PATH. If the python version error, I don't think I can see the GUI of bitbake. after manually closed gui, the shell output is like attachement. and I tried like this: if I change some file in poky's recipes for the conf file, the processing recipes window will work normally, and I can see the progress bar rolling. but if I issue the cmd second time, loading cache window will hang. On Fri, 2011-07-01 at 09:34 +0800, NiQingliang wrote: I'm using python2.7 I have setup a new file named python in build dir, whose content like that: #!/bin/bash /usr/bin/env python2 $@ and add the build dir in env var PATH. If the python version error, I don't think I can see the GUI of bitbake. after manually closed gui, the shell output is like attachement. and I tried like this: if I change some file in poky's recipes for the conf file, the loading cache window will work normally, and I can see the progress bar rolling. but if I issue the cmd second time, it will hang. On Fri, 2011-07-01 at 07:55 +0800, Saul Wold wrote: On 06/29/2011 08:18 PM, NiQingliang wrote: I have added -DDD -v, after close window loading cache manually, the bitbake exited, and then I can see some DEBUG info on shell, but there is no clue. how to dig out where it hangs:-( Can you capture the log and send it. I noticed you are running on ArchLinux, can you confirm which version of Python you are using and which version of Poky you have? You have to be using 2.6 or 2.7 Python. Sau! On Thu, 2011-06-30 at 10:57 +0800, Cui, Dexuan wrote: NiQingliang wrote: once builded, is after executed bitbake core-image-minimal and generated the final image. I tried that just now on recent poky.git's master branch but can't reproduce the issue. :-( You may need to dig out where it hangs... On Thu, 2011-06-30 at 10:18 +0800, Cui, Dexuan wrote: , and set env, follow cmd works normally. bitbake -g -u depexp core-image-minimal but once builded, the cmd works abnormal, the symptom like that: What does once builded mean? Thanks, -- Dexuan -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dependency gui problem
I have looked the fiel depexp.py, and have some doubt: why in ParseCompleted, the progress bar will hide, but in CacheLoadCompleted, it will not??? I don't think these two events need different process. if isinstance(event, bb.event.CacheLoadCompleted): gtk.gdk.threads_enter() pbar.update(progress_total, progress_total) gtk.gdk.threads_leave() continue ... if isinstance(event, bb.event.ParseCompleted): pbar.hide() continue On Fri, 2011-07-01 at 09:47 +0800, NiQingliang wrote: Oh, sorry, I have fixed some bug in my description:-) I'm using python2.7 I have setup a new file named python in build dir, whose content like that: #!/bin/bash /usr/bin/env python2 $@ and add the build dir in env var PATH. If the python version error, I don't think I can see the GUI of bitbake. after manually closed gui, the shell output is like attachement. and I tried like this: if I change some file in poky's recipes for the conf file, the processing recipes window will work normally, and I can see the progress bar rolling. but if I issue the cmd second time, loading cache window will hang. On Fri, 2011-07-01 at 09:34 +0800, NiQingliang wrote: I'm using python2.7 I have setup a new file named python in build dir, whose content like that: #!/bin/bash /usr/bin/env python2 $@ and add the build dir in env var PATH. If the python version error, I don't think I can see the GUI of bitbake. after manually closed gui, the shell output is like attachement. and I tried like this: if I change some file in poky's recipes for the conf file, the loading cache window will work normally, and I can see the progress bar rolling. but if I issue the cmd second time, it will hang. On Fri, 2011-07-01 at 07:55 +0800, Saul Wold wrote: On 06/29/2011 08:18 PM, NiQingliang wrote: I have added -DDD -v, after close window loading cache manually, the bitbake exited, and then I can see some DEBUG info on shell, but there is no clue. how to dig out where it hangs:-( Can you capture the log and send it. I noticed you are running on ArchLinux, can you confirm which version of Python you are using and which version of Poky you have? You have to be using 2.6 or 2.7 Python. Sau! On Thu, 2011-06-30 at 10:57 +0800, Cui, Dexuan wrote: NiQingliang wrote: once builded, is after executed bitbake core-image-minimal and generated the final image. I tried that just now on recent poky.git's master branch but can't reproduce the issue. :-( You may need to dig out where it hangs... On Thu, 2011-06-30 at 10:18 +0800, Cui, Dexuan wrote: , and set env, follow cmd works normally. bitbake -g -u depexp core-image-minimal but once builded, the cmd works abnormal, the symptom like that: What does once builded mean? Thanks, -- Dexuan -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dependency gui problem
I have not found the email adress of bitbake's developer, does anyone know? On Fri, 2011-07-01 at 11:13 +0800, NiQingliang wrote: I have changed that code section, and solved my problem, but I don't know if it is the right way. if isinstance(event, bb.event.CacheLoadCompleted): pbar.hide() continue ... if isinstance(event, bb.event.ParseCompleted): pbar.hide() continue On Fri, 2011-07-01 at 10:45 +0800, NiQingliang wrote: I have looked the fiel depexp.py, and have some doubt: why in ParseCompleted, the progress bar will hide, but in CacheLoadCompleted, it will not??? I don't think these two events need different process. if isinstance(event, bb.event.CacheLoadCompleted): gtk.gdk.threads_enter() pbar.update(progress_total, progress_total) gtk.gdk.threads_leave() continue ... if isinstance(event, bb.event.ParseCompleted): pbar.hide() continue On Fri, 2011-07-01 at 09:47 +0800, NiQingliang wrote: Oh, sorry, I have fixed some bug in my description:-) I'm using python2.7 I have setup a new file named python in build dir, whose content like that: #!/bin/bash /usr/bin/env python2 $@ and add the build dir in env var PATH. If the python version error, I don't think I can see the GUI of bitbake. after manually closed gui, the shell output is like attachement. and I tried like this: if I change some file in poky's recipes for the conf file, the processing recipes window will work normally, and I can see the progress bar rolling. but if I issue the cmd second time, loading cache window will hang. On Fri, 2011-07-01 at 09:34 +0800, NiQingliang wrote: I'm using python2.7 I have setup a new file named python in build dir, whose content like that: #!/bin/bash /usr/bin/env python2 $@ and add the build dir in env var PATH. If the python version error, I don't think I can see the GUI of bitbake. after manually closed gui, the shell output is like attachement. and I tried like this: if I change some file in poky's recipes for the conf file, the loading cache window will work normally, and I can see the progress bar rolling. but if I issue the cmd second time, it will hang. On Fri, 2011-07-01 at 07:55 +0800, Saul Wold wrote: On 06/29/2011 08:18 PM, NiQingliang wrote: I have added -DDD -v, after close window loading cache manually, the bitbake exited, and then I can see some DEBUG info on shell, but there is no clue. how to dig out where it hangs:-( Can you capture the log and send it. I noticed you are running on ArchLinux, can you confirm which version of Python you are using and which version of Poky you have? You have to be using 2.6 or 2.7 Python. Sau! On Thu, 2011-06-30 at 10:57 +0800, Cui, Dexuan wrote: NiQingliang wrote: once builded, is after executed bitbake core-image-minimal and generated the final image. I tried that just now on recent poky.git's master branch but can't reproduce the issue. :-( You may need to dig out where it hangs... On Thu, 2011-06-30 at 10:18 +0800, Cui, Dexuan wrote: , and set env, follow cmd works normally. bitbake -g -u depexp core-image-minimal but once builded, the cmd works abnormal, the symptom like that: What does once builded mean? Thanks, -- Dexuan -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dependency gui problem
once builded, is after executed bitbake core-image-minimal and generated the final image. On Thu, 2011-06-30 at 10:18 +0800, Cui, Dexuan wrote: , and set env, follow cmd works normally. bitbake -g -u depexp core-image-minimal but once builded, the cmd works abnormal, the symptom like that: What does once builded mean? -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dependency gui problem
I have added -DDD -v, after close window loading cache manually, the bitbake exited, and then I can see some DEBUG info on shell, but there is no clue. how to dig out where it hangs:-( On Thu, 2011-06-30 at 10:57 +0800, Cui, Dexuan wrote: NiQingliang wrote: once builded, is after executed bitbake core-image-minimal and generated the final image. I tried that just now on recent poky.git's master branch but can't reproduce the issue. :-( You may need to dig out where it hangs... On Thu, 2011-06-30 at 10:18 +0800, Cui, Dexuan wrote: , and set env, follow cmd works normally. bitbake -g -u depexp core-image-minimal but once builded, the cmd works abnormal, the symptom like that: What does once builded mean? Thanks, -- Dexuan -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] the mpc8315's compile option
mpc8315's core is e300c3, why use tune-ppc603e.inc? I think there should be an file named tune-ppce300c3.inc? I can find it in openembedded. -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
