[OE-core] [PATCH] openssl: honour calling environment's values in wrapper script

From: Rasmus Villemoes When using openssl with some pkcs#11 plugin module, one (usually) needs to set the OPENSSL_CONF environment variable appropriately, and e.g. invoke openssl as openssl dgst -engine pkcs11 -keyform engine ... However, when putting that logic in a bitbake recipe and depend

[OE-core] [PATCH] openssl: fold result of sed invocation into environment file

From: Rasmus Villemoes A long time ago, the environment.d-openssl.sh file was shared between openssl 1.0 and openssl 1.1 recipes, and sed was used to make the path right for the 1.1 version. Nowadays, with only a single recipe, this is a bit roundabout, so just use the proper path in the file dir

[OE-core] [PATCH] systemd-netlogd: new recipe

From: Rasmus Villemoes In some deployments, the log aggregator collects log messages in the syslog format, so systemd-journal-upload and friends can not be used. systemd-netlogd is a daemon for filling that gap. Signed-off-by: Rasmus Villemoes --- .../systemd/systemd-netlogd_1.4.4.bb

Re: [OE-core] [PATCH v2] linux-yocto: add and use GPL-2.0-with-syscall-note license

On Tue, Dec 03 2024, "Denis OSTERLAND-HEIM via lists.openembedded.org" wrote: > See Linux COPYING, LICENSES/preferred/GPL-2.0 > and LICENSES/exceptions/Linux-syscall-note. > > + [snip GPL text] > + > + NOTE! This copyright does *not* cover user programs that use kernel > + services by normal s

[OE-core] [PATCH] gcc: remove unused JAVA variable

From: Rasmus Villemoes As commit 81551871b183 (gcc: Remove Java support variables) correctly stated Java support was removed in upstream gcc 7. but this line snuck back in with commit bbf32e24608c (gcc-9: Add recipes for gcc 9.1 release). Signed-off-by: Rasmus Villemoes --- meta/recipes-de

Re: [OE-core] [PATCH] bitbake.conf: set FILESYSTEM_PERMS_TABLES using ??=

On Fri, Nov 22 2024, Peter Kjellerstedt wrote: >> From: Rasmus Villemoes >> >> This default value of FILESYSTEM_PERMS_TABLES is set before >> local.conf, ${DISTRO}.conf etc. are parsed. So in order for >> ${DISTRO}.conf to define the value, it has to use =. But that then >> precludes the ${MACH

[OE-core] [PATCH] bitbake.conf: set FILESYSTEM_PERMS_TABLES using ??=

From: Rasmus Villemoes This default value of FILESYSTEM_PERMS_TABLES is set before local.conf, ${DISTRO}.conf etc. are parsed. So in order for ${DISTRO}.conf to define the value, it has to use =. But that then precludes the ${MACHINE}.conf from having final say, unless one there resorts to some o

[OE-core] [PATCH] dosfstools: add backported patch for honouring SOURCE_DATE_EPOCH

From: Rasmus Villemoes From: Rasmus Villemoes Currently, file system images created with mkfs.vfat are not reproducible, because both the file system creation time and the volume id are derived from the current time. Upstream has added a patch for deriving those from SOURCE_DATE_EPOCH, when de

Re: [OE-core] openssl environment variables

On Tue, Oct 29 2024, Richard Purdie wrote: > On Tue, 2024-10-29 at 10:01 +0100, Rasmus Villemoes via > lists.openembedded.org wrote: >> I'm wondering if anybody has encountered this problem before, and if so, >> if there is a clean solution: >> >> When usin

[OE-core] openssl environment variables

Hi I'm wondering if anybody has encountered this problem before, and if so, if there is a clean solution: When using openssl-native, there's machinery in place so that when openssl-the-binary is called, it's done through a wrapper script that sets OPENSSL_CONF SSL_CERT_DIR SSL_CERT_FILE OPENSSL_

[OE-core] [PATCH] systemd: include sysvinit in default PACKAGECONFIG only if in DISTRO_FEATURES

From: Rasmus Villemoes The sysvinit PACKAGECONFIG knob enables various legacy/compatibility code that may not be needed or even desired. If DISTRO_FEATURES includes systemd (as it must for this recipe to build) but not sysvinit, there is no point building and installing that legacy support. As m

[OE-core] [PATCH] openssh: factor out sshd hostkey setup to separate function

From: Rasmus Villemoes Commit 0827c29566 (openssh: allow configuration of hostkey type) broke our setup. We make use of the 'Include /etc/ssh/sshd_config.d/*.conf' and put a hostkeys.conf file in there, configuring the types and locations of the sshd host keys. With that commit, we now get an ex

[OE-core] [PATCH] iptables: remove /etc/ethertypes

From: Rasmus Villemoes When building an image including iptable built with the libnftnl PACKAGECONFIG, one hits Downloading file:.../oe-rootfs-repo/armv8a/libkmod2 * check_data_file_clashes: Package iptables wants to install file .../rootfs/etc/ethertypes But that file is already provid

Re: [OE-core] [PATCH] openssh: allow configuration of hostkey type

"Matthew Bullock via lists.openembedded.org" writes: > Allow selection of host key types used by openssh via PACKAGECONFIG. > Any combination of hostkey-rsa, hostkey-ecdsa and hostkey-ed25519 can be > specified. Default to just generating ecdsa keys. > > The current default generates all three ke

Re: [OE-core] [PATCH] findutils: split into packages

On 17/06/2024 13.43, Alexander Kanavin wrote: > This then needs to happen for all of the core system executables, No, that's not at all true, and does not follow logically. > not just these three ones you happen to be using. [I happen to need just one, that's the point.] > Packaging should > fo

Re: [OE-core] [PATCH] findutils: split into packages

On 17/06/2024 12.22, Ross Burton wrote: > On 17 Jun 2024, at 10:59, Rasmus Villemoes via lists.openembedded.org > wrote: >> >> From: Rasmus Villemoes >> >> It can be useful to have find and/or xargs by themselves without >> pulling in locate and its associa

Re: [OE-core] [PATCH] findutils: split into packages

On 17/06/2024 11.59, Rasmus Villemoes wrote: > > For backwards compatibility, make ${PN} pull in all the new packages. > [...] > > +RDEPENDS:${PN} += "${PN}-find ${PN}-xargs ${PN}-locate" Sorry about not testing properly before sending. For this to work this also needs ALLOW_EMPTY:${PN} = "1"

[OE-core] [PATCH] findutils: split into packages

From: Rasmus Villemoes It can be useful to have find and/or xargs by themselves without pulling in locate and its associated binaries updatedb and frcode. In my case, I just need xargs in an initramfs, which is a 42K binary; the other binaries add over 300K of dead weight. So split the recipe in

[OE-core] [scarthgap][PATCH] git: set --with-gitconfig=/etc/gitconfig for -native builds

From: Rasmus Villemoes Commit 6c2ae2346db0 (kern-tools: depend on git-replacement-native) broke our kernel builds. For saving space and time, we have a DL_DIR shared between multiple users/buildbots, not all of which run with the same uid (and with appropriate sticky bits set so that files downlo

Re: [OE-core] [PATCH] git: set --with-gitconfig=/etc/gitconfig for -native builds

Polite ping. On 23/04/2024 11.57, Rasmus Villemoes via lists.openembedded.org wrote: > From: Rasmus Villemoes > > Commit 6c2ae2346db0 (kern-tools: depend on git-replacement-native) > broke our kernel builds. For saving space and time, we have a DL_DIR > shared between multiple

Re: [OE-core] [PATCH] systemd: sed ROOT_HOME only if sysusers PACKAGECONFIG is set

On 24/04/2024 10.36, Alexander Kanavin via lists.openembedded.org wrote: > On Wed, 24 Apr 2024 at 10:19, Christian B. Sørensen via > lists.openembedded.org > wrote: > >> Any input on the patchset ? Would appreciate if it could be included in the >> scarthgap release. > > A little patience would

[OE-core] [PATCH] git: set --with-gitconfig=/etc/gitconfig for -native builds

From: Rasmus Villemoes Commit 6c2ae2346db0 (kern-tools: depend on git-replacement-native) broke our kernel builds. For saving space and time, we have a DL_DIR shared between multiple users/buildbots, not all of which run with the same uid (and with appropriate sticky bits set so that files downlo

Re: [OE-core] [PATCH] bmaptool: add PROVIDES bmap-tools for compatibility

On 19/04/2024 23.00, Alexander Kanavin wrote: > This was already proposed, and rejected. > https://lists.openembedded.org/g/openembedded-core/topic/104753355 > > You need to fix the metadata that refers to the old name. So, how can a layer then be compatible with both nanbield and scarthgap? Coul

[OE-core] [PATCH] bmaptool: add PROVIDES bmap-tools for compatibility

From: Rasmus Villemoes This is very often a build dependency, such as in my case using a class from meta-ptx, which fails with ERROR: Nothing PROVIDES 'bmap-tools-native'. Close matches: bmaptool-native bpftool-native mtools-native due to the renaming. Signed-off-by: Rasmus Villemoes --

[OE-core] [PATCH] openssh: add After dependencies on nss-user-lookup.target

From: Rasmus Villemoes Quoting 'man systemd.special': nss-user-lookup.target A target that should be used as synchronization point for all regular UNIX user/group name service lookups. [...] All services for which the availability of the full user/group database is essential s

[OE-core] [PATCH v2] perf: add jevents PACKAGECONFIG item

From: Rasmus Villemoes Building for an arm64 target, e.g. qemuarm64 or a raspberrypi3, without "python" in PACKAGECONFIG, results in | Makefile.config:892: *** ERROR: No python interpreter needed for jevents generation. Install python or build with NO_JEVENTS=1.. Stop. Signed-off-by: Rasmus V

Re: [OE-core] [PATCH] perf: add jevents PACKAGECONFIG item

On 06/11/2023 16.07, Richard Purdie wrote: > On Mon, 2023-11-06 at 16:00 +0100, Rasmus Villemoes wrote: >> >> When I set PACKAGECONFIG for perf in a perf.bbappend file, without >> python being in there, the build breaks: >> [...] >> This difference is, to put it mildly, quite confusing and surprisi

Re: [OE-core] [PATCH] perf: add jevents PACKAGECONFIG item

On 06/11/2023 15.49, Bruce Ashfield wrote: > On Mon, Nov 6, 2023 at 9:22 AM Rasmus Villemoes > wrote: >> >> From: Rasmus Villemoes >> >> Building for an arm64 target, e.g. qemuarm64 or a raspberrypi3, >> without "python" in PACKAGECONFIG, results in >> >> | Makefile.config:892: *** ERROR: No pyth

Re: [OE-core] [PATCH] perf: add jevents PACKAGECONFIG item

Somewhat related, but maybe not really: When I set PACKAGECONFIG for perf in a perf.bbappend file, without python being in there, the build breaks: | Makefile.config:277: *** .../tmp/work/qemuarm64-poky-linux/perf/1.0/recipe-sysroot-native/usr/bin/python3-native/python3-config not found. Stop. |

[OE-core] [PATCH] perf: add jevents PACKAGECONFIG item

From: Rasmus Villemoes Building for an arm64 target, e.g. qemuarm64 or a raspberrypi3, without "python" in PACKAGECONFIG, results in | Makefile.config:892: *** ERROR: No python interpreter needed for jevents generation. Install python or build with NO_JEVENTS=1.. Stop. Signed-off-by: Rasmus V

[OE-core] [PATCH] valgrind: split helper scripts to separate packages, update dependencies

From: Rasmus Villemoes The cachegrind scripts have been rewritten in python3, so the RDEPENDS on perl is no longer sufficient. This is unfortunately not caught by QA checks since the scripts use #! /usr/bin/env python3 as shebang line. Since the valgrind binary by itself can be quite useful

[OE-core] [PATCH v2] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

From: Rasmus Villemoes Building perf without security_flags.inc being included in one's distro results in the buildpaths warning WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in package perf contains reference to TMPDIR because the ${DEBUG_PREFIX_MAP} does not get used. Most

Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

On 20/10/2023 12.13, Richard Purdie wrote: > On Fri, 2023-10-20 at 12:03 +0200, Rasmus Villemoes wrote: >> On 20/10/2023 11.38, Richard Purdie wrote: >>> On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote: On 19/10/2023 14.48, Richard Purdie wrote: >> > The fact this works suggests

Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

On 20/10/2023 11.38, Richard Purdie wrote: > On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote: >> On 19/10/2023 14.48, Richard Purdie wrote: >>> The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there >>> anything in the perf build system where we should be passing in cflags

Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

On 19/10/2023 14.48, Richard Purdie wrote: > On Thu, 2023-10-19 at 14:32 +0200, Rasmus Villemoes via > lists.openembedded.org wrote: >> From: Rasmus Villemoes >> >> Building perf without security_flags.inc being included in one's >> distro results in the buildpa

[OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

From: Rasmus Villemoes Building perf without security_flags.inc being included in one's distro results in the buildpaths warning WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in package perf contains reference to TMPDIR because the ${DEBUG_PREFIX_MAP} does not get used. Most

Re: [OE-core] [PATCH 04/15] perf: fix buildpaths QA warning in 6.4+

On 10/10/2023 14.31, Bruce Ashfield wrote: > > > On Tue, Oct 10, 2023 at 7:44 AM Rasmus Villemoes > It seems we can fix it with > > $ git diff > diff --git a/meta/recipes-kernel/perf/perf.bb > b/meta/recipes-kernel/perf/perf.bb > index 420286

Re: [OE-core] [PATCH 04/15] perf: fix buildpaths QA warning in 6.4+

On 10/07/2023 05.20, Bruce Ashfield via lists.openembedded.org wrote: > From: Bruce Ashfield > > kernel version 6.4 introduces a new file that need to have > absolute paths removed, so we can avoid the buildpaths QA > warning and have relocatable packages. > > We add pmu-flex.h to the processing

[OE-core] [PATCH] openssh: update sshd_check_keys script to make use of 'sshd -G'

From: Rasmus Villemoes Parsing sshd's config file with 'sed' does not work in for example the case where somebody has made use of the new ability to add a config fragment in /etc/ssh/sshd_config.d/ with one or more HostKey stanzas. Also, sshd_config keywords are case-insensitive, but the current

Re: [OE-core] Dilemma on changes - merge or not to merge (e.g. 6.4)

On 15/08/2023 15.08, Paul Gortmaker via lists.openembedded.org wrote: > [Dilemma on changes - merge or not to merge (e.g. 6.4)] On 14/08/2023 (Mon > 10:54) Richard Purdie wrote: > >> Remaining are: >> * an error upon boot on preempt-rt on qemux86-64 >> (e.g. >> https://autobuilder.yoctopr

Re: [OE-core] [RFC] [PATCH] Allow fitimage + initramfs rebuild to be accelerated

On 10/11/2022 21.32, Paul Eggleton via lists.openembedded.org wrote: > Hi Richard > > On Thursday, 10 November 2022 11:14:24 NZDT Richard Purdie wrote: >> Adding in yet further if/else paths with magic variables to control >> them isn't filling me with confidence. > > I understand that. I was ho

[OE-core] [PATCH] bitbake.conf: set BB_DEFAULT_UMASK using ??=

Currently, there's no way for the user's site.conf, local.conf or similar to set BB_DEFAULT_UMASK, because those files are included by bitbake.conf prior to the unconditional assignment of BB_DEFAULT_UMASK. To make that possible, use a weak default assignment instead. This is also consistent with m

Re: [OE-core] Should BB_DEFAULT_UMASK be set with ?=

On 30/05/2022 11.19, Rasmus Villemoes via lists.openembedded.org wrote: > Hi, > > Suppose I want to define BB_DEFAULT_UMASK in site.conf or local.conf (I > do have a use case for setting it to 002). But bitbake.conf includes > those files before it then goes on to use an unconditi

Re: [OE-core] [PATCH] e2fsprogs: add alternatives handling of lsattr as well

On 09/06/2022 09.20, Luca Ceresoli wrote: > Hi Rasmus, > > On Wed, 8 Jun 2022 15:12:05 +0200 > "Rasmus Villemoes via lists.openembedded.org" > wrote: > ^^^ > > As you can see above, your sender address is getting mangled. This is >

[OE-core] [PATCH] e2fsprogs: add alternatives handling of lsattr as well

Building busybox with CONFIG_LSATTR=y and installing that in the same filesystem as e2fsprogs breaks: ERROR: ... do_rootfs: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot, then please place them into pkg_postinst_ontarget:${PN} (). Deferri

Re: [OE-core] [PATCH] vim: put xxd in its own package

On 08/06/2022 14.30, Paulo Neves wrote: > On 6/8/22 14:13, Rasmus Villemoes wrote: > >> On 08/06/2022 13.58, Paulo Neves via lists.openembedded.org wrote: > I mean that your patch allows for a new standalone package ${PN}-xxd. > Were somebody to use this package standalone, meaning without install

Re: [OE-core] [PATCH] vim: put xxd in its own package

On 08/06/2022 13.58, Paulo Neves via lists.openembedded.org wrote: > Forgive me if it is a stupid question, but does xxd not rdepend on > ncurses-terminfo-base as well? No, it does not, it's a trivial standalone utility whose only dynamic dependency is libc. > I ask because before your patch it c

[OE-core] [PATCH] vim: put xxd in its own package

The xxd tool can be quite handy by itself, and doesn't have anything to do with vim per se. Make it possible to include the rather tiny xxd in a rootfs without pulling in the several MB vim binary and associated data. For backwards compatibility, add an RDEPENDS from the main package to the new vi

[OE-core] Should BB_DEFAULT_UMASK be set with ?=

Hi, Suppose I want to define BB_DEFAULT_UMASK in site.conf or local.conf (I do have a use case for setting it to 002). But bitbake.conf includes those files before it then goes on to use an unconditional assignment BB_DEFAULT_UMASK = "022" So how/where is one supposed to be able to set BB_DEFAUL

[OE-core] [PATCH] git: make expat and curl into PACKAGECONFIG items

It can be useful to use git on target (e.g. with some wrapper like etckeeper for keeping track of changes to /etc), and for such cases, it is likely one has no need for pulling from/pushing to http[s] repositories. From the INSTALL file: - "libcurl" library ... If you do not use http:// or htt

Re: [OE-core] [PATCH] bitbake.conf: add BB_NUMBER_THREADS to BB_HASHEXCLUDE_COMMON

On 28/02/2022 14.41, Richard Purdie wrote: > On Mon, 2022-02-28 at 09:42 +0100, Rasmus Villemoes wrote: >> The imx-gpu-sdk recipe in the meta-imx layer references >> ${BB_NUMBER_THREADS} in its do_compile function. Changing >> BB_NUMBER_THREADS between bitbake invocations leads to the well-known >>

[OE-core] [PATCH] bitbake.conf: add BB_NUMBER_THREADS to BB_HASHEXCLUDE_COMMON

The imx-gpu-sdk recipe in the meta-imx layer references ${BB_NUMBER_THREADS} in its do_compile function. Changing BB_NUMBER_THREADS between bitbake invocations leads to the well-known When reparsing ...meta-imx/meta-sdk/recipes-graphics/imx-gpu-sdk/imx-gpu-sdk_5.8.0.bb:do_compile, the basehash

[OE-core] [PATCH] kernel.bbclass: remove unnecessary dead code

The grep pattern seems to have been wrong ever since we stopped adding the -ffile-prefix-map via a patch in commit 20aea61385e, because the actual upstream gcc produces -ffile-prefix-map== and not -ffile-prefix-map= Besides, these *-prefix-map options are already used when building the kern

Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL

On 06/07/2021 21.39, Alex Stewart wrote: > Hey Rasmus, > > Sorry for the delay; I was OOO for the holidays and I'm just now working > through my inbox. No need to apologize; as it happens I've just now returned from vacation. > On 6/28/21 4:17 AM, Rasmus Villemoes wrote: >> On 25/06/2021 18.13,

Re: [OE-core] [PATCH] recipes-kernel: vdsotest: new recipe

On 30/06/2021 23.19, Alexander Kanavin wrote: > Should this be in meta-oe rather than oe-core? Perhaps. Could you share some of your thought process that led you to ask that question? I honestly didn't think much about it, but it did seem to fit well with the other "userspace tools closely tied t

[OE-core] [PATCH] recipes-kernel: vdsotest: new recipe

vdsotest is a handy tool for testing and benchmarking the vDSO, e.g. to measure the overhead of clock_gettime() done via the vDSO compared to an actual system call. Signed-off-by: Rasmus Villemoes --- Resending because the list rejected the first attempt, sent from a wrong email address. Apologie

Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL

On 25/06/2021 18.13, Richard Purdie wrote: > On Fri, 2021-06-25 at 17:45 +0200, Rasmus Villemoes wrote: >> On 25/06/2021 14.16, Richard Purdie wrote: >>> On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via >>> lists.openembedded.org wrote: >>>> I noti

Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL

On 25/06/2021 14.16, Richard Purdie wrote: > On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via > lists.openembedded.org wrote: >> I noticed that if I have an image recipe that says >> >> IMAGE_INSTALL += "kernel-module-foo" >> >> it fails as e

[OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL

I noticed that if I have an image recipe that says IMAGE_INSTALL += "kernel-module-foo" it fails as expected when the kernel hasn't been built with CONFIG_FOO=m. However, if at the same time some other package which happens to get installed in the same image says RRECOMMENDS_${PN} += "kernel-mo