Date   

Re: [bitbake] fsl-image-xwayland DISTRO -- can't get rid of dev packages.

Khem Raj
 

Hi Karim

On 6/15/18 6:29 AM, Karim ATIKI wrote:
Hi all,
I've created a custom image based on core-image.
It runs for an i.MX6 and i.MX8.
I've installed only Qt, gstreamer and xwayland stuff.
I've removed dev-pkgs, dbg-pkgs and staticdev-pkgs from IMAGE_FEATURES.
Finally, in the created image, ALL the dpg, dev packages have been installed, with tons of .h header files. static .a files etc.
I've tried everything and just can't figure out how to get rid of them.
Any idea ?
It seems that some dev packages are still being pulled in you might want to check output of

bitbake -g <image>

which will be in bunch of dotty files, that can show what is being pulled and why

Thanks.
K.


[PATCH] ref-variables: Document UBOOT_DTB_LOADADDRESS/UBOOT_DTBO_LOADADDRESS

Alex Kiernan
 

Document UBOOT_DTB_LOADADDRESS (address used for device tree blobs) and
UBOOT_DTBO_LOADADDRESS (address used for device tree overlay blobs).

Signed-off-by: Alex Kiernan <alex.kiernan@...>
---
These variables are introduced by this patch series:

https://patchwork.openembedded.org/series/12601/

documentation/ref-manual/ref-variables.xml | 43 ++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)

diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 1c55a92..0d97e17 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -15862,6 +15862,49 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
</glossdef>
</glossentry>

+ <glossentry id='var-UBOOT_DTB_LOADADDRESS'><glossterm>UBOOT_DTB_LOADADDRESS</glossterm>
+ <info>
+ UBOOT_DTB_LOADADDRESS[doc] = "Specifies the load address for DT blobs in the U-Boot FIT image."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+ Specifies the load address for DT blobs in the the U-Boot
+ FIT image.
+ </para>
+
+ <para>
+ When using DT overlays with <filename>bootm</filename>
+ then both <filename>UBOOT_DTB_LOADADDRESS</filename> and
+ <filename>UBOOT_DTBO_LOADADDRESS</filename> must be
+ specified. See
+ <filename>doc/uImage.FIT/overlay-fdt-boot</filename> in
+ U-Boot.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry id='var-UBOOT_DTBO_LOADADDRESS'><glossterm>UBOOT_DTBO_LOADADDRESS</glossterm>
+ <info>
+ UBOOT_DTBO_LOADADDRESS[doc] = "Specifies the load address for DT
+blob overlays in the U-Boot FIT image."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+ Specifies the load address for DT blob overlays in the
+ the U-Boot FIT image.
+ </para>
+
+ <para>
+ When using DT overlays with <filename>bootm</filename>
+ then both <filename>UBOOT_DTB_LOADADDRESS</filename> and
+ <filename>UBOOT_DTBO_LOADADDRESS</filename> must be
+ specified. See
+ <filename>doc/uImage.FIT/overlay-fdt-boot</filename> in
+ U-Boot.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-UBOOT_ENTRYPOINT'><glossterm>UBOOT_ENTRYPOINT</glossterm>
<info>
UBOOT_ENTRYPOINT[doc] = "Specifies the entry point for the U-Boot image."
--
2.7.4


Re: Yocto not fetching unzip

Andre McCurdy <armccurdy@...>
 

On Mon, Jun 11, 2018 at 6:33 AM, Maas, Jonas <Jonas.Maas@...> wrote:
Hello everyone,

I am experiencing an issue with yocto-2.1.2:

I am trying to prefetch all needed sources for a certain image, let’s say
“my-image”, by calling:

$ bitbake -c fetchall my-image

Next I am archiving the whole Yocto system (including the downloads
directory) to a tar.gz file and unpack it on another system.

Now when I set BB_NO_NETWORK=”1” in the local.conf and try to build using

$ bitbake my-image

the package “unzip” is missing. I can fetch it manually by temporarily
switching to online build an calling

$ bitbake -c fetch unzip

However I want to be able to build completely from the generated tar.gz.

Is this a bug in Yocto or intended behavior? If it is intended: Is there a
proper setting to solve this or do I have to fetch unzip manually bevor
packing the archive?
You don't mention how you are using unzip.

If you are including unzip in your image then failing to download it
during fetchall is unexpected and sounds like a bug.

If you're not including unzip in your image but instead your build
actually depends on unzip-native (ie a tool to run on the host and
needed as a build dependency if a recipe you build contains .zip or
.jar files in SRC_URI) then I'm not sure what the expectation is. If
fetchall doesn't download these indirect -native dependencies then it
might just be the way it is. If so, then manually running "bitbake -c
fetch unzip-native" might be an appropriate solution.


Re: Yocto not fetching unzip

Khem Raj
 

Hi Jonas

On 6/11/18 6:33 AM, Maas, Jonas wrote:
Hello everyone,

 

I am experiencing an issue with yocto-2.1.2:

I am trying to prefetch all needed sources for a certain image, let’s
say “my-image”, by calling:

 

$ bitbake -c fetchall my-image

 

Next I am archiving the whole Yocto system (including the downloads
directory) to a tar.gz file and unpack it on another system.

Now when I set BB_NO_NETWORK=”1” in the local.conf and try to build using

 

$ bitbake my-image

 
I you built image on the machine where fetchall was done, do you see it
building unzip ?


the package “unzip” is missing. I can fetch it manually by temporarily
switching to online build an calling

 

$ bitbake -c fetch unzip

 

However I want to be able to build completely from the generated tar.gz.

 

Is this a bug in Yocto or intended behavior? If it is intended: Is there
a proper setting to solve this or do I have to fetch unzip manually
bevor packing the archive?

Thanks in advance!

 

 

Kind regards,

 

Jonas


[PATCH] meta-yocto-bsp: Let yocto BSPs be able to build with linux-yocto-dev

He Zhe
 

Signed-off-by: He Zhe <zhe.he@...>
---
.../recipes-kernel/linux/linux-yocto-dev.bbappend | 15 +++++++++++++++
1 file changed, 15 insertions(+)
create mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend
new file mode 100644
index 0000000000..f044dafb4d
--- /dev/null
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -0,0 +1,15 @@
+KBRANCH_genericx86 = "standard/base"
+KBRANCH_genericx86-64 = "standard/base"
+KBRANCH_edgerouter = "standard/edgerouter"
+KBRANCH_beaglebone-yocto = "standard/beaglebone"
+KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
+
+KMACHINE_genericx86 ?= "common-pc"
+KMACHINE_genericx86-64 ?= "common-pc-64"
+KMACHINE_beaglebone-yocto ?= "beaglebone"
+
+COMPATIBLE_MACHINE_genericx86 = "genericx86"
+COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
+COMPATIBLE_MACHINE_edgerouter = "edgerouter"
+COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
+COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
--
2.11.0


[PATCH] meta-yocto-bsp: mpc8315e-rdb: Change kernel provider assignment to a weaker one

He Zhe
 

Currently mpc8315e-rdb.conf comes after local.conf during parsing. We should
give local.conf a chance to overwrite the kernel provider assignment, like
other BSPs.

Signed-off-by: He Zhe <zhe.he@...>
---
meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
index 34f12303a1..72f52912eb 100644
--- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
+++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
@@ -15,7 +15,7 @@ SERIAL_CONSOLE = "115200 ttyS0"
MACHINE_FEATURES = "keyboard pci ext2 ext3 serial"

PREFERRED_VERSION_linux-yocto ?= "4.15%"
-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"

PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
XSERVER ?= "xserver-xorg \
--
2.11.0


[bitbake] fsl-image-xwayland DISTRO -- can't get rid of dev packages.

Atiki Karim
 

Hi all,


I've created a custom image based on core-image.

It runs for an i.MX6 and i.MX8.

I've installed only Qt, gstreamer and xwayland stuff.


I've removed dev-pkgs, dbg-pkgs and staticdev-pkgs from IMAGE_FEATURES.


Finally, in the created image, ALL the dpg, dev packages have been installed, with tons of .h header files. static .a files etc.

I've tried everything and just can't figure out how to get rid of them.


Any idea ?


Thanks.


K.


Re: devtool finish & patch order

Peter Kjellerstedt
 

-----Original Message-----
From: Alexander Kanavin [mailto:alex.kanavin@...]
Sent: den 15 juni 2018 06:37
To: Peter Kjellerstedt <peter.kjellerstedt@...>
Cc: Tim Hammer <tdhammer99@...>; Yocto discussion list
<yocto@...>; Paul Eggleton (paul.eggleton@...)
<paul.eggleton@...>
Subject: Re: [yocto] devtool finish & patch order

2018-06-15 2:11 GMT+03:00 Peter Kjellerstedt
<peter.kjellerstedt@...>:
* `devtool modify -w <some simple package>`
* Modify some file, e.g., add some comment to the Makefile.
* Commit it with subject "Change 1"
* Repeat the two steps above two more times, increasing the number in
the subject each time.
* `devtool finish <some simple package> <layer where the recipe is>`
* Examine the updated recipe. In my case the patches were in the
correct order after this step:

SRC_URI = "<original URI> \
file://0001-Change-1.patch \
file://0002-Change-2.patch \
file://0003-Change-3.patch \
"

* Not to be discouraged, I started over (using the existing source
dir):
* `devtool modify -n <some simple package>`
* `git rebase -i 'HEAD~3'` (in workspace/sources/<some simple
package>)
* Use "reword" on the last two commits and change their subject lines
to "Another change" and "Some third change".
* `devtool finish <some simple package> <some other layer than where
the recipe is>`
* Now I ended up with the following in the new .bbappend file:

SRC_URI += "file://0002-Another-change.patch file://0003-Some-third-change.patch file://0001-Change-1.patch"
Wait, what would be the correct thing for devtool to do here? The
original patches are already added to the recipe in the original
layer, so .bbappend would have to first revert them and add newly
modified ones? I don't think devtool is that clever :) Does it add
the patches correctly, if you repeat the first half of the sequence
(adding new patches), but use devtool finish to save changes to a
diffferent layer?

Alex
When I said "I started over" above, that included removing the
patches that had been added to the recipe file. So each time I
did `devtool finish ...`, the recipe state was the initial one
(i.e., without any patches in either the recipe or any bbappend).

I actually did the devtool modify/devtool finish cycle a number
of times. I never got the wrongly ordered patches when they were
added to the recipe, but when they were added in a bbappend, the
results varied. The first time I tried they were in the right
order, but then I did the rewriting of the commit messages and
then they ended up in the wrong order.

//Peter


Re: bbappend extra SRC_URI ignored

Damien LEFEVRE
 

It's exactly as you said. Thanks a lot!

I got it solved and learned some new tricks =)

-Damien

On Thu, Jun 14, 2018 at 5:23 PM, Martin Jansa <martin.jansa@...> wrote:
See ./recipes-bsp/tegra-binaries/tegra-shared-binaries.inc

It's disabling standard do_fetch, do_unpack, do_patch and replacing them with tegra-binaries:do_unpack tegra-binaries:do_preconfigure which populates
S directory in work-shared
S = "${TMPDIR}/work-shared/L4T-${SOC_FAMILY}-${PV}-${PR}/Linux_for_Tegra"

so basically you need to add it in tegra-binaries recipe (not tegra-tools).

On Thu, Jun 14, 2018 at 3:22 PM Damien LEFEVRE <lefevre.da@...> wrote:

Thanks

Here are some interesting parts of bitbake -e. It seems my syntax is correct 


# $FILESEXTRAPATHS [3 operations]
#   set? /home/damien/procbox-pyro/sources/poky/meta/conf/bitbake.conf:325
#     "__default:"
#   set /home/damien/procbox-pyro/sources/poky/meta/conf/documentation.conf:173
#     [doc] "Extends the search path the OpenEmbedded build system uses when looking for files and patches as it processes recipes and append files."
#   _prepend[tegra186] /home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bbappend:1
#     "/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186:"
# pre-expansion value:
#   "/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186:__default:"
FILESEXTRAPATHS="/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186:__default:"

#
# $SRC_URI [10 operations]
.....
#     "    file://nvcamera-daemon.init     file://nvcamera-daemon.service     file://argus-daemon.init     file://argus-daemon.service     file://nvstartup.init     file://nvstartup.service "
#   _append[tegra186] /home/damien/procbox-pyro/sources/meta-tegra/recipes-bsp/tegra-binaries/tegra-binaries-28.2.0.inc:19
#     "     file://tegra186-flash-helper.sh     file://nvpmodel.init     file://nvpmodel.service "
#   set /home/damien/procbox-pyro/sources/meta-tegra/recipes-bsp/tegra-binaries/tegra-shared-binaries.inc:8
#     ""
#   _prepend[tegra186] /home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bbappend:2
#     "file://nvpmodel.conf "
#   set tegra-binaries-28.2.0.inc:42 [__anon_46__home_damien_procbox_pyro_sources_meta_tegra_recipes_bsp_tegra_binaries_tegra_binaries_28_2_0_inc]
#     [md5sum] "22bbd0002db06bb26bf5de2d17cea8eb"
#   set tegra-binaries-28.2.0.inc:43 [__anon_46__home_damien_procbox_pyro_sources_meta_tegra_recipes_bsp_tegra_binaries_tegra_binaries_28_2_0_inc]
#     [sha256sum] "62f57b4c03fedde1fe0a1635bd0828b334308eca71bd21f25ae5757f48fb3a76"
# pre-expansion value:
#   "file://nvpmodel.conf      file://tegra186-flash-helper.sh     file://nvpmodel.init     file://nvpmodel.service "
SRC_URI="file://nvpmodel.conf      file://tegra186-flash-helper.sh     file://nvpmodel.init     file://nvpmodel.service "

Then no other mentions until the do_install

Yet the nvpmodel.conf is never copied to ${WORKDIR} which is /home/damien/procbox-pyro/build-jetson-tx2/tmp/work/aarch64_tegra186-poky-linux/tegra-tools/28.2.0-r0 in my case.

Could some bitbake options disable this standard behavior?

On Thu, Jun 14, 2018 at 3:33 PM, Martin Jansa <martin.jansa@...> wrote:
On Thu, Jun 14, 2018 at 03:16:00PM +0300, Damien LEFEVRE wrote:
> HI,
>
> I'm working on meta-tegra layer and I'd like to append a recipe. The
> original recipe looks like this:
> https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb
> <https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb>
>
> I've made a tegra-tools_28.2.0.bbappend to change the default PM_CONFIG
> DEFAULT from 2 to 3 to get max performance in nvpmodel.conf configuration
> file.
>
> ```
> FILESEXTRAPATHS_prepend := "${THISDIR}/files/tegra186:"
> SRC_URI_prepend_tegra186 += "file://nvpmodel.conf "
>
> do_install_append_tegra186() {
>     install -d ${D}${sysconfdir}
>     install -m 0755 ${B}/usr/sbin/nvpmodel ${D}${sbindir}/
>     install -m 0644 ${WORKDIR}/nvpmodel.conf ${D}${sysconfdir}/nvpmodel.conf
>     install -d ${D}${sysconfdir}/init.d
>     install -m 0644 ${S}/nvpmodel.init ${D}${sysconfdir}/init.d/nvpmodel
>     install -d ${D}${systemd_system_unitdir}
>     install -m 0644 ${S}/nvpmodel.service ${D}${systemd_system_unitdir}
> }
> ```
> Would you have any idea why the nvpmodel.conf prepend is ignored and the
> file never ends up in ${WORKDIR}.
>
> I've made sure the paths are correct. nvpmodel.conf exists and if I put a
> typo like nvpmodel.conf_blabla bitbake throws a warning that it cannot find
> the file. So I'm sure the file is found but somehow bitbake ignores it.
>
> I'm having this issue with this one single recipe only, none of the others
> in my build system so I'm a bit puzzled.

Always use bitbake -e to verify that the file://nvpmodel.conf ends where
you expect it to end (and if it doesn't the history will show you why
not).

>
> Thanks,
> -Damien

> --
> _______________________________________________
> yocto mailing list
> yocto@...
> https://lists.yoctoproject.org/listinfo/yocto


--
Martin 'JaMa' Jansa     jabber: Martin.Jansa@...



Re: sysroot not being populated

Patrick Vacek <patrick.vacek@...>
 

On 14.06.2018 16:28, Khem Raj wrote:
On Thu, Jun 14, 2018 at 5:45 AM Patrick Vacek <patrick.vacek@...> wrote:
On 12.06.2018 00:48, Andre McCurdy wrote:
On Fri, Jun 8, 2018 at 2:42 AM, Patrick Vacek <patrick.vacek@...> wrote:
On 08.06.2018 10:26, Khem Raj wrote:
On 6/8/18 12:27 AM, Patrick Vacek wrote:
On 07.06.2018 19:06, Khem Raj wrote:
On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek
<patrick.vacek@...> wrote:
I have a recipe (aktualizr-hsm-prov) that depends on another
(aktualizr)
to provide an executable and a config file. The former recipe includes
`DEPENDS = "aktualizr-native"`, and my do_install() for
aktualizr-hsm-prov has a line something like this:

aktualizr -i ${STAGING_DIR_NATIVE}${libdir}/sota.conf

The binary executable (aktualizr) runs, which tells me that the recipe
can find that. (Although to be honest, I'm not sure which version
it is
running.) However, it doesn't find the config file, and sure enough,
${STAGING_DIR_NATIVE}${libdir} does not have the config file I
expect. I
can see that aktualizr-native is populating its sysroot-destdir,
but it
isn't getting copied to the sysroot for aktualizr-hsm-prov.

I see this problem in sumo and master, although previously this logic
has worked just fine in morty/pyro/rocko.

What am I doing wrong? What changed between rocko and sumo?
Can you check location of sota.conf in the build tree for
aktualizr-native in directory called package/
Oddly, I do not see a package subdirectory inside the aktualizr-native
directory in the build tree. I do see it inside the aktualizr directory,
though, and it contains everything that I would expect. Is there some
sort of configuration of the packaging system for a native recipe that I
haven't done correctly?
No, what you see is expected - there's no packaging for -native recipes.

Back to the original problem, I think you should consider the
aktualizr executable and the sota.conf file as two separate things.
The host executable should always be provided by aktualizr-native.
It's less clear what should provide sota.conf - it depends whether
it's just required for building other recipes (ie like a header file)
or whether it needs to be present in the final rootfs? If it's only
required for building other packages, then it should be in the -dev
package for aktualizr. If it needs to be present in the final rootfs
then it should be in the default package for aktualizr. Either way,
recipes which need to find sota.conf in sysroot would then depend on
"aktualizr". Therefore recipes which need both the host executable and
sota.conf in sysroot should depend on both aktualizr and
aktualizr-native.
Actually, after some further research, it appears that my problem is not
entirely resolved. The explanation of packaging and native vs. target
dependencies all makes sense to me and usually works. However, this is
not the case for one specific condition which happens to be part of my
test suite.

One of my tests is to change the MACHINE in my local.conf, add some
additional layers, change some other variables, and then bitbake. Then I
undo that and bitbake again. For the most part, that works fine. In
rocko and before, it worked consistently. But it seems like on sumo and
master, when I do the test by changing the MACHINE and the layers, it
somehow clears out everything in my recipe's work directory, despite
that that recipe is not used by that test. In fact, it removes every
single file in tmp/work/core2-64-poky-linux (but leaves most of the
directories). When I switch back to how it was before and bitbake, most
of the files get recreated or re-copied, but not all. I have to
explicitly run `bitbake -c cleanall aktualizr aktualizr-hsm-prov` to get
things to work again. (Perhaps cleanall isn't necessary, but some form
of cleaning is, and it has to be both recipes.)

Can someone help explain why I am seeing this behavior? I don't
understand why the files get erased, why they don't get repopulated, and
why this was different back in rocko.
when machine and other variables are changed then its mostly
resulting in hash changes which is enforcing it to rebuild and when
rebuild happens it will clear the recipe specific build area for that
given recipe and repopulate it as it has to rebuild/repackage it since
this time it will get most of build artifacts from shared state as it
has been bullt with same hash once before. so it will most probably be
re-using that.
That make sense.
If doing clean build is helping then this might mean that they
are not staging all the files that you depend on. When you do
clean build they get staged into build area during compile phase and
it silently uses it. So ensure that all files you need are accounted
for in do_install
That makes sense, too, but the first recipe (aktualizr) definitely
installs the config file I need in do_install and lists it in
FILES_${PN}-host-tools. In fact, the entire package subdirectory of
aktualizr is not repopulated, and thus the recipe-sysroot for the second
recipe (aktualizr-hsm-prov, the one that depends on aktualizr) is also
left empty. It seems like something is not triggering or preventing the
repopulation of those directories when I change MACHINE back to the
original value (qemux86-64).


Re: [meta-java][PATCH 3/3] openjdk-8: use ca-certificates-java

Richard Leitner
 

Hi,
this commit of yours breaks the build on meta-java's current
mater-next branch (when building an image containing openjre-8
or openjdk-8) with following message:

ERROR: openjre-8-test-image-1.0-r0 do_rootfs: [log_check] openjre-8-test-image: found 1 error message in the logfile:
[log_check] E: /yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/rootfs/etc/ca-certificates/update.d/ca-certificates-java-hook exited with code 1.

ERROR: openjre-8-test-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/temp/log.do_rootfs.19892
ERROR: Task (/yocto/meta-java-test/meta-java/recipes-images/images/openjre-8-test-image.bb:do_rootfs) failed with exit code '1'


The logfile contains following error:

Running hooks in /yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/rootfs/etc/ca-certificates/update.d...
/yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/rootfs/etc/ca-certificates/update.d/ca-certificates-java-hook: no JVM_LIBDIR specified
E: /yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/rootfs/etc/ca-certificates/update.d/ca-certificates-java-hook exited with code 1.
done.


Therefore it will be removed from master-next.

It would be great if you could send an fixed version.

Thank you!

regards;Richard.L

On 03/30/2018 10:40 AM, André Draszik wrote:
From: André Draszik <andre.draszik@...>

The OpenJDK-8 package currently comes with a trustStore
that was generated at OpenJDK-8-native build time from
*all* certificates available in the system, not just from
those that are marked as trusted.

This isn't right...

openjdk-8 and openjre-8 now RDEPENDS on (and use) the CA
certificates as provided by the ca-certificates-java
package just added.

This makes sure that Java now uses the same trusted CA
certificates as the rest of the system.

Signed-off-by: André Draszik <andre.draszik@...>
---
recipes-core/openjdk/openjdk-8-common.inc | 2 ++
recipes-core/openjdk/openjdk-8-cross.inc | 12 +++++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/recipes-core/openjdk/openjdk-8-common.inc b/recipes-core/openjdk/openjdk-8-common.inc
index b2020c3..c8d157e 100644
--- a/recipes-core/openjdk/openjdk-8-common.inc
+++ b/recipes-core/openjdk/openjdk-8-common.inc
@@ -254,3 +254,5 @@ def version_specific_cflags(d):
CFLAGS_append = " ${@version_specific_cflags(d)}"
CXXFLAGS_append = " ${@version_specific_cflags(d)}"
CXX_append = " -std=gnu++98"
+
+RDEPENDS_${PN} = "ca-certificates-java"
diff --git a/recipes-core/openjdk/openjdk-8-cross.inc b/recipes-core/openjdk/openjdk-8-cross.inc
index d70c946..6795c92 100644
--- a/recipes-core/openjdk/openjdk-8-cross.inc
+++ b/recipes-core/openjdk/openjdk-8-cross.inc
@@ -57,7 +57,6 @@ EXTRA_OECONF_append = "\
--with-sys-root=${STAGING_DIR_HOST} \
--with-tools-dir=${STAGING_DIR_NATIVE} \
--with-boot-jdk=${STAGING_LIBDIR_NATIVE}/jvm/openjdk-8-native \
- --with-cacerts-file=${STAGING_LIBDIR_NATIVE}/jvm/openjdk-8-native/jre/lib/security/cacerts \
\
--disable-precompiled-headers \
--disable-zip-debug-info \
@@ -88,6 +87,17 @@ do_install_append() {
pack200 --repack --effort=9 --segment-limit=-1 --modification-time=latest --strip-debug "$0"'
fi
fi
+
+ if [ -d ${D}${JDK_HOME} ] ; then
+ rm ${D}${JDK_HOME}/jre/lib/security/cacerts
+ ln -s ${@os.path.relpath("${sysconfdir}/ssl/certs/java/cacerts", "${JDK_HOME}/jre/lib/security/cacerts")} \
+ ${D}${JDK_HOME}/jre/lib/security/cacerts
+ fi
+ if [ -d ${D}${JRE_HOME} ] ; then
+ rm ${D}${JRE_HOME}/lib/security/cacerts
+ ln -s ${@os.path.relpath("${sysconfdir}/ssl/certs/java/cacerts", "${JRE_HOME}/lib/security/cacerts")} \
+ ${D}${JRE_HOME}/lib/security/cacerts
+ fi
}

export MAKE_VERBOSE = "y"


Re: devtool finish & patch order

Alexander Kanavin
 

2018-06-15 2:11 GMT+03:00 Peter Kjellerstedt <peter.kjellerstedt@...>:
* `devtool modify -w <some simple package>`
* Modify some file, e.g., add some comment to the Makefile.
* Commit it with subject "Change 1"
* Repeat the two steps above two more times, increasing the number in
the subject each time.
* `devtool finish <some simple package> <layer where the recipe is>`
* Examine the updated recipe. In my case the patches were in the correct
order after this step:

SRC_URI = "<original URI> \
file://0001-Change-1.patch \
file://0002-Change-2.patch \
file://0003-Change-3.patch \
"

* Not to be discouraged, I started over (using the existing source dir):
* `devtool modify -n <some simple package>`
* `git rebase -i 'HEAD~3'` (in workspace/sources/<some simple package>)
* Use "reword" on the last two commits and change their subject lines
to "Another change" and "Some third change".
* `devtool finish <some simple package> <some other layer than where the recipe is>`
* Now I ended up with the following in the new .bbappend file:

SRC_URI += "file://0002-Another-change.patch file://0003-Some-third-change.patch file://0001-Change-1.patch"
Wait, what would be the correct thing for devtool to do here? The
original patches are already added to the recipe in the original
layer, so .bbappend
would have to first revert them and add newly modified ones? I don't
think devtool is that clever :) Does it add the patches correctly, if
you repeat
the first half of the sequence (adding new patches), but use devtool
finish to save changes to a diffferent layer?

Alex


Re: devtool finish & patch order

Peter Kjellerstedt
 

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Alexander Kanavin
Sent: den 14 juni 2018 09:07
To: Tim Hammer <tdhammer99@...>
Cc: Yocto discussion list <yocto@...>
Subject: Re: [yocto] devtool finish & patch order

2018-06-14 7:02 GMT+03:00 Tim Hammer <tdhammer99@...>:

My changes for U-Boot are not working as expected. I am wondering-
did I use
devtool incorrectly?

I used 'devtool modify' to create a working copy of the vendor's u-
boot and
copied & modified files to add support for my custom board. I did my
work in
3 distinct and commitable steps, resulting in 3 patch files in my
layer when
I ran 'devtool finish'.

When I pulled the changes into another clone for validation, it
appears to
be applying patches in reverse order! It is attempting to apply patch
003
but cannot find the file to modify. That file was created in patch
001. None
of the files created in patch 001 are in my working directory.

I reversed the order of the patch files in the .bbappend file and it
worked
fine.

Do I need to use the tool differently to get the patches correctly
applied?

Devtool should add newly added patches to the recipe in the same order
as the commits you created in workdir repo. If that is not the case,
please provide the steps that reproduce the issue.

Alex
It should, but there does not seem to be a guarantee that it does.
To (hopefully) reproduce the problem, here is what I did:

* `devtool modify -w <some simple package>`
* Modify some file, e.g., add some comment to the Makefile.
* Commit it with subject "Change 1"
* Repeat the two steps above two more times, increasing the number in
the subject each time.
* `devtool finish <some simple package> <layer where the recipe is>`
* Examine the updated recipe. In my case the patches were in the correct
order after this step:

SRC_URI = "<original URI> \
file://0001-Change-1.patch \
file://0002-Change-2.patch \
file://0003-Change-3.patch \
"

* Not to be discouraged, I started over (using the existing source dir):
* `devtool modify -n <some simple package>`
* `git rebase -i 'HEAD~3'` (in workspace/sources/<some simple package>)
* Use "reword" on the last two commits and change their subject lines
to "Another change" and "Some third change".
* `devtool finish <some simple package> <some other layer than where the recipe is>`
* Now I ended up with the following in the new .bbappend file:

SRC_URI += "file://0002-Another-change.patch file://0003-Some-third-change.patch file://0001-Change-1.patch"

Also noteworthy is the different formattings used when updating the
SRC_URI in the original recipe vs the bbappend file. The format
used in the bbappend file is not one I would have chosen (personally
I prefer to use SRC_URI += "..." for each patch, so that no other
lines need to be modified when adding the first patch or removing
the last one).

//Peter


[ANNOUNCEMENT] Yocto Project 2.4.3 (rocko-18.0.3) Released

Tracy Graydon <tracy.graydon@...>
 

Hello,

The latest release of the Yocto Project 2.4.3 (rocko-18.0.3) is now available for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.3/poky-rocko-18.0.3.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.3/poky-rocko-18.0.3.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.3/RELEASENOTES

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW24_-_2018-06-12-_Full_Test_Cycle_-_2.4.3_rc2

Thank you to everyone for your contributions to this release!

Tracy Graydon
Yocto Project Release Engineering
tracy.graydon@...


------------------
yocto-2.4.3 Errata
--------------------

Release Name: eclipse-poky-neon-rocko-18.0.3
Branch: neon/rocko
Tag: neon/rocko-18.0.3
Hash: a5dbc01b96be55c4ec2f774af9996a8086e402ab
md5: 54e8fca5fa246c43845721ec9e0c709b
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.3/eclipse-poky-neon-rocko-18.0.3.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.3/eclipse-poky-neon-rocko-18.0.3.tar.bz2

Release Name: eclipse-poky-oxygen-rocko-18.0.3
Branch: oxygen/rocko
Tag: oxygen/rocko-18.0.3
Hash: 020fc5814d2028654879356296b647002caf30b6
md5: f61add93dc74f864a4d66d62249b4bf7
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.3/eclipse-poky-oxygen-rocko-18.0.3.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.3/eclipse-poky-oxygen-rocko-18.0.3.tar.bz2

Release Name: meta-qt3-rocko-18.0.3
Branch: rocko
Tag: rocko-18.0.3
Hash: 8ef7261a331e0869a0461ab2fb44e39980cedc02
md5: d9fc8c6550d7352dd9176a1ce980bdf4
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.3/meta-qt3-rocko-18.0.3.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.3/meta-qt3-rocko-18.0.3.tar.bz2

Release Name: meta-qt4-rocko-18.0.3
Branch: rocko
Tag: rocko-18.0.3
Hash: e290738759ef3f39c9e079eaa9b606a62107e5ba
md5: df426f563fca33a943aa9cef5bd20903
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.3/meta-qt4-rocko-18.0.3.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.3/meta-qt4-rocko-18.0.3.tar.bz2

Release Name: poky-rocko-18.0.3
Branch: rocko
Tag: rocko-18.0.3
Hash: 7e7ee662f5dea4d090293045f7498093322802cc
md5: fabf3fa0506a8a487b1b79c8f108de0b
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.3/poky-rocko-18.0.3.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.3/poky-rocko-18.0.3.tar.bz2


---------------
Known Issues
---------------
Toaster for Rocko:

- There are two patches that fix toaster issues that did not make it into this release. These fixes are on the Poky rocko and bitbake rocko/1.36 branches.
The first patch fixes an error that breaks the initialization of Toaster. The second patches fixes a change in behavior for Django that creates
an extra thread that blocks Toaster from shutting down. These issues only affect Toaster and do not affect the rest of the release.


- https://bugzilla.yoctoproject.org/show_bug.cgi?id=12751: django fails for 'optional' fixture 'custom.xml'

Toaster looks for and will include the optional fixture file "custom.xml". The test for this file relied on a passive fail if the file was not found. This is now a hard fail that breaks Toaster startup.
Solution is to wrap the load command with a "try" and passive "except".

Fix is on Rocko branch:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=rocko&id=9c3da34ec6c2c9a9abc30c72d6a8f9b996250862


---------------
Security Fixes
---------------
libnl: fix CVE-2017-0553
perl: Security fix CVE-2017-12883
patch: fix CVE-2018-1000156
patch: fix CVE-2018-6951
dhcp: Security Advisory - CVE-2017-3144
libvorbis: CVE-2018-5146
libvorbis: CVE-2017-14632
libvorbis: CVE-2017-14633
lame: revert "lame: fix CVE-2017-13712"


------
Fixes
------
documentation: Prepped set for a 2.4.3 release
ref-manual: Updated SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS variable
bsp-guide: Fixed manual title in title page note
ref-manual: Updated the SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS variable
documentation: Updated manual notes
bitbake: toaster: do not fail on optional 'custom.xml' file
bitbake: Toaster: fix shutdown and extra threads
build-appliance-image: Update to rocko head revision
poky: Bump version to 2.4.3
meta-yocto-bsp: bump to the latest v4.12 stable kernel for the non-x86 BSPs
linux-yocto: update genericx86* SRCREVs for 4.12
ncurses: Abstract out termlib
ncurses: fix deletion of /usr/lib/terminfo
ncurses: fix do_install failure when base_libdir has more than one level
ncurses: 6.0+20170715 -> 6.0+20171125
package.py: use single quotes for path passed to file in is_elf()
package.bbclass: Add '-b' option to file call in isELF
package.bbclass: use single quotes for path passed to file in isELF()
Revert "package.bbclass: Add '-b' option to file call in isELF"
ruby: Update to 2.4.4
ruby: fix typo in gmp PACKAGECONFIG option
ruby: remove spurious db build dependency
ruby: upgrade to 2.4.2
grub/grub-efi: fix conflict
scripts/test-dependencies.sh: remove
Revert "waf.bbclass: explicitly pass bindir and libdir if supported"
perl: add patch to solve libcrypt incompatibility
rsync: update to 3.1.3
mpfr: Update SRC_URI to use gnu
uninative: Set the dynamic linker to use at compile time
uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds
bitbake.conf: Set and export TZ envvar to UTC
yocto-uninative: Update to version 1.9 (fedora28 compatible)
package.bbclass: Add '-b' option to file call in isELF
patch:2.7.5 -> 2.7.6
gio-module-cache.bbclass: pass in ${libexecdir}
uninative: add variables to the whitelist so that it does not re-triger recipe parsing
package_manager.py: Skip gpgcheck while using dnf on target
libpcre-ptest: skip locale test
openssl: update 1.1.0g -> 1.1.0h
openssl: update 1.0.2n -> 1.0.2o
openssl: fix libdir logic to allow multiarch style paths
openssl: drop openssl-1.0.2a-x32-asm.patch
openssl: refresh patches
package_rpm: set _builddir to B not S
linux-yocto/4.12: intel-socfpga, intel-pmc-core and ish support for CoffeeLake board
linux-yocto/meta: improve wifi driver granularity
linux-yocto/4.12: add ssl and utils native dependencies
linux-yocto/4.12: update to v4.12.21
mirrors.bbclass: change Debian anonscm to salsa
ca-certificates: change SRC_URI from Debian anonscm to salsa
ncurses: change SRC_URI from Debian anonscm to salsa
curl: DEPENDS on libidn2 (not libidn)
libxml2: 2.9.4 -> 2.9.5
curl: upgrade to 7.58.0
curl: 7.54.1 -> 7.57.0
logging.bbclass: Enclose the tr string in quotes
bitbake.conf: Add comm to HOSTTOOLS
lttng-modules: update to v2.10.5 for kernel 4.15
lttng-ust: upgrade 2.9.1 -> 2.10.1
lttng-modules: upgrade 2.9.5 -> 2.10.4
distcc: Change SRC_URI
e2fsprogs: fix compatibility with glibc 2.27
openssl_1.0.2n: improve reproducibility
checklayer: remove reference to undefined class
valgrind: Fix multilib header conflict - valgrind/config.h
tiff: Fix multilib header conflict - tiffconf.h
scripts/oe-build-perf-report: fix comparing arbitrary commits
ca-certificates: run postinst script only for -target package
linux-yocto/4.12: backport bugfixes for x86
linux-yocto/4.12: warning: drm/i915/cfl: Coffee Lake works on Kaby Lake PCH
linux-yocto/4.12: memleak and build warning fixes
linux-yocto/4.12: fix aufs compile warning
linux-yocto/4.12: add stratix10 SoC development board
qemu: fix memfd_create with glibc 2.27
package-manager: add install_glob()
package_manager: improve install_complementary
sdk: generate locale archive and remove packages
populate_sdk_base: depend on nativesdk-glibc-locale
populate_sdk: install UTF-8 locales in SDKs
sdk: only install locales if we're using glibc
sdk: install specified locales into SDK
cross-localedef-native: add way to specify which locale archive to write
glibc: relocate locale paths in nativesdk
glibc: don't use host locales in nativesdk
default-distrovars: don't rename locales for nativesdk
beaglebone: Find /boot partition on mmcblk0
gcc: Fix internal compiler error for PPC test case "gcc.dg/vmx/7d-02.c"
gcc: Fix test case issue when SSE is not enabled
maintainers.inc: add myself as maintainer for the new busybox-inittab
layer.conf: add busybox-inittab to SIGGEN_EXCLUDERECIPES_ABISAFE
busybox: separate inittab into own package, due to SERIAL_CONSOLES being machine-specific
package_manager.py: Explicit complementary fail
go: Upgrade 1.9 to 1.9.4 stable release
uninative: Add compatiblity version check
yocto-uninative: Upgrade to 1.8 version with glibc 2.27
unfs3: Fix libtirpc usage for unfs3-native version
libtirpc: Extend to native and nativesdk recipes
unfs3: Fix build with musl
gcc6: Patch to fix broken gcc-sanitizers build
gdb: fix header ordering for TRAP_HWBKPT
glibc: add missing TRAP_BRANCH/TRAP_HWBKPT definitions
gcc: Remove patch causing ICE on x86_64 valgrind compile
gcc6: Backport few more patches
gcc6: enable FL_LPAE flag for armv7ve cores
gcc7/gcc6: Fix unaligned STRD issue on ARM
gcc6: Upgrade to 6.4
gcc: Fix libssh_nonshared linker specs for ppc/musl
gcc: Link libssp_nonshared.a only on musl targets
gcc-runtime: Disable libitm on riscv
bitbake: providers: Fix determinism issue
glibc: Update to tip of 2.26
glibc: Adapt do_install_append_aarch64() for usrmerge
libtirpc: refresh patches
libtirpc: stop dropping in NIS headers
libunwind: Fix multilib header conflict - libunwind.h
libmpc: fix SRC_URI
siteinfo: add aarch64_illp32 decode
update-rc.d: QA regression.
webkitgtk_2.18.6.bb: Fix configure failure for aarch64 build
eglinfo-fb: Pass -DMESA_EGL_NO_X11_HEADERS to cxxflags
openssl: remove patch from 1.0.2m left behind after update to 1.0.2n
p11-kit: take source code from official git


Re: qemu-native build fails on sumo due to missing capstone.h

Khem Raj
 



On Thu, Jun 14, 2018 at 1:08 PM Jon Szymaniak <jon.szymaniak@...> wrote:
On Thu, Jun 14, 2018 at 14:18 Khem Raj <raj.khem@...> wrote:
On Thu, Jun 14, 2018 at 9:56 AM Jon Szymaniak <jon.szymaniak@...> wrote:
>
> On Thu, Jun 14, 2018 at 11:43 Khem Raj <raj.khem@...> wrote:
> > Do you have capstone development headers/libs installed on your build host ?
> >
>
> No, and I understand that's an easy thing to address on the build host.
>
> However, I don't think this should be necessary build host dependency.
> QEMU includes the capstone codebase as a git submodule, so everything
> that's needed is there.
>
> Maybe it's just a matter of tweaking the recipe to set
> CMAKE_INSTALL_PREFIX appropriately so that when the build dives down
> into the capstone directory, this points to the correct prefix?
>
> It looks like the inclusion and use of capstone is new, as of the QEMU
> version included with sumo. (i.e. This appears not to be the situation
> with the version used in rocko and pyro).

Least intrusive approach would be to disable it if its not something you
depend on.

Makes sense, thank you. 

Two workarounds that worked for me were either adding qemu-native to ASSUME_PROVIDED or appending “--disable-capstone” to qemu’s EXTRA_OECONF.

The fact that not everyone sees this issue makes me think that it might be something in your environment that’s triggering this but if we disable it then we make the issue irrelevant 

I’ll try to follow up with a patch to the recipe in oe-core, unless you suspect that the source of this is merely something on my end.


Re: How handle files needing updates in read-only filesystem

Ulf Samuelsson
 

I looked at the populate-volatile.sh, and this seemed to almost do the job,
if I solve the problem using symlinks.
What it needs is a copy file function.
As a temporary solution, I created a derivative: populate-settings.sh
which will check /etc/default/settings in the same way populate-volatile.sh
checks /etc/default/volatiles.

It also support copying a file, if the copy target does not exist.

What I have right now is a ”writeable.bbclass”
To make a file located in a read-only location, I just inherit writeable and declare it writeable in a bbappend.

inherit writeable
WRITEABLE = ”/etc/localtime”

At build time, the ”/etc/localtime” is moved to ”/etc/update/localtime”, and ”/etc/localtime” becomes a symlink to ”/persistent/localtime”
(a leading ”/etc” is shaved off)
An entry to copy ”/etc/update/localtime” to “/persistent/localtime” is created in
“/etc/default/settings/99_tzdata”
When “/etc/init.d/populate-settings.sh” is run, “/persistent/localtime” is created.

This works.

Efficiency is on several levels.
I am looking for a solution, where I, like above, only need to declare the name of the file. I want to avoid solutions, where I manually have to add symlinks etc.

Once the symlink/bind mount is accessed, it should not eat up the CPU cycles,
Kno
Best Regards,
Ulf Samuelsson

14 juni 2018 kl. 01:02 skrev Andre McCurdy <armccurdy@...>:

On Wed, Jun 13, 2018 at 9:28 AM, Ulf Samuelsson <yocto@...> wrote:
Thanks, is it more efficient than symlinking?
Efficient in what way?

Have you looked at the volatile-binds recipe in oe-core? Its job is to
setup enough bind mounts to enable systemd to run from a readonly
rootfs. Although it's currently systemd specific (it only provides a
systemd service file, no init script) it might give you some clues
about how to setup bind mounts at boot time.

Best Regards,
Ulf Samuelsson

13 juni 2018 kl. 15:20 skrev Anders Darander <anders@...>:

* Ulf Samuelsson <yocto@...> [180612 22:01]:

We want most of /etc to be read-only for security reasons,
and the overlayfs will make the whole of /etc writeable.
I tried mount —bind /etc/timezone /persistent/etc/timezone, and it
complained that they were not directories. Bind mounting /etc again
will make all of /etc writeable.
Try to use: mount —o bind /etc/timezone /persistent/etc/timezone

I'm using that heavily, either manually or by the volatile-binds recipe.
It works perfectly fine with files.

Symlinking to /persistent is fine, so the question is what an
acceptable method is to have a simple way of ensuring that a certain
file is converted to that symlink.
This is normally done by a manual inspection / addition of bbappend
file.

Cheers,
Anders
--
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Issue when integrating different bsp-layers on a single bblayers.conf

Peter Kjellerstedt
 

Just thought I should mention that since Krogoth, BBMASK is actually a list of regular expressions, so your example below is better written as:

 

BBMASK += "${@bb.utils.contains('MACHINE', '<rockchip>', '', '/meta-rockchip/recipes-.*', d)}"

 

(including changing base_conditional() to bb.utils.contains(), and correcting the regular expression).

 

//Peter

 

From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Ulf Samuelsson
Sent: den 7 juni 2018 17:27
To: Iván Castell <icastell@...>
Cc: Yocto Project <yocto@...>
Subject: Re: [yocto] Issue when integrating different bsp-layers on a single bblayers.conf

 

Maybe something similar to this in local.conf

 

BBMASK .= "${@base_conditional('MACHINE', '<rockchip>', '','|meta-rockchip/recipes-*', d)}"

(did not test)

If there are multiple machines in the meta-rockchip layer, you have to look for a unique variable which is true only if a machine in the meta-rockchip layer is used.

 

 

Best Regards,

Ulf Samuelsson


7 juni 2018 kl. 16:39 skrev Iván Castell <icastell@...>:

Hello forum.

 

I am trying to integrate several BSP-layers for different platforms on a single Yocto repository to build a Linux Yocto-based distro for all those platforms easily.

 

The idea is maintaining a single bblayers.conf with all the layers available, set PLATFORM and DISTRO on local.conf, call bitbake <image> and get the final image for that platform.

 

When setting the "build" directory with a bblayers.conf customized for a single platform, each platform builds the image recipe properly.

 

However, when I have integrated all bsp-layers in a single bblayers.conf, the compilation of some platforms has been broken.

 

The specific problem is this: one bsp layer (meta-rockchip + meta-rockchip-extra) defines a recipes-graphics/mesa/mesa_%.bbappend with this content inside:



    PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl virtual/libwayland-egl"



That alters gstreamer recipe on the poky layer, getting this error when building for a meta-intel platform:

 

    ERROR: Nothing PROVIDES 'virtual/egl' (but /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb, /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.2.bb DEPENDS on or otherwise requires it)

 

My questions:

 

    - Is a good practice to define a custom bblayers.conf depending on the choosen PLATFORM?

    - Is there some any other way to disable a BSP-layer completely when building for a different one?

    - Can you suggest a fix to solve this issue?

 

Thanks a lot in advance! :)

 

Kind regards.

  -- Ivan

 

 

--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Issue yocto strip the kernel module signature during packaging

Mark Hatle <mark.hatle@...>
 

On 6/13/18 12:10 PM, Mathieu Alexandre-Tétreault wrote:
Hello,

I am working to activate the kernel module signature for in-tree and out-of-tree packages.
While I was debugging the cause of the kernel complaining about unsigned modules.
I noticed that yocto was stripping the signature information from the binary, therefore I've
set INHIBIT_PACKAGE_STRIP = "1" for all of my out-of-tree module. Then I had to set the flag
for the kernel recipe to fix the issue for my in-tree kernel module.
This sounds like a bug, it should not be stripping that part of the data.. only
debug information.

My question is:
- is there any issue with turning off the stripping for the linux recipe? I'd like to be sure I haven't overlooked anything about this.
The kernel and modules will become much larger.

- Would there be a better way to achieve this?
The code runs from meta/classes/package.bbclass, function split_and_strip_files,
near the end you will see:

if (d.getVar('INHIBIT_PACKAGE_STRIP') != '1'):
strip = d.getVar("STRIP")
sfiles = []
for file in elffiles:
elf_file = int(elffiles[file])
#bb.note("Strip %s" % file)
sfiles.append((file, elf_file, strip))
for f in kernmods:
sfiles.append((f, 16, strip))

oe.utils.multiprocess_exec(sfiles, oe.package.runstrip)


The last line executes oe.package.runstrip, which is defined in
meta/lib/oe/package.py. It uses the arguments defined by:

# kernel module
if elftype & 16:
stripcmd.extend(["--strip-debug", "--remove-section=.comment",
"--remove-section=.note", "--preserve-dates"])
# .so and shared library
elif ".so" in file and elftype & 8:
stripcmd.extend(["--remove-section=.comment", "--remove-section=.note",
"--strip-unneeded"])
# shared or executable:
elif elftype & 8 or elftype & 4:
stripcmd.extend(["--remove-section=.comment", "--remove-section=.note"])

First verify that it's using the kernel module, as expected -- assuming it is --
you'll need to find the section that has the information you care about it in..
and figure out how to preserve it with the right arguments.

--Mark

Cheers,

Mathieu


Re: qemu-native build fails on sumo due to missing capstone.h

Jon Szymaniak <jon.szymaniak@...>
 

On Thu, Jun 14, 2018 at 14:18 Khem Raj <raj.khem@...> wrote:
On Thu, Jun 14, 2018 at 9:56 AM Jon Szymaniak <jon.szymaniak@...> wrote:
>
> On Thu, Jun 14, 2018 at 11:43 Khem Raj <raj.khem@...> wrote:
> > Do you have capstone development headers/libs installed on your build host ?
> >
>
> No, and I understand that's an easy thing to address on the build host.
>
> However, I don't think this should be necessary build host dependency.
> QEMU includes the capstone codebase as a git submodule, so everything
> that's needed is there.
>
> Maybe it's just a matter of tweaking the recipe to set
> CMAKE_INSTALL_PREFIX appropriately so that when the build dives down
> into the capstone directory, this points to the correct prefix?
>
> It looks like the inclusion and use of capstone is new, as of the QEMU
> version included with sumo. (i.e. This appears not to be the situation
> with the version used in rocko and pyro).

Least intrusive approach would be to disable it if its not something you
depend on.

Makes sense, thank you. 

Two workarounds that worked for me were either adding qemu-native to ASSUME_PROVIDED or appending “--disable-capstone” to qemu’s EXTRA_OECONF.

I’ll try to follow up with a patch to the recipe in oe-core, unless you suspect that the source of this is merely something on my end.


Re: Build failure when BUILDHISTORY_FEATURES includes "package"

Khem Raj
 

On Thu, Jun 14, 2018 at 10:58 AM Jon Szymaniak
<jon.szymaniak.foss@...> wrote:

Hi all,

I'm encountering the following error, which I can reproduce with qemu
targets, core-image-minimal, a default bblayers.conf, and the
following additions to an otherwise default local.conf:

INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "0"
BUILDHISTORY_FEATURES = "package"


ERROR: core-image-minimal-dev-1.0-r0 do_packagedata_setscene: The
recipe core-image-minimal-dev is trying to install files into a shared
area when those files already exist. Those files and their manifest
location are:
${TMPDIR}/pkgdata/qemux86-64/runtime/core-image-minimal-dev
(matched in manifest-qemux86_64-core-image-minimal.packagedata)
Please verify which recipe should provide the above files.

My build host is XUbuntu-17.10 -- not officially supported so I
understand my mileage may vary. If no one else is seeing this, I can
follow up with some logs, try a supported LTS next week, and try to
report back with a root cause.

Mostly just trying to confirm this isn't PEBKAC ... ;)
I tried with these options added, I do not see the errors you are seeing

NOTE: Tasks Summary: Attempted 2305 tasks of which 1745 didn't need to
be rerun and all succeeded.
NOTE: No commit since BUILDHISTORY_COMMIT != '1'
NOTE: Build completion summary:


Cheers,
Jon
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

16321 - 16340 of 57804