Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
On Thu, Nov 04, 2010 at 06:47:52PM -0400, Denys Dmytriyenko wrote: On Thu, Nov 04, 2010 at 11:33:01PM +0100, Eric B?nard wrote: Hi, Le 04/11/2010 23:06, Denys Dmytriyenko a ?crit : On Thu, Nov 04, 2010 at 09:04:43PM +0100, Leon Woestenberg wrote: Hello all, at OEDEM we discussed the need for OpenEmbedded releases. - OpenEmbedded releases are planned in certain months, so that we can plan stabilization efforts in the future. - Each release is a point release in time. - A release is a candidate branch point for a stable branch (which can be maintained by those who use it). - The next release is planned 2010.12, more specifically December 1st. That's only four weeks from now. - The 2010.12 release is hand-picked from a recent testing branch. - OpenEmbedded releases are planned to be time based and happen every 3 month (quarterly), starting with the first one on December 1st. - what about a no major change freeze period for 2-3 weeks before each release to have a enough time to stabilize a little bit the beast ? I thought Leon kind of mentioned it in the first bullet point above, but probably not very clear. And yes, we definitely need a 2-3 weeks feature freeze period for stabilization. Thanks for pointing it out. what about branching future release those 2-3 weeks ago and keep master for active development? I know it could lower number of people using this future release branch during testing period before release, but still seems better then pushing 3 weeks of commits from my local branch as soon as release is branched and master open for new recipes again. Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Moving to layered structure of openembedded metadata
Hello. On Thu, 2010-11-04 at 21:00, Denys Dmytriyenko wrote: That is already being discussed and decided. See the following previous topics on the mailing list... To clear this up a bit. There can't be a real decision for now. Not all developers have been present at the OEDEM and we haven't discussed every detail their either. :) Most, if not all, people liked the idea during the OEDEM discussions, but we would need more input on problem that this may rise. As it stands I'm happy to see Khem coming up to put this on the ml. :) One I currently see is how we can keep it all working when the layers are maintained in different places and what kid of combinational explosion we will have with layers in different places. regards Stefan Schmidt ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] emacs alternative?
I posted here before to say that emacs in OE doesn't build on my machine as
the Makefile's being generated by autotools are being corrupted somehow. I've
not been able to get to the bottom of it at all.
I thought I saw a post here recently that mentioned an embedded version of an
emacs editor but can't find any such email. Maybe I imagined it. If anybody
knows of the alternative which does build or perhaps knows why the Makefile's
would be corrupted I'd be very glad to hear from you.
bitbake emacs gives me:
ERROR: Function do_compile failed
NOTE: Task failed: ('function do_compile failed',
'/home/john/programming/openmoko/shr/shr-unstable/tmp/work/armv4t-oe-linux-
gnueabi/emacs-22.3-r1/temp/log.do_compile.9130')
ERROR: Logfile of failure stored in: /home/john/programming/openmoko/shr/shr-
unstable/tmp/work/armv4t-oe-linux-gnueabi/emacs-22.3-
r1/temp/log.do_compile.9130
Log data follows:
| NOTE: make -j 4 QEMU=qemu-arm -s 1048576 -L
/home/john/programming/openmoko/shr/shr-unstable/tmp/work/armv4t-oe-linux-
gnueabi/emacs-22.3-r1/qemu-treedir
| cd lib-src; make all - --jobserver-fds=10,11 -j \
| CC='arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-
interwork -mthumb' CFLAGS='-isystem/home/john/programming/openmoko/shr/shr-
unstable/tmp/sysroots/armv4t-oe-linux-gnueabi/usr/include -fexpensive-
optimizations -fomit-frame-pointer -frename-registers -Os' CPPFLAGS='-
D_BSD_SOURCE -isystem/home/john/programming/openmoko/shr/shr-
unstable/tmp/sysroots/armv4t-oe-linux-gnueabi/usr/include' \
| LDFLAGS='-Wl,-O1 -Wl,--hash-style=gnu -Wl,-znocombreloc' MAKE='make'
| make[1]: Entering directory `/home/john/programming/openmoko/shr/shr-
unstable/tmp/work/armv4t-oe-linux-gnueabi/emacs-22.3-r1/emacs-22.3/lib-src'
| Makefile:149: *** commands commence before first target. Stop.
| make[1]: Leaving directory `/home/john/programming/openmoko/shr/shr-
unstable/tmp/work/armv4t-oe-linux-gnueabi/emacs-22.3-r1/emacs-22.3/lib-src'
| make: *** [lib-src] Error 2
| FATAL: oe_runmake failed
| ERROR: Function do_compile failed
NOTE: package emacs-22.3-r1: task do_compile: Failed
In the above output the emace-22.3 Makefile in /lib-src is failing at line 149.
The Makefile at that line contains:
ALL_CFLAGS = -D_BSD_SOURCE -DHAVE_CONFIG_H
-I. -I../src -I${srcdir} -I${srcdir}/../src ${LDFLAGS} ${CPPFLAGS}
${CFLAGS}
That is there are two lines but there should only be one. For some reason the
line is being split into two and make is interpreting the second line (149)
starting with -I as a command. Like the error says Make don't expect this
command before it's read a target for some sort. If I remove this error I'll
just move on to the next error where a new line has been inserted. There's a
few of them :-(
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] New e.V. members
Hello. On Tue, 2010-11-02 at 09:41, Stefan Schmidt wrote: If anyone of you is interest to get an e.V. member please let me know. I'm going to prepare a proposal to vote for new members next week. Just a reminder. Some people sent in their proposal already. If you want to be on the list on Tuesday as well please let me know until monday. regards Stefan Schmidt ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] emacs alternative?
On Fri, Nov 05, 2010 at 07:35:25AM +, captain.dea...@gmail.com wrote: I posted here before to say that emacs in OE doesn't build on my machine as the Makefile's being generated by autotools are being corrupted somehow. I've not been able to get to the bottom of it at all. http://article.gmane.org/gmane.comp.handhelds.shr.devel/3131/match=mg and emacs-x11_23.1.bb builds in SHR feeds just fine (so you can look there for patches needed by emacs_22.3 - probably emacs-x11-23.1/configure.in.lost.backslashes.patch). Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] gphoto2_2.4.8.bb: Stop configure from looking in /usr/local/include
2010/11/3 Khem Raj raj.k...@gmail.com: On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/11/3 Khem Raj raj.k...@gmail.com: On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/11/3 Khem Raj raj.k...@gmail.com: yes a more detailed solution is better. you have to go through the configure of every package and understand the behavior then act upon. As I said before its a tedious task I'm well aware of this. That is also why in the infrastructure thread I suggested using automated testing to find misbehaving packages. Btw there are 355 .inc files that contain the word autotools and 1899 .bb files. Of course there are lots of dups in there. And maybe for the base recipes we can convince the yocto people that this is a serious QA issue (and they have some people employed to work on this if I understood properly). numbers means not so much when it comes down to this. I don't know if any distribution that even does that so I take comfort in everyone being wrong. I agree that numbers don't mean that much. Just wanted to give an indication of the possible effort needed. Also no idea how debian does this. Does it do it in first place ? I peeked briefly at the sources. Debian seems to resolve the problem by going for the max dependencies so autotools can pick up everything. E.g. for gphoto2, lenny has a depends on both libexif and libreadline (see http://packages.debian.org/lenny/gphoto2) So basically they go for the max config. We could do the same. Then again for deeply embedded systems it might be desirable to allow more finegrained tuning. (did I hear someone say USE flags ? ) Enjoy! Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Moving to layered structure of openembedded metadata
2010/11/5 Stefan Schmidt ste...@datenfreihafen.org: Hello. On Thu, 2010-11-04 at 21:00, Denys Dmytriyenko wrote: That is already being discussed and decided. See the following previous topics on the mailing list... To clear this up a bit. There can't be a real decision for now. Not all developers have been present at the OEDEM and we haven't discussed every detail their either. :) Most, if not all, people liked the idea during the OEDEM discussions, but we would need more input on problem that this may rise. As it stands I'm happy to see Khem coming up to put this on the ml. :) One I currently see is how we can keep it all working when the layers are maintained in different places and what kid of combinational explosion we will have with layers in different places. Good points! To keep things working I feel it is important to minimize the inter layer dependencies (and make the ones that exist explicit). My suggestion is that every layer has a maintainer/custodian/owner or whatever name you want to give it who is responsible to keep the layer in good shape. Presumably this means we get a structure where there are two versions of a layer: the last validated/integrated/accepted one and the working one. Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] emacs alternative?
On Friday 05 November 2010 07:44:09 Martin Jansa wrote: On Fri, Nov 05, 2010 at 07:35:25AM +, captain.dea...@gmail.com wrote: I posted here before to say that emacs in OE doesn't build on my machine as the Makefile's being generated by autotools are being corrupted somehow. I've not been able to get to the bottom of it at all. http://article.gmane.org/gmane.comp.handhelds.shr.devel/3131/match=mg and emacs-x11_23.1.bb builds in SHR feeds just fine (so you can look there for patches needed by emacs_22.3 - probably emacs-x11-23.1/configure.in.lost.backslashes.patch). Regards, Thanks for that I was trying to build the plain emacs without x and having those problems. x11 version does work so thanks for the pointer. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
Leon Woestenberg ha scritto, Il 04/11/2010 21:04: Hello all, at OEDEM we discussed the need for OpenEmbedded releases. - OpenEmbedded releases are planned in certain months, so that we can plan stabilization efforts in the future. - Each release is a point release in time. - A release is a candidate branch point for a stable branch (which can be maintained by those who use it). - The next release is planned 2010.12, more specifically December 1st. That's only four weeks from now. - The 2010.12 release is hand-picked from a recent testing branch. Now that our testing team has the process in place to gather test results, please consider to build your favorite set of distro/machine targets using tinderbox, and report your results. One requirement is to use bitbake 1.10, as the minimal requirement will soon be 1.10 for the OpenEmbedded metadata. Regards, Thank you Leon I am going to insert my KaeilOS distro tests ASAP Cordiali Saluti / Kindest Regards / mit freundlichen Grüssen -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Atmel third party certified consultant Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com http://www.KaeilOS.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
Le 05/11/2010 07:52, Martin Jansa a écrit : what about branching future release those 2-3 weeks ago and keep master for active development? Stabilizing the master branch is active development as this allows to have stronger fundation for the next features you can introduce 2 or 3 weeks after the stabilization weeks starts. I know it could lower number of people using this future release branch during testing period before release, but still seems better then pushing 3 weeks of commits from my local branch as soon as release is branched and master open for new recipes again. That's the way linux, u-boot co are running and when the new merge window opens several thousand of patches can be merged in a few days. If we don't do that, the idea of stable release which implies detecting and fixing potential failures introduced by previous big changes will fail. Eric ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH/RFC] qt4-embedded: tune QT_ARCH for armv6
On 11/04/2010 08:14 PM, Eric Bénard wrote: Hi, ill it be? in the painting engine, from what I saw in the .h, the asm optimisations are only enabled when using ARM RCVT compiler and not when using gcc but I have not checked everywhere in the code so I'm not sure of this. that is something else, I also have a partially applied C implementation that appears to be faster than the brute force armv6 code. One benefit of using armv6 is that the atomic code will use a different implementation (ldrex,strex IIRC instead of swp). In any case please use something like qttracereply to see if passing armv6 is giving any benefit at all. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] testing branch 2010-11-04
2010/11/4 Cliff Brake cliff.br...@gmail.com: Had a decent run with testing last week as a number of combinations built: http://cgit.openembedded.org/cgit.cgi/openembedded/tag/?id=tested_2010-10-29 testing-next is ready for clean builds. testing branch has been moved forward to last weeks testing-next. For more information on testing, please see: http://wiki.openembedded.org/index.php/Testing#Testing_Log Thanks, Cliff Thanks Cliff. As requested I have added my testing script to the tree. (contrib/testing/testscript.sh ) It is just pushed so it does not appear in this weeks testing-next branch. http://wiki.openembedded.net/index.php/TestingScript Feel free to improve! Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
On Fri, Nov 05, 2010 at 10:22:38AM +0100, Eric Bénard wrote: Le 05/11/2010 07:52, Martin Jansa a écrit : what about branching future release those 2-3 weeks ago and keep master for active development? no new recipes during at least last week of stablizing was also proposed http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-November/026552.html Stabilizing the master branch is active development as this allows to have stronger fundation for the next features you can introduce 2 or 3 weeks after the stabilization weeks starts. I agree but pushing new recipes to master and cherry-picking of fixes from master to next release would also work and even allow testing of fix.patch in master before cherry-picking it. I know it could lower number of people using this future release branch during testing period before release, but still seems better then pushing 3 weeks of commits from my local branch as soon as release is branched and master open for new recipes again. That's the way linux, u-boot co are running and when the new merge window opens several thousand of patches can be merged in a few days. And also why there is linux-next, but I agree that in our scale we can keep new recipes and features in local checkouts/out-of-tree branches without too much pain in merging them after 3 weeks. If we don't do that, the idea of stable release which implies detecting and fixing potential failures introduced by previous big changes will fail. IMHO forcing main branch to be closed for new stuff (gcc branches after stage1, before opening stage1 for new version) is used mostly to force developers to use branch which is supposed to become stable without tracking only the latest. But as I said before I don't mind (much) keeping new recipes locally for those few weeks or even pay more attention to my not-embedded-related daywork instead of playing with OE :). Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] packaged-staging
Tom and Chris, Thanks for your replies, things are more clear now. With kind regards, Fabrice I *think* bitbake 1.8 should be fine with packaged staging, its the more recent OE that's critical :) Fabrice, you may want to look at the Testing page on the OE wiki and the testing branch as a starting point, as its a bit more tested version of master. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
Hi, Le 05/11/2010 10:49, Martin Jansa a écrit : I know it could lower number of people using this future release branch during testing period before release, but still seems better then pushing 3 weeks of commits from my local branch as soon as release is branched and master open for new recipes again. That's the way linux, u-boot co are running and when the new merge window opens several thousand of patches can be merged in a few days. And also why there is linux-next, but I agree that in our scale we can keep new recipes and features in local checkouts/out-of-tree branches without too much pain in merging them after 3 weeks. a temporary next branch could be open to host new big patches and then merged to master once stable is out. This way most peoples getting oe during the stabilization period will get master and will test it and developers will be able to follow their development in the next branch. I think that during this stabilization weeks, developers have to do the effort to checkout the next branch if they want to work on it and user must get the master branch being stabilized as a default, but not the reverse. Eric ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH/RFC] qt4-embedded: tune QT_ARCH for armv6
Le 05/11/2010 11:21, Holger Freyther a écrit : On 11/05/2010 10:42 AM, Eric Bénard wrote: Hi, OK where is the code you are talking about in qt ? tool/qttracereply. 1.) record a trace (e.g. the qtdemo) you will need Qt/X11 for that (desktop, device). But make sure that the qtdemo width/height fits on the screen. Does this option works for qtembedded (I don't have X11 on my boards) ? $ qttdemo -graphicssystem trace (exit the app normally) 2.) Use qttracereply to replay the trace, it will print nice FPS data. One thing : what I see here is that qtdemo was crashing after a random time and now (with armv6) it runs stable for hours. well, not very scientific. :) not at all ;) Eric ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] libX11: patch configure.ac so a nios2 system is not seen as an os2 system.
2010/11/5 Paul Menzel paulepan...@users.sourceforge.net: Am Freitag, den 05.11.2010, 14:19 +0100 schrieb Frans Meulenbroeks: 2010/11/5 Paul Menzel paulepan...@users.sourceforge.net: Am Freitag, den 05.11.2010, 13:08 +0100 schrieb Frans Meulenbroeks: configure.ac matches target_system against *os2* to detect if we're configuring for an os2 system. Unfortunately this also matches if the target_system is nios-linux (which is not an os2 system :-) ) This patch adds an additional case. The patch is added to the individual recipes and also made upstream. Please add a link to this commit message and the patch headers pointing to the upstream commit, list message or ticket. Patch is tested by fully building 1.3.2 and by running bitbake -c patch for the other recipes. Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com a--- .../xorg-lib/libx11-1.1.5/configure.ac-nios2.patch | 12 .../xorg-lib/libx11-1.3.2/configure.ac-nios2.patch | 12 .../xorg-lib/libx11-1.3.6/configure.ac-nios2.patch | 12 .../libx11-1.3.99.903/configure.ac-nios2.patch | 12 recipes/xorg-lib/libx11_1.1.5.bb | 3 ++- recipes/xorg-lib/libx11_1.3.2.bb | 3 ++- recipes/xorg-lib/libx11_1.3.6.bb | 3 ++- recipes/xorg-lib/libx11_1.3.99.903.bb | 3 ++- 8 files changed, 56 insertions(+), 4 deletions(-) create mode 100644 recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch create mode 100644 recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch create mode 100644 recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch create mode 100644 recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch diff --git a/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch b/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch new file mode 100644 index 000..5605a59 --- /dev/null +++ b/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch @@ -0,0 +1,12 @@ +Index: libX11-1.3.2/configure.ac +=== +--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100 libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100 +@@ -202,6 +202,7 @@ + # arch specific things + WCHAR32=1 + case $target_alias in ++ nios2*) os2=false ;; + *os2*) os2=true ; WCHAR32=0 ;; + *) ;; + esac It looks like these three patches are exactly the same. Would one file in the version independent directory be enough? […] They are exactly the same. I discussed this with Martin Jansa on irc, and we felt it would be best to submit the patch upstream. I agree. Then if it is in the inc file, it needs to be taken out again when the next version comes. Sorry, I did not make myself clear. My point was if you could put `configure.ac-nios2.patch` into `libX11/` or `files`. Yes. files is not too nice, libX11 is probably better Hence it was put in the individual files. BTW it looks like upstream might go for a slightly different patch. I'll leave it to Martin to decide whether to go for that one or for this one (he is on cc of the upstream correspondence). Again, could you provide a link to that discussion. http://lists.freedesktop.org/archives/xorg/2010-November/051731.html I'll be afk next week so can't give followup on this. Understood. Thank you for your fast reply. You thanks for your review work! It is not often said, but it is definitely appreciated. Frans Thanks, Paul ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Release 2010.12 --- needs your help!
On Fri, Nov 05, 2010 at 02:32:18PM +0100, Paul Menzel wrote: Dear OE folks, Am Freitag, den 05.11.2010, 11:03 +0100 schrieb Eric Bénard: Le 05/11/2010 10:49, Martin Jansa a écrit : I know it could lower number of people using this future release branch during testing period before release, but still seems better then pushing 3 weeks of commits from my local branch as soon as release is branched and master open for new recipes again. That's the way linux, u-boot co are running and when the new merge window opens several thousand of patches can be merged in a few days. And also why there is linux-next, but I agree that in our scale we can keep new recipes and features in local checkouts/out-of-tree branches without too much pain in merging them after 3 weeks. a temporary next branch could be open to host new big patches and then merged to master once stable is out. I certainly would encourage to push your changes to the OE repository as soon as possible to share your work so other can use it or improve it. Be it `master` or some different branch. I have gitorious repo for my patch queue (but that's always rebased on top of master - to keep the diff small and changes ready for easy cherry-pick from it). This way most peoples getting oe during the stabilization period will get master and will test it and developers will be able to follow their development in the next branch. I think that during this stabilization weeks, developers have to do the effort to checkout the next branch if they want to work on it and user must get the master branch being stabilized as a default, but not the reverse. I guess both sides have good arguments. I would decide on what the documentation suggests to beginners and new contributors. If it suggests that `master` is the development branch new contributions should be based on, I suggest to create a new branch for the next stable release. If the documentation suggests something different, then the next stable release can be based on the master branch. In either case the documentation has to be correct or needs to be updated to reflect the changes. Well if it goes to master-next, then will we rebase it on top of current master (and solve ie that PR bump because of new feature in master-next needs another PR bump, because there was PR bump in current master due to some small fix). Or will we just merge current master to it and resolve conflicts there and then when stabilizing ends, merge master-next back to master with all those ugly merge+resolve commits? On the otherside if there is release branch created asap it's quite easy that cherry-picked fix from master has newer PR changed (and edit it to change it only by 1). But it will also force release maintainers to push patch first to master and then cherry-pick. Also whoever will be using master just to test next released version should be really carefull not to call git pull after it is taged as release and branched (or he will get stuff from maybe already merged master-next). So both ways have pros and cons, depends if you look at it as master-next developer or release maintainer :). Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] libX11: patch configure.ac so a nios2 system is not seen as an os2 system.
Am Freitag, den 05.11.2010, 14:38 +0100 schrieb Martin Jansa:
On Fri, Nov 05, 2010 at 02:26:48PM +0100, Paul Menzel wrote:
I agree.
Then if it is in the inc file, it needs to be taken out again when the
next version comes.
Sorry, I did not make myself clear. My point was if you could put
`configure.ac-nios2.patch` into `libX11/` or `files`.
better not to use files at all
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-October/025673.html
Correct. I forgot.
diet-x11_1.1.5.bb libx11-trim_1.1.5.bb will find it ok in libx11* dir,
because of FILESPATHPKG .= :libx11-${PV}:libx11 in libx11.inc
but even when it's the same file I would keep it in separate dirs,
because newer versions won't need it (hopefully) and then it will be
removed with older versions.
That is a valid argument. Although then patches should never be share
between versions unless there is no upstream development anymore?
It is fine either way by me. So do as you prefer.
Hence it was put in the individual files.
BTW it looks like upstream might go for a slightly different patch.
I'll leave it to Martin to decide whether to go for that one or for
this one (he is on cc of the upstream correspondence).
Again, could you provide a link to that discussion.
http://lists.freedesktop.org/archives/xorg/2010-November/051731.html
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] TSC Discussions from 2010/11/03
On Fri, Nov 05, 2010 at 12:16:54AM +, Richard Purdie wrote:
Hi,
The TSC met yesterday and discussed various topics. We're trying a
slightly different approach to recording the outcome of the discussions:
http://wiki.openembedded.org/index.php/TSCDecisions
and the output from 5 such discussions yesterday is recorded there.
These were all things that had discussion by the TSC pending after
OEDEM.
Just idea for last point about FILESPATH:
It isn't tested and bitbake's Local fetcher localpath still
needs FILESPATH or similar change.
Just to show what I meant in:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-October/025673.html
Regards,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
From a3c0a5af9640a6c9395e3747fbcff288020b2355 Mon Sep 17 00:00:00 2001
From: Martin Jansa martin.ja...@gmail.com
Date: Fri, 5 Nov 2010 15:47:25 +0100
Subject: [PATCH] base.bbclass: test for FILESPATHPKG existence first, then try
FILESPATHOVERRIDES
---
classes/base.bbclass | 15 +--
conf/bitbake.conf|3 ++-
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/classes/base.bbclass b/classes/base.bbclass
index fd507d3..a1f65a9 100644
--- a/classes/base.bbclass
+++ b/classes/base.bbclass
@@ -203,18 +203,21 @@ python base_do_unpack() {
if not src_uri:
return
srcurldata = bb.fetch.init(src_uri.split(), d, True)
-filespath = d.getVar(FILESPATH, True).split(:)
+filespathlist = d.getVar(FILESPATHLIST, True).split(:)
+filespathoverrides = d.getVar(FILESPATHOVERRIDES, True).split(:)
for url in src_uri.split():
urldata = srcurldata[url]
if urldata.type == file and * in urldata.path:
# The fetch code doesn't know how to handle globs, so
# we need to handle the local bits ourselves
-for path in filespath:
-srcdir = oe.path.join(path, urldata.host,
- os.path.dirname(urldata.path))
-if os.path.exists(srcdir):
-break
+for path in filespathlist:
+if os.path.exists(path):
+for override in filespathoverrides:
+srcdir = oe.path.join(path, override, urldata.host,
+ os.path.dirname(urldata.path))
+if os.path.exists(srcdir):
+break
else:
bb.fatal(Unable to locate files for %s % url)
diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 177e0b3..e623281 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -271,7 +271,8 @@ FILES_${PN}-locale = ${datadir}/locale
FILE_DIRNAME = $...@os.path.dirname(bb.data.getVar('FILE', d))}
FILESPATHBASE = ${FILE_DIRNAME}
FILESPATHPKG = ${PF}:${P}:${PN}:${BP}:${BPN}:files:.
-FILESPATH = ${@':'.join(uniq(os.path.normpath(os.path.join(fp, p, o)) for fp
in '${FILESPATHBASE}'.split(':') for p in '${FILESPATHPKG}'.split(':') for o in
reversed([''] + filter(None, '${OVERRIDES}'.split(':')}
+FILESPATHOVERRIDES =
${MACHINE}:${DISTRO}:${TARGET_ARCH}:{BASE_PACKAGE_ARCH}:.
+FILESPATHLIST = ${@':'.join(uniq(os.path.normpath(os.path.join(fp, p)) for fp
in '${FILESPATHBASE}'.split(':') for p in '${FILESPATHPKG}'.split(':')))}
FILESDIR = $...@bb.which(d.getVar('FILESPATH', 1), '.')}
##
--
1.7.3.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] libX11: patch configure.ac so a nios2 system is not seen as an os2 system.
On Fri, Nov 5, 2010 at 5:08 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
configure.ac matches target_system against *os2* to detect if we're
configuring for an os2 system. Unfortunately this also matches if the
target_system is nios-linux (which is not an os2 system :-) )
This patch adds an additional case. The patch is added to the individual
recipes and also made upstream.
Patch is tested by fully building 1.3.2 and by running
bitbake -c patch for the other recipes.
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
Hmmm good find. I am ok with general fix. but please consider other
review comments before you commit
Acked-by: Khem Raj raj.k...@gmail.com
---
.../xorg-lib/libx11-1.1.5/configure.ac-nios2.patch | 12
.../xorg-lib/libx11-1.3.2/configure.ac-nios2.patch | 12
.../xorg-lib/libx11-1.3.6/configure.ac-nios2.patch | 12
.../libx11-1.3.99.903/configure.ac-nios2.patch | 12
recipes/xorg-lib/libx11_1.1.5.bb | 3 ++-
recipes/xorg-lib/libx11_1.3.2.bb | 3 ++-
recipes/xorg-lib/libx11_1.3.6.bb | 3 ++-
recipes/xorg-lib/libx11_1.3.99.903.bb | 3 ++-
8 files changed, 56 insertions(+), 4 deletions(-)
create mode 100644 recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch
create mode 100644 recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch
create mode 100644 recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch
create mode 100644
recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch
diff --git a/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch
b/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch
new file mode 100644
index 000..5605a59
--- /dev/null
+++ b/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.3.2/configure.ac
+===
+--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100
libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100
+@@ -202,6 +202,7 @@
+ # arch specific things
+ WCHAR32=1
+ case $target_alias in
++ nios2*) os2=false ;;
+ *os2*) os2=true ; WCHAR32=0 ;;
+ *) ;;
+ esac
diff --git a/recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch
b/recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch
new file mode 100644
index 000..5605a59
--- /dev/null
+++ b/recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.3.2/configure.ac
+===
+--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100
libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100
+@@ -202,6 +202,7 @@
+ # arch specific things
+ WCHAR32=1
+ case $target_alias in
++ nios2*) os2=false ;;
+ *os2*) os2=true ; WCHAR32=0 ;;
+ *) ;;
+ esac
diff --git a/recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch
b/recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch
new file mode 100644
index 000..5605a59
--- /dev/null
+++ b/recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.3.2/configure.ac
+===
+--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100
libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100
+@@ -202,6 +202,7 @@
+ # arch specific things
+ WCHAR32=1
+ case $target_alias in
++ nios2*) os2=false ;;
+ *os2*) os2=true ; WCHAR32=0 ;;
+ *) ;;
+ esac
diff --git a/recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch
b/recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch
new file mode 100644
index 000..5605a59
--- /dev/null
+++ b/recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.3.2/configure.ac
+===
+--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100
libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100
+@@ -202,6 +202,7 @@
+ # arch specific things
+ WCHAR32=1
+ case $target_alias in
++ nios2*) os2=false ;;
+ *os2*) os2=true ; WCHAR32=0 ;;
+ *) ;;
+ esac
diff --git a/recipes/xorg-lib/libx11_1.1.5.bb
b/recipes/xorg-lib/libx11_1.1.5.bb
index e775585..b44dcc8 100644
--- a/recipes/xorg-lib/libx11_1.1.5.bb
+++ b/recipes/xorg-lib/libx11_1.1.5.bb
@@ -1,7 +1,8 @@
require libx11.inc
DEPENDS = ${COMMON_DEPENDS}
-PR = ${INC_PR}.1
+PR = ${INC_PR}.2
+SRC_URI += file://configure.ac-nios2.patch
SRC_URI[archive.md5sum] = d1512d65dadd4f48c779d4749e7753a8
SRC_URI[archive.sha256sum] =
da9272900e41615e9c5dc25d84730b8966da6f5c8f4c40418dca2ad040fc8b82
diff --git a/recipes/xorg-lib/libx11_1.3.2.bb
b/recipes/xorg-lib/libx11_1.3.2.bb
index b3d48ab..189d1ff
Re: [oe] [PATCH] gphoto2_2.4.8.bb: Stop configure from looking in /usr/local/include
On Fri, Nov 5, 2010 at 12:51 AM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/11/3 Khem Raj raj.k...@gmail.com: On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/11/3 Khem Raj raj.k...@gmail.com: On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/11/3 Khem Raj raj.k...@gmail.com: yes a more detailed solution is better. you have to go through the configure of every package and understand the behavior then act upon. As I said before its a tedious task I'm well aware of this. That is also why in the infrastructure thread I suggested using automated testing to find misbehaving packages. Btw there are 355 .inc files that contain the word autotools and 1899 .bb files. Of course there are lots of dups in there. And maybe for the base recipes we can convince the yocto people that this is a serious QA issue (and they have some people employed to work on this if I understood properly). numbers means not so much when it comes down to this. I don't know if any distribution that even does that so I take comfort in everyone being wrong. I agree that numbers don't mean that much. Just wanted to give an indication of the possible effort needed. Also no idea how debian does this. Does it do it in first place ? I peeked briefly at the sources. Debian seems to resolve the problem by going for the max dependencies so autotools can pick up everything. E.g. for gphoto2, lenny has a depends on both libexif and libreadline (see http://packages.debian.org/lenny/gphoto2) So basically they go for the max config. We could do the same. Then again for deeply embedded systems it might be desirable to allow more finegrained tuning. (did I hear someone say USE flags ? ) which is good for things that dont care about size. Not so good for embedded systems I think. and there are some packages I know which have catch-22 situation so adding max depends is also not a wholesome solution. Enjoy! Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] dm355_codecs_03_10_00_00.tar.gz
Hi, i try to install the recipe ti-codecs-dm355_3.10.00.00.bb: MACHINE=dm355-leopard bitbake -b ti-codecs-dm355_3.10.00.00.bb I get the following error: kl...@ubuntu:~/development/oe$ MACHINE=dm355-leopard bitbake -b ti-codecs-dm355_3.10.00.00.bb NOTE: preferred version 1_13_000 of ti-codecs-dm355 not available (for item ti-codecs-dm355) Build Configuration: BB_VERSION= 1.8.18 METADATA_BRANCH = master METADATA_REVISION = a33cf7368366d425c71369339e88a50d5660b7c0 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = dm355-leopard DISTRO= angstrom DISTRO_VERSION= 2010.7-test-20101104 TARGET_FPU= soft NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 2 of 17 (ID: 8, /home/klaus/development/oe/openembedded/recipes/ti/ti-codecs-dm355_3.10.00.00.bb, do_fetch) NOTE: fetch ftp://gtftp01.gt.design.ti.com/arago/dm355_codecs_03_10_00_00.tar.gz --2010-11-04 20:28:42-- ftp://gtftp01.gt.design.ti.com/arago/dm355_codecs_03_10_00_00.tar.gz = `/home/klaus/development/oe/downloads/dm355_codecs_03_10_00_00.tar.gz' Resolving gtftp01.gt.design.ti.com... failed: Name or service not known. wget: unable to resolve host address `gtftp01.gt.design.ti.com' NOTE: fetch http://mirrors.openembedded.org//dm355_codecs_03_10_00_00.tar.gz --2010-11-04 20:28:42-- http://mirrors.openembedded.org//dm355_codecs_03_10_00_00.tar.gz Resolving mirrors.openembedded.org... 82.197.159.157 Connecting to mirrors.openembedded.org|82.197.159.157|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2010-11-04 20:28:42 ERROR 404: Not Found. NOTE: fetch http://sources.openembedded.org//dm355_codecs_03_10_00_00.tar.gz --2010-11-04 20:28:43-- http://sources.openembedded.org//dm355_codecs_03_10_00_00.tar.gz Resolving sources.openembedded.org... 140.211.169.165 Connecting to sources.openembedded.org|140.211.169.165|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2010-11-04 20:28:43 ERROR 404: Not Found. NOTE: fetch http://www.angstrom-distribution.org/unstable/sources/dm355_codecs_03_10_00_00.tar.gz --2010-11-04 20:28:43-- http://www.angstrom-distribution.org/unstable/sources/dm355_codecs_03_10_00_00.tar.gz Resolving www.angstrom-distribution.org... 188.40.83.200 Connecting to www.angstrom-distribution.org|188.40.83.200|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2010-11-04 20:28:43 ERROR 404: Not Found. NOTE: Task failed: Fetch failed: ftp://gtftp01.gt.design.ti.com/arago/dm355_codecs_03_10_00_00.tar.gz;name=dm355codecsbin ERROR: TaskFailed event exception, aborting ERROR: Build of /home/klaus/development/oe/openembedded/recipes/ti/ti-codecs-dm355_3.10.00.00.bb do_fetch failed ERROR: Task 8 (/home/klaus/development/oe/openembedded/recipes/ti/ti-codecs-dm355_3.10.00.00.bb, do_fetch) failed NOTE: Tasks Summary: Attempted 1 tasks of which 1 didn't need to be rerun and 1 failed. ERROR: '/home/klaus/development/oe/openembedded/recipes/ti/ti-codecs-dm355_3.10.00.00.bb' failed kl...@ubuntu:~/development/oe$ Where is the file? Is the recipe to old? Thanks! Regards, Klaus -- Sensortherm GmbH Sitz:/Head quarter: Hauptstraße 123, 65843 Sulzbach (Taunus) Registergericht:/Registry office: Amtsgericht Frankfurt/M. Eintragungs-Nr.:/Registry-No. HRB 52438 Geschäftsführer:/General Manager: Werner Weldert ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] postgresql-8.1.8 : fix configure on x86
Without this patch, postgres fails on configure:
| checking alignment of int... configure: error: cannot compute alignment of
int, 77
NOTE: package postgresql-8.1.8-r4: task do_configure: Failed
Similar fix for arm was in 5fa3d153.
Signed-off-by: Bob Foerster rob...@erafx.com
---
site/ix86-common |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/site/ix86-common b/site/ix86-common
index 5323c7a..8a4a4c3 100644
--- a/site/ix86-common
+++ b/site/ix86-common
@@ -202,6 +202,13 @@
rsync_cv_HAVE_SECURE_MKSTEMP=${rsync_cv_HAVE_SECURE_MKSTEMP=yes}
rsync_cv_REPLACE_INET_NTOA=${rsync_cv_REPLACE_INET_NTOA=no}
rsync_cv_REPLACE_INET_ATON=${rsync_cv_REPLACE_INET_ATON=no}
+# postgresql
+pgac_cv_alignof_short=2
+pgac_cv_alignof_int=4
+pgac_cv_alignof_long=4
+pgac_cv_alignof_long_long_int=8
+pgac_cv_alignof_double=8
+
# samba
samba_cv_HAVE_GETTIMEOFDAY_TZ=${samba_cv_HAVE_GETTIMEOFDAY_TZ=yes}
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] OpenEmbedded and the Yocto Project
I've talked to various people and I think the point has come to write down my thoughts rather than repeat conversations with various people. Sorry if this ends up as a long email. I'm on record in the past for commenting on the number of build system presentations at ELC-E in 2009. The embedded community has several of them, all with advantages and disadvantages, I look at this and wonder why we couldn't have one good one. You also wonder why there is no focus point fostering embedded Linux tools in general, everyone loves to go off and do their own thing as its easier than working together. It was based on these observations and a desire to improve the situation, I proposed the idea of what has become the Yocto project. Intel doesn't want to own Yocto, it realises that to create this one good build system for example, it needs other people to be involved. This is why the Linux Foundation now owns the rights to Poky and the Yocto Project. Yes, it been seeded by Intel/Wind River people and by Poky, not OpenEmbedded. The simple reason is that these are the things could be donated to the project, OpenEmbedded is not something the Linux Foundation can take ownership of, nor should it be. There are many interesting facets to the Yocto project and I will cover some of them below later as I don't think people are seeing them yet but I know what most readers are interested in here so getting to the heart of the matter, OpenEmbedded and Poky. OpenEmbedded has always intended itself to be useful to companies to build products off and to become an all purpose fully featured build system and development tool. It does many things well, I love it for what it is and I've spent over half a decade working on it in various ways which I'd never have done that if I didn't believe in the architecture. When it comes to using OE commercially, its actually quite hard. If you look at even the big companies using OE like TI, Mentor and Montavista to name but a few, whilst they are using it, there are significant changes they need to make to turn it into a commercial product. Those changes and stabilisation are eating a lot of the developer resources they put in and there is arguably a comparatively low amount of feature development being worked upon. If somehow we could share some of that effort, it would free up resources for feature development. So what do I mean by hard? First there are the conversations with your legal department where some questions arise: * How do you ensure license compliance? * When someone makes a change, how do you know the license is still correct? * You've mixing GPLv2 and v3? How are you ensuring no contamination? cue a long discussion which I'd bet most companies have Bottom line is that the contributions process to OE is not sufficient to be acceptable to most companies legal departments. Sure, instead of Yocto, Intel and Wind River could each have some internal version of OE which we'd vet changes to and I suspect Montavista and Mentor at least already have this but its not very open source and it duplicates a lot of work. So the end result is that the Yocto project has totally vetted the LICENSE data in Poky, any new additions go through a set of checks before they be allowed into the repository and we also have some automated process/tools enhancements such as the licence checksums to catch changes to licenses more easily. So that is one area, second is one of development and releases. OE has never had one, it may have one soon, we'll see but so far its never happened. Releases are important in many ways as they give people something to plan expectations against. Currently OE is always active development, there is never any calm down before a release, switch to bug fixing mode rather than enhancement and so forth. This means if you develop a BSP layer, which version of OE can you state it works with? End result is that Yocto/Poky have a states release cycle, approximately six months. We have releases, BSPs can be made against the last release. When planning people can know roughly what state the tree will be in at a given time and whilst no timeline is perfect for everyone, its well defined and people can adapt to it. Third is a QA problem and one of size and scale. Realistically, there is no way you can test OE as its just too large with too many combinations. On the other hand we have a pretty good known test matrix for Poky/Yocto as its a smaller set of data than OE. If we want to expand that set, we're prepared to as long as there is contribution to help test it too (additional autobuilder machines and QA resource). We do appreciate the value of the additional things OE contains however and also realise the value in additional machine support. This is why the Yocto project has done work to make layers work better and become usable for additional topic metadata layers and also machine support in the form of BSPs. This neatly allows people to take ownership of subsets of the
Re: [oe] postgresql-8.1.8 : fix configure on x86
On Friday, November 5, 2010 at 9:06 AM, Bob Foerster wrote: Without this patch, postgres fails on configure:| checking alignment of int... configure: error: cannot compute alignment of int, 77NOTE: package postgresql-8.1.8-r4: task do_configure: FailedSimilar fix for arm was in 5fa3d153.Signed-off-by: Bob Foerster rob...@erafx.comAcked-by: Christopher Larson chris_lar...@mentor.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] dm355_codecs_03_10_00_00.tar.gz
On 11/05/2010 11:08 AM, Klaus Schwarzkopf wrote: Hi, i try to install the recipe ti-codecs-dm355_3.10.00.00.bb: MACHINE=dm355-leopard bitbake -b ti-codecs-dm355_3.10.00.00.bb I get the following error: kl...@ubuntu:~/development/oe$ MACHINE=dm355-leopard bitbake -b ti-codecs-dm355_3.10.00.00.bb NOTE: preferred version 1_13_000 of ti-codecs-dm355 not available (for item ti-codecs-dm355) Build Configuration: BB_VERSION= 1.8.18 METADATA_BRANCH = master METADATA_REVISION = a33cf7368366d425c71369339e88a50d5660b7c0 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = dm355-leopard DISTRO= angstrom DISTRO_VERSION= 2010.7-test-20101104 TARGET_FPU= soft NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 2 of 17 (ID: 8, /home/klaus/development/oe/openembedded/recipes/ti/ti-codecs-dm355_3.10.00.00.bb, do_fetch) NOTE: fetch ftp://gtftp01.gt.design.ti.com/arago/dm355_codecs_03_10_00_00.tar.gz --2010-11-04 20:28:42-- ftp://gtftp01.gt.design.ti.com/arago/dm355_codecs_03_10_00_00.tar.gz = `/home/klaus/development/oe/downloads/dm355_codecs_03_10_00_00.tar.gz' Resolving gtftp01.gt.design.ti.com... failed: Name or service not known. wget: unable to resolve host address `gtftp01.gt.design.ti.com' NOTE: fetch http://mirrors.openembedded.org//dm355_codecs_03_10_00_00.tar.gz --2010-11-04 20:28:42-- http://mirrors.openembedded.org//dm355_codecs_03_10_00_00.tar.gz Resolving mirrors.openembedded.org... 82.197.159.157 Connecting to mirrors.openembedded.org|82.197.159.157|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2010-11-04 20:28:42 ERROR 404: Not Found. NOTE: fetch http://sources.openembedded.org//dm355_codecs_03_10_00_00.tar.gz --2010-11-04 20:28:43-- http://sources.openembedded.org//dm355_codecs_03_10_00_00.tar.gz Resolving sources.openembedded.org... 140.211.169.165 Connecting to sources.openembedded.org|140.211.169.165|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2010-11-04 20:28:43 ERROR 404: Not Found. NOTE: fetch http://www.angstrom-distribution.org/unstable/sources/dm355_codecs_03_10_00_00.tar.gz --2010-11-04 20:28:43-- http://www.angstrom-distribution.org/unstable/sources/dm355_codecs_03_10_00_00.tar.gz Resolving www.angstrom-distribution.org... 188.40.83.200 Connecting to www.angstrom-distribution.org|188.40.83.200|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2010-11-04 20:28:43 ERROR 404: Not Found. NOTE: Task failed: Fetch failed: ftp://gtftp01.gt.design.ti.com/arago/dm355_codecs_03_10_00_00.tar.gz;name=dm355codecsbin ERROR: TaskFailed event exception, aborting ERROR: Build of /home/klaus/development/oe/openembedded/recipes/ti/ti-codecs-dm355_3.10.00.00.bb do_fetch failed ERROR: Task 8 (/home/klaus/development/oe/openembedded/recipes/ti/ti-codecs-dm355_3.10.00.00.bb, do_fetch) failed NOTE: Tasks Summary: Attempted 1 tasks of which 1 didn't need to be rerun and 1 failed. ERROR: '/home/klaus/development/oe/openembedded/recipes/ti/ti-codecs-dm355_3.10.00.00.bb' failed kl...@ubuntu:~/development/oe$ Where is the file? Is the recipe to old? Thanks! Regards, Klaus Klaus, ti-codecs is now at 3.10.00.02, but I think the larger issue is just one of server-side directory reorganization since the recipe was updated. That tarball is part of the DVSDK, which can be downloaded here http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_3_10/latest/index_FDS.html We should probably update the recipe at some point not to attempt to fetch the tarball directly, unless someone else has it hosted separately. -Matt -- Matt Johnson Graduate Student University of Illinois at Urbana-Champaign, Dept. of ECE Coordinated Science Lab, Rm. 213 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Random problems with building locales
I am getting apparent random failures when attempting to build OpenEmbedded with bitbake 1.10.0. It seems that localedef is randomly failing as shown below. The first time it failed compiling UTF-8 es_NI, the second UTF-8 gv_GB, third UTF-8 es_NI again, and finally UTF-8 xh_ZA. Initially I suspected a problem with my machine, but I ran diagnostics overnight with no failures. Has anyone else experienced this type of failure? Could you help guide me where else to look? Thanks in advance for any help. Best regards, Dave. NOTE: Task failed: localedef returned an error (command was PATH=/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/armv5te/bin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/sbin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/bin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/sbin:/home/dlambert/oe/build/tmp/sysroots/i686-linux//bin:/home/dlambert/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/armelf/bin I18NPATH=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/usr/share/i18n qemu-arm -s 1048576 -r 2.6.24 -L /home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree -E LD_LIBRARY_PATH=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/lib /home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/bin/localedef --force --old-style --no-archive --prefix=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree --inputfile=/usr/share/i18n/locales/es_NI --charmap=UTF-8 es_NI). NOTE: package glibc-2.9-r37.3: task do_package: Failed ERROR: TaskFailed event exception, aborting ERROR: Build of /home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb do_package failed ERROR: Task 159 (/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb, do_package) failed with 256 ERROR: '/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb' failed ERROR: '/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb' failed dlamb...@development:~/oe/build$ bitbake base-image NOTE: Handling BitBake files: \ (7090/7090) [100 %] Parsing of 7090 .bb files complete (6676 cached, 414 parsed). 7279 targets, 339 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 516 of 1345 (ID: 159, /home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb, do_package) NOTE: package glibc-2.9-r37.3: task do_package: Started NOTE: preparing tree for binary locale generation NOTE: generating locale es_NI (UTF-8) NOTE: generating locale bo_IN (UTF-8) NOTE: generating locale gv_GB (UTF-8) qemu-arm: relocation error: qemu-arm: symbol unlink, version GLIBC_2.0 not defined in file libc.so.6 with link time reference ERROR: TaskFailed event exception, aborting ERROR: Build of /home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb do_package failed ERROR: Task 159 (/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb, do_package) failed with 256 ERROR: '/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb' failed NOTE: Task failed: localedef returned an error (command was PATH=/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/armv5te/bin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/sbin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/bin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/sbin:/home/dlambert/oe/build/tmp/sysroots/i686-linux//bin:/home/dlambert/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/armelf/bin I18NPATH=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/usr/share/i18n qemu-arm -s 1048576 -r 2.6.24 -L /home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree -E LD_LIBRARY_PATH=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/lib /home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/bin/localedef --force --old-style --no-archive --prefix=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree --inputfile=/usr/share/i18n/locales/gv_GB --charmap=UTF-8 gv_GB). NOTE: package glibc-2.9-r37.3: task do_package: Failed ERROR: TaskFailed event exception, aborting ERROR: Build of /home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb do_package failed ERROR: Task 159 (/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb, do_package) failed with 256 ERROR: '/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb' failed ERROR: '/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb' failed dlamb...@development:~/oe/build$ bitbake base-image NOTE: Handling BitBake files: \ (7090/7090) [100 %] Parsing of 7090 .bb files complete (6676 cached, 414 parsed). 7279 targets, 339 skipped, 0
Re: [oe] OpenEmbedded and the Yocto Project
Am Freitag, den 05.11.2010, 16:07 + schrieb Richard Purdie: I've talked to various people and I think the point has come to write down my thoughts rather than repeat conversations with various people. Sorry if this ends up as a long email. Thank you for writing this. I am aware that this probably took you quite some time. I'm on record in the past for commenting on the number of build system presentations at ELC-E in 2009. The embedded community has several of them, all with advantages and disadvantages, I look at this and wonder why we couldn't have one good one. You also wonder why there is no focus point fostering embedded Linux tools in general, everyone loves to go off and do their own thing as its easier than working together. It was based on these observations and a desire to improve the situation, I proposed the idea of what has become the Yocto project. […] This project is not in competition to OpenEmbedded, its a compliment to it. Its a serious opportunity to leverage some corporate sponsorship and see OpenEmbedded, the Yocto project and also Embedded Linux all grow. […] Hopefully this email explains some of the reasons the project exists, what the differences are to OE and that is isn't something bad but actually a very positive thing. I have not dived into the topic of if/how Poky and OE can work together, that can be the subject of another email. If anyone has any questions I'm happy to answer them. Actually this is in my opinion the most important question. In the beginning you talk about the one good build system. But in the end to get the one good build system, OpenEmbedded should somehow be merged into or replaced by Poky(?) or be replaced, should not it? I have only some small experience with and used only OpenEmbedded. So I do not know about Poky and the other build systems. But I agree with you to try to avoid duplicate work. So a message about your vision about the future of OE would be greatly appreciated. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded and the Yocto Project
On Fri, Nov 5, 2010 at 9:07 AM, Richard Purdie rpur...@rpsys.net wrote: When it comes to using OE commercially, its actually quite hard. If you look at even the big companies using OE like TI, Mentor and Montavista to name but a few, whilst they are using it, there are significant changes they need to make to turn it into a commercial product. Those changes and stabilisation are eating a lot of the developer resources they put in and there is arguably a comparatively low amount of feature development being worked upon. If somehow we could share some of that effort, it would free up resources for feature development. I think we can all agree with that. End result is that Yocto/Poky have a states release cycle, approximately six months. We have releases, BSPs can be made against the last release. When planning people can know roughly what state the tree will be in at a given time and whilst no timeline is perfect for everyone, its well defined and people can adapt to it. This is good to hear, and I hope OE can adopt this as well, or, alternatively, as has been discussed a bit, OE could become a set of layers built upon Yocto, and share the release cycle. Third is a QA problem and one of size and scale. Realistically, there is no way you can test OE as its just too large with too many combinations. On the other hand we have a pretty good known test matrix for Poky/Yocto as its a smaller set of data than OE. If we want to expand that set, we're prepared to as long as there is contribution to help test it too (additional autobuilder machines and QA resource). We do appreciate the value of the additional things OE contains however and also realise the value in additional machine support. This is why the Yocto project has done work to make layers work better and become usable for additional topic metadata layers and also machine support in the form of BSPs. This neatly allows people to take ownership of subsets of the metadata, be them community or commercial, a problem OE has long suffered from. This is also good to hear, and I agree that this is a good solution -- we actually always wanted to be able to split control and ownership in this way, but originally determining how to combine metadata from multiple places wasn't a priority. Aside: the approach taken by Conary for the metadata is a very intriguing one. Having a known test matrix and an ability to QA the system also helps massively with feature development. Within Poky/Yocto we can *know* whether a given change causes a regression within the core without too much effort. I'd suggest this is much much harder to know within OE. Perhaps, but I think the OE Testing effort is a step in the right direction, so OE too will have a test matrix, just, as you say, a less complete one. This brings me to a forth problem which is related to some of the above indirectly which is that of the contributions model itself. Above, I mentioned we needed to ensure some kind of vetting of the license on new recipes and this isn't possible with the OE push contributions model. This is why Yocto/Poky have adopted a kernel like pull model for changes. If it can scale for the Linux kernel, I think it can scale for Poky/Yocto and could if there was a will, for OE too. Sub-maintainers are appointed based on trust to merge together pull requests and pass them upwards so no one person becomes overloaded. This pull model also makes decisions and technical direction easier, there has to be a lot of trust in the Linus type person to do the right thing. If that person screws up, the project can fork and there would likely be a clear winner afterwards if the decision was worth the fork so there is actually a strong natural pressure on that person to get things right. In the Yocto/Poky world, I've taken on that overall responsibility as I have relevant technical experience and a long history of leading Poky and to a large extent OE from a technical standpoint having contributed many of the technical advancements and architecture improvements that have put OE where it is today. I fully intend to have sub maintainers to help and I really care about their technical leadership, not who pays their wages. This is as good a time as any to talk about the governance of the Yocto Project as people look at the diagram on the website and get very confused. The people with the power in the model are the architect/ maintainer groups. When it comes to technical direction this comes from the maintainers of the various components. They set this based on the input from the architect/steering group but they are the ones deciding the implementation details, writing code, accepting patches and developing the feature roadmaps and development schedules and actually doing the real work. One of the cornerstones of the governance is that if the steering group ever has to tell the architect what to do then the architect has failed at
Re: [oe] Moving to layered structure of openembedded metadata
On Fri, Nov 05, 2010 at 08:34:48AM +0100, Stefan Schmidt wrote: Hello. On Thu, 2010-11-04 at 21:00, Denys Dmytriyenko wrote: That is already being discussed and decided. See the following previous topics on the mailing list... To clear this up a bit. There can't be a real decision for now. Not all developers have been present at the OEDEM and we haven't discussed every detail their either. :) Most, if not all, people liked the idea during the OEDEM discussions, but we would need more input on problem that this may rise. As it stands I'm happy to see Khem coming up to put this on the ml. :) One I currently see is how we can keep it all working when the layers are maintained in different places and what kid of combinational explosion we will have with layers in different places. That is exactly what I said - being discussed and (being) decided. I didn't say it was or has been already decided. Being is not the same as been! :) I.e. present continuous instead of past tense. And BTW, it may not be a simple decision after all - while technically Yocto seems quite a decent project and embracing it would be reasonable, many large companies are still having issues with it's governance model and past issues with Intel's other seemingly open source projects... The good news is that this side of the problem is now being actively looked at for any possible solutions, which would benefit all involved... -- Denys ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] gphoto2_2.4.8.bb: Stop configure from looking in /usr/local/include
2010/11/5 Khem Raj raj.k...@gmail.com: On Fri, Nov 5, 2010 at 12:51 AM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/11/3 Khem Raj raj.k...@gmail.com: On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/11/3 Khem Raj raj.k...@gmail.com: On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/11/3 Khem Raj raj.k...@gmail.com: yes a more detailed solution is better. you have to go through the configure of every package and understand the behavior then act upon. As I said before its a tedious task I'm well aware of this. That is also why in the infrastructure thread I suggested using automated testing to find misbehaving packages. Btw there are 355 .inc files that contain the word autotools and 1899 .bb files. Of course there are lots of dups in there. And maybe for the base recipes we can convince the yocto people that this is a serious QA issue (and they have some people employed to work on this if I understood properly). numbers means not so much when it comes down to this. I don't know if any distribution that even does that so I take comfort in everyone being wrong. I agree that numbers don't mean that much. Just wanted to give an indication of the possible effort needed. Also no idea how debian does this. Does it do it in first place ? I peeked briefly at the sources. Debian seems to resolve the problem by going for the max dependencies so autotools can pick up everything. E.g. for gphoto2, lenny has a depends on both libexif and libreadline (see http://packages.debian.org/lenny/gphoto2) So basically they go for the max config. We could do the same. Then again for deeply embedded systems it might be desirable to allow more finegrained tuning. (did I hear someone say USE flags ? ) which is good for things that dont care about size. Not so good for embedded systems I think. and there are some packages I know which have catch-22 situation so adding max depends is also not a wholesome solution. Catch22 situations seem mostly to appear because one packag exports both a lib and a (sample) program. One example that I saw recently was libcdio and libcddb. Probably the only other way of catch 22 situations are triple or quadruple staged builds.(build A, build B rebuild A maybe rebuild B) Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] libX11: patch configure.ac so a nios2 system is not seen as an os2 system.
2010/11/5 Khem Raj raj.k...@gmail.com:
On Fri, Nov 5, 2010 at 5:08 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
configure.ac matches target_system against *os2* to detect if we're
configuring for an os2 system. Unfortunately this also matches if the
target_system is nios-linux (which is not an os2 system :-) )
This patch adds an additional case. The patch is added to the individual
recipes and also made upstream.
Patch is tested by fully building 1.3.2 and by running
bitbake -c patch for the other recipes.
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
Hmmm good find. I am ok with general fix. but please consider other
review comments before you commit
Acked-by: Khem Raj raj.k...@gmail.com
I won't have time to commit next 10 days or so. I'll be mostly afk.
If desired Martin (being the X maintainer iirc, can commit).
And feel free to change the patch or the commit message (or maybe move
to the alternative suggested upstream).
Frans
---
.../xorg-lib/libx11-1.1.5/configure.ac-nios2.patch | 12
.../xorg-lib/libx11-1.3.2/configure.ac-nios2.patch | 12
.../xorg-lib/libx11-1.3.6/configure.ac-nios2.patch | 12
.../libx11-1.3.99.903/configure.ac-nios2.patch | 12
recipes/xorg-lib/libx11_1.1.5.bb | 3 ++-
recipes/xorg-lib/libx11_1.3.2.bb | 3 ++-
recipes/xorg-lib/libx11_1.3.6.bb | 3 ++-
recipes/xorg-lib/libx11_1.3.99.903.bb | 3 ++-
8 files changed, 56 insertions(+), 4 deletions(-)
create mode 100644 recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch
create mode 100644 recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch
create mode 100644 recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch
create mode 100644
recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch
diff --git a/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch
b/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch
new file mode 100644
index 000..5605a59
--- /dev/null
+++ b/recipes/xorg-lib/libx11-1.1.5/configure.ac-nios2.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.3.2/configure.ac
+===
+--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100
libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100
+@@ -202,6 +202,7 @@
+ # arch specific things
+ WCHAR32=1
+ case $target_alias in
++ nios2*) os2=false ;;
+ *os2*) os2=true ; WCHAR32=0 ;;
+ *) ;;
+ esac
diff --git a/recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch
b/recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch
new file mode 100644
index 000..5605a59
--- /dev/null
+++ b/recipes/xorg-lib/libx11-1.3.2/configure.ac-nios2.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.3.2/configure.ac
+===
+--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100
libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100
+@@ -202,6 +202,7 @@
+ # arch specific things
+ WCHAR32=1
+ case $target_alias in
++ nios2*) os2=false ;;
+ *os2*) os2=true ; WCHAR32=0 ;;
+ *) ;;
+ esac
diff --git a/recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch
b/recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch
new file mode 100644
index 000..5605a59
--- /dev/null
+++ b/recipes/xorg-lib/libx11-1.3.6/configure.ac-nios2.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.3.2/configure.ac
+===
+--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100
libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100
+@@ -202,6 +202,7 @@
+ # arch specific things
+ WCHAR32=1
+ case $target_alias in
++ nios2*) os2=false ;;
+ *os2*) os2=true ; WCHAR32=0 ;;
+ *) ;;
+ esac
diff --git a/recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch
b/recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch
new file mode 100644
index 000..5605a59
--- /dev/null
+++ b/recipes/xorg-lib/libx11-1.3.99.903/configure.ac-nios2.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.3.2/configure.ac
+===
+--- libX11-1.3.2.orig/configure.ac 2010-11-05 10:30:33.825536983 +0100
libX11-1.3.2/configure.ac 2010-11-05 10:31:25.913899269 +0100
+@@ -202,6 +202,7 @@
+ # arch specific things
+ WCHAR32=1
+ case $target_alias in
++ nios2*) os2=false ;;
+ *os2*) os2=true ; WCHAR32=0 ;;
+ *) ;;
+ esac
diff --git a/recipes/xorg-lib/libx11_1.1.5.bb
b/recipes/xorg-lib/libx11_1.1.5.bb
index e775585..b44dcc8 100644
--- a/recipes/xorg-lib/libx11_1.1.5.bb
+++ b/recipes/xorg-lib/libx11_1.1.5.bb
@@ -1,7 +1,8 @@
require libx11.inc
DEPENDS = ${COMMON_DEPENDS}
-PR = ${INC_PR}.1
+PR = ${INC_PR}.2
+SRC_URI +=
Re: [oe] Moving to layered structure of openembedded metadata
On Fri, Nov 5, 2010 at 9:57 AM, Denys Dmytriyenko de...@denix.org wrote: On Fri, Nov 05, 2010 at 08:34:48AM +0100, Stefan Schmidt wrote: Hello. On Thu, 2010-11-04 at 21:00, Denys Dmytriyenko wrote: That is already being discussed and decided. See the following previous topics on the mailing list... To clear this up a bit. There can't be a real decision for now. Not all developers have been present at the OEDEM and we haven't discussed every detail their either. :) Most, if not all, people liked the idea during the OEDEM discussions, but we would need more input on problem that this may rise. As it stands I'm happy to see Khem coming up to put this on the ml. :) One I currently see is how we can keep it all working when the layers are maintained in different places and what kid of combinational explosion we will have with layers in different places. That is exactly what I said - being discussed and (being) decided. I didn't say it was or has been already decided. Being is not the same as been! :) I.e. present continuous instead of past tense. And BTW, it may not be a simple decision after all - while technically Yocto seems quite a decent project and embracing it would be reasonable, many large companies are still having issues with it's governance model and past issues with Intel's other seemingly open source projects... The good news is that this side of the problem is now being actively looked at for any possible solutions, which would benefit all involved... My proposal is to align OE and poky and in turn for benefit of community. Yocto as I understand has a bigger scope and uses OE/poky for the build system that it uses. Which in general is also good for OE development. If we design the layers well it will be very portable and componentized. How yocto itself operates is probably is a separate thing they may make some good moves which benefits OE and thats what we should be interested in and concerned about and I am sure that if we do something that is beneficial then yocto using poky build system will definitely like it too. -- Denys ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Random problems with building locales
On Fri, Nov 5, 2010 at 9:30 AM, David Lambert d...@lambsys.com wrote: I am getting apparent random failures when attempting to build OpenEmbedded with bitbake 1.10.0. It seems that localedef is randomly failing as shown below. The first time it failed compiling UTF-8 es_NI, the second UTF-8 gv_GB, third UTF-8 es_NI again, and finally UTF-8 xh_ZA. Initially I suspected a problem with my machine, but I ran diagnostics overnight with no failures. Has anyone else experienced this type of failure? Could you help guide me where else to look? I think its because qemu-arm is dying on you. there is 0.13 release that happens few weeks back I am still working on getting that into OE. Once I have that in may be it will get fixed I am not sure yet remain tuned -Khem Thanks in advance for any help. Best regards, Dave. NOTE: Task failed: localedef returned an error (command was PATH=/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/armv5te/bin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/sbin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/bin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/sbin:/home/dlambert/oe/build/tmp/sysroots/i686-linux//bin:/home/dlambert/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/armelf/bin I18NPATH=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/usr/share/i18n qemu-arm -s 1048576 -r 2.6.24 -L /home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree -E LD_LIBRARY_PATH=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/lib /home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/bin/localedef --force --old-style --no-archive --prefix=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree --inputfile=/usr/share/i18n/locales/es_NI --charmap=UTF-8 es_NI). NOTE: package glibc-2.9-r37.3: task do_package: Failed ERROR: TaskFailed event exception, aborting ERROR: Build of /home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb do_package failed ERROR: Task 159 (/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb, do_package) failed with 256 ERROR: '/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb' failed ERROR: '/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb' failed dlamb...@development:~/oe/build$ bitbake base-image NOTE: Handling BitBake files: \ (7090/7090) [100 %] Parsing of 7090 .bb files complete (6676 cached, 414 parsed). 7279 targets, 339 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 516 of 1345 (ID: 159, /home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb, do_package) NOTE: package glibc-2.9-r37.3: task do_package: Started NOTE: preparing tree for binary locale generation NOTE: generating locale es_NI (UTF-8) NOTE: generating locale bo_IN (UTF-8) NOTE: generating locale gv_GB (UTF-8) qemu-arm: relocation error: qemu-arm: symbol unlink, version GLIBC_2.0 not defined in file libc.so.6 with link time reference ERROR: TaskFailed event exception, aborting ERROR: Build of /home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb do_package failed ERROR: Task 159 (/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb, do_package) failed with 256 ERROR: '/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb' failed NOTE: Task failed: localedef returned an error (command was PATH=/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/armv5te/bin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/sbin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/usr/bin:/home/dlambert/oe/build/tmp/sysroots/i686-linux/sbin:/home/dlambert/oe/build/tmp/sysroots/i686-linux//bin:/home/dlambert/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/armelf/bin I18NPATH=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/usr/share/i18n qemu-arm -s 1048576 -r 2.6.24 -L /home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree -E LD_LIBRARY_PATH=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/lib /home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree/bin/localedef --force --old-style --no-archive --prefix=/home/dlambert/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/glibc-2.9-r37.3/locale-tree --inputfile=/usr/share/i18n/locales/gv_GB --charmap=UTF-8 gv_GB). NOTE: package glibc-2.9-r37.3: task do_package: Failed ERROR: TaskFailed event exception, aborting ERROR: Build of /home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb do_package failed ERROR: Task 159 (/home/dlambert/oe/openembedded/recipes/glibc/glibc_2.9.bb, do_package) failed with 256 ERROR:
Re: [oe] OpenEmbedded and the Yocto Project
On Fri, 2010-11-05 at 17:36 +0100, Paul Menzel wrote: Am Freitag, den 05.11.2010, 16:07 + schrieb Richard Purdie: Hopefully this email explains some of the reasons the project exists, what the differences are to OE and that is isn't something bad but actually a very positive thing. I have not dived into the topic of if/how Poky and OE can work together, that can be the subject of another email. If anyone has any questions I'm happy to answer them. Actually this is in my opinion the most important question. In the beginning you talk about the one good build system. But in the end to get the one good build system, OpenEmbedded should somehow be merged into or replaced by Poky(?) or be replaced, should not it? I have only some small experience with and used only OpenEmbedded. So I do not know about Poky and the other build systems. But I agree with you to try to avoid duplicate work. So a message about your vision about the future of OE would be greatly appreciated. The thing to keep in mind is that Poky and OE are very similar, sharing bitbake, the recipe format and pretty much the same class files. We therefore we didn't start a new build system project we took an existing one very similar to OpenEmbedded and we plan to keep the architecture the same. Even since Poky was created over five years ago I've been publicly discussing new features, how they're best implemented and so on with OE developers, bitbake maintainers and the OE TSC so the projects stay roughly in sync. I've stated what Yocto/Poky is doing differently and why, the question now is whether the OE developers agree/disagree with those things and if they are prepared to change OE at all to address some of the reasons Yocto is doing some things differently. There are ways the two projects can complement each other but there has to be a will there to do it. Traditionally, OE has trouble making decisions which I think it hurts the project in general. I'm hoping this topic isn't going to be one of those things it fails to reach a conclusion on. Cheers, Richard ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Random problems with building locales
Khem, Thanks for your reply. Is there a quick workaround? Is there an earlier branch/tag that is more stable? Regards, Dave. On 11/05/2010 02:19 PM, Khem Raj wrote I think its because qemu-arm is dying on you. there is 0.13 release that happens few weeks back I am still working on getting that into OE. Once I have that in may be it will get fixed I am not sure yet remain tuned -Khem ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Random problems with building locales
On 05.11.2010 20:26, David Lambert wrote: Is there a quick workaround? You can add ENABLE_BINARY_LOCALE_GENERATION = 0 to your local.conf. It will disable locale generation. Best regards Bernhard ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] openldap: fix ltmain.sh location
Signed-off-by: Roman I Khimov khi...@altell.ru
---
recipes/openldap/openldap_2.4.23.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/recipes/openldap/openldap_2.4.23.bb
b/recipes/openldap/openldap_2.4.23.bb
index 3ac15f6..f8f3fb5 100644
--- a/recipes/openldap/openldap_2.4.23.bb
+++ b/recipes/openldap/openldap_2.4.23.bb
@@ -188,7 +188,7 @@ DEPENDS += ${OPENLDAP_DEPENDS}
CPPFLAGS_append = -D_GNU_SOURCE
do_configure() {
- cp ${STAGING_DATADIR}/libtool/config/ltmain.sh ${S}/build
+ cp ${STAGING_DATADIR_NATIVE}/libtool/config/ltmain.sh ${S}/build
rm -f ${S}/libtool
aclocal
libtoolize --force --copy
--
1.6.4.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded and the Yocto Project
2010/11/5 Richard Purdie rpur...@rpsys.net: On Fri, 2010-11-05 at 17:36 +0100, Paul Menzel wrote: Am Freitag, den 05.11.2010, 16:07 + schrieb Richard Purdie: Hopefully this email explains some of the reasons the project exists, what the differences are to OE and that is isn't something bad but actually a very positive thing. I have not dived into the topic of if/how Poky and OE can work together, that can be the subject of another email. If anyone has any questions I'm happy to answer them. Actually this is in my opinion the most important question. In the beginning you talk about the one good build system. But in the end to get the one good build system, OpenEmbedded should somehow be merged into or replaced by Poky(?) or be replaced, should not it? I have only some small experience with and used only OpenEmbedded. So I do not know about Poky and the other build systems. But I agree with you to try to avoid duplicate work. So a message about your vision about the future of OE would be greatly appreciated. The thing to keep in mind is that Poky and OE are very similar, sharing bitbake, the recipe format and pretty much the same class files. We therefore we didn't start a new build system project we took an existing one very similar to OpenEmbedded and we plan to keep the architecture the same. Even since Poky was created over five years ago I've been publicly discussing new features, how they're best implemented and so on with OE developers, bitbake maintainers and the OE TSC so the projects stay roughly in sync. I've stated what Yocto/Poky is doing differently and why, the question now is whether the OE developers agree/disagree with those things and if they are prepared to change OE at all to address some of the reasons Yocto is doing some things differently. There are ways the two projects can complement each other but there has to be a will there to do it. Traditionally, OE has trouble making decisions which I think it hurts the project in general. I'm hoping this topic isn't going to be one of those things it fails to reach a conclusion on. Well, I for me I have some reservations, but I definitely also see plenty of options as yocto does address several issues that historically were not among the strong points of OE. Let's work on combining the best of both worlds! Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] openldap: fix ltmain.sh location
On Fri, Nov 5, 2010 at 1:03 PM, Roman I Khimov khi...@altell.ru wrote:
Signed-off-by: Roman I Khimov khi...@altell.ru
Acked-by: Khem Raj raj.k...@gmail.com
---
recipes/openldap/openldap_2.4.23.bb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/recipes/openldap/openldap_2.4.23.bb
b/recipes/openldap/openldap_2.4.23.bb
index 3ac15f6..f8f3fb5 100644
--- a/recipes/openldap/openldap_2.4.23.bb
+++ b/recipes/openldap/openldap_2.4.23.bb
@@ -188,7 +188,7 @@ DEPENDS += ${OPENLDAP_DEPENDS}
CPPFLAGS_append = -D_GNU_SOURCE
do_configure() {
- cp ${STAGING_DATADIR}/libtool/config/ltmain.sh ${S}/build
+ cp ${STAGING_DATADIR_NATIVE}/libtool/config/ltmain.sh ${S}/build
rm -f ${S}/libtool
aclocal
libtoolize --force --copy
--
1.6.4.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] problems building openldap and libtool
On Thu, Nov 4, 2010 at 12:39 AM, J. L. vwyodap...@gmail.com wrote:
On Thu, Nov 4, 2010 at 12:27 AM, J. L. vwyodap...@gmail.com wrote:
On Wed, Nov 3, 2010 at 6:37 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 5:46 PM, J. L. vwyodap...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:48 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:36 PM, J. L. vwyodap...@gmail.com wrote:
On Wed, Nov 3, 2010 at 4:24 PM, Khem Raj raj.k...@gmail.com wrote:
On Wed, Nov 3, 2010 at 3:55 PM, J. L. vwyodap...@gmail.com wrote:
I am having an issue of how libtool is building on my machine. I am
running Ubuntu 10.10 64bit Kernel 2.6.35-23-generic bitbake 1.10.1
overo branch. Here is what happens when building:
Error for openldap
NOTE: package openldap-2.4.23-r2: task do_configure: Started
ERROR: Function do_configure failed
NOTE: Task failed: ('function do_configure failed',
'/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.12815')
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.12815
Log data follows:
| cp: cannot stat
`/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/ltmain.sh':
No such file or directory
can you add DEPENDS += libtool to openldap_2.4.23.bb and retry ?
Still getting this error and I cleaned and rebuilt both recipes
try this patch and remove that DEPENDS
diff --git a/recipes/openldap/openldap_2.4.23.bb
b/recipes/openldap/openldap_2.4.23.bb
index 3ac15f6..8afd951 100644
--- a/recipes/openldap/openldap_2.4.23.bb
+++ b/recipes/openldap/openldap_2.4.23.bb
@@ -188,7 +188,7 @@ DEPENDS += ${OPENLDAP_DEPENDS}
CPPFLAGS_append = -D_GNU_SOURCE
do_configure() {
- cp ${STAGING_DATADIR}/libtool/config/ltmain.sh ${S}/build
+ cp ${STAGING_ETCDIR_NATIVE}/libtool/config/ltmain.sh ${S}/build
rm -f ${S}/libtool
aclocal
libtoolize --force --copy
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.do_configure.2783
Log data follows:
| cp: cannot stat
`/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/ltmain.sh':
No such file or directory
| ERROR: Function do_configure failed
NOTE: package openldap-2.4.23-r2: task do_configure: Failed
libtool does not build to this location
/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/libtool/
it builds to here
tmp/sysroots/armv7a-angstrom-linux-gnueabi/home/vdubhack/overo-oe/tmp/sysroots/x86_64-linux/usr/share/libtool/
It seems to put home/vdubhack/overo-oe/tmp the incorrect way. instead
of being in front of the tmp/sysroot like most things
same with aclocal and aclocal-1.11
Thanks
JL
-khem
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Did as you asked and also deleted the tmp/ dir to just make sure was
nothing in there and rebuilt. And must not have done something right
as the patch failed with this:
ERROR: Logfile of failure stored in:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/openldap-2.4.23-r2/temp/log.patch_do_patch.22762
Log data follows:
| ERROR: Error in executing python function in:
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/openldap/openldap_2.4.23.bb
| ERROR: Exception:class 'oe.patch.CmdError' Message:Command Error:
exit status: 1 Output:
| Applying patch test-fix.patch
| patching file recipes/openldap/openldap_2.4.23.bb
| Hunk #1 FAILED at 188.
| 1 out of 1 hunk FAILED -- rejects in file
recipes/openldap/openldap_2.4.23.bb
| Patch test-fix.patch does not apply (enforce with -f)
| ERROR: Printing the environment of the function
| ERROR: Function patch_do_patch failed
NOTE: package openldap-2.4.23-r2: task do_patch: Failed
I have attached the patch and the .bb so you can see what and how I did
it.
crap.
dude you make that one line change in the recipe .bb file *by hand*
its not a patch for the sources
but for the recipe.
Thanks for the help so far.
JL
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
[oe] [PATCH] recipes/fluxbox/fluxbox_1.1.1.bb - Fixed depends for libxpm recipes/initscripts/file/halt - Fixed poweroff when booted from NFS
* Fix to halt courtesy by penghb,patch by angelox_123 * Fix to fluxbox compile with libxpm by angelox_123 Signed-off-by: Angelo S. Mavridis Bartolome ang...@pynell.com --- recipes/fluxbox/fluxbox_1.1.1.bb |2 +- recipes/initscripts/files/halt |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/recipes/fluxbox/fluxbox_1.1.1.bb b/recipes/fluxbox/fluxbox_1.1.1.bb index 55a747c..85f4c8b 100644 --- a/recipes/fluxbox/fluxbox_1.1.1.bb +++ b/recipes/fluxbox/fluxbox_1.1.1.bb @@ -2,7 +2,7 @@ DESCRIPTION = The Fluxbox Windowmanager HOMEPAGE = http://www.fluxbox.org; LICENSE = MIT DEPENDS = fontconfig virtual/libx11 - +DEPENDS += libxpm PR = r1 PE = 1 diff --git a/recipes/initscripts/files/halt b/recipes/initscripts/files/halt index d8cab22..b869966 100644 --- a/recipes/initscripts/files/halt +++ b/recipes/initscripts/files/halt @@ -20,6 +20,6 @@ then hddown= fi -halt -d -f -i -p $hddown +/bin/busybox poweroff -f : exit 0 -- 1.7.3.2 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH v2 1/2] eglibc: fix build issue with make-3.82
Add patch to fix this error when building eglibc-2.11, eglibc-2.12
with make-3.82:
make[2]: Entering directory `eglibc-2_12/libc/manual'
Makefile:246: *** mixed implicit and normal rules. Stop.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
Add fixed eglibc versions to patch comment
recipes/eglibc/eglibc_2.11.bb |3 ++-
recipes/eglibc/eglibc_2.12.bb |3 ++-
recipes/eglibc/files/eglibc-make-382.patch | 15 +++
3 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644 recipes/eglibc/files/eglibc-make-382.patch
diff --git a/recipes/eglibc/eglibc_2.11.bb b/recipes/eglibc/eglibc_2.11.bb
index 3763124..89742b6 100644
--- a/recipes/eglibc/eglibc_2.11.bb
+++ b/recipes/eglibc/eglibc_2.11.bb
@@ -4,7 +4,7 @@ DEFAULT_PREFERENCE = -1
DEPENDS += gperf-native
FILESPATHPKG =. eglibc-svn:
PV = 2.11
-PR = ${INC_PR}.7
+PR = ${INC_PR}.8
PR_append = +svnr${SRCPV}
SRCREV=10690
EGLIBC_BRANCH=eglibc-2_11
@@ -14,6 +14,7 @@ SRC_URI =
svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
file://shorten-build-commands.patch \
file://sh4_set_fpscr.patch \
file://sh4_local-fpscr_values.patch \
+ file://eglibc-make-382.patch \
file://etc/ld.so.conf \
file://generate-supported.mk
S = ${WORKDIR}/${EGLIBC_BRANCH}/libc
diff --git a/recipes/eglibc/eglibc_2.12.bb b/recipes/eglibc/eglibc_2.12.bb
index 40ab65c..956f64b 100644
--- a/recipes/eglibc/eglibc_2.12.bb
+++ b/recipes/eglibc/eglibc_2.12.bb
@@ -4,7 +4,7 @@ DEFAULT_PREFERENCE = -1
DEPENDS += gperf-native
FILESPATHPKG =. eglibc-svn:
PV = 2.12
-PR = ${INC_PR}.6
+PR = ${INC_PR}.7
PR_append = +svnr${SRCPV}
SRCREV=11762
EGLIBC_BRANCH=eglibc-2_12
@@ -16,6 +16,7 @@ SRC_URI =
svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
file://sh4_local-fpscr_values.patch \
file://eglibc-dont-cache-slibdir.patch \
file://armv4-eabi-compile-fix.patch \
+ file://eglibc-make-382.patch \
file://etc/ld.so.conf \
file://generate-supported.mk
S = ${WORKDIR}/${EGLIBC_BRANCH}/libc
diff --git a/recipes/eglibc/files/eglibc-make-382.patch
b/recipes/eglibc/files/eglibc-make-382.patch
new file mode 100644
index 000..5ecad90
--- /dev/null
+++ b/recipes/eglibc/files/eglibc-make-382.patch
@@ -0,0 +1,15 @@
+http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=blob_plain;f=source/base/glibc/make-3.82-fix.patch;hb=8217c32ecc2e14962847ba3d8a272eb64a3dba4f
+
+--- libc/manual/Makefile
libc/manual/Makefile
+@@ -232,7 +232,9 @@
+ .PHONY: stubs
+ stubs: $(objpfx)stubs
+ endif
+-$(objpfx)stubs ../po/manual.pot $(objpfx)stamp%:
++$(objpfx)stubs ../po/manual.pot:
++ touch $@
++$(objpfx)stamp%:
+ $(make-target-directory)
+ touch $@
+
--
1.7.3.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] recipes/fluxbox/fluxbox_1.1.1.bb - Fixed depends for libxpm recipes/initscripts/file/halt - Fixed poweroff when booted from NFS
Am Freitag, den 05.11.2010, 20:25 -0200 schrieb Angelo S. Mavridis Bartolome: * Fix to halt courtesy by penghb,patch by angelox_123 * Fix to fluxbox compile with libxpm by angelox_123 Where are the nicknames from? IRC? Signed-off-by: Angelo S. Mavridis Bartolome ang...@pynell.com --- recipes/fluxbox/fluxbox_1.1.1.bb |2 +- recipes/initscripts/files/halt |2 +- […] Please send a patch for each change. You could git commit patch/to/changed/file to create separate commits. Please only put the recipe name to the beginning of the commit summary as demanded by OE’s commit policy [1]. I would love to see your build configuration and your build error in the commit log too and, if you know it, a small comment why this fix is needed. These files seem to have been around for quite some time so I find it strange that these issues have not been surfaced earlier. Thanks, Paul [1] http://wiki.openembedded.org/index.php/Commit_Policy signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] metano.conf: Removed inutil package
* Removed nano package from default,it isn't need at this time
Signed-off-by: Angelo S. Mavridis Bartolome ang...@pynell.com
---
conf/distro/metano.conf |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/conf/distro/metano.conf b/conf/distro/metano.conf
index 9bab8d9..6262aa0 100644
--- a/conf/distro/metano.conf
+++ b/conf/distro/metano.conf
@@ -122,7 +122,6 @@ DISTRO_EXTRA_RRECOMMENDS += \
mplayer \
alsa-lib \
alsa-utils \
-nano \
gpe-filemanager \
gpe-mini-browser \
${XSERVER} \
--
1.7.3.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] vlc_1.1.4.1: Really add `lua5.1` to `DEPENDS` (instead of just `lua`).
Date: Thu, 4 Nov 2010 23:04:35 +0100 This fixes commit 93dca1 [1]. Thanks to Dallas for reporting this issue [2]. [1] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=93dca1c604d420ed4db44a71a375182933658886 [2] http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-November/026475.html Reported-by: Dallas Foley dfo...@telus.net Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net --- I am deeply sorry for my mistake, missing QA and for the additional hassle. The build still fails with the following error. checking for LUA... yes checking for luac... no configure: error: Could not find the LUA byte compiler. ERROR: Function do_configure failed This problem is discussed in the above mentioned thread [2]. --- recipes/vlc/vlc_1.1.4.1.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/recipes/vlc/vlc_1.1.4.1.bb b/recipes/vlc/vlc_1.1.4.1.bb index ef764c1..af01d98 100644 --- a/recipes/vlc/vlc_1.1.4.1.bb +++ b/recipes/vlc/vlc_1.1.4.1.bb @@ -10,7 +10,7 @@ SRC_URI[sha256sum] = 61c9ea30a17ea40c6ccbfd507026e5c83ad9e0691f221d3667c8e49696 # ffmpeg from git (library version = 52) is required # libtool-native must be = 2.2.4 -DEPENDS += libdvdcss libdvdread lua +DEPENDS += libdvdcss libdvdread lua5.1 EXTRA_OECONF += \ --enable-dvdread \ -- 1.7.2.3 signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] metano.conf: Removed inutil package
Am Freitag, den 05.11.2010, 20:45 -0200 schrieb Angelo S. Mavridis Bartolome: * Removed nano package from default, The commit summary contradicts what this patch does.(?) it isn't need at this time Could this be more understandable? Why is `nano` not needed? […] Please resend and please also update OE’s patch queue [1]. Thanks, Paul [1] http://wiki.openembedded.org/index.php/Patchwork signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] vlc_1.1.4.1: Why is `lua5.1-native` not added to `DEPENDS` automatically? (was: [PATCH] vlc_1.1.4.1: add `lua5.1` to `DEPENDS`)
Am Mittwoch, den 03.11.2010, 10:55 -0700 schrieb Dallas Foley: On 10-11-03 02:28 AM, Paul Menzel wrote: Date: Wed, 3 Nov 2010 09:52:36 +0100 After VLC 1.0.6, being the latest version in OE until addition of 1.1.4.1 in commit 30e362 [2], some interfaces were implemented in Lua in VLC 1.1.0 [1]. Interfaces: * Renamed the legacy rc, telnet and http interfaces to oldrc, oldtelnet and oldhttp. * rc, telnet and http are now implemented using the lua interface system. Task `configure` fails with the following error message. […] | checking for LUA... no | configure: WARNING: lua5.1 not found, trying lua= 5.1 instead | checking for LUA... no | checking lua.h usability... no | checking lua.h presence... no | checking for lua.h... no | checking lauxlib.h usability... no | checking lauxlib.h presence... no | checking for lauxlib.h... no | checking lualib.h usability... no | checking lualib.h presence... no | checking for lualib.h... no | checking for luaL_newstate in -llua5.1 ... no | checking for luaL_newstate in -llua51 ... no | checking for luaL_newstate in -llua ... no | configure: error: Could not find lua. Lua is needed for some interfaces (rc, telnet, http) as well as many other custom scripts. Use --disable-lua to ignore this error. | ERROR: Function do_configure failed NOTE: package vlc-1.1.4.1-r0: task do_configure: Failed […] Adding `lua5.1` to `DEPENDS` is chosen in favor of disabling it. [1] http://git.videolan.org/?p=vlc.git;a=commitdiff;h=3c1df96cda8086f605f2eacaa5653c9e43ec45ac [2] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=30e362c22a49521ebeef9bed1f0c58902b7dc50b Signed-off-by: Paul Menzelpaulepan...@users.sourceforge.net --- recipes/vlc/vlc_1.1.4.1.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/recipes/vlc/vlc_1.1.4.1.bb b/recipes/vlc/vlc_1.1.4.1.bb index d4535a5..ef764c1 100644 --- a/recipes/vlc/vlc_1.1.4.1.bb +++ b/recipes/vlc/vlc_1.1.4.1.bb @@ -10,7 +10,7 @@ SRC_URI[sha256sum] = 61c9ea30a17ea40c6ccbfd507026e5c83ad9e0691f221d3667c8e49696 # ffmpeg from git (library version = 52) is required # libtool-native must be= 2.2.4 -DEPENDS += libdvdcss libdvdread +DEPENDS += libdvdcss libdvdread lua EXTRA_OECONF += \ --enable-dvdread \ I seem to need lua5.1 and lua5.1-native in DEPENDS for this vlc as opposed to just lua. You are indeed correct. Somehow I messed up the patch and just edited the commit message. :( I sent a fixup some minutes ago [3]. ie. DEPENDS += libdvdcss libdvdread lua5.1 lua5.1-native I doubt this has anything to do with it, but I am using DISTRO=angstrom-2010.x and setting ANGSTROM_LIBTOOL_VERSION = 2.2.6b LIBTOOL_HAS_SYSROOT = no only because apache2 does not configure with the newer libtool As you wrote after applying this patch there is still the following problem in the task `configure`. […] checking for LUA... yes checking for luac... no configure: error: Could not find the LUA byte compiler. ERROR: Function do_configure failed Indeed in all my tests there is no `luac` staged. $ find . -name *luac* ./minimal-dev/sysroots/armv7a-oe-linux-gnueabi/usr/include/luaconf.h ./minimal-dev/sysroots/armv7a-oe-linux-gnueabi/usr/share/man/man1/luac.1 ./minimal-dev/work/armv7a-oe-linux-gnueabi/vlc-1.1.4.1-r0/vlc-1.1.4.1/share/lua/intf/luac.lua $ find angstrom-dev/ -name *luac* # angstrom-2008.1 angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/luaconf.h angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/man/man1/luac.1 angstrom-dev/work/armv7a-angstrom-linux-gnueabi/vlc-1.1.4.1-r0/vlc-1.1.4.1/share/lua/intf/luac.lua This should be done by adding `lua5.1-native` to `DEPENDS` as you suggested. But I am wondering why `lua5.1` is not providing `luac`. Is there a problem with the `lua5.1` recipe [4][5]? Thanks, Paul [3] http://patchwork.openembedded.org/patch/3504/ [4] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/lua/lua5.1_5.1.4.bb?id=48838f0fca6b00767115dd13bce2537f035fd3ba [5] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/lua/lua.inc?id=709c4d66e0b107ca606941b988bad717c0b45d9b signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] ARMv4 not working with latest gcc,eglibc
Hi, Khems addition of gcc 4.5 patch effectivly removed the thumb 'bx' instruction from the binaries, but Im getting the exact same issue as before (kernel panic at init time). Filip zyzniewski had the combination of gcc 4.4.2 + eglibc 2.12 working well on his machine, I also know another person with an ARMv4t which used gcc 4.5 + eglibc 2.12 without any issues (with same distro file). Therefore I still believe its an compiler/thumb issue. Im currently trying to reproduce filips environment to make sure, once I do it should be confirmed. Best wishes Kristoffer Ericson http://www.jlime.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
