Re: [yocto] how to separate packages in downloads folder into those that run on target and those that do not run on target?
Dear Gangadhar, In message CAKxnL=hss5nncqy9ztzi0xwxgjoon0i_0f-x7k7jksczzrg...@mail.gmail.com you wrote: I want to separate the packages in downloads folder. I want to separate the packages into those that run on target and those that do not run on the target. The idea is to feed the packages that go into target to fossology Do you think such a separation is possible at all? Depending on your target configuration, packages might go into both - for example, if you build SDK / toolchain images, then gcc and related tools will be both in the cross tools and in the target file system. And why do you need to split the downloads folder for that? You have the list of packages that get installed into your target file system - is this not sufficient? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The complexity of software is an essential property, not an acciden- tal one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.- Fred Brooks, Jr. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Referencing sysroot libraries during build?
Hello,
I have a build problem which is caused by libraries not being found.
It's a recipe to build the U-Boot bot loader which includes running
the mkimage tool generated during this build. This fails as
follows:
...
| LD u-boot
| OBJCOPY u-boot.bin
| MKIMAGE u-boot.img
|
/opt/eldk/build/eldk-rel-v5.6-2014-08-17-fe344de-mcvevk/tmp/work/mcvevk-linux-gnueabi/u-boot/v2014.10+gitAUTOINC+c43fd23cf6-r0/git/tools/mkimage:
error while loading shared libraries: libssl.so.1.0.0: cannot open shared
object file: No such file or directory
| make: *** [u-boot.img] Error 127
I verified that the LD_LIBRARY_PATH variable is not set when these
commands are run, which explains the problem:
- ldd
/opt/eldk/build/eldk-rel-v5.6-2014-08-17-fe344de-mcvevk/tmp/work/mcvevk-linux-gnueabi/u-boot/v2014.10+gitAUTOINC+c43fd23cf6-r0/git/tools/mkimage
linux-vdso.so.1 = (0x7fff6a7fe000)
libssl.so.1.0.0 = not found
libcrypto.so.1.0.0 = not found
libc.so.6 = /lib64/libc.so.6 (0x00339600)
/lib64/ld-linux-x86-64.so.2 (0x003395c0)
The reason is that this system uses a different version of these libraries:
- ls -l /lib64/libssl.so.1* /lib64/libcrypto.so.1*
-rwxr-xr-x 1 root root 1972736 Aug 8 13:48 /lib64/libcrypto.so.1.0.1e
lrwxrwxrwx 1 root root 19 Sep 2 23:49 /lib64/libcrypto.so.10 -
libcrypto.so.1.0.1e
-rwxr-xr-x 1 root root 446040 Aug 8 13:48 /lib64/libssl.so.1.0.1e
lrwxrwxrwx 1 root root 16 Sep 2 23:49 /lib64/libssl.so.10 -
libssl.so.1.0.1e
So the host system is using one version of these libraries, while the
build is done against a different version.
I can work around this problem by adding the build's sysroot
libraries to LD_LIBRARY_PATH, like that:
do_compile_prepend () {
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${STAGING_LIBDIR_NATIVE}:${STAGING_LIBDIR_NATIVE}/../../lib
}
But this looks wrong to me - if this was needed, should it not be
done on a much higer level, at some central point so that all tools
run during the build will automatically pick up the matching
libraries from sysroot?
Or is this some problem anywhere else in my own code?
Thanks in advance.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If I had to live my life again, I'd make the same mistakes, only
sooner. -- Tallulah Bankhead
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Perl: fix PERL5LIB settings
The PERL5LIB settings in the perl wrapper script did not include the
site_perl or vendor_perl directories, which caused some errors.
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=6890
Signed-off-by: Wolfgang Denk w...@denx.de
---
meta/recipes-devtools/perl/perl-native_5.14.3.bb | 4 ++--
meta/recipes-devtools/perl/perl_5.14.3.bb| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/perl/perl-native_5.14.3.bb
b/meta/recipes-devtools/perl/perl-native_5.14.3.bb
index c9ec2d2..8ea7ddb 100644
--- a/meta/recipes-devtools/perl/perl-native_5.14.3.bb
+++ b/meta/recipes-devtools/perl/perl-native_5.14.3.bb
@@ -101,8 +101,8 @@ do_install () {
install $i ${D}${libdir}/perl/${PV}/CORE
done
- create_wrapper ${D}${bindir}/perl
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl/${PV}:${STAGING_LIBDIR}/perl/'
- create_wrapper ${D}${bindir}/perl${PV}
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl/${PV}:${STAGING_LIBDIR}/perl/'
+ create_wrapper ${D}${bindir}/perl
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl/${PV}:${STAGING_LIBDIR}/perl:${STAGING_LIBDIR}/perl/site_perl/${PV}:${STAGING_LIBDIR}/perl/vendor_perl/${PV}'
+ create_wrapper ${D}${bindir}/perl${PV}
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl/${PV}:${STAGING_LIBDIR}/perl${STAGING_LIBDIR}/perl:${STAGING_LIBDIR}/perl/site_perl/${PV}:${STAGING_LIBDIR}/perl/vendor_perl/${PV}'
}
SYSROOT_PREPROCESS_FUNCS += perl_sysroot_create_wrapper
diff --git a/meta/recipes-devtools/perl/perl_5.14.3.bb
b/meta/recipes-devtools/perl/perl_5.14.3.bb
index 1e14e17..7ea2c99 100644
--- a/meta/recipes-devtools/perl/perl_5.14.3.bb
+++ b/meta/recipes-devtools/perl/perl_5.14.3.bb
@@ -215,7 +215,7 @@ do_install() {
do_install_append_class-nativesdk () {
create_wrapper ${D}${bindir}/perl \
-
PERL5LIB='$PERL5LIB:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl/${PV}'
+
PERL5LIB='$PERL5LIB:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl/${PV}:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl/site_perl/${PV}:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl/vendor_perl/${PV}'
}
PACKAGE_PREPROCESS_FUNCS += perl_package_preprocess
--
1.8.3.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PERL5LIB not properly reflecting target_sdk_dir
Dear Joseph Andrew de la Peña, In message cajrrhk4q_bnrv2g1kup9btjj9gvmufkmsltmbx8k5hmp7me...@mail.gmail.com you wrote: anyone? I confirm the problem. I have seen a problem in SDK installation where PERL5LIB does not reflect vendor_perl location. I have specified SDK installtion path as /bonus/scratch/sdk. Yet when I executed -V no vendor_perl is included in PERL5LIB. To be more precise, PERL5LIB is not set in the environment, and the installation routine cannot fix the built-in strings in the perl binary. @INC: /bonus/scratch/sdk/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3 /bonus/scratch/sdk/sysroots/i686-pokysdk-linux//usr/lib/perl /bonus/scratch/sdk/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3 /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/site_perl/5.14.3/ /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/site_perl/5.14.3 /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/vendor_perl/5.14.3/ /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/vendor_perl/5.14.3 /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3/ /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3 /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3 As you can see, even though you install into a non-standard directory (/bonus/scratch/sdk), perl still references the built-in path (/opt/sdk/...). The problem is present in all versions of Yocto, up to and including the upcoming 1.7. I've opened a bug for it, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=6890 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You know, after a woman's raised a family and so on, she wants to start living her own life. Whose life she's _been_ living, then? - Terry Pratchett, _Witches Abroad_ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] kernel-yocto.bbclass ignoring SRCREV?
Hi, is my understanding of kernel-yocto.bbclass correct that it effectively completely ignores any specific git commit ID that was gien in SRCREV, but instead always checks out and uses the HEAD of the respective branch? Or am I missing something here? My expectation was that we specify a git commit ID (as the only reliable, truly unique identifier for a specific source code version) in SRCREV, but instead it appears that this information is effectively being ignored? I can understand that there are situations where automatically using the top commit of a branch (say, the latest stable version of some package) may be useful, but should there not be some different way to do that? I mean, how can we make sure to ever be able to reproduce the very same build if the git commit ID specified in SRCREV will not be used for the checkout? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de More software projects have gone awry for lack of calendar time than for all other causes combined. - Fred Brooks, Jr., _The Mythical Man Month_ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Known toolchain bug?
Dear Gary Thomas,
In message 52fe2b80.9030...@mlbassoc.com you wrote:
in message [1] on the Linaro mailing list, Koen Kooi reported a
toolchain problem. I can reproduce the same problem both in Yocto
1.5.1 and witht he current top-of-tree; for example, using the latest
autobuilder result
core-image-sato-sdk-imx53qsb-20140213124023.rootfs.tar.bz2
I get this [source of Koen's test program attached]:
Source code attachment missing?
Sorry. Here it is...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Is the glass half empty, half full, or twice as large as it needs to
#include iostream
#include thread
#include mutex
std::mutex mx;
int i;
void thrfunc();
int main(void)
{
i=0;
std::thread thr1(thrfunc),thr2(thrfunc);
thr1.join();
thr2.join();
return 0;
}
void thrfunc()
{
mx.lock();
i++;
std::cout std::this_thread::get_id() i: i std::endl;
mx.unlock();
}
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] uimage instead of zImage
Dear Edward, In message canwz6nzqq8a1rnql3ety2tj-cktonoobqtievxu6+tohve5...@mail.gmail.com you wrote: A uImage file is a kernel with a modified header for u-boot. A tool called No header gets modified. Instead, a new header gets prepended. mkimage is used to convert a zImage (regular kernel compressed image) to a Actually it's pretty stupid to use a zImage inside an uImage. It is much better to use normal (uncompressed) kernel image, compress it using just gzip, and use this as poayload for mkimage. This way U-Boot does the uncompresiong instead of including yet another uncompressor with each kernel image. uImage file. And No, zImage files, as they are, are not compatible with U-Boot. You must convert them You can boot zImage files directly with U-Boot. That's what the bootz command is for. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Hacking's just another word for nothing left to kludge. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux with Xenomai support
Dear Asier, In message camzj-5md+klf3jvs7mmyq-jfrekpdcoam0nfctrqsfw4bnr...@mail.gmail.com you wrote: Is there any Linux distribution based on the Yocto project that lets me configure my embedded kernel with Xenomai? If not, has anybody got any experinece in adding Xenomai to the Yocto project? ELDK adds full Xenomai support starting with release v5.4 ; please see www.denx.de/wiki/view/ELDK-5 for details, or feel free to ask for more details on the ELDK mailing list, see http://lists.denx.de/mailman/listinfo/eldk I'm using an Atom N270 chipset. ELDK primarily supports ARM, MIPS and Power architectures. We didn't test the Xenomai stuff on x86 yet. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Real programmers don't comment their code. It was hard to write, it should be hard to understand. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Unhandled dependency checking
Hello, I'm looking ofr a good way to deal with some build breakages caused by missing dependency checking. The problem: some packages require certain capabilities, without checking for these, and actually I can;t see a good way how to implement such checking. For example, the lttng package requires module support. But when you modify the defconfig for the Linux kernel and disable module support there, then the build for lttng will break. Is there some good way to handle or at least to test for such hidden dependencies on features provided by other packages, so we could at least issue more useful error messages to the end user? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The rule on staying alive as a program manager is to give 'em a num- ber or give 'em a date, but never give 'em both at once. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Add sbindir_nativesdk to environment setup
When adding for example file system generating tools like
mkfs.cramfs or mkfs.ubifs to the SDK, these will be installed into
the ${prefix_nativesdk}/sbin directory, but the generated
environment-setup script sets a PATH that includes /bin only.
Add a new definition of sbindir_nativesdk and include this into the
PATH setting.
Signed-off-by: Wolfgang Denk w...@denx.de
---
meta/classes/toolchain-scripts.bbclass | 2 +-
meta/conf/bitbake.conf | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 6d8623c..86581cb 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -10,7 +10,7 @@ toolchain_create_sdk_env_script () {
script=${1:-${SDK_OUTPUT}/${SDKPATH}/environment-setup-${REAL_MULTIMACH_TARGET_SYS}}
rm -f $script
touch $script
- echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${REAL_MULTIMACH_TARGET_SYS}:$PATH'
$script
+ echo 'export
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${REAL_MULTIMACH_TARGET_SYS}:${SDKPATHNATIVE}${sbindir_nativesdk}:${SDKPATHNATIVE}${sbindir_nativesdk}/${REAL_MULTIMACH_TARGET_SYS}:$PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=${SDKTARGETSYSROOT}' $script
echo 'export PKG_CONFIG_PATH=${SDKTARGETSYSROOT}${libdir}/pkgconfig'
$script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-${REAL_MULTIMACH_TARGET_SYS}' $script
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 2dc50ca..62cf439 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -59,6 +59,7 @@ bindir_cross = /bin
bindir_crossscripts = ${bindir}/crossscripts
prefix_nativesdk = /usr
bindir_nativesdk = ${prefix_nativesdk}/bin
+sbindir_nativesdk = ${prefix_nativesdk}/sbin
includedir_nativesdk = ${prefix_nativesdk}/include
libdir_nativesdk = ${prefix_nativesdk}/lib
base_libdir_nativesdk = /lib
--
1.7.11.7
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2/M3.rc1 availability
Dear Saul Wold, In message 51007091.1030...@linux.intel.com you wrote: Please continue to test the rc1 of M3. The Meta-Intel bits might come a little later this time due to some issues which are being worked on. I see two issues so far (all with a armv7a based configuration): 1) Building of core-image-lsb-dev and core-image-lsb-sdk fail with errors like this: | * check_data_file_clashes: Package font-alias wants to install file /opt/eldk/build/eldk-rel-v5.4-M3.rc1-2013-01-24-618361c-armv7a/tmp/work/generic_armv7a-linux-gnueabi/core-image-lsb-dev/1.0-r0/rootfs/usr/share/fonts/X11/misc/fonts.alias | But that file is already provided by package * xorg-minimal-fonts | * opkg_install_cmd: Cannot install package mkfontdir-dev. This is a known issue, and the patch provided by [1] fixes the problem for me (however, I don't see it in Yocto yet). [1] http://article.gmane.org/gmane.comp.handhelds.openembedded.core/32245 2) Building of meta-toolchain-sdk fails in nativesdk-e2fsprogs with errors like this: checking for pkg-config... /opt/eldk/build/eldk-rel-v5.4-M3.rc1-2013-01-24-618361c-armv7a/tmp/sysroots/x86_64-linux/usr/bin/pkg-config configure: WARNING: using cross tools not prefixed with host triplet checking pkg-config is at least version 0.9.0... yes checking for uuid_generate in -luuid... no configure: error: external uuid library not found Configure failed. The contents of all config.log files follows to aid debugging configure:3168: i686-eldk-linux-gcc -march=i686 --sysroot=/opt/eldk/build/eldk-rel-v5.4-M3.rc1-2013-01-24-618361c-armv7a/tmp/sysroots/i686-nativesdk-eldk-linux -V 5 i686-eldk-linux-gcc: error: unrecognized command line option '-V' i686-eldk-linux-gcc: fatal error: no input files configure:3168: i686-eldk-linux-gcc -march=i686 --sysroot=/opt/eldk/build/eldk-rel-v5.4-M3.rc1-2013-01-24-618361c-armv7a/tmp/sysroots/i686-nativesdk-eldk-linux -qversion 5 i686-eldk-linux-gcc: error: unrecognized command line option '-qversion' i686-eldk-linux-gcc: fatal error: no input files Are these known issues? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The more we disagree, the more chance there is that at least one of us is right. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Installation of i686 SDK on a x86_64 machine?
Hi, in previous releases it ha always been possible to install a SDK configured for a i686 machine on both x86 and x86_64 systems. Since commit c04f5435 populate_sdk_base.bbclass: use SDK_ARCH instead of SDKMACHINE this does not work any more; instead, installation will abort with Error: Installation machine not supported! ++ uname -m ++ sed -e 's/i[3-6]86/ix86/' -e 's/x86[-_]64/x86_64/' + INST_ARCH=x86_64 ++ echo i686 ++ sed -e 's/i[5-6]86/ix86/' + SDK_ARCH=ix86 + '[' x86_64 '!=' ix86 ']' + echo 'Error: Installation machine not supported!' Error: Installation machine not supported! + exit -1 Is this intended behaviour (and if so, why?) or rather a bug that should be reported and fixed? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If there was anything that depressed him more than his own cynicism, it was that quite often it still wasn't as cynical as real life. - Terry Pratchett, _Guards! Guards!_ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installation of i686 SDK on a x86_64 machine?
Dear Laurentiu, In message 50fe4900.7020...@intel.com you wrote: in previous releases it ha always been possible to install a SDK configured for a i686 machine on both x86 and x86_64 systems. Since commit c04f5435 populate_sdk_base.bbclass: use SDK_ARCH instead of SDKMACHINE this does not work any more; instead, installation will abort with Error: Installation machine not supported! ... Is this intended behaviour (and if so, why?) or rather a bug that should be reported and fixed? This is the intended behavior. Please check: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3269 Sorry, but this bug is about a different problem - the fix overshoots the mark. The following combinations of SDK_ARCH and INST_ARCH are possible and relevant here: Id SDK_ARCHINST_ARCH Status == 1 ix86ix86works 2 ix86x86_64 works 3 x86_64 ix86cannot work 4 x86_64 x86_64 works The bug report is about case 3 - attempting to install a 64 bit SDK on a 32 bit machine. This indeed cannot work and shuld be prevented byy the installer. But the current code also prevents case 2, installing 32 bit images on a 64 bit machine, which works perfectly fine (assuming you have the needed 32 bit libraries installed). For any distribution it is very convenient to provide only one set of images (configured for ix86), as these images will work both on 32 and 64 bit systems. I consider it a major drawback if you intentionally prevent such use. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm not a god, I was misquoted. - Lister, Red Dwarf ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installation of i686 SDK on a x86_64 machine?
Dear Laurentiu, In message 50fe5f87.4060...@intel.com you wrote: Id SDK_ARCHINST_ARCH Status == 1 ix86ix86works 2 ix86x86_64 works 3 x86_64 ix86cannot work 4 x86_64 x86_64 works The bug report is about case 3 - attempting to install a 64 bit SDK on a 32 bit machine. This indeed cannot work and shuld be prevented byy the installer. But the current code also prevents case 2, installing 32 bit images on a 64 bit machine, which works perfectly fine (assuming you have the needed 32 bit libraries installed). I see your point. Would you please file a bug on this? Done, with a patch included. Please see https://bugzilla.yoctoproject.org/show_bug.cgi?id=3770 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, Conscience of the King, stardate unknown ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2, M3, M4 milestones available?
Dear Cornel, In message 33115abc4887814e8a92a08fbc93416b08dc5...@irsmsx103.ger.corp.intel.com you wrote: From a QA point of view, we are approaching the 1.4 M3 milestone. Here is what Saul wrote for the latest Full Pass request: QA Teams: Please do FULL Pass testing on this as a PRE-M3 Full Pass so we have some idea of what's going on. Git Rev: 9eb88ceb39b7d0b8ddc6487e61ce8edadef10ec4 OK, so we have not reached M3 yet. Thanks. Would it not make sense to regularly update the release schedule web page [1] so that it also reports the current state? or is there any other web page where such information is present? [1] https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule 1.4 M2 was kind of blurry because it landed during charismas and new year thus many of us were on vacation. So what exactly is the git commit ID of the 1.4 M2 milestone release? I cannot see any matching tag in the git repository? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you use modules, you pay the price. Sane embedded solutions running in tight environments don't use modules :-) -- Benjamin Herrenschmidt in 1258234866.2140.451.camel@pasglop ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2, M3, M4 milestones available?
Dear Elizabeth, In message CAPhnLPCk8byBnRSEB2aMOBPEmZQRfWpNSJ+xj+uX4BVvHKMf=q...@mail.gmail.com you wrote: 1.4 M2 was kind of blurry because it landed during charismas and new year thus many of us were on vacation. So what exactly is the git commit ID of the 1.4 M2 milestone release? I cannot see any matching tag in the git repository? That is because we have merged M2 and M3. See: http://article.gmane.org/gmane.linux.embedded.yocto.general/11075/match=merging+m2 I see - thanks for the information. All this is pretty much frustrating. I mean, you cannot really expect people who are looking for release information to scan the mailing list archives for such bits of scattered information? Especially since what appears to the the Yocto Project's official web site claims that there _has_ been a M2-RC1, M2-RC2 and M2, see [1]: M2 Stabilize schedule Release Candidate and Milestone Release schedule (Full Pass QA test follows every RC build) RC1: 12/26/12 RC2: 1/2/13 M2 release: 1/11/13 [1] https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule#M2_Stabilize_schedule It would so nice if we had somewhere, publicly visible at a well known location (like the above page), some correct and useful information. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you are afraid of loneliness, don't marry. - Chekhov ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2, M3, M4 milestones available?
Dear John, In message cagoht_fp04irbj2pqnjszjjiow5qzjyqctz0rxudg_gjvha...@mail.gmail.com you wrote: The M2 and M3 milestones were merged. Please see Liu Song's email on Dec 27, in part: Yocto Project CCB has approved our request to merge M2 and M3 together. So there won't be a M2 release and we will be working toward a M3 release for M2 and M3 features by Feb. 7th, 2013 Thanks, understood now. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You don't have to worry about me. I might have been born yesterday... but I stayed up all night. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ANOUNCEMENT] bmaptool
Dear Artem, In message 1358167593.2731.66.ca...@sauron.fi.intel.com you wrote: Please, read all the details in the project wiki page: https://source.tizen.org/documentation/reference/bmaptool The project was created for Tizen IVI, but it is generic and is not bounded to Tizen in any way. I do not want to duplicate the bmap-tools documentation here, but instead, let me just describe how we use it in Tizen IVI. Thanks for doing this, as the links on the page referenced above are broken: both [1] Introduction and [2] Usage give just a 404 to me... [1] https://source.tizen.org/documentation/reference/bmap-tool/bmap-introduction [2] https://source.tizen.org/documentation/reference/bmap-tool/usage Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If the odds are a million to one against something occuring, chances are 50-50 it will. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Git tag systematics ?
Dear Elizabeth, In message caphnlpbxsycndeksw6xbljsrjunhudtkrohr_ahtu9pysqm...@mail.gmail.com you wrote: However, there is no such release tag as danny-8.0. You are correct. That was an oversight on my part. I've corrected it. Thanks. Is there some formal procedure in place how git release tags are assigned, and when? What is the system in this numbering / tagging? Milestones: 1.x_My.rcz Major releases: 1.x and they should also get the name-x.y.z tag Thanks again - but is there any documetn somehere on the web pages or in the wiki that actually says what the name of the next release will be, and which branch it is being worked on? Releated: is there any document which explains the branch names being used for development. for example, how can I find out (officially) what the branch name for Yocto 1.4 will be / is ? When Richard tells me :) We have a 1.4_M1.final tag in the 1.4_M1 branch, and I see similar 1.x_My branches for the other releases. When will some name-... branch become visible? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, The City on the Edge of Forever, stardate unknown ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Git tag systematics ?
In message 20121215132238.503dc201...@gemini.denx.de I wrote: Hi, can anybody explain to me the systematics of the git tags ysed to mark the Yocto / Poky releases? For example, for Yocto 1.2 and before, we have release tags like denzil-7.0, edison-6.0, bernard-5.0, laverne-4.0, etc. Some parts of the current 1.3 Yocto release refer to it as Poky 8.0 or Version 8.0 Danny, see for example here: https://www.yoctoproject.org/download/yocto-project-13-poky-80 However, there is no such release tag as danny-8.0. Instead, there is a tag 1.3 - but there are no similar tags as 1.1 or 1.2 for the earlier releases? What is the system in this numbering / tagging? Releated: is there any document which explains the branch names being used for development. for example, how can I find out (officially) what the branch name for Yocto 1.4 will be / is ? No comments anybody?Thanks in advance! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Q: Why do PCs have a reset button on the front? A: Because they are expected to run Microsoft operating systems. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Git tag systematics ?
Hi, can anybody explain to me the systematics of the git tags ysed to mark the Yocto / Poky releases? For example, for Yocto 1.2 and before, we have release tags like denzil-7.0, edison-6.0, bernard-5.0, laverne-4.0, etc. Some parts of the current 1.3 Yocto release refer to it as Poky 8.0 or Version 8.0 Danny, see for example here: https://www.yoctoproject.org/download/yocto-project-13-poky-80 However, there is no such release tag as danny-8.0. Instead, there is a tag 1.3 - but there are no similar tags as 1.1 or 1.2 for the earlier releases? What is the system in this numbering / tagging? Releated: is there any document which explains the branch names being used for development. for example, how can I find out (officially) what the branch name for Yocto 1.4 will be / is ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A committee is a group that keeps the minutes and loses hours. -- Milton Berle ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot for use with GDB
Hello, nobody here who could help out? In message 20121203124234.6327b200...@gemini.denx.de I wrote: according to the documentation [1] the right way to debug applications on the target is to load the target library information in GDB using set solib-absolute-prefix /path/to/tmp/rootfs i. e. referring it to the libraries in the target root file system image. Assuming the target root file system uses by defualt stripped libraries, we need to set up a copy of the rootfs with debug information included. But do we really have to? Why cannot we use the libraries present in the SDK's sysroot directory (i. e. what OECORE_TARGET_SYSROOT points to) ? It appears that documentation and code are inconsistent; at least the eclipse plugin generates a .gdbinit script which contains a set sysroot /opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi statement, i. e. it uses OECORE_TARGET_SYSROOT as I thought should work - but it doesn't. Trying to do so, we see that it fails. Our current suspicion is that maybe prelinking of the target images and libraries introduces some incompatibility. Is this a reasonable assumption, and if so, is this a problem that should be fixed, or unavoidable for some reason? Or is there a problem with the libraries in OECORE_TARGET_SYSROOT ? All help welcome - thanks in advance. [1] http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-gdb-remotedebug-launch-gdb OK, guess I should enter a bug in bugzilla, then? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Humanity has the stars in its future, and that future is too important to be lost under the burden of juvenile folly and ignorant superstition. - Isaac Asimov ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot for use with GDB
Hello, In message 20121205123818.c17eb200...@gemini.denx.de I wrote: OK, guess I should enter a bug in bugzilla, then? Done that; please see Bug 3540 - remote target debugging broken https://bugzilla.yoctoproject.org/show_bug.cgi?id=3540 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can type faster than I can move a mouse, so I find menu-driven drawing packages time consuming and frustrating. - W. R. Stevens ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sysroot for use with GDB
Hello, according to the documentation [1] the right way to debug applications on the target is to load the target library information in GDB using set solib-absolute-prefix /path/to/tmp/rootfs i. e. referring it to the libraries in the target root file system image. Assuming the target root file system uses by defualt stripped libraries, we need to set up a copy of the rootfs with debug information included. But do we really have to? Why cannot we use the libraries present in the SDK's sysroot directory (i. e. what OECORE_TARGET_SYSROOT points to) ? Trying to do so, we see that it fails. Our current suspicion is that maybe prelinking of the target images and libraries introduces some incompatibility. Is this a reasonable assumption, and if so, is this a problem that should be fixed, or unavoidable for some reason? Or is there a problem with the libraries in OECORE_TARGET_SYSROOT ? All help welcome - thanks in advance. [1] http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-gdb-remotedebug-launch-gdb Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inconsistent pages out there for setting up your yocto dev host
Dear Paul, In message 3038126.PEqOPPdATB@helios you wrote: if you're on an allegedly supported distro, and you do an upgrade, it's entirely possible that one of those bits of software gets upgraded in a way that breaks OE/yocto, and by using ASSUME_PROVIDED, you'll automatically start using that newer utility. or is the list of supported distros specifically only those installed out of the box and never updated? if that's the case, then, yes, i agree with your position. That's why we test specific versions of distributions, and with the Poky distro config we warn the user if the distro/distro version is untested. It's rare that you get that kind of breakage between major versions; if there were then other applications are likely to be affected so it would be considered a regression in that distro. But of course there have always been, and will always be, such regressions. Just look at Fedora 17 (one of the supported versions of distributions), if one of the updates pulls in git version 1.7.11.7 and suddenly all git downloads using HTTP protocol will fail for you (due to bug 865692, see https://bugzilla.redhat.com/show_bug.cgi?id=865692) Actually it may make a lot of sense for certain configurations to bootstrap more tools from a known version of the sources. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Beware of the Turing Tar-pit in which everything is possible but nothing of interest is easy. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Alternative SDK installation directory working?
/usr/bin/armv5te-poky-linux-gnueabi/../../libexec/armv5te-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find crtend.o: No such file or directory /opt/poky-test/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/../../libexec/armv5te-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find crtn.o: No such file or directory collect2: error: ld returned 1 exit status What am I missing here? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Doubt isn't the opposite of faith; it is an element of faith. - Paul Tillich, German theologian and historian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Alternative SDK installation directory working?
Dear Jack Mitchell,
In message 50aa2ee4.1000...@communistcode.co.uk you wrote:
- source /opt/poky-test/environment-setup-armv5te-poky-linux-gnueabi
- ${TARGET_PREFIX}gcc -v -o /tmp/x /tmp/x.c
I think you need a --sysroot in there. e.g.
--sysroot=/opt/poky-test/sysroots/arch-blah-blah-blah
I see. Thanks for pointing out.
However, this still leaves a number of somewhat suspicious messages:
- $CC -v -o /tmp/x /tmp/x.c
...
ignoring nonexistent directory
/opt/poky-test/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/../../lib/armv5te-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/../../../../../arm-poky-linux-gnueabi/include
ignoring duplicate directory
/opt/poky-test/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/../../lib/armv5te-poky-linux-gnueabi/gcc/../../../lib/armv5te-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/include
ignoring nonexistent directory
/opt/poky-test/sysroots/armv5te-poky-linux-gnueabi/usr/local/include
ignoring duplicate directory
/opt/poky-test/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/../../lib/armv5te-poky-linux-gnueabi/gcc/../../../lib/armv5te-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/include-fixed
ignoring nonexistent directory
/opt/poky-test/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/../../lib/armv5te-poky-linux-gnueabi/gcc/../../../lib/armv5te-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/../../../../../arm-poky-linux-gnueabi/include
#include ... search starts here:
...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
This cultural mystique surrounding the biological function -- you
realize humans are overly preoccupied with the subject.
-- Kelinda the Kelvan, By Any Other Name, stardate 4658.9
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Alternative SDK installation directory working?
Dear Laurentiu,
In message 50aa31d8.5020...@intel.com you wrote:
- source /opt/poky-test/environment-setup-armv5te-poky-linux-gnueabi
- ${TARGET_PREFIX}gcc -v -o /tmp/x /tmp/x.c
Just do: $CC -o /tmp/x /tmp/x.c
It should work.
echo $CC
arm-poky-linux-gnueabi-gcc -march=armv5te -marm -mthumb-interwork
-mtune=arm926ej-s --sysroot=/tests/sdk/sysroots/armv5te-poky-linux-gnueabi
Argh... Isn't it somewhat ... unconventional (to avoid stonger words)
to encode compiler options in a variable which is supposed to define
the Program for compiling C programs ?
Should such options not go to one of the *FLAGS variables instead?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Bankers do it with interest (penalty for early withdrawal).
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] denx.de site down?
Dear Elvis, In message 8fdc41dc-70b4-4bcb-9b95-51cfbca89...@gmail.com you wrote: I noticed that your site has been down since yesterday? I usually sync with your u-boot and eldk repositories, and during the yocto build process, it failed because your site was un-reachable. I was able to get past the yocto build issue, by temporarily modifying my u-boot repositories to point to the local file system. I'm sure others are also facing a similar issue. I apologize for the inconveniencies. We had a hardware problem on our main server (actually nothing serious, just a dead disk drive), but our hoster handles this not exactly in a competent way - instead of just hot-swapping the failed drive so we just have to re-sync the degraded RAID array he decided to replace _all_ disks so we are forced to reinstall from scratch and restore from backups. This process is still in the works. Sorry for that. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You don't need a weatherman to know which way the wind blows. - Bob Dylan ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M5.rc2 status.
Dear Flanagan, Elizabeth, In message CAPhnLPCYC9_xvdinu9=prhuoz8ffquyk5tvrbkihlz4fyk2...@mail.gmail.com you wrote: 1.3_M5.rc2 was started a bit late today due to some miscommunication. The build has begun and judging from recent autobuilder performance, I'm expecting it to complete in about six and a half hours from now. For those doing QA against 1.3_M5.rc2, if you can, please begin testing what you can as soon as build artifacts become available. Download: http://autobuilder.yoctoproject.org/pub/nightly/20120926-1 poky: 718eb85806e080d0b165344b272e531ef19421eb This commit has: meta-yocto/conf/distro/poky.conf:LAYER_CONF_VERSION ?= 6 But: meta/conf/sanity.conf:LAYER_CONF_VERSION ?= 5 So for me the sanity checker bails out with: ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Your version of bblayers.conf was generated from an older version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing. Matching the version numbers will remove this message. meld conf/bblayers.conf /home/wd/git/eldk-5.3/meta*/conf/bblayers.conf.sample is a good way to visualise the changes. ERROR: Execution of event handler 'check_sanity_eventhandler' failed Am I doing anyhting wrong? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Insufficient facts always invite danger. -- Spock, Space Seed, stardate 3141.9 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M5.rc2 status.
Dear Paul Eggleton, In message 10067256.0vCsjtRvv5@helios you wrote: Am I doing anyhting wrong? No, this is expected, at the moment you need to follow the instructions and make the appropriate changes to your conf/bblayers.conf. However, there is a patch out for review that we would like to include for the 1.3 final release which will take care of this automatically for you. Thanks. Please excuse my ignorance: where would I find the respective instructions? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Misquotation is, in fact, the pride and privilege of the learned. A widely-read man never quotes accurately, for the rather obvious reason that he has read too widely. - Hesketh Pearson _Common Misquotations_ introduction ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M5.rc2 status.
Dear Paul, In message 1767865.bvfduhkKG5@helios you wrote: On Wednesday 26 September 2012 15:06:53 Wolfgang Denk wrote: this is expected, at the moment you need to follow the instructions and make the appropriate changes to your conf/bblayers.conf. However, there is a patch out for review that we would like to include for the 1.3 final release which will take care of this automatically for you. Thanks. Please excuse my ignorance: where would I find the respective instructions? It does have some very brief instructions in the error message: Please compare the two files and merge any changes before continuing. Matching the version numbers will remove this message. meld conf/bblayers.conf /home/wd/git/eldk-5.3/meta*/conf/bblayers.conf.sample is a good way to visualise the changes. I appreciate this is not as helpful as it could be, hence why we are working to do this automatically for the user. Ah, OK. Well, I decided to update meta/conf/sanity.conf to have a matching value of LAYER_CONF_VERSION, so this is solved. Sorry, I misinterpreted your note and expected any additional instructions for building 1.3_M5 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the pitiful, multipage, connection-boxed form to which the flow- chart has today been elaborated, it has proved to be useless as a design tool -- programmers draw flowcharts after, not before, writing the programs they describe.- Fred Brooks, Jr. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M5.rc2 status.
Dear Paul Eggleton, In message 2428256.OTjtN2nWn5@helios you wrote: Ah, OK. Well, I decided to update meta/conf/sanity.conf to have a matching value of LAYER_CONF_VERSION, so this is solved. That will work, but normally you would edit conf/bblayers.conf, since meta/conf/sanity.conf is part of the metadata. Well, what is the rationale for setting LAYER_CONF_VERSION=6 in meta-yocto/conf/distro/poky.conf, then? If meta layer specific values of LAYER_CONF_VERSION are allowed, the sanity checker needs a better way to deal with these; alternatively, above setting in meta-yocto/conf/distro/poky.conf is wrong. So either of these should be fixed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Build a system that even a fool can use and only a fool will want to use it. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M5.rc2 status.
Dear Paul, In message 224780988.1nyHnvScgz@helios you wrote: If meta layer specific values of LAYER_CONF_VERSION are allowed, the sanity checker needs a better way to deal with these; alternatively, above setting in meta-yocto/conf/distro/poky.conf is wrong. So either of these should be fixed. By better way to deal with these, what would you suggest? I don't see any alternative that avoids the BSP components just disappearing for users who have existing configurations. Well, the comment in meta-yocto/conf/bblayers.conf.sample says: # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly This suggests that such changes are not exactly unusual. But any such change will cause the build to fail, because the sanity checker uses a different value. If such a change is allowed and is done intentionally, then it should be considered sane, and the sanity checker should not complain. The problem (and the longer I think about it the less I hesitate to call it a plain bug) is that we allow for meta layer specific values of LAYER_CONF_VERSION, while still assuming a single hard-coded value in meta/conf/sanity.conf could be used as reference. This _cannot_ work. But when I'm supposed to overwrite the setting (to match the sanity checker's expectations) in my local conf/bblayers.conf, then why do we bother to set a dieferent value in the meta layer in the first place? And hey, why do we check this value at all if all we can do is always make it match manually? I understand the intention, but the current implementation is just broken, and I don't see a way to fix it. It would probably be better to remove this test than to leave it as is. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If a packet hits a pocket on a socket on a port, And the bus is interrupted as a very last resort, And the address of the memory makes your floppy disk abort, Then the socket packet pocket has an error to report! - Ken Burchill? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M5.rc2 status.
Dear Chris, In message cabczanmpe_d+gpwxnkvzcme9ti011zdsxxpix8ztw4vrdyi...@mail.gmail.com you wrote: Well, the comment in meta-yocto/conf/bblayers.conf.sample says: # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly This suggests that such changes are not exactly unusual. But any such change will cause the build to fail, because the sanity checker uses a different value. This is wrong. A compatibility break in bblayers.conf is *extremely* rare. If such a change is allowed and is done intentionally, then it should be considered sane, and the sanity checker should not complain. Wrong. The user has to know that they may need to change their bblayers.conf to match the upstream structure. If it didn't complain, they could silently break or encounter unexpected behavior. Sorry, but I don't get how this is supposed to work. I have an incompatible change, and increase LAYER_CONF_VERSION in my meta layer's bblayers.conf.sample . When sourcing oe-init-build-env, this file gets copied to the build dir as conf/bblayers.conf. Building with this setting fails, because the samity checker does not accept the value. So I have to actually undo the change I made in bblayers.conf.sample to make it build. My internal sanity checker barfs on such logic... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Tell the truth and run. - Yugoslav proverb ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Qt embedded
Dear Giovanni, In message cansupap8k__yazngrw88ogh8pk2xfnqfgkj_378oc+8cmfq...@mail.gmail.com you wrote: I solved adding in my setup-environment script all enviroment variable related to Qt (I used paths generated by meta-toolchain-qte). I still can't configure the environment to run using qt creator... Did you read this: http://www.denx.de/wiki/view/ELDK-5/FrequentlyAskedQuestionsAndAnswers#How_can_I_use_the_QtEmbedded_tar Does it help? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If the facts don't fit the theory, change the facts. -- Albert Einstein ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Qt embedded
Dear Giovanni, In message cansupap4h2ouz_4mckq8jmfm_grv_ccgcmfxzqagms7ty8b...@mail.gmail.com you wrote: This is my first post on this mailing list and I'm quite new to Yocto. I successfully built a distro using the latest release of hob, including Qt embedded (without X11). I wrote a Qt application and cross compiled for ARM on my host machine but when I deploy it on the device (a Freescale iMX53) I get and error because the application looks for libraries like libQtGui but on the distro all Qt libraries are named like libQtGuiE (ending with E which I suppose it stands for Embedded). These names are OK for the Qt Embedded libraries, and they should match what your cross development tools are using. Which tool chain did you use for compiling and linking your application - the one from meta-toolchain-qte ? When I build meta-toolchain-qte, this also includes, for example, .../sysroots/armv6-vfp-linux-gnueabi/usr/lib/libQtGuiE.so.4.8.2 so cross tool chain and native systems work together without problems. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's hard to make a program foolproof because fools are so ingenious. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ANNOUNCEMENT] Cedar Trail with PowerVR for Edison 6.0.1
Dear Elizabeth, In message caphnlpbb-qcmq-mhwbxoiu9qxchawjkvtgvavsr1goyh_8t...@mail.gmail.com you wrote: This release enables the BSP to use the latest available kernel patches for Intel's PowerVR graphics driver. The BSP image includes time limited kernel images for testing purposes. This is probaby a stupid question, so I apologize in advance: What is a time limited kernel image? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You have the capacity to learn from mistakes. You'll learn a lot today. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] LICENSE = GPL -- problem?
Hi, we noticed warnings like No generic license file exists for: GPL in any provider for our own linux kernel recipe. The cause wa the use of an entry LICENSE = GPL which whould read GPLv2 instead of GPL. A scan detected that the same string GPL is used in a number of other recipes: bitbake/lib/bb/shell.py:LICENSE = GPL meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:LICENSE = GPL meta/recipes-kernel/linux/linux-dummy.bb:LICENSE = GPL meta/recipes-bsp/x-load/x-load.inc:LICENSE = GPL meta/recipes-devtools/gcc/gcc-common.inc:LICENSE = GPL meta/recipes-devtools/unifdef/unifdef-native_2.6.18+git.bb:LICENSE = GPL Eventually these should be fixed, too? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Human beings were created by water to transport it uphill. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LICENSE = GPL -- problem?
Dear Elizabeth, In message CAPhnLPDzcwr+0uMFk274KKtfbGD48-z5yQDqD=jozlo0ja9...@mail.gmail.com you wrote: which whould read GPLv2 instead of GPL. A scan detected that the same string GPL is used in a number of other recipes: bitbake/lib/bb/shell.py:LICENSE = GPL meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:LICENSE = GPL meta/recipes-kernel/linux/linux-dummy.bb:LICENSE = GPL meta/recipes-bsp/x-load/x-load.inc:LICENSE = GPL meta/recipes-devtools/gcc/gcc-common.inc:LICENSE = GPL meta/recipes-devtools/unifdef/unifdef-native_2.6.18+git.bb:LICENSE = G PL Eventually these should be fixed, too? Yes, GPL is somewhat meaningless so these should be audited to determine the correct GPL version and corrected. Should I create an entry in the bug database? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Computers are not intelligent. They only think they are. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a Qt4-x11 app.
Dear Daniel, In message cadvyk4sbwkanu4rl6k2_+1aedbfnfptohkffjgdak6c2bs-...@mail.gmail.com you wrote: I wish to run an application developed with QT in a Yocto filesystem. The app should be linked against Qt4-X11 libs. What is the exact work flow to get my app cross compiled on my x86_64 host ? So far I have : - Build a complete core-image-sato with IPKG as a packaging system. - Build qt4-x11-free - Build qt4-tools-nativesdk Now, I got something called qmake2 in the build directory (sysroot-x86_64) , but it complains about not finding the right qmake specs. I got the feeling I am doing something fundamentally wrong with my setup, can anyone enlighten me ? Try building meta-toolchain-qte for the cross development tools, and core-image-qte-sdk for a reasonably complete root file system that can also be used for native development when needed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Include the success of others in your dreams for your own success. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.2 release candidate 4 now available.
Dear Elizabeth, In message CAPhnLPCs-57NxB5-O=ysiqbpzqk0xhigeefdehwrgb2_qtg...@mail.gmail.com you wrote: Release candidate 4 for 1.2 is now available for testing: Thanks. Sorry, here is a new Bug 2347 - libtool library files broken Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Overdrawn? But I still have checks left! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build time data
Dear Darren Hart, In message 4f87c2d3.8020...@linux.intel.com you wrote: Phenom II X4 965, 4GB RAM, RAID0 (3 SATA2 disks) for WORKDIR, RAID5 (the same 3 SATA2 disks) BUILDDIR (raid as mdraid), now I have Bulldozer AMD FX(tm)-8120, 16GB RAM, still the same RAID0 but different motherboard.. Why RAID5 for BUILDDIR? The write overhead of RAID5 is very high. The savings RAID5 alots you is more significant with more disks, but with 3 disks it's only 1 disk better than RAID10, with a lot more overhead. Indeed, RAID5 with just 3 devices makes little sense - especially when running on the same drives as the RAID0 workdir. I spent some time outlining all this a while back: http://www.dvhart.com/2011/03/qnap_ts419p_configuration_raid_levels_and_throughput/ Well, such data from a 4 spindle array are nor teling much. When you are asking for I/O performance on RAID arrays, you want to distibute load over _many_ spindles. Do your comparisons on a 8 or 16 (or more) spindle setup, and the results will be much different. Also, your test of copying huge files is just one usage mode: strictly sequential access. But what we see with OE / Yocto builds is completely different. Here you will see a huge number of small and even tiny data transfers. Classical recommendations for performance optimization od RAID arrays (which are usually tuning for such big, sequentuial accesses only) like using big stripe sizes and huge read-ahead etc. turn out to be counter-productive here. But it makes no sense to have for example a stripe size of 256 kB or more when 95% or more of your disk accesses write less than 4 kB only. Here's the relevant bit: RAID 5 distributes parity across all the drives in the array, this parity calculation is both compute intensive and IO intensive. Every write requires the parity calculation, and data must be written to every drive. But did you look at a real system? I never found the CPU load of the parity calculations to be a bottleneck. I rather have the CPU spend cycles on computing parity, instead of running it with all cores idle because it's waitong for I/O to complete. I found that for the work loads we have (software builds like Yocto etc.) a multi-spindle software RAID array outperforms all other solutions (and especially the h/w RAID controllers I had access to so far - these don't even closely reach the same number of IOPS). OH - and BTW: if you care about reliability, then don't use RAID5. Go for RAID6. Yes, it's more expensive, but it's also much less painful when you have to rebuild the array in case of a disk failure. I've seen too many cases where a second disk would fail during the rebuild to ever go with RAID5 for big systems again - restoring several TB of data from tape ain't no fun. See also the RAID wiki for specific performance optizations on such RAID arrays. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never put off until tomorrow what you can put off indefinitely. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] why is YOCTO_GIT_URL defined to use http?
Dear Robert, In message alpine.DEB.2.02.1203180937590.7439@oneiric you wrote: $ git clone http://git.yoctoproject.org/poky.git git Cloning into git... fatal: http://git.yoctoproject.org/poky.git/info/refs not found: did you run git update-server-info on the server? This is indeed an issue that should be fixed on the server. now that i'm awake, i can expand on the above. it seems that you simply can't use a single entity for this since you can use it in two different contexts: 1) for browsing (http://) 2) for cloning (git://) isn't the obvious solution to define two different entities, to be used depending on the context? Umm... I think you get this wrong. You should be able to access the repository thrugh git both with git clone http://git.yoctoproject.org/poky.git and git clone git://git.yoctoproject.org/poky.git For access though a web browser, the URL would be http://git.yoctoproject.org/cgit/cgit.cgi/poky which is indeed a separate thing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.2_M2-Final build failures
Dear Paul, In message 1619950.WDgEWRegMs@helios you wrote: I see the very same error as described as 3. above, but I don't use sub-layers. I'm not sure what you mean here. Which entries for meta-intel do you have in your bblayers.conf? None. I have this: - cat conf/bblayers.conf # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly LCONF_VERSION = 4 BBFILES ?= BBLAYERS ?= \ /home/wd/git/poky/eldk-5.2/meta \ /home/wd/git/poky/eldk-5.2/meta-yocto \ /home/wd/git/poky/eldk-5.2/meta-eldk \ This was working fine before, and we don't have any sub-layers in meta-eldk. So far I have no idea where to look ... Thanks! Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] clutter-1.6: make build for armv4t
Dear Matthew, In message caesovnc9jv5ro3yilgl19q-veyq-h-e5sy-huvfyxu3pmav...@mail.gmail.com you wrote: On Thu, Dec 22, 2011 at 3:21 AM, Wolfgang Denk w...@denx.de wrote: GCC will define __ARM_ARCH_4T__ when building with -march=3Darmv4t so we can check this to turn off the use of 'clz' instructions, which otherwise would cause compile errors like selected processor does not support ARM mode `clz r3,r0'. ... This version was dropped recently... Is this possibly for the 1.1.1 edison release? If so, I would CC: Joshua Lock. yes, this patch was for the edison series (mainline has updated to clutter-1.8 in the meantime). Sorry for not being clear. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 'Tis true, 'tis pity, and pity 'tis 'tis true. - Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Related to mounting USB
Dear Navani Kamal Srivastava, In message 9bacabf0c6b14a4d8c33b42a795119be096d7...@pocitmsexmb03.lntuniverse.com you wrote: I am facing problem in mounting USB. At the time of system bootup if USB stick is plugged, it shows messages like ... But I won't get any sda or sda1 in /dev to mount. If I am unplugging the USB stick and again plug it I would be able to look for it in /dev and mount it. Please look after this issue. This is a known problem. Some even call it a feature ;-) Yocto tries to speedup the boot process by caching the /dev contents: it creates an archive /etc/dev.tar on the first boot and, if this archive exists during the next boot, it gets extracted and most of the coldplug events are filtered. Only if the archive doesn't exist a full scan is performed. This seems to be a good solution for a root file system used inside a typical embedded device (as scanning for cold plug events is known to be slow) but this clearly doesn't work in your setup where the booted configuration changes. As a workaround you just need to remove the /etc/dev.tar file from the root file system. As a real fix you might want to disable this functionality for your configuration. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only time the world beats a path to your door is when you are in the bathroom. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Weekly Test Report for Yocto 1.2 M1 RC2 Build
Dear Jiajun Hu, In message d5ab6e638e5a3e4b8f4406b113a5a19a12ed44b...@shsmsx501.ccr.corp.intel.com you wrote: This is the weekly test report for Yocto 1.2 M1 RC2 build. There are 2 new bugs found for this build. HuronRiver board is broken, so Thi is not complete. I reported another bug (build failure) yesterday. Issue summary -- ... Bug Number ... Bug 310 - [eMenlow] i2c_transfer error on e-Menlow Bug 1779 - gsettings-data-convert segfault on sdk image Bug 1823 - [Bealgeboard C4] keyboard could not work with 20111207 build Bug 1825: Application 'Dates' can not be launched with 20111207 build New! Bug 1840 - glxgears fail to run on Blacksand Bug 1826: [HuronRiver] only 3/4 screen is used when psplash loading New! Bug 1842 - [Hob2] there should be a warning when meta-intel layer not added for BSP build Please add: Bug 1841 - 1.2_M1 build broken for meta-toolchain-sdk Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't have a battle of wits with an unarmed opponent. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] where does that 50G disk space figure come from in QS guide?
Dear Robert, In message alpine.DEB.2.02.1110301735310.4586@localhost6.localdomain6 you wrote: QS guide suggests build process using sato will use about 50G of disk space. where does that figure come from? i just did a configure and build of core-image-sato for beagleboard on my 64-bit ubuntu 11.10 system and it cost me about 3.5G for the tarball download directory, and just under 28G for the entire build directory. so where does 50G come from? and that was *without* economizing using INHERIT += rm_work. After building core-image-sato-sdk, core-image-qte-sdk, meta-toolchain-sdk, and meta-toolchain-qte I see 70G used... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The software required `Windows 95 or better', so I installed Linux. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky release is 5.0 Bernard confusion
Dear Elizabeth Flanagan, In message 4dac90d3.3050...@intel.com you wrote: Yes, there was a problem with what I assumed would be our bernard-5.0 release and the tag needed to be moved, which, while a messy practice, was the only available option at the time. The tag shouldn't have been created until after verification of the RC. I'll make sure that this is captured in our release process. If you want, please feel free to open up a bug in bugzilla and assign it to me. As this was a relatively new process, I knew we'd hit some snags. This was one of them, and I'll make sure this is captured in our process so that we don't hit it again. I know that such things happen, but then it would have been at least a good idea to post some information about this - as mentioned, nobody expects that git tags get moved. Do you also plan to GPG-sign the tags? Note that annotated tags would also help a lot for example with commands like git describe. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Der Dativ ist dem Genitiv sein Tod. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky release is 5.0 Bernard confusion
Dear Scott Garman, In message 4da127f6.3010...@intel.com you wrote: This suggests to me that your local git repository isn't up to date. The tag has been moved at least once since it was created, and it sounds like your repository is behind the most recent move of the tag. You are ... moving release tags? Grrrgh!!! Could you please stop doing this? Nobody ever expects such a thing. And while we are at it: It would also be great if you could GPG-sign the tags. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de He only drinks when he gets depressed. Why does he get depressed? Sometimes it's because he hasn't had a drink. - Terry Pratchett, _Men at Arms_ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] [Announcement] Laverne 4.0.1 Release
Dear Elizabeth, In message 4d503519.8010...@intel.com you wrote: It is indeed 4.0.1, the commits for 7fa2b1c and d1fd60f were incorrect (there was some confusion on my part as to the numbering scheme). These issues were corrected @ 45526f5. Sorry for any confusion. Understood - thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Winners never talk about glorious victories. That's because they're the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories. - Terry Pratchett, _Small Gods_ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
