Date   

Re: patching an .inc file?

Alejandro Hernandez Samaniego
 

Hey Derek,

I would advise against this, inc files aren't supposed to be appended to, priorities would work, adding TUNEVALID on your machine conf is also possible, but I'd say those are both temporary solutions, you might also just wait a little bit until they release their 2020.x releases already compatible with Zeus.

Alejandro


On Sat, 28 Mar 2020 at 15:00, Konrad Weihmann <kweihmann@...> wrote:

What you could do is to override the file in a layer with higher priority.
Just create the same file under the same path (e.g. <your-layer>/conf/machine/include/microblaze/feature-microblaze-versions.inc) and apply the changes there - this should help for now.

But be aware that this way could lead to trouble in case the overridden file does change on an update - so use with caution.
Unfortunately you can't BBMASK the original inc file, you have to rely on layer prio.

On 28.03.20 22:42, Derek Dresser wrote:
Hello,

I am trying to update a build for a custom board based on the Xilinx zcu102-zynqmp (using meta-xilinx)  to 'zeus' and am getting the following error message:

Toolchain tunings invalid:
Tuning 'microblaze' has the following errors:
Feature 'v11.0' is not defined.

I have tracked this down to the following file:

poky/meta/conf/machine/include/microblaze/feature-microblaze-versions.inc

Editing this file allows me to build without errors.  I'd like to apply a patch to this file (or override the file with an edited version.)

diff --git meta/conf/machine/include/microblaze/feature-microblaze-versions.inc meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
index 955674fff9..3221e2aab7 100644
--- meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
+++ meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
@@ -44,6 +44,7 @@ TUNEVALID[v9.4]  = "MicroBlaze version 9.4"
 TUNEVALID[v9.5]  = "MicroBlaze version 9.5"
 TUNEVALID[v9.6]  = "MicroBlaze version 9.6"
 TUNEVALID[v10.0] = "MicroBlaze version 10.0"
+TUNEVALID[v11.0] = "MicroBlaze version 11.0"

 # Version conflict matrix
 TUNECONFLICTS[v8.00] = ""
@@ -60,6 +61,7 @@ TUNECONFLICTS[v9.4]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3"
 TUNECONFLICTS[v9.5]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4"
 TUNECONFLICTS[v9.6]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5"
 TUNECONFLICTS[v10.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6"
+TUNECONFLICTS[v11.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6 v10.0"

 # Version flags
 TUNE_CCARGS += "-mcpu=${@microblaze_current_version(d, True)}"

I know how to apply a patch against a recipe source file, but not this toolchain tuning include file.   How can I accomplish this without editing the files in openembedded-core?   I'd like to override or patch this in my own layer.

Thanks,
Derek


    


Re: patching an .inc file?

Konrad Weihmann <kweihmann@...>
 

What you could do is to override the file in a layer with higher priority.
Just create the same file under the same path (e.g. <your-layer>/conf/machine/include/microblaze/feature-microblaze-versions.inc) and apply the changes there - this should help for now.

But be aware that this way could lead to trouble in case the overridden file does change on an update - so use with caution.
Unfortunately you can't BBMASK the original inc file, you have to rely on layer prio.

On 28.03.20 22:42, Derek Dresser wrote:
Hello,

I am trying to update a build for a custom board based on the Xilinx zcu102-zynqmp (using meta-xilinx)  to 'zeus' and am getting the following error message:

Toolchain tunings invalid:
Tuning 'microblaze' has the following errors:
Feature 'v11.0' is not defined.

I have tracked this down to the following file:

poky/meta/conf/machine/include/microblaze/feature-microblaze-versions.inc

Editing this file allows me to build without errors.  I'd like to apply a patch to this file (or override the file with an edited version.)

diff --git meta/conf/machine/include/microblaze/feature-microblaze-versions.inc meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
index 955674fff9..3221e2aab7 100644
--- meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
+++ meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
@@ -44,6 +44,7 @@ TUNEVALID[v9.4]  = "MicroBlaze version 9.4"
 TUNEVALID[v9.5]  = "MicroBlaze version 9.5"
 TUNEVALID[v9.6]  = "MicroBlaze version 9.6"
 TUNEVALID[v10.0] = "MicroBlaze version 10.0"
+TUNEVALID[v11.0] = "MicroBlaze version 11.0"

 # Version conflict matrix
 TUNECONFLICTS[v8.00] = ""
@@ -60,6 +61,7 @@ TUNECONFLICTS[v9.4]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3"
 TUNECONFLICTS[v9.5]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4"
 TUNECONFLICTS[v9.6]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5"
 TUNECONFLICTS[v10.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6"
+TUNECONFLICTS[v11.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6 v10.0"

 # Version flags
 TUNE_CCARGS += "-mcpu=${@microblaze_current_version(d, True)}"

I know how to apply a patch against a recipe source file, but not this toolchain tuning include file.   How can I accomplish this without editing the files in openembedded-core?   I'd like to override or patch this in my own layer.

Thanks,
Derek


    


patching an .inc file?

Derek Dresser <dresser.net@...>
 

Hello,

I am trying to update a build for a custom board based on the Xilinx zcu102-zynqmp (using meta-xilinx)  to 'zeus' and am getting the following error message:

Toolchain tunings invalid:
Tuning 'microblaze' has the following errors:
Feature 'v11.0' is not defined.

I have tracked this down to the following file:

poky/meta/conf/machine/include/microblaze/feature-microblaze-versions.inc

Editing this file allows me to build without errors.  I'd like to apply a patch to this file (or override the file with an edited version.)

diff --git meta/conf/machine/include/microblaze/feature-microblaze-versions.inc meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
index 955674fff9..3221e2aab7 100644
--- meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
+++ meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
@@ -44,6 +44,7 @@ TUNEVALID[v9.4]  = "MicroBlaze version 9.4"
 TUNEVALID[v9.5]  = "MicroBlaze version 9.5"
 TUNEVALID[v9.6]  = "MicroBlaze version 9.6"
 TUNEVALID[v10.0] = "MicroBlaze version 10.0"
+TUNEVALID[v11.0] = "MicroBlaze version 11.0"

 # Version conflict matrix
 TUNECONFLICTS[v8.00] = ""
@@ -60,6 +61,7 @@ TUNECONFLICTS[v9.4]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3"
 TUNECONFLICTS[v9.5]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4"
 TUNECONFLICTS[v9.6]  = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5"
 TUNECONFLICTS[v10.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6"
+TUNECONFLICTS[v11.0] = "v8.00 v8.10 v8.20 v8.30 v8.40 v8.50 v9.0 v9.1 v9.2 v9.3 v9.4 v9.5 v9.6 v10.0"

 # Version flags
 TUNE_CCARGS += "-mcpu=${@microblaze_current_version(d, True)}"

I know how to apply a patch against a recipe source file, but not this toolchain tuning include file.   How can I accomplish this without editing the files in openembedded-core?   I'd like to override or patch this in my own layer.

Thanks,
Derek


Re: Compressing btrfs image

Konrad Weihmann <kweihmann@...>
 

AFAIK there is no way to mount something without root credentials.

fakeroot/pseudo is intercepting some calls before they will reach the kernel, but mounting isn't a supported option - it just makes all child processes think they running under uid 0.

What you could do is try to find an option (https://btrfs.wiki.kernel.org/index.php/Manpage/mkfs.btrfs) which does what you want directly while creating the image.

These options should go then to a variable called EXTRA_IMAGECMD.


On 28.03.20 16:30, Edson Seabra wrote:
Hi all.

I'm trying to compress a btrfs rootfs

I added  in "image_types.bbclass:IMAGE_CMD_btrfs ()"  two commands:

1) mount the btrfs image after mkfs.btrfs
2) btrfs filesystem defrag + compress option

But the command mount fails:

mount: /home/edson/ng-trunk/nodegrid/tmp/work/genericx86_64-poky-linux/nodegrid/1.0-r0/deploy-nodegrid-image-complete/temp_btrfs: failed to setup loop device for /home/edson/ng-trunk/nodegrid/tmp/work/genericx86_64-poky-linux/nodegrid/1.0-r0/deploy-nodegrid-image-complete/nodegrid-genericx86-64-20200328134151.rootfs.btrfs.

I saw in image.bbclass the creation of do_image_btrfs task with flag 'fakeroot'.

====== image.bbclass ====
        task = "do_image_%s" % t.replace("-", "_").replace(".", "_")

        d.setVar(task, '\n'.join(cmds))
        d.setVarFlag(task, 'func', '1')
        d.setVarFlag(task, 'fakeroot', '1')
=======================

would the fakeroot flag allow do_image_btrfs execute commands that requires root privilege ?

If not what would be the way to execute the mount command ?

I tried "pseudo mount" but it failed same way...

Thanks in advance.

Edson.

Edson Seabra

Principal Engineer

M +1 510 579 0843

1506169147061_OutlookEmoji-1505330244060_ZPELogo_Email.png1e6c5898-d340-4c90-8c28-e559c26bc7d1.png
46757 Fremont Blvd., Fremont, CA 94538
zpesystems.com | Request a Nodegrid Demo



      


Re: Fw: Reducing rootfs size in yocto

Konrad Weihmann <kweihmann@...>
 

HI,


800MB sounds fairly much for just the base system - maybe there is some potential for you to slim it down.
If your project requires all these packages, I' afraid there isn't an easy magical switch to reduce the size.

What you could do is take the image manifest (https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-IMAGE_MANIFEST) and browse manually though it, if there

is any obvious package that shouldn't be installed, which could be removed - but to be honest 3.9GB for all that stuff required according to your list sounds like a reasonable size for the rootfs.

If you already know what the real "big ones" are in your image you could try to configure them to include only things really needed - if not you could also take the

image manifest feed the information into "oe-pkgdata-util package-info <pkgname>" to get the size of the package.

I guess from here on you can take it.


In the end 3.9GB for a fully fledged development environment doesn't sounds too much - just remember a vanilla ubuntu for example takes at least 15GB.


BR

Konrad


On 28.03.20 19:36, Ajam Ali wrote:
Hi Konrad,

Actually my current image size is 3.9GB because of heavy size packages required by my project and without project required packages my image size in Yocto is 800MB.

I want to reduce the image size as maximum as possible.


Thanks a lot in advance,
Ajam Ali

From: Konrad Weihmann <kweihmann@...>
Sent: Saturday, March 28, 2020 7:38 PM
To: Ajam Ali <AjamA@...>
Cc: yocto@... <yocto@...>
Subject: Re: [yocto] Fw: Reducing rootfs size in yocto
 

[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

Pretty general questions, but I try to answer your question.


I don't know what the purpose of your image is, but installing development tools like boost-dev or gcc (I guess that is what you mean with cpp) makes your image automatically a lot bigger, I would suggest to put devtools into a SDK, which could be shipped separately.


Next thing you can do is to analyze the what is actually so big in your image, e.g. by creating a tar.gz of the image, unpacking it and browsing by 'du -sh *'.
You can get the package/recipe to a file by using 'oe-pkgdata-util find-path <path>'.


In the identified recipe you can look for PACKAGECONFIG or OE_EXTRACONF switches that you don't need and disable them.


As said, I don't know what the purpose/environment of your image will be like, but you could also consider to use a different fs-format like squash.


In general if you want small images preferring musl over glibc and systemV over systemd is something that you could consider as well.


TL;DR


1) move to SDK

2) check PACKAGECONFIG switches

3) same as 2 or consider something "smaller" like lxc

4) same as 2

5) same as 2

6) same as 2

7) move to SDK

8) same as 2


On 28.03.20 14:25, Ajam Ali wrote:



 
Hi All,

I am trying to reduce the image size.

how can i  reduce the size of following packages so that i could get a small image size after integrating these packages in yocto?


1) boost-dev 2) docker 3) containerd-opencontainers 4) nodejs 5) nodejs-npm 6) python3-numpy 7) cpp 8) postgresql



Thanks in advance,

Ajam Ali


::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.



          


Re: Fw: Reducing rootfs size in yocto

Ajam Ali
 

Hi Konrad,

Actually my current image size is 3.9GB because of heavy size packages required by my project and without project required packages my image size in Yocto is 800MB.

I want to reduce the image size as maximum as possible.


Thanks a lot in advance,
Ajam Ali


From: Konrad Weihmann <kweihmann@...>
Sent: Saturday, March 28, 2020 7:38 PM
To: Ajam Ali <AjamA@...>
Cc: yocto@... <yocto@...>
Subject: Re: [yocto] Fw: Reducing rootfs size in yocto
 

[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

Pretty general questions, but I try to answer your question.


I don't know what the purpose of your image is, but installing development tools like boost-dev or gcc (I guess that is what you mean with cpp) makes your image automatically a lot bigger, I would suggest to put devtools into a SDK, which could be shipped separately.


Next thing you can do is to analyze the what is actually so big in your image, e.g. by creating a tar.gz of the image, unpacking it and browsing by 'du -sh *'.
You can get the package/recipe to a file by using 'oe-pkgdata-util find-path <path>'.


In the identified recipe you can look for PACKAGECONFIG or OE_EXTRACONF switches that you don't need and disable them.


As said, I don't know what the purpose/environment of your image will be like, but you could also consider to use a different fs-format like squash.


In general if you want small images preferring musl over glibc and systemV over systemd is something that you could consider as well.


TL;DR


1) move to SDK

2) check PACKAGECONFIG switches

3) same as 2 or consider something "smaller" like lxc

4) same as 2

5) same as 2

6) same as 2

7) move to SDK

8) same as 2


On 28.03.20 14:25, Ajam Ali wrote:



 
Hi All,

I am trying to reduce the image size.

how can i  reduce the size of following packages so that i could get a small image size after integrating these packages in yocto?


1) boost-dev 2) docker 3) containerd-opencontainers 4) nodejs 5) nodejs-npm 6) python3-numpy 7) cpp 8) postgresql



Thanks in advance,

Ajam Ali


::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.




Re: Compressing btrfs image

Edson Seabra
 

I forget to say I'm using zeus...


From: Edson Seabra
Sent: Saturday, March 28, 2020 12:30 PM
To: yocto@... <yocto@...>
Subject: Compressing btrfs image
 
Hi all.

I'm trying to compress a btrfs rootfs

I added  in "image_types.bbclass:IMAGE_CMD_btrfs ()"  two commands:

1) mount the btrfs image after mkfs.btrfs
2) btrfs filesystem defrag + compress option

But the command mount fails:

mount: /home/edson/ng-trunk/nodegrid/tmp/work/genericx86_64-poky-linux/nodegrid/1.0-r0/deploy-nodegrid-image-complete/temp_btrfs: failed to setup loop device for /home/edson/ng-trunk/nodegrid/tmp/work/genericx86_64-poky-linux/nodegrid/1.0-r0/deploy-nodegrid-image-complete/nodegrid-genericx86-64-20200328134151.rootfs.btrfs.

I saw in image.bbclass the creation of do_image_btrfs task with flag 'fakeroot'.

====== image.bbclass ====
        task = "do_image_%s" % t.replace("-", "_").replace(".", "_")

        d.setVar(task, '\n'.join(cmds))
        d.setVarFlag(task, 'func', '1')
        d.setVarFlag(task, 'fakeroot', '1')
=======================

would the fakeroot flag allow do_image_btrfs execute commands that requires root privilege ?

If not what would be the way to execute the mount command ?

I tried "pseudo mount" but it failed same way...

Thanks in advance.

Edson.

Edson Seabra

Principal Engineer

M +1 510 579 0843

1506169147061_OutlookEmoji-1505330244060_ZPELogo_Email.png1e6c5898-d340-4c90-8c28-e559c26bc7d1.png
46757 Fremont Blvd., Fremont, CA 94538
zpesystems.com | Request a Nodegrid Demo


Compressing btrfs image

Edson Seabra
 

Hi all.

I'm trying to compress a btrfs rootfs

I added  in "image_types.bbclass:IMAGE_CMD_btrfs ()"  two commands:

1) mount the btrfs image after mkfs.btrfs
2) btrfs filesystem defrag + compress option

But the command mount fails:

mount: /home/edson/ng-trunk/nodegrid/tmp/work/genericx86_64-poky-linux/nodegrid/1.0-r0/deploy-nodegrid-image-complete/temp_btrfs: failed to setup loop device for /home/edson/ng-trunk/nodegrid/tmp/work/genericx86_64-poky-linux/nodegrid/1.0-r0/deploy-nodegrid-image-complete/nodegrid-genericx86-64-20200328134151.rootfs.btrfs.

I saw in image.bbclass the creation of do_image_btrfs task with flag 'fakeroot'.

====== image.bbclass ====
        task = "do_image_%s" % t.replace("-", "_").replace(".", "_")

        d.setVar(task, '\n'.join(cmds))
        d.setVarFlag(task, 'func', '1')
        d.setVarFlag(task, 'fakeroot', '1')
=======================

would the fakeroot flag allow do_image_btrfs execute commands that requires root privilege ?

If not what would be the way to execute the mount command ?

I tried "pseudo mount" but it failed same way...

Thanks in advance.

Edson.

Edson Seabra

Principal Engineer

M +1 510 579 0843

1506169147061_OutlookEmoji-1505330244060_ZPELogo_Email.png1e6c5898-d340-4c90-8c28-e559c26bc7d1.png
46757 Fremont Blvd., Fremont, CA 94538
zpesystems.com | Request a Nodegrid Demo


Re: Fw: Reducing rootfs size in yocto

Konrad Weihmann <kweihmann@...>
 

Pretty general questions, but I try to answer your question.


I don't know what the purpose of your image is, but installing development tools like boost-dev or gcc (I guess that is what you mean with cpp) makes your image automatically a lot bigger, I would suggest to put devtools into a SDK, which could be shipped separately.


Next thing you can do is to analyze the what is actually so big in your image, e.g. by creating a tar.gz of the image, unpacking it and browsing by 'du -sh *'.
You can get the package/recipe to a file by using 'oe-pkgdata-util find-path <path>'.


In the identified recipe you can look for PACKAGECONFIG or OE_EXTRACONF switches that you don't need and disable them.


As said, I don't know what the purpose/environment of your image will be like, but you could also consider to use a different fs-format like squash.


In general if you want small images preferring musl over glibc and systemV over systemd is something that you could consider as well.


TL;DR


1) move to SDK

2) check PACKAGECONFIG switches

3) same as 2 or consider something "smaller" like lxc

4) same as 2

5) same as 2

6) same as 2

7) move to SDK

8) same as 2


On 28.03.20 14:25, Ajam Ali wrote:



 
Hi All,

I am trying to reduce the image size.

how can i  reduce the size of following packages so that i could get a small image size after integrating these packages in yocto?


1) boost-dev 2) docker 3) containerd-opencontainers 4) nodejs 5) nodejs-npm 6) python3-numpy 7) cpp 8) postgresql



Thanks in advance,

Ajam Ali


::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.



    


Fw: Reducing rootfs size in yocto

Ajam Ali
 




 
Hi All,

I am trying to reduce the image size.

how can i  reduce the size of following packages so that i could get a small image size after integrating these packages in yocto?


1) boost-dev 2) docker 3) containerd-opencontainers 4) nodejs 5) nodejs-npm 6) python3-numpy 7) cpp 8) postgresql



Thanks in advance,

Ajam Ali


::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.


Files get sporadically lost for native packages

Konrad Weihmann <kweihmann@...>
 

Hi,

I'm facing the following error message sporadically on all branches I tried so far (master, zeus, warrior and thud)

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:extend_recipe_sysroot(d)
     0003:
File: '/build/poky/meta/classes/staging.bbclass', lineno: 551, function: extend_recipe_sysroot
     0547:                    dest = newmanifest[l]
     0548:                    if l.endswith("/"):
     0549:                        staging_copydir(l, targetdir, dest, seendirs)
     0550:                        continue
 *** 0551:                    staging_copyfile(l, targetdir, dest, postinsts, seendirs)
     0552:
     0553:    bb.note("Installed into sysroot: %s" % str(msg_adding))
     0554:    bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
     0555:
File: '/build/poky/meta/classes/staging.bbclass', lineno: 152, function: staging_copyfile
     0148:        os.symlink(linkto, dest)
     0149:        #bb.warn(c)
     0150:    else:
     0151:        try:
 *** 0152:            os.link(c, dest)
     0153:        except OSError as err:
     0154:            if err.errno == errno.EXDEV:
     0155:                bb.utils.copyfile(c, dest)
     0156:            else:
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc' -> '/build/poky/build/tmp/work/qemux86_64-mine-linux/core-image-minimal-mine/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc'

I already had a look at the manifest

cat manifest-x86_64-python3-msgcheck-native.populate_sysroot
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__init__.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/po.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/msgcheck.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/po.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/msgcheck.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/dependency_links.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/requires.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/top_level.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/SOURCES.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/PKG-INFO
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/entry_points.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/msgcheck
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/sysroot-providers/python3-msgcheck-native
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/sysroot-providers/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/share/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/

which states the file should be there, but when doing

find /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__init__.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/po.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/msgcheck.cpython-37.pyc
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/po.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/msgcheck.py
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/dependency_links.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/requires.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/top_level.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/SOURCES.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/PKG-INFO
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/entry_points.txt
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/msgcheck
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/share

the file isn't there.

This happens to random python packages compiled as native (sometimes even for python-native itself), but (afaik) not for cross or target packages (I'm pretty sure because of the different packaging applied).
So I digged a little into the code classes/sstate.bbclass:sstate_install, which seems to create the sysroot-component dir and the manifest.
There is a gap between the manifest creation (line 285) and the hardlinking (line till 311).

Now my question is there any place where a file potentially could get lost? - at first glance there shouldn't be one - I have to admit that I don't fully understand all this subprocess magic in lib/oe/path.py:copyhardlinktree.
What I do to fix the issue is reopening the manifest and double check for missing files and remove them from the manifest, but this
feels wrong - so any advise is welcome...

Hope that someone more familiar with the topic could have a look.

Thanks

Konrad


Re: [meta-security][PATCH] openscap-daemon: add missing runtime dependencies

Armin Kuster
 



On 3/9/20 5:45 AM, Yi Zhao wrote:
Add missing runtime dependencies otherwise /usr/bin/oscapd can not
startup.

Signed-off-by: Yi Zhao <yi.zhao@...>
merged.

thanks,
Armin
---
 .../openscap-daemon/openscap-daemon_0.1.10.bb                | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb b/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
index ca6e030..a775021 100644
--- a/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
+++ b/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
@@ -17,4 +17,7 @@ inherit setuptools3
 
 S = "${WORKDIR}/git"
 
-RDEPENDS_${PN} = "python"
+RDEPENDS_${PN} = "openscap scap-security-guide \
+                  python3-core python3-dbus \
+                  python3-pygobject \
+                 "


    


Re: [meta-security][PATCH] layer.conf: update LAYERSERIES_COMPAT for dunfell

Armin Kuster
 



On 3/25/20 6:01 AM, Martin Jansa wrote:
Signed-off-by: Martin Jansa <Martin.Jansa@...>
Merged.

thanks,
Armin
---
 conf/layer.conf                          | 2 +-
 meta-integrity/conf/layer.conf           | 2 +-
 meta-security-compliance/conf/layer.conf | 2 +-
 meta-security-isafw/conf/layer.conf      | 2 +-
 meta-tpm/conf/layer.conf                 | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 3e890e1..2c3bd96 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -9,6 +9,6 @@ BBFILE_COLLECTIONS += "security"
 BBFILE_PATTERN_security = "^${LAYERDIR}/"
 BBFILE_PRIORITY_security = "8"
 
-LAYERSERIES_COMPAT_security = "zeus"
+LAYERSERIES_COMPAT_security = "dunfell"
 
 LAYERDEPENDS_security = "core openembedded-layer perl-layer networking-layer meta-python"
diff --git a/meta-integrity/conf/layer.conf b/meta-integrity/conf/layer.conf
index bfc9c6f..b4edac3 100644
--- a/meta-integrity/conf/layer.conf
+++ b/meta-integrity/conf/layer.conf
@@ -21,7 +21,7 @@ INTEGRITY_BASE := '${LAYERDIR}'
 # interactive shell is enough.
 OE_TERMINAL_EXPORTS += "INTEGRITY_BASE"
 
-LAYERSERIES_COMPAT_integrity = "zeus"
+LAYERSERIES_COMPAT_integrity = "dunfell"
 # ima-evm-utils depends on keyutils from meta-oe
 LAYERDEPENDS_integrity = "core openembedded-layer"
 
diff --git a/meta-security-compliance/conf/layer.conf b/meta-security-compliance/conf/layer.conf
index 8572a1f..965c837 100644
--- a/meta-security-compliance/conf/layer.conf
+++ b/meta-security-compliance/conf/layer.conf
@@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "scanners-layer"
 BBFILE_PATTERN_scanners-layer = "^${LAYERDIR}/"
 BBFILE_PRIORITY_scanners-layer = "10"
 
-LAYERSERIES_COMPAT_scanners-layer = "zeus"
+LAYERSERIES_COMPAT_scanners-layer = "dunfell"
 
 LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python"
 
diff --git a/meta-security-isafw/conf/layer.conf b/meta-security-isafw/conf/layer.conf
index 241c461..63f990a 100644
--- a/meta-security-isafw/conf/layer.conf
+++ b/meta-security-isafw/conf/layer.conf
@@ -14,4 +14,4 @@ LAYERVERSION_security-isafw = "1"
 
 LAYERDEPENDS_security-isafw = "core"
 
-LAYERSERIES_COMPAT_security-isafw = "zeus"
+LAYERSERIES_COMPAT_security-isafw = "dunfell"
diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index 175eba8..c3372c7 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "tpm-layer"
 BBFILE_PATTERN_tpm-layer = "^${LAYERDIR}/"
 BBFILE_PRIORITY_tpm-layer = "10"
 
-LAYERSERIES_COMPAT_tpm-layer = "zeus"
+LAYERSERIES_COMPAT_tpm-layer = "dunfell"
 
 LAYERDEPENDS_tpm-layer = " \
     core \


    


Re: [meta-security][PATCH 1/6] sssd: Sort PACKAGECONFIG entries

Armin Kuster
 



On 3/25/20 4:43 AM, Jonatan Pålsson wrote:
Signed-off-by: Jonatan Pålsson <jonatan.p@...>

series merged.

thanks
Armin
---
 recipes-security/sssd/sssd_1.16.4.bb | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/recipes-security/sssd/sssd_1.16.4.bb b/recipes-security/sssd/sssd_1.16.4.bb
index c5ddd5c..b0b7038 100644
--- a/recipes-security/sssd/sssd_1.16.4.bb
+++ b/recipes-security/sssd/sssd_1.16.4.bb
@@ -37,18 +37,18 @@ PACKAGECONFIG ?="nss nscd"
 PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)}"
 PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)}"
 
-PACKAGECONFIG[ssh] = "--with-ssh, --with-ssh=no, "
-PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
-PACKAGECONFIG[selinux] = "--with-selinux, --with-selinux=no --with-semanage=no, libselinux"
-PACKAGECONFIG[manpages] = "--with-manpages, --with-manpages=no"
-PACKAGECONFIG[python3] = "--with-python3-bindings, --without-python3-bindings"
-PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
 PACKAGECONFIG[crypto] = "--with-crypto=libcrypto, , libcrypto"
-PACKAGECONFIG[nscd] = "--with-nscd=${sbindir}, --with-nscd=no "
+PACKAGECONFIG[curl] = "--with-secrets --with-kcm, --without-secrets --without-kcm, curl"
+PACKAGECONFIG[http] = "--with-secrets, --without-secrets, apache2"
+PACKAGECONFIG[manpages] = "--with-manpages, --with-manpages=no"
 PACKAGECONFIG[nl] = "--with-libnl, --with-libnl=no, libnl"
+PACKAGECONFIG[nscd] = "--with-nscd=${sbindir}, --with-nscd=no "
+PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
+PACKAGECONFIG[python3] = "--with-python3-bindings, --without-python3-bindings"
+PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
+PACKAGECONFIG[selinux] = "--with-selinux, --with-selinux=no --with-semanage=no, libselinux"
+PACKAGECONFIG[ssh] = "--with-ssh, --with-ssh=no, "
 PACKAGECONFIG[systemd] = "--with-initscript=systemd,--with-initscript=sysv"
-PACKAGECONFIG[http] = "--with-secrets, --without-secrets, apache2"
-PACKAGECONFIG[curl] = "--with-secrets --with-kcm, --without-secrets --without-kcm, curl"
 
 EXTRA_OECONF += " \
     --disable-cifs-idmap-plugin \



      

    


Re: [opkg-devel] [opkg-utils PATCH] Opkg.py : Support for tilde in version compare

Alejandro del Castillo <alejandro.delcastillo@...>
 

Hi Marteen,

thanks for working on this, a couple of comments

On 3/19/20 6:26 AM, Maarten wrote:
Add support for the special tilde character. The current opkg version
allows specifying a version appended with a tilde e.g.
1.2.2~releasecandidate which is lower in version than 1.2.2 itself. With
this commit, this is now also supported by the opkg.py script.
Signed-off-by: Maarten <maarten.vanmegen@...>
---
opkg.py | 132 ++++++++++++++++++++++++++++----------------------------
1 file changed, 66 insertions(+), 66 deletions(-)
diff --git a/opkg.py b/opkg.py
index ba947c2..34af483 100644
--- a/opkg.py
+++ b/opkg.py
@@ -1,5 +1,4 @@
-#!/usr/bin/env python3
-# SPDX-License-Identifier: GPL-2.0-or-later
did you intentionally modified the shebang & removed the SPDX identifier?

+#!/usr/bin/env python
# Copyright (C) 2001 Alexander S. Guy <a7r@...>
# Andern Research Labs
#
@@ -38,58 +37,86 @@ from __future__ import print_function
import tempfile
import os
import sys
-import glob
import hashlib
import re
import subprocess
from stat import ST_SIZE
import arfile
import tarfile
-import textwrap
import collections
+
+def order(x):
+ if not x:
+ return 0
+ if x == "~":
+ return -1
+ if str.isdigit(x):
+ return 0
+ if str.isalpha(x):
+ return ord(x)
+
+ return 256 + ord(x)
+
+
class Version(object):
"""A class for holding parsed package version information."""
+
def __init__(self, epoch, version):
self.epoch = epoch
self.version = version
def _versioncompare(self, selfversion, refversion):
+ """
+ Implementation below is a copy of the opkg version comparison algorithm
+ https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/opkg/tree/libopkg/pkg.c*n933__;Iw!!FbZ0ZwI3Qg!5LDeOr__t_Ow1oYBFtvf1sVRXNIPxT_bNylibWik21KDrv8His3FsfSxBbFI88ZZzzTfeg$
+ it alternates between number and non number comparisons until a difference is found
+ digits are compared by value. other characters are sorted lexically using the above method orderOfChar
+
+ One slight modification, the original version can return any value, whereas this one is limited to -1, 0, +1
+ """
if not selfversion: selfversion = ""
if not refversion: refversion = ""
- while 1:
- ## first look for non-numeric version component
- selfm = re.match('([^0-9]*)(.*)', selfversion)
- #print(('selfm', selfm.groups()))
- (selfalpha, selfversion) = selfm.groups()
- refm = re.match('([^0-9]*)(.*)', refversion)
- #print(('refm', refm.groups())
- (refalpha, refversion) = refm.groups()
- if (selfalpha > refalpha):
- return 1
- elif (selfalpha < refalpha):
- return -1
- ## now look for numeric version component
- (selfnum, selfversion) = re.match('([0-9]*)(.*)', selfversion).groups()
- (refnum, refversion) = re.match('([0-9]*)(.*)', refversion).groups()
- #print(('selfnum', selfnum, selfversion)
- #print(('refnum', refnum, refversion)
- if (selfnum != ''):
- selfnum = int(selfnum)
- else:
- selfnum = -1
- if (refnum != ''):
- refnum = int(refnum)
- else:
- refnum = -1
- if (selfnum > refnum):
+
+ value = list(selfversion)
+ ref = list(refversion)
+
+ while value or ref:
+ first_diff = 0
+ # alphanumeric comparison
+ while (value and not str.isdigit(value[0])) or (ref and not str.isdigit(ref[0])):
+ vc = order(value.pop(0) if value else None)
+ rc = order(ref.pop(0) if ref else None)
+ if vc != rc:
+ return -1 if vc < rc else 1
+
+ # comparing numbers
+ # start by skipping 0
+ while value and value[0] == "0":
+ value.pop(0)
+ while ref and ref[0] == "0":
+ ref.pop(0)
+
+ # actual number comparison
+ while value and str.isdigit(value[0]) and ref and str.isdigit(ref[0]):
+ if not first_diff:
+ first_diff = int(value.pop(0)) - int(ref.pop(0))
+ else:
+ value.pop(0)
+ ref.pop(0)
+
+ # the one that has a value remaining was the highest number
+ if value and str.isdigit(value[0]):
return 1
- elif (selfnum < refnum):
+ if ref and str.isdigit(ref[0]):
return -1
- if selfversion == '' and refversion == '':
- return 0
+ # in case of equal length numbers look at the first diff
+ if first_diff:
+ return 1 if first_diff > 0 else -1
+ return 0
def compare(self, ref):
+
if (self.epoch > ref.epoch):
return 1
elif (self.epoch < ref.epoch):
@@ -191,9 +218,6 @@ class Package(object):
if name == "md5":
self._computeFileMD5()
return self.md5
- elif name == "sha256":
- self._computeFileSHA256()
- return self.sha256
this seems unrelated to your patch, was it intentional to remove sha256 support?

elif name == 'size':
return self._get_file_size()
else:
@@ -213,20 +237,6 @@ class Package(object):
f.close()
self.md5 = sum.hexdigest()
- def _computeFileSHA256(self):
- # compute the SHA256.
- if not self.fn:
- self.sha256 = 'Unknown'
- else:
- f = open(self.fn, "rb")
- sum = hashlib.sha256()
- while True:
- data = f.read(1024)
- if not data: break
- sum.update(data)
- f.close()
- self.sha256 = sum.hexdigest()
-
same here

def _get_file_size(self):
if not self.fn:
self.size = 0;
@@ -259,8 +269,6 @@ class Package(object):
self.size = int(value)
elif name_lowercase == 'md5sum':
self.md5 = value
- elif name_lowercase == 'sha256sum':
- self.sha256 = value
and here

elif name_lowercase in self.__dict__:
self.__dict__[name_lowercase] = value
elif all_fields:
@@ -384,7 +392,6 @@ class Package(object):
error = subprocess.CalledProcessError(retcode, cmd)
error.output = output
raise error
- output = output.decode("utf-8")
return output
if not self.fn:
@@ -408,12 +415,8 @@ class Package(object):
return []
f = open(self.fn, "rb")
ar = arfile.ArFile(f, self.fn)
- try:
- tarStream = ar.open("data.tar.gz")
- tarf = tarfile.open("data.tar.gz", "r", tarStream)
- except IOError:
- tarStream = ar.open("data.tar.xz")
- tarf = tarfile.open("data.tar.xz", "r:xz", tarStream)
+ tarStream = ar.open("data.tar.gz")
+ tarf = tarfile.open("data.tar.gz", "r", tarStream)
this also seem to revert a newer commit (add xz support)

self.file_list = tarf.getnames()
self.file_list = [["./", ""][a.startswith("./")] + a for a in self.file_list]
@@ -488,7 +491,7 @@ class Package(object):
ref.parsed_version = parse_version(ref.version)
return self.parsed_version.compare(ref.parsed_version)
- def print(self, checksum):
+ def __str__(self):
this change also looks unrelated

out = ""
# XXX - Some checks need to be made, and some exceptions
@@ -505,10 +508,7 @@ class Package(object):
if self.section: out = out + "Section: %s\n" % (self.section)
if self.architecture: out = out + "Architecture: %s\n" % (self.architecture)
if self.maintainer: out = out + "Maintainer: %s\n" % (self.maintainer)
- if 'md5' in checksum:
- if self.md5: out = out + "MD5Sum: %s\n" % (self.md5)
- if 'sha256' in checksum:
- if self.sha256: out = out + "SHA256sum: %s\n" % (self.sha256)
+ if self.md5: out = out + "MD5Sum: %s\n" % (self.md5)
if self.size: out = out + "Size: %d\n" % int(self.size)
if self.installed_size: out = out + "InstalledSize: %d\n" % int(self.installed_size)
if self.filename: out = out + "Filename: %s\n" % (self.filename)
@@ -585,14 +585,14 @@ class Packages(object):
def __getitem__(self, key):
return self.packages[key]
-if __name__ == "__main__":
+if __name__ == "__main__":
assert Version(0, "1.2.2-r1").compare(Version(0, "1.2.3-r0")) == -1
assert Version(0, "1.2.2-r0").compare(Version(0, "1.2.2+cvs20070308-r0")) == -1
assert Version(0, "1.2.2+cvs20070308").compare(Version(0, "1.2.2-r0")) == 1
assert Version(0, "1.2.2-r0").compare(Version(0, "1.2.2-r0")) == 0
assert Version(0, "1.2.2-r5").compare(Version(0, "1.2.2-r0")) == 1
-
+ assert Version(0, "1.1.2~r1").compare(Version(0, "1.1.2")) == -1
package = Package()
package.set_package("FooBar")
--
Cheers,

Alejandro


Re: Mechanism behind pkg_postinst_ontarget_${PN} #yocto

Quentin Schulz
 

Hi Stefan,

On Fri, Mar 27, 2020 at 06:41:57AM -0700, stefan.wenninger@... wrote:
Hi Quentin,
I have now read up on the exact meaning of PROVIDES and PACKAGES and I do understand your response.
It does sound like I am talking about PACKAGES since I did suspect PROVIDES to work like that.
Well at least if PROVIDES would work like that, it would explain why my postinstall did not work previously.

But I did use PROVIDES, which I now know is basically just a alias.

Here is the situation I had before and how I solved it:

Previous attempt:
*my_recipe.bb:*
...
PROVIDES += "my_recipes_package"
Your recipe can now be used in DEPENDS of other recipes with both "my-recipe"
and "my-recipe-package". N.B.: please do not use underscore in recipe
names, it can have weird consequences (been there, trust me). I assume
it's only for the sake of an example so it's fine.

RPROVIDES_${PN} += "my_recipes_package"
Here, you mean, ${PN} (packaged named my-recipe which is the main
package usually) can also be known as my-recipes-package, it's another
alias, for different thing but still nothing crazy.

pkg_postinst_ontarget_${PN} () {
#!/bin/sh
file=$D/home/root/test/test.txt
printf "hello world\n" > $file
}

*my_image.bb:*
IMAGE_INSTALL += " my_recipes_package "
"Please install my-recipes-package which is an alias to my-recipe
package."

This actually seems okay to me. So if no typo and no underscore, I'm
clueless.

Can you try that exact same recipe but with:
pkg_postinst_ontarget_my-recipes-package instead of
pkg_postinst_ontarget_${PN} ()?

And another try, with the exact same recipe (so not the modification
asked above), with IMAGE_INSTALL += "my-recipe"?

In any case, this seems to me to be bug that should be reported.

Quentin


Re: Mechanism behind pkg_postinst_ontarget_${PN} #yocto

stefan.wenninger@...
 

Hi Quentin,
I have now read up on the exact meaning of PROVIDES and PACKAGES and I do understand your response.
It does sound like I am talking about PACKAGES since I did suspect PROVIDES to work like that.
Well at least if PROVIDES would work like that, it would explain why my postinstall did not work previously.

But I did use PROVIDES, which I now know is basically just a alias.

Here is the situation I had before and how I solved it:

Previous attempt:
my_recipe.bb:
...
PROVIDES += "my_recipes_package"
RPROVIDES_${PN} += "my_recipes_package"

pkg_postinst_ontarget_${PN} () {
#!/bin/sh
file=$D/home/root/test/test.txt
printf "hello world\n" > $file
}

my_image.bb:
IMAGE_INSTALL += " my_recipes_package "

current solution:
my_recipe.bb:
...
pkg_postinst_ontarget_${PN} () {
#!/bin/sh
file=$D/home/root/test/test.txt
printf "hello world\n" > $file
}

my_image.bb:
IMAGE_INSTALL += " my_recipe "

I can only guess that the postinst was only attached to the package called "my_recipe" and not to its alias "my_recipes_package"?

Stefan


Re: Mechanism behind pkg_postinst_ontarget_${PN} #yocto

Quentin Schulz
 

Hi Stefan,

On Fri, Mar 27, 2020 at 05:26:23AM -0700, stefan.wenninger@... wrote:
I think the relevant part for me in that script is the func exec_postinst_scriplets(). It looks to me as if this function iterates through all scripts in the /etc/deb-postinsts directory in my case and executes them with "sh".
My problem seems to have stemmed from confusion on my part about what package the postinst attaches to.
The postinst belongs to the package with the same name as my recipe because of the _${PN}. However I specified that my recipe produces another package with the PROVIDES ="" variable.
I think you meant PACKAGES and not PROVIDES here. If that is the case,
then yes, congrats, you found the root cause :)

Otherwise, I think there might be something worth debugging and maybe
reporting.

Quentin


Re: Mechanism behind pkg_postinst_ontarget_${PN} #yocto

stefan.wenninger@...
 

I think the relevant part for me in that script is the func exec_postinst_scriplets(). It looks to me as if this function iterates through all scripts in the /etc/deb-postinsts directory in my case and executes them with "sh".
My problem seems to have stemmed from confusion on my part about what package the postinst attaches to.
The postinst belongs to the package with the same name as my recipe because of the _${PN}. However I specified that my recipe produces another package with the PROVIDES ="" variable.
In my IMAGE_INSTALL I only added the package I specifically provide. Therefore the recipe package with the postinst did not end up in my rootfs.

When changing the IMAGE_INSTALL I get my commands to be executed on the system on first boot.
I realize now that my current method of having every recipe create an extra package with PROVIDES is not really necessary.

Your hint about the run-postinsts directory was what lead me to understand the mechanism further.
And on the way I recognized a bad or at least confusing practice on my behalf.

I consider this question/problem solved, thank you very much.

Stefan


[meta-security][PATCH 2/2] apparmor: update to 2.13.4

Jan Luebbe
 

Signed-off-by: Jan Luebbe <jlu@...>
---
recipes-mac/AppArmor/{apparmor_2.13.3.bb => apparmor_2.13.4.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-mac/AppArmor/{apparmor_2.13.3.bb => apparmor_2.13.4.bb} (99%)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.3.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
similarity index 99%
rename from recipes-mac/AppArmor/apparmor_2.13.3.bb
rename to recipes-mac/AppArmor/apparmor_2.13.4.bb
index 3398a3a75baa..f8fd19eb9e00 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.3.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -25,7 +25,7 @@ SRC_URI = " \
file://run-ptest \
"

-SRCREV = "2f9d9ea7e01a115b29858455d3b1b5c6a0bab75c"
+SRCREV = "df0ac742f7a1146181d8734d03334494f2015134"
S = "${WORKDIR}/git"

PARALLEL_MAKE = ""
--
2.26.0.rc2

8421 - 8440 of 57386