Re: [OE-core] [PATCH v6] systemd: Build the systemctl executable

2025-02-25 Thread Ross Burton via lists.openembedded.org
On 20 Feb 2025, at 15:33, Vyacheslav Yurkov wrote: > Isn't is supposed to be created on first boot? Yes, ish, but our rootfs is read only at this point: [7.639766] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only. [7.641135] systemd[1]: Booting up i

[OE-core] [PATCH 3/4] apr-utils: remove obsolete patch

2025-02-25 Thread Ross Burton via lists.openembedded.org
This patch to change how autotools pulls in macros is no longer needed. Signed-off-by: Ross Burton --- .../apr/apr-util/configure_fixes.patch| 31 --- meta/recipes-support/apr/apr-util_1.6.3.bb| 1 - 2 files changed, 32 deletions(-) delete mode 100644 meta/recipes-s

[OE-core] [PATCH 2/4] recipes/*: remove obsolete use of acpaths

2025-02-25 Thread Ross Burton via lists.openembedded.org
The bulk of these recipes used acpaths to work around argument list limits as we passed the full path to every directory. As this behaviour no longer happens we can remove these workarounds. Signed-off-by: Ross Burton --- meta/recipes-connectivity/inetutils/inetutils_2.5.bb | 2 -- meta/recipe

[OE-core] [PATCH 4/4] freetype: pass missing include paths to autoreconf

2025-02-25 Thread Ross Burton via lists.openembedded.org
Now that autotools isn't searching for every m4 file the configure fails. This is because freetype only uses autoconf and has a manual autogen.sh script that passes -I. itself. As we don't call that script, pass -I . to autoreconf ourselves. Signed-off-by: Ross Burton --- meta/recipes-graphics/

[OE-core] [PATCH 1/4] autotools: don't try and find in-tree macros

2025-02-25 Thread Ross Burton via lists.openembedded.org
autotools has improved a lot since this class was written, and there's now no need to search the source tree for m4 files and add them to the include path. If packages have macros in subdirectories the idiom is to tell aclocal via an assignment in Makefile.am: ACLOCAL_AMFLAGS = -I gl/m4 -I m4

Re: [OE-core] [PATCH v3 2/2] mtd-utils: Upgrade to 2.3.0

2025-02-24 Thread Ross Burton via lists.openembedded.org
On 19 Feb 2025, at 18:51, Fabio Estevam via lists.openembedded.org wrote: > > +DEPENDS:append:libc-musl = " libexecinfo" > +LDFLAGS:append:libc-musl = " -lexecinfo” We already have a gcompat recipe in core which provides this: https://git.adelielinux.org/adelie/gcompat/-/blob/current/libgcompa

Re: [OE-core][PATCH v12.1 1/5] rpm-sequoia-crypto-policy: New recipe

2025-02-20 Thread Ross Burton via lists.openembedded.org
On 13 Feb 2025, at 15:21, Zoltan Boszormenyi via lists.openembedded.org wrote: > +DEPENDS = "coreutils-native openssl-native make-native" > + > +inherit allarch python3native These dependencies seem unexpected, and if they’re needed then they should be explained. We assume make on the host, so

Re: [OE-core] [PATCH v6] systemd: Build the systemctl executable

2025-02-20 Thread Ross Burton via lists.openembedded.org
On 20 Feb 2025, at 15:52, Vyacheslav Yurkov wrote: > > From meta/classes-recipe/rootfs-postcommands.bbclass: > > # 20:12 < mezcalero> koen: you have three options: a) run > systemd-machine-id-setup at install time, b) have / read-only and an empty > file there (for stateless) and c) boot w

[OE-core] [PATCH] documentation: remove AUTHOR[doc]

2025-02-20 Thread Ross Burton via lists.openembedded.org
The variable was mostly removed in oe-core 9d5edd12 but the documentation remained. [ YOCTO #15758 ] Signed-off-by: Ross Burton --- meta/conf/documentation.conf | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf index 2dcf85f7672..3dd7

Re: [OE-core] [PATCH] man-db: fix do_configure "Argument list too long" error

2025-02-20 Thread Ross Burton via lists.openembedded.org
On 20 Feb 2025, at 08:56, Changqing Li wrote: > For autotools.bbclass, how about don't pass -I $i to acpaths, suppose that > upstream configure.ac or Makefile.am have set the correct > AC_CONFIG_MACRO_DIRS, ACLOCAL_AUTOMAKE_DIR, or ACLOCAL_AMFLAGS. if the > recipe is not correctly set, the

Re: [OE-core] [PATCH v6] systemd: Build the systemctl executable

2025-02-20 Thread Ross Burton via lists.openembedded.org
On 19 Feb 2025, at 10:39, Vyacheslav Yurkov via lists.openembedded.org wrote: > > From: Vyacheslav Yurkov > > Instead of the python re-implementation build the actual systemctl from > the systemd source tree. The python script was used when systemd didn't > provide an option to build individua

Re: [OE-core] [PATCH 1/4] nfs-utils: clean up startup

2025-02-18 Thread Ross Burton via lists.openembedded.org
On 12 Feb 2025, at 19:12, Dan McGregor via lists.openembedded.org wrote: > > Change the sysvinit script to start at the S runlevel, this matches > Debian, and prevents systemd from generating a unit file for it. > Also have the nfsd systemd service request the nfsd kernel filesystem > mountpoint

Re: [OE-core] [scarthgap][PATCH v2 2/2] setuptools3-base.bbclass: override default subprocess timeout

2025-02-18 Thread Ross Burton via lists.openembedded.org
On 18 Feb 2025, at 13:37, hongxu via lists.openembedded.org wrote: > > The environment variable SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT allows to override > the subprocess timeout. The default is 40 seconds and should work for most > needs.[1] However, it was not enough while using git shallow tarball

Re: [OE-core] [PATCH 2/2] libadwaita: upgrade 1.6.2 -> 1.6.4

2025-02-18 Thread Ross Burton via lists.openembedded.org
On 18 Feb 2025, at 10:55, Ross Burton via lists.openembedded.org wrote: > > On 3 Feb 2025, at 23:25, Simone Weiß via lists.openembedded.org > wrote: >> >> From: Simone Weiß >> >> Add sassc-native as in libadwaita the handling wrt to pre build artifacts &

Re: [OE-core] [PATCH 2/2] libadwaita: upgrade 1.6.2 -> 1.6.4

2025-02-18 Thread Ross Burton via lists.openembedded.org
On 3 Feb 2025, at 23:25, Simone Weiß via lists.openembedded.org wrote: > > From: Simone Weiß > > Add sassc-native as in libadwaita the handling wrt to pre build artifacts > changed and sassc is now needed. This seemed odd to me, and I just successfully did a build of 1.6.4 without sassc pres

Re: [OE-core] [PATCH V3] setuptools3-base.bbclass: override default subprocess timeout

2025-02-17 Thread Ross Burton via lists.openembedded.org
On 17 Feb 2025, at 07:46, hongxu via lists.openembedded.org wrote: > > The environment variable SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT allows to override > the subprocess timeout. The default is 40 seconds and should work for most > needs.[1] However, it was not enough while using git shallow tarball

[OE-core] [PATCH 3/4] systemd-serialgetty: don't set a default SERIAL_CONSOLES

2025-02-13 Thread Ross Burton via lists.openembedded.org
bitbake.conf defines a default value, so there's no value in setting another default here that doesn't match the rest of the system. Signed-off-by: Ross Burton --- meta/recipes-core/systemd/systemd-serialgetty.bb | 2 -- 1 file changed, 2 deletions(-) diff --git a/meta/recipes-core/systemd/syst

[OE-core] [PATCH 1/4] systemd: if getty generator is disabled remove the generator, not the units

2025-02-13 Thread Ross Burton via lists.openembedded.org
If the getty generator is disabled then it's neater to remove just the generator tool instead of the unit files as the unit files are still useful. Signed-off-by: Ross Burton --- meta/recipes-core/systemd/systemd_257.1.bb | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git

[OE-core] [PATCH 4/4] sysvinit-inittab: exec getty from the wrapper

2025-02-13 Thread Ross Burton via lists.openembedded.org
Instead of forking, the start_getty wrapper can use exec to replace itself. This results in one less process in ps per getty. Signed-off-by: Ross Burton --- meta/recipes-core/sysvinit/sysvinit-inittab/start_getty | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-co

[OE-core] [PATCH 2/4] systemd-serialgetty: use existing unit files in systemd

2025-02-13 Thread Ross Burton via lists.openembedded.org
Now that systemd isn't deleting the serial-getty@.service unit template files, we can simply symlink to the files provided by systemd instead of shipping a copy of them in this recipe. Signed-off-by: Ross Burton --- .../systemd/systemd-serialgetty.bb| 12 + .../systemd-serialgett

Re: [OE-core] [PATCH] python3-license-expression: fix ptest installation

2025-02-13 Thread Ross Burton via lists.openembedded.org
On 12 Feb 2025, at 22:56, Khem Raj wrote: >> +ln -s ${PYTHON_SITEPACKAGES_DIR}/license_expression/ >> ${D}${PTEST_PATH}/src/ > > should this be ln -sf ? We’re working in a fresh directory so there is no destination file to forcible remove. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive a

Re: [OE-core] [PATCH] python3-license-expression: Make the ptest work as expected

2025-02-12 Thread Ross Burton via lists.openembedded.org
On 10 Feb 2025, at 09:36, Yu, Mingli via lists.openembedded.org wrote: > -do_install_ptest() { > +do_install_ptest:append() { > install -d ${D}${PTEST_PATH}/src > cp -rf ${S}/src/* ${D}${PTEST_PATH}/src/ > cp -rf ${S}/setup.cfg ${D}${PTEST_PATH}/ I didn’t like how this test was insta

[OE-core] [PATCH] python3-license-expression: fix ptest installation

2025-02-12 Thread Ross Burton via lists.openembedded.org
This recipe was overriding do_install_ptest which is provided by the ptest-python-pytest class, so there was no tests or run-ptest installed. Use an append override, and minimise the installed files: use a symlink so that scancode-licensedb-index.json is found and install setup.cfg. Signed-off-by

Re: [OE-core] [PATCH v3][OE-core 0/4] cve-check: allow feed selection

2025-02-10 Thread Ross Burton via lists.openembedded.org
On 5 Feb 2025, at 14:34, Marta Rybczynska via lists.openembedded.org wrote: > > This series is allowing choice of the NVD feed to use, you can > configure them using the NVD_DB_VERSION variable in local.conf > > Available feeds: > - NVD2 (default) - the current NVD API v2 feed > - NVD1 - the ol

Re: [OE-core] [PATCH] systemd: move systemctl utility to separate subpackage

2025-02-10 Thread Ross Burton via lists.openembedded.org
On 6 Feb 2025, at 14:49, Oleksiy Obitotskyy via lists.openembedded.org wrote: > Move systemctl into separate subpackage to minimize > dependencies from core systemd package. In what situation would you have systemd or systemctl without the other? Cheers, Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You

[OE-core] [PATCH] dbus: explictly set the path to systemctl

2025-02-07 Thread Ross Burton via lists.openembedded.org
The dbus.socket user unit file calls systemctl, and the meson.build uses find_program() to find the path, falling back to a hardcoded value if it cannot be found. On the initial build the sysroot doesn't contain systemctl (as it is not in the target systemd sysroot), however after the do_package_w

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

2025-02-07 Thread Ross Burton via lists.openembedded.org
On 7 Feb 2025, at 12:06, Rasmus Villemoes via lists.openembedded.org wrote: > > 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

[OE-core] [PATCH] openssl: fix register trampling on aarch64

2025-02-06 Thread Ross Burton via lists.openembedded.org
Backport a patch from upstream to fix register tramping on aarch64. Signed-off-by: Ross Burton --- .../openssl/openssl/aarch64-regs.patch| 52 +++ .../openssl/openssl_3.4.0.bb | 1 + 2 files changed, 53 insertions(+) create mode 100644 meta/recipes-conn

[OE-core] [PATCH 1/3] nfs-utils: remove python hashbang rewrites

2025-02-06 Thread Ross Burton via lists.openembedded.org
These were replaced with python3 in 2.5.2 (commit d1683f). Signed-off-by: Ross Burton --- meta/recipes-connectivity/nfs-utils/nfs-utils_2.8.2.bb | 3 --- 1 file changed, 3 deletions(-) diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.8.2.bb b/meta/recipes-connectivity/nfs-utils/nfs

[OE-core] [PATCH 3/3] nfs-utils: remove obsolete 'make clean' call

2025-02-06 Thread Ross Burton via lists.openembedded.org
The 1.2.8 release did indeed ship binary .o files, but recent releases do not. Signed-off-by: Ross Burton --- meta/recipes-connectivity/nfs-utils/nfs-utils_2.8.2.bb | 6 -- 1 file changed, 6 deletions(-) diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.8.2.bb b/meta/recipes-con

[OE-core] [PATCH 2/3] nfs-utils: clean up sbin installation

2025-02-06 Thread Ross Burton via lists.openembedded.org
There's no need to sed the Makefiles as there's an option to simply respect sbindir. Signed-off-by: Ross Burton --- meta/recipes-connectivity/nfs-utils/nfs-utils_2.8.2.bb | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.8.2.

[OE-core] [PATCH] libslirp: set the PV in the filename

2025-02-05 Thread Ross Burton via lists.openembedded.org
As this recipe builds the tagged releases we can put the PV in the filename. Signed-off-by: Ross Burton --- .../slirp/{libslirp_git.bb => libslirp_4.9.0.bb}| 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) rename meta/recipes-connectivity/slirp/{libslirp_git.bb => libslirp

Re: [OE-core] [PATCH v3 2/2] scripts: add b4-wrapper for poky

2025-02-05 Thread Ross Burton via lists.openembedded.org
> On 5 Feb 2025, at 15:05, Quentin Schulz via lists.openembedded.org > wrote: > +if subprocess.call(["which", "lsdiff"], stdout=subprocess.DEVNULL) != 0: “which” isn’t actually a standard tool, so I’d use shutil.which() instead: guaranteed to work and no need to spawn. Ross -=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] meson.bbclass: Specify a cross binary for cmake

2025-02-04 Thread Ross Burton via lists.openembedded.org
On 4 Feb 2025, at 16:45, Peter Kjellerstedt wrote: > Does not look like it. I guess it is the same as for, e.g., pkg-config, > which is on the next line in the meson.cross file. Just had it confirmed that in cross builds meson needs _every_ binary to be specified, so this patch is entirely corr

Re: [OE-core] [PATCH] meson.bbclass: Specify a cross binary for cmake

2025-02-04 Thread Ross Burton via lists.openembedded.org
On 4 Feb 2025, at 16:06, Peter Kjellerstedt via lists.openembedded.org wrote: > +cmake = ‘cmake' Is that not the default? Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#210812): https://lists.openembedded.org/g/openembedded-core/message/210

Re: [OE-core] [PATCH 3/3] systemd: Build the systemctl executable

2025-02-03 Thread Ross Burton via lists.openembedded.org
On 2 Feb 2025, at 21:03, Vyacheslav Yurkov via lists.openembedded.org wrote: > Instead of the python re-implementation build the actual systemctl from > the systemd source tree. Very glad to see this - I tried some time ago but the dependency tree at the time was quite invasive to remove so I g

Re: [OE-core] [PATCH 2/2] systemd: use getty generators by default

2025-01-31 Thread Ross Burton via lists.openembedded.org
On 31 Jan 2025, at 07:25, Mikko Rapeli wrote: > ACK, we have also found that systemd and udev handle serial consoles > correctly when supporting multiple devices like rockpi4b, synquacer, > AMD KV260, zcu102, AVA, qemu etc from a single build. The challenge is doing the same for sysvinit… Sharin

Re: [OE-core] [PATCH 1/2] systemd-serialgetty: add comments explaining use

2025-01-31 Thread Ross Burton via lists.openembedded.org
On 31 Jan 2025, at 14:16, Mathieu Dubois-Briand wrote: > > On Thu Jan 30, 2025 at 6:59 PM CET, Ross Burton via lists.openembedded.org > wrote: >> Add some comments to clarify exactly what this recipe is for. >> >> Signed-off-by: Ross Burton >> --- > >

[OE-core] [PATCH 1/2] systemd-serialgetty: add comments explaining use

2025-01-30 Thread Ross Burton via lists.openembedded.org
Add some comments to clarify exactly what this recipe is for. Signed-off-by: Ross Burton --- meta/recipes-core/systemd/systemd-serialgetty.bb | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/systemd/systemd-serialgetty.bb b/meta/recipes-core/systemd/sy

[OE-core] [PATCH 2/2] systemd: use getty generators by default

2025-01-30 Thread Ross Burton via lists.openembedded.org
systemd can automatically create getty service units at boot time by probing the hardware: if will check for a list of known hypervisor consoles and also spawn a getty on every active console. However in a historical attempt to change as little behaviour as possible, we disabled this and instead w

Re: [OE-core] [PATCH 2/9] multilib_header.bbclass: need multilib headers for nativesdk builds

2025-01-29 Thread Ross Burton via lists.openembedded.org
On 21 Jan 2025, at 08:55, hongxu via lists.openembedded.org wrote: > The nativesdk multilib support required it to fix multilib headers > conflict So the context here is that luajit apparently needs to be able to build native code with the same word size as the target. But this demonstrates ni

[OE-core] [PATCH] meson: upgrade to 1.7.0

2025-01-27 Thread Ross Burton via lists.openembedded.org
Summary of changes: - New custom dependency for atomic - --cap-lints allow used for Cargo subprojects - Cargo features are resolved globally - Meson can run "clippy" on Rust projects - Devenv support in external project module - Fixed sizeof and find_library methods for Fortran compilers - format c

[OE-core] [PATCH] man-db: fix broken requirement for flex

2025-01-22 Thread Ross Burton via lists.openembedded.org
Normally flex-native in the sysroot via the toolchain, but different toolchains may not depend on flex-native (eg, external-arm-toolchain). This results in a configure error: checking for flex... no configure: error: flex is required when building from revision control Now we're not building

Re: [OE-core] [PATCH] buildhistory.bbclass: restore BUILDHISTORY_PRESERVE files

2025-01-22 Thread Ross Burton via lists.openembedded.org
Hi Pedro, > On 15 Jan 2025, at 15:31, Pedro Ferreira via lists.openembedded.org > wrote: > > From: Pedro Ferreira > > On each build using sstate-cache, buildhistory will move > content to a temporary folder named `old`. > When buildhistory looks for the main dir, it wont find it > and ends up

Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

2025-01-22 Thread Ross Burton via lists.openembedded.org
Hi Sean, On 17 Jan 2025, at 13:08, Sean Nyekjaer via lists.openembedded.org wrote: > Some recipes(systemd) requires usrmerge. Create the required > symlinks for `/bin`, `/lib` and `/sbin`, when installing nativesdk > packages. > Enable the symlink creation by setting the `usrmerge` flag in > DIS

Re: [OE-core] [PATCH 1/2] rust: fix for rust multilib sdk configuration

2025-01-22 Thread Ross Burton via lists.openembedded.org
Hi Harish, On 16 Jan 2025, at 11:38, Sadineni, Harish via lists.openembedded.org wrote: > The change includes: > - Prepending '${RUST_TARGET_SYS}' to 'rust.sh' to differentiate between > target systems. > - Moving the non-target-specific environment variables to 'nativesdk-cargo' > and 'nativ

Re: [OE-core] [PATCH] rust-cross-canadian: set CC_ for nativesdk

2025-01-22 Thread Ross Burton via lists.openembedded.org
Hi Sean, > On 14 Jan 2025, at 08:21, Sean Nyekjaer via lists.openembedded.org > wrote: > > This fixes build errors when building rust bindings for C dependencies > for the sdk host. > This will allow us to build and run rust programs on the sdk host. Can you also add a test case to exercise th

Re: [OE-core] [PATCH 2/2] gcc: make include poisoning fatal again in gcc/g++

2025-01-22 Thread Ross Burton via lists.openembedded.org
On 22 Jan 2025, at 10:52, Richard Purdie wrote: > I think this needs to be: > > +#ifdef POISON_BY_DEFAULT > +#define POISON_IS_ERROR " -Werror=poison-system-directories" > +#else > +#define POISON_IS_ERROR > +#endif > > otherwwise POISON_IS_ERROR is undefined and leads to failures building > ta

[OE-core] [PATCH 2/2] gcc: make include poisoning fatal again in gcc/g++

2025-01-21 Thread Ross Burton via lists.openembedded.org
We have a patch to allow us to 'poison' system include directories, which are warnings by default but we make them fatal in cross builds. However, in the 13.1 upgrade[1] the patch to make the warnings fatal was dropped in the compiler invocation, so it only took effect for pure preprocessor calls.

[OE-core] [PATCH 1/2] oeqa/poisoning: fix gcc include poisoning test

2025-01-21 Thread Ross Burton via lists.openembedded.org
The test code in poison was flawed: as long as one CPP/CC/CXX has fatal poisoning enabled then the test passes. However, at the moment due to a bad rebase only CPP has fatal poisoning and CC/CXX do not. Rewrite the do_compile() task to more carefully check the output so the test harness itself ju

Re: [PATCH] [OE-core] [PATCH v3] ncurses: Fix install conflict when enable multilib.

2025-01-21 Thread Ross Burton via lists.openembedded.org
On 16 Jan 2025, at 00:19, wangmy via lists.openembedded.org wrote: > > From: Wang Mingyu > > The setting of want_xterm_kbs is as following: > case $host_os in > (*linux-gnu|*cygwin|*mingw32|*msys) >want_xterm_kbs=DEL >;; > (*) >want_xterm_kbs=BS >;; > esac > > The host_os when

Re: [OE-core] [PATCH V2 2/2] oeqa/sdk/context: fix for gtk3 test failure during do_testsdk

2025-01-21 Thread Ross Burton via lists.openembedded.org
On 16 Jan 2025, at 13:48, Sadineni, Harish via lists.openembedded.org wrote: > > From: Harish Sadineni > > The do_testsdk for lib32-core-image-sato aborts with below error: > configure: error: Package requirements (gtk+-3.0) were not met: > No package 'gtk+-3.0' found > Consider adjusting the

Re: [OE-core] [PATCH v4] sanity: test for c toolchain

2025-01-21 Thread Ross Burton via lists.openembedded.org
Hi, Some more comments: The shortlog says “C toolchain” but the test is for the C++ toolchain not C, correct? > +def check_c_toolchain(d): > +try: > +with NamedTemporaryFile(delete=False, suffix=".c") as c_file: Why delete=False and then manual cleanup later? You can move the com

Re: [OE-core] [master] [PATCH] strace: add vendor to CVE_PRODUCT to exclude false positives

2025-01-20 Thread Ross Burton via lists.openembedded.org
On 15 Jan 2025, at 15:29, Madhu Marri via lists.openembedded.org wrote: > > - To avoid false positives such as CVE-2000-0006, add the CVE_PRODUCT > value with the vendor. But CVE-2000-0006 is specific to this strace, not another strace. Quoting from the original reference (https://web.archive

[OE-core] [PATCH] fmt: fix build with GCC 9.4

2025-01-20 Thread Ross Burton via lists.openembedded.org
fmt-native is needed to build ccache-native, and the compile fails on hosts with GCC 9.4 (such as Ubuntu 20.04). Backport a patch to fix this issue. Signed-off-by: Ross Burton --- .../recipes-devtools/fmt/files/fix-gcc9.patch | 26 +++ meta/recipes-devtools/fmt/fmt_11.1.1.bb

Re: [OE-core] [PATCH] fmt: disable buiding the tests

2025-01-20 Thread Ross Burton via lists.openembedded.org
I retract this, the problem has now been fixed upstream and there is some value on building the tests even if we don’t run them. I shall backport the fix instead. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#210025): https://lists.openemb

Re: [OE-core] [PATCH 1/1] fmt: 11.0.2 -> 11.1.1

2025-01-17 Thread Ross Burton via lists.openembedded.org
On 9 Jan 2025, at 18:35, Khem Raj via lists.openembedded.org wrote: > > I know this patch is applied but I still want to bring it to attention > Many packages in other layers depend on fmt. fmt's APIs are not or > not used in a very backward compatible way > some packages provide an option to u

[OE-core] [PATCH] fmt: disable buiding the tests

2025-01-17 Thread Ross Burton via lists.openembedded.org
We don't run or install the tests so there's limited value in building them, and one of the tests is currently failing to build in fmt-native on ubuntu 20.04 systems, presumably due the g++ 9.4 being old. Filed upstream as https://github.com/fmtlib/fmt/issues/4313. Signed-off-by: Ross Burton ---

[OE-core] [PATCH] lttng-tools: disable patching our libtool.m4

2025-01-16 Thread Ross Burton via lists.openembedded.org
Twelve years ago, libtool on Debian had a patch that meant it failed to cross-compile lttng-tools correctly. The solution at the time was to sed libtool.m4 whilst configure was being ran[1], which (assuming it patches the correct file) results in a re-execution of configure during do_compile. This

[OE-core] [PATCH 3/3] autoconf: rename autotools_aclocals and only run in do_configure

2025-01-15 Thread Ross Burton via lists.openembedded.org
Despite the name, autotools_aclocals() doesn't actually do anything with aclocal. Instead it reads all of the available autoconf site default files[1] and sets CONFIG_SITE appropriately. Rename the function to autotools_sitefiles to make this clear. Also there's no need to do this before do_config

[OE-core] [PATCH 2/3] libtool: remove obsolete ACLOCALEXTRAPATH

2025-01-15 Thread Ross Burton via lists.openembedded.org
This variable no longer exists, and would have had the effect of not letting the target libtool see the contents of the native aclocal directory. I don't understand why this was needed but autotools has improved dramatically in the last eight years, so it's most likely obsolete now. Signed-off-by

[OE-core] [PATCH 1/3] autotools: clean up aclocal/ search path assignments

2025-01-15 Thread Ross Burton via lists.openembedded.org
We need aclocal to look in two different $datadir/aclocal/ directories: the native (eg, for pkg.m4 from pkgconfig) and the target (eg, for alsa.m4 from alsa-lib). aclocal doesn't directly support this pattern, currently we use --system-acdir to specify the target directory and then add the native

Re: [OE-core] [PATCH v2][OE-core 4/4] cve-check: allow feed choice

2025-01-15 Thread Ross Burton via lists.openembedded.org
14 Jan 2025, at 17:54, Ross Burton via lists.openembedded.org > wrote: > > On 24 Dec 2024, at 10:25, Marta Rybczynska via lists.openembedded.org > wrote: > > There’s an inconsistency: > >> Set the NVD_DB_VERSION variable to choose feed: >> NVD2 (default) - the

Re: [OE-core] [PATCH v2][OE-core 4/4] cve-check: allow feed choice

2025-01-14 Thread Ross Burton via lists.openembedded.org
On 24 Dec 2024, at 10:25, Marta Rybczynska via lists.openembedded.org wrote: There’s an inconsistency: > Set the NVD_DB_VERSION variable to choose feed: > NVD2 (default) - the NVD feed with API version 2 > NVD1 - the NVD JSON feed (deprecated) > FKIE - the FKIE-CAD feed reconstruction “NVD1”

Re: [OE-core] [PATCH] libxkbcommon: remove locale dependecy

2025-01-13 Thread Ross Burton via lists.openembedded.org
On 12 Dec 2024, at 21:34, Hiago De Franco via lists.openembedded.org wrote: > > From: Hiago De Franco > > The error described does not occur in all cases where libxkbcommon is > used. As example, a Qt application that depends on libxkbcommon might > not require any locales to be installed. Th

[OE-core] [PATCH v2 2/4] classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture

2025-01-10 Thread Ross Burton via lists.openembedded.org
Using the package architecture to select the right qemu options to pass to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are not typically any options set for the machine name. Solve this by using TUNE_PKGARCH

Re: [OE-core] [PATCH 1/3] classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture

2025-01-10 Thread Ross Burton via lists.openembedded.org
On 10 Jan 2025, at 17:52, Martin Jansa wrote: > > Too late to easily ignore as it seems already in master, e.g.: > https://git.openembedded.org/openembedded-core/commit/?id=5e14a1b26cc77b35c3e36869021afae9455bb1a8 > or do you mean some other changes? Eek. They’re not in poky/master so I wonder

[OE-core] [PATCH v2 3/4] classes/qemu: move QEMU_EXTRAOPTIONS for PPC to the relevant tunes

2025-01-10 Thread Ross Burton via lists.openembedded.org
Every other architecture has the QEMU_EXTRAOPTIONS assignments in the tune files, so move the PPC ones too. Signed-off-by: Ross Burton --- meta/classes-recipe/qemu.bbclass | 9 - meta/conf/machine/include/powerpc/arch-powerpc64.inc | 1 + meta/conf/machine/include/pow

[OE-core] [PATCH v2 1/4] classes/nativesdk: also override TUNE_PKGARCH

2025-01-10 Thread Ross Burton via lists.openembedded.org
The nativesdk class overrides PACKAGE_ARCH and unsets TUNE_FEATURES, but as recipes might want to look at TUNE_PKGARCH too (for example, when setting QEMU_EXTRAOPTIONS) we should also override that variable. Otherwise, a nativesdk recipe will have the TUNE_PKGARCH of the target, which leads to err

[OE-core] [PATCH v2 4/4] qemu/machine: rename QEMU_EXTRAOPTIONS for consistency

2025-01-10 Thread Ross Burton via lists.openembedded.org
The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH}, but this doesn't follow the pattern of all of the other tune-specific variables in the machine configuration which is VARIABLE:tune-[name]. Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} fo

Re: [OE-core] [PATCH 1/3] classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture

2025-01-10 Thread Ross Burton via lists.openembedded.org
This series breaks under nativesdk, please ignore for now. Ross > On 10 Jan 2025, at 13:01, Ross Burton via lists.openembedded.org > wrote: > > Using the package architecture to select the right qemu options to pass > to qemu-user is incorrect, and fails for recipes that set PA

[OE-core] [PATCH kirkstone] classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture

2025-01-10 Thread Ross Burton via lists.openembedded.org
Using the package architecture to select the right qemu options to pass to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are not typically any options set for the machine name. Solve this by using TUNE_PKGARCH

[OE-core] [PATCH styhead] classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture

2025-01-10 Thread Ross Burton via lists.openembedded.org
Using the package architecture to select the right qemu options to pass to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are not typically any options set for the machine name. Solve this by using TUNE_PKGARCH

[OE-core] [PATCH scarthgap] classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture

2025-01-10 Thread Ross Burton via lists.openembedded.org
Using the package architecture to select the right qemu options to pass to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are not typically any options set for the machine name. Solve this by using TUNE_PKGARCH

[OE-core] [PATCH 2/3] classes/qemu: move QEMU_EXTRAOPTIONS for PPC to the relevant tunes

2025-01-10 Thread Ross Burton via lists.openembedded.org
Every other architecture has the QEMU_EXTRAOPTIONS assignments in the tune files, so move the PPC ones too. Signed-off-by: Ross Burton --- meta/classes-recipe/qemu.bbclass | 9 - meta/conf/machine/include/powerpc/arch-powerpc64.inc | 1 + meta/conf/machine/include/pow

Re: [OE-core] [PATCH] classes/qemu: move QEMU_EXTRAOPTIONS for PPC to the relevant tunes

2025-01-10 Thread Ross Burton via lists.openembedded.org
Note this has been superseded by the series I just sent. Ross > On 9 Jan 2025, at 18:11, Ross Burton via lists.openembedded.org > wrote: > > Every other architecture has the QEMU_EXTRAOPTIONS assignments in the > tune files, so move the PPC ones too. > > Leave the MAC

[OE-core] [PATCH 1/3] classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architecture

2025-01-10 Thread Ross Burton via lists.openembedded.org
Using the package architecture to select the right qemu options to pass to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are not typically any options set for the machine name. Solve this by using TUNE_PKGARCH

[OE-core] [PATCH 3/3] qemu/machine: rename QEMU_EXTRAOPTIONS for consistency

2025-01-10 Thread Ross Burton via lists.openembedded.org
The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH}, but this doesn't follow the pattern of all of the other tune-specific variables in the machine configuration which is VARIABLE:tune-[name]. Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} fo

Re: [OE-core] [PATCH 1/4] rsync: clean up configure/configure.sh fiddling

2025-01-10 Thread Ross Burton via lists.openembedded.org
On 10 Jan 2025, at 10:30, Richard Purdie wrote: > > On Wed, 2025-01-08 at 15:46 +, Ross Burton via lists.openembedded.org > wrote: >> The upstream Makefiles tell autoconf to write the generated script to >> configure.sh instead of the idiomatic configure. We now

[OE-core] [PATCH] classes/qemu: move QEMU_EXTRAOPTIONS for PPC to the relevant tunes

2025-01-09 Thread Ross Burton via lists.openembedded.org
Every other architecture has the QEMU_EXTRAOPTIONS assignments in the tune files, so move the PPC ones too. Leave the MACHINE_ARCH workarounds present for now as these are masking a genuine bug (#15647) that needs to be resolved properly. Signed-off-by: Ross Burton --- meta/classes-recipe/qemu.

Re: [OE-core] [PATCH 12/20] libgit2: update 1.8.4 -> 1.9.0

2025-01-09 Thread Ross Burton via lists.openembedded.org
On 8 Jan 2025, at 08:42, Alexander Kanavin via lists.openembedded.org wrote: Your commit message says: > Do not install cmake files; if someone wants them, please make > them reproducible and not hardcode-installed into /usr/lib. But then: > +Subject: [PATCH] src/libgit2/CMakeLists.txt: insta

Re: [OE-core] [PATCH 08/20] procps: update 4.0.4 -> 4.0.5

2025-01-09 Thread Ross Burton via lists.openembedded.org
On 8 Jan 2025, at 08:42, Alexander Kanavin via lists.openembedded.org wrote: > > Drop pidfd.patch (upstream significantly refactored the code; the patch can > be tested > only with very old kernels; upstream submission has not been followed up > since initial > MR creation). Not quite: the re

Re: [OE-core][PATCH V2] lib32-64k-pagesize.inc: add conf for building 32bit binary with 64K alignment

2025-01-08 Thread Ross Burton via lists.openembedded.org
> On 8 Jan 2025, at 17:02, Ross Burton via lists.openembedded.org > wrote: > First, I should point out that changing the page size is an ABI break, and > the 32-bit ABI was formalised long before 64kb pages were a thing, so things > _will_ break. That said the loader sh

Re: [OE-core][PATCH V2] lib32-64k-pagesize.inc: add conf for building 32bit binary with 64K alignment

2025-01-08 Thread Ross Burton via lists.openembedded.org
On 25 Dec 2024, at 03:04, Chen Qi via lists.openembedded.org wrote: > When 64K page size is enabled, for 32bit multilib, we'll need to build > applications with 64K alignment, otherwise, we'll see errors like below at > runtime: > > root@marvell-cn10xxx:~# /lib/ld-linux-armhf.so.3 >Segment

[OE-core] [PATCH 3/4] autotools: log when we're removing aclocal.m4

2025-01-08 Thread Ross Burton via lists.openembedded.org
Some mysterious autotools errors are because upstream has a custom aclocal.m4 that we're deleting it unless we know we're not even running aclocal. There's a case to be made for removing this deletion logic on the grounds that aclocal should know what it is doing, but for now make it clear that we

[OE-core] [PATCH 2/4] libtheora: backport a patch to fix autoreconf

2025-01-08 Thread Ross Burton via lists.openembedded.org
This is needed so that autoreconf works without any macro path fiddling, which autotools may no longer be doing implicitly. Signed-off-by: Ross Burton --- .../libtheora-1.1.1/autoreconf.patch | 42 +++ .../libtheora/libtheora_1.1.1.bb | 1 + 2 files changed

[OE-core] [PATCH 1/4] rsync: clean up configure/configure.sh fiddling

2025-01-08 Thread Ross Burton via lists.openembedded.org
The upstream Makefiles tell autoconf to write the generated script to configure.sh instead of the idiomatic configure. We now remove all of the Makefile rules that refer to configure.sh (makefile-no-rebuild.patch) but some pieces remained, so remove them too and delete the existing configure.sh to

[OE-core] [PATCH 4/4] autotools: remove aclocal --automake-acdir, relocated so knows the right path

2025-01-08 Thread Ross Burton via lists.openembedded.org
A relocated aclocal in the native sysroot has the right paths already: $ cat /work/ross/build/tmp/work/cortexa57-poky-linux/expect/5.45.4/recipe-sysroot-native/usr/bin/aclocal my @automake_includes = ('/work/ross/build/tmp/work/cortexa57-poky-linux/expect/5.45.4/recipe-sysroot-native/usr/share/a

Re: [OE-core] [PATCH] man-db: fix do_configure "Argument list too long" error

2025-01-08 Thread Ross Burton via lists.openembedded.org
I have a series in testing that removes acpaths entirely which solves this problem at the source instead of having to be worked around in every recipe. Ross > On 8 Jan 2025, at 08:40, Changqing Li via lists.openembedded.org > wrote: > > ping > On 12/17/24 17:09, Changqing Li via lists.openemb

Re: [OE-core] [PATCH] systemd: Add WATCHDOG_RUNTIME_SEC optional variable

2025-01-08 Thread Ross Burton via lists.openembedded.org
On 19 Dec 2024, at 11:16, Livius via lists.openembedded.org wrote: > +# To make use of the hardware watchdog it is sufficient to set > WATCHDOG_RUNTIME_SEC > +# (RuntimeWatchdogSec= option in /etc/systemd/system.conf) to a value like > 20s > +# and the watchdog is enabled. (defaults is no hardw

Re: [OE-core] [PATCH] icu: fix buildpaths QA error occasionally

2025-01-08 Thread Ross Burton via lists.openembedded.org
On 30 Dec 2024, at 12:23, hongxu via lists.openembedded.org wrote: > > $ bitbake icu > ... > ERROR: QA Issue: File /usr/lib64/icu/76.1/pkgdata.inc in package icu-dev > contains reference to TMPDIR [buildpaths] The autobuilder (or anyone else that I’m aware of) never seen this, so what is the

Re: [OE-core][PATCH] oe-pkgdata-util: avoid glibc-locale being mapped out by glibc packages

2025-01-08 Thread Ross Burton via lists.openembedded.org
On 19 Dec 2024, at 09:23, Chen Qi via lists.openembedded.org wrote: > > From: Chen Qi > > oe-pkgdata-util's glob command will output different results depending > on whether glibc-locale is built or not. This in turn results in do_rootfs > error when multilib is enabled. The glob command is g

[OE-core] [PATCH 2/7] subversion: add explicit DEPENDS on expat

2024-12-19 Thread Ross Burton via lists.openembedded.org
The configure script looks explicitly for expat, so add it to DEPENDS. Signed-off-by: Ross Burton --- meta/recipes-devtools/subversion/subversion_1.14.5.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/subversion/subversion_1.14.5.bb b/meta/recipes-de

[OE-core] [PATCH 1/7] bash: remove aclocal workarounds

2024-12-19 Thread Ross Burton via lists.openembedded.org
Instead of patching configure.ac to not load m4 directly and working around what aclocal and the autotools class do, just exclude the running of aclocal entirely. This stops the class removing the existing aclocal.m4 and autoreconf running aclocal. Signed-off-by: Ross Burton --- meta/recipes-ex

[OE-core] [PATCH 6/7] expect: don't run aclocal in do_configure

2024-12-19 Thread Ross Burton via lists.openembedded.org
expect has a hand-maintained aclocal.m4 so don't run aclocal, which has the side effect of not deleting the aclocal.m4 file which pulls in macros. The build works without this change more through luck and a combination of behaviours than design. Signed-off-by: Ross Burton --- meta/recipes-devto

[OE-core] [PATCH 7/7] expect: cleanup do_install

2024-12-19 Thread Ross Burton via lists.openembedded.org
Clean up the do_install append, and remove a long-standing unused variable that appears to be intending to not install the scripts but would have never actually done that as the relevant override since 2008 has been task-install. As we've been installing the scripts, keep instaling them. Signed-o

[OE-core] [PATCH 5/7] tcl8: don't run aclocal in do_configure

2024-12-19 Thread Ross Burton via lists.openembedded.org
tcl has a hand-maintained aclocal.m4 so don't run aclocal, which has the side effect of not deleting the aclocal.m4 file which pulls in macros. The build works without this change more through luck and a combination of behaviours than design. Signed-off-by: Ross Burton --- meta/recipes-devtools

[OE-core] [PATCH 4/7] tcl: don't run aclocal in do_configure

2024-12-19 Thread Ross Burton via lists.openembedded.org
tcl has a hand-maintained aclocal.m4 so don't run aclocal, which has the side effect of not deleting the aclocal.m4 file which pulls in macros. The build works without this change more through luck and a combination of behaviours than design. Signed-off-by: Ross Burton --- meta/recipes-devtools

[OE-core] [PATCH 3/7] subversion: refactor do_configure

2024-12-19 Thread Ross Burton via lists.openembedded.org
Upstream has an autogen.sh which constructs a hand-written aclocal.m4 and manually copies libtool into place. Instead of working around the bad interaction between these expectations and our autotools class we can just disable the execution of aclocal in autoreconf and copy files as autogen.sh does

[OE-core] [PATCH] ofono: fix the build when toolchain has old linux headers

2024-12-19 Thread Ross Burton via lists.openembedded.org
Whilst our default toolchain has modern kernel headers (6.12, at time of writing), some external toolchains may use old kernel headers. As ofono's rmnet module uses kernel defines which were added in 5.14, add some compatibility defines in case they are not set. Signed-off-by: Ross Burton --- .

  1   2   >