[OE-core] [PATCH 0/1] web-webkit: enable https web page accessing
From: Zhai Edwin edwin.z...@intel.com Let web-webkit RRECOMMENDS glib-networing for TLS support. The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib gzhai/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master Zhai Edwin (1): web-webkit: recommends glib-networking to access https web page meta/recipes-sato/web/web-webkit_svn.bb |5 - 1 files changed, 4 insertions(+), 1 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] web-webkit: recommends glib-networking to access https web page
From: Zhai Edwin edwin.z...@intel.com
It is required by libsoup for TLS support.
[YOCTO #1037] got fixed
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
meta/recipes-sato/web/web-webkit_svn.bb |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-sato/web/web-webkit_svn.bb
b/meta/recipes-sato/web/web-webkit_svn.bb
index a625929..2f79e0a 100644
--- a/meta/recipes-sato/web/web-webkit_svn.bb
+++ b/meta/recipes-sato/web/web-webkit_svn.bb
@@ -8,9 +8,12 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34
SECTION = x11
DEPENDS = libxml2 glib-2.0 gtk+ libglade webkit-gtk curl gconf js libowl
+# To access https web pages
+RRECOMMENDS_${PN} += glib-networking
+
SRCREV = 130
PV = 0.0+svnr${SRCPV}
-PR = r3
+PR = r4
SRC_URI = svn://svn.o-hand.com/repos/web/branches;module=webkit;proto=http \
file://link-with-g++.patch \
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On Wed, Jun 29, 2011 at 00:51, Scott Garman scott.a.gar...@intel.com wrote: On 06/28/2011 03:41 PM, Khem Raj wrote: reason is that dropbear only provides ssh and sshd packages openssh provides a few more e.g. openssh-sftp-server which is demanded by some images and at same time wants dropbear to provide sshd and ssh Now both recipes are to be built but are in contention for providing ssh and sshd How to solve this problem. ? Are other packages that openssh provides strictly depending on ssh/sshd from openssh ? or will they work on any ssh/sshd ? If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish Sounds good. I'd probably suggest openssh-ssh and openssh-sftp, where the latter one only includes what's necessary for the sftp-server to work. (Or maybe that was similar to what you meant?) I've run into that and have been wondering how to resolve it as well. If there are currently existing images which are pulling in dropbear's ssh and sshd while using openssh's sftp-server, then that would imply they can work independently, even though that combo seems like an aggressive space optimization that I would tend to avoid. I wouldn't say that it is a very common practice, but it certainly isn't too uncommon. I've seen it a number of times, and also used it in a few occasions. Regards, Anders ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
Op 29 jun 2011, om 00:41 heeft Khem Raj het volgende geschreven: If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish Dividing the openssl recipe would gain us little and the gains would be only for the power companies since you'd have to build openssh twice to get both sftp and ssh. The decrease in build time for only sftp is neglible. The real problem is the everything-is-a-distro-choice history we inherited from Poky. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] Upstream-Status: update the status for some patches
gypsy: fix-unused-but-set-variable-warning.patch telepathy-python: parallel_make.patch opkg-utils: mtime-int.patch opkg: headerfix.patch flac: flac-gcc43-fixes.patch libsamplerate0: libsamplerate-0.1.7-macro-quoting.patch Signed-off-by: Dongxiao Xu dongxiao...@intel.com --- .../fix-unused-but-set-variable-warning.patch |2 +- .../telepathy-python-0.15.19/parallel_make.patch |3 ++- .../opkg-utils/opkg-utils/mtime-int.patch |1 + .../opkg/opkg-0.1.8/headerfix.patch|2 +- .../flac/flac-1.2.1/flac-gcc43-fixes.patch |2 +- .../libsamplerate-0.1.7-macro-quoting.patch|2 +- 6 files changed, 7 insertions(+), 5 deletions(-) diff --git a/meta/recipes-connectivity/gypsy/files/fix-unused-but-set-variable-warning.patch b/meta/recipes-connectivity/gypsy/files/fix-unused-but-set-variable-warning.patch index 8dbf3ef..94523be 100644 --- a/meta/recipes-connectivity/gypsy/files/fix-unused-but-set-variable-warning.patch +++ b/meta/recipes-connectivity/gypsy/files/fix-unused-but-set-variable-warning.patch @@ -1,4 +1,4 @@ -Upstream-Status: Pending +Upstream-Status: Submitted Index: gypsy-0.8/gypsy/gypsy-time.c === diff --git a/meta/recipes-connectivity/telepathy/telepathy-python-0.15.19/parallel_make.patch b/meta/recipes-connectivity/telepathy/telepathy-python-0.15.19/parallel_make.patch index f1f3f56..2488246 100644 --- a/meta/recipes-connectivity/telepathy/telepathy-python-0.15.19/parallel_make.patch +++ b/meta/recipes-connectivity/telepathy/telepathy-python-0.15.19/parallel_make.patch @@ -5,7 +5,8 @@ src/_generated directory that tasks are based on. Signed-off-by: Dongxiao Xu dongxiao...@intel.com -Upstream-Status: Pending +Upstream-Status: Submitted +(However it seems that this project is out of maintanence.) diff -ruN telepathy-python-0.15.19-orig/src/Makefile.am telepathy-python-0.15.19/src/Makefile.am --- telepathy-python-0.15.19-orig/src/Makefile.am 2011-03-10 08:51:49.0 +0800 diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils/mtime-int.patch b/meta/recipes-devtools/opkg-utils/opkg-utils/mtime-int.patch index fdbce21..483a62a 100644 --- a/meta/recipes-devtools/opkg-utils/opkg-utils/mtime-int.patch +++ b/meta/recipes-devtools/opkg-utils/opkg-utils/mtime-int.patch @@ -13,6 +13,7 @@ gain by this change. Signed-off-by: Enrico Scholz enrico.sch...@sigma-chemnitz.de Upstream-Status: Pending +(Contacting the original author, no response yet.) Index: opkg-utils/opkg-make-index === diff --git a/meta/recipes-devtools/opkg/opkg-0.1.8/headerfix.patch b/meta/recipes-devtools/opkg/opkg-0.1.8/headerfix.patch index b3515a0..f68524b 100644 --- a/meta/recipes-devtools/opkg/opkg-0.1.8/headerfix.patch +++ b/meta/recipes-devtools/opkg/opkg-0.1.8/headerfix.patch @@ -2,7 +2,7 @@ Without this, the FILE reference in this header can cause compile issues. RP - 29/1/10 -Upstream-Status: Pending +Upstream-Status: Accepted Index: trunk/libopkg/pkg_dest.h === diff --git a/meta/recipes-multimedia/flac/flac-1.2.1/flac-gcc43-fixes.patch b/meta/recipes-multimedia/flac/flac-1.2.1/flac-gcc43-fixes.patch index 9c528c2..6b66599 100644 --- a/meta/recipes-multimedia/flac/flac-1.2.1/flac-gcc43-fixes.patch +++ b/meta/recipes-multimedia/flac/flac-1.2.1/flac-gcc43-fixes.patch @@ -1,6 +1,6 @@ # Acquired from OpenEmbedded # Fix no declaration of memcmp() -Upstream-Status: Pending +Upstream-Status: Submitted diff -urN flac-1.2.1-orig/examples/cpp/encode/file/main.cpp flac-1.2.1/examples/cpp/encode/file/main.cpp --- flac-1.2.1-orig/examples/cpp/encode/file/main.cpp 2010-06-23 15:06:29.159481339 +0800 diff --git a/meta/recipes-multimedia/libsamplerate/libsamplerate0-0.1.7/libsamplerate-0.1.7-macro-quoting.patch b/meta/recipes-multimedia/libsamplerate/libsamplerate0-0.1.7/libsamplerate-0.1.7-macro-quoting.patch index 878f969..1518d7e 100644 --- a/meta/recipes-multimedia/libsamplerate/libsamplerate0-0.1.7/libsamplerate-0.1.7-macro-quoting.patch +++ b/meta/recipes-multimedia/libsamplerate/libsamplerate0-0.1.7/libsamplerate-0.1.7-macro-quoting.patch @@ -1,4 +1,4 @@ -Upstream-Status: Pending +Upstream-Status: Inappropriate [configuration] diff -ruN libsamplerate-0.1.7-orig//acinclude.m4 libsamplerate-0.1.7/acinclude.m4 --- libsamplerate-0.1.7-orig//acinclude.m4 2011-04-20 15:04:25.147664992 +0800 -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1][PULL] Upstream-Status update
Hi Saul, This pull request update some patch's Upstream-Status, please help to review and pull. Thanks, Dongxiao The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dxu4/patch-upstream http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/patch-upstream Dongxiao Xu (1): Upstream-Status: update the status for some patches .../fix-unused-but-set-variable-warning.patch |2 +- .../telepathy-python-0.15.19/parallel_make.patch |3 ++- .../opkg-utils/opkg-utils/mtime-int.patch |1 + .../opkg/opkg-0.1.8/headerfix.patch|2 +- .../flac/flac-1.2.1/flac-gcc43-fixes.patch |2 +- .../libsamplerate-0.1.7-macro-quoting.patch|2 +- 6 files changed, 7 insertions(+), 5 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On Wed, Jun 29, 2011 at 10:24, Koen Kooi k...@dominion.thruhere.net wrote: Op 29 jun 2011, om 00:41 heeft Khem Raj het volgende geschreven: If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish Dividing the openssl recipe would gain us little and the gains would be only for the power companies since you'd have to build openssh twice to get both sftp and ssh. The decrease in build time for only sftp is neglible. Hm, speaking against what I've often been advocating (reducing build time by factoring out dependenies etc)... I think the simplest and most straightforward solution is to just split the packaging into openssh-ssh and openssh-sftp, where openssh-sftp packages just what is needed for handling the sftp-server in cooperation with dropbear. It could possibly also include the sftp-client if desired/needed. The openssh-ssh package could then depend on the openssh-sftp package; then there would be no difference today for the distros using the complete openssh package. I read the If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest part as just splitting the package. But now when I re-read it, it could very well have implied creating two recipes; which I agree wouldn't be the best option. Regards, Anders ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On 06/29/2011 09:50 AM, Anders Darander wrote: On Wed, Jun 29, 2011 at 10:24, Koen Kooi k...@dominion.thruhere.net wrote: Op 29 jun 2011, om 00:41 heeft Khem Raj het volgende geschreven: If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish Dividing the openssl recipe would gain us little and the gains would be only for the power companies since you'd have to build openssh twice to get both sftp and ssh. The decrease in build time for only sftp is neglible. Hm, speaking against what I've often been advocating (reducing build time by factoring out dependenies etc)... I think the simplest and most straightforward solution is to just split the packaging into openssh-ssh and openssh-sftp, where openssh-sftp packages just what is needed for handling the sftp-server in cooperation with dropbear. It could possibly also include the sftp-client if desired/needed. The openssh-ssh package could then depend on the openssh-sftp package; then there would be no difference today for the distros using the complete openssh package. I read the If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest part as just splitting the package. But now when I re-read it, it could very well have implied creating two recipes; which I agree wouldn't be the best option. The package in OE has been split for a long long time since I first discovered about dropbear being about to use sftp-server. Graeme ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
Op 29 jun 2011, om 10:50 heeft Anders Darander het volgende geschreven: On Wed, Jun 29, 2011 at 10:24, Koen Kooi k...@dominion.thruhere.net wrote: Op 29 jun 2011, om 00:41 heeft Khem Raj het volgende geschreven: If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish Dividing the openssl recipe would gain us little and the gains would be only for the power companies since you'd have to build openssh twice to get both sftp and ssh. The decrease in build time for only sftp is neglible. Hm, speaking against what I've often been advocating (reducing build time by factoring out dependenies etc)... I think the simplest and most straightforward solution is to just split the packaging into openssh-ssh and openssh-sftp, where openssh-sftp packages just what is needed for handling the sftp-server in cooperation with dropbear. It could possibly also include the sftp-client if desired/needed. That's already the case now. The problem is the PROVIDES overlap since the Poky people decided a distro could only have one true ssh implementation instead of choosing it per image. So if your distro doesn't set the PREFERRED_PROVIDER_sshd you get those nagging messages during parsing that scare users and make consultants rich. OE .dev isn't a lot better with the misguided DISTRO_SSH_DAEMON, but at least it doesn't show those nag messages. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Gstreamer packaging
Saul said I broke gst-meta with my patch, so let's view the gstreamer situation:
given:
1) plugins move between -good, -bad and -ugly
2) libraries move between -good, -bad and -ugly
3) applications require specific plugins
4) upgrade paths must work
When combining 1 and 4 the current 'gst-plugin-{good,bad,ugly}-foo' naming does
not work, since the same file will get provided by 2 packages after the move.
Attentive readers will have guessed that the current gst-meta tries, and
ultimately fails to hide 1) and 2).
So the new systems does the following:
* split out each plugin as gst-plugin-foo
* split out each lib as libfoo
So both plugins and libraries have a stable package name (barring plugin
renames, e.g. flvdemux - flv). Package feeds and upgrades finally work as
expected
There are some downsides with this approach:
a) no way to know a priori where a plugin lives at a given time
b) by extension you build too much or too little.
c) scary multiple provider messages during parsing
OE .dev has a slightly different approach where you manually go through deploy
and see what got generated by who and plug that into PROVIDES. I'm not a big
fan of that, but it eliminates those scary messages.
I would very much like to have package feeds and upgrades to work, which
currently is impossible for gstreamer packages.
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On Wed, 2011-06-29 at 10:08 +0100, Phil Blundell wrote: On Wed, 2011-06-29 at 10:56 +0200, Koen Kooi wrote: That's already the case now. The problem is the PROVIDES overlap since the Poky people decided a distro could only have one true ssh implementation instead of choosing it per image. So if your distro doesn't set the PREFERRED_PROVIDER_sshd you get those nagging messages during parsing that scare users and make consultants rich. OE .dev isn't a lot better with the misguided DISTRO_SSH_DAEMON, but at least it doesn't show those nag messages. Fundamentally I think it is just a bug in bitbake that it makes such a fuss about overlapping PROVIDES. It's not unreasonable for both openssh and dropbear to be PROVIDEing something like virtual/ssh-daemon (and indeed RPROVIDEing an equivalent) but, as you say, any given distro is perfectly entitled to want to build both of them and ship them in different images and/or feeds. I guess what bitbake is really trying to warn about is recipes which will install conflicting files into the sysroot. Obviously in a future utopia of per-recipe sysroot construction this would be a non-issue, but even with today's level of technology I think it would be fairly easy for us to detect when a collision actually happens and issue a sensible diagnostic at that point. That would allow the offending ERROR to be removed without causing any real regression. Speaking as the person who likely added this code in the first place, its not quite this simple. There are two problem cases: a) When we have several recipes like external-toolchain, glibc, eglibc and uclibc all of which provide virtual/libc. If something else in the build wants say eglibc-locale-foo but the preferred provider of virtual/libc is uclibc then what bitbake is trying to warn about is that it the user isn't going to get what they expect as both uclibc and eglibc could end up being built. We used to end up in a mess where bitbake could build the external-toolchain recipe and some other libcs in parallel resulting an a what could only be described as a mess. These days this doesn't happen so much due to bitbake spitting out its dummy earlier on. It is actually quite hard to detect this problem generically. b) There is also the case where two recipes might generate the same package. There is also some code in bitbake which at least tries to flag problems like that from the point of view of multiple runtime providers. So the code does actually stop some pretty nasty breakage from happening but it isn't perfect and if we can find better ways, by all means... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [Multilib] a problem of SHLIBSDIR
On Wed, 2011-06-29 at 17:10 +0800, Lu, Lianhao wrote: Hi, SHLIBSDIR is a central place where to store the pkg information about the shared libraries which the package would provide. In the do_package task, the function package_do_shlibs() will use this kind of information to automatically add RDEPENDS for the package being built. In the multilib situation, the SHLIBSDIR should be set to a different place form the normal version, otherwise a 32bit application might RDEPENDS on lib64-eglibc instead of the 32bit eglibc. The following patch tries to solve this problem. Any comment? http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=llu/mlid=1970842424c414db50058ff99c6627e3ca034a04 I think I'd been assuming that SHLIBSDIR included the TARGET_VENDOR string as part of the triplet but it obviously doesn't and we need this. Good catch. I think the patch is a good one to add! Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On Wed, 2011-06-29 at 10:42 +0100, Richard Purdie wrote: Speaking as the person who likely added this code in the first place, its not quite this simple. There are two problem cases: a) When we have several recipes like external-toolchain, glibc, eglibc and uclibc all of which provide virtual/libc. If something else in the build wants say eglibc-locale-foo but the preferred provider of virtual/libc is uclibc then what bitbake is trying to warn about is that it the user isn't going to get what they expect as both uclibc and eglibc could end up being built. In the particular case of uclibc vs eglibc, this isn't going to happen because the COMPATIBLE_HOST logic will only ever admit one or the other to the set of allowed recipes. And, in the general case of arbitrary packages, the point I was trying to make earlier is that the user might actually _want_ to build two things which happen to both provide the same virtual, and shouldn't be prevented (or even necessarily discouraged) from doing so. If there are other cases like the eglibc/uclibc thing which aren't intrinsically safe in the same way then I guess the right way to solve that is via some kind of (R)CONFLICTS declaration and smarter dependency processing within bitbake. b) There is also the case where two recipes might generate the same package. There is also some code in bitbake which at least tries to flag problems like that from the point of view of multiple runtime providers. As with the sysroot thing, I think the place to detect and diagnose that is at the point where the packages are generated. Or, alternatively (but slightly less robustly) you could just scan PACKAGES for all the recipes in the runqueue and look for collisions there, which would allow you to detect at least some problems sooner. I don't think the list of PROVIDES is sufficiently reliable to use for this purpose since you can easily have both false positives and false negatives. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Gstreamer packaging
On Wed, 2011-06-29 at 11:33 +0200, Koen Kooi wrote: So the new systems does the following: * split out each plugin as gst-plugin-foo * split out each lib as libfoo So both plugins and libraries have a stable package name (barring plugin renames, e.g. flvdemux - flv). Package feeds and upgrades finally work as expected Agreed, I think this is about the only reasonable thing to do. The way that the gstreamer folks bundle up their plugins for distribution, and particularly the semi-arbitrary split between -base, -good and -bad, is not especially helpful for consumers of those packages. In the past I have been strongly tempted to just stick all the plugins (with the possible exception of -ugly, which might require a bit of ENTERPRISE_DISTRO care) into a single recipe so that at least you always know which recipe needs building to get a given plugin. That would obviously lead to more build time but I think it is probably a good tradeoff in this situation. In an ideal world it would be nice for all the plugins to be packaged independently a la Xorg, but I have no idea whether the gstreamer folks would be receptive to that idea. OE .dev has a slightly different approach where you manually go through deploy and see what got generated by who and plug that into PROVIDES. I'm not a big fan of that, but it eliminates those scary messages. I guess that does also work, but I didn't like the patch when it first went into .dev and I am still not very fond of it. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On Wed, 2011-06-29 at 10:51 +0100, Phil Blundell wrote: On Wed, 2011-06-29 at 10:42 +0100, Richard Purdie wrote: Speaking as the person who likely added this code in the first place, its not quite this simple. There are two problem cases: a) When we have several recipes like external-toolchain, glibc, eglibc and uclibc all of which provide virtual/libc. If something else in the build wants say eglibc-locale-foo but the preferred provider of virtual/libc is uclibc then what bitbake is trying to warn about is that it the user isn't going to get what they expect as both uclibc and eglibc could end up being built. In the particular case of uclibc vs eglibc, this isn't going to happen because the COMPATIBLE_HOST logic will only ever admit one or the other to the set of allowed recipes. And, in the general case of arbitrary packages, the point I was trying to make earlier is that the user might actually _want_ to build two things which happen to both provide the same virtual, and shouldn't be prevented (or even necessarily discouraged) from doing so. If there are other cases like the eglibc/uclibc thing which aren't intrinsically safe in the same way glibc/eglibc? external-toolchain? This area used to be a world of pain for users as bitbake would merrily go and build a ton of conflicting stuff and the user would be left with no idea what was going on. Before that code was in bitbake, it was a major frustration of users and whilst there are issues like the ssh one, in general the current code has done orders of magnitude more good than harm. I believe there is also a whitelist variable to say we really don't mind multiple providers of X too so there may actually be an already existing way to work around this issue. then I guess the right way to solve that is via some kind of (R)CONFLICTS declaration and smarter dependency processing within bitbake. Likely yes but the trouble is you then have to explicitly mark two things as conflicting so as soon as you add something new to the mix, the mechanism doesn't work. This also means adding *CONFLICTS support to bitbake which is something we've wanted to do for a long time but never got around to. b) There is also the case where two recipes might generate the same package. There is also some code in bitbake which at least tries to flag problems like that from the point of view of multiple runtime providers. As with the sysroot thing, I think the place to detect and diagnose that is at the point where the packages are generated. Or, alternatively (but slightly less robustly) you could just scan PACKAGES for all the recipes in the runqueue and look for collisions there, which would allow you to detect at least some problems sooner. I don't think the list of PROVIDES is sufficiently reliable to use for this purpose since you can easily have both false positives and false negatives. I don't disagree but as things stand PROVIDES has actually been vert helpful to users in general, certainly its better than doing nothing. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Gstreamer packaging
On Wed, 2011-06-29 at 10:55 +0100, Phil Blundell wrote:
On Wed, 2011-06-29 at 11:33 +0200, Koen Kooi wrote:
So the new systems does the following:
* split out each plugin as gst-plugin-foo
* split out each lib as libfoo
So both plugins and libraries have a stable package name (barring
plugin renames, e.g. flvdemux - flv). Package feeds and upgrades
finally work as expected
Agreed, I think this is about the only reasonable thing to do. The way
that the gstreamer folks bundle up their plugins for distribution, and
particularly the semi-arbitrary split between -base, -good and -bad, is
not especially helpful for consumers of those packages.
In the past I have been strongly tempted to just stick all the plugins
(with the possible exception of -ugly, which might require a bit of
ENTERPRISE_DISTRO care) into a single recipe so that at least you always
know which recipe needs building to get a given plugin. That would
obviously lead to more build time but I think it is probably a good
tradeoff in this situation. In an ideal world it would be nice for all
the plugins to be packaged independently a la Xorg, but I have no idea
whether the gstreamer folks would be receptive to that idea.
Let me quickly recap the problem. Its perfectly reasonable for a recipe
to want to depend on gst-plugin-foo.
The trouble is that bitbake is left pretty much totally clueless when
something says it would like to have gst-plugin-foo and multiple
things provide it.
Obviously you can make the recipe depend on good+bad+ugly but its less
than ideal for build time reasons (esp. when considering dependencies)
but also the reason that good/bad/ugly exist in the first place which is
licensing. If the recipe always has to depend on good+bad+ugly, it
becomes rather tricky to disable ugly and work out whether the resulting
configuration can build. Companies interested in license compliance do
have a strong need to be able to do this.
Its for the latter reason that OE-Core has kept ${PN} in the plugin
names at present since deterministic builds are kind of nice.
OE .dev has a slightly different approach where you manually go
through deploy and see what got generated by who and plug that into
PROVIDES. I'm not a big fan of that, but it eliminates those scary
messages.
I guess that does also work, but I didn't like the patch when it first
went into .dev and I am still not very fond of it.
It would at least ensure deterministic builds but I share your lack of
fondness.
A recipe per plugin would certainly start to look attractive and it
might be worth talking to the gstreamer people...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Gstreamer packaging
On Wed, 2011-06-29 at 11:53 +0100, Richard Purdie wrote: Obviously you can make the recipe depend on good+bad+ugly but its less than ideal for build time reasons (esp. when considering dependencies) but also the reason that good/bad/ugly exist in the first place which is licensing. It's only -ugly which has licensing issues, and those same licensing issues also mean that plugins don't tend to migrate to or from -ugly in the same way as they do between the other packages. So, if -good, -bad and -base were combined in a single recipe, leaving -ugly separate, that would solve about 90% of the current nuisance. Dependency-wise, gst-plugins-good is the only one with a large stack of DEPENDS. If you assume that most people are probably going to need at least one plugin from that package anyway, which I think is probably the case in reality, then the dependency impact of combining -good, -bad and -base in a single recipe would be fairly negligible. (The only extra dependencies you'd get from -bad would be libmusicbrainz, tremor and librsvg.) Of course, another way to attack the dependency stack problem would be to combine the recipes and then be more aggressive about allowing DISTROs to select only the plugins (and hence the dependencies) that they want. For example, I have long found it slightly annoying that gst-plugins-good requires gtk+ and x11 at build time since I don't actually use either of those libraries in my deployed system. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Gstreamer packaging
On Wed, 2011-06-29 at 11:53 +0100, Richard Purdie wrote: Obviously you can make the recipe depend on good+bad+ugly but its less than ideal for build time reasons (esp. when considering dependencies) but also the reason that good/bad/ugly exist in the first place which is licensing. If the recipe always has to depend on good+bad+ugly, it becomes rather tricky to disable ugly and work out whether the resulting configuration can build. Companies interested in license compliance do have a strong need to be able to do this. Incidentally, there isn't actually (as far as I can tell) anything in the current -ugly recipe which would indicate to an ENTERPRISE_DISTRO that this recipe is potentially problematic. Its LICENSE field just reads GPLv2+ LGPLv2.1+ LGPLv2+, which might or might not be accurate, and it doesn't appear to have the self-skipping behaviour which the corresponding recipe in oe.dev does. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] prelink_git.bb: Only block the postinst script when no image-prelink
On Wed, 2011-06-29 at 12:20 +0100, Phil Blundell wrote: On Tue, 2011-06-28 at 20:42 -0500, Mark Hatle wrote: +# If we're using mklibs-prelink, we want to skip this on the host side Is it really mklibs-prelink? I thought those were two different things. Ah, nevermind, I see you changed this in v2. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
On Tue, 2011-06-28 at 17:07 -0700, Saul Wold wrote:
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a',
'${staticdev_libs}', d)}
Does that actually work? I wouldn't have expected the pattern to get
globbed early enough for the oe_filter_out to have any effect.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] fontconfig: specify font directory in EXTRA_OECONF
On Tue, 2011-06-28 at 17:27 -0700, Khem Raj wrote: On 06/27/2011 08:24 AM, Phil Blundell wrote: -PR = r1 +PR = r3 a nitpick though not wrong but should be r2 Is it official policy that PRs need to be sequential? There seem to be various precedents for incrementing it by more than one in a single checkin, see for example d3fc33760a80b0a067b41ff88e99941f1c40c8f9 and 993a2367f881f1f4eaa10339cde93c7058660d67. If it's meant to only go up by one each time then I guess I can cope with that but it would require a bit of extra mangling at my end. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libc locale split: fix some remaining problems
* libc-{common,package}.bbclass: fix shlib renaming for the C library
Without this you'd end up with eglibc_2.12.ipk instead of
libc6_2.12.ipk as before
* eglibc-locale: don't make versions go backwards after split from eglibc
eglibc was way beyond PR = r1 at the time of the split, so increase
PR to make package upgrades work
This still doesn't fix:
$ dpkg-deb -I ipk/armv7a/libc6_2.12-r16_armv7a.ipk
Package: libc6
[..]
Depends: libc6-dev (= 2.12)
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/classes/libc-common.bbclass |9 +
meta/classes/libc-package.bbclass |7 +--
meta/recipes-core/eglibc/eglibc-locale.inc |2 +-
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/meta/classes/libc-common.bbclass b/meta/classes/libc-common.bbclass
index bae0ace..912a7ee 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -21,3 +21,12 @@ def get_libc_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --without-fp
return
+
+# We want to do this indirection so that we can safely 'return'
+# from the called function even though we're prepending
+python populate_packages_prepend () {
+ if bb.data.getVar('DEBIAN_NAMES', d, 1):
+ bpn = bb.data.getVar('BPN', d, 1)
+ bb.data.setVar('PKG_'+bpn, 'libc6', d)
+ bb.data.setVar('PKG_'+bpn+'-dev', 'libc6-dev', d)
+}
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 4bc58c8..8e03f03 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -365,12 +365,7 @@ python package_do_split_gconvs () {
}
-# We want to do this indirection so that we can safely 'return'
-# from the called function even though we're prepending
python populate_packages_prepend () {
- if bb.data.getVar('DEBIAN_NAMES', d, 1):
- bpn = bb.data.getVar('BPN', d, 1)
- bb.data.setVar('PKG_'+bpn, 'libc6', d)
- bb.data.setVar('PKG_'+bpn+'-dev', 'libc6-dev', d)
bb.build.exec_func('package_do_split_gconvs', d)
}
+
diff --git a/meta/recipes-core/eglibc/eglibc-locale.inc
b/meta/recipes-core/eglibc/eglibc-locale.inc
index 7c4b1d5..96f2d8a 100644
--- a/meta/recipes-core/eglibc/eglibc-locale.inc
+++ b/meta/recipes-core/eglibc/eglibc-locale.inc
@@ -26,7 +26,7 @@ BINARY_LOCALE_ARCHES ?= arm.* i[3-6]86 x86_64 powerpc mips
# set 0 for qemu emulation of native localedef for locale generation
LOCALE_GENERATION_WITH_CROSS-LOCALEDEF = 1
-PR = r1
+PR = r16
PKGSUFFIX =
PKGSUFFIX_virtclass-nativesdk = -nativesdk
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] libc locale split: fix some remaining problems
* libc-{common,package}.bbclass: fix shlib renaming for the C library
Without this you'd end up with eglibc_2.12.ipk instead of
libc6_2.12.ipk as before
* eglibc-locale: don't make versions go backwards after split from eglibc
eglibc was way beyond PR = r1 at the time of the split, so increase
PR to make package upgrades work
This still doesn't fix:
$ dpkg-deb -I ipk/armv7a/libc6_2.12-r16_armv7a.ipk
Package: libc6
[..]
Depends: libc6-dev (= 2.12)
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/classes/libc-common.bbclass |7 +++
meta/classes/libc-package.bbclass |5 +
meta/recipes-core/eglibc/eglibc-locale.inc |2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/meta/classes/libc-common.bbclass b/meta/classes/libc-common.bbclass
index bae0ace..5e93205 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -21,3 +21,10 @@ def get_libc_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --without-fp
return
+
+python populate_packages_prepend () {
+ if bb.data.getVar('DEBIAN_NAMES', d, 1):
+ bpn = bb.data.getVar('BPN', d, 1)
+ bb.data.setVar('PKG_'+bpn, 'libc6', d)
+ bb.data.setVar('PKG_'+bpn+'-dev', 'libc6-dev', d)
+}
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 4bc58c8..695b260 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -368,9 +368,6 @@ python package_do_split_gconvs () {
# We want to do this indirection so that we can safely 'return'
# from the called function even though we're prepending
python populate_packages_prepend () {
- if bb.data.getVar('DEBIAN_NAMES', d, 1):
- bpn = bb.data.getVar('BPN', d, 1)
- bb.data.setVar('PKG_'+bpn, 'libc6', d)
- bb.data.setVar('PKG_'+bpn+'-dev', 'libc6-dev', d)
bb.build.exec_func('package_do_split_gconvs', d)
}
+
diff --git a/meta/recipes-core/eglibc/eglibc-locale.inc
b/meta/recipes-core/eglibc/eglibc-locale.inc
index 7c4b1d5..96f2d8a 100644
--- a/meta/recipes-core/eglibc/eglibc-locale.inc
+++ b/meta/recipes-core/eglibc/eglibc-locale.inc
@@ -26,7 +26,7 @@ BINARY_LOCALE_ARCHES ?= arm.* i[3-6]86 x86_64 powerpc mips
# set 0 for qemu emulation of native localedef for locale generation
LOCALE_GENERATION_WITH_CROSS-LOCALEDEF = 1
-PR = r1
+PR = r16
PKGSUFFIX =
PKGSUFFIX_virtclass-nativesdk = -nativesdk
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] bump PR to fix the perl-native issue
Cui, Dexuan wrote:
I did a core-image-sato-sdk and meta-toolchain-gmae building using a
commit of May 12 between 605141a9(the perl-native workaround patch)
and 3ba6d018(populate perl-native into its own dir), and grepped
${STAGING_BINDIR_NATIVE}/perl in
${STAGING_BINDIR_NATIVE} to find out all the scripts needed to
address. Some recipes' PRs have been bumped, so this patch only bumps
the omitted ones.
Please review the patch.
The following changes since commit
2163461ec94528ecf046a04edc5db3d2dd3a6b8b:
systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16 22:14:06
+0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dcui/bump_PR
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/bump_PR
Dexuan Cui (1):
glib-2.0,intltool,rpm,sgmlspl-native: Bump PR to resolve perl-native
issue
meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb |2 +-
meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb |2 +-
meta/recipes-devtools/intltool/intltool_0.40.6.bb |2 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb |2 +-
.../sgmlspl/sgmlspl-native_1.03ii.bb |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] bump PR to fix the perl-native issue
Cui, Dexuan wrote:
Cui, Dexuan wrote:
I did a core-image-sato-sdk and meta-toolchain-gmae building using a
commit of May 12 between 605141a9(the perl-native workaround patch)
and 3ba6d018(populate perl-native into its own dir), and grepped
${STAGING_BINDIR_NATIVE}/perl in
${STAGING_BINDIR_NATIVE} to find out all the scripts needed to
address. Some recipes' PRs have been bumped, so this patch only
bumps the omitted ones.
Please review the patch.
The following changes since commit
2163461ec94528ecf046a04edc5db3d2dd3a6b8b:
systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16
22:14:06 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dcui/bump_PR
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/bump_PR
Dexuan Cui (1):
glib-2.0,intltool,rpm,sgmlspl-native: Bump PR to resolve
perl-native issue
meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb |2 +-
meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb |2 +-
meta/recipes-devtools/intltool/intltool_0.40.6.bb |2 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb |2 +-
.../sgmlspl/sgmlspl-native_1.03ii.bb |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
(Sorry for my previous empty reply to this thead. I pressed enter too
hastily...)
Looks the patch was neglected somehow, either? :-)
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] fix to bug #1099, updates to Upstream-Status and distro_tracking_fields.inc
The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (3): grub: add -fno-reorder-functions into STAGE2_COMPILE lttng-ust: change the patch's Upstream-Status to Accepted. distro_tracking_fields.inc: update RECIPE_MANUAL_CHECK_DATE for screen and tcf-agent .../conf/distro/include/distro_tracking_fields.inc |3 +- .../grub/grub-0.97/no-reorder-functions.patch | 31 meta/recipes-bsp/grub/grub_0.97.bb |5 ++- .../lttng/lttng-ust/uclibc-sched_getcpu.patch |2 +- 4 files changed, 37 insertions(+), 4 deletions(-) create mode 100644 meta/recipes-bsp/grub/grub-0.97/no-reorder-functions.patch -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] grub: add -fno-reorder-functions into STAGE2_COMPILE
This is used to work around a gcc-4.6's bug about the option.
[YOCTO #1099]
Signed-off-by: Dexuan Cui dexuan@intel.com
---
.../grub/grub-0.97/no-reorder-functions.patch | 31
meta/recipes-bsp/grub/grub_0.97.bb |5 ++-
2 files changed, 34 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-bsp/grub/grub-0.97/no-reorder-functions.patch
diff --git a/meta/recipes-bsp/grub/grub-0.97/no-reorder-functions.patch
b/meta/recipes-bsp/grub/grub-0.97/no-reorder-functions.patch
new file mode 100644
index 000..70037e4
--- /dev/null
+++ b/meta/recipes-bsp/grub/grub-0.97/no-reorder-functions.patch
@@ -0,0 +1,31 @@
+Upstream-Status: Inappropriate [disable feature]
+
+After the commit tcmode-default: switch to gcc 4.6.0 for x86, x86-64 arm,
+we got bug 1099 (http://bugzilla.yoctoproject.org/show_bug.cgi?id=1099):
+
+Running install --stage2=/ssd/boot/grub/stage2 /boot/grub/stage1(hd0)
+ /boot/grub/stage2 p /boot/grub/menu list failed
+Error 6: Mismatched or corrupt version of stage1/stage2
+
+This turned out to be a gcc's bug. See
+https://bugs.gentoo.org/show_bug.cgi?id=360513
+http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
+
+Upstream gcc seems uninterested in the bug, so at present we can disable the
+option as a workaround. Thanks Ryan Hill for the investigation and the
+workaround patch.
+
+Dexuan Cui dexuan@intel.com
+Wed Jun 29 20:21:39 CST 2011
+
+--- grub-0.97/stage2/Makefile.am.orig
grub-0.97/stage2/Makefile.am
+@@ -79,7 +79,7 @@
+ HERCULES_FLAGS =
+ endif
+
+-STAGE2_COMPILE = $(STAGE2_CFLAGS) -fno-builtin -nostdinc \
++STAGE2_COMPILE = $(STAGE2_CFLAGS) -fno-reorder-functions -fno-builtin
-nostdinc \
+ $(NETBOOT_FLAGS) $(SERIAL_FLAGS) $(HERCULES_FLAGS)
+
+ STAGE1_5_LINK = -nostdlib -Wl,-N -Wl,-Ttext -Wl,2000
diff --git a/meta/recipes-bsp/grub/grub_0.97.bb
b/meta/recipes-bsp/grub/grub_0.97.bb
index 131d942..ffacb61 100644
--- a/meta/recipes-bsp/grub/grub_0.97.bb
+++ b/meta/recipes-bsp/grub/grub_0.97.bb
@@ -11,10 +11,11 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b \
file://grub/main.c;beginline=3;endline=9;md5=22a5f28d2130fff9f2a17ed54be90ed6
RDEPENDS_${PN} = diffutils
-PR = r3
+PR = r6
SRC_URI = ftp://alpha.gnu.org/gnu/grub/grub-${PV}.tar.gz; \
- file://autohell.patch;apply=yes
+file://no-reorder-functions.patch \
+file://autohell.patch
SRC_URI[md5sum] = cd3f3eb54446be6003156158d51f4884
SRC_URI[sha256sum] =
4e1d15d12dbd3e9208111d6b806ad5a9857ca8850c47877d36575b904559260b
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] distro_tracking_fields.inc: update RECIPE_MANUAL_CHECK_DATE for screen and tcf-agent
Signed-off-by: Dexuan Cui dexuan@intel.com --- .../conf/distro/include/distro_tracking_fields.inc |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index e9594cf..6699ab7 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -1001,6 +1001,7 @@ RECIPE_MAINTAINER_pn-mdadm = Dexuan Cui dexuan@intel.com RECIPE_STATUS_pn-screen = green RECIPE_DEPENDENCY_CHECK_pn-screen = not done RECIPE_LATEST_VERSION_pn-screen = 4.0.3 +RECIPE_MANUAL_CHECK_DATE_pn-screen = June 29, 2011 RECIPE_NO_OF_PATCHES_pn-screen = 2 RECIPE_PATCH_pn-screen+screen_4.0.3-11+lenny1.diff.gz = Debian's enhancement RECIPE_PATCH_pn-screen+configure = fix configure.in to make the build pass @@ -2773,7 +2774,7 @@ RECIPE_STATUS_pn-tcf-agent = green DISTRO_PN_ALIAS_pn-tcf-agent = WindRiver upstream=http://www.eclipse.org/dsdp/tm/; RECIPE_DEPENDENCY_CHECK_pn-tcf-agent = not done RECIPE_LATEST_VERSION_pn-tcf-agent = 0.3.0+svnr1078 -RECIPE_MANUAL_CHECK_DATE_pn-tcf-agent = June 13, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-tcf-agent = June 29, 2011 RECIPE_NO_UPDATE_REASON_pn-tcf-agent = Do not upgrade to version: (998)? because upstraem hasn't defined a formal release tag. RECIPE_NO_OF_PATCHES_pn-tcf-agent = 2 RECIPE_PATCH_pn-tcf-agent+terminals_agent = we might get the patch from git://git.yoctoproject.org/eclipse-poky.git in future -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] grub: add -fno-reorder-functions into STAGE2_COMPILE
Cui, Dexuan wrote:
This is used to work around a gcc-4.6's bug about the option.
[YOCTO #1099]
diff --git a/meta/recipes-bsp/grub/grub_0.97.bb
b/meta/recipes-bsp/grub/grub_0.97.bb
index 131d942..ffacb61 100644
--- a/meta/recipes-bsp/grub/grub_0.97.bb
+++ b/meta/recipes-bsp/grub/grub_0.97.bb
RDEPENDS_${PN} = diffutils
-PR = r3
+PR = r6
Sorry, PR should be r4 here... I used r6 in my debugging.
I forgot to clean this up when I sent the patch.
I've re-pushed my branch.
Please use the new commit:
http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=dcui/masterid=5c670ef29d828e76ae101fcfe9234732af759dfa
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] lttng-ust: change the patch's Upstream-Status to Accepted.
Signed-off-by: Dexuan Cui dexuan@intel.com --- .../lttng/lttng-ust/uclibc-sched_getcpu.patch |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-kernel/lttng/lttng-ust/uclibc-sched_getcpu.patch b/meta/recipes-kernel/lttng/lttng-ust/uclibc-sched_getcpu.patch index a6aa6a7..f4ea196 100644 --- a/meta/recipes-kernel/lttng/lttng-ust/uclibc-sched_getcpu.patch +++ b/meta/recipes-kernel/lttng/lttng-ust/uclibc-sched_getcpu.patch @@ -6,7 +6,7 @@ this header is not needed even in eglibc case so it can be removed Signed-off-by: Khem Raj raj.k...@gmail.com -Upstream-Status: Submitted +Upstream-Status: Accepted Index: ust-0.12/libust/tracer.h === -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] grub: add -fno-reorder-functions into STAGE2_COMPILE
On Wed, 2011-06-29 at 21:09 +0800, Dexuan Cui wrote: +This turned out to be a gcc's bug. See +https://bugs.gentoo.org/show_bug.cgi?id=360513 +http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333 + +Upstream gcc seems uninterested in the bug, so at present we can disable the +option as a workaround. Thanks Ryan Hill for the investigation and the +workaround patch. I'm not sure it's fair to say that upstream gcc is uninterested. It doesn't appear that anybody has been willing or able to produce a testcase which will allow the gcc people to debug the problem. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc-locale: fix localedef packaging
On Tue, 2011-06-28 at 22:32 +0200, Koen Kooi wrote: From http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yoctoid=0d0e14cda2ddd881d09798b0e6edd8086aa9b6d9 +libc6 - libc6_dev; So libc6 now depends on libc6-dev :( I guess it would be straightforward to patch insane.bbclass to detect that particular failure (which does indeed seem to happen to libc distressingly often). It already diagnoses the case where a package erroneously depends on a -dbg package, and I can't think of any reason why the same logic couldn't be applied to -dev. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Fix prelink to avoid first boot script
On Tue, 2011-06-28 at 20:42 -0500, Mark Hatle wrote: In most cases the user will have the image-prelink enabled, which will prelink the target image at image creation time. If this is enabled we want to avoid prelinking at first boot. We do this by setting the script exit status to '0' if we detect we're on the host. Also fixes a small bug found in sstate.bbclass: do_cleansstate The following changes since commit 8a5c20417d4d6bee6dd0bcdbeb8d4f9e0696a216: [PATCH] u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:12 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/prelink http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/prelink Mark Hatle (2): sstate.bbclass: Fix an issue if the config changes prelink_git.bb: Only block the postinst script when no image-prelink Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1][PULL] Upstream-Status update
On Wed, 2011-06-29 at 16:47 +0800, Dongxiao Xu wrote: Hi Saul, This pull request update some patch's Upstream-Status, please help to review and pull. Thanks, Dongxiao The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dxu4/patch-upstream http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/patch-upstream Dongxiao Xu (1): Upstream-Status: update the status for some patches Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] web-webkit: enable https web page accessing
On Wed, 2011-06-29 at 14:39 +0800, edwin.z...@intel.com wrote: From: Zhai Edwin edwin.z...@intel.com Let web-webkit RRECOMMENDS glib-networing for TLS support. The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib gzhai/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master Zhai Edwin (1): web-webkit: recommends glib-networking to access https web page Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1][PULL] Update manual check info in distro_checking_fields.inc
On Wed, 2011-06-29 at 14:09 +0800, Dongxiao Xu wrote: Hi Saul, This pull request update the manual check fields in distro_checking_fields.inc, Please help to review and pull. Thanks, Dongxiao The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dxu4/upgrade http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/upgrade Dongxiao Xu (1): distro_tracking: update some manual checking fields Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6 v4][PULL] 3G network support
On Wed, 2011-06-29 at 10:59 +0800, Dongxiao Xu wrote: Hi, This is the 4th version of 3G patches, please help to review and pull. Changes from v3: 1) Use DISTRO_FEATURE to handle the dependency of ofono. 2) Adopt ofono 0.50 version which could work with Ericsson modem. (ofono's commit d99ca17 fixed the crash issue) Thanks, Dongxiao The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dxu4/ggg-v4 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/ggg-v4 Dongxiao Xu (6): connman: Upgrade to version 0.75 wpa-supplicant: remove the 0.6.10 version. ofono: upgrade to version 0.50 connman-gnome: Add 3G configuration support initscript: Change some order of init scripts task-base: add 3G into DISTRO_FEATURE These look good to me, merged to masterm thanks! Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc-locale: fix localedef packaging
On Wed, 2011-06-29 at 14:36 +0100, Phil Blundell wrote: On Tue, 2011-06-28 at 22:32 +0200, Koen Kooi wrote: From http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yoctoid=0d0e14cda2ddd881d09798b0e6edd8086aa9b6d9 +libc6 - libc6_dev; So libc6 now depends on libc6-dev :( I guess it would be straightforward to patch insane.bbclass to detect that particular failure (which does indeed seem to happen to libc distressingly often). It already diagnoses the case where a package erroneously depends on a -dbg package, and I can't think of any reason why the same logic couldn't be applied to -dev. I'd love to see a patch for this! :) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] OE Changelog for 2011-06-20 to 2011-06-27
Changelog for 2011-06-20 to 2011-06-27. Projects included in this report: bitbake: git://git.openembedded.org/bitbake openembedded-core: git://git.openembedded.org/openembedded-core meta-openembedded: git://git.openembedded.org/meta-openembedded meta-angstrom: git://git.angstrom-distribution.org/meta-angstrom meta-yocto: git://git.yoctoproject.org/poky meta-texasinstruments: git://git.angstrom-distribution.org/meta-texasinstruments meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git meta-micro: git://git.openembedded.org/meta-micro meta-slugos: git://github.com/kraj/meta-slugos meta-nslu2: git://github.com/kraj/meta-nslu2 meta-intel: git://git.yoctoproject.org/meta-intel openembedded: git://git.openembedded.org/openembedded Changelog for bitbake: Brandon Stafford (1): doc/usermanual.xml: Tweaks for the manual Christopher Larson (2): msg: use a simpler enumeration for the domains msg: fix domain enum use Mark Hatle (1): runqueue.py: Add umask task control Scott Garman (1): fetch2/git.py: improve error reporting when an invalid protocol is used Changelog for openembedded-core: Beth Flanagan (1): common-licenses: Additions and corrections Bruce Ashfield (3): linux-yocto: update SRCREVs for utrace merge linux-yocto: update meta SRCREV for new config groups linux-yocto: update meta and yocto/standard SRCREVs Jiajun Xu (1): qemuimagetest: update cvs and iptables to newer version for toolchain test Khem Raj (10): gettext-0.18.1.1: Remove unused patches uclibc/x86_64/uClibc.machine: Enable ARCH_USE_MMU uclibc: Add support for $ORIGIN uclibc.inc: libsegfault is only RPROVIDED by uclibc binutils_2.21.bb: Fix ld segfault exposed by eglibc 2.14 on x86_64 eglibc-package.inc: Package newly added sotruss and supporting libraries eglibc: Upgrade recipes from 2.13 - 2.14 tcmode-default.inc: Bump EGLIBCVERSION to 2.14 gcc-4.6: Switch to using svn SRC_URI for recipe tcmode-default.inc: use 4.6 for GCCVERSION and SDKGCCVERSION Koen Kooi (4): gnome-keyring 2.32.1: fix packaging glib-2.0 2.28.x: update to 2.28.8 alsa-utils 1.0.24.2: fix packaging kernel.bbclass: restore kernel-abiversion file Mark Hatle (40): tinylogin: Avoid stripped binaries boost: Move the do_configure_prepend to a seperate task nasm: Fix aclocal dropbear: Don't patch in configure unzip: Avoid stripping binaries db: Avoid stripping binaries sysstat: Avoid stripping binaries quota: Avoid stripping binaries busybox: Avoid stripping binaries wireless-tools: Avoid stripping binaries libproxy: Add missing debug files gtk-sato-engine: Add missing debug files gstreamer: Add missing debug files. trace-cmd: Add missing debug files systemtamp: Add missing debug files gthumb: Add missing debug files gamin: Add missing debug files to -dbg mc: Add missing debug files to -dbg python-gst: Add missing files to the -dbg package liba52: Remove custom -dbg, fall back to default modutils: Add in missing -dbg package psmisc: Remove custom -dbg packages, use default texinfo: Change to use the standard -dbg file libxml-parser-perl: Fix debug package python-pyobject: Remove unnecessary -dbg setting python: Switch to using the default -dbg package classes/package_rpm.bbclass: Enhance diagnostic messages sysfsutils: Fall back to default -dbg package kernel.bbclass: Add support for perf-dbg package perf: Fix linux-tools to ensure perf is installed under fakeroot classes/package_rpm.bbclass: Change the way the PV is transformed native.bbclass: Add a simple chown intercept command resolveconf: Fix file owners base-passwd: Fix owners/groups ghostscript: Fix owner/group of /etc/cups libtirpc: Fix owner/group of /etc/netconfig tzdata: Ensure all files are owned by root:root gnome-doc-utils: Fix the owner/group on select files db: Fix file ownership python: Add python to the dependency to pygobject Paul Eggleton (4): u-boot: set SRCREV to a git revision instead of a tag reference qt4-tools-nativesdk: fix unpack failure due to missing g++.conf qt4-tools-nativesdk: drop freetype include as we build with -no-freetype qt4-tools-nativesdk: fix compile failure in src/dbus Richard Purdie (4): Revert tcmode-default.inc: Bump EGLIBCVERSION to 2.14 Revert eglibc: Upgrade recipes from 2.13 - 2.14 packagedata.py: Fix read_subpkgdata_dict() kernel.bbclass: Stop do_install poking directly into the sysroot and evading Tom Rini (1): kernel.bbclass: Stage System.map with KERNEL_VERSION suffix Xiaofeng Yan (1): task-core-lsb: Add absent libraries and commands to task-core-lsb.bb Zhai Edwin (2): gnome-vfs: remove gnome-vfs as it is deprecated in favour of GVFS and GIO clutter: Use new git repo Changelog for meta-openembedded: Khem Raj (1): gcc-4.6: Change the
Re: [OE-core] [PATCH 0/3] fix to bug #1099, updates to Upstream-Status and distro_tracking_fields.inc
On Wed, 2011-06-29 at 21:09 +0800, Dexuan Cui wrote: The following changes since commit a4f3e006e1f2fd93f156012af2a05adccf41d065: u-boot-mkimage: bump version to 2011.03 (2011-06-28 17:13:19 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (3): grub: add -fno-reorder-functions into STAGE2_COMPILE lttng-ust: change the patch's Upstream-Status to Accepted. distro_tracking_fields.inc: update RECIPE_MANUAL_CHECK_DATE for screen and tcf-agent Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] bump PR to fix the perl-native issue
On Wed, 2011-06-29 at 20:49 +0800, Cui, Dexuan wrote:
Cui, Dexuan wrote:
Cui, Dexuan wrote:
I did a core-image-sato-sdk and meta-toolchain-gmae building using a
commit of May 12 between 605141a9(the perl-native workaround patch)
and 3ba6d018(populate perl-native into its own dir), and grepped
${STAGING_BINDIR_NATIVE}/perl in
${STAGING_BINDIR_NATIVE} to find out all the scripts needed to
address. Some recipes' PRs have been bumped, so this patch only
bumps the omitted ones.
Please review the patch.
The following changes since commit
2163461ec94528ecf046a04edc5db3d2dd3a6b8b:
systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16
22:14:06 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dcui/bump_PR
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/bump_PR
Dexuan Cui (1):
glib-2.0,intltool,rpm,sgmlspl-native: Bump PR to resolve
perl-native issue
meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb |2 +-
meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb |2 +-
meta/recipes-devtools/intltool/intltool_0.40.6.bb |2 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb |2 +-
.../sgmlspl/sgmlspl-native_1.03ii.bb |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
(Sorry for my previous empty reply to this thead. I pressed enter too
hastily...)
Looks the patch was neglected somehow, either? :-)
It did seem to get missed, sorry. I've merged it.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-libc-headers: add 2.6.39
ping
Op 21 jun 2011, om 15:59 heeft Koen Kooi het volgende geschreven:
The 2.6.37.2 version is kept to allow the qemu kernels and libc headers
version to match
---
.../linux-libc-headers_2.6.39.bb | 49
1 files changed, 49 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.39.bb
diff --git
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.39.bb
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.39.bb
new file mode 100644
index 000..65c19ec
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.39.bb
@@ -0,0 +1,49 @@
+require linux-libc-headers.inc
+
+INHIBIT_DEFAULT_DEPS = 1
+DEPENDS += unifdef-native
+
+SRC_URI += file://connector-msg-size-fix.patch
+SRC_URI[md5sum] = 1aab7a741abe08d42e8eccf20de61e05
+SRC_URI[sha256sum] =
584d17f2a3ee18a9501d7ff36907639e538cfdba4529978b8550c461d45c61f6
+
+S = ${WORKDIR}/linux-${PV}
+
+set_arch() {
+ case ${TARGET_ARCH} in
+ alpha*) ARCH=alpha ;;
+ arm*) ARCH=arm ;;
+ cris*)ARCH=cris ;;
+ hppa*)ARCH=parisc ;;
+ i*86*)ARCH=i386 ;;
+ ia64*)ARCH=ia64 ;;
+ mips*)ARCH=mips ;;
+ m68k*)ARCH=m68k ;;
+ powerpc*) ARCH=powerpc ;;
+ s390*)ARCH=s390 ;;
+ sh*) ARCH=sh ;;
+ sparc64*) ARCH=sparc64 ;;
+ sparc*) ARCH=sparc ;;
+ x86_64*) ARCH=x86_64 ;;
+ avr32*) ARCH=avr32 ;;
+ bfin*)ARCH=blackfin ;;
+ microblaze*) ARCH=microblaze ;;
+ esac
+}
+
+do_configure() {
+ set_arch
+ oe_runmake allnoconfig ARCH=$ARCH
+}
+
+do_compile () {
+}
+
+do_install() {
+ set_arch
+ oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix}
ARCH=$ARCH
+ # Kernel should not be exporting this header
+ rm -f ${D}${exec_prefix}/include/scsi/scsi.h
+}
+
+BBCLASSEXTEND = nativesdk
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] grub: add -fno-reorder-functions into STAGE2_COMPILE
On Wed, 2011-06-29 at 14:20 +0100, Phil Blundell wrote: On Wed, 2011-06-29 at 21:09 +0800, Dexuan Cui wrote: +This turned out to be a gcc's bug. See +https://bugs.gentoo.org/show_bug.cgi?id=360513 +http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333 + +Upstream gcc seems uninterested in the bug, so at present we can disable the +option as a workaround. Thanks Ryan Hill for the investigation and the +workaround patch. I'm not sure it's fair to say that upstream gcc is uninterested. It doesn't appear that anybody has been willing or able to produce a testcase which will allow the gcc people to debug the problem. Agreed, it would be good if the gcc people could get a testcase to fix the problem. In the meantime I will take the workaround though. Cheers, RIchard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Gstreamer packaging
On Wed, 2011-06-29 at 12:08 +0100, Phil Blundell wrote: On Wed, 2011-06-29 at 11:53 +0100, Richard Purdie wrote: Obviously you can make the recipe depend on good+bad+ugly but its less than ideal for build time reasons (esp. when considering dependencies) but also the reason that good/bad/ugly exist in the first place which is licensing. If the recipe always has to depend on good+bad+ugly, it becomes rather tricky to disable ugly and work out whether the resulting configuration can build. Companies interested in license compliance do have a strong need to be able to do this. Incidentally, there isn't actually (as far as I can tell) anything in the current -ugly recipe which would indicate to an ENTERPRISE_DISTRO that this recipe is potentially problematic. Its LICENSE field just reads GPLv2+ LGPLv2.1+ LGPLv2+, which might or might not be accurate, and it doesn't appear to have the self-skipping behaviour which the corresponding recipe in oe.dev does. See conf/distro/include/default-distrovars.inc: # This is a list of packages that require a commercial license to ship # product. If shipped as part of an image these packages may have # implications so they are disabled by default COMMERCIAL_LICENSE ?= lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp COMMERCIAL_AUDIO_PLUGINS ?= # COMMERCIAL_AUDIO_PLUGINS ?= gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse COMMERCIAL_VIDEO_PLUGINS ?= # COMMERCIAL_VIDEO_PLUGINS ?= gst-plugins-ugly-mpeg2dec gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse COMMERCIAL_QT ?= # COMMERCIAL_QT ?= qmmp I agree we should like have this kind of information indicated at the recipe level though. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
Hi Saul,
I'm still not 100% sure this patch is the right way to go or not. Let me
ask some specific questions below.
On Tue, 2011-06-28 at 17:07 -0700, Saul Wold wrote:
This commit adds a new base package ${PN}-staticdev to
bitbake.conf which pulls in the static *.a libraries as
a seperate package, it filters out the nonshared.a
libraries where appropriate.
Additional this commit adds a new libdev.bbclass which provides
a set of macros and variables to convert ${PN} to lib${PN},
which a number of recipes where then converted to use.
PR bumps all around
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/lib_package.bbclass | 10 -
meta/classes/libdev.bbclass| 44
meta/conf/bitbake.conf |8 +++-
meta/recipes-bsp/pciutils/pciutils_3.1.7.bb|7 ++-
.../wireless-tools/wireless-tools_29.bb|9 +++-
meta/recipes-core/eglibc/eglibc-common.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|9 +++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb | 16
meta/recipes-core/glibc/glibc-package.inc |9 +++-
.../meta/external-csl-toolchain_2008q3-72.bb |8 ++-
meta/recipes-core/uclibc/uclibc.inc|9 +++-
meta/recipes-core/udev/udev-new.inc| 14 --
meta/recipes-core/udev/udev_164.bb |2 +-
meta/recipes-core/util-linux/util-linux.inc| 11 -
meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +-
.../binutils/binutils-cross-canadian_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils-cross.inc |2 +
.../binutils/binutils-cross_csl-arm-2008q1.bb |2 +-
.../binutils/binutils-crosssdk_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|9 +---
meta/recipes-devtools/binutils/binutils_2.21.bb|2 +-
meta/recipes-devtools/gcc/gcc-package-runtime.inc | 25 ---
meta/recipes-devtools/gcc/libgcc_4.6.bb|2 +-
meta/recipes-devtools/opkg/opkg_0.1.8.bb |8 ++-
meta/recipes-devtools/opkg/opkg_svn.bb |8 ++-
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 18
meta/recipes-extended/augeas/augeas.inc|7 +--
meta/recipes-extended/augeas/augeas_0.8.1.bb |2 +-
meta/recipes-extended/gamin/gamin_0.1.10.bb| 13 +-
.../tcp-wrappers/tcp-wrappers_7.6.bb |9 +++-
meta/recipes-graphics/cairo/cairo_1.10.2.bb|9 ++--
meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb |7 +--
meta/recipes-multimedia/liba52/liba52_0.7.4.bb |4 +-
meta/recipes-support/attr/acl_2.2.51.bb|2 +-
meta/recipes-support/attr/attr_2.4.46.bb |2 +-
meta/recipes-support/attr/ea-acl.inc | 16 +---
meta/recipes-support/curl/curl_7.21.6.bb | 17 +++-
meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb |5 +-
meta/recipes-support/sqlite/sqlite3.inc| 10 +
meta/recipes-support/sqlite/sqlite3_3.7.6.2.bb |2 +-
41 files changed, 203 insertions(+), 146 deletions(-)
create mode 100644 meta/classes/libdev.bbclass
diff --git a/meta/classes/lib_package.bbclass
b/meta/classes/lib_package.bbclass
index 5ce8727..e8cbc25 100644
--- a/meta/classes/lib_package.bbclass
+++ b/meta/classes/lib_package.bbclass
@@ -5,6 +5,12 @@ FILES_${PN} = ${libexecdir} ${libdir}/lib*${SOLIBS} \
${base_libdir}/*${SOLIBS} \
${datadir}/${PN} ${libdir}/${PN}
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
- ${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
- ${datadir}/aclocal ${bindir}/*-config
+${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
+${datadir}/aclocal ${bindir}/*-config \
+${libdir}/*_nonshared.a
FILES_${PN}-bin = ${bindir}/* ${sbindir}/* /bin/* /sbin/*
+
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a',
'${staticdev_libs}', d)}
As Phil says, I'm not sure this works and since the nonshared.a thing is
a *libc thing its probably not worth adding this complexity to the core
but just work putting it in the *libc packaging code.
diff --git a/meta/classes/libdev.bbclass b/meta/classes/libdev.bbclass
new file mode 100644
index 000..d0aac2f
--- /dev/null
+++ b/meta/classes/libdev.bbclass
@@ -0,0 +1,44 @@
+#
+# This bbclass it a common case for lib${PN}*.a static libraries
+#
+
+SUMMARY_lib${PN}-dbg ?= ${SUMMARY} - Debugging files
+DESCRIPTION_lib${PN}-dbg ?= ${DESCRIPTION} \
+This package contains ELF symbols and related sources for debugging
purposes.
+
+SUMMARY_lib${PN}-dev ?= ${SUMMARY} -
Re: [OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
On 06/29/2011 04:25 AM, Phil Blundell wrote:
On Tue, 2011-06-28 at 17:07 -0700, Saul Wold wrote:
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a', '${staticdev_libs}',
d)}
Does that actually work? I wouldn't have expected the pattern to get
globbed early enough for the oe_filter_out to have any effect.
Yes it does, I have tested it.
Sau!
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/7] useradd.bbclass: new class for managing user/group permissions
On Tue, 2011-06-28 at 09:42 -0500, Mark Hatle wrote:
On 6/28/11 8:04 AM, Richard Purdie wrote:
Hi Scott,
Sorry its taken me a while to get to this. Some comments below.
I think I know the answer to a few of the issues mentioned below. Scott can
correct me if I'm wrong.
On Thu, 2011-06-02 at 16:50 -0700, Scott Garman wrote:
This class is to be used by recipes that need to set up specific
user/group accounts and set custom file/directory permissions.
Signed-off-by: Scott Garman scott.a.gar...@intel.com
---
meta/classes/useradd.bbclass | 163
++
1 files changed, 163 insertions(+), 0 deletions(-)
create mode 100644 meta/classes/useradd.bbclass
diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
new file mode 100644
index 000..3f07e5e
--- /dev/null
+++ b/meta/classes/useradd.bbclass
@@ -0,0 +1,163 @@
+USERADDPN ?= ${PN}
+
+# base-passwd-cross provides the default passwd and group files in the
+# target sysroot, and shadow-native provides the utilities needed to
+# add and modify user and group accounts
+DEPENDS_append = base-passwd shadow-native
+RDEPENDS_${USERADDPN}_append = base-passwd shadow
+
+PSEUDO=${STAGING_DIR_NATIVE}/usr/bin/pseudo
+export PSEUDO
For reference this can be done with:
export PSEUDO = ${STAGING_DIR_NATIVE}/usr/bin/pseudo
+PSEUDO_LOCALSTATEDIR=${STAGING_DIR_TARGET}/var/pseudo
+export PSEUDO_LOCALSTATEDIR
I'm a little bit puzzled at this point. This is changing the default
PSEUDO state directory to be one shared by many other users rather than
the default of the one in workdir. Is that really what you intend here?
I guess the question is whether we need to preserve these users in the
sysroot or whether preserving them for the install/package/package_write
cycle is enough.
If we're populating the sysroot, we need to have a pseudo directory setup for
it
so that we can run the adduser/group items. The new adduser/group require the
ability to chroot into a (pseudo) root. The above should only kick in while
working with sysroots.
I understand this now. I still do have a concern about namespacing
though. I think alongside the existing code which does:
SYSROOT=${STAGING_DIR_TARGET}
OPT=--root ${STAGING_DIR_TARGET}
we should have these PSEUDO* exports, then they can't easily get
confused with the general pseudo environment we're using. Some comments
about what this is doing would also be useful as if I can't understand
this now, its likely in 3 months time its just going to be worse...
The way this is implemented the new sysroot tasks call the regular tasks so
the
code only has to be implemented once. Assuming context doesn't change, it
should be possible to move the PSEUDO calls down into the _sysroot functions
and remove them from the items that get embedded into the target packages.
I like this idea and I think it will be clearer whats going on,
particularly if we can do something like I mention above :)
+ pkgs = packages[0]
+
+ for pkg in pkgs.split():
+ param = bb.data.getVar(param_type % pkg, localdata, 1)
+ params.append(param)
+
+ return string.join(params, ; )
... it's not clear to me that any of the 'd' elements are changing. So
localdata may not actually be needed in any way. Either we should be
consistent
and use localdata everywhere or just 'd'. (Normally I use localdata when I'm
transforming the data in-place and using setVar... but I don't see that in
here.
Good catch, I think there should be more use of localdata here too.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] prelink_git.bb: Only block the postinst script when no image-prelink (v2)
Mark Hatle wrote:
[V2 - fix a small typo in the comment]
If image-prelink is being used, the system will automatically prelink
the target image. This avoids the need to run the postinst prelink
script at first boot. However, if the user has not enabled image
prelinking -- then we do enable the script to run on first boot.
# The cron script attempts to re-prelink the system daily -- on
@@ -58,11 +58,13 @@ do_install_append () {
install -m 0644 ${WORKDIR}/macros.prelink
${D}${sysconfdir}/rpm/macros.prelink }
+# If we're using image-prelink, we want to skip this on the host side
+# but still do it if the package is installed on the target...
pkg_postinst_prelink() {
#!/bin/sh
if [ x$D != x ]; then
- exit 1
+ ${@base_contains('USER_CLASSES', 'image-prelink', 'exit 0', 'exit
1', d)} fi
prelink -a
Even if without the patch, we still skip this on the host side -- previously we
skipped with exit 1, and with the patch now we skip with exit 1 or exit 0.
So IMHO looks the patch doesn't actually help? :-)
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] prelink_git.bb: Only block the postinst script when no image-prelink (v2)
On 6/29/11 9:42 AM, Phil Blundell wrote: On Wed, 2011-06-29 at 22:39 +0800, Cui, Dexuan wrote: Even if without the patch, we still skip this on the host side -- previously we skipped with exit 1, and with the patch now we skip with exit 1 or exit 0. So IMHO looks the patch doesn't actually help? :-) If the script exits with 0 in offline mode then it won't get rerun at first boot on the target. If it exits with 1 then it will. Yes. Since we've already run the equivalent of the script in the image-prelink, we can safely exit with a '0' telling the image preinst code that this was successfully run and to ignore it at first boot. --Mark p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] bitbake -b busted again?
Using bitbake master from today, I'm now getting this error whenever I try to do bitbake -b anything.bb: ERROR: Command execution failed: Traceback (most recent call last): File /home/pb/oe/bitbake/lib/bb/command.py, line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File /home/pb/oe/bitbake/lib/bb/command.py, line 190, in buildFile command.cooker.buildFile(bfile, task) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 792, in buildFile self.status.add_from_recipeinfo(fn, info_array) File /home/pb/oe/bitbake/lib/bb/cache.py, line 710, in add_from_recipeinfo info.add_cacheData(self, fn) File /home/pb/oe/bitbake/lib/bb/cache.py, line 182, in add_cacheData cachedata.task_deps[fn] = self.task_deps AttributeError: 'CoreRecipeInfo' object has no attribute 'task_deps' p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] prelink_git.bb: Only block the postinst script when no image-prelink (v2)
Mark Hatle wrote: On 6/29/11 9:42 AM, Phil Blundell wrote: On Wed, 2011-06-29 at 22:39 +0800, Cui, Dexuan wrote: Even if without the patch, we still skip this on the host side -- previously we skipped with exit 1, and with the patch now we skip with exit 1 or exit 0. So IMHO looks the patch doesn't actually help? :-) If the script exits with 0 in offline mode then it won't get rerun at first boot on the target. If it exits with 1 then it will. Yes. Since we've already run the equivalent of the script in the image-prelink, we can safely exit with a '0' telling the image preinst code that this was successfully run and to ignore it at first boot. Ok, got it! Thanks very much for the explanation! Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] bitbake -b busted again?
On Wed, 2011-06-29 at 15:48 +0100, Phil Blundell wrote: Using bitbake master from today, I'm now getting this error whenever I try to do bitbake -b anything.bb: Actually, it looks like I was just unlucky/unskilled in my choice of recipes when I tested. It does in fact work for at least some files; there must be something about the ones I was trying to begin with that is upsetting it. I'll investigate further. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] bitbake -b busted again?
On Wed, 2011-06-29 at 16:55 +0200, Koen Kooi wrote:
Op 29 jun 2011, om 16:54 heeft Phil Blundell het volgende geschreven:
On Wed, 2011-06-29 at 15:48 +0100, Phil Blundell wrote:
Using bitbake master from today, I'm now getting this error whenever I
try to do bitbake -b anything.bb:
Actually, it looks like I was just unlucky/unskilled in my choice of
recipes when I tested. It does in fact work for at least some files;
there must be something about the ones I was trying to begin with that
is upsetting it. I'll investigate further.
Try bitbake -b /full/path/to/recipe, that seems to make things work for me.
It seems that the main problem I was having was that (coincidentally in
light of the earlier gst discussion) the recipe I was trying to build
was unluckily named and being skipped because base.bbclass thought I
wasn't licensed to use it.
The code which detects commerciality is somewhat simple-minded and just
does a straight regex search for ${PN} within ${COMMERCIAL_LICENSE}, so
if your recipe happens to be called fmp (for example) it will match
against ffmpeg and you will lose.
I think this has probably just started to bite me because I recently
started using default-distrovars.inc. Possibly that was a dim plan on
my part.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] bitbake -b busted again?
On Wed, 2011-06-29 at 16:07 +0100, Phil Blundell wrote: It seems that the main problem I was having was that (coincidentally in light of the earlier gst discussion) the recipe I was trying to build was unluckily named and being skipped because base.bbclass thought I wasn't licensed to use it. Also, it does seem that bitbake -e -b ... really is broken. I get: ERROR: Command execution failed: Traceback (most recent call last): File /home/pb/oe/bitbake/lib/bb/command.py, line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File /home/pb/oe/bitbake/lib/bb/command.py, line 272, in showEnvironment command.cooker.showEnvironment(bfile) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 259, in showEnvironment fn = self.matchFile(buildfile) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 753, in matchFile matches = self.matchFiles(buildfile) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 736, in matchFiles filelist, masked = self.collect_bbfiles() File /home/pb/oe/bitbake/lib/bb/cooker.py, line 997, in collect_bbfiles files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 997, in lambda files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 463, in calc_bbfile_priority for _, _, regex, pri in self.status.bbfile_config_priorities: AttributeError: 'NoneType' object has no attribute 'bbfile_config_priorities' Using an absolute path to the .bb file doesn't seem to help in this case, and I also verified that it does build successfully without the -e. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] In which meta/layer is a home for not yet supported machines
Hi, just started to collect first oe-core experiences and would like to get the hardware on my (or friend's) desk supported. To check already available I did find -name *.conf | grep machine and miss o gumstix overo ( http://www.gumstix.com/store/index.php?cPath=33 ) o tx28 ( http://www.karo-electronics.com/tx28.html / have prepared support for oe but would like to get this to oe-core ) o mx28evk ( http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCIMX28EVKJfr=g ) In which meta/layer is the first place for configurations/bootloader/kernels? Regards Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] In which meta/layer is a home for not yet supported machines
On Wed, Jun 29, 2011 at 8:28 AM, Andreas Mueller schnitzelt...@gmx.de wrote: Hi, just started to collect first oe-core experiences and would like to get the hardware on my (or friend's) desk supported. To check already available I did find -name *.conf | grep machine and miss o gumstix overo ( http://www.gumstix.com/store/index.php?cPath=33 ) o tx28 ( http://www.karo-electronics.com/tx28.html / have prepared support for oe but would like to get this to oe-core ) o mx28evk ( http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCIMX28EVKJfr=g ) In which meta/layer is the first place for configurations/bootloader/kernels? you would need meta layer for the new machines. There already are some layers checkout angstrom if the machines do not fit into those existing you can create a new layer something like meta-gumstix Regards Andreas ___ Openembedded-devel mailing list openembedded-de...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Khem Raj wrote: On 06/28/2011 04:07 AM, Paul Eggleton wrote: On Tuesday 28 June 2011 07:45:09 Koen Kooi wrote: So it works as expected, but the output is a bit confusing. I have a few (conflicting) suggestions: 1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.: meta-archos branch = master meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad 2) for the extra layers put branch and revision on a single line: meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad I'd go with option 2 over 1, personally - the list gets rather long on something like Angstrom, better to keep it short. I would say to do it uniformly and treat oe-core as one of layers too when emitting this info Ok. I'll make a new version for this. BTW: meta and mete-yocto belong to the same git repo actually, so do you think showing them in one line like this meta,meta-yocto = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 is better than showing 2 lines like this: meta = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 meta-yocto= master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 ? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Op 29 jun 2011, om 18:14 heeft Cui, Dexuan het volgende geschreven: Khem Raj wrote: On 06/28/2011 04:07 AM, Paul Eggleton wrote: On Tuesday 28 June 2011 07:45:09 Koen Kooi wrote: So it works as expected, but the output is a bit confusing. I have a few (conflicting) suggestions: 1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.: meta-archos branch = master meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad 2) for the extra layers put branch and revision on a single line: meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad I'd go with option 2 over 1, personally - the list gets rather long on something like Angstrom, better to keep it short. I would say to do it uniformly and treat oe-core as one of layers too when emitting this info Ok. I'll make a new version for this. BTW: meta and mete-yocto belong to the same git repo actually, so do you think showing them in one line like this meta,meta-yocto = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 is better than showing 2 lines like this: meta = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 meta-yocto= master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 That breaks with repos like meta-intel and meta-oe. Maybe something like this: BB_VERSION = 1.13.2 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = archosa32 DISTRO = angstrom DISTRO_VERSION = v2011.06-core TARGET_FPU = hard METADATA_BRANCH = master METADATA_REVISION = 16f84804cfbe472833ff00bfd2694947eabf8e20 meta-angstrom = master:fd68a073e9669fdee0a9dc0483b3d39d3e3e0b46 meta-oe = master:8a12ecca32766ecdceb72cae76e93f8aadcf3669 meta-eflsame meta-gpesame meta-gnome same meta-texasinstruments = master:2e16e2fbd93bc00bc0a0afaf86975da7778eaa43 meta-efikamx= master:70cff8742d629fd32463e3ef1bddb83f04d08dc5 meta-nslu2 = master:aaf918b85d7a8155d6e7c0ff042808346998fbea meta-htc= master:f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-nokia same meta-openmoko same meta-palm same meta-zaurus same meta-sugarbay = master:50661bf038a34702f3aa139c3ea0d67fbb0ce5db meta-crownbay same meta-emenlowsame meta-fishriver same meta-jasperforest same meta-n450 same meta-ettus = master:c34c30fa29f7ab484cc90efb9713325da8e01460 meta-openpandora= master:edaf6e751f873ed7a82c1116d3d58b9a070052dc meta-archos = master:4b689944d968b0ef4d0e9928e76c54f8a76a919a regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
On 06/29/2011 07:18 AM, Richard Purdie wrote:
Hi Saul,
I'm still not 100% sure this patch is the right way to go or not. Let me
ask some specific questions below.
On Tue, 2011-06-28 at 17:07 -0700, Saul Wold wrote:
This commit adds a new base package ${PN}-staticdev to
bitbake.conf which pulls in the static *.a libraries as
a seperate package, it filters out the nonshared.a
libraries where appropriate.
Additional this commit adds a new libdev.bbclass which provides
a set of macros and variables to convert ${PN} to lib${PN},
which a number of recipes where then converted to use.
PR bumps all around
Signed-off-by: Saul Wolds...@linux.intel.com
---
meta/classes/lib_package.bbclass | 10 -
meta/classes/libdev.bbclass| 44
meta/conf/bitbake.conf |8 +++-
meta/recipes-bsp/pciutils/pciutils_3.1.7.bb|7 ++-
.../wireless-tools/wireless-tools_29.bb|9 +++-
meta/recipes-core/eglibc/eglibc-common.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|9 +++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb | 16
meta/recipes-core/glibc/glibc-package.inc |9 +++-
.../meta/external-csl-toolchain_2008q3-72.bb |8 ++-
meta/recipes-core/uclibc/uclibc.inc|9 +++-
meta/recipes-core/udev/udev-new.inc| 14 --
meta/recipes-core/udev/udev_164.bb |2 +-
meta/recipes-core/util-linux/util-linux.inc| 11 -
meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +-
.../binutils/binutils-cross-canadian_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils-cross.inc |2 +
.../binutils/binutils-cross_csl-arm-2008q1.bb |2 +-
.../binutils/binutils-crosssdk_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|9 +---
meta/recipes-devtools/binutils/binutils_2.21.bb|2 +-
meta/recipes-devtools/gcc/gcc-package-runtime.inc | 25 ---
meta/recipes-devtools/gcc/libgcc_4.6.bb|2 +-
meta/recipes-devtools/opkg/opkg_0.1.8.bb |8 ++-
meta/recipes-devtools/opkg/opkg_svn.bb |8 ++-
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 18
meta/recipes-extended/augeas/augeas.inc|7 +--
meta/recipes-extended/augeas/augeas_0.8.1.bb |2 +-
meta/recipes-extended/gamin/gamin_0.1.10.bb| 13 +-
.../tcp-wrappers/tcp-wrappers_7.6.bb |9 +++-
meta/recipes-graphics/cairo/cairo_1.10.2.bb|9 ++--
meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb |7 +--
meta/recipes-multimedia/liba52/liba52_0.7.4.bb |4 +-
meta/recipes-support/attr/acl_2.2.51.bb|2 +-
meta/recipes-support/attr/attr_2.4.46.bb |2 +-
meta/recipes-support/attr/ea-acl.inc | 16 +---
meta/recipes-support/curl/curl_7.21.6.bb | 17 +++-
meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb |5 +-
meta/recipes-support/sqlite/sqlite3.inc| 10 +
meta/recipes-support/sqlite/sqlite3_3.7.6.2.bb |2 +-
41 files changed, 203 insertions(+), 146 deletions(-)
create mode 100644 meta/classes/libdev.bbclass
diff --git a/meta/classes/lib_package.bbclass b/meta/classes/lib_package.bbclass
index 5ce8727..e8cbc25 100644
--- a/meta/classes/lib_package.bbclass
+++ b/meta/classes/lib_package.bbclass
@@ -5,6 +5,12 @@ FILES_${PN} = ${libexecdir} ${libdir}/lib*${SOLIBS} \
${base_libdir}/*${SOLIBS} \
${datadir}/${PN} ${libdir}/${PN}
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
- ${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
- ${datadir}/aclocal ${bindir}/*-config
+${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
+${datadir}/aclocal ${bindir}/*-config \
+${libdir}/*_nonshared.a
FILES_${PN}-bin = ${bindir}/* ${sbindir}/* /bin/* /sbin/*
+
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a', '${staticdev_libs}',
d)}
As Phil says, I'm not sure this works and since the nonshared.a thing is
a *libc thing its probably not worth adding this complexity to the core
but just work putting it in the *libc packaging code.
I have tested this and it works, after reviewing this further, I will
move this to handled by the specific cases that need, rather than being
a general solution in bitbake.conf
diff --git a/meta/classes/libdev.bbclass b/meta/classes/libdev.bbclass
new file mode 100644
index 000..d0aac2f
--- /dev/null
+++ b/meta/classes/libdev.bbclass
@@ -0,0 +1,44 @@
+#
+# This bbclass it a common case for lib${PN}*.a static libraries
+#
+
+SUMMARY_lib${PN}-dbg ?=
Re: [OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
Op 29 jun 2011, om 18:23 heeft Saul Wold het volgende geschreven:
On 06/29/2011 07:18 AM, Richard Purdie wrote:
Hi Saul,
I'm still not 100% sure this patch is the right way to go or not. Let me
ask some specific questions below.
On Tue, 2011-06-28 at 17:07 -0700, Saul Wold wrote:
This commit adds a new base package ${PN}-staticdev to
bitbake.conf which pulls in the static *.a libraries as
a seperate package, it filters out the nonshared.a
libraries where appropriate.
Additional this commit adds a new libdev.bbclass which provides
a set of macros and variables to convert ${PN} to lib${PN},
which a number of recipes where then converted to use.
PR bumps all around
Signed-off-by: Saul Wolds...@linux.intel.com
---
meta/classes/lib_package.bbclass | 10 -
meta/classes/libdev.bbclass| 44
meta/conf/bitbake.conf |8 +++-
meta/recipes-bsp/pciutils/pciutils_3.1.7.bb|7 ++-
.../wireless-tools/wireless-tools_29.bb|9 +++-
meta/recipes-core/eglibc/eglibc-common.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|9 +++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb | 16
meta/recipes-core/glibc/glibc-package.inc |9 +++-
.../meta/external-csl-toolchain_2008q3-72.bb |8 ++-
meta/recipes-core/uclibc/uclibc.inc|9 +++-
meta/recipes-core/udev/udev-new.inc| 14 --
meta/recipes-core/udev/udev_164.bb |2 +-
meta/recipes-core/util-linux/util-linux.inc| 11 -
meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +-
.../binutils/binutils-cross-canadian_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils-cross.inc |2 +
.../binutils/binutils-cross_csl-arm-2008q1.bb |2 +-
.../binutils/binutils-crosssdk_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|9 +---
meta/recipes-devtools/binutils/binutils_2.21.bb|2 +-
meta/recipes-devtools/gcc/gcc-package-runtime.inc | 25 ---
meta/recipes-devtools/gcc/libgcc_4.6.bb|2 +-
meta/recipes-devtools/opkg/opkg_0.1.8.bb |8 ++-
meta/recipes-devtools/opkg/opkg_svn.bb |8 ++-
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 18
meta/recipes-extended/augeas/augeas.inc|7 +--
meta/recipes-extended/augeas/augeas_0.8.1.bb |2 +-
meta/recipes-extended/gamin/gamin_0.1.10.bb| 13 +-
.../tcp-wrappers/tcp-wrappers_7.6.bb |9 +++-
meta/recipes-graphics/cairo/cairo_1.10.2.bb|9 ++--
meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb |7 +--
meta/recipes-multimedia/liba52/liba52_0.7.4.bb |4 +-
meta/recipes-support/attr/acl_2.2.51.bb|2 +-
meta/recipes-support/attr/attr_2.4.46.bb |2 +-
meta/recipes-support/attr/ea-acl.inc | 16 +---
meta/recipes-support/curl/curl_7.21.6.bb | 17 +++-
meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb |5 +-
meta/recipes-support/sqlite/sqlite3.inc| 10 +
meta/recipes-support/sqlite/sqlite3_3.7.6.2.bb |2 +-
41 files changed, 203 insertions(+), 146 deletions(-)
create mode 100644 meta/classes/libdev.bbclass
diff --git a/meta/classes/lib_package.bbclass
b/meta/classes/lib_package.bbclass
index 5ce8727..e8cbc25 100644
--- a/meta/classes/lib_package.bbclass
+++ b/meta/classes/lib_package.bbclass
@@ -5,6 +5,12 @@ FILES_${PN} = ${libexecdir} ${libdir}/lib*${SOLIBS} \
${base_libdir}/*${SOLIBS} \
${datadir}/${PN} ${libdir}/${PN}
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la
\
- ${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
- ${datadir}/aclocal ${bindir}/*-config
+${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
+${datadir}/aclocal ${bindir}/*-config \
+${libdir}/*_nonshared.a
FILES_${PN}-bin = ${bindir}/* ${sbindir}/* /bin/* /sbin/*
+
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a',
'${staticdev_libs}', d)}
As Phil says, I'm not sure this works and since the nonshared.a thing is
a *libc thing its probably not worth adding this complexity to the core
but just work putting it in the *libc packaging code.
I have tested this and it works, after reviewing this further, I will move
this to handled by the specific cases that need, rather than being a general
solution in bitbake.conf
diff --git a/meta/classes/libdev.bbclass b/meta/classes/libdev.bbclass
new file mode 100644
index 000..d0aac2f
--- /dev/null
+++ b/meta/classes/libdev.bbclass
@@ -0,0 +1,44 @@
[OE-core] meta-toolchain issues. Unsatisfied dependencies, eglic, eglibc-dev
Prior to Koen's patch libc locale split: fix some remaining problems I was getting the same issue but with libc6 and particular versions. I'm guessing this is more fallout from the same issue Koen found? Relevant chunk of log is (during populate_sdk) is: | Downloading file:/home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/deploy/ipk/armv7a/task-core-standalone-sdk-target_1.0-r6_armv7a.ipk. | libc6-dev: unsatisfied recommendation for eglibc-thread-db-dev | libc6-dev: unsatisfied recommendation for eglibc-gconv-libgb-dev | libc6-dev: unsatisfied recommendation for eglibc-gconv-libksc-dev | libc6-dev: unsatisfied recommendation for eglibc-gconv-libjis-dev | libc6-dev: unsatisfied recommendation for eglibc-gconv-libjisx0213-dev | libc6-dev: unsatisfied recommendation for libsegfault-dev | libc6-dev: unsatisfied recommendation for eglibc-gconv-libcns-dev | libc6-dev: unsatisfied recommendation for eglibc-gconv-libisoir165-dev | libc6-dev: unsatisfied recommendation for eglibc-extra-nss-dev | libc6-dev: unsatisfied recommendation for libcidn-dev | eglibc-dbg: unsatisfied recommendation for libsegfault-dbg | eglibc-dbg: unsatisfied recommendation for eglibc-gconv-libjis-dbg | eglibc-dbg: unsatisfied recommendation for eglibc-gconv-libksc-dbg | eglibc-dbg: unsatisfied recommendation for eglibc-gconv-libgb-dbg | eglibc-dbg: unsatisfied recommendation for eglibc-thread-db-dbg | eglibc-dbg: unsatisfied recommendation for eglibc-extra-nss-dbg | eglibc-dbg: unsatisfied recommendation for eglibc-gconv-libisoir165-dbg | eglibc-dbg: unsatisfied recommendation for eglibc-gconv-libjisx0213-dbg | eglibc-dbg: unsatisfied recommendation for libgcc-dbg | eglibc-dbg: unsatisfied recommendation for eglibc-gconv-libcns-dbg | eglibc-dbg: unsatisfied recommendation for libcidn-dbg | Installing task-core-standalone-sdk-target-dbg (1.0-r6) to root... | Downloading file:/home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/deploy/ipk/armv7a/task-core-standalone-sdk-target-dbg_1.0-r6_armv7a.ipk. | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for libsegfault-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for libstdc++-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for eglibc-thread-db-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for locale-base-en-us-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for eglibc-localedata-i18n-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for eglibc-utils-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for eglibc-gconv-ibm850-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for eglibc-gconv-iso8859-15-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for eglibc-gconv-cp1252-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for libgcc-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for eglibc-gconv-iso8859-1-dbg | task-core-standalone-sdk-target-dbg: unsatisfied recommendation for locale-base-en-gb-dbg | Installing task-core-standalone-sdk-target (1.0-r6) to root... | Installing eglibc-dbg (2.12-r17) to root... | Downloading file:/home/jic23/src/beagle/setup-scripts/build/tmp-angstrom_2010_x-eglibc/deploy/ipk/armv7a/eglibc-dbg_2.12-r17_armv7a.ipk. | Configuring eglibc-dbg. | Configuring task-core-standalone-sdk-target. | Configuring task-core-standalone-sdk-target-dbg. | Collected errors: | * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-core-standalone-sdk-target: | *eglibc *eglibc-dev * | * opkg_install_cmd: Cannot install package task-core-standalone-sdk-target. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
On Wed, 2011-06-29 at 07:22 -0700, Saul Wold wrote:
On 06/29/2011 04:25 AM, Phil Blundell wrote:
On Tue, 2011-06-28 at 17:07 -0700, Saul Wold wrote:
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a',
'${staticdev_libs}', d)}
Does that actually work? I wouldn't have expected the pattern to get
globbed early enough for the oe_filter_out to have any effect.
Yes it does, I have tested it.
That's interesting. Do you know where the glob is taking place? I
thought it didn't happen until after FILES was expanded and split inside
populate_packages.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Koen Kooi wrote: Op 29 jun 2011, om 18:14 heeft Cui, Dexuan het volgende geschreven: Khem Raj wrote: On 06/28/2011 04:07 AM, Paul Eggleton wrote: On Tuesday 28 June 2011 07:45:09 Koen Kooi wrote: BTW: meta and mete-yocto belong to the same git repo actually, so do you think showing them in one line like this meta,meta-yocto = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 is better than showing 2 lines like this: meta = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 meta-yocto= master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 That breaks with repos like meta-intel and meta-oe. Maybe something Could you please explain a bit more? like this: METADATA_BRANCH = master METADATA_REVISION = 16f84804cfbe472833ff00bfd2694947eabf8e20 meta-angstrom = master:fd68a073e9669fdee0a9dc0483b3d39d3e3e0b46 meta-oe = master:8a12ecca32766ecdceb72cae76e93f8aadcf3669 meta-efl same meta-gpe same meta-gnome same meta-texasinstruments = master:2e16e2fbd93bc00bc0a0afaf86975da7778eaa43 meta-efikamx = master:70cff8742d629fd32463e3ef1bddb83f04d08dc5 meta-nslu2 = master:aaf918b85d7a8155d6e7c0ff042808346998fbea meta-htc = master:f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-nokia same meta-openmoko same meta-palm same meta-zaurus same meta-sugarbay = master:50661bf038a34702f3aa139c3ea0d67fbb0ce5db meta-crownbay same meta-emenlowsame meta-fishriver same meta-jasperforest same meta-n450 same meta-ettus = master:c34c30fa29f7ab484cc90efb9713325da8e01460 meta-openpandora = master:edaf6e751f873ed7a82c1116d3d58b9a070052dc meta-archos = master:4b689944d968b0ef4d0e9928e76c54f8a76a919a I think the below is a better format(but the line may be too long?)? meta,meta-yocto = master:16f84804cfbe472833ff00bfd2694947eabf8e20 meta-angstrom = master:fd68a073e9669fdee0a9dc0483b3d39d3e3e0b46 meta-oe,meta-efl,meta-gpe,meta-gnome = master:8a12ecca32766ecdceb72cae76e93f8aadcf3669 meta-texasinstruments = master:2e16e2fbd93bc00bc0a0afaf86975da7778eaa43 meta-efikamx= master:70cff8742d629fd32463e3ef1bddb83f04d08dc5 meta-nslu2 = master:aaf918b85d7a8155d6e7c0ff042808346998fbea meta-htc,meta-nokia,meta-openmoko,meta-palm,meta,zaurus = master:f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-sugarbay,meta-crownbay,meta-emenlow,meta-fishriver,meta-jasperforest,meta-n450, = master:50661bf038a34702f3aa139c3ea0d67fbb0ce5db meta-ettus = master:c34c30fa29f7ab484cc90efb9713325da8e01460 meta-openpandora= master:edaf6e751f873ed7a82c1116d3d58b9a070052dc meta-archos = master:4b689944d968b0ef4d0e9928e76c54f8a76a919a Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)
On 06/29/2011 01:56 AM, Koen Kooi wrote: Op 29 jun 2011, om 10:50 heeft Anders Darander het volgende geschreven: On Wed, Jun 29, 2011 at 10:24, Koen Kooik...@dominion.thruhere.net wrote: Op 29 jun 2011, om 00:41 heeft Khem Raj het volgende geschreven: If they are independent then may be the openssh recipe should be divided into openssh-ssh and openssh-rest so one can use openssh provided daemon or dropbear provided as they wish Dividing the openssl recipe would gain us little and the gains would be only for the power companies since you'd have to build openssh twice to get both sftp and ssh. The decrease in build time for only sftp is neglible. Hm, speaking against what I've often been advocating (reducing build time by factoring out dependenies etc)... I think the simplest and most straightforward solution is to just split the packaging into openssh-ssh and openssh-sftp, where openssh-sftp packages just what is needed for handling the sftp-server in cooperation with dropbear. It could possibly also include the sftp-client if desired/needed. That's already the case now. The problem is the PROVIDES overlap since the Poky people decided a distro could only have one true ssh implementation instead of choosing it per image. So if your distro doesn't set the PREFERRED_PROVIDER_sshd you get those nagging messages during parsing that scare users and make consultants rich. OE .dev isn't a lot better with the misguided DISTRO_SSH_DAEMON, but at least it doesn't show those nag messages. It's worth noting that one of the things I got into master just after Yocto 1.0 shipped was a refactoring of how ssh servers were specified. It no longer is a distro choice - we have task-core-ssh-openssh and task-core-ssh-dropbear that you add to IMAGE_FEATURES for your desired image. Which makes me wonder what the consequences would be to simply remove the PROVIDES from the dropbear and openssh recipes? Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
On 06/29/2011 09:26 AM, Koen Kooi wrote:
Op 29 jun 2011, om 18:23 heeft Saul Wold het volgende geschreven:
On 06/29/2011 07:18 AM, Richard Purdie wrote:
Hi Saul,
I'm still not 100% sure this patch is the right way to go or not. Let me
ask some specific questions below.
On Tue, 2011-06-28 at 17:07 -0700, Saul Wold wrote:
This commit adds a new base package ${PN}-staticdev to
bitbake.conf which pulls in the static *.a libraries as
a seperate package, it filters out the nonshared.a
libraries where appropriate.
Additional this commit adds a new libdev.bbclass which provides
a set of macros and variables to convert ${PN} to lib${PN},
which a number of recipes where then converted to use.
PR bumps all around
Signed-off-by: Saul Wolds...@linux.intel.com
---
meta/classes/lib_package.bbclass | 10 -
meta/classes/libdev.bbclass| 44
meta/conf/bitbake.conf |8 +++-
meta/recipes-bsp/pciutils/pciutils_3.1.7.bb|7 ++-
.../wireless-tools/wireless-tools_29.bb|9 +++-
meta/recipes-core/eglibc/eglibc-common.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|9 +++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb | 16
meta/recipes-core/glibc/glibc-package.inc |9 +++-
.../meta/external-csl-toolchain_2008q3-72.bb |8 ++-
meta/recipes-core/uclibc/uclibc.inc|9 +++-
meta/recipes-core/udev/udev-new.inc| 14 --
meta/recipes-core/udev/udev_164.bb |2 +-
meta/recipes-core/util-linux/util-linux.inc| 11 -
meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +-
.../binutils/binutils-cross-canadian_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils-cross.inc |2 +
.../binutils/binutils-cross_csl-arm-2008q1.bb |2 +-
.../binutils/binutils-crosssdk_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|9 +---
meta/recipes-devtools/binutils/binutils_2.21.bb|2 +-
meta/recipes-devtools/gcc/gcc-package-runtime.inc | 25 ---
meta/recipes-devtools/gcc/libgcc_4.6.bb|2 +-
meta/recipes-devtools/opkg/opkg_0.1.8.bb |8 ++-
meta/recipes-devtools/opkg/opkg_svn.bb |8 ++-
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 18
meta/recipes-extended/augeas/augeas.inc|7 +--
meta/recipes-extended/augeas/augeas_0.8.1.bb |2 +-
meta/recipes-extended/gamin/gamin_0.1.10.bb| 13 +-
.../tcp-wrappers/tcp-wrappers_7.6.bb |9 +++-
meta/recipes-graphics/cairo/cairo_1.10.2.bb|9 ++--
meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb |7 +--
meta/recipes-multimedia/liba52/liba52_0.7.4.bb |4 +-
meta/recipes-support/attr/acl_2.2.51.bb|2 +-
meta/recipes-support/attr/attr_2.4.46.bb |2 +-
meta/recipes-support/attr/ea-acl.inc | 16 +---
meta/recipes-support/curl/curl_7.21.6.bb | 17 +++-
meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb |5 +-
meta/recipes-support/sqlite/sqlite3.inc| 10 +
meta/recipes-support/sqlite/sqlite3_3.7.6.2.bb |2 +-
41 files changed, 203 insertions(+), 146 deletions(-)
create mode 100644 meta/classes/libdev.bbclass
diff --git a/meta/classes/lib_package.bbclass b/meta/classes/lib_package.bbclass
index 5ce8727..e8cbc25 100644
--- a/meta/classes/lib_package.bbclass
+++ b/meta/classes/lib_package.bbclass
@@ -5,6 +5,12 @@ FILES_${PN} = ${libexecdir} ${libdir}/lib*${SOLIBS} \
${base_libdir}/*${SOLIBS} \
${datadir}/${PN} ${libdir}/${PN}
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
- ${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
- ${datadir}/aclocal ${bindir}/*-config
+${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
+${datadir}/aclocal ${bindir}/*-config \
+${libdir}/*_nonshared.a
FILES_${PN}-bin = ${bindir}/* ${sbindir}/* /bin/* /sbin/*
+
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a', '${staticdev_libs}',
d)}
As Phil says, I'm not sure this works and since the nonshared.a thing is
a *libc thing its probably not worth adding this complexity to the core
but just work putting it in the *libc packaging code.
I have tested this and it works, after reviewing this further, I will move this
to handled by the specific cases that need, rather than being a general
solution in bitbake.conf
diff --git a/meta/classes/libdev.bbclass b/meta/classes/libdev.bbclass
new file mode 100644
index 000..d0aac2f
--- /dev/null
+++ b/meta/classes/libdev.bbclass
@@ -0,0
[OE-core] [RFC v3 PATCH 0/9] Linux 3.0 build support
v3: - task-base.bb: fix a problem that *pcmia26 couldn't be found.
v2: Probably some more patches could be squashed together. There might also
be more places that should be addressed in these patches.
- Whitespace fixes
- Updated module-init-tools to 3.16. I'm not applying the ignore*.patch
(it didn't apply).
- Do not provide virtual/*/depmod-2.6; just provide virtual/*/depmod.
- Do only install as depmod.
- Rearrange the order of some patches.
- Added patches to clean up (partly) task-base, distro_tracking_fields.
A few of the patches might be ready to pull, but the majority will need
to be revised.
===
This work is unfinished and incomplete...
It is published in its current form both to get feedback, but also to aid
anyone else who is working on 3.0-support. If some of the patches are found to
be OK, it's fine to cherrypick them.
The kernel-related classes has been modified to build a 3.0 kernel. The
patches has been simplified by removing support for the 2.4-series. (The
latter was suggested in an older mail thread:
http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg02682.html
).
The patches has been tested on linux-yocto_2.6.37 and a hacked version using
the linux-yocto-dev repository (using a 3.0-rcX). The latest versions has only
been built for qemuarm, prior iterations has also been built for qemux86.
Finally, no work has been done on the libc-linux-headers classes and recipes.
/Anders
Please review the following changes for suitability for inclusion. If you have
any objections or suggestions for improvement, please respond to the patches. If
you agree with the changes, please provide your Acked-by.
The following changes since commit ff014d9634638457622f6019b163e75bafcefada:
task-base: add 3G into DISTRO_FEATURE (2011-06-29 14:46:46 +0100)
are available in the git repository at:
git://github.com/darander/oe-core kernel-3.0
https://github.com/darander/oe-core/tree/kernel-3.0
Anders Darander (9):
Remove support for building 2.4 kernels
image¡kernel.bblass: do not use depmod-2.6
modules-init-tools(-cross): update to 3.16
module-init-tools-cross: do not install depmod as depmod-2.6
kernel.bblass: remove get_kernelmajorversion
modutils-initscripts: move recipe prior to modutils removal
modutils: remove modutils
task-base: remove modutils reference.
distro_tracking_fields: remove modutils.
meta/classes/image.bbclass |2 +-
meta/classes/kernel.bbclass| 22 ++
meta/classes/linux-kernel-base.bbclass |8 --
meta/classes/module-base.bbclass |2 +-
.../conf/distro/include/distro_tracking_fields.inc |8 +--
meta/recipes-core/tasks/task-base.bb | 24 +
.../{modutils = module-init-tools}/files/PD.patch |0
.../files/modutils.sh |0
.../module-init-tools-cross_3.12.bb| 12 ---
.../module-init-tools-cross_3.16.bb|8 ++
.../module-init-tools/module-init-tools.inc|1 -
...nit-tools_3.12.bb = module-init-tools_3.16.bb} |6 +-
.../modutils-initscripts.bb|0
meta/recipes-kernel/modutils/files/armeb.patch | 16
meta/recipes-kernel/modutils/files/configure.patch | 34 ---
meta/recipes-kernel/modutils/files/gcc4.patch | 93
meta/recipes-kernel/modutils/files/lex.l.diff | 35
.../modutils/files/modutils-notest.patch | 16
.../modutils/files/program_prefix.patch| 71 ---
.../recipes-kernel/modutils/modutils-collateral.bb | 21 -
.../modutils/modutils-cross/module.h.diff | 35
.../modutils/modutils-cross_2.4.27.bb | 20
meta/recipes-kernel/modutils/modutils_2.4.27.bb| 93
23 files changed, 24 insertions(+), 503 deletions(-)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/PD.patch
(100%)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/modutils.sh
(100%)
delete mode 100644
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
create mode 100644
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
rename meta/recipes-kernel/module-init-tools/{module-init-tools_3.12.bb =
module-init-tools_3.16.bb} (87%)
rename meta/recipes-kernel/{modutils =
module-init-tools}/modutils-initscripts.bb (100%)
delete mode 100644 meta/recipes-kernel/modutils/files/armeb.patch
delete mode 100644 meta/recipes-kernel/modutils/files/configure.patch
delete mode 100644 meta/recipes-kernel/modutils/files/gcc4.patch
delete mode 100644 meta/recipes-kernel/modutils/files/lex.l.diff
delete mode 100644 meta/recipes-kernel/modutils/files/modules
delete mode 100644 meta/recipes-kernel/modutils/files/modules.conf
delete mode 100644
[OE-core] [RFC v3 PATCH 6/9] modutils-initscripts: move recipe prior to modutils removal
Signed-off-by: Anders Darander and...@chargestorm.se
---
.../{modutils = module-init-tools}/files/PD.patch |0
.../files/modutils.sh |0
.../modutils-initscripts.bb|0
3 files changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/PD.patch
(100%)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/modutils.sh
(100%)
rename meta/recipes-kernel/{modutils =
module-init-tools}/modutils-initscripts.bb (100%)
diff --git a/meta/recipes-kernel/modutils/files/PD.patch
b/meta/recipes-kernel/module-init-tools/files/PD.patch
similarity index 100%
rename from meta/recipes-kernel/modutils/files/PD.patch
rename to meta/recipes-kernel/module-init-tools/files/PD.patch
diff --git a/meta/recipes-kernel/modutils/files/modutils.sh
b/meta/recipes-kernel/module-init-tools/files/modutils.sh
similarity index 100%
rename from meta/recipes-kernel/modutils/files/modutils.sh
rename to meta/recipes-kernel/module-init-tools/files/modutils.sh
diff --git a/meta/recipes-kernel/modutils/modutils-initscripts.bb
b/meta/recipes-kernel/module-init-tools/modutils-initscripts.bb
similarity index 100%
rename from meta/recipes-kernel/modutils/modutils-initscripts.bb
rename to meta/recipes-kernel/module-init-tools/modutils-initscripts.bb
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC v3 PATCH 1/9] Remove support for building 2.4 kernels
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/classes/kernel.bbclass | 12 ++--
meta/classes/module-base.bbclass |2 +-
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index fd27832..6bdfd3e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -73,9 +73,6 @@ KERNEL_ALT_IMAGETYPE ??=
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake include/linux/version.h CC=${KERNEL_CC} LD=${KERNEL_LD}
- if [ ${KERNEL_MAJOR_VERSION} != 2.6 ]; then
- oe_runmake dep CC=${KERNEL_CC} LD=${KERNEL_LD}
- fi
oe_runmake ${KERNEL_IMAGETYPE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD}
}
@@ -111,9 +108,7 @@ kernel_do_install() {
install -m 0644 vmlinux ${D}/boot/vmlinux-${KERNEL_VERSION}
[ -e Module.symvers ] install -m 0644 Module.symvers
${D}/boot/Module.symvers-${KERNEL_VERSION}
install -d ${D}/etc/modutils
- if [ ${KERNEL_MAJOR_VERSION} = 2.6 ]; then
- install -d ${D}/etc/modprobe.d
- fi
+ install -d ${D}/etc/modprobe.d
#
# Support for external module building - create a minimal copy of the
@@ -397,10 +392,7 @@ python populate_packages_prepend () {
# Write out any modconf fragment
modconf = bb.data.getVar('module_conf_%s' % basename, d, 1)
if modconf:
- if bb.data.getVar(KERNEL_MAJOR_VERSION, d, 1) ==
2.6:
- name = '%s/etc/modprobe.d/%s.conf' % (dvar,
basename)
- else:
- name = '%s/etc/modutils/%s.conf' % (dvar,
basename)
+ name = '%s/etc/modprobe.d/%s.conf' % (dvar, basename)
f = open(name, 'w')
f.write(%s\n % modconf)
f.close()
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index c98bace..a7cf233 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -7,7 +7,7 @@ export CROSS_COMPILE = ${TARGET_PREFIX}
export KERNEL_VERSION =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}
export KERNEL_SOURCE =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-source')}
-KERNEL_OBJECT_SUFFIX = ${@[.o,
.ko][base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion') 2.6.0]}
+KERNEL_OBJECT_SUFFIX = .ko
KERNEL_CCSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ccsuffix')}
KERNEL_LDSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ldsuffix')}
KERNEL_ARSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-arsuffix')}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC v3 PATCH 5/9] kernel.bblass: remove get_kernelmajorversion
It is now unused.
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/classes/linux-kernel-base.bbclass |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/meta/classes/linux-kernel-base.bbclass
b/meta/classes/linux-kernel-base.bbclass
index 510951a..4f2b0a4 100644
--- a/meta/classes/linux-kernel-base.bbclass
+++ b/meta/classes/linux-kernel-base.bbclass
@@ -24,14 +24,6 @@ def get_kernelversion(p):
return m.group(1)
return None
-def get_kernelmajorversion(p):
- import re
- r = re.compile(([0-9]+\.[0-9]+).*)
- m = r.match(p);
- if m:
- return m.group(1)
- return None
-
def linux_module_packages(s, d):
suffix =
return .join(map(lambda s: kernel-module-%s%s %
(s.lower().replace('_', '-').replace('@', '+'), suffix), s.split()))
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC v3 PATCH 9/9] distro_tracking_fields: remove modutils.
Signed-off-by: Anders Darander and...@chargestorm.se --- .../conf/distro/include/distro_tracking_fields.inc |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index 8a13426..0d915e4 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -1,5 +1,6 @@ RECIPE_STATUS_pn-diffutils = green RECIPE_LATEST_VERSION_pn-diffutils = 3.0 + RECIPE_LAST_UPDATE_pn-diffutils = Dec 10, 2010 RECIPE_MAINTAINER_pn-diffutils = Qing He qing...@intel.com @@ -685,13 +686,6 @@ RECIPE_COMMENTS_pn-keymaps = local scripts follow Poky's MIT license, however i RECIPE_LAST_UPDATE_pn-keymaps = Jul 21, 2006 RECIPE_MAINTAINER_pn-keymaps = Yu Ke ke...@intel.com -RECIPE_STATUS_pn-modutils = red -RECIPE_DEPENDENCY_CHECK_pn-modutils-initscripts = not done -RECIPE_LATEST_VERSION_pn-modutils = 2.4.27 -RECIPE_LAST_UPDATE_pn-modutils = Jul 21, 2006 -RECIPE_MAINTAINER_pn-modutils = Yu Ke ke...@intel.com -DISTRO_PN_ALIAS_pn-modutils = Ubuntu=module-init-tools Fedora=module-init-tools - RECIPE_STATUS_pn-modutils-initscripts = green RECIPE_DEPENDENCY_CHECK_pn-modutils-initscripts = not done RECIPE_LATEST_VERSION_pn-modutils-initscripts = 1.0 -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC v3 PATCH 3/9] modules-init-tools(-cross): update to 3.16
Update to get support for Linux 3.0.
Remove the application of ignore_arch_directory.patch, as this one do not apply.
(A comment in the patch states not sure the reason yet. Keep for a while and
verify later.).
Signed-off-by: Anders Darander and...@chargestorm.se
---
...oss_3.12.bb = module-init-tools-cross_3.16.bb} |4 ++--
.../module-init-tools/module-init-tools.inc|1 -
...nit-tools_3.12.bb = module-init-tools_3.16.bb} |6 +++---
3 files changed, 5 insertions(+), 6 deletions(-)
rename meta/recipes-kernel/module-init-tools/{module-init-tools-cross_3.12.bb
= module-init-tools-cross_3.16.bb} (74%)
rename meta/recipes-kernel/module-init-tools/{module-init-tools_3.12.bb =
module-init-tools_3.16.bb} (87%)
diff --git
a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
similarity index 74%
rename from
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
rename to meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
index 08bf1a9..da7b30c 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
@@ -1,7 +1,7 @@
require module-init-tools.inc
-PR = r1
+PR = r0
inherit cross
-PROVIDES += virtual/${TARGET_PREFIX}depmod virtual/${TARGET_PREFIX}depmod-2.6
+PROVIDES += virtual/${TARGET_PREFIX}depmod
SRC_URI += file://no-static-binaries.patch
diff --git a/meta/recipes-kernel/module-init-tools/module-init-tools.inc
b/meta/recipes-kernel/module-init-tools/module-init-tools.inc
index 4d96d16..c290c4f 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools.inc
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools.inc
@@ -12,7 +12,6 @@ FILES_module-init-tools-depmod = ${sbindir}/depmod.26
FILES_module-init-tools-insmod-static = ${sbindir}/insmod.static
SRC_URI =
${KERNELORG_MIRROR}/linux/utils/kernel/module-init-tools/module-init-tools-${PV}.tar.bz2
\
- file://ignore_arch_directory.patch \
file://modutils_extension.patch \
file://disable_man.patch \
file://grab_module_memset.patch
diff --git a/meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
similarity index 87%
rename from meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
rename to meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
index 3d7c287..0248b46 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
@@ -1,5 +1,5 @@
require module-init-tools.inc
-PR = r1
+PR = r0
# autotools set prefix to /usr, however we want them in /bin and /sbin
bindir = /bin
@@ -38,5 +38,5 @@ pkg_prerm_module-init-tools-depmod() {
update-alternatives --remove depmod /sbin/depmod.26
}
-SRC_URI[md5sum] = 8b2257ce9abef74c4a44d825d23140f3
-SRC_URI[sha256sum] =
d012ab07ea26721467a85a775f34747c1c8897e37f16bec5317d8a72ef8b4f17
+SRC_URI[md5sum] = bc44832c6e41707b8447e2847d2019f5
+SRC_URI[sha256sum] =
e1f2cdcae64a8effc25e545a5e0bdaf312f816ebbcd0916e4e87450755fab64b
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC v3 PATCH 7/9] modutils: remove modutils
As 2.4 support is being phased out, remove modutils.
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/recipes-kernel/modutils/files/armeb.patch | 16
meta/recipes-kernel/modutils/files/configure.patch | 34 ---
meta/recipes-kernel/modutils/files/gcc4.patch | 93
meta/recipes-kernel/modutils/files/lex.l.diff | 35
.../modutils/files/modutils-notest.patch | 16
.../modutils/files/program_prefix.patch| 71 ---
.../recipes-kernel/modutils/modutils-collateral.bb | 21 -
.../modutils/modutils-cross/module.h.diff | 35
.../modutils/modutils-cross_2.4.27.bb | 20
meta/recipes-kernel/modutils/modutils_2.4.27.bb| 93
10 files changed, 0 insertions(+), 434 deletions(-)
delete mode 100644 meta/recipes-kernel/modutils/files/armeb.patch
delete mode 100644 meta/recipes-kernel/modutils/files/configure.patch
delete mode 100644 meta/recipes-kernel/modutils/files/gcc4.patch
delete mode 100644 meta/recipes-kernel/modutils/files/lex.l.diff
delete mode 100644 meta/recipes-kernel/modutils/files/modules
delete mode 100644 meta/recipes-kernel/modutils/files/modules.conf
delete mode 100644 meta/recipes-kernel/modutils/files/modutils-notest.patch
delete mode 100644 meta/recipes-kernel/modutils/files/program_prefix.patch
delete mode 100644 meta/recipes-kernel/modutils/modutils-collateral.bb
delete mode 100644 meta/recipes-kernel/modutils/modutils-cross/module.h.diff
delete mode 100644 meta/recipes-kernel/modutils/modutils-cross_2.4.27.bb
delete mode 100644 meta/recipes-kernel/modutils/modutils_2.4.27.bb
diff --git a/meta/recipes-kernel/modutils/files/armeb.patch
b/meta/recipes-kernel/modutils/files/armeb.patch
deleted file mode 100644
index 3198553..000
--- a/meta/recipes-kernel/modutils/files/armeb.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-Upstream-Status: Pending
-
modutils-2.4.27/include/elf_arm.h.orig 2004-09-21 18:37:00.0
-0400
-+++ modutils-2.4.27/include/elf_arm.h 2004-09-21 18:38:18.0 -0400
-@@ -1,7 +1,11 @@
- /* Machine-specific elf macros for ARM. */
-
- #define ELFCLASSM ELFCLASS32
-+#ifdef __ARMEB__
-+#define ELFDATAM ELFDATA2MSB
-+#else
- #define ELFDATAM ELFDATA2LSB
-+#endif
-
- #define MATCH_MACHINE(x) (x == EM_ARM)
-
diff --git a/meta/recipes-kernel/modutils/files/configure.patch
b/meta/recipes-kernel/modutils/files/configure.patch
deleted file mode 100644
index 63e80d7..000
--- a/meta/recipes-kernel/modutils/files/configure.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-Upstream-Status: Pending
-
-#
-# Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
-#
-
modutils-2.4.25/./configure.in~configure
-+++ modutils-2.4.25/./configure.in
-@@ -1,4 +1,5 @@
--AC_INIT(insmod/insmod.c)
-+AC_INIT
-+AC_CONFIG_SRCDIR([insmod/insmod.c])
- AC_PREFIX_DEFAULT(/usr)
-
- # Canonical system uses CC_FOR_BUILD while Linux may use BUILDCC
-@@ -15,7 +16,7 @@
- BUILDCC=$CC_FOR_BUILD
- export CC_FOR_BUILD
-
--AC_CANONICAL_SYSTEM
-+AC_CANONICAL_TARGET([])
-
- # Handle target_cpu for compatibility.
- if test $host_cpu != $target_cpu; then
-@@ -350,6 +351,7 @@
- fi
- fi
-
--AC_OUTPUT(Makefile Makefile.common depmod/Makefile genksyms/Makefile
-+AC_CONFIG_FILES([Makefile Makefile.common depmod/Makefile genksyms/Makefile
- insmod/Makefile $kerneld_Makefiles obj/Makefile util/Makefile
--man/Makefile)
-+man/Makefile])
-+AC_OUTPUT
diff --git a/meta/recipes-kernel/modutils/files/gcc4.patch
b/meta/recipes-kernel/modutils/files/gcc4.patch
deleted file mode 100644
index 4507b03..000
--- a/meta/recipes-kernel/modutils/files/gcc4.patch
+++ /dev/null
@@ -1,93 +0,0 @@
-Upstream-Status: Pending
-
-Index: modutils-2.4.27/depmod/depmod.c
-===
modutils-2.4.27.orig/depmod/depmod.c
-+++ modutils-2.4.27/depmod/depmod.c
-@@ -1133,7 +1133,7 @@ static int addksyms(char *file_syms)
-
- for (ksym = ksyms; so_far nksyms; ++so_far, ksym++) {
- if (strncmp((char *)ksym-name, GPLONLY_, 8) == 0)
-- ((char *)ksym-name) += 8;
-+ ksym-name += 8;
- assert(n_syms MAX_MAP_SYM);
- symtab[n_syms++] = addsym((char *)ksym-name, mod,
SYM_DEFINED, 0);
- }
-Index: modutils-2.4.27/genksyms/genksyms.c
-===
modutils-2.4.27.orig/genksyms/genksyms.c
-+++ modutils-2.4.27/genksyms/genksyms.c
-@@ -45,7 +45,7 @@ char *cur_filename, *output_directory;
- int flag_debug, flag_dump_defs, flag_warnings;
- int checksum_version = 1, kernel_version = version(2,0,0);
-
--static int errors;
-+int errors;
- static int nsyms;
-
- static struct symbol *expansion_trail;
-Index: modutils-2.4.27/insmod/insmod.c
[OE-core] [RFC v3 PATCH 8/9] task-base: remove modutils reference.
Also remove the other kernel24 references.
Make everything dependent on kernel26 default.
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/recipes-core/tasks/task-base.bb | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/meta/recipes-core/tasks/task-base.bb
b/meta/recipes-core/tasks/task-base.bb
index 3ff57ff..62432b4 100644
--- a/meta/recipes-core/tasks/task-base.bb
+++ b/meta/recipes-core/tasks/task-base.bb
@@ -45,7 +45,7 @@ PACKAGES = ' \
${@base_contains(DISTRO_FEATURES, raid, task-base-raid,
,d)} \
${@base_contains(DISTRO_FEATURES, zeroconf,
task-base-zeroconf, , d)} \
\
-
${@base_contains(MACHINE_FEATURES,kernel26,task-base-kernel26,task-base-kernel24,d)}
\
+task-base-kernel26 \
'
ALLOW_EMPTY = 1
@@ -58,12 +58,12 @@ PACKAGE_ARCH = ${MACHINE_ARCH}
#
# linux-hotplug or none
#
-HOTPLUG ?= ${@base_contains(MACHINE_FEATURES, kernel24,
linux-hotplug,,d)}
+HOTPLUG ?=
#
# pcmciautils for = 2.6.13-rc1, pcmcia-cs for others
#
-PCMCIA_MANAGER ?= ${@base_contains('MACHINE_FEATURES',
'kernel26','pcmciautils','pcmcia-cs',d)}
+PCMCIA_MANAGER ?= pcmciautils
#
# those ones can be set in machine config to supply packages needed to get
machine booting
@@ -79,7 +79,7 @@ RDEPENDS_task-base = \
task-machine-base \
${HOTPLUG} \
\
-${@base_contains('MACHINE_FEATURES',
'kernel26','task-base-kernel26','task-base-kernel24',d)} \
+task-base-kernel26 \
${@base_contains('MACHINE_FEATURES', 'apm', 'task-base-apm', '',d)} \
${@base_contains('MACHINE_FEATURES', 'acpi', 'task-base-acpi', '',d)} \
${@base_contains('MACHINE_FEATURES', 'keyboard', 'task-base-keyboard',
'',d)} \
@@ -155,17 +155,10 @@ RRECOMMENDS_task-distro-base =
${DISTRO_EXTRA_RRECOMMENDS}
RDEPENDS_task-machine-base = ${MACHINE_EXTRA_RDEPENDS}
RRECOMMENDS_task-machine-base = ${MACHINE_EXTRA_RRECOMMENDS}
-RDEPENDS_task-base-kernel24 = \
-modutils-depmod
-
RDEPENDS_task-base-kernel26 = \
sysfsutils \
module-init-tools
-RRECOMMENDS_task-base-kernel24 = \
-kernel-module-input \
-kernel-module-uinput
-
RRECOMMENDS_task-base-kernel26 = \
kernel-module-nls-utf8 \
kernel-module-input \
@@ -221,21 +214,12 @@ RDEPENDS_task-base-pcmcia = \
RRECOMMENDS_task-base-pcmcia = \
-${@base_contains('MACHINE_FEATURES', 'kernel26', '${task-base-pcmcia26}',
'${task-base-pcmcia24}',d)} \
kernel-module-pcmcia \
kernel-module-airo-cs \
kernel-module-pcnet-cs \
kernel-module-serial-cs \
kernel-module-ide-cs \
kernel-module-ide-disk \
-
-
-task-base-pcmcia24 = \
-${@base_contains('DISTRO_FEATURES', 'wifi', 'hostap-modules-cs', '',d)} \
-${@base_contains('DISTRO_FEATURES', 'wifi', 'orinoco-modules-cs', '',d)} \
-
-
-task-base-pcmcia26 = \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-hostap-cs',
'',d)} \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-orinoco-cs',
'',d)} \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-spectrum-cs',
'',d)}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC v3 PATCH 4/9] module-init-tools-cross: do not install depmod as depmod-2.6
Signed-off-by: Anders Darander and...@chargestorm.se
---
.../module-init-tools-cross_3.16.bb|4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git
a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
index da7b30c..8b3458b 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
@@ -6,7 +6,3 @@ PROVIDES += virtual/${TARGET_PREFIX}depmod
SRC_URI += file://no-static-binaries.patch
EXTRA_OECONF_append = --program-prefix=${TARGET_PREFIX}
-
-do_install_append () {
-mv ${D}${bindir}/${TARGET_PREFIX}depmod
${D}${bindir}/${TARGET_PREFIX}depmod-2.6
-}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v3 PATCH 0/9] Linux 3.0 build support
On Wed, Jun 29, 2011 at 19:54, Anders Darander and...@chargestorm.se wrote: v3: - task-base.bb: fix a problem that *pcmia26 couldn't be found. This third version fixes a bug introduced in v2. (task-base-pcmcia26 weren't found). The fix is incorporated in patch 0008 (task-base). Sofar, I've only got positive feedback on v2. (some feedback off-list (including some that probably should have been on-list if it hadn't been for some gmane problems). Unless I find some more problems, or get such reports, I plan to send a pull request towards the end of this week. Regards, Anders ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] kernel: move menuconfig task after configure
The following changes since commit e0fc42b51a8209dac1163ae8126f8c687b6bfddf: distro_tracking_fields.inc: update RECIPE_MANUAL_CHECK_DATE for screen and tcf-agent (2011-06-29 15:04:59 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dvhart/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/kernel Darren Hart (1): kernel: move menuconfig task after configure meta/classes/kernel.bbclass |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Consistent MAC on Beagleboard xM
We have an open bug for a consistent MAC on the Beagleboard xM on the yocto project bugzilla. I want to track whatever solution you have or plan to take. I didn't see a fix in linux-omap_2.6.39 at a quick scan through the patches. There are two approaches suggested in Comment 3 of the bug: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1073 They are: https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/687396 http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-October/026240.html Do you already have plans to address this? If not, do you have any opinion on the proposed solutions in the bug? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] glib-networking: Add 2.28.7 as new recipe
On 06/28/2011 06:54 AM, Richard Purdie wrote: On Tue, 2011-06-28 at 15:42 +0800, edwin.z...@intel.com wrote: From: Zhai Edwinedwin.z...@intel.com glib-networking contains the implementations of certain GLib networking features that cannot be implemented directly in GLib itself because of their dependencies. TLS/SSL support is one of them, which is needed for accessing SSL web page. Signed-off-by: Zhai Edwinedwin.z...@intel.com --- .../glib-networking/glib-networking_2.28.7.bb | 21 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-core/glib-networking/glib-networking_2.28.7.bb I merged this patch but we should revisit the issue of the gnome bbclass files in a subsequent patch. Should this not go into recipes-support? Sau! Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] multiple recipes converted to -staticdev packages
Op 29 jun 2011, om 19:27 heeft Saul Wold het volgende geschreven:
On 06/29/2011 09:26 AM, Koen Kooi wrote:
Op 29 jun 2011, om 18:23 heeft Saul Wold het volgende geschreven:
On 06/29/2011 07:18 AM, Richard Purdie wrote:
Hi Saul,
I'm still not 100% sure this patch is the right way to go or not. Let me
ask some specific questions below.
On Tue, 2011-06-28 at 17:07 -0700, Saul Wold wrote:
This commit adds a new base package ${PN}-staticdev to
bitbake.conf which pulls in the static *.a libraries as
a seperate package, it filters out the nonshared.a
libraries where appropriate.
Additional this commit adds a new libdev.bbclass which provides
a set of macros and variables to convert ${PN} to lib${PN},
which a number of recipes where then converted to use.
PR bumps all around
Signed-off-by: Saul Wolds...@linux.intel.com
---
meta/classes/lib_package.bbclass | 10 -
meta/classes/libdev.bbclass| 44
meta/conf/bitbake.conf |8 +++-
meta/recipes-bsp/pciutils/pciutils_3.1.7.bb|7 ++-
.../wireless-tools/wireless-tools_29.bb|9 +++-
meta/recipes-core/eglibc/eglibc-common.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|9 +++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb | 16
meta/recipes-core/glibc/glibc-package.inc |9 +++-
.../meta/external-csl-toolchain_2008q3-72.bb |8 ++-
meta/recipes-core/uclibc/uclibc.inc|9 +++-
meta/recipes-core/udev/udev-new.inc| 14 --
meta/recipes-core/udev/udev_164.bb |2 +-
meta/recipes-core/util-linux/util-linux.inc| 11 -
meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +-
.../binutils/binutils-cross-canadian_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils-cross.inc |2 +
.../binutils/binutils-cross_csl-arm-2008q1.bb |2 +-
.../binutils/binutils-crosssdk_2.21.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|9 +---
meta/recipes-devtools/binutils/binutils_2.21.bb|2 +-
meta/recipes-devtools/gcc/gcc-package-runtime.inc | 25 ---
meta/recipes-devtools/gcc/libgcc_4.6.bb|2 +-
meta/recipes-devtools/opkg/opkg_0.1.8.bb |8 ++-
meta/recipes-devtools/opkg/opkg_svn.bb |8 ++-
meta/recipes-devtools/python/python_2.6.6.bb |4 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 18
meta/recipes-extended/augeas/augeas.inc|7 +--
meta/recipes-extended/augeas/augeas_0.8.1.bb |2 +-
meta/recipes-extended/gamin/gamin_0.1.10.bb| 13 +-
.../tcp-wrappers/tcp-wrappers_7.6.bb |9 +++-
meta/recipes-graphics/cairo/cairo_1.10.2.bb|9 ++--
meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb |7 +--
meta/recipes-multimedia/liba52/liba52_0.7.4.bb |4 +-
meta/recipes-support/attr/acl_2.2.51.bb|2 +-
meta/recipes-support/attr/attr_2.4.46.bb |2 +-
meta/recipes-support/attr/ea-acl.inc | 16 +---
meta/recipes-support/curl/curl_7.21.6.bb | 17 +++-
meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb |5 +-
meta/recipes-support/sqlite/sqlite3.inc| 10 +
meta/recipes-support/sqlite/sqlite3_3.7.6.2.bb |2 +-
41 files changed, 203 insertions(+), 146 deletions(-)
create mode 100644 meta/classes/libdev.bbclass
diff --git a/meta/classes/lib_package.bbclass
b/meta/classes/lib_package.bbclass
index 5ce8727..e8cbc25 100644
--- a/meta/classes/lib_package.bbclass
+++ b/meta/classes/lib_package.bbclass
@@ -5,6 +5,12 @@ FILES_${PN} = ${libexecdir} ${libdir}/lib*${SOLIBS} \
${base_libdir}/*${SOLIBS} \
${datadir}/${PN} ${libdir}/${PN}
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV}
${libdir}/*.la \
- ${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
- ${datadir}/aclocal ${bindir}/*-config
+${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
+${datadir}/aclocal ${bindir}/*-config \
+${libdir}/*_nonshared.a
FILES_${PN}-bin = ${bindir}/* ${sbindir}/* /bin/* /sbin/*
+
+staticdev_libs = ${libdir}/*.a ${base_libdir}/*.a
+FILES_${PN}-staticdev = ${@oe_filter_out('lib.*_nonshared.a',
'${staticdev_libs}', d)}
As Phil says, I'm not sure this works and since the nonshared.a thing is
a *libc thing its probably not worth adding this complexity to the core
but just work putting it in the *libc packaging code.
I have tested this and it works, after reviewing this further, I will move
this to handled by the specific cases that need, rather than being a
general solution in bitbake.conf
diff --git a/meta/classes/libdev.bbclass b/meta/classes/libdev.bbclass
new file
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Op 29 jun 2011, om 18:44 heeft Cui, Dexuan het volgende geschreven: Koen Kooi wrote: Op 29 jun 2011, om 18:14 heeft Cui, Dexuan het volgende geschreven: Khem Raj wrote: On 06/28/2011 04:07 AM, Paul Eggleton wrote: On Tuesday 28 June 2011 07:45:09 Koen Kooi wrote: BTW: meta and mete-yocto belong to the same git repo actually, so do you think showing them in one line like this meta,meta-yocto = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 is better than showing 2 lines like this: meta = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 meta-yocto= master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 That breaks with repos like meta-intel and meta-oe. Maybe something Could you please explain a bit more? That will become very wide with meta-intel and meta-oe and friends. I know my terminals are 200 chars wide, but not everyone is weird that way :) Just look at the line below: meta-sugarbay,meta-crownbay,meta-emenlow,meta-fishriver,meta-jasperforest,meta-n450, = master:50661bf038a34702f3aa139c3ea0d67fbb0ce5db ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Consistent MAC on Beagleboard xM
Op 29 jun 2011, om 23:00 heeft Darren Hart het volgende geschreven: We have an open bug for a consistent MAC on the Beagleboard xM on the yocto project bugzilla. I want to track whatever solution you have or plan to take. I didn't see a fix in linux-omap_2.6.39 at a quick scan through the patches. There are two approaches suggested in Comment 3 of the bug: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1073 They are: https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/687396 http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-October/026240.html Do you already have plans to address this? If not, do you have any opinion on the proposed solutions in the bug? I'd like to use the die-ID for the mac, but the proposed patch by the linaro folks is just wrong in the way it is done, I don't want to add 40 lines of code to my boardfiles just for the mac address *and* need to hardcode usb topology as well. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] glib-networking: Add 2.28.7 as new recipe
Op 29 jun 2011, om 23:13 heeft Saul Wold het volgende geschreven: On 06/28/2011 06:54 AM, Richard Purdie wrote: On Tue, 2011-06-28 at 15:42 +0800, edwin.z...@intel.com wrote: From: Zhai Edwinedwin.z...@intel.com glib-networking contains the implementations of certain GLib networking features that cannot be implemented directly in GLib itself because of their dependencies. TLS/SSL support is one of them, which is needed for accessing SSL web page. Signed-off-by: Zhai Edwinedwin.z...@intel.com --- .../glib-networking/glib-networking_2.28.7.bb | 21 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-core/glib-networking/glib-networking_2.28.7.bb I merged this patch but we should revisit the issue of the gnome bbclass files in a subsequent patch. Should this not go into recipes-support? I'd put it in the same dir as the other glib recipes to make it easier to find. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 0/2] Sanity check network connectivity
v3 of this change set based on extra feedback from Khem Raj. Changes since v2: * Remove references to Yocto, don't offer default uri's to check * Make the error message configurable through a variable, CONNECTIVITY_CHECK_MSG, whilst providing a reasonable default. In response to a Yocto Bugzilla request[1] I've written a sanity test to check whether BitBake is able to fecth from http, https and git sources. The idea being that if the user is behing a proxy and this test fails we can more easily help them diagnose and fix their problem. I've built on the existing infrastructure for less frequent sanity tests so whilst this test is reasonably heavy it will only run when TMPDIR changes (usually first run?). Further I added a variable to disable just this sanity check. People shipping offline installs to customers should just be able to set the variable in their shipped configuration and not worry about this sanity check irritating people. The following changes since commit ff014d9634638457622f6019b163e75bafcefada: task-base: add 3G into DISTRO_FEATURE (2011-06-29 14:46:46 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib josh/connection-test http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/connection-test Joshua Lock (2): sanity.bbclass: pass the data object to the less frequent test harnesses sanity: implement network connectivity test meta/classes/sanity.bbclass | 53 -- 1 files changed, 45 insertions(+), 8 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 1/2] sanity.bbclass: pass the data object to the less frequent test harnesses
By passing the data object to the less frequently run test harnesses
(check_sanity_tmpdir_change(), check_sanity_sstate_dir_change() and
check_sanity_version_change()) we can run tests against BitBake data here
too.
Signed-off-by: Joshua Lock j...@linux.intel.com
---
meta/classes/sanity.bbclass | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index d296c86..720777a 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -21,7 +21,7 @@ def check_conf_exists(fn, data):
return True
return False
-def check_sanity_sstate_dir_change(sstate_dir):
+def check_sanity_sstate_dir_change(sstate_dir, data):
# Sanity checks to be done when the value of SSTATE_DIR changes
# Check that SSTATE_DIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
@@ -30,14 +30,14 @@ def check_sanity_sstate_dir_change(sstate_dir):
testmsg = check_create_long_filename(sstate_dir, SSTATE_DIR)
return testmsg
-def check_sanity_tmpdir_change(tmpdir):
+def check_sanity_tmpdir_change(tmpdir, data):
# Sanity checks to be done when the value of TMPDIR changes
# Check that TMPDIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
testmsg = check_create_long_filename(tmpdir, TMPDIR)
return testmsg
-def check_sanity_version_change():
+def check_sanity_version_change(data):
# Sanity checks to be done when SANITY_VERSION changes
return
@@ -266,14 +266,14 @@ def check_sanity(e):
sanity_version = int(data.getVar('SANITY_VERSION', e.data, True) or 1)
if last_sanity_version sanity_version:
-messages = messages + check_sanity_version_change()
-messages = messages + check_sanity_tmpdir_change(tmpdir)
-messages = messages + check_sanity_sstate_dir_change(sstate_dir)
+messages = messages + check_sanity_version_change(e.data)
+messages = messages + check_sanity_tmpdir_change(tmpdir, e.data)
+messages = messages + check_sanity_sstate_dir_change(sstate_dir,
e.data)
else:
if last_tmpdir != tmpdir:
-messages = messages + check_sanity_tmpdir_change(tmpdir)
+messages = messages + check_sanity_tmpdir_change(tmpdir, e.data)
if last_sstate_dir != sstate_dir:
-messages = messages + check_sanity_sstate_dir_change(sstate_dir)
+messages = messages + check_sanity_sstate_dir_change(sstate_dir,
e.data)
if os.path.exists(conf):
f = file(sanityverfile, 'w')
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 2/2] sanity: implement network connectivity test
Sanity test to verify files can be fetched from the network using git, http
and https fetchers point users at a page to help get set up in the case of a
failure.
Requires a variable CONNECTIVITY_CHECK_URIS to be set, using the same pattern
as SRC_URI, of URI's to test against.
The variable CONNECTIVITY_CHECK_MSG can be set to provide a custom error
message, such as a pointer to some help, when this check fails.
Addresses [YOCTO #933]
Signed-off-by: Joshua Lock j...@linux.intel.com
---
meta/classes/sanity.bbclass | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 720777a..c9d37c9 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -35,6 +35,8 @@ def check_sanity_tmpdir_change(tmpdir, data):
# Check that TMPDIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
testmsg = check_create_long_filename(tmpdir, TMPDIR)
+# Check that we can fetch from various network transports
+testmsg = testmsg + check_connectivity(data)
return testmsg
def check_sanity_version_change(data):
@@ -79,6 +81,41 @@ def check_create_long_filename(filepath, pathname):
return Failed to create a file in %s: %s % (pathname, strerror)
return
+def check_connectivity(d):
+# URI's to check can be set in the CONNECTIVITY_CHECK_URIS variable
+# using the same syntax as for SRC_URI. If the variable is not set
+# the check is skipped
+test_uris = (bb.data.getVar('CONNECTIVITY_CHECK_URIS', d, True) or
).split()
+retval =
+
+# Only check connectivity if network enabled and the
+# CONNECTIVITY_CHECK_URIS are set
+network_enabled = not bb.data.getVar('BB_NO_NETWORK', d, True)
+check_enabled = len(test_uris)
+if check_enabled and network_enabled:
+data = bb.data.createCopy(d)
+bookmark = os.getcwd()
+dldir = bb.data.expand('${TMPDIR}/sanity', data)
+bb.data.setVar('DL_DIR', dldir, data)
+
+try:
+fetcher = bb.fetch2.Fetch(test_uris, data)
+fetcher.download()
+fetcher.clean(test_uris)
+except Exception:
+# Allow the message to be configured so that users can be
+# pointed to a support mechanism.
+msg = bb.data.getVar('CONNECTIVITY_CHECK_MSG', d, True) or
+if len(msg) == 0:
+msg = Failed to fetch test data from the network. Please
ensure your network is configured correctly.\n
+retval = msg
+finally:
+# Make sure we tidy up the cruft
+oe.path.remove(dldir)
+os.chdir(bookmark)
+
+return retval
+
def check_sanity(e):
from bb import note, error, data, __version__
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC 0/2] Sanity check network connectivity
Op 29 jun 2011, om 23:55 heeft Joshua Lock het volgende geschreven: v3 of this change set based on extra feedback from Khem Raj. Changes since v2: * Remove references to Yocto, don't offer default uri's to check Can't you offer an oe.org url to check instead? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Building behind a firewall/proxy
On Tue, 2011-06-28 at 22:20 +0200, Koen Kooi wrote: Op 28 jun 2011, om 22:14 heeft Joshua Lock het volgende geschreven: All, For the Yocto 1.1 release we want to ease the pain of getting set up to build behind a firewall. I have a series of patches under development to run a one hit sanity test which tries to verify the user can fetch and in the case of failure point the user to a wiki page where we'd document common causes of fetch failures. We're also going to look at the site.conf file, which can be used to specify proxy settings and other site specific settings such MIRRORS, and ensure that it can easily be edited to help people get set up. It'd be great if people who operate behind a proxy/firewall can help us document the steps they had to take to work around this. Further if you have other ideas as to how we can help make this process less painful please let us know. This is what I'm using inside TI: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/setup-scripts/tree/oebb.sh?h=oe-core It grew organically, so grepping for 'proxy' is your best bet :) Thanks Koen, a useful reference. Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Building behind a firewall/proxy
On Tue, 2011-06-28 at 14:46 -0700, Tom Rini wrote: On 06/28/2011 01:14 PM, Joshua Lock wrote: All, For the Yocto 1.1 release we want to ease the pain of getting set up to build behind a firewall. I have a series of patches under development to run a one hit sanity test which tries to verify the user can fetch and in the case of failure point the user to a wiki page where we'd document common causes of fetch failures. We're also going to look at the site.conf file, which can be used to specify proxy settings and other site specific settings such MIRRORS, and ensure that it can easily be edited to help people get set up. It'd be great if people who operate behind a proxy/firewall can help us document the steps they had to take to work around this. Further if you have other ideas as to how we can help make this process less painful please let us know. Is SOCKS5_PASSWD SOCKS5_USER in the default BB_ENV_EXTRAWHITE list atm? If not, it needs to be. Noted, thanks Tom. Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc-locale: fix localedef packaging
Op 28 jun 2011, om 18:11 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-28 at 17:30 +0200, Koen Kooi wrote:
the ${PN} still needs some checking, since it will now inheriting the
default FILES_${PN}
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
I merged a different version of this which drops PN-locale and fixes
glibc too.
It's getting late here, so I haven't double checked the bug, but:
* check_data_file_clashes: Package eglibc-utils wants to install file
/usr/bin/localedef
But that file is already provided by package * localedef
This seems fixable by a strategically placed 'rm' in eglibc-package.inc
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Add env setting to support libtool2.4 m4 macro
Add OECORE_ACLOCAL_OPTS to env setup scripts for options
running aclocal to generate correct libtool 2.4 m4 macro,
the autogen.sh should be changed as aclocal ${OECORE_ACLOCAL_OPTS}
The following changes since commit c412674cf818e77e35857fb93353e392e7ac9e53:
Khem Raj (1):
package.bbclass,prserv.bbclass: Compare USE_PR_SERV with 1 or 0
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib jzhang/aclocal
http://git.yoctoproject.org/cgit.cgi//log/?h=jzhang/aclocal
Jessica Zhang (1):
Add OECORE_ACLOCAL_OPTS to env setup scripts for autotool project
using correct libtool 2.4
meta/classes/toolchain-scripts.bbclass |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] Add OECORE_ACLOCAL_OPTS to env setup scripts for autotool project using correct libtool 2.4
Signed-off-by: Jessica Zhang jessica.zh...@intel.com
---
meta/classes/toolchain-scripts.bbclass |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 09ecd7c..3301319 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -28,6 +28,7 @@ toolchain_create_sdk_env_script () {
echo 'export CPPFLAGS=--sysroot=${SDKTARGETSYSROOT}' $script
echo 'export OECORE_NATIVE_SYSROOT=${SDKPATHNATIVE}' $script
echo 'export OECORE_TARGET_SYSROOT=${SDKTARGETSYSROOT}' $script
+ echo 'export OECORE_ACLOCAL_OPTS=-I
${SDKPATHNATIVE}/usr/share/aclocal' $script
echo 'export POKY_DISTRO_VERSION=${DISTRO_VERSION}' $script
}
@@ -59,6 +60,7 @@ toolchain_create_tree_env_script () {
echo 'export CXXFLAGS=${TARGET_CC_ARCH}' $script
echo 'export OECORE_NATIVE_SYSROOT=${STAGING_DIR_NATIVE}' $script
echo 'export OECORE_TARGET_SYSROOT=${STAGING_DIR_TARGET}' $script
+ echo 'export OECORE_ACLOCAL_OPTS=-I
${STAGING_DIR_NATIVE}/usr/share/aclocal' $script
}
# This function creates an environment-setup-script for use by the ADT
installer
@@ -89,6 +91,7 @@ toolchain_create_sdk_env_script_for_installer () {
echo 'export CPPFLAGS=--sysroot=##SDKTARGETSYSROOT##' $script
echo 'export OECORE_NATIVE_SYSROOT=${SDKPATHNATIVE}' $script
echo 'export OECORE_TARGET_SYSROOT=##SDKTARGETSYSROOT##' $script
+echo 'export OECORE_ACLOCAL_OPTS=-I
${SDKPATHNATIVE}/usr/share/acloal' $script
echo 'export POKY_DISTRO_VERSION=${DISTRO_VERSION}' $script
echo 'export POKY_SDK_VERSION=${SDK_VERSION}' $script
}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] How to reuse code in oe-core environment
Hi,
I am playing around with oe-core try to find a way of reusing code for multiple
recipes. In oe I did create foo.inc with
foo() {
# code to reuse
}
and called foo from several recipes. In oe-core the run.* scripts are much more
stripped of unnecessary. All the code included by 'require' seems to miss, so
the function foo() will not be found.
My searches for examples did not lead to a hook so what is the suggested
solution for reusing code for multiple recipes in oe-core?
regards
Andreas
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Consistent MAC on Beagleboard xM
On 06/29/2011 02:19 PM, Koen Kooi wrote: Op 29 jun 2011, om 23:00 heeft Darren Hart het volgende geschreven: We have an open bug for a consistent MAC on the Beagleboard xM on the yocto project bugzilla. I want to track whatever solution you have or plan to take. I didn't see a fix in linux-omap_2.6.39 at a quick scan through the patches. There are two approaches suggested in Comment 3 of the bug: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1073 They are: https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/687396 http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-October/026240.html Do you already have plans to address this? If not, do you have any opinion on the proposed solutions in the bug? I'd like to use the die-ID for the mac, but the proposed patch by the linaro folks is just wrong in the way it is done, I don't want to add 40 lines of code to my boardfiles just for the mac address *and* need to hardcode usb topology as well. Seems like a combination of the two approaches would be ideal. Enable user-setting of the mac address and then have the boardfile update it using the die-ID? I'll mark this bug as WaitForUpstream. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc-locale: add missing 2.12 version
On 06/28/2011 05:21 AM, Koen Kooi wrote:
Signed-off-by: Koen Kooik...@dominion.thruhere.net
---
meta/recipes-core/eglibc/eglibc-locale_2.12.bb | 58
1 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-core/eglibc/eglibc-locale_2.12.bb
diff --git a/meta/recipes-core/eglibc/eglibc-locale_2.12.bb
b/meta/recipes-core/eglibc/eglibc-locale_2.12.bb
new file mode 100644
index 000..ed6c099
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-locale_2.12.bb
@@ -0,0 +1,58 @@
+INHIBIT_DEFAULT_DEPS = 1
+LICENSE = LGPL
+
+BPN = eglibc
+
+do_fetch[noexec] = 1
+do_unpack[noexec] = 1
+do_patch[noexec] = 1
+do_configure[noexec] = 1
+do_compile[noexec] = 1
+
+# Binary locales are generated at build time if ENABLE_BINARY_LOCALE_GENERATION
+# is set. The idea is to avoid running localedef on the target (at first boot)
+# to decrease initial boot time and avoid localedef being killed by the OOM
+# killer which used to effectively break i18n on machines with 128MB RAM.
+
+# default to disabled
+ENABLE_BINARY_LOCALE_GENERATION ?= 0
+ENABLE_BINARY_LOCALE_GENERATION_pn-eglibc-locale-nativesdk = 0
+
+#enable locale generation on these arches
+# BINARY_LOCALE_ARCHES is a space separated list of regular expressions
+BINARY_LOCALE_ARCHES ?= arm.* i[3-6]86 x86_64 powerpc mips
+
+# set 1 to use cross-localedef for locale generation
+# set 0 for qemu emulation of native localedef for locale generation
+LOCALE_GENERATION_WITH_CROSS-LOCALEDEF = 1
+
+PR = r0
+
+PKGSUFFIX =
+PKGSUFFIX_virtclass-nativesdk = -nativesdk
+
+PACKAGES = eglibc-locale localedef${PKGSUFFIX}
+
+PACKAGES_DYNAMIC = locale-base-* \
+eglibc-gconv-* eglibc-charmap-* eglibc-localedata-*
eglibc-binary-localedata-* \
+glibc-gconv-*${PKGSUFFIX} glibc-charmap-* glibc-localedata-*
glibc-binary-localedata-*
+
+PROVIDES = virtual/libc-locale${PKGSUFFIX}
+
+RPROVIDES_eglibc-locale = glibc-locale
+
+FILES_eglibc-gconv = ${libdir}/gconv/*
+FILES_localedef${PKGSUFFIX} = ${bindir}/localedef
+
+do_install () {
+ cp -fpPR
${STAGING_INCDIR}/eglibc-locale-internal-${MULTIMACH_TARGET_SYS}/* ${D}
+ cp -fpPR ${D}/SUPPORTED ${WORKDIR}
+}
+
+DESCRIPTION_localedef = eglibc: compile locale definition files
+
+inherit libc-package
+
+do_install[depends] += virtual/libc${PKGSUFFIX}:do_populate_sysroot
+
+BBCLASSEXTEND = nativesdk
Richard merged a variation of this.
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] How to reuse code in oe-core environment
On Wed, Jun 29, 2011 at 4:02 PM, Andreas Mueller schnitzelt...@gmx.de wrote:
Hi,
I am playing around with oe-core try to find a way of reusing code for
multiple
recipes. In oe I did create foo.inc with
foo() {
# code to reuse
}
and called foo from several recipes. In oe-core the run.* scripts are much
more
stripped of unnecessary. All the code included by 'require' seems to miss, so
the function foo() will not be found.
My searches for examples did not lead to a hook so what is the suggested
solution for reusing code for multiple recipes in oe-core?
hmm do u mean something like what busybox recipe is doing as an example.
or did I misunderstand
regards
Andreas
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] How to reuse code in oe-core environment
On Wed, Jun 29, 2011 at 4:02 PM, Andreas Mueller schnitzelt...@gmx.de wrote:
foo() {
# code to reuse
}
and called foo from several recipes. In oe-core the run.* scripts are much
more
stripped of unnecessary. All the code included by 'require' seems to miss, so
the function foo() will not be found.
My searches for examples did not lead to a hook so what is the suggested
solution for reusing code for multiple recipes in oe-core?
The require doesn't have to do with anything. bitbake emits only the
functions which get called somewhere from the task being run. It
tracks what variables reference what other variables. If you call a
shell function from another shell function, it tracks this, and
realizes that both need to be emitted. Either you're doing something
wrong, or you're doing something in a way that bitbake can't track.
There's a variable flag you can set to explicitly add variable
dependencies.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] util-linux: Rebase remove-lscpu patch for non-gplv3
This patch rebases the remove-lscpu patch for util-linux so that it can build a non-gplv3 compliant image. Sau! The following changes since commit ff014d9634638457622f6019b163e75bafcefada: task-base: add 3G into DISTRO_FEATURE (2011-06-29 14:46:46 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib sgw/fix http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/fix Saul Wold (1): util-linux: Rebase remove-lscpu patch from non-gplv3 .../util-linux-2.19.1/remove-lscpu.patch | 120 ++- meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +- 2 files changed, 64 insertions(+), 58 deletions(-) -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] How to reuse code in oe-core environment
On Thursday, June 30, 2011 02:32:56 AM Mark Hatle wrote:
On 6/29/11 6:59 PM, Chris Larson wrote:
On Wed, Jun 29, 2011 at 4:02 PM, Andreas Mueller schnitzelt...@gmx.de
wrote:
foo() {
# code to reuse
}
and called foo from several recipes. In oe-core the run.* scripts are
much more stripped of unnecessary. All the code included by 'require'
seems to miss, so the function foo() will not be found.
My searches for examples did not lead to a hook so what is the suggested
solution for reusing code for multiple recipes in oe-core?
The require doesn't have to do with anything. bitbake emits only the
functions which get called somewhere from the task being run. It
tracks what variables reference what other variables. If you call a
shell function from another shell function, it tracks this, and
realizes that both need to be emitted. Either you're doing something
wrong, or you're doing something in a way that bitbake can't track.
There's a variable flag you can set to explicitly add variable
dependencies.
There is an example of how to work around this in the rootfs_rpm.bbclass..
It's a bit odd, but it has to do with the way the function is called:
# Workaround so the parser knows we need the resolve_package
function! if false ; then
resolve_package_rpm foo ${RPMCONF_TARGET_BASE}.conf || true
fi
pkg_name=$(resolve_package_rpm $pkg-locale-$lang
${RPMCONF_TARGET_BASE}.conf)
So if the function is called within a subshell, the parser doesn't appear
to know it's there.. so you have to reference it in the function somewhere
(the if false works well for this) in order for it to be available to
call.
I'll try to understand that tomorrow z
Andreas
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] util-linux: Rebase remove-lscpu patch from non-gplv3
Signed-off-by: Saul Wold s...@linux.intel.com --- .../util-linux-2.19.1/remove-lscpu.patch | 120 ++- meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +- 2 files changed, 64 insertions(+), 58 deletions(-) diff --git a/meta/recipes-core/util-linux/util-linux-2.19.1/remove-lscpu.patch b/meta/recipes-core/util-linux/util-linux-2.19.1/remove-lscpu.patch index c726cf1..afa50f4 100644 --- a/meta/recipes-core/util-linux/util-linux-2.19.1/remove-lscpu.patch +++ b/meta/recipes-core/util-linux/util-linux-2.19.1/remove-lscpu.patch @@ -6,84 +6,90 @@ Take out lscpu stuff from the code Saul Wold saul.w...@intel.com Nitin A Kamble nitin.a.kam...@intel.com -Index: util-linux-ng-2.17.2/sys-utils/Makefile.am +Index: util-linux-2.19.1/sys-utils/Makefile.am === util-linux-ng-2.17.2.orig/sys-utils/Makefile.am -+++ util-linux-ng-2.17.2/sys-utils/Makefile.am -@@ -11,11 +11,11 @@ dist_man_MANS = flock.1 ipcrm.1 ipcs.1 i - if LINUX - bin_PROGRAMS += dmesg - sbin_PROGRAMS += ctrlaltdel --usrbin_exec_PROGRAMS += cytune setarch lscpu -+usrbin_exec_PROGRAMS += cytune setarch - usrsbin_exec_PROGRAMS += ldattach tunelp rtcwake - +--- util-linux-2.19.1.orig/sys-utils/Makefile.am 2011-04-05 03:43:02.0 -0700 util-linux-2.19.1/sys-utils/Makefile.am2011-06-29 12:08:24.187440334 -0700 +@@ -17,12 +17,6 @@ dist_man_MANS += dmesg.1 ctrlaltdel.8 cytune.8 setarch.8 \ -- ldattach.8 lscpu.1 tunelp.8 rtcwake.8 -+ ldattach.8 tunelp.8 rtcwake.8 + ldattach.8 tunelp.8 rtcwake.8 fsfreeze.8 fstrim.8 + +-if HAVE_CPU_SET_T +-usrbin_exec_PROGRAMS += lscpu +-lscpu_SOURCES = lscpu.c $(top_srcdir)/lib/cpuset.c +-dist_man_MANS += lscpu.1 +-endif +- endif cytune_SOURCES = cytune.c cyclades.h -Index: util-linux-ng-2.17.2/sys-utils/Makefile.in +Index: util-linux-2.19.1/sys-utils/Makefile.in === util-linux-ng-2.17.2.orig/sys-utils/Makefile.in -+++ util-linux-ng-2.17.2/sys-utils/Makefile.in -@@ -47,10 +47,10 @@ usrsbin_exec_PROGRAMS = readprofile$(EXE - $(am__EXEEXT_10) - @LINUX_TRUE@am__append_1 = dmesg - @LINUX_TRUE@am__append_2 = ctrlaltdel --@LINUX_TRUE@am__append_3 = cytune setarch lscpu -+@LINUX_TRUE@am__append_3 = cytune setarch - @LINUX_TRUE@am__append_4 = ldattach tunelp rtcwake +--- util-linux-2.19.1.orig/sys-utils/Makefile.in 2011-05-02 02:49:19.0 -0700 util-linux-2.19.1/sys-utils/Makefile.in2011-06-29 12:10:47.647440371 -0700 +@@ -51,8 +51,6 @@ @LINUX_TRUE@am__append_5 = dmesg.1 ctrlaltdel.8 cytune.8 setarch.8 \ --@LINUX_TRUE@ ldattach.8 lscpu.1 tunelp.8 rtcwake.8 -+@LINUX_TRUE@ ldattach.8 tunelp.8 rtcwake.8 + @LINUX_TRUE@ ldattach.8 tunelp.8 rtcwake.8 fsfreeze.8 fstrim.8 - @BUILD_FALLOCATE_TRUE@am__append_6 = fallocate - @BUILD_FALLOCATE_TRUE@am__append_7 = fallocate.1 -@@ -100,7 +100,7 @@ am__installdirs = $(DESTDIR)$(bindir) +-@HAVE_CPU_SET_T_TRUE@@LINUX_TRUE@am__append_6 = lscpu +-@HAVE_CPU_SET_T_TRUE@@LINUX_TRUE@am__append_7 = lscpu.1 + @BUILD_FALLOCATE_TRUE@am__append_8 = fallocate + @BUILD_FALLOCATE_TRUE@am__append_9 = fallocate.1 + @BUILD_PIVOT_ROOT_TRUE@am__append_10 = pivot_root +@@ -98,7 +96,6 @@ @BUILD_PIVOT_ROOT_TRUE@am__EXEEXT_4 = pivot_root$(EXEEXT) @BUILD_SWITCH_ROOT_TRUE@am__EXEEXT_5 = switch_root$(EXEEXT) - @LINUX_TRUE@am__EXEEXT_6 = cytune$(EXEEXT) setarch$(EXEEXT) \ --@LINUX_TRUE@ lscpu$(EXEEXT) -+@LINUX_TRUE@ - @BUILD_FALLOCATE_TRUE@am__EXEEXT_7 = fallocate$(EXEEXT) - @BUILD_UNSHARE_TRUE@am__EXEEXT_8 = unshare$(EXEEXT) - @LINUX_TRUE@am__EXEEXT_9 = ldattach$(EXEEXT) tunelp$(EXEEXT) \ -@@ -141,9 +141,6 @@ ipcs_LDADD = $(LDADD) + @LINUX_TRUE@am__EXEEXT_6 = cytune$(EXEEXT) setarch$(EXEEXT) +-@HAVE_CPU_SET_T_TRUE@@LINUX_TRUE@am__EXEEXT_7 = lscpu$(EXEEXT) + @BUILD_FALLOCATE_TRUE@am__EXEEXT_8 = fallocate$(EXEEXT) + @BUILD_UNSHARE_TRUE@am__EXEEXT_9 = unshare$(EXEEXT) + @LINUX_TRUE@am__EXEEXT_10 = ldattach$(EXEEXT) tunelp$(EXEEXT) \ +@@ -146,11 +143,6 @@ ldattach_SOURCES = ldattach.c ldattach_OBJECTS = ldattach.$(OBJEXT) ldattach_LDADD = $(LDADD) --lscpu_SOURCES = lscpu.c --lscpu_OBJECTS = lscpu.$(OBJEXT) +-am__lscpu_SOURCES_DIST = lscpu.c $(top_srcdir)/lib/cpuset.c +-@HAVE_CPU_SET_T_TRUE@@LINUX_TRUE@am_lscpu_OBJECTS = lscpu.$(OBJEXT) \ +-@HAVE_CPU_SET_T_TRUE@@LINUX_TRUE@ cpuset.$(OBJEXT) +-lscpu_OBJECTS = $(am_lscpu_OBJECTS) -lscpu_LDADD = $(LDADD) pivot_root_SOURCES = pivot_root.c pivot_root_OBJECTS = pivot_root.$(OBJEXT) pivot_root_LDADD = $(LDADD) -@@ -201,11 +198,11 @@ AM_V_GEN = $(am__v_GEN_$(V)) - am__v_GEN_ = $(am__v_GEN_$(AM_DEFAULT_VERBOSITY)) +@@ -206,13 +198,13 @@ am__v_GEN_0 = @echo GEN$@; - SOURCES = arch.c ctrlaltdel.c $(cytune_SOURCES) dmesg.c fallocate.c \ -- flock.c ipcmk.c ipcrm.c ipcs.c ldattach.c lscpu.c pivot_root.c \ -+ flock.c ipcmk.c ipcrm.c ipcs.c ldattach.c
Re: [OE-core] [PATCH 9/9] cmake: add nativesdk and target versions
On 06/17/2011 07:51 AM, Otavio Salvador wrote:
Adds a recipe that provides the nativesdk and target versions of
CMake.
This recipe is based on code from OpenEmbeeded (rev
b1f2e1501c19540617a829b37415c0616101c7ad).
Signed-off-by: Otavio Salvadorota...@ossystems.com.br
---
.../cmake/cmake/dont-run-cross-binaries.patch | 22 +
meta/recipes-devtools/cmake/cmake_2.8.3.bb | 48
2 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
create mode 100644 meta/recipes-devtools/cmake/cmake_2.8.3.bb
diff --git a/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
b/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
new file mode 100644
index 000..4eb1794
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
@@ -0,0 +1,22 @@
+cmake: don't run cross-binaries on host machine
+
+When doing the cross build we obviously cannot run those binaries on
+host since they can be binary incompatible.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Otavio Salvadorota...@ossystems.com.br
+
+diff -ru cmake-2.8.2.orig/CMakeLists.txt cmake-2.8.2/CMakeLists.txt
+--- cmake-2.8.2.orig/CMakeLists.txt2010-07-28 00:48:42.0 +0200
cmake-2.8.2/CMakeLists.txt 2010-07-28 01:05:17.0 +0200
+@@ -518,7 +518,8 @@
+
+ # build the remaining subdirectories
+ ADD_SUBDIRECTORY(Source)
+-ADD_SUBDIRECTORY(Utilities)
++# Come on! Running the cross-binaries on host is not a good idea.
++#ADD_SUBDIRECTORY(Utilities)
+ ADD_SUBDIRECTORY(Tests)
+
+ # add a test
diff --git a/meta/recipes-devtools/cmake/cmake_2.8.3.bb
b/meta/recipes-devtools/cmake/cmake_2.8.3.bb
new file mode 100644
index 000..93c98c3
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake_2.8.3.bb
@@ -0,0 +1,48 @@
+require cmake.inc
+
+inherit cmake
+
+DEPENDS += curl expat zlib libarchive ncurses
+
+PR = ${INC_PR}.0
+
+SRC_URI += file://dont-run-cross-binaries.patch
+
+SRC_URI[md5sum] = a76a44b93acf5e3badda9de111385921
+SRC_URI[sha256sum] =
689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288
+
+# Strip ${prefix} from ${docdir}, set result into docdir_stripped
+python () {
+prefix=bb.data.getVar(prefix, d, 1)
+docdir=bb.data.getVar(docdir, d, 1)
+
+if not docdir.startswith(prefix):
+ raise bb.build.FuncFailed('docdir must contain prefix as its prefix')
+
+docdir_stripped = docdir[len(prefix):]
+if len(docdir_stripped) 0 and docdir_stripped[0] == '/':
+ docdir_stripped = docdir_stripped[1:]
+
+bb.data.setVar(docdir_stripped, docdir_stripped, d)
+}
+
+EXTRA_OECMAKE= \
+-DCMAKE_DOC_DIR=${docdir_stripped}/cmake-${CMAKE_MAJOR_VERSION} \
+-DCMAKE_USE_SYSTEM_LIBRARIES=1 \
+# This is compiler target dependant, but it seems cmake does not in fact use
this value.
+-DKWSYS_CHAR_IS_SIGNED=1 \
+# This disables large file support. Hopefully nobody processes2G files on the
target.
+# If you want to enable this, add -DWKSYS_LFS_WORKS=1
+-DKWSYS_LFS_DISABLE=1 \
+
Otavio,
You can't embedded comments into variable setting like the above anymore.
Sau!
+
+# FIXME: Hack due gcc-crosssdk not being able to detect those automatically
+CXXFLAGS_virtclass-nativesdk += \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS} \
+
+
+FILES_${PN} += ${datadir}/cmake-${CMAKE_MAJOR_VERSION}
+FILES_${PN}-doc += ${docdir}/cmake-${CMAKE_MAJOR_VERSION}
+
+BBCLASSEXTEND = nativesdk
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
