|
Re: [layerindex-web][PATCH] recipeparse.py: add BBLAYERS in bblayers.conf
Changqing Li
Hi, Please ignore this patch, I need to send a V2 Thanks Changqing On 9/26/21 9:32 AM, Changqing Li wrote:
From: Changqing Li <changqing.li@...> since commit [97183e10f cookerdata: Show error for no BBLAYERS in bblayers.conf], no BBLAYERS in bblayers.conf will cause layerindex update failed with below error: ERROR: Traceback (most recent call last): File "update_layer.py", line 478, in main (tinfoil, tempdir) = recipeparse.init_parser(settings, branch, bitbakepath, nocheckout=options.nocheckout, logger=logger) File "/path/to/layerindex-web/layerindex/recipeparse.py", line 83, in init_parser tinfoil = utils.setup_tinfoil(bitbakepath, enable_tracking, loglevel=logger.getEffectiveLevel()) File "/path/to/layerindex-web/layerindex/utils.py", line 206, in setup_tinfoil tinfoil.prepare(config_only = True) File "/path/to/layerindex/git___lxgit_wrs_com_bitbake/lib/bb/tinfoil.py", line 413, in prepare config_params.updateToServer(self.server_connection.connection, os.environ.copy()) File "/path/to/layerindex/git___lxgit_wrs_com_bitbake/lib/bb/cookerdata.py", line 73, in updateToServer ret, error = server.runCommand(["updateConfig", options, environment, sys.argv]) File "/path/to/layerindex/git___lxgit_wrs_com_bitbake/lib/bb/server/process.py", line 410, in runCommand raise bb.BBHandledException() bb.BBHandledException Signed-off-by: Changqing Li <changqing.li@...> --- layerindex/recipeparse.py | 1 + 1 file changed, 1 insertion(+) diff --git a/layerindex/recipeparse.py b/layerindex/recipeparse.py index 62c08e9..d4343b4 100644 --- a/layerindex/recipeparse.py +++ b/layerindex/recipeparse.py @@ -79,6 +79,7 @@ def init_parser(settings, branch, bitbakepath, enable_tracking=False, nocheckout if not classic: # We need this to avoid problems with AVAILABLE_LICENSES f.write('COREBASE = "%s"\n' % core_repodir) + f.write('BBLAYERS ?= "%s"\n' % core_layerdir) pass if logger: |
|
|
|
[meta-security][PATCH] clamav: Move /var/lib/clamav to the main package
Zoltan Boszormenyi <zboszor@...>
From: Zoltán Böszörményi <zboszor@...>
Previously, clamav-freshclam shipped /var/lib/clamav. The main clamav package used chown in pkg_postinst to set the ownership of this directory but pkg_postinst was not marked as "ontarget" so this chown only took effect when upgrading or reinstalling the package. As a result, when clamav is part of an OS image out of the box, freshclamd (running under the clamav user) cannot populate this directory. Fix this by creating /var/lib/clamav with the proper ownership in do_install and move /var/lib/clamav to the main clamav package. This will also avoid this warning, because clamav has RDEPENDS on clamav-freshclam, not the other way around: Installing : clamav-freshclam-... 487/1954 warning: user clamav does not exist - using root warning: group clamav does not exist - using root warning: user clamav does not exist - using root warning: group clamav does not exist - using root Signed-off-by: Zoltán Böszörményi <zboszor@...> --- recipes-scanners/clamav/clamav_0.104.0.bb | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb b/recipes-scanners/clamav/clamav_0.104.0.bb index 0d3a678..e821ff1 100644 --- a/recipes-scanners/clamav/clamav_0.104.0.bb +++ b/recipes-scanners/clamav/clamav_0.104.0.bb @@ -54,7 +54,7 @@ export OECMAKE_C_FLAGS += " -I${STAGING_INCDIR} -L ${RECIPE_SYSROOT}${nonarch_li do_install:append () { install -d ${D}/${sysconfdir} - install -d ${D}/${localstatedir}/lib/clamav + install -d -o ${CLAMAV_UID} -g ${CLAMAV_GID} ${D}/${localstatedir}/lib/clamav install -d ${D}${sysconfdir}/clamav ${D}${sysconfdir}/default/volatiles install -m 644 ${WORKDIR}/clamd.conf ${D}/${prefix}/${sysconfdir} @@ -83,7 +83,6 @@ pkg_postinst:${PN} () { elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then ${sysconfdir}/init.d/populate-volatile.sh update fi - chown -R ${CLAMAV_UID}:${CLAMAV_GID} ${localstatedir}/lib/clamav fi } @@ -92,6 +91,7 @@ PACKAGES += "${PN}-daemon ${PN}-clamdscan ${PN}-freshclam ${PN}-libclamav" FILES:${PN} = "${bindir}/clambc ${bindir}/clamscan ${bindir}/clamsubmit ${sbindir}/clamonacc \ ${bindir}/*sigtool ${mandir}/man1/clambc* ${mandir}/man1/clamscan* \ ${mandir}/man1/sigtool* ${mandir}/man1/clambsubmit* \ + ${localstatedir}/lib/clamav \ ${docdir}/clamav/*" FILES:${PN}-clamdscan = " ${bindir}/clamdscan \ @@ -116,7 +116,6 @@ FILES:${PN}-freshclam = "${bindir}/freshclam \ /usr/etc/freshclam.conf* \ ${sysconfdir}/clamav ${sysconfdir}/default/volatiles \ ${sysconfdir}/tmpfiles.d/*.conf \ - ${localstatedir}/lib/clamav \ ${docdir}/${PN}-freshclam ${mandir}/man1/freshclam.* \ ${mandir}/man5/freshclam.conf.* \ ${systemd_system_unitdir}/clamav-freshclam.service" -- 2.31.1 |
|
|
|
[layerindex-web][PATCH] recipeparse.py: add BBLAYERS in bblayers.conf
Changqing Li
From: Changqing Li <changqing.li@...>
since commit [97183e10f cookerdata: Show error for no BBLAYERS in bblayers.conf], no BBLAYERS in bblayers.conf will cause layerindex update failed with below error: ERROR: Traceback (most recent call last): File "update_layer.py", line 478, in main (tinfoil, tempdir) = recipeparse.init_parser(settings, branch, bitbakepath, nocheckout=options.nocheckout, logger=logger) File "/path/to/layerindex-web/layerindex/recipeparse.py", line 83, in init_parser tinfoil = utils.setup_tinfoil(bitbakepath, enable_tracking, loglevel=logger.getEffectiveLevel()) File "/path/to/layerindex-web/layerindex/utils.py", line 206, in setup_tinfoil tinfoil.prepare(config_only = True) File "/path/to/layerindex/git___lxgit_wrs_com_bitbake/lib/bb/tinfoil.py", line 413, in prepare config_params.updateToServer(self.server_connection.connection, os.environ.copy()) File "/path/to/layerindex/git___lxgit_wrs_com_bitbake/lib/bb/cookerdata.py", line 73, in updateToServer ret, error = server.runCommand(["updateConfig", options, environment, sys.argv]) File "/path/to/layerindex/git___lxgit_wrs_com_bitbake/lib/bb/server/process.py", line 410, in runCommand raise bb.BBHandledException() bb.BBHandledException Signed-off-by: Changqing Li <changqing.li@...> --- layerindex/recipeparse.py | 1 + 1 file changed, 1 insertion(+) diff --git a/layerindex/recipeparse.py b/layerindex/recipeparse.py index 62c08e9..d4343b4 100644 --- a/layerindex/recipeparse.py +++ b/layerindex/recipeparse.py @@ -79,6 +79,7 @@ def init_parser(settings, branch, bitbakepath, enable_tracking=False, nocheckout if not classic: # We need this to avoid problems with AVAILABLE_LICENSES f.write('COREBASE = "%s"\n' % core_repodir) + f.write('BBLAYERS ?= "%s"\n' % core_layerdir) pass if logger: -- 2.17.1 |
|
|
|
Gtk+3 applications are missing icons.
Manuel Wagesreither
Hello all,
I built an image based on core-image and added the package gtk+3-demos. I'm using wayland with weston compositor. Unfortunately icons seem to be missing. Can anyone give me a hint on what went wrong? I'm on Dunfell. Here's a screenshot: https://imgur.com/syLzQ1l Thanks a lot! Manuel |
|
|
|
Re: [meta-security,dunfell][PATCH] recipes-security/fscrypt: Add fscrypt .bb file
On 9/19/21 12:19 PM, Bhupesh Sharma wrote:
fscrypt is a high-level tool for the management of LinuxWas this a double post? or a V2? I follow the OE/YP Stable process and this appears to be adding a new package to a stable release which is not allowed.. I have no issue taking it for Master. -armin
|
|
|
|
Create do_xconfig for kernel, u-boot
Khoi Dinh Trinh <khoidinhtrinh@...>
Hi All, I'm learning Yocto after spending some time with Buildroot. One of the things I like to do is to use xconfig instead of menuconfig for configuring things like kernels, u-boot, etc as it's easier to search and navigate in there. Yocto came with do_menuconfig so I tried to adapt it to use xconfig. do_menuconfig(defined in in cml1.bbclass) has KCONFIG_CONFIG_COMMAND to select which make target to use so the first thing I did was change the value from "menuconfig" to "xconfig". This didn't work since pkg-config has problems finding the Qt package when running make xconfig. I then add the meta-qt5 layer as well as adding some dependencies to do_menuconfig: do_menuconfig[depends] += "qtbase-native:do_populate_sysroot" do_menuconfig[depends] += "nativesdk-qtbase:do_populate_sysroot" This didn't work as pkg-config still has problems finding the Qt. I checked do_menuconfig's log and the only thing pkg-config seems to be able to find is gtk-docs. This is where I'm currently stumped, any help would be appreciated. Thank you for your time. -- Best, Khoi Trinh |
|
|
|
[meta-security][PATCH] chkrootkit: update to 0.55
changes:
Umbreon Linux Rootkit detection Kinsing.A Backdoor RotaJakito Backdoor Minor bug fixes Signed-off-by: Armin Kuster <akuster808@...> --- .../rootkits/{chkrootkit_0.53.bb => chkrootkit_0.55.bb} | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) rename recipes-scanners/rootkits/{chkrootkit_0.53.bb => chkrootkit_0.55.bb} (94%) diff --git a/recipes-scanners/rootkits/chkrootkit_0.53.bb b/recipes-scanners/rootkits/chkrootkit_0.55.bb similarity index 94% rename from recipes-scanners/rootkits/chkrootkit_0.53.bb rename to recipes-scanners/rootkits/chkrootkit_0.55.bb index 4536be3..20015a1 100644 --- a/recipes-scanners/rootkits/chkrootkit_0.53.bb +++ b/recipes-scanners/rootkits/chkrootkit_0.55.bb @@ -6,8 +6,7 @@ LICENSE = "BSD-2-Clause" LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=fdbe53788f7081c63387d8087273f5ff" SRC_URI = "ftp://ftp.pangeia.com.br/pub/seg/pac/${BPN}.tar.gz" -SRC_URI[sha256sum] = "7262dae33b338976828b5d156b70d159e0043c0db43ada8dee66c97387cf45b5" - +SRC_URI[sha256sum] = "a81c0286ec449313f953701202a00e81b204fc2cf43e278585a11c12a5e0258b" inherit autotools-brokensep -- 2.25.1 |
|
|
|
Re: [meta-zephyr][PATCH 1/2] zephyr-qemuboot: fix parse build failure
Jon Mason
With both of these, and the patch I just sent out, I am able to get
all of the boards building (except qemu-nios2) and passing testimage (for the qemu boards). https://gitlab.com/jonmason00/meta-zephyr/-/pipelines/376922543 Thanks, Jon On Fri, Sep 24, 2021 at 2:40 AM Naveen Saini <naveen.kumar.saini@...> wrote:
|
|
|
|
[meta-zephyr][PATCH] qemuzephyrrunner.py: use os._exit instead of sys.exit
Jon Mason
sys.exit(0) can cause an error to be reported when the child exits, even
though not an error. Since this is a child process, os._exit(0) is the proper way to exit and not cause this issue. Signed-off-by: Jon Mason <jon.mason@...> --- lib/oeqa/utils/qemuzephyrrunner.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/oeqa/utils/qemuzephyrrunner.py b/lib/oeqa/utils/qemuzephyrrunner.py index a1ed30be1ca8..7b486ce8af3f 100644 --- a/lib/oeqa/utils/qemuzephyrrunner.py +++ b/lib/oeqa/utils/qemuzephyrrunner.py @@ -191,7 +191,7 @@ class QemuZephyrRunner(QemuRunner): r = os.fdopen(r) x = r.read() os.killpg(os.getpgid(self.runqemu.pid), signal.SIGTERM) - sys.exit(0) + os._exit(0) bb.note("qemu started, pid is %s" % self.runqemu.pid) return self.create_socket() -- 2.20.1 |
|
|
|
Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device
Trevor Woerner
On Sat 2021-09-25 @ 09:56:21 AM, Markus Volk wrote:
Probably. You'll need to re-send this with a better subject line and commit message so the right people will notice it. Otherwise they'll think it's meta-rockchip-specific. If (when) this patch gets applied upstream, then we can remove our work-around. This is a fantastic find, I'm guessing other BSP layers might find it useful. I was thinking of investigating adding a per-line "--no-fstab" option to wic to indicate specific lines not desired in the fstab, but this looks much nicer. |
|
|
|
Re: [meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default
Trevor Woerner
On Thu 2021-09-23 @ 11:17:59 PM, Markus Volk wrote:
Signed-off-by: MarkusVolk <f_l_k@...>Applied to meta-rockchip master (with an updated commit message), thanks! |
|
|
|
Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device
Markus Volk
Am 23.09.21 um 22:55 schrieb Trevor
Woerner:
We can add the --use-uuid line to the /boot entry if you really think it should be mounted on boot, but we shouldn't use it on the others and cause wic to generate a bad fstab. There are examples of other boards that don't mount /boot by default (raspi for sure, and I think bbb too). Could the solution be as simple as this? From b8ba56d84fbac53901e5b7ca122498320e51fbf4 Mon Sep 17 00:00:00 2001 From: MarkusVolk <f_l_k@...> Date: Sat, 25 Sep 2021 09:21:15 +0200 Subject: [PATCH] wic:direct.py: improve filter for fstab update Signed-off-by: MarkusVolk <f_l_k@...> --- scripts/lib/wic/plugins/imager/direct.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/lib/wic/plugins/imager/direct.py b/scripts/lib/wic/plugins/imager/direct.py index 9d10ec01d0..15fa47356f 100644 --- a/scripts/lib/wic/plugins/imager/direct.py +++ b/scripts/lib/wic/plugins/imager/direct.py @@ -117,7 +117,7 @@ class DirectPlugin(ImagerPlugin): updated = False for part in self.parts: if not part.realnum or not part.mountpoint \ - or part.mountpoint == "/": + or part.mountpoint == "/" or not part.mountpoint.startswith('/'): continue if part.use_uuid: -- 2.25.1 With this patch wic only adds the /boot mountpoint. The invalid entries get filtered out. We would then only need to set --use-uuid for /boot to avoid the system from crashing if 'no-fstab-update' isn't expicitly given as an argument |
|
|
|
Re: [meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default
Markus Volk
Am 24.09.21 um 15:10 schrieb Trevor
Woerner:
Thanks for the patch and the SoB line. I'm going to apply this patch, but I'm going to amend the commit message to capture some of the conversation we've had. There's a chance we'll want to know "why" at some point in the future ;-) Thanks for applying :) It would be cool if wic had something like an 'exclude-from-fstab-update" option. That would make the 'fstab-update' much more useful. |
|
|
|
Re: Cross-compiling or compiling on target VM?
On 9/24/21 2:06 AM, arnaud.bienner@... wrote:
Hi,there are different possibilities you have with all great tooling you get with yocto project, I think you have made a good choice. inherently Yocto project is a cross compiling infrastructure so lot of commonly used workflows will be around cross-compiling, however you can also leverage it in ways you described, where you build a development VM using yocto project itself which includes all the tools your developers would need and use that as build env + devtest env, see core-image-sato-sdk. However, this will be more of less a static env, which means devs wont be able to install packages like they might be doing with debian VM, you will have to either rebuild the VM or publish own feeds, but if you expect this to be static env then this might turn out to be ok. Advantage is that you will use same tools that your final target will use and you have ease of native development and folks not familiar with yocto can be effective as well. However this is not a common workflow that yocto project users might be using, so community support might be scarce. Other option could be that you do cross builds on your debian VM and use qemux86-64 as target and run your tests using ptest framework so you will be running your target VM in qemu on top of your build running debian which is running on windows/MacOS or Linux baremetal. There might be some quirks to use qemu in VM but I think it should work out well. This also means that in future when you target real hardware ( I assume thats what you want eventually ) then not much changes, you add another MACHINE and workflow remains pretty much same. But this would require your devs to learn a bit of yocto-fu and cross-complation workflows. In advance, thanks a lot for your help. |
|
|
|
[PATCH] yocto-bsp/5.13: drop recipes
Bruce Ashfield
From: Bruce Ashfield <bruce.ashfield@...>
5.13 has been removed from core, and we've moved the default support to 5.14, so we can drop our bbappend. Signed-off-by: Bruce Ashfield <bruce.ashfield@...> --- .../linux/linux-yocto_5.13.bbappend | 23 ------------------- 1 file changed, 23 deletions(-) delete mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend deleted file mode 100644 index daf5fd2cd6..0000000000 --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend +++ /dev/null @@ -1,23 +0,0 @@ -KBRANCH:genericx86 = "v5.13/standard/base" -KBRANCH:genericx86-64 = "v5.13/standard/base" -KBRANCH:edgerouter = "v5.13/standard/edgerouter" -KBRANCH:beaglebone-yocto = "v5.13/standard/beaglebone" - -KMACHINE:genericx86 ?= "common-pc" -KMACHINE:genericx86-64 ?= "common-pc-64" -KMACHINE:beaglebone-yocto ?= "beaglebone" - -SRCREV_machine:genericx86 ?= "7280c93f5599946db3add473eeb05b34c364938d" -SRCREV_machine:genericx86-64 ?= "7280c93f5599946db3add473eeb05b34c364938d" -SRCREV_machine:edgerouter ?= "a832a0390e96c4f014d7b2bf9f161ac9477140f7" -SRCREV_machine:beaglebone-yocto ?= "dbdc921374c057a75b2df92302124994e241ca51" - -COMPATIBLE_MACHINE:genericx86 = "genericx86" -COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64" -COMPATIBLE_MACHINE:edgerouter = "edgerouter" -COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto" - -LINUX_VERSION:genericx86 = "5.13.15" -LINUX_VERSION:genericx86-64 = "5.13.15" -LINUX_VERSION:edgerouter = "5.13.15" -LINUX_VERSION:beaglebone-yocto = "5.13.15" -- 2.19.1 |
|
|
|
Re: #yocto -third party licensimg
#yocto
Hi Steven,
Please see my comments inline On 24/09/2021 14:10, Monsees, Steven C (US) via lists.yoctoproject.org wrote: The one solution I found says : Add *LICENSE_PATH += "${LAYERDIR}/custom-licenses"* under conf/layer.conf, *this does not resolve this warning*.I am a bit confused, but can try to show you what I typically do. In my custom meta-my-layer I add to layer.conf: #--> LICENSE_PATH += " ${LAYERDIR}/custom-licenses" CUSTOM_COMMON_LICENSE_DIR := '${@os.path.normpath("${LAYERDIR}/custom-licenses")}' BB_HASHBASE_WHITELIST_append = " CUSTOM_COMMON_LICENSE_DIR" #<-- underneath the custom-licenses dir in this meta-my-layer I put the custom "hello-license". *Can you tell me the proper way to add a custom license to a recipe in yocto ?*Once you did something like mentioned above you can add the license to the recipe you use to build the funny component of your supplier. example_0.1.bb: LICENSE = "hello-license" LIC_FILES_CHKSUM = "file://${CUSTOM_COMMON_LICENSE_DIR}/hello-license;beginline=5;endline=12;md5=36e6988a930e054886e6af19372edb07" If you want to get fancy, since it does not seem to be an open source license, you can mark it also as: LICENSE_FLAGS = "commercial" in the recipe but then you need to whitelist e.g. in your local.conf to be able to bitbake it: # whitelist example recipe, which is under a commercial license LICENSE_FLAGS_WHITELIST = "commercial_example" Thanks,Hope this helps, Regards, Robert |
|
|
|
Re: [meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default
Trevor Woerner
On Thu 2021-09-23 @ 11:17:59 PM, Markus Volk wrote:
Signed-off-by: MarkusVolk <f_l_k@...>Thanks for the patch and the SoB line. I'm going to apply this patch, but I'm going to amend the commit message to capture some of the conversation we've had. There's a chance we'll want to know "why" at some point in the future ;-) |
|
|
|
Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device
Trevor Woerner
On Thu 2021-09-23 @ 09:46:40 PM, Khem Raj wrote:
are you both using systemd or sysvinitAh, good catch. I'm using sysvinit. |
|
|
|
#yocto -third party licensimg
#yocto
Monsees, Steven C (US)
Hello:
I am running zeus 3.0.4…
A vendor has supplied us with a generic license.txt file, which we were able to add to the acexpci recipe we use to build in their package. The license provided to us by the vendor is not part of the generic licenses list that yocto recognizes.
We get a warning though which says:
WARNING: aiox-defaultfs-1.0-r0 do_rootfs: The license listed DataDeviceCorporation was not in the licenses collected for recipe acexpci
Though the warning occurs, I can see the license.txt being saved inside the rootfs on and is saved under tmp/deploy/licenses/acexpci. I’ve been trying to get rid of this warning when the image builds, but I can’t seem to find anything in the manuals or online.
The one solution I found says : Add LICENSE_PATH += "${LAYERDIR}/custom-licenses" under conf/layer.conf, this does not resolve this warning.
This is a new item being added to our Yocto build. The Data Direct vendor does not submit their code to Yocto because they sell thier code. We are adding code to Yocto that has a private license and we are attempting to have Yocto accept the license, is this proper way to handle this ?
Can you tell me the proper way to add a custom license to a recipe in yocto ?
Thanks, Steve |
|
|
|
Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device
Markus Volk
Am 24.09.21 um 06:46 schrieb Khem Raj:
are you both using systemd or sysvinit I am using systemd |
|
|