Re: [OE-core] systemd issue with network commandline config and 6.4 kernel

On 2023-08-08 17:34, Chen Qi via lists.openembedded.org wrote: Maybe some changes in new kernel allows renaming network interface while it's up? Seems correct! https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=bd039b5ea2a91ea707ee8539df26456bd5be80af That was added

Re: [OE-core] [RFC] python3-cryptogaphy upgrade to 40.0.2 issues

Hi, a short status update: On 2023-05-05 06:01, Tim Orling wrote: On Thu, May 4, 2023 at 5:00 AM Peter Bergin wrote: On 2023-05-04 11:00, Alexander Kanavin wrote: > On Thu, 4 May 2023 at 10:41, Peter Bergin wrote: > >> At >> https

Re: [OE-core] [RFC] python3-cryptogaphy upgrade to 40.0.2 issues

On 2023-05-04 19:13, Frederic Martinsons wrote: Le jeu. 4 mai 2023, 13:42, Peter Bergin a écrit : On 2023-05-04 12:03, Frederic Martinsons wrote: Le jeu. 4 mai 2023, 11:31, Frédéric Martinsons a écrit : On Thu, 4 May 2023 at 11:00, Alexander Kanavin

Re: [OE-core] [RFC] python3-cryptogaphy upgrade to 40.0.2 issues

On 2023-05-04 11:00, Alexander Kanavin wrote: On Thu, 4 May 2023 at 10:41, Peter Bergin wrote: At https://github.com/pyca/cryptography/blob/f816b457494e010b655cd7fdcd30e3446f86a703/src/rust/build.rs#L46 the path to python includes is defined by calling 'python3 -c "import sysconfig;

Re: [OE-core] [RFC] python3-cryptogaphy upgrade to 40.0.2 issues

On 2023-05-04 12:03, Frederic Martinsons wrote: Le jeu. 4 mai 2023, 11:31, Frédéric Martinsons a écrit : On Thu, 4 May 2023 at 11:00, Alexander Kanavin wrote: On Thu, 4 May 2023 at 10:41, Peter Bergin wrote: > At > https://gith

Re: [OE-core] [RFC] python3-cryptogaphy upgrade to 40.0.2 issues

On 2023-05-03 19:30, Tim Orling wrote: I am working on an upgrade from 39.0.2 to 40.0.2 for python3-cryptography: https://git.yoctoproject.org/poky-contrib/log/?h=timo/python3-cryptography_40.0.2 The patch at the tip of HEAD is perhaps not needed, as the compiling of `openssl-sys` was not

[OE-core] [PATCH] update-alternatives.bbclass: fix old override syntax

From: Peter Bergin Function 'gen_updatealternativesvardeps' still used old override syntax when fetching variable flags. Update to use ':' instead to match recipe meta data. This was found by review and no real issue encountered but it is a bug that affects variable dependencies and can affect

Re: [OE-core] update-alternatives.bbclass - is this a leftover from old override syntax?

On 2023-05-02 11:38, Richard Purdie wrote: We should fix it, can you send a patch please? Yes - will do! /Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180720): https://lists.openembedded.org/g/openembedded-core/message/180720 Mute

[OE-core] update-alternatives.bbclass - is this a leftover from old override syntax?

Hi, I stumbled on some code in update-alternatives.bbclass that I suspect is missed when we changed to new override syntax but I'm a bit unsure and would like some more eyes and comments on this. Doing debugging with logging I see that the class is fetching variables like 'ALTERNATIVE_${PN}'

Re: [OE-core] [PATCHV2 3/5] rust-example: provide a recipe for zvariant

On 2023-03-26 16:56, Frederic Martinsons wrote: From: Frederic Martinsons This recipe is for showing a "real world" example of a crate that depends on some git repositories. Usually, this kind of crate is built within a global workspace (here it is the zbus project) and so doesn't need a

Re: [OE-core] [PATCH] systemd: change syntax for SRC_URI append

On 2022-10-31 22:54, Alexander Kanavin wrote: On Mon, 31 Oct 2022 at 22:32, Peter Bergin wrote: Sure, I can do that. My aim for override those in a bbappend is just for development purposes and nothing I plan to use in production or push in public. My way of working when I realized

Re: [OE-core] [PATCH] systemd: change syntax for SRC_URI append

Hi Alex, On 2022-10-31 22:24, Alexander Kanavin wrote: On Mon, 31 Oct 2022 at 22:09, Peter Bergin wrote: In order to be able to override the git repo used in a bbappend file the additions of files to SRC_URI needs to be done with :append instead of +=, otherwise those will not be added. My

[OE-core] [PATCH] gptfdisk: remove warning message from target system

nor change in libuuid + +Upstream-Status: Backport [https://sourceforge.net/p/gptfdisk/code/ci/6a8416cbd12d55f882bb751993b94f72d338d96f/] +Signed-off-by: Peter Bergin +--- + guid.cc | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/guid.cc b/guid.cc +index 1e73ab7..d3e4fd5 100644 +---

[OE-core] [PATCH] systemd: change syntax for SRC_URI append

by the recipe (systemd.git instead of systemd-stable.git). With this change this is possible to do by having SRC_URI, SRCREV and SRCBRANCH in a bbappend. Signed-off-by: Peter Bergin --- meta/recipes-core/systemd/systemd_251.4.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [OE-core] Kirkstone Rust - native only error

Hi Joel, On 2022-09-11 03:00, Joel Winarske wrote: I'm putting together a recipe that requires two passes, native, then target.  I'm hitting a python error only in the native pass.  I can cross compile the tool without error, so the problem is  isolated to native.  Any ideas? Recipe is

Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: avoid moving ssh host keys if etc is writable

Thanks for the review. I have addressed them in v2 that is sent. /Peter On 2022-09-05 18:15, Peter Kjellerstedt wrote: -Original Message- From: openembedded-core@lists.openembedded.org On Behalf Of Peter Bergin Sent: den 5 september 2022 16:23 To: openembedded-core

[OE-core] [PATCH v2] rootfs-postcommands.bbclass: avoid moving ssh host keys if etc is writable

t;read-only-rootfs overlayfs-etc" --> ssh keys/config handled as rw root IMAGE_FEATURES = "read-only-rootfs stateless-rootfs" --> ssh keys/config handled as ro root IMAGE_FEATURES = "read-only-rootfs overlayfs-etc stateless-rootfs" --> ssh keys/config han

[OE-core] [PATCH] rootfs-postcommands.bbclass: avoid moving ssh host keys if etc is writable

t;read-only-rootfs overlayfs-etc" --> ssh keys/config handled as rw root IMAGE_FEATURES = "read-only-rootfs stateless-rootfs" --> ssh keys/config handled as ro root IMAGE_FEATURES = "read-only-rootfs overlayfs-etc stateless-rootfs" --> ssh keys/co

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

I was able to confirm that fixed a simple test case for nativesdk-gcc on i686 so I'll queue it up to reset the rust changes. Cheers, Richard Thank you Richard! Great that you could fix this and we could get the rust tests in. /Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

Hi Richard, (also adding Khem Raj to CC as maintainer for gcc in oe-core) On 2022-08-25 17:25, Richard Purdie wrote: On Thu, 2022-08-25 at 14:03 +0200, Peter Bergin wrote: Hi Richard, On 2022-08-25 10:21, Richard Purdie wrote: I've tried locally to reproduce something. I've built

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

Hi Richard, On 2022-08-25 10:21, Richard Purdie wrote: I've tried locally to reproduce something. I've built and tested genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the target for the autobuilder. Both tests passes. The failure I see in the autobuilder logs is that the

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

Hi Richard, On 2022-08-24 10:52, Richard Purdie wrote: On Tue, 2022-08-23 at 10:56 +0200, Peter Bergin wrote: The test for rust in the SDK is extended with the simplest possible build script. This will make use of the host toolchain for building build.rs before building the rust package

Re: [OE-core] [PATCH] rust-cross-canadian: rename shell variables for easier appends

On 2022-08-23 23:32, Otavio Salvador wrote: Em ter., 23 de ago. de 2022 às 17:38, Peter Bergin escreveu: In my particular case the rust application I'm building against the SDK is using the crate prost-build (https://crates.io/crates/prost-build) that is used to generate

Re: [OE-core] [PATCH] rust-cross-canadian: rename shell variables for easier appends

Hi Otavio, On 2022-08-23 16:03, Otavio Salvador wrote: Em ter., 23 de ago. de 2022 às 08:02, Peter Bergin escreveu: Make unique shell variable names for cargo and rust setup scripts. This change will make it easier to append to the scripts in a bbappend file by using

[OE-core] [PATCH] rust-cross-canadian: rename shell variables for easier appends

-by: Peter Bergin --- meta/recipes-devtools/rust/rust-cross-canadian.inc | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/recipes-devtools/rust/rust-cross-canadian.inc b/meta/recipes-devtools/rust/rust-cross-canadian.inc index 77d45a37a31..7bf75a4712e 100644 --- a/meta

[OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

The test for rust in the SDK is extended with the simplest possible build script. This will make use of the host toolchain for building build.rs before building the rust package for target. Signed-off-by: Peter Bergin --- meta/lib/oeqa/sdk/files/rust/hello/build.rs | 3 +++ 1 file changed, 3

[OE-core] [PATCH 1/2] packagegroup-rust-cross-canadian: add native compiler environment

-scripts.html Signed-off-by: Peter Bergin --- .../packagegroups/packagegroup-rust-cross-canadian.bb | 4 1 file changed, 4 insertions(+) diff --git a/meta/recipes-core/packagegroups/packagegroup-rust-cross-canadian.bb b/meta/recipes-core/packagegroups/packagegroup-rust-cross

[OE-core] [PATCH] rust: fix issue building cross-canadian tools for aarch64 on x86_64

Commit bd36593ba3db758b3eacc974e48468a665967961 did introduce a regression when building package rust-cross-canadian-aarch64 on a x86_64 host. This commit will fix that configuration. Suggested-by: Richard Purdie Signed-off-by: Peter Bergin --- meta/recipes-devtools/rust/rust-common.inc | 5

[OE-core] [PATCH] systemd: add packageconfig for sysext

Currently the sysext binary is packaged in systemd-utils and the service systemd-sysext.service in systemd package. Add a PACKAGECONFIG for sysext to actively choose if it is going to be installed or not, default off. If installed it will be added to systemd package. Signed-off-by: Peter Bergin

Re: [oe-core][PATCH v3 2/2] libavtp: add recipe to be able to use aaf config for alsa-plugins

On 2022-06-01 11:43, Alexander Kanavin wrote: I'm not sure what the dilemma is, inspecting the repo shows that there's a standard 0.2.0 tag pointing to a commit in the master branch. You can look at pretty much any other recipe fetching from git. https://github.com/Avnu/libavtp/tags Agree. My

Re: [oe-core][PATCH v2] libavtp: add recipe to be able to use aaf config for alsa-plugins

Hi, thanks Marcel for bumping this patch again! On 2022-05-31 18:38, Khem Raj wrote: On Tue, May 31, 2022 at 8:57 AM Marcel Ziswiler wrote: From: Peter Bergin In order to enable configuration option aaf (AVTP Audio Format) used for AVB the library libavtp is a dependency but no recipe

[OE-core] [RFC PATCH] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

that create multi partition images. These can turn the feature off locally by defining: do_image_myfs[respect_exclude_path] = "0" Specifically, "wic" and "multiubi" come with the feature disabled. Signed-off-by: Kristian Amlie Signed-off-by: Peter Bergin --- meta/classe

[OE-core] [RFC PATCH] Implement functionality to exclude dirs from rootfs

With this patch trying to wake alive an old patch that never found its way in to oe-core last time [1]. The added function is to configure directories that shall be excluded when creating an image. One use case is that some directories are located in a separate partition in the memory and

Re: [OE-core] rust - relocation error when setting up SDK

Not much around this and I opened a bugzilla issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14640 /Peter On 2021-11-17 11:27, Peter Bergin wrote: Hi, I'm trying to explore how to add and use rust in the SDK for cross-compilation. When installing and setting up a SDK

Re: [OE-core] rust in SDK

Hi Alex, On 2021-11-24 09:04, Alexander Kanavin wrote: Yocto is what you make it, and you shouldn't expect things to magically happen if you wait for them. If you are able to make rust work in SDK, adjust the docs, the readmes, add the tests and examples, and send the patches, and then

[OE-core] rust in SDK

Hi, I'm looking for information about how mature and tested it is to have rust tools in the SDK. In README-rust.md [1] there is a phrase "Once the Rust SDK support is added to oe-core..." which can be read that it is not ready yet. In the first bullet "What works:" it states "-buildsdk and

[OE-core] rust - relocation error when setting up SDK

Hi, I'm trying to explore how to add and use rust in the SDK for cross-compilation. When installing and setting up a SDK with packagegroup-rust-cross-canadian it fails if the installation path is too long. I have found similar issues in meta-rust [1] and some other setup [2] but can not

[OE-core] [PATCH] systemd: add packageconfig for wheel-group

eel' group in the standard config files for tmpfiles. Add this as a PACKAGECONFIG and enable it by default to keep default. Signed-off-by: Peter Bergin --- meta/recipes-core/systemd/systemd_249.3.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-core/systemd/systemd_249.3.

Re: [OE-core] [RFC][PATCH] libubootenv: exclude from world build if no u-boot config

On 2021-07-08 09:07, Richard Purdie wrote: On Tue, 2021-07-06 at 17:55 +0200, Peter Bergin wrote: As a fix for failing the world build for targets not using u-boot as boot loader libubootenv is excluded from world builds if both UBOOT_MACHINE and UBOOT_CONFIG variables are empty. Signed-off

Re: [OE-core] [PATCH] Revert "libubootenv: inherit uboot-config"

Hi Otavio, On 2021-07-06 18:56, Otavio Salvador wrote: Em ter., 6 de jul. de 2021 às 12:12, Peter Bergin mailto:pe...@berginkonsult.se>> escreveu: Then I can correct my earlier statement and a new wisdom that run-time dependecies are scanned already in the early

[OE-core] [RFC][PATCH] libubootenv: exclude from world build if no u-boot config

As a fix for failing the world build for targets not using u-boot as boot loader libubootenv is excluded from world builds if both UBOOT_MACHINE and UBOOT_CONFIG variables are empty. Signed-off-by: Peter Bergin --- meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb | 3 +++ 1 file changed, 3

Re: [OE-core] [PATCH] Revert "libubootenv: inherit uboot-config"

Hi again, sorry for the noise but did some investigations and was able to reproduce On 2021-07-06 15:42, Peter Bergin wrote: Hi, On 2021-07-06 04:44, Anuj Mittal wrote: Hi Peter, On Sun, 2021-07-04 at 10:21 +0100, Richard Purdie wrote: On Sun, 2021-07-04 at 10:59 +0200, Peter Bergin

Re: [OE-core] [PATCH] Revert "libubootenv: inherit uboot-config"

Hi, On 2021-07-06 04:44, Anuj Mittal wrote: Hi Peter, On Sun, 2021-07-04 at 10:21 +0100, Richard Purdie wrote: On Sun, 2021-07-04 at 10:59 +0200, Peter Bergin wrote: On 2021-07-03 16:55, Mittal, Anuj wrote: On Fri, 2021-07-02 at 13:59 +0200, Peter Bergin wrote: This reverts commit

Re: [OE-core] [PATCH] Revert "libubootenv: inherit uboot-config"

On 2021-07-03 16:55, Mittal, Anuj wrote: On Fri, 2021-07-02 at 13:59 +0200, Peter Bergin wrote: This reverts commit 10aa1291979fb90bed1beb49be4d406ed0e1e4d5. As there is no build dependency between libubootenv and the configuration of u-boot there is no reason to check for UBOOT_CONFIG

[OE-core] [PATCH] Revert "libubootenv: inherit uboot-config"

in bsp layer (meta-freescale). Signed-off-by: Peter Bergin --- meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb index 2cf87c794e..306296922c

[OE-core] [PATCH] libavtp: add recipe to be able to use aaf config for alsa-plugins

In order to enable configuration option aaf (AVTP Audio Format) used for AVB the library libavtp is a dependency but no recipe for this library was present. aaf support for alsa-plugins was introduced in ddf5421331180bc45697511b44cdd4a4e6dda6ff. Signed-off-by: Peter Bergin --- meta/recipes

[OE-core] [PATCH] buildhistory.bbclass: avoid exception for empty BUILDHISTORY_FEATURES variable

bute 'strip' This can happen in a multiconfig build where the default configuration use the buildhistory class but not the configuration in mc. It should be a rare case that this happens and it was found in a missconfigured build. Signed-off-by: Peter Bergin --- This should be a rare configuration

Re: [OE-core][RFC] weston-init: Stop running weston as root

Hi, this is a good improvement to the security, thanks for sharing this! As the global socket now is at /run/wayland-0 users that belongs to group 'wayland' and want to use weston needs to set its XDG_RUNTIME_DIR accordingly. As probably more applications than weston client is using

Re: [OE-core] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

Hi Alex, On 2020-11-12 12:38, Alexander Kanavin wrote: If you can provide exact steps to reproduce (the recipe is not available in oe-core), I can take a look. It's been reported plenty of times, but always with something not in core and not easily available. here are the steps to reproduce

[OE-core] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

Hi, when running 'devtool modify u-boot-imx' I get a stacktrace ending up in "ModuleNotFoundError: No module named '_sysconfigdata'". 'devtool modify' works for other recipes. Detailed stacktrace and layer info is added below. The stacktrace seems very similar to

Re: [OE-core] [PATCH 0/2] Make rt-tests buildable for all architectures

Hi Khem, On 2020-11-12 02:33, Khem Raj wrote: this seems to improve the situation but its not clear if arches without frc() will now fail miserably at runtime or will it only fail a subset of tests and rt-tests will still be largely useful for such arches. In the latter case, I am fine with

[OE-core] [PATCH 0/2] Make rt-tests buildable for all architectures

always work but oslat fails in run-time if frc() is missing. This commit series will backport that patch from rt-tets and revert oe-core commit to allow builds for all architectures again. Peter Bergin (2): rt-tests: backport patch that enable build for all archs Revert "rt-tests: Enable

[OE-core] [PATCH 2/2] Revert "rt-tests: Enable only for x86/ppc64 architectures"

This reverts commit 44010756b0ae91e0ac7715b7840285d59f991141. With the packported patch from rt-tests (67da9d8af7d8a0e1a0822e6ee99d68fa3d5a46d2) that allows build for all archs this patch can be reverted. An error is dumped in run-time is frc() is not present. Signed-off-by: Peter Bergin

[OE-core] [PATCH 1/2] rt-tests: backport patch that enable build for all archs

Upstream rt-tests has applied a patch that allow builds for all archs. The problem is that oslat using frc() that is not present for all archs. With this backported patch oslat is building but in run-time an error message is dumped if frc() is not present. Signed-off-by: Peter Bergin

[OE-core] [PATCH] systemd: avoid failing if no udev rules provided

. This solution is dynamic and search for *.rules files in $WORKDIR. If found they are installed. Signed-off-by: Peter Bergin --- meta/recipes-core/systemd/systemd_246.2.bb | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/systemd/systemd_246.2.bb b/meta/recipes

Re: [OE-core] [PATCH] kernel-devsrc: fix error with old (<4.2) x86 kernels

On 2019-11-28 15:08, Bruce Ashfield wrote: On Thu, Nov 28, 2019 at 1:14 AM Peter Bergin <mailto:pe...@berginkonsult.se>> wrote: When using kernel-devsrc for older kernels do_install fails with: | cp: failed to get attributes of 'arch/x86/entry': No such file or

[OE-core] [PATCH] kernel-devsrc: fix error with old (<4.2) x86 kernels

les copied in the kernel-devsrc recipe. Commit 1f57d5d85 was added in v4.2. To be able to use kernel-devsrc for kernels older than v4.2 this commit make use of find for the files that shall be copied. Signed-off-by: Peter Bergin --- meta/recipes-kernel/linux/kernel-devsrc.bb | 10 +- 1 file

[OE-core] gcc - internal compiler error: Segmentation failt

Hi, I'm working with thud branch and have run into a bug in gcc. I would like help how to proceed with this. Compiling the following C code gives Segmentation fault in gcc: #include #include #include int main(void) {     const int32_t BUFFER_MAX_LENGTH = 4096*1024;     char

[OE-core] [PATCH] at-spi2-core: only depend of x11 if in DISTRO_FEATURES

Build system for at-spi2-core package have auto detection of x11 dependency since version 2.26.1. Remove the hardcoded dependency in the recipe and let DISTRO_FEATURES decide. Signed-off-by: Peter Bergin --- meta/recipes-support/atk/at-spi2-core_2.30.0.bb | 9 + 1 file changed, 5

[OE-core] [PATCH v3] rpm: handle virtual memory usage when limit is set

Fix the situation where the task do_package_write_rpm ends up in "liblzma: memory allocation failed". This happens if the host environment has set a limit on virtual_memory for the user with 'ulimit -v' for packages with a lot of binary packages, e.g. glibc-locale. Signed-off-by: Pe

Re: [OE-core] [PATCH v2] rpm: handle virtual memory usage when limit is set

sending v2 it would be nice. The impact of this patch for most people is just a call to getrlimit(RLIMIT_AS, ...) so unless someone finds a problem, I think it should be merged after v3. On 09/20/2018 02:35 AM, Peter Bergin wrote: Fix the situation where the task do_package_write_rpm ends

Re: [OE-core] [PATCH v2] rpm: handle virtual memory usage when limit is set

Ping! Is this something that can be included? Main question for community is if we should support the server setup with restricted virtual memory and rpm packaging. Thanks! /Peter On 2018-09-20 08:35, Peter Bergin wrote: Fix the situation where the task do_package_write_rpm ends up

Re: [OE-core] [PATCH] rpm: handle virtual memory usage when limit is set

On 2018-09-20 01:02, Andre McCurdy wrote: On Wed, Sep 19, 2018 at 2:05 PM, Peter Bergin wrote: Fix the situation where the task do_package_write_rpm ends up in "liblzma: memory allocation failed". This happens if the host environment has set a limit on virtual_memory for the user wi

[OE-core] [PATCH v2] rpm: handle virtual memory usage when limit is set

Fix the situation where the task do_package_write_rpm ends up in "liblzma: memory allocation failed". This happens if the host environment has set a limit on virtual_memory for the user with 'ulimit -v' for packages with a lot of binary packages, e.g. glibc-locale. Signed-off-by: Pe

[OE-core] [PATCH] rpm: handle virtual memory usage when limit is set

ppropriate [error introduced by oe-core patch on rpm] Signed-off-by: Peter Bergin --- ...estrict-virtual-memory-usage-if-limit-set.patch | 52 ++ meta/recipes-devtools/rpm/rpm_4.14.2.bb| 1 + 2 files changed, 53 insertions(+) create mode 100644 meta/recipes-de

Re: [OE-core] [PATCH] busybox: move default config fragments to defconfig

On 2017-03-29 19:25, Ulrich Ölmann wrote: On Wed, Mar 29, 2017 at 08:23:00AM -0700, Andre McCurdy wrote: On Wed, Mar 29, 2017 at 3:24 AM, Richard Purdie wrote: Also, in case its not apparent, you can work around this today by providing empty fragment files

Re: [OE-core] [PATCH] busybox: move default config fragments to defconfig

On 2017-03-29 12:22, Richard Purdie wrote: On Wed, 2017-03-29 at 10:16 +0200, Peter Bergin wrote: I agree that it is nice and encouraged to group configurations together and make them selectable as a group. A good example from busybox_1.24.1.bb is: ${@["", "

Re: [OE-core] [PATCH] busybox: move default config fragments to defconfig

On 2017-03-29 01:02, Richard Purdie wrote: On Tue, 2017-03-28 at 22:08 +0200, Peter Bergin wrote: Move config fragments that are unconditionally and always applied to the configuration to the default defconfig file. This will make it easier to provide your own defconfig file for your target

[OE-core] [PATCH] busybox: move default config fragments to defconfig

. Signed-off-by: Peter Bergin <pe...@berginkonsult.se> --- meta/recipes-core/busybox/busybox/defconfig| 64 +++--- meta/recipes-core/busybox/busybox/getopts.cfg | 3 - .../busybox/busybox/login-utilities.cfg| 13 - .../busybox/busybox/mount-via-lab

[OE-core] busybox - providing your own defconfig

Hi, I'm currently looking into the configuration of busybox. What I want to do is to have my own defconfig in my own layer added by a bbappend file. During configuration of busybox I want use my defconfig file. What happens is that my defconfig is used as a base but then a couple of .cfg

[OE-core] [PATCH] useradd-staticids: fix typo for '--expiredate'

hat caused an error. Signed-off-by: Peter Bergin <pe...@berginkonsult.se> --- meta/classes/useradd-staticids.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/useradd-staticids.bbclass b/meta/classes/useradd-staticids.bbclass index a309b88..a65c3f6 1