Re: [OE-core] [PATCH] oeqa/selftest/devtool: Fix for usrmerge in DISTRO_FEATURES

[Khem Raj]

On Tue, May 7, 2024 at 3:47 PM Richard Purdie via lists.openembedded.org
 wrote:

> If usrmerge is in DISTRO_FEATURES, assumptions in one of the tests would
> fail. Improve the test so it works in both cases.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/lib/oeqa/selftest/cases/devtool.py | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/lib/oeqa/selftest/cases/devtool.py
> b/meta/lib/oeqa/selftest/cases/devtool.py
> index c8f9534e416..882225dde34 100644
> --- a/meta/lib/oeqa/selftest/cases/devtool.py
> +++ b/meta/lib/oeqa/selftest/cases/devtool.py
> @@ -1773,6 +1773,8 @@ class DevtoolExtractTests(DevtoolBase):
>  # Definitions
>  testrecipe = 'mdadm'
>  testfile = '/sbin/mdadm'
> +if "usrmerge" in get_bb_var('DISTRO_FEATURES'):
> +testfile = '/usr/sbin/mdadm'
>  testimage = 'oe-selftest-image'
>  testcommand = '/sbin/mdadm --help'


Won’t this line also need to be covered as well ?
I wonder if these paths need to be absolute or can they be searched in
standard paths

>
>  # Build an image to run
> --
> 2.40.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199110): 
https://lists.openembedded.org/g/openembedded-core/message/199110
Mute This Topic: https://lists.openembedded.org/mt/105970675/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] oeqa/selftest/devtool: Fix for usrmerge in DISTRO_FEATURES

[Richard Purdie]

If usrmerge is in DISTRO_FEATURES, assumptions in one of the tests would
fail. Improve the test so it works in both cases.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/devtool.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/devtool.py 
b/meta/lib/oeqa/selftest/cases/devtool.py
index c8f9534e416..882225dde34 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -1773,6 +1773,8 @@ class DevtoolExtractTests(DevtoolBase):
 # Definitions
 testrecipe = 'mdadm'
 testfile = '/sbin/mdadm'
+if "usrmerge" in get_bb_var('DISTRO_FEATURES'):
+testfile = '/usr/sbin/mdadm'
 testimage = 'oe-selftest-image'
 testcommand = '/sbin/mdadm --help'
 # Build an image to run
-- 
2.40.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199109): 
https://lists.openembedded.org/g/openembedded-core/message/199109
Mute This Topic: https://lists.openembedded.org/mt/105970675/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] oeqa/selftest/recipetool: Fix for usrmerge in DISTRO_FEATURES

[Richard Purdie]

If usrmerge is in DISTRO_FEATURES, assumptions in one of the tests would
fail. Improve the test so it works in both cases.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/recipetool.py | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index aebea42502b..126906df502 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -120,9 +120,15 @@ class RecipetoolAppendTests(RecipetoolBase):
 self._try_recipetool_appendfile_fail('/dev/console', self.testfile, 
['ERROR: /dev/console cannot be handled by this tool'])
 
 def test_recipetool_appendfile_alternatives(self):
+lspath = '/bin/ls'
+dirname = "base_bindir"
+if "usrmerge" in get_bb_var('DISTRO_FEATURES'):
+lspath = '/usr/bin/ls'
+dirname = "bindir"
+
 # Now try with a file we know should be an alternative
 # (this is very much a fake example, but one we know is reliably an 
alternative)
-self._try_recipetool_appendfile_fail('/bin/ls', self.testfile, 
['ERROR: File /bin/ls is an alternative possibly provided by the following 
recipes:', 'coreutils', 'busybox'])
+self._try_recipetool_appendfile_fail(lspath, self.testfile, ['ERROR: 
File %s is an alternative possibly provided by the following recipes:' % 
lspath, 'coreutils', 'busybox'])
 # Need a test file - should be executable
 testfile2 = os.path.join(self.corebase, 'oe-init-build-env')
 testfile2name = os.path.basename(testfile2)
@@ -131,12 +137,12 @@ class RecipetoolAppendTests(RecipetoolBase):
  'SRC_URI += "file://%s"\n' % testfile2name,
  '\n',
  'do_install:append() {\n',
- 'install -d ${D}${base_bindir}\n',
- 'install -m 0755 ${WORKDIR}/%s 
${D}${base_bindir}/ls\n' % testfile2name,
+ 'install -d ${D}${%s}\n' % dirname,
+ 'install -m 0755 ${WORKDIR}/%s ${D}${%s}/ls\n' % 
(testfile2name, dirname),
  '}\n']
-self._try_recipetool_appendfile('coreutils', '/bin/ls', testfile2, '-r 
coreutils', expectedlines, [testfile2name])
+self._try_recipetool_appendfile('coreutils', lspath, testfile2, '-r 
coreutils', expectedlines, [testfile2name])
 # Now try bbappending the same file again, contents should not change
-bbappendfile, _ = self._try_recipetool_appendfile('coreutils', 
'/bin/ls', self.testfile, '-r coreutils', expectedlines, [testfile2name])
+bbappendfile, _ = self._try_recipetool_appendfile('coreutils', lspath, 
self.testfile, '-r coreutils', expectedlines, [testfile2name])
 # But file should have
 copiedfile = os.path.join(os.path.dirname(bbappendfile), 'coreutils', 
testfile2name)
 result = runCmd('diff -q %s %s' % (testfile2, copiedfile), 
ignore_status=True)
-- 
2.40.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199108): 
https://lists.openembedded.org/g/openembedded-core/message/199108
Mute This Topic: https://lists.openembedded.org/mt/105969283/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] uboot-sign: fix loop in do_uboot_assemble_fitimage

[Ralph Siemsen]

On Fri, May 3, 2024 at 1:36 PM Steve Sakoman  wrote:
>
> Please submit a kirkstone patch once this hits the master branch.

Ack. I have been checking daily on master and master-next, but so far
it does not seem to have been picked up.

It is a clean cherry-pick into kirkstone, so at least that part should
be simple ;-)

Regards,
Ralph

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199107): 
https://lists.openembedded.org/g/openembedded-core/message/199107
Mute This Topic: https://lists.openembedded.org/mt/105890177/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 v2 07/11] kea: Remove -fvisibility-inlines-hidden from C++ flags

[Khem Raj]

On Tue, May 7, 2024 at 12:56 PM Alexander Kanavin
 wrote:
>
> On Tue, 7 May 2024 at 18:13, Khem Raj  wrote:
> > Firstly I am inclined towards removing it if we can, since I think it 
> > should be
> > packages to decide to use it, then they can maintain it better from testing 
> > POV,
> > However, there is something
> > to consider w.r.t. to this option. This does help in optimizing loading DSOs
> > by reducing the number of PLTs and improves loading time for DSOs which 
> > might
> > be quite meaningful for embedded devices that we target. However, we only
> > enable hidden visibility only for inlines so it won't be full benefits but 
> > we do
> > have better default compatibility.
> >
> > Since we have had this option for a long time and it still seems
> > relevant, I would
> > think it would make sense to do some benchmarking on a sizeable C++ program
> > perhaps chromium or webkit, and see the difference in DSOs sizes with
> > and without
> > this option and also benchmark the loading time of the resulting
> > chromium package.
> >
> > maybe we will find that the gains are not as significant, in that case
> > we might drop
> > it from defaults.
>
> I digged deeper and this is where I think it originated:
> https://git.openembedded.org/openembedded/commit/?id=ddd6d1fd26416a3766d754eeda4237a680a65520
>
> Ah the simpler times of oe-classic, when one could bundle four
> unrelated changes into one commit and explain none of them.
>
> Benchmarking I have no time for right now, just wanted to point out
> that adding the flag was never justified in commit log. Can you
> experiment with webkit?
>

Yes, I have added it to my backlog.

> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199106): 
https://lists.openembedded.org/g/openembedded-core/message/199106
Mute This Topic: https://lists.openembedded.org/mt/105955497/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 v2] glib/gobject-introspection: update 2.78.4 -> 2.80.0, 1.78.1 -> 1.80.0

[Alexander Kanavin]

On Tue, 7 May 2024 at 17:52, Ross Burton  wrote:
> If you send a v3, this can be Backport. :)

I'm leaning towards addressing the review comments with followup
patches. None is a critical fix needed for update itself. You ok with
that?

> > +EXTRA_OEMESON:append:class-target = " ${@'-Dgir_dir_prefix=${libdir}' if 
> > d.getVar('MULTILIBS') else ''}"
>
> Why does this need to be conditional?

This is a direct copy-paste from g-i recipe. g-i (before) and glib
(now) install gir files into /usr/share by default which doesn't work
for multilib because they differ between 32 and 64 bit targets, and
package manager errors out.

> > # setuptools can be removed when upstream removes all uses of distutils
> > -RDEPENDS:${PN} = "python3-pickle python3-xml python3-setuptools"
> > +RDEPENDS:${PN} = "python3-pickle python3-xml python3-setuptools glib-2.0”
>
> Is setuptools still needed?  If so, might be worth calling out what the exact 
> user is because a simple grep doesn’t find any users.

Indeed, neither distutils nor setuptools are anywhere in 2.80.0 tree.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199105): 
https://lists.openembedded.org/g/openembedded-core/message/199105
Mute This Topic: https://lists.openembedded.org/mt/105860089/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 v2 07/11] kea: Remove -fvisibility-inlines-hidden from C++ flags

[Alexander Kanavin]

On Tue, 7 May 2024 at 18:13, Khem Raj  wrote:
> Firstly I am inclined towards removing it if we can, since I think it should 
> be
> packages to decide to use it, then they can maintain it better from testing 
> POV,
> However, there is something
> to consider w.r.t. to this option. This does help in optimizing loading DSOs
> by reducing the number of PLTs and improves loading time for DSOs which might
> be quite meaningful for embedded devices that we target. However, we only
> enable hidden visibility only for inlines so it won't be full benefits but we 
> do
> have better default compatibility.
>
> Since we have had this option for a long time and it still seems
> relevant, I would
> think it would make sense to do some benchmarking on a sizeable C++ program
> perhaps chromium or webkit, and see the difference in DSOs sizes with
> and without
> this option and also benchmark the loading time of the resulting
> chromium package.
>
> maybe we will find that the gains are not as significant, in that case
> we might drop
> it from defaults.

I digged deeper and this is where I think it originated:
https://git.openembedded.org/openembedded/commit/?id=ddd6d1fd26416a3766d754eeda4237a680a65520

Ah the simpler times of oe-classic, when one could bundle four
unrelated changes into one commit and explain none of them.

Benchmarking I have no time for right now, just wanted to point out
that adding the flag was never justified in commit log. Can you
experiment with webkit?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199104): 
https://lists.openembedded.org/g/openembedded-core/message/199104
Mute This Topic: https://lists.openembedded.org/mt/105955497/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] linux-yocto/6.6: fix kselftest failures

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/6.6:

1/1 [
Author: Mark Brown
Email: broo...@kernel.org
Subject: kselftest: Add a ksft_perror() helper
Date: Thu, 28 Sep 2023 16:38:11 +0200

The standard library perror() function provides a convenient way to print
an error message based on the current errno but this doesn't play nicely
with KTAP output. Provide a helper which does an equivalent thing in a KTAP
compatible format.

nolibc doesn't have a strerror() and adding the table of strings required
doesn't seem like a good fit for what it's trying to do so when we're using
that only print the errno.

Signed-off-by: Mark Brown 
Reviewed-by: Kees Cook 
Signed-off-by: Shuah Khan 
Signed-off-by: Bruce Ashfield 
]

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_6.6.bb   |  2 +-
 .../linux/linux-yocto-tiny_6.6.bb |  2 +-
 meta/recipes-kernel/linux/linux-yocto_6.6.bb  | 22 +--
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb
index ea429692d8..53f413407d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb
@@ -14,7 +14,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "99d3632c1cf7688066e57aea89f9adfe8d1a5ca5"
+SRCREV_machine ?= "9bdb085cb6fcfd49586b980ba27cb81e5c76689e"
 SRCREV_meta ?= "a78c74a3510067017dda1926f88bd914f0a053b3"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https
 \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.6.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_6.6.bb
index bdad73bbbc..44c9a7b1e0 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.6.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.6.bb
@@ -17,7 +17,7 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
+SRCREV_machine ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
 SRCREV_meta ?= "a78c74a3510067017dda1926f88bd914f0a053b3"
 
 PV = "${LINUX_VERSION}+git"
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.6.bb 
b/meta/recipes-kernel/linux/linux-yocto_6.6.bb
index 12197ba414..817639bce0 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.6.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.6.bb
@@ -18,17 +18,17 @@ KBRANCH:qemux86-64 ?= "v6.6/standard/base"
 KBRANCH:qemuloongarch64  ?= "v6.6/standard/base"
 KBRANCH:qemumips64 ?= "v6.6/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "45982c347ee123883a88f220d1d9a740e2c2b959"
-SRCREV_machine:qemuarm64 ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
-SRCREV_machine:qemuloongarch64 ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
-SRCREV_machine:qemumips ?= "738f344ef6da38ebf6fcca87b701281c930b16e4"
-SRCREV_machine:qemuppc ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
-SRCREV_machine:qemuriscv64 ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
-SRCREV_machine:qemuriscv32 ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
-SRCREV_machine:qemux86 ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
-SRCREV_machine:qemux86-64 ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
-SRCREV_machine:qemumips64 ?= "7f4b889b7acb9fe36e290bf40c2e9b6cec523f6d"
-SRCREV_machine ?= "6655dc03f5de7bb734da3ec8eb97f9be281dfbdb"
+SRCREV_machine:qemuarm ?= "0b90bbe1359b3fd590780119f19dbd0a01e58560"
+SRCREV_machine:qemuarm64 ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
+SRCREV_machine:qemuloongarch64 ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
+SRCREV_machine:qemumips ?= "ab44de80a320e30a49150ea74554a937affaf78d"
+SRCREV_machine:qemuppc ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
+SRCREV_machine:qemuriscv64 ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
+SRCREV_machine:qemuriscv32 ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
+SRCREV_machine:qemux86 ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
+SRCREV_machine:qemux86-64 ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
+SRCREV_machine:qemumips64 ?= "75da5d44c2e54a85a1221ea7d0c04be9aefb7fa1"
+SRCREV_machine ?= "7c76aad68f6d1247e72f024f1e0291067a404f8d"
 SRCREV_meta ?= "a78c74a3510067017dda1926f88bd914f0a053b3"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199103): 
https://lists.openembedded.org/g/openembedded-core/message/199103
Mute This Topic: https://lists.openembedded.org/mt/105966984/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][kirkstone][PATCH] xz: Update LICENSE variable for xz packages

[Khem Raj]

On Mon, May 6, 2024 at 8:33 AM Marta Rybczynska via
lists.openembedded.org 
wrote:
>
>
>
> On Mon, 6 May 2024, 13:09 nikhil via lists.openembedded.org, 
>  wrote:
>>
>> Update LICENSE defined for xz packages to match the license
>> information provided in the xz COPYING file.
>>
>> The License information from PACKAGERS file of xz mentions
>> packages with lzma files are in public domain.They ask to
>> use GPLv2+, if only it's not possible to mention "PD and GPLv2+".
>>
>> Include PD license with GPLv2 to packages with lzma content:
>> xz-dev package contains lzma header
>> xz-doc package contains lzma man pages
>> xz packages contains lzma binaries
>>
>> Links: https://github.com/tukaani-project/xz/blob/v5.2.6/COPYING
>>https://github.com/tukaani-project/xz/blob/v5.4.1/PACKAGERS
>>
>> Signed-off-by: Bhabu Bindu 
>> ---
>>  meta/recipes-extended/xz/xz_5.2.6.bb | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/recipes-extended/xz/xz_5.2.6.bb 
>> b/meta/recipes-extended/xz/xz_5.2.6.bb
>> index 3482622471..33496748bc 100644
>> --- a/meta/recipes-extended/xz/xz_5.2.6.bb
>> +++ b/meta/recipes-extended/xz/xz_5.2.6.bb
>> @@ -9,10 +9,10 @@ SECTION = "base"
>>  # libgnu, which appears to be used for DOS builds. So we're left with
>>  # GPL-2.0-or-later and PD.
>>  LICENSE = "GPL-2.0-or-later & GPL-3.0-with-autoconf-exception & 
>> LGPL-2.1-or-later & PD"
>> -LICENSE:${PN} = "GPL-2.0-or-later"
>> -LICENSE:${PN}-dev = "GPL-2.0-or-later"
>> +LICENSE:${PN} = "PD & GPL-2.0-or-later"
>> +LICENSE:${PN}-dev = "PD & GPL-2.0-or-later"
>>  LICENSE:${PN}-staticdev = "GPL-2.0-or-later"
>> -LICENSE:${PN}-doc = "GPL-2.0-or-later"
>> +LICENSE:${PN}-doc = "PD & GPL-2.0-or-later"
>>  LICENSE:${PN}-dbg = "GPL-2.0-or-later"
>>  LICENSE:${PN}-locale = "GPL-2.0-or-later"
>>  LICENSE:liblzma = "PD"
>> --
>> 2.25.1
>
>
> I'm not a copyright lawyer, but from what I understand public domain is not a 
> licence. For a discussion see 
> https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files
>

rather each PD is a license of its own is what I understand.

> The next version of xz will be 0BSD so the statement will change too.
>
> Regards,
> Marta
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199102): 
https://lists.openembedded.org/g/openembedded-core/message/199102
Mute This Topic: https://lists.openembedded.org/mt/105937026/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 v2 07/11] kea: Remove -fvisibility-inlines-hidden from C++ flags

[Khem Raj]

On Tue, May 7, 2024 at 3:15 AM Alexander Kanavin  wrote:
>
> On Tue, 7 May 2024 at 07:33, Khem Raj via lists.openembedded.org
>  wrote:
>
> > +CXXFLAGS:remove = "-fvisibility-inlines-hidden"
>
> Same comment as v1: this seems like the wrong way around. Why do we
> have it as a global glibc/musl setting in the first place? Shouldn't
> we just remove it from there? I did some digging and this line was
> imported from oe-classic in 2010 with eglibc definition,  so most
> likely whatever reasons there used to be are long obsolete.

Firstly I am inclined towards removing it if we can, since I think it should be
packages to decide to use it, then they can maintain it better from testing POV,
However, there is something
to consider w.r.t. to this option. This does help in optimizing loading DSOs
by reducing the number of PLTs and improves loading time for DSOs which might
be quite meaningful for embedded devices that we target. However, we only
enable hidden visibility only for inlines so it won't be full benefits but we do
have better default compatibility.

Since we have had this option for a long time and it still seems
relevant, I would
think it would make sense to do some benchmarking on a sizeable C++ program
perhaps chromium or webkit, and see the difference in DSOs sizes with
and without
this option and also benchmark the loading time of the resulting
chromium package.

maybe we will find that the gains are not as significant, in that case
we might drop
it from defaults.

>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199101): 
https://lists.openembedded.org/g/openembedded-core/message/199101
Mute This Topic: https://lists.openembedded.org/mt/105955497/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 v2] glib/gobject-introspection: update 2.78.4 -> 2.80.0, 1.78.1 -> 1.80.0

[Ross Burton]

> On 2 May 2024, at 11:32, Alexander Kanavin via lists.openembedded.org 
>  wrote:
> -GTKDOC_MESON_OPTION = "gtk_doc"
> +inherit meson gettext gi-docgen pkgconfig ptest-gnome 
> upstream-version-is-even bash-completion gio-module-cache manpages 
> gobject-introspection-data

You’ll want to set GIDOCGEN_MESON_OPTION = “documentation”, the default of 
‘gtk_doc’ is deprecated.

Also, and I know it’s a pain, but splitting the “rearrange inc/bb” changes into 
a separate commit would make this easier to review.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199100): 
https://lists.openembedded.org/g/openembedded-core/message/199100
Mute This Topic: https://lists.openembedded.org/mt/105860089/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 v2] glib/gobject-introspection: update 2.78.4 -> 2.80.0, 1.78.1 -> 1.80.0

[Ross Burton]

> On 2 May 2024, at 11:32, Alexander Kanavin via lists.openembedded.org 
>  wrote:
> +++ 
> b/meta/recipes-core/glib-2.0/files/0001-girepository-introspection-correctly-install-.gir-fi.patch
> @@ -0,0 +1,88 @@
> +From 4e6be5d15e5d2f8e494d22a3d49b623064f9c1a5 Mon Sep 17 00:00:00 2001
> +From: Alexander Kanavin 
> +Date: Tue, 23 Apr 2024 11:24:34 +0200
> +Subject: [PATCH] girepository/introspection: correctly install .gir files 
> into
> + custom locations provided via meson option
> +
> +Upstream-Status: Submitted 
> [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4020]

If you send a v3, this can be Backport. :)

> +EXTRA_OEMESON:append:class-target = " ${@'-Dgir_dir_prefix=${libdir}' if 
> d.getVar('MULTILIBS') else ''}"

Why does this need to be conditional?

> # setuptools can be removed when upstream removes all uses of distutils
> -RDEPENDS:${PN} = "python3-pickle python3-xml python3-setuptools"
> +RDEPENDS:${PN} = "python3-pickle python3-xml python3-setuptools glib-2.0”

Is setuptools still needed?  If so, might be worth calling out what the exact 
user is because a simple grep doesn’t find any users.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199099): 
https://lists.openembedded.org/g/openembedded-core/message/199099
Mute This Topic: https://lists.openembedded.org/mt/105860089/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 v2] glib/gobject-introspection: update 2.78.4 -> 2.80.0, 1.78.1 -> 1.80.0

[Ross Burton]

Hi Alex,

Thanks for digging into this!

packages/cortexa57-poky-linux/glib-2.0/glib-2.0-utils: FILELIST: added 
"/usr/bin/gi-compile-repository /usr/bin/gi-inspect-typelib 
/usr/bin/gi-decompile-typelib”
packages/cortexa57-poky-linux/glib-2.0/glib-2.0-utils: PKGSIZE changed from 
770935 to 1105901 (+43%)

Any image that uses GSettings pulls in this package for the gsettings tools.  
Should these normally built-time utilities be moved to glib-2.0-codegen instead?

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

[OE-core] Yocto Project Status 7 May 2024 (WW19)

[Stephen Jolley]

Current Dev Position: YP 5.1 M1

Next Deadline: YP 5.1 M1 Build 20 May 2024

Next Team Meetings:

   -

   Bug Triage meeting Thursday May 9th at 7:30 am PST (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync Tuesday May 7th at 8 am PST (
   https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
   
   -

   Twitch -  See https://www.twitch.tv/theyoctojester


Key Status/Updates:

   -

   YP 3.1.33 has been released
   -

   YP 4.0.18 is due to be released
   -

   There is an open letter the project has created related to the CVE/NVD
   situation, more information is available here:
   https://lists.openembedded.org/g/openembedded-architecture/message/1990

Please consider signing this to show support for those changes.

Signatures from small businesses/consultancies are as welcome as those from
larger organizations as we want to demonstrate the breadth of the need for
these changes.

   -

   The project is sponsoring Syslinbit to separate out our CVE tooling from
   the build system into a standalone tool so that it can be used on software
   manifests of output at a later date.
   -

   There are proposals on the openembedded-architecture list to rework how
   do_unpack works, switching it from WORKDIR to a new variable and changing
   some directory layout.
   -

   The introduction of UNPACKDIR has happened, maintainers should be able
   to improve their S=WORKDIR recipes (which should use S, not
   WORKDIR/UNPACKDIR) and fix the common use of WORKDIR in
   do_compile/do_install to access files from SRC_URI which should now be
   UNPACKDIR.
   -

   gcc 14 has patches pending thanks for Khem and Martin in particular.
   Merging the new gcc version is needed to generate new uninative tarballs to
   support Fedora 40 builds or any other distro using the new gcc version.
   -

   The project is in the process of testing a new way of hosting our
   autobuilder with plans to switch soon if successful. Our existing hardware
   is past end of life and showing increased hardware failures so is currently
   down on capacity meaning builds are taking longer than normal.
   -

   Mailing list changes now mean any google hosted email accounts have the
   mailing list From: address rewritten. This had impacted our ability to
   handle patches but key maintainers now have workarounds for this.


Ways to contribute:

   -

   As people are likely aware, the project has a number of components which
   are either unmaintained, or have people with little to no time trying to
   keep them alive. These components include: devtool, toaster, wic, oeqa,
   autobuilder, CROPs containers, pseudo and more. Many have open bugs. Help
   is welcome in trying to better look after these components!
   -

   There are bugs identified as possible for newcomers to the project:
   https://wiki.yoctoproject.org/wiki/Newcomers
   -

   There are bugs that are currently unassigned for YP 5.1. See:
   
https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium+_5.1_Unassigned_Enhancements/Bugs
   -

   We’d welcome new maintainers for recipes in OE-Core. Please see the list
   at:
   
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
   and discuss with the existing maintainer, or ask on the OE-Core mailing
   list. We will likely move a chunk of these to “Unassigned” soon to help
   facilitate this.
   -

   Help is very much welcome in trying to resolve our autobuilder
   intermittent issues. You can see the list of failures we’re continuing to
   see by searching for the “AB-INT” tag in bugzilla:
   https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
   -

   Help us resolve CVE issues: CVE metrics
   
   -

   We have a growing number of bugs in bugzilla, any help with them is
   appreciated.
   -

   Regarding bugs, even if you can’t fix a bug, submitting a failing test
   case that can reproduce the issue significantly improves the chances it
   might get fixed.


Tracking Metrics:

   -

   WDD 2720 (last week 2728) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   OE-Core/Poky Patch Metrics
   -

  Total patches found: 1125 (last week 1125)
  -

  Patches in the Pending State: 221 (20%) [last week 221 (20%)]
  -

   https://autobuilder.yocto.io/pub/non-release/patchmetrics/


YP 5.1 Milestone Dates:

   -

   YP 5.1 M1 Build date  2024-05-20
   -

   YP 5.1 M1 Release date 2024-05-31
   -

   YP 5.1 M2 Build date  2024-07-08
   -

   YP 5.1 M2 Release date 2024-07-19
   -

   YP 5.1 M3 Build date  2024-08-26
   -

   YP 5.1 M3 Release date 2024-09-06
   -

   YP 5.1 M4 Build date  2024-09-30
   -

   YP 5.1 M4 Release date 2024-10-25


Upcoming dot releases:

   -

   YP 3.1.33 is released.
   -

   YP 4.0.18 is ready for release.


   -

   YP 5.0.1 Build Date 2024-05-13
   -

   YP 5.0.1 Release 

[OE-core] [PATCH 2/2] gstreamer1.0: skip another known flaky test

[Ross Burton]

The baseparse:parser_pull_short_read test is known to be unreliable,
according to the list of known bad tests in gst-devtools.

Also clean up an incorrect comment.

Signed-off-by: Ross Burton 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0/run-ptest | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0/run-ptest 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/run-ptest
index 7d0312005f4..ab2df80dcc2 100755
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0/run-ptest
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0/run-ptest
@@ -1,11 +1,13 @@
 #! /bin/sh
 
-# Multiply all timeouts by ten so they're more likely to work
-# on a loaded system.
+# Multiply all timeouts by five so they're more likely to work
+# on a loaded system. The default timeout is 20s so this makes it
+# one minute.
 export CK_TIMEOUT_MULTIPLIER=5
 
 # Skip some tests that we know are problematic
 export GST_CHECKS_IGNORE=""
+
 # gstnetclientclock.c:test_functioning is very sensitive to load
 GST_CHECKS_IGNORE="$GST_CHECKS_IGNORE,test_functioning"
 
@@ -13,4 +15,7 @@ GST_CHECKS_IGNORE="$GST_CHECKS_IGNORE,test_functioning"
 # https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/410
 GST_CHECKS_IGNORE="$GST_CHECKS_IGNORE,test_infinite_seek_50_src_live"
 
+# Known unreliable tests as per 
subprojects/gst-devtools/validate/launcher/testsuites/check.py:
+GST_CHECKS_IGNORE="$GST_CHECKS_IGNORE:parser_pull_short_read"
+
 gnome-desktop-testing-runner gstreamer
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199096): 
https://lists.openembedded.org/g/openembedded-core/message/199096
Mute This Topic: https://lists.openembedded.org/mt/105960405/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/2] curl: locale-base-en-us isn't glibc-specific

[Ross Burton]

The musl-locales package provides this too, so we can depend without a
libc override.

Signed-off-by: Ross Burton 
---
 meta/recipes-support/curl/curl_8.7.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/curl/curl_8.7.1.bb 
b/meta/recipes-support/curl/curl_8.7.1.bb
index c74416d7e9d..3fdad6a4cf8 100644
--- a/meta/recipes-support/curl/curl_8.7.1.bb
+++ b/meta/recipes-support/curl/curl_8.7.1.bb
@@ -120,6 +120,7 @@ do_install_ptest() {
 
 RDEPENDS:${PN}-ptest += " \
bash \
+   locale-base-en-us \
perl-module-b \
perl-module-base \
perl-module-cwd \
@@ -135,7 +136,6 @@ RDEPENDS:${PN}-ptest += " \
perl-module-storable \
perl-module-time-hires \
 "
-RDEPENDS:${PN}-ptest:append:libc-glibc = " locale-base-en-us"
 
 PACKAGES =+ "lib${BPN}"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199095): 
https://lists.openembedded.org/g/openembedded-core/message/199095
Mute This Topic: https://lists.openembedded.org/mt/105960404/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] [nanbield] git command included in buildtools-extended does not work with https authentication

[Richard Purdie]

On Tue, 2024-05-07 at 15:13 +0200, Christian Eggers via lists.openembedded.org 
wrote:
> I am in the process of upgrading from Kirkstone to Scarthgap (via Langdale,
> Mickledore and Nanbield). As my host system (openSUSE) doesn't meet the
> system requirements, I use the buildtools-extended tarball.
> 
> Since the migration step from Mickledore to Nanbield, I cannot access my
> company's GIT server (runing GitLab, requires https + authentifaction) 
> anymore.
> When I use the GIT client from openSUSE, everything works fine, but when
> the GIT command from the buildtools tarball is used, I get a 

Try using the buildtools straight from scarthgap. There have been
various problems but it should be fixed in that one.

Cheers,

Richard

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

[OE-core] [nanbield] git command included in buildtools-extended does not work with https authentication

[Christian Eggers]

I am in the process of upgrading from Kirkstone to Scarthgap (via Langdale,
Mickledore and Nanbield). As my host system (openSUSE) doesn't meet the
system requirements, I use the buildtools-extended tarball.

Since the migration step from Mickledore to Nanbield, I cannot access my
company's GIT server (runing GitLab, requires https + authentifaction) anymore.
When I use the GIT client from openSUSE, everything works fine, but when
the GIT command from the buildtools tarball is used, I get a

"remote: HTTP Basic: Access denied."

error message (log below). When I compare this log with the working version,
I see that ...
- h2 is used instead of http/1.1
- authentication happens straight after SSL setup (before the GET command)

Could the GIT client in the buildtools tarball be configured in a way that
it works with https + authentication?


GIT_TRACE_CURL=TRUE GIT_TRACE_CURL_NO_DATA=1 GIT_TRACE_REDACT=FALSE 
GIT_TRACE2_REDACT=FALSE git clone g...@git.mycompany.com:myrepo.git
Cloning into 'myrepo'...
12:35:38.736181 http.c:820  == Info:   Trying xxx.xxx.xxx.xxx:443...
12:35:38.736581 http.c:820  == Info: Connected to git.mycompany.com 
(xxx.xxx.xxx.xxx) port 443
12:35:38.738282 http.c:820  == Info: ALPN: curl offers http/1.1
12:35:38.738544 http.c:820  == Info: TLSv1.3 (OUT), TLS handshake, 
Client hello (1):
12:35:38.749279 http.c:820  == Info:  CAfile: 
/build/buildtools/sysroots/x86_64-pokysdk-linux/etc/ssl/certs/ca-certificates.crt
12:35:38.749303 http.c:820  == Info:  CApath: none
12:35:38.749385 http.c:820  == Info: TLSv1.3 (IN), TLS handshake, 
Server hello (2):
12:35:38.749698 http.c:820  == Info: TLSv1.3 (IN), TLS handshake, 
Encrypted Extensions (8):
12:35:38.749722 http.c:820  == Info: TLSv1.3 (IN), TLS handshake, 
Certificate (11):
12:35:38.750274 http.c:820  == Info: TLSv1.3 (IN), TLS handshake, 
CERT verify (15):
12:35:38.750368 http.c:820  == Info: TLSv1.3 (IN), TLS handshake, 
Finished (20):
12:35:38.750407 http.c:820  == Info: TLSv1.3 (OUT), TLS change 
cipher, Change cipher spec (1):
12:35:38.750432 http.c:820  == Info: TLSv1.3 (OUT), TLS handshake, 
Finished (20):
12:35:38.750537 http.c:820  == Info: SSL connection using TLSv1.3 / 
TLS_AES_256_GCM_SHA384
12:35:38.750546 http.c:820  == Info: ALPN: server accepted http/1.1
12:35:38.750555 http.c:820  == Info: Server certificate:
12:35:38.750571 http.c:820  == Info:  subject: CN=*.mycompany.com
12:35:38.750581 http.c:820  == Info:  start date: Feb 28 00:00:00 
2024 GMT
12:35:38.750589 http.c:820  == Info:  expire date: Mar 15 23:59:59 
2025 GMT
12:35:38.750606 http.c:820  == Info:  subjectAltName: host 
"git.mycompany.com" matched cert's "*.mycompany.com"
12:35:38.750622 http.c:820  == Info:  issuer: C=GB; ST=Greater 
Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation 
Secure Server CA
12:35:38.750629 http.c:820  == Info:  SSL certificate verify ok.

12:35:38.750632 http.c:820  == Info: using HTTP/1.1
   NOTE: openSUSE's GIT client uses 
HTTP/2 here and also performs authentication here.

12:35:38.750680 http.c:767  => Send header, 000247 bytes 
(0x00f7)
12:35:38.750688 http.c:779  => Send header: GET 
/myrepo.git/info/refs?service=git-upload-pack HTTP/1.1
12:35:38.750690 http.c:779  => Send header: Host: git.mycompany.com
12:35:38.750692 http.c:779  => Send header: User-Agent: git/2.42.0
12:35:38.750694 http.c:779  => Send header: Accept: */*
12:35:38.750696 http.c:779  => Send header: Accept-Encoding: 
deflate, gzip
12:35:38.750698 http.c:779  => Send header: Pragma: no-cache
12:35:38.750699 http.c:779  => Send header: Git-Protocol: version=2
12:35:38.750701 http.c:779  => Send header:
12:35:38.764115 http.c:820  == Info: TLSv1.3 (IN), TLS handshake, 
Newsession Ticket (4):
12:35:38.764234 http.c:820  == Info: TLSv1.3 (IN), TLS handshake, 
Newsession Ticket (4):
12:35:38.764247 http.c:820  == Info: old SSL session ID is stale, 
removing
12:35:38.774919 http.c:767  <= Recv header, 27 bytes 
(0x001b)
12:35:38.774944 http.c:779  <= Recv header: HTTP/1.1 401 
Unauthorized
   NOTE: working version returns 
"HTTP/2 401" here.

12:35:38.774947 http.c:767  <= Recv header, 15 bytes 
(0x000f)
12:35:38.774949 http.c:779  <= Recv header: Server: nginx
12:35:38.774953 http.c:767  <= Recv header, 37 bytes 
(0x0025)
12:35:38.774954 http.c:779  <= Recv header: Date: Tue, 07 May 2024 
12:35:38 GMT
12:35:38.774957 http.c:767   

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

[Alexander Kanavin]

From: Alexander Kanavin 

This scripts takes an existing, active yocto build, and puts pieces of it
into a bundle directory, which is then placed in a tarball, and that goes
into a self-extracting shell archive. This allows moving the bundle to another
machine, or placing it on a network server for downloads. It's like esdk
bundles, except inside there is a regular, plain, direct yocto build.

The bundle includes:
- copies of all layers used in a build, with their git histories
- build configuration as a template in a special layer private to the bundle
- (this is the best bit) all the sstate needed for the specified target,
but *only* that sstate and not a complete copy of the local cache.

When someone runs the self-extracting shell archive, everything
should 'just work': the layers are restored, and the build
set up to use them, the bundled sstate cache, and the template configuration.

Alternatively, it's possible to not include the cache, and presumably it will 
come
from a configured sstate mirror.

This enables at least two*scratch*three interesting use cases:

- moving builds around in single-step fashion: run the script, and give
the artifact to someone else via file sharing or usb sticks.

- publishing builds on the network, perhaps right next to the sstate
cache that can fulfil them. This allows an alternative, much smoother
entry point into 'doing yocto', as this guarantees availability of
needed cache items, and so builds will be a lot faster than the typical
'compile everything from scratch' yocto experience. Sstate is guaranteed
to be available, as there's a record of needed items in each bundle, and
that record can be used to prevent pruning of still-needed cache items.

- this, in turn, can enable 'binary Yocto distro' implemented with
sstate, if there's a higher level tool that creates bundles in a systematic,
structured fashion, and another tool that iterates over available bundles, and
lets users pick them for building locally.

Signed-off-by: Alexander Kanavin 
---
 meta/files/bundle-shar-extract.sh   | 55 +++
 meta/lib/oeqa/selftest/cases/sstatetests.py | 13 
 scripts/oe-replicate-build  | 75 +
 3 files changed, 143 insertions(+)
 create mode 100644 meta/files/bundle-shar-extract.sh
 create mode 100755 scripts/oe-replicate-build

diff --git a/meta/files/bundle-shar-extract.sh 
b/meta/files/bundle-shar-extract.sh
new file mode 100644
index 000..ae10dbaf065
--- /dev/null
+++ b/meta/files/bundle-shar-extract.sh
@@ -0,0 +1,55 @@
+#!/bin/bash
+
+verbose=0
+listcontents=0
+prepare_buildsystem="yes"
+while getopts "Dln" OPT; do
+case $OPT in
+D)
+verbose=1
+;;
+l)
+listcontents=1
+;;
+n)
+prepare_buildsystem="no"
+;;
+*)
+echo "Usage: $(basename "$0") [-D] [-l] [-n]"
+echo "  -D Use set -x to see what is going on"
+echo "  -l list files that will be extracted"
+echo "  -n Extract files but do not prepare the build 
system"
+exit 1
+;;
+esac
+done
+
+if [ $verbose = 1 ] ; then
+set -x
+fi
+
+payload_offset=$(($(grep -na -m1 "^MARKER:$" "$0"|cut -d':' -f1) + 1))
+
+if [ "$listcontents" = "1" ] ; then
+tail -n +$payload_offset "$0"| tar tv || exit 1
+exit
+fi
+
+
+tail -n +$payload_offset "$0"| tar mx --zstd --checkpoint=.2500 || exit 1
+
+if [ $prepare_buildsystem = "no" ] ; then
+exit
+fi
+
+target_dir=$(basename "$0" .sh)
+pushd $target_dir
+layers/setup-build setup -c build-config-default -b build --no-shell > 
setup-build.log
+popd
+
+echo "Each time you wish to use this build in a new shell session, you need to 
source the environment setup script:"
+echo " \$ . $target_dir/build/init-build-env"
+
+exit 0
+
+MARKER:
diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 94ad6e38b68..b59d0d2d1e8 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -1007,3 +1007,16 @@ MACHINE = "{}"
 def test_local_cache_qemuarm64(self):
 exceptions = []
 self.run_test("qemuarm64", "core-image-minimal core-image-full-cmdline 
core-image-sato-sdk", exceptions, check_cdn = False)
+
+class SStateBundles(SStateCheckObjectPresence):
+def test_minimal_bundle(self):
+targets = "core-image-minimal"
+machine = get_bb_var('MACHINE')
+bitbake("--runall build {}".format(targets))
+runCmd("oe-replicate-build --targets {}".format(targets))
+extractedbundledir = tempfile.mkdtemp(prefix='bundle-extracted-', 
dir=self.topdir)
+runCmd("../build-bundle.sh", cwd=extractedbundledir)
+result = runCmd(". build-bundle/build/init-build-env && MACHINE={} 
bitbake -DD -n 

[OE-core] [PATCH 1/9] bblayers/makesetup: raise exceptions when errors happen

[Alexander Kanavin]

From: Alexander Kanavin 

Otherwise the calling code can only issue a generic, unhelpful
erorr message, and it's difficult to tell what went wrong
if logger.error output is obscured or redirected.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/bblayers/makesetup.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/lib/bblayers/makesetup.py b/meta/lib/bblayers/makesetup.py
index 99d59737602..8148b0d9ff4 100644
--- a/meta/lib/bblayers/makesetup.py
+++ b/meta/lib/bblayers/makesetup.py
@@ -48,8 +48,9 @@ class MakeSetupPlugin(LayerPlugin):
 if l_name == 'workspace':
 continue
 if l_ismodified:
-logger.error("Layer {name} in {path} has uncommitted 
modifications or is not in a git repository.".format(name=l_name,path=l_path))
-return
+e = "Layer {name} in {path} has uncommitted modifications or 
is not in a git repository.".format(name=l_name,path=l_path)
+logger.error(e)
+raise Exception(e)
 repo_path = oe.buildcfg.get_metadata_git_toplevel(l_path)
 
 if self._is_submodule(repo_path):
@@ -63,8 +64,9 @@ class MakeSetupPlugin(LayerPlugin):
 if repo_path == destdir_repo:
 repos[repo_path]['contains_this_file'] = True
 if not repos[repo_path]['git-remote']['remotes'] and not 
repos[repo_path]['contains_this_file']:
-logger.error("Layer repository in {path} does not have any 
remotes configured. Please add at least one with 'git remote 
add'.".format(path=repo_path))
-return
+e = "Layer repository in {path} does not have any remotes 
configured. Please add at least one with 'git remote 
add'.".format(path=repo_path)
+logger.error(e)
+raise Exception(e)
 
 top_path = os.path.commonpath([os.path.dirname(r) for r in 
repos.keys()])
 
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199084): 
https://lists.openembedded.org/g/openembedded-core/message/199084
Mute This Topic: https://lists.openembedded.org/mt/105958239/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/9] selftest/sstatetests: separate sstate presence check into its own class

[Alexander Kanavin]

From: Alexander Kanavin 

This allows reusing the check function in tests other than CDN/local mirror
ones, such as sstate bundle testing.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oeqa/selftest/cases/sstatetests.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 86d6cd7464f..8f843139ebc 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -917,8 +917,7 @@ INHERIT += "base-do-configure-modified"
 """,
 expected_sametmp_output, expected_difftmp_output)
 
-@OETestTag("yocto-mirrors")
-class SStateMirrors(SStateBase):
+class SStateCheckObjectPresence(SStateBase):
 def check_bb_output(self, output, exceptions, check_cdn):
 def is_exception(object, exceptions):
 for e in exceptions:
@@ -960,6 +959,8 @@ class SStateMirrors(SStateBase):
 self.assertEqual(len(failed_urls), missing_objects, "Amount of 
reported missing objects does not match failed URLs: {}\nFailed 
URLs:\n{}\nFetcher diagnostics:\n{}".format(missing_objects, 
"\n".join(failed_urls), "\n".join(failed_urls_extrainfo)))
 self.assertEqual(len(failed_urls), 0, "Missing objects in the 
cache:\n{}\nFetcher diagnostics:\n{}".format("\n".join(failed_urls), 
"\n".join(failed_urls_extrainfo)))
 
+@OETestTag("yocto-mirrors")
+class SStateMirrors(SStateCheckObjectPresence):
 def run_test(self, machine, targets, exceptions, check_cdn = True, 
ignore_errors = False):
 # sstate is checked for existence of these, but they never get written 
out to begin with
 exceptions += ["{}.*image_qa".format(t) for t in targets.split()]
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199090): 
https://lists.openembedded.org/g/openembedded-core/message/199090
Mute This Topic: https://lists.openembedded.org/mt/105958246/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 8/9] selftest/sstatetests: move exception list for cache objects to the parent class

[Alexander Kanavin]

From: Alexander Kanavin 

This is useful not just in cdn/local cache tests, but also in the build bundle 
test,
and so should be applied by default.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oeqa/selftest/cases/sstatetests.py | 26 ++---
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 8f843139ebc..94ad6e38b68 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -918,13 +918,24 @@ INHERIT += "base-do-configure-modified"
 expected_sametmp_output, expected_difftmp_output)
 
 class SStateCheckObjectPresence(SStateBase):
-def check_bb_output(self, output, exceptions, check_cdn):
+def check_bb_output(self, output, targets, exceptions, check_cdn):
 def is_exception(object, exceptions):
 for e in exceptions:
 if re.search(e, object):
 return True
 return False
 
+# sstate is checked for existence of these, but they never get written 
out to begin with
+exceptions += ["{}.*image_qa".format(t) for t in targets.split()]
+exceptions += ["{}.*deploy_source_date_epoch".format(t) for t in 
targets.split()]
+exceptions += ["{}.*image_complete".format(t) for t in targets.split()]
+exceptions += ["linux-yocto.*shared_workdir"]
+# these get influnced by IMAGE_FSTYPES tweaks in 
yocto-autobuilder-helper's config.json (on x86-64)
+# additionally, they depend on noexec (thus, absent stamps) package, 
install, etc. image tasks,
+# which makes tracing other changes difficult
+exceptions += ["{}.*create_spdx".format(t) for t in targets.split()]
+exceptions += ["{}.*create_runtime_spdx".format(t) for t in 
targets.split()]
+
 output_l = output.splitlines()
 for l in output_l:
 if l.startswith("Sstate summary"):
@@ -962,17 +973,6 @@ class SStateCheckObjectPresence(SStateBase):
 @OETestTag("yocto-mirrors")
 class SStateMirrors(SStateCheckObjectPresence):
 def run_test(self, machine, targets, exceptions, check_cdn = True, 
ignore_errors = False):
-# sstate is checked for existence of these, but they never get written 
out to begin with
-exceptions += ["{}.*image_qa".format(t) for t in targets.split()]
-exceptions += ["{}.*deploy_source_date_epoch".format(t) for t in 
targets.split()]
-exceptions += ["{}.*image_complete".format(t) for t in targets.split()]
-exceptions += ["linux-yocto.*shared_workdir"]
-# these get influnced by IMAGE_FSTYPES tweaks in 
yocto-autobuilder-helper's config.json (on x86-64)
-# additionally, they depend on noexec (thus, absent stamps) package, 
install, etc. image tasks,
-# which makes tracing other changes difficult
-exceptions += ["{}.*create_spdx".format(t) for t in targets.split()]
-exceptions += ["{}.*create_runtime_spdx".format(t) for t in 
targets.split()]
-
 if check_cdn:
 self.config_sstate(True)
 self.append_config("""
@@ -988,7 +988,7 @@ MACHINE = "{}"
 bitbake("-S none {}".format(targets))
 if ignore_errors:
 return
-self.check_bb_output(result.output, exceptions, check_cdn)
+self.check_bb_output(result.output, targets, exceptions, check_cdn)
 
 def test_cdn_mirror_qemux86_64(self):
 exceptions = []
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199091): 
https://lists.openembedded.org/g/openembedded-core/message/199091
Mute This Topic: https://lists.openembedded.org/mt/105958247/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/9] lib/oe/sstatesig.py: add an option to make a unihash cache copy

[Alexander Kanavin]

From: Alexander Kanavin 

This is already performed in eSDK creation; the change allows also
making a copy with a standalone 'bitbake -S unihash-cache-copy targets...'
command, which is useful for replicating builds on a different build host
(simply coping sstate objects is not enough if they need to be discovered
through unihash redirections).

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/sstatesig.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index a46e5502ab3..5dfd180e7f2 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -147,6 +147,10 @@ class SignatureGeneratorOEBasicHashMixIn(object):
 sigfile = os.getcwd() + "/locked-sigs.inc"
 bb.plain("Writing locked sigs to %s" % sigfile)
 self.dump_lockedsigs(sigfile)
+if 'unihash-cache-copy' in options:
+cachefile = os.getcwd() + "/bb_unihashes.dat"
+bb.plain("Writing unihash cache to %s" % cachefile)
+bb.parse.siggen.copy_unitaskhashes(os.getcwd())
 return super(bb.siggen.SignatureGeneratorBasicHash, 
self).dump_sigs(dataCache, options)
 
 
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199088): 
https://lists.openembedded.org/g/openembedded-core/message/199088
Mute This Topic: https://lists.openembedded.org/mt/105958243/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/9] bblayers/setupwriters/oe-local-copy: add a 'local copy' plugin for bitbake-layers create-layer-setup

[Alexander Kanavin]

From: Alexander Kanavin 

This plugin copies all currently configured layer respositories into
a dedicated location on local disk. This is useful for entirely offline
layer replication, when the layers are packed and then unpacked from
an archive, rather than fetched from git (there can be situations
where fetching from git is undesirable or impossible).

This plugin will also be used when replicating an entire yocto build
(with build config and sstate cache), and is an element of that.

This plugin is similar to what esdk does, and it provides that functionality
outside of populate_sdk_ext task. It does not reuse esdk code,
as that simply copies the layer tree; it's better to use 'git clone'
with a path to original repo on local disk, as that will preserve
commit history in the copy.

Signed-off-by: Alexander Kanavin 
---
 .../bblayers/setupwriters/oe-local-copy.py| 41 +++
 meta/lib/oeqa/selftest/cases/bblayers.py  | 13 ++
 2 files changed, 54 insertions(+)
 create mode 100644 meta/lib/bblayers/setupwriters/oe-local-copy.py

diff --git a/meta/lib/bblayers/setupwriters/oe-local-copy.py 
b/meta/lib/bblayers/setupwriters/oe-local-copy.py
new file mode 100644
index 000..8c1ccb67368
--- /dev/null
+++ b/meta/lib/bblayers/setupwriters/oe-local-copy.py
@@ -0,0 +1,41 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+import logging
+import json
+
+logger = logging.getLogger('bitbake-layers')
+
+def plugin_init(plugins):
+return OeLocalCopyWriter()
+
+class OeLocalCopyWriter():
+
+def __str__(self):
+return "oe-local-copy"
+
+def do_write(self, parent, args):
+""" Writes out a local copy of all the metadata layers (and bitbake) 
included in a current build. """
+if not os.path.exists(args.destdir):
+os.makedirs(args.destdir)
+repos = parent.make_repo_config(args.destdir)
+if not repos:
+raise Exception("Could not determine layer sources")
+output = os.path.join(os.path.abspath(args.destdir), 
args.output_prefix or "layers")
+json_f = os.path.join(os.path.abspath(args.destdir), 
"bundle-repos.json")
+
+for r in repos.values():
+r['git-remote']['remotes'] = {"origin":{"uri":r["originpath"]}}
+
+json_data = {"version":"1.0","sources":repos}
+with open(json_f, 'w') as f:
+json.dump(json_data, f, sort_keys=True, indent=4)
+
+logger.info("Cloning repositories into {}".format(output))
+bb.process.run('oe-setup-layers --force-bootstraplayer-checkout 
--destdir {} --jsondata {}'.format(output, json_f))
+
+def register_arguments(self, parser):
+pass
diff --git a/meta/lib/oeqa/selftest/cases/bblayers.py 
b/meta/lib/oeqa/selftest/cases/bblayers.py
index 695d17377d4..8b2bc319d50 100644
--- a/meta/lib/oeqa/selftest/cases/bblayers.py
+++ b/meta/lib/oeqa/selftest/cases/bblayers.py
@@ -240,3 +240,16 @@ class BitbakeLayers(OESelftestTestCase):
 self.assertEqual(first_desc_2, '', "Describe not cleared: 
'{}'".format(first_desc_2))
 self.assertEqual(second_rev_2, second_rev_1, "Revision should not be 
updated: '{}'".format(second_rev_2))
 self.assertEqual(second_desc_2, second_desc_1, "Describe should not be 
updated: '{}'".format(second_desc_2))
+
+def test_bitbakelayers_setup_localcopy(self):
+testcopydir = os.path.join(self.builddir, 'test-layer-copy')
+result = runCmd('bitbake-layers create-layers-setup --writer 
oe-local-copy {}'.format(testcopydir))
+oe_core_found = False
+meta_selftest_found = False
+for topdir, subdirs, files in os.walk(testcopydir):
+if topdir.endswith('meta/conf') and 'layer.conf' in files:
+oe_core_found = True
+if topdir.endswith('meta-selftest/conf') and 'layer.conf' in files:
+meta_selftest_found = True
+self.assertTrue(oe_core_found, "meta/conf/layer.conf not found in 
{}".format(testcopydir))
+self.assertTrue(meta_selftest_found, "meta-selftest/conf/layer.conf 
not found in {}".format(testcopydir))
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199087): 
https://lists.openembedded.org/g/openembedded-core/message/199087
Mute This Topic: https://lists.openembedded.org/mt/105958242/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/9] sstatesig/dump_sigs: allow setting output directory explicitly from command line option

[Alexander Kanavin]

From: Alexander Kanavin 

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

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/sstatesig.py | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 5dfd180e7f2..f885bb54f64 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -143,14 +143,19 @@ class SignatureGeneratorOEBasicHashMixIn(object):
 super().set_taskdata(data[3:])
 
 def dump_sigs(self, dataCache, options):
+outdir = os.getcwd()
+for o in options:
+if o.startswith('outdir'):
+outdir = o.split('=')[1]
+
 if 'lockedsigs' in options:
-sigfile = os.getcwd() + "/locked-sigs.inc"
+sigfile = outdir + "/locked-sigs.inc"
 bb.plain("Writing locked sigs to %s" % sigfile)
 self.dump_lockedsigs(sigfile)
 if 'unihash-cache-copy' in options:
-cachefile = os.getcwd() + "/bb_unihashes.dat"
+cachefile = outdir + "/bb_unihashes.dat"
 bb.plain("Writing unihash cache to %s" % cachefile)
-bb.parse.siggen.copy_unitaskhashes(os.getcwd())
+bb.parse.siggen.copy_unitaskhashes(outdir)
 return super(bb.siggen.SignatureGeneratorBasicHash, 
self).dump_sigs(dataCache, options)
 
 
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199089): 
https://lists.openembedded.org/g/openembedded-core/message/199089
Mute This Topic: https://lists.openembedded.org/mt/105958244/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/9] bblayers/makesetup: include local repository paths in discovered layer repo data

[Alexander Kanavin]

From: Alexander Kanavin 

This can be useful when the caller needs to know where the repos actually
are on local disk (for example to make a local copy of them or obtain
additional information about them).

This field however should be removed from the json output in oe-setup-layers
plugin, as it is host-specific and not part of the schema.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/bblayers/makesetup.py| 1 +
 meta/lib/bblayers/setupwriters/oe-setup-layers.py | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/meta/lib/bblayers/makesetup.py b/meta/lib/bblayers/makesetup.py
index 8148b0d9ff4..48dc73c288d 100644
--- a/meta/lib/bblayers/makesetup.py
+++ b/meta/lib/bblayers/makesetup.py
@@ -76,6 +76,7 @@ class MakeSetupPlugin(LayerPlugin):
 repos_nopaths[r_nopath] = repos[r]
 r_relpath = os.path.relpath(r, top_path)
 repos_nopaths[r_nopath]['path'] = r_relpath
+repos_nopaths[r_nopath]['originpath'] = r
 return repos_nopaths
 
 def do_make_setup(self, args):
diff --git a/meta/lib/bblayers/setupwriters/oe-setup-layers.py 
b/meta/lib/bblayers/setupwriters/oe-setup-layers.py
index 59ca968ff33..56c929471e6 100644
--- a/meta/lib/bblayers/setupwriters/oe-setup-layers.py
+++ b/meta/lib/bblayers/setupwriters/oe-setup-layers.py
@@ -85,6 +85,8 @@ class OeSetupLayersWriter():
 if not os.path.exists(args.destdir):
 os.makedirs(args.destdir)
 repos = parent.make_repo_config(args.destdir)
+for r in repos.values():
+del r['originpath']
 json = {"version":"1.0","sources":repos}
 if not repos:
 err = "Could not determine layer sources"
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199085): 
https://lists.openembedded.org/g/openembedded-core/message/199085
Mute This Topic: https://lists.openembedded.org/mt/105958240/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/9] bblayers/makesetup: move check for existence of git remotes to oe-setup-layers plugin

[Alexander Kanavin]

From: Alexander Kanavin 

This helps when making a local copy of all the layers: it's fine to
not have any remotes configured in that case.

Also correct the mistake in accessing 'contains_this_file' property:
it may not necessarily exist, and if so, it should default to False.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/bblayers/makesetup.py| 4 
 meta/lib/bblayers/setupwriters/oe-setup-layers.py | 3 +++
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/lib/bblayers/makesetup.py b/meta/lib/bblayers/makesetup.py
index 48dc73c288d..4199b5f0698 100644
--- a/meta/lib/bblayers/makesetup.py
+++ b/meta/lib/bblayers/makesetup.py
@@ -63,10 +63,6 @@ class MakeSetupPlugin(LayerPlugin):
 
'describe':oe.buildcfg.get_metadata_git_describe(repo_path)}}
 if repo_path == destdir_repo:
 repos[repo_path]['contains_this_file'] = True
-if not repos[repo_path]['git-remote']['remotes'] and not 
repos[repo_path]['contains_this_file']:
-e = "Layer repository in {path} does not have any remotes 
configured. Please add at least one with 'git remote 
add'.".format(path=repo_path)
-logger.error(e)
-raise Exception(e)
 
 top_path = os.path.commonpath([os.path.dirname(r) for r in 
repos.keys()])
 
diff --git a/meta/lib/bblayers/setupwriters/oe-setup-layers.py 
b/meta/lib/bblayers/setupwriters/oe-setup-layers.py
index 56c929471e6..8faeabfabc8 100644
--- a/meta/lib/bblayers/setupwriters/oe-setup-layers.py
+++ b/meta/lib/bblayers/setupwriters/oe-setup-layers.py
@@ -86,6 +86,9 @@ class OeSetupLayersWriter():
 os.makedirs(args.destdir)
 repos = parent.make_repo_config(args.destdir)
 for r in repos.values():
+if not r['git-remote']['remotes'] and not 
r.get('contains_this_file', False):
+e = "Layer repository in {path} does not have any remotes 
configured. Please add at least one with 'git remote 
add'.".format(path=r['originpath'])
+raise Exception(e)
 del r['originpath']
 json = {"version":"1.0","sources":repos}
 if not repos:
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199086): 
https://lists.openembedded.org/g/openembedded-core/message/199086
Mute This Topic: https://lists.openembedded.org/mt/105958241/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 v2 07/11] kea: Remove -fvisibility-inlines-hidden from C++ flags

[Alexander Kanavin]

On Tue, 7 May 2024 at 07:33, Khem Raj via lists.openembedded.org
 wrote:

> +CXXFLAGS:remove = "-fvisibility-inlines-hidden"

Same comment as v1: this seems like the wrong way around. Why do we
have it as a global glibc/musl setting in the first place? Shouldn't
we just remove it from there? I did some digging and this line was
imported from oe-classic in 2010 with eglibc definition,  so most
likely whatever reasons there used to be are long obsolete.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199083): 
https://lists.openembedded.org/g/openembedded-core/message/199083
Mute This Topic: https://lists.openembedded.org/mt/105955497/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 07/10] kea: Remove -fvisibility-inlines-hidden from C++ flags

[Alexander Kanavin]

On Tue, 7 May 2024 at 03:15, Khem Raj via lists.openembedded.org
 wrote:

> +CXXFLAGS:remove = "-fvisibility-inlines-hidden"

This seems like the wrong way around. Why do we have it as a global
glibc/musl setting in the first place? Shouldn't we just remove it
from there? I did some digging and this line was imported from
oe-classic in 2010 with eglibc definition, so most likely whatever
reasons there used to be are long obsolete.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199082): 
https://lists.openembedded.org/g/openembedded-core/message/199082
Mute This Topic: https://lists.openembedded.org/mt/105952338/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][kirkstone][PATCH] xz: Update LICENSE variable for xz packages

[Alexander Kanavin]

PD is not a license for legal compliance purposes, but it's a valid
identifier in a recipe's LICENSE field. We have plenty of those
already.

Also, shouldn't this be addressed in master first?

Alex

On Mon, 6 May 2024 at 17:33, Marta Rybczynska via
lists.openembedded.org 
wrote:
>
>
>
> On Mon, 6 May 2024, 13:09 nikhil via lists.openembedded.org, 
>  wrote:
>>
>> Update LICENSE defined for xz packages to match the license
>> information provided in the xz COPYING file.
>>
>> The License information from PACKAGERS file of xz mentions
>> packages with lzma files are in public domain.They ask to
>> use GPLv2+, if only it's not possible to mention "PD and GPLv2+".
>>
>> Include PD license with GPLv2 to packages with lzma content:
>> xz-dev package contains lzma header
>> xz-doc package contains lzma man pages
>> xz packages contains lzma binaries
>>
>> Links: https://github.com/tukaani-project/xz/blob/v5.2.6/COPYING
>>https://github.com/tukaani-project/xz/blob/v5.4.1/PACKAGERS
>>
>> Signed-off-by: Bhabu Bindu 
>> ---
>>  meta/recipes-extended/xz/xz_5.2.6.bb | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/recipes-extended/xz/xz_5.2.6.bb 
>> b/meta/recipes-extended/xz/xz_5.2.6.bb
>> index 3482622471..33496748bc 100644
>> --- a/meta/recipes-extended/xz/xz_5.2.6.bb
>> +++ b/meta/recipes-extended/xz/xz_5.2.6.bb
>> @@ -9,10 +9,10 @@ SECTION = "base"
>>  # libgnu, which appears to be used for DOS builds. So we're left with
>>  # GPL-2.0-or-later and PD.
>>  LICENSE = "GPL-2.0-or-later & GPL-3.0-with-autoconf-exception & 
>> LGPL-2.1-or-later & PD"
>> -LICENSE:${PN} = "GPL-2.0-or-later"
>> -LICENSE:${PN}-dev = "GPL-2.0-or-later"
>> +LICENSE:${PN} = "PD & GPL-2.0-or-later"
>> +LICENSE:${PN}-dev = "PD & GPL-2.0-or-later"
>>  LICENSE:${PN}-staticdev = "GPL-2.0-or-later"
>> -LICENSE:${PN}-doc = "GPL-2.0-or-later"
>> +LICENSE:${PN}-doc = "PD & GPL-2.0-or-later"
>>  LICENSE:${PN}-dbg = "GPL-2.0-or-later"
>>  LICENSE:${PN}-locale = "GPL-2.0-or-later"
>>  LICENSE:liblzma = "PD"
>> --
>> 2.25.1
>
>
> I'm not a copyright lawyer, but from what I understand public domain is not a 
> licence. For a discussion see 
> https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files
>
> The next version of xz will be 0BSD so the statement will change too.
>
> Regards,
> Marta
>
>
> 
>

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