Date   

Re: Reducing the perl footprint on my image

Tim Orling
 



On Wed, Mar 3, 2021 at 12:28 PM Tim Orling via lists.yoctoproject.org <ticotimo=gmail.com@...> wrote:


On Wed, Mar 3, 2021 at 7:06 AM Rusty Howell <rustyhowell@...> wrote:
Steve, you're right.  My image.bb is adding various lmsensors packages to the IMAGE_INSTALL, some of which depend on perl-modules.   perl-modules seems to be the big monster, not perl.  We need lmsensors.  So I guess my question is really, how can I (or can I at all) reduce the footprint of perl-modules?  perl-modules doesn't have any Depends, rather it has a long list (~ 670) of Recommends. 


If you look at the lmsensors recipe, the lmsensors-sensorsdetect [1] and lmsensors-sensorsconfconvert [2] subpackages both have perl-modules in RDEPENDS.
One way to determine the ACTUAL dependencies is to run the perl.req script from rpm [3].

Related bug [6]

$ perl.req sensors-detect
perl >= 0:5.004
perl(Fcntl)
perl(File::Basename)
perl(constant)
perl(strict)
perl(vars)

$ perl.req sensors-conf-convert
perl(strict)
perl(vars)

You then need to translate those into the perl-modules-* subpackages, which is easiest to see in perl-rdepends.txt [4].

I have not built nor tested this, but using the described approach I have a patch for lmsensors [5].

Please cherry-pick, test and if it works, add your signed-off-by and submit to the mailing list.


On Tue, Mar 2, 2021 at 1:49 PM Richard Purdie <richard.purdie@...> wrote:
On Tue, 2021-03-02 at 20:42 +0000, Diego Santa Cruz via lists.yoctoproject.org wrote:
> > -----Original Message-----
> > From: yocto@... <yocto@...> On
> > Behalf Of Steve Sakoman via lists.yoctoproject.org
> > Sent: 02 March 2021 21:06
> > To: Steve Sakoman <steve@...>
> > Cc: rustyhowell@...; Yocto (yocto@...)
> > <yocto@...>
> > Subject: Re: [yocto] Reducing the perl footprint on my image
> >
> > On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
> > lists.yoctoproject.org <steve=sakoman.com@...>
> > wrote:
> > >
> > > On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@...> wrote:
> > > >
> > > > I have an image that is using debian package management
> > (PACKAGE_CLASSES = "package_deb").  Because apt and dpkg require perl,
> > perl is being installed in the image.   No problem.  Except that the entire perl
> > stack is 669 packages.
> > >
> > > I just took a look at the manifest for one of my images that includes
> > > PACKAGE_CLASSES = "package_deb".  I see the perl package plus 43
> > > perl-module packages.  Are you sure that something else in your images
> > > isn't pulling in all of those other perl-module packages?
> >
> > It just occurred to me to make sure you are looking in the image
> > manifest to see which packages are actually installed in your image.
> > The perl recipe does generate 676 packages (in dunfell) so perhaps you
> > might be looking at the generated packages rather than the installed
> > packages??
> >
>
> I encountered a similar problem with package management enabled and rpm 
> as package format, where I also just install rpm for package management 
> and not all dnf stack. I get quite a lot of perl and python packages 
> into the image which are pulled by the rpm package, but they are only
> needed for things like rpm-build, rpm-sign, etc., not for the bare 
> rpm command, which is the only one I need in the image.
>
> So I locally extended the rpm recipe to split those tools into rpm-build, 
> rpm-sign and rpm-archive and skip those packages in the image. I should 
> probably send patches for that to oe-core. Is that something that could
> be accepted?

Not sure they need to go to separate packages but moving those 
three to some kind of "build" package would make a lot of sense
to me at least.

Cheers,

Richard








Re: Reducing the perl footprint on my image

Tim Orling
 



On Wed, Mar 3, 2021 at 7:06 AM Rusty Howell <rustyhowell@...> wrote:
Steve, you're right.  My image.bb is adding various lmsensors packages to the IMAGE_INSTALL, some of which depend on perl-modules.   perl-modules seems to be the big monster, not perl.  We need lmsensors.  So I guess my question is really, how can I (or can I at all) reduce the footprint of perl-modules?  perl-modules doesn't have any Depends, rather it has a long list (~ 670) of Recommends. 


If you look at the lmsensors recipe, the lmsensors-sensorsdetect [1] and lmsensors-sensorsconfconvert [2] subpackages both have perl-modules in RDEPENDS.
One way to determine the ACTUAL dependencies is to run the perl.req script from rpm [3].

$ perl.req sensors-detect
perl >= 0:5.004
perl(Fcntl)
perl(File::Basename)
perl(constant)
perl(strict)
perl(vars)

$ perl.req sensors-conf-convert
perl(strict)
perl(vars)

You then need to translate those into the perl-modules-* subpackages, which is easiest to see in perl-rdepends.txt [4].

I have not built nor tested this, but using the described approach I have a patch for lmsensors [5].

Please cherry-pick, test and if it works, add your signed-off-by and submit to the mailing list.


On Tue, Mar 2, 2021 at 1:49 PM Richard Purdie <richard.purdie@...> wrote:
On Tue, 2021-03-02 at 20:42 +0000, Diego Santa Cruz via lists.yoctoproject.org wrote:
> > -----Original Message-----
> > From: yocto@... <yocto@...> On
> > Behalf Of Steve Sakoman via lists.yoctoproject.org
> > Sent: 02 March 2021 21:06
> > To: Steve Sakoman <steve@...>
> > Cc: rustyhowell@...; Yocto (yocto@...)
> > <yocto@...>
> > Subject: Re: [yocto] Reducing the perl footprint on my image
> >
> > On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
> > lists.yoctoproject.org <steve=sakoman.com@...>
> > wrote:
> > >
> > > On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@...> wrote:
> > > >
> > > > I have an image that is using debian package management
> > (PACKAGE_CLASSES = "package_deb").  Because apt and dpkg require perl,
> > perl is being installed in the image.   No problem.  Except that the entire perl
> > stack is 669 packages.
> > >
> > > I just took a look at the manifest for one of my images that includes
> > > PACKAGE_CLASSES = "package_deb".  I see the perl package plus 43
> > > perl-module packages.  Are you sure that something else in your images
> > > isn't pulling in all of those other perl-module packages?
> >
> > It just occurred to me to make sure you are looking in the image
> > manifest to see which packages are actually installed in your image.
> > The perl recipe does generate 676 packages (in dunfell) so perhaps you
> > might be looking at the generated packages rather than the installed
> > packages??
> >
>
> I encountered a similar problem with package management enabled and rpm 
> as package format, where I also just install rpm for package management 
> and not all dnf stack. I get quite a lot of perl and python packages 
> into the image which are pulled by the rpm package, but they are only
> needed for things like rpm-build, rpm-sign, etc., not for the bare 
> rpm command, which is the only one I need in the image.
>
> So I locally extended the rpm recipe to split those tools into rpm-build, 
> rpm-sign and rpm-archive and skip those packages in the image. I should 
> probably send patches for that to oe-core. Is that something that could
> be accepted?

Not sure they need to go to separate packages but moving those 
three to some kind of "build" package would make a lot of sense
to me at least.

Cheers,

Richard





Re: cc1 binary in final rootfs even when no reference to it

Marek Belisko
 

On Wed, Mar 3, 2021 at 6:31 PM Khem Raj <raj.khem@gmail.com> wrote:

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image
It turns out that cpp + cpp-symlinks is pulled by python3-pycparser.
It is really necessary to be as runtime dependency in recipe?

On Wed, Mar 3, 2021 at 6:10 AM Marek Belisko <marek.belisko@gmail.com> wrote:

Hello,

on dunfell images I start seeing that cc1 binary (checked by buildhistory):
files-in-image.txt:-rwxr-xr-x root root 17674124
./usr/libexec/gcc/arm-poky-linux-gnueabi/9.3.0/cc1

is present in the final image. I check taskexp but cannot find any
reference which pointes to it.
Any ideas how to check or it's a common problem?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com




--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


[GDP] : Query on container development for Genivi GDP. #linux #meta-virtualization #yocto

Siddhartha V
 

I need to build a docker container/lxc container image for Genivi GDP. I searched a lot (almost 2 weeks) on this, but didn't get proper data to refer. 
 
But, recently, I found these links, https://github.com/gmacario/easy-build/pull/258 and https://github.com/gmacario/easy-build/issues/251 . I found them bit informative. 
 
I kindly request you to suggest me if there is any material/links to refer so that, it helps me in container development for GDP.
 
 
   Any suggestion will help me a lot. Thanks in advance


Regards,
Siddhartha V.


Re: cc1 binary in final rootfs even when no reference to it

Khem Raj
 

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image

On Wed, Mar 3, 2021 at 6:10 AM Marek Belisko <marek.belisko@gmail.com> wrote:

Hello,

on dunfell images I start seeing that cc1 binary (checked by buildhistory):
files-in-image.txt:-rwxr-xr-x root root 17674124
./usr/libexec/gcc/arm-poky-linux-gnueabi/9.3.0/cc1

is present in the final image. I check taskexp but cannot find any
reference which pointes to it.
Any ideas how to check or it's a common problem?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com



Re: Reducing the perl footprint on my image

Diego Santa Cruz
 

-----Original Message-----
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Sent: 02 March 2021 21:50
To: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>;
steve@sakoman.com
Cc: rustyhowell@gmail.com; Yocto (yocto@lists.yoctoproject.org)
<yocto@lists.yoctoproject.org>
Subject: Re: [yocto] Reducing the perl footprint on my image
[...]
So I locally extended the rpm recipe to split those tools into rpm-build,
rpm-sign and rpm-archive and skip those packages in the image. I should
probably send patches for that to oe-core. Is that something that could
be accepted?
Not sure they need to go to separate packages but moving those
three to some kind of "build" package would make a lot of sense
to me at least.
I'll be sending a patch to split it then. Having the sign and archive in separate packages allows to skip their dependencies in images too, and they are not really related to the rpm build part and the complexity delta is minimal; usually there is no need to have rpm-sign in a target image nor rpm2archive if the archive PACKAGECONFIG is enabled.

Best,
Diego

--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com


Re: Reducing the perl footprint on my image

Rusty Howell
 

Steve, you're right.  My image.bb is adding various lmsensors packages to the IMAGE_INSTALL, some of which depend on perl-modules.   perl-modules seems to be the big monster, not perl.  We need lmsensors.  So I guess my question is really, how can I (or can I at all) reduce the footprint of perl-modules?  perl-modules doesn't have any Depends, rather it has a long list (~ 670) of Recommends. 


On Tue, Mar 2, 2021 at 1:49 PM Richard Purdie <richard.purdie@...> wrote:
On Tue, 2021-03-02 at 20:42 +0000, Diego Santa Cruz via lists.yoctoproject.org wrote:
> > -----Original Message-----
> > From: yocto@... <yocto@...> On
> > Behalf Of Steve Sakoman via lists.yoctoproject.org
> > Sent: 02 March 2021 21:06
> > To: Steve Sakoman <steve@...>
> > Cc: rustyhowell@...; Yocto (yocto@...)
> > <yocto@...>
> > Subject: Re: [yocto] Reducing the perl footprint on my image
> >
> > On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
> > lists.yoctoproject.org <steve=sakoman.com@...>
> > wrote:
> > >
> > > On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@...> wrote:
> > > >
> > > > I have an image that is using debian package management
> > (PACKAGE_CLASSES = "package_deb").  Because apt and dpkg require perl,
> > perl is being installed in the image.   No problem.  Except that the entire perl
> > stack is 669 packages.
> > >
> > > I just took a look at the manifest for one of my images that includes
> > > PACKAGE_CLASSES = "package_deb".  I see the perl package plus 43
> > > perl-module packages.  Are you sure that something else in your images
> > > isn't pulling in all of those other perl-module packages?
> >
> > It just occurred to me to make sure you are looking in the image
> > manifest to see which packages are actually installed in your image.
> > The perl recipe does generate 676 packages (in dunfell) so perhaps you
> > might be looking at the generated packages rather than the installed
> > packages??
> >
>
> I encountered a similar problem with package management enabled and rpm 
> as package format, where I also just install rpm for package management 
> and not all dnf stack. I get quite a lot of perl and python packages 
> into the image which are pulled by the rpm package, but they are only
> needed for things like rpm-build, rpm-sign, etc., not for the bare 
> rpm command, which is the only one I need in the image.
>
> So I locally extended the rpm recipe to split those tools into rpm-build, 
> rpm-sign and rpm-archive and skip those packages in the image. I should 
> probably send patches for that to oe-core. Is that something that could
> be accepted?

Not sure they need to go to separate packages but moving those 
three to some kind of "build" package would make a lot of sense
to me at least.

Cheers,

Richard


cc1 binary in final rootfs even when no reference to it

Marek Belisko
 

Hello,

on dunfell images I start seeing that cc1 binary (checked by buildhistory):
files-in-image.txt:-rwxr-xr-x root root 17674124
./usr/libexec/gcc/arm-poky-linux-gnueabi/9.3.0/cc1

is present in the final image. I check taskexp but cannot find any
reference which pointes to it.
Any ideas how to check or it's a common problem?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


[PATCH yocto-autobuilder-helper] config.json: add a systemd no-x11 build

Alexander Kanavin
 

Particularly the weston image has now regressed twice under systemd,
so I think there should be a quality gate for it.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
config.json | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index 8025166..d6e7df8 100644
--- a/config.json
+++ b/config.json
@@ -715,8 +715,19 @@
"SANITYTARGETS" : "core-image-full-cmdline:do_testimage core-image-weston:do_testimage",
"extravars" : [
"DISTRO_FEATURES_remove = 'x11'"
- ]
-
+ ],
+ "step1" : {
+ "shortname" : "Sysvinit weston"
+ },
+ "step2" : {
+ "shortname" : "Systemd weston",
+ "extravars" : [
+ "TEST_SUITES_append = ' systemd'",
+ "DISTRO_FEATURES_append = ' pam systemd'",
+ "VIRTUAL-RUNTIME_init_manager = 'systemd'",
+ "DISTRO_FEATURES_BACKFILL_CONSIDERED = 'sysvinit'"
+ ]
+ }
},
"musl-qemux86" : {
"MACHINE" : "qemux86",
--
2.29.2


How to run the recipe Go tests on Yocto

Javier Tia
 

Hi,

Is there a way to run the recipe Go tests in Yocto?

I have tried several ways (1. Manually and 2. ptest) with unsuccess.

1. Manually exporting all the toolchain variables:

GOARCH="${BUILD_GOARCH}"
CGO_ENABLED="1"
CFLAGS="${BUILD_CFLAGS}"
LDFLAGS="${BUILD_LDFLAGS}"
CGO_CFLAGS="${BUILD_CFLAGS}"
CGO_LDFLAGS="${BUILD_LDFLAGS}"
CC="${BUILD_CC}"
LD="${BUILD_LD}"

and run it with the Go test native version.


2. Using ptest, and adding to the Go recipe:

do_compile_ptest() {
${GO} test -vet off $(go_list_package_tests)
}

In both cases the error messages are like this:

fork/exec .../recipe_name/1.0-r0/go-tmp/go-build7113/b338/util.test: no
such file or directory
FAIL util 0.000s

It's happening with Yocto Zeus (v3.0.4) and Go v1.4.17


Regards,

▷ Javier's 🖊


Re: Reducing the perl footprint on my image

Richard Purdie
 

On Tue, 2021-03-02 at 20:42 +0000, Diego Santa Cruz via lists.yoctoproject.org wrote:
-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
Behalf Of Steve Sakoman via lists.yoctoproject.org
Sent: 02 March 2021 21:06
To: Steve Sakoman <steve@sakoman.com>
Cc: rustyhowell@gmail.com; Yocto (yocto@lists.yoctoproject.org)
<yocto@lists.yoctoproject.org>
Subject: Re: [yocto] Reducing the perl footprint on my image

On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@lists.yoctoproject.org>
wrote:

On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@gmail.com> wrote:

I have an image that is using debian package management
(PACKAGE_CLASSES = "package_deb"). Because apt and dpkg require perl,
perl is being installed in the image. No problem. Except that the entire perl
stack is 669 packages.

I just took a look at the manifest for one of my images that includes
PACKAGE_CLASSES = "package_deb". I see the perl package plus 43
perl-module packages. Are you sure that something else in your images
isn't pulling in all of those other perl-module packages?
It just occurred to me to make sure you are looking in the image
manifest to see which packages are actually installed in your image.
The perl recipe does generate 676 packages (in dunfell) so perhaps you
might be looking at the generated packages rather than the installed
packages??
I encountered a similar problem with package management enabled and rpm 
as package format, where I also just install rpm for package management 
and not all dnf stack. I get quite a lot of perl and python packages 
into the image which are pulled by the rpm package, but they are only
needed for things like rpm-build, rpm-sign, etc., not for the bare 
rpm command, which is the only one I need in the image.

So I locally extended the rpm recipe to split those tools into rpm-build, 
rpm-sign and rpm-archive and skip those packages in the image. I should 
probably send patches for that to oe-core. Is that something that could
be accepted?
Not sure they need to go to separate packages but moving those 
three to some kind of "build" package would make a lot of sense
to me at least.

Cheers,

Richard


[meta-rockchip][PATCH] tinker board: refactor machine config

Trevor Woerner
 

Create a common conf/machine/include/tinker.inc and re-spin
- conf/machine/tinker-board.conf
- conf/machine-tinker-board-s.conf
to just contain the differences.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
conf/machine/include/tinker.inc | 15 +++++++++++++++
conf/machine/tinker-board-s.conf | 16 +---------------
conf/machine/tinker-board.conf | 16 +---------------
3 files changed, 17 insertions(+), 30 deletions(-)
create mode 100644 conf/machine/include/tinker.inc

diff --git a/conf/machine/include/tinker.inc b/conf/machine/include/tinker.inc
new file mode 100644
index 0000000..e851b59
--- /dev/null
+++ b/conf/machine/include/tinker.inc
@@ -0,0 +1,15 @@
+require conf/machine/include/rk3288.inc
+
+WKS_FILE ?= "tinker-board.wks"
+IMAGE_FSTYPES += "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ ${KERNEL_DEVICETREE} \
+ "
diff --git a/conf/machine/tinker-board-s.conf b/conf/machine/tinker-board-s.conf
index f7b17e4..9f44f2f 100644
--- a/conf/machine/tinker-board-s.conf
+++ b/conf/machine/tinker-board-s.conf
@@ -5,23 +5,9 @@
#@NAME: Tinker-S RK3288
#@DESCRIPTION: ASUS Tinker Board is a Raspberry Pi 3 Alternative based on Rockchip RK3288 Processor.

-require conf/machine/include/rk3288.inc
+require conf/machine/include/tinker.inc

KERNEL_DEVICETREE = "rk3288-tinker-s.dtb"
UBOOT_MACHINE = "tinker-s-rk3288_defconfig"

RK_BOOT_DEVICE ?= "mmcblk1"
-
-WKS_FILE ?= "tinker-board.wks"
-IMAGE_FSTYPES += "wic wic.bmap"
-
-WKS_FILE_DEPENDS ?= " \
- mtools-native \
- dosfstools-native \
- virtual/bootloader \
- virtual/kernel \
- "
-IMAGE_BOOT_FILES ?= "\
- ${KERNEL_IMAGETYPE} \
- ${KERNEL_DEVICETREE} \
- "
diff --git a/conf/machine/tinker-board.conf b/conf/machine/tinker-board.conf
index 1c3c08a..8fe5f63 100644
--- a/conf/machine/tinker-board.conf
+++ b/conf/machine/tinker-board.conf
@@ -5,21 +5,7 @@
#@NAME: Tinker RK3288
#@DESCRIPTION: ASUS Tinker Board is a Raspberry Pi 3 Alternative based on Rockchip RK3288 Processor.

-require conf/machine/include/rk3288.inc
+require conf/machine/include/tinker.inc

KERNEL_DEVICETREE = "rk3288-tinker.dtb"
UBOOT_MACHINE = "tinker-rk3288_defconfig"
-
-WKS_FILE ?= "tinker-board.wks"
-IMAGE_FSTYPES += "wic wic.bmap"
-
-WKS_FILE_DEPENDS ?= " \
- mtools-native \
- dosfstools-native \
- virtual/bootloader \
- virtual/kernel \
- "
-IMAGE_BOOT_FILES ?= "\
- ${KERNEL_IMAGETYPE} \
- ${KERNEL_DEVICETREE} \
- "
--
2.30.0.rc0


[meta-rockchip][PATCH] COMPATIBLE_MACHINE cleanup

Trevor Woerner
 

The COMPATIBLE_MACHINE strings were getting unwieldy, so switch to the
MACHINEOVERRIDE notation so they're neater.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
recipes-kernel/linux/linux-stable-bleeding_5.11.bb | 2 +-
recipes-kernel/linux/linux-yocto-dev.bbappend | 9 ++++++++-
recipes-kernel/linux/linux-yocto-rt_%.bbappend | 9 ++++++++-
recipes-kernel/linux/linux-yocto-tiny_%.bbappend | 9 ++++++++-
recipes-kernel/linux/linux-yocto_%.bbappend | 10 ++++++++--
5 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/recipes-kernel/linux/linux-stable-bleeding_5.11.bb b/recipes-kernel/linux/linux-stable-bleeding_5.11.bb
index dce537d..508ddae 100644
--- a/recipes-kernel/linux/linux-stable-bleeding_5.11.bb
+++ b/recipes-kernel/linux/linux-stable-bleeding_5.11.bb
@@ -15,4 +15,4 @@ LINUX_VERSION = "5.11"
LINUX_VERSION_EXTENSION = ""
PV = "${LINUX_VERSION}"

-COMPATIBLE_MACHINE = "(rock-pi-e)"
+COMPATIBLE_MACHINE_rock-pi-e = "rock-pi-e"
diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
index a85b85e..e5ea197 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -1 +1,8 @@
-COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288|rock-pi-e"
+COMPATIBLE_MACHINE_marsboard-rk3066 = "marsboard-rk3066"
+COMPATIBLE_MACHINE_rock2-square = "rock2-square"
+COMPATIBLE_MACHINE_radxarock = "radxarock"
+COMPATIBLE_MACHINE_firefly-rk3288 = "firefly-rk3288"
+COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
+COMPATIBLE_MACHINE_tinker-board = "tinker-board"
+COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
+COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
diff --git a/recipes-kernel/linux/linux-yocto-rt_%.bbappend b/recipes-kernel/linux/linux-yocto-rt_%.bbappend
index 2f498d9..e5ea197 100644
--- a/recipes-kernel/linux/linux-yocto-rt_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-rt_%.bbappend
@@ -1 +1,8 @@
-COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+COMPATIBLE_MACHINE_marsboard-rk3066 = "marsboard-rk3066"
+COMPATIBLE_MACHINE_rock2-square = "rock2-square"
+COMPATIBLE_MACHINE_radxarock = "radxarock"
+COMPATIBLE_MACHINE_firefly-rk3288 = "firefly-rk3288"
+COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
+COMPATIBLE_MACHINE_tinker-board = "tinker-board"
+COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
+COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
diff --git a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend b/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
index 2f498d9..e5ea197 100644
--- a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
@@ -1 +1,8 @@
-COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+COMPATIBLE_MACHINE_marsboard-rk3066 = "marsboard-rk3066"
+COMPATIBLE_MACHINE_rock2-square = "rock2-square"
+COMPATIBLE_MACHINE_radxarock = "radxarock"
+COMPATIBLE_MACHINE_firefly-rk3288 = "firefly-rk3288"
+COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
+COMPATIBLE_MACHINE_tinker-board = "tinker-board"
+COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
+COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
index 97b8cda..e5ea197 100644
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -1,2 +1,8 @@
-COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
-
+COMPATIBLE_MACHINE_marsboard-rk3066 = "marsboard-rk3066"
+COMPATIBLE_MACHINE_rock2-square = "rock2-square"
+COMPATIBLE_MACHINE_radxarock = "radxarock"
+COMPATIBLE_MACHINE_firefly-rk3288 = "firefly-rk3288"
+COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
+COMPATIBLE_MACHINE_tinker-board = "tinker-board"
+COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
+COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
--
2.30.0.rc0


Re: Reducing the perl footprint on my image

Diego Santa Cruz
 

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
Behalf Of Steve Sakoman via lists.yoctoproject.org
Sent: 02 March 2021 21:06
To: Steve Sakoman <steve@sakoman.com>
Cc: rustyhowell@gmail.com; Yocto (yocto@lists.yoctoproject.org)
<yocto@lists.yoctoproject.org>
Subject: Re: [yocto] Reducing the perl footprint on my image

On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@lists.yoctoproject.org>
wrote:

On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@gmail.com> wrote:

I have an image that is using debian package management
(PACKAGE_CLASSES = "package_deb"). Because apt and dpkg require perl,
perl is being installed in the image. No problem. Except that the entire perl
stack is 669 packages.

I just took a look at the manifest for one of my images that includes
PACKAGE_CLASSES = "package_deb". I see the perl package plus 43
perl-module packages. Are you sure that something else in your images
isn't pulling in all of those other perl-module packages?
It just occurred to me to make sure you are looking in the image
manifest to see which packages are actually installed in your image.
The perl recipe does generate 676 packages (in dunfell) so perhaps you
might be looking at the generated packages rather than the installed
packages??
I encountered a similar problem with package management enabled and rpm as package format, where I also just install rpm for package management and not all dnf stack. I get quite a lot of perl and python packages into the image which are pulled by the rpm package, but they are only needed for things like rpm-build, rpm-sign, etc., not for the bare rpm command, which is the only one I need in the image.

So I locally extended the rpm recipe to split those tools into rpm-build, rpm-sign and rpm-archive and skip those packages in the image. I should probably send patches for that to oe-core. Is that something that could be accepted?

--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com


#yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

 

I still appear to be having an issue with the SXT SDK install…

 

Building for zeus/x86_64 Intel based platform…

I build my kernel image clean, fully functional…

Standard SDK builds clean and appears functional…

 

Ext SDK builds clean, but on install I am still seeing Error below…

 

(1)    What is it comparing  between unhash/task hash ?, more sig issues ?

 

(2)    What is meant by “This is usually due to missing setscene tasks” ?

 

(3)    In the local.conf under the SDK they set :

 

SSTATE_MIRRORS += " file://universal/(.*) file://universal-4.9/\1 file://universal-4.9/(.*) file://universal-4.8/\1"

 

Under sdk-extra.conf I set :

 

SSTATE_MIRRORS += file://.* file:///ede/tms/yocto/zeus/sstate_cache/PATH

 

My SSTATE_MIRRIOR is based off the clean builds I mentioned above, is this the correct procedure ?

 

I am trying to figure out how best to debug this issue, it is occurring on the post install, and everything pretty much appears in place.

 

Steve

 

14:43 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |###########################################################################################| Time: 0:01:32

Initialising tasks: 100% |########################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |################################################################| Time: 0:00:03

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/liburcu/liburcu_0.11.1.bb:do_populate_sysroot, unihash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601, taskhash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/python/python3_3.7.8.bb:do_packagedata, unihash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f, taskhash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f

.

.

.

 

This is usually due to missing setscene tasks. Those missing in this build were:

 

<<appears to list every recipe under ./testSDK/layers directory here>>


Re: Reducing the perl footprint on my image

Steve Sakoman
 

On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@lists.yoctoproject.org>
wrote:

On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@gmail.com> wrote:

I have an image that is using debian package management (PACKAGE_CLASSES = "package_deb"). Because apt and dpkg require perl, perl is being installed in the image. No problem. Except that the entire perl stack is 669 packages.
I just took a look at the manifest for one of my images that includes
PACKAGE_CLASSES = "package_deb". I see the perl package plus 43
perl-module packages. Are you sure that something else in your images
isn't pulling in all of those other perl-module packages?
It just occurred to me to make sure you are looking in the image
manifest to see which packages are actually installed in your image.
The perl recipe does generate 676 packages (in dunfell) so perhaps you
might be looking at the generated packages rather than the installed
packages??

Steve


Most of the packages are super tiny and are probably not needed by apt or dpkg. Is there a way to strip down the large number of perl packages in the image to just what is needed by apt/dpkg?
I haven't found anything in the MegaManual yet.
Thanks in advance.



Re: Reducing the perl footprint on my image

Steve Sakoman
 

On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@gmail.com> wrote:

I have an image that is using debian package management (PACKAGE_CLASSES = "package_deb"). Because apt and dpkg require perl, perl is being installed in the image. No problem. Except that the entire perl stack is 669 packages.
I just took a look at the manifest for one of my images that includes
PACKAGE_CLASSES = "package_deb". I see the perl package plus 43
perl-module packages. Are you sure that something else in your images
isn't pulling in all of those other perl-module packages?

Steve

Most of the packages are super tiny and are probably not needed by apt or dpkg. Is there a way to strip down the large number of perl packages in the image to just what is needed by apt/dpkg?
I haven't found anything in the MegaManual yet.
Thanks in advance.


[meta-security][dunfell][PATCH 4/9] initramfs-framework-ima: RDEPENDS on ima-evm-keys

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../recipes-core/initrdscripts/initramfs-framework-ima.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framewor=
k-ima.bb b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-=
ima.bb
index dacdc8b..77f6f7c 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.b=
b
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.b=
b
@@ -27,5 +27,5 @@ do_install () {
=20
FILES_${PN} =3D "/init.d ${sysconfdir}"
=20
-RDEPENDS_${PN} =3D "keyutils ${IMA_POLICY}"
+RDEPENDS_${PN} =3D "keyutils ima-evm-keys ${IMA_POLICY}"
RDEPENDS_${PN} +=3D "initramfs-framework-base"
--=20
2.29.0


[meta-security][dunfell][PATCH 0/9] Some IMA/EVM fixes to dunfell branch

Ming Liu <liu.ming50@...>
 

From: Ming Liu <ming.liu@toradex.com>

Cherry pick some IMA/EVM fixes to LTS dunfell branch, with these=20
patches applied, I could run a ima enabled image with sysvinit/systemd
on qemuarm/qemuarm64 and some NXP machines.

Ming Liu (9):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
ima-evm-keys: add recipe
initramfs-framework-ima: RDEPENDS on ima-evm-keys
meta: refactor IMA/EVM sign rootfs
README.md: update according to the refactoring in
ima-evm-rootfs.bbclass
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic
ima-policy-hashed: add CGROUP2_SUPER_MAGIC fsmagic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
.../ima_policy_hashed/files/ima_policy_hashed | 3 ++
7 files changed, 41 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-=
keys_1.0.bb

--=20
2.29.0


[meta-security][dunfell][PATCH 2/9] initramfs-framework-ima: fix a wrong path

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

/etc/ima-policy > /etc/ima/ima-policy.

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../recipes-core/initrdscripts/initramfs-framework-ima/ima | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framewor=
k-ima/ima b/meta-integrity/recipes-core/initrdscripts/initramfs-framework=
-ima/ima
index 8616f99..16ed53f 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/i=
ma
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/i=
ma
@@ -46,7 +46,7 @@ ima_run() {
# ("[Linux-ima-user] IMA policy loading via cat") and we get better =
error reporting when
# checking the write of each line. To minimize the risk of policy lo=
ading going wrong we
# also remove comments and blank lines ourselves.
- if ! (set -e; while read i; do if echo "$i" | grep -q -e '^#' -e '^ =
*$'; then debug "Skipping IMA policy: $i"; else debug "Writing IMA policy=
: $i"; if echo $i; then sleep ${bootparam_ima_delay:-0}; else fatal "Inva=
lid line in IMA policy: $i"; exit 1; fi; fi; done) </etc/ima-policy >/sys=
/kernel/security/ima/policy; then
+ if ! (set -e; while read i; do if echo "$i" | grep -q -e '^#' -e '^ =
*$'; then debug "Skipping IMA policy: $i"; else debug "Writing IMA policy=
: $i"; if echo $i; then sleep ${bootparam_ima_delay:-0}; else fatal "Inva=
lid line in IMA policy: $i"; exit 1; fi; fi; done) </etc/ima/ima-policy >=
/sys/kernel/security/ima/policy; then
fatal "Could not load IMA policy."
fi
}
--=20
2.29.0

4621 - 4640 of 57160