Re: [OE-core] [AUH] xz: upgrading to 5.6.2 SUCCEEDED

These are the release notes: https://github.com/tukaani-project/xz/releases/ There are also backdoor notes: https://tukaani.org/xz-backdoor/ "I plan to write an article how the backdoor got into the releases and what can be learned from this." - that'd be most welcome, as it would be first hand in

Re: [OE-core] xcb-util-errors

I think it belongs in core, as otherwise it would require a cross-layer include, which is technically possible, but is a maintenance issue. New xcb releases are very rare. Alex On Sun, 2 Jun 2024 at 14:39, Markus Volk via lists.openembedded.org wrote: > > xcb-util-errors is an optional dependenc

Re: [OE-core] [RFC PATCH 0/3] Implement RECIPE_UPDATE_EXTRA_TASKS

Thanks, I like the idea. There are a number of other recipes that for various reasons need 'special handling' in version updates that devtool doesn't know how to perform, and this could be used to define that handling where it belongs, which is in the recipe itself. E.g. updating cmake could also

Re: [OE-core] Set the CMake BUILD_TESTING option to OFF as the default setting

On Mon, 3 Jun 2024 at 11:40, Fabio Berton via lists.openembedded.org wrote: > Based on this, I would say that we don't want to build tests unless ptests > are enabled (so the argument that building tests also tests the code is > moot). In turn, it may be sensible to use the default CMake option

Re: [OE-core] Set the CMake BUILD_TESTING option to OFF as the default setting

On Mon, 3 Jun 2024 at 11:40, Fabio Berton via lists.openembedded.org wrote: > Based on this, I would say that we don't want to build tests unless ptests > are enabled (so the argument that building tests also tests the code is > moot). In turn, it may be sensible to use the default CMake option

Re: [OE-core] [PATCH] oeqa/runtime: fix regression in minidebuginfo test

It's not typically expected for contributors to know the ins and outs of the AB test matrix; just send the needed patches, and any fails will be reported back to you. Alex On Mon, 3 Jun 2024 at 13:35, Etienne Cordonnier via lists.openembedded.org wrote: > > Hi Richard, > thanks for merging the v

Re: [OE-core] [PATCH 02/19] package_rpm: remove support for DIRFILES

I think it's better to drop DIRFILES from the meta-mono recipes instead. Feature removal isn't eligible for LTS backport (even if the feature isn't working). Alex On Mon, 3 Jun 2024 at 14:11, Livius via lists.openembedded.org wrote: > > As i see it is merged only for master branch of poky repo.

Re: [OE-core] [PATCH] rust: rustdoc reproducibility - disable PGO

Wait, did you test this patch locally? What was the outcome? Alex On Mon, 3 Jun 2024 at 16:46, Sundeep KOKKONDA via lists.openembedded.org wrote: > > From: Sundeep KOKKONDA > > The rustdoc binaries are differed on their .llvm. suffixes between the > builds. > This is a test patch to verify the

Re: [OE-core] [PATCH] python3-rpds-py: Create a symlink for cython module on musl

I agree with RP, please get to the source of the mismatch. It’s a really unpleasant workaround. Alex On Mon 3. Jun 2024 at 20.49, Khem Raj via lists.openembedded.org wrote: > On Mon, Jun 3, 2024 at 9:35 AM Richard Purdie > wrote: > > > > On Mon, 2024-06-03 at 09:25 -0700, Khem Raj via lists.op

Re: [OE-core] mesa: build failure in CI, dependency not found

I don't think you need the full log. The key part is: Run-time dependency libclc found: NO (tried pkgconfig) > | > | ../mesa-24.1.0/meson.build:852:12: ERROR: Dependency "libclc" not > found, tried pkgconfig > | So you could find meson.build in ${S}, find line 852 in it, and see why that line is

Re: [OE-core] [PATCH] python3-rpds-py: Create a symlink for cython module on musl

Thanks for getting to the root of the issue. Alex On Wed 5. Jun 2024 at 9.47, Khem Raj via lists.openembedded.org wrote: > On Mon, Jun 3, 2024 at 9:56 PM Khem Raj wrote: > > > > On Mon, Jun 3, 2024 at 10:49 AM Khem Raj wrote: > > > > > > On Mon, Jun 3, 2024 at 9:35 AM Richard Purdie > > > w

Re: [OE-core] mesa: build failure in CI, dependency not found

I think we could ask Markus to look at this update to 24.1, as he's done work with libclc dependency previously (and authored the patch for it, which should preferably be dropped). Alex On Tue, 4 Jun 2024 at 12:13, Alexander Kanavin via lists.openembedded.org wrote: > > I don'

Re: [OE-core] mesa: build failure in CI, dependency not found

On Wed, 5 Jun 2024 at 14:25, Quentin Schulz wrote: > Additionally, Intel Vulkan driver forces libclc dependency if intel-clc > option is not "system" (so either "enabled" or "disabled" or "auto"), > since commit b52e25d3a8eee702ff5d21e4cdb9a4dc0736282a. > > Moreover, Intel Iris Gallium driver for

Re: [oe-core][PATCH] gstreamer1.0-plugins-bad: drop PACKAGECONFIG for sctp and srtp

I don't think this is correct. What if someone wants to enable these features but not enable webrtc? Before this change it would be possible, and now it isn't. If someone wants webrtc, they should add these two to their packageconfig as well; perhaps there could be a comment in the recipe. Alex

Re: [OE-core] [PATCH] bitbake-config-build: add a plugin for config fragments

On Mon, 10 Jun 2024 at 12:08, Richard Purdie wrote: > b) The code adding/removing require lines from local.conf seems a > little fragile. I did wonder if we wanted a higher level bitbake API to > this, for example a BB_CONF_FRAGMENTS variable which basically tagges a > set of config files onto th

Re: [OE-core] [PATCH] bitbake-config-build: add a plugin for config fragments

On Mon, 10 Jun 2024 at 16:51, Richard Purdie wrote: > > I don't quite follow. If BB_CONF_FRAGMENTS value is a space separated > > list of fragments, then how would the tooling > > > > - add to it? > > - remove from it? > > bb.utils.edit_metadata()/bb.utils.edit_metadata_file() ? Right, I had no i

Re: [OE-core] [PATCH] bitbake-config-build: add a plugin for config fragments

On Tue, 11 Jun 2024 at 12:56, Richard Purdie wrote: > oe-arch is the right place to discuss with the OE TSC being the > ultimate decision maker if needed. I've written a summary reply to oe-arch so that we can continue there. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to

[OE-core] [PATCH 2/3] sstatesig/dump_sigs: allow setting output directory explicitly from command line option

From: Alexander Kanavin The default (current directory) is unfortunately non-deterministic, as the operation is performed from bitbake-server and not from bitbake process directly. If the server was started in a different directory it will write the files there, and not where bitbake command

[OE-core] [PATCH 3/3] scripts/oe-replicate-build: add a script that packages and replicates a yocto build elsewhere

From: Alexander Kanavin This scripts takes an existing, active yocto build, and puts pieces of it into a bundle directory, which is then placed in a tarball, and that goes into a self-extracting shell archive. This allows moving the bundle to another machine, or placing it on a network server

[OE-core] [PATCH 1/3] bblayers/setupwriters/oe-local-copy: add a 'local copy' plugin for bitbake-layers create-layer-setup

From: Alexander Kanavin This plugin copies all currently configured layer respositories into a dedicated location on local disk. This is useful for entirely offline layer replication, when the layers are packed and then unpacked from an archive, rather than fetched from git (there can be

Re: [OE-core] [PATCH 3/3] rust: reproducibility issue fix with v1.76

Is the issue reported upstream? This should be done, and the link included into the inappropriate patch. Alex On Fri, 14 Jun 2024 at 07:51, Yash Shinde via lists.openembedded.org wrote: > > From: Yash Shinde > > A few crates are using the updated version of the 'cc' crate and > this is causing

Re: [OE-core] [PATCH 2/3] rust: Upgrade 1.75.0->1.76.0

On Fri, 14 Jun 2024 at 07:50, Yash Shinde via lists.openembedded.org wrote: > --- a/meta/recipes-devtools/rust/rust-source.inc > +++ b/meta/recipes-devtools/rust/rust-source.inc > @@ -4,17 +4,14 @@ SRC_URI += > "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n > f

Re: [OE-core][PATCH 2/2] findutils: upgrade from 4.9.0 to 4.10.0

Note that reporting this does not mean Chen has to reproduce or fix it. And you Khem should make it clear in your report. Ptests are expected to pass only in the standard glibc/gcc configuration that the autobuilder tests. Alex On Sat 15. Jun 2024 at 5.45, Khem Raj via lists.openembedded.org w

Re: [OE-core] [PATCH v2 3/3] rust: reproducibility issue fix with v1.76

This does not address my previous comment. This needs a link to upstream report or patch submission. Alex On Sat, 15 Jun 2024 at 18:05, wrote: > > From: Yash Shinde > > A few crates are using the updated version of the 'cc' crate and > this is causing the generated object file names containing

Re: [OE-core] QemuPPC64 machine status

No. It's not tested on the autobuilder. Alex On Mon, 17 Jun 2024 at 11:51, Dmitry Baryshkov via lists.openembedded.org wrote: > > Hello, > > Is qemuppc64 considered to be supported? We have been running CI over > a set of machines, it seems that PPC64 kernel build is broken for > quite some time

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

This then needs to happen for all of the core system executables, and not just these three ones you happen to be using. Packaging should follow a policy and not be an inconsistent mishmash. But having a policy that splits every executable into its own package would be a maintenance nightmare. I’d

Re: [OE-core] QemuPPC64 machine status

RESOLVED WONTFIX I’m afraid. The set of tested targets is defined by YP members. If other targets regress, it’s on those who need them to provide fixes. Alex On Mon 17. Jun 2024 at 13.47, Dmitry Baryshkov wrote: > On Mon, 17 Jun 2024 at 12:53, Alexander Kanavin > wrote: > > >

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

On Mon, 17 Jun 2024 at 14:29, Rasmus Villemoes wrote: > I really don't see how this is any different from any of the dozens of > the existing recipes that show up if you do "git grep 'FILES.*bindir'". > iproute2, e2fsprogs, psmisc, openssh, mtd-utils and lots of others > package binaries in distin

Re: [OE-core] [scarthgap][master][PATCH 2/2] apt: runtime error: filename too long (tmpdir length)

On Tue, 18 Jun 2024 at 05:30, Changqing Li via lists.openembedded.org wrote: > > From: Changqing Li > > when the tmpdir dir is longer than 220, there is no files saved in > tmp/sysroots/x86_64-linux/var/lib/apt/lists/ after run apt-get update, > this is because apt-get uses the path as the file n

Re: [OE-core] [kirkstone][PATCH] dpkg: upgrade 1.21.4 -> 1.21.22

erdir/supposed-dir/supposed-file", 'something'); > -+ > -+# Generate overlay tar. > -+system($Dpkg::PROGTAR, '-cf', "$overdir.tar", '-C', $overdir, qw( > -+subdir-a subdir-b > -+symlink-escape/escaped-file symlink-

Re: [OE-core] Yocto Project Status 18 June 2024 (WW25)

On Tue, 18 Jun 2024 at 17:01, Stephen Jolley via lists.openembedded.org wrote: > Patches in the Pending State: 205 (19%) [last week 205 (19%)] > > https://autobuilder.yocto.io/pub/non-release/patchmetrics/ I've been (gently) triaging Pending patches, collecting the fixes here: https://git.yoctopr

[OE-core] [PATCH 04/15] glib-networking: submit eagain.patch upstream

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-core/glib-networking/glib-networking/eagain.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/glib-networking/glib-networking/eagain.patch b/meta/recipes-core/glib-networking

[OE-core] [PATCH 05/15] psmisc: merge .inc into .bb

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-extended/psmisc/psmisc.inc | 59 meta/recipes-extended/psmisc/psmisc_23.7.bb | 60 - 2 files changed, 59 insertions(+), 60 deletions(-) delete mode 100644 meta/recipes

[OE-core] [PATCH 07/15] psmisc: remove 0001-Use-UINTPTR_MAX-instead-of-__WORDSIZE.patch

From: Alexander Kanavin Somewhere on the way it ceased to be needed (checked on musl). Signed-off-by: Alexander Kanavin --- ...se-UINTPTR_MAX-instead-of-__WORDSIZE.patch | 47 --- meta/recipes-extended/psmisc/psmisc_23.7.bb | 1 - 2 files changed, 48 deletions(-) delete

[OE-core] [PATCH 06/15] psmisc: drop duplicate entries

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-extended/psmisc/psmisc_23.7.bb | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/meta/recipes-extended/psmisc/psmisc_23.7.bb b/meta/recipes-extended/psmisc/psmisc_23.7.bb index

[OE-core] [PATCH 08/15] openssh: drop add-test-support-for-busybox.patch

From: Alexander Kanavin The ptest package is nowadays depending on coreutils so busybox tweaks are both incomplete and unneeded. Signed-off-by: Alexander Kanavin --- .../add-test-support-for-busybox.patch| 47 --- .../openssh/openssh_9.7p1.bb | 1 - 2

[OE-core] [PATCH 01/15] perf: drop newt from tui build requirements

From: Alexander Kanavin As the comment says this was used by very old kernels (pre 3.10), and slang has been the only option for a long time. Also, correct the option to disable slang TUI. Signed-off-by: Alexander Kanavin --- meta/recipes-kernel/perf/perf.bb | 5 + 1 file changed, 1

[OE-core] [PATCH 10/15] glslang: mark 0001-generate-glslang-pkg-config.patch as Inappropriate

From: Alexander Kanavin Issue is already being independently fixed upstream. Signed-off-by: Alexander Kanavin --- .../glslang/glslang/0001-generate-glslang-pkg-config.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/glslang/glslang/0001

[OE-core] [PATCH 09/15] libfm-extra: drop unneeded 0001-nls.m4-Take-it-from-gettext-0.15.patch

From: Alexander Kanavin nls.m4 is always provided with gettext or gettext-minimal if gettext class is inherited (and it is). Signed-off-by: Alexander Kanavin --- ...001-nls.m4-Take-it-from-gettext-0.15.patch | 54 --- .../libfm/libfm-extra_1.3.2.bb| 1 - 2

[OE-core] [PATCH 03/15] python3: submit deterministic_imports.patch upstream as a ticket

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- .../recipes-devtools/python/python3/deterministic_imports.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/python/python3/deterministic_imports.patch b/meta/recipes-devtools/python

[OE-core] [PATCH 02/15] libnewt: move to meta-oe

From: Alexander Kanavin There are no consumers in oe-core (after obsolete perf dependency was dropped), and so no reason to keep it there. Signed-off-by: Alexander Kanavin --- meta/conf/distro/include/distro_alias.inc | 2 - meta/conf/distro/include/maintainers.inc | 1 - .../0001

[OE-core] [PATCH 11/15] tcp-wrappers: mark all patches as inactive-upstream

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- .../tcp-wrappers-7.6/0001-Fix-build-with-clang.patch| 2 +- .../0001-Fix-implicit-function-declaration-warnings.patch | 2 +- .../tcp-wrappers-7.6/0001-Remove-fgets-extern-declaration.patch | 2 +- .../tcp-wrappers

[OE-core] [PATCH 13/15] settings-daemon: submit addsoundkeys.patch upstream and update to a revision that has it

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- .../settings-daemon/files/addsoundkeys.patch | 49 --- .../settings-daemon/settings-daemon_0.0.2.bb | 8 +-- 2 files changed, 4 insertions(+), 53 deletions(-) delete mode 100644 meta/recipes-sato/settings-daemon

[OE-core] [PATCH 12/15] automake: mark new_rt_path_for_test-driver.patch as Inappropriate

From: Alexander Kanavin The patch is specific to how oe-core runs autotools-generated tests: by cherry-picking needed bits from builddir and srcdir, then hacking Makefile with sed until it runs. As GNU is not interested in installable tests, they wouldn't be interested in this patch either

[OE-core] [PATCH 15/15] libacpi: mark patches as inactive-upstream

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- .../files/0001-libacpi-Fix-build-witth-fno-commom.patch| 2 +- meta/recipes-bsp/libacpi/files/ldflags.patch | 3 +-- meta/recipes-bsp/libacpi/files/libacpi_fix_for_x32.patch | 2 +- meta/recipes-bsp

[OE-core] [PATCH 14/15] dpkg: mark patches adding custom non-debian architectures as inappropriate for upstream

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- .../dpkg/dpkg/0001-Add-support-for-riscv32-CPU.patch| 2 +- .../dpkg/dpkg/0001-dpkg-Support-muslx32-build.patch | 2 +- .../dpkg/dpkg/0006-add-musleabi-to-known-target-tripets.patch | 2 +- meta/recipes

Re: [OE-core] [PATCH 10/15] glslang: mark 0001-generate-glslang-pkg-config.patch as Inappropriate

On Wed, 19 Jun 2024 at 11:34, Jose Quaresma wrote: >> -Upstream-Status: Pending >> +Upstream-Status: Inappropriate [independently developed patch submitted at >> https://github.com/KhronosGroup/glslang/pull/3371] > > > Maybe we can switch to the upstream submission. It is mostly the same with >

Re: [OE-core] [PATCH 10/15] glslang: mark 0001-generate-glslang-pkg-config.patch as Inappropriate

On Wed, 19 Jun 2024 at 17:35, Ross Burton wrote: > >>> +Upstream-Status: Inappropriate [independently developed patch submitted > >>> at https://github.com/KhronosGroup/glslang/pull/3371] > >> > >> > >> Maybe we can switch to the upstream submission. It is mostly the same with > >> the exception

Re: [OE-core] [PATCH 10/15] glslang: mark 0001-generate-glslang-pkg-config.patch as Inappropriate

On Wed, 19 Jun 2024 at 18:35, Ross Burton wrote: > > It's right at the bottom. Visible here as well: > > https://github.com/KhronosGroup/glslang/pull/3371/files > > Did you press Start a Review? You need to submit the review (this is so you > can incrementally review a PR and send all the commen

Re: [OE-core] [PATCH] python3-setuptools: drop python3-2to3 from RDEPENDS

On Thu, 20 Jun 2024 at 14:47, Ross Burton via lists.openembedded.org wrote: > > On 20 Jun 2024, at 12:30, Guðni Már Gilbert via lists.openembedded.org > > wrote: > > > > To add to this topic, I found > > https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/395 > > > > I wonder if setup

Re: [OE-core][RFC][PATCH] python3-numpy: upgrade 1.26.4 -> 2.0.0

On Thu, 20 Jun 2024 at 17:10, Trevor Gamblin via lists.openembedded.org wrote: > When trying to build the recipe, I see this error during do_compile: > > | Found Pkg-config: NO > | Run-time dependency python found: YES 3.12 > | Has header "Python.h" with dependency python: NO > | > | ../numpy-2.0.

[OE-core] [PATCH 02/11] devtool/upgrade: add RECIPE_UPGRADE_FINISH_EXTRA_TASKS

From: Alexander Kanavin This is modeled on RECIPE_UPGRADE_EXTRA_TASKS with the difference being that the tasks run in 'devtool finish', and only when finishing an upgrade operation. This allows recipes to define custom operations, such as renaming additional supplementary recipe

[OE-core] [PATCH 01/11] devtool/upgrade: rename RECIPE_UPDATE_EXTRA_TASKS -> RECIPE_UPGRADE_EXTRA_TASKS

From: Alexander Kanavin 'UPDATE' as a name is somewhat unfortunate as the variable is intended only for the 'devtool upgrade' operation and devtool also has an 'update-recipe' operation. I also intend to introduce additional variables in RECIPE_UPGRADE_* space, s

[OE-core] [PATCH 03/11] recipe-upgrade-additional-rename.bbclass: add a class

From: Alexander Kanavin Please see the comment in the class for the rationale. Signed-off-by: Alexander Kanavin --- .../recipe-upgrade-additional-rename.bbclass | 22 +++ 1 file changed, 22 insertions(+) create mode 100644 meta/classes-recipe/recipe-upgrade-additional

[OE-core] [PATCH 08/11] util-linux: rename util-linux-libuuid on recipe version upgrades

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-core/util-linux/util-linux-libuuid_2.39.3.bb | 2 ++ meta/recipes-core/util-linux/util-linux_2.39.3.bb | 3 +++ 2 files changed, 5 insertions(+) diff --git a/meta/recipes-core/util-linux/util-linux

[OE-core] [PATCH 04/11] glib-2.0: rename glib-initial recipe as well on version upgrades

From: Alexander Kanavin This makes use of all the facilities introduced in the previous commits. Signed-off-by: Alexander Kanavin --- meta/recipes-core/glib-2.0/glib-2.0-initial_2.80.2.bb | 2 +- meta/recipes-core/glib-2.0/glib-2.0_2.80.2.bb | 2 ++ 2 files changed, 3 insertions(+), 1

[OE-core] [PATCH 05/11] cmake: rename cmake-native recipe on version upgrades

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-devtools/cmake/cmake_3.29.3.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-devtools/cmake/cmake_3.29.3.bb b/meta/recipes-devtools/cmake/cmake_3.29.3.bb index 9146fa8c0f9..50f760f1c51 100644 --- a

[OE-core] [PATCH 10/11] mesa: rename mesa-gl on recipe version upgrades

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-graphics/mesa/mesa_24.0.7.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-graphics/mesa/mesa_24.0.7.bb b/meta/recipes-graphics/mesa/mesa_24.0.7.bb index 96e8aa38d61..0b36d8d5869 100644 --- a/meta

[OE-core] [PATCH 06/11] qemu: rename qemu-native and qemu-system-native recipes on version upgrades

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-devtools/qemu/qemu_9.0.0.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-devtools/qemu/qemu_9.0.0.bb b/meta/recipes-devtools/qemu/qemu_9.0.0.bb index dc1352232ef..da9b5bc679d 100644 --- a/meta

[OE-core] [PATCH 07/11] libva: rename libva-initial recipe on recipe version upgrades

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-graphics/libva/libva-initial_2.20.0.bb | 1 + meta/recipes-graphics/libva/libva_2.20.0.bb | 3 +++ 2 files changed, 4 insertions(+) diff --git a/meta/recipes-graphics/libva/libva-initial_2.20.0.bb b/meta

[OE-core] [PATCH 11/11] rt-tests: rename hwlatdetect on recipe version upgrades

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-rt/rt-tests/hwlatdetect_git.bb | 2 ++ meta/recipes-rt/rt-tests/rt-tests_git.bb| 3 +++ 2 files changed, 5 insertions(+) diff --git a/meta/recipes-rt/rt-tests/hwlatdetect_git.bb b/meta/recipes-rt/rt-tests

[OE-core] [PATCH 09/11] systemd: rename systemd-boot on recipe version upgrades

From: Alexander Kanavin Signed-off-by: Alexander Kanavin --- meta/recipes-core/systemd/systemd-boot_255.6.bb | 1 + meta/recipes-core/systemd/systemd_255.6.bb | 3 +++ 2 files changed, 4 insertions(+) diff --git a/meta/recipes-core/systemd/systemd-boot_255.6.bb b/meta/recipes-core

Re: [OE-core] Rust reproducibility issue summary

On Mon, 24 Jun 2024 at 06:00, Sundeep KOKKONDA via lists.openembedded.org wrote: > - The hash-id generates identically when the rust built from it's sources > every time. This is not the case. I just built rust (without sstate, from sources) in two different build directories on the same machine

Re: [OE-core] Rust reproducibility issue summary

On Mon, 24 Jun 2024 at 11:07, Sundeep KOKKONDA via lists.openembedded.org wrote: > This is not the case. I just built rust (without sstate, from sources) > in two different build directories on the same machine, and indeed > > Thanks for sharing this... Unfortunately I couldn't see this happening

Re: [OE-core] [PATCH] package.bbclass: Fix broken dev package dependency.

On Mon, 24 Jun 2024 at 11:56, Sreejith Ravi via lists.openembedded.org wrote: > > Currently, the process_pkgconfig() would process only the "Requires" key > field and ignore "Requires.private" while generating the dev dependency chain. > > Example: usr/lib/pkgconfig/libical.pc > -- > Libs

Re: [OE-core] [PATCH] package.bbclass: Fix broken dev package dependency.

On Mon, 24 Jun 2024 at 13:20, Sreejith Ravi wrote: > The icu package is necessary for the compilation of libical; otherwise, the > build will fail. "Recommended" contains all the packages that are part of the > dependent build. If we try to install the recommended packages, it will > download a

Re: [OE-core] Rust reproducibility issue summary

On Mon, 24 Jun 2024 at 11:11, Alexander Kanavin via lists.openembedded.org wrote: > I can share the two different build directories for your further > inspection perhaps? Let me upload the tarballs somewhere public. They're here: https://drive.google.com/file/d/1kKhHoC3oMFPFjvuLvM4gl

Re: [OE-core] [PATCH] package.bbclass: Fix broken dev package dependency.

On Mon, 24 Jun 2024 at 14:23, Sreejith Ravi via lists.openembedded.org wrote: > > We are building the components through Yocto and using dev IPKs for the > dependent packages (generated from Yocto) to resolve the build dependencies. > > Steps: > 1) Generate the libical IPKs from Yocto. > 2) Copy

Re: [OE-core] [PATCH] package.bbclass: Fix broken dev package dependency.

On Mon, 24 Jun 2024 at 14:47, Sreejith Ravi via lists.openembedded.org wrote: > > What is the purpose of the dev IPKs generated by Yocto? As I understand, we > can use them to resolve build dependencies. The purpose is to generate a SDK for cross-builds with a toolchain, or a target image for na

Re: [OE-core] [PATCH] package.bbclass: Fix broken dev package dependency.

On Mon, 24 Jun 2024 at 15:02, Sreejith Ravi via lists.openembedded.org wrote: > > We should be able to install the dev IPK and resolve its corresponding > dependency chain. As I mentioned earlier, enabling recommended packages and > installing them increases hard disk usage and installation time

Re: [OE-core] [PATCH] gobject-introspection: split tools and giscanner into a separate package

On Mon, 24 Jun 2024 at 22:32, Guðni Már Gilbert via lists.openembedded.org wrote: > +FILES:${PN}-tools = "\ > +${bindir}/g-ir-annotation-tool \ > +${bindir}/g-ir-compiler \ > +${bindir}/g-ir-generate \ > +${bindir}/g-ir-generate \ > +${bindir}/g-ir-inspect \

Re: [OE-core] Rust reproducibility issue summary

On Tue, 25 Jun 2024 at 05:02, Sundeep KOKKONDA wrote: > I can share the two different build directories for your further > inspection perhaps? Let me upload the tarballs somewhere public. > > They're here: > https://drive.google.com/file/d/1kKhHoC3oMFPFjvuLvM4glQzKX8JeXNue/view?usp=drive_link > ht

Re: [OE-core] [PATCH 02/11] devtool/upgrade: add RECIPE_UPGRADE_FINISH_EXTRA_TASKS

On Mon, 24 Jun 2024 at 22:33, Richard Purdie wrote: > Whilst I understand the desire, I'm not sure this lives up to way > devtool works. > > By that I mean that devtool upgrade usually does testing of the result > but with what you implement here, the second recipe is never actually > tested so th

Re: [OE-core] [PATCH 02/11] devtool/upgrade: add RECIPE_UPGRADE_FINISH_EXTRA_TASKS

On Tue, 25 Jun 2024 at 13:06, Richard Purdie wrote: > I don't think we even need to list the recipes like this. When devtool > upgrade runs, we get a list of files which change. We can then query > bitbake with that list of changed files and ask "which recipes also > depend on these?". Right. Ca

Re: [OE-core] [PATCH] python3-setuptools: drop python3-2to3 from RDEPENDS

Normally I'd say there's no need to worry and it's in a staging branch, but I don't see it there this time: https://git.yoctoproject.org/poky/log/?h=master-next https://git.yoctoproject.org/poky-contrib/log/?h=abelloni/master-next Alex On Thu, 27 Jun 2024 at 10:17, Guðni Már Gilbert via lists.ope

[OE-core] [PATCH] python3: drop deterministic_imports.patch

From: Alexander Kanavin https://github.com/python/importlib_metadata/issues/489 Upstream discussion revealed that: - the issue was happening due to a bug in setuptools - the bug was fixed in setuptools 63 (I confirmed this: empty dist-info directories no longer seem to trigger any issues if

Re: [OE-core] mc: broken source link

What kind of 'broken' are you seeing? I just issued 'wget http://www.midnight-commander.org/downloads/mc-4.8.31.tar.bz2' and it proceeded without issues to completion. Github archives are auto-generated and unstable. There is a qa check in insane.bbclass that prevents them from being used. Alex

Re: [OE-core] [AUH] bluez5: upgrading to 5.76 FAILED

I'd say just drop the problematic patch. If someone still needs it, they should come up with a correct, rebased version after the fact. Alex On Sun, 30 Jun 2024 at 13:38, Guðni Már Gilbert via lists.openembedded.org wrote: > > I found a Github issue which is related to the problematic obexd patc

Re: [OE-core] [PATCH 0/2] Pulseaudio Y2038 fix

Thanks, these look good. Alex On Mon, 1 Jul 2024 at 07:56, Primoz Fiser via lists.openembedded.org wrote: > > Hi, > > these 2 patches fix pulseaudio issues with Y2038 compatibility. And in > turn solve run-time issue with "Stack smashing" as described here [1]. > > Explanation: > > Patch #1: Add

Re: [OE-core] [PATCH 2/9] rust: Upgrade 1.75.0->1.76.0

On Mon, 1 Jul 2024 at 11:27, wrote: > * Drop 'rust-rustdoc' and 'rust-dbg' from 'exclude_packages' list > to check for rust reproducibility. If the reproducibility issue in rustdoc has not been solved, then this will only cause fails in CI and the patchset will be rejected. Have you done local t

Re: [OE-core] mc: broken source link

On Tue, 2 Jul 2024 at 23:28, Livius via lists.openembedded.org wrote: > By the way my experience is that GitHub source links of Releases/Tags are > more stable to get them any of time in 24/7. GitHub.com's Bandwidth and > accessibility/availability is very well. So why you said they are unstable

Re: [OE-core] [scarthgap][PATCH] python3-requests: cleanup RDEPENDS

On Wed, 3 Jul 2024 at 09:40, Guðni Már Gilbert via lists.openembedded.org wrote: > > I thought I should mention that now on master branch, python3-ndg-httpsclient > recipe is not required for any recipes in openembedded-core. Should it be > moved to meta-openembedded? Yes, that would be good.

Re: [OE-core] mc: broken source link

On Wed, 3 Jul 2024 at 11:45, Alexander Kanavin via lists.openembedded.org wrote: > There are two kinds of github archives, manually created and uploaded > release artefacts (those are stable), and automatically generated tag > archives (those are not). What you see at > https:

Re: [OE-core] Rust reproducibility issue summary

On Wed, 3 Jul 2024 at 10:09, Sundeep KOKKONDA < sundeep.kokko...@windriver.com> wrote: > > I ran both with 'bitbake -c install rust' which runs a complete build up > to install task, and then checked that rustdoc in image/ is different > between them. The other tasks aren't relevant, and you can i

Re: [OE-core] [PATCH 02/11] devtool/upgrade: add RECIPE_UPGRADE_FINISH_EXTRA_TASKS

On Tue, 25 Jun 2024 at 13:54, Richard Purdie wrote: > I appreciate it calls this "inherits" but this is actually a list of > any file included by the base recipe so any bbclass, .bb, or .inc file > that was included should be listed here. The True/False associated with > it is whether the file ex

Re: [OE-core] [PATCH] bluez5: upgrade 5.72 -> 5.76

On Thu, 4 Jul 2024 at 01:57, Guðni Már Gilbert via lists.openembedded.org wrote: > * Add a patch file to resolve an issue introduce in version 5.73 where > --disable-cups configuration breaks the build. A > patch was submitted upstream a while ago but was denied (silently) due > to failing CI

Re: [OE-core] [PATCH 9/9] rust: Upgrade 1.77.2->1.78.0

It's arm/arm64/x86/x86-64/mips/mips64/ppc. Given that rust upstream has all mips support in tier 3 (no promises), and ppc support in tier 2 without host tools (only building standard libraries for the target is tested), I don't think we should be fighting against that: https://doc.rust-lang.org/ru

Re: [OE-core] [PATCH 02/11] devtool/upgrade: add RECIPE_UPGRADE_FINISH_EXTRA_TASKS

On Wed, 3 Jul 2024 at 15:31, Richard Purdie wrote: > Sorry, I've got confused. Look at tinfoil.cooker_data.file_depends AttributeError: TinfoilRecipeCacheAdapter instance has no attribute 'file_depends' I had looked into the code, it seems that data is internal to bitbake, and isn't exposed to

Re: [OE-core] [PATCH] bluez5: upgrade 5.72 -> 5.76

That's right. I think the submission instructions are here? https://github.com/bluez/bluez/blob/master/HACKING Alex On Thu, 4 Jul 2024 at 12:50, Guðni Már Gilbert via lists.openembedded.org wrote: > > Hi Alex, > > I can try, I’ve already subscribed to the linux-bluetooth mailing list. Just > ne

Re: [OE-core] [PATCH 9/9] rust: Upgrade 1.77.2->1.78.0

On Thu, 4 Jul 2024 at 12:36, Alexander Kanavin via lists.openembedded.org wrote: > > It's arm/arm64/x86/x86-64/mips/mips64/ppc. > > Given that rust upstream has all mips support in tier 3 (no promises), > and ppc support in tier 2 without host tools (only building standard

Re: [OE-core] Rust reproducibility issue summary

Hello, I simply ran two independent builds, each with their own sstate. The host distro is not relevant, as it's been observed on yocto autobuilder across many different distros. I'm not sure why you insist on being able to reproduce the issue, as you're simply going to get the same build trees a

Re: [OE-core] Rust reproducibility issue summary

On Thu, 4 Jul 2024 at 18:47, Randy MacLeod wrote: > That's true, but it's always nicer to be able to reproduce a problem locally > so one can tests fixes properly. > Richard and I suggested that we at least get the distro and list of packages > identified so that Sundeep > could see if he can re

Re: [OE-core] Rust reproducibility issue summary

On Mon, 3 Jun 2024 at 09:08, Sundeep KOKKONDA < sundeep.kokko...@windriver.com> wrote: > Further analysis on autobuilder binaries shows that the deviations are > similar to that of earlier *rustdoc *issue. The deviations are in > .llvm. suffixes. > > As discussed in issue >

Re: [OE-core] [PATCH] execute pkg_postinst_ontarget task for read only rootfs when read-only-rootfs-delayed-postinsts is set

You need to use ‘git send-email’. Alex On Tue 9. Jul 2024 at 9.03, Gassner, Tobias.ext via lists.openembedded.org wrote: > Hi, > > this patch will ensure that pkg_postinst_ontarget task is executed for > read only rootfs when read-only-rootfs-delayed-postinsts is set as > IMAGE_FEATURES. In add

Re: [OE-core] [scarthgap][master][PATCH] vulkan-samples: fix do_compile error when -Og enabled

We haven’t updated Vulkan-samples in a while, can you check if the issue still occurs on the latest revision? Patches like this are difficult to remove, once added because one is expected to ‘prove’ they’re not needed, so I’d rather update. Alex On Tue 9. Jul 2024 at 9.32, Changqing Li via lists

Re: [OE-core] Yocto Python package upgradation from 3.10 to 3.11.5 version

Is your upgraded python used for both python3 and python3-native? nativepython3 is coming from python3-native variant of the recipe, so somehow that is still using the 3.10? It helps if you publish the layer. It's difficult to help without seeing what you did exactly. Alex On Wed, 10 Jul 2024 at

Re: [OE-core] [PATCH] cargo-update-recipe-crates: Use override style append so generated code passes oelint-adv.

But does this fix any actual issue? It’s not enough to justify the change with a ‘linter is complaining’. Reading the link, it’s about supporting a hypothetical weak assignment to SRC_URI, which basically never happens in real recipes. Alex On Wed 10. Jul 2024 at 21.47, jermigra via lists.openemb

Re: [OE-core] [PATCH] execute pkg_postinst_ontarget task for read only rootfs when read-only-rootfs-delayed-postinsts is set

This patch needs to be sent with 'git send-email'. I think this was requested before already? Alex On Wed, 10 Jul 2024 at 21:47, Gassner, Tobias.ext via lists.openembedded.org wrote: > > Hi, > > this patch will ensure that pkg_postinst_ontarget task is executed for read > only rootfs when read-

Re: [OE-core] [PATCH] cargo-update-recipe-crates: Use override style append so generated code passes oelint-adv.

On Wed, 10 Jul 2024 at 22:29, Jérémi Graveline wrote: > I understand, it is true it doesn't really happen in real recipes. Is the new > version of the class bad though? I cannot find a way to suppress the error > from the recipe itself and wish not to edit the generated include file. If I remem

Re: [OE-core] [PATCH 2/2] arch-arm64: Use neoverse-v1 ISA for Qemu usermode

I don't understand. Why setting an earlier CPU (that supports less instructions) solves the problem of trying to execute unsupported instructions? I think Arm folks should look at this. Alex On Fri, 12 Jul 2024 at 01:42, Khem Raj via lists.openembedded.org wrote: > > With latest qemu several pla

<    5   6   7   8   9   10   11   12   13   14   >