[yocto] Bitbake error for elfutils-native
bitbake for imx6qsabreauto command used bitbake -v tizen-common-core-image-minimal-dev I have applied fix to - meta/classes/patch.bbclass i.e + del os.environ['TMPDIR'] ***Error Log ERROR: Command Error: exit status: 1 Output: Applying patch redhat-portability.diff patching file backends/ChangeLog patching file backends/Makefile.am patching file backends/Makefile.in patching file ChangeLog patching file config/ChangeLog patching file config/eu.am patching file config/Makefile.in Hunk #1 succeeded at 147 (offset 1 line). Hunk #2 succeeded at 179 (offset 1 line). patching file config.h.in patching file configure Hunk #1 FAILED at 661. Hunk #2 FAILED at 678. Hunk #3 FAILED at 802. Hunk #4 FAILED at 1461. Hunk #5 succeeded at 4943 with fuzz 1 (offset 234 lines). Hunk #6 FAILED at 4869. Hunk #7 succeeded at 5535 (offset 256 lines). Hunk #8 FAILED at 6015. Hunk #9 succeeded at 7010 with fuzz 1 (offset 257 lines). 6 out of 9 hunks FAILED -- rejects in file configure patching file configure.ac patching file lib/ChangeLog patching file lib/eu-config.h patching file lib/Makefile.in patching file libasm/ChangeLog patching file libasm/Makefile.in patching file libcpu/ChangeLog patching file libcpu/i386_disasm.c patching file libcpu/Makefile.in patching file libdw/ChangeLog patching file libdw/dwarf_begin_elf.c patching file libdw/libdw.h patching file libdw/Makefile.in patching file libdwfl/ChangeLog patching file libdwfl/linux-core-attach.c patching file libdwfl/linux-pid-attach.c patching file libdwfl/Makefile.in patching file libebl/ChangeLog patching file libebl/Makefile.in patching file libelf/ChangeLog patching file libelf/common.h patching file libelf/gnuhash_xlate.h patching file libelf/Makefile.in patching file m4/Makefile.in patching file Makefile.in patching file src/addr2line.c patching file src/ChangeLog patching file src/findtextrel.c patching file src/ld.h patching file src/Makefile.am patching file src/Makefile.in patching file src/readelf.c patching file src/strings.c patching file src/strip.c patching file tests/backtrace.c patching file tests/ChangeLog patching file tests/line2addr.c patching file tests/Makefile.in Patch redhat-portability.diff does not apply (enforce with -f) ERROR: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /home/sfm/yocto_temp/build/tmp/work/i686-linux/elfutils-native/0.158- r0/temp/log.do_patch.3531 ERROR: Task 993 (virtual:native:/home/sfm/yocto_temp/poky/meta/recipes- devtools/elfutils/elfutils_0.158.bb, do_patch) failed with exit code '1' do patch log file /home/sfm/yocto_temp/poky/meta/recipes-devtools/elfutils/elfutils/ /home/sfm/yocto_temp/poky/meta/recipes-devtools/elfutils/files/ NOTE: Applying patch 'redhat-portability.diff' (../poky/meta/recipes- devtools/elfutils/elfutils-0.158/redhat-portability.diff) ERROR: Command Error: exit status: 1 Output: Applying patch redhat-portability.diff patching file backends/ChangeLog patching file backends/Makefile.am patching file backends/Makefile.in patching file ChangeLog patching file config/ChangeLog patching file config/eu.am patching file config/Makefile.in Hunk #1 succeeded at 147 (offset 1 line). Hunk #2 succeeded at 179 (offset 1 line). patching file config.h.in patching file configure Hunk #1 FAILED at 661. Hunk #2 FAILED at 678. Hunk #3 FAILED at 802. Hunk #4 FAILED at 1461. Hunk #5 succeeded at 4943 with fuzz 1 (offset 234 lines). Hunk #6 FAILED at 4869. Hunk #7 succeeded at 5535 (offset 256 lines). Hunk #8 FAILED at 6015. Hunk #9 succeeded at 7010 with fuzz 1 (offset 257 lines). 6 out of 9 hunks FAILED -- rejects in file configure patching file configure.ac patching file lib/ChangeLog patching file lib/eu-config.h patching file lib/Makefile.in patching file libasm/ChangeLog patching file libasm/Makefile.in patching file libcpu/ChangeLog patching file libcpu/i386_disasm.c patching file libcpu/Makefile.in patching file libdw/ChangeLog patching file libdw/dwarf_begin_elf.c patching file libdw/libdw.h patching file libdw/Makefile.in patching file libdwfl/ChangeLog patching file libdwfl/linux-core-attach.c patching file libdwfl/linux-pid-attach.c patching file libdwfl/Makefile.in patching file libebl/ChangeLog patching file libebl/Makefile.in patching file libelf/ChangeLog patching file libelf/common.h patching file libelf/gnuhash_xlate.h patching file libelf/Makefile.in patching file m4/Makefile.in patching file Makefile.in patching file src/addr2line.c patching file src/ChangeLog patching file src/findtextrel.c patching file src/ld.h patching file src/Makefile.am patching file src/Makefile.in patching file src/readelf.c patching file src/strings.c patching file src/strip.c patching file tests/backtrace.c patching file tests/ChangeLog patching file tests/line2addr.c patching file tests/Makefile.in Patch redhat-portability.diff does not apply (enforce with -f) DEBUG: Python function patch_do_patch finished DEBUG: Python function do_patch
Re: [yocto] Bitbake error for elfutils-native
Good day Anoop, Error is in do_patch task when applying patch for configure. Please check the hashes in your patch if it's compatible with the HEAD or some upstream changes for configure. Thanks, Joseph On Thu, Jul 24, 2014 at 3:05 PM, Anoop wrote: > bitbake for imx6qsabreauto > > command used > bitbake -v tizen-common-core-image-minimal-dev > > I have applied fix to - meta/classes/patch.bbclass > i.e > + del os.environ['TMPDIR'] > > ***Error Log > ERROR: Command Error: exit status: 1 Output: > Applying patch redhat-portability.diff > patching file backends/ChangeLog > patching file backends/Makefile.am > patching file backends/Makefile.in > patching file ChangeLog > patching file config/ChangeLog > patching file config/eu.am > patching file config/Makefile.in > Hunk #1 succeeded at 147 (offset 1 line). > Hunk #2 succeeded at 179 (offset 1 line). > patching file config.h.in > patching file configure > Hunk #1 FAILED at 661. > Hunk #2 FAILED at 678. > Hunk #3 FAILED at 802. > Hunk #4 FAILED at 1461. > Hunk #5 succeeded at 4943 with fuzz 1 (offset 234 lines). > Hunk #6 FAILED at 4869. > Hunk #7 succeeded at 5535 (offset 256 lines). > Hunk #8 FAILED at 6015. > Hunk #9 succeeded at 7010 with fuzz 1 (offset 257 lines). > 6 out of 9 hunks FAILED -- rejects in file configure > patching file configure.ac > patching file lib/ChangeLog > patching file lib/eu-config.h > patching file lib/Makefile.in > patching file libasm/ChangeLog > patching file libasm/Makefile.in > patching file libcpu/ChangeLog > patching file libcpu/i386_disasm.c > patching file libcpu/Makefile.in > patching file libdw/ChangeLog > patching file libdw/dwarf_begin_elf.c > patching file libdw/libdw.h > patching file libdw/Makefile.in > patching file libdwfl/ChangeLog > patching file libdwfl/linux-core-attach.c > patching file libdwfl/linux-pid-attach.c > patching file libdwfl/Makefile.in > patching file libebl/ChangeLog > patching file libebl/Makefile.in > patching file libelf/ChangeLog > patching file libelf/common.h > patching file libelf/gnuhash_xlate.h > patching file libelf/Makefile.in > patching file m4/Makefile.in > patching file Makefile.in > patching file src/addr2line.c > patching file src/ChangeLog > patching file src/findtextrel.c > patching file src/ld.h > patching file src/Makefile.am > patching file src/Makefile.in > patching file src/readelf.c > patching file src/strings.c > patching file src/strip.c > patching file tests/backtrace.c > patching file tests/ChangeLog > patching file tests/line2addr.c > patching file tests/Makefile.in > Patch redhat-portability.diff does not apply (enforce with -f) > ERROR: Function failed: patch_do_patch > ERROR: Logfile of failure stored in: > /home/sfm/yocto_temp/build/tmp/work/i686-linux/elfutils-native/0.158- > r0/temp/log.do_patch.3531 > ERROR: Task 993 (virtual:native:/home/sfm/yocto_temp/poky/meta/recipes- > devtools/elfutils/elfutils_0.158.bb, do_patch) failed with exit code '1' > > > do patch log file > > /home/sfm/yocto_temp/poky/meta/recipes-devtools/elfutils/elfutils/ > /home/sfm/yocto_temp/poky/meta/recipes-devtools/elfutils/files/ > NOTE: Applying patch 'redhat-portability.diff' (../poky/meta/recipes- > devtools/elfutils/elfutils-0.158/redhat-portability.diff) > ERROR: Command Error: exit status: 1 Output: > Applying patch redhat-portability.diff > patching file backends/ChangeLog > patching file backends/Makefile.am > patching file backends/Makefile.in > patching file ChangeLog > patching file config/ChangeLog > patching file config/eu.am > patching file config/Makefile.in > Hunk #1 succeeded at 147 (offset 1 line). > Hunk #2 succeeded at 179 (offset 1 line). > patching file config.h.in > patching file configure > Hunk #1 FAILED at 661. > Hunk #2 FAILED at 678. > Hunk #3 FAILED at 802. > Hunk #4 FAILED at 1461. > Hunk #5 succeeded at 4943 with fuzz 1 (offset 234 lines). > Hunk #6 FAILED at 4869. > Hunk #7 succeeded at 5535 (offset 256 lines). > Hunk #8 FAILED at 6015. > Hunk #9 succeeded at 7010 with fuzz 1 (offset 257 lines). > 6 out of 9 hunks FAILED -- rejects in file configure > patching file configure.ac > patching file lib/ChangeLog > patching file lib/eu-config.h > patching file lib/Makefile.in > patching file libasm/ChangeLog > patching file libasm/Makefile.in > patching file libcpu/ChangeLog > patching file libcpu/i386_disasm.c > patching file libcpu/Makefile.in > patching file libdw/ChangeLog > patching file libdw/dwarf_begin_elf.c > patching file libdw/libdw.h > patching file libdw/Makefile.in > patching file libdwfl/ChangeLog > patching file libdwfl/linux-core-attach.c > patching file libdwfl/linux-pid-attach.c > patching file libdwfl/Makefile.in > patching file libebl/ChangeLog > patching file libebl/Makefile.in > patching file libelf/ChangeLog > patching file libelf/common.h > patching file libelf/gnuhash_xlate.h > patching file libelf/Makefile.in > patching file m4/Makefile.in > patching file Makefile.in > patchi
Re: [yocto] Bitbake error for elfutils-native
On 24 July 2014 08:05, Anoop wrote: > Patch redhat-portability.diff does not apply (enforce with -f) Please update your poky, this has been fixed already and the meta-tizen fork of Poky has already integrated this fix. (poky commit 52a6d20519870103134166d91e22d21fd736195d) Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SDK not contianing archive libraries
Good day Ross,
I've mimic'd the bitbake.conf way of adding -staticdev. Apparently I got a
QA error stating that there are already multiple definitions of -staticdev
for my unit.
BTW, what's the purpose of ALLOW_EMPTY_${PN} = "1" and
ALLOW_EMPTY_${PN}-dev = "1"?
Really thank you for your help with this one.
- Joseph
On Wed, Jul 23, 2014 at 5:27 PM, Burton, Ross wrote:
> On 23 July 2014 10:23, Joseph Andrew de la Peña
> wrote:
> > Thanks for your reply Anooj. Apparently, based on my findings, the SDK
> > contains libraries that are "libtool archives", .la. For my part, I have
> > used .a only which is not "libtoolized". I'm finding a way how to make my
> > unit generate a libtool archive.
>
> In general you don't need libtool archives. If you want .a files in
> the SDK for static linking then you want to add the recipe's
> -staticdev packages to the SDK.
>
> Ross
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-mingw][PATCH] *-mingw32: Do not set binutils-crosssdk preferred provider
Nowadays this is already set in OE-Core, in tcmode-default.inc.
Fixes:
WARNING: Variable key
PREFERRED_PROVIDER_virtual/${SDK_PREFIX}binutils-crosssdk
(binutils-crosssdk-${SDK_ARCH}) replaces original key
PREFERRED_PROVIDER_virtual/x86_64-oesdk-mingw32-binutils-crosssdk
(binutils-crosssdk-${SDK_ARCH}).
Signed-off-by: Jacob Kroon
---
conf/machine-sdk/i686-mingw32.conf | 1 -
conf/machine-sdk/x86_64-mingw32.conf | 1 -
2 files changed, 2 deletions(-)
diff --git a/conf/machine-sdk/i686-mingw32.conf
b/conf/machine-sdk/i686-mingw32.conf
index 2567e26..098fc3d 100644
--- a/conf/machine-sdk/i686-mingw32.conf
+++ b/conf/machine-sdk/i686-mingw32.conf
@@ -3,7 +3,6 @@ SDK_OS = "mingw32"
GCCTHREADS_mingw32 = "win32"
-PREFERRED_PROVIDER_virtual/${SDK_SYS}-binutils-crosssdk =
"binutils-crosssdk-${SDK_ARCH}"
PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc =
"nativesdk-mingw-w64-runtime"
PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
PREFERRED_PROVIDER_virtual/nativesdk-libintl = "nativesdk-mingw-w64-runtime"
diff --git a/conf/machine-sdk/x86_64-mingw32.conf
b/conf/machine-sdk/x86_64-mingw32.conf
index 6a66b60..ac66623 100644
--- a/conf/machine-sdk/x86_64-mingw32.conf
+++ b/conf/machine-sdk/x86_64-mingw32.conf
@@ -3,7 +3,6 @@ SDK_OS = "mingw32"
GCCTHREADS_mingw32 = "win32"
-PREFERRED_PROVIDER_virtual/${SDK_SYS}-binutils-crosssdk =
"binutils-crosssdk-${SDK_ARCH}"
PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc =
"nativesdk-mingw-w64-runtime"
PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
PREFERRED_PROVIDER_virtual/nativesdk-libintl = "nativesdk-mingw-w64-runtime"
--
1.9.3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SDK not contianing archive libraries
On 24 July 2014 08:30, Joseph Andrew de la Peña wrote:
> I've mimic'd the bitbake.conf way of adding -staticdev. Apparently I got a
> QA error stating that there are already multiple definitions of -staticdev
> for my unit.
Your package will already have them due to the default values in
bitbake.conf, I meant you'll need to add those packages to your SDK.
> BTW, what's the purpose of ALLOW_EMPTY_${PN} = "1" and ALLOW_EMPTY_${PN}-dev
> = "1"?
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-ALLOW_EMPTY
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What kernel configs are needed for using DM_CRYPT with cryptsetup?
Hello Brian,
You have to enable CONFIG_DM_CRYPT and CONFIG_BLK_DEV_DM in kernel;
Also make sure you have corresponding CONFIG_CRYPTO* enabled. And, if
compiled as modules, make sure that modules are loaded before running
cryptsetup during runtime
See https://code.google.com/p/cryptsetup/wiki for more info.
BR,
Maxim.
On Fri, Jul 18, 2014 at 11:31 PM, Wenholz, Brian (GE Healthcare) <
brian.wenh...@med.ge.com> wrote:
> All,
>
>
>
> I have been struggling to get this working. I intend to use an encrypted
> loop device during runtime (not at boot time). I have included the meta-oe
> cryptsetup recipe (V1.6.2) and am trying to “create” (or open) the loop
> file on my Yocto system.
>
>
>
> The basic attempt is:
>
>
>
> head -c 100M /dev/zero > test
>
> cryptsetup create t1 test
>
>
>
> The passphrase is requested and then cryptsetup hangs. Strace reveals that
> cryptsetup is hanging on a kernel semaphore that never returns, but I have
> been unable to decipher (pun intended) what the meaning of the strace log
> is.
>
>
>
> Any help would be appreciated.
>
>
>
> Brian Wenholz
>
>
>
> The strace log follows and kernel config is attached:
>
>
>
> execve("/usr/sbin/cryptsetup", ["cryptsetup", "create", "t1", "test"], [/*
> 15 vars */]) = 0
>
> brk(0) = 0x8056000
>
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb77ca000
>
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
>
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>
> fstat64(3, {st_mode=S_IFREG|0644, st_size=43040, ...}) = 0
>
> mmap2(NULL, 43040, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77bf000
>
> close(3)= 0
>
> open("/usr/lib/libcryptsetup.so.4", O_RDONLY|O_CLOEXEC) = 3
>
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\320\207H4\0\0\0"...,
> 512) = 512
>
> fstat64(3, {st_mode=S_IFREG|0755, st_size=158244, ...}) = 0
>
> mmap2(0x4887a000, 155620, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0x4887a000
>
> mmap2(0x4889f000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25) = 0x4889f000
>
> close(3)= 0
>
> open("/usr/lib/libpopt.so.0", O_RDONLY|O_CLOEXEC) = 3
>
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P:\213H4\0\0\0"..., 512) =
> 512
>
> fstat64(3, {st_mode=S_IFREG|0755, st_size=47060, ...}) = 0
>
> mmap2(0x488b2000, 48332, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0x488b2000
>
> mmap2(0x488bd000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa) = 0x488bd000
>
> close(3)= 0
>
> open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
>
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p6\272I4\0\0\0"..., 512) =
> 512
>
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1527200, ...}) = 0
>
> mmap2(0x49b8a000, 1534652, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0x49b8a000
>
> mmap2(0x49cfb000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x171) = 0x49cfb000
>
> mmap2(0x49cfe000, 10940, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x49cfe000
>
> close(3)= 0
>
> open("/lib/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
>
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320N{H4\0\0\0"..., 512) =
> 512
>
> fstat64(3, {st_mode=S_IFREG|0755, st_size=15820, ...}) = 0
>
> mmap2(0x487b4000, 12776, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0x487b4000
>
> mmap2(0x487b7000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x487b7000
>
> close(3)= 0
>
> open("/usr/lib/libdevmapper.so.1.02", O_RDONLY|O_CLOEXEC) = 3
>
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\361{H4\0\0\0"..., 512)
> = 512
>
> fstat64(3, {st_mode=S_IFREG|0555, st_size=242320, ...}) = 0
>
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb77be000
>
> mmap2(0x487ba000, 243612, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0x487ba000
>
> mmap2(0x487f2000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x38) = 0x487f2000
>
> mmap2(0x487f5000, 1948, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x487f5000
>
> close(3)= 0
>
> open("/usr/lib/libssl.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
>
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220a\202H4\0\0\0"..., 512)
> = 512
>
> fstat64(3, {st_mode=S_IFREG|0755, st_size=387880, ...}) = 0
>
> mmap2(0x4881a000, 385004, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0x4881a000
>
> mmap2(0x48873000, 20480, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x59) = 0x48873000
>
> close(3)= 0
>
> open("/lib/libcrypto.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
>
> read(3, "\177ELF\1\1\1\0\0\0\0\0
Re: [yocto] Bitbake error for elfutils-native
Burton, Ross writes: > > On 24 July 2014 08:05, Anoop wrote: > > Patch redhat-portability.diff does not apply (enforce with -f) > > Please update your poky, this has been fixed already and the > meta-tizen fork of Poky has already integrated this fix. > > (poky commit 52a6d20519870103134166d91e22d21fd736195d) > > Ross Ross many thanks for the valuable input. I had been building tizen with yocto based on the following link. https://wiki.tizen.org/wiki/Build_Tizen_with_Yocto For poky it is mentioned to use git clone https://github.com/eurogiciel-oss/poky.git I think the redhat-portability.diff file in the path /home/sfm/yocto_temp/poky/meta/recipes-devtools/elfutils/elfutils-0.158 as well as /home/sfm/yocto_temp/poky/meta/recipes-devtools/elfutils/elfutils might not have been updated based on the poky commit 52a6d20519870103134166d91e22d21fd736195d. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake error for elfutils-native
On 24 July 2014 10:25, Anoop wrote: > Ross > many thanks for the valuable input. > I had been building tizen with yocto based on the following link. > > https://wiki.tizen.org/wiki/Build_Tizen_with_Yocto > > For poky it is mentioned to use > git clone https://github.com/eurogiciel-oss/poky.git > > I think the redhat-portability.diff file in the path > /home/sfm/yocto_temp/poky/meta/recipes-devtools/elfutils/elfutils-0.158 > as well as > /home/sfm/yocto_temp/poky/meta/recipes-devtools/elfutils/elfutils > might not have been updated based on the poky commit > 52a6d20519870103134166d91e22d21fd736195d. https://github.com/eurogiciel-oss/poky/commit/52a6d20519870103134166d91e22d21fd736195d It's there - you need to pull the latest commits. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SELinux doesn't work on t4240qds
Hi Mark,
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Mark Hatle
> Sent: Wednesday, July 23, 2014 10:41 PM
> To: yocto@yoctoproject.org
> Subject: Re: [yocto] SELinux doesn't work on t4240qds
>
> On 7/23/14, 7:15 AM, zhenhua@freescale.com wrote:
> > I tried dora(poky + meta-selinux + meta-fsl-ppc), following error
> message appears during kernel boot up, please help.
> >
> > RAMDISK: gzip image found at block 0
> > VFS: Mounted root (ext2 filesystem) on device 1:0.
> > devtmpfs: mounted
> > Freeing unused kernel memory: 340k freed Mount failed for selinuxfs on
> > /sys/fs/selinux: No such file or directory
>
> Sounds like the selinuxfs was not enabled -- or the /sys/fs/selinux mount
> mount was not created by default. I'd start with suspecting the kernel
> configuration, and then look to see if the early init scripts for selinux
> are incorrect and need to add that mount mount.
[Luo Zhenhua-B19537] The selinuxfs is not enabled in kernel, selinux permissive
mode can be boot up successfully after enabling this option.
The enforce mode can't boot up successfully, I am not sure what's the
reason.
Following is the log.
type=1403 audit(1600153052.391:2): policy loaded auid=4294967295
ses=4294967295
type=1400 audit(1600153052.403:3): avc: denied { execmem } for
pid=1 comm="init" scontext=system_u:system_r:kernel_t:s15:c0.c1023
tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=process
Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
Call Trace:
[c002f915f890] [c0008b2c] .show_stack+0x7c/0x1f0
(unreliable)
[c002f915f960] [c0816868] .panic+0xec/0x24c
[c002f915f9f0] [c003d094] .do_exit+0x964/0xa40
[c002f915fae0] [c003e354] .do_group_exit+0x54/0xf0
[c002f915fb70] [c004d0a0]
.get_signal_to_deliver+0x1e0/0x670
[c002f915fc70] [c000aa44] .do_signal+0x54/0x2d0
[c002f915fdb0] [c000adf8] .do_notify_resume+0x68/0x80
[c002f915fe30] [cb18] .ret_from_except_lite+0x44/0x48
Best Regards,
Zhenhua
> --Mark
>
> > Unable to load SELinux Policy. Machine is in enforcing mode. Halting
> now.
> > Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x0100
> >
> > Call Trace:
> > [c002f9143ae0] [c0008b2c] .show_stack+0x7c/0x1f0
> > (unreliable) [c002f9143bb0] [c0816e48] .panic+0xec/0x24c
> > [c002f9143c40] [c003d094] .do_exit+0x964/0xa40
> > [c002f9143d30] [c003e354] .do_group_exit+0x54/0xf0
> > [c002f9143dc0] [c003e404] .SyS_exit_group+0x14/0x20
> > [c002f9143e30] [c598] syscall_exit+0x0/0x88 Rebooting
> > in 180 seconds..
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> >
> >> -Original Message-
> >> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> >> boun...@yoctoproject.org] On Behalf Of zhenhua@freescale.com
> >> Sent: Wednesday, July 23, 2014 10:29 AM
> >> To: Mark Hatle; yocto@yoctoproject.org
> >> Subject: Re: [yocto] SELinux doesn't work on t4240qds
> >>
> >> Hi Mark,
> >>
> >> Thanks for your comments.
> >>
> >>> -Original Message-
> >>> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> >>> boun...@yoctoproject.org] On Behalf Of Mark Hatle
> >>>
> >>> On 7/22/14, 10:11 AM, zhenhua@freescale.com wrote:
> Hi all,
> >>>
> >>> Which release are you using.
> >> [Luo Zhenhua-B19537] I tried poky daisy + meta-fsl-ppc master + meta-
> >> selinux master
> >>
> >>> The last version I used w/ meta-selinux was the 1.5 release.
> >>>
> >>> We're planning on updating it to master in the 'near' future
> >>> [patches welcome!], and I've been told by a few others of success w/
> 1.7.
> >> [Luo Zhenhua-B19537] I will try master and dora.
> >>
> >>> Did you enable the 'selinux' distribution flag?
> >>> If so, it should have enabled all of the components necessary for
> >>> this
> >> stuff to be enabled.
> >> [Luo Zhenhua-B19537] Yes, selinux is in DISTRO_FEATURES.
> >>
> >>
> >> Best Regards,
> >>
> >> Zhenhua
> >>
> >>> --Mark
> >>>
> I use the meta-selinux layer to build a core-image-selinux rootfs
> image, and build kernel with following options enabled.
>
> CONFIG_AUDIT=y
>
> CONFIG_NETWORK_SECMARK=y
>
> CONFIG_EXT2_FS_SECURITY=y
>
> CONFIG_EXT3_FS_SECURITY=y
>
> CONFIG_EXT4_FS_SECURITY=y
>
> CONFIG_JFS_SECURITY=y
>
> CONFIG_REISERFS_FS_SECURITY=y
>
> CONFIG_JFFS2_FS_SECURITY=y
>
> CONFIG_SECURITY_NETWORK=y
>
> CONFIG_SECURITY_SELINUX=y
>
> CONFIG_SECURITY_SELINUX_BOOTPARAM=y
>
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
>
> CONFIG_SECURITY_SELINUX_DISABLE=y
>
> CONFIG_SECURITY_SELINUX_DEVELOP=y
>
[yocto] [meta-selinux][PATCH] Enable two options to ensure selinux can boot up
* CONFIG_SECURITY=y * CONFIG_SECURITYFS=y Signed-off-by: Zhenhua Luo --- recipes-kernel/linux/linux-yocto/selinux.cfg | 2 ++ 1 file changed, 2 insertions(+) diff --git a/recipes-kernel/linux/linux-yocto/selinux.cfg b/recipes-kernel/linux/linux-yocto/selinux.cfg index 53cdf57..2edd366 100644 --- a/recipes-kernel/linux/linux-yocto/selinux.cfg +++ b/recipes-kernel/linux/linux-yocto/selinux.cfg @@ -18,6 +18,8 @@ CONFIG_EXT4_FS_SECURITY=y CONFIG_JFS_SECURITY=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFFS2_FS_SECURITY=y +CONFIG_SECURITY=y +CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y -- 1.9.3 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake error for elfutils-native
Thank you Ross for the wonderful support. I cherrypicked the commit. The issue is resolved now. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Bitbake error for rpm-native -- do compile failed
bitbake for imx6qsabreauto command used bitbake -v tizen-common-core-image-minimal-dev Summary: 1 task failed: virtual:native:/home/sfm/yocto_temp/meta-tizen/recipes- tizen/rpm/rpm_git.bb, do_compile + CPPFLAGS=-isystem/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/include -I/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/include/nss3 + export CPPFLAGS + export LDFLAGS=-L/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/lib -L/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,- rpath-link,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/usr/lib -Wl,- rpath-link,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,- rpath,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/usr/lib -Wl,- rpath,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,-O1 -Wl,- Bsymbolic-functions -ffunction-sections + export CCFLAGS+= -fPIC /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git- r0/temp/run.do_compile.26826: 120: export: CCFLAGS+: bad variable name + bb_exit_handler + ret=2 + echo WARNING: exit code 2 from a shell command. WARNING: exit code 2 from a shell command. + exit 2 ERROR: Function failed: do_compile (log file is located at /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git- r0/temp/log.do_compile.26826) *do compile log file* DEBUG: Executing shell function do_compile + cd /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-r0/git + do_compile + cd /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-r0/git + LANG=C + export LANG + unset DISPLAY + LD_AS_NEEDED=1 + export LD_AS_NEEDED + pkg-config --cflags nss + CPPFLAGS=-isystem/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/include -I/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/include/nss3 + export CPPFLAGS + export LDFLAGS=-L/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/lib -L/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,- rpath-link,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/usr/lib -Wl,- rpath-link,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,- rpath,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/usr/lib -Wl,- rpath,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,-O1 -Wl,- Bsymbolic-functions -ffunction-sections + export CCFLAGS+= -fPIC /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git- r0/temp/run.do_compile.26826: 120: export: CCFLAGS+: bad variable name + bb_exit_handler + ret=2 + echo WARNING: exit code 2 from a shell command. WARNING: exit code 2 from a shell command. + exit 2 + cd /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-r0/git + do_compile + cd /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git-r0/git + LANG=C + export LANG + unset DISPLAY + LD_AS_NEEDED=1 + export LD_AS_NEEDED + pkg-config --cflags nss + CPPFLAGS=-isystem/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/include -I/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/include/nss3 + export CPPFLAGS + export LDFLAGS=-L/home/sfm/yocto_temp/build/tmp/sysroots/i686- linux/usr/lib -L/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,- rpath-link,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/usr/lib -Wl,- rpath-link,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,- rpath,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/usr/lib -Wl,- rpath,/home/sfm/yocto_temp/build/tmp/sysroots/i686-linux/lib -Wl,-O1 -Wl,- Bsymbolic-functions -ffunction-sections + export CCFLAGS+= -fPIC /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git- r0/temp/run.do_compile.26826: 120: export: CCFLAGS+: bad variable name + bb_exit_handler + ret=2 + echo WARNING: exit code 2 from a shell command. WARNING: exit code 2 from a shell command. + exit 2 ERROR: Function failed: do_compile (log file is located at /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git- r0/temp/log.do_compile.26826) Request inputs to resolve this error -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake error for rpm-native -- do compile failed
On 24 July 2014 14:29, Anoop wrote: > + export CCFLAGS+= -fPIC > /home/sfm/yocto_temp/build/tmp/work/i686-linux/rpm-native/git- > r0/temp/run.do_compile.26826: 120: export: CCFLAGS+: bad variable name += is a bash extension and those scripts are not running under bash. This has been fixed in meta-tizen. *Please* fetch the latest revisions. Also, this isn't the best list for problems with meta-tizen as meta-tizen isn't part of the Yocto project - you'll be better off contacting the maintainers directly or filing bugs in their issue tracker. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] whose leg do you have to hump to get access to RDK?
was asked about the yocto-based RDK initiative last week: http://rdkcentral.com/ looked interesting so i thought i would read up on it. tried to access the wiki, was told i needed an account and password. registered for that, was told i wasn't on the list of official licensees. applied for that, waiting to hear back. *sigh*. is it worth expending any more effort here? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Why won't my app use multiple threads under 'valleyisland'?
I've got a recipe for an application. This has:
1) A main thread;
2) An OpenGL ('X' / EGL) graphics rendering thread created using posix threads;
3) As many threads as required from the graphics thread for GStreamer to
service various pipelines.
On a Cedartrail platform this happily uses multiple cores.
However, if I use the same recipe under a 64-bit valleyisland build (daisy) it
only ever uses a single core (and virtually grinds to a halt).
'top' shows CPU usage for the application never goes above 25% (J1900, so four
cores available). Running four instances of 'yes' gets the total CPU usage to
100%, so all the cores are available.
'taskset' shows that the affinity mask for the application is not restricting
the set of available cores.
Umm... Any ideas what's going on here?
It looks as if GStreamer and OpenGL are fighting for access to something, but
the pipelines only render to 'fakesink' and 'appsink'.
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] OpenSSL 1.0.0m
question on the openssl recipes and openssl versions... Point me to the correct distro if this is the incorrect spot to ask this... We're currently on Danny, 1.3.2. In there, the openssl version is 1.0.0j. The openssl project is currently promoting 1.0.1h. Due to the multiple CVEs being released, we're wanting to move to the latest. But, looking at the poky releases, it seems that, after "Danny", Poky reverted back to 1.0.0e and added patches as CVEs are released. For example, here's the patches in "Daisy" (1.6.1): openssl-1.0.1e-cve-2014-0195.patch openssl-1.0.1e-cve-2014-0198.patch openssl-1.0.1e-cve-2014-0221.patch openssl-1.0.1e-cve-2014-0224.patch openssl-1.0.1e-cve-2014-3470.patch openssl-CVE-2010-5298.patch Am I reading that correct? If I move to the recipes there, will that close current issues on openssl? Or, is there a recipe available to use 1.0.1h? Thanks for any info. Mark Evans -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OpenSSL 1.0.0m
On Thu, Jul 24, 2014 at 5:44 PM, Mark Evans wrote: > question on the openssl recipes and openssl versions... Point me to the > correct distro if this is the incorrect spot to ask this... > > We're currently on Danny, 1.3.2. In there, the openssl version is 1.0.0j. > The openssl project is currently promoting 1.0.1h. Due to the multiple CVEs > being released, we're wanting to move to the latest. But, looking at the > poky releases, it seems that, after "Danny", Poky reverted back to 1.0.0e > and added patches as CVEs are released. For example, here's the patches in > "Daisy" (1.6.1): > > openssl-1.0.1e-cve-2014-0195.patch > openssl-1.0.1e-cve-2014-0198.patch > openssl-1.0.1e-cve-2014-0221.patch > openssl-1.0.1e-cve-2014-0224.patch > openssl-1.0.1e-cve-2014-3470.patch > openssl-CVE-2010-5298.patch > > Am I reading that correct? If I move to the recipes there, will that close > current issues on openssl? Or, is there a recipe available to use 1.0.1h? > oe-core/master is having 1.0.1h, you can backport that into your own layer and tool your project to use it. > Thanks for any info. > Mark Evans > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OpenSSL 1.0.0m
Thanks for the nfo. I'll go there and take a look. --MarkE On 7/24/2014 7:51 PM, Khem Raj wrote: On Thu, Jul 24, 2014 at 5:44 PM, Mark Evans wrote: question on the openssl recipes and openssl versions... Point me to the correct distro if this is the incorrect spot to ask this... We're currently on Danny, 1.3.2. In there, the openssl version is 1.0.0j. The openssl project is currently promoting 1.0.1h. Due to the multiple CVEs being released, we're wanting to move to the latest. But, looking at the poky releases, it seems that, after "Danny", Poky reverted back to 1.0.0e and added patches as CVEs are released. For example, here's the patches in "Daisy" (1.6.1): openssl-1.0.1e-cve-2014-0195.patch openssl-1.0.1e-cve-2014-0198.patch openssl-1.0.1e-cve-2014-0221.patch openssl-1.0.1e-cve-2014-0224.patch openssl-1.0.1e-cve-2014-3470.patch openssl-CVE-2010-5298.patch Am I reading that correct? If I move to the recipes there, will that close current issues on openssl? Or, is there a recipe available to use 1.0.1h? oe-core/master is having 1.0.1h, you can backport that into your own layer and tool your project to use it. Thanks for any info. Mark Evans -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding prebuilt binaries/libraries to /usr/bin or/usr/lib on rootfs
The steps shared by you is telling about customizing the image on existing
recipes.
But I query is how to add prebuild libraries directly to rootfs.
Thanks in Advance.
Regards
Meena
From: Vladimir Redzhepov [vladimir_redzhe...@epam.com]
Sent: Friday, July 18, 2014 4:05 PM
To: Meenakumari Shedole; yocto@yoctoproject.org; ross.bur...@intel.com
Subject: RE: [yocto] Adding prebuilt binaries/libraries to /usr/bin or/usr/lib
on rootfs
There're some variables and methods that are responsible for rootfs content.
The official documentation is a good place to start
Read carefully how to customize image here
http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky-extend-customimage
-Original Message-
From: Meenakumari Shedole [mailto:meenakumar...@hcl.com]
Sent: Friday, July 18, 2014 1:01 PM
To: Vladimir Redzhepov; yocto@yoctoproject.org; ross.bur...@intel.com
Subject: RE: [yocto] Adding prebuilt binaries/libraries to /usr/bin or/usr/lib
on rootfs
Thanks for your response.
But if I have few different packages like "usb" "BT" "Qt" and only these
packages bin and libraries if I want to add to yocto rootfs ?
Regards
Meena
From: Vladimir Redzhepov [vladimir_redzhe...@epam.com]
Sent: Friday, July 18, 2014 2:28 PM
To: Meenakumari Shedole; yocto@yoctoproject.org; ross.bur...@intel.com
Subject: RE: [yocto] Adding prebuilt binaries/libraries to /usr/bin or/usr/lib
on rootfs
Hi
You should look closely at meta-oracle-java layer if want to add some binaries
to the target rootfs. On the other hand if you want to use binaries within the
build process they should be put down in the places poky could find them.
There's an example how to use a binary apache-maven within build process
DESCRIPTION = "Maven is a software project management and comprehension tool.
Based on the concept \
of a Project Object Model (POM), Maven can manage a project's build, reporting
and documentation \
from a central piece of information."
HOMEPAGE = "http://maven.apache.org";
SECTION = "devel"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=9af13b2d31a47f71518aa5dde47fc025"
SRC_URI =
"http://ftp.byfly.by/pub/apache.org/maven/maven-3/${PV}/binaries/${BP}-bin.zip";
SRC_URI[md5sum] = "5d86506f17e5ff0b0c83c648f4093abb"
SRC_URI[sha256sum] =
"df3338233b34f6d65ec3901fc0039f72ba59ff1380d09eebc5b58916b5fea2a3"
do_configure() {
sed -i
'49i${STAGING_DATADIR_NATIVE}/maven-repository'
${S}/conf/settings.xml
}
do_install() {
install -d -m 0755 ${D}${bindir}/${PN}
cp -ar * ${D}${bindir}/${PN}
ln -sf ${PN}/bin/mvn ${D}${bindir}/mvn
}
BBCLASSEXTEND = "native"
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Meenakumari Shedole
Sent: Friday, July 18, 2014 8:55 AM
To: yocto@yoctoproject.org; ross.bur...@intel.com
Subject: [yocto] Adding prebuilt binaries/libraries to /usr/bin or/usr/lib on
rootfs
Hi all.
I have few prebuilt binaries and libraries, and I want to add them to the yocto
build rootfs at the
build itself.
So Can any one please tell me the steps to add recipes or suggest me any other
method for this.
Thnaks in Advance.
Regards
Meena
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and
other defects.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
