Re: [OE-core] [PATCH 1/1] ncurses: Update to 5.9
On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote:
The previous 5.7 release was relatively close to 5.8 due to it bringing
in a patch to sync with upstream work-in-progress. We skip over the
5.8 release and move to 5.9.
there already are patches for 5.9 available too
ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz
Signed-off-by: Tom Rini tom_r...@mentor.com
---
.../{ncurses-5.7 = ncurses-5.9}/config.cache | 0
.../{ncurses-5.7 = ncurses-5.9}/tic-hang.patch | 0
.../ncurses/{ncurses_5.7.bb = ncurses_5.9.bb} | 21 +++
3 files changed, 4 insertions(+), 17 deletions(-)
rename meta/recipes-core/ncurses/{ncurses-5.7 = ncurses-5.9}/config.cache
(100%)
rename meta/recipes-core/ncurses/{ncurses-5.7 = ncurses-5.9}/tic-hang.patch
(100%)
rename meta/recipes-core/ncurses/{ncurses_5.7.bb = ncurses_5.9.bb} (88%)
diff --git a/meta/recipes-core/ncurses/ncurses-5.7/config.cache
b/meta/recipes-core/ncurses/ncurses-5.9/config.cache
similarity index 100%
rename from meta/recipes-core/ncurses/ncurses-5.7/config.cache
rename to meta/recipes-core/ncurses/ncurses-5.9/config.cache
diff --git a/meta/recipes-core/ncurses/ncurses-5.7/tic-hang.patch
b/meta/recipes-core/ncurses/ncurses-5.9/tic-hang.patch
similarity index 100%
rename from meta/recipes-core/ncurses/ncurses-5.7/tic-hang.patch
rename to meta/recipes-core/ncurses/ncurses-5.9/tic-hang.patch
diff --git a/meta/recipes-core/ncurses/ncurses_5.7.bb
b/meta/recipes-core/ncurses/ncurses_5.9.bb
similarity index 88%
rename from meta/recipes-core/ncurses/ncurses_5.7.bb
rename to meta/recipes-core/ncurses/ncurses_5.9.bb
index 7ab078d..9d4aa22 100644
--- a/meta/recipes-core/ncurses/ncurses_5.7.bb
+++ b/meta/recipes-core/ncurses/ncurses_5.9.bb
@@ -3,34 +3,21 @@ HOMEPAGE =
http://www.gnu.org/software/ncurses/ncurses.html;
LICENSE = MIT
LIC_FILES_CHKSUM =
file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc180a8c44ca642e97c35452fab5f66
SECTION = libs
-PATCHDATE = 20100501
-PKGV = ${PV}+${PATCHDATE}
-PR = r1
+PR = r0
DEPENDS = ncurses-native
DEPENDS_virtclass-native =
inherit autotools binconfig
-SRC_URI = ${GNU_MIRROR}/ncurses/ncurses-${PV}.tar.gz;name=tarball \
-
ftp://invisible-island.net/ncurses/5.7/ncurses-5.7-20100424-patch.sh.bz2;apply=yes;name=p20100424sh
\
-\
-
http://autobuilder.yoctoproject.org/sources/ncurses-5.7-${PATCHDATE}.patch.gz;name=p20100501
\
+SRC_URI = ${GNU_MIRROR}/ncurses/ncurses-${PV}.tar.gz \
file://tic-hang.patch \
file://config.cache \
+SRC_URI[md5sum] = 8cb9c412e5f2d96bc6f459aa8c6282a1
+SRC_URI[sha256sum] =
9046298fb440324c9d4135ecea7879ffed8546dd1b58e59430ea07a4633f563b
-#
ftp://invisible-island.net/ncurses/5.7/ncurses-5.7-${PATCHDATE}.patch.gz;name=p20100501
-
-SRC_URI[tarball.md5sum] = cce05daf61a64501ef6cd8da1f727ec6
-SRC_URI[tarball.sha256sum] =
0a9bdea5c7de8ded5c9327ed642915f2cc380753f12d4ad120ef7da3ea3498f4
-SRC_URI[p20100424sh.md5sum] = 3a5f76613f0f7ec3e0e73b835bc24864
-SRC_URI[p20100424sh.sha256sum] =
1e9d70d2d1fe1fea471868832c52f1b9cc6065132102e49e2a3755f2f4f5be53
-SRC_URI[p20100501.md5sum] = 6518cfa5d45e9069a1e042468161448b
-SRC_URI[p20100501.sha256sum] =
a97ccc30e4bd6fbb89564f3058db0fe84bd35cfefee831556c500793b477abde
-
-#PARALLEL_MAKE =
EXTRA_AUTORECONF = -I m4
CONFIG_SITE =+ ${WORKDIR}/config.cache
--
1.7.0.4
___
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 2/6] gst-meta-base: Support http/https remote streams
Op 5 apr 2011, om 23:48 heeft Saul Wold het volgende geschreven: From: Dongxiao Xu dongxiao...@intel.com Add libgstsouphttpsrc library to support remote stream playing via http/https protocols. This solves the mp4 playing issue by regel from mediatomb file server. Signed-off-by: Dongxiao Xu dongxiao...@intel.com -gst-plugins-good-autodetect +gst-plugins-good-autodetect \ +gst-plugins-good-souphttpsrc FWIW, souphttpsrc is quite heavy in dependencies, so in the future we should look for something lighter (GIO?). regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposed Multilib Implementation Brainstorming
Richard Purdie richard.pur...@linuxfoundation.org writes: One of the items on our post 1.0 schedule is multilib and we need a plan of implementation. I've been thinking about this for a while and at least have some ideas how some of the issues can be handled. Does this make sense to everyone, are there any questions/ objections/ concerns/ things I've missed? Which actual OE use-cases justify this kind of addition to OE? I know it is on the Yocto post 1.0 schedule, but is it actually a good thing for OE? Maintaining OE recipes is clearly not going to get any easier with multilibs support. /Esben ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposed Multilib Implementation Brainstorming
Op 5 apr 2011, om 13:02 heeft Richard Purdie het volgende geschreven: One of the items on our post 1.0 schedule is multilib and we need a plan of implementation. I've been thinking about this for a while and at least have some ideas how some of the issues can be handled. In case anyone isn't familiar with the idea of multilibs, the most common example are x86 systems which have both 32 bit and 64 bit libraries installed at the same time in /lib/ and /lib64/ directories or similar and hence both types of binaries can be used. The number of libs isn't limited to two choices as for example the mips platform has three choices which can be used in parallel. The x32 ABI would mean three possible x86 options too. Sweet, this opens the door for arm multilibs as well. With this can finally build an armv7a without NEON and with NEON in one go and use hwcaps to load the right lib. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposed Multilib Implementation Brainstorming
2011/4/5 Richard Purdie richard.pur...@linuxfoundation.org: [...] Does this make sense to everyone, are there any questions/ objections/ concerns/ things I've missed? I think most embedded systems would only use one lib. To take your lib/lib64 example: If I am developing for an embedded system I know whether it will run as 32 or 64 bit, so there is no need to have both. multilib has its merits when it comes to supporting multiple hardware systems. However as in the embedded world one is typically targeting a specific hardware configuration. (actually I don't recall having seen requests for multilib on the ML before, although I could have missed it). Also I'm somewhat worried by the actual complexity this adds (to the build process and the recipes, and timewise probably also to the bootstrap process as additional packages have to be built). Not sure if that is a desirable route forward, but if we (we as in OE members + developers) feel that OE should go that way, I would sugggest to have a way to opt-in or opt-out Frans ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/7] elfutils: fix builds with gcc 4.6
On Tue, 2011-04-05 at 10:03 -0700, Khem Raj wrote: On Tue, Apr 5, 2011 at 9:46 AM, Joshua Lock j...@linux.intel.com wrote: On Mon, 2011-04-04 at 18:58 -0700, Khem Raj wrote: On 4/1/2011 6:51 AM, Joshua Lock wrote: From: Joshua Lockj...@linux.intel.com gcc 4.6 (as used in Fedora 15) adds some extra warnings which are included with Werror. The new unused-but-set variable warning causes an error in libasm of elfutils. Work around this by removing unused-but-set from Werror. Signed-off-by: Joshua Lockj...@linux.intel.com --- meta/recipes-devtools/elfutils/elfutils_0.148.bb |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/meta/recipes-devtools/elfutils/elfutils_0.148.bb b/meta/recipes-devtools/elfutils/elfutils_0.148.bb index b2f700e..c395be8 100644 --- a/meta/recipes-devtools/elfutils/elfutils_0.148.bb +++ b/meta/recipes-devtools/elfutils/elfutils_0.148.bb @@ -40,6 +40,10 @@ SRC_URI += \ inherit autotools +# GCC 4.6.0 raises an unused-but-set warning in libasm, for now remove +# this warning from Werror +CFLAGS_virtclass-native += -Wno-error=unused-but-set-variable + unused-but-set-variable is a new option in gcc 4.6 which means this will cause problems with older gcc's as they wont recognize this option and not all distros have gcc 4.6 as base compiler. Have you tried compiling this patchset on a build machine which has older gcc ? say 4.5 I had not but thanks for pointing this out. I'll work up a new patch and make sure to test it on a machine with an older GCC. IMO either disabling Werror completely or fixing the problem are only two alternatives Agreed. I've gone the route of fixing the problem and have pulled in a series of patches from upstream. I haven't yet had the chance to test on GCC other than 4.6 but will send a pull request shortly. Regards, Joshua -- Joshua Lock Yocto Build System Monkey Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Fix elfutils-native with GCC 4.6
From: Joshua Lock j...@linux.intel.com Unfortunately I'm currently unable to test this on a machine with GCC version other than 4.6 but thought it was worth getting this patch out there as I'll be in the air and travelling until next week. Pull URL: git://git.openembedded.org/openembedded-core-contrib Branch: josh/elfutils Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/elfutils Thanks, Joshua Lock j...@linux.intel.com --- Joshua Lock (1): elfutils: remove unused variables to fix compilation with GCC 4.6 .../elfutils/elfutils-0.148/remove-unused.patch| 152 meta/recipes-devtools/elfutils/elfutils_0.148.bb |3 +- 2 files changed, 154 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-devtools/elfutils/elfutils-0.148/remove-unused.patch -- 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] [poky] Proposed Multilib Implementation Brainstorming
On Wed, 2011-04-06 at 09:08 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: One of the items on our post 1.0 schedule is multilib and we need a plan of implementation. I've been thinking about this for a while and at least have some ideas how some of the issues can be handled. Does this make sense to everyone, are there any questions/ objections/ concerns/ things I've missed? Which actual OE use-cases justify this kind of addition to OE? Several people wanting to use OECore have a requirement of multilib support. The typical embedded use case is where you have one main application which you might want to run in some kind of large memory mode or with some special optimisation (think a database engine) whilst the rest of the system is standard. This requires the ability to mix different libraries. I know it is on the Yocto post 1.0 schedule, but is it actually a good thing for OE? Maintaining OE recipes is clearly not going to get any easier with multilibs support. As detailed in the proposal you will see that the complexity added is minimal. It requires a simple enhancement to BBCLASSEXTEND which is likely desirable for other reasons too and that is the only real bitbake change required. For the metadata, individual recipes remain unaffected and also the core conf files are unchanged too. The toolchain dependency changes will be the only change affecting users at the recipe level and most of the class/machine configuration will be opt in by anyone using multilib. The only other invasive change is the package manager integration. For rpm, it has good support for multilib already and we're just enabling that. For opkg, we still need to determine the best approach but the simplistic approach I mentioned will probably suffice and anyone wanting true support at the package manager level can use rpm. For day to day recipe maintenance I don't see much direct impact. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] Proposed Multilib Implementation Brainstorming
Richard Purdie richard.pur...@linuxfoundation.org writes: On Wed, 2011-04-06 at 09:08 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: One of the items on our post 1.0 schedule is multilib and we need a plan of implementation. I've been thinking about this for a while and at least have some ideas how some of the issues can be handled. Does this make sense to everyone, are there any questions/ objections/ concerns/ things I've missed? Which actual OE use-cases justify this kind of addition to OE? Several people wanting to use OECore have a requirement of multilib support. Just out of curiosity, could you come with some examples of such people or projects? The typical embedded use case is where you have one main application which you might want to run in some kind of large memory mode or with some special optimisation (think a database engine) whilst the rest of the system is standard. This requires the ability to mix different libraries. I know it is on the Yocto post 1.0 schedule, but is it actually a good thing for OE? Maintaining OE recipes is clearly not going to get any easier with multilibs support. As detailed in the proposal you will see that the complexity added is minimal. It requires a simple enhancement to BBCLASSEXTEND which is likely desirable for other reasons too and that is the only real bitbake change required. For the metadata, individual recipes remain unaffected and also the core conf files are unchanged too. I thought that all recipes (fx. library recipes) involved in a multilib build must have the appropriate multilib parts put in BBCLASSEXTEND, and after that, anybody touch that recipe is suddenly faced with having to take care not to break multilib builds (which most developers probably will not really care for). The toolchain dependency changes will be the only change affecting users at the recipe level and most of the class/machine configuration will be opt in by anyone using multilib. The only other invasive change is the package manager integration. For rpm, it has good support for multilib already and we're just enabling that. For opkg, we still need to determine the best approach but the simplistic approach I mentioned will probably suffice and anyone wanting true support at the package manager level can use rpm. For day to day recipe maintenance I don't see much direct impact. I guess time will show... /Esben ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] Proposed Multilib Implementation Brainstorming
On Wed, 2011-04-06 at 14:16 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: On Wed, 2011-04-06 at 09:08 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: One of the items on our post 1.0 schedule is multilib and we need a plan of implementation. I've been thinking about this for a while and at least have some ideas how some of the issues can be handled. Does this make sense to everyone, are there any questions/ objections/ concerns/ things I've missed? Which actual OE use-cases justify this kind of addition to OE? Several people wanting to use OECore have a requirement of multilib support. Just out of curiosity, could you come with some examples of such people or projects? Well, you've seen Koen's reaction to the prospect of multilib support, there is one example. I've given x32 as another at the start of this thread. Its an issue I keep hearing about from companies too. Fundamentally, multilib is one of the biggest remaining weaknesses of the OE architecture. One of Yoctos objectives is to reduce the number of build systems out there and to do this, we need to make one good fully featured one. Until OE has multilib support there is a functionality gap. I don't see any technical reason OE can't support mulitlibs and I don't believe the complexity is high either, we just need to tweak some things. I actually believe the core in OE is well suited to multilib support and using it will show off some of the power in the OE architecture as I think we can do it better than anyone else before! I know it is on the Yocto post 1.0 schedule, but is it actually a good thing for OE? Maintaining OE recipes is clearly not going to get any easier with multilibs support. As detailed in the proposal you will see that the complexity added is minimal. It requires a simple enhancement to BBCLASSEXTEND which is likely desirable for other reasons too and that is the only real bitbake change required. For the metadata, individual recipes remain unaffected and also the core conf files are unchanged too. I thought that all recipes (fx. library recipes) involved in a multilib build must have the appropriate multilib parts put in BBCLASSEXTEND, and after that, anybody touch that recipe is suddenly faced with having to take care not to break multilib builds (which most developers probably will not really care for). The multilib conf files are responsible for changing BBCLASSEXTEND, I don't want to see the need for many, if any recipe specific changes. The recipe specific problems are likely to be limited to the likes of hardcoded library paths and those already break things like DISTRO=minimal in OE.dev today. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] Proposed Multilib Implementation Brainstorming
Richard Purdie richard.pur...@linuxfoundation.org writes: On Wed, 2011-04-06 at 14:16 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: On Wed, 2011-04-06 at 09:08 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: One of the items on our post 1.0 schedule is multilib and we need a plan of implementation. I've been thinking about this for a while and at least have some ideas how some of the issues can be handled. Does this make sense to everyone, are there any questions/ objections/ concerns/ things I've missed? Which actual OE use-cases justify this kind of addition to OE? Several people wanting to use OECore have a requirement of multilib support. Just out of curiosity, could you come with some examples of such people or projects? Well, you've seen Koen's reaction to the prospect of multilib support, there is one example. I've given x32 as another at the start of this thread. Its an issue I keep hearing about from companies too. Fundamentally, multilib is one of the biggest remaining weaknesses of the OE architecture. One of Yoctos objectives is to reduce the number of build systems out there and to do this, we need to make one good fully featured one. Until OE has multilib support there is a functionality gap. I don't see any technical reason OE can't support mulitlibs and I don't believe the complexity is high either, we just need to tweak some things. I actually believe the core in OE is well suited to multilib support and using it will show off some of the power in the OE architecture as I think we can do it better than anyone else before! The one thing that in my experience pushes most people in other directiosn than OE is the complexity. Unless OE made simpler, I think it will be quite hard to reach the goal of significantly reducing the number of build systems. I am uncertain to what effect multilib in OE will have (positive and negative), but it is clearly not making OE simpler. I just kind of makes things a bit ehmm... hopeless that the requests I (and others with similar customers) hear from companies are considered out of line for OE evolution, whereas the requests you and others hear can be used as valid arguments for which directions to take. It is not that I think it will add considerable burden, but is just yet another brick to the wall to pass for developers trying to understand OE. Anyways, you asked and I raised my concern. /Esben ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] Proposed Multilib Implementation Brainstorming
On Wed, 2011-04-06 at 15:21 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: On Wed, 2011-04-06 at 14:16 +0200, Esben Haabendal wrote: I actually believe the core in OE is well suited to multilib support and using it will show off some of the power in the OE architecture as I think we can do it better than anyone else before! The one thing that in my experience pushes most people in other directiosn than OE is the complexity. Unless OE made simpler, I think it will be quite hard to reach the goal of significantly reducing the number of build systems. I am uncertain to what effect multilib in OE will have (positive and negative), but it is clearly not making OE simpler. I just kind of makes things a bit ehmm... hopeless that the requests I (and others with similar customers) hear from companies are considered out of line for OE evolution, whereas the requests you and others hear can be used as valid arguments for which directions to take. It is not that I think it will add considerable burden, but is just yet another brick to the wall to pass for developers trying to understand OE. Nobody is saying requests for simplicity or ease of use are out of line, far from it. Its something that is being worked on by Yocto quite heavily. What does differ is the approach though, yours is to rip out anything you personally don't need, Yocto is taking a more reasoned approach to this and asking questions like: What can we do to make things easier for new users? Can we make error messages more user friendly? What code do we have that is needlessly complex and can be simplified? If we are going to add a new feature, how was we reuse existing established concepts? If something is complex and hard to understand but required, how can we document or better explain the concepts to people? I'd go as far as to say that things are getting more understandable and easier too. Yocto ran an alpha test programme where we took a selection of people, some with experience and some with no experience of embeddded, pointed them at the quick start guide and asked them to build an image, boot it and experiment. The results of this programme with Yocto 1.0 are orders of magnitude better than 0.9. This at least shows the new user experience is better than it was. Its not the only area that needs improvement and there is a long way to go but its a very positive start IMO. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposed Multilib Implementation Brainstorming
On Wed, 2011-04-06 at 10:47 +0200, Frans Meulenbroeks wrote: I think most embedded systems would only use one lib. To take your lib/lib64 example: If I am developing for an embedded system I know whether it will run as 32 or 64 bit, so there is no need to have both. I agree that this is the most common usecase and that remains unchanged. multilib has its merits when it comes to supporting multiple hardware systems. However as in the embedded world one is typically targeting a specific hardware configuration. (actually I don't recall having seen requests for multilib on the ML before, although I could have missed it). These have been requests I've received verbally in general but you'll see from the replies on the mailing list, Montavista is interested, Koen is as are a number of others. Also I'm somewhat worried by the actual complexity this adds (to the build process and the recipes, and timewise probably also to the bootstrap process as additional packages have to be built). Not sure if that is a desirable route forward, but if we (we as in OE members + developers) feel that OE should go that way, I would sugggest to have a way to opt-in or opt-out Multilib will be opt-in. Things will operate just as they do today unless you specify you want a multilib configuration. 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/1] ncurses: Update to 5.9
On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Update Qt4 to 4.7.2, security update
From: Paul Eggleton paul.eggle...@linux.intel.com Move Qt 4.7.x from 4.7.1 to 4.7.2 and apply security patch from OE. Pull URL: git://git.openembedded.org/openembedded-core-contrib Branch: paule/qt-4.7.2 Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qt-4.7.2 Thanks, Paul Eggleton paul.eggle...@linux.intel.com --- Denys Dmytriyenko (1): qt4: security advisory - blacklist fraudulent comodo certificates ...klist-fraudulent-comodo-certificates-patch.diff | 134 meta/recipes-qt/qt4/qt-4.6.3.inc |1 + meta/recipes-qt/qt4/qt-4.7.2.inc |1 + meta/recipes-qt/qt4/qt4-embedded_4.6.3.bb |2 +- meta/recipes-qt/qt4/qt4-embedded_4.7.2.bb |2 +- meta/recipes-qt/qt4/qt4-x11-free_4.6.3.bb |2 +- meta/recipes-qt/qt4/qt4-x11-free_4.7.2.bb |2 +- 7 files changed, 140 insertions(+), 4 deletions(-) create mode 100644 meta/recipes-qt/qt4/files/blacklist-fraudulent-comodo-certificates-patch.diff ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] qt4: security advisory - blacklist fraudulent comodo certificates
From: Denys Dmytriyenko de...@ti.com
Security advisory: Blacklist fraudulent certificates. More info is in the
patch and at the following links:
http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
http://qt.nokia.com/files/qt-patches/blacklist-fraudulent-comodo-certificates-patch.diff/view
(Imported from OE rev 61c1224c4f974f9185c2b93eeb19d13938af)
Signed-off-by: Denys Dmytriyenko de...@ti.com
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
...klist-fraudulent-comodo-certificates-patch.diff | 134
meta/recipes-qt/qt4/qt-4.6.3.inc |1 +
meta/recipes-qt/qt4/qt-4.7.2.inc |1 +
meta/recipes-qt/qt4/qt4-embedded_4.6.3.bb |2 +-
meta/recipes-qt/qt4/qt4-embedded_4.7.2.bb |2 +-
meta/recipes-qt/qt4/qt4-x11-free_4.6.3.bb |2 +-
meta/recipes-qt/qt4/qt4-x11-free_4.7.2.bb |2 +-
7 files changed, 140 insertions(+), 4 deletions(-)
create mode 100644
meta/recipes-qt/qt4/files/blacklist-fraudulent-comodo-certificates-patch.diff
diff --git
a/meta/recipes-qt/qt4/files/blacklist-fraudulent-comodo-certificates-patch.diff
b/meta/recipes-qt/qt4/files/blacklist-fraudulent-comodo-certificates-patch.diff
new file mode 100644
index 000..00faf75
--- /dev/null
+++
b/meta/recipes-qt/qt4/files/blacklist-fraudulent-comodo-certificates-patch.diff
@@ -0,0 +1,134 @@
+Security advisory: Fraudulent certificates
+
+Background:
+
+Recently a group of people managed to get fraudulent SSL certificates signed
+by a Certificate Authority (CA).
+
+These certificates potentially enable their owners to pretend to be other
+entities on the Web; the attackers can present valid certificates for e.g.
+mail.google.com, login.yahoo.com and login.live.com, among others.
+
+The patch below solves this problem by blacklisting those fake certificates
+and aborting an SSL handshake with entities that present these certificates.
+The patch applies to all 4.6 and 4.7 versions, and should be applied to all Qt
+4.6.x and 4.7.x versions; upcoming Qt releases will contain a fix for this
+problem.
+
+More technical background:
+
+In order to trick a user into establishing an SSL connection to a site using
+one of those fake certificates, in addition to controlling the certificate, an
+attacker would need to either control the DNS server used by the victim, or
+have control over a proxy that the victim uses. That way, the attacker could
+trick the victim to connect to the attacker?s site and then present the user
+with a valid certificate.
+
+One obvious question now is: Should those certificates not just be revoked,
+which would solve the problem?
+
+First, they have been revoked by the affected Certificate Authority (see above
+link).
+
+However, the problem in this case, and probably part of the reason why most
+browser vendors release new versions blacklisting those certificates, is that
+by default browsers do not treat invalid responses from an OCSP server (a
+server used for checking the revocation status of a certificate) as fatal, and
+will allow the SSL connection to proceed anyway. Qt itself does not support
+OCSP yet, which makes blacklisting the certificates the only valid option (now
+would be a good moment to vote on the task for implementing OCSP in Qt); since
+Qt is relying on the system root certificates since version 4.7, it cannot
+control the root certificates that Qt trusts automatically anymore.
+
+http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
+http://qt.nokia.com/files/qt-patches/blacklist-fraudulent-comodo-certificates-patch.diff/view
+
+diff --git a/src/network/ssl/qsslcertificate.cpp
b/src/network/ssl/qsslcertificate.cpp
+index 618ac79..a5cdf01 100644
+--- a/src/network/ssl/qsslcertificate.cpp
b/src/network/ssl/qsslcertificate.cpp
+@@ -219,17 +219,19 @@ bool QSslCertificate::isNull() const
+ Returns true if this certificate is valid; otherwise returns
+ false.
+
+-Note: Currently, this function only checks that the current
++Note: Currently, this function checks that the current
+ data-time is within the date-time range during which the
+-certificate is considered valid. No other checks are
+-currently performed.
++certificate is considered valid, and checks that the
++certificate is not in a blacklist of fraudulent certificates.
+
+ \sa isNull()
+ */
+ bool QSslCertificate::isValid() const
+ {
+ const QDateTime currentTime = QDateTime::currentDateTime();
+-return currentTime = d-notValidBefore currentTime =
d-notValidAfter;
++return currentTime = d-notValidBefore
++currentTime = d-notValidAfter
++! QSslCertificatePrivate::isBlacklisted(*this);
+ }
+
+ /*!
+@@ -798,6 +800,30 @@ QListQSslCertificate
QSslCertificatePrivate::certificatesFromDer(const QByteAr
+ return certificates;
+ }
+
++// These certificates are known to be fraudulent and were created during the
comodo
++//
Re: [OE-core] [PATCH 0/1] Fix elfutils-native with GCC 4.6
On Wed, 2011-04-06 at 12:10 +0100, Joshua Lock wrote: From: Joshua Lock j...@linux.intel.com Unfortunately I'm currently unable to test this on a machine with GCC version other than 4.6 but thought it was worth getting this patch out there as I'll be in the air and travelling until next week. Pull URL: git://git.openembedded.org/openembedded-core-contrib Branch: josh/elfutils Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/elfutils Thanks, Joshua Lock j...@linux.intel.com --- Joshua Lock (1): elfutils: remove unused variables to fix compilation with GCC 4.6 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] Consolidated Pull Request
On Tue, 2011-04-05 at 14:47 -0700, Saul Wold wrote: From: Saul Wold s...@linux.intel.com Richard, Here are a half dozen pull requests for oe-core and poky. Thanks Sau! Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: distro/oe-core Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=distro/oe-core Thanks, Saul Wold s...@linux.intel.com --- Dongxiao Xu (1): gst-meta-base: Support http/https remote streams Kang Kai (1): xdg-utils: add xdg-utils to pass the lsb test Mei Lei (1): distrodata.bbclass: Merge the get_pkg_info.log into checkpkg.csv Saul Wold (1): desktop-file-utils: Add SRC_URI checksums Scott Rifenbark (1): documentation/adt-manual/adt-eclipse.xml: Updated repo URL for Eclipse Plug-in Xiaofeng Yan (1): LSB_Setup.sh: Add function to install all test packages 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] [poky] Proposed Multilib Implementation Brainstorming
Richard Purdie richard.pur...@linuxfoundation.org writes: On Wed, 2011-04-06 at 15:21 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: On Wed, 2011-04-06 at 14:16 +0200, Esben Haabendal wrote: I actually believe the core in OE is well suited to multilib support and using it will show off some of the power in the OE architecture as I think we can do it better than anyone else before! The one thing that in my experience pushes most people in other directiosn than OE is the complexity. Unless OE made simpler, I think it will be quite hard to reach the goal of significantly reducing the number of build systems. I am uncertain to what effect multilib in OE will have (positive and negative), but it is clearly not making OE simpler. I just kind of makes things a bit ehmm... hopeless that the requests I (and others with similar customers) hear from companies are considered out of line for OE evolution, whereas the requests you and others hear can be used as valid arguments for which directions to take. It is not that I think it will add considerable burden, but is just yet another brick to the wall to pass for developers trying to understand OE. Nobody is saying requests for simplicity or ease of use are out of line, far from it. Its something that is being worked on by Yocto quite heavily. What does differ is the approach though, yours is to rip out anything you personally don't need, That's not fair. While I do rip out (to use your choice of colorful term) stuff in OE-lite, I do and did not proppose to rip out any features from OE. I did comment that sstate as a pice of code might not be give as much value if some of the concepts from OE-lite were implemented. Yocto is taking a more reasoned approach to this and asking questions like: Sorry, but I must take offence on that remark. I do not feel that your approach is anymore reasoned than mine. It is different, and you clearly prefer your approach, I don't question that. What can we do to make things easier for new users? Can we make error messages more user friendly? What code do we have that is needlessly complex and can be simplified? If we are going to add a new feature, how was we reuse existing established concepts? If something is complex and hard to understand but required, how can we document or better explain the concepts to people? I'd go as far as to say that things are getting more understandable and easier too. Yocto ran an alpha test programme where we took a selection of people, some with experience and some with no experience of embeddded, pointed them at the quick start guide and asked them to build an image, boot it and experiment. The results of this programme with Yocto 1.0 are orders of magnitude better than 0.9. This at least shows the new user experience is better than it was. Its not the only area that needs improvement and there is a long way to go but its a very positive start IMO. Yes, that is measuring Yocto user usability. I am at least as much concerned with long-time developer usability. Given the amount of long-time developers normally available in OE, I find it disappointing that at any time, almost noone (at most a very small handful) dares to comment on RFC's touch core parts, such as BitBake and gcc/glibc recipes. I am firmly convinced that we (whoever that might be) can do better than that. I also believe that this is one of the biggest reasons that there are so many embedded Linux buildsystems. Most people agrees that OE is among (if not the) most advanced embedded Linux build system, but many of them end up using some of the simpler tools. With careful design, and constant refactoring, I believe that you can lead in both features and simplicity, but you have to accept that code and design concepts will be discarded when something better turns up. /Esben ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] [PATCH 0/2] Update Qt4 to 4.7.2, security update
Op 6 apr 2011, om 16:57 heeft Paul Eggleton het volgende geschreven: From: Paul Eggleton paul.eggle...@linux.intel.com Move Qt 4.7.x from 4.7.1 to 4.7.2 and apply security patch from OE. Pull URL: git://git.openembedded.org/openembedded-core-contrib Branch: paule/qt-4.7.2 Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qt-4.7.2 I haven't tested it, but it looks good to me. ___ 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] ncurses: Update to 5.9
On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it -- Tom Rini Mentor Graphics Corporation ___ 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] ncurses: Update to 5.9
On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. -- Tom Rini Mentor Graphics Corporation ___ 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] ncurses: Update to 5.9
On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes -- Tom Rini Mentor Graphics Corporation ___ 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] ncurses: Update to 5.9
On 04/06/2011 10:26 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes That still leaves the problem of there not being a valid patch there at the moment. And I still don't see why ncurses needs to be in the bucket of recipes we track the scm for rather than relying on the latest stable release. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] Proposed Multilib Implementation Brainstorming
On Apr 6, 2011, at 7:29 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2011-04-06 at 10:47 +0200, Frans Meulenbroeks wrote: I think most embedded systems would only use one lib. To take your lib/lib64 example: If I am developing for an embedded system I know whether it will run as 32 or 64 bit, so there is no need to have both. I agree that this is the most common usecase and that remains unchanged. I'd like to stress that existing use-case behavior (non multilib) is imperative to keep the same as we have today. Multilib is a specialized use case that covers large enough space that it needs to be supported. multilib has its merits when it comes to supporting multiple hardware systems. However as in the embedded world one is typically targeting a specific hardware configuration. (actually I don't recall having seen requests for multilib on the ML before, although I could have missed it). These have been requests I've received verbally in general but you'll see from the replies on the mailing list, Montavista is interested, Koen is as are a number of others. I'll add Wind River has customers that directly need this functionality. Many of their products are similar to specialized servers, but really are embedded. Also I'm somewhat worried by the actual complexity this adds (to the build process and the recipes, and timewise probably also to the bootstrap process as additional packages have to be built). Not sure if that is a desirable route forward, but if we (we as in OE members + developers) feel that OE should go that way, I would sugggest to have a way to opt-in or opt-out Multilib will be opt-in. Things will operate just as they do today unless you specify you want a multilib configuration. Cheers, Richard ___ poky mailing list p...@yoctoproject.org https://lists.yoctoproject.org/listinfo/poky ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposed Multilib Implementation Brainstorming
On 04/06/2011 01:47 AM, Frans Meulenbroeks wrote: 2011/4/5 Richard Purdie richard.pur...@linuxfoundation.org: [...] Does this make sense to everyone, are there any questions/ objections/ concerns/ things I've missed? I think most embedded systems would only use one lib. To take your lib/lib64 example: If I am developing for an embedded system I know whether it will run as 32 or 64 bit, so there is no need to have both. What about the case of new 64bit hardware and legacy software that's still 32bit? This is a problem that embedded systems have and OE needs to support multilib has its merits when it comes to supporting multiple hardware systems. However as in the embedded world one is typically targeting a specific hardware configuration. (actually I don't recall having seen requests for multilib on the ML before, although I could have missed it). You missed it :) Roman Khimov posted a very basic thing years ago for dealing with the x86/x86_64 problem. Also I'm somewhat worried by the actual complexity this adds (to the build process and the recipes, and timewise probably also to the bootstrap process as additional packages have to be built). I agree, we do need to be careful to make sure the non-multilib case isn't made more difficult by all of this. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposed Multilib Implementation Brainstorming
A few comments to the original proposal below...
On Apr 5, 2011, at 2:24 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
One of the items on our post 1.0 schedule is multilib and we need a plan
of implementation. I've been thinking about this for a while and at
least have some ideas how some of the issues can be handled.
In case anyone isn't familiar with the idea of multilibs, the most
common example are x86 systems which have both 32 bit and 64 bit
libraries installed at the same time in /lib/ and /lib64/ directories or
similar and hence both types of binaries can be used.
The number of libs isn't limited to two choices as for example the mips
platform has three choices which can be used in parallel. The x32 ABI
would mean three possible x86 options too.
There are really two facets when people talk about multilibs. The first is
what is discussed above, incompatible ABI that are compatible in regards of
running on the same hardware and can be collocated within a single filesystem.
The other type of multilibs, common on ARM, is same ABI with different
optimizations, machine specific code.
Both types of multilibs need to be supported over time.
The first step is being able to build given recipes for each of a set of
given multilibs. This is very similar in principle to the way
BBCLASSEXTEND is used, the difference it that whilst the native or
nativesdk classes are used once, for multilib we need a kind of multiple
inheritance of a class assuming we don't want one class per multilib.
To do this I'm thinking of a new set of include files of the form
conf/machine/include/multilib-.inc, similar in nature to the
tune-xxx.inc files. A given setup would include each of the multilibs it
requred. Each multilib include file would look something like:
conf/machine/include/multilib-x86-lib32.inc:
MULTILIBS += lib32
BASE_PACKAGE_ARCH_virtclass-multilib-lib32 = core2-lib32
TARGET_CC_ARCH_virtclass-multilib-lib32 = -m32 -march=core2
PACKAGE_EXTRA_ARCHS += core2-lib32
libdir_virtclass-multilib-lib32 = ${exec_prefix}/lib32
base_libdir_virtclass-multilib-lib32 = ${base_prefix}/lib32
i.e. use overrides to change the target cc architecture specifying the
required flags to the compiler and also alter the library paths as
required.
I'm envisaging passing an optional new parameter to classes in
BBCLASSEXTEND so for example the definition of a multilib could look
something like:
BBCLASSEXTEND_append = multilib:x86-lib32
and all the multilib class would need to do is to manipulation of
variables including OVERRIDES in a similar way to native.bbclass with
the complication of handling the parameter.
One of the complications though is deciding what packages to build for which
multilibs. We will need a way to say the default system libraries and
components should be say 32-bit. But I need this one component to be 64-bit
The toolchain bootstrap process would become a little complicated by
this. We'll need to be able to iterate over the list of multilibs and
configure the compiler with a configuration appropriate to the multilibs
requested. The compiler should then take care of generating a suitable
libgcc for each multilib. Where the compiler currently depends on
virtual/libc-initial, we'll need with a function called to generate the
dependecies so for example: virtual/libc virtual/libc-initial-lib32
I think the toolchain bootstrap is a place where the implementation of the
toolchain can make this easier or MUCH harder. In the environments I am used
to using (code sorcery based toolchain) its a single binary that enables the
user to use many different multilibs. However, this is likely not the
best/easiest approach for source based toolchain builds. It's much easier for
use to just iteratively build toolchains for each multlib. Using unique
filenames can make this fairly easy to implement with minimal changes to the
recipes.
Using something more complex like the CS toolchains, you can do simply by
creating specific wrappers that call the base common toolchain with the right
parameters to switch the multlib settings..
The toolchain bootstrap process would hence become something like:
gcc-cross-initial
libc-initial
libc-initial-lib32
gcc-cross-intermediate
libc
libc-lib32
gcc-cross
libgcc (package)
libgcc-lib32 (package)
gcc-runtime
gcc-runtime-lib32
So for any multilib, we're stuck with always building the libc due to
the way gcc handles multilib. For subsequent tasks, only the libs
requested in a give image in a given ABI would be built.
Yes, when building multilibs there is a key set that has to exist before you
can build anything else. This normally includes libgcc, libstdcxx, and libc.
Otherwise general depenedencies can handle anything we need... But as
mentioned before we need to understand which items to build and use for
filesystem construction.
Note that as far as
Re: [OE-core] [PATCH 1/1] ncurses: Update to 5.9
On Wed, Apr 6, 2011 at 10:35 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:26 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes That still leaves the problem of there not being a valid patch there at the moment. And I still don't see why ncurses needs to be in the bucket of recipes we track the scm for rather than relying on the latest stable release. 5.9 was released few days back so that patch might be lean for now but I assume overtime it will get fatter -- Tom Rini Mentor Graphics Corporation ___ 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] ncurses: Update to 5.9
On 04/06/2011 11:27 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:35 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:26 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes That still leaves the problem of there not being a valid patch there at the moment. And I still don't see why ncurses needs to be in the bucket of recipes we track the scm for rather than relying on the latest stable release. 5.9 was released few days back so that patch might be lean for now but I assume overtime it will get fatter It's invalid at the moment, yes. But you haven't explained why ncurses needs to be in the bleeding edge bucket. Usually this is for stuff that hasn't really reached a stability point. -- Tom Rini Mentor Graphics Corporation ___ 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] ncurses: Update to 5.9
On Wed, Apr 6, 2011 at 11:29 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 11:27 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:35 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:26 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes That still leaves the problem of there not being a valid patch there at the moment. And I still don't see why ncurses needs to be in the bucket of recipes we track the scm for rather than relying on the latest stable release. 5.9 was released few days back so that patch might be lean for now but I assume overtime it will get fatter It's invalid at the moment, yes. But you haven't explained why ncurses needs to be in the bleeding edge bucket. Usually this is for stuff that hasn't really reached a stability point. It does not have to be but those patches are cumulative fixed that are done on top of a release. I am sure we will also run into the problems those will fix thats why its better to keep and eye on them -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposed Multilib Implementation Brainstorming
On 04/06/2011 11:26 AM, Hatle, Mark wrote: A few comments to the original proposal below... On Apr 5, 2011, at 2:24 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: [snip] and all the multilib class would need to do is to manipulation of variables including OVERRIDES in a similar way to native.bbclass with the complication of handling the parameter. One of the complications though is deciding what packages to build for which multilibs. We will need a way to say the default system libraries and components should be say 32-bit. But I need this one component to be 64-bit To be clear (and I think you agree), it also needs to be vice-versa (64bit except...) and rather arbitrary on what recipes get which treatment. The toolchain bootstrap process would become a little complicated by this. We'll need to be able to iterate over the list of multilibs and configure the compiler with a configuration appropriate to the multilibs requested. The compiler should then take care of generating a suitable libgcc for each multilib. Where the compiler currently depends on virtual/libc-initial, we'll need with a function called to generate the dependecies so for example: virtual/libc virtual/libc-initial-lib32 I think the toolchain bootstrap is a place where the implementation of the toolchain can make this easier or MUCH harder. In the environments I am used to using (code sorcery based toolchain) its a single binary that enables the user to use many different multilibs. However, this is likely not the best/easiest approach for source based toolchain builds. It's much easier for use to just iteratively build toolchains for each multlib. Using unique filenames can make this fairly easy to implement with minimal changes to the recipes. Using something more complex like the CS toolchains, you can do simply by creating specific wrappers that call the base common toolchain with the right parameters to switch the multlib settings.. Putting my community hat on, why not replicate what the CS folks do? Even with sstate and the yocto 1.1 goal of quicker builds, no one likes how long the toolchain bottleneck is. -- Tom Rini Mentor Graphics Corporation ___ 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] ncurses: Update to 5.9
On 04/06/2011 11:32 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 11:29 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 11:27 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:35 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:26 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes That still leaves the problem of there not being a valid patch there at the moment. And I still don't see why ncurses needs to be in the bucket of recipes we track the scm for rather than relying on the latest stable release. 5.9 was released few days back so that patch might be lean for now but I assume overtime it will get fatter It's invalid at the moment, yes. But you haven't explained why ncurses needs to be in the bleeding edge bucket. Usually this is for stuff that hasn't really reached a stability point. It does not have to be but those patches are cumulative fixed that are done on top of a release. I am sure we will also run into the problems those will fix thats why its better to keep and eye on them That can be said for just about every recipe we have. It sounds like you're suggesting we need _svn recipe or similar recipe for ncurses as well. I still don't see why ncurses is special in this regard and ask that when you see a worthwhile patch for ncurses 5.9 that you do another pull request. I'm just trying to keep oe-core in sync with openembedded.master. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/6] gst-meta-base: Support http/https remote streams
On Wed, 2011-04-06 at 09:11 +0200, Koen Kooi wrote: Op 5 apr 2011, om 23:48 heeft Saul Wold het volgende geschreven: From: Dongxiao Xu dongxiao...@intel.com Add libgstsouphttpsrc library to support remote stream playing via http/https protocols. This solves the mp4 playing issue by regel from mediatomb file server. Signed-off-by: Dongxiao Xu dongxiao...@intel.com -gst-plugins-good-autodetect +gst-plugins-good-autodetect \ +gst-plugins-good-souphttpsrc FWIW, souphttpsrc is quite heavy in dependencies, so in the future we should look for something lighter (GIO?). Sounds like a good plan. Does something already exist or does code need writing for that? 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/1] ncurses: Update to 5.9
On Tue, 2011-04-05 at 23:18 -0700, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Can someone summarise what the benefits of these patches are? I'm trying to figure out whether we lose anything due to this upgrade or not... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposed Multilib Implementation Brainstorming
On Tue, 2011-04-05 at 16:28 -0700, Jeremy Puhlman wrote:
To do this I'm thinking of a new set of include files of the form
conf/machine/include/multilib-.inc, similar in nature to the
tune-xxx.inc files. A given setup would include each of the multilibs it
requred. Each multilib include file would look something like:
conf/machine/include/multilib-x86-lib32.inc:
MULTILIBS += lib32
BASE_PACKAGE_ARCH_virtclass-multilib-lib32 = core2-lib32
TARGET_CC_ARCH_virtclass-multilib-lib32 = -m32 -march=core2
PACKAGE_EXTRA_ARCHS += core2-lib32
libdir_virtclass-multilib-lib32 = ${exec_prefix}/lib32
base_libdir_virtclass-multilib-lib32 = ${base_prefix}/lib32
i.e. use overrides to change the target cc architecture specifying the
required flags to the compiler and also alter the library paths as
required.
I'm envisaging passing an optional new parameter to classes in
BBCLASSEXTEND so for example the definition of a multilib could look
something like:
BBCLASSEXTEND_append = multilib:x86-lib32
and all the multilib class would need to do is to manipulation of
variables including OVERRIDES in a similar way to native.bbclass with
the complication of handling the parameter.
It is possible to do it with out changes to bitbake, but adding
parametrization to BBCLASSEXTEND would be useful in a number of ways,
and much more elegant then doing it with out it, and cleaner for that
matter. Unrelated to multilib, would the full path to the sub parameters
be configurable via the extended class? i.e. conf/machine/include/ be
a configurable value from the multilib class?
I've been thinking this would be the other way around. The act of adding
some conf/machine/include/* files would then trigger the inheritance of
the multilib class with the parameter specified at the point of the
inclusion.
For opkg there are multiple levels we can take the integration to. It
should be possible for example to install the weaker multilibs first,
then just install the stronger ones over the top, assuming any file
overwriting is ok and can be ignored.
If there isn't any kind of compartmentalization of binaries(i.e. the
alternate abi having a set of packages that only contian runtime libs),
wouldn't this render the package management on opkg based systems post
install largely useless other then just adding new components?
Its use case specific and I agree the above is hacky. It would be better
to have that option with known caveats that none at all though.
Most
applications are getting better about it(openssl comes to mind), but
some may still place arch specific headers in common locations. Many
like openssl started switching over to arch wrapper headers, but there
may be some stuff still lurking out there. Could probably be handled on
a case by case basis.
Yes, we've going to have to watch for this kind of issue and get it
fixed as and where we find it.
I have been kicking around a still broken POC implementation to this for
a bit, but this is basically the line of thought(minus the
parametrization of BBCLASSEXTEND) for a while on the subject. This looks
mostly right to me.
Great, thanks for the feedback!
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/1] ncurses: Update to 5.9
On 04/06/2011 11:38 AM, Richard Purdie wrote: On Tue, 2011-04-05 at 23:18 -0700, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Can someone summarise what the benefits of these patches are? I'm trying to figure out whether we lose anything due to this upgrade or not... The patches we applied to 5.7 are part of the 5.8 release and 5.9 of course replaces 5.8. The invisible-island.net patch sets are things taken from the official source repo and put out there for use. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] [PATCH 0/2] Update Qt4 to 4.7.2, security update
On Wed, 2011-04-06 at 15:57 +0100, Paul Eggleton wrote: From: Paul Eggleton paul.eggle...@linux.intel.com Move Qt 4.7.x from 4.7.1 to 4.7.2 and apply security patch from OE. Pull URL: git://git.openembedded.org/openembedded-core-contrib Branch: paule/qt-4.7.2 Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qt-4.7.2 Thanks, Paul Eggleton paul.eggle...@linux.intel.com --- Denys Dmytriyenko (1): qt4: security advisory - blacklist fraudulent comodo certificates Paul Eggleton (1): qt4: replace 4.7.1 with version 4.7.2 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 2/6] gst-meta-base: Support http/https remote streams
Op 6 apr. 2011 om 20:31 heeft Richard Purdie richard.pur...@linuxfoundation.org het volgende geschreven: On Wed, 2011-04-06 at 09:11 +0200, Koen Kooi wrote: Op 5 apr 2011, om 23:48 heeft Saul Wold het volgende geschreven: From: Dongxiao Xu dongxiao...@intel.com Add libgstsouphttpsrc library to support remote stream playing via http/https protocols. This solves the mp4 playing issue by regel from mediatomb file server. Signed-off-by: Dongxiao Xu dongxiao...@intel.com -gst-plugins-good-autodetect +gst-plugins-good-autodetect \ +gst-plugins-good-souphttpsrc FWIW, souphttpsrc is quite heavy in dependencies, so in the future we should look for something lighter (GIO?). Sounds like a good plan. Does something already exist or does code need writing for that? It has been over a year since I looked at it, but back then GIO used libsoup as backend, so doing http with gstreamer bloated up your product. I'll have a look at the current state when I get some time. regards, koen 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/1] ncurses: Update to 5.9
On Wed, Apr 6, 2011 at 11:38 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2011-04-05 at 23:18 -0700, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Can someone summarise what the benefits of these patches are? I'm trying to figure out whether we lose anything due to this upgrade or not... ftp://invisible-island.net/ncurses/5.9/README 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] [poky] Proposed Multilib Implementation Brainstorming
Hatle, Mark mark.ha...@windriver.com writes: On Apr 6, 2011, at 5:06 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2011-04-06 at 09:08 +0200, Esben Haabendal wrote: Richard Purdie richard.pur...@linuxfoundation.org writes: One of the items on our post 1.0 schedule is multilib and we need a plan of implementation. I've been thinking about this for a while and at least have some ideas how some of the issues can be handled. Does this make sense to everyone, are there any questions/ objections/ concerns/ things I've missed? Which actual OE use-cases justify this kind of addition to OE? Several people wanting to use OECore have a requirement of multilib support. The typical embedded use case is where you have one main application which you might want to run in some kind of large memory mode or with some special optimisation (think a database engine) whilst the rest of the system is standard. This requires the ability to mix different libraries. This is a very popular use-case in carrier grade systems. Back haul voice, data, etc applications that require large routing databases or billing databases. The other use I've seen for multilibs is some very specialized DVR systems where large amount of video need to stay in memory for quick retrieval. None of which really resembles the systems the typical OE developer is working on. My point being that what might be important goals for YP might not be equally important for community OE as such. Not that it necesarely is a real conflict, but I believe it is worth keeping in mind. I know it is on the Yocto post 1.0 schedule, but is it actually a good thing for OE? Maintaining OE recipes is clearly not going to get any easier with multilibs support. As detailed in the proposal you will see that the complexity added is minimal. It requires a simple enhancement to BBCLASSEXTEND which is likely desirable for other reasons too and that is the only real bitbake change required. For the metadata, individual recipes remain unaffected and also the core conf files are unchanged too. The toolchain dependency changes will be the only change affecting users at the recipe level and most of the class/machine configuration will be opt in by anyone using multilib. The only other invasive change is the package manager integration. For rpm, it has good support for multilib already and we're just enabling that. For opkg, we still need to determine the best approach but the simplistic approach I mentioned will probably suffice and anyone wanting true support at the package manager level can use rpm. For day to day recipe maintenance I don't see much direct impact. What I've seen in the past is the ability to build multilibs has improved the quality of the software integration by finding poorly constructed headers, hard coded library paths, etc... All things we should fix. Cannot really be against improving software quality :-) /Esben ___ 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] ncurses: Update to 5.9
On Wed, Apr 6, 2011 at 11:48 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 11:32 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 11:29 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 11:27 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:35 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:26 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes That still leaves the problem of there not being a valid patch there at the moment. And I still don't see why ncurses needs to be in the bucket of recipes we track the scm for rather than relying on the latest stable release. 5.9 was released few days back so that patch might be lean for now but I assume overtime it will get fatter It's invalid at the moment, yes. But you haven't explained why ncurses needs to be in the bleeding edge bucket. Usually this is for stuff that hasn't really reached a stability point. It does not have to be but those patches are cumulative fixed that are done on top of a release. I am sure we will also run into the problems those will fix thats why its better to keep and eye on them That can be said for just about every recipe we have. It sounds like you're suggesting we need _svn recipe or similar recipe for ncurses as well. I still don't see why ncurses is special in this regard and ask that when you see a worthwhile patch for ncurses 5.9 that you do another pull request. I'm just trying to keep oe-core in sync with openembedded.master. Those patches are not same as all patches that would be applied to say svn version these are fixes on top of a release e.g. 5.9 I was merely suggesting that your upgrade patch is fine please see if there already are some fixes on top of 5.9 that we need thats all -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] [PATCH 0/2] Update Qt4 to 4.7.2, security update
On 04/06/2011 07:57 AM, Paul Eggleton wrote:
From: Paul Eggletonpaul.eggle...@linux.intel.com
Move Qt 4.7.x from 4.7.1 to 4.7.2 and apply security patch from OE.
Paul could you please create or update the distro_tracking_fields.inc
file. Entries are needed for each recipe that has a distinct PN.
Please refer to this wiki page for details:
https://wiki.yoctoproject.org/wiki/Best_Known_Methods_%28BKMs%29_for_Package_Updating#Distro_Tracking_Fields
Thanks
Sau!
Pull URL: git://git.openembedded.org/openembedded-core-contrib
Branch: paule/qt-4.7.2
Browse:
http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qt-4.7.2
Thanks,
Paul Eggletonpaul.eggle...@linux.intel.com
---
Denys Dmytriyenko (1):
qt4: security advisory - blacklist fraudulent comodo certificates
Paul Eggleton (1):
qt4: replace 4.7.1 with version 4.7.2
...klist-fraudulent-comodo-certificates-patch.diff | 134
meta/recipes-qt/qt4/qt-4.6.3.inc |1 +
meta/recipes-qt/qt4/{qt-4.7.1.inc = qt-4.7.2.inc} |5 +-
.../0001-Added-Openembedded-crossarch-option.patch |0
.../recipes-qt/qt4/{qt-4.7.1 = qt-4.7.2}/g++.conf |0
.../hack-out-pg2-4.7.0.patch |0
.../qt4/{qt-4.7.1 = qt-4.7.2}/linux.conf |0
meta/recipes-qt/qt4/qt4-embedded_4.6.3.bb |2 +-
...qt4-embedded_4.7.1.bb = qt4-embedded_4.7.2.bb} |0
...s-native_4.7.1.bb = qt4-tools-native_4.7.2.bb} |4 +-
meta/recipes-qt/qt4/qt4-tools-nativesdk_4.7.1.bb |6 -
meta/recipes-qt/qt4/qt4-tools-nativesdk_4.7.2.bb |6 +
meta/recipes-qt/qt4/qt4-x11-free_4.6.3.bb |2 +-
...qt4-x11-free_4.7.1.bb = qt4-x11-free_4.7.2.bb} |0
14 files changed, 148 insertions(+), 12 deletions(-)
create mode 100644
meta/recipes-qt/qt4/files/blacklist-fraudulent-comodo-certificates-patch.diff
rename meta/recipes-qt/qt4/{qt-4.7.1.inc = qt-4.7.2.inc} (89%)
rename meta/recipes-qt/qt4/{qt-4.7.1 =
qt-4.7.2}/0001-Added-Openembedded-crossarch-option.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.7.1 = qt-4.7.2}/g++.conf (100%)
rename meta/recipes-qt/qt4/{qt-4.7.1 = qt-4.7.2}/hack-out-pg2-4.7.0.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.7.1 = qt-4.7.2}/linux.conf (100%)
rename meta/recipes-qt/qt4/{qt4-embedded_4.7.1.bb = qt4-embedded_4.7.2.bb}
(100%)
rename meta/recipes-qt/qt4/{qt4-tools-native_4.7.1.bb =
qt4-tools-native_4.7.2.bb} (61%)
delete mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.7.1.bb
create mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.7.2.bb
rename meta/recipes-qt/qt4/{qt4-x11-free_4.7.1.bb = qt4-x11-free_4.7.2.bb}
(100%)
___
poky mailing list
p...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/poky
___
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] ncurses: Update to 5.9
On Wed, 2011-04-06 at 10:35 -0700, Tom Rini wrote: On 04/06/2011 10:26 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes That still leaves the problem of there not being a valid patch there at the moment. And I still don't see why ncurses needs to be in the bucket of recipes we track the scm for rather than relying on the latest stable release. It sounds like these patches are more like tracking an SCM rather than a source of specific security patches or critical updates. I think it might be wise to note this location in the recipe as a comment (can someone please send an updated patch) but I don't think we should be including these patches by default, particular if upstream are making regular releases again. 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/1] ncurses: Update to 5.9
On 04/06/2011 02:16 PM, Richard Purdie wrote: On Wed, 2011-04-06 at 10:35 -0700, Tom Rini wrote: On 04/06/2011 10:26 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 10:10 AM, Tom Rini tom_r...@mentor.com wrote: On 04/06/2011 10:05 AM, Khem Raj wrote: On Wed, Apr 6, 2011 at 7:30 AM, Tom Rini tom_r...@mentor.com wrote: On 04/05/2011 11:18 PM, Khem Raj wrote: On Tue, Apr 5, 2011 at 5:38 PM, Tom Rini tom_r...@mentor.com wrote: The previous 5.7 release was relatively close to 5.8 due to it bringing in a patch to sync with upstream work-in-progress. We skip over the 5.8 release and move to 5.9. there already are patches for 5.9 available too ftp://invisible-island.net/ncurses/5.9/ncurses-5.9.patch.gz Wrong link? That reverse applies to ncurses 5.9 release. But regardless, is ncurses something we need to be tracking top of tree for? It seems like we needed to for 5.7 since there had been a lot going on without a release but that seems to have changed now. those patches usually contain critical bug fixes including security updates so it will be of interest to keep track of it Well, it doesn't currently. And while I agree we need to do a good job, everywhere, of keeping track of security updates, I don't think we should move back to depending on a site that frequently removes patches. yes. cache the patches like yocto did for 5.7 recipes That still leaves the problem of there not being a valid patch there at the moment. And I still don't see why ncurses needs to be in the bucket of recipes we track the scm for rather than relying on the latest stable release. It sounds like these patches are more like tracking an SCM rather than a source of specific security patches or critical updates. I think it might be wise to note this location in the recipe as a comment (can someone please send an updated patch) but I don't think we should be including these patches by default, particular if upstream are making regular releases again. I'll go v2 it -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] v2: Update ncurses
This updates ncurses to 5.9. While less of a deal for oe-core where we
had the patch we applied on top of 5.7 mirrored and referenced that
openembedded.master did not and the patch recently went away. Fortunately
there's now a 5.8 and 5.9 release of ncurses and our 5.7 + patch was
close to 5.8 making this an easy update. While at this we move most of
the important parts of ncurses_5.x.bb into ncurses.inc which has previously
been unused. Finally, we add a comment saying that invisible-island.net
may have useful additional patches.
Pull URL: git://git.openembedded.org/openembedded-core-contrib
Branch: trini/update-ncurses
Browse:
http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=trini/update-ncurses
Thanks,
Tom Rini tom_r...@mentor.com
---
Tom Rini (1):
ncurses: Update to 5.9
.../{ncurses-5.7 = ncurses-5.9}/config.cache |0
.../{ncurses-5.7 = ncurses-5.9}/tic-hang.patch|0
meta/recipes-core/ncurses/ncurses.inc | 256 +++-
meta/recipes-core/ncurses/ncurses_5.7.bb | 246 ---
meta/recipes-core/ncurses/ncurses_5.9.bb | 10 +
5 files changed, 204 insertions(+), 308 deletions(-)
rename meta/recipes-core/ncurses/{ncurses-5.7 = ncurses-5.9}/config.cache
(100%)
rename meta/recipes-core/ncurses/{ncurses-5.7 = ncurses-5.9}/tic-hang.patch
(100%)
delete mode 100644 meta/recipes-core/ncurses/ncurses_5.7.bb
create mode 100644 meta/recipes-core/ncurses/ncurses_5.9.bb
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] ncurses: Update to 5.9
The previous 5.7 release was relatively close to 5.8 due to it bringing
in a patch to sync with upstream work-in-progress. We skip over the
5.8 release and move to 5.9. Also, we move most of the contents of the
main recipe into the previously unused ncurses.inc file.
Signed-off-by: Tom Rini tom_r...@mentor.com
---
.../{ncurses-5.7 = ncurses-5.9}/config.cache |0
.../{ncurses-5.7 = ncurses-5.9}/tic-hang.patch|0
meta/recipes-core/ncurses/ncurses.inc | 256 +++-
meta/recipes-core/ncurses/ncurses_5.7.bb | 246 ---
meta/recipes-core/ncurses/ncurses_5.9.bb | 10 +
5 files changed, 204 insertions(+), 308 deletions(-)
rename meta/recipes-core/ncurses/{ncurses-5.7 = ncurses-5.9}/config.cache
(100%)
rename meta/recipes-core/ncurses/{ncurses-5.7 = ncurses-5.9}/tic-hang.patch
(100%)
delete mode 100644 meta/recipes-core/ncurses/ncurses_5.7.bb
create mode 100644 meta/recipes-core/ncurses/ncurses_5.9.bb
diff --git a/meta/recipes-core/ncurses/ncurses-5.7/config.cache
b/meta/recipes-core/ncurses/ncurses-5.9/config.cache
similarity index 100%
rename from meta/recipes-core/ncurses/ncurses-5.7/config.cache
rename to meta/recipes-core/ncurses/ncurses-5.9/config.cache
diff --git a/meta/recipes-core/ncurses/ncurses-5.7/tic-hang.patch
b/meta/recipes-core/ncurses/ncurses-5.9/tic-hang.patch
similarity index 100%
rename from meta/recipes-core/ncurses/ncurses-5.7/tic-hang.patch
rename to meta/recipes-core/ncurses/ncurses-5.9/tic-hang.patch
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index 3f897f6..e244eb8 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -2,7 +2,7 @@ SUMMARY = The New Curses library
DESCRIPTION = SVr4 and XSI-Curses compatible curses library and terminfo
tools including tic, infocmp, captoinfo. Supports color, multiple highlights,
forms-drawing characters, and automatic recognition of keypad and function-key
sequences. Extensions include resizable windows and mouse support on both xterm
and Linux console using the gpm library.
HOMEPAGE = http://www.gnu.org/software/ncurses/ncurses.html;
LICENSE = MIT
-LIC_FILES_CHKSUM =
file://ncurses/base/version.c;beginline=1;endline=27;md5=cf3c7ab00720a1b83391f49ea9956277
+LIC_FILES_CHKSUM =
file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc180a8c44ca642e97c35452fab5f66
SECTION = libs
DEPENDS = ncurses-native
DEPENDS_virtclass-native =
@@ -11,53 +11,121 @@ PACKAGES_append = ncurses-terminfo
FILES_ncurses_append = ${datadir}/tabset
RSUGGESTS_${PN} = ncurses-terminfo
RPROVIDES = libncurses5
+INC_PR = r0
-inherit autotools
+inherit autotools binconfig
-# This keeps only tput/tset in ncurses
-# clear/reset are in already busybox
-FILES_ncurses-tools = ${bindir}/tic ${bindir}/toe ${bindir}/infotocap
${bindir}/captoinfo ${bindir}/infocmp ${bindir}/clear.${PN}
${bindir}/reset.${PN} ${bindir}/tack
-FILES_ncurses-terminfo = ${datadir}/terminfo
-FILES_${PN} = ${bindir}/tput ${bindir}/tset ${libdir}/lib*.so.*
/usr/share/tabset /etc/terminfo
-
-PARALLEL_MAKE=
-
-FILESPATH =
${FILE_DIRNAME}/local:${FILE_DIRNAME}/ncurses-${PV}-${PR}:${FILE_DIRNAME}/ncurses-${PV}:${FILE_DIRNAME}/ncurses:${FILE_DIRNAME}
-
-EXTRA_OECONF = --with-shared \
---with-libtool \
- --without-profile \
- --without-debug \
- --disable-rpath \
- --enable-echo \
- --enable-const \
- --without-ada \
- --enable-termcap \
- --without-cxx-binding \
- --with-terminfo-dirs=${sysconfdir}/terminfo:${datadir}/terminfo
\
- --enable-overwrite \
- --with-build-ldflags='' \
- --with-build-ccflags=''
-export BUILD_CCFLAGS = -I${S}/ncurses -I${S}/include ${BUILD_CFLAGS}
-export BUILD_LDFLAGS =
-export EXTRA_OEMAKE = 'BUILD_LDFLAGS= BUILD_CCFLAGS=${BUILD_CCFLAGS}'
+# Upstream has useful patches at times at ftp://invisible-island.net/ncurses/
+SRC_URI = ${GNU_MIRROR}/ncurses/ncurses-${PV}.tar.gz
+
+EXTRA_AUTORECONF = -I m4
+CONFIG_SITE =+ ${WORKDIR}/config.cache
+
+# Whether to enable separate widec libraries; must be 'true' or 'false'
+#
+# TODO: remove this variable when widec is supported in every setup?
+ENABLE_WIDEC = true
+
+# _GNU_SOURCE is required for widec stuff and is detected automatically
+# for target objects. But it must be set manually for native and sdk
+# builds.
+BUILD_CPPFLAGS += -D_GNU_SOURCE
+
+# Override the function from the autotools class; ncurses requires a
+# patched autoconf213 to generate the configure script. This autoconf
+# is not available so that the shipped script will be used.
+do_configure() {
+# check does not work with cross-compiling and is generally
+# broken because it requires stdin to be pollable (which is
+# not the case for /dev/null redirections)
+
