| Submitter | Ulf Samuelsson |
|---|---|
| Date | Nov. 26, 2011, 11:24 a.m. |
| Message ID | <4ED0CC76.4040606@emagii.com> |
| Download | mbox | patch |
| Permalink | /patch/15441/ |
| State | New |
| Headers | show |
Comments
Hi Ulf, Le 26/11/2011 12:24, Ulf Samuelsson a écrit : > 3. When I ran into this problem, I exited with ctrl-C. > This left some recipes in the middle of a fetch ,and the build could not > continue. > I had to "bitbake -c clean <package>" on all problematic packages to recover. > Seems a little bit fragile to me. > already met here : you must let bitbake end the other tasks already started to prevent that (so only one control C). > 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64). > Fails in the fetch stage. > I removed the layer, since it was not needed for qemuarm. > I also met this kind of problem. To prevent that problem, in my bsp overlay, I always add COMPATIBLE_MACHINE = "" to the machine specific recipes. What is strange is that meta-ti also have this in its recipes so their linux-3.0 recipe should not be used if you target qemuarm. > 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host) > tiff won't build. > Did: > bitbake console-image" > bitbake -c clean tiff > bitbake tiff > - No luck > Reading through the mailing list, I found someone which deleted > $TMPDIR and then > bitbake tiff > bitbake console-image > That worked for me as well once, second time, same problem. > Problem is that #include <iostream> fails. > > I noted that "iostream" is built and available in <sysroot>/usr/include/c++ > On the host, it is located in /usr/incolude/c++/<version> > "tiff" build seems to be OK with Ubuntu 11.04 i686. > what is your BB_NUMBER_THREADS setting ? Here (on 2 different hosts/distro/arch but with an i7 CPU in both cases) if I set it over 4, I often (always with a value of 8) meet problems with c++ includes during build from scratch. 4 seems the magic value which never trigger the problem. Eric
On 2011-11-26 13:38, Eric Bénard wrote: > Hi Ulf, > > Le 26/11/2011 12:24, Ulf Samuelsson a écrit : >> 3. When I ran into this problem, I exited with ctrl-C. >> This left some recipes in the middle of a fetch ,and the build could not >> continue. >> I had to "bitbake -c clean <package>" on all problematic packages to >> recover. >> Seems a little bit fragile to me. >> > already met here : you must let bitbake end the other tasks already > started to prevent that (so only one control C). > >> 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64). >> Fails in the fetch stage. >> I removed the layer, since it was not needed for qemuarm. >> > I also met this kind of problem. To prevent that problem, in my bsp > overlay, I always add COMPATIBLE_MACHINE = "" to the machine specific > recipes. > What is strange is that meta-ti also have this in its recipes so their > linux-3.0 recipe should not be used if you target qemuarm. > >> 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host) >> tiff won't build. >> Did: >> bitbake console-image" >> bitbake -c clean tiff >> bitbake tiff >> - No luck >> Reading through the mailing list, I found someone which deleted >> $TMPDIR and then >> bitbake tiff >> bitbake console-image >> That worked for me as well once, second time, same problem. >> Problem is that #include <iostream> fails. >> >> I noted that "iostream" is built and available in >> <sysroot>/usr/include/c++ >> On the host, it is located in /usr/incolude/c++/<version> >> "tiff" build seems to be OK with Ubuntu 11.04 i686. >> > what is your BB_NUMBER_THREADS setting ? > Here (on 2 different hosts/distro/arch but with an i7 CPU in both > cases) if I set it over 4, I often (always with a value of 8) meet > problems with c++ includes during build from scratch. 4 seems the > magic value which never trigger the problem. OK, it is higher than that. Was trying out a Core-i7-980X with 6 cores/12 threads with TMP on a fast SSD. The CPU seems to be running at low frequencies most of the time. > > Eric > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Sat, 2011-11-26 at 13:38 +0100, Eric Bénard wrote: > Hi Ulf, > > Le 26/11/2011 12:24, Ulf Samuelsson a écrit : > > 3. When I ran into this problem, I exited with ctrl-C. > > This left some recipes in the middle of a fetch ,and the build could not > > continue. > > I had to "bitbake -c clean <package>" on all problematic packages to recover. > > Seems a little bit fragile to me. > > > already met here : you must let bitbake end the other tasks already started to > prevent that (so only one control C). > > > 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64). > > Fails in the fetch stage. > > I removed the layer, since it was not needed for qemuarm. > > > I also met this kind of problem. To prevent that problem, in my bsp overlay, I > always add COMPATIBLE_MACHINE = "" to the machine specific recipes. > What is strange is that meta-ti also have this in its recipes so their > linux-3.0 recipe should not be used if you target qemuarm. > > > 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host) > > tiff won't build. > > Did: > > bitbake console-image" > > bitbake -c clean tiff > > bitbake tiff > > - No luck > > Reading through the mailing list, I found someone which deleted > > $TMPDIR and then > > bitbake tiff > > bitbake console-image > > That worked for me as well once, second time, same problem. > > Problem is that #include <iostream> fails. > > > > I noted that "iostream" is built and available in <sysroot>/usr/include/c++ > > On the host, it is located in /usr/incolude/c++/<version> > > "tiff" build seems to be OK with Ubuntu 11.04 i686. > > > what is your BB_NUMBER_THREADS setting ? > Here (on 2 different hosts/distro/arch but with an i7 CPU in both cases) if I > set it over 4, I often (always with a value of 8) meet problems with c++ > includes during build from scratch. 4 seems the magic value which never > trigger the problem. To help me get further data points on this issue, are you using rm_work? Do the recent changes in master help (the bitbake sstate/task_skip() ones in particular)? I've not been able to reproduce this :( Cheers, Richard
Le 27/11/2011 12:40, Richard Purdie a écrit : > On Sat, 2011-11-26 at 13:38 +0100, Eric Bénard wrote: >> Le 26/11/2011 12:24, Ulf Samuelsson a écrit : >>> I noted that "iostream" is built and available in<sysroot>/usr/include/c++ >>> On the host, it is located in /usr/incolude/c++/<version> >>> "tiff" build seems to be OK with Ubuntu 11.04 i686. >>> >> what is your BB_NUMBER_THREADS setting ? >> Here (on 2 different hosts/distro/arch but with an i7 CPU in both cases) if I >> set it over 4, I often (always with a value of 8) meet problems with c++ >> includes during build from scratch. 4 seems the magic value which never >> trigger the problem. > > To help me get further data points on this issue, are you using rm_work? > Do the recent changes in master help (the bitbake sstate/task_skip() > ones in particular)? I've not been able to reproduce this :( > yes that was with rm_work, I still need to test with current head. Eric
2011-11-27 12:47, Eric Bénard skrev: > Le 27/11/2011 12:40, Richard Purdie a écrit : >> On Sat, 2011-11-26 at 13:38 +0100, Eric Bénard wrote: >>> Le 26/11/2011 12:24, Ulf Samuelsson a écrit : >>>> I noted that "iostream" is built and available >>>> in<sysroot>/usr/include/c++ >>>> On the host, it is located in /usr/incolude/c++/<version> >>>> "tiff" build seems to be OK with Ubuntu 11.04 i686. >>>> >>> what is your BB_NUMBER_THREADS setting ? >>> Here (on 2 different hosts/distro/arch but with an i7 CPU in both >>> cases) if I >>> set it over 4, I often (always with a value of 8) meet problems with >>> c++ >>> includes during build from scratch. 4 seems the magic value which never >>> trigger the problem. >> >> To help me get further data points on this issue, are you using rm_work? >> Do the recent changes in master help (the bitbake sstate/task_skip() >> ones in particular)? I've not been able to reproduce this :( >> > yes that was with rm_work, I still need to test with current head. > > Eric I have tried Ubuntu 11.10 x64 once more. This time with BB_NUMBER_THREADS = "4" PARALLEL_MAKE = "j4". Not exactly the same symptoms , but similar. This time, the "string" header is not found. | # source='libcg_ba.cpp' object='libcg_ba.o' libtool=no | arm-angstrom-linux-gnueabi-g++ -march=armv5te -mno-thumb -mthumb-interwork -mtune=arm926ej-s -mthumb-interwork -mno-thumb --sysroot=/media/SSD/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm -DHAVE_CONFIG_H -I. -I.. -I../include -O2 -pipe -g -feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden -fvisibility-inlines-hidden -c -o libcg_ba.o libcg_ba.cpp | libcg_ba.cpp:18:18: fatal error: string: No such file or directory | compilation terminated. | make[2]: *** [libcg_ba.o] Error 1 Tried compiling manually. It appears to me that the "--sysroot" directive gets ignored. --sysroot=/media/SSD/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm I manually added "-I/usr/include/c++", but that did not help I then copied "string" to the compile directory, and then the compile continued /until missing the next include file) compiler built: arm-angstrom-linux-gnueabi-g++ --version arm-angstrom-linux-gnueabi-g++ (GCC) 4.5.4 20110917 (prerelease) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The same build works on Ubuntu 11.04 i686. Best Regards Ulf Samuelsson > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Le 27/11/2011 12:40, Richard Purdie a écrit : > To help me get further data points on this issue, are you using rm_work? > Do the recent changes in master help (the bitbake sstate/task_skip() > ones in particular)? I've not been able to reproduce this :( > OK I don't seem to reproduce it with head (but I now meet a new problem with base-passwd, see coming mail). Eric
On Sat, 2011-11-26 at 12:24 +0100, Ulf Samuelsson wrote: > Downloaded the latest, and tried building console-image for qemuarm. > Host = Ubuntu 11.04 i686. > > Looked through the build log, and thought I'd share it with the list. Thanks for doing this, its valuable feedback. > A number of warnings (see below) We're trying to work through addressing those. Some of them are from versions in meta-oe where there is a fix for the error in OECore (such as the libgcc linker hash style). > Seen a couple of errors as well. > > 1. ERROR: Function 'useradd_sysroot' failed > Tried to access "/etc/group" but this was locked. > Problem disappeared the next time I rebuilt. Can you file a bug about this problem please. I think we need to go through the code paths in shadow and ensure its locking is sane. I took a quick look at the code and was left wondering what lckpwdf() does for example. Scott, could you take a look at this? > 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer > available. > tzdata , same problem. > The recipe is located in two places. > meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the > problem > This is what the build uses. This is something to raise with the meta-oe maintainers. I think there isn't a problem in OECore. > 3. When I ran into this problem, I exited with ctrl-C. > This left some recipes in the middle of a fetch ,and the build > could not continue. > I had to "bitbake -c clean <package>" on all problematic > packages to recover. > Seems a little bit fragile to me. Yes, this isn't good. Could you file a bug report on this please? > 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64). > Fails in the fetch stage. > I removed the layer, since it was not needed for qemuarm. Makes sense and its something raise with the meta-ti layer maintainers which I think I've seen elsewhere. > 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host) > tiff won't build. > Did: > bitbake console-image" > bitbake -c clean tiff > bitbake tiff > - No luck > Reading through the mailing list, I found someone which deleted > $TMPDIR and then > bitbake tiff > bitbake console-image > That worked for me as well once, second time, same problem. > Problem is that #include <iostream> fails. > > I noted that "iostream" is built and available in > <sysroot>/usr/include/c++ > On the host, it is located in /usr/incolude/c++/<version> > "tiff" build seems to be OK with Ubuntu 11.04 i686. I think these errors should be fixed by recent changes. If not I'd be interested in the full console log please. Cheers, Richard
Op 29 nov. 2011, om 16:03 heeft Richard Purdie het volgende geschreven: > On Sat, 2011-11-26 at 12:24 +0100, Ulf Samuelsson wrote: >> Downloaded the latest, and tried building console-image for qemuarm. >> Host = Ubuntu 11.04 i686. >> >> Looked through the build log, and thought I'd share it with the list. > > Thanks for doing this, its valuable feedback. > >> A number of warnings (see below) > > We're trying to work through addressing those. Some of them are from > versions in meta-oe where there is a fix for the error in OECore (such > as the libgcc linker hash style). Assuming your statement is true, why isn't the hash style fixed in the .inc? Meta-oe uses the ones from OE-core, so if the include files are sane, the toolchain for meta-oe is sane.
On Tue, 2011-11-29 at 16:50 +0100, Koen Kooi wrote: > Op 29 nov. 2011, om 16:03 heeft Richard Purdie het volgende geschreven: > > > On Sat, 2011-11-26 at 12:24 +0100, Ulf Samuelsson wrote: > >> Downloaded the latest, and tried building console-image for qemuarm. > >> Host = Ubuntu 11.04 i686. > >> > >> Looked through the build log, and thought I'd share it with the list. > > > > Thanks for doing this, its valuable feedback. > > > >> A number of warnings (see below) > > > > We're trying to work through addressing those. Some of them are from > > versions in meta-oe where there is a fix for the error in OECore (such > > as the libgcc linker hash style). > > Assuming your statement is true, why isn't the hash style fixed in > the .inc? Meta-oe uses the ones from OE-core, so if the include files > are sane, the toolchain for meta-oe is sane. Its fixed by a patch so someone needs to backport that patch to the gcc 4.5 patch set. Cheers, Richard
On 2011-11-29 16:03, Richard Purdie wrote: > >> 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer >> available. >> tzdata , same problem. >> The recipe is located in two places. >> meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the >> problem >> This is what the build uses. > This is something to raise with the meta-oe maintainers. I think there > isn't a problem in OECore. Since we now have a large number of layers, maybe it is a good idea to define in each layer, how the "git send email" should behave in by providing a better ".git/config" file in the trunk? I.E: [sendemail] to = openembedded-core@lists.openembedded.org or meta-angstrom/.git/config [sendemail] to = angstrom-distro-devel@linuxtogo.org [format] subjectprefix = "[meta-angstrom]" No need to look in the README file with this.
Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: > On 2011-11-29 16:03, Richard Purdie wrote: >> >>> 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer >>> available. >>> tzdata , same problem. >>> The recipe is located in two places. >>> meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the >>> problem >>> This is what the build uses. >> This is something to raise with the meta-oe maintainers. I think there >> isn't a problem in OECore. > > Since we now have a large number of layers, maybe it is a good > idea to define in each layer, how the "git send email" should behave in > by providing a better ".git/config" file in the trunk? > > > I.E: > > [sendemail] > to = openembedded-core@lists.openembedded.org > > or > meta-angstrom/.git/config > [sendemail] > to = angstrom-distro-devel@linuxtogo.org > [format] > subjectprefix = "[meta-angstrom]" > > > No need to look in the README file with this. That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers
On 2011-11-29 21:06, Koen Kooi wrote: > Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: > >> On 2011-11-29 16:03, Richard Purdie wrote: >>>> 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer >>>> available. >>>> tzdata , same problem. >>>> The recipe is located in two places. >>>> meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the >>>> problem >>>> This is what the build uses. >>> This is something to raise with the meta-oe maintainers. I think there >>> isn't a problem in OECore. >> Since we now have a large number of layers, maybe it is a good >> idea to define in each layer, how the "git send email" should behave in >> by providing a better ".git/config" file in the trunk? >> >> >> I.E: >> >> [sendemail] >> to = openembedded-core@lists.openembedded.org >> >> or >> meta-angstrom/.git/config >> [sendemail] >> to = angstrom-distro-devel@linuxtogo.org >> [format] >> subjectprefix = "[meta-angstrom]" >> >> >> No need to look in the README file with this. > That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers Not really. Even if pulling is the preferred way for certain layers, having this in the config, wouldnt hurt a pulling process. It does makes it more likely that stuff is not sent to the wrong list. BR Ulf Samuelsson > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>> Seen a couple of errors as well. >> >> 1. ERROR: Function 'useradd_sysroot' failed >> Tried to access "/etc/group" but this was locked. >> Problem disappeared the next time I rebuilt. > Can you file a bug about this problem please. I think we need to go > through the code paths in shadow and ensure its locking is sane. I took > a quick look at the code and was left wondering what lckpwdf() does for > example. Scott, could you take a look at this? Bugzilla is out of service, so bugs cannot be filed. Haven't seen the issue since then so it is hard to give any details. I used very high BB_NUMBER_THREADS = 24. This machine (Ubuntu 11.10 /x64) gets stuck in building C++ programs at the moment, so I am considering resinstalling with Ubuntu 11.04 to get something done.
On 11/29/2011 01:18 PM, Ulf Samuelsson wrote: > >>> Seen a couple of errors as well. >>> >>> 1. ERROR: Function 'useradd_sysroot' failed >>> Tried to access "/etc/group" but this was locked. >>> Problem disappeared the next time I rebuilt. >> Can you file a bug about this problem please. I think we need to go >> through the code paths in shadow and ensure its locking is sane. I took >> a quick look at the code and was left wondering what lckpwdf() does for >> example. Scott, could you take a look at this? > > Bugzilla is out of service, so bugs cannot be filed. I have filed a bug for this, and have been trying to reproduce it without success: http://bugzilla.pokylinux.org/show_bug.cgi?id=1794 > Haven't seen the issue since then so it is hard to give any details. > I used very high BB_NUMBER_THREADS = 24. I do have access to a system with a lot of cores, and have been doing builds on it. I'd just like to confirm that when you saw this, it was a build from scratch (e.g, not using sstate cache from a previous build). And also, you *weren't* building this from a remote filesystem (NFS), correct? Thanks, Scott
On (29/11/11 16:03), Richard Purdie wrote: > > Assuming your statement is true, why isn't the hash style fixed in > > the .inc? Meta-oe uses the ones from OE-core, so if the include files > > are sane, the toolchain for meta-oe is sane. > > Its fixed by a patch so someone needs to backport that patch to the gcc > 4.5 patch set. I have intentionally not ported the patch back to 4.5 but let me see if I can find some spare hours -Khem
On Wed, 2011-11-30 at 17:52 -0800, Khem Raj wrote: > On (29/11/11 16:03), Richard Purdie wrote: > > > Assuming your statement is true, why isn't the hash style fixed in > > > the .inc? Meta-oe uses the ones from OE-core, so if the include files > > > are sane, the toolchain for meta-oe is sane. > > > > Its fixed by a patch so someone needs to backport that patch to the gcc > > 4.5 patch set. > > I have intentionally not ported the patch back to 4.5 but let me see if > I can find some spare hours Don't take my comments as a request to do so btw, personally speaking I don't see it as a problem. I just wanted to be clear about what was missing. Cheers, Richard
On 11/29/2011 03:06 PM, Koen Kooi wrote: > > Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: > >> On 2011-11-29 16:03, Richard Purdie wrote: >>> >>>> 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer >>>> available. >>>> tzdata , same problem. >>>> The recipe is located in two places. >>>> meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the >>>> problem >>>> This is what the build uses. >>> This is something to raise with the meta-oe maintainers. I think there >>> isn't a problem in OECore. >> >> Since we now have a large number of layers, maybe it is a good >> idea to define in each layer, how the "git send email" should behave in >> by providing a better ".git/config" file in the trunk? >> >> >> I.E: >> >> [sendemail] >> to = openembedded-core@lists.openembedded.org >> >> or >> meta-angstrom/.git/config >> [sendemail] >> to = angstrom-distro-devel@linuxtogo.org >> [format] >> subjectprefix = "[meta-angstrom]" >> >> >> No need to look in the README file with this. > > That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers Even if it is not the preferred way, it would direct the discussion to the appropriate list. This would reduce the number of mis-directed emails to this list. And we know that no one reads the README's :) Philip > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 2011-11-30 18:30, Scott Garman wrote: > On 11/29/2011 01:18 PM, Ulf Samuelsson wrote: >> >>>> Seen a couple of errors as well. >>>> >>>> 1. ERROR: Function 'useradd_sysroot' failed >>>> Tried to access "/etc/group" but this was locked. >>>> Problem disappeared the next time I rebuilt. >>> Can you file a bug about this problem please. I think we need to go >>> through the code paths in shadow and ensure its locking is sane. I took >>> a quick look at the code and was left wondering what lckpwdf() does for >>> example. Scott, could you take a look at this? >> >> Bugzilla is out of service, so bugs cannot be filed. > > I have filed a bug for this, and have been trying to reproduce it > without success: > > http://bugzilla.pokylinux.org/show_bug.cgi?id=1794 > >> Haven't seen the issue since then so it is hard to give any details. >> I used very high BB_NUMBER_THREADS = 24. > > I do have access to a system with a lot of cores, and have been doing > builds on it. > > I'd just like to confirm that when you saw this, it was a build from > scratch (e.g, not using sstate cache from a previous build). And also, > you *weren't* building this from a remote filesystem (NFS), correct? > > Thanks, > > Scott > No NFS for sure. I think this was the first build, but only 99% sure. It disappered when I restarted the build. Have not seen this problem repeated, but then, the build on this machine has other problems Packages tend to fail since the c++ compiler seems to ignore "--sysroot" Machine = Ubuntu-11.10 x64. This is with BB_NUMBER_THREADS = "4" If I change this, then the same problem occur, but in a different package. (Tried with "4" AND "24") BR Ulf
Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: > On 11/29/2011 03:06 PM, Koen Kooi wrote: >> >> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: >> >>> On 2011-11-29 16:03, Richard Purdie wrote: >>>> >>>>> 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer >>>>> available. >>>>> tzdata , same problem. >>>>> The recipe is located in two places. >>>>> meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the >>>>> problem >>>>> This is what the build uses. >>>> This is something to raise with the meta-oe maintainers. I think there >>>> isn't a problem in OECore. >>> >>> Since we now have a large number of layers, maybe it is a good >>> idea to define in each layer, how the "git send email" should behave in >>> by providing a better ".git/config" file in the trunk? >>> >>> >>> I.E: >>> >>> [sendemail] >>> to = openembedded-core@lists.openembedded.org >>> >>> or >>> meta-angstrom/.git/config >>> [sendemail] >>> to = angstrom-distro-devel@linuxtogo.org >>> [format] >>> subjectprefix = "[meta-angstrom]" >>> >>> >>> No need to look in the README file with this. >> >> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers > > Even if it is not the preferred way, it would direct the discussion to > the appropriate list. This would reduce the number of mis-directed > emails to this list. You can't fix stupid, sadly.
2011-12-01 16:37, Koen Kooi skrev: > Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: > >> On 11/29/2011 03:06 PM, Koen Kooi wrote: >>> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: >>> >>>> On 2011-11-29 16:03, Richard Purdie wrote: >>>>>> 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer >>>>>> available. >>>>>> tzdata , same problem. >>>>>> The recipe is located in two places. >>>>>> meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the >>>>>> problem >>>>>> This is what the build uses. >>>>> This is something to raise with the meta-oe maintainers. I think there >>>>> isn't a problem in OECore. >>>> Since we now have a large number of layers, maybe it is a good >>>> idea to define in each layer, how the "git send email" should behave in >>>> by providing a better ".git/config" file in the trunk? >>>> >>>> >>>> I.E: >>>> >>>> [sendemail] >>>> to = openembedded-core@lists.openembedded.org >>>> >>>> or >>>> meta-angstrom/.git/config >>>> [sendemail] >>>> to = angstrom-distro-devel@linuxtogo.org >>>> [format] >>>> subjectprefix = "[meta-angstrom]" >>>> >>>> >>>> No need to look in the README file with this. >>> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers >> Even if it is not the preferred way, it would direct the discussion to >> the appropriate list. This would reduce the number of mis-directed >> emails to this list. > You can't fix stupid, sadly. Tend to disagree. The whole purpose of OE is to make it possible for people, stupid or not, to go off and make things which they would not be able to do on their own. As I see it, it is no real drawback of adding this, and at least some benefit. As for not beeing the preferred way, I think that people that engage themselves in a layer should adopt the preferred way. Anyone seeing a bad layer, applicable only to a small subset of users, interfering with their build should not be expected to put a lof of effort into the fix, except reporting it. Then the mailing list is probably the easiest thing to use. If this is not there, expect them to send it to the official list. BR Ulf > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
2011/12/1 Ulf Samuelsson <openembedded-core@emagii.com> > 2011-12-01 16:37, Koen Kooi skrev: > > Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: > > > On 11/29/2011 03:06 PM, Koen Kooi wrote: > > Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: > > > On 2011-11-29 16:03, Richard Purdie wrote: > > 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" <ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz> is no longer > available. > tzdata , same problem. > The recipe is located in two places. > meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the > problem > This is what the build uses. > > This is something to raise with the meta-oe maintainers. I think there > isn't a problem in OECore. > > Since we now have a large number of layers, maybe it is a good > idea to define in each layer, how the "git send email" should behave in > by providing a better ".git/config" file in the trunk? > > > I.E: > > [sendemail] > to = openembedded-core@lists.openembedded.org > > or > meta-angstrom/.git/config > [sendemail] > to = angstrom-distro-devel@linuxtogo.org > [format] > subjectprefix = "[meta-angstrom]" > > > No need to look in the README file with this. > > That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers > > Even if it is not the preferred way, it would direct the discussion to > the appropriate list. This would reduce the number of mis-directed > emails to this list. > > You can't fix stupid, sadly. > > > Tend to disagree. > The whole purpose of OE is to make it possible for people, > stupid or not, to go off and make things which they would > not be able to do on their own. > > As I see it, it is no real drawback of adding this, and at least some > benefit. > > As for not beeing the preferred way, I think that people that engage > themselves > in a layer should adopt the preferred way. > > Anyone seeing a bad layer, applicable only to a small subset of users, > interfering with their build should not be expected > to put a lof of effort into the fix, except reporting it. > Then the mailing list is probably the easiest thing to use. > > If this is not there, expect them to send it to the official list. > BR > Ulf > My two cents: If I see a small problem in a layer that I am not working on and submitting a patch is easy (e.g. committing the patch, doing a send-email) I would probably do so. If it becomes harder (since I have to find what list it needs to be send to) chances that the effort is made become smaller and actually depending on the time at hand If i have to set up a git mirror just for this single patch, forget it. I think if we want to encourage people fixing and submitting patches it helps to have a mailing address in the config file. But of course if you prefer to do maintenance only with the happy few, this is less desirable (but then you should probably consider not accepting mailed patches at all) frans
Op 1 dec. 2011, om 17:31 heeft Ulf Samuelsson het volgende geschreven: > 2011-12-01 16:37, Koen Kooi skrev: >> Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: >> >> >>> On 11/29/2011 03:06 PM, Koen Kooi wrote: >>> >>>> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: >>>> >>>> >>>>> On 2011-11-29 16:03, Richard Purdie wrote: >>>>> >>>>>>> 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" >>>>>>> is no longer >>>>>>> available. >>>>>>> tzdata , same problem. >>>>>>> The recipe is located in two places. >>>>>>> meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the >>>>>>> problem >>>>>>> This is what the build uses. >>>>>>> >>>>>> This is something to raise with the meta-oe maintainers. I think there >>>>>> isn't a problem in OECore. >>>>>> >>>>> Since we now have a large number of layers, maybe it is a good >>>>> idea to define in each layer, how the "git send email" should behave in >>>>> by providing a better ".git/config" file in the trunk? >>>>> >>>>> >>>>> I.E: >>>>> >>>>> [sendemail] >>>>> to = >>>>> openembedded-core@lists.openembedded.org >>>>> >>>>> >>>>> or >>>>> meta-angstrom/.git/config >>>>> [sendemail] >>>>> to = >>>>> angstrom-distro-devel@linuxtogo.org >>>>> >>>>> [format] >>>>> subjectprefix = "[meta-angstrom]" >>>>> >>>>> >>>>> No need to look in the README file with this. >>>>> >>>> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers >>>> >>> Even if it is not the preferred way, it would direct the discussion to >>> the appropriate list. This would reduce the number of mis-directed >>> emails to this list. >>> >> You can't fix stupid, sadly. >> > > Tend to disagree. > The whole purpose of OE is to make it possible for people, > stupid or not, to go off and make things which they would > not be able to do on their own. > > As I see it, it is no real drawback of adding this, and at least some benefit. The drawback is that people will postpone reading the README even longer. Why are you so dead against having people read the README?
On 2011-12-02 10:49, Koen Kooi wrote: > Op 1 dec. 2011, om 17:31 heeft Ulf Samuelsson het volgende geschreven: > >> 2011-12-01 16:37, Koen Kooi skrev: >>> Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: >>> >>> >>>> On 11/29/2011 03:06 PM, Koen Kooi wrote: >>>> >>>>> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: >>>>> >>>>> >>>>>> On 2011-11-29 16:03, Richard Purdie wrote: >>>>>> >>>>>>>> 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" >>>>>>>> is no longer >>>>>>>> available. >>>>>>>> tzdata , same problem. >>>>>>>> The recipe is located in two places. >>>>>>>> meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the >>>>>>>> problem >>>>>>>> This is what the build uses. >>>>>>>> >>>>>>> This is something to raise with the meta-oe maintainers. I think there >>>>>>> isn't a problem in OECore. >>>>>>> >>>>>> Since we now have a large number of layers, maybe it is a good >>>>>> idea to define in each layer, how the "git send email" should behave in >>>>>> by providing a better ".git/config" file in the trunk? >>>>>> >>>>>> >>>>>> I.E: >>>>>> >>>>>> [sendemail] >>>>>> to = >>>>>> openembedded-core@lists.openembedded.org >>>>>> >>>>>> >>>>>> or >>>>>> meta-angstrom/.git/config >>>>>> [sendemail] >>>>>> to = >>>>>> angstrom-distro-devel@linuxtogo.org >>>>>> >>>>>> [format] >>>>>> subjectprefix = "[meta-angstrom]" >>>>>> >>>>>> >>>>>> No need to look in the README file with this. >>>>>> >>>>> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers >>>>> >>>> Even if it is not the preferred way, it would direct the discussion to >>>> the appropriate list. This would reduce the number of mis-directed >>>> emails to this list. >>>> >>> You can't fix stupid, sadly. >>> >> Tend to disagree. >> The whole purpose of OE is to make it possible for people, >> stupid or not, to go off and make things which they would >> not be able to do on their own. >> >> As I see it, it is no real drawback of adding this, and at least some benefit. > The drawback is that people will postpone reading the README even longer. > > Why are you so dead against having people read the README? I am against that every layer should *appear to* have their own way of treating feedback. There should be a common README on how to provide a patch, and any difference in where it ends up should be hidden in the system. This will make it easy for the causal user of a layer. If you want stuff to be pulled, then there are ways of handling this. Instead of directing the email to a list, you could direct the mail to a special address, which bounces back a message saying that the recommended thing is to pull. It could of course forward to the real list as well. As mentioned before by me, and by Frans right now, If I have to set up a git mirror for something I dont use (like meta-ti right now), just because this has a problem which affects my builds, I won't do that. As I dig deeper into openembedded-core, I will probably get to setting up git mirrors for the layers I use. OTOH , If I am bored and pull up my Beagleboard from a drawer, again I would probably do a git mirror for meta-ti. Some further study shows that the idea will not work as intended fully. meta-openembedded and meta-handhelds have "meta-*" subdirectories which each have their own README with different instructions for the same git tree. Seems kind of strange to me. BR Ulf Samuelsson > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 2011-12-01 15:49, Ulf Samuelsson wrote: > On 2011-11-30 18:30, Scott Garman wrote: >> On 11/29/2011 01:18 PM, Ulf Samuelsson wrote: >>> >>>>> Seen a couple of errors as well. >>>>> >>>>> 1. ERROR: Function 'useradd_sysroot' failed >>>>> Tried to access "/etc/group" but this was locked. >>>>> Problem disappeared the next time I rebuilt. >>>> Can you file a bug about this problem please. I think we need to go >>>> through the code paths in shadow and ensure its locking is sane. I >>>> took >>>> a quick look at the code and was left wondering what lckpwdf() does >>>> for >>>> example. Scott, could you take a look at this? >>> >>> Bugzilla is out of service, so bugs cannot be filed. >> >> I have filed a bug for this, and have been trying to reproduce it >> without success: >> >> http://bugzilla.pokylinux.org/show_bug.cgi?id=1794 >> >>> Haven't seen the issue since then so it is hard to give any details. >>> I used very high BB_NUMBER_THREADS = 24. >> >> I do have access to a system with a lot of cores, and have been doing >> builds on it. >> >> I'd just like to confirm that when you saw this, it was a build from >> scratch (e.g, not using sstate cache from a previous build). And >> also, you *weren't* building this from a remote filesystem (NFS), >> correct? >> >> Thanks, >> >> Scott >> > No NFS for sure. > > I think this was the first build, but only 99% sure. > It disappered when I restarted the build. > > Have not seen this problem repeated, but then, the build on this > machine has other problems > > Packages tend to fail since the c++ compiler seems to ignore "--sysroot" > > Machine = Ubuntu-11.10 x64. > > This is with BB_NUMBER_THREADS = "4" > If I change this, then the same problem occur, but in a different > package. > (Tried with "4" AND "24") > Have made some further tests with the same machine, but now running Ubuntu 11.04 x64 bitbake console-image PARALLEL_TASKS BB_NUMBER_TASKS BUILD TIME 2 2 1:24:16 4 4 0:48:22 6 6 0:45:00 24 24 C++ compiler fails with --sysroot problem after ~2200 out of 2400 tasks. BR Ulf
Patch
From 7c6dc15fe61b367a32324959036488059d130722 Mon Sep 17 00:00:00 2001 From: Ulf Samuelsson <ulf.samuelsson@atmel.com> Date: Sat, 26 Nov 2011 09:15:57 +0100 Subject: [PATCH 2/2] tzdata: Change tarball location Signed-off-by: Ulf Samuelsson <ulf.samuelsson@telia.com> --- meta-oe/recipes-extended/tzdata/tzdata.inc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-oe/recipes-extended/tzdata/tzdata.inc b/meta-oe/recipes-extended/tzdata/tzdata.inc index ceec924..9192d9b 100644 --- a/meta-oe/recipes-extended/tzdata/tzdata.inc +++ b/meta-oe/recipes-extended/tzdata/tzdata.inc @@ -11,7 +11,7 @@ RCONFLICTS_${PN} = "timezones timezone-africa timezone-america timezone-antarcti timezone-australia timezone-europe timezone-indian \ timezone-iso3166.tab timezone-pacific timezone-zone.tab" -SRC_URI = "ftp://elsie.nci.nih.gov/pub/tzdata${PV}.tar.gz;subdir=${BPN}-${PV}" +SRC_URI = "http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;subdir=${BPN}-${PV}" TZONES= "africa antarctica asia australasia europe northamerica southamerica \ factory solar87 solar88 solar89 etcetera backward systemv \ -- 1.7.4.1
Downloaded the latest, and tried building console-image for qemuarm. Host = Ubuntu 11.04 i686. Looked through the build log, and thought I'd share it with the list. A number of warnings (see below) Seen a couple of errors as well. 1. ERROR: Function 'useradd_sysroot' failed Tried to access "/etc/group" but this was locked. Problem disappeared the next time I rebuilt. 2. "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer available. tzdata , same problem. The recipe is located in two places. meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the problem This is what the build uses. 3. When I ran into this problem, I exited with ctrl-C. This left some recipes in the middle of a fetch ,and the build could not continue. I had to "bitbake -c clean <package>" on all problematic packages to recover. Seems a little bit fragile to me. 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64). Fails in the fetch stage. I removed the layer, since it was not needed for qemuarm. 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host) tiff won't build. Did: bitbake console-image" bitbake -c clean tiff bitbake tiff - No luck Reading through the mailing list, I found someone which deleted $TMPDIR and then bitbake tiff bitbake console-image That worked for me as well once, second time, same problem. Problem is that #include <iostream> fails. I noted that "iostream" is built and available in <sysroot>/usr/include/c++ On the host, it is located in /usr/incolude/c++/<version> "tiff" build seems to be OK with Ubuntu 11.04 i686. BR Ulf Samuelsson ------------------------------------------------------------------------------------------ The following packages could not be downloaded. http://kernel.org/pub/linux/utils/util-linux-ng/v2.19/util-linux-2.19.1.tar.bz2 http://kernel.org/pub/linux/libs/pam/library/Linux-PAM-1.1.4.tar.bz2 http://kernel.org/pub/linux/kernel/people/jsipek/guilt/guilt-0.33.tar.gz http://kernel.org/pub/linux/utils/kernel/module-init-tools/module-init-tools-3.16.tar.bz2 http://kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-2.22.tar.bz2 http://kernel.org/pub/linux/utils/usb/usbutils/usbutils-0.91.tar.gz http://kernel.org/pub/linux/bluetooth/bluez-4.96.tar.gz http://www.kernel.org/pub/linux/bluetooth/bluez-hcidump-2.1.tar.gz http://kernel.org/pub/linux/utils/kbd/kbd-1.15.2.tar.bz2 http://kernel.org/pub/linux/utils/kernel/pcmcia/pcmciautils-018.tar.bz2 http://www.kernel.org/pub/linux/network/connman/connman-0.77.tar.gz ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz WARNING: zip: No generic license file exists for: Info-ZIP at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: zip: There is also no SPDXLICENSEMAP for this license type: Info-ZIP at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: tcp-wrappers: No generic license file exists for: tcp-wrappers at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: tcp-wrappers: There is also no SPDXLICENSEMAP for this license type: tcp-wrappers at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: Missing md5 SRC_URI checksum for /home/downloads/downloads/hicolor-icon-theme-0.12.tar.gz, consider adding to the recipe: SRC_URI[md5sum] = "55cafbcef8bcf7107f6d502149eb4d87" WARNING: Missing sha256 SRC_URI checksum for /home/downloads/downloads/hicolor-icon-theme-0.12.tar.gz, consider adding to the recipe: SRC_URI[sha256sum] = "9edca690617eaa19054951ca53501c802180262be8880ed84754ac46c93bec73" WARNING: perl: No generic license file exists for: Artistic|GPL at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: perl: There is also no SPDXLICENSEMAP for this license type: Artistic|GPL at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gmp: No generic license file exists for: LGPLv3&GPLv3 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gmp: There is also no SPDXLICENSEMAP for this license type: LGPLv3&GPLv3 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: bzip2: No generic license file exists for: bzip2 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: bzip2: There is also no SPDXLICENSEMAP for this license type: bzip2 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: busybox: No generic license file exists for: bzip2 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: busybox: There is also no SPDXLICENSEMAP for this license type: bzip2 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: ntp: No generic license file exists for: ntp at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: ntp: There is also no SPDXLICENSEMAP for this license type: ntp at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: For recipe resolvconf, the following files/directories were installed but not shipped in any package: WARNING: /usr/sbin WARNING: /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/qemuarm-angstrom-linux-gnueabi/sysvinit-inittab-2.88dsf-r6/sysvinit-2.88dsf/COPYING could not be copied for some reason. It may not exist. WARN for now. WARNING: python: No generic license file exists for: PSFv2 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: python: There is also no SPDXLICENSEMAP for this license type: PSFv2 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: dnsmasq-dbus: No generic license file exists for: GPLv2GPLv3 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: dnsmasq-dbus: There is also no SPDXLICENSEMAP for this license type: GPLv2GPLv3 at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: elfutils: No generic license file exists for: Exception at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: elfutils: There is also no SPDXLICENSEMAP for this license type: Exception at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: libgcc: No generic license file exists for: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: libgcc: There is also no SPDXLICENSEMAP for this license type: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gcc-cross: No generic license file exists for: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gcc-cross: There is also no SPDXLICENSEMAP for this license type: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gcc-cross-initial: No generic license file exists for: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gcc-cross-initial: There is also no SPDXLICENSEMAP for this license type: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gcc-cross-intermediate: No generic license file exists for: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gcc-cross-intermediate: There is also no SPDXLICENSEMAP for this license type: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gcc-runtime: No generic license file exists for: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: gcc-runtime: There is also no SPDXLICENSEMAP for this license type: GCCRUNTIMELIBRARYEXCEPTION at /home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses WARNING: For recipe eglibc, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/locale WARNING: For recipe libgcc, the following files/directories were installed but not shipped in any package: WARNING: /usr/src WARNING: /usr/src/debug WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/libgcc-4.5-r43+svnr178923/packages-split/libgcc/lib/libgcc_s.so.1' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/zip-3.0-r0/packages-split/zip/usr/bin/zipsplit' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/zip-3.0-r0/packages-split/zip/usr/bin/zip' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/zip-3.0-r0/packages-split/zip/usr/bin/zipnote' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/zip-3.0-r0/packages-split/zip/usr/bin/zipcloak' WARNING: For recipe ncurses, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/terminfo WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/gdbm-1.8.3-r4/packages-split/gdbm/usr/lib/libgdbm.so.3.0.0' WARNING: For recipe openssl, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/engines WARNING: /usr/lib/ssl/private WARNING: /usr/lib/ssl/certs WARNING: For recipe readline, the following files/directories were installed but not shipped in any package: WARNING: /usr/bin WARNING: QA Issue: readline: /work/armv5te-angstrom-linux-gnueabi/readline-6.2-r0/packages-split/readline/usr/lib/libhistory.so.6 contains probably-redundant RPATH /usr/lib WARNING: QA Issue: readline: /work/armv5te-angstrom-linux-gnueabi/readline-6.2-r0/packages-split/readline/usr/lib/libhistory.so.6.2 contains probably-redundant RPATH /usr/lib WARNING: QA Issue: readline: /work/armv5te-angstrom-linux-gnueabi/readline-6.2-r0/packages-split/readline/usr/lib/libreadline.so.6.2 contains probably-redundant RPATH /usr/lib WARNING: QA Issue: readline: /work/armv5te-angstrom-linux-gnueabi/readline-6.2-r0/packages-split/readline/usr/lib/libreadline.so.6 contains probably-redundant RPATH /usr/lib WARNING: For recipe cracklib, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/python2.7 WARNING: /usr/lib/python2.7/site-packages WARNING: For recipe libcgroup, the following files/directories were installed but not shipped in any package: WARNING: /lib/security/pam_cgroup.la WARNING: /lib/security/.debug WARNING: /lib/security/.debug/pam_cgroup.so WARNING: /lib/security/.debug/pam_cgroup.so.0.0.0 WARNING: /lib/security/.debug/pam_cgroup.so.0 WARNING: For recipe libgcrypt, the following files/directories were installed but not shipped in any package: WARNING: /usr/sbin WARNING: For recipe dbus, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/dbus-1.0/test WARNING: For recipe glib-2.0, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/gio WARNING: /usr/lib/gio/modules WARNING: For recipe perl, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/perl/site_perl WARNING: /usr/lib/perl/site_perl/5.14.2 WARNING: For recipe angstrom-version, the following files/directories were installed but not shipped in any package: WARNING: /usr/src WARNING: /usr/src/debug WARNING: For recipe dbus-glib, the following files/directories were installed but not shipped in any package: WARNING: /etc WARNING: /etc/bash_completion.d WARNING: /etc/bash_completion.d/dbus-bash-completion.sh WARNING: /usr/libexec/dbus-bash-completion-helper WARNING: For recipe alsa-utilsWARNING, the following files/directories were installed but not shipped in any package: WARNING: /var WARNING: /var/lib WARNING: /var/lib/alsa WARNING: For recipe udev, the following files/directories were installed but not shipped in any package: WARNING: /usr/sbin WARNING: For recipe avahi, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/avahi WARNING: For recipe bluez4, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/bluetooth WARNING: /usr/lib/bluetooth/plugins WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-lib/usr/lib/libperl.so.5.14.2' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-symbol/usr/lib/perl/5.14.2/auto/Encode/Symbol/Symbol.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-unicode/usr/lib/perl/5.14.2/auto/Encode/Unicode/Unicode.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-jp/usr/lib/perl/5.14.2/auto/Encode/JP/JP.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-cn/usr/lib/perl/5.14.2/auto/Encode/CN/CN.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-tw/usr/lib/perl/5.14.2/auto/Encode/TW/TW.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-kr/usr/lib/perl/5.14.2/auto/Encode/KR/KR.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-byte/usr/lib/perl/5.14.2/auto/Encode/Byte/Byte.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-ebcdic/usr/lib/perl/5.14.2/auto/Encode/EBCDIC/EBCDIC.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-b/usr/lib/perl/5.14.2/auto/B/B.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-unicode/usr/lib/perl/5.14.2/auto/Unicode/Normalize/Normalize.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-unicode/usr/lib/perl/5.14.2/auto/Unicode/Collate/Collate.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-mro/usr/lib/perl/5.14.2/auto/mro/mro.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-posix/usr/lib/perl/5.14.2/auto/POSIX/POSIX.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-fcntl/usr/lib/perl/5.14.2/auto/Fcntl/Fcntl.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-devel/usr/lib/perl/5.14.2/auto/Devel/PPPort/PPPort.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-devel/usr/lib/perl/5.14.2/auto/Devel/Peek/Peek.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-devel/usr/lib/perl/5.14.2/auto/Devel/DProf/DProf.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-io/usr/lib/perl/5.14.2/auto/IO/IO.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-list/usr/lib/perl/5.14.2/auto/List/Util/Util.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-opcode/usr/lib/perl/5.14.2/auto/Opcode/Opcode.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-cwd/usr/lib/perl/5.14.2/auto/Cwd/Cwd.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-file/usr/lib/perl/5.14.2/auto/File/Glob/Glob.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-compress/usr/lib/perl/5.14.2/auto/Compress/Raw/Bzip2/Bzip2.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-compress/usr/lib/perl/5.14.2/auto/Compress/Raw/Zlib/Zlib.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-sdbm-file/usr/lib/perl/5.14.2/auto/SDBM_File/SDBM_File.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-attributes/usr/lib/perl/5.14.2/auto/attributes/attributes.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-math/usr/lib/perl/5.14.2/auto/Math/BigInt/FastCalc/FastCalc.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-text/usr/lib/perl/5.14.2/auto/Text/Soundex/Soundex.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-re/usr/lib/perl/5.14.2/auto/re/re.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-sys/usr/lib/perl/5.14.2/auto/Sys/Syslog/Syslog.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-sys/usr/lib/perl/5.14.2/auto/Sys/Hostname/Hostname.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-threads/usr/lib/perl/5.14.2/auto/threads/threads.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-threads/usr/lib/perl/5.14.2/auto/threads/shared/shared.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-storable/usr/lib/perl/5.14.2/auto/Storable/Storable.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-hash/usr/lib/perl/5.14.2/auto/Hash/Util/Util.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-hash/usr/lib/perl/5.14.2/auto/Hash/Util/FieldHash/FieldHash.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-ipc/usr/lib/perl/5.14.2/auto/IPC/SysV/SysV.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-digest/usr/lib/perl/5.14.2/auto/Digest/MD5/MD5.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-digest/usr/lib/perl/5.14.2/auto/Digest/SHA/SHA.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-gdbm-file/usr/lib/perl/5.14.2/auto/GDBM_File/GDBM_File.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-i18n/usr/lib/perl/5.14.2/auto/I18N/Langinfo/Langinfo.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-data/usr/lib/perl/5.14.2/auto/Data/Dumper/Dumper.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-filter/usr/lib/perl/5.14.2/auto/Filter/Util/Call/Call.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-socket/usr/lib/perl/5.14.2/auto/Socket/Socket.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-time/usr/lib/perl/5.14.2/auto/Time/HiRes/HiRes.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-time/usr/lib/perl/5.14.2/auto/Time/Piece/Piece.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-perlio/usr/lib/perl/5.14.2/auto/PerlIO/encoding/encoding.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-perlio/usr/lib/perl/5.14.2/auto/PerlIO/scalar/scalar.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-perlio/usr/lib/perl/5.14.2/auto/PerlIO/via/via.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-mime/usr/lib/perl/5.14.2/auto/MIME/Base64/Base64.so' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode/usr/lib/perl/5.14.2/auto/Encode/Encode.so' WARNING: For recipe ntp, the following files/directories were installed but not shipped in any package: WARNING: /usr/sbin WARNING: /usr/lib WARNING: For recipe netbase, the following files/directories were installed but not shipped in any package: WARNING: /usr/sbin WARNING: For recipe systemd, the following files/directories were installed but not shipped in any package: WARNING: /usr/lib/binfmt.d WARNING: /usr/lib/sysctl.d WARNING: /usr/lib/modules-load.d WARNING: For recipe linux-yocto, the following files/directories were installed but not shipped in any package: WARNING: /etc/modprobe.d WARNING: /lib/modules/3.0.8-yocto-standard+/modules.builtin WARNING: /lib/modules/3.0.8-yocto-standard+/modules.order WARNING: /lib/modules/3.0.8-yocto-standard+/build WARNING: /lib/modules/3.0.8-yocto-standard+/source WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/irda-utils-0.9.18-r0/packages-split/irda-utils/usr/sbin/dongle_attach' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/irda-utils-0.9.18-r0/packages-split/irda-utils/usr/sbin/irdaping' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/irda-utils-0.9.18-r0/packages-split/irda-utils/usr/sbin/irattach' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/hostap-utils-0.4.7-r4/packages-split/hostap-utils/usr/sbin/hostap_io_debug' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/hostap-utils-0.4.7-r4/packages-split/hostap-utils/usr/sbin/hostap_rid' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/hostap-utils-0.4.7-r4/packages-split/hostap-utils/usr/sbin/hostap_diag' WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/wireless-tools-1_29-r2/packages-split/libiw/usr/lib/libiw.so.29' ERROR: Function 'useradd_sysroot' failed (see /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/systemd-git-r6/temp/log.do_install.30331 for further information) ERROR: Logfile of failure stored in: /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/systemd-git-r6/temp/log.do_install.30331 Log data follows: | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common'] | ERROR: Function 'useradd_sysroot' failed (see /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/systemd-git-r6/temp/log.do_install.30331 for further information) | + cd /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/systemd-git-r6/git | + useradd_sysroot | + export PSEUDO=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/pseudo | + PSEUDO=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/pseudo | + export PSEUDO_LOCALSTATEDIR=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm/var/pseudo | + PSEUDO_LOCALSTATEDIR=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm/var/pseudo | + D=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm | + useradd_preinst | + OPT= | + SYSROOT= | + test x/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm '!=' x | + SYSROOT=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm | + OPT='--root /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm' | + GROUPADD_PARAM='-r lock' | + USERADD_PARAM= | + test 'x-r lock' '!=' x | + echo 'Running groupadd commands...' | Running groupadd commands... | ++ echo '-r lock' | ++ cut -d ';' -f 1 | + opts='-r lock' | ++ echo '-r lock' | ++ cut -d ';' -f 2- | + remaining='-r lock' | + test 'x-r lock' '!=' x | ++ echo '-r lock' | ++ awk '{ print $NF }' | + groupname=lock | ++ grep '^lock:' /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm/etc/group | ++ true | + group_exists= | + test x = x | + eval /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/pseudo groupadd --root /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm -r lock | ++ /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/pseudo groupadd --root /home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm -r lock | groupadd: cannot lock /etc/group; try again later. NOTE: package systemd-git-r6: task do_install: Failed ERROR: Task 158 (/home/ulf/projects/OE_core/setup-scripts/sources/meta-openembedded/meta-oe/recipes-core/systemd/systemd_git.bb, do_install) failed with exit code '1'