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:
|
|
Re: patching an .inc file?
Konrad Weihmann <kweihmann@...>
What you could do is to override the file in a layer with higher
priority.
On 28.03.20 22:42, Derek Dresser wrote:
|
|
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:
I have tracked this down to the following file: 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.) 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.
toggle quoted messageShow quoted text
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:
|
|
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. 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:
|
|
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 *'.
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:
|
|
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
|
|
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
|
|
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 *'.
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:
|
|
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 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: I already had a look at the manifest cat manifest-x86_64-python3-msgcheck-native.populate_sysroot which states the file should be there, but when doing find
/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/ 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). Hope that someone more familiar with the topic could have a look. Thanks Konrad
|
|
Re: [meta-security][PATCH] openscap-daemon: add missing runtime dependencies
On 3/9/20 5:45 AM, Yi Zhao wrote:
merged.Add missing runtime dependencies otherwise /usr/bin/oscapd can not startup. Signed-off-by: Yi Zhao <yi.zhao@...> 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
On 3/25/20 6:01 AM, Martin Jansa wrote:
Merged.Signed-off-by: Martin Jansa <Martin.Jansa@...> 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
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 versiondid you intentionally modified the shebang & removed the SPDX identifier? +#!/usr/bin/env pythonthis seems unrelated to your patch, was it intentional to remove sha256 support? elif name == 'size':same here def _get_file_size(self):and here elif name_lowercase in self.__dict__:this also seem to revert a newer commit (add xz support) self.file_list = tarf.getnames()this change also looks unrelated out = ""-- 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,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} () {"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".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
|
|