Date   

Re: Including binary application as part of the image output

Chuck Wolber
 

Your company's application should be built within its _own_ bitbake recipe and then pulled into your image with an RDEPENDS entry in your image build recipe.

If you do it that way, you can find the packaged version of your application in the tmp/deploy directory automatically.

..Ch:W..


On Wed, Jan 27, 2021 at 10:32 AM chuck kamas via lists.yoctoproject.org <chuckkamas=yahoo.com@...> wrote:
Hi all,


As part of our image we build our company's application. This
application becomes part of the image and is executed when the image boots.

My question is how to have the binary image also be available along with
the image's wic file? Is there a line I can add to a recipe to have it
copy that image file to the tmp/deploy directory or other appropriate
directory so that it is available?


Thanks!

Chuck







--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Including binary application as part of the image output

chuck kamas
 

Hi all,


As part of our image we build our company's application. This application becomes part of the image and is executed when the image boots.

My question is how to have the binary image also be available along with the image's wic file? Is there a line I can add to a recipe to have it copy that image file to the tmp/deploy directory or other appropriate directory so that it is available?


Thanks!

Chuck


Kernel Initramfs Problems

Martin Townsend <mtownsend1973@...>
 

Hi,

I'm trying to get an initramfs working so I can load firmware early
enough in the boot. So I've created an initramfs with the firmware
files and a script to switch to the main root. I've set the following

# Use the FIT image format
KERNEL_IMAGETYPES += "fitImage"
KERNEL_CLASSES += "kernel-fitimage"
KERNEL_IMAGETYPE = "fitImage"
KERNEL_IMAGETYPE_aarch64 = "fitImage"

# Add the initramfs for loading the firmware files
INITRAMFS_IMAGE_BUNDLE = "1"
INITRAMFS_IMAGE = "octave-cad-image-initramfs"
INITRAMFS_FSTYPES = "cpio.gz"

in a configuration file. According to the docs for INITRAMFS_IMAGE_BUNDLE:
"The unpacked initramfs image is then passed to the kernel's Makefile
using the CONFIG_INITRAMFS_SOURCE variable, allowing the initramfs
image to be built into the kernel normally. "

Perfect, this is exactly what I want. Now I'm expecting the kernel
image to contain the initramfs using CONFIG_INITRAMFS_SOURCE and not
include the initramfs in the FIT image as an image configuration that
U-Boot extracts and passes to the kernel.

But I'm not seeing this. I get two FIT images deployed, one with an
initramfs included as a configuration and a FIT image without. This
doesn't seem right as the initramfs should already be in the kernel so
including it in the FIT image means it would be there twice. Ignoring
this the FIT image without an initramfs in the filename should still
have the initramfs in the kernel via CONFIG_INITRAMFS_SOURCE but it's
not there. When booting this image I don't see the firmware loading

[ 0.629648][ T12] imx-sdma 302b0000.dma-controller: Direct
firmware load for imx/sdma/sdma-imx7d.bin failed with error -2
[ 0.638320][ T12] imx-sdma 302b0000.dma-controller: Falling back
to sysfs fallback for: imx/sdma/sdma-imx7d.bin

Now if I boot the FIT image with the initramfs in the filename I get

[ 0.713335][ T12] imx-sdma 302b0000.dma-controller: loaded firmware 4.5

early in the boot so I know the initramfs works.

So you could say use the FIT image with the initramfs in its filename
but this isn't the FIT image that gets installed by
packagegroup-core-boot and I can't find out how to use the other FIT
image. I would prefer to bundle the initramfs into the kernel and not
rely on the FIT image mechanism.

I've tried building the kernel with all the INITRAMFS_* variables
commented out and the file sizes are nearly the same, not quite but
nearly. The initramfs is around 4MiB in size due to firmware files,
busybox and the libraries that this requires to perform the
switch_root. This also suggests that CONFIG_INITRAMFS_SOURCE isn't
working.

I've built the kernel with verbose on and see
+ use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build/usr/octave-cad-image-initramfs-octave-imx8mnevk.cpio


and also
+ oe_runmake [snip]
CONFIG_INITRAMFS_SOURCE=/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build/usr/octave-cad-image-initramfs-octave-imx8mnevk.cpio

So it looks like this doesn't work for some reason. I am using NXP's
vendor specific kernel but I don't think they've touched the kernel's
build system. The kernel version is 5.4. The log does contain what
looks like the Makefile actually performing the steps required

GEN Makefile

scripts/kconfig/conf --syncconfig Kconfig

GEN Makefile

CALL /ws/rufilla/octopus/octave-dunfell/build-release/tmp/work-shared/octave-imx8mnevk/kernel-source/scripts/checksyscalls.sh

CALL /ws/rufilla/octopus/octave-dunfell/build-release/tmp/work-shared/octave-imx8mnevk/kernel-source/scripts/atomic/check-atomics.sh

CHK include/generated/compile.h

GEN usr/initramfs_data.cpio

AS usr/initramfs_data.o

AR usr/built-in.a

GEN .version

CHK include/generated/compile.h

LD vmlinux.o

MODPOST vmlinux.o

MODINFO modules.builtin.modinfo

LD .tmp_vmlinux1

KSYM .tmp_kallsyms1.o

LD .tmp_vmlinux2

KSYM .tmp_kallsyms2.o

LD vmlinux

SORTEX vmlinux

SYSMAP System.map

OBJCOPY arch/arm64/boot/Image

${B}/usr seems ok

drwxr-xr-x 2 martin martin 4096 Jan 27 17:19 .
drwxr-xr-x 20 martin martin 4096 Jan 27 17:19 ..
-rw-rw-r-- 1 martin martin 146 Jan 27 17:19 built-in.a
-rw-r--r-- 1 martin martin 109 Jan 27 17:19 .built-in.a.cmd
-rwxr-xr-x 1 martin martin 31320 Jan 27 17:14 gen_init_cpio
-rw-r--r-- 1 martin martin 6642 Jan 27 17:14 .gen_init_cpio.cmd
-rw-r--r-- 1 martin martin 512 Jan 27 17:14 initramfs_data.cpio
-rw-r--r-- 1 martin martin 188 Jan 27 17:14 .initramfs_data.cpio.cmd
-rw-r--r-- 1 martin martin 142 Jan 27 17:15 .initramfs_data.cpio.d
-rw-rw-r-- 1 martin martin 1504249 Jan 27 17:19 initramfs_data.cpio.gz
-rw-rw-r-- 1 martin martin 389 Jan 27 17:19 .initramfs_data.cpio.gz.cmd
-rw-rw-r-- 1 martin martin 329 Jan 27 17:19 .initramfs_data.cpio.gz.d
-rw-rw-r-- 1 martin martin 1505240 Jan 27 17:19 initramfs_data.o
-rw-r--r-- 1 martin martin 4631 Jan 27 17:19 .initramfs_data.o.cmd
-rw-r--r-- 1 martin martin 2939392 Jan 27 17:15
octave-cad-image-initramfs-octave-imx8mnevk.cpio

I'm wondering if there is maybe a race condition somewhere in the
build. I say this because after the initial build I see the following

ls -la arch/arm64/boot/
total 50684
drwxr-xr-x 3 martin martin 4096 Jan 27 18:01 .
drwxr-xr-x 9 martin martin 4096 Jan 27 18:00 ..
drwxr-xr-x 3 martin martin 4096 Jan 27 18:00 dts
-rwx------ 1 martin martin 7218640 Jan 27 18:00 fitImage
-rwx------ 1 martin martin 10239756 Jan 27 18:01
fitImage-octave-cad-image-initramfs
-rw-r--r-- 1 martin martin 15876608 Jan 27 18:00 Image
-rw-r--r-- 1 martin martin 143 Jan 27 18:01 .Image.cmd
-rw-rw-r-- 1 martin martin 18825728 Jan 27 18:01 Image.initramfs
lrwxrwxrwx 1 martin martin 16 Jan 27 18:00 vmlinux -> ../../../vmlinux


Now if I manually from do_assemble_fitimage again I get
./temp/run.do_assemble_fitimage
gzip
fit-image.its:8.26-20.19: Warning (unit_address_vs_reg):
/images/kernel@1: node has a unit name, but no reg property
fit-image.its:17.32-19.27: Warning (unit_address_vs_reg):
/images/kernel@1/hash@1: node has a unit name, but no reg property
fit-image.its:21.60-31.19: Warning (unit_address_vs_reg):
/images/fdt@freescale_octopus,octave-imx8mnevk.dtb: node has a unit
name, but no reg property
fit-image.its:28.32-30.27: Warning (unit_address_vs_reg):
/images/fdt@freescale_octopus,octave-imx8mnevk.dtb/hash@1: node has a
unit name, but no reg property
fit-image.its:36.61-45.19: Warning (unit_address_vs_reg):
/configurations/conf@freescale_octopus,octave-imx8mnevk.dtb: node has
a unit name, but no reg property
fit-image.its:42.32-44.27: Warning (unit_address_vs_reg):
/configurations/conf@freescale_octopus,octave-imx8mnevk.dtb/hash@1:
node has a unit name, but no reg property
FIT description: U-Boot fitImage for Octopus Energy Octave Linux
OS/5.4.24+gitAUTOINC+babac008e5/octave-imx8mnevk
Created: Sat May 30 07:25:46 2020
Image 0 (kernel@1)
Description: Linux kernel
Created: Sat May 30 07:25:46 2020
Type: Kernel Image
Compression: gzip compressed
Data Size: 8692100 Bytes = 8488.38 KiB = 8.29 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x40480000
Entry Point: 0x40480000
Hash algo: sha256
Hash value: 3c2213b560910ff59f04307e6531ad6bd55c21e17d559c3a5d4f1927e23d4c1a
Image 1 (fdt@freescale_octopus,octave-imx8mnevk.dtb)
Description: Flattened Device Tree blob
Created: Sat May 30 07:25:46 2020
Type: Flat Device Tree
Compression: uncompressed
Data Size: 35902 Bytes = 35.06 KiB = 0.03 MiB
Architecture: AArch64
Hash algo: sha256
Hash value: 63b81215384c3b243a538f8f738e3d9ea0c8496373cf47c2a138838f88bbe90c
Default Configuration: 'conf@freescale_octopus,octave-imx8mnevk.dtb'
Configuration 0 (conf@freescale_octopus,octave-imx8mnevk.dtb)
Description: 1 Linux kernel, FDT blob
Kernel: kernel@1
FDT: fdt@freescale_octopus,octave-imx8mnevk.dtb
Hash algo: sha256
Hash value: unavailable
martin@martin-X570-AORUS-ELITE:/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0$
ls -la build/arch/arm64/boot/total 52160
drwxr-xr-x 3 martin martin 4096 Jan 27 18:06 .
drwxr-xr-x 9 martin martin 4096 Jan 27 18:00 ..
drwxr-xr-x 3 martin martin 4096 Jan 27 18:00 dts
-rwx------ 1 martin martin 8730032 Jan 27 18:06 fitImage
-rwx------ 1 martin martin 10239756 Jan 27 18:01
fitImage-octave-cad-image-initramfs
-rw-r--r-- 1 martin martin 15876608 Jan 27 18:00 Image
-rw-r--r-- 1 martin martin 143 Jan 27 18:01 .Image.cmd
-rw-rw-r-- 1 martin martin 18825728 Jan 27 18:01 Image.initramfs
lrwxrwxrwx 1 martin martin 16 Jan 27 18:00 vmlinux -> ../../../vmlinux

Now the FIT image looks like it contains the initramfs. I tried
booting it and the firmware files were loaded. Looking at the
original log for do_assemble_fitimage I see

FIT description: U-Boot fitImage for Octopus Energy Octave Linux
OS/5.4.24+gitAUTOINC+babac008e5/octave-imx8mnevk
Created: Sat May 30 07:25:46 2020
Image 0 (kernel@1)
Description: Linux kernel
Created: Sat May 30 07:25:46 2020
Type: Kernel Image
Compression: gzip compressed
Data Size: 7180707 Bytes = 7012.41 KiB = 6.85 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x40480000
Entry Point: 0x40480000
Hash algo: sha256

Note that the kernel image size is 7180707 originally whereas the
second time I run do_assemble_fitimage it's 8692100. It looks like
linux.bin the first time doesn't include the initramfs but on the
second time it does. Note my PC is a fairly rapid AMD Ryzen 9 5950X
16-Core (32 thread) Processor.

I'll keep digging but I would be grateful for any suggestions.

Many Thanks,
Martin.


Re: #yocto bbappenf question #yocto

Quentin Schulz
 

Hi Steve,

On Wed, Jan 27, 2021 at 02:46:55PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

What does it mean when a bbappend files does something like the following to a task layer ?

do_install() {
:
}
This overwrite the do_install task with "nothing".

The ':' character is needed because do_install() {} is not syntaxically
correct.

However, the do_install_prepend and _append would still apply I think.

Cheers,
Quentin


#yocto bbappenf question #yocto

Monsees, Steven C (US)
 

 

What does it mean when a bbappend files does something like the following to a task layer ?

 

do_install() {

         :

}

 

Thanks,

Steve


Issue with packaging a systemd-nspawn container and have it autostart

François GOUDAL
 

Hello,
I am trying to create a recipe for a package that contains a whole systemd-nspawn container (a rootfs that goes into /var/lib/machines/mycontainer) and a system nspawn config file that goes into /etc/systemd/nspawn/mycontainer.nspawn.

Now, I’d like this recipe to make the container start automatically.

This means enabling the service called systemd-nspawn@mycontainer.service

So, I’ve tried to add the following two lines to my bb file:

inherit systemd
SYSTEMD_SERVICE_${PN} = "systemd-nspawn@airmont-gw.service"

But this fails when I build the recipe:

ERROR: mycontainer-1.0-r0 do_package: SYSTEMD_SERVICE_mycontainer value systemd-nspawn@mycontainer.service does not exist

I guess it complains because my own package doesn’t have a file called systemd-nspawn@mycontainer.service but by definition, it won’t have one. So what could be the right way of doing this ?


Different raspberry pi 4 and 3 on same SD card

edmundwatson@...
 

Hello,

I am trying to build a image that work on a raspberry pi 3 and 4.

Does anyone know a way of doing this?

I have tryied copying over bcm2710-rpi-3-b.dtb kernel7.img (the RPi3 kernel) over to  raspberry pi 4  image boot partition
I get a blank screen however.

Thanks

Ed Watson


Re: Points to consider while moving to new yocto versions

Martin Jansa
 

Yes, there are significant diffferences in gcc, see:

The recipes in public layers were already fixed at that time, but if you have a lot of your own C/C++ code in your builds, then expect some fixes needed.

On Wed, Jan 27, 2021 at 10:11 AM amaya jindal <amayajindal786@...> wrote:
Thankyou for your comments and guidance. 

Currently i am trying to first move from krogoth version of yocto to rocko version first that will suffice our requirements but i need to understand whether any major difference is there in gcc 4.9.3 vs gcc 6.4. As krogoth is usin gcc 4.9.3 /5.3 recipe but rocko is using 6.4/7.x as recipe for gcc source compilation. Please guide.

Regards,
Rohit Jindal

On Mon, Jan 25, 2021 at 6:16 PM Robert Berger@... <robert.berger.yocto.user@...> wrote:
Hi,

My comments are in-line

On 25/01/2021 10:07, amaya jindal wrote:
> Hi All,
>
> We are planning to move to New yocto from current one that is krogoth
> yocto to some updated one.

I would consider it "best practice" to somewhat try to stay up to date
with recent yocto versions and plan for this from the beginning of your
project.

What I mean is to have a "stable release" and a "next release" which is
being used in your nightly builds and tests.

This will make it significantly easier to make version upgrades.

> We are not thinking to move to gates-garth or
> some other major release but the releases than can have easily support
> for arm.

I am not sure what you mean by that?

Which versions make it easier/more difficult to support arm?

It's more a question of which chip/kernel/boot loader,...

>
> Please support and help.
>
> Points need to take care to port to new yocto version.

Ssince you use a completely outdated and end of life version[1] it might
require quite some effort to update, but through pain we learn ;)

[1] https://wiki.yoctoproject.org/wiki/Releases

Which chip do you use?

Is it supported by an upstream kernel/boot loader?

Which (additional) layers do you use?

Are these layers supported by the same version as the Yocto version you
want to move to?

How about your own recipes?

Are they compatible with upstream yocto?

>
> Regards,
> Rohit

Regards,

Robert

>
>
>
>





Re: any interest in an official "meta-rubygems" layer?

Jack Mitchell
 

On 27/01/2021 09:17, Jack Mitchell wrote:
On 27/01/2021 09:09, Robert P. J. Day wrote:
On Wed, 27 Jan 2021, Jack Mitchell wrote:
... snip ...

Hi Robert,

This is something I would be interested in. I have a developed a
much more basic rubygems class privately which I had intended to
opensource and create a similar later, so it would be nice to have a
central place to contribute Ruby/RubyGems improvements. As you have
found there are many layers with spotty Ruby support and a
particular copy of an old class that is being banded about which is
often insufficient.
cool ... care to share your rubygems.bbclass file? be great to
combine the best of both worlds.

rday
Please find attached, it's basically the old ruby class with only
support for pure RubyGems (i.e. no cross-compiling) with some influence
from the pypi class for grabbing and compiling a SRC_URI.

Cheers,
Jack.

and a short example of how it's used

cat recipes-devtools/ruby/ruby-pqueue_2.1.0.bb
inherit rubygems

LICENSE = "BSD-2-Clause"
LIC_FILES_CHKSUM = "file://License.txt;md5=8f085d0bb9ef0d1705dc5fd61aaaffa1"

SRC_URI[sha256sum] =
"8b79d9baa303a9747e83877def5a698e0e61d145d4c4275487c79fb1642102a9"


--
Jack Mitchell, Consultant
https://www.tuxable.co.uk


Re: any interest in an official "meta-rubygems" layer?

Jack Mitchell
 

On 27/01/2021 09:09, Robert P. J. Day wrote:
On Wed, 27 Jan 2021, Jack Mitchell wrote:
... snip ...

Hi Robert,

This is something I would be interested in. I have a developed a
much more basic rubygems class privately which I had intended to
opensource and create a similar later, so it would be nice to have a
central place to contribute Ruby/RubyGems improvements. As you have
found there are many layers with spotty Ruby support and a
particular copy of an old class that is being banded about which is
often insufficient.
cool ... care to share your rubygems.bbclass file? be great to
combine the best of both worlds.

rday
Please find attached, it's basically the old ruby class with only
support for pure RubyGems (i.e. no cross-compiling) with some influence
from the pypi class for grabbing and compiling a SRC_URI.

Cheers,
Jack.

--
Jack Mitchell, Consultant
https://www.tuxable.co.uk


Re: Points to consider while moving to new yocto versions

amaya jindal
 

Thankyou for your comments and guidance. 

Currently i am trying to first move from krogoth version of yocto to rocko version first that will suffice our requirements but i need to understand whether any major difference is there in gcc 4.9.3 vs gcc 6.4. As krogoth is usin gcc 4.9.3 /5.3 recipe but rocko is using 6.4/7.x as recipe for gcc source compilation. Please guide.

Regards,
Rohit Jindal

On Mon, Jan 25, 2021 at 6:16 PM Robert Berger@... <robert.berger.yocto.user@...> wrote:
Hi,

My comments are in-line

On 25/01/2021 10:07, amaya jindal wrote:
> Hi All,
>
> We are planning to move to New yocto from current one that is krogoth
> yocto to some updated one.

I would consider it "best practice" to somewhat try to stay up to date
with recent yocto versions and plan for this from the beginning of your
project.

What I mean is to have a "stable release" and a "next release" which is
being used in your nightly builds and tests.

This will make it significantly easier to make version upgrades.

> We are not thinking to move to gates-garth or
> some other major release but the releases than can have easily support
> for arm.

I am not sure what you mean by that?

Which versions make it easier/more difficult to support arm?

It's more a question of which chip/kernel/boot loader,...

>
> Please support and help.
>
> Points need to take care to port to new yocto version.

Ssince you use a completely outdated and end of life version[1] it might
require quite some effort to update, but through pain we learn ;)

[1] https://wiki.yoctoproject.org/wiki/Releases

Which chip do you use?

Is it supported by an upstream kernel/boot loader?

Which (additional) layers do you use?

Are these layers supported by the same version as the Yocto version you
want to move to?

How about your own recipes?

Are they compatible with upstream yocto?

>
> Regards,
> Rohit

Regards,

Robert

>
>
>
>


Re: any interest in an official "meta-rubygems" layer?

Robert P. J. Day
 

On Wed, 27 Jan 2021, Jack Mitchell wrote:
... snip ...

Hi Robert,

This is something I would be interested in. I have a developed a
much more basic rubygems class privately which I had intended to
opensource and create a similar later, so it would be nice to have a
central place to contribute Ruby/RubyGems improvements. As you have
found there are many layers with spotty Ruby support and a
particular copy of an old class that is being banded about which is
often insufficient.
cool ... care to share your rubygems.bbclass file? be great to
combine the best of both worlds.

rday


CMake cannot find installed package #yocto

Vijay Rakesh Munganda
 

Hi,

I had installed a library into the build by writing my own recipe, but cmake couldn't find my installed package. Please anyone suggest what I have to add in my recipe?

CMake Error at recipe-sysroot-native/usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:711 (message):
|   None of the required 'libopentok' found
|   Call Stack (most recent call first):
|   CMakeLists.txt:14 (PKG_SEARCH_MODULE)

Thanks & Regards,
Vijay


[meta-zephyr] bitbake zephyr-helloworld configure failure

Peter Smith <salerio@...>
 

Using master branch

MACHINE=96b_nitrogen bitbake zephyr-helloworld creates a configure error due to a failure for native python to import ruamel.

I fixed this temporarily by creating a python3-ruamel-yaml_%.bbappend that includes the required BBEXTEND and adding python3-ruamel-yaml-native to zephyr-kernel-common.inc.

I don't know (not enough experience) if this is actually a problem in the meta-openembedded recipe or meta-zephyr?

Best Regards
Peter


Re: any interest in an official "meta-rubygems" layer?

Jack Mitchell
 

On 27/01/2021 06:33, Robert P. J. Day wrote:

since it appears that i will be diving head-first into messing with
ruby in some current YP builds, is there any interest in creating a
meta-rubygems layer to start collecting recipes based on what konrad
weihmann has done in his meta-sca layer here?

https://github.com/priv-kweihmann/meta-sca

i've been swapping emails with konrad over the last few days and,
first, it seems clear that it's not appropriate to start dumping
general ruby recipes into meta-sca as that layer is clearly defined as
being for "static code analysis and security hardening", so a new,
more general layer is obviously more appropriate.

also, konrad focuses on using his own "rubygems.bbclass" class file:

https://github.com/priv-kweihmann/meta-sca/blob/master/classes/rubygems.bbclass

to define recipes that pull from rubygems.org exclusively, and he
agrees that it would keep things simpler to stick with that model;
hence, the proposal of the layer name "meta-rubygems" and not just
"meta-ruby".

konrad already offered to do the maintenance of such a new layer, as
long as there is standard infrastructure support for testing, that
sort of thing. and i'm sure that would make his meta-sca layer simpler
as all the more generic rubygems-based recipes could be moved into the
meta-rubygems layer, leaving his meta-sca layer to focus exclusively
on the code analysis and security recipes, however he wants to do
that.

thoughts? it seems that a new layer could be populated almost
instantly with a large chunk of meta-sca, and we could take it from
there.

rday
Hi Robert,

This is something I would be interested in. I have a developed a much
more basic rubygems class privately which I had intended to opensource
and create a similar later, so it would be nice to have a central place
to contribute Ruby/RubyGems improvements. As you have found there are
many layers with spotty Ruby support and a particular copy of an old
class that is being banded about which is often insufficient.

Regards,
Jack.

--
Jack Mitchell, Consultant
https://www.tuxable.co.uk


any interest in an official "meta-rubygems" layer?

Robert P. J. Day
 

since it appears that i will be diving head-first into messing with
ruby in some current YP builds, is there any interest in creating a
meta-rubygems layer to start collecting recipes based on what konrad
weihmann has done in his meta-sca layer here?

https://github.com/priv-kweihmann/meta-sca

i've been swapping emails with konrad over the last few days and,
first, it seems clear that it's not appropriate to start dumping
general ruby recipes into meta-sca as that layer is clearly defined as
being for "static code analysis and security hardening", so a new,
more general layer is obviously more appropriate.

also, konrad focuses on using his own "rubygems.bbclass" class file:

https://github.com/priv-kweihmann/meta-sca/blob/master/classes/rubygems.bbclass

to define recipes that pull from rubygems.org exclusively, and he
agrees that it would keep things simpler to stick with that model;
hence, the proposal of the layer name "meta-rubygems" and not just
"meta-ruby".

konrad already offered to do the maintenance of such a new layer, as
long as there is standard infrastructure support for testing, that
sort of thing. and i'm sure that would make his meta-sca layer simpler
as all the more generic rubygems-based recipes could be moved into the
meta-rubygems layer, leaving his meta-sca layer to focus exclusively
on the code analysis and security recipes, however he wants to do
that.

thoughts? it seems that a new layer could be populated almost
instantly with a large chunk of meta-sca, and we could take it from
there.

rday


Re: QA notification for completed autobuilder build (yocto-3.3_M2.rc1)

Sangeeta Jain
 

Hi All,

This is the full report for yocto-3.3_M2.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

new issue found

BUG id:14203 - [QA 3.3 M2 RC1] failure in ptest : gstreamer1.0.gstreamer-1.0/pipelines_seek.test


======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14203

Thanks,
Sangeeta

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Pokybuild User
Sent: Thursday, 21 January, 2021 1:05 PM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.3_M2.rc1)


A build flagged for QA (yocto-3.3_M2.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3_M2.rc1


Build hash information:

bitbake: 01e901c44ab0f496606b1d45c8953dc54970204c
meta-arm: a8f32f990a0d9dc1db310892c70d5a994c698b32
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: b4e5d33affeaa223459c0935a853485137b4591d
meta-kernel: 8349870943ba44bbd688656897372e881f32c741
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: 79821d5a185e25384f5b6b5158b238bbee17c79e
poky: b5e634644b69a968a93aad0dd0502cf479d3973a



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org



Re: openjdk-8 multilib

Rudolf J Streif
 

On 1/26/21 11:35 AM, Richard Purdie wrote:
On Tue, 2021-01-26 at 09:00 -0800, Rudolf J Streif wrote:
I have been scratching my head over building openjdk-8 with multilib for
an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the
64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host
arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively
including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc
I suspect that at this point in the parse, the mulitlib code hasn't
swizzled the bits around so it still looks like the main lib rather
than the mutlilib.

Including a variable in a require like that is an immediate expansion
operation so it can't be "undone" when things get properly setup later.

Offhand I'm not sure what you'd do to avoid this. The multilibs are all
a bit ugly in some ways. It suggests they need to be setting up the
overrides earlier. The assumption in the code is that people don't use
immediate expansion for this reason.

Cheers,

Richard
Thanks, Richard. That's what I thought it is. Essentially, the includes are, as expected, resolved at parse time of the recipes, which makes entirely sense. The include files themselves conditionally set SRC_URI for patchsets which are evaluated when the recipes eventually is executed. While the conditional include is neat for keeping things separate, a solution might be to combine the two include files into one.

Cheers,
Rudi

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Re: openjdk-8 multilib

Richard Purdie
 

On Tue, 2021-01-26 at 09:00 -0800, Rudolf J Streif wrote:
I have been scratching my head over building openjdk-8 with multilib for
an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the
64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host
arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively
including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc
I suspect that at this point in the parse, the mulitlib code hasn't
swizzled the bits around so it still looks like the main lib rather
than the mutlilib.

Including a variable in a require like that is an immediate expansion
operation so it can't be "undone" when things get properly setup later.

Offhand I'm not sure what you'd do to avoid this. The multilibs are all
a bit ugly in some ways. It suggests they need to be setting up the
overrides earlier. The assumption in the code is that people don't use
immediate expansion for this reason.

Cheers,

Richard


openjdk-8 multilib

Rudolf J Streif
 

I have been scratching my head over building openjdk-8 with multilib for an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the 64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc

The include file for openjdk-8-release-aarch32.inc sets:

COMPATIBLE_HOST = "^$"
COMPATIBLE_HOST_armv7ve = "arm"
COMPATIBLE_HOST_armv7a = "arm"

So this should theoretically work as it does when the recipe is built for native aarch32. Except that it does not in the multilib case. Although building for multilib the recipe includes openjdk-8-release-aarch64.inc instead of openjdk-8-release-aarch32.inc. If I force the recipe to include openjdk-8-release-aarch32.inc everything works fine, except, of course, that OpenJDK cannot be built for aarch64 anymore.

I am not too familiar with the inner workings of bitbake's multilib code. That's why I am looking here for assistance first before spending a lot of time digging through the code.

Thanks,
Rudi

2121 - 2140 of 54213