Re: [OE-core] [RFC PATCH 0/6] (e)SDK workflow directly in a Yocto build
Hello Alexander, On Wed, Jun 22, 2022 at 12:33 PM Alexander Kanavin wrote: > > There's been a recent discussion about how we can make the Yocto SDK > experience better [1]. One of the ideas was to eliminate the SDK > as a separate artefact altogether and simply provide everything > that the SDK and eSDKs do directly in a yocto build. > > So without further ado, here's how you get a 'SDK' with this set of patches: > Thanks for this work! I like this approach. Regards, Leon. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171692): https://lists.openembedded.org/g/openembedded-core/message/171692 Mute This Topic: https://lists.openembedded.org/mt/91918831/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] The state of DKMS in the Yocto community
Hello Alex, with DKMS, do you mean cross-compiling out-of-kernel modules on the build machine (that runs the Yocto/OpenEmbedded driven build)? Or do you mean provisioning the target with enough tools to allow compiling out-of-kernel modules there from source? In the first case, yes, I can share such recipe for reasonably recent releases. Regards, Leon. -- Leon Woestenberg l...@sidebranch.com T: +31 40 711 42 76 M: +31 6 472 30 372 Sidebranch Embedded Systems Eindhoven, The Netherlands http://www.sidebranch.com On Fri, Dec 10, 2021 at 9:58 PM Alex Stewart wrote: > > Hey List, > > I'm trying to work out the mysterious state of DKMS in OE-Core. > > Our (NI) OE distributions rely heavily on DKMS to (un)install our > ecosystem of kernel drivers at runtime across our product lines. To > facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017, > which we have carried out-of-stream since. > > We tried to upstream it, and the patched rev'ed a couple of times [2]; > but it seems to have never made it into a yocto release. > > Though some other recipes mention DKMS passingly, I don't see anywhere > that OE-Core officially supports it. Nor does my googling reveal anyone > else who uses DKMS. I find that a little hard to believe, though I > understand that it's probably relatively rare in the embedded space. > > > @all > So does anyone else on the list use DKMS in their yocto distribution? > Are you maintaining a DKMS recipe out-of-stream as well? > > > @maintainers > If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and > submitted it again to OE-Core, would you accept it? If not, we will move > it to our own meta layer and accept that we are unique in this regard. > > > [1] > https://github.com/ni/openembedded-core/commit/5789a27b68d95f3840bb8c4cb0d7b28d538c9a50 > > [2] https://lists.openembedded.org/g/openembedded-core/message/100680 > > Thanks, > > -- > Alex Stewart > Software Engineer - NI Real-Time OS > NI (National Instruments) > > alex.stew...@ni.com > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159567): https://lists.openembedded.org/g/openembedded-core/message/159567 Mute This Topic: https://lists.openembedded.org/mt/87645999/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] bitbake.conf: Add lz4c, pzstd and zstd
Hi Konrad, On Thu, Aug 19, 2021 at 4:51 PM Konrad Weihmann wrote: > > I mean this is the second hard cut in the project within just weeks and > this time it was host related, which is even harder to fix in a timely > manner in a corporate environment (basically rolling out changes to all > dev installations isn't something I fancy on a Wednesday morning :-( ) > The choice to follow bleeding edge, means bleeding at some points in time. Why do you follow master on all dev installations if you are not able to match (slightly) disruptive changes? I would recommend to prevalidate changes on one instance before spreading across all (inflexible) dev installations anyway. I did not follow the rationale closely, but I think it was related to CMake dependencies as well. Regards, Leon. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154976): https://lists.openembedded.org/g/openembedded-core/message/154976 Mute This Topic: https://lists.openembedded.org/mt/84201703/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] GCC crashes on aarch64 since gatesgarth
> > > Let me know if I must replicate a specific set of commits. > > Don't know what you mean by that, can you explain? > I mean I could try to reproduce your build locally, but I would want the specific commits of the layers you are testing against, and the local.conf settings that trigger your faults. (I.e. be as close to the failing setup as possible). Leon. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147355): https://lists.openembedded.org/g/openembedded-core/message/147355 Mute This Topic: https://lists.openembedded.org/mt/80159078/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] GCC crashes on aarch64 since gatesgarth
Hello Mike, At first sight, this does sound like memory corruption in one specific memory area (DIMM?) to me. Check dmesg for tripping temperatures etc. I would reduce both the amount of bitbake tasks and Makefile parallelism to 1 on a fresh run to reduce memory pressure. Not seen anything similar yet (MACHINE=zcu102, build host i7-10700K w/ 128MB memory.) I would assume aarch64 is widely run by the community. Let me know if I must replicate a specific set of commits. Regards, Leon. On Wed, Jan 27, 2021 at 4:10 PM Mike Looijmans wrote: > When doing large builds, the GCC compiler tends to crash on random spots > in the code. There are a few common denominators though. > > It only happens when compiling for aarch64 (cortex-A53), not for 32-bit > arm (cortex-A9) > > It's random and usually happens on "big" sets like kernel, openssl, > boost, u-boot etc. > > It always reports "during GIMPLE pass: ealias" in the error, for example: > > | during GIMPLE pass: ealias > | ../openssl-1.1.1i/crypto/x509v3/v3_utl.c: In function 'do_x509_check': > | ../openssl-1.1.1i/crypto/x509v3/v3_utl.c:1239:1: internal compiler > error: Illegal instruction > | 1239 | } > > Compiling the same thing again usually goes fine. > > I've never experienced this with the zeus and older branches of OE. > > > I've already tried upgrading to the latest gatesgarth status, and > cleaning out everything and start from scratch. I've also run "mprime" > test on my machine (over one hour) just to be confident that the system > itself is really okay. > > > Ideas to diagnose, fix or reliably reprodruce are more than welcome. > > -- > Mike Looijmans > > > Met vriendelijke groet / kind regards, > > Mike Looijmans > System Expert > > > TOPIC Embedded Products B.V. > Materiaalweg 4, 5681 RJ Best > The Netherlands > > T: +31 (0) 499 33 69 69 > E: mike.looijm...@topicproducts.com > W: www.topicproducts.com > > Please consider the environment before printing this e-mail > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147352): https://lists.openembedded.org/g/openembedded-core/message/147352 Mute This Topic: https://lists.openembedded.org/mt/80159078/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8
On Fri, 15 Jan 2021 at 18:35, Luca Boccassi via lists.openembedded.org wrote: > > > There's the get_kernelversion* functions available to recipes, > reasonably widely used already - so something that checks it and > conditionally installs the drop-in should work fine, in theory? > That would make the workaround a initial build-time dependency. As I understand the proposed solution was a run-time check. What if the kernel is upgraded in the field? > > > -- -- Leon Woestenberg l...@sidebranch.com T: +31 40 711 42 76 M: +31 6 472 30 372 Sidebranch Embedded Systems Eindhoven, The Netherlands http://www.sidebranch.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#146902): https://lists.openembedded.org/g/openembedded-core/message/146902 Mute This Topic: https://lists.openembedded.org/mt/79695930/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V2 2/3] gcc-cross-canadian: Install gcc/g++ wrappers for musl
On Thu, Aug 20, 2020 at 10:01 AM Khem Raj wrote: > > gcc needs -mmusl option to be passed in SDK since we ship crossdk compiler > configured for glibc by default, this helps in creating correct > compiler defaults for musl based SDK compilers > > [YOCTO #13459] > > Signed-off-by: Khem Raj > Cc: Leon Woestenberg > --- > v2: Delete file before creating wrapper > Thanks, v2 works and solves [YOCTO #13459]. We already independently had the same v1->v2 fix locally, while we tested your v1 approach (and ignored the mailing list...) Tested-by: Leon Woestenberg Acked-by: Leon Woestenberg -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141679): https://lists.openembedded.org/g/openembedded-core/message/141679 Mute This Topic: https://lists.openembedded.org/mt/76303678/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/4] gcc-cross-canadian: Install gcc/g++ wrappers for musl
With the rm -f $d/$p added, the links generated earlier are first
removed, then replaced by the wrapper, as expected.
We have tested this to work correctly.
(This fixes the bug where the first echo ... > would write to the
softlink target, the actual gcc binary.)
This is what I have locally in my meta-fixes overlay:
meta-fixes/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend:
do_install_append () {
for i in linux ${CANADIANEXTRAOS}
do
for v in ${CANADIANEXTRAVENDOR}
do
d=${D}${bindir}/../${TARGET_ARCH}$v-$i
install -d $d
for j in ${TARGET_PREFIX}gcc${EXEEXT}
${TARGET_PREFIX}g++${EXEEXT}
do
p=${TARGET_ARCH}$v-$i-`echo $j | sed -e
s,${TARGET_PREFIX},,`
case $i in
*musl*)
# %d/$p is a link to the
compiler, if we redirect output to it, the target will be overwritten
rm -f $d/$p
echo "#!/usr/bin/env sh" > $d/$p
echo "exec \`dirname
\$0\`/../${TARGET_SYS}/$j -mmusl \$@" >> $d/$p
chmod 0755 $d/$p
;;
esac
done
done
done
}
Regards.
Leon.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#141673):
https://lists.openembedded.org/g/openembedded-core/message/141673
Mute This Topic: https://lists.openembedded.org/mt/76303186/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/4] gcc-cross-canadian: Install gcc/g++ wrappers for musl
Hi Khem,
Thanks for looking into this. I applied your patch on top of our zeus
branch (I think the issue is in zeus, dunfell, master).
On Thu, Aug 20, 2020 at 8:57 AM Khem Raj wrote:
>
> gcc needs -mmusl option to be passed in SDK since we ship crossdk compiler
> configured for glibc by default, this helps in creating correct
> compiler defaults for musl based SDK compilers
>
> [YOCTO #13459]
>
> diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
> b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
Can you elaborate why this is the proper solution over just
TARGET_CC_ARCH_append_linux-musl = " --mmusl" in
toolchain-scripts.bbclass?
> +
> + for i in linux ${CANADIANEXTRAOS}
Why keep linux in here?
> + do
> + for v in ${CANADIANEXTRAVENDOR}
> + do
> + d=${D}${bindir}/../${TARGET_ARCH}$v-$i
> + install -d $d
Hmm, even for the non-musl case?
> + for j in ${TARGET_PREFIX}gcc${EXEEXT}
> ${TARGET_PREFIX}g++${EXEEXT}
> + do
> + p=${TARGET_ARCH}$v-$i-`echo $j | sed -e
> s,${TARGET_PREFIX},,`
> + case $i in
> + *musl*)
> + echo "#!/usr/bin/env sh" > $d/$p
$d/$p already exists at this point, and it's a softlink to the actual gcc.
The redirected output will end up in the *target* of the softlink;
this replaces the actual gcc compiler binary by a script, which calls
itself.
It ends up being a recursive invocation.
I have added rm -f $d/$p above to fix this locally, while testing.
> + echo "exec \`dirname
> \$0\`/../${TARGET_SYS}/$j -mmusl \$@" >> $d/$p
> + chmod 0755 $d/$p
> + ;;
Regards,
Leon.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#141669):
https://lists.openembedded.org/g/openembedded-core/message/141669
Mute This Topic: https://lists.openembedded.org/mt/76303186/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] -mmusl missing in SDK / CMake MUSL toolchain
Hello Fred, > This append at the top of toolchain-script.bbclass is thus without effect: > TARGET_CC_ARCH_append_libc-musl = " -mmusl" > > This works: > > TARGET_CC_ARCH_append_linux-musl = " -mmusl" > > FYI, > Sounds like you ran into the SDK / musl problem > Thanks, I have updated https://bugzilla.yoctoproject.org/show_bug.cgi?id=13459 with my findings so far. Regards, Leon. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141649): https://lists.openembedded.org/g/openembedded-core/message/141649 Mute This Topic: https://lists.openembedded.org/mt/76245876/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] -mmusl missing in SDK / CMake MUSL toolchain
RFC:
During the creation of the environment script for the canadian cross
SDK in toolchain-script.bbclass,
for a MUSL C library target, the OVERRIDES contains libc-glibc instead
of libc-musl.
OVERRIDES=task-generate-content:linux-musl:x86-64:pn-meta-environment-qemux86-64:qemuall:qemux86-64:nodistro:class-cross-canadian:libc-glibc:forcevariable
This can be easily inspected by adding these lines to the script
creation (Thanks to Richard for the suggestion on IRC).
echo 'export TARGET_CC_ARCH=${TARGET_CC_ARCH}' >> $script
echo 'export OVERRIDES=${OVERRIDES}' >> $script
This append at the top of toolchain-script.bbclass is thus without effect:
TARGET_CC_ARCH_append_libc-musl = " -mmusl"
This works:
TARGET_CC_ARCH_append_linux-musl = " -mmusl"
(notice linux instead of libc, as linux-musl stays present in OVERRIDES.)
I have a (minimal) test case here. Run make in the cloned repo.
https://github.com/likewise/oe-musl-sdk-cmake
Regards,
--
Leon
p.s. sorry for the HTML sig earlier.
--
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372
Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com
On Mon, Aug 17, 2020 at 5:28 PM Leon Woestenberg via
lists.openembedded.org
wrote:
>
> Hello all,
>
> Compared with a BitBake/CMake built of a C application, the SDK/CMake
> approach lacks the "-mmusl" flag. The resulting binaries of the SDK do not
> load on the target (wrong runtime linker/loader).
>
> Minimal test case here (dunfell), just run make will show PASS / FAIL for
> BitBake and SDK approach:
>
> https://github.com/likewise/oe-musl-sdk-cmake
>
> Has something to do with TARGET_CC_ARCH not propagating, investigation
> further...
>
>
> Regards,
>
> Leon.
> --
> --
> Leon Woestenberg
> l...@sidebranch.com
> T: +31 40 711 42 76
> M: +31 6 472 30 372
>
> Sidebranch Embedded Systems
> Eindhoven, The Netherlands
> http://www.sidebranch.com
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#141646):
https://lists.openembedded.org/g/openembedded-core/message/141646
Mute This Topic: https://lists.openembedded.org/mt/76245876/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [dunfell] [PATCH] cmake-native: Use cmake-provided zstd library; supported host distro zstd may be too old.
Hello Adrian, all, On Sat, Aug 15, 2020 at 9:55 AM Adrian Bunk wrote: > On Fri, Aug 14, 2020 at 11:44:17PM +0200, Alexander Kanavin wrote: > > This needs to go to master first probably? > > Better for master might be moving zstd from meta-openembedded, > and then DEPENDS on zstd-native? > > IMHO moving target zstd to OE-core is already overdue, > so this would not be solely for cmake. > > Good point, makes better sense then my proposed fix for cmake-native only. More breakage of master against Ubuntu 16.04 (still supported by Yocto) that supports Adrian's suggestion: | ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c: In function ‘int lto_normalized_zstd_level()’: | ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c:120:36: error: ‘ZSTD_maxCLevel’ was not declared in this scope |else if (level > ZSTD_maxCLevel ()) | ^ | ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c: In function ‘void lto_uncompression_zstd(lto_compression_stream*)’: | ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c:160:74: error: ‘ZSTD_getFrameContentSize’ was not declared in this scope |unsigned long long const rsize = ZSTD_getFrameContentSize (cursor, size); | ^ | ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c:161:16: error: ‘ZSTD_CONTENTSIZE_ERROR’ was not declared in this scope |if (rsize == ZSTD_CONTENTSIZE_ERROR) | ^ | ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c:163:21: error: ‘ZSTD_CONTENTSIZE_UNKNOWN’ was not declared in this scope |else if (rsize == ZSTD_CONTENTSIZE_UNKNOWN) | ^ | Makefile:1118: recipe for target 'lto-compress.o' failed | make[1]: *** [lto-compress.o] Error 1 | make[1]: *** Waiting for unfinished jobs Did not deep-dive into this, nor test with Adrian's suggestion yet. Regards, Leon. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141645): https://lists.openembedded.org/g/openembedded-core/message/141645 Mute This Topic: https://lists.openembedded.org/mt/76196110/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] -mmusl missing in SDK / CMake MUSL toolchain
Hello all, Compared with a BitBake/CMake built of a C application, the SDK/CMake approach lacks the "-mmusl" flag. The resulting binaries of the SDK do not load on the target (wrong runtime linker/loader). Minimal test case here (dunfell), just run make will show PASS / FAIL for BitBake and SDK approach: https://github.com/likewise/oe-musl-sdk-cmake Has something to do with TARGET_CC_ARCH not propagating, investigation further... Regards, Leon. -- -- Leon Woestenberg l...@sidebranch.com T: +31 40 711 42 76 M: +31 6 472 30 372 Sidebranch Embedded Systems Eindhoven, The Netherlands http://www.sidebranch.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141577): https://lists.openembedded.org/g/openembedded-core/message/141577 Mute This Topic: https://lists.openembedded.org/mt/76245876/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [dunfell] [PATCH] cmake-native: Use cmake-provided zstd library; supported host distro zstd may be too old.
Hello Alexander, On Fri, Aug 14, 2020 at 11:44 PM Alexander Kanavin wrote: > > This needs to go to master first probably? > Alex > > On Fri, 14 Aug 2020 at 22:46, Leon Woestenberg wrote: >> >> cmake-native uses the system provided libraries due to: >> <...> >> This fix is to not depend on the system library and use the zstd library >> provided with cmake. >> Yes most probably, but master did not build for me so was untestable for me within reasonable time span I had for this issue. Regards, Leon. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141464): https://lists.openembedded.org/g/openembedded-core/message/141464 Mute This Topic: https://lists.openembedded.org/mt/76196110/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [dunfell] [PATCH] cmake-native: Use cmake-provided zstd library; supported host distro zstd may be too old.
cmake-native uses the system provided libraries due to: CMAKE_EXTRACONF = "<...> -DCMAKE_USE_SYSTEM_LIBRARIES=1 <...>" Now, iff the libzstd(-dev) is installed but too old, which can happen on Ubuntu 16.04: dpkg -l | grep zstd ii libzstd-dev 0.5.1-1 ii libzstd0 0.5.1-1 cmake configure will use the zstd system library: cat ./tmp/work/x86_64-linux/cmake-native/3.15.3-r0/temp/log.do_configure | grep -i ZSTD -- Using system-installed ZSTD -- Found ZSTD: /usr/lib/x86_64-linux-gnu/libzstd.so but will fail to compile due to: <...>/tmp/work/x86_64-linux/cmake-native/3.15.3-r0/cmake-3.15.3/Utilities/cmlibarchive/libarchive/archive_read_support_filter_zstd.c:59:2: error: unknown type name ‘ZSTD_DStream’ | ZSTD_DStream *dstream; | ^ The library does not contain that datatype: grep -rne ZSTD_DStream /usr/include/zstd.h Apparently the cmake-native library check is not checking the library version or features. This fix is to not depend on the system library and use the zstd library provided with cmake. CMAKE_EXTRACONF = "\ <...> -DCMAKE_USE_SYSTEM_LIBRARY_ZSTD=0 \ <...> Signed-off-by: Leon Woestenberg --- meta/recipes-devtools/cmake/cmake-native_3.16.5.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb b/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb index b2952ee..e0ac3f8 100644 --- a/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb +++ b/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb @@ -21,6 +21,7 @@ CMAKE_EXTRACONF = "\ -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \ -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0 \ -DCMAKE_USE_SYSTEM_LIBRARY_LIBRHASH=0 \ +-DCMAKE_USE_SYSTEM_LIBRARY_ZSTD=0 \ -DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \ -DHAVE_SYS_ACL_H=0 \ " -- 2.7.4 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141461): https://lists.openembedded.org/g/openembedded-core/message/141461 Mute This Topic: https://lists.openembedded.org/mt/76196110/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe-core][zeus][PATCH] cmake-native: Use cmake-provided zstd library; system library might be too old.
On Fri, 14 Aug 2020 at 12:00, Ross Burton wrote: > Is this Zeus specific, or should it also be merged into master and dunfell? Good point. I will see into the supported distro's for dunfell and see if I can replicate the issue there. Note that if the zstd system library is not installed, cmake-native will build, configured without zstd archive support. I will come back with the result, if it is preferable to wait for that result, disregard this patch. > > Ross > > On Thu, 13 Aug 2020 at 12:52, Leon Woestenberg > wrote: > > > > On Mint 19.2 (based on Ubuntu 18.04.2), if the system library zstd is > present, > > the compile fails as follows: > > > > > <...>/tmp/work/x86_64-linux/cmake-native/3.15.3-r0/cmake-3.15.3/Utilities/cmlibarchive/libarchive/archive_read_support_filter_zstd.c:59:2: > > error: unknown type name ‘ZSTD_DStream’ > > | ZSTD_DStream *dstream; > > | ^ > > > > cat ./tmp/work/x86_64-linux/cmake-native/3.15.3-r0/temp/log.do_configure > | grep -i ZSTD > > -- Using system-installed ZSTD > > -- Found ZSTD: /usr/lib/x86_64-linux-gnu/libzstd.so > > > > grep -rne ZSTD_DStream /usr/include/zstd.h > > > > > > The fix in this commit is to use the cmake provided zstd library: > > > > -DCMAKE_USE_SYSTEM_LIBRARY_ZSTD=0 \ > > > > so that on supported distributions, we do not depend on the system zstd > library (version). > > > > Signed-off-by: Leon Woestenberg > > --- > > meta/recipes-devtools/cmake/cmake-native_3.15.3.bb | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.15.3.bb > b/meta/recipes-devtools/cmake/cmake-native_3.15.3.bb > > index b2952ee..e0ac3f8 100644 > > --- a/meta/recipes-devtools/cmake/cmake-native_3.15.3.bb > > +++ b/meta/recipes-devtools/cmake/cmake-native_3.15.3.bb > > @@ -21,6 +21,7 @@ CMAKE_EXTRACONF = "\ > > -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \ > > -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0 \ > > -DCMAKE_USE_SYSTEM_LIBRARY_LIBRHASH=0 \ > > +-DCMAKE_USE_SYSTEM_LIBRARY_ZSTD=0 \ > > -DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \ > > -DHAVE_SYS_ACL_H=0 \ > > " > > -- > > 2.7.4 > > > > > -- -- Leon Woestenberg l...@sidebranch.com T: +31 40 711 42 76 M: +31 6 472 30 372 Sidebranch Embedded Systems Eindhoven, The Netherlands http://www.sidebranch.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141454): https://lists.openembedded.org/g/openembedded-core/message/141454 Mute This Topic: https://lists.openembedded.org/mt/76165585/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe-core][zeus][PATCH] cmake-native: Use cmake-provided zstd library; system library might be too old.
On Mint 19.2 (based on Ubuntu 18.04.2), if the system library zstd is present, the compile fails as follows: <...>/tmp/work/x86_64-linux/cmake-native/3.15.3-r0/cmake-3.15.3/Utilities/cmlibarchive/libarchive/archive_read_support_filter_zstd.c:59:2: error: unknown type name ‘ZSTD_DStream’ | ZSTD_DStream *dstream; | ^ cat ./tmp/work/x86_64-linux/cmake-native/3.15.3-r0/temp/log.do_configure | grep -i ZSTD -- Using system-installed ZSTD -- Found ZSTD: /usr/lib/x86_64-linux-gnu/libzstd.so grep -rne ZSTD_DStream /usr/include/zstd.h The fix in this commit is to use the cmake provided zstd library: -DCMAKE_USE_SYSTEM_LIBRARY_ZSTD=0 \ so that on supported distributions, we do not depend on the system zstd library (version). Signed-off-by: Leon Woestenberg --- meta/recipes-devtools/cmake/cmake-native_3.15.3.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/cmake/cmake-native_3.15.3.bb b/meta/recipes-devtools/cmake/cmake-native_3.15.3.bb index b2952ee..e0ac3f8 100644 --- a/meta/recipes-devtools/cmake/cmake-native_3.15.3.bb +++ b/meta/recipes-devtools/cmake/cmake-native_3.15.3.bb @@ -21,6 +21,7 @@ CMAKE_EXTRACONF = "\ -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \ -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0 \ -DCMAKE_USE_SYSTEM_LIBRARY_LIBRHASH=0 \ +-DCMAKE_USE_SYSTEM_LIBRARY_ZSTD=0 \ -DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \ -DHAVE_SYS_ACL_H=0 \ " -- 2.7.4 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141429): https://lists.openembedded.org/g/openembedded-core/message/141429 Mute This Topic: https://lists.openembedded.org/mt/76165585/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] freetype: add pixmap to PACKAGECONFIG
Hello all, On Tue, Mar 3, 2020 at 6:42 PM Jacob Kroon wrote: > > On 3/1/20 12:47 AM, Matt Ranostay wrote: > > Add pixmap to PACKAGECONFIG defaults to allow consumers to > > render color emojis without distro changes. > > > > Signed-off-by: Matt Ranostay > > --- > > -PACKAGECONFIG ??= "zlib" > > +PACKAGECONFIG ??= "zlib pixmap" > > > Wouldn't it make sense to keep it off by default and let whoever needs it > enable it ? > /Jacob > I would agree, and would also vote for opt-in rather than opt-out for this use-case. Do we have a more generic stance on how we select the PACKAGECONFIG defaults? Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [thud][PATCH] systemd: RDEPENDS on util-linux-umount
Hi Adrian, On Thu, Mar 7, 2019 at 4:18 PM Adrian Bunk wrote: > > On Thu, Mar 07, 2019 at 03:56:33PM +0100, Leon Woestenberg wrote: > > On Thu, Mar 7, 2019 at 3:27 PM Adrian Bunk wrote: > > > > > > From: André Draszik > > > > > > It looks like there is an implicit dependency on util-linux' > > > umount - as otherwise when using busybox' umount we see a > > > long delay on shutdown / reboot. > > > > > > [YOCTO #13058] > > > > If systemd needs util-linux mount/umount in master it should also > depend on them in older releases (both master and thud had systemd 239 > at that point). > Agreed. I was just adding info to this e-mail thread. The "looks like there is an implicit dependency" text was a bit too vague for me. I'ld like to add the root cause that was found. The implicit dependency was for a specific option to umount to be supported. If we have the proper busybox in master, we no longer have a implicit dependency on util-linux-umount. (The reason for the util-linux-mount dependency was different, AFAIK.) Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [thud][PATCH] systemd: RDEPENDS on util-linux-umount
On Thu, Mar 7, 2019 at 3:27 PM Adrian Bunk wrote: > > From: André Draszik > > It looks like there is an implicit dependency on util-linux' > umount - as otherwise when using busybox' umount we see a > long delay on shutdown / reboot. > > [YOCTO #13058] > That bug number is wrong, seems only slighty related: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13058 Following the discussions, I think this had to do with older versions of busybox not ignoring the '-c' option that systemd passes to umount. https://github.com/systemd/systemd/issues/7786 So, systemd has a dependency on *either* util-linux-mount *or* a minimal version of busybox. Do we support minimal version dependencies in Yocto? Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wic creates ext4 images that read really slow in u-boot
Hello Mike, all, On Wed, Feb 20, 2019 at 11:42 AM Mike Looijmans wrote: > > On 19-02-19 21:45, Leon Woestenberg wrote: > > Hello all, > > > > On Tue, Feb 19, 2019 at 8:28 PM Andre McCurdy wrote: > >> On Tue, Feb 19, 2019 at 9:13 AM Leon Woestenberg > >> wrote: > >>> > >>> Hello Mike, > >>> > >>> sounds familiar. > >>> > >>> On Tue, 19 Feb 2019 at 17:55, Mike Looijmans > >>> wrote: > >>>> > >>>> Took me a while to figure out why my board took 90 seconds to boot > >>>> suddenly. > >>>> The issue turned out to be the ext4 partition created by wic. > >>> > >>> I suspect it's not WIC's fault. > >>>> > >>> I am aware of two fixes for U-Boot. I will look them up, and reply again > >>> to this thread. > > > > Google for these two commits. I cherry-picked the first one for my > > project and can confirm it brings back the desired performance. (Still > > assuming this is the identical cause as for TO/Mike.) > > > > commit 855b8e4f9f255415a7753819e392e4b5d984f35c > > Author: Matt Madison > > Date: Sat Aug 19 08:46:46 2017 -0700 > > > > ext4: cache extent blocks during file reads > > > > A simpler and less-efficient approach to solving > > the problem with extent index blocks than what > > was in fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5, > > but one that does not break write operations. > > > > Signed-off-by: Matt Madison > > I'll give it a try... > > You mentioned "two" commits? Yes the commit above, and *another* approach referred to and mentioned in the commit message (also with hash). The block cache feature may solve the problem in a more generic way (also caching things like directory lookups), whereas the ext4 extent patches are more specific to ext4 only. I found the ext4 fixes starting from here: https://github.com/madisongh/meta-tegra/issues/42 Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wic creates ext4 images that read really slow in u-boot
Hello all, On Tue, Feb 19, 2019 at 8:28 PM Andre McCurdy wrote: > On Tue, Feb 19, 2019 at 9:13 AM Leon Woestenberg wrote: >> >> Hello Mike, >> >> sounds familiar. >> >> On Tue, 19 Feb 2019 at 17:55, Mike Looijmans wrote: >>> >>> Took me a while to figure out why my board took 90 seconds to boot suddenly. >>> The issue turned out to be the ext4 partition created by wic. >> >> I suspect it's not WIC's fault. >>> >>> ZynqMP> load mmc 0:2 0x10 /lib/firmware/fpga.bin >>> 19311092 bytes read in 85529 ms (219.7 KiB/s) >>> >>> Now if I boot the board rename and copy that file onto itself, then it's >>> suddenly normal again when I reboot the board: >>> >>> ZynqMP> load mmc 0:2 0x1 >>> I'm not knowledgeable on ext4, so any ideas what's being passed onto the >>> image >>> creation tool that causes this? >> >> I suspect your version of U-Boot does not handle files spread across >> multiple filesystems (allocation) extends efficiently. >> >> Copying the file makes the copy being layed out in one extend probably. > > > If WIC is generating filesystem images from scratch there's no excuse for > files to be unnecessarily fragmented. > > Even if some of all of the boot time can be recovered by a patch to u-boot > that won't help systems which have already been deployed and don't have a way > to update the bootloader. > I am not sure if "fragmented" is the right term in terms of filesystem details. Filesystem allocation extents (not "extends" as I mistyped earlier) are different from heavy file fragmentation. However, I agree things can be made more optimal. So, with adding the above, there are *two* issues at play here: 1) Most/older versions of U-Boot not able to efficiently load files from ext4 filesystems, that cross multiple extents. I am aware of two fixes, see below. 2) WIC uses mkext4fs in such a way that files can cross multiple (allocation) extents. This is sub-optimal and know to cause issues with many U-Boot versions (deployed on existing systems in the field). The problems shows "randomly" with large files being deployed to the ext4 filesystem. We (OE/Yocto) may want to fix this. >> I am aware of two fixes for U-Boot. I will look them up, and reply again to >> this thread. Google for these two commits. I cherry-picked the first one for my project and can confirm it brings back the desired performance. (Still assuming this is the identical cause as for TO/Mike.) commit 855b8e4f9f255415a7753819e392e4b5d984f35c Author: Matt Madison Date: Sat Aug 19 08:46:46 2017 -0700 ext4: cache extent blocks during file reads A simpler and less-efficient approach to solving the problem with extent index blocks than what was in fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5, but one that does not break write operations. Signed-off-by: Matt Madison Regards, Leon. p.s. excuse the earlier HTML mail with signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wic creates ext4 images that read really slow in u-boot
Hello Mike, sounds familiar. On Tue, 19 Feb 2019 at 17:55, Mike Looijmans wrote: > Took me a while to figure out why my board took 90 seconds to boot > suddenly. > > The issue turned out to be the ext4 partition created by wic. I suspect it's not WIC's fault. > ZynqMP> load mmc 0:2 0x10 /lib/firmware/fpga.bin > 19311092 bytes read in 85529 ms (219.7 KiB/s) > > Now if I boot the board rename and copy that file onto itself, then it's > suddenly normal again when I reboot the board: > > ZynqMP> load mmc 0:2 0x1 > I'm not knowledgeable on ext4, so any ideas what's being passed onto the > image > creation tool that causes this? I suspect your version of U-Boot does not handle files spread across multiple filesystems (allocation) extends efficiently. Copying the file makes the copy being layed out in one extend probably. I am aware of two fixes for U-Boot. I will look them up, and reply again to this thread. Regards, Leon -- Leon Woestenberg l...@sidebranch.com T: +31 40 711 42 76 M: +31 6 472 30 372 Sidebranch Embedded Systems Eindhoven, The Netherlands http://www.sidebranch.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Always install initramfs-framework-base in case of linux-yocto & INITRAMFS_IMAGE_BUNDLE=1
On Tue, Jan 29, 2019 at 9:01 PM Alexey Brodkin wrote: > --->8-- > /dev/console is missing or not a character device! > Please ensure your rootfs is properly configured > --->8-- I thought /dev/console could also be created by the kernel itself onto a "temporary filesystem for device nodes" (DEVTMPFS). I am not sure, but here is a similar case: http://lists.busybox.net/pipermail/buildroot/2015-March/123309.html Is your (other) kernel configured with CONFIG_DEVTMPFS=y? Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: add devmem
On Thu, Jan 31, 2019 at 11:16 AM Philip Balister wrote: > > On 01/30/2019 09:09 PM, Scott Ellis wrote: > > Is the busybox devmem functionally different then the standalone devmem2 > > package? > > Replying again > > I've been told they are functionally different and to use devmem2. I > think the issue with the busybox version is that it does a readback when > writing, this can be bad for some hardware. > And the fact that the devmem2 tool is written with no fixed integer width. You have to understand that on a 64-bit system, reading a "word" from a 32-bit hardware peripheral (most are), you are touching two registers. case 'h': read_result = *((unsigned short *) virt_addr); break; case 'w': read_result = *((unsigned long *) virt_addr); break; I rewrote it once to use uint_t but I do not think there is a proper upstream repository / maintenance going on. Not sure about devmem in Busybox. Anyway, devmem being useful for development, I do not see why it should be in BusyBox by default. We are not shipping devmem2 and should not. We can have such reasoning for every tool out there. I rather would have a single switch to include tools like these. I disagree that devmem(2) should be included for purposes such as pin-muxing. Yes, I use it weekly for that during bring-up, but the released result should be in DTS or DTS overlays, or boot loader code in the end. Regards, -- Leon Woestenberg http://www.sidebranch.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: add devmem
Hi all, On Wed, Jan 30, 2019 at 11:32 PM Richard Purdie wrote: > > One reason I'm a little nervous of devmem in busybox is security attack > surface. > It is useful so I am torn but its worth keeping this in mind... > I agree with this reasoning. devmem(2) really is a development tool, and indeed I would leave it out of any defaults in Yocto. There are numerous attempts to minimize cruft, and in typical images devmem should not be used. For the people that need it, it is typically easier to add such tools to their image than it is to minimize their image. As for automated deployment, I would rather see that an imaginary PACKAGECONFIG[debug-tweaks] or such would include this busybox tool through configuration rather than have it opt-out. Just my two cents (and yes devmem is in my images but they are for development, not in releases). Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hi Marek, Alex, On Tue, Sep 18, 2018 at 1:19 PM Marek Vasut wrote: > On 09/18/2018 12:59 PM, Leon Woestenberg wrote: > > On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut wrote: > >> On 09/18/2018 12:22 PM, Leon Woestenberg wrote: > >>> > >>> There is no exception for INITRAMFS_IMAGE_BUNDLE in > >>> kernel-fitimage.bbclass. The initramfs will be packed inside the FIT, > >>> in addition of also being packed inside the kernel. > >> > >> So why would you use initramfs_image_bundle with fitImage when you can > >> pack the initrd into the fitImage instead ? > >> > > To be honest, I do not know that use-case anymore but it's a valid > > configuration that shouldn't give an unexpected outcome. > > True > > > We also found a use-case for non-compressed kernels in the FIT image; > > that was for very small delta-upgrades even when kernels are FIT > > packed. Currently kernel-fitimage.bbclass hard-selects a compressed > > kernel (such as zImage). > > Patches are welcome > Thanks for explaining the rationale behind the deploy stage, it confirms Alex's suspicion I was solving the problem at the wrong place. Alex, if you are still reading this: the answer is yes, please revert. Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hi Marek, On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut wrote: > On 09/18/2018 12:22 PM, Leon Woestenberg wrote: > > > > There is no exception for INITRAMFS_IMAGE_BUNDLE in > > kernel-fitimage.bbclass. The initramfs will be packed inside the FIT, > > in addition of also being packed inside the kernel. > > So why would you use initramfs_image_bundle with fitImage when you can > pack the initrd into the fitImage instead ? > To be honest, I do not know that use-case anymore but it's a valid configuration that shouldn't give an unexpected outcome. We also found a use-case for non-compressed kernels in the FIT image; that was for very small delta-upgrades even when kernels are FIT packed. Currently kernel-fitimage.bbclass hard-selects a compressed kernel (such as zImage). Regards, Leon/ -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hi Marek,
On Tue, Sep 18, 2018 at 12:12 PM Marek Vasut wrote:
>
> On 09/18/2018 12:01 PM, Leon Woestenberg wrote:
> > Hi Marek,
> Could you _please_ stop top-posting ?
Yes.
>
> > one of the issues I saw was that both kernel.bbclass and
> > kernel-fitImage.bbclass deployed the FIT image into the deploy/images/
> > subfolder.
> >
> > My fix was to make the kernel.bbclass ignore "fitImage" during
> > deployment. This is also the fix I saw from Xilinx.
>
> If I recall correctly, meta-xilinx had their own horribly hacked
> fitImage bbclass, are you sure it's not interfering here ?
>
Yes I am sure it's not.
>
> > (Another fix I have pending is that bundled initramfs images (i.e that
> > go inside the kernel binary) where also seperately packed inside the FIT
> > image.)
>
> Separate initrd is already supported.
There is no exception for INITRAMFS_IMAGE_BUNDLE in
kernel-fitimage.bbclass. The initramfs will be packed inside the FIT,
in addition of also being packed inside the kernel.
My local fix has this:
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index a4d7aca..17addab 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -475,7 +475,9 @@ addtask assemble_fitimage before do_install after do_compile
do_assemble_fitimage_initramfs() {
if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
- test -n "${INITRAMFS_IMAGE}" ; then
+ test -n "${INITRAMFS_IMAGE}" && \
+ test ! -n "${INITRAMFS_IMAGE_BUNDLE}"; then
+
cd ${B}
fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
fitImage-${INITRAMFS_IMAGE} 1
fi
@@ -483,6 +485,18 @@ do_assemble_fitimage_initramfs() {
addtask assemble_fitimage_initramfs before do_deploy after do_install
+do_assemble_fitimage_bundled_initramfs() {
+ if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
+ test -n "${INITRAMFS_IMAGE}" && \
+ test -n "${INITRAMFS_IMAGE_BUNDLE}"; then
+
+ cd ${B}
+ fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
fitImage-${INITRAMFS_IMAGE}
+ fi
+}
+
+addtask assemble_fitimage_bundled_initramfs before do_deploy after
do_bundle_initramfs
+
Regards,
Leon.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hello Marek, On Tue, Sep 18, 2018 at 12:01 PM Leon Woestenberg wrote: > On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut wrote: >> On 09/18/2018 11:40 AM, Leon Woestenberg wrote: >> What bug is it that you're seeing ? >> >> > Whilst cleaning things up, my understanding was that >> > kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the >> > fitImages, along with the .its file etc. >> > Maybe I was mistaken. >> >> That's the case, yes. Am I mistaken or is my assumption correct that kernel-fitimage.bbclass should deploy the fitImages? Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hi Marek, one of the issues I saw was that both kernel.bbclass and kernel-fitImage.bbclass deployed the FIT image into the deploy/images/ subfolder. My fix was to make the kernel.bbclass ignore "fitImage" during deployment. This is also the fix I saw from Xilinx. (Another fix I have pending is that bundled initramfs images (i.e that go inside the kernel binary) where also seperately packed inside the FIT image.) In general, I am trying to fix all bugs and issues that match "kernel-fitimage.bbclass" on the mailing list. Regards, Leon. On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut wrote: > On 09/18/2018 11:40 AM, Leon Woestenberg wrote: > > Hi Alex, > > Hi, > > > Adding Marek Vasut, original author of kernel-fitimage.bbclass. > > > >> I guess the reason that the deployment happens in kernel.bbclass is so > >> you only have all the symlinking logic in one place > > > > The deployment happens in both kernel.bbclass and > > kernel-fitimage.bbclass. That was exactly one of the bugs I wanted to > > solve. I am not sure what the intention was, though. > > > > Marek: can you comment of the exact purpose of the deploy task in > > kernel-fitimage.bbclass? > > Which class should deploy the FIT images themselves? > > It seems to have to do with deploying of the ITS files and the symlinks > for then . > > It's hard to make any sense from the discussion below due to the > constant top-posting and mixing of email history, so I'll just not do > that, sorry. > > What bug is it that you're seeing ? > > > Whilst cleaning things up, my understanding was that > > kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the > > fitImages, along with the .its file etc. > > Maybe I was mistaken. > > That's the case, yes. > > > I have several other fixed piled up; for example initramfs's supposed to > > get bundled inside the kernel get also packed into the FIT; this takes > > double the amount of space in the FIT image... > > > > Regards, > > > > Leon. > > > > > > > > > > On Tue, Sep 18, 2018 at 8:10 AM Alex Kiernan > <mailto:alex.kier...@gmail.com>> wrote: > > > > Thanks Leon > > > > I guess the reason that the deployment happens in kernel.bbclass is > so > > you only have all the symlinking logic in one place. > > > > Are in agreement that this change should be reverted and the > > "fitImage" deployed here: > > > > > http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495 > > > > is the one which we should remove? > > On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg > > mailto:l...@sidebranch.com>> wrote: > > > > > > Hi Alex, > > > > > > I expected it to be kernel-fitimage.bbclass’s responsibility to > > deploy the fitImage. > > > > > > Regards, Leon > > > > > > > > > > > > > > > On 16 Sep 2018, at 16:22, Alex Kiernan > <mailto:alex.kier...@gmail.com>> wrote: > > > > > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan > > mailto:alex.kier...@gmail.com>> wrote: > > > > > > > > > Hi Leon > > > > > > > > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg > > mailto:l...@sidebranch.com>> wrote: > > > > > > > > > Hi Alex, > > > > > > > > > On 15 Sep 2018, at 19:45, Alex Kiernan > <mailto:alex.kier...@gmail.com>> wrote: > > > > > > > > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg > > mailto:l...@sidebranch.com>> wrote: > > > > > > > > > kernel-fitimage.bbclass replaces an occurance of "fitImage" in > > > > > > KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for > the > > > > > > architecture (such as zImage). The kernel-fitimage.bbclass packs > that > > > > > > image as sub-image in a flattened image tree image (fitImage) and > > > > > > deploys this fitImage along with the image tree source file (.its). > > > > > > > > > kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which > thus > > > > > > also contains "fitImage", which kernel.bbclass will al
Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hi Alex, Adding Marek Vasut, original author of kernel-fitimage.bbclass. > I guess the reason that the deployment happens in kernel.bbclass is so > you only have all the symlinking logic in one place The deployment happens in both kernel.bbclass and kernel-fitimage.bbclass. That was exactly one of the bugs I wanted to solve. I am not sure what the intention was, though. Marek: can you comment of the exact purpose of the deploy task in kernel-fitimage.bbclass? Which class should deploy the FIT images themselves? Whilst cleaning things up, my understanding was that kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the fitImages, along with the .its file etc. Maybe I was mistaken. I have several other fixed piled up; for example initramfs's supposed to get bundled inside the kernel get also packed into the FIT; this takes double the amount of space in the FIT image... Regards, Leon. On Tue, Sep 18, 2018 at 8:10 AM Alex Kiernan wrote: > Thanks Leon > > I guess the reason that the deployment happens in kernel.bbclass is so > you only have all the symlinking logic in one place. > > Are in agreement that this change should be reverted and the > "fitImage" deployed here: > > > http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495 > > is the one which we should remove? > On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg > wrote: > > > > Hi Alex, > > > > I expected it to be kernel-fitimage.bbclass’s responsibility to deploy > the fitImage. > > > > Regards, Leon > > > > > > > > > > On 16 Sep 2018, at 16:22, Alex Kiernan wrote: > > > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan > wrote: > > > > > > Hi Leon > > > > > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg > wrote: > > > > > > Hi Alex, > > > > > > On 15 Sep 2018, at 19:45, Alex Kiernan wrote: > > > > > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg > wrote: > > > > > > kernel-fitimage.bbclass replaces an occurance of "fitImage" in > > > > KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the > > > > architecture (such as zImage). The kernel-fitimage.bbclass packs that > > > > image as sub-image in a flattened image tree image (fitImage) and > > > > deploys this fitImage along with the image tree source file (.its). > > > > > > kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus > > > > also contains "fitImage", which kernel.bbclass will also deploy > > > > redundantly with different naming. > > > > > > The result is a dual deployment with slightly different naming, > > > > each with a set of symlinks. > > > > > > The solution chosen is to have fitImage deployment be handled by > > > > kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage > > > > types during deployment. > > > > > > Signed-off-by: Leon Woestenberg > > > > > > This looks completely plausible, but the two "FIT" images that are > > > > installed aren't identical... after this I end up with no FIT image > > > > and only a bare image in the deploy dir. > > > > > > What was in your KERNEL_IMAGETYPES? Did it at least contain “fitImage”?? > > > > > > > > Yes, in fact only fitImage (and no initramfs). > > > > > > Digging into it, the logic between the two classes is a bit odd... in > > > > the case of a non initramfs build, the fitImage is actually installed > > > > here. > > > > > > If ‘here’ means kernel-fitimage, then I’ld say ALL versions of a FIT > image containing AT LEAST a Linux kernel are installed by kernel-fitimage. > > > > > > The one that's installed in kernel-fitimage is the bare > > > > linux.bin, but named fitImage-... > > > > > > which is totally broken. If you want the bare kernel binary (which > naming depends on architecture, so it should NOT be hard-coded to linux.bin > anyway), you would need to specify that type *also* in KERNEL_IMAGETYPES, > next to “fitImage”. > > > > > > Totally agree... > > > > > > > > I'll send a patch reverting this and removing the other one as I'd > > > > agree that it appears to have no purpose (and if you did want it, I > > > > guess you could list it in KERNEL_IMAGETYPES). > > > > > > I’m sorry I cannot follow what this and the other one is, and it. Let’s > first
Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hi Alex,
I expected it to be kernel-fitimage.bbclass’s responsibility to deploy the
fitImage.
Regards, Leon
> On 16 Sep 2018, at 16:22, Alex Kiernan wrote:
>
>> On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan wrote:
>>
>> Hi Leon
>>
>>> On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg
>>> wrote:
>>>
>>> Hi Alex,
>>>
>>>>> On 15 Sep 2018, at 19:45, Alex Kiernan wrote:
>>>>>
>>>>> On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg
>>>>> wrote:
>>>>>
>>>>> kernel-fitimage.bbclass replaces an occurance of "fitImage" in
>>>>> KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
>>>>> architecture (such as zImage). The kernel-fitimage.bbclass packs that
>>>>> image as sub-image in a flattened image tree image (fitImage) and
>>>>> deploys this fitImage along with the image tree source file (.its).
>>>>>
>>>>> kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
>>>>> also contains "fitImage", which kernel.bbclass will also deploy
>>>>> redundantly with different naming.
>>>>>
>>>>> The result is a dual deployment with slightly different naming,
>>>>> each with a set of symlinks.
>>>>>
>>>>> The solution chosen is to have fitImage deployment be handled by
>>>>> kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
>>>>> types during deployment.
>>>>>
>>>>> Signed-off-by: Leon Woestenberg
>>>>
>>>> This looks completely plausible, but the two "FIT" images that are
>>>> installed aren't identical... after this I end up with no FIT image
>>>> and only a bare image in the deploy dir.
>>>
>>> What was in your KERNEL_IMAGETYPES? Did it at least contain “fitImage”??
>>>
>>
>> Yes, in fact only fitImage (and no initramfs).
>>
>>>> Digging into it, the logic between the two classes is a bit odd... in
>>>> the case of a non initramfs build, the fitImage is actually installed
>>>> here.
>>>
>>> If ‘here’ means kernel-fitimage, then I’ld say ALL versions of a FIT image
>>> containing AT LEAST a Linux kernel are installed by kernel-fitimage.
>>>
>>>> The one that's installed in kernel-fitimage is the bare
>>>> linux.bin, but named fitImage-...
>>>
>>> which is totally broken. If you want the bare kernel binary (which naming
>>> depends on architecture, so it should NOT be hard-coded to linux.bin
>>> anyway), you would need to specify that type *also* in KERNEL_IMAGETYPES,
>>> next to “fitImage”.
>>
>> Totally agree...
>>
>>>>
>>>> I'll send a patch reverting this and removing the other one as I'd
>>>> agree that it appears to have no purpose (and if you did want it, I
>>>> guess you could list it in KERNEL_IMAGETYPES).
>>>
>>> I’m sorry I cannot follow what this and the other one is, and it. Let’s
>>> first understand all cases correctly.
>>>
>>
>> Sorry I've not described it well... the code in
>> kernel-fitimage.bbclass that inserts the kernel into the its happens
>> here
>> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n371
>>
>> fitimage_emit_section_kernel ${1} "${kernelcount}" linux.bin "${linux_comp}"
>>
>> inside fitimage_emit_section_kernel we create a kernel section which
>> has `data = /incbin/("${3}");` so linux.bin is our bare image.
>>
>> Then we have the installation of fitImage-linux-bin that happens here
>> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
>>
>> echo "Copying linux.bin file..."
>> install -m 0644 ${B}/linux.bin
>> ${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_NAME}.bin
>> ln -snf fitImage-linux.bin-${KERNEL_FIT_NAME}.bin
>> ${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_LINK_NAME}
>>
>> i.e. the bare linux.bin file which we used to pack into the FIT image,
>> not a fitImage.
>>
>> The output FIT image from kernel-fitimage.bbclass is created here
>> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n450
>>
>> uboot-mkimage \
>> ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"'
Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hi Alex,
> On 15 Sep 2018, at 19:45, Alex Kiernan wrote:
>
>> On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg
>> wrote:
>>
>> kernel-fitimage.bbclass replaces an occurance of "fitImage" in
>> KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
>> architecture (such as zImage). The kernel-fitimage.bbclass packs that
>> image as sub-image in a flattened image tree image (fitImage) and
>> deploys this fitImage along with the image tree source file (.its).
>>
>> kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
>> also contains "fitImage", which kernel.bbclass will also deploy
>> redundantly with different naming.
>>
>> The result is a dual deployment with slightly different naming,
>> each with a set of symlinks.
>>
>> The solution chosen is to have fitImage deployment be handled by
>> kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
>> types during deployment.
>>
>> Signed-off-by: Leon Woestenberg
>
> This looks completely plausible, but the two "FIT" images that are
> installed aren't identical... after this I end up with no FIT image
> and only a bare image in the deploy dir.
What was in your KERNEL_IMAGETYPES? Did it at least contain “fitImage”??
> Digging into it, the logic between the two classes is a bit odd... in
> the case of a non initramfs build, the fitImage is actually installed
> here.
If ‘here’ means kernel-fitimage, then I’ld say ALL versions of a FIT image
containing AT LEAST a Linux kernel are installed by kernel-fitimage.
> The one that's installed in kernel-fitimage is the bare
> linux.bin, but named fitImage-...
which is totally broken. If you want the bare kernel binary (which naming
depends on architecture, so it should NOT be hard-coded to linux.bin anyway),
you would need to specify that type *also* in KERNEL_IMAGETYPES, next to
“fitImage”.
>
> I'll send a patch reverting this and removing the other one as I'd
> agree that it appears to have no purpose (and if you did want it, I
> guess you could list it in KERNEL_IMAGETYPES).
I’m sorry I cannot follow what this and the other one is, and it. Let’s first
understand all cases correctly.
Regards, Leon
>
>> ---
>> meta/classes/kernel.bbclass | 18 --
>> 1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index b57832c..1f69091 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -669,8 +669,11 @@ kernel_do_deploy() {
>>fi
>>
>>for imageType in ${KERNEL_IMAGETYPES} ; do
>> - base_name=${imageType}-${KERNEL_IMAGE_NAME}
>> - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
>> $deployDir/${base_name}.bin
>> + # kernel-fitimage class deploys fitImages, skip here
>> + if [ "$imageType" != "fitImage" ]; then
>> + base_name=${imageType}-${KERNEL_IMAGE_NAME}
>> + install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
>> $deployDir/${base_name}.bin
>> + fi
>>done
>>if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e
>> '^CONFIG_MODULES=y$' .config); then
>>mkdir -p ${D}/lib
>> @@ -687,10 +690,13 @@ kernel_do_deploy() {
>>
>>if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1
>> ]; then
>>for imageType in ${KERNEL_IMAGETYPES} ; do
>> - initramfs_base_name=${imageType}-${INITRAMFS_NAME}
>> -
>> initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
>> - install -m 0644
>> ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs
>> $deployDir/${initramfs_base_name}.bin
>> - ln -sf ${initramfs_base_name}.bin
>> $deployDir/${initramfs_symlink_name}.bin
>> + # kernel-fitimage class deploys fitImages, skip here
>> + if [ "$imageType" != "fitImage" ]; then
>> +
>> initramfs_base_name=${imageType}-${INITRAMFS_NAME}
>> +
>> initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
>> + install -m 0644
>> ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs
>> $deployDir/${initramfs_base_name}.bin
>> + ln -sf ${initramfs
[OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
kernel-fitimage.bbclass replaces an occurance of "fitImage" in
KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
architecture (such as zImage). The kernel-fitimage.bbclass packs that
image as sub-image in a flattened image tree image (fitImage) and
deploys this fitImage along with the image tree source file (.its).
kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
also contains "fitImage", which kernel.bbclass will also deploy
redundantly with different naming.
The result is a dual deployment with slightly different naming,
each with a set of symlinks.
The solution chosen is to have fitImage deployment be handled by
kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
types during deployment.
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel.bbclass | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b57832c..1f69091 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -669,8 +669,11 @@ kernel_do_deploy() {
fi
for imageType in ${KERNEL_IMAGETYPES} ; do
- base_name=${imageType}-${KERNEL_IMAGE_NAME}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
$deployDir/${base_name}.bin
+ # kernel-fitimage class deploys fitImages, skip here
+ if [ "$imageType" != "fitImage" ]; then
+ base_name=${imageType}-${KERNEL_IMAGE_NAME}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
$deployDir/${base_name}.bin
+ fi
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e
'^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}/lib
@@ -687,10 +690,13 @@ kernel_do_deploy() {
if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ];
then
for imageType in ${KERNEL_IMAGETYPES} ; do
- initramfs_base_name=${imageType}-${INITRAMFS_NAME}
-
initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
- install -m 0644
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs
$deployDir/${initramfs_base_name}.bin
- ln -sf ${initramfs_base_name}.bin
$deployDir/${initramfs_symlink_name}.bin
+ # kernel-fitimage class deploys fitImages, skip here
+ if [ "$imageType" != "fitImage" ]; then
+
initramfs_base_name=${imageType}-${INITRAMFS_NAME}
+
initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
+ install -m 0644
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs
$deployDir/${initramfs_base_name}.bin
+ ln -sf ${initramfs_base_name}.bin
$deployDir/${initramfs_symlink_name}.bin
+ fi
done
fi
}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [openembedded-core][PATCH] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Hi Andre,
thanks for reviewing.
On Sat, Sep 8, 2018 at 12:10 AM, Andre McCurdy wrote:
> On Thu, Sep 6, 2018 at 2:06 PM, Leon Woestenberg wrote:
>> + if [ "$imageType" != "fitImage" ]; then
>> + for imageType in ${KERNEL_IMAGETYPES} ; do
>
> This looks odd. You test imageType before the for loop which assigns a
> value to it?
>
Good catch. I will create new patch that turns the lines around, i.e.
test within the for loop
(The above acted on the last imageType of the previous for loop, which
had the correct order.)
>> +
>> initramfs_base_name=${imageType}-${INITRAMFS_NAME}
>> +
>> initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
>> + install -m 0644
>> ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs
>> $deployDir/${initramfs_base_name}.bin
>> + ln -sf ${initramfs_base_name}.bin
>> $deployDir/${initramfs_symlink_name}.bin
>> + done
>> + fi
>> fi
>> }
>> do_deploy[cleandirs] = "${DEPLOYDIR}"
Thanks,
Leon.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [openembedded-core][PATCH] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
kernel-fitimage.bbclass replaces an occurance of "fitImage" in
KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
architecture (such as zImage). The kernel-fitimage.bbclass packs that
image as sub-image in a flattened image tree image (fitImage) and
deploys this fitImage along with the image tree source file (.its).
kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
also contains "fitImage", which kernel.bbclass will also deploy
redundantly with different naming.
The result is a dual deployment with slightly different naming,
each with a set of symlinks.
The solution chosen is to have fitImage deployment be handled by
kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
types during deployment.
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel.bbclass | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b57832c..5d168e8 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -669,8 +669,11 @@ kernel_do_deploy() {
fi
for imageType in ${KERNEL_IMAGETYPES} ; do
- base_name=${imageType}-${KERNEL_IMAGE_NAME}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
$deployDir/${base_name}.bin
+ for imageType in ${KERNEL_IMAGETYPES} ; do
+ if [ "$imageType" != "fitImage" ]; then
+ base_name=${imageType}-${KERNEL_IMAGE_NAME}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
$deployDir/${base_name}.bin
+ fi
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e
'^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}/lib
@@ -686,12 +689,14 @@ kernel_do_deploy() {
done
if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ];
then
- for imageType in ${KERNEL_IMAGETYPES} ; do
- initramfs_base_name=${imageType}-${INITRAMFS_NAME}
-
initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
- install -m 0644
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs
$deployDir/${initramfs_base_name}.bin
- ln -sf ${initramfs_base_name}.bin
$deployDir/${initramfs_symlink_name}.bin
- done
+ if [ "$imageType" != "fitImage" ]; then
+ for imageType in ${KERNEL_IMAGETYPES} ; do
+
initramfs_base_name=${imageType}-${INITRAMFS_NAME}
+
initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
+ install -m 0644
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs
$deployDir/${initramfs_base_name}.bin
+ ln -sf ${initramfs_base_name}.bin
$deployDir/${initramfs_symlink_name}.bin
+ done
+ fi
fi
}
do_deploy[cleandirs] = "${DEPLOYDIR}"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [openembedded-core][PATCH v2 2/2] kernel-fitimage.bbclass: Create a "fitImage" symlink to resulting FIT image.
From: Walter Goossens
If an initramfs was used, the fitImage link will point to the FIT containing
the initramfs. Otherwise it will link to the FIT without initramfs.
This ensures the user can depend on "fitImage" to point to the desired
FIT image.
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel-fitimage.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 8bda644..17addab 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -519,5 +519,10 @@ kernel_do_deploy_append() {
install -m 0644
${B}/arch/${ARCH}/boot/fitImage-${INITRAMFS_IMAGE}
${DEPLOYDIR}/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}.bin
ln -snf
fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}.bin
${DEPLOYDIR}/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_LINK_NAME}
fi
+ if [ -n "${INITRAMFS_IMAGE}" ]; then
+ ln -sf
fitImage-its-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}.its fitImage
+ else
+ ln -sf fitImage-linux.bin-${KERNEL_FIT_NAME}.bin
fitImage
+ fi
fi
}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [openembedded-core][PATCH v2 1/2] kernel-fitimage.bbclass: Handle bundled initramfs case correctly.
From: Walter Goossens
If INITRAMFS_IMAGE was set, but also INITRAMFS_BUNDLE = 1, then
the kernel image already has the initramfs bundled inside. In that
case do not pack the initramfs inside the FIT (again).
(The fitImage name does keep the suffix INITRAMFS_IMAGE for all
initramfs cases.)
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel-fitimage.bbclass | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 88d8022..8bda644 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -475,7 +475,9 @@ addtask assemble_fitimage before do_install after do_compile
do_assemble_fitimage_initramfs() {
if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
- test -n "${INITRAMFS_IMAGE}" ; then
+ test -n "${INITRAMFS_IMAGE}" && \
+ test ! -n "${INITRAMFS_IMAGE_BUNDLE}"; then
+
cd ${B}
fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
fitImage-${INITRAMFS_IMAGE} 1
fi
@@ -483,6 +485,18 @@ do_assemble_fitimage_initramfs() {
addtask assemble_fitimage_initramfs before do_deploy after do_install
+do_assemble_fitimage_bundled_initramfs() {
+ if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
+ test -n "${INITRAMFS_IMAGE}" && \
+ test -n "${INITRAMFS_IMAGE_BUNDLE}"; then
+
+ cd ${B}
+ fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
fitImage-${INITRAMFS_IMAGE}
+ fi
+}
+
+addtask assemble_fitimage_bundled_initramfs before do_deploy after
do_bundle_initramfs
+
kernel_do_deploy[vardepsexclude] = "DATETIME"
kernel_do_deploy_append() {
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [openembedded-core][PATCH] kernel-fitimage.bbclass: Create a "fitImage" symlink to resulting FIT image.
From: Walter Goossens
If an initramfs was used, the fitImage link will point to the FIT containing
the initramfs. Otherwise it will link to the FIT without initramfs.
This ensures the user can depend on "fitImage" to point to the desired
FIT image.
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel-fitimage.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 6d02d74..b672579 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -496,6 +496,9 @@ kernel_do_deploy_append() {
if [ -n "${INITRAMFS_IMAGE}" ]; then
ln -sf ${its_initramfs_base_name}.its
${its_initramfs_symlink_name}.its
ln -sf ${fit_initramfs_base_name}.bin
${fit_initramfs_symlink_name}.bin
+ ln -sf ${fit_initramfs_base_name}.bin fitImage
+ else
+ ln -sf ${linux_bin_base_name}.bin fitImage
fi
fi
}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [openembedded-core][PATCH] kernel-fitimage.bbclass: Handle bundled initramfs case correctly.
From: Walter Goossens
If INITRAMFS_IMAGE was set, but also INITRAMFS_BUNDLE = 1, then
the kernel image already has the initramfs bundled inside. In that
case do not pack the initramfs inside the FIT (again).
(The fitImage name does keep the suffix INITRAMFS_IMAGE for all
initramfs cases.)
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel-fitimage.bbclass | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 16499c8..6d02d74 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -443,7 +443,9 @@ addtask assemble_fitimage before do_install after do_compile
do_assemble_fitimage_initramfs() {
if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
- test -n "${INITRAMFS_IMAGE}" ; then
+ test -n "${INITRAMFS_IMAGE}" && \
+ test ! -n "${INITRAMFS_IMAGE_BUNDLE}"; then
+
cd ${B}
fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
fitImage-${INITRAMFS_IMAGE} 1
fi
@@ -451,6 +453,18 @@ do_assemble_fitimage_initramfs() {
addtask assemble_fitimage_initramfs before do_deploy after do_install
+do_assemble_fitimage_bundled_initramfs() {
+ if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
+ test -n "${INITRAMFS_IMAGE}" && \
+ test -n "${INITRAMFS_IMAGE_BUNDLE}"; then
+
+ cd ${B}
+ fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
fitImage-${INITRAMFS_IMAGE}
+ fi
+}
+
+addtask assemble_fitimage_bundled_initramfs before do_deploy after
do_bundle_initramfs
+
kernel_do_deploy[vardepsexclude] = "DATETIME"
kernel_do_deploy_append() {
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [openembedded-core][PATCH] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
kernel-fitimage.bbclass replaces an occurance of "fitImage" in
KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
architecture (such as zImage). The kernel-fitimage.bbclass packs that
image as sub-image in a flattened image tree image (fitImage) and
deploys this fitImage along with the image tree source file (.its).
kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
also contains "fitImage", which kernel.bbclass will also deploy
redundantly with different naming.
The result is a dual deployment with slightly different naming,
each with a set of symlinks.
The solution chosen is to have fitImage deployment be handled by
kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
types during deployment.
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel.bbclass | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b341733..fd43ecd 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -675,8 +675,10 @@ kernel_do_deploy() {
fi
for type in ${KERNEL_IMAGETYPES} ; do
- base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}
$deployDir/${base_name}.bin
+ if [ "$type" != "fitImage" ]; then
+ base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}
$deployDir/${base_name}.bin
+ fi
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e
'^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}/lib
@@ -685,21 +687,25 @@ kernel_do_deploy() {
fi
for type in ${KERNEL_IMAGETYPES} ; do
- base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
- symlink_name=${type}-${KERNEL_IMAGE_SYMLINK_NAME}
- ln -sf ${base_name}.bin $deployDir/${symlink_name}.bin
- ln -sf ${base_name}.bin $deployDir/${type}
+ if [ "$type" != "fitImage" ]; then
+ base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
+ symlink_name=${type}-${KERNEL_IMAGE_SYMLINK_NAME}
+ ln -sf ${base_name}.bin $deployDir/${symlink_name}.bin
+ ln -sf ${base_name}.bin $deployDir/${type}
+ fi
done
cd ${B}
# Update deploy directory
for type in ${KERNEL_IMAGETYPES} ; do
- if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
- echo "Copying deploy ${type} kernel-initramfs image and
setting up links..."
- initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}
- initramfs_symlink_name=${type}-initramfs-${MACHINE}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.initramfs
$deployDir/${initramfs_base_name}.bin
- ln -sf ${initramfs_base_name}.bin
$deployDir/${initramfs_symlink_name}.bin
+ if [ "$type" != "fitImage" ]; then
+ if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
+ echo "Copying deploy ${type} kernel-initramfs
image and setting up links..."
+
initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}
+
initramfs_symlink_name=${type}-initramfs-${MACHINE}
+ install -m 0644
${KERNEL_OUTPUT_DIR}/${type}.initramfs $deployDir/${initramfs_base_name}.bin
+ ln -sf ${initramfs_base_name}.bin
$deployDir/${initramfs_symlink_name}.bin
+ fi
fi
done
}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [openembedded-core][PATCH] kernel-fitimage.bbclass: Wrong binary was deployed for kernel-only FIT image.
The kernel-fitimage.bbclass always outputs one FIT image without initramfs.
This variant did deploy the kernel image itself rather than the FIT image.
(The FIT with initramfs was correctly deployed.)
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel-fitimage.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 50a91e1..16499c8 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -463,7 +463,7 @@ kernel_do_deploy_append() {
install -m 0644 fit-image.its ${DEPLOYDIR}/${its_base_name}.its
linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
- install -m 0644 linux.bin
${DEPLOYDIR}/${linux_bin_base_name}.bin
+ install -m 0644 arch/${ARCH}/boot/fitImage
${DEPLOYDIR}/${linux_bin_base_name}.bin
if [ -n "${INITRAMFS_IMAGE}" ]; then
echo "Copying fit-image-${INITRAMFS_IMAGE}.its source
file..."
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] meta-freescale general mailing list
Hello Otavio, all, On Sun, Nov 18, 2012 at 9:00 PM, Otavio Salvador wrote: > > On Thu, Nov 15, 2012 at 3:02 PM, Otavio Salvador > wrote: > >> >> On Thu, Nov 15, 2012 at 1:36 PM, Philip Balister wrote: >> >>> On 11/14/2012 11:58 AM, McClintock Matthew-B29882 wrote: >>> Do we have a standard for yocto/OE list names on gmane? >>> >> I tried to add it but it did not work. >> > It is now done. > > You can see it at > http://blog.gmane.org/gmane.linux.embedded.yocto.meta-freescale > Regards, > Otavio > Thanks. There is a small typo in the gmane: Leyers vs Layers. -Freescale OpenEmbedded/Yocto Leyers discussion list () +Freescale OpenEmbedded/Yocto Layers discussion list () Regards, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 06/28] kernel.bbclass: fix external module building
Hello Saul, On Wed, Jul 25, 2012 at 9:19 AM, Saul Wold wrote: > + # Necessary for building modules like compat-wireless. > + cp include/generated/bounds.h $kerneldir/include/generated/bounds.h > + > Thanks, can we get this merged into the Denzil branch as well? In general, how are commits selected for release branches? Regards, Leon 'likewise' Woestenberg ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] bitbake parsing of IMAGE_INSTALL += # tslib mtd-utils" extremely user unfriendly.
Hello Richard, On Sun, Feb 26, 2012 at 2:06 PM, Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Mon, 2012-02-20 at 23:00 +0100, Leon Woestenberg wrote: > > bitbake can really braindump on us when we insert typo's. The result > > of bitbake 1.14 parsing this one wasn't pleasant: > > > > IMAGE_INSTALL += # tslib mtd-utils" > > > > (Yes, it's a typo. No, I wouldn't expect bitbake to give me that much > > output :) ) > > I agree we need to fix that. I've proposed a patch to bitbake which > would allow detection and a better error message for something like this > by enforcing quoting of variables. It is a major change in bitbake's > behaviour though so I'm taking feedback on whether we should make the > change. > If we focus on our user interface view, that would mean this will no longer work: SOME_BINARY_VARIABLE = 1 but that might be a better compromise than what we currently have. Regards, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] bitbake parsing of IMAGE_INSTALL += # tslib mtd-utils" extremely user unfriendly.
Hello all, bitbake can really braindump on us when we insert typo's. The result of bitbake 1.14 parsing this one wasn't pleasant: IMAGE_INSTALL += # tslib mtd-utils" (Yes, it's a typo. No, I wouldn't expect bitbake to give me that much output :) ) Regards, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] armhf support in OpenEmbedded?
Hello, On Mon, Feb 6, 2012 at 10:22 PM, Mark Hatle wrote: > On 2/6/12 3:17 PM, Koen Kooi wrote: > >> >> Op 6 feb. 2012, om 22:01 heeft Leon Woestenberg het volgende geschreven: >> >> do we already have support for the ARM "armhf" ABI in OpenEmbedded? (A >>> quick search on the ML didn't get me hits). >>> Basically,"armhf" is built with -mfloat-abi=hard, and tuned for armv7-a >>> CPUs. >>> >> >> Yes, we've had it for ages in OE-classic and Marks tune overhaul made it >> easy to use in OE-core as well. Also note that armhf has practically no >> adavantage over softfp in real world applications. The only things getting >> a decent speedup in proper benchmarks was povray. >> > > I strongly discourage people from using it. If you don't care about ABI > compatibility it might be a few cycles faster.. but it does limit your > ability to draw from existing EABI software. (Be it commercial or open > source.) > Can someone please lift that large rock I have been under for ages? Thanks! Leon /me climbing back into the OE trenches ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] armhf support in OpenEmbedded?
Hello, do we already have support for the ARM "armhf" ABI in OpenEmbedded? (A quick search on the ML didn't get me hits). Basically,"armhf" is built with -mfloat-abi=hard, and tuned for armv7-a CPUs. http://wiki.debian.org/ArmHardFloatPort http://www.powerdeveloper.org/forums/viewtopic.php?p=13645#13645 Regards, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] meta-openembedded: avahi-ui-0.6.30: 'Fetcher failure for URL: 'file://fix_for_automake_1.11.2.patch'
Hello, On Wed, Jan 4, 2012 at 11:38 PM, Khem Raj wrote: > On Wed, Jan 4, 2012 at 1:26 PM, Leon Woestenberg > wrote: > > > > I cannot spot the error, other than that the patch exists in oe-core, > but it > > required from meta-oe. That should work, shouldn't it? > > I dont think so unless you have the oe-core locations in FILESPATH > > OK, then avahi-ui in meta-oe is broken. This is unmodified oe-core + meta-oe, so I think this fails to build for everyone. I suggest to remove avahi-ui from meta-oe completely. Regards, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] meta-openembedded: avahi-ui-0.6.30: 'Fetcher failure for URL: 'file://fix_for_automake_1.11.2.patch'
Hello, avahi-ui-0.6.30 recipe appears in both openembedded-core and meta-openembedded, is this intended and if so why? I do not see it doing things differently. The first one seems better maintained, the one in meta-openembedded has MD5/SHA sums. With todays GIT pull of both layers (meta-oe on top of oe-core), I run into this problem: - NOTE: package avahi-ui-0.6.30-r0: task do_fetch: Started ERROR: Function 'Fetcher failure for URL: 'file://fix_for_automake_1.11.2.patch'. Unable to fetch URL file://fix_for_automake_1.11.2.patch from any source.' failed ERROR: Logfile of failure stored in: /home/leon/sandbox/sidebranch/openembedded/imx53qsb/openembedded/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/avahi-ui-0.6.30-r0/temp/log.do_fetch.27184 Log data follows: | DEBUG: Trying PREMIRRORS | DEBUG: Trying Upstream | ERROR: Function 'Fetcher failure for URL: 'file://fix_for_automake_1.11.2.patch'. Unable to fetch URL file://fix_for_automake_1.11.2.patch from any source.' failed ERROR: Task 2836 (/home/leon/sandbox/sidebranch/openembedded/imx53qsb/openembedded/meta-openembedded.git/meta-oe/recipes-connectivity/avahi/ avahi-ui_0.6.30.bb, do_fetch) failed with exit code '1' meld ../openembedded-core.git/meta/recipes-connectivity/avahi/ avahi-ui_0.6.30.bb../meta-openembedded.git/meta-oe/recipes-connectivity/avahi/ avahi-ui_0.6.30.bb - I cannot spot the error, other than that the patch exists in oe-core, but it required from meta-oe. That should work, shouldn't it? Regards, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] after modifying source code in work/, how to rebuild package?
Lauri en Luo, On Fri, Dec 16, 2011 at 9:13 AM, Lauri Hintsala wrote: > Sorry, this workflow will clean all your changes. How about that: > > bitbake projectname -c compile -f > bitbake projectname > > Thank you. This works. Regards Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] after modifying source code in work/, how to rebuild package?
Hello all, after modifying source code in the work directory, what is the set of commands to rebuild the package (from the compile stage and further)? Under classic OpenEmbedded, I removed the compile, install, package stages stamp files and ran bitbake. However, shared staging "broke" that workflow. Is there an equivalent approach with OpenEmbedded Core? Possibly disabling 'sstage' on a per build, or per package basis? Thanks, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC] Move package-split of kexec-tools (kdump/kexec) into oe-core?
Hello all, meta-openembedded uses .bbappend to change the package-split-up of "kexec-tools" (as in openembedded-core) into "kexec" and "kdump" packages (this was classic OE behaviour). http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-kernel/kexec/kexec-tools_2.0.2.bbappend?id=0c6d03335c117d24096598a3415ba22f74ec4f6e However, in openembedded-core we have a dependency on kexec-tools, thus this error results: | * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-core-tools-testapps: | * kexec-tools * | * opkg_install_cmd: Cannot install package task-core-tools-testapps. So the use of meta-openembedded as a layer breaks openembedded-core. As a solution, can we move this package-split into openembedded-core? Other (neat!) solutions at hand? Maybe a meta-package? Regards, Leon. thanks 'ant_work' for the pointer to bbappend. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] siteinfo split between powerpc-common & powerpc-linux
Kumar, On Thu, Jul 21, 2011 at 2:17 PM, Kumar Gala wrote: > Why do we have a split between powerpc-common & powerpc-linux? > > I assume powerpc-linux is used and picked up for powerpc-linux-uclibc in > addition to normal powerpc-linux. > > I'm looking at adding powerpc64 support and powerpc-common is all kinda of > broken for it. I'd like to just merge powerpc-common & powerpc-linux (as > powerpc-linux 32-bit) for now and start a new powerpc-common that refactors > 32/64 commonalities. > > Unless someone says otherwise about the meaning of these files. > Good fine, go ahead, I think these are left-overs from long ago. Regards, -- Leon ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 13/14] perl-native: create_wrapper on perl${PV} too
Hello Khem, On Sun, May 22, 2011 at 7:12 AM, Khem Raj wrote: >> >> Andreas Mueller today reported that this commit breaks his perl build. >> >> See http://article.gmane.org/gmane.comp.handhelds.openembedded/45640 >> > http://git.openembedded.org/cgit.cgi/openembedded-core/commit/?id=a10bd976f4cef54ac50b0c82f885c17a26e5989f > > Has already fixed it in oe-core few days back Thanks, the tipping point for oe-core becomes evident :) Regards, -- Leon ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 13/14] perl-native: create_wrapper on perl${PV} too
Hello,
On Mon, May 16, 2011 at 11:44 PM, Saul Wold wrote:
> From: Tom Rini
>
> perl${PV} becomes hostperl when building for the target so we need a wrapper
> on that too.
>
> This is 1e255fbd296e95ff178d66c4a1fe4875a988d7e1 in OE.
>
> Signed-off-by: Tom Rini
> ---
> meta/recipes-devtools/perl/perl-native_5.12.3.bb | 1 +
> 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/'
> }
> --
Heads up:
Andreas Mueller today reported that this commit breaks his perl build.
See http://article.gmane.org/gmane.comp.handhelds.openembedded/45640
Regards,
--
Leon
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] default-distrovars.inc, task-core-boot.bb: Create distro overridable varibales
Hello, On Wed, May 18, 2011 at 7:29 PM, Koen Kooi wrote: > > Op 18 mei 2011, om 19:08 heeft Phil Blundell het volgende geschreven: > >> On Wed, 2011-05-18 at 09:40 -0700, Khem Raj wrote: >>> Problem I have is, I dont want udev in RDEPENDS which is added by >>> task-core-boot >>> and task-core-boot is added to DISTRO_EXTRA_RDEPENDS through >>> default-distrovars.inc -> defaultsetup.conf -> bitbake.conf >>> >>> and my distro adds DISTRO_EXTRA_RDEPENDS to its RDEPENDS >>> as I think the variable is meant for distro's to define some extra >>> stuff if needed. >>> >>> How should I solve this problem ? >> >> Well, what I did in micro-base-image was simply to not use >> task-core-boot at all. But in your case I was thinking that you could >> overlay that recipe with from your distro's layer and make it do >> whatever you wanted. > > The fact that we have layers does not mean we need to follow the silo > mentality you seem to prefer. If task-base in oe-core stops being usefull we > should fix it, now play around in our own little sandboxes. > If task-base is getting less useful, removing it altogether (I found the reasons mentioned by Phil convincing) should be at least considered as an alternative. I am not sure why we should keep task-base as something generic --all distro's have their own specific requirements and configurations, even for task-base, so why not move this functionality into the distro and out of oe-core? I never quite saw what task-base gained us on a netto basis, but I think I am biased towards small tweaked images, so these are just my two cents. Regards, -- Leon ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] Commit and Patch message guidelines - fifth draft
Hello Mark, On Thu, May 12, 2011 at 9:57 PM, Mark Hatle wrote: > <...> Let the code > tell the story of the mechanics of the change (as much as possible), and let > your comment tell the other details -- i.e. what the problem was, how it > manifested itself (symptoms), and if necessary, the justification for why the > fix was done in manner that it was. > In other words, the long commit message must describe *why* the change was needed (instead of what has changed). I find this item the most lacking in current OpenEmbedded/Poky related commits. Thanks for working on this, -- Leon ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] siteinfo.bbclass: Add powerpc-linux-gnuspe.
Hello Richard, On Fri, May 13, 2011 at 12:45 PM, Richard Purdie wrote: > On Fri, 2011-05-13 at 12:28 +0200, Leon Woestenberg wrote: >> On Fri, May 13, 2011 at 5:50 AM, Khem Raj wrote: >> > you need to rebase this patch on latest oe-core >> > >> Yes, I was using oe-core-contrib/master as a base, wrongly assuming >> that that is the correct base for -contrib fixes/additions. > > To be fair when you wrote the patch, the conflicting distro changes were > not in either branch so in that case it didn't matter. > > It was easier to take the distro changes and fix this up than the other > way around though. > It takes a while before I will git it all, Thanks for the patience and help, -- Leon ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] siteinfo.bbclass: Add powerpc-linux-gnuspe.
Hello Khem, On Fri, May 13, 2011 at 5:50 AM, Khem Raj wrote: > On Wed, May 11, 2011 at 3:29 AM, Leon Woestenberg > wrote: >> From: Leon Woestenberg >> Re-add powerpc-linux-gnuspe, from OpenEmbedded. Also adds support >> to poky.conf so that minimal-core-image builds with DISTRO=poky, > > you need to rebase this patch on latest oe-core > Yes, I was using oe-core-contrib/master as a base, wrongly assuming that that is the correct base for -contrib fixes/additions. Regards, -- Leon ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] How does openembedded-core-contrib/master relate to openembedded-core/master?
Hello Richard, On Wed, May 11, 2011 at 3:41 PM, Richard Purdie wrote: > On Wed, 2011-05-11 at 14:37 +0200, Leon Woestenberg wrote: >> how does the master branch of openembedded-core-contrib relate to the >> master branch of openembedded-core? >> >> Is -core-contrib tracking -core 1-to-1? > >> My first feature branch (likewise/gnuspe) was cloned from, branched, >> and pushes against openembedded-core-contrib, is that the correct >> approach? > > The pull request you sent looked fine. This only works if that master > branch is kept in sync with the main repo though. > which was exactly why I wrote this email. Thanks for confirming my concerns. So the safer way would be to create a feature branch on core-contrib, that however is (re)based on core. Should I clone core, then create a feature branch that I push to core-contrib? Should I clone core-contrib, then rebase against core, then create a feature branch that I push to core-contrib? In either way, I could use a list of the corresponding git commands, as I hate to screw up and we need to document this anyway; we need more core developers. Regards, -- Leon ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] How does openembedded-core-contrib/master relate to openembedded-core/master?
Hello, how does the master branch of openembedded-core-contrib relate to the master branch of openembedded-core? Is -core-contrib tracking -core 1-to-1? The reason I ask is that user contribution go into feature branches (name/feature) of -core-contrib, but should ideally be based against core itself, as RP pulls there, and we want clean pulls. http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/ http://git.openembedded.org/cgit.cgi/openembedded-core/log/ My first feature branch (likewise/gnuspe) was cloned from, branched, and pushes against openembedded-core-contrib, is that the correct approach? Regards, -- Leon ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Re-add powerpc-linux-gnuspe support.
From: Leon Woestenberg (Re-)add powerpc-linux-gnuspe support, as from OpenEmbedded. Pull URL: git://git.openembedded.org/openembedded-core-contrib Branch: likewise/gnuspe Browse: http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=likewise/gnuspe Thanks, Leon Woestenberg --- Leon Woestenberg (1): siteinfo.bbclass: Add powerpc-linux-gnuspe. meta/classes/siteinfo.bbclass |1 + meta/conf/distro/poky.conf|1 + 2 files changed, 2 insertions(+), 0 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] siteinfo.bbclass: Add powerpc-linux-gnuspe.
From: Leon Woestenberg
Re-add powerpc-linux-gnuspe, from OpenEmbedded. Also adds support
to poky.conf so that minimal-core-image builds with DISTRO=poky,
Signed-off-by: Leon Woestenberg
---
meta/classes/siteinfo.bbclass |1 +
meta/conf/distro/poky.conf|1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index df29097..731ccd1 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -47,6 +47,7 @@ def get_siteinfo_list(d):
"powerpc-darwin": "endian-big bit-32 common-darwin",\
"ppc-linux": "endian-big bit-32 common-glibc
powerpc-common",\
"powerpc-linux": "endian-big bit-32 common-glibc
powerpc-common",\
+ "powerpc-linux-gnuspe":"endian-big bit-32 common-glibc
powerpc-common",\
"powerpc-linux-uclibc":"endian-big bit-32 common-uclibc
powerpc-common",\
"sh3-linux": "endian-little bit-32 common-glibc
sh-common",\
"sh4-linux": "endian-little bit-32 common-glibc
sh-common",\
diff --git a/meta/conf/distro/poky.conf b/meta/conf/distro/poky.conf
index 71e40de..536fdc9 100644
--- a/meta/conf/distro/poky.conf
+++ b/meta/conf/distro/poky.conf
@@ -55,6 +55,7 @@ KERNEL_CONSOLE = "ttyS0"
# Default to TARGETOS values for EABI on arm
GLIBCTARGETOS = "linux${@['','-gnueabi'][bb.data.getVar('TARGET_ARCH',d,1) in
['arm', 'armeb']]}"
UCLIBCTARGETOS =
"linux${@['-uclibc','-uclibcgnueabi'][bb.data.getVar('TARGET_ARCH',d,1) in
['arm', 'armeb']]}"
+GLIBCTARGETOS =
"linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500',
'ppce500v2']]}"
POKYMODE ?= "default"
require conf/distro/include/poky-${POKYMODE}.inc
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] error: LOOP: udev/ libudev during do_rootfs?
Hello Mark, thanks for your response. On Wed, May 4, 2011 at 12:31 AM, Mark Hatle wrote: > On 5/3/11 5:19 PM, Leon Woestenberg wrote: >> on oe-core I'm testing the addition of powerpc-linux-gnuspe targets. >> | error: LOOP: >> | error: removing udev-164-r1.ppce500v2 "Requires: libudev0 >= 164" >> from tsort relations. >> | error: removing libudev0-164-r1.ppce500v2 "Requires: udev = 164-r1" >> from tsort relations. >> | Preparing... >> ## >> | ERROR: Function 'do_rootfs' failed (see > > In the past I've only seen this type of "mystery" failure when PSEUDO was not > be > run properly. (pseudo is being configured by the "bitbake" wrapper, located > in > the scripts directory. It has to be preloaded by the wrapper for performance > reasons during the build.) If you are not using the bitbake wrapper script > (automatically added to your environment when you use the environment setup > script oe-init-build-env) you will need to either use the environment setup > script, or add the wrapper to your path [or call it directly]. > > If the wrapper is being invoked, I have some further checks to verify behavior > on your system. > > If the failures continue, what type of host system do you have (distro), and > what version of libc? Do you have both 32-bit and 64-bit libraries and > executables installed? > Ubuntu 10.04 32-bit only, glibc 2.11.1 Linux sideways 2.6.32-25-generic-pae #44-Ubuntu SMP Fri Sep 17 21:57:48 UTC 2010 i686 GNU/Linux $ . oe-init-build-env $ which bitbake /home/leon/sandbox/sidebranch/yocto/oe-core/scripts/bitbake OE Build Configuration: BB_VERSION= "1.13.0" METADATA_BRANCH = "master" METADATA_REVISION = "472c04ed1a8715243de0c5430883bc23d60aca19" TARGET_ARCH = "powerpc" TARGET_OS = "linux-gnuspe" MACHINE = "p2020rdb" DISTRO= "poky" DISTRO_VERSION= "0.9+snapshot-20110504" TARGET_FPU= "" I could reproduce twice from scratch, and the problem repeats by running bitbake core-image-minimal again. On an earlier snapshot of oe-core with meta-openembedded, I didn't run into this. I will now rerun against MACHINE=mpc8315e-rdb. Regards, Leon. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] error: LOOP: udev/ libudev during do_rootfs?
Hello,
on oe-core I'm testing the addition of powerpc-linux-gnuspe targets.
Everything runs fine up to do_rootfs where I hit this "LOOP" error
which I found rather cryptic:
Seems a cyclic loop dependency. I have never seen this error, does
this ring a bell with someone?
| error: LOOP:
| error: removing udev-164-r1.ppce500v2 "Requires: libudev0 >= 164"
from tsort relations.
| error: removing libudev0-164-r1.ppce500v2 "Requires: udev = 164-r1"
from tsort relations.
| Preparing...##
| ERROR: Function 'do_rootfs' failed
This is my abbreviated diff against oe-core (tip)
diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
+ "powerpc-linux-gnuspe":"endian-big bit-32
common-glibc powerpc-common",\
diff --git a/meta/conf/distro/poky.conf b/meta/conf/distro/poky.conf
+GLIBCTARGETOS =
"linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in
['ppce500', 'ppce500v2']]}"
but I'm not sure if gnuspe is related.
Here is the full part of the log where the failure starts:
NOTE: Running task 1527 of 1528 (ID: 8,
/home/leon/sandbox/sidebranch/yocto/oe-core/meta/recipes-core/images/core-image-minimal.bb,
do_rootfs)
NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Started
ERROR: Function 'do_rootfs' failed (see
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/work/p2020rdb-poky-linux-gnuspe/core-image-minimal-1.0-r0/temp/log.do_rootfs.12166
for further information)
ERROR: Logfile of failure stored in:
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/work/p2020rdb-poky-linux-gnuspe/core-image-minimal-1.0-r0/temp/log.do_rootfs.12166
Log data follows:
| + cd /home/leon/sandbox/sidebranch/yocto/oe-core/build
| + do_rootfs
| + rm -rf
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/work/p2020rdb-poky-linux-gnuspe/core-image-minimal-1.0-r0/rootfs
| + mkdir -p
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/work/p2020rdb-poky-linux-gnuspe/core-image-minimal-1.0-r0/rootfs
| + mkdir -p /home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/images
| + '[' 0 '!=' 1 ']'
| + for devtable in
/home/leon/sandbox/sidebranch/yocto/oe-core/meta/files/device_table-minimal.txt
| + makedevs -r
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/work/p2020rdb-poky-linux-gnuspe/core-image-minimal-1.0-r0/rootfs
-D
/home/leon/sandbox/sidebranch/yocto/oe-core/meta/files/device_table-minimal.txt
| + rootfs_rpm_do_rootfs
| + package_update_index_rpm
| + rpmarchs='all any noarch powerpc ppce500v2 p2020rdb'
| + '[' '!' -z '' ']'
| + packagedirs=
| + packagedirs_sdk=
| + for arch in '$rpmarchs'
| ++ echo all
| ++ sed -e s/powerpc/i686/
| + sdkarch=all
| + extension=-nativesdk
| + '[' all = all -o all = any -o all = noarch ']'
| + extension=
| +
packagedirs='/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/all
'
| +
packagedirs_sdk='/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/all
'
| + rm -rf
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/all/solvedb
| + rm -rf
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/all/solvedb
| + for arch in '$rpmarchs'
| ++ echo any
| ++ sed -e s/powerpc/i686/
| + sdkarch=any
| + extension=-nativesdk
| + '[' any = all -o any = any -o any = noarch ']'
| + extension=
| +
packagedirs='/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/any
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/all '
| +
packagedirs_sdk='/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/any
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/all '
| + rm -rf
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/any/solvedb
| + rm -rf
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/any/solvedb
| + for arch in '$rpmarchs'
| ++ echo noarch
| ++ sed -e s/powerpc/i686/
| + sdkarch=noarch
| + extension=-nativesdk
| + '[' noarch = all -o noarch = any -o noarch = noarch ']'
| + extension=
| +
packagedirs='/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/noarch
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/any
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/all '
| +
packagedirs_sdk='/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/noarch
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/any
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/all '
| + rm -rf
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/noarch/solvedb
| + rm -rf
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/noarch/solvedb
| + for arch in '$rpmarchs'
| ++ echo powerpc
| ++ sed -e s/powerpc/i686/
| + sdkarch=i686
| + extension=-nativesdk
| + '[' i686 = all -o i686 = any -o i686 = noarch ']'
| +
packagedirs='/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm/powerpc
/home/leon/sandbox/sidebranch/yocto/oe-core/build/tmp/deploy/rpm
