Re: [yocto] State of Meson build system through eSDK
On 8/13/19 12:59 PM, Alexander Kanavin wrote: On Tue, 13 Aug 2019 at 12:41, Martin Siegumfeldt mailto:m...@gomspace.com>> wrote: The link above is not about eSDK, it's about devtool which works perfectly fine in a non-SDK environment (e.g. plain yocto). Hmm, since it is a subsection beneath 'Using the Extensible SDK' I was expecting the list to describe supported build systems related to devtool in context of the eSDK? This is maybe not communicated well, but devtool works the same in and out of SDK environment. You can check what build systems it supports here: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/recipetool/create_buildsys.py#n874 It probably wouldn't be too much effort to add a meson handler there. In any case, 'devtool add' is just a starting point, and does not promise to produce a fully working recipe. Alex Ok, so it does appear to be "close" but yet unknown territory. If I manage to find time for experiments, I'll get back with the results. Thanks again :) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] State of Meson build system through eSDK
On 8/13/19 11:57 AM, Alexander Kanavin wrote: On Tue, 13 Aug 2019 at 10:40, Martin Siegumfeldt mailto:m...@gomspace.com>> wrote: I am wondering if/when Meson is expected supported through the eSDK - I don't see it from the list: https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-a-closer-look-at-devtool-add ? The link above is not about eSDK, it's about devtool which works perfectly fine in a non-SDK environment (e.g. plain yocto). Hmm, since it is a subsection beneath 'Using the Extensible SDK' I was expecting the list to describe supported build systems related to devtool in context of the eSDK? I think meson in SDKs actually is supported, as there is a nativesdk- version of the meson recipe. Do you want to try and report? Sorry I don't have any particular SW at hand - I was more thinking long term build system strategy, and everyone seems to be chasing Meson these days. Alex Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] State of Meson build system through eSDK
Hi, I am wondering if/when Meson is expected supported through the eSDK - I don't see it from the list: https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-a-closer-look-at-devtool-add ? Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Sequential generation of eSDK from with the same workspace fails for similar machines
Hi Chen, You are right, simply renaming 'SDK_NAME' solves the issue. Thanks, Martin From: ChenQi Sent: Wednesday, August 29, 2018 3:36:41 AM To: Martin Siegumfeldt; yocto@yoctoproject.org Subject: Re: [yocto] Sequential generation of eSDK from with the same workspace fails for similar machines The problem is about two machines having the same TUNE_PKGARCH, and could be solved by setting TOOLCHAIN_OUTPUTNAME in your distro conf file to include MACHINE information. But I'm not sure if this is a bug and should be fixed. Let's wait for more opinions. Best Regards, Chen Qi On 08/28/2018 04:44 PM, Martin Siegumfeldt wrote: > Hi, > > I am subsequently trying to render eSDKs for two different machines from > within the same workspace. > > The first (succeeding) is built according to 'MACHINE="zcu102-zynqmp" bitbake > core-image-minimal -c populate_sdk_ext' whereas the second > (MACHINE="zcu104-zynqmp" bitbake core-image-minimal -c populate_sdk_ext) > fails providing: > > ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: The recipe > core-image-minimal is trying to install files into a shared area when those > files already exist. Those files and their manifest location are: > > /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.testdata.json > (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) > > /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.sh > (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) > Please verify which recipe should provide the above files. > > The build has stopped, as continuing in this scenario WILL break things - if > not now, possibly in the future (we've seen builds fail several months > later). If the system knew how to recover from this automatically it would, > however there are several different scenarios which can result in this and we > don't know which one this is. It may be you have switched providers of > something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in > that case you need to execute the clean task for both recipes and it will > resolve this error. It may be you changed DISTRO_FEATURES from systemd to > udev or vice versa. Cleaning those recipes should again resolve this error, > however switching DISTRO_FEATURES on an existing build directory is not > supported - you should really clean out tmp and rebuild (reusing sstate > should be safe). It could be the overlapping files detected are harmless in > which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It > could also be yo ur >build is including two different conflicting versions of things (e.g. > bluez 4 and bluez 5 and the correct solution for that would be to resolve the > conflict. If in doubt, please ask on the mailing list, sharing the error and > filelist above. > ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: If the above message is > too much, the simpler version is you're advised to wipe out tmp and rebuild > (reusing sstate is fine). That will likely fix things in most (but not all) > cases. > ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed: > sstate_task_postfunc > ERROR: Logfile of failure stored in: > /home/martin/work/z7000-distro/build/tmp/work/zcu104_zynqmp-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk_ext.14111 > ERROR: Task > (/home/martin/work/z7000-distro/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext) > failed with exit code '1' > > > Since the machines are of the same CPU architecture and and the image being > the same, the previously built artifacts are about to be overwritten. AFAICS > images are neatly populated in subdirectories according to the machine name, > however since the SDKs are not populated according to the machine the above > issue is encountered. > > Is this not a supported use case, or am I missing a configuration? > > Thanks, > Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Sequential generation of eSDK from with the same workspace fails for similar machines
Hi, I am subsequently trying to render eSDKs for two different machines from within the same workspace. The first (succeeding) is built according to 'MACHINE="zcu102-zynqmp" bitbake core-image-minimal -c populate_sdk_ext' whereas the second (MACHINE="zcu104-zynqmp" bitbake core-image-minimal -c populate_sdk_ext) fails providing: ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: The recipe core-image-minimal is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.testdata.json (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.sh (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) Please verify which recipe should provide the above files. The build has stopped, as continuing in this scenario WILL break things - if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would, however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error, however switching DISTRO_FEATURES on an existing build directory is not supported - you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above. ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases. ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed: sstate_task_postfunc ERROR: Logfile of failure stored in: /home/martin/work/z7000-distro/build/tmp/work/zcu104_zynqmp-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk_ext.14111 ERROR: Task (/home/martin/work/z7000-distro/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext) failed with exit code '1' Since the machines are of the same CPU architecture and and the image being the same, the previously built artifacts are about to be overwritten. AFAICS images are neatly populated in subdirectories according to the machine name, however since the SDKs are not populated according to the machine the above issue is encountered. Is this not a supported use case, or am I missing a configuration? Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipe availability through eSDK (cppzmq)
Hi Andrea,
You are right, the recipe works-as-is, when adding 'cppzmq-dev' to the image
rather than just 'cppzmq' - I was not aware of this. From an eSDK perspective
it seems to work when the package is installed according to
devtool sdk-install -s cppzmq
and then adding 'IMAGE_INSTALL += "cppzmq-dev"' to local.conf.
On the variables passed in from the shell, can you refer to the location of
this whitelist - for future reference?
Thanks for your support - highly appreciated.
Martin
From: Andrea Galbusera <giz...@gmail.com>
Sent: Wednesday, May 2, 2018 10:33
To: Martin Siegumfeldt
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
On Wed, May 2, 2018 at 9:52 AM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi,
>
>
> Hacking the recipe according to:
>
>
> martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
> diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> index a64745c94..aba1d6edb 100644
> --- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> +++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> @@ -13,9 +13,11 @@ S = "${WORKDIR}/git"
>
> do_install () {
> install -d ${D}/usr/include
> + install -d ${D}/etc
> install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
> + install -m 0755 ${S}/zmq.hpp ${D}/etc
> }
>
> -PACKAGES = "${PN}-dev"
> +PACKAGES = "${PN}-dev ${PN}"
If you go down the patch-the-recipe way, you can probably leave
PACKAGES at its default: both ${PN} and ${PN}-dev are there by
default.
> RDEPENDS_${PN}-dev = "zeromq-dev"
>
> triggers both ${PN}-dev and ${PN} variants to be packaged and included by
> the image. Leaving out the installation into /etc causes ${PN} package not
> to be generated and the image generation does not pick up the ${PN}-dev
> variant.
Better would be adding:
ALLOW_EMPTY_${PN} = "1"
This way it's cleaner and should work as well. However, you'll need to
force your image to depend upon an empty package to be added
(meaningless for the target), for the sake of the corresponding -dev
package to be part of the tailored eSDK... Maybe there's a better way
to achieve this, possibly by adding cppzmq-dev to the SDK explicitly
with something like TOOLCHAIN_TARGET_TASK_append (never used it in
practice though). Hopefully someone can further comment on this to add
some wisdom.
> In essence, it looks like image generation disregards recipes residing
> exclusively in the ${PN}-dev variant - question is whether this is intended
> or not?
Yes it is. -dev packages are not intended to be installed into target
image by design.
>
>
> Br,
>
> Martin
>
>
>
> From: Martin Siegumfeldt
> Sent: Tuesday, May 1, 2018 8:49:17 PM
> To: Andrea Galbusera
>
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
>
> Hi Andrea,
>
>
>
>
> From: Andrea Galbusera <giz...@gmail.com>
> Sent: Tuesday, May 1, 2018 16:06
> To: Martin Siegumfeldt
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
> Hi Martin,
>
> On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com>
> wrote:
>> Hi,
>>
>> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
>> search function does not return anything, despite the recipe being available
>> through local recipe:
>>
>> martin@dell:~/gomspace_sdk$ ls
>> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
>> cppzmq_git.bb files zeromq_4.1.6.bb
>>
>> I assume this is expected since it does not come prebuilt as part of the
>> eSDK - is this correct understood?
>>
>> Fortunately, 'devtool modify/build/package' generates the package -
>> unfortunately it is not included in the subsequent image generation:
>>
>> martin@dell:~/gomspace_sdk$ devtool package cppzmq
>> NOTE: Starting bitbake server...
>> NOTE: Starting bitbake server...
>> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
>> version of the build system; you may possibly experience unexpected
>> failures. It is recommended that you use a tested distribution.
>> Loading cache: 100%
>> ||
>> Time: 0:00:03
>> Loaded 2773 e
Re: [yocto] Recipe availability through eSDK (cppzmq)
Hi,
Hacking the recipe according to:
martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
index a64745c94..aba1d6edb 100644
--- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
+++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
@@ -13,9 +13,11 @@ S = "${WORKDIR}/git"
do_install () {
install -d ${D}/usr/include
+install -d ${D}/etc
install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
+install -m 0755 ${S}/zmq.hpp ${D}/etc
}
-PACKAGES = "${PN}-dev"
+PACKAGES = "${PN}-dev ${PN}"
RDEPENDS_${PN}-dev = "zeromq-dev"
triggers both ${PN}-dev and ${PN} variants to be packaged and included by the
image. Leaving out the installation into /etc causes ${PN} package not to be
generated and the image generation does not pick up the ${PN}-dev variant.
In essence, it looks like image generation disregards recipes residing
exclusively in the ${PN}-dev variant - question is whether this is intended or
not?
Br,
Martin
________
From: Martin Siegumfeldt
Sent: Tuesday, May 1, 2018 8:49:17 PM
To: Andrea Galbusera
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
Hi Andrea,
From: Andrea Galbusera <giz...@gmail.com>
Sent: Tuesday, May 1, 2018 16:06
To: Martin Siegumfeldt
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
Hi Martin,
On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi,
>
> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
> search function does not return anything, despite the recipe being available
> through local recipe:
>
> martin@dell:~/gomspace_sdk$ ls
> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
> cppzmq_git.bb files zeromq_4.1.6.bb
>
> I assume this is expected since it does not come prebuilt as part of the eSDK
> - is this correct understood?
>
> Fortunately, 'devtool modify/build/package' generates the package -
> unfortunately it is not included in the subsequent image generation:
>
> martin@dell:~/gomspace_sdk$ devtool package cppzmq
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
> version of the build system; you may possibly experience unexpected failures.
> It is recommended that you use a tested distribution.
> Loading cache: 100%
> ||
> Time: 0:00:03
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100%
> |##|
> Time: 0:00:01
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305
> skipped, 11 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> Initialising tasks: 100%
> |###|
> Time: 0:00:00
> Checking sstate mirror object availability: 100%
> |###|
> Time: 0:00:00
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be rerun
> and all succeeded.
>
> Summary: There was 1 WARNING message shown.
> NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk
>
> martin@dell:~/gomspace_sdk$ devtool build-image
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
> version of the build system; you may possibly experience unexpected failures.
> It is recommended that you use a tested distribution.
> Loading cache: 100%
> ||
> Time: 0:00:00
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100%
> |##|
> Time: 0:00:02
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 27
Re: [yocto] Recipe availability through eSDK (cppzmq)
Hi Andrea, From: Andrea Galbusera <giz...@gmail.com> Sent: Tuesday, May 1, 2018 16:06 To: Martin Siegumfeldt Cc: yocto@yoctoproject.org Subject: Re: [yocto] Recipe availability through eSDK (cppzmq) Hi Martin, On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com> wrote: > Hi, > > I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The > search function does not return anything, despite the recipe being available > through local recipe: > > martin@dell:~/gomspace_sdk$ ls > layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/ > cppzmq_git.bb files zeromq_4.1.6.bb > > I assume this is expected since it does not come prebuilt as part of the eSDK > - is this correct understood? > > Fortunately, 'devtool modify/build/package' generates the package - > unfortunately it is not included in the subsequent image generation: > > martin@dell:~/gomspace_sdk$ devtool package cppzmq > NOTE: Starting bitbake server... > NOTE: Starting bitbake server... > WARNING: Host distribution "ubuntu-17.10" has not been validated with this > version of the build system; you may possibly experience unexpected failures. > It is recommended that you use a tested distribution. > Loading cache: 100% > || > Time: 0:00:03 > Loaded 2773 entries from dependency cache. > Parsing recipes: 100% > |##| > Time: 0:00:01 > Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 > skipped, 11 masked, 0 errors. > NOTE: Resolving any missing task queue dependencies > Initialising tasks: 100% > |###| > Time: 0:00:00 > Checking sstate mirror object availability: 100% > |###| > Time: 0:00:00 > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be rerun > and all succeeded. > > Summary: There was 1 WARNING message shown. > NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk > > martin@dell:~/gomspace_sdk$ devtool build-image > NOTE: Starting bitbake server... > WARNING: Host distribution "ubuntu-17.10" has not been validated with this > version of the build system; you may possibly experience unexpected failures. > It is recommended that you use a tested distribution. > Loading cache: 100% > || > Time: 0:00:00 > Loaded 2773 entries from dependency cache. > Parsing recipes: 100% > |##| > Time: 0:00:02 > Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 > skipped, 11 masked, 0 errors. > > Summary: There was 1 WARNING message shown. > WARNING: Skipping recipe cppzmq as it doesn't produce a package with the same > name This is the suspicious bit... If you look at the recipe, you'll notice it's re-defining the PACKAGES variable. Then, it's not generating a package called 'cppzmq', but only one named 'cppzmq-dev'. That said, I'm not sure why you'd want to add a package which only provides development headers to your target image... I understand your doubt here. The header file installed is a wrapper around zeromq and thus DEPENDS/RDEPENDS on this library. zeromq is included in the image, for which the SDK is generated, hence I would expect this to be a valid use case? Anyhow, I realized that the recipe does not even work in a BB environment - the following is encountered for an image including the package: ERROR: Nothing RPROVIDES 'cppzmq' (but /home/martin/work/z7000-distro-zcu102/poky/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'cppzmq' is unbuildable, removing... Missing or unbuildable dependency chain was: ['cppzmq'] ERROR: Required build target 'core-image-minimal' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-minimal', 'cppzmq']
[yocto] Recipe availability through eSDK (cppzmq)
Hi, I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The search function does not return anything, despite the recipe being available through local recipe: martin@dell:~/gomspace_sdk$ ls layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/ cppzmq_git.bb files zeromq_4.1.6.bb I assume this is expected since it does not come prebuilt as part of the eSDK - is this correct understood? Fortunately, 'devtool modify/build/package' generates the package - unfortunately it is not included in the subsequent image generation: martin@dell:~/gomspace_sdk$ devtool package cppzmq NOTE: Starting bitbake server... NOTE: Starting bitbake server... WARNING: Host distribution "ubuntu-17.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Loading cache: 100% || Time: 0:00:03 Loaded 2773 entries from dependency cache. Parsing recipes: 100% |##| Time: 0:00:01 Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 skipped, 11 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Initialising tasks: 100% |###| Time: 0:00:00 Checking sstate mirror object availability: 100% |###| Time: 0:00:00 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be rerun and all succeeded. Summary: There was 1 WARNING message shown. NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk martin@dell:~/gomspace_sdk$ devtool build-image NOTE: Starting bitbake server... WARNING: Host distribution "ubuntu-17.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Loading cache: 100% || Time: 0:00:00 Loaded 2773 entries from dependency cache. Parsing recipes: 100% |##| Time: 0:00:02 Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 skipped, 11 masked, 0 errors. Summary: There was 1 WARNING message shown. WARNING: Skipping recipe cppzmq as it doesn't produce a package with the same name Inspecting the manifest file confirms that the package is not installed - any idea why not? I also tried installing though sdk-install: martin@dell:~/gomspace_sdk$ devtool sdk-install -s cppzmq NOTE: Starting bitbake server... WARNING: Host distribution "ubuntu-17.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Loading cache: 100% || Time: 0:00:00 Loaded 2773 entries from dependency cache. Parsing recipes: 100% |##| Time: 0:00:02 Parsing of 1968 .bb files complete (1961 cached, 7 parsed). 2780 targets, 305 skipped, 11 masked, 0 errors.
Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE
On Wed, Apr 18, 2018 at 5:41 AM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi,
>
> I am having a number of recipes residing in two versions, some (development
> versions) being down-prioritized using:
>
> DEFAULT_PREFERENCE = "-1"
>
>
> The source code is hosted at a private git repository, and the git version is
> selected using 'AUTOREV'. The extensible SDK renders successfully, however
> the installation (by third party) fails:
>
> Traceback (most recent call last):
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
> try:
> >s = __expand_var_regexp__.sub(varparse.var_sub, s)
> try:
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7,
> 15), match='${SRCPV}'>):
> else:
> >var = self.d.getVarFlag(key, "_content")
> self.references.add(key)
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True,
> noweakdefault=False, parsing=False):
> cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}',
> varname='SRCPV'):
> def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
> File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
> line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}',
> varname='SRCPV'):
> except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher
> failure: Fetch command export GIT_SSL_CAINFO="/home
> /martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
> export
> PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
> /recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
> sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
> ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
> n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
> ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
> export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote
> ssh://g...@github.com/GomS
> pace/libisl failed with exit code 128, output:
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> It is not the intention that third party will ever need access to the
> development version, and I don't see why the version information is fetched
> given the reduced priority. Have I encountered an 'undocumented bug' or is
> there an alternate approach to achieve this?
AUTOREV is floating dependency, fetcher has to ensure to get a value
for it to populate version strings
before comparing which one to use. you might be able to use BBMASK
effectively to eliminate these
recips from parsers visibility completely.
Thanks, BBMASK seems to do the trick...
>
> Thanks,
> Martin
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Extensible SDK and DEFAULT_PREFERENCE
Hi,
I am having a number of recipes residing in two versions, some (development
versions) being down-prioritized using:
DEFAULT_PREFERENCE = "-1"
The source code is hosted at a private git repository, and the git version is
selected using 'AUTOREV'. The extensible SDK renders successfully, however the
installation (by third party) fails:
Traceback (most recent call last):
File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
try:
> s = __expand_var_regexp__.sub(varparse.var_sub, s)
try:
File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 15),
match='${SRCPV}'>):
else:
> var = self.d.getVarFlag(key, "_content")
self.references.add(key)
File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True,
noweakdefault=False, parsing=False):
cachename = var + "[" + flag + "]"
> value = self.expand(value, cachename)
File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'):
def expand(self, s, varname = None):
> return self.expandWithRefs(s, varname).value
File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py",
line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}',
varname='SRCPV'):
except Exception as exc:
> raise ExpansionError(varname, s, exc) from exc
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher
failure: Fetch command export GIT_SSL_CAINFO="/home
/martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
export
PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
/recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote
ssh://g...@github.com/GomS
pace/libisl failed with exit code 128, output:
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
It is not the intention that third party will ever need access to the
development version, and I don't see why the version information is fetched
given the reduced priority. Have I encountered an 'undocumented bug' or is
there an alternate approach to achieve this?
Thanks,
Martin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Exposure of Shared Library Functionality through eSDK - missing include file
After a bit of further study, it turns out that adding the explicit dependency to the recipe: DEPENDS = "libisl" resolves the issue. Br, Martin ____ From: Martin Siegumfeldt Sent: Tuesday, February 13, 2018 2:10:48 PM To: yocto@yoctoproject.org Subject: Exposure of Shared Library Functionality through eSDK - missing include file Hi, We are implementing certain logic within a shared library and aims at exposing this through the extensible SDK, unfortunately without success so far. The library and it's associated header file is successfully added to the image and appears also present from the eSDK: martin@dell:~/gomspace_sdk$ find . -name libgsisl.so ./tmp/sysroots/nanomind-ultra-zu6eg-zcu102/usr/lib/libgsisl.so ./tmp/work/aarch64-gomspace-linux/libisl/develop-r0/sysroot-destdir/usr/lib/libgsisl.so ./tmp/sysroots-components/aarch64/libisl/usr/lib/libgsisl.so martin@dell:~/gomspace_sdk$ find . -name isl.h ./tmp/sysroots/nanomind-ultra-zu6eg-zcu102/usr/include/gs/isl/isl.h ./tmp/work/aarch64-gomspace-linux/libisl/develop-r0/sysroot-destdir/usr/include/gs/isl/isl.h ./tmp/sysroots-components/aarch64/libisl/usr/include/gs/isl/isl.h martin@dell:~/gomspace_sdk$ For testing, I have implemented a small application, built through CMake: martin@dell:~/work/xsllibtest$ cat CMakeLists.txt add_executable (xsllibtest xsllibtest.c) target_link_libraries (xsllibtest gsisl) with the library- and test application build natively the library call works on my host machine, however the cross-compilation fails to find the header file: martin@dell:~/gomspace_sdk$ devtool add xsllibtest ~/work/xsllibtest/ NOTE: Starting bitbake server... NOTE: Starting bitbake server... NOTE: Starting bitbake server... NOTE: Recipe /home/martin/gomspace_sdk/workspace/recipes/xsllibtest/xsllibtest.bb has been automatically created; further editing may be required to make it fully functional martin@dell:~/gomspace_sdk$ cat workspace/recipes/xsllibtest/xsllibtest.bb # Recipe created by recipetool # This is the basis of a recipe and may need further editing in order to be fully functional. # (Feel free to remove these comments when editing.) # Unable to find any files that looked like license statements. Check the accompanying # documentation and source headers and set LICENSE and LIC_FILES_CHKSUM accordingly. # # NOTE: LICENSE is being set to "CLOSED" to allow you to at least start building - if # this is not accurate with respect to the licensing of the software being built (it # will not be in most cases) you must specify the correct value before using this # recipe for anything other than initial testing/development! LICENSE = "CLOSED" LIC_FILES_CHKSUM = "" # No information for SRC_URI yet (only an external source tree was specified) SRC_URI = "" inherit cmake # Specify any options you want to pass to cmake using EXTRA_OECMAKE: EXTRA_OECMAKE = "" martin@dell:~/gomspace_sdk$ cat workspace/appends/xsllibtest.bbappend inherit externalsrc EXTERNALSRC = "/home/martin/work/xsllibtest" during the compilation: . . . Log data follows: | DEBUG: Executing python function externalsrc_compile_prefunc | NOTE: xsllibtest: compiling from external source tree /home/martin/work/xsllibtest | DEBUG: Python function externalsrc_compile_prefunc finished | DEBUG: Executing shell function do_compile | NOTE: VERBOSE=1 cmake --build /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0/ -- -j 8 | /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/recipe-sysroot-native/usr/bin/cmake -H/home/martin/work/xsllibtest -B/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0 --check-build-system CMakeFiles/Makefile.cmake 0 | /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/recipe-sysroot-native/usr/bin/cmake -E cmake_progress_start /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0/CMakeFiles /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0/CMakeFiles/progress.mar ks | make -f CMakeFiles/Makefile2 all | make[1]: Entering directory '/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0' | make -f CMakeFiles/xsllibtest.dir/build.make CMakeFiles/xsllibtest.dir/depend | make[2]: Entering directory '/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0' | cd /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0 && /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/recipe-sysroot-native/usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/martin/work/xsllibtest /home/martin/work/xsllibtest /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace -linux/xsllibtest/1.0-r0/xsllibtest-1.0
[yocto] Exposure of Shared Library Functionality through eSDK - missing include file
Hi, We are implementing certain logic within a shared library and aims at exposing this through the extensible SDK, unfortunately without success so far. The library and it's associated header file is successfully added to the image and appears also present from the eSDK: martin@dell:~/gomspace_sdk$ find . -name libgsisl.so ./tmp/sysroots/nanomind-ultra-zu6eg-zcu102/usr/lib/libgsisl.so ./tmp/work/aarch64-gomspace-linux/libisl/develop-r0/sysroot-destdir/usr/lib/libgsisl.so ./tmp/sysroots-components/aarch64/libisl/usr/lib/libgsisl.so martin@dell:~/gomspace_sdk$ find . -name isl.h ./tmp/sysroots/nanomind-ultra-zu6eg-zcu102/usr/include/gs/isl/isl.h ./tmp/work/aarch64-gomspace-linux/libisl/develop-r0/sysroot-destdir/usr/include/gs/isl/isl.h ./tmp/sysroots-components/aarch64/libisl/usr/include/gs/isl/isl.h martin@dell:~/gomspace_sdk$ For testing, I have implemented a small application, built through CMake: martin@dell:~/work/xsllibtest$ cat CMakeLists.txt add_executable (xsllibtest xsllibtest.c) target_link_libraries (xsllibtest gsisl) with the library- and test application build natively the library call works on my host machine, however the cross-compilation fails to find the header file: martin@dell:~/gomspace_sdk$ devtool add xsllibtest ~/work/xsllibtest/ NOTE: Starting bitbake server... NOTE: Starting bitbake server... NOTE: Starting bitbake server... NOTE: Recipe /home/martin/gomspace_sdk/workspace/recipes/xsllibtest/xsllibtest.bb has been automatically created; further editing may be required to make it fully functional martin@dell:~/gomspace_sdk$ cat workspace/recipes/xsllibtest/xsllibtest.bb # Recipe created by recipetool # This is the basis of a recipe and may need further editing in order to be fully functional. # (Feel free to remove these comments when editing.) # Unable to find any files that looked like license statements. Check the accompanying # documentation and source headers and set LICENSE and LIC_FILES_CHKSUM accordingly. # # NOTE: LICENSE is being set to "CLOSED" to allow you to at least start building - if # this is not accurate with respect to the licensing of the software being built (it # will not be in most cases) you must specify the correct value before using this # recipe for anything other than initial testing/development! LICENSE = "CLOSED" LIC_FILES_CHKSUM = "" # No information for SRC_URI yet (only an external source tree was specified) SRC_URI = "" inherit cmake # Specify any options you want to pass to cmake using EXTRA_OECMAKE: EXTRA_OECMAKE = "" martin@dell:~/gomspace_sdk$ cat workspace/appends/xsllibtest.bbappend inherit externalsrc EXTERNALSRC = "/home/martin/work/xsllibtest" during the compilation: . . . Log data follows: | DEBUG: Executing python function externalsrc_compile_prefunc | NOTE: xsllibtest: compiling from external source tree /home/martin/work/xsllibtest | DEBUG: Python function externalsrc_compile_prefunc finished | DEBUG: Executing shell function do_compile | NOTE: VERBOSE=1 cmake --build /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0/ -- -j 8 | /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/recipe-sysroot-native/usr/bin/cmake -H/home/martin/work/xsllibtest -B/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0 --check-build-system CMakeFiles/Makefile.cmake 0 | /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/recipe-sysroot-native/usr/bin/cmake -E cmake_progress_start /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0/CMakeFiles /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0/CMakeFiles/progress.mar ks | make -f CMakeFiles/Makefile2 all | make[1]: Entering directory '/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0' | make -f CMakeFiles/xsllibtest.dir/build.make CMakeFiles/xsllibtest.dir/depend | make[2]: Entering directory '/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0' | cd /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0 && /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/recipe-sysroot-native/usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/martin/work/xsllibtest /home/martin/work/xsllibtest /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace -linux/xsllibtest/1.0-r0/xsllibtest-1.0 /home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/xsllibtest/1.0-r0/xsllibtest-1.0
Re: [yocto] wic- optimizing an image containing a large empty partition
Thanks Ed, you are right - my image is indeed generated as a sparse image: martin@martin-Precision-5510:~/work/z7000-distro_wic/build/tmp-glibc/deploy/images/zynq-soft-zedboard$ ls -Llhs z7000-base-image-zynq-soft-zedboard.wic 43M -rw-r--r-- 1 martin martin 1,2G Jan 16 15:00 z7000-base-image-zynq-soft-zedboard.wic I appears however, that dfu-util does not directly support this (as correctly stated from within bmap-tools list): martin@martin-Precision-5510:~/work/z7000-distro_wic/build/tmp-glibc/deploy/images/zynq-soft-zedboard$ dfu-util -D z7000-base-image-zynq-soft-zedboard.wic -a emmc dfu-util 0.9 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2016 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ dfu-util: Invalid DFU suffix signature dfu-util: A valid DFU suffix will be required in a future dfu-util release!!! Opening DFU capable USB device... ID 03fd:0300 Run-time device DFU version 0110 Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 0110 Device returned transfer size 4096 Copying data from PC to DFU device Download [=] 100% 1257452544 bytes Download done. state(7) = dfuMANIFEST, status(0) = No error condition is present state(2) = dfuIDLE, status(0) = No error condition is present Done! I'll look into your above proposal - I wonder if fastboot is capable of this without further effort? Thanks, Martin From: Ed Bartosh <ed.bart...@linux.intel.com> Sent: Tuesday, January 16, 2018 10:58 To: Martin Siegumfeldt Cc: yocto@yoctoproject.org Subject: Re: [yocto] wic- optimizing an image containing a large empty partition On Tue, Jan 16, 2018 at 09:22:07AM +, Martin Siegumfeldt wrote: > Hi, > > > I am trying to optimize an image having a fairly large empty partition with > regards to file size - wks file: > > > martin@martin-Precision-5510:~/work/z7000-distro_wic/meta-z7000$ cat > scripts/lib/wic/canned-wks/gs-boot-rootfs.wks > part --ondisk mmcblk --size 4 > part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label > boot --active --align 4096 --size 64 --fsoptions ro > part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4096 > part /mnt/data --ondisk mmcblk0 --fstype=ext4 --label data --size 1024 > > Now, generating the map file indicates that bmap-tools is capable of > significantly reducing the data transfer: > > martin@martin-Precision-5510:~/work/z7000-distro_wic/build/tmp-glibc/deploy/images/zynq-soft-zedboard$ > cat z7000-base-image-zynq-soft-zedboard.wic.bmap > > > > > > 1257452544 > > > 4096 > > > 306996 > > > 10765 > > > sha256 > > > >d41d210e8efdf32597e566360a2f701e706f3b04bcf2418bb0c50a1f8a8d6c72 > > > > > chksum="4e1c836ffaf1a23f316382f5d7eff44a0fc5a43ac681fa11e100e55b73e8bc7b"> 0-6 > > chksum="b795c68a5cde6a8ab0b7b541f2094792f4746fb0f9e5b794024895b5c72a42ea"> >2048-2347 > chksum="073c303254e96b44400b7df159fdd8cfcc48cad90f77ab14cf157eaaaf94d810"> >23552-23620 > chksum="b34201ffa94456444c5bc8e546e3805fc58961403c0a444ce039f21eb894c05c"> >23622-23688 > chksum="731c02b87191f90e37683778e6c8817c03cf2b3e6ac1159c1bb7934700709e8b"> >23957-25600 > chksum="e1dd56bc7566dda92807ce28582f3f5ead589d7dfbf4beca9c6f928238f73ede"> >25664-29696 > chksum="2ccb999e7b63cad77d1891c93424d301cff5dd1c2f25813b96f243d425592770"> >29760-31744 > chksum="06986ccd4f1319028200fbfb9dccb72fabd4e18abf4195cfbe288ac09436630c"> >32768-33792 > chksum="8cdfec001877d4b6bb41d1caf814aadfc67cabef160a0a442fbb98dfc4190424"> >33856-35389 > chksum="f9ca40694ee8b587e20fcfb2a803055f16a6cb1b348a90badae9c13860cff8a0"> >37888 > chksum="b05058de59ab0182064323d297a3c6fba42772f3da4f48fa9f60dc58f4b386e3"> >41984 > chksum="2abc48348f9551bd05258553014f8c389970d30381e3dc64547a0a7b6f48af14"> >44851-44917 > chksum="71899ad8e3fa013443678f384e219f1064e74687fb34861036aa8e4567e12e9a"> >44920-44921 > chksum="cc80e24228a48b279bcd626dae16181c317b56acfb8fc56dc7b1f83463966166"> >44923-44925 > chksum="3efa6bcb59cd77722327d11d040bf51e983e004c8d826e4ddf7f9b94b0cc754b"> >44932-44933 > chksum="3c3ea8e0f3eb5a88321bde760d9328826b1cd87df9
[yocto] wic- optimizing an image containing a large empty partition
Hi, I am trying to optimize an image having a fairly large empty partition with regards to file size - wks file: martin@martin-Precision-5510:~/work/z7000-distro_wic/meta-z7000$ cat scripts/lib/wic/canned-wks/gs-boot-rootfs.wks part --ondisk mmcblk --size 4 part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4096 --size 64 --fsoptions ro part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4096 part /mnt/data --ondisk mmcblk0 --fstype=ext4 --label data --size 1024 Now, generating the map file indicates that bmap-tools is capable of significantly reducing the data transfer: martin@martin-Precision-5510:~/work/z7000-distro_wic/build/tmp-glibc/deploy/images/zynq-soft-zedboard$ cat z7000-base-image-zynq-soft-zedboard.wic.bmap 1257452544 4096 306996 10765 sha256 d41d210e8efdf32597e566360a2f701e706f3b04bcf2418bb0c50a1f8a8d6c72 0-6 2048-2347 23552-23620 23622-23688 23957-25600 25664-29696 29760-31744 32768-33792 33856-35389 37888 41984 44851-44917 44920-44921 44923-44925 44932-44933 53124-53130 77619-77621 143155-143157 175923-175924 208691-208693 274227-274229 306992-306995 Unfortunately, my HW does not integrate an SD card (that could have been flashed using bmap-tools) and we currently flash the soldered eMMC using dfu-util. In this case all 1.2 GB are transferred, which I consider fairly suboptimal compared to the above reported 42 MB . In the past we maintained a custom image class that simply skipped creating the empty ext4 partition and left it to be created upon the first boot. I could probably live with this approach, but I don't really see an easy way of achieveing this using wic - perhaps I missed it? However, if possible, my preference would be to generate the partition during the build and not at runtime. I see some history of sparse images related to wic, but the works appears reverted? Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Issues building Extensible SDK
Hi Robert,
Thank you very much, adding the lines
require conf/distro/include/yocto-uninative.inc
INHERIT += "uninative"
to the distro configuration enables the build to succeed.
Br,
Martin
From: Robert Yang <liezhi.y...@windriver.com>
Sent: Thursday, January 11, 2018 6:45:29 AM
To: Martin Siegumfeldt; yocto@yoctoproject.org
Subject: Re: [yocto] Issues building Extensible SDK
Hi Martin,
Try:
$ bitbake -e | grep '^INHERIT=.*uninative'
If there is nothing, then add the following line to conf/local.conf:
INHERIT += "uninative"
// Robert
On 01/10/2018 03:46 PM, Martin Siegumfeldt wrote:
> Hi,
>
> We have a custom piece of (Zynq based) HW that we render a custom distro
> using Yocto. I am trying to build the extensible SDK but run into the below
> error:
>
> pokyuser@03c19f8798ba:/workdir/krogoth/build$ bitbake core-image-minimal -c
> populate_sdk_ext
> Loading cache: 100%
> ||
> Time: 0:00:00
> Loaded 2675 entries from dependency cache.
> Parsing recipes: 100%
> |##|
> Time: 0:00:01
> Parsing of 1915 .bb files complete (1913 cached, 2 parsed). 2677 targets, 377
> skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION= "1.34.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING = "ubuntu-16.04"
> TARGET_SYS= "arm-oe-linux-gnueabi"
> MACHINE = "zynq-soft-z7000-mb-v2"
> DISTRO= "gomspace"
> DISTRO_VERSION= "2.0"
> TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> TARGET_FPU= "hard"
> meta = "pyro:9c75151116aa293dc8567c237d7e4da5bdec90e3"
> meta-xilinx = "pyro:18097af3120a394a8e6933b7abc85e73e508c7e3"
> meta-oe
> meta-filesystems
> meta-networking
> meta-python = "pyro:dfbdd28d206a74bf264c2f7ee0f7b3e5af587796"
> meta-z7000= "pyro:b255ea4575b40d77a2f5dc9200de0718f979f175"
>
> Initialising tasks: 100%
> |###|
> Time: 0:00:03
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Error executing a
> python function in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function:
> 0001:
> *** 0002:copy_buildsystem(d)
> 0003:
> File:
> '/workdir/krogoth/openembedded-core/meta/classes/populate_sdk_ext.bbclass',
> lineno: 298, function: copy_buildsystem
> 0294:f.write('TCLIBCAPPEND = ""\n')
> 0295:f.write('DL_DIR = "${TOPDIR}/downloads"\n')
> 0296:
> 0297:f.write('INHERIT += "%s"\n' % 'uninative')
> *** 0298:f.write('UNINATIVE_CHECKSUM[%s] = "%s"\n\n' %
> (d.getVar('BUILD_ARCH'), uninative_checksum))
> 0299:f.write('CONF_VERSION = "%s"\n\n' %
> d.getVar('CONF_VERSION', False))
> 0300:
> 0301:# Some classes are not suitable for SDK, remove them
> from INHERIT
> 0302:f.write('INHERIT_remove = "%s"\n' %
> d.getVar('SDK_INHERIT_BLACKLIST', False))
> Exception: UnboundLocalError: local variable 'uninative_checksum' referenced
> before assignment
>
> ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed:
> copy_buildsystem
> ERROR: Logfile of failure stored in:
> /workdir/krogoth/build/tmp-glibc/work/zynq_soft_z7000_mb_v2-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_populate_sdk_ext.8408
> ERROR: Task
> (/workdir/krogoth/openembedded-core/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 2214 tasks of which 2210 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> /wor
