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
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
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
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/
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
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
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
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
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
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
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
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
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
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
&
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
> 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
-=-=-=-=-=-=-=-
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
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
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
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
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
>> ---
>
>
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
---
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
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
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
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
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
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”
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 - 100 of 177 matches
Mail list logo