Signed-off-by: Vyacheslav Yurkov
---
meta/lib/oeqa/selftest/cases/overlayfs.py | 141 ++
1 file changed, 141 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index 43415778ce..4623215a47 100644
---
Signed-off-by: Vyacheslav Yurkov
---
meta/classes/overlayfs.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/overlayfs.bbclass b/meta/classes/overlayfs.bbclass
index 3c0f4dc882..f1b8086ea8 100644
--- a/meta/classes/overlayfs.bbclass
+++ b/meta/classes/overlayfs.bbclass
@@
Move helper functions out of class scope so they can be used in other tests
Signed-off-by: Vyacheslav Yurkov
---
meta/lib/oeqa/selftest/cases/overlayfs.py | 32 +++
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py
Signed-off-by: Vyacheslav Yurkov
---
meta/classes/image.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 6c759fdf70..e198f041b1 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@
Introduce wic image for overlayfs-etc tests with a dedicated /data
partition and configurable kernel parameters
Signed-off-by: Vyacheslav Yurkov
---
meta-selftest/wic/overlayfs_etc.wks.in | 4
1 file changed, 4 insertions(+)
create mode 100644 meta-selftest/wic/overlayfs_etc.wks.in
diff
This class provides an image feature that mounts /etc as an overlayfs
file system. This is an extension for existing overlayfs class, which
doesn't support /etc
Signed-off-by: Alfred Schapansky
Signed-off-by: Vyacheslav Yurkov
---
meta/classes/overlayfs-etc.bbclass | 93
This is a V1 of overlayfs-etc image feature implementation, that allows
to setup the whole /etc under overlayfs. Please review and merge if you
find it OK
The following changes since commit 0d15632f3db787d3f08eb260732567e62f52ffb3:
libtasn1: upgrade 4.17.0 -> 4.18.0 (2021-11-16 22:19:47 +)
Hi,
Gentle ping on this patch.
Thanks,
pgowda
On Mon, Nov 15, 2021 at 5:44 PM Pgowda wrote:
>
> source : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102035
>
> Upstream-Status:
> Backport[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3929bca9ca95de9d35e82ae8828b188029e3eb70]
>
On 11/18/21 8:12 PM, Joshua Watt wrote:
Reworks the crate fetcher class to have it install the fetcher at recipe
finalization so that it is always available before SRC_URI is expanded.
In addition, override the value of SRCPV to also install the fetcher
when SRCPV is expanded so that AUTOREV
Reworks the crate fetcher class to have it install the fetcher at recipe
finalization so that it is always available before SRC_URI is expanded.
In addition, override the value of SRCPV to also install the fetcher
when SRCPV is expanded so that AUTOREV works.
Signed-off-by: Joshua Watt
---
Hi Luca,
If the real useful part is only about systemd-analyze in case of
nativesdk/native, I'd suggest adding systemd-analyze-native or
nativesdk-systemd-analyze instead of extending the current systemd recipe.
This is because systemd has a whole bunch of dependencies which
basically make no
Please merge these changes.
Thanks,
Anuj
The following changes since commit 0ca080a23c2770a15138f702d4c879bbd90ca360:
build-appliance-image: Update to hardknott head revision (2021-11-04 11:58:28
+)
are available in the Git repository at:
On 2021-11-18 10:30 a.m., Pgowda wrote:
Hi,
Gentle ping on this patch.
It's in master-next but it may not have been this morning.
$ pwd
.../oe-core.git
$ git status
On branch master-next
Your branch is up to date with 'origin/master-next'.
nothing to commit, working tree clean
On Thu, Nov 18, 2021 at 2:32 AM Alexander Kanavin
wrote:
>
> I double checked, with strace (can't trust the logs as they don't show the
> actual linker invocation :)
>
>
Adds the rust tools to the cross and native files if present so that
projects that use both rust and meson can build
Signed-off-by: Joshua Watt
---
meta/classes/meson.bbclass | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/classes/meson.bbclass
These are glibc specific which comes from glibc packaging class
Signed-off-by: Khem Raj
---
meta/recipes-core/glibc/glibc-tests_2.34.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/glibc/glibc-tests_2.34.bb
b/meta/recipes-core/glibc/glibc-tests_2.34.bb
index
DISTRO_CODENAME is part of VERSION variable but not used as dependency
for do_compile task. Append it to the vardeps list to rebuild in case it
changes.
Signed-off-by: Daniel Gomez
---
meta/recipes-core/os-release/os-release.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Hi Robert,
On 11/18/21 11:43 AM, Robert P. J. Day wrote:
> On Thu, 18 Nov 2021, Martin Jansa wrote:
>
>> openembedded-core/scripts/sstate-cache-management.sh
> i just now found that script, and noticed that it is not documented
> anywhere in the YP docs. perhaps we need a short section on
>
Signed-off-by: Ulrich Ölmann
---
.../gstreamer/gstreamer1.0-plugins-base_1.18.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.5.bb
colleague just asked me about the viability of TAS in OE:
https://tcp-acceleration-service.github.io/documents/tas_slides.pdf
i've never even heard of it ... anyone crammed it into an
OE build?
rdayu
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply
Hi,
Gentle ping on this patch.
Thanks,
pgowda
On Mon, Nov 15, 2021 at 7:33 PM Pgowda wrote:
>
> rust-cross-* imported from meta-rust has incorrect signatures,
> depending on MACHINEOVERRIDES making it effectively MACHINE_ARCH
> as shown by sstate-diff-machines.sh:
>
>
Hi,
I would like to get some opinions from the OE experts regarding the
recommended structure of npm recipes. I have test different solutions
but need some advice.
npm could be used to build a web browser application or a Node.js
application:
1) A build of a *web browser application* with
On Thu, 18 Nov 2021, Alexander Kanavin wrote:
> There is a caveat here. This will touch all sstate that is needed to
> construct an image, but won't touch sstate needed to build
> components that go into the image. So target packages are guaranteed
> to be kept, but native items may be deleted -
There is a caveat here. This will touch all sstate that is needed to
construct an image, but won't touch sstate needed to build components that
go into the image. So target packages are guaranteed to be kept, but native
items may be deleted - I've seen this with e.g. java compiler that is used
for
If you can say that you've touched all the sstate you'll need then the
find trick is sufficient. I use it on our CI to prune any sstate that
hasn't been touched in a month, for example.
The script is more powerful and can selectively save or destroy
things, but can potentially be more
On 11/18/21 11:48, Alexander Kanavin wrote:
It would be also nice to confirm that the script is in use by someone,
and functions properly. There's a ton of stuff under scripts/ that
isn't getting a lot of attention or testing.
I use it regularly.
/Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You
It would be also nice to confirm that the script is in use by someone, and
functions properly. There's a ton of stuff under scripts/ that isn't
getting a lot of attention or testing.
Alex
On Thu, 18 Nov 2021 at 11:43, Robert P. J. Day
wrote:
> On Thu, 18 Nov 2021, Martin Jansa wrote:
>
> >
On Thu, 18 Nov 2021, Martin Jansa wrote:
> openembedded-core/scripts/sstate-cache-management.sh
i just now found that script, and noticed that it is not documented
anywhere in the YP docs. perhaps we need a short section on
sstate-cache management somewhere in the docs.
rday
Not really, no. It's also important to stop all builds while this is
running - sstate artefacts vanishing during a build will cause chaos.
Alex
On Thu, 18 Nov 2021 at 11:38, Robert P. J. Day
wrote:
>
> assuming my (correct) understanding of sstate-cache is that, as time
> goes by, it just
openembedded-core/scripts/sstate-cache-management.sh
On Thu, Nov 18, 2021 at 11:38 AM Robert P. J. Day
wrote:
>
> assuming my (correct) understanding of sstate-cache is that, as time
> goes by, it just gets larger and larger, it will increasingly contain
> content that is of little value
assuming my (correct) understanding of sstate-cache is that, as time
goes by, it just gets larger and larger, it will increasingly contain
content that is of little value anymore, what is the simplest way to
purge or prune entries that are no longer involved in any desired
builds?
i'm
I double checked, with strace (can't trust the logs as they don't show the
actual linker invocation :)
execve("/home/alex/development/poky/build-64-alt/tmp/work/core2-64-poky-linux/busybox/1.34.1-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc",
["x86_64-poky-linux-gcc",
32 matches
Mail list logo
