Re: [OE-core] [PATCH 10/29] meson: upgrade 0.60.1 -> 0.60.2

[Khem Raj]

On Fri, Dec 10, 2021 at 9:01 AM Khem Raj  wrote:
>
> this breaks gjs also see https://github.com/mesonbuild/meson/issues/9472
>

I have a fix for gjs [1] but I was thinking meta-gnome is a good
testcase for meson. So when upgrading meson it will be good to add
this layer
to test and build world.


[1] 
https://lore.kernel.org/openembedded-devel/20211210173603.2826515-1-raj.k...@gmail.com/T/#u

> On Wed, Dec 8, 2021 at 2:00 PM Alexander Kanavin  
> wrote:
> >
> > From: Alexander Kanavin 
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  meta/recipes-devtools/meson/meson.inc   | 2 +-
> >  .../recipes-devtools/meson/{meson_0.60.1.bb => meson_0.60.2.bb} | 0
> >  .../{nativesdk-meson_0.60.1.bb => nativesdk-meson_0.60.2.bb}| 0
> >  3 files changed, 1 insertion(+), 1 deletion(-)
> >  rename meta/recipes-devtools/meson/{meson_0.60.1.bb => meson_0.60.2.bb} 
> > (100%)
> >  rename meta/recipes-devtools/meson/{nativesdk-meson_0.60.1.bb => 
> > nativesdk-meson_0.60.2.bb} (100%)
> >
> > diff --git a/meta/recipes-devtools/meson/meson.inc 
> > b/meta/recipes-devtools/meson/meson.inc
> > index f383ad9f74..7fbb246b87 100644
> > --- a/meta/recipes-devtools/meson/meson.inc
> > +++ b/meta/recipes-devtools/meson/meson.inc
> > @@ -15,7 +15,7 @@ SRC_URI = 
> > "https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> > file://0002-Support-building-allarch-recipes-again.patch \
> > file://0001-is_debianlike-always-return-False.patch \
> > "
> > -SRC_URI[sha256sum] = 
> > "5add789c953d984b500858b2851ee3d7add0460cf1a6f852f0a721af17384e13"
> > +SRC_URI[sha256sum] = 
> > "64e6968565bf1b8152f4f9d6ca8154efb9e14caa9aabf7b22e71e6c5d053e921"
> >
> >  UPSTREAM_CHECK_URI = "https://github.com/mesonbuild/meson/releases;
> >  UPSTREAM_CHECK_REGEX = "meson-(?P\d+(\.\d+)+)\.tar"
> > diff --git a/meta/recipes-devtools/meson/meson_0.60.1.bb 
> > b/meta/recipes-devtools/meson/meson_0.60.2.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/meson/meson_0.60.1.bb
> > rename to meta/recipes-devtools/meson/meson_0.60.2.bb
> > diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.60.1.bb 
> > b/meta/recipes-devtools/meson/nativesdk-meson_0.60.2.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/meson/nativesdk-meson_0.60.1.bb
> > rename to meta/recipes-devtools/meson/nativesdk-meson_0.60.2.bb
> > --
> > 2.20.1
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159559): 
https://lists.openembedded.org/g/openembedded-core/message/159559
Mute This Topic: https://lists.openembedded.org/mt/87599646/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] The state of DKMS in the Yocto community

[Alex Stewart]

Hey List,

I'm trying to work out the mysterious state of DKMS in OE-Core.

Our (NI) OE distributions rely heavily on DKMS to (un)install our 
ecosystem of kernel drivers at runtime across our product lines. To 
facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017, 
which we have carried out-of-stream since.


We tried to upstream it, and the patched rev'ed a couple of times [2]; 
but it seems to have never made it into a yocto release.


Though some other recipes mention DKMS passingly, I don't see anywhere 
that OE-Core officially supports it. Nor does my googling reveal anyone 
else who uses DKMS. I find that a little hard to believe, though I 
understand that it's probably relatively rare in the embedded space.



@all
So does anyone else on the list use DKMS in their yocto distribution? 
Are you maintaining a DKMS recipe out-of-stream as well?



@maintainers
If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and 
submitted it again to OE-Core, would you accept it? If not, we will move 
it to our own meta layer and accept that we are unique in this regard.



[1] 
https://github.com/ni/openembedded-core/commit/5789a27b68d95f3840bb8c4cb0d7b28d538c9a50


[2] https://lists.openembedded.org/g/openembedded-core/message/100680

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stew...@ni.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159558): 
https://lists.openembedded.org/g/openembedded-core/message/159558
Mute This Topic: https://lists.openembedded.org/mt/87645999/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][dunfell 16/18] cmake: FindGTest: Add target for gmock library

[Jasper Orschulko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everyone,

after some digging we identified the issue to be on our part.
We have been using "GTEST_LIBRARY" and "GTEST_MAIN_LIBRARY" in our
CMake scripts instead of "GTEST_LIBRARIES" and "GTEST_MAIN_LIBRARIES",
as described in the cmake docs:
https://cmake.org/cmake/help/v3.16/module/FindGTest.html#result-variables

So all good here! :)

- -- 
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
jasper.orschu...@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Schnellerstraße 1-5 | 12439 Berlin

https://iris-sensing.com/





On Thu, 2021-12-09 at 09:32 -1000, Steve Sakoman wrote:
> On Thu, Dec 9, 2021 at 7:38 AM Jasper Orschulko
>  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Hi,
> > 
> > I can't provide any details yet, but I can say with certainty that
> > this
> > patch breaks our build (using the parent commit
> >     746b301d37f9b7333f3d93e6fb7ea2808665df41 as refspec during
> > the build worksasexpected):
> > 
> > [...] undefined reference to `testing::*
> > 
> > Can someone confirm this issue? Feel free to reach out for further
> > details.
> 
> I've not seen any issues in either local or autobuilder testing, so I
> think we need more details!
> 
> Steve
> 
> > On Fri, 2021-12-03 at 08:19 -1000, Steve Sakoman wrote:
> > > From: Eero Aaltonen 
> > > 
> > > `googlemock` has been absorbed into the
> > > [googletest](https://github.com/google/googletest) project and is
> > > built
> > > and installed from the same source tree.
> > > 
> > > `googletest` has provided a CMake Config-file Package starting
> > > with
> > > GTest 1.8.1. `find_package(GTest ...)` by default dispatches
> > > first to
> > > CMake Find Module. Starting with CMake commit
> > > 2327b4330cce157d616ff8b611b3e77568d00351 in CMake v3.20.0 the
> > > module
> > > dispatches onward to the Config-file Package so that the same
> > > targets
> > > are available. In pre v3.20.0 versions of CMake however the Find
> > > Module
> > > masks the targets provided by the upstream `GTest` package.
> > > 
> > > Update `Modules/FindGTest.cmake` to provide the same targets as
> > > the
> > > CMake Config-file Package and backwards compatible targets and
> > > result
> > > variables.
> > > 
> > > Signed-off-by: Eero Aaltonen 
> > > Signed-off-by: Steve Sakoman 
> > > ---
> > >  .../cmake/cmake-native_3.16.5.bb  |   1 +
> > >  ...ndGTest-Add-target-for-gmock-library.patch | 255
> > > ++
> > >  2 files changed, 256 insertions(+)
> > >  create mode 100644 meta/recipes-devtools/cmake/cmake/0006-cmake-
> > > FindGTest-Add-target-for-gmock-library.patch
> > > 
> > > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb
> > > b/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb
> > > index b2952ee5f5..96a7be6770 100644
> > > --- a/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb
> > > +++ b/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb
> > > @@ -7,6 +7,7 @@ SRC_URI += "file://OEToolchainConfig.cmake \
> > >  file://environment.d-cmake.sh \
> > > 
> > > file://0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
> > >  \
> > > 
> > > file://0005-Disable-use-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch
> > >  \
> > > +
> > > file://0006-cmake-FindGTest-Add-target-for-gmock-library.patch \
> > >  "
> > > 
> > > 
> > > diff --git a/meta/recipes-devtools/cmake/cmake/0006-cmake-
> > > FindGTest-
> > > Add-target-for-gmock-library.patch b/meta/recipes-
> > > devtools/cmake/cmake/0006-cmake-FindGTest-Add-target-for-gmock-
> > > library.patch
> > > new file mode 100644
> > > index 00..267f586a71
> > > --- /dev/null
> > > +++ b/meta/recipes-devtools/cmake/cmake/0006-cmake-FindGTest-Add-
> > > target-for-gmock-library.patch
> > > @@ -0,0 +1,255 @@
> > > +From 39eae0d6c1b398f18761abac7f55944f0290f8a1 Mon Sep 17
> > > 00:00:00
> > > 2001
> > > +From: Eero Aaltonen 
> > > +Date: Sun, 17 Oct 2021 17:13:07 +0300
> > > +Subject: [PATCH] FindGTest: Add target for gmock library
> > > +
> > > +`googlemock` has been absorbed into the
> > > +[googletest](https://github.com/google/googletest) project and
> > > is
> > > built
> > > +and installed from the same source tree.
> > > +
> > > +As GTest may be built with or without GMock, skip GMock if it is
> > > not
> > > +present.
> > > +
> > > +Do not provide result variables for GMock.  They are not
> > > provided by
> > > +upstream GTest's CMake Package Configuration File.
> > > +
> > > +Also update the test case to cover linking to `GTest::gmock`.
> > > +
> > > +The patch was imported from the Kitware git server
> > > +(g...@gitlab.kitware.com:cmake/cmake.git) as of commit id
> > > +50bf457a0dd857cf976b22c5be7d333493233d1e
> > > +
> > > +Patch was modified to support upper case variable `GTEST_FOUND`.
> > > +
> > > +Upstream-Status: Accepted
> > 

[OE-core] [PATCH] elf: Discard input .note.gnu.build-id sections

[Valery Chernous]

From: Valerii Chernous 

Originally issue:
building of glibc 2.32 or 2.34 with option "-Wl,--build-id"
produce libc.so.6 with section ".note.gnu.build-id" that have
invalid(double, 0x48) section size. It happens because glibc
use sublibraries for linking libc.so.6
ld produce this sublibraries with build-id section and on last
linking stage loads this sections as input for linking.
ld should create new(valid) ".note.gnu.build-id" into function
ldelf_setup_build_id on last linking stage but it skip creating because
build-id section already exists.
As result libc.so.6 contain ".note.gnu.build-id" with build-ids from
sublibraries and without valid build-id

Howto solved:
1. Discard input .note.gnu.build-id sections.
2. Clear the build ID field before writing.
3. Use bfd_make_section_anyway_with_flags to create the output
   .note.gnu.build-id section.

Upstream-Status: Backport

Reference to upstream patch:
[https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f1d0fa6c944e612b416a2a6e11abcf5199f]

Signed-off-by: Valerii Chernous 
Signed-off-by: Valery Chernous 
---
 .../binutils/binutils-2.37.inc|   1 +
 ...rd-input-.note.gnu.build-id-sections.patch | 215 ++
 2 files changed, 216 insertions(+)
 create mode 100644 
meta/recipes-devtools/binutils/binutils/0001-elf-Discard-input-.note.gnu.build-id-sections.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.37.inc 
b/meta/recipes-devtools/binutils/binutils-2.37.inc
index 8f91c6460d..c565adc4b7 100644
--- a/meta/recipes-devtools/binutils/binutils-2.37.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.37.inc
@@ -35,5 +35,6 @@ SRC_URI = "\
  file://0015-sync-with-OE-libtool-changes.patch \
  file://0016-Check-for-clang-before-checking-gcc-version.patch \
  file://0017-bfd-Close-the-file-descriptor-if-there-is-no-archive.patch \
+ file://0001-elf-Discard-input-.note.gnu.build-id-sections.patch \
 "
 S  = "${WORKDIR}/git"
diff --git 
a/meta/recipes-devtools/binutils/binutils/0001-elf-Discard-input-.note.gnu.build-id-sections.patch
 
b/meta/recipes-devtools/binutils/binutils/0001-elf-Discard-input-.note.gnu.build-id-sections.patch
new file mode 100644
index 00..c93af4e46f
--- /dev/null
+++ 
b/meta/recipes-devtools/binutils/binutils/0001-elf-Discard-input-.note.gnu.build-id-sections.patch
@@ -0,0 +1,215 @@
+From b2e18d3ea300f7491705b6e86a7cc3d6366e3b1f Mon Sep 17 00:00:00 2001
+From: "H.J. Lu" 
+Date: Tue, 30 Nov 2021 20:40:38 -0800
+Subject: [PATCH] elf: Discard input .note.gnu.build-id sections
+
+1. Discard input .note.gnu.build-id sections.
+2. Clear the build ID field before writing.
+3. Use bfd_make_section_anyway_with_flags to create the output
+.note.gnu.build-id section.
+
+   PR ld/28639
+   * ldelf.c (ldelf_after_open): Discard input .note.gnu.build-id
+   sections, excluding the first one.
+   (write_build_id): Clear the build ID field before writing.
+   (ldelf_setup_build_id): Use bfd_make_section_anyway_with_flags
+   to create the output .note.gnu.build-id section.
+   * testsuite/ld-elf/build-id.exp: New file.
+   * testsuite/ld-elf/pr28639a.rd: Likewise.
+   * testsuite/ld-elf/pr28639b.rd: Likewise.
+   * testsuite/ld-elf/pr28639c.rd: Likewise.
+   * testsuite/ld-elf/pr28639d.rd: Likewise.
+
+Upstream-Status: Backport
+
+Reference to upstream patch:
+[https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f1d0fa6c944e612b416a2a6e11abcf5199f]
+---
+ ld/ldelf.c   | 15 ++-
+ ld/testsuite/ld-elf/build-id.exp | 77 
+ ld/testsuite/ld-elf/pr28639a.rd  |  6 +++
+ ld/testsuite/ld-elf/pr28639b.rd  |  6 +++
+ ld/testsuite/ld-elf/pr28639c.rd  | 10 +
+ ld/testsuite/ld-elf/pr28639d.rd  |  4 ++
+ 6 files changed, 117 insertions(+), 1 deletion(-)
+ create mode 100644 ld/testsuite/ld-elf/build-id.exp
+ create mode 100644 ld/testsuite/ld-elf/pr28639a.rd
+ create mode 100644 ld/testsuite/ld-elf/pr28639b.rd
+ create mode 100644 ld/testsuite/ld-elf/pr28639c.rd
+ create mode 100644 ld/testsuite/ld-elf/pr28639d.rd
+
+diff --git a/ld/ldelf.c b/ld/ldelf.c
+index 21e655bb55c..8501d98b48f 100644
+--- a/ld/ldelf.c
 b/ld/ldelf.c
+@@ -1043,6 +1043,15 @@ ldelf_after_open (int use_libpath, int native, int 
is_linux, int is_freebsd,
+   /* Do not allow executable files to be used as inputs to the link.  */
+   for (abfd = link_info.input_bfds; abfd; abfd = abfd->link.next)
+ {
++  /* Discard input .note.gnu.build-id sections.  */
++  s = bfd_get_section_by_name (abfd, ".note.gnu.build-id");
++  while (s != NULL)
++  {
++if (s != elf_tdata (link_info.output_bfd)->o->build_id.sec)
++  s->flags |= SEC_EXCLUDE;
++s = bfd_get_next_section_by_name (NULL, s);
++  }
++
+   if (abfd->xvec->flavour == bfd_target_elf_flavour
+ && !bfd_input_just_syms (abfd)
+ && elf_tdata (abfd) != NULL
+@@ -1387,6 +1396,9 @@ write_build_id (bfd *abfd)
+ 

Re: [OE-core] [PATCH 10/29] meson: upgrade 0.60.1 -> 0.60.2

[Khem Raj]

this breaks gjs also see https://github.com/mesonbuild/meson/issues/9472

On Wed, Dec 8, 2021 at 2:00 PM Alexander Kanavin  wrote:
>
> From: Alexander Kanavin 
>
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/recipes-devtools/meson/meson.inc   | 2 +-
>  .../recipes-devtools/meson/{meson_0.60.1.bb => meson_0.60.2.bb} | 0
>  .../{nativesdk-meson_0.60.1.bb => nativesdk-meson_0.60.2.bb}| 0
>  3 files changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-devtools/meson/{meson_0.60.1.bb => meson_0.60.2.bb} 
> (100%)
>  rename meta/recipes-devtools/meson/{nativesdk-meson_0.60.1.bb => 
> nativesdk-meson_0.60.2.bb} (100%)
>
> diff --git a/meta/recipes-devtools/meson/meson.inc 
> b/meta/recipes-devtools/meson/meson.inc
> index f383ad9f74..7fbb246b87 100644
> --- a/meta/recipes-devtools/meson/meson.inc
> +++ b/meta/recipes-devtools/meson/meson.inc
> @@ -15,7 +15,7 @@ SRC_URI = 
> "https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> file://0002-Support-building-allarch-recipes-again.patch \
> file://0001-is_debianlike-always-return-False.patch \
> "
> -SRC_URI[sha256sum] = 
> "5add789c953d984b500858b2851ee3d7add0460cf1a6f852f0a721af17384e13"
> +SRC_URI[sha256sum] = 
> "64e6968565bf1b8152f4f9d6ca8154efb9e14caa9aabf7b22e71e6c5d053e921"
>
>  UPSTREAM_CHECK_URI = "https://github.com/mesonbuild/meson/releases;
>  UPSTREAM_CHECK_REGEX = "meson-(?P\d+(\.\d+)+)\.tar"
> diff --git a/meta/recipes-devtools/meson/meson_0.60.1.bb 
> b/meta/recipes-devtools/meson/meson_0.60.2.bb
> similarity index 100%
> rename from meta/recipes-devtools/meson/meson_0.60.1.bb
> rename to meta/recipes-devtools/meson/meson_0.60.2.bb
> diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.60.1.bb 
> b/meta/recipes-devtools/meson/nativesdk-meson_0.60.2.bb
> similarity index 100%
> rename from meta/recipes-devtools/meson/nativesdk-meson_0.60.1.bb
> rename to meta/recipes-devtools/meson/nativesdk-meson_0.60.2.bb
> --
> 2.20.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159555): 
https://lists.openembedded.org/g/openembedded-core/message/159555
Mute This Topic: https://lists.openembedded.org/mt/87599646/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 08/10] qemu: remove obsolete support for renamed libtool

[Ross Burton]

On Fri, 10 Dec 2021 at 15:58, Khem Raj  wrote:
>> libtool is now longer renamed to ${host}-libtool, so
>
> Typo now should be no

Argh.

Dug out git-filter-branch, now fixed in poky-contrib:ross/libtool.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159554): 
https://lists.openembedded.org/g/openembedded-core/message/159554
Mute This Topic: https://lists.openembedded.org/mt/87636636/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] perf: Tweak for mips n64

[Richard Purdie]

On Fri, 2021-12-10 at 07:56 -0800, Khem Raj wrote:
> 
> 
> On Fri, Dec 10, 2021 at 4:05 AM Richard Purdie
>  wrote:
> > With the changes to binutils, perf's direct calls to ld break for mips n64.
> > We already have tweaks for n32 so match those with the ones for n64.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/recipes-kernel/perf/perf.bb | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-
> > kernel/perf/perf.bb
> > index 7bbc1ad70c5..ec0c6efe15f 100644
> > --- a/meta/recipes-kernel/perf/perf.bb
> > +++ b/meta/recipes-kernel/perf/perf.bb
> > @@ -125,9 +125,11 @@ PERF_SRC ?= "Makefile \
> > 
> >  PERF_EXTRA_LDFLAGS = ""
> > 
> > -# MIPS N32
> > +# MIPS N32/N64
> >  PERF_EXTRA_LDFLAGS:mipsarchn32eb = "-m elf32btsmipn32"
> >  PERF_EXTRA_LDFLAGS:mipsarchn32el = "-m elf32ltsmipn32"
> > +PERF_EXTRA_LDFLAGS:mipsarchn64eb = "-m elf64btsmip"
> > +PERF_EXTRA_LDFLAGS:mipsarchn64el = "-m elf64ltsmip"
> > 
> 
> 
> Hmm this tells me that the default is not really changed in binutils to use
> n64 abi with out the patch to binutils configure 
> 
> N32 patch above is perhaps fine because that’s not our default 
> 
> Perhaps we need to check a bit more here as to what’s going on

In the x86 case, ld looks at the existing object files and sets it's emulation
mode accordingly if none were specified. It seems mips lacks this and there was
a binutils patch which changed the default which I have dropped in -next. The
N32 case is another example of it which we never patched. Unlike the gcc case,
there is no option to change the default when compiling binutils.

Most of the time we don't need that patch as programs use CC/CCLD for linking
and the correct flags are specified there through the gcc driver, perf is the
only one in core which seems to use ld directly like this.

We could start to try and fix the autodetection for mips in the compiler but for
an architecture which has minimal mindshare, I'm not sure it is worth the
effort. Using the same approach as we already have for N32 and dropping the
patch seemed like the reasonable course of action?

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159553): 
https://lists.openembedded.org/g/openembedded-core/message/159553
Mute This Topic: https://lists.openembedded.org/mt/87634357/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 08/10] qemu: remove obsolete support for renamed libtool

[Khem Raj]

On Fri, Dec 10, 2021 at 6:22 AM Ross Burton  wrote:

> libtool is now longer renamed to ${host}-libtool, so


Typo now should be no

remove the changes
> to support this.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/qemu/qemu.inc | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc
> b/meta/recipes-devtools/qemu/qemu.inc
> index ea7dfaecef8..fe35f94acf7 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -98,8 +98,6 @@ EXTRA_OECONF = " \
>  ${PACKAGECONFIG_CONFARGS} \
>  "
>
> -export LIBTOOL="${HOST_SYS}-libtool"
> -
>  B = "${WORKDIR}/build"
>
>  #EXTRA_OECONF:append = " --python=${HOSTTOOLS_DIR}/python3"
> --
> 2.25.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159552): 
https://lists.openembedded.org/g/openembedded-core/message/159552
Mute This Topic: https://lists.openembedded.org/mt/87636636/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 01/10] libtool: don't prefix the installed binary

[Ross Burton]

On Fri, 10 Dec 2021 at 15:17, Khem Raj  wrote:
> Does it mean that it can now run original libtool script accidentally which 
> is pregenerated part of package which may be not what we want

Not really, if we run libtoolize then we replace any existing libtool
binary.  If we don't run libtoolize then there isn't our binary in the
first place.  Also, libtool-cross/libtool-native provide our libtool
binary on $PATH.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159551): 
https://lists.openembedded.org/g/openembedded-core/message/159551
Mute This Topic: https://lists.openembedded.org/mt/87636630/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe][OE-core][Patch 0/2] implement applying patches from a directory

[Richard Purdie]

On Fri, 2021-12-10 at 14:04 +0100, Max Krummenacher wrote:
> The current developer manual [1] specifies that patches that are
> part of a directory which is given in SRC_URI are applied by
> the do_patch task. However that is not implemented in the
> current code.
> 
> This patchset implements that, but deviates from what is
> documented. If the patches are applied I will send a patch
> for the documentation changing the relevant part to:
> 
> ```
> If you have a directory full of patch files and you want to
> apply them all you can add the directory to SRC_URI and add
> the "apply=yes" parameter. This will apply ALL files in the
> directiory, including files in subdirectories.
> The patches will be applied sorted by their filename. Files
> from subdirectories will be sorted into the list at the
> position given by the subdirectory name.
> 
>SRC_URI = " \
>git://path_to_repo/some_package \
>file://path_to_lots_of_patch_files;apply=yes \
>"
> 
> In the previous example all the files in the directory holding
> the patch files would be applied as a patch.
> ```
> 
> Max
> 
> [1] 
> https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-tasks-patch
> 
> Max Krummenacher (2):
>   lib/oe/patch.py: apply patches from src_uri specified directories
>   lib/oe/recipeutils.py: follow changed method argument list
> 

Can I ask about the motivation here? Have you a use case you needed this to work
with or are you just making the code match the docs?

I'm a little worried about adding features like this which aren't commonly used
and clearly haven't been needed for a while. Such changes really do need some
kind of test case and as Bruce mentions, ordering of patches patches in
directories is a concern, you did at least sort the listdir() output which is
good :)

In the past when I've needed something like this, dumping "ls -1" into a file
and turning it into a SRC_URI hasn't been too hard even for long lists of
patches...

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159550): 
https://lists.openembedded.org/g/openembedded-core/message/159550
Mute This Topic: https://lists.openembedded.org/mt/87635232/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] perf: Tweak for mips n64

[Khem Raj]

On Fri, Dec 10, 2021 at 4:05 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> With the changes to binutils, perf's direct calls to ld break for mips n64.
> We already have tweaks for n32 so match those with the ones for n64.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-kernel/perf/perf.bb | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/
> perf.bb
> index 7bbc1ad70c5..ec0c6efe15f 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -125,9 +125,11 @@ PERF_SRC ?= "Makefile \
>
>  PERF_EXTRA_LDFLAGS = ""
>
> -# MIPS N32
> +# MIPS N32/N64
>  PERF_EXTRA_LDFLAGS:mipsarchn32eb = "-m elf32btsmipn32"
>  PERF_EXTRA_LDFLAGS:mipsarchn32el = "-m elf32ltsmipn32"
> +PERF_EXTRA_LDFLAGS:mipsarchn64eb = "-m elf64btsmip"
> +PERF_EXTRA_LDFLAGS:mipsarchn64el = "-m elf64ltsmip"
>

Hmm this tells me that the default is not really changed in binutils to use
n64 abi with out the patch to binutils configure

N32 patch above is perhaps fine because that’s not our default

Perhaps we need to check a bit more here as to what’s going on


>  do_compile() {
> # Linux kernel build system is expected to do the right thing
> --
> 2.32.0
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159549): 
https://lists.openembedded.org/g/openembedded-core/message/159549
Mute This Topic: https://lists.openembedded.org/mt/87634357/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] libva: move wayland PACKAGECONFIG to libva.inc

[Khem Raj]

On Fri, Dec 10, 2021 at 6:33 AM Markus Volk  wrote:

> Thats strange indeed. Wayland is set as a DISTRO_FEATURE for my image, so
> it gets built by a lot of packages. This wasn't a clean build, i had
> sstate cache availbale when i started to experiment with libva and normally
> it doesn't get  built inside my image because i can't use it on my board.
> First i did 'bitbake libva' and this succeeded. Second i added 'va'
> PACKAGECONFIG to a mesa.bbappend and started rebuilding the image. Now the
> build for libva-initial was started and failed with the error about missing
> wayland-scanner.
>
> I also wondered what is pulling  wayland into  its sysroot . Did 'bitbake
> -c cleanstate libva-initial libva' and tried to build libva-initial again
> with 'bitbake libva-initial' and had the same issue. On my machine this is
> reproducible
>

Post configure logs including meson run  logs for this package perhaps
there is some hint in there

>
> Markus
> Am 10.12.21 um 15:06 schrieb Alexander Kanavin:
>
> | Run-time dependency wayland-client found: YES 1.19.0
>
> Can you please explain how the issue can be reproduced? I find it odd that
> libva-initial (which only needs libdrm, and is required by mesa) has
> wayland in its sysroot in your build - where does that come from? There's a
> chance the problem is elsewhere.
>
> Alex
>
> On Fri, 10 Dec 2021 at 15:03, Markus Volk  wrote:
>
>> I encountered an error while trying to build libva under wayland.
>> libva-initial
>> was missing wayland-native dependency and failed like this:
>>
>> | Run-time dependency xfixes found: NO (tried pkgconfig and cmake)
>> | Run-time dependency wayland-client found: YES 1.19.0
>> | Program wayland-scanner /usr/bin/wayland-scanner found: NO
>> |
>> | ../libva-2.13.0/meson.build:107:4: ERROR: Program 'wayland-scanner
>> /usr/bin/wayland-scanner' not found
>> |
>> | A full log can be found at
>> /home/flk/build/poky/build-rock/tmp/work/cortexa72-cortexa53-crypto-poky-linux/libva-initial/2.13.0-r0/build/meson-logs/meson-log.txt
>> | ERROR: meson failed
>> | WARNING: exit code 1 from a shell command.
>>
>> This commit moves the PACKAGECONFIG[wayland] to libva.inc to make it
>> available to libva-initial also
>>
>> Signed-off-by: MarkusVolk 
>> ---
>>  meta/recipes-graphics/libva/libva.inc   | 7 +++
>>  meta/recipes-graphics/libva/libva_2.13.0.bb | 4 +---
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/recipes-graphics/libva/libva.inc
>> b/meta/recipes-graphics/libva/libva.inc
>> index bcf9757c1a..0e2721e291 100644
>> --- a/meta/recipes-graphics/libva/libva.inc
>> +++ b/meta/recipes-graphics/libva/libva.inc
>> @@ -27,3 +27,10 @@ UPSTREAM_CHECK_URI = "
>> https://github.com/intel/libva/releases;
>>  DEPENDS = "libdrm"
>>
>>  inherit meson pkgconfig
>> +
>> +PACKAGECONFIG:append = " \
>> +${@bb.utils.filter('DISTRO_FEATURES', 'wayland', d)} \
>> +"
>> +
>> +PACKAGECONFIG[wayland] =
>> "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native wayland"
>> +
>> diff --git a/meta/recipes-graphics/libva/libva_2.13.0.bb
>> b/meta/recipes-graphics/libva/libva_2.13.0.bb
>> index ed2be289fc..a8c6355b01 100644
>> --- a/meta/recipes-graphics/libva/libva_2.13.0.bb
>> +++ b/meta/recipes-graphics/libva/libva_2.13.0.bb
>> @@ -2,14 +2,12 @@ require libva.inc
>>
>>  PACKAGECONFIG ??= " \
>>  ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', '', d)}
>> \
>> -${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)} \
>> +${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} \
>>  "
>>
>>  PACKAGECONFIG[x11] = "-Dwith_x11=yes,-Dwith_x11=no,virtual/libx11
>> libxext libxfixes"
>>  PACKAGECONFIG[glx] = "-Dwith_glx=yes,-Dwith_glx=no,virtual/mesa"
>>
>> -PACKAGECONFIG[wayland] =
>> "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native wayland"
>> -
>>  PACKAGES =+ "${PN}-x11 ${PN}-glx ${PN}-wayland"
>>
>>  RDEPENDS:${PN}-x11 =+ "${PN}"
>> --
>> 2.25.1
>>
>>
>>
>>
>>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159548): 
https://lists.openembedded.org/g/openembedded-core/message/159548
Mute This Topic: https://lists.openembedded.org/mt/87636241/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v2] epiphany: Add packageconfig for libsoup2

[Joshua Watt]

Adds a PACKAGECONFIG option to use libsoup2 instead of libsoup3.
Including libsoup2 and libsoup3 in the same process can cause strange
runtime failures, and the latest release of each major version will
cause the process to exit if both are detected on startup.

The default is changed from libsoup3 back to libsoup2 to follow
webkitgtk.

Signed-off-by: Joshua Watt 
---
 meta/recipes-gnome/epiphany/epiphany_41.0.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/epiphany/epiphany_41.0.bb 
b/meta/recipes-gnome/epiphany/epiphany_41.0.bb
index 09210b68aa..8f3bd87340 100644
--- a/meta/recipes-gnome/epiphany/epiphany_41.0.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_41.0.bb
@@ -30,10 +30,13 @@ SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@oe.utils.trim_version("${PV}", 1)}/${GN
"
 SRC_URI[archive.sha256sum] = 
"b39d1825492595b0b74c5d6a6686a857f9419dfa4c02f8013c297bc870e26dd0"
 
-EXTRA_OEMESON += "-Dsoup2=disabled"
+PACKAGECONFIG_SOUP ?= "soup2"
+PACKAGECONFIG ??= "${PACKAGECONFIG_SOUP}"
 
 # Developer mode enables debugging
 PACKAGECONFIG[developer-mode] = "-Ddeveloper_mode=true,-Ddeveloper_mode=false"
+PACKAGECONFIG[soup2] = "-Dsoup2=enabled,-Dsoup2=disabled,libsoup-2.4,,,soup3"
+PACKAGECONFIG[soup3] = ",,libsoup,,,soup2"
 
 FILES:${PN} += "${datadir}/dbus-1 ${datadir}/gnome-shell/search-providers 
${datadir}/metainfo"
 RDEPENDS:${PN} = "iso-codes adwaita-icon-theme gsettings-desktop-schemas"
-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159547): 
https://lists.openembedded.org/g/openembedded-core/message/159547
Mute This Topic: https://lists.openembedded.org/mt/87638363/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v2] webkitgtk: Add packageconfig for libsoup2

[Joshua Watt]

Adds a PACKAGECONFIG option to use libsoup2 instead of libsoup3.
Including libsoup2 and libsoup3 in the same process can cause strange
runtime failures, and the latest release of each major version will
cause the process to exit if both are detected on startup.

The default is changed from libsoup3 back to libsoup2. Most GNOME
packages are still using libsoup2, and a large number of these pull in
webkitgtk either directly or indirectly. If webkitgtk uses libsoup3,
this causes all of these packages to fail at startup. It appears that
most GNOME packages will have to switch to libsoup3 when they transition
to GTK4.

Signed-off-by: Joshua Watt 
---
 meta/recipes-sato/webkit/webkitgtk_2.34.2.bb | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.34.2.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.34.2.bb
index 413e0cdf92..a9b151e3c3 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.34.2.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.34.2.bb
@@ -38,7 +38,6 @@ DEPENDS = " \
   atk \
   libwebp \
   gtk+3 \
-  libsoup \
   libxslt \
   libtasn1 \
   libnotify \
@@ -46,12 +45,14 @@ DEPENDS = " \
   gstreamer1.0-plugins-base \
   "
 
+PACKAGECONFIG_SOUP ?= "soup2"
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd wayland 
x11', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'webgl opengl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', 'webgl 
gles2 angle', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'opengl-or-es', '', d)} \
enchant \
libsecret \
+   ${PACKAGECONFIG_SOUP} \
   "
 
 PACKAGECONFIG[wayland] = 
"-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe 
wpebackend-fdo wayland-native"
@@ -70,6 +71,8 @@ PACKAGECONFIG[openjpeg] = 
"-DUSE_OPENJPEG=ON,-DUSE_OPENJPEG=OFF,openjpeg"
 PACKAGECONFIG[systemd] = "-DUSE_SYSTEMD=ON,-DUSE_SYSTEMD=off,systemd"
 PACKAGECONFIG[reduce-size] = 
"-DCMAKE_BUILD_TYPE=MinSizeRel,-DCMAKE_BUILD_TYPE=Release,,"
 PACKAGECONFIG[lcms] = "-DUSE_LCMS=ON,-DUSE_LCMS=OFF,lcms"
+PACKAGECONFIG[soup2] = "-DUSE_SOUP2=ON,-DUSE_SOUP2=OFF,libsoup-2.4,,,soup3"
+PACKAGECONFIG[soup3] = ",,libsoup,,,soup2"
 
 # webkitgtk is full of /usr/bin/env python, particular for generating docs
 do_configure[postfuncs] += "setup_python_link"
@@ -124,7 +127,7 @@ EXTRA_OECMAKE:append:x86-x32 = " -DENABLE_JIT=OFF "
 SECURITY_CFLAGS:remove:aarch64 = "-fpie"
 SECURITY_CFLAGS:append:aarch64 = " -fPIE"
 
-FILES:${PN} += 
"${libdir}/webkit2gtk-4.1/injected-bundle/libwebkit2gtkinjectedbundle.so"
+FILES:${PN} += 
"${libdir}/webkit2gtk-4.*/injected-bundle/libwebkit2gtkinjectedbundle.so"
 
 RRECOMMENDS:${PN} += "ca-certificates shared-mime-info"
 
-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159546): 
https://lists.openembedded.org/g/openembedded-core/message/159546
Mute This Topic: https://lists.openembedded.org/mt/87638358/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] kmscube: fix build on OpenGL ES 3 dependencies not providing GLES3/gl3ext.h

[Quentin Schulz]

On Fri, Dec 10, 2021 at 04:09:28PM +0100, Quentin Schulz wrote:
> According to Khronos documentation[1], gl2ext.h can be used for OpenGL
> ES 3. Some vendor implementation of OpenGL ES 3, such as
> Rockchip's libmali[2], do not have a gl3ext.h but only a gl2ext.h while
> being OpenGL ES 3 compliant.
> 
> This fixes the header files to be included from gl3ext.h to gl2ext.h to
> be compatible with (hopefully) all OpenGL ES 3 implementations.
> 
> [1] https://www.khronos.org/registry/OpenGL/index_es.php#headers
> [2] https://github.com/rockchip-linux/libmali
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  ...ator-Use-correct-GL-extension-header.patch | 33 +++
>  meta/recipes-graphics/kmscube/kmscube_git.bb  |  1 +
>  2 files changed, 34 insertions(+)
>  create mode 100644 
> meta/recipes-graphics/kmscube/0001-texturator-Use-correct-GL-extension-header.patch
> 
> diff --git 
> a/meta/recipes-graphics/kmscube/0001-texturator-Use-correct-GL-extension-header.patch
>  
> b/meta/recipes-graphics/kmscube/0001-texturator-Use-correct-GL-extension-header.patch
> new file mode 100644
> index 00..5965782de7
> --- /dev/null
> +++ 
> b/meta/recipes-graphics/kmscube/0001-texturator-Use-correct-GL-extension-header.patch

Wrong path here, forgot to run a build before sending the patch, will
send a v2 sometime soon but reviews welcome anyway :)

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159545): 
https://lists.openembedded.org/g/openembedded-core/message/159545
Mute This Topic: https://lists.openembedded.org/mt/87637669/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 01/10] libtool: don't prefix the installed binary

[Khem Raj]

On Fri, Dec 10, 2021 at 6:22 AM Ross Burton  wrote:

> Typically libtool installs the binary to 'libtool' in the source tree,
> but we've got patches to rename this to ${host_sys}-libtool. As this
> isn't standard any upstream that don't respect the LIBTOOL variable need
> to be told explicitly where libtool is, which is a long-term maintenance
> burden for us on top of the initial libtool patches.
>
> The reasoning for this renaming appears to stem from the design to be
> sure that we're using our new/patched libtool and not the host's binary.
> However, now that we have HOSTTOOLS, there's no way to run the host
> libtool so this argument is moot.
>
> This patch removes the libtool renaming, follow-up patches remove the
> required modifications from the rest of the recipes.
>

Does it mean that it can now run original libtool script accidentally which
is pregenerated part of package which may be not what we want


> Signed-off-by: Ross Burton 
> ---
>  .../libtool/libtool-cross_2.4.6.bb| 11 ++-
>  .../libtool/libtool-native_2.4.6.bb   |  4 +-
>  .../libtool/libtool/prefix.patch  | 98 ---
>  .../libtool/nativesdk-libtool_2.4.6.bb|  6 +-
>  4 files changed, 11 insertions(+), 108 deletions(-)
>  delete mode 100644 meta/recipes-devtools/libtool/libtool/prefix.patch
>
> diff --git a/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
> b/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
> index 4a43867b3ec..4448373afc4 100644
> --- a/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
> +++ b/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
> @@ -1,7 +1,7 @@
>  require libtool-${PV}.inc
>
>  PACKAGES = ""
> -SRC_URI += "file://prefix.patch"
> +#SRC_URI += "file://prefix.patch"
>  SRC_URI += "file://fixinstall.patch"
>
>  datadir = "${STAGING_DIR_TARGET}${target_datadir}"
> @@ -22,15 +22,16 @@ do_configure:prepend () {
>  # Find references to LTCC="ccache xxx-gcc" and CC="ccache xxx-gcc"
>  #
>  do_install () {
> +   ln -s false ${D}
> install -d ${D}${bindir_crossscripts}/
> -   install -m 0755 ${HOST_SYS}-libtool
> ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
> +   install -m 0755 libtool ${D}${bindir_crossscripts}/libtool
> sed -e 's@^\(predep_objects="\).*@\1"@' \
> -e 's@^\(postdep_objects="\).*@\1"@' \
> -e 's@^CC="ccache.@CC="@' \
> -e 's@^LTCC="ccache.@LTCC="@' \
> -   -i ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
> -   sed -i '/^archive_cmds=/s/\-nostdlib//g'
> ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
> -   sed -i '/^archive_expsym_cmds=/s/\-nostdlib//g'
> ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
> +   -i ${D}${bindir_crossscripts}/libtool
> +   sed -i '/^archive_cmds=/s/\-nostdlib//g'
> ${D}${bindir_crossscripts}/libtool
> +   sed -i '/^archive_expsym_cmds=/s/\-nostdlib//g'
> ${D}${bindir_crossscripts}/libtool
> GREP='/bin/grep' SED='sed' ${S}/build-aux/inline-source libtoolize
> > ${D}${bindir_crossscripts}/libtoolize
> chmod 0755 ${D}${bindir_crossscripts}/libtoolize
> install -d ${D}${target_datadir}/libtool/build-aux/
> diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
> b/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
> index 3b20ce3e69f..c68527f2609 100644
> --- a/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
> +++ b/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
> @@ -2,7 +2,7 @@ require libtool-${PV}.inc
>
>  DEPENDS = ""
>
> -SRC_URI += "file://prefix.patch"
> +#SRC_URI += "file://prefix.patch"
>
>  inherit native
>
> @@ -18,5 +18,5 @@ do_configure:prepend () {
>  do_install () {
> autotools_do_install
> install -d ${D}${bindir}/
> -   install -m 0755 ${HOST_SYS}-libtool
> ${D}${bindir}/${HOST_SYS}-libtool
> +   install -m 0755 libtool ${D}${bindir}/libtool
>  }
> diff --git a/meta/recipes-devtools/libtool/libtool/prefix.patch
> b/meta/recipes-devtools/libtool/libtool/prefix.patch
> deleted file mode 100644
> index a73df2e4a7a..000
> --- a/meta/recipes-devtools/libtool/libtool/prefix.patch
> +++ /dev/null
> @@ -1,98 +0,0 @@
> -Upstream-Status: Inappropriate [embedded specific]
> -
> -Renames "libtool" -> "${TARGET_PREFIX}libtool" which makes sure
> -it can't be confused with the host libtool.
> -
> -Originally by: RP
> -
> -Updated: Date: 2010/06/28
> -Nitin A Kamble 
> -
> -It also adjusts libtool so that the header at the script is used for
> -script execution and not thevalue of $SHELL. This is because many
> -Makefiles change $SHELL so dash can get used to execute what is
> -otherwise configured as a bash shell script. Since we don't need to
> -execute scipts this way on any system I'm aware of us building upon,
> -the simplest fix is just to remove $SHELL.
> -
> -Updated: Date: 2011/11/09
> -RP
> -
> -Updated by: Robert Yang 
> -
> -diff --git a/Makefile.am b/Makefile.am
>  a/Makefile.am
> -+++ b/Makefile.am
> -@@ 

[OE-core] [PATCH 1/3] kmscube: fix build on OpenGL ES 3 dependencies not providing GLES3/gl3ext.h

[Quentin Schulz]

According to Khronos documentation[1], gl2ext.h can be used for OpenGL
ES 3. Some vendor implementation of OpenGL ES 3, such as
Rockchip's libmali[2], do not have a gl3ext.h but only a gl2ext.h while
being OpenGL ES 3 compliant.

This fixes the header files to be included from gl3ext.h to gl2ext.h to
be compatible with (hopefully) all OpenGL ES 3 implementations.

[1] https://www.khronos.org/registry/OpenGL/index_es.php#headers
[2] https://github.com/rockchip-linux/libmali

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 ...ator-Use-correct-GL-extension-header.patch | 33 +++
 meta/recipes-graphics/kmscube/kmscube_git.bb  |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-graphics/kmscube/0001-texturator-Use-correct-GL-extension-header.patch

diff --git 
a/meta/recipes-graphics/kmscube/0001-texturator-Use-correct-GL-extension-header.patch
 
b/meta/recipes-graphics/kmscube/0001-texturator-Use-correct-GL-extension-header.patch
new file mode 100644
index 00..5965782de7
--- /dev/null
+++ 
b/meta/recipes-graphics/kmscube/0001-texturator-Use-correct-GL-extension-header.patch
@@ -0,0 +1,33 @@
+From 2b74e0e32235f6ab2e3e42d53dea985a7ba6227f Mon Sep 17 00:00:00 2001
+From: Damian Hobson-Garcia 
+Date: Wed, 16 Dec 2020 11:08:25 +0900
+Subject: [PATCH] texturator: Use correct GL extension header
+
+gl2ext.h is the extenstion header for OpenGL ES 2.0 and all later
+versions according to the Khronos documentation [1].  gl3ext.h is either
+an empty stub, or may not even exist on some platforms.
+
+[1]: https://www.khronos.org/registry/OpenGL/index_es.php#headers
+
+Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/mesa/kmscube/-/merge_requests/26]
+Signed-off-by: Quentin Schulz 
+---
+ texturator.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/texturator.c b/texturator.c
+index d9335d7..6d97856 100644
+--- a/texturator.c
 b/texturator.c
+@@ -30,7 +30,7 @@
+ #include 
+ 
+ #include 
+-#include 
++#include 
+ 
+ #ifdef HAVE_LIBPNG
+ #include 
+-- 
+2.33.1
+
diff --git a/meta/recipes-graphics/kmscube/kmscube_git.bb 
b/meta/recipes-graphics/kmscube/kmscube_git.bb
index f4e6cd41e7..efaa962704 100644
--- a/meta/recipes-graphics/kmscube/kmscube_git.bb
+++ b/meta/recipes-graphics/kmscube/kmscube_git.bb
@@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = 
"file://kmscube.c;beginline=1;endline=23;md5=8b309d4ee67b7315
 
 SRCREV = "9f63f359fab1b5d8e862508e4e51c9dfe339ccb0"
 SRC_URI = 
"git://gitlab.freedesktop.org/mesa/kmscube;branch=master;protocol=https"
+SRC_URI += "file://0001-texturator-Use-correct-GL-extension-header.patch"
 UPSTREAM_CHECK_COMMITS = "1"
 
 S = "${WORKDIR}/git"
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159541): 
https://lists.openembedded.org/g/openembedded-core/message/159541
Mute This Topic: https://lists.openembedded.org/mt/87637669/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/3] kmscube: add build dependency on virtual/libgles3

[Quentin Schulz]

texturator requires GLES 3 headers and libs so let's explicit this
dependency. This was not detected until now because mesa, the default
provider, actually provides both Open GLES 2 and 3 compliant
implementations.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 meta/recipes-graphics/kmscube/kmscube_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/kmscube/kmscube_git.bb 
b/meta/recipes-graphics/kmscube/kmscube_git.bb
index efaa962704..54993be89e 100644
--- a/meta/recipes-graphics/kmscube/kmscube_git.bb
+++ b/meta/recipes-graphics/kmscube/kmscube_git.bb
@@ -6,7 +6,7 @@ OpenGL or OpenGL ES."
 HOMEPAGE = "https://cgit.freedesktop.org/mesa/kmscube/;
 LICENSE = "MIT"
 SECTION = "graphics"
-DEPENDS = "virtual/libgles2 virtual/egl libdrm"
+DEPENDS = "virtual/libgles3 virtual/libgles2 virtual/egl libdrm"
 
 LIC_FILES_CHKSUM = 
"file://kmscube.c;beginline=1;endline=23;md5=8b309d4ee67b7315ff7381270dd631fb"
 
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159543): 
https://lists.openembedded.org/g/openembedded-core/message/159543
Mute This Topic: https://lists.openembedded.org/mt/87637671/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/3] mesa: PROVIDES virtual/libgles3

[Quentin Schulz]

It's assumed that not all OpenGL ES implementation are compliant with
the 3.x specification. Therefore an additional virtual providers is
created to explicit compatibility with OpenGL ES 3 specification.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 meta/conf/distro/include/default-providers.inc | 1 +
 meta/conf/machine/include/qemu.inc | 1 +
 meta/conf/machine/qemux86-64.conf  | 1 +
 meta/conf/machine/qemux86.conf | 1 +
 meta/recipes-graphics/mesa/mesa.inc| 2 +-
 5 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/default-providers.inc 
b/meta/conf/distro/include/default-providers.inc
index ea88bd4876..6defdca12d 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -9,6 +9,7 @@ PREFERRED_PROVIDER_virtual/libgl-native ?= "mesa-native"
 PREFERRED_PROVIDER_virtual/nativesdk-libgl ?= "nativesdk-mesa"
 PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa"
+PREFERRED_PROVIDER_virtual/libgles3 ?= "mesa"
 PREFERRED_PROVIDER_virtual/mesa ?= "mesa"
 PREFERRED_PROVIDER_virtual/update-alternatives ?= "opkg-utils"
 PREFERRED_PROVIDER_virtual/update-alternatives-native ?= "opkg-utils-native"
diff --git a/meta/conf/machine/include/qemu.inc 
b/meta/conf/machine/include/qemu.inc
index 642c322abc..0d71bcbbad 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -3,6 +3,7 @@ PREFERRED_PROVIDER_virtual/egl ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa"
+PREFERRED_PROVIDER_virtual/libgles3 ?= "mesa"
 
 XSERVER ?= "xserver-xorg \
 ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'mesa-driver-swrast xserver-xorg-extension-glx', '', d)} \
diff --git a/meta/conf/machine/qemux86-64.conf 
b/meta/conf/machine/qemux86-64.conf
index 978334d5bb..901353499c 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -6,6 +6,7 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa"
+PREFERRED_PROVIDER_virtual/libgles3 ?= "mesa"
 
 require conf/machine/include/qemu.inc
 DEFAULTTUNE ?= "core2-64"
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index ad7f6e0ee4..1e072e1ae2 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -6,6 +6,7 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa"
+PREFERRED_PROVIDER_virtual/libgles3 ?= "mesa"
 
 require conf/machine/include/qemu.inc
 DEFAULTTUNE ?= "core2-32"
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index c894c2dab5..6d6fc607f9 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -39,7 +39,7 @@ DEPENDS = "expat makedepend-native flex-native bison-native 
libxml2-native zlib
 EXTRANATIVEPATH += "chrpath-native"
 PROVIDES = " \
 ${@bb.utils.contains('PACKAGECONFIG', 'opengl', 'virtual/libgl', '', d)} \
-${@bb.utils.contains('PACKAGECONFIG', 'gles', 'virtual/libgles1 
virtual/libgles2', '', d)} \
+${@bb.utils.contains('PACKAGECONFIG', 'gles', 'virtual/libgles1 
virtual/libgles2 virtual/libgles3', '', d)} \
 ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'virtual/egl', '', d)} \
 ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'virtual/libgbm', '', d)} \
 virtual/mesa \
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159542): 
https://lists.openembedded.org/g/openembedded-core/message/159542
Mute This Topic: https://lists.openembedded.org/mt/87637670/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] libva: move wayland PACKAGECONFIG to libva.inc

[Alexander Kanavin]

Can you try this on a plain poky and try to figure out why the problem is
not seen on poky?

Alex

On Fri, 10 Dec 2021 at 15:33, Markus Volk  wrote:

> Thats strange indeed. Wayland is set as a DISTRO_FEATURE for my image, so
> it gets built by a lot of packages. This wasn't a clean build, i had
> sstate cache availbale when i started to experiment with libva and normally
> it doesn't get  built inside my image because i can't use it on my board.
> First i did 'bitbake libva' and this succeeded. Second i added 'va'
> PACKAGECONFIG to a mesa.bbappend and started rebuilding the image. Now the
> build for libva-initial was started and failed with the error about missing
> wayland-scanner.
>
> I also wondered what is pulling  wayland into  its sysroot . Did 'bitbake
> -c cleanstate libva-initial libva' and tried to build libva-initial again
> with 'bitbake libva-initial' and had the same issue. On my machine this is
> reproducible
>
> Markus
> Am 10.12.21 um 15:06 schrieb Alexander Kanavin:
>
> | Run-time dependency wayland-client found: YES 1.19.0
>
> Can you please explain how the issue can be reproduced? I find it odd that
> libva-initial (which only needs libdrm, and is required by mesa) has
> wayland in its sysroot in your build - where does that come from? There's a
> chance the problem is elsewhere.
>
> Alex
>
> On Fri, 10 Dec 2021 at 15:03, Markus Volk  wrote:
>
>> I encountered an error while trying to build libva under wayland.
>> libva-initial
>> was missing wayland-native dependency and failed like this:
>>
>> | Run-time dependency xfixes found: NO (tried pkgconfig and cmake)
>> | Run-time dependency wayland-client found: YES 1.19.0
>> | Program wayland-scanner /usr/bin/wayland-scanner found: NO
>> |
>> | ../libva-2.13.0/meson.build:107:4: ERROR: Program 'wayland-scanner
>> /usr/bin/wayland-scanner' not found
>> |
>> | A full log can be found at
>> /home/flk/build/poky/build-rock/tmp/work/cortexa72-cortexa53-crypto-poky-linux/libva-initial/2.13.0-r0/build/meson-logs/meson-log.txt
>> | ERROR: meson failed
>> | WARNING: exit code 1 from a shell command.
>>
>> This commit moves the PACKAGECONFIG[wayland] to libva.inc to make it
>> available to libva-initial also
>>
>> Signed-off-by: MarkusVolk 
>> ---
>>  meta/recipes-graphics/libva/libva.inc   | 7 +++
>>  meta/recipes-graphics/libva/libva_2.13.0.bb | 4 +---
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/recipes-graphics/libva/libva.inc
>> b/meta/recipes-graphics/libva/libva.inc
>> index bcf9757c1a..0e2721e291 100644
>> --- a/meta/recipes-graphics/libva/libva.inc
>> +++ b/meta/recipes-graphics/libva/libva.inc
>> @@ -27,3 +27,10 @@ UPSTREAM_CHECK_URI = "
>> https://github.com/intel/libva/releases;
>>  DEPENDS = "libdrm"
>>
>>  inherit meson pkgconfig
>> +
>> +PACKAGECONFIG:append = " \
>> +${@bb.utils.filter('DISTRO_FEATURES', 'wayland', d)} \
>> +"
>> +
>> +PACKAGECONFIG[wayland] =
>> "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native wayland"
>> +
>> diff --git a/meta/recipes-graphics/libva/libva_2.13.0.bb
>> b/meta/recipes-graphics/libva/libva_2.13.0.bb
>> index ed2be289fc..a8c6355b01 100644
>> --- a/meta/recipes-graphics/libva/libva_2.13.0.bb
>> +++ b/meta/recipes-graphics/libva/libva_2.13.0.bb
>> @@ -2,14 +2,12 @@ require libva.inc
>>
>>  PACKAGECONFIG ??= " \
>>  ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', '', d)}
>> \
>> -${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)} \
>> +${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} \
>>  "
>>
>>  PACKAGECONFIG[x11] = "-Dwith_x11=yes,-Dwith_x11=no,virtual/libx11
>> libxext libxfixes"
>>  PACKAGECONFIG[glx] = "-Dwith_glx=yes,-Dwith_glx=no,virtual/mesa"
>>
>> -PACKAGECONFIG[wayland] =
>> "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native wayland"
>> -
>>  PACKAGES =+ "${PN}-x11 ${PN}-glx ${PN}-wayland"
>>
>>  RDEPENDS:${PN}-x11 =+ "${PN}"
>> --
>> 2.25.1
>>
>>
>>
>>
>>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159540): 
https://lists.openembedded.org/g/openembedded-core/message/159540
Mute This Topic: https://lists.openembedded.org/mt/87636241/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] libva: move wayland PACKAGECONFIG to libva.inc

[Markus Volk]

Thats strange indeed. Wayland is set as a DISTRO_FEATURE for my image, 
so it gets built by a lot ofpackages. This wasn't a clean build, i had 
sstate cache availbale when i started to experiment with libva and 
normally it doesn't get  built inside my image because i can't use it on 
my board. First i did 'bitbake libva' and this succeeded. Second i added 
'va' PACKAGECONFIG to a mesa.bbappend and started rebuilding the image. 
Now the build for libva-initial was started and failed with the error 
about missing wayland-scanner.


I also wondered what is pulling wayland into  its sysroot . Did 'bitbake 
-c cleanstate libva-initial libva' and tried to build libva-initial 
again with 'bitbake libva-initial' and had the same issue. On my machine 
this is reproducible


Markus

Am 10.12.21 um 15:06 schrieb Alexander Kanavin:

| Run-time dependency wayland-client found: YES 1.19.0

Can you please explain how the issue can be reproduced? I find it odd 
that libva-initial (which only needs libdrm, and is required by mesa) 
has wayland in its sysroot in your build - where does that come from? 
There's a chance the problem is elsewhere.


Alex

On Fri, 10 Dec 2021 at 15:03, Markus Volk > wrote:


I encountered an error while trying to build libva under wayland.
libva-initial
was missing wayland-native dependency and failed like this:

| Run-time dependency xfixes found: NO (tried pkgconfig and cmake)
| Run-time dependency wayland-client found: YES 1.19.0
| Program wayland-scanner /usr/bin/wayland-scanner found: NO
|
| ../libva-2.13.0/meson.build:107:4: ERROR: Program
'wayland-scanner /usr/bin/wayland-scanner' not found
|
| A full log can be found at

/home/flk/build/poky/build-rock/tmp/work/cortexa72-cortexa53-crypto-poky-linux/libva-initial/2.13.0-r0/build/meson-logs/meson-log.txt
| ERROR: meson failed
| WARNING: exit code 1 from a shell command.

This commit moves the PACKAGECONFIG[wayland] to libva.inc to make
it available to libva-initial also

Signed-off-by: MarkusVolk mailto:f_...@t-online.de>>
---
 meta/recipes-graphics/libva/libva.inc       | 7 +++
 meta/recipes-graphics/libva/libva_2.13.0.bb
 | 4 +---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/libva/libva.inc
b/meta/recipes-graphics/libva/libva.inc
index bcf9757c1a..0e2721e291 100644
--- a/meta/recipes-graphics/libva/libva.inc
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -27,3 +27,10 @@ UPSTREAM_CHECK_URI =
"https://github.com/intel/libva/releases
"
 DEPENDS = "libdrm"

 inherit meson pkgconfig
+
+PACKAGECONFIG:append = " \
+    ${@bb.utils.filter('DISTRO_FEATURES', 'wayland', d)} \
+"
+
+PACKAGECONFIG[wayland] =
"-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native wayland"
+
diff --git a/meta/recipes-graphics/libva/libva_2.13.0.bb

b/meta/recipes-graphics/libva/libva_2.13.0.bb 
index ed2be289fc..a8c6355b01 100644
--- a/meta/recipes-graphics/libva/libva_2.13.0.bb

+++ b/meta/recipes-graphics/libva/libva_2.13.0.bb

@@ -2,14 +2,12 @@ require libva.inc

 PACKAGECONFIG ??= " \
     ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx',
'', d)} \
-    ${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)} \
+    ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} \
 "

 PACKAGECONFIG[x11] = "-Dwith_x11=yes,-Dwith_x11=no,virtual/libx11
libxext libxfixes"
 PACKAGECONFIG[glx] = "-Dwith_glx=yes,-Dwith_glx=no,virtual/mesa"

-PACKAGECONFIG[wayland] =
"-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native wayland"
-
 PACKAGES =+ "${PN}-x11 ${PN}-glx ${PN}-wayland"

 RDEPENDS:${PN}-x11 =+ "${PN}"
-- 
2.25.1









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159539): 
https://lists.openembedded.org/g/openembedded-core/message/159539
Mute This Topic: https://lists.openembedded.org/mt/87636241/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 01/10] libtool: don't prefix the installed binary

[Ross Burton]

Note that meta-oe-contrib:ross/libtool contains the patches needed to
get this working against meta-oe, as far as I can tell in my testing.

Ross

On Fri, 10 Dec 2021 at 14:22, Ross Burton via lists.openembedded.org
 wrote:
>
> Typically libtool installs the binary to 'libtool' in the source tree,
> but we've got patches to rename this to ${host_sys}-libtool. As this
> isn't standard any upstream that don't respect the LIBTOOL variable need
> to be told explicitly where libtool is, which is a long-term maintenance
> burden for us on top of the initial libtool patches.
>
> The reasoning for this renaming appears to stem from the design to be
> sure that we're using our new/patched libtool and not the host's binary.
> However, now that we have HOSTTOOLS, there's no way to run the host
> libtool so this argument is moot.
>
> This patch removes the libtool renaming, follow-up patches remove the
> required modifications from the rest of the recipes.
>
> Signed-off-by: Ross Burton 
> ---
>  .../libtool/libtool-cross_2.4.6.bb| 11 ++-
>  .../libtool/libtool-native_2.4.6.bb   |  4 +-
>  .../libtool/libtool/prefix.patch  | 98 ---
>  .../libtool/nativesdk-libtool_2.4.6.bb|  6 +-
>  4 files changed, 11 insertions(+), 108 deletions(-)
>  delete mode 100644 meta/recipes-devtools/libtool/libtool/prefix.patch
>
> diff --git a/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb 
> b/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
> index 4a43867b3ec..4448373afc4 100644
> --- a/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
> +++ b/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
> @@ -1,7 +1,7 @@
>  require libtool-${PV}.inc
>
>  PACKAGES = ""
> -SRC_URI += "file://prefix.patch"
> +#SRC_URI += "file://prefix.patch"
>  SRC_URI += "file://fixinstall.patch"
>
>  datadir = "${STAGING_DIR_TARGET}${target_datadir}"
> @@ -22,15 +22,16 @@ do_configure:prepend () {
>  # Find references to LTCC="ccache xxx-gcc" and CC="ccache xxx-gcc"
>  #
>  do_install () {
> +   ln -s false ${D}
> install -d ${D}${bindir_crossscripts}/
> -   install -m 0755 ${HOST_SYS}-libtool 
> ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
> +   install -m 0755 libtool ${D}${bindir_crossscripts}/libtool
> sed -e 's@^\(predep_objects="\).*@\1"@' \
> -e 's@^\(postdep_objects="\).*@\1"@' \
> -e 's@^CC="ccache.@CC="@' \
> -e 's@^LTCC="ccache.@LTCC="@' \
> -   -i ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
> -   sed -i '/^archive_cmds=/s/\-nostdlib//g' 
> ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
> -   sed -i '/^archive_expsym_cmds=/s/\-nostdlib//g' 
> ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
> +   -i ${D}${bindir_crossscripts}/libtool
> +   sed -i '/^archive_cmds=/s/\-nostdlib//g' 
> ${D}${bindir_crossscripts}/libtool
> +   sed -i '/^archive_expsym_cmds=/s/\-nostdlib//g' 
> ${D}${bindir_crossscripts}/libtool
> GREP='/bin/grep' SED='sed' ${S}/build-aux/inline-source libtoolize > 
> ${D}${bindir_crossscripts}/libtoolize
> chmod 0755 ${D}${bindir_crossscripts}/libtoolize
> install -d ${D}${target_datadir}/libtool/build-aux/
> diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb 
> b/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
> index 3b20ce3e69f..c68527f2609 100644
> --- a/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
> +++ b/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
> @@ -2,7 +2,7 @@ require libtool-${PV}.inc
>
>  DEPENDS = ""
>
> -SRC_URI += "file://prefix.patch"
> +#SRC_URI += "file://prefix.patch"
>
>  inherit native
>
> @@ -18,5 +18,5 @@ do_configure:prepend () {
>  do_install () {
> autotools_do_install
> install -d ${D}${bindir}/
> -   install -m 0755 ${HOST_SYS}-libtool ${D}${bindir}/${HOST_SYS}-libtool
> +   install -m 0755 libtool ${D}${bindir}/libtool
>  }
> diff --git a/meta/recipes-devtools/libtool/libtool/prefix.patch 
> b/meta/recipes-devtools/libtool/libtool/prefix.patch
> deleted file mode 100644
> index a73df2e4a7a..000
> --- a/meta/recipes-devtools/libtool/libtool/prefix.patch
> +++ /dev/null
> @@ -1,98 +0,0 @@
> -Upstream-Status: Inappropriate [embedded specific]
> -
> -Renames "libtool" -> "${TARGET_PREFIX}libtool" which makes sure
> -it can't be confused with the host libtool.
> -
> -Originally by: RP
> -
> -Updated: Date: 2010/06/28
> -Nitin A Kamble 
> -
> -It also adjusts libtool so that the header at the script is used for
> -script execution and not thevalue of $SHELL. This is because many
> -Makefiles change $SHELL so dash can get used to execute what is
> -otherwise configured as a bash shell script. Since we don't need to
> -execute scipts this way on any system I'm aware of us building upon,
> -the simplest fix is just to remove $SHELL.
> -
> -Updated: Date: 2011/11/09
> -RP
> -
> -Updated by: Robert Yang 
> -
> -diff --git a/Makefile.am b/Makefile.am
>  

[OE-core] [RFC PATCH 09/10] subversion: remove obsolete support for renamed libtool

[Ross Burton]

libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.

Signed-off-by: Ross Burton 
---
 ...001-Fix-libtool-name-in-configure.ac.patch | 29 ---
 .../subversion/subversion_1.14.1.bb   |  1 -
 2 files changed, 30 deletions(-)
 delete mode 100644 
meta/recipes-devtools/subversion/subversion/0001-Fix-libtool-name-in-configure.ac.patch

diff --git 
a/meta/recipes-devtools/subversion/subversion/0001-Fix-libtool-name-in-configure.ac.patch
 
b/meta/recipes-devtools/subversion/subversion/0001-Fix-libtool-name-in-configure.ac.patch
deleted file mode 100644
index 5a1b10b2e11..000
--- 
a/meta/recipes-devtools/subversion/subversion/0001-Fix-libtool-name-in-configure.ac.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From cbcfe0399347989e45a8fb695f55c855d6b3da72 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin 
-Date: Mon, 7 Dec 2015 17:11:02 +0200
-Subject: [PATCH] Fix libtool name in configure.ac
-
-Upstream-Status: Inappropriate [embedded specific]
-Signed-off-by: Alexander Kanavin 

- configure.ac | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 4ed66d4..ceb64f9 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -221,8 +221,8 @@ if test "$experimental_libtool" = "yes"; then
-   LIBTOOL="$sh_libtool"
-   SVN_LIBTOOL="$sh_libtool"
- else
--  sh_libtool="$abs_builddir/libtool"
--  SVN_LIBTOOL="\$(SHELL) \"$sh_libtool\""
-+  sh_libtool="$abs_builddir/$host_alias-libtool"
-+  SVN_LIBTOOL="\$(SHELL) \$(abs_builddir)/$host_alias-libtool"
- fi
- AC_SUBST(SVN_LIBTOOL)
- 
--- 
-2.6.2
-
diff --git a/meta/recipes-devtools/subversion/subversion_1.14.1.bb 
b/meta/recipes-devtools/subversion/subversion_1.14.1.bb
index 87dc359439c..a0a9376f3de 100644
--- a/meta/recipes-devtools/subversion/subversion_1.14.1.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.14.1.bb
@@ -10,7 +10,6 @@ DEPENDS:append:class-native = " file-replacement-native"
 
 SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://disable_macos.patch \
-   file://0001-Fix-libtool-name-in-configure.ac.patch \
file://serfmacro.patch \
"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159536): 
https://lists.openembedded.org/g/openembedded-core/message/159536
Mute This Topic: https://lists.openembedded.org/mt/87636637/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 07/10] apr: remove obsolete support for renamed libtool

[Ross Burton]

libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.

This means that apr now installs libtool into the build-1 folder, but
as this has never been needed before (as we use the system libtool) we
can remove it (it contains build paths so is unreproducible).  Also add
a RDEPENDS on libtool for the target -dev package.

Signed-off-by: Ross Burton 
---
 meta/recipes-support/apr/apr_1.7.0.bb | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-support/apr/apr_1.7.0.bb 
b/meta/recipes-support/apr/apr_1.7.0.bb
index 5f8fd6a4618..9c826d43807 100644
--- a/meta/recipes-support/apr/apr_1.7.0.bb
+++ b/meta/recipes-support/apr/apr_1.7.0.bb
@@ -63,7 +63,7 @@ MULTILIB_SCRIPTS = "${PN}-dev:${bindir}/apr-1-config \
 ${PN}-dev:${datadir}/build-1/apr_rules.mk"
 
 FILES:${PN}-dev += "${libdir}/apr.exp ${datadir}/build-1/*"
-RDEPENDS:${PN}-dev += "bash"
+RDEPENDS:${PN}-dev += "bash libtool"
 
 RDEPENDS:${PN}-ptest += "libgcc"
 
@@ -80,6 +80,8 @@ do_install:append() {
 }
 
 do_install:append:class-target() {
+   rm -f ${D}${datadir}/build-1/libtool
+   sed -i s,LIBTOOL=.*,LIBTOOL=libtool,g 
${D}${datadir}/build-1/apr_rules.mk
sed -i -e 's,${DEBUG_PREFIX_MAP},,g' \
   -e 's,${STAGING_DIR_HOST},,g' ${D}${datadir}/build-1/apr_rules.mk
sed -i -e 's,${STAGING_DIR_HOST},,g' \
@@ -97,12 +99,12 @@ apr_sysroot_preprocess () {
cp ${S}/build/apr_rules.mk $d/
sed -i s,apr_builddir=.*,apr_builddir=,g $d/apr_rules.mk
sed -i s,apr_builders=.*,apr_builders=,g $d/apr_rules.mk
-   sed -i s,LIBTOOL=.*,LIBTOOL=${HOST_SYS}-libtool,g $d/apr_rules.mk
+   sed -i s,LIBTOOL=.*,LIBTOOL=libtool,g $d/apr_rules.mk
sed -i s,\$\(apr_builders\),${STAGING_DATADIR}/apr/,g $d/apr_rules.mk
cp ${S}/build/mkdir.sh $d/
cp ${S}/build/make_exports.awk $d/
cp ${S}/build/make_var_export.awk $d/
-   cp ${S}/${HOST_SYS}-libtool ${SYSROOT_DESTDIR}${datadir}/build-1/libtool
+   cp ${S}/libtool ${SYSROOT_DESTDIR}${datadir}/build-1/libtool
 }
 
 do_compile_ptest() {
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159534): 
https://lists.openembedded.org/g/openembedded-core/message/159534
Mute This Topic: https://lists.openembedded.org/mt/87636635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 08/10] qemu: remove obsolete support for renamed libtool

[Ross Burton]

libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/qemu/qemu.inc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index ea7dfaecef8..fe35f94acf7 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -98,8 +98,6 @@ EXTRA_OECONF = " \
 ${PACKAGECONFIG_CONFARGS} \
 "
 
-export LIBTOOL="${HOST_SYS}-libtool"
-
 B = "${WORKDIR}/build"
 
 #EXTRA_OECONF:append = " --python=${HOSTTOOLS_DIR}/python3"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159535): 
https://lists.openembedded.org/g/openembedded-core/message/159535
Mute This Topic: https://lists.openembedded.org/mt/87636636/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 10/10] apmd: remove obsolete support for renamed libtool

[Ross Burton]

libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.

Signed-off-by: Ross Burton 
---
 meta/recipes-bsp/apmd/apmd/libtool.patch | 22 +++---
 meta/recipes-bsp/apmd/apmd_3.2.2-15.bb   |  2 +-
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-bsp/apmd/apmd/libtool.patch 
b/meta/recipes-bsp/apmd/apmd/libtool.patch
index 834ee080a1f..fd0a952890d 100644
--- a/meta/recipes-bsp/apmd/apmd/libtool.patch
+++ b/meta/recipes-bsp/apmd/apmd/libtool.patch
@@ -1,3 +1,8 @@
+From d5dde7ca91a5aed273d8fe269e1a5194e85c8c79 Mon Sep 17 00:00:00 2001
+From: Scott Garman 
+Date: Tue, 13 Jul 2010 16:46:46 +0800
+Subject: [PATCH] apmd: upgrade to 3.2.2-14
+
 Add by RP to address "unable to infer tagged configuration" error:
commit 35de05e61b88c0808a5e885bb0efdf420555d5ad
Author: Richard Purdie 
@@ -15,15 +20,18 @@ Upstream-Status: Pending
 
 Signed-off-by: Scott Garman 
 
-Index: apmd-3.2.2.orig/Makefile
-===
 apmd-3.2.2.orig.orig/Makefile  2004-01-04 08:13:18.0 +
-+++ apmd-3.2.2.orig/Makefile   2008-04-21 17:10:03.0 +0100
-@@ -58,9 +57,8 @@
- #CFLAGS=-O3 -m486 -fomit-frame-pointer
+---
+ Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 92fc0fd..8e283dc 100644
+--- a/Makefile
 b/Makefile
+@@ -59,8 +59,8 @@ RANLIB=ranlib
  #LDFLAGS=-s
  
--LIBTOOL=libtool --quiet
+ LIBTOOL=libtool --quiet
 -LT_COMPILE = $(LIBTOOL) --mode=compile $(CC)
 -LT_LINK = $(LIBTOOL) --mode=link $(CC)
 +LT_COMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CC)
diff --git a/meta/recipes-bsp/apmd/apmd_3.2.2-15.bb 
b/meta/recipes-bsp/apmd/apmd_3.2.2-15.bb
index da17e5a2350..1779e8b2a03 100644
--- a/meta/recipes-bsp/apmd/apmd_3.2.2-15.bb
+++ b/meta/recipes-bsp/apmd/apmd_3.2.2-15.bb
@@ -43,7 +43,7 @@ EXTRA_OEMAKE = "-e MAKEFLAGS="
 
 do_compile() {
# apmd doesn't use whole autotools. Just libtool for installation
-   oe_runmake "LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool" apm 
apmd
+   oe_runmake apm apmd
 }
 
 do_install() {
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159537): 
https://lists.openembedded.org/g/openembedded-core/message/159537
Mute This Topic: https://lists.openembedded.org/mt/87636638/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 06/10] freetype: remove obsolete support for renamed libtool

[Ross Burton]

libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.

Signed-off-by: Ross Burton 
---
 .../freetype/freetype/use-right-libtool.patch | 31 ---
 .../freetype/freetype_2.11.1.bb   |  4 +--
 2 files changed, 1 insertion(+), 34 deletions(-)
 delete mode 100644 
meta/recipes-graphics/freetype/freetype/use-right-libtool.patch

diff --git a/meta/recipes-graphics/freetype/freetype/use-right-libtool.patch 
b/meta/recipes-graphics/freetype/freetype/use-right-libtool.patch
deleted file mode 100644
index b389455f5d4..000
--- a/meta/recipes-graphics/freetype/freetype/use-right-libtool.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 50499e4482d40cff2ef05905c658ba4380e7e6fc Mon Sep 17 00:00:00 2001
-From: Ross Burton 
-Date: Thu, 7 Jan 2016 21:13:07 +
-Subject: [PATCH] freetype: enable out-of-tree builds, and use host zlib
-
-Freetype think that it knows best about where libtool is, and explicitly the
-libtool autoconf macros telling it where to find the libtool script.  Of course
-we prefix the script with the target triplet, so it's wrong.  Fix this by
-removing the forced assignment, so the configure script's knowledge of where it
-put libtool is used.
-
-Upstream-Status: Pending
-Signed-off-by: Ross Burton 
-

- builds/unix/unix-cc.in | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/builds/unix/unix-cc.in b/builds/unix/unix-cc.in
-index 89be450..72609d3 100644
 a/builds/unix/unix-cc.in
-+++ b/builds/unix/unix-cc.in
-@@ -16,7 +16,7 @@ CC   := @CC@
- COMPILER_SEP := $(SEP)
- FT_LIBTOOL_DIR ?= $(PLATFORM_DIR)
- 
--LIBTOOL := $(FT_LIBTOOL_DIR)/libtool
-+LIBTOOL := $(FT_LIBTOOL_DIR)/@LIBTOOL@ --tag CC
- 
- 
- # The object file extension (for standard and static libraries).  This can be
diff --git a/meta/recipes-graphics/freetype/freetype_2.11.1.bb 
b/meta/recipes-graphics/freetype/freetype_2.11.1.bb
index 78babdcbdb2..04b56adc6b2 100644
--- a/meta/recipes-graphics/freetype/freetype_2.11.1.bb
+++ b/meta/recipes-graphics/freetype/freetype_2.11.1.bb
@@ -12,9 +12,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE.TXT;md5=a5927784d823d443c6cae55701d01553 \
 file://docs/FTL.TXT;md5=9f37b4e6afa3fef9dba8932b16bd3f97 \
 file://docs/GPLv2.TXT;md5=8ef380476f642c20ebf40fecb0add2ec"
 
-SRC_URI = "${SAVANNAH_NONGNU_MIRROR}/${BPN}/${BP}.tar.xz \
-   file://use-right-libtool.patch \
-  "
+SRC_URI = "${SAVANNAH_NONGNU_MIRROR}/${BPN}/${BP}.tar.xz"
 SRC_URI[sha256sum] = 
"ae7cfda88429c97a7ae63b7d01ab398076c3b67182e960e5684050f2c5c8"
 
 UPSTREAM_CHECK_REGEX = "freetype-(?P\d+(\.\d+)+)"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159533): 
https://lists.openembedded.org/g/openembedded-core/message/159533
Mute This Topic: https://lists.openembedded.org/mt/87636634/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 05/10] db: remove obsolete support for renamed libtool

[Ross Burton]

libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.

Signed-off-by: Ross Burton 
---
 meta/recipes-support/db/db_5.3.28.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-support/db/db_5.3.28.bb 
b/meta/recipes-support/db/db_5.3.28.bb
index d5b788a3d78..c5427f54eb0 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -66,8 +66,6 @@ PACKAGECONFIG ??= ""
 PACKAGECONFIG[verify] = "--enable-verify, --disable-verify"
 PACKAGECONFIG[dbm] = "--enable-dbm,--disable-dbm,"
 
-EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
-
 EXTRA_AUTORECONF += "--exclude=autoheader  -I ${S}/dist/aclocal 
-I${S}/dist/aclocal_java"
 AUTOTOOLS_SCRIPT_PATH = "${S}/dist"
 
@@ -91,7 +89,7 @@ oe_runconf:prepend() {
 
 do_compile:prepend() {
 # Stop libtool adding RPATHs
-sed -i -e 's|hardcode_into_libs=yes|hardcode_into_libs=no|' 
${B}/${HOST_SYS}-libtool
+sed -i -e 's|hardcode_into_libs=yes|hardcode_into_libs=no|' ${B}/libtool
 }
 
 do_install:append() {
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159532): 
https://lists.openembedded.org/g/openembedded-core/message/159532
Mute This Topic: https://lists.openembedded.org/mt/87636632/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 01/10] libtool: don't prefix the installed binary

[Ross Burton]

Typically libtool installs the binary to 'libtool' in the source tree,
but we've got patches to rename this to ${host_sys}-libtool. As this
isn't standard any upstream that don't respect the LIBTOOL variable need
to be told explicitly where libtool is, which is a long-term maintenance
burden for us on top of the initial libtool patches.

The reasoning for this renaming appears to stem from the design to be
sure that we're using our new/patched libtool and not the host's binary.
However, now that we have HOSTTOOLS, there's no way to run the host
libtool so this argument is moot.

This patch removes the libtool renaming, follow-up patches remove the
required modifications from the rest of the recipes.

Signed-off-by: Ross Burton 
---
 .../libtool/libtool-cross_2.4.6.bb| 11 ++-
 .../libtool/libtool-native_2.4.6.bb   |  4 +-
 .../libtool/libtool/prefix.patch  | 98 ---
 .../libtool/nativesdk-libtool_2.4.6.bb|  6 +-
 4 files changed, 11 insertions(+), 108 deletions(-)
 delete mode 100644 meta/recipes-devtools/libtool/libtool/prefix.patch

diff --git a/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb 
b/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
index 4a43867b3ec..4448373afc4 100644
--- a/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
+++ b/meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb
@@ -1,7 +1,7 @@
 require libtool-${PV}.inc
 
 PACKAGES = ""
-SRC_URI += "file://prefix.patch"
+#SRC_URI += "file://prefix.patch"
 SRC_URI += "file://fixinstall.patch"
 
 datadir = "${STAGING_DIR_TARGET}${target_datadir}"
@@ -22,15 +22,16 @@ do_configure:prepend () {
 # Find references to LTCC="ccache xxx-gcc" and CC="ccache xxx-gcc"
 #
 do_install () {
+   ln -s false ${D}
install -d ${D}${bindir_crossscripts}/
-   install -m 0755 ${HOST_SYS}-libtool 
${D}${bindir_crossscripts}/${HOST_SYS}-libtool
+   install -m 0755 libtool ${D}${bindir_crossscripts}/libtool
sed -e 's@^\(predep_objects="\).*@\1"@' \
-e 's@^\(postdep_objects="\).*@\1"@' \
-e 's@^CC="ccache.@CC="@' \
-e 's@^LTCC="ccache.@LTCC="@' \
-   -i ${D}${bindir_crossscripts}/${HOST_SYS}-libtool
-   sed -i '/^archive_cmds=/s/\-nostdlib//g' 
${D}${bindir_crossscripts}/${HOST_SYS}-libtool
-   sed -i '/^archive_expsym_cmds=/s/\-nostdlib//g' 
${D}${bindir_crossscripts}/${HOST_SYS}-libtool
+   -i ${D}${bindir_crossscripts}/libtool
+   sed -i '/^archive_cmds=/s/\-nostdlib//g' 
${D}${bindir_crossscripts}/libtool
+   sed -i '/^archive_expsym_cmds=/s/\-nostdlib//g' 
${D}${bindir_crossscripts}/libtool
GREP='/bin/grep' SED='sed' ${S}/build-aux/inline-source libtoolize > 
${D}${bindir_crossscripts}/libtoolize
chmod 0755 ${D}${bindir_crossscripts}/libtoolize
install -d ${D}${target_datadir}/libtool/build-aux/
diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb 
b/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
index 3b20ce3e69f..c68527f2609 100644
--- a/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
+++ b/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb
@@ -2,7 +2,7 @@ require libtool-${PV}.inc
 
 DEPENDS = ""
 
-SRC_URI += "file://prefix.patch"
+#SRC_URI += "file://prefix.patch"
 
 inherit native
 
@@ -18,5 +18,5 @@ do_configure:prepend () {
 do_install () {
autotools_do_install
install -d ${D}${bindir}/
-   install -m 0755 ${HOST_SYS}-libtool ${D}${bindir}/${HOST_SYS}-libtool
+   install -m 0755 libtool ${D}${bindir}/libtool
 }
diff --git a/meta/recipes-devtools/libtool/libtool/prefix.patch 
b/meta/recipes-devtools/libtool/libtool/prefix.patch
deleted file mode 100644
index a73df2e4a7a..000
--- a/meta/recipes-devtools/libtool/libtool/prefix.patch
+++ /dev/null
@@ -1,98 +0,0 @@
-Upstream-Status: Inappropriate [embedded specific]
-
-Renames "libtool" -> "${TARGET_PREFIX}libtool" which makes sure
-it can't be confused with the host libtool.
-
-Originally by: RP
-
-Updated: Date: 2010/06/28
-Nitin A Kamble 
-
-It also adjusts libtool so that the header at the script is used for 
-script execution and not thevalue of $SHELL. This is because many 
-Makefiles change $SHELL so dash can get used to execute what is 
-otherwise configured as a bash shell script. Since we don't need to 
-execute scipts this way on any system I'm aware of us building upon, 
-the simplest fix is just to remove $SHELL.
-
-Updated: Date: 2011/11/09
-RP
-
-Updated by: Robert Yang 
-
-diff --git a/Makefile.am b/Makefile.am
 a/Makefile.am
-+++ b/Makefile.am
-@@ -31,7 +31,7 @@ SUBDIRS  = .
- DIST_SUBDIRS  = $(SUBDIRS)
- EXTRA_DIST=
- 
--BUILT_SOURCES = libtool libtoolize
-+BUILT_SOURCES = $(host_alias)-libtool libtoolize
- 
- CLEANFILES=
- MOSTLYCLEANFILES  =
-@@ -67,7 +67,7 @@ build_scripts= $(srcdir)/$(aux_dir)/announce-gen \
- 
- EXTRA_DIST += bootstrap bootstrap.conf 

[OE-core] [RFC PATCH 04/10] gtk+3: remove obsolete support for renamed libtool

[Ross Burton]

libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.

Signed-off-by: Ross Burton 
---
 meta/recipes-gnome/gtk+/gtk+3.inc |  3 --
 .../gtk+/gtk+3/0001-Hardcoded-libtool.patch   | 47 ---
 meta/recipes-gnome/gtk+/gtk+3_3.24.30.bb  |  1 -
 3 files changed, 51 deletions(-)
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+3/0001-Hardcoded-libtool.patch

diff --git a/meta/recipes-gnome/gtk+/gtk+3.inc 
b/meta/recipes-gnome/gtk+/gtk+3.inc
index 47cdb83dce6..4de4dcf5324 100644
--- a/meta/recipes-gnome/gtk+/gtk+3.inc
+++ b/meta/recipes-gnome/gtk+/gtk+3.inc
@@ -27,9 +27,6 @@ ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
 export PKG_CONFIG_FOR_BUILD = "${STAGING_BINDIR_NATIVE}/pkg-config-native"
 
 do_configure:prepend() {
-# Do this because the configure script is running ./libtool directly
-rm -f libtool
-ln -s ${TARGET_PREFIX}libtool libtool
 #delete a file that will get confused with generated one in ${B}
 rm -f ${S}/gtk/gtktypefuncs.c
 
diff --git a/meta/recipes-gnome/gtk+/gtk+3/0001-Hardcoded-libtool.patch 
b/meta/recipes-gnome/gtk+/gtk+3/0001-Hardcoded-libtool.patch
deleted file mode 100644
index c210bbc7d5f..000
--- a/meta/recipes-gnome/gtk+/gtk+3/0001-Hardcoded-libtool.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-From 0ecaa5bab162abf0cb2057d77beeb7b89d5873b4 Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen 
-Date: Tue, 21 Jun 2016 14:53:56 +0300
-Subject: [PATCH 1/4] Hardcoded libtool
-
-Upstream-Status: Inappropriate [embedded specific]
-
-Signed-off-by: Marko Lindqvist 
-Signed-off-by: Jussi Kukkonen 

- configure.ac | 6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 6628e21..f43ac09 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -617,7 +617,7 @@ AC_MSG_CHECKING([whether to write dependencies into .pc 
files])
- case $enable_explicit_deps in
-   auto)
- export SED
--deplibs_check_method=`(./libtool --config; echo 'eval echo 
\"$deplibs_check_method\"') | sh`
-+deplibs_check_method=`(./$host_alias-libtool --config; echo 'eval echo 
\"$deplibs_check_method\"') | sh`
- if test "x$deplibs_check_method" != xpass_all || test "x$enable_static" = 
xyes ; then
-   enable_explicit_deps=yes
- else
-@@ -895,7 +895,7 @@ else
- dnl Now we check to see if our libtool supports shared lib deps
- dnl (in a rather ugly way even)
- if $dynworks; then
--module_libtool_config="${CONFIG_SHELL-/bin/sh} ./libtool --config"
-+module_libtool_config="${CONFIG_SHELL-/bin/sh} ./$host_alias-libtool 
--config"
- module_deplibs_check=`$module_libtool_config | \
- grep '^[[a-z_]]*check[[a-z_]]*_method=[['\''"]]' | \
- sed 's/.*[['\''"]]\(.*\)[['\''"]]$/\1/'`
-@@ -1649,7 +1649,7 @@ AC_SUBST(GTK_PRINT_BACKENDS)
- # We are using gmodule-no-export now, but I'm leaving the stripping
- # code in place for now, since pango and atk still require gmodule.
- export SED
--export_dynamic=`(./libtool --config; echo eval echo 
\\$export_dynamic_flag_spec) | sh`
-+export_dynamic=`(./$host_alias-libtool --config; echo eval echo 
\\$export_dynamic_flag_spec) | sh`
- if test -n "$export_dynamic"; then
-   GDK_DEP_LIBS=`echo $GDK_DEP_LIBS | sed -e "s/$export_dynamic//"`
-   GTK_DEP_LIBS=`echo $GTK_DEP_LIBS | sed -e "s/$export_dynamic//"`
--- 
-2.12.0
-
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.24.30.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.24.30.bb
index 7e7566f9af9..3de5b588eba 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.24.30.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.24.30.bb
@@ -3,7 +3,6 @@ require gtk+3.inc
 MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 
 SRC_URI = 
"http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz \
-   file://0001-Hardcoded-libtool.patch \
file://0002-Do-not-try-to-initialize-GL-without-libGL.patch \
file://0003-Add-disable-opengl-configure-option.patch \
file://link_fribidi.patch \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159531): 
https://lists.openembedded.org/g/openembedded-core/message/159531
Mute This Topic: https://lists.openembedded.org/mt/87636631/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 03/10] pkgconfig: remove obsolete support for renamed libtool

[Ross Burton]

libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.

Signed-off-by: Ross Burton 
---
 .../fix-glib-configure-libtool-usage.patch| 45 ---
 .../pkgconfig/pkgconfig_git.bb|  1 -
 2 files changed, 46 deletions(-)
 delete mode 100644 
meta/recipes-devtools/pkgconfig/pkgconfig/fix-glib-configure-libtool-usage.patch

diff --git 
a/meta/recipes-devtools/pkgconfig/pkgconfig/fix-glib-configure-libtool-usage.patch
 
b/meta/recipes-devtools/pkgconfig/pkgconfig/fix-glib-configure-libtool-usage.patch
deleted file mode 100644
index 01c62472c1d..000
--- 
a/meta/recipes-devtools/pkgconfig/pkgconfig/fix-glib-configure-libtool-usage.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-
-Upstream-Status: Inappropriate [embedded specific]
-
-Signed-off-by: Saul Wold 
-
-
-Index: pkg-config-0.28/glib/configure.ac
-===
 pkg-config-0.28.orig/glib/configure.ac
-+++ pkg-config-0.28/glib/configure.ac
-@@ -1438,7 +1438,7 @@ if test x"$glib_native_win32" = xyes; th
-   G_MODULE_LDFLAGS=
- else
-   export SED
--  G_MODULE_LDFLAGS=`(./libtool --config; echo eval echo 
\\$export_dynamic_flag_spec) | sh`
-+  G_MODULE_LDFLAGS=`(./${host_alias}-libtool --config; echo eval echo 
\\$export_dynamic_flag_spec) | sh`
- fi
- dnl G_MODULE_IMPL= don't reset, so cmd-line can override
- G_MODULE_NEED_USCORE=0
-@@ -1503,13 +1503,13 @@ if test "$G_MODULE_IMPL" = "G_MODULE_IMP
-   LDFLAGS="$LDFLAGS $G_MODULE_LDFLAGS"
- dnl *** check for OSF1/5.0 RTLD_GLOBAL brokenness
-   echo "void glib_plugin_test(void) { }" > plugin.c
--  ${SHELL} ./libtool --mode=compile --tag=CC ${CC} ${CFLAGS} \
-+  ${SHELL} ./${host_alias}-libtool --mode=compile --tag=CC ${CC} 
${CFLAGS} \
-   ${CPPFLAGS} -c -o plugin.lo plugin.c >/dev/null 2>&1
--  ${SHELL} ./libtool --mode=link --tag=CC ${CC} ${CFLAGS} \
-+  ${SHELL} ./${host_alias}-libtool --mode=link --tag=CC ${CC} ${CFLAGS} \
-   ${LDFLAGS} -module -o plugin.la -export-dynamic \
-   -shrext ".o" -avoid-version plugin.lo \
-   -rpath /dont/care >/dev/null 2>&1
--  eval `./libtool --config | grep ^objdir`
-+  eval `./${host_alias}-libtool --config | grep ^objdir`
-   AC_CACHE_CHECK([for RTLD_GLOBAL brokenness],
-   glib_cv_rtldglobal_broken,[
-   AC_TRY_RUN([
-@@ -1582,7 +1582,7 @@ fi
- 
- AC_MSG_CHECKING(for the suffix of module shared libraries)
- export SED
--shrext_cmds=`./libtool --config | grep '^shrext_cmds='`
-+shrext_cmds=`./${host_alias}-libtool --config | grep '^shrext_cmds='`
- eval $shrext_cmds
- module=yes eval std_shrext=$shrext_cmds
- # chop the initial dot
diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb 
b/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
index c220bafd905..16efcef5613 100644
--- a/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
+++ b/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
@@ -14,7 +14,6 @@ PV = "0.29.2+git${SRCPV}"
 SRC_URI = 
"git://gitlab.freedesktop.org/pkg-config/pkg-config.git;branch=master;protocol=https
 \
file://pkg-config-esdk.in \
file://pkg-config-native.in \
-   file://fix-glib-configure-libtool-usage.patch \

file://0001-glib-gettext.m4-Update-AM_GLIB_GNU_GETTEXT-to-match-.patch \

file://0001-autotools-remove-support-for-the-__int64-type.-See-1.patch \

file://0001-autotools-use-C99-printf-format-specifiers-on-Window.patch \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159528): 
https://lists.openembedded.org/g/openembedded-core/message/159528
Mute This Topic: https://lists.openembedded.org/mt/87636628/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 02/10] binutils: don't expect libtool to be host-prefixed

[Ross Burton]

We update the libtool m4 files in binutils with the latest files from
our patched libtool so that we can use the --with-libtool-sysroot option.

Remove the chunks that are specific to the libtool renaming, which now
doesn't happen.

Signed-off-by: Ross Burton 
---
 .../binutils/0013-Use-libtool-2.4.patch   | 171 --
 1 file changed, 171 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils/0013-Use-libtool-2.4.patch 
b/meta/recipes-devtools/binutils/binutils/0013-Use-libtool-2.4.patch
index a75e72105f2..8f87cfdb777 100644
--- a/meta/recipes-devtools/binutils/binutils/0013-Use-libtool-2.4.patch
+++ b/meta/recipes-devtools/binutils/binutils/0013-Use-libtool-2.4.patch
@@ -796,25 +796,6 @@ index daa51244369..79d0c4b4623 100755
cat > conftest.c << _LT_EOF
  int main() { return 0;}
  _LT_EOF
-@@ -7706,7 +8201,8 @@ fi
- LIBTOOL_DEPS="$ltmain"
- 
- # Always use our own libtool.
--LIBTOOL='$(SHELL) $(top_builddir)/libtool'
-+LIBTOOL='$(SHELL) $(top_builddir)'
-+LIBTOOL="$LIBTOOL/${host_alias}-libtool"
- 
- 
- 
-@@ -7795,7 +8291,7 @@ aix3*)
- esac
- 
- # Global variables:
--ofile=libtool
-+ofile=${host_alias}-libtool
- can_build_shared=yes
- 
- # All known linkers require a `.a' archive for static linking (except MSVC,
 @@ -8093,8 +8589,6 @@ fi
  lt_prog_compiler_pic=
  lt_prog_compiler_static=
@@ -2757,25 +2738,6 @@ index bf6461dab1e..8e6f6d30b4d 100755
cat > conftest.c << _LT_EOF
  int main() { return 0;}
  _LT_EOF
-@@ -7593,7 +8088,8 @@ fi
- LIBTOOL_DEPS="$ltmain"
- 
- # Always use our own libtool.
--LIBTOOL='$(SHELL) $(top_builddir)/libtool'
-+LIBTOOL='$(SHELL) $(top_builddir)'
-+LIBTOOL="$LIBTOOL/${host_alias}-libtool"
- 
- 
- 
-@@ -7682,7 +8178,7 @@ aix3*)
- esac
- 
- # Global variables:
--ofile=libtool
-+ofile=${host_alias}-libtool
- can_build_shared=yes
- 
- # All known linkers require a `.a' archive for static linking (except MSVC,
 @@ -7980,8 +8476,6 @@ fi
  lt_prog_compiler_pic=
  lt_prog_compiler_static=
@@ -4696,25 +4658,6 @@ index 789d1b38b33..7ac563a13ad 100755
cat > conftest.c << _LT_EOF
  int main() { return 0;}
  _LT_EOF
-@@ -7318,7 +7813,8 @@ fi
- LIBTOOL_DEPS="$ltmain"
- 
- # Always use our own libtool.
--LIBTOOL='$(SHELL) $(top_builddir)/libtool'
-+LIBTOOL='$(SHELL) $(top_builddir)'
-+LIBTOOL="$LIBTOOL/${host_alias}-libtool"
- 
- 
- 
-@@ -7407,7 +7903,7 @@ aix3*)
- esac
- 
- # Global variables:
--ofile=libtool
-+ofile=${host_alias}-libtool
- can_build_shared=yes
- 
- # All known linkers require a `.a' archive for static linking (except MSVC,
 @@ -7705,8 +8201,6 @@ fi
  lt_prog_compiler_pic=
  lt_prog_compiler_static=
@@ -6638,25 +6581,6 @@ index 5703bba4462..e1ac86ec797 100755
cat > conftest.c << _LT_EOF
  int main() { return 0;}
  _LT_EOF
-@@ -7220,7 +7715,8 @@ fi
- LIBTOOL_DEPS="$ltmain"
- 
- # Always use our own libtool.
--LIBTOOL='$(SHELL) $(top_builddir)/libtool'
-+LIBTOOL='$(SHELL) $(top_builddir)'
-+LIBTOOL="$LIBTOOL/${host_alias}-libtool"
- 
- 
- 
-@@ -7309,7 +7805,7 @@ aix3*)
- esac
- 
- # Global variables:
--ofile=libtool
-+ofile=${host_alias}-libtool
- can_build_shared=yes
- 
- # All known linkers require a `.a' archive for static linking (except MSVC,
 @@ -7607,8 +8103,6 @@ fi
  lt_prog_compiler_pic=
  lt_prog_compiler_static=
@@ -8597,25 +8521,6 @@ index 2aeb3317b65..5ef46d31558 100755
  
  
  # Set options
-@@ -8077,7 +8582,8 @@ fi
- LIBTOOL_DEPS="$ltmain"
- 
- # Always use our own libtool.
--LIBTOOL='$(SHELL) $(top_builddir)/libtool'
-+LIBTOOL='$(SHELL) $(top_builddir)'
-+LIBTOOL="$LIBTOOL/${host_alias}-libtool"
- 
- 
- 
-@@ -8166,7 +8672,7 @@ aix3*)
- esac
- 
- # Global variables:
--ofile=libtool
-+ofile=${host_alias}-libtool
- can_build_shared=yes
- 
- # All known linkers require a `.a' archive for static linking (except MSVC,
 @@ -8464,8 +8970,6 @@ fi
  lt_prog_compiler_pic=
  lt_prog_compiler_static=
@@ -11220,25 +11125,6 @@ index 82bcf13a606..a7fb723a145 100755
cat > conftest.c << _LT_EOF
  int main() { return 0;}
  _LT_EOF
-@@ -8248,7 +8742,8 @@ fi
- LIBTOOL_DEPS="$ltmain"
- 
- # Always use our own libtool.
--LIBTOOL='$(SHELL) $(top_builddir)/libtool'
-+LIBTOOL='$(SHELL) $(top_builddir)'
-+LIBTOOL="$LIBTOOL/${host_alias}-libtool"
- 
- 
- 
-@@ -8337,7 +8832,7 @@ aix3*)
- esac
- 
- # Global variables:
--ofile=libtool
-+ofile=${host_alias}-libtool
- can_build_shared=yes
- 
- # All known linkers require a `.a' archive for static linking (except MSVC,
 @@ -8635,8 +9130,6 @@ fi
  lt_prog_compiler_pic=
  lt_prog_compiler_static=
@@ -12422,16 +12308,6 @@ index 9a13f3b117a..5be47564443 100644
  
  
  # LT_PREREQ(VERSION)
-@@ -92,7 +94,8 @@ _LT_SET_OPTIONS([$0], [$1])
- LIBTOOL_DEPS="$ltmain"
- 
- # Always use our own libtool.
--LIBTOOL='$(SHELL) $(top_builddir)/libtool'
-+LIBTOOL='$(SHELL) $(top_builddir)'
-+LIBTOOL="$LIBTOOL/${host_alias}-libtool"
- AC_SUBST(LIBTOOL)dnl
- 
- _LT_SETUP
 @@ -166,10 +169,13 @@ _LT_DECL([], [exeext], [0], [Executable file suffix 
(normally "")])dnl
  dnl
  

Re: [oe][OE-core][Patch 1/2] lib/oe/patch.py: apply patches from src_uri specified directories

[Quentin Schulz]

On Fri, Dec 10, 2021 at 09:01:18AM -0500, Bruce Ashfield wrote:
> On Fri, Dec 10, 2021 at 8:29 AM Konrad Weihmann  wrote:
> >
> >
> >
> > On 10.12.21 14:04, Max Krummenacher wrote:
> > > The current developer manual specifies that patches that are
> > > part of a directory which is given in SRC_URI are applied by
> > > the do_patch task. However that is not implemented in the
> > > current code.
> > >
> > > Implement part of it with two differences:
> > > - The implementation requires the parameter "apply=yes" and
> > >adds all files as patches, not only files ending in .patch
> > >and .diff.
> > >This keeps recipes which depend on the current implementation
> > >working.
> > > - The possibility to exclude a file in that directory from being
> > >applied by a follow up entry with "apply=no" is dropped.
> > >
> > > Signed-off-by: Max Krummenacher 
> > > ---
> > >   meta/lib/oe/patch.py | 98 ++--
> > >   1 file changed, 59 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> > > index 950fe723dc..0d2afab2f9 100644
> > > --- a/meta/lib/oe/patch.py
> > > +++ b/meta/lib/oe/patch.py
> > > @@ -794,68 +794,88 @@ class UserResolver(Resolver):
> > >   raise
> > >   os.chdir(olddir)
> > >
> > > -
> > > -def patch_path(url, fetch, workdir, expand=True):
> > > -"""Return the local path of a patch, or return nothing if this isn't 
> > > a patch"""
> > > -
> > > -local = fetch.localpath(url)
> > > -if os.path.isdir(local):
> > > -return
> > > +def is_patch(local, workdir, apply_all, expand):
> > >   base, ext = os.path.splitext(os.path.basename(local))
> > >   if ext in ('.gz', '.bz2', '.xz', '.Z'):
> > >   if expand:
> > >   local = os.path.join(workdir, base)
> > >   ext = os.path.splitext(base)[1]
> > >
> > > -urldata = fetch.ud[url]
> > > +if ext in (".diff", ".patch") or apply_all:
> > > +return True
> > > +return False
> > > +
> > > +def patch_path(local, urldata, fetch, workdir, expand=True):
> > > +"""Return a list of local paths of patches or return an empty list 
> > > if there are no patches"""
> > > +patches = []
> > > +
> > > +apply_all = False
> > >   if "apply" in urldata.parm:
> > >   apply = oe.types.boolean(urldata.parm["apply"])
> > >   if not apply:
> > > -return
> > > -elif ext not in (".diff", ".patch"):
> > > -return
> > > +return patches
> > > +else:
> > > +apply_all = True
> > > +
> > > +if os.path.isdir(local) and apply_all:
> > > +for f in sorted(os.listdir(local)):
> >
> > This assumes that patches can be ordered (in here alphabetically) -
> > which isn't the case for most of the projects I worked with - I think it
> > was also a reason why one has to specify the order and inclusion in SRC_URI.
> 
> This was immediately my concern as well when I read the 0/N for the series.
> 
> I'd be more inclined to remove the documentation, rather than trying
> to deal with sorting and sequencing issues. Since it hasn't been
> working until now, there wouldn't be any users to annoy with dropped
> functionality.
> 
> (That being said, we could make the argument that anyone attempting to
> just point at a directory full of patches knows enough that they need
> to have them named in a way to keep them sorted and applied in order).
> 

First, I'd very much welcome a patch for the documentation since I
assume if this gets merged it does not get backported, so currently
maintained but not master branches would have the old behavior,
warranting a fix in the documentation.

I would assume that this can break kernel-yocto and the KERNEL_FEATURES
with optional patching if .scc and .patch files are in the same
directory which is added to SRC_URI with apply=True.

On a slightly different topic, I personally think that including directories
in SRC_URI should be discouraged because overriding a directory from a
bbappend is completely replacing it and not doing a mergeof both
directories.

i.e.

some-dir/a
some-dir/b
some-dir/c

bbappend/some-dir/b

The result is the only file fetched by the recipe is b from the
bbappend. So it makes it much harder to override only one file from
within a directory which is included in SRC_URI.

Cheers,
Quentin

> Cheers,
> 
> Bruce
> 
> 
> >
> > > +sublocal = local + '/' + f
> >
> > Wouldn't be a sorted glob be more suitable here?
> >
> > > +# Also search in subdirs
> > > +if os.path.isdir(sublocal):
> > > +patches = patches + patch_path(sublocal, urldata, fetch, 
> > > workdir, expand)
> > > +else:
> > > +if is_patch(sublocal, workdir, apply_all, expand):
> > > +patches.append(sublocal)
> > > +else:
> > > +if is_patch(local, workdir, apply_all, expand):
> > > +

Re: [oe][OE-core][Patch 1/2] lib/oe/patch.py: apply patches from src_uri specified directories

[Bruce Ashfield]

On Fri, Dec 10, 2021 at 9:07 AM Max  wrote:
>
> Am Freitag, den 10.12.2021, 09:01 -0500 schrieb Bruce Ashfield:
> > On Fri, Dec 10, 2021 at 8:29 AM Konrad Weihmann  
> > wrote:
> > >
> > >
> > > On 10.12.21 14:04, Max Krummenacher wrote:
> > > > The current developer manual specifies that patches that are
> > > > part of a directory which is given in SRC_URI are applied by
> > > > the do_patch task. However that is not implemented in the
> > > > current code.
> > > >
> > > > Implement part of it with two differences:
> > > > - The implementation requires the parameter "apply=yes" and
> > > >adds all files as patches, not only files ending in .patch
> > > >and .diff.
> > > >This keeps recipes which depend on the current implementation
> > > >working.
> > > > - The possibility to exclude a file in that directory from being
> > > >applied by a follow up entry with "apply=no" is dropped.
> > > >
> > > > Signed-off-by: Max Krummenacher 
> > > > ---
> > > >   meta/lib/oe/patch.py | 98 ++--
> > > >   1 file changed, 59 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> > > > index 950fe723dc..0d2afab2f9 100644
> > > > --- a/meta/lib/oe/patch.py
> > > > +++ b/meta/lib/oe/patch.py
> > > > @@ -794,68 +794,88 @@ class UserResolver(Resolver):
> > > >   raise
> > > >   os.chdir(olddir)
> > > >
> > > > -
> > > > -def patch_path(url, fetch, workdir, expand=True):
> > > > -"""Return the local path of a patch, or return nothing if this 
> > > > isn't a patch"""
> > > > -
> > > > -local = fetch.localpath(url)
> > > > -if os.path.isdir(local):
> > > > -return
> > > > +def is_patch(local, workdir, apply_all, expand):
> > > >   base, ext = os.path.splitext(os.path.basename(local))
> > > >   if ext in ('.gz', '.bz2', '.xz', '.Z'):
> > > >   if expand:
> > > >   local = os.path.join(workdir, base)
> > > >   ext = os.path.splitext(base)[1]
> > > >
> > > > -urldata = fetch.ud[url]
> > > > +if ext in (".diff", ".patch") or apply_all:
> > > > +return True
> > > > +return False
> > > > +
> > > > +def patch_path(local, urldata, fetch, workdir, expand=True):
> > > > +"""Return a list of local paths of patches or return an empty list 
> > > > if there are no
> > > > patches"""
> > > > +patches = []
> > > > +
> > > > +apply_all = False
> > > >   if "apply" in urldata.parm:
> > > >   apply = oe.types.boolean(urldata.parm["apply"])
> > > >   if not apply:
> > > > -return
> > > > -elif ext not in (".diff", ".patch"):
> > > > -return
> > > > +return patches
> > > > +else:
> > > > +apply_all = True
> > > > +
> > > > +if os.path.isdir(local) and apply_all:
> > > > +for f in sorted(os.listdir(local)):
> > >
> > > This assumes that patches can be ordered (in here alphabetically) -
> > > which isn't the case for most of the projects I worked with - I think it
> > > was also a reason why one has to specify the order and inclusion in 
> > > SRC_URI.
> >
> > This was immediately my concern as well when I read the 0/N for the series.
> >
> > I'd be more inclined to remove the documentation, rather than trying
> > to deal with sorting and sequencing issues. Since it hasn't been
> > working until now, there wouldn't be any users to annoy with dropped
> > functionality.
> >
> > (That being said, we could make the argument that anyone attempting to
> > just point at a directory full of patches knows enough that they need
> > to have them named in a way to keep them sorted and applied in order).
> >
>
> This now implemented feature is not meant to replace the current way
> of specifying patches. So if you cannot change the patch filenames
> to specify the order then don't use it.

Well yes, that is obvious.  I can't imagine why anyone would want to
even use potentially unordered directories of patches, so making it
a replacement would be unwise :D

>
> One use case I envision is a patchset in flight while upstreaming to
> the upstream project. Apply such a patchset as the content of a
> directory. For that use case the patches are sorted with their
> 000x-*.patch naming from generating them by default.
> If you want to mix apples and orange patches, then I agree that the
> directory approach is probably the wrong one.

Agreed. If someone is dumping patches from git, they get numerical
ordering. Practice shows that even nicely ordered patches start to
get a strange ordering as more are added, some are removed (and
people forget to specify start-number when dumping the new patches).

I'm sure someone might use the functionality, and it is true that it has
no impact on the main workflows, so there's no risk there. It is just
more code to support (and we should probably have a test added for
it) .. and Richard probably knows better than me the risks and 

Re: [oe][OE-core][Patch 1/2] lib/oe/patch.py: apply patches from src_uri specified directories

[Max Krummenacher]

Am Freitag, den 10.12.2021, 09:01 -0500 schrieb Bruce Ashfield:
> On Fri, Dec 10, 2021 at 8:29 AM Konrad Weihmann  wrote:
> > 
> > 
> > On 10.12.21 14:04, Max Krummenacher wrote:
> > > The current developer manual specifies that patches that are
> > > part of a directory which is given in SRC_URI are applied by
> > > the do_patch task. However that is not implemented in the
> > > current code.
> > > 
> > > Implement part of it with two differences:
> > > - The implementation requires the parameter "apply=yes" and
> > >adds all files as patches, not only files ending in .patch
> > >and .diff.
> > >This keeps recipes which depend on the current implementation
> > >working.
> > > - The possibility to exclude a file in that directory from being
> > >applied by a follow up entry with "apply=no" is dropped.
> > > 
> > > Signed-off-by: Max Krummenacher 
> > > ---
> > >   meta/lib/oe/patch.py | 98 ++--
> > >   1 file changed, 59 insertions(+), 39 deletions(-)
> > > 
> > > diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> > > index 950fe723dc..0d2afab2f9 100644
> > > --- a/meta/lib/oe/patch.py
> > > +++ b/meta/lib/oe/patch.py
> > > @@ -794,68 +794,88 @@ class UserResolver(Resolver):
> > >   raise
> > >   os.chdir(olddir)
> > > 
> > > -
> > > -def patch_path(url, fetch, workdir, expand=True):
> > > -"""Return the local path of a patch, or return nothing if this isn't 
> > > a patch"""
> > > -
> > > -local = fetch.localpath(url)
> > > -if os.path.isdir(local):
> > > -return
> > > +def is_patch(local, workdir, apply_all, expand):
> > >   base, ext = os.path.splitext(os.path.basename(local))
> > >   if ext in ('.gz', '.bz2', '.xz', '.Z'):
> > >   if expand:
> > >   local = os.path.join(workdir, base)
> > >   ext = os.path.splitext(base)[1]
> > > 
> > > -urldata = fetch.ud[url]
> > > +if ext in (".diff", ".patch") or apply_all:
> > > +return True
> > > +return False
> > > +
> > > +def patch_path(local, urldata, fetch, workdir, expand=True):
> > > +"""Return a list of local paths of patches or return an empty list 
> > > if there are no
> > > patches"""
> > > +patches = []
> > > +
> > > +apply_all = False
> > >   if "apply" in urldata.parm:
> > >   apply = oe.types.boolean(urldata.parm["apply"])
> > >   if not apply:
> > > -return
> > > -elif ext not in (".diff", ".patch"):
> > > -return
> > > +return patches
> > > +else:
> > > +apply_all = True
> > > +
> > > +if os.path.isdir(local) and apply_all:
> > > +for f in sorted(os.listdir(local)):
> > 
> > This assumes that patches can be ordered (in here alphabetically) -
> > which isn't the case for most of the projects I worked with - I think it
> > was also a reason why one has to specify the order and inclusion in SRC_URI.
> 
> This was immediately my concern as well when I read the 0/N for the series.
> 
> I'd be more inclined to remove the documentation, rather than trying
> to deal with sorting and sequencing issues. Since it hasn't been
> working until now, there wouldn't be any users to annoy with dropped
> functionality.
> 
> (That being said, we could make the argument that anyone attempting to
> just point at a directory full of patches knows enough that they need
> to have them named in a way to keep them sorted and applied in order).
> 

This now implemented feature is not meant to replace the current way
of specifying patches. So if you cannot change the patch filenames
to specify the order then don't use it.

One use case I envision is a patchset in flight while upstreaming to
the upstream project. Apply such a patchset as the content of a
directory. For that use case the patches are sorted with their
000x-*.patch naming from generating them by default.
If you want to mix apples and orange patches, then I agree that the
directory approach is probably the wrong one.

> Cheers,
> 
> Bruce
> 
> 
> > > +sublocal = local + '/' + f
> > 
> > Wouldn't be a sorted glob be more suitable here?

I'll look into it.

Max

> > 
> > > +# Also search in subdirs
> > > +if os.path.isdir(sublocal):
> > > +patches = patches + patch_path(sublocal, urldata, fetch, 
> > > workdir, expand)
> > > +else:
> > > +if is_patch(sublocal, workdir, apply_all, expand):
> > > +patches.append(sublocal)
> > > +else:
> > > +if is_patch(local, workdir, apply_all, expand):
> > > +patches.append(local)
> > > 
> > > -return local
> > > +return patches
> > > 
> > >   def src_patches(d, all=False, expand=True):
> > > +"""Return a list of local paths from SRC_URI. With all=False all 
> > > patches targeting
> > > do_patch, with all=True all other local paths"""
> > >   workdir = d.getVar('WORKDIR')
> > > 

Re: [OE-core] [PATCH] libva: move wayland PACKAGECONFIG to libva.inc

[Alexander Kanavin]

 | Run-time dependency wayland-client found: YES 1.19.0

Can you please explain how the issue can be reproduced? I find it odd that
libva-initial (which only needs libdrm, and is required by mesa) has
wayland in its sysroot in your build - where does that come from? There's a
chance the problem is elsewhere.

Alex

On Fri, 10 Dec 2021 at 15:03, Markus Volk  wrote:

> I encountered an error while trying to build libva under wayland.
> libva-initial
> was missing wayland-native dependency and failed like this:
>
> | Run-time dependency xfixes found: NO (tried pkgconfig and cmake)
> | Run-time dependency wayland-client found: YES 1.19.0
> | Program wayland-scanner /usr/bin/wayland-scanner found: NO
> |
> | ../libva-2.13.0/meson.build:107:4: ERROR: Program 'wayland-scanner
> /usr/bin/wayland-scanner' not found
> |
> | A full log can be found at
> /home/flk/build/poky/build-rock/tmp/work/cortexa72-cortexa53-crypto-poky-linux/libva-initial/2.13.0-r0/build/meson-logs/meson-log.txt
> | ERROR: meson failed
> | WARNING: exit code 1 from a shell command.
>
> This commit moves the PACKAGECONFIG[wayland] to libva.inc to make it
> available to libva-initial also
>
> Signed-off-by: MarkusVolk 
> ---
>  meta/recipes-graphics/libva/libva.inc   | 7 +++
>  meta/recipes-graphics/libva/libva_2.13.0.bb | 4 +---
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-graphics/libva/libva.inc
> b/meta/recipes-graphics/libva/libva.inc
> index bcf9757c1a..0e2721e291 100644
> --- a/meta/recipes-graphics/libva/libva.inc
> +++ b/meta/recipes-graphics/libva/libva.inc
> @@ -27,3 +27,10 @@ UPSTREAM_CHECK_URI = "
> https://github.com/intel/libva/releases;
>  DEPENDS = "libdrm"
>
>  inherit meson pkgconfig
> +
> +PACKAGECONFIG:append = " \
> +${@bb.utils.filter('DISTRO_FEATURES', 'wayland', d)} \
> +"
> +
> +PACKAGECONFIG[wayland] =
> "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native wayland"
> +
> diff --git a/meta/recipes-graphics/libva/libva_2.13.0.bb
> b/meta/recipes-graphics/libva/libva_2.13.0.bb
> index ed2be289fc..a8c6355b01 100644
> --- a/meta/recipes-graphics/libva/libva_2.13.0.bb
> +++ b/meta/recipes-graphics/libva/libva_2.13.0.bb
> @@ -2,14 +2,12 @@ require libva.inc
>
>  PACKAGECONFIG ??= " \
>  ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', '', d)} \
> -${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)} \
> +${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} \
>  "
>
>  PACKAGECONFIG[x11] = "-Dwith_x11=yes,-Dwith_x11=no,virtual/libx11 libxext
> libxfixes"
>  PACKAGECONFIG[glx] = "-Dwith_glx=yes,-Dwith_glx=no,virtual/mesa"
>
> -PACKAGECONFIG[wayland] =
> "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native wayland"
> -
>  PACKAGES =+ "${PN}-x11 ${PN}-glx ${PN}-wayland"
>
>  RDEPENDS:${PN}-x11 =+ "${PN}"
> --
> 2.25.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159524): 
https://lists.openembedded.org/g/openembedded-core/message/159524
Mute This Topic: https://lists.openembedded.org/mt/87636241/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] libva: move wayland PACKAGECONFIG to libva.inc

[Markus Volk]

I encountered an error while trying to build libva under wayland. libva-initial
was missing wayland-native dependency and failed like this:

| Run-time dependency xfixes found: NO (tried pkgconfig and cmake)
| Run-time dependency wayland-client found: YES 1.19.0
| Program wayland-scanner /usr/bin/wayland-scanner found: NO
|
| ../libva-2.13.0/meson.build:107:4: ERROR: Program 'wayland-scanner 
/usr/bin/wayland-scanner' not found
|
| A full log can be found at 
/home/flk/build/poky/build-rock/tmp/work/cortexa72-cortexa53-crypto-poky-linux/libva-initial/2.13.0-r0/build/meson-logs/meson-log.txt
| ERROR: meson failed
| WARNING: exit code 1 from a shell command.

This commit moves the PACKAGECONFIG[wayland] to libva.inc to make it available 
to libva-initial also

Signed-off-by: MarkusVolk 
---
 meta/recipes-graphics/libva/libva.inc   | 7 +++
 meta/recipes-graphics/libva/libva_2.13.0.bb | 4 +---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/libva/libva.inc 
b/meta/recipes-graphics/libva/libva.inc
index bcf9757c1a..0e2721e291 100644
--- a/meta/recipes-graphics/libva/libva.inc
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -27,3 +27,10 @@ UPSTREAM_CHECK_URI = 
"https://github.com/intel/libva/releases;
 DEPENDS = "libdrm"
 
 inherit meson pkgconfig
+
+PACKAGECONFIG:append = " \
+${@bb.utils.filter('DISTRO_FEATURES', 'wayland', d)} \
+"
+
+PACKAGECONFIG[wayland] = "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native 
wayland"
+
diff --git a/meta/recipes-graphics/libva/libva_2.13.0.bb 
b/meta/recipes-graphics/libva/libva_2.13.0.bb
index ed2be289fc..a8c6355b01 100644
--- a/meta/recipes-graphics/libva/libva_2.13.0.bb
+++ b/meta/recipes-graphics/libva/libva_2.13.0.bb
@@ -2,14 +2,12 @@ require libva.inc
 
 PACKAGECONFIG ??= " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', '', d)} \
-${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)} \
+${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} \
 "
 
 PACKAGECONFIG[x11] = "-Dwith_x11=yes,-Dwith_x11=no,virtual/libx11 libxext 
libxfixes"
 PACKAGECONFIG[glx] = "-Dwith_glx=yes,-Dwith_glx=no,virtual/mesa"
 
-PACKAGECONFIG[wayland] = "-Dwith_wayland=yes,-Dwith_wayland=no,wayland-native 
wayland"
-
 PACKAGES =+ "${PN}-x11 ${PN}-glx ${PN}-wayland"
 
 RDEPENDS:${PN}-x11 =+ "${PN}"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159523): 
https://lists.openembedded.org/g/openembedded-core/message/159523
Mute This Topic: https://lists.openembedded.org/mt/87636241/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe][OE-core][Patch 1/2] lib/oe/patch.py: apply patches from src_uri specified directories

[Bruce Ashfield]

On Fri, Dec 10, 2021 at 8:29 AM Konrad Weihmann  wrote:
>
>
>
> On 10.12.21 14:04, Max Krummenacher wrote:
> > The current developer manual specifies that patches that are
> > part of a directory which is given in SRC_URI are applied by
> > the do_patch task. However that is not implemented in the
> > current code.
> >
> > Implement part of it with two differences:
> > - The implementation requires the parameter "apply=yes" and
> >adds all files as patches, not only files ending in .patch
> >and .diff.
> >This keeps recipes which depend on the current implementation
> >working.
> > - The possibility to exclude a file in that directory from being
> >applied by a follow up entry with "apply=no" is dropped.
> >
> > Signed-off-by: Max Krummenacher 
> > ---
> >   meta/lib/oe/patch.py | 98 ++--
> >   1 file changed, 59 insertions(+), 39 deletions(-)
> >
> > diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> > index 950fe723dc..0d2afab2f9 100644
> > --- a/meta/lib/oe/patch.py
> > +++ b/meta/lib/oe/patch.py
> > @@ -794,68 +794,88 @@ class UserResolver(Resolver):
> >   raise
> >   os.chdir(olddir)
> >
> > -
> > -def patch_path(url, fetch, workdir, expand=True):
> > -"""Return the local path of a patch, or return nothing if this isn't a 
> > patch"""
> > -
> > -local = fetch.localpath(url)
> > -if os.path.isdir(local):
> > -return
> > +def is_patch(local, workdir, apply_all, expand):
> >   base, ext = os.path.splitext(os.path.basename(local))
> >   if ext in ('.gz', '.bz2', '.xz', '.Z'):
> >   if expand:
> >   local = os.path.join(workdir, base)
> >   ext = os.path.splitext(base)[1]
> >
> > -urldata = fetch.ud[url]
> > +if ext in (".diff", ".patch") or apply_all:
> > +return True
> > +return False
> > +
> > +def patch_path(local, urldata, fetch, workdir, expand=True):
> > +"""Return a list of local paths of patches or return an empty list if 
> > there are no patches"""
> > +patches = []
> > +
> > +apply_all = False
> >   if "apply" in urldata.parm:
> >   apply = oe.types.boolean(urldata.parm["apply"])
> >   if not apply:
> > -return
> > -elif ext not in (".diff", ".patch"):
> > -return
> > +return patches
> > +else:
> > +apply_all = True
> > +
> > +if os.path.isdir(local) and apply_all:
> > +for f in sorted(os.listdir(local)):
>
> This assumes that patches can be ordered (in here alphabetically) -
> which isn't the case for most of the projects I worked with - I think it
> was also a reason why one has to specify the order and inclusion in SRC_URI.

This was immediately my concern as well when I read the 0/N for the series.

I'd be more inclined to remove the documentation, rather than trying
to deal with sorting and sequencing issues. Since it hasn't been
working until now, there wouldn't be any users to annoy with dropped
functionality.

(That being said, we could make the argument that anyone attempting to
just point at a directory full of patches knows enough that they need
to have them named in a way to keep them sorted and applied in order).

Cheers,

Bruce


>
> > +sublocal = local + '/' + f
>
> Wouldn't be a sorted glob be more suitable here?
>
> > +# Also search in subdirs
> > +if os.path.isdir(sublocal):
> > +patches = patches + patch_path(sublocal, urldata, fetch, 
> > workdir, expand)
> > +else:
> > +if is_patch(sublocal, workdir, apply_all, expand):
> > +patches.append(sublocal)
> > +else:
> > +if is_patch(local, workdir, apply_all, expand):
> > +patches.append(local)
> >
> > -return local
> > +return patches
> >
> >   def src_patches(d, all=False, expand=True):
> > +"""Return a list of local paths from SRC_URI. With all=False all 
> > patches targeting do_patch, with all=True all other local paths"""
> >   workdir = d.getVar('WORKDIR')
> >   fetch = bb.fetch2.Fetch([], d)
> >   patches = []
> >   sources = []
> > -for url in fetch.urls:
> > -local = patch_path(url, fetch, workdir, expand)
> > -if not local:
> > -if all:
> > -local = fetch.localpath(url)
> > -sources.append(local)
> > -continue
> >
> > +for url in fetch.urls:
> > +local = fetch.localpath(url)
> >   urldata = fetch.ud[url]
> > -parm = urldata.parm
> > -patchname = parm.get('pname') or os.path.basename(local)
> > +locals = []
> > +locals = locals + patch_path(local, urldata, fetch, workdir, 
> > expand)
> >
> > -apply, reason = should_apply(parm, d)
> > -if not apply:
> > -if reason:
> > -bb.note("Patch %s %s" % (patchname, reason))
> > +if not locals:

Re: [oe][OE-core][Patch 1/2] lib/oe/patch.py: apply patches from src_uri specified directories

[Konrad Weihmann]

On 10.12.21 14:04, Max Krummenacher wrote:

The current developer manual specifies that patches that are
part of a directory which is given in SRC_URI are applied by
the do_patch task. However that is not implemented in the
current code.

Implement part of it with two differences:
- The implementation requires the parameter "apply=yes" and
   adds all files as patches, not only files ending in .patch
   and .diff.
   This keeps recipes which depend on the current implementation
   working.
- The possibility to exclude a file in that directory from being
   applied by a follow up entry with "apply=no" is dropped.

Signed-off-by: Max Krummenacher 
---
  meta/lib/oe/patch.py | 98 ++--
  1 file changed, 59 insertions(+), 39 deletions(-)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 950fe723dc..0d2afab2f9 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -794,68 +794,88 @@ class UserResolver(Resolver):
  raise
  os.chdir(olddir)
  
-

-def patch_path(url, fetch, workdir, expand=True):
-"""Return the local path of a patch, or return nothing if this isn't a 
patch"""
-
-local = fetch.localpath(url)
-if os.path.isdir(local):
-return
+def is_patch(local, workdir, apply_all, expand):
  base, ext = os.path.splitext(os.path.basename(local))
  if ext in ('.gz', '.bz2', '.xz', '.Z'):
  if expand:
  local = os.path.join(workdir, base)
  ext = os.path.splitext(base)[1]
  
-urldata = fetch.ud[url]

+if ext in (".diff", ".patch") or apply_all:
+return True
+return False
+
+def patch_path(local, urldata, fetch, workdir, expand=True):
+"""Return a list of local paths of patches or return an empty list if there are no 
patches"""
+patches = []
+
+apply_all = False
  if "apply" in urldata.parm:
  apply = oe.types.boolean(urldata.parm["apply"])
  if not apply:
-return
-elif ext not in (".diff", ".patch"):
-return
+return patches
+else:
+apply_all = True
+
+if os.path.isdir(local) and apply_all:
+for f in sorted(os.listdir(local)):


This assumes that patches can be ordered (in here alphabetically) - 
which isn't the case for most of the projects I worked with - I think it 
was also a reason why one has to specify the order and inclusion in SRC_URI.



+sublocal = local + '/' + f


Wouldn't be a sorted glob be more suitable here?


+# Also search in subdirs
+if os.path.isdir(sublocal):
+patches = patches + patch_path(sublocal, urldata, fetch, 
workdir, expand)
+else:
+if is_patch(sublocal, workdir, apply_all, expand):
+patches.append(sublocal)
+else:
+if is_patch(local, workdir, apply_all, expand):
+patches.append(local)
  
-return local

+return patches
  
  def src_patches(d, all=False, expand=True):

+"""Return a list of local paths from SRC_URI. With all=False all patches targeting 
do_patch, with all=True all other local paths"""
  workdir = d.getVar('WORKDIR')
  fetch = bb.fetch2.Fetch([], d)
  patches = []
  sources = []
-for url in fetch.urls:
-local = patch_path(url, fetch, workdir, expand)
-if not local:
-if all:
-local = fetch.localpath(url)
-sources.append(local)
-continue
  
+for url in fetch.urls:

+local = fetch.localpath(url)
  urldata = fetch.ud[url]
-parm = urldata.parm
-patchname = parm.get('pname') or os.path.basename(local)
+locals = []
+locals = locals + patch_path(local, urldata, fetch, workdir, expand)
  
-apply, reason = should_apply(parm, d)

-if not apply:
-if reason:
-bb.note("Patch %s %s" % (patchname, reason))
+if not locals:
+if all:
+sources.append(local)
  continue
-
-patchparm = {'patchname': patchname}
-if "striplevel" in parm:
-striplevel = parm["striplevel"]
-elif "pnum" in parm:
-#bb.msg.warn(None, "Deprecated usage of 'pnum' url parameter in '%s', 
please use 'striplevel'" % url)
-striplevel = parm["pnum"]
  else:
-striplevel = '1'
-patchparm['striplevel'] = striplevel
+for patch in locals:
+parm = urldata.parm
+patchname = parm.get('pname') or os.path.basename(patch)
+
+apply, reason = should_apply(parm, d)
+if not apply:
+if reason:
+bb.note("Patch %s %s" % (patchname, reason))
+continue
+
+patchparm = {'patchname': patchname}
+if "striplevel" in parm:
+striplevel = 

[oe][OE-core][Patch 2/2] lib/oe/recipeutils.py: follow changed method argument list

[Max Krummenacher]

Signed-off-by: Max Krummenacher 
---
 meta/lib/oe/recipeutils.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index a0c6974f04..7b5b6bf10e 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -467,7 +467,7 @@ def get_recipe_local_files(d, patches=False, 
archives=False):
 for uri in uris:
 if fetch.ud[uri].type == 'file':
 if (not patches and
-oe.patch.patch_path(uri, fetch, '', expand=False)):
+oe.patch.patch_path(fetch.localpath(uri), fetch.ud[uri], 
fetch, '', expand=False)):
 continue
 # Skip files that are referenced by absolute path
 fname = fetch.ud[uri].basepath
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159520): 
https://lists.openembedded.org/g/openembedded-core/message/159520
Mute This Topic: https://lists.openembedded.org/mt/87635234/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe][OE-core][Patch 0/2] implement applying patches from a directory

[Max Krummenacher]

The current developer manual [1] specifies that patches that are
part of a directory which is given in SRC_URI are applied by
the do_patch task. However that is not implemented in the
current code.

This patchset implements that, but deviates from what is
documented. If the patches are applied I will send a patch
for the documentation changing the relevant part to:

```
If you have a directory full of patch files and you want to
apply them all you can add the directory to SRC_URI and add
the "apply=yes" parameter. This will apply ALL files in the
directiory, including files in subdirectories.
The patches will be applied sorted by their filename. Files
from subdirectories will be sorted into the list at the
position given by the subdirectory name.

   SRC_URI = " \
   git://path_to_repo/some_package \
   file://path_to_lots_of_patch_files;apply=yes \
   "

In the previous example all the files in the directory holding
the patch files would be applied as a patch.
```

Max

[1] 
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-tasks-patch

Max Krummenacher (2):
  lib/oe/patch.py: apply patches from src_uri specified directories
  lib/oe/recipeutils.py: follow changed method argument list

 meta/lib/oe/patch.py   | 98 +++---
 meta/lib/oe/recipeutils.py |  2 +-
 2 files changed, 60 insertions(+), 40 deletions(-)

-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159518): 
https://lists.openembedded.org/g/openembedded-core/message/159518
Mute This Topic: https://lists.openembedded.org/mt/87635232/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe][OE-core][Patch 1/2] lib/oe/patch.py: apply patches from src_uri specified directories

[Max Krummenacher]

The current developer manual specifies that patches that are
part of a directory which is given in SRC_URI are applied by
the do_patch task. However that is not implemented in the
current code.

Implement part of it with two differences:
- The implementation requires the parameter "apply=yes" and
  adds all files as patches, not only files ending in .patch
  and .diff.
  This keeps recipes which depend on the current implementation
  working.
- The possibility to exclude a file in that directory from being
  applied by a follow up entry with "apply=no" is dropped.

Signed-off-by: Max Krummenacher 
---
 meta/lib/oe/patch.py | 98 ++--
 1 file changed, 59 insertions(+), 39 deletions(-)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 950fe723dc..0d2afab2f9 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -794,68 +794,88 @@ class UserResolver(Resolver):
 raise
 os.chdir(olddir)
 
-
-def patch_path(url, fetch, workdir, expand=True):
-"""Return the local path of a patch, or return nothing if this isn't a 
patch"""
-
-local = fetch.localpath(url)
-if os.path.isdir(local):
-return
+def is_patch(local, workdir, apply_all, expand):
 base, ext = os.path.splitext(os.path.basename(local))
 if ext in ('.gz', '.bz2', '.xz', '.Z'):
 if expand:
 local = os.path.join(workdir, base)
 ext = os.path.splitext(base)[1]
 
-urldata = fetch.ud[url]
+if ext in (".diff", ".patch") or apply_all:
+return True
+return False
+
+def patch_path(local, urldata, fetch, workdir, expand=True):
+"""Return a list of local paths of patches or return an empty list if 
there are no patches"""
+patches = []
+
+apply_all = False
 if "apply" in urldata.parm:
 apply = oe.types.boolean(urldata.parm["apply"])
 if not apply:
-return
-elif ext not in (".diff", ".patch"):
-return
+return patches
+else:
+apply_all = True
+
+if os.path.isdir(local) and apply_all:
+for f in sorted(os.listdir(local)):
+sublocal = local + '/' + f
+# Also search in subdirs
+if os.path.isdir(sublocal):
+patches = patches + patch_path(sublocal, urldata, fetch, 
workdir, expand)
+else:
+if is_patch(sublocal, workdir, apply_all, expand):
+patches.append(sublocal)
+else:
+if is_patch(local, workdir, apply_all, expand):
+patches.append(local)
 
-return local
+return patches
 
 def src_patches(d, all=False, expand=True):
+"""Return a list of local paths from SRC_URI. With all=False all patches 
targeting do_patch, with all=True all other local paths"""
 workdir = d.getVar('WORKDIR')
 fetch = bb.fetch2.Fetch([], d)
 patches = []
 sources = []
-for url in fetch.urls:
-local = patch_path(url, fetch, workdir, expand)
-if not local:
-if all:
-local = fetch.localpath(url)
-sources.append(local)
-continue
 
+for url in fetch.urls:
+local = fetch.localpath(url)
 urldata = fetch.ud[url]
-parm = urldata.parm
-patchname = parm.get('pname') or os.path.basename(local)
+locals = []
+locals = locals + patch_path(local, urldata, fetch, workdir, expand)
 
-apply, reason = should_apply(parm, d)
-if not apply:
-if reason:
-bb.note("Patch %s %s" % (patchname, reason))
+if not locals:
+if all:
+sources.append(local)
 continue
-
-patchparm = {'patchname': patchname}
-if "striplevel" in parm:
-striplevel = parm["striplevel"]
-elif "pnum" in parm:
-#bb.msg.warn(None, "Deprecated usage of 'pnum' url parameter in 
'%s', please use 'striplevel'" % url)
-striplevel = parm["pnum"]
 else:
-striplevel = '1'
-patchparm['striplevel'] = striplevel
+for patch in locals:
+parm = urldata.parm
+patchname = parm.get('pname') or os.path.basename(patch)
+
+apply, reason = should_apply(parm, d)
+if not apply:
+if reason:
+bb.note("Patch %s %s" % (patchname, reason))
+continue
+
+patchparm = {'patchname': patchname}
+if "striplevel" in parm:
+striplevel = parm["striplevel"]
+elif "pnum" in parm:
+#bb.warn("Deprecated usage of 'pnum' url parameter in 
'%s', please use 'striplevel'" % url)
+striplevel = parm["pnum"]
+else:
+striplevel = '1'
+patchparm['striplevel'] = striplevel
 
-patchdir = parm.get('patchdir')
-   

[OE-core] [PATCH 8/8] overlayfs: move templates to files directory

[Vyacheslav Yurkov]

Signed-off-by: Vyacheslav Yurkov 
---
 meta/classes/overlayfs.bbclass   | 52 
 meta/files/overlayfs-all-overlays.service.in | 12 +
 meta/files/overlayfs-create-dirs.service.in  | 14 ++
 meta/files/overlayfs-unit.mount.in   | 13 +
 4 files changed, 49 insertions(+), 42 deletions(-)
 create mode 100644 meta/files/overlayfs-all-overlays.service.in
 create mode 100644 meta/files/overlayfs-create-dirs.service.in
 create mode 100644 meta/files/overlayfs-unit.mount.in

diff --git a/meta/classes/overlayfs.bbclass b/meta/classes/overlayfs.bbclass
index f1b8086ea8..4a860f7308 100644
--- a/meta/classes/overlayfs.bbclass
+++ b/meta/classes/overlayfs.bbclass
@@ -37,51 +37,19 @@ REQUIRED_DISTRO_FEATURES += "systemd overlayfs"
 
 inherit systemd features_check
 
+OVERLAYFS_CREATE_DIRS_TEMPLATE ??= 
"${COREBASE}/meta/files/overlayfs-create-dirs.service.in"
+OVERLAYFS_MOUNT_UNIT_TEMPLATE ??= 
"${COREBASE}/meta/files/overlayfs-unit.mount.in"
+OVERLAYFS_ALL_OVERLAYS_TEMPLATE ??= 
"${COREBASE}/meta/files/overlayfs-all-overlays.service.in"
+
 python do_create_overlayfs_units() {
 from oe.overlayfs import mountUnitName
 
-CreateDirsUnitTemplate = """[Unit]
-Description=Overlayfs directories setup
-Requires={DATA_MOUNT_UNIT}
-After={DATA_MOUNT_UNIT}
-DefaultDependencies=no
-
-[Service]
-Type=oneshot
-ExecStart=mkdir -p {DATA_MOUNT_POINT}/workdir{LOWERDIR} && mkdir -p 
{DATA_MOUNT_POINT}/upper{LOWERDIR}
-RemainAfterExit=true
-StandardOutput=journal
-
-[Install]
-WantedBy=multi-user.target
-"""
-MountUnitTemplate = """[Unit]
-Description=Overlayfs mount unit
-Requires={CREATE_DIRS_SERVICE}
-After={CREATE_DIRS_SERVICE}
-
-[Mount]
-What=overlay
-Where={LOWERDIR}
-Type=overlay
-Options=lowerdir={LOWERDIR},upperdir={DATA_MOUNT_POINT}/upper{LOWERDIR},workdir={DATA_MOUNT_POINT}/workdir{LOWERDIR}
-
-[Install]
-WantedBy=multi-user.target
-"""
-AllOverlaysTemplate = """[Unit]
-Description=Groups all overlays required by {PN} in one unit
-After={ALL_OVERLAYFS_UNITS}
-Requires={ALL_OVERLAYFS_UNITS}
-
-[Service]
-Type=oneshot
-ExecStart=/bin/true
-RemainAfterExit=true
-
-[Install]
-WantedBy=local-fs.target
-"""
+with open(d.getVar("OVERLAYFS_CREATE_DIRS_TEMPLATE"), "r") as f:
+CreateDirsUnitTemplate = f.read()
+with open(d.getVar("OVERLAYFS_MOUNT_UNIT_TEMPLATE"), "r") as f:
+MountUnitTemplate = f.read()
+with open(d.getVar("OVERLAYFS_ALL_OVERLAYS_TEMPLATE"), "r") as f:
+AllOverlaysTemplate = f.read()
 
 def prepareUnits(data, lower):
 from oe.overlayfs import helperUnitName
diff --git a/meta/files/overlayfs-all-overlays.service.in 
b/meta/files/overlayfs-all-overlays.service.in
new file mode 100644
index 00..74ee4e90ae
--- /dev/null
+++ b/meta/files/overlayfs-all-overlays.service.in
@@ -0,0 +1,12 @@
+[Unit]
+Description=Groups all overlays required by {PN} in one unit
+After={ALL_OVERLAYFS_UNITS}
+Requires={ALL_OVERLAYFS_UNITS}
+
+[Service]
+Type=oneshot
+ExecStart=/bin/true
+RemainAfterExit=true
+
+[Install]
+WantedBy=local-fs.target
diff --git a/meta/files/overlayfs-create-dirs.service.in 
b/meta/files/overlayfs-create-dirs.service.in
new file mode 100644
index 00..17204145f2
--- /dev/null
+++ b/meta/files/overlayfs-create-dirs.service.in
@@ -0,0 +1,14 @@
+[Unit]
+Description=Overlayfs directories setup
+Requires={DATA_MOUNT_UNIT}
+After={DATA_MOUNT_UNIT}
+DefaultDependencies=no
+
+[Service]
+Type=oneshot
+ExecStart=mkdir -p {DATA_MOUNT_POINT}/workdir{LOWERDIR} && mkdir -p 
{DATA_MOUNT_POINT}/upper{LOWERDIR}
+RemainAfterExit=true
+StandardOutput=journal
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/files/overlayfs-unit.mount.in 
b/meta/files/overlayfs-unit.mount.in
new file mode 100644
index 00..1d33b7e39c
--- /dev/null
+++ b/meta/files/overlayfs-unit.mount.in
@@ -0,0 +1,13 @@
+[Unit]
+Description=Overlayfs mount unit
+Requires={CREATE_DIRS_SERVICE}
+After={CREATE_DIRS_SERVICE}
+
+[Mount]
+What=overlay
+Where={LOWERDIR}
+Type=overlay
+Options=lowerdir={LOWERDIR},upperdir={DATA_MOUNT_POINT}/upper{LOWERDIR},workdir={DATA_MOUNT_POINT}/workdir{LOWERDIR}
+
+[Install]
+WantedBy=multi-user.target
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159517): 
https://lists.openembedded.org/g/openembedded-core/message/159517
Mute This Topic: https://lists.openembedded.org/mt/87635154/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 5/8] oeqa/selftest: overlayfs helper function

[Vyacheslav Yurkov]

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 
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index 84242a1605..43415778ce 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -5,16 +5,16 @@
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, runqemu
 
-class OverlayFSTests(OESelftestTestCase):
-"""Overlayfs class usage tests"""
+def getline_qemu(out, line):
+for l in out.split('\n'):
+if line in l:
+return l
 
-def getline_qemu(self, out, line):
-for l in out.split('\n'):
-if line in l:
-return l
+def getline(res, line):
+return getline_qemu(res.output, line)
 
-def getline(self, res, line):
-return self.getline_qemu(res.output, line)
+class OverlayFSTests(OESelftestTestCase):
+"""Overlayfs class usage tests"""
 
 def add_overlay_conf_to_machine(self):
 machine_inc = """
@@ -40,7 +40,7 @@ inherit overlayfs
 self.write_recipeinc('overlayfs-user', overlayfs_recipe_append)
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = self.getline(res, "overlayfs-user was skipped: missing required 
distro features")
+line = getline(res, "overlayfs-user was skipped: missing required 
distro features")
 self.assertTrue("overlayfs" in res.output, msg=res.output)
 self.assertTrue("systemd" in res.output, msg=res.output)
 self.assertTrue("ERROR: Required build target 'core-image-minimal' has 
no buildable providers." in res.output, msg=res.output)
@@ -61,9 +61,9 @@ DISTRO_FEATURES += "systemd overlayfs"
 self.add_overlay_conf_to_machine()
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = self.getline(res, "Unit name mnt-overlay.mount not found in 
systemd unit directories")
+line = getline(res, "Unit name mnt-overlay.mount not found in systemd 
unit directories")
 self.assertTrue(line and line.startswith("WARNING:"), msg=res.output)
-line = self.getline(res, "Not all mount units are installed by the 
BSP")
+line = getline(res, "Not all mount units are installed by the BSP")
 self.assertTrue(line and line.startswith("ERROR:"), msg=res.output)
 
 def test_mount_unit_not_set(self):
@@ -81,7 +81,7 @@ DISTRO_FEATURES += "systemd overlayfs"
 self.write_config(config)
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = self.getline(res, "A recipe uses overlayfs class but there is 
no OVERLAYFS_MOUNT_POINT set in your MACHINE configuration")
+line = getline(res, "A recipe uses overlayfs class but there is no 
OVERLAYFS_MOUNT_POINT set in your MACHINE configuration")
 self.assertTrue(line and line.startswith("Parsing recipes...ERROR:"), 
msg=res.output)
 
 def test_wrong_mount_unit_set(self):
@@ -104,7 +104,7 @@ OVERLAYFS_MOUNT_POINT[usr-share-overlay] = 
"/usr/share/overlay"
 self.set_machine_config(wrong_machine_config)
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = self.getline(res, "Missing required mount point for 
OVERLAYFS_MOUNT_POINT[mnt-overlay] in your MACHINE configuration")
+line = getline(res, "Missing required mount point for 
OVERLAYFS_MOUNT_POINT[mnt-overlay] in your MACHINE configuration")
 self.assertTrue(line and line.startswith("Parsing recipes...ERROR:"), 
msg=res.output)
 
 def test_correct_image(self):
@@ -201,11 +201,11 @@ EOT
 # /usr/share/my-application as an overlay (see overlayfs-user 
recipe)
 status, output = qemu.run_serial("/bin/mount -t tmpfs,overlay")
 
-line = self.getline_qemu(output, "on /mnt/overlay")
+line = getline_qemu(output, "on /mnt/overlay")
 self.assertTrue(line and line.startswith("tmpfs"), msg=output)
 
-line = self.getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/my-application")
+line = getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/my-application")
 self.assertTrue(line and line.startswith("overlay"), msg=output)
 
-line = self.getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/another-overlay-mount")
+line = getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/another-overlay-mount")
 self.assertTrue(line and line.startswith("overlay"), msg=output)
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159514): 
https://lists.openembedded.org/g/openembedded-core/message/159514
Mute This Topic: 

[OE-core] [PATCH 6/8] oeqa/selftest: unit tests for overlayfs-etc

[Vyacheslav Yurkov]

Signed-off-by: Vyacheslav Yurkov 
---
 meta/lib/oeqa/selftest/cases/overlayfs.py | 184 ++
 1 file changed, 184 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py 
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index 43415778ce..82007fade7 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -209,3 +209,187 @@ EOT
 
 line = getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/another-overlay-mount")
 self.assertTrue(line and line.startswith("overlay"), msg=output)
+
+class OverlayFSEtcRunTimeTests(OESelftestTestCase):
+"""overlayfs-etc class tests"""
+
+def test_all_required_variables_set(self):
+"""
+Summary:   Check that required variables are set
+Expected:  Fail when any of required variables is missing
+Author:Vyacheslav Yurkov 
+"""
+
+configBase = """
+DISTRO_FEATURES += "systemd"
+
+# Use systemd as init manager
+VIRTUAL-RUNTIME_init_manager = "systemd"
+
+# enable overlayfs in the kernel
+KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
+
+# Image configuration for overlayfs-etc
+EXTRA_IMAGE_FEATURES += "overlayfs-etc"
+IMAGE_FEATURES:remove = "package-management"
+"""
+configMountPoint = """
+OVERLAYFS_ETC_MOUNT_POINT = "/data"
+"""
+configDevice = """
+OVERLAYFS_ETC_DEVICE = "/dev/mmcblk0p1"
+"""
+
+self.write_config(configBase)
+res = bitbake('core-image-minimal', ignore_status=True)
+line = getline(res, "OVERLAYFS_ETC_MOUNT_POINT must be set in your 
MACHINE configuration")
+self.assertTrue(line, msg=res.output)
+
+self.append_config(configMountPoint)
+res = bitbake('core-image-minimal', ignore_status=True)
+line = getline(res, "OVERLAYFS_ETC_DEVICE must be set in your MACHINE 
configuration")
+self.assertTrue(line, msg=res.output)
+
+self.append_config(configDevice)
+res = bitbake('core-image-minimal', ignore_status=True)
+line = getline(res, "OVERLAYFS_ETC_FSTYPE should contain a valid file 
system type on /dev/mmcblk0p1")
+self.assertTrue(line, msg=res.output)
+
+def test_image_feature_conflict(self):
+"""
+Summary:   Overlayfs-etc is not allowed to be used with 
package-management
+Expected:  Feature conflict
+Author:Vyacheslav Yurkov 
+"""
+
+config = """
+DISTRO_FEATURES += "systemd"
+
+# Use systemd as init manager
+VIRTUAL-RUNTIME_init_manager = "systemd"
+
+# enable overlayfs in the kernel
+KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
+EXTRA_IMAGE_FEATURES += "overlayfs-etc"
+EXTRA_IMAGE_FEATURES += "package-management"
+"""
+
+self.write_config(config)
+
+res = bitbake('core-image-minimal', ignore_status=True)
+line = getline(res, "contains conflicting IMAGE_FEATURES")
+self.assertTrue("overlayfs-etc" in res.output, msg=res.output)
+self.assertTrue("package-management" in res.output, msg=res.output)
+
+def test_image_feature_is_missing_class_included(self):
+configAppend = """
+INHERIT += "overlayfs-etc"
+"""
+self.run_check_image_feature(configAppend)
+
+def test_image_feature_is_missing(self):
+self.run_check_image_feature()
+
+def run_check_image_feature(self, appendToConfig=""):
+"""
+Summary:   Overlayfs-etc class is not applied when image feature is 
not set
+   even if we inherit it directly,
+Expected:  Image is created successfully but /etc is not an overlay
+Author:Vyacheslav Yurkov 
+"""
+
+config = f"""
+DISTRO_FEATURES += "systemd"
+
+# Use systemd as init manager
+VIRTUAL-RUNTIME_init_manager = "systemd"
+
+# enable overlayfs in the kernel
+KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
+
+IMAGE_FSTYPES += "wic"
+WKS_FILE = "overlayfs_etc.wks.in"
+
+EXTRA_IMAGE_FEATURES += "read-only-rootfs"
+# Image configuration for overlayfs-etc
+OVERLAYFS_ETC_MOUNT_POINT = "/data"
+OVERLAYFS_ETC_DEVICE = "/dev/sda3"
+{appendToConfig}
+"""
+
+self.write_config(config)
+
+bitbake('core-image-minimal')
+
+with runqemu('core-image-minimal', image_fstype='wic') as qemu:
+status, output = qemu.run_serial("/bin/mount")
+
+line = getline_qemu(output, "upperdir=/data/overlay-etc/upper")
+self.assertFalse(line, msg=output)
+
+def test_sbin_init_preinit(self):
+self.run_sbin_init(False)
+
+def test_sbin_init_original(self):
+self.run_sbin_init(True)
+
+def run_sbin_init(self, origInit):
+"""
+Summary:   Confirm we can replace original init and mount overlay on 
top of /etc
+Expected:  Image is created successfully and /etc is mounted as an 
overlay
+Author:Vyacheslav Yurkov 
+"""
+
+config = """
+DISTRO_FEATURES 

[OE-core] [PATCH 7/8] overlayfs: update notes on /etc

[Vyacheslav Yurkov]

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
@@ -31,6 +31,7 @@
 #   OVERLAYFS_WRITABLE_PATHS[mnt-overlay] = "/usr/share/another-application"
 #
 # Note: the class does not support /etc directory itself, because systemd 
depends on it
+# For /etc directory use overlayfs-etc class
 
 REQUIRED_DISTRO_FEATURES += "systemd overlayfs"
 
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159516): 
https://lists.openembedded.org/g/openembedded-core/message/159516
Mute This Topic: https://lists.openembedded.org/mt/87635152/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 4/8] image: add overlayfs-etc image feature

[Vyacheslav Yurkov]

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 8a46b4852c..2b0ce4a988 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -15,6 +15,7 @@ IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 
'container', 'image-contain
 IMGCLASSES += "image_types_wic"
 IMGCLASSES += "rootfs-postcommands"
 IMGCLASSES += "image-postinst-intercepts"
+IMGCLASSES += "overlayfs-etc"
 inherit ${IMGCLASSES}
 
 TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
@@ -33,7 +34,7 @@ INHIBIT_DEFAULT_DEPS = "1"
 # IMAGE_FEATURES may contain any available package group
 IMAGE_FEATURES ?= ""
 IMAGE_FEATURES[type] = "list"
-IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
allow-empty-password allow-root-login post-install-logging"
+IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
allow-empty-password allow-root-login post-install-logging overlayfs-etc"
 
 # Generate companion debugfs?
 IMAGE_GEN_DEBUGFS ?= "0"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159513): 
https://lists.openembedded.org/g/openembedded-core/message/159513
Mute This Topic: https://lists.openembedded.org/mt/87635148/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/8] wic: image for overlayfs-etc tests

[Vyacheslav Yurkov]

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 --git a/meta-selftest/wic/overlayfs_etc.wks.in 
b/meta-selftest/wic/overlayfs_etc.wks.in
new file mode 100644
index 00..1e1e5836e7
--- /dev/null
+++ b/meta-selftest/wic/overlayfs_etc.wks.in
@@ -0,0 +1,4 @@
+part /boot --active --source bootimg-biosplusefi --ondisk sda 
--sourceparams="loader=grub-efi" --align 1024
+part / --source rootfs --ondisk sda --fstype=ext4 --use-uuid --align 1024
+part --ondisk sda --fstype=ext4 --size=5 --align 1024
+bootloader --ptable gpt --timeout=1 --append="rootfstype=ext4 
console=ttyS0,115200 console=tty0 ${OVERLAYFS_INIT_OPTION}"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159512): 
https://lists.openembedded.org/g/openembedded-core/message/159512
Mute This Topic: https://lists.openembedded.org/mt/87635147/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/8] overlayfs-etc: mount etc as overlayfs

[Vyacheslav Yurkov]

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 | 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 meta/classes/overlayfs-etc.bbclass

diff --git a/meta/classes/overlayfs-etc.bbclass 
b/meta/classes/overlayfs-etc.bbclass
new file mode 100644
index 00..4ced07ba11
--- /dev/null
+++ b/meta/classes/overlayfs-etc.bbclass
@@ -0,0 +1,76 @@
+# Class for setting up /etc in overlayfs
+#
+# In order to have /etc directory in overlayfs a special handling at early 
boot stage is required
+# The idea is to supply a custom init script that mounts /etc before launching 
actual init program,
+# because the latter already requires /etc to be mounted
+#
+# The configuration must be machine specific. You should at least set these 
three variables:
+#   OVERLAYFS_ETC_MOUNT_POINT ?= "/data"
+#   OVERLAYFS_ETC_FSTYPE ?= "ext4"
+#   OVERLAYFS_ETC_DEVICE ?= "/dev/mmcblk0p2"
+#
+# To control more mount options you should consider setting mount options:
+#   OVERLAYFS_ETC_MOUNT_OPTIONS ?= "defaults"
+#
+# The class provides two options for /sbin/init generation
+# 1. Default option is to rename original /sbin/init to /sbin/init.orig and 
place generated init under
+#original name, i.e. /sbin/init. It has an advantage that you won't need 
to change any kernel
+#parameters in order to make it work, but it poses a restriction that 
package-management can't
+#be used, becaause updating init manager would remove generated script
+# 2. If you are would like to keep original init as is, you can set
+#OVERLAYFS_ETC_USE_ORIG_INIT_NAME = "0"
+#Then generated init will be named /sbin/preinit and you would need to 
extend you kernel parameters
+#manually in your bootloader configuration.
+#
+# Regardless which mode you choose, update and migration strategy of 
configuration files under /etc
+# overlay is out of scope of this class
+
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", 
"overlayfs-etc", "create_overlayfs_etc_preinit;", "", d)}'
+IMAGE_FEATURES_CONFLICTS_overlayfs-etc = "package-management"
+
+OVERLAYFS_ETC_MOUNT_POINT ??= ""
+OVERLAYFS_ETC_FSTYPE ??= ""
+OVERLAYFS_ETC_DEVICE ??= ""
+OVERLAYFS_ETC_USE_ORIG_INIT_NAME ??= "1"
+OVERLAYFS_ETC_MOUNT_OPTIONS ??= "defaults"
+OVERLAYFS_ETC_INIT_TEMPLATE ??= 
"${COREBASE}/meta/files/overlayfs-etc-preinit.sh.in"
+
+python create_overlayfs_etc_preinit() {
+overlayEtcMountPoint = d.getVar("OVERLAYFS_ETC_MOUNT_POINT")
+overlayEtcFsType = d.getVar("OVERLAYFS_ETC_FSTYPE")
+overlayEtcDevice = d.getVar("OVERLAYFS_ETC_DEVICE")
+
+if not overlayEtcMountPoint:
+bb.fatal("OVERLAYFS_ETC_MOUNT_POINT must be set in your MACHINE 
configuration")
+if not overlayEtcDevice:
+bb.fatal("OVERLAYFS_ETC_DEVICE must be set in your MACHINE 
configuration")
+if not overlayEtcFsType:
+bb.fatal("OVERLAYFS_ETC_FSTYPE should contain a valid file system type 
on {0}".format(overlayEtcDevice))
+
+with open(d.getVar("OVERLAYFS_ETC_INIT_TEMPLATE"), "r") as f:
+PreinitTemplate = f.read()
+
+useOrigInit = 
oe.types.boolean(d.getVar('OVERLAYFS_ETC_USE_ORIG_INIT_NAME'))
+preinitPath = oe.path.join(d.getVar("IMAGE_ROOTFS"), 
d.getVar("base_sbindir"), "preinit")
+initBaseName = oe.path.join(d.getVar("base_sbindir"), "init")
+origInitNameSuffix = ".orig"
+
+args = {
+'OVERLAYFS_ETC_MOUNT_POINT': overlayEtcMountPoint,
+'OVERLAYFS_ETC_MOUNT_OPTIONS': d.getVar('OVERLAYFS_ETC_MOUNT_OPTIONS'),
+'OVERLAYFS_ETC_FSTYPE': overlayEtcFsType,
+'OVERLAYFS_ETC_DEVICE': overlayEtcDevice,
+'SBIN_INIT_NAME': initBaseName + origInitNameSuffix if useOrigInit 
else initBaseName
+}
+
+if useOrigInit:
+# rename original /sbin/init
+origInit = oe.path.join(d.getVar("IMAGE_ROOTFS"), initBaseName)
+bb.debug(1, "rootfs path %s, init path %s, test %s" % 
(d.getVar('IMAGE_ROOTFS'), origInit, d.getVar("IMAGE_ROOTFS")))
+bb.utils.rename(origInit, origInit + origInitNameSuffix)
+preinitPath = origInit
+
+with open(preinitPath, 'w') as f:
+f.write(PreinitTemplate.format(**args))
+os.chmod(preinitPath, 0o755)
+}
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159511): 
https://lists.openembedded.org/g/openembedded-core/message/159511
Mute This Topic: https://lists.openembedded.org/mt/87635146/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/8] files: add overlayfs-etc-preinit.sh.in

[Vyacheslav Yurkov]

A template init script for overlayfs-etc class

Signed-off-by: Vyacheslav Yurkov 
---
 meta/files/overlayfs-etc-preinit.sh.in | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 meta/files/overlayfs-etc-preinit.sh.in

diff --git a/meta/files/overlayfs-etc-preinit.sh.in 
b/meta/files/overlayfs-etc-preinit.sh.in
new file mode 100644
index 00..2ebb6c9224
--- /dev/null
+++ b/meta/files/overlayfs-etc-preinit.sh.in
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+echo "PREINIT: Start"
+
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+mount -o remount,rw /
+
+mkdir -p /proc
+mkdir -p /sys
+mkdir -p /run
+mkdir -p /var/run
+
+mount -t proc proc /proc
+mount -t sysfs sysfs /sys
+
+[ -z "$CONSOLE" ] && CONSOLE="/dev/console"
+
+mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}
+if mount -n -t {OVERLAYFS_ETC_FSTYPE} -o {OVERLAYFS_ETC_MOUNT_OPTIONS} 
{OVERLAYFS_ETC_DEVICE} {OVERLAYFS_ETC_MOUNT_POINT}
+then
+mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper
+mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/work
+mount -n -t overlay -o 
upperdir={OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper,lowerdir=/etc,workdir={OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/work
 {OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper /etc || echo "PREINIT: Mounting 
etc-overlay failed!"
+else
+echo "PREINIT: Mounting  failed!"
+fi
+
+echo "PREINIT: done; starting "
+exec {SBIN_INIT_NAME}
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159510): 
https://lists.openembedded.org/g/openembedded-core/message/159510
Mute This Topic: https://lists.openembedded.org/mt/87635144/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 0/8] Pull request (cover letter only)

[Vyacheslav Yurkov]

This is a V3 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 1a6c2a7345199d77ad5aeac8ad337ed80a8aa39b:

  build-appliance-image: Update to master head revision (2021-12-09 13:56:07 
+)

are available in the Git repository at:

  git://github.com/UVV-gh/openembedded-core feature/overlayfs-etc
  https://github.com/UVV-gh/openembedded-core/tree/feature/overlayfs-etc

Vyacheslav Yurkov (8):
  files: add overlayfs-etc-preinit.sh.in
  overlayfs-etc: mount etc as overlayfs
  wic: image for overlayfs-etc tests
  image: add overlayfs-etc image feature
  oeqa/selftest: overlayfs helper function
  oeqa/selftest: unit tests for overlayfs-etc
  overlayfs: update notes on /etc
  overlayfs: move templates to files directory

 meta-selftest/wic/overlayfs_etc.wks.in   |   4 +
 meta/classes/image.bbclass   |   3 +-
 meta/classes/overlayfs-etc.bbclass   |  76 +++
 meta/classes/overlayfs.bbclass   |  53 +
 meta/files/overlayfs-all-overlays.service.in |  12 ++
 meta/files/overlayfs-create-dirs.service.in  |  14 ++
 meta/files/overlayfs-etc-preinit.sh.in   |  29 +++
 meta/files/overlayfs-unit.mount.in   |  13 ++
 meta/lib/oeqa/selftest/cases/overlayfs.py| 216 +--
 9 files changed, 361 insertions(+), 59 deletions(-)
 create mode 100644 meta-selftest/wic/overlayfs_etc.wks.in
 create mode 100644 meta/classes/overlayfs-etc.bbclass
 create mode 100644 meta/files/overlayfs-all-overlays.service.in
 create mode 100644 meta/files/overlayfs-create-dirs.service.in
 create mode 100644 meta/files/overlayfs-etc-preinit.sh.in
 create mode 100644 meta/files/overlayfs-unit.mount.in

-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159509): 
https://lists.openembedded.org/g/openembedded-core/message/159509
Mute This Topic: https://lists.openembedded.org/mt/87635143/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/8] files: add preinit.sh.in

[Richard Purdie]

On Fri, 2021-12-10 at 12:50 +0100, Vyacheslav Yurkov wrote:
> A template init script for overlayfs-etc class
> 
> Signed-off-by: Vyacheslav Yurkov 
> ---
>  meta/files/preinit.sh.in | 29 +
>  1 file changed, 29 insertions(+)
>  create mode 100644 meta/files/preinit.sh.in

Can you call this something like overlayfs-etc-preinit.sh please?

That way we can know roughly what is using it!

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159508): 
https://lists.openembedded.org/g/openembedded-core/message/159508
Mute This Topic: https://lists.openembedded.org/mt/87634116/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] perf: Tweak for mips n64

[Richard Purdie]

With the changes to binutils, perf's direct calls to ld break for mips n64.
We already have tweaks for n32 so match those with the ones for n64.

Signed-off-by: Richard Purdie 
---
 meta/recipes-kernel/perf/perf.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 7bbc1ad70c5..ec0c6efe15f 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -125,9 +125,11 @@ PERF_SRC ?= "Makefile \
 
 PERF_EXTRA_LDFLAGS = ""
 
-# MIPS N32
+# MIPS N32/N64
 PERF_EXTRA_LDFLAGS:mipsarchn32eb = "-m elf32btsmipn32"
 PERF_EXTRA_LDFLAGS:mipsarchn32el = "-m elf32ltsmipn32"
+PERF_EXTRA_LDFLAGS:mipsarchn64eb = "-m elf64btsmip"
+PERF_EXTRA_LDFLAGS:mipsarchn64el = "-m elf64ltsmip"
 
 do_compile() {
# Linux kernel build system is expected to do the right thing
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159507): 
https://lists.openembedded.org/g/openembedded-core/message/159507
Mute This Topic: https://lists.openembedded.org/mt/87634357/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 7/8] overlayfs: update notes on /etc

[Vyacheslav Yurkov]

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
@@ -31,6 +31,7 @@
 #   OVERLAYFS_WRITABLE_PATHS[mnt-overlay] = "/usr/share/another-application"
 #
 # Note: the class does not support /etc directory itself, because systemd 
depends on it
+# For /etc directory use overlayfs-etc class
 
 REQUIRED_DISTRO_FEATURES += "systemd overlayfs"
 
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159505): 
https://lists.openembedded.org/g/openembedded-core/message/159505
Mute This Topic: https://lists.openembedded.org/mt/87634123/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 6/8] oeqa/selftest: unit tests for overlayfs-etc

[Vyacheslav Yurkov]

Signed-off-by: Vyacheslav Yurkov 
---
 meta/lib/oeqa/selftest/cases/overlayfs.py | 184 ++
 1 file changed, 184 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py 
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index 43415778ce..82007fade7 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -209,3 +209,187 @@ EOT
 
 line = getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/another-overlay-mount")
 self.assertTrue(line and line.startswith("overlay"), msg=output)
+
+class OverlayFSEtcRunTimeTests(OESelftestTestCase):
+"""overlayfs-etc class tests"""
+
+def test_all_required_variables_set(self):
+"""
+Summary:   Check that required variables are set
+Expected:  Fail when any of required variables is missing
+Author:Vyacheslav Yurkov 
+"""
+
+configBase = """
+DISTRO_FEATURES += "systemd"
+
+# Use systemd as init manager
+VIRTUAL-RUNTIME_init_manager = "systemd"
+
+# enable overlayfs in the kernel
+KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
+
+# Image configuration for overlayfs-etc
+EXTRA_IMAGE_FEATURES += "overlayfs-etc"
+IMAGE_FEATURES:remove = "package-management"
+"""
+configMountPoint = """
+OVERLAYFS_ETC_MOUNT_POINT = "/data"
+"""
+configDevice = """
+OVERLAYFS_ETC_DEVICE = "/dev/mmcblk0p1"
+"""
+
+self.write_config(configBase)
+res = bitbake('core-image-minimal', ignore_status=True)
+line = getline(res, "OVERLAYFS_ETC_MOUNT_POINT must be set in your 
MACHINE configuration")
+self.assertTrue(line, msg=res.output)
+
+self.append_config(configMountPoint)
+res = bitbake('core-image-minimal', ignore_status=True)
+line = getline(res, "OVERLAYFS_ETC_DEVICE must be set in your MACHINE 
configuration")
+self.assertTrue(line, msg=res.output)
+
+self.append_config(configDevice)
+res = bitbake('core-image-minimal', ignore_status=True)
+line = getline(res, "OVERLAYFS_ETC_FSTYPE should contain a valid file 
system type on /dev/mmcblk0p1")
+self.assertTrue(line, msg=res.output)
+
+def test_image_feature_conflict(self):
+"""
+Summary:   Overlayfs-etc is not allowed to be used with 
package-management
+Expected:  Feature conflict
+Author:Vyacheslav Yurkov 
+"""
+
+config = """
+DISTRO_FEATURES += "systemd"
+
+# Use systemd as init manager
+VIRTUAL-RUNTIME_init_manager = "systemd"
+
+# enable overlayfs in the kernel
+KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
+EXTRA_IMAGE_FEATURES += "overlayfs-etc"
+EXTRA_IMAGE_FEATURES += "package-management"
+"""
+
+self.write_config(config)
+
+res = bitbake('core-image-minimal', ignore_status=True)
+line = getline(res, "contains conflicting IMAGE_FEATURES")
+self.assertTrue("overlayfs-etc" in res.output, msg=res.output)
+self.assertTrue("package-management" in res.output, msg=res.output)
+
+def test_image_feature_is_missing_class_included(self):
+configAppend = """
+INHERIT += "overlayfs-etc"
+"""
+self.run_check_image_feature(configAppend)
+
+def test_image_feature_is_missing(self):
+self.run_check_image_feature()
+
+def run_check_image_feature(self, appendToConfig=""):
+"""
+Summary:   Overlayfs-etc class is not applied when image feature is 
not set
+   even if we inherit it directly,
+Expected:  Image is created successfully but /etc is not an overlay
+Author:Vyacheslav Yurkov 
+"""
+
+config = f"""
+DISTRO_FEATURES += "systemd"
+
+# Use systemd as init manager
+VIRTUAL-RUNTIME_init_manager = "systemd"
+
+# enable overlayfs in the kernel
+KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
+
+IMAGE_FSTYPES += "wic"
+WKS_FILE = "overlayfs_etc.wks.in"
+
+EXTRA_IMAGE_FEATURES += "read-only-rootfs"
+# Image configuration for overlayfs-etc
+OVERLAYFS_ETC_MOUNT_POINT = "/data"
+OVERLAYFS_ETC_DEVICE = "/dev/sda3"
+{appendToConfig}
+"""
+
+self.write_config(config)
+
+bitbake('core-image-minimal')
+
+with runqemu('core-image-minimal', image_fstype='wic') as qemu:
+status, output = qemu.run_serial("/bin/mount")
+
+line = getline_qemu(output, "upperdir=/data/overlay-etc/upper")
+self.assertFalse(line, msg=output)
+
+def test_sbin_init_preinit(self):
+self.run_sbin_init(False)
+
+def test_sbin_init_original(self):
+self.run_sbin_init(True)
+
+def run_sbin_init(self, origInit):
+"""
+Summary:   Confirm we can replace original init and mount overlay on 
top of /etc
+Expected:  Image is created successfully and /etc is mounted as an 
overlay
+Author:Vyacheslav Yurkov 
+"""
+
+config = """
+DISTRO_FEATURES 

[OE-core] [PATCH 8/8] overlayfs: move templates to files directory

[Vyacheslav Yurkov]

Signed-off-by: Vyacheslav Yurkov 
---
 meta/classes/overlayfs.bbclass   | 52 
 meta/files/overlayfs-all-overlays.service.in | 12 +
 meta/files/overlayfs-create-dirs.service.in  | 14 ++
 meta/files/overlayfs-unit.mount.in   | 13 +
 4 files changed, 49 insertions(+), 42 deletions(-)
 create mode 100644 meta/files/overlayfs-all-overlays.service.in
 create mode 100644 meta/files/overlayfs-create-dirs.service.in
 create mode 100644 meta/files/overlayfs-unit.mount.in

diff --git a/meta/classes/overlayfs.bbclass b/meta/classes/overlayfs.bbclass
index f1b8086ea8..4a860f7308 100644
--- a/meta/classes/overlayfs.bbclass
+++ b/meta/classes/overlayfs.bbclass
@@ -37,51 +37,19 @@ REQUIRED_DISTRO_FEATURES += "systemd overlayfs"
 
 inherit systemd features_check
 
+OVERLAYFS_CREATE_DIRS_TEMPLATE ??= 
"${COREBASE}/meta/files/overlayfs-create-dirs.service.in"
+OVERLAYFS_MOUNT_UNIT_TEMPLATE ??= 
"${COREBASE}/meta/files/overlayfs-unit.mount.in"
+OVERLAYFS_ALL_OVERLAYS_TEMPLATE ??= 
"${COREBASE}/meta/files/overlayfs-all-overlays.service.in"
+
 python do_create_overlayfs_units() {
 from oe.overlayfs import mountUnitName
 
-CreateDirsUnitTemplate = """[Unit]
-Description=Overlayfs directories setup
-Requires={DATA_MOUNT_UNIT}
-After={DATA_MOUNT_UNIT}
-DefaultDependencies=no
-
-[Service]
-Type=oneshot
-ExecStart=mkdir -p {DATA_MOUNT_POINT}/workdir{LOWERDIR} && mkdir -p 
{DATA_MOUNT_POINT}/upper{LOWERDIR}
-RemainAfterExit=true
-StandardOutput=journal
-
-[Install]
-WantedBy=multi-user.target
-"""
-MountUnitTemplate = """[Unit]
-Description=Overlayfs mount unit
-Requires={CREATE_DIRS_SERVICE}
-After={CREATE_DIRS_SERVICE}
-
-[Mount]
-What=overlay
-Where={LOWERDIR}
-Type=overlay
-Options=lowerdir={LOWERDIR},upperdir={DATA_MOUNT_POINT}/upper{LOWERDIR},workdir={DATA_MOUNT_POINT}/workdir{LOWERDIR}
-
-[Install]
-WantedBy=multi-user.target
-"""
-AllOverlaysTemplate = """[Unit]
-Description=Groups all overlays required by {PN} in one unit
-After={ALL_OVERLAYFS_UNITS}
-Requires={ALL_OVERLAYFS_UNITS}
-
-[Service]
-Type=oneshot
-ExecStart=/bin/true
-RemainAfterExit=true
-
-[Install]
-WantedBy=local-fs.target
-"""
+with open(d.getVar("OVERLAYFS_CREATE_DIRS_TEMPLATE"), "r") as f:
+CreateDirsUnitTemplate = f.read()
+with open(d.getVar("OVERLAYFS_MOUNT_UNIT_TEMPLATE"), "r") as f:
+MountUnitTemplate = f.read()
+with open(d.getVar("OVERLAYFS_ALL_OVERLAYS_TEMPLATE"), "r") as f:
+AllOverlaysTemplate = f.read()
 
 def prepareUnits(data, lower):
 from oe.overlayfs import helperUnitName
diff --git a/meta/files/overlayfs-all-overlays.service.in 
b/meta/files/overlayfs-all-overlays.service.in
new file mode 100644
index 00..74ee4e90ae
--- /dev/null
+++ b/meta/files/overlayfs-all-overlays.service.in
@@ -0,0 +1,12 @@
+[Unit]
+Description=Groups all overlays required by {PN} in one unit
+After={ALL_OVERLAYFS_UNITS}
+Requires={ALL_OVERLAYFS_UNITS}
+
+[Service]
+Type=oneshot
+ExecStart=/bin/true
+RemainAfterExit=true
+
+[Install]
+WantedBy=local-fs.target
diff --git a/meta/files/overlayfs-create-dirs.service.in 
b/meta/files/overlayfs-create-dirs.service.in
new file mode 100644
index 00..17204145f2
--- /dev/null
+++ b/meta/files/overlayfs-create-dirs.service.in
@@ -0,0 +1,14 @@
+[Unit]
+Description=Overlayfs directories setup
+Requires={DATA_MOUNT_UNIT}
+After={DATA_MOUNT_UNIT}
+DefaultDependencies=no
+
+[Service]
+Type=oneshot
+ExecStart=mkdir -p {DATA_MOUNT_POINT}/workdir{LOWERDIR} && mkdir -p 
{DATA_MOUNT_POINT}/upper{LOWERDIR}
+RemainAfterExit=true
+StandardOutput=journal
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/files/overlayfs-unit.mount.in 
b/meta/files/overlayfs-unit.mount.in
new file mode 100644
index 00..1d33b7e39c
--- /dev/null
+++ b/meta/files/overlayfs-unit.mount.in
@@ -0,0 +1,13 @@
+[Unit]
+Description=Overlayfs mount unit
+Requires={CREATE_DIRS_SERVICE}
+After={CREATE_DIRS_SERVICE}
+
+[Mount]
+What=overlay
+Where={LOWERDIR}
+Type=overlay
+Options=lowerdir={LOWERDIR},upperdir={DATA_MOUNT_POINT}/upper{LOWERDIR},workdir={DATA_MOUNT_POINT}/workdir{LOWERDIR}
+
+[Install]
+WantedBy=multi-user.target
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159506): 
https://lists.openembedded.org/g/openembedded-core/message/159506
Mute This Topic: https://lists.openembedded.org/mt/87634124/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 4/8] image: add overlayfs-etc image feature

[Vyacheslav Yurkov]

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 8a46b4852c..2b0ce4a988 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -15,6 +15,7 @@ IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 
'container', 'image-contain
 IMGCLASSES += "image_types_wic"
 IMGCLASSES += "rootfs-postcommands"
 IMGCLASSES += "image-postinst-intercepts"
+IMGCLASSES += "overlayfs-etc"
 inherit ${IMGCLASSES}
 
 TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
@@ -33,7 +34,7 @@ INHIBIT_DEFAULT_DEPS = "1"
 # IMAGE_FEATURES may contain any available package group
 IMAGE_FEATURES ?= ""
 IMAGE_FEATURES[type] = "list"
-IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
allow-empty-password allow-root-login post-install-logging"
+IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
allow-empty-password allow-root-login post-install-logging overlayfs-etc"
 
 # Generate companion debugfs?
 IMAGE_GEN_DEBUGFS ?= "0"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159502): 
https://lists.openembedded.org/g/openembedded-core/message/159502
Mute This Topic: https://lists.openembedded.org/mt/87634119/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 5/8] oeqa/selftest: overlayfs helper function

[Vyacheslav Yurkov]

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 
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index 84242a1605..43415778ce 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -5,16 +5,16 @@
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, runqemu
 
-class OverlayFSTests(OESelftestTestCase):
-"""Overlayfs class usage tests"""
+def getline_qemu(out, line):
+for l in out.split('\n'):
+if line in l:
+return l
 
-def getline_qemu(self, out, line):
-for l in out.split('\n'):
-if line in l:
-return l
+def getline(res, line):
+return getline_qemu(res.output, line)
 
-def getline(self, res, line):
-return self.getline_qemu(res.output, line)
+class OverlayFSTests(OESelftestTestCase):
+"""Overlayfs class usage tests"""
 
 def add_overlay_conf_to_machine(self):
 machine_inc = """
@@ -40,7 +40,7 @@ inherit overlayfs
 self.write_recipeinc('overlayfs-user', overlayfs_recipe_append)
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = self.getline(res, "overlayfs-user was skipped: missing required 
distro features")
+line = getline(res, "overlayfs-user was skipped: missing required 
distro features")
 self.assertTrue("overlayfs" in res.output, msg=res.output)
 self.assertTrue("systemd" in res.output, msg=res.output)
 self.assertTrue("ERROR: Required build target 'core-image-minimal' has 
no buildable providers." in res.output, msg=res.output)
@@ -61,9 +61,9 @@ DISTRO_FEATURES += "systemd overlayfs"
 self.add_overlay_conf_to_machine()
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = self.getline(res, "Unit name mnt-overlay.mount not found in 
systemd unit directories")
+line = getline(res, "Unit name mnt-overlay.mount not found in systemd 
unit directories")
 self.assertTrue(line and line.startswith("WARNING:"), msg=res.output)
-line = self.getline(res, "Not all mount units are installed by the 
BSP")
+line = getline(res, "Not all mount units are installed by the BSP")
 self.assertTrue(line and line.startswith("ERROR:"), msg=res.output)
 
 def test_mount_unit_not_set(self):
@@ -81,7 +81,7 @@ DISTRO_FEATURES += "systemd overlayfs"
 self.write_config(config)
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = self.getline(res, "A recipe uses overlayfs class but there is 
no OVERLAYFS_MOUNT_POINT set in your MACHINE configuration")
+line = getline(res, "A recipe uses overlayfs class but there is no 
OVERLAYFS_MOUNT_POINT set in your MACHINE configuration")
 self.assertTrue(line and line.startswith("Parsing recipes...ERROR:"), 
msg=res.output)
 
 def test_wrong_mount_unit_set(self):
@@ -104,7 +104,7 @@ OVERLAYFS_MOUNT_POINT[usr-share-overlay] = 
"/usr/share/overlay"
 self.set_machine_config(wrong_machine_config)
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = self.getline(res, "Missing required mount point for 
OVERLAYFS_MOUNT_POINT[mnt-overlay] in your MACHINE configuration")
+line = getline(res, "Missing required mount point for 
OVERLAYFS_MOUNT_POINT[mnt-overlay] in your MACHINE configuration")
 self.assertTrue(line and line.startswith("Parsing recipes...ERROR:"), 
msg=res.output)
 
 def test_correct_image(self):
@@ -201,11 +201,11 @@ EOT
 # /usr/share/my-application as an overlay (see overlayfs-user 
recipe)
 status, output = qemu.run_serial("/bin/mount -t tmpfs,overlay")
 
-line = self.getline_qemu(output, "on /mnt/overlay")
+line = getline_qemu(output, "on /mnt/overlay")
 self.assertTrue(line and line.startswith("tmpfs"), msg=output)
 
-line = self.getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/my-application")
+line = getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/my-application")
 self.assertTrue(line and line.startswith("overlay"), msg=output)
 
-line = self.getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/another-overlay-mount")
+line = getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/another-overlay-mount")
 self.assertTrue(line and line.startswith("overlay"), msg=output)
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159503): 
https://lists.openembedded.org/g/openembedded-core/message/159503
Mute This Topic: 

[OE-core] [PATCH 3/8] wic: image for overlayfs-etc tests

[Vyacheslav Yurkov]

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 --git a/meta-selftest/wic/overlayfs_etc.wks.in 
b/meta-selftest/wic/overlayfs_etc.wks.in
new file mode 100644
index 00..1e1e5836e7
--- /dev/null
+++ b/meta-selftest/wic/overlayfs_etc.wks.in
@@ -0,0 +1,4 @@
+part /boot --active --source bootimg-biosplusefi --ondisk sda 
--sourceparams="loader=grub-efi" --align 1024
+part / --source rootfs --ondisk sda --fstype=ext4 --use-uuid --align 1024
+part --ondisk sda --fstype=ext4 --size=5 --align 1024
+bootloader --ptable gpt --timeout=1 --append="rootfstype=ext4 
console=ttyS0,115200 console=tty0 ${OVERLAYFS_INIT_OPTION}"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159501): 
https://lists.openembedded.org/g/openembedded-core/message/159501
Mute This Topic: https://lists.openembedded.org/mt/87634118/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/8] files: add preinit.sh.in

[Vyacheslav Yurkov]

A template init script for overlayfs-etc class

Signed-off-by: Vyacheslav Yurkov 
---
 meta/files/preinit.sh.in | 29 +
 1 file changed, 29 insertions(+)
 create mode 100644 meta/files/preinit.sh.in

diff --git a/meta/files/preinit.sh.in b/meta/files/preinit.sh.in
new file mode 100644
index 00..2ebb6c9224
--- /dev/null
+++ b/meta/files/preinit.sh.in
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+echo "PREINIT: Start"
+
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+mount -o remount,rw /
+
+mkdir -p /proc
+mkdir -p /sys
+mkdir -p /run
+mkdir -p /var/run
+
+mount -t proc proc /proc
+mount -t sysfs sysfs /sys
+
+[ -z "$CONSOLE" ] && CONSOLE="/dev/console"
+
+mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}
+if mount -n -t {OVERLAYFS_ETC_FSTYPE} -o {OVERLAYFS_ETC_MOUNT_OPTIONS} 
{OVERLAYFS_ETC_DEVICE} {OVERLAYFS_ETC_MOUNT_POINT}
+then
+mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper
+mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/work
+mount -n -t overlay -o 
upperdir={OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper,lowerdir=/etc,workdir={OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/work
 {OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper /etc || echo "PREINIT: Mounting 
etc-overlay failed!"
+else
+echo "PREINIT: Mounting  failed!"
+fi
+
+echo "PREINIT: done; starting "
+exec {SBIN_INIT_NAME}
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159499): 
https://lists.openembedded.org/g/openembedded-core/message/159499
Mute This Topic: https://lists.openembedded.org/mt/87634116/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/8] overlayfs-etc: mount etc as overlayfs

[Vyacheslav Yurkov]

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 | 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 meta/classes/overlayfs-etc.bbclass

diff --git a/meta/classes/overlayfs-etc.bbclass 
b/meta/classes/overlayfs-etc.bbclass
new file mode 100644
index 00..5e89339269
--- /dev/null
+++ b/meta/classes/overlayfs-etc.bbclass
@@ -0,0 +1,76 @@
+# Class for setting up /etc in overlayfs
+#
+# In order to have /etc directory in overlayfs a special handling at early 
boot stage is required
+# The idea is to supply a custom init script that mounts /etc before launching 
actual init program,
+# because the latter already requires /etc to be mounted
+#
+# The configuration must be machine specific. You should at least set these 
three variables:
+#   OVERLAYFS_ETC_MOUNT_POINT ?= "/data"
+#   OVERLAYFS_ETC_FSTYPE ?= "ext4"
+#   OVERLAYFS_ETC_DEVICE ?= "/dev/mmcblk0p2"
+#
+# To control more mount options you should consider setting mount options:
+#   OVERLAYFS_ETC_MOUNT_OPTIONS ?= "defaults"
+#
+# The class provides two options for /sbin/init generation
+# 1. Default option is to rename original /sbin/init to /sbin/init.orig and 
place generated init under
+#original name, i.e. /sbin/init. It has an advantage that you won't need 
to change any kernel
+#parameters in order to make it work, but it poses a restriction that 
package-management can't
+#be used, becaause updating init manager would remove generated script
+# 2. If you are would like to keep original init as is, you can set
+#OVERLAYFS_ETC_USE_ORIG_INIT_NAME = "0"
+#Then generated init will be named /sbin/preinit and you would need to 
extend you kernel parameters
+#manually in your bootloader configuration.
+#
+# Regardless which mode you choose, update and migration strategy of 
configuration files under /etc
+# overlay is out of scope of this class
+
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", 
"overlayfs-etc", "create_overlayfs_etc_preinit;", "", d)}'
+IMAGE_FEATURES_CONFLICTS_overlayfs-etc = "package-management"
+
+OVERLAYFS_ETC_MOUNT_POINT ??= ""
+OVERLAYFS_ETC_FSTYPE ??= ""
+OVERLAYFS_ETC_DEVICE ??= ""
+OVERLAYFS_ETC_USE_ORIG_INIT_NAME ??= "1"
+OVERLAYFS_ETC_MOUNT_OPTIONS ??= "defaults"
+OVERLAYFS_ETC_INIT_TEMPLATE ??= "${COREBASE}/meta/files/preinit.sh.in"
+
+python create_overlayfs_etc_preinit() {
+overlayEtcMountPoint = d.getVar("OVERLAYFS_ETC_MOUNT_POINT")
+overlayEtcFsType = d.getVar("OVERLAYFS_ETC_FSTYPE")
+overlayEtcDevice = d.getVar("OVERLAYFS_ETC_DEVICE")
+
+if not overlayEtcMountPoint:
+bb.fatal("OVERLAYFS_ETC_MOUNT_POINT must be set in your MACHINE 
configuration")
+if not overlayEtcDevice:
+bb.fatal("OVERLAYFS_ETC_DEVICE must be set in your MACHINE 
configuration")
+if not overlayEtcFsType:
+bb.fatal("OVERLAYFS_ETC_FSTYPE should contain a valid file system type 
on {0}".format(overlayEtcDevice))
+
+with open(d.getVar("OVERLAYFS_ETC_INIT_TEMPLATE"), "r") as f:
+PreinitTemplate = f.read()
+
+useOrigInit = 
oe.types.boolean(d.getVar('OVERLAYFS_ETC_USE_ORIG_INIT_NAME'))
+preinitPath = oe.path.join(d.getVar("IMAGE_ROOTFS"), 
d.getVar("base_sbindir"), "preinit")
+initBaseName = oe.path.join(d.getVar("base_sbindir"), "init")
+origInitNameSuffix = ".orig"
+
+args = {
+'OVERLAYFS_ETC_MOUNT_POINT': overlayEtcMountPoint,
+'OVERLAYFS_ETC_MOUNT_OPTIONS': d.getVar('OVERLAYFS_ETC_MOUNT_OPTIONS'),
+'OVERLAYFS_ETC_FSTYPE': overlayEtcFsType,
+'OVERLAYFS_ETC_DEVICE': overlayEtcDevice,
+'SBIN_INIT_NAME': initBaseName + origInitNameSuffix if useOrigInit 
else initBaseName
+}
+
+if useOrigInit:
+# rename original /sbin/init
+origInit = oe.path.join(d.getVar("IMAGE_ROOTFS"), initBaseName)
+bb.debug(1, "rootfs path %s, init path %s, test %s" % 
(d.getVar('IMAGE_ROOTFS'), origInit, d.getVar("IMAGE_ROOTFS")))
+bb.utils.rename(origInit, origInit + origInitNameSuffix)
+preinitPath = origInit
+
+with open(preinitPath, 'w') as f:
+f.write(PreinitTemplate.format(**args))
+os.chmod(preinitPath, 0o755)
+}
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159500): 
https://lists.openembedded.org/g/openembedded-core/message/159500
Mute This Topic: https://lists.openembedded.org/mt/87634117/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 0/8] Pull request (cover letter only)

[Vyacheslav Yurkov]

This is a V2 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 1a6c2a7345199d77ad5aeac8ad337ed80a8aa39b:

  build-appliance-image: Update to master head revision (2021-12-09 13:56:07 
+)

are available in the Git repository at:

  git://github.com/UVV-gh/openembedded-core feature/overlayfs-etc
  https://github.com/UVV-gh/openembedded-core/tree/feature/overlayfs-etc

Vyacheslav Yurkov (8):
  files: add preinit.sh.in
  overlayfs-etc: mount etc as overlayfs
  wic: image for overlayfs-etc tests
  image: add overlayfs-etc image feature
  oeqa/selftest: overlayfs helper function
  oeqa/selftest: unit tests for overlayfs-etc
  overlayfs: update notes on /etc
  overlayfs: move templates to files directory

 meta-selftest/wic/overlayfs_etc.wks.in   |   4 +
 meta/classes/image.bbclass   |   3 +-
 meta/classes/overlayfs-etc.bbclass   |  76 +++
 meta/classes/overlayfs.bbclass   |  53 +
 meta/files/overlayfs-all-overlays.service.in |  12 ++
 meta/files/overlayfs-create-dirs.service.in  |  14 ++
 meta/files/overlayfs-unit.mount.in   |  13 ++
 meta/files/preinit.sh.in |  29 +++
 meta/lib/oeqa/selftest/cases/overlayfs.py| 216 +--
 9 files changed, 361 insertions(+), 59 deletions(-)
 create mode 100644 meta-selftest/wic/overlayfs_etc.wks.in
 create mode 100644 meta/classes/overlayfs-etc.bbclass
 create mode 100644 meta/files/overlayfs-all-overlays.service.in
 create mode 100644 meta/files/overlayfs-create-dirs.service.in
 create mode 100644 meta/files/overlayfs-unit.mount.in
 create mode 100644 meta/files/preinit.sh.in

-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159498): 
https://lists.openembedded.org/g/openembedded-core/message/159498
Mute This Topic: https://lists.openembedded.org/mt/87634115/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [honister][PATCH 4/4] license.bbclass: implement ast.NodeVisitor.visit_Constant

[Ross Burton]

From: Ross Burton 

Since Python 3.8 visit_Num(), visit_Str() and so on are all deprecated
and replaced with visit_Constant.  We can't yet remove the deprecated
functions until we require 3.8, but we can implement visit_Constant to
silence the deprecation warnings.

Signed-off-by: Ross Burton 
---
 meta/classes/license.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 45d912741d2..7a34e185c74 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -145,6 +145,10 @@ def find_license_files(d):
 find_license(node.s.replace("+", "").replace("*", ""))
 self.generic_visit(node)
 
+def visit_Constant(self, node):
+find_license(node.value.replace("+", "").replace("*", ""))
+self.generic_visit(node)
+
 def find_license(license_type):
 try:
 bb.utils.mkdirhier(gen_lic_dest)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159497): 
https://lists.openembedded.org/g/openembedded-core/message/159497
Mute This Topic: https://lists.openembedded.org/mt/87633493/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [honister][PATCH 3/4] oe/license: implement ast.NodeVisitor.visit_Constant

[Ross Burton]

From: Ross Burton 

Since Python 3.8 visit_Num(), visit_Str() and so on are all deprecated
and replaced with visit_Constant.  We can't yet remove the deprecated
functions until we require 3.8, but we can implement visit_Constant to
silence the deprecation warnings.

Signed-off-by: Ross Burton 
---
 meta/lib/oe/license.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/lib/oe/license.py b/meta/lib/oe/license.py
index 665d32ecbb1..b5d378a549b 100644
--- a/meta/lib/oe/license.py
+++ b/meta/lib/oe/license.py
@@ -74,6 +74,9 @@ class FlattenVisitor(LicenseVisitor):
 def visit_Str(self, node):
 self.licenses.append(node.s)
 
+def visit_Constant(self, node):
+self.licenses.append(node.value)
+
 def visit_BinOp(self, node):
 if isinstance(node.op, ast.BitOr):
 left = FlattenVisitor(self.choose_licenses)
@@ -227,6 +230,9 @@ class ListVisitor(LicenseVisitor):
 def visit_Str(self, node):
 self.licenses.add(node.s)
 
+def visit_Constant(self, node):
+self.licenses.add(node.value)
+
 def list_licenses(licensestr):
 """Simply get a list of all licenses mentioned in a license string.
Binary operators are not applied or taken into account in any way"""
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159495): 
https://lists.openembedded.org/g/openembedded-core/message/159495
Mute This Topic: https://lists.openembedded.org/mt/87633491/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [honister][PATCH 2/4] packagedata.py: silence a DeprecationWarning

[Ross Burton]

From: Mingli Yu 

Use regex strings (r’’) to silence below deprecation warning [1]:
 $ cat 
tmp/work/intel_x86_64-wrs-linux/linux-yocto/5.10.x+gitAUTOINC+917c420111_373c02c3ca-r0/temp/log.do_deploy
 [snip]
 /build/layers/oe-core/meta/lib/oe/packagedata.py:22: DeprecationWarning: 
invalid escape sequence \s
 r = re.compile("(^.+?):\s+(.*)")
 [snip]

[1] https://docs.python.org/3/library/re.html

Signed-off-by: Mingli Yu 
---
 meta/lib/oe/packagedata.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/packagedata.py b/meta/lib/oe/packagedata.py
index 02c81e5a522..212f048bc60 100644
--- a/meta/lib/oe/packagedata.py
+++ b/meta/lib/oe/packagedata.py
@@ -19,7 +19,7 @@ def read_pkgdatafile(fn):
 import re
 with open(fn, 'r') as f:
 lines = f.readlines()
-r = re.compile("(^.+?):\s+(.*)")
+r = re.compile(r"(^.+?):\s+(.*)")
 for l in lines:
 m = r.match(l)
 if m:
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159496): 
https://lists.openembedded.org/g/openembedded-core/message/159496
Mute This Topic: https://lists.openembedded.org/mt/87633492/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [honister][PATCH 1/4] lib/pyinotify.py: Remove deprecated module asyncore

[Ross Burton]

From: Robert Yang 

When build with nativesdk-python3 (3.10) from buildtools:
/path/to/bitbake/lib/pyinotify.py:55: DeprecationWarning: The asyncore module 
is deprecated. The recommended replacement is asyncio

The pyinotify.py's upstream didn't have any update in recent 7 years:
https://github.com/seb-m/pyinotify

And bitbake doesn't use the asyncore module, so remove the related code.

Signed-off-by: Robert Yang 
---
 bitbake/lib/pyinotify.py | 30 --
 1 file changed, 30 deletions(-)

diff --git a/bitbake/lib/pyinotify.py b/bitbake/lib/pyinotify.py
index 6ae40a2d765..8c94b3e3348 100644
--- a/bitbake/lib/pyinotify.py
+++ b/bitbake/lib/pyinotify.py
@@ -52,7 +52,6 @@ from collections import deque
 from datetime import datetime, timedelta
 import time
 import re
-import asyncore
 import glob
 import locale
 import subprocess
@@ -1475,35 +1474,6 @@ class ThreadedNotifier(threading.Thread, Notifier):
 self.loop()
 
 
-class AsyncNotifier(asyncore.file_dispatcher, Notifier):
-"""
-This notifier inherits from asyncore.file_dispatcher in order to be able to
-use pyinotify along with the asyncore framework.
-
-"""
-def __init__(self, watch_manager, default_proc_fun=None, read_freq=0,
- threshold=0, timeout=None, channel_map=None):
-"""
-Initializes the async notifier. The only additional parameter is
-'channel_map' which is the optional asyncore private map. See
-Notifier class for the meaning of the others parameters.
-
-"""
-Notifier.__init__(self, watch_manager, default_proc_fun, read_freq,
-  threshold, timeout)
-asyncore.file_dispatcher.__init__(self, self._fd, channel_map)
-
-def handle_read(self):
-"""
-When asyncore tells us we can read from the fd, we proceed processing
-events. This method can be overridden for handling a notification
-differently.
-
-"""
-self.read_events()
-self.process_events()
-
-
 class TornadoAsyncNotifier(Notifier):
 """
 Tornado ioloop adapter.
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159494): 
https://lists.openembedded.org/g/openembedded-core/message/159494
Mute This Topic: https://lists.openembedded.org/mt/87633490/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] bootchart2: remove wait_boot logic

[Alexander Kanavin]

Thank you, but please submit the patch upstream first. We're tightening the
policy on Pending patches.

Alex

On Fri, 10 Dec 2021 at 03:16, Yu, Mingli  wrote:

> From: Mingli Yu 
>
> When boot with "init=/sbin/bootchartd" as below:
>  # runqemu qemux86 bootparams="init=/sbin/bootchartd"
>
> There are two bootchartd process after boot [1].
>  # ps -ef | grep bootchart
> root   101 1  0 03:27 ?00:00:00 /bin/sh /sbin/bootchartd
> root   103   101  8 03:27 ?00:00:02
> /lib64/bootchart/bootchart-collector 50
> root   106 1  0 03:27 ?00:00:00 /bin/sh /sbin/bootchartd
> root   792   106  0 03:27 ?00:00:00
> /lib64/bootchart/bootchart-collector --usleep 100
> root   794   725  0 03:27 ttyS000:00:00 grep bootchart
>
>  # /sbin/bootchartd stop
> [bootchart] bootchart-collector started as pid 596 with 2 args:
> [bootchart] '--dump'
> [bootchart] '/tmp/bootchart.3lXpVDAq3v'
> [bootchart] Extracting profile data from pid 204
> [bootchart] map 0xbed9a000 -> 0xbedbb000 size: 132k from 'bed9a000'
> 'bedbb000'
> [bootchart] read 135168 bytes of 135168
> [bootchart] reading 150 chunks (of 150) ...
> [bootchart] wrote 18760 kbB
> [bootchart] bootchart-collector pid: 596 unmounted proc / clean exit
>
> But there still one process exist after the above stop command finish.
>  # ps -ef | grep bootchartd
> root 202 1 0 09:09 ? 00:00:00 /bin/sh /sbin/bootchartd
> root 629 516 0 09:10 ? 00:00:00 grep bootchartd
>
> Remove the wait_boot which used to wait the boot process to finish to
> make sure only one bootchartd process and meanwhile we don't need the
> wait_boot logic because we either use "/sbin/bootchartd stop" to stop
> the bootchartd manually or install package bootchartd-stop-initscript
> altogether with bootchart2 to stop bootchartd automatically after boot.
>
> After patch:
>  # ps -ef | grep bootchart
>  root   101 1  0 03:36 ?00:00:00 /bin/sh /sbin/bootchartd
>  root   103   101  6 03:36 ?00:00:04
> /lib64/bootchart/bootchart-collector 50
>  root   596   592  0 03:37 ttyS000:00:00 grep bootchart
>
> [1] https://github.com/xrmx/bootchart/issues/94
>
> Signed-off-by: Mingli Yu 
> ---
>  ...ake-sure-only-one-bootchartd-process.patch | 68 +++
>  .../bootchart2/bootchart2_0.14.9.bb   |  1 +
>  2 files changed, 69 insertions(+)
>  create mode 100644
> meta/recipes-devtools/bootchart2/bootchart2/0001-bootchartd.in-make-sure-only-one-bootchartd-process.patch
>
> diff --git
> a/meta/recipes-devtools/bootchart2/bootchart2/0001-bootchartd.in-make-sure-only-one-bootchartd-process.patch
> b/meta/recipes-devtools/bootchart2/bootchart2/0001-bootchartd.in-make-sure-only-one-bootchartd-process.patch
> new file mode 100644
> index 00..0d6c20c47c
> --- /dev/null
> +++
> b/meta/recipes-devtools/bootchart2/bootchart2/0001-bootchartd.in-make-sure-only-one-bootchartd-process.patch
> @@ -0,0 +1,68 @@
> +From 988ca784d4840c87509e770a21d5d22105af8668 Mon Sep 17 00:00:00 2001
> +From: Mingli Yu 
> +Date: Fri, 5 Nov 2021 11:18:07 +0800
> +Subject: [PATCH] bootchartd.in: make sure only one bootchartd process
> +
> +When boot with "init=/sbin/bootchartd" as below:
> + # runqemu qemux86 bootparams="init=/sbin/bootchartd"
> +
> +There are two bootchartd process after boot [1].
> + # ps -ef | grep bootchart
> +root   101 1  0 03:27 ?00:00:00 /bin/sh /sbin/bootchartd
> +root   103   101  8 03:27 ?00:00:02
> /lib64/bootchart/bootchart-collector 50
> +root   106 1  0 03:27 ?00:00:00 /bin/sh /sbin/bootchartd
> +root   792   106  0 03:27 ?00:00:00
> /lib64/bootchart/bootchart-collector --usleep 100
> +root   794   725  0 03:27 ttyS000:00:00 grep bootchart
> +
> + # /sbin/bootchartd stop
> +[bootchart] bootchart-collector started as pid 596 with 2 args:
> +[bootchart] '--dump'
> +[bootchart] '/tmp/bootchart.3lXpVDAq3v'
> +[bootchart] Extracting profile data from pid 204
> +[bootchart] map 0xbed9a000 -> 0xbedbb000 size: 132k from 'bed9a000'
> 'bedbb000'
> +[bootchart] read 135168 bytes of 135168
> +[bootchart] reading 150 chunks (of 150) ...
> +[bootchart] wrote 18760 kbB
> +[bootchart] bootchart-collector pid: 596 unmounted proc / clean exit
> +
> +But there still one process exist after the above stop command finish.
> + # ps -ef | grep bootchartd
> +root 202 1 0 09:09 ? 00:00:00 /bin/sh /sbin/bootchartd
> +root 629 516 0 09:10 ? 00:00:00 grep bootchartd
> +
> +Remove the wait_boot which used to wait the boot process to finish to
> +make sure only one bootchartd process and meanwhile we don't need the
> +wait_boot logic because we either use "/sbin/bootchartd stop" to stop
> +the bootchartd manually or install package bootchartd-stop-initscript
> +altogether with bootchart2 to stop bootchartd automatically after boot.
> +
> +After patch:
> + # ps -ef | grep bootchart
> + root   101 1  0 03:36 ?00:00:00 /bin/sh /sbin/bootchartd
> + root

Re: [OE-core] [PATCH v2] pango: upgrade 1.48.10 -> 1.50.0

[Alexander Kanavin]

+-#ifdef __x86_64__

I think the above simply needs to be adjusted to say 'if x86_64 and not
x32'?

Also, this does not resolve the newly occurring ptest failures.

Alex

On Fri, 10 Dec 2021 at 02:47, wangmy  wrote:

> Add patch 0001-Fix-bug-for-x86_64_x32.patch
> to fix compile bug when building 32bit on x86_64 environment.
>
> Signed-off-by: Wang Mingyu 
> ---
>  .../pango/0001-Fix-bug-for-x86_64_x32.patch   | 55 +++
>  .../{pango_1.48.10.bb => pango_1.50.0.bb} |  4 +-
>  2 files changed, 58 insertions(+), 1 deletion(-)
>  create mode 100644
> meta/recipes-graphics/pango/pango/0001-Fix-bug-for-x86_64_x32.patch
>  rename meta/recipes-graphics/pango/{pango_1.48.10.bb => pango_1.50.0.bb}
> (91%)
>
> diff --git
> a/meta/recipes-graphics/pango/pango/0001-Fix-bug-for-x86_64_x32.patch
> b/meta/recipes-graphics/pango/pango/0001-Fix-bug-for-x86_64_x32.patch
> new file mode 100644
> index 00..9ab55879a4
> --- /dev/null
> +++ b/meta/recipes-graphics/pango/pango/0001-Fix-bug-for-x86_64_x32.patch
> @@ -0,0 +1,55 @@
> +From 8e97429dfb9a2931c79658869da25b44014f8eba Mon Sep 17 00:00:00 2001
> +From: Wang Mingyu 
> +Date: Thu, 9 Dec 2021 00:13:20 +0900
> +Subject: [PATCH] Fix bug for x86_64_x32
> +
> +When built 32-bit Pango on x86_64 environment, the following problems
> occured:
> +
> +error: size of array '_GStaticAssertCompileTimeAssertion_4' is negative
> +|   826 | #define G_STATIC_ASSERT(expr) typedef char G_PASTE
> (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
> G_GNUC_UNUSED
> +
> +This problem can be solved by removing the judgement of arch.
> +
> +Upstream-Status: Inappropriate [
> https://gitlab.gnome.org/GNOME/pango/-/issues/637]
> +
> +Signed-off-by: Wang Mingyu 
> +---
> + pango/pango-item-private.h | 15 ---
> + 1 file changed, 15 deletions(-)
> +
> +diff --git a/pango/pango-item-private.h b/pango/pango-item-private.h
> +index d37fc3f..d49f2a6 100644
> +--- a/pango/pango-item-private.h
>  b/pango/pango-item-private.h
> +@@ -40,19 +40,6 @@ G_BEGIN_DECLS
> +
> + typedef struct _PangoItemPrivate PangoItemPrivate;
> +
> +-#ifdef __x86_64__
> +-
> +-struct _PangoItemPrivate
> +-{
> +-  int offset;
> +-  int length;
> +-  int num_chars;
> +-  int char_offset;
> +-  PangoAnalysis analysis;
> +-};
> +-
> +-#else
> +-
> + struct _PangoItemPrivate
> + {
> +   int offset;
> +@@ -62,8 +49,6 @@ struct _PangoItemPrivate
> +   int char_offset;
> + };
> +
> +-#endif
> +-
> + G_STATIC_ASSERT (offsetof (PangoItem, offset) == offsetof
> (PangoItemPrivate, offset));
> + G_STATIC_ASSERT (offsetof (PangoItem, length) == offsetof
> (PangoItemPrivate, length));
> + G_STATIC_ASSERT (offsetof (PangoItem, num_chars) == offsetof
> (PangoItemPrivate, num_chars));
> +--
> +2.25.1
> +
> diff --git a/meta/recipes-graphics/pango/pango_1.48.10.bb
> b/meta/recipes-graphics/pango/pango_1.50.0.bb
> similarity index 91%
> rename from meta/recipes-graphics/pango/pango_1.48.10.bb
> rename to meta/recipes-graphics/pango/pango_1.50.0.bb
> index 40df7042e6..974e053b8f 100644
> --- a/meta/recipes-graphics/pango/pango_1.48.10.bb
> +++ b/meta/recipes-graphics/pango/pango_1.50.0.bb
> @@ -20,7 +20,9 @@ GIR_MESON_DISABLE_FLAG = "disabled"
>
>  SRC_URI += "file://run-ptest"
>
> -SRC_URI[archive.sha256sum] =
> "21e1f5798bcdfda75eabc4280514b0896ab56f656d4e7e66030b9a2535ecdc98"
> +SRC_URI:append:x86-x32 = " file://0001-Fix-bug-for-x86_64_x32.patch"
> +
> +SRC_URI[archive.sha256sum] =
> "dba8b62ddf86e10f73f93c3d2256b73238b2bcaf87037ca229b40bdc040eb3f3"
>
>  DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv
> cairo harfbuzz fribidi"
>
> --
> 2.25.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159492): 
https://lists.openembedded.org/g/openembedded-core/message/159492
Mute This Topic: https://lists.openembedded.org/mt/87627577/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-