Re: [oe] [PATCH] metadata_scm.bbclass: get the metadata revision for current HEAD
On Wed, Nov 3, 2010 at 8:06 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Nov 3, 2010 at 5:13 PM, Martin Jansa martin.ja...@gmail.com wrote: On Wed, Nov 03, 2010 at 04:55:52PM -0700, Chris Larson wrote: On Wed, Nov 3, 2010 at 3:40 PM, Khem Raj raj.k...@gmail.com wrote: Currently we report wrong revision when we build from branches not based on master because we only fetch the HEAD value which is remote master This patch makes it to report the HEAD of whatever branch one has checked out. This doesn't make sense. The HEAD ref always points to the current checked out commit or branch, it is *not* specific to master. No it does make sense, because it fixes my unknown METADATA_REVISION :). Acked-by: Martin Jansa martin.ja...@gmail.com in my R/W checkout I have it right even before patch bitb...@jama ~/oe $ git show-ref HEAD b3246d96069fd11caee42ec6ebcbf6dca2d62449 refs/remotes/origin/HEAD No, this is broken. It shouldn't be determining the METADATA_REVISION from a ref you don't even have checked out. Right now it's pulling the HEAD ref from upstream, it should be pulling the local HEAD ref. So NACK on this patch, the metadata revision code needs to be fixed to either not use show-ref or pass the necessary args to not operate based on a HEAD of a remote. whats wrong with this patch. or what is it that we need additionally. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] problems building openldap and libtool
On Wed, Nov 3, 2010 at 6:37 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 5:46 PM, J. L. vwyodap...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:48 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:36 PM, J. L. vwyodap...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:24 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 3:55 PM, J. L. vwyodap...@gmail.com wrote:
I am having an issue of how libtool is building on my machine. I am
running Ubuntu 10.10 64bit Kernel 2.6.35-23-generic bitbake 1.10.1
overo branch. Here is what happens when building:
Error for openldap
NOTE: package openldap-2.4.23-r2: task do_configure: Started
ERROR: Function do_configure failed
NOTE: Task failed: ('function do_configure failed',
'/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.12815')
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.12815
Log data follows:
| cp: cannot stat
`/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/ltmain.sh':
No such file or directory
can you add DEPENDS += libtool to openldap_2.4.23.bb and retry ?
Still getting this error and I cleaned and rebuilt both recipes
try this patch and remove that DEPENDS
diff --git a/recipes/openldap/openldap_2.4.23.bb
b/recipes/openldap/openldap_2.4.23.bb
index 3ac15f6..8afd951 100644
--- a/recipes/openldap/openldap_2.4.23.bb
+++ b/recipes/openldap/openldap_2.4.23.bb
@@ -188,7 +188,7 @@ DEPENDS += ${OPENLDAP_DEPENDS}
CPPFLAGS_append = -D_GNU_SOURCE
do_configure() {
- cp ${STAGING_DATADIR}/libtool/config/ltmain.sh ${S}/build
+ cp ${STAGING_ETCDIR_NATIVE}/libtool/config/ltmain.sh ${S}/build
rm -f ${S}/libtool
aclocal
libtoolize --force --copy
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.2783
Log data follows:
| cp: cannot stat
`/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/ltmain.sh':
No such file or directory
| ERROR: Function do_configure failed
NOTE: package openldap-2.4.23-r2: task do_configure: Failed
libtool does not build to this location
/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/
it builds to here
tmp/sysroots/armv7a-angstrom-linux-gnueabi/home/vdubhack/overo-oe/tmp/sysroots/x86_64-linux/usr/share/libtool/
It seems to put home/vdubhack/overo-oe/tmp the incorrect way. instead
of being in front of the tmp/sysroot like most things
same with aclocal and aclocal-1.11
Thanks
JL
-khem
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Did as you asked and also deleted the tmp/ dir to just make sure was
nothing in there and rebuilt. And must not have done something right
as the patch failed with this:
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.patch_do_patch.22762
Log data follows:
| ERROR: Error in executing python function in:
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/openldap/openldap_2.4.23.bb
| ERROR: Exception:class 'oe.patch.CmdError' Message:Command Error:
exit status: 1 Output:
| Applying patch test-fix.patch
| patching file recipes/openldap/openldap_2.4.23.bb
| Hunk #1 FAILED at 188.
| 1 out of 1 hunk FAILED -- rejects in file
recipes/openldap/openldap_2.4.23.bb
| Patch test-fix.patch does not apply (enforce with -f)
| ERROR: Printing the environment of the function
| ERROR: Function patch_do_patch failed
NOTE: package openldap-2.4.23-r2: task do_patch: Failed
I have attached the patch and the .bb so you can see what and how I did it.
crap.
dude you make that one line change in the recipe .bb file *by hand*
its not a patch for the sources
but for the recipe.
Thanks for the help so far.
JL
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Sorry didnt catch it
Re: [oe] problems building openldap and libtool
On Thu, Nov 4, 2010 at 12:27 AM, J. L. vwyodap...@gmail.com wrote:
On Wed, Nov 3, 2010 at 6:37 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 5:46 PM, J. L. vwyodap...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:48 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:36 PM, J. L. vwyodap...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:24 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 3:55 PM, J. L. vwyodap...@gmail.com wrote:
I am having an issue of how libtool is building on my machine. I am
running Ubuntu 10.10 64bit Kernel 2.6.35-23-generic bitbake 1.10.1
overo branch. Here is what happens when building:
Error for openldap
NOTE: package openldap-2.4.23-r2: task do_configure: Started
ERROR: Function do_configure failed
NOTE: Task failed: ('function do_configure failed',
'/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.12815')
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.12815
Log data follows:
| cp: cannot stat
`/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/ltmain.sh':
No such file or directory
can you add DEPENDS += libtool to openldap_2.4.23.bb and retry ?
Still getting this error and I cleaned and rebuilt both recipes
try this patch and remove that DEPENDS
diff --git a/recipes/openldap/openldap_2.4.23.bb
b/recipes/openldap/openldap_2.4.23.bb
index 3ac15f6..8afd951 100644
--- a/recipes/openldap/openldap_2.4.23.bb
+++ b/recipes/openldap/openldap_2.4.23.bb
@@ -188,7 +188,7 @@ DEPENDS += ${OPENLDAP_DEPENDS}
CPPFLAGS_append = -D_GNU_SOURCE
do_configure() {
- cp ${STAGING_DATADIR}/libtool/config/ltmain.sh ${S}/build
+ cp ${STAGING_ETCDIR_NATIVE}/libtool/config/ltmain.sh ${S}/build
rm -f ${S}/libtool
aclocal
libtoolize --force --copy
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.2783
Log data follows:
| cp: cannot stat
`/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/ltmain.sh':
No such file or directory
| ERROR: Function do_configure failed
NOTE: package openldap-2.4.23-r2: task do_configure: Failed
libtool does not build to this location
/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/
it builds to here
tmp/sysroots/armv7a-angstrom-linux-gnueabi/home/vdubhack/overo-oe/tmp/sysroots/x86_64-linux/usr/share/libtool/
It seems to put home/vdubhack/overo-oe/tmp the incorrect way. instead
of being in front of the tmp/sysroot like most things
same with aclocal and aclocal-1.11
Thanks
JL
-khem
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Did as you asked and also deleted the tmp/ dir to just make sure was
nothing in there and rebuilt. And must not have done something right
as the patch failed with this:
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.patch_do_patch.22762
Log data follows:
| ERROR: Error in executing python function in:
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/openldap/openldap_2.4.23.bb
| ERROR: Exception:class 'oe.patch.CmdError' Message:Command Error:
exit status: 1 Output:
| Applying patch test-fix.patch
| patching file recipes/openldap/openldap_2.4.23.bb
| Hunk #1 FAILED at 188.
| 1 out of 1 hunk FAILED -- rejects in file
recipes/openldap/openldap_2.4.23.bb
| Patch test-fix.patch does not apply (enforce with -f)
| ERROR: Printing the environment of the function
| ERROR: Function patch_do_patch failed
NOTE: package openldap-2.4.23-r2: task do_patch: Failed
I have attached the patch and the .bb so you can see what and how I did it.
crap.
dude you make that one line change in the recipe .bb file *by hand*
its not a patch for the sources
but for the recipe.
Thanks for the help so far.
JL
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
Re: [oe] DEPENDS broken for native(sdk).bbclass Was: libgee introspection problem
On Tue, Oct 26, 2010 at 01:25:51PM +0200, Martin Jansa wrote:
On Tue, Oct 26, 2010 at 11:39:26AM +0200, Martin Jansa wrote:
On Tue, Oct 26, 2010 at 11:16:46AM +0200, Frans Meulenbroeks wrote:
Hi,
With the testing branch I get a problem with libgee native in
combination with introspection.
I'm building distro minimal, target neek (but I doubt that the latter
matters)
Anyone an idea?
that should be fixed with
http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=df932a2769c2f6f7195363e8eb83994846805398
but that didn't make it to DEPENDS_virtclass-native (as well as
glib-2.0), I'm checking why (reading native.bbclass looks like it
should be there automatically).
if I don't find bug in native.bbclass I'll append it to
DEPENDS_virtclass-native too
native.bbclass and nativesdk.bbclass use
ORIG_DEPENDS := ${DEPENDS}
DEPENDS_virtclass-native ?= ${ORIG_DEPENDS}
and then for every dependency in DEPENDS_virtclass-native it does:
1) if it ends with -cross appends dependency ending -native instead
2) if it ends with -native it just appends
3) else appends dependency ending with native instead
That's all nice and right and works in theory, BUT:
base.bbclass:
DEPENDS_prepend=$...@base_deps(d)}
DEPENDS_virtclass-native_prepend=$...@base_deps(d)}
DEPENDS_virtclass-nativesdk_prepend=$...@base_deps(d)}
autotools.bbclass:
DEPENDS_prepend = $...@autotools_deps(d)}
DEPENDS_virtclass-native_prepend = $...@autotools_deps(d)}
DEPENDS_virtclass-nativesdk_prepend = $...@autotools_deps(d)}
vala.bbclass:
DEPENDS += vala-native
DEPENDS_virtclass-native += vala-native
so DEPENDS_virtclass-native is not empty when native.bbclass calls:
DEPENDS_virtclass-native ?= ${ORIG_DEPENDS}
and ORIG_DEPENDS are just ignored
we cannot fix it with
DEPENDS_virtclass-native += ${ORIG_DEPENDS}
because sometimes we want to override DEPENDS_virtclass-native from
recipe (ie when target recipe depends on its own ${PN}-native).
Maybe it's because the order of bbclass processing was changed? It would
work OK if we process native and nativesdk first.
I've added small debug output to see order now
DEBUG: Removing /OE/dev/recipes/libgee/libgee_0.6.0.bb from cache
DEBUG: Parsing /OE/dev/recipes/libgee/libgee_0.6.0.bb
DEBUG: inherited base
DEBUG: inherited autotools
DEBUG: inherited vala
DEBUG: inherited base
DEBUG: inherited autotools
DEBUG: inherited vala
DEBUG: inherited native
No idea why I see it twice..
Current broken state:
DEBUG: OrigDepends: autoconf-native automake-native libtool-native
gnu-config-native coreutils-native linux-libc-headers-native glib-2.0
vala-native gobject-introspection-native
DEBUG: Depends: autoconf-native automake-native libtool-native
gnu-config-native coreutils-native linux-libc-headers-native vala-native
glib-2.0 is from libgee.inc, gobject-introspection-native from
libgee_0.6.0.bb, but both lost
If I remove those append/preppend from bbclasses:
DEBUG: OrigDepends: autoconf-native automake-native libtool-native
gnu-config-native coreutils-native linux-libc-headers-native glib-2.0
vala-native gobject-introspection-native
DEBUG: Depends: autoconf-native automake-native libtool-native
gnu-config-native coreutils-native linux-libc-headers-native glib-2.0
vala-native gobject-introspection-native
I'll send patch for removing those DEPENDS_virtclass-native(sdk) from
bbclasses.
But that will break those recipes where DEPENDS_virtclass-native is used to
override
common DEPENDS but without still needed dependencies from classes, so
enforced
bbclass order would be probably better fix.
We really need some sort of unit tests :/.
Regards,
ping?
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [RFC] turning conf/machine into a set of bblayers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03-11-10 21:44, Khem Raj wrote: I dont think it would make sense to put things like gcc and binutils and core components into overlays. I would put those into a 'devtools' layer, like poky has done. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFM0mVjMkyGM64RGpERAspiAKCCVvbm5EWD3OejRvjSCxAxbBEsoQCfVjND kvkJ8A0aRkuCV5lP28eXLas= =rw7D -END PGP SIGNATURE- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] dangling symlinks
Dear all, Wrt messages like this in do_package: NOTE: sysvinit-utils contains dangling symlink to /usr/bin/last NOTE: sysvinit contains dangling symlink to /sbin/halt NOTE: sysvinit contains dangling symlink to /sbin/init NOTE: sysvinit contains dangling symlink to /sbin/halt I know that the link will (most likely) be resolved when installing the package. I would expect do_package to detect if the symlink src actually exists and if so it could be silent. But if the link is not there, I guess I would raise this to at least a WARN and maybe even to an ERROR. No idea how to fix this though. Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] e2fsprogs do_package issue
Got this when building e2fsprogs: NOTE: package e2fsprogs-1.41.9-r24: task do_package: Started NOTE: the following files were installed but not shipped in any package: NOTE: /usr/share/ss/ct_c.awk NOTE: /usr/share/ss/ct_c.sed NOTE: /usr/share/et/et_h.awk NOTE: /usr/share/et/et_c.awk No idea where these are for. Should these be packaged? And if not should they be removed e.g. in do_install_append so the above note gets away? Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] own-mirrors.bbclass: allow mirroring of scm fetched packages
2010/11/4 Denys Dmytriyenko de...@denix.org:
On Wed, Nov 03, 2010 at 04:41:24PM -0700, Tom Rini wrote:
Eric B??nard wrote:
this way, it's possible to setup a local webserver (for example
using busybox httpd -p 8081 -h backuped_download_dir) serving
a presiously fetched download directory and to build wihout the
need for an internet access
this can also be used when connected to know to know which packages
are missing from the local mirror's directory (and thus are fetched
from internet as a fallback), it's possible to run the server this way :
busybox httpd -p 8081 -h backuped_download_dir -vv -f | grep -B 1
response:404
to get the name of the missing packages.
Signed-off-by: Eric B??nard e...@eukrea.com
Acked-by: Tom Rini tom_r...@mentor.com
Looks like a nice way to have local mirrored downloads. May I suggest to put
the above examples of running busybox httpd as a comment inside the class.
Acked-by: Denys Dmytriyenko de...@denix.org
Cool. Thanks alot!
Acked-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
classes/own-mirrors.bbclass | 7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/classes/own-mirrors.bbclass b/classes/own-mirrors.bbclass
index e8a0f48..720ce42 100644
--- a/classes/own-mirrors.bbclass
+++ b/classes/own-mirrors.bbclass
@@ -1,4 +1,9 @@
PREMIRRORS() {
-https?://.*/.* ${SOURCE_MIRROR_URL}
+cvs://.*/.* ${SOURCE_MIRROR_URL}
+svn://.*/.* ${SOURCE_MIRROR_URL}
+git://.*/.* ${SOURCE_MIRROR_URL}
+hg://.*/.* ${SOURCE_MIRROR_URL}
+bzr://.*/.* ${SOURCE_MIRROR_URL}
+https?$://.*/.* ${SOURCE_MIRROR_URL}
ftp://.*/.* ${SOURCE_MIRROR_URL}
}
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Patchwork cleanup weekend in two days
Hello. Its time for some house-keeping again. I know many people are working on patchwork on-going, thanks for that. Looking throught it during OEDEM did still show up way to many entries. Some are still from 2009. Next Saturday and Sunday I would like to reduce our current count from 273 patches. 100 or less would be a nice goal imho. Steps to help out: 1) make sure you have a patchwork account and are added to the admin group to change patches 2) Hang out on IRC on saturday and sunday 3) Go through the patchwork and find all patches from yourself and up date them with a current status. e.g. mark them as superseeded if you send a new version or applied if they hit the tree. 4) After your own patches pick other ones and try to find out about their current staus. Usually git log, the ml or asking people on IRC helps here to find out stuff about the patch. If you cleaned up more then 10 patches a day you are allowed to drink a beer in the evening. ;) regards Stefan Schmidt ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH/RFC] qt4-embedded: tune QT_ARCH for armv6
this is a RFC, I think it can also be used on qt 4.6.x and on armv7.
Setting QT_ARCH to armv6 enable some asm optimized functions in QT.
Signed-off-by: Eric Bénard e...@eukrea.com
---
recipes/qt4/qt4-embedded_4.7.0.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/recipes/qt4/qt4-embedded_4.7.0.bb
b/recipes/qt4/qt4-embedded_4.7.0.bb
index 7e3d4b8..fbfaf85 100644
--- a/recipes/qt4/qt4-embedded_4.7.0.bb
+++ b/recipes/qt4/qt4-embedded_4.7.0.bb
@@ -2,9 +2,10 @@ DEFAULT_PREFERENCE = -1
require qt4-embedded.inc
-PR = ${INC_PR}.1
+PR = ${INC_PR}.2
QT_CONFIG_FLAGS_append_armv6 = -no-neon
+QT_ARCH_armv6 = armv6
require qt-${PV}.inc
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] eglibc: fix build issue with make-3.82
Add patch to fix this error when building eglibc-2.12
with make-3.82:
make[2]: Entering directory `eglibc-2_12/libc/manual'
Makefile:246: *** mixed implicit and normal rules. Stop.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
recipes/eglibc/eglibc_2.11.bb |3 ++-
recipes/eglibc/eglibc_2.12.bb |3 ++-
recipes/eglibc/files/eglibc-make-382.patch | 15 +++
3 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644 recipes/eglibc/files/eglibc-make-382.patch
diff --git a/recipes/eglibc/eglibc_2.11.bb b/recipes/eglibc/eglibc_2.11.bb
index 3763124..89742b6 100644
--- a/recipes/eglibc/eglibc_2.11.bb
+++ b/recipes/eglibc/eglibc_2.11.bb
@@ -4,7 +4,7 @@ DEFAULT_PREFERENCE = -1
DEPENDS += gperf-native
FILESPATHPKG =. eglibc-svn:
PV = 2.11
-PR = ${INC_PR}.7
+PR = ${INC_PR}.8
PR_append = +svnr${SRCPV}
SRCREV=10690
EGLIBC_BRANCH=eglibc-2_11
@@ -14,6 +14,7 @@ SRC_URI =
svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
file://shorten-build-commands.patch \
file://sh4_set_fpscr.patch \
file://sh4_local-fpscr_values.patch \
+ file://eglibc-make-382.patch \
file://etc/ld.so.conf \
file://generate-supported.mk
S = ${WORKDIR}/${EGLIBC_BRANCH}/libc
diff --git a/recipes/eglibc/eglibc_2.12.bb b/recipes/eglibc/eglibc_2.12.bb
index 40ab65c..956f64b 100644
--- a/recipes/eglibc/eglibc_2.12.bb
+++ b/recipes/eglibc/eglibc_2.12.bb
@@ -4,7 +4,7 @@ DEFAULT_PREFERENCE = -1
DEPENDS += gperf-native
FILESPATHPKG =. eglibc-svn:
PV = 2.12
-PR = ${INC_PR}.6
+PR = ${INC_PR}.7
PR_append = +svnr${SRCPV}
SRCREV=11762
EGLIBC_BRANCH=eglibc-2_12
@@ -16,6 +16,7 @@ SRC_URI =
svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
file://sh4_local-fpscr_values.patch \
file://eglibc-dont-cache-slibdir.patch \
file://armv4-eabi-compile-fix.patch \
+ file://eglibc-make-382.patch \
file://etc/ld.so.conf \
file://generate-supported.mk
S = ${WORKDIR}/${EGLIBC_BRANCH}/libc
diff --git a/recipes/eglibc/files/eglibc-make-382.patch
b/recipes/eglibc/files/eglibc-make-382.patch
new file mode 100644
index 000..5ecad90
--- /dev/null
+++ b/recipes/eglibc/files/eglibc-make-382.patch
@@ -0,0 +1,15 @@
+http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=blob_plain;f=source/base/glibc/make-3.82-fix.patch;hb=8217c32ecc2e14962847ba3d8a272eb64a3dba4f
+
+--- libc/manual/Makefile
libc/manual/Makefile
+@@ -232,7 +232,9 @@
+ .PHONY: stubs
+ stubs: $(objpfx)stubs
+ endif
+-$(objpfx)stubs ../po/manual.pot $(objpfx)stamp%:
++$(objpfx)stubs ../po/manual.pot:
++ touch $@
++$(objpfx)stamp%:
+ $(make-target-directory)
+ touch $@
+
--
1.7.3.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/2] busybox: fix build issue with make-3.82
make-3.82 complains about mixed implicit and normal rules
on busybox 1.15.x/1.16.x Makefile. 1.17.x versions are not affected.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
recipes/busybox/busybox_1.15.3.bb |3 ++-
recipes/busybox/busybox_1.16.2.bb |6 +-
recipes/busybox/files/busybox-make-3-82.patch | 20
3 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 recipes/busybox/files/busybox-make-3-82.patch
diff --git a/recipes/busybox/busybox_1.15.3.bb
b/recipes/busybox/busybox_1.15.3.bb
index 5fa6225..987b9c5 100644
--- a/recipes/busybox/busybox_1.15.3.bb
+++ b/recipes/busybox/busybox_1.15.3.bb
@@ -1,8 +1,9 @@
require busybox_1.1x.inc
-PR = ${INC_PR}.4
+PR = ${INC_PR}.5
SRC_URI += \
file://-wget-no-check-certificate.patch \
+ file://busybox-make-3-82.patch \
SRC_URI[md5sum] = 6059ac9456de6fb18dc8ee4cd0ec9240
diff --git a/recipes/busybox/busybox_1.16.2.bb
b/recipes/busybox/busybox_1.16.2.bb
index 982b49b..fb80b52 100644
--- a/recipes/busybox/busybox_1.16.2.bb
+++ b/recipes/busybox/busybox_1.16.2.bb
@@ -1,5 +1,9 @@
require busybox_1.1x.inc
-PR = ${INC_PR}.3
+PR = ${INC_PR}.4
+
+SRC_URI += \
+ file://busybox-make-3-82.patch \
+
DEFAULT_PREFERENCE = -1
DEFAULT_PREFERENCE_shr = 1
diff --git a/recipes/busybox/files/busybox-make-3-82.patch
b/recipes/busybox/files/busybox-make-3-82.patch
new file mode 100644
index 000..5c5c3b6
--- /dev/null
+++ b/recipes/busybox/files/busybox-make-3-82.patch
@@ -0,0 +1,20 @@
+--- busybox-1.7.4/Makefile.1 2010-10-26 19:31:29.04217 +0300
busybox-1.7.4/Makefile 2010-10-26 19:39:14.01218 +0300
+@@ -402,7 +402,7 @@ ifeq ($(config-targets),1)
+ -include $(srctree)/arch/$(ARCH)/Makefile
+ export KBUILD_DEFCONFIG
+
+-config %config: scripts_basic outputmakefile FORCE
++%config: scripts_basic outputmakefile FORCE
+ $(Q)mkdir -p include
+ $(Q)$(MAKE) $(build)=scripts/kconfig $@
+ $(Q)$(MAKE) -C $(srctree) KBUILD_SRC= .kernelrelease
+@@ -1240,7 +1240,7 @@ endif
+ $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
+
+ # Modules
+-/ %/: prepare scripts FORCE
++%/: prepare scripts FORCE
+ $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
+ $(build)=$(build-dir)
+ %.ko: prepare scripts FORCE
--
1.7.3.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Patchwork cleanup weekend in two days
2010/11/4 Stefan Schmidt ste...@datenfreihafen.org: Hello. Its time for some house-keeping again. I know many people are working on patchwork on-going, thanks for that. Looking throught it during OEDEM did still show up way to many entries. Some are still from 2009. Next Saturday and Sunday I would like to reduce our current count from 273 patches. 100 or less would be a nice goal imho. Steps to help out: 1) make sure you have a patchwork account and are added to the admin group to change patches 2) Hang out on IRC on saturday and sunday 3) Go through the patchwork and find all patches from yourself and up date them with a current status. e.g. mark them as superseeded if you send a new version or applied if they hit the tree. 4) After your own patches pick other ones and try to find out about their current staus. Usually git log, the ml or asking people on IRC helps here to find out stuff about the patch. If you cleaned up more then 10 patches a day you are allowed to drink a beer in the evening. ;) I would love to help out, but as it stands I'll be travelling on saturday and won't have internet access on sat and sun (and probably the rest of the week neither) (but I'll drink the beer anyway :-) ). Wish you all the best cleaning up! Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Race issues (lzma-native)
FWIW Issue is still present.
I'll try the workaround you posted.
Andrea
On Tue, Oct 26, 2010 at 9:58 AM, Andrea Adami andrea.ad...@gmail.com wrote:
Just to add this time the race appears building on Ubuntu 10.4 32bit.
Last race-case (gtk+-native) was only on Gentoo and not on Ubuntu...
Both distros are on the same Quad host and share an EXT3 OpenEmbedded
partition, though.
PARALLEL_MAKE = -j5
BB_NUMBER_THREADS = 4
Perplexed...
Andrea
On Mon, Oct 25, 2010 at 5:59 AM, Graham Gower graham.go...@gmail.com wrote:
On 10/24/2010 07:29 PM, Andrea Adami wrote:
Hello,
during first build of console image I notice a strange fault:
subsequent builds are ok.
My scripts builds console-image and opie-image.
ERROR: Task 2411
(virtual:native:/oe/openembedded/recipes/lzma/lzma_4.65.bb,
do_distribute_sources) failed with exit code '1'
NOTE: Unpacking ../sources/lzma465.tar.bz2 to
tmp/work/i686-linux/lzma-native-4.65-r4.1/
NOTE: package lzma-native-4.65-r4.1: task do_distribute_sources: Started
NOTE: package lzma-native-4.65-r4.1: task SRC_DISTRIBUTECOMMAND: Failed
ERROR: Function 'SRC_DISTRIBUTECOMMAND' failed
Looking at the
run.SRC_DISTRIBUTECOMMAND.18268 16384 (failing)
run.SRC_DISTRIBUTECOMMAND.9570 34334
it looks like the file is not complete / malformed:
package_generate_ipkg_conf() {
--mkdir -p /oe/build/tmp/sysroots/i686-linux/etc/
--echo src oe file:/oe/build/tmp/deploy/glibc/ipk
/oe/build/tmp/sysroots/i686-linux/etc/opkg.conf
--echo src oe file:/
EOF
run.do_distribute_sources.18268 is empty, while second time
run.do_distribute_sources.9570 1051 contains def
do_distribute_sources(d):
This seems indeed a race issue...
Andrea
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
I can reproduce this one quite easily. Reverting a6a23f73 seems to make it
disappear. Alternately the change below works, but I'm not convinced this is
the right fix.
Can someone with greater insight explain what causes this race?
-Graham
diff --git a/classes/src_distribute.bbclass b/classes/src_distribute.bbclass
index 795a5cf..98d8d88 100644
--- a/classes/src_distribute.bbclass
+++ b/classes/src_distribute.bbclass
@@ -1,7 +1,7 @@
SRC_DISTRIBUTE_DLONLY ?= 0
SRC_DISTRIBUTECOMMAND[func] = 1
-addtask distribute_sources before do_build after do_fetch
+addtask distribute_sources before do_build after do_unpack
python do_distribute_sources () {
bb.build.exec_func(do_fetch, d)
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] packaged-staging
I forgot to say we are using bitbake 1.8.12 and branch stable/2009
Fabrice Aeschbacher
-Ursprüngliche Nachricht-
Von: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] Im
Auftrag von Aeschbacher, Fabrice
Gesendet: Donnerstag, 4. November 2010 12:32
An: openembedded-devel@lists.openembedded.org
Betreff: [oe] packaged-staging
Hi,
I am trying to use packaged staging, following the
description found here:
http://marcin.juszkiewicz.com.pl/2008/07/01/packaged-staging-a
nd-what-it-gives/
http://blog.denix.org/2008/09/getting-dangerous-with-packaged-
staging.html
I set:
DEPLOY_DIR_PSTAGE = ${OEBASE}/pstage
, and then:
$ bitbake base-image
$ rm -rf ${TMPDIR}
$ bitbake base-image
During build I noticed a lot of messages like:
NOTE: Staging package found, using it for
.../org.openembedded/recipes/gettext/gettext-native_0.17.bb
But finally the last step fails:
ERROR: function do_rootfs failed
| * ERROR: Cannot satisfy the following dependencies for task-boot:
| * kernel * base-files * base-passwd * busybox *
modutils-initscripts * netbase * update-alternatives *
| * Cannot find package task-boot.
| * Cannot find package util-linux-mount.
| * Cannot find package util-linux-umount.
| * Cannot find package dropbear.
| * Cannot find package angstrom-version.
| * Cannot find package hotplug-ng.
| * Cannot find package libgcc1.
| * Cannot find package libstdc++6.
| * Cannot find package initscripts.
| * Cannot find package sysvinit.
| * Cannot find package sysvinit-pidof.
| * Cannot find package tinylogin.
| * Cannot find package opkg-nogpg.
| * Cannot find package angstrom-version.
| * Cannot find package angstrom-feed-configs.
| * Cannot find package opkg-collateral.
NOTE: Task failed:
/home/projects/oe-stable-2009/build/taurus/work/taurus-angstro
m-linux-gnueabi/base-image-1.0-r0/temp/log.do_rootfs.10147
Some remarks:
- It does not help trying to bitbake the indicated missing packages
but for each package, I need to:
bitbake package -f -c package_write
- After a first build, cross-compiler is installer in
${TEMPDIR}/cross/armv5te/bin
(which is added to the $PATH for oe_runmake)
But after a packaged-staging build, this directory does not exist;
the cross-compiler is actually installed in ${TEMPDIR}/cross/bin
= every do_compile fails
to circumvent this, I had to :
cd ${TEMPDIR}/cross
mkdir armv5te
ln -s ../bin armv5te
I saw Frans Meulenbroeks already had the same issue:
http://www.mail-archive.com/openembedded-de...@lists.openembed
ded.org/msg03314.html
Did someone find a solution?
With kind regards,
Fabrice Aeschbacher
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] packaged-staging
Aeschbacher, Fabrice wrote: I forgot to say we are using bitbake 1.8.12 and branch stable/2009 packaged-staging isn't complete there, sorry. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] packaged-staging
Aeschbacher, Fabrice wrote: Aeschbacher, Fabrice wrote: I forgot to say we are using bitbake 1.8.12 and branch stable/2009 packaged-staging isn't complete there, sorry. Tom Rini Is it with bitbake-1.8.18 and stable/2009 ? Sorry, bitbake 1.10.x and master (aka dev) are required for packaged staging to be functional. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] metadata_scm.bbclass: get the metadata revision for current HEAD
On Wed, Nov 3, 2010 at 11:01 PM, Khem Raj raj.k...@gmail.com wrote: bitb...@jama ~/oe $ git show-ref HEAD b3246d96069fd11caee42ec6ebcbf6dca2d62449 refs/remotes/origin/HEAD No, this is broken. It shouldn't be determining the METADATA_REVISION from a ref you don't even have checked out. Right now it's pulling the HEAD ref from upstream, it should be pulling the local HEAD ref. So NACK on this patch, the metadata revision code needs to be fixed to either not use show-ref or pass the necessary args to not operate based on a HEAD of a remote. whats wrong with this patch. or what is it that we need additionally. The issue is, show-ref shows all refs which match the supplied search string. show-ref HEAD will show all the HEAD refs, both local and the ones in all your remotes, which isn't what we want for METADATA_REVISION. I'm testing a patch which changes it to use rev-parse to get the commit hash for HEAD rather than show-ref. Thanks for catching this, by the way, I don't want to sound unappreciative, its just that this patch is more of a workaround, rather than a fix for the root problem. :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] packaged-staging
On Thu, Nov 4, 2010 at 6:58 AM, Tom Rini tom_r...@mentor.com wrote: Aeschbacher, Fabrice wrote: Aeschbacher, Fabrice wrote: I forgot to say we are using bitbake 1.8.12 and branch stable/2009 packaged-staging isn't complete there, sorry. Tom Rini Is it with bitbake-1.8.18 and stable/2009 ? Sorry, bitbake 1.10.x and master (aka dev) are required for packaged staging to be functional. I *think* bitbake 1.8 should be fine with packaged staging, its the more recent OE that's critical :) Fabrice, you may want to look at the Testing page on the OE wiki and the testing branch as a starting point, as its a bit more tested version of master. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] DEPENDS broken for native(sdk).bbclass Was: libgee introspection problem
On Thu, Nov 4, 2010 at 1:05 AM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: After your ping: I'm definitely no expert in this area. Your proposal looks ok but I'm a little bit worried about the breaking of DEPENDS_virtclass-native. This seems to involve some 44 recipes (list at end). Guess we should repair those first. Did we already have that _target suffix? Adding a target override has proved to be rather painful due to when OVERRIDES is used during the parsing process, unfortunately. Khem's patch ran into some problems, which I'm investigating. Will reply to this thread or his patch thread with details as I gather them. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] metadata_scm: use rev-parse rather than show-ref
From: Chris Larson chris_lar...@mentor.com
show-ref will show all matching refs, so a show-ref HEAD will show not just
the local HEAD, but the fetched remote ones as well. This isn't what we want
for this function, so change it to use rev-parse with --verify, and also
change it to use --short, to shorten the hash to a more palatable length.
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/metadata_scm.bbclass | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/classes/metadata_scm.bbclass b/classes/metadata_scm.bbclass
index ffc6a8a..f79ea19 100644
--- a/classes/metadata_scm.bbclass
+++ b/classes/metadata_scm.bbclass
@@ -63,14 +63,18 @@ def base_get_metadata_svn_revision(path, d):
return revision
def base_get_metadata_git_branch(path, d):
- branch = os.popen('cd %s; PATH=%s git symbolic-ref HEAD 2/dev/null' %
(path, d.getVar(PATH, 1))).read().rstrip()
-
- if len(branch) != 0:
- return branch.replace(refs/heads/, )
- return unknown
+try:
+rev = oe_run(d, [git, symbolic-ref, HEAD], cwd=path).rstrip()
+except oe.process.CmdError:
+rev = unknown
+else:
+rev = rev.replace(refs/heads/, )
+return rev
def base_get_metadata_git_revision(path, d):
- rev = os.popen(cd %s; PATH=%s git show-ref HEAD 2/dev/null % (path,
d.getVar(PATH, 1))).read().split( )[0].rstrip()
- if len(rev) != 0:
- return rev
- return unknown
+try:
+rev = oe_run(d, [git, rev-parse, --verify, --short, HEAD],
+ cwd=path).rstrip()
+except oe.process.CmdError:
+rev = unknown
+return rev
--
1.7.2.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] metadata_scm.bbclass: get the metadata revision for current HEAD
On Thu, Nov 4, 2010 at 7:07 AM, Chris Larson clar...@kergoth.com wrote: On Wed, Nov 3, 2010 at 11:01 PM, Khem Raj raj.k...@gmail.com wrote: bitb...@jama ~/oe $ git show-ref HEAD b3246d96069fd11caee42ec6ebcbf6dca2d62449 refs/remotes/origin/HEAD No, this is broken. It shouldn't be determining the METADATA_REVISION from a ref you don't even have checked out. Right now it's pulling the HEAD ref from upstream, it should be pulling the local HEAD ref. So NACK on this patch, the metadata revision code needs to be fixed to either not use show-ref or pass the necessary args to not operate based on a HEAD of a remote. whats wrong with this patch. or what is it that we need additionally. The issue is, show-ref shows all refs which match the supplied search string. show-ref HEAD will show all the HEAD refs, both local and the ones in all your remotes, which isn't what we want for METADATA_REVISION. I'm testing a patch which changes it to use rev-parse to get the commit hash for HEAD rather than show-ref. FWIW you could also use git show-ref --head branch Thanks for catching this, by the way, I don't want to sound unappreciative, its just that this patch is more of a workaround, rather than a fix for the root problem. :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] metadata_scm.bbclass: get the metadata revision for current HEAD
On Thu, Nov 4, 2010 at 8:59 AM, Khem Raj raj.k...@gmail.com wrote: The issue is, show-ref shows all refs which match the supplied search string. show-ref HEAD will show all the HEAD refs, both local and the ones in all your remotes, which isn't what we want for METADATA_REVISION. I'm testing a patch which changes it to use rev-parse to get the commit hash for HEAD rather than show-ref. FWIW you could also use git show-ref --head branch Yeah, that will work if the branch is the full path including refs/heads/, but it's not using the right plumbing tool for the job. show-ref is designed to *list* refs in the repo, not resolve a single one. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] dangling symlinks
On Thu, Nov 4, 2010 at 12:52 AM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: Wrt messages like this in do_package: NOTE: sysvinit-utils contains dangling symlink to /usr/bin/last NOTE: sysvinit contains dangling symlink to /sbin/halt NOTE: sysvinit contains dangling symlink to /sbin/init NOTE: sysvinit contains dangling symlink to /sbin/halt I know that the link will (most likely) be resolved when installing the package. I would expect do_package to detect if the symlink src actually exists and if so it could be silent. But if the link is not there, I guess I would raise this to at least a WARN and maybe even to an ERROR. No idea how to fix this though. I would guess that these are caused by symlinks to binaries which were renamed for use with update-alternatives. I think the best approach is to change it so all use of update-alternatives is controlled via metadata, rather than manually adding postinst/prerm snippets to do it, then the do_package check could utilize that information as well. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH/RFC] qt4-embedded: tune QT_ARCH for armv6
On (04/11/10 10:52), Eric Bénard wrote:
this is a RFC, I think it can also be used on qt 4.6.x and on armv7.
Setting QT_ARCH to armv6 enable some asm optimized functions in QT.
Signed-off-by: Eric Bénard e...@eukrea.com
Acked-by: Khem Raj raj.k...@gmail.com
---
recipes/qt4/qt4-embedded_4.7.0.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/recipes/qt4/qt4-embedded_4.7.0.bb
b/recipes/qt4/qt4-embedded_4.7.0.bb
index 7e3d4b8..fbfaf85 100644
--- a/recipes/qt4/qt4-embedded_4.7.0.bb
+++ b/recipes/qt4/qt4-embedded_4.7.0.bb
@@ -2,9 +2,10 @@ DEFAULT_PREFERENCE = -1
require qt4-embedded.inc
-PR = ${INC_PR}.1
+PR = ${INC_PR}.2
QT_CONFIG_FLAGS_append_armv6 = -no-neon
+QT_ARCH_armv6 = armv6
require qt-${PV}.inc
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] metadata_scm: use rev-parse rather than show-ref
On (04/11/10 07:18), Chris Larson wrote:
From: Chris Larson chris_lar...@mentor.com
show-ref will show all matching refs, so a show-ref HEAD will show not just
the local HEAD, but the fetched remote ones as well. This isn't what we want
for this function, so change it to use rev-parse with --verify, and also
change it to use --short, to shorten the hash to a more palatable length.
Signed-off-by: Chris Larson chris_lar...@mentor.com
seems to hold on my limited testing
Acked-by: Khem Raj raj.k...@gmail.com
---
classes/metadata_scm.bbclass | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/classes/metadata_scm.bbclass b/classes/metadata_scm.bbclass
index ffc6a8a..f79ea19 100644
--- a/classes/metadata_scm.bbclass
+++ b/classes/metadata_scm.bbclass
@@ -63,14 +63,18 @@ def base_get_metadata_svn_revision(path, d):
return revision
def base_get_metadata_git_branch(path, d):
- branch = os.popen('cd %s; PATH=%s git symbolic-ref HEAD 2/dev/null' %
(path, d.getVar(PATH, 1))).read().rstrip()
-
- if len(branch) != 0:
- return branch.replace(refs/heads/, )
- return unknown
+try:
+rev = oe_run(d, [git, symbolic-ref, HEAD], cwd=path).rstrip()
+except oe.process.CmdError:
+rev = unknown
+else:
+rev = rev.replace(refs/heads/, )
+return rev
def base_get_metadata_git_revision(path, d):
- rev = os.popen(cd %s; PATH=%s git show-ref HEAD 2/dev/null % (path,
d.getVar(PATH, 1))).read().split( )[0].rstrip()
- if len(rev) != 0:
- return rev
- return unknown
+try:
+rev = oe_run(d, [git, rev-parse, --verify, --short, HEAD],
+ cwd=path).rstrip()
+except oe.process.CmdError:
+rev = unknown
+return rev
--
1.7.2.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH/RFC] qt4-embedded: tune QT_ARCH for armv6
On 11/04/2010 10:52 AM, Eric Bénard wrote: this is a RFC, I think it can also be used on qt 4.6.x and on armv7. Setting QT_ARCH to armv6 enable some asm optimized functions in QT. Do you know the consequences of this change? E.g. in the painting engine unaligned memory access will be allowed. I am not sure that Nokia has ever benchmarked what is faster (aligned/unaligned) access. So it would be very interesting to know the perf difference. E.g. use qttracereply to measure it. Phil do you happen to know why unaligned access got allowed starting from armv6? How fast will it be? ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH/RFC] qt4-embedded: tune QT_ARCH for armv6
Hi, Le 04/11/2010 19:26, Holger Freyther a écrit : On 11/04/2010 10:52 AM, Eric Bénard wrote: this is a RFC, I think it can also be used on qt 4.6.x and on armv7. Setting QT_ARCH to armv6 enable some asm optimized functions in QT. Do you know the consequences of this change? E.g. in the painting engine unaligned memory access will be allowed. I am not sure that Nokia has ever benchmarked what is faster (aligned/unaligned) access. So it would be very interesting to know the perf difference. E.g. use qttracereply to measure it. Phil do you happen to know why unaligned access got allowed starting from armv6? How fast will it be? in the painting engine, from what I saw in the .h, the asm optimisations are only enabled when using ARM RCVT compiler and not when using gcc but I have not checked everywhere in the code so I'm not sure of this. Eric ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] meta.bbclass: Exclude meta recipes from world builds
Signed-off-by: Khem Raj raj.k...@gmail.com --- classes/meta.bbclass |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/classes/meta.bbclass b/classes/meta.bbclass index d35c40b..d0626e3 100644 --- a/classes/meta.bbclass +++ b/classes/meta.bbclass @@ -1,4 +1,4 @@ - +EXCLUDE_FROM_WORLD = 1 PACKAGES = -do_build[recrdeptask] = do_build \ No newline at end of file +do_build[recrdeptask] = do_build -- 1.7.1 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] OpenEmbedded Release 2010.12 --- needs your help!
Hello all, at OEDEM we discussed the need for OpenEmbedded releases. - OpenEmbedded releases are planned in certain months, so that we can plan stabilization efforts in the future. - Each release is a point release in time. - A release is a candidate branch point for a stable branch (which can be maintained by those who use it). - The next release is planned 2010.12, more specifically December 1st. That's only four weeks from now. - The 2010.12 release is hand-picked from a recent testing branch. Now that our testing team has the process in place to gather test results, please consider to build your favorite set of distro/machine targets using tinderbox, and report your results. One requirement is to use bitbake 1.10, as the minimal requirement will soon be 1.10 for the OpenEmbedded metadata. Regards, -- Leon ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH/RFC] qt4-embedded: tune QT_ARCH for armv6
On Thu, Nov 4, 2010 at 11:26 AM, Holger Freyther holger...@freyther.de wrote: On 11/04/2010 10:52 AM, Eric Bénard wrote: this is a RFC, I think it can also be used on qt 4.6.x and on armv7. Setting QT_ARCH to armv6 enable some asm optimized functions in QT. Do you know the consequences of this change? E.g. in the painting engine unaligned memory access will be allowed. I am not sure that Nokia has ever benchmarked what is faster (aligned/unaligned) access. So it would be very interesting to know the perf difference. E.g. use qttracereply to measure it. Phil do you happen to know why unaligned access got allowed starting from armv6? How fast will it be? The instructions can cope with unaligned data so the performance will not be impacted but its only upto 32-bit data above that the fault will still be generated and not all instructions can operate on unaligned data only ones operating on 32-bit data can do it. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] meta.bbclass: Exclude meta recipes from world builds
On Thu, Nov 4, 2010 at 12:14 PM, Khem Raj raj.k...@gmail.com wrote: Signed-off-by: Khem Raj raj.k...@gmail.com Acked-by: Chris Larson chris_lar...@mentor.com -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
On Thu, Nov 4, 2010 at 1:04 PM, Leon Woestenberg leon.woestenb...@gmail.com wrote: Hello all, at OEDEM we discussed the need for OpenEmbedded releases. - OpenEmbedded releases are planned in certain months, so that we can plan stabilization efforts in the future. - Each release is a point release in time. - A release is a candidate branch point for a stable branch (which can be maintained by those who use it). - The next release is planned 2010.12, more specifically December 1st. That's only four weeks from now. - The 2010.12 release is hand-picked from a recent testing branch. Thanks Leon for the notice. Now that our testing team has the process in place to gather test results, please consider to build your favorite set of distro/machine targets using tinderbox, and report your results. All testers please update the Testing page on wiki with the information. http://wiki.openembedded.org/index.php/Testing One requirement is to use bitbake 1.10, as the minimal requirement will soon be 1.10 for the OpenEmbedded metadata. Regards, -- Leon ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] testing branch 2010-11-04
Had a decent run with testing last week as a number of combinations built: http://cgit.openembedded.org/cgit.cgi/openembedded/tag/?id=tested_2010-10-29 testing-next is ready for clean builds. testing branch has been moved forward to last weeks testing-next. For more information on testing, please see: http://wiki.openembedded.org/index.php/Testing#Testing_Log Thanks, Cliff -- = http://bec-systems.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote: Hello all, at OEDEM we discussed the need for OpenEmbedded releases. One requirement is to use bitbake 1.10, as the minimal requirement will soon be 1.10 for the OpenEmbedded metadata. I'm hearing that TSC made a decision today to NOT require 1.10 for the upcoming release. Can we get any clarification and the official announcemnt, please. Thanks. -- Denys ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
On 5 November 2010 09:03, Eric Bénard e...@eukrea.com wrote: Hi, Le 04/11/2010 23:06, Denys Dmytriyenko a écrit : - OpenEmbedded releases are planned to be time based and happen every 3 month (quarterly), starting with the first one on December 1st. - what about a no major change freeze period for 2-3 weeks before each release to have a enough time to stabilize a little bit the beast ? This seems like a very sane thing. Can I further suggest a no new recipes freeze (perhaps only in the last week). -Graham ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
On Thu, Nov 04, 2010 at 11:33:01PM +0100, Eric B?nard wrote: Hi, Le 04/11/2010 23:06, Denys Dmytriyenko a ?crit : On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote: Hello all, at OEDEM we discussed the need for OpenEmbedded releases. - OpenEmbedded releases are planned in certain months, so that we can plan stabilization efforts in the future. - Each release is a point release in time. - A release is a candidate branch point for a stable branch (which can be maintained by those who use it). - The next release is planned 2010.12, more specifically December 1st. That's only four weeks from now. - The 2010.12 release is hand-picked from a recent testing branch. - OpenEmbedded releases are planned to be time based and happen every 3 month (quarterly), starting with the first one on December 1st. - what about a no major change freeze period for 2-3 weeks before each release to have a enough time to stabilize a little bit the beast ? I thought Leon kind of mentioned it in the first bullet point above, but probably not very clear. And yes, we definitely need a 2-3 weeks feature freeze period for stabilization. Thanks for pointing it out. Now that our testing team has the process in place to gather test results, please consider to build your favorite set of distro/machine targets using tinderbox, and report your results. One requirement is to use bitbake 1.10, as the minimal requirement will soon be 1.10 for the OpenEmbedded metadata. -- Denys ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Moving to layered structure of openembedded metadata
Hi In recent discussions there seems to be a lot of interest in moving towards more layered structure in OE where we discussed machine layers and arch based layers. There certainly are advantages to this approach as discussed in other threads on mailing list I think poky has already achieved that to a certain extent and has made metadata changes needed for such a structure. There are other polishing to metadata which is beneficial in general like recipe licenses, gcc runtime demystification etc. I would like to suggest that we adopt this structure and use Poky as core layer which we should always maintain in coherence and add the extra machines,architectures and recipes as additional layers around the base layer. This will also help us to scale the project and reduce the to and fro in merges as well as communities at large will benefit by seamless flow of patches and other contributions. This will of course need a lot of work and I wanted to bring to everyone to know if this would be a good approach moving forward. Thanks -Khem ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] TSC Discussions from 2010/11/03
Hi, The TSC met yesterday and discussed various topics. We're trying a slightly different approach to recording the outcome of the discussions: http://wiki.openembedded.org/index.php/TSCDecisions and the output from 5 such discussions yesterday is recorded there. These were all things that had discussion by the TSC pending after OEDEM. Cheers, Richard ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] task-arago-toolchain: Exclude from World build
Signed-off-by: Khem Raj raj.k...@gmail.com
---
recipes/tasks/task-arago-toolchain-dvsdk-target.bb |1 +
recipes/tasks/task-arago-toolchain-gst-target.bb |1 +
recipes/tasks/task-arago-toolchain-target.bb |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/recipes/tasks/task-arago-toolchain-dvsdk-target.bb
b/recipes/tasks/task-arago-toolchain-dvsdk-target.bb
index c143255..a8d3884 100644
--- a/recipes/tasks/task-arago-toolchain-dvsdk-target.bb
+++ b/recipes/tasks/task-arago-toolchain-dvsdk-target.bb
@@ -1,6 +1,7 @@
DESCRIPTION = Target packages for a standalone Arago SDK or external
toolchain
ALLOW_EMPTY = 1
PR = r18
+EXCLUDE_FROM_WORLD = 1
PACKAGES = ${PN}
diff --git a/recipes/tasks/task-arago-toolchain-gst-target.bb
b/recipes/tasks/task-arago-toolchain-gst-target.bb
index 3c6c2b9..ced1708 100644
--- a/recipes/tasks/task-arago-toolchain-gst-target.bb
+++ b/recipes/tasks/task-arago-toolchain-gst-target.bb
@@ -1,6 +1,7 @@
DESCRIPTION = Target packages for a standalone Arago SDK or external
toolchain
ALLOW_EMPTY = 1
PR = r24
+EXCLUDE_FROM_WORLD = 1
PACKAGES = ${PN}
diff --git a/recipes/tasks/task-arago-toolchain-target.bb
b/recipes/tasks/task-arago-toolchain-target.bb
index 496910e..8fb5182 100644
--- a/recipes/tasks/task-arago-toolchain-target.bb
+++ b/recipes/tasks/task-arago-toolchain-target.bb
@@ -1,6 +1,7 @@
DESCRIPTION = Target packages for a standalone Arago SDK or external
toolchain
ALLOW_EMPTY = 1
PR = r3
+EXCLUDE_FROM_WORLD = 1
PACKAGES = ${PN}
--
1.7.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
On Thu, 2010-11-04 at 18:14 -0400, Denys Dmytriyenko wrote: On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote: Hello all, at OEDEM we discussed the need for OpenEmbedded releases. One requirement is to use bitbake 1.10, as the minimal requirement will soon be 1.10 for the OpenEmbedded metadata. I'm hearing that TSC made a decision today to NOT require 1.10 for the upcoming release. Can we get any clarification and the official announcemnt, please. Thanks. There was a feeling it was too soon to the release to make a change like that. I've emailed out a pointer to a summary of the results of the discussions. I have to admit I'm a little frustrated by some of the decisions but I respect the processes we have in place. Cheers, Richard ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
