date:20220302

On 03.03.22 00:05, Richard Purdie wrote:

On Wed, 2022-03-02 at 21:55 +0100, Konrad Weihmann wrote:

An interesting behavior struck me once more after a long long time.

*** 0002:extend_recipe_sysroot(d)
0003:
File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 584,
function: extend_recipe_sysroot
0580:if "/bin/" in l or "/sbin/" in l:
0581:# defer /*bin/* files until last in
case they need libs
0582:binfiles[l] = (targetdir, dest)
0583:else:
*** 0584:staging_copyfile(l, targetdir, dest,
postinsts, seendirs)
0585:
0586:# Handle deferred binfiles
0587:for l in binfiles:
0588:(targetdir, dest) = binfiles[l]
File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 158,
function: staging_copyfile
0154:os.symlink(linkto, dest)
0155:#bb.warn(c)
0156:else:
0157:try:
*** 0158:os.link(c, dest)
0159:except OSError as err:
0160:if err.errno == errno.EXDEV:
0161:bb.utils.copyfile(c, dest)
0162:else:
Exception: FileExistsError: [Errno 17] File exists:
'/build/tmp/sysroots-components/x86_64/some/path/to/some/deeply/nested/file'
->
'/build/tmp/work/x86_64-linux/some-recipe/1.0-r0/recipe-sysroot-native/some/path/to/some/deeply/nested/file'

This happens in rare case when doing a differential build o a recipe
with hundreds or thousands of native dependencies.

The file mentioned is pretty much random and it's unique (no duplicates
among all the dependencies when it comes to filename+path).

So far I helped myself with ignoring this error by adding

except FileExistsError:
pass

to staging - I wonder if anyone else ever seen this behavior and what's
the best way to deal with it

What comes to my mind is

- ignoring it - but then no one can be sure it's the right file
- falling back to the OSError/EXDEV path and copying over the file requested
- a 3rd option

Any thoughts?

(Just to be sure, this happens like once in a thousand builds and only
on differential builds)

My initial thought is that is a horrible work around and we need to get to the
real issue.

The question is where is the duplicate file coming from and why.

Also, is this dunfell or master or something else? There were issues that were
fixed in these codepaths after dunfell.

Is there anything significant about the kinds of files this is being hit with.
For example are they generated pyc files? We have see that issue before. Is
there anything significant about the path lengths involved? It is hard to tell
from the information provided.

To shed some light on it - no it's current master (head of yesterday)
and it's no regarding some pyc, as I normally remove them by a different
class in my builds.
As I said, the error hits on pretty random file, one time it's a code
file, one time it a LICENSE file - I don't see any pattern in there.

And I agree one need to get to the bottom of it, which indeed difficult
as this hits me like once in every 3-4 months and usually a sstate clean
fixes it for me.

TBH I have no idea how to get into this state, but once you're in there
it can be reproduced with a 100% certainty.

The only thing I see is, that the more build time dependencies one
injects the more likely it's going to hit.
In today incident I rebuild npm-native, which cause the rebuild of like
~5000 dependencies to be setup for a particular workspace.
Anyway just to assure you it's not about npm, I encountered the very
same on a recipe that had like ~250 python dependencies.

My question is, what should I do, next time this hits me.
What kind of trace and/or info you would need to analyze this, as I have
admit this is beyond my understanding of bitbake/OE

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162630):
https://lists.openembedded.org/g/openembedded-core/message/162630
Mute This Topic: https://lists.openembedded.org/mt/89511363/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] staging: FileExistsError

On Wed, 2022-03-02 at 21:55 +0100, Konrad Weihmann wrote:
> An interesting behavior struck me once more after a long long time.
> 
>   *** 0002:extend_recipe_sysroot(d)
>   0003:
> File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 584, 
> function: extend_recipe_sysroot
>   0580:if "/bin/" in l or "/sbin/" in l:
>   0581:# defer /*bin/* files until last in 
> case they need libs
>   0582:binfiles[l] = (targetdir, dest)
>   0583:else:
>   *** 0584:staging_copyfile(l, targetdir, dest, 
> postinsts, seendirs)
>   0585:
>   0586:# Handle deferred binfiles
>   0587:for l in binfiles:
>   0588:(targetdir, dest) = binfiles[l]
> File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 158, 
> function: staging_copyfile
>   0154:os.symlink(linkto, dest)
>   0155:#bb.warn(c)
>   0156:else:
>   0157:try:
>   *** 0158:os.link(c, dest)
>   0159:except OSError as err:
>   0160:if err.errno == errno.EXDEV:
>   0161:bb.utils.copyfile(c, dest)
>   0162:else:
> Exception: FileExistsError: [Errno 17] File exists: 
> '/build/tmp/sysroots-components/x86_64/some/path/to/some/deeply/nested/file' 
> -> 
> '/build/tmp/work/x86_64-linux/some-recipe/1.0-r0/recipe-sysroot-native/some/path/to/some/deeply/nested/file'
> 
> This happens in rare case when doing a differential build o a recipe 
> with hundreds or thousands of native dependencies.
> 
> The file mentioned is pretty much random and it's unique (no duplicates 
> among all the dependencies when it comes to filename+path).
> 
> So far I helped myself with ignoring this error by adding
> 
>  except FileExistsError:
>  pass
> 
> to staging - I wonder if anyone else ever seen this behavior and what's 
> the best way to deal with it
> 
> What comes to my mind is
> 
> - ignoring it - but then no one can be sure it's the right file
> - falling back to the OSError/EXDEV path and copying over the file requested
> - a 3rd option
> 
> Any thoughts?
> 
> (Just to be sure, this happens like once in a thousand builds and only 
> on differential builds)

My initial thought is that is a horrible work around and we need to get to the
real issue.

The question is where is the duplicate file coming from and why.

Also, is this dunfell or master or something else? There were issues that were
fixed in these codepaths after dunfell.

Is there anything significant about the kinds of files this is being hit with.
For example are they generated pyc files? We have see that issue before. Is
there anything significant about the path lengths involved? It is hard to tell
from the information provided.

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162629): 
https://lists.openembedded.org/g/openembedded-core/message/162629
Mute This Topic: https://lists.openembedded.org/mt/89511363/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] wic: Use custom kernel path if provided

On Tue, 2022-02-15 at 16:54 +, Bill Pittman wrote:
> If the custom kernel path is provided in options, then
> use that path instead of the default path.
> 
> Signed-off-by: Bill Pittman 
> ---
>  scripts/wic | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/scripts/wic b/scripts/wic
> index a741aed364..29a157bf37 100755
> --- a/scripts/wic
> +++ b/scripts/wic
> @@ -159,6 +159,9 @@ def wic_create_subcommand(options, usage_str):
>                             "(Use -e/--image-name to specify it)")
>          native_sysroot = options.native_sysroot
>  
> +    if options.kernel_dir:
> +        kernel_dir = options.kernel_dir
> +
>      if not options.vars_dir and (not native_sysroot or not
> os.path.isdir(native_sysroot)):
>          logger.info("Building wic-tools...\n")
>          subprocess.check_call(["bitbake", "wic-tools"])


The concern with these kinds of changes is I can't really test it or tell if it
is the right thing to do and I worry about it regressing in the future.

Is there part of the test coverage we should be improving too? wic does have
fairly good coverage from oe-selftest -r wic

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162628): 
https://lists.openembedded.org/g/openembedded-core/message/162628
Mute This Topic: https://lists.openembedded.org/mt/89165206/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] wic: Use custom kernel path if provided

2022-03-02 Thread Andrei Gherzan


Feb 15, 2022 16:54:28 Bill Pittman :

> If the custom kernel path is provided in options, then
> use that path instead of the default path.

Just to understand this a bit, what is your usecase here?
--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162627): 
https://lists.openembedded.org/g/openembedded-core/message/162627
Mute This Topic: https://lists.openembedded.org/mt/89165206/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/1] go.bbclass: Allow network in do_compile

2022-03-02 Thread Andrei Gherzan


Mar 1, 2022 20:15:52 Bruce Ashfield :

> On Tue, Mar 1, 2022 at 10:54 AM  wrote:
>>
>> On Tue, Mar 1, 2022 at 02:14 PM, Bruce Ashfield wrote:
>>
>> On Tue, Mar 1, 2022 at 6:42 AM Andrei Gherzan  wrote:
>>
>>
>> On Tue, 1 Mar 2022, at 01:55, Bruce Ashfield wrote:
>>
>> On Mon, Feb 28, 2022 at 8:17 PM Bruce Ashfield via
>> lists.openembedded.org
>>  wrote:
>>
>>
>> On Mon, Feb 28, 2022 at 6:54 PM Andrei Gherzan  wrote:
>>
>>
>> From: Andrei Gherzan 
>>
>> Compile pulls in the go.mod list requiring network. Without this, do
>> compile would fail with a similar error to the following:
>>
>> dial tcp: lookup proxy.golang.org: Temporary failure in name resolution
>>
>> This is something that needs to be carried in your own layers, IMHO it
>> isn't appropriate for core.
>>
>> It isn't about the fetching, it is the entire gap in functionality
>> that we are missing if go starts fetching dependencies during compile.
>>
>> A further thought is that if this is for go.mod issues, there is the
>> go-mod.bbclass.
>>
>> Perhaps enabling it in that class and doing a bbwarn about go fetching
>> dependencies would be appropriate ?
>>
>> Otherwise, someone may not know that this is happening and that a no
>> network configuration has no chance of working.
>>
>> I reckon that is reasonable. I'll personally go down the recipe level to 
>> workaround this change but understanding and agreeing with the reasoning 
>> behind this change, I want to invest a bit into trying to find a proper 
>> solution in the core. Bruce, I know you invested a fair amount of time into 
>> this already. Would you be willing to sync up and see how we can work 
>> together in tackling this?
>>
>> Definitely, more ideas are good. In fact, I think there are probably
>> several approaches that can co-exist, depending on what a
>> recipe/developer needs.
>>
>> I'm in the Eastern time zone here, and will try and grab folks on IRC
>> to have a level set
>>
>> Bruce
>>
>> Added Zyga to CC as he is also interested in this as part of his go 
>> development activities.
>>
>> Thanks,
>> Andrei
>>
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>>
>> The problem in allowing downloads during compile (e.g. by go) is, that it 
>> leads to non-reproducable builds. I'm currently facing the same issue and 
>> would like to have a reproducable go *offline* build.
>> I would like to propose two ideas to workaround the go-compile fetching 
>> issue:
>>
>> First:
>> - Fetch go-dependencies using go.mod file from 'proxy.golang.org' (e.g. by 
>> writing a seperate go fetcher or a wget-fetcher) and unpack the dependencies 
>> into go projects 'vendor' folder. This forces go to compile offline. 
>> However, one have to generate the 'modules.txt' file in the vendor folder 
>> 'manually' during unpack. This is error prone, as there is no official 
>> documentation how this format should look like. Anyway, I've tried this 
>> approach and it works for me.
>>
>> Second:
>> - Fetch go-dependencies using go.mod file from 'proxy.golang.org' (e.g. by 
>> writing a seperate go fetcher) and unpack the dependencies into a local 
>> (workdir) go-path. This seemed a good solution for me as the go-path is well 
>> defined. But for some reason 'go'  fetches the zip-files during compile into 
>> it's download-cache AGAIN, even if the source is already unpacked in the 
>> go-path. I'll assume this is required to verify the source files integrity?! 
>> With this approach one have to adapt 'go' to suppress this download 
>> behaviour.
>>
>
> I've been doing offline builds using a constructed vendor/ directory
> and generated modules.txt.
>
> The only difference between what I have working and what you are
> suggesting (type 1), is that I've gone directly to the sources and
> constructed the vendor directory using the OE git fetcher. That allows
> all functionality to continue to work that is part of OEcore, and the
> build to continue.  Switching out the git fetches for tarballs would
> be possible, I just wasn't sure how to use the proxied modules (and I
> wanted the history for debug).
>
> I've never had any issues with the modules.txt, as I generate it at
> the same time as the git fetch lines for the SRC_URI. I've also not
> been using information from the go.mod directly from go.proxy.org, it
> is information I've generated from a clone of the project and dumped
> via go mod. There's likely improvements I can do there, but with what
> I'm doing, I'm going directly to the source of the projects and doing
> clones, which keeps everything clear of the go infrastructure.
>
> I have a utility that I'm still cleaning up that generates the SRC_URI
> lines, as well as the modules.txt, when I resolve a few nagging
> issues, I'll make the WIP scripts available.
>
> Other projects (BSD, etc), have been doing different sorts of
> constructed vendor directories, but they are similar in approach.

[OE-core] test email from AUH

2022-03-02 Thread Auto Upgrade Helper

this is a test email

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

[OE-core] staging: FileExistsError


An interesting behavior struck me once more after a long long time.

 *** 0002:extend_recipe_sysroot(d)
 0003:
File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 584, 
function: extend_recipe_sysroot

 0580:if "/bin/" in l or "/sbin/" in l:
 0581:# defer /*bin/* files until last in 
case they need libs

 0582:binfiles[l] = (targetdir, dest)
 0583:else:
 *** 0584:staging_copyfile(l, targetdir, dest, 
postinsts, seendirs)

 0585:
 0586:# Handle deferred binfiles
 0587:for l in binfiles:
 0588:(targetdir, dest) = binfiles[l]
File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 158, 
function: staging_copyfile

 0154:os.symlink(linkto, dest)
 0155:#bb.warn(c)
 0156:else:
 0157:try:
 *** 0158:os.link(c, dest)
 0159:except OSError as err:
 0160:if err.errno == errno.EXDEV:
 0161:bb.utils.copyfile(c, dest)
 0162:else:
Exception: FileExistsError: [Errno 17] File exists: 
'/build/tmp/sysroots-components/x86_64/some/path/to/some/deeply/nested/file' 
-> 
'/build/tmp/work/x86_64-linux/some-recipe/1.0-r0/recipe-sysroot-native/some/path/to/some/deeply/nested/file'


This happens in rare case when doing a differential build o a recipe 
with hundreds or thousands of native dependencies.


The file mentioned is pretty much random and it's unique (no duplicates 
among all the dependencies when it comes to filename+path).


So far I helped myself with ignoring this error by adding

except FileExistsError:
pass

to staging - I wonder if anyone else ever seen this behavior and what's 
the best way to deal with it


What comes to my mind is

- ignoring it - but then no one can be sure it's the right file
- falling back to the OSError/EXDEV path and copying over the file requested
- a 3rd option

Any thoughts?

(Just to be sure, this happens like once in a thousand builds and only 
on differential builds)

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162624): 
https://lists.openembedded.org/g/openembedded-core/message/162624
Mute This Topic: https://lists.openembedded.org/mt/89511363/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 v3] pip_install_wheel: improve wheel handling




On 02.03.22 20:04, Khem Raj wrote:

On Wed, Mar 2, 2022 at 11:01 AM Konrad Weihmann  wrote:




On 02.03.22 19:45, Khem Raj wrote:

v4 is definitely better than v3, I see one case it could address as well e.g.

python3-pymetno produces PyMetno-0.9.0-py3-none-any.whl, so if
guessing code could address the case-sensitive piece here would be
good.


I'm torn on this one, I agree that it would really nice to have in terms
of a seamless transition, but it would require either some bash/shell
hacks to disable case sensitive filename globs or some "after compile"
renaming - I'm not sure how to tackle this.
If everyone else agrees I would vote for "after compile" renaming to a
fully lower case filename - any thoughts?



I think the suggestion that Ross has is a good one to install the wheel file
intentionally to a known location using --dist-dir and then use a more
relaxed regexp to package it.


As I mentioned in the v4 patch dist-dir doesn't work for me - somehow it 
isn't respected by most of the python modules.
So my idea would be it remain on default "dist" directory, but run 
something line rename 'y/A-Z/a-z/' ${PYPA_WHEEL} after compile - also 
minding that in PIP_INSTALL_PACKAGE.


I'm happy to see dist-dir/bdist-dir work, but so far I failed to see any 
successful run on my setup (Ubuntu 20.04 btw)






On Wed, Mar 2, 2022 at 1:21 AM Konrad Weihmann  wrote:


v4 is out.
I tried to make it work with the dist-dir/bdist-dir option, but
apparently this isn't respected by setuptools in all of the tested recipes.
That's why I went with applying cleandirs on
${SETUPTOOLS_SETUP_PATH}/dist, that should do the trick as well.

v4 is tested against all core python recipes, all the python recipes in
my layers and a reasonable subset from meta-oe

On 02.03.22 09:06, Konrad Weihmann wrote:

My bad - one of the brackets in the name guessing slipped...
Will send a v4 soon

On 02.03.22 06:20, Khem Raj wrote:

this is causing 100+ packages to fail see

https://errors.yoctoproject.org/Errors/Build/142116/

I suggest to include meta-python for wider testing of such changes.

On Tue, Mar 1, 2022 at 12:14 PM Ross Burton  wrote:


On Tue, 1 Mar 2022 at 18:48, Khem Raj  wrote:

where the wheel file is called
pytest_runner-5.3.1-py3-none-any.whl


I'm thinking we should tell pip to install the wheels to a directory
we control and then just install *.whl.

IIRC the option was --dist-dir, and we can [cleandirs] that to ensure
it's clean on builds.

Ross






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162623): 
https://lists.openembedded.org/g/openembedded-core/message/162623
Mute This Topic: https://lists.openembedded.org/mt/89472354/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] copy_buildsystem: allow more layer paths

2022-03-02 Thread Daniel Wagenknecht

Layers could be located anywhere. The eSDK should work with them even if
they are not located in TOPDIR or in the same parent directory as
COREBASE.

For layers located in the same parent directory as COREBASE this preserves
the intent from the previous
  copy_buildsystem: include layer tree during build structure creation
commit.

Related OE-Core rev: 5a59a6997f41e606d088e3e86812de56f72f543b

Signed-off-by: Daniel Wagenknecht 
---
This patch resolves issues like
  ERROR: my-image-1.0-r0 do_populate_sdk_ext: Failed to generate filtered task 
list for extensible SDK:

  ### Shell environment set up for builds. ###
  [...]

  ERROR: bitbake failed:
  ERROR: The following layer directories do not exist:
  ERROR:
/build/tmp/work/my-board-linux/my-image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/../../../repo/layers/meta-my-layer
  ERROR: Please check BBLAYERS in 
/build/tmp/work/my-board-linux/my-image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/conf/bblayers.conf
  ERROR: Logfile of failure stored in: 
/build/tmp/work/my-board-linux/my-image/1.0-r0/temp/log.do_populate_sdk_ext.68844

I tried to preserve the special casing to preserve the layer tree e.g. get the
following layer-structure in the eSDK:
  layers/poky/meta
  layers/meta-openembedded/meta-networking
  layers/meta-openembedded/meta-oe
For layers that are not located in a directory tree right next to COREBASE we
don't have an anchor to determine what part of the layer tree we should keep,
thus the layer tree will be flattened.

Alternative to this patch:
Delete the whole else / elseif block. This would lead to a layer structure in
the eSDK like
  layers/poky/meta
  layers/meta-networking
  layers/meta-oe
thus flattening the layer tree. I'm personally not opposed to this approach,
but both 5a59a6997f41e606d088e3e86812de56f72f543b and
55ecf6988d3e3c0935cb6324a6ad2c75f1191a1d (OE-Core) show that there seems to be
a need / preference for keeping the layer tree.


 meta/lib/oe/copy_buildsystem.py | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index d97bf9d1b9..79642fd76a 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -45,9 +45,6 @@ class BuildSystem(object):
 
 corebase = os.path.abspath(self.d.getVar('COREBASE'))
 layers.append(corebase)
-# Get relationship between TOPDIR and COREBASE
-# Layers should respect it
-corebase_relative = 
os.path.dirname(os.path.relpath(os.path.abspath(self.d.getVar('TOPDIR')), 
corebase))
 # The bitbake build system uses the meta-skeleton layer as a layout
 # for common recipies, e.g: the recipetool script to create kernel 
recipies
 # Add the meta-skeleton layer to be included as part of the eSDK 
installation
@@ -100,11 +97,10 @@ class BuildSystem(object):
 layerdestpath = destdir
 if corebase == os.path.dirname(layer):
 layerdestpath += '/' + os.path.basename(corebase)
-else:
-layer_relative = os.path.relpath(layer, corebase)
-if os.path.dirname(layer_relative) == corebase_relative:
-layer_relative = os.path.dirname(corebase_relative) + '/' 
+ layernewname
-layer_relative = os.path.basename(corebase) + '/' + 
layer_relative
+# If the layer is located somewhere under the same parent directory
+# as corebase we keep the layer structure.
+elif os.path.commonpath([layer, corebase]) == 
os.path.dirname(corebase):
+layer_relative = os.path.relpath(layer, 
os.path.dirname(corebase))
 if os.path.dirname(layer_relative) != layernewname:
 layerdestpath += '/' + os.path.dirname(layer_relative)
 
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162622): 
https://lists.openembedded.org/g/openembedded-core/message/162622
Mute This Topic: https://lists.openembedded.org/mt/89508969/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 v3] pip_install_wheel: improve wheel handling

2022-03-02 Thread Khem Raj

On Wed, Mar 2, 2022 at 11:01 AM Konrad Weihmann  wrote:
>
>
>
> On 02.03.22 19:45, Khem Raj wrote:
> > v4 is definitely better than v3, I see one case it could address as well 
> > e.g.
> >
> > python3-pymetno produces PyMetno-0.9.0-py3-none-any.whl, so if
> > guessing code could address the case-sensitive piece here would be
> > good.
>
> I'm torn on this one, I agree that it would really nice to have in terms
> of a seamless transition, but it would require either some bash/shell
> hacks to disable case sensitive filename globs or some "after compile"
> renaming - I'm not sure how to tackle this.
> If everyone else agrees I would vote for "after compile" renaming to a
> fully lower case filename - any thoughts?
>

I think the suggestion that Ross has is a good one to install the wheel file
intentionally to a known location using --dist-dir and then use a more
relaxed regexp to package it.

> >
> > On Wed, Mar 2, 2022 at 1:21 AM Konrad Weihmann  
> > wrote:
> >>
> >> v4 is out.
> >> I tried to make it work with the dist-dir/bdist-dir option, but
> >> apparently this isn't respected by setuptools in all of the tested recipes.
> >> That's why I went with applying cleandirs on
> >> ${SETUPTOOLS_SETUP_PATH}/dist, that should do the trick as well.
> >>
> >> v4 is tested against all core python recipes, all the python recipes in
> >> my layers and a reasonable subset from meta-oe
> >>
> >> On 02.03.22 09:06, Konrad Weihmann wrote:
> >>> My bad - one of the brackets in the name guessing slipped...
> >>> Will send a v4 soon
> >>>
> >>> On 02.03.22 06:20, Khem Raj wrote:
>  this is causing 100+ packages to fail see
> 
>  https://errors.yoctoproject.org/Errors/Build/142116/
> 
>  I suggest to include meta-python for wider testing of such changes.
> 
>  On Tue, Mar 1, 2022 at 12:14 PM Ross Burton  wrote:
> >
> > On Tue, 1 Mar 2022 at 18:48, Khem Raj  wrote:
> >> where the wheel file is called
> >> pytest_runner-5.3.1-py3-none-any.whl
> >
> > I'm thinking we should tell pip to install the wheels to a directory
> > we control and then just install *.whl.
> >
> > IIRC the option was --dist-dir, and we can [cleandirs] that to ensure
> > it's clean on builds.
> >
> > Ross
> >>>
> >>>
> >>> 
> >>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162621): 
https://lists.openembedded.org/g/openembedded-core/message/162621
Mute This Topic: https://lists.openembedded.org/mt/89472354/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 v3] pip_install_wheel: improve wheel handling




On 02.03.22 19:45, Khem Raj wrote:

v4 is definitely better than v3, I see one case it could address as well e.g.

python3-pymetno produces PyMetno-0.9.0-py3-none-any.whl, so if
guessing code could address the case-sensitive piece here would be
good.


I'm torn on this one, I agree that it would really nice to have in terms 
of a seamless transition, but it would require either some bash/shell 
hacks to disable case sensitive filename globs or some "after compile" 
renaming - I'm not sure how to tackle this.
If everyone else agrees I would vote for "after compile" renaming to a 
fully lower case filename - any thoughts?




On Wed, Mar 2, 2022 at 1:21 AM Konrad Weihmann  wrote:


v4 is out.
I tried to make it work with the dist-dir/bdist-dir option, but
apparently this isn't respected by setuptools in all of the tested recipes.
That's why I went with applying cleandirs on
${SETUPTOOLS_SETUP_PATH}/dist, that should do the trick as well.

v4 is tested against all core python recipes, all the python recipes in
my layers and a reasonable subset from meta-oe

On 02.03.22 09:06, Konrad Weihmann wrote:

My bad - one of the brackets in the name guessing slipped...
Will send a v4 soon

On 02.03.22 06:20, Khem Raj wrote:

this is causing 100+ packages to fail see

https://errors.yoctoproject.org/Errors/Build/142116/

I suggest to include meta-python for wider testing of such changes.

On Tue, Mar 1, 2022 at 12:14 PM Ross Burton  wrote:


On Tue, 1 Mar 2022 at 18:48, Khem Raj  wrote:

where the wheel file is called
pytest_runner-5.3.1-py3-none-any.whl


I'm thinking we should tell pip to install the wheels to a directory
we control and then just install *.whl.

IIRC the option was --dist-dir, and we can [cleandirs] that to ensure
it's clean on builds.

Ross






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162620): 
https://lists.openembedded.org/g/openembedded-core/message/162620
Mute This Topic: https://lists.openembedded.org/mt/89472354/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 v3] pip_install_wheel: improve wheel handling

2022-03-02 Thread Khem Raj

v4 is definitely better than v3, I see one case it could address as well e.g.

python3-pymetno produces PyMetno-0.9.0-py3-none-any.whl, so if
guessing code could address the case-sensitive piece here would be
good.

On Wed, Mar 2, 2022 at 1:21 AM Konrad Weihmann  wrote:
>
> v4 is out.
> I tried to make it work with the dist-dir/bdist-dir option, but
> apparently this isn't respected by setuptools in all of the tested recipes.
> That's why I went with applying cleandirs on
> ${SETUPTOOLS_SETUP_PATH}/dist, that should do the trick as well.
>
> v4 is tested against all core python recipes, all the python recipes in
> my layers and a reasonable subset from meta-oe
>
> On 02.03.22 09:06, Konrad Weihmann wrote:
> > My bad - one of the brackets in the name guessing slipped...
> > Will send a v4 soon
> >
> > On 02.03.22 06:20, Khem Raj wrote:
> >> this is causing 100+ packages to fail see
> >>
> >> https://errors.yoctoproject.org/Errors/Build/142116/
> >>
> >> I suggest to include meta-python for wider testing of such changes.
> >>
> >> On Tue, Mar 1, 2022 at 12:14 PM Ross Burton  wrote:
> >>>
> >>> On Tue, 1 Mar 2022 at 18:48, Khem Raj  wrote:
>  where the wheel file is called
>  pytest_runner-5.3.1-py3-none-any.whl
> >>>
> >>> I'm thinking we should tell pip to install the wheels to a directory
> >>> we control and then just install *.whl.
> >>>
> >>> IIRC the option was --dist-dir, and we can [cleandirs] that to ensure
> >>> it's clean on builds.
> >>>
> >>> Ross
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162619): 
https://lists.openembedded.org/g/openembedded-core/message/162619
Mute This Topic: https://lists.openembedded.org/mt/89472354/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] wic: Use custom kernel path if provided

2022-03-02 Thread Bill Pittman

Hey all,

Gentle ping on this patch, any comments?

Thanks,
Bill


From: Bill Pittman
Sent: Tuesday, February 15, 2022 10:54 AM
To: openembedded-core@lists.openembedded.org 

Subject: [PATCH] wic: Use custom kernel path if provided

If the custom kernel path is provided in options, then
use that path instead of the default path.



INTERNAL - NI CONFIDENTIAL

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162618): 
https://lists.openembedded.org/g/openembedded-core/message/162618
Mute This Topic: https://lists.openembedded.org/mt/89165206/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 4/4] license: Rework INCOMPATIBLE_LICENSE wildcard handling

On Wed, 2022-03-02 at 15:09 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Richard Purdie
> > Sent: den 2 mars 2022 00:42
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH 4/4] license: Rework INCOMPATIBLE_LICENSE
> > wildcard handling
> > 
> > The current wildcard handling is badly documented and inconsistently
> > used and understood.
> > 
> > Forcing users to have to use "GPL-3.0-only GPL-3.0-or-later" whilst
> > explict is not very user friendly. Equally, using the current wildcards
> > is ambigious. This supports pre-defined expansions only and at least makes
> > it clear what GPL-3.0* means (it doesn't include the exception licenses).
> > 
> > This is hopefully an acceptable compromise between literal meaning and
> > having something usable.
> > 
> > Non-SPDX forms of license in this field have been dropped and errors are
> > shown for unsupported expansions and unsupported old style license terms.
> > 
> > Users need to carefully consider how to migrate to the new syntax but
> > the meaning should be well defined and clear from here forward.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/classes/license.bbclass  | 41 +
> >  .../oeqa/selftest/cases/incompatible_lic.py   | 86 +++
> >  2 files changed, 70 insertions(+), 57 deletions(-)
> > 
> > diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> > index 68c022248c8..cb1f46983ac 100644
> > --- a/meta/classes/license.bbclass
> > +++ b/meta/classes/license.bbclass
> > @@ -277,28 +277,27 @@ AVAILABLE_LICENSES := "${@'
> > '.join(available_licenses(d))}"
> > 
> >  def expand_wildcard_licenses(d, wildcard_licenses):
> >  """
> > -Return actual spdx format license names if wildcards are used. We
> > expand
> > -wildcards from SPDXLICENSEMAP flags and AVAILABLE_LICENSES.
> > +There are some common wildcard values users may want to use. Support
> > them
> > +here.
> >  """
> > -import fnmatch
> > -
> > -licenses = wildcard_licenses[:]
> > -spdxmapkeys = d.getVarFlags('SPDXLICENSEMAP').keys()
> > -for wld_lic in wildcard_licenses:
> > -spdxflags = fnmatch.filter(spdxmapkeys, wld_lic)
> > -licenses += [d.getVarFlag('SPDXLICENSEMAP', flag) for flag in
> > spdxflags]
> > -# Assume that if we are passed "GPL-3.0" or "*GPL-3.0", then it
> > means
> > -# "-or-later" as well.
> > -if not wld_lic.endswith(("-or-later", "-only", "*", "+")):
> > -spdxflags = fnmatch.filter(spdxmapkeys, wld_lic + "+")
> > -licenses += [d.getVarFlag('SPDXLICENSEMAP', flag) for flag in
> > spdxflags]
> > -
> > -spdx_lics = d.getVar('AVAILABLE_LICENSES').split()
> > -for wld_lic in wildcard_licenses:
> > -licenses += fnmatch.filter(spdx_lics, wld_lic)
> > -
> > -licenses = list(set(licenses))
> > -return licenses
> > +licenses = set(wildcard_licenses)
> > +mapping = {
> > +"GPL-3.0*" : ["GPL-3.0-only", "GPL-3.0-or-later"],
> > +"LGPL-3.0*" : ["LGPL-3.0-only", "LGPL-3.0-or-later"],
> 
> If you are adamant about using "*" in these shortcuts (which I 
> still think is a mistake), then you should add these two as well:
> 
> "AGPL-3.0*" : ["AGPL-3.0-only", "AGPL-3.0-or-later"],
> "*GPL-3.0*" : ["GPL-3.0-only", "GPL-3.0-or-later", "LGPL-3.0-only",
> "LGPL-3.0-or-later", "AGPL-3.0-only", "AGPL-3.0-or-later"],
> 
> I believe the last one is what most really want to do, i.e., 
> exclude all GPL-3.0 variants.

I don't think I've seen anything under the AGPL. I don't have a strong
preference for adding it here or not, I was tempted to wait for patches and see
if anyone needed it.

The idea is the wildcards added should remove the need for the latter as people
can say "GPL-3.0* LGPL-3.0*" which I think is manageable.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162617): 
https://lists.openembedded.org/g/openembedded-core/message/162617
Mute This Topic: https://lists.openembedded.org/mt/89490747/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 3/4] license/insane: Show warning for obsolete license usage

2022-03-02 Thread Michael Opdenacker via lists.openembedded.org

On Wed, 2022-03-02 at 15:17 +, Peter Kjellerstedt wrote:
> > +main_lic = d.getVar('LICENSE')
> > +
> > +# Check for obsolete license references in main LICENSE (packages are 
> > checked below for any changes)
> > +main_licenses = oe.license.list_licenses(d.getVar('LICENSE'))
> 
> The documentation for oe.license.list_licenses() says that it returns 
> a list, but I assume that is not true or the code below would not work...
> 
> > +obsolete = set(oe.license.obsolete_license_list()) & main_licenses
> > +if obsolete:
> > +oe.qa.handle_error("obsolete-license", "Recipe LICENSE includes 
> > obsolete licenses %s" % ' '.join(obsolete), d)
> > +
> >  bb.build.exec_func("read_subpackage_metadata", d)
> > 
> >  # Check non UTF-8 characters on recipe's metadata

It does return a set, not a list.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162616): 
https://lists.openembedded.org/g/openembedded-core/message/162616
Mute This Topic: https://lists.openembedded.org/mt/89490745/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 3/4] license/insane: Show warning for obsolete license usage

2022-03-02 Thread Peter Kjellerstedt

> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Richard Purdie
> Sent: den 2 mars 2022 00:42
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 3/4] license/insane: Show warning for obsolete 
> license usage
> 
> We want to use SPDX identifiers in LICENSE variables. There is now a
> conversion script to make most of the translations. Add a list of
> strings which have been replaced so we can show warnings to users
> if they're still used anywhere.
> 
> Add checks to the package as insane check. This is currently a warning
> by default but can be turned off or made an error as per the other standard
> checks.
> 
> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/base.bbclass   |  6 ++
>  meta/classes/insane.bbclass | 31 ++-
>  meta/lib/oe/license.py  | 10 ++
>  3 files changed, 38 insertions(+), 9 deletions(-)
> 
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index bfc7087a189..b7869da3b38 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -597,6 +597,12 @@ python () {
> 
>  exceptions = (d.getVar("INCOMPATIBLE_LICENSE_EXCEPTIONS") or 
> "").split()
> 
> +for lic_exception in exceptions:
> +if ":" in lic_exception:
> +lic_exception.split(":")[0]
> +if lic_exception in oe.license.obsolete_license_list():
> +bb.fatal("Invalid license %s used in 
> INCOMPATIBLE_LICENSE_EXCEPTIONS" % lic_exception)
> +
>  pkgs = d.getVar('PACKAGES').split()
>  skipped_pkgs = {}
>  unskipped_pkgs = []
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 29b9b3d466a..3c8d49f13bd 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -27,7 +27,7 @@ WARN_QA ?= " libdir xorg-driver-abi \
>  mime mime-xdg unlisted-pkg-lics unhandled-features-check \
>  missing-update-alternatives native-last missing-ptest \
>  license-exists license-no-generic license-syntax license-format \
> -license-incompatible license-file-missing \
> +license-incompatible license-file-missing obsolete-license \
>  "
>  ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
>  perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
> @@ -909,14 +909,19 @@ def package_qa_check_unlisted_pkg_lics(package, d, 
> messages):
>  return True
> 
>  recipe_lics_set = oe.license.list_licenses(d.getVar('LICENSE'))
> -unlisted = oe.license.list_licenses(pkg_lics) - recipe_lics_set
> -if not unlisted:
> -return True
> -
> -oe.qa.add_message(messages, "unlisted-pkg-lics",
> -   "LICENSE:%s includes licenses (%s) that are not "
> -   "listed in LICENSE" % (package, ' 
> '.join(unlisted)))
> -return False
> +package_lics = oe.license.list_licenses(pkg_lics)
> +unlisted = package_lics - recipe_lics_set
> +if unlisted:
> +oe.qa.add_message(messages, "unlisted-pkg-lics",
> +   "LICENSE:%s includes licenses (%s) that are 
> not "
> +   "listed in LICENSE" % (package, ' 
> '.join(unlisted)))
> +return False
> +obsolete = set(oe.license.obsolete_license_list()) & package_lics - 
> recipe_lics_set
> +if obsolete:
> +oe.qa.add_message(messages, "obsolete-license",
> +   "LICENSE:%s includes obsolete licenses %s" % 
> (package, ' '.join(obsolete)))
> +return False
> +return True
> 
>  QAPKGTEST[empty-dirs] = "package_qa_check_empty_dirs"
>  def package_qa_check_empty_dirs(pkg, d, messages):
> @@ -1012,6 +1017,14 @@ python do_package_qa () {
> 
>  bb.note("DO PACKAGE QA")
> 
> +main_lic = d.getVar('LICENSE')
> +
> +# Check for obsolete license references in main LICENSE (packages are 
> checked below for any changes)
> +main_licenses = oe.license.list_licenses(d.getVar('LICENSE'))

The documentation for oe.license.list_licenses() says that it returns 
a list, but I assume that is not true or the code below would not work...

> +obsolete = set(oe.license.obsolete_license_list()) & main_licenses
> +if obsolete:
> +oe.qa.handle_error("obsolete-license", "Recipe LICENSE includes 
> obsolete licenses %s" % ' '.join(obsolete), d)
> +
>  bb.build.exec_func("read_subpackage_metadata", d)
> 
>  # Check non UTF-8 characters on recipe's metadata

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162615): 
https://lists.openembedded.org/g/openembedded-core/message/162615
Mute This Topic: https://lists.openembedded.org/mt/89490745/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe:

Re: [OE-core] [PATCH 4/4] license: Rework INCOMPATIBLE_LICENSE wildcard handling

2022-03-02 Thread Peter Kjellerstedt

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 2 mars 2022 00:42
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 4/4] license: Rework INCOMPATIBLE_LICENSE
> wildcard handling
> 
> The current wildcard handling is badly documented and inconsistently
> used and understood.
> 
> Forcing users to have to use "GPL-3.0-only GPL-3.0-or-later" whilst
> explict is not very user friendly. Equally, using the current wildcards
> is ambigious. This supports pre-defined expansions only and at least makes
> it clear what GPL-3.0* means (it doesn't include the exception licenses).
> 
> This is hopefully an acceptable compromise between literal meaning and
> having something usable.
> 
> Non-SPDX forms of license in this field have been dropped and errors are
> shown for unsupported expansions and unsupported old style license terms.
> 
> Users need to carefully consider how to migrate to the new syntax but
> the meaning should be well defined and clear from here forward.
> 
> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/license.bbclass  | 41 +
>  .../oeqa/selftest/cases/incompatible_lic.py   | 86 +++
>  2 files changed, 70 insertions(+), 57 deletions(-)
> 
> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> index 68c022248c8..cb1f46983ac 100644
> --- a/meta/classes/license.bbclass
> +++ b/meta/classes/license.bbclass
> @@ -277,28 +277,27 @@ AVAILABLE_LICENSES := "${@' 
> '.join(available_licenses(d))}"
> 
>  def expand_wildcard_licenses(d, wildcard_licenses):
>  """
> -Return actual spdx format license names if wildcards are used. We expand
> -wildcards from SPDXLICENSEMAP flags and AVAILABLE_LICENSES.
> +There are some common wildcard values users may want to use. Support them
> +here.
>  """
> -import fnmatch
> -
> -licenses = wildcard_licenses[:]
> -spdxmapkeys = d.getVarFlags('SPDXLICENSEMAP').keys()
> -for wld_lic in wildcard_licenses:
> -spdxflags = fnmatch.filter(spdxmapkeys, wld_lic)
> -licenses += [d.getVarFlag('SPDXLICENSEMAP', flag) for flag in 
> spdxflags]
> -# Assume that if we are passed "GPL-3.0" or "*GPL-3.0", then it means
> -# "-or-later" as well.
> -if not wld_lic.endswith(("-or-later", "-only", "*", "+")):
> -spdxflags = fnmatch.filter(spdxmapkeys, wld_lic + "+")
> -licenses += [d.getVarFlag('SPDXLICENSEMAP', flag) for flag in 
> spdxflags]
> -
> -spdx_lics = d.getVar('AVAILABLE_LICENSES').split()
> -for wld_lic in wildcard_licenses:
> -licenses += fnmatch.filter(spdx_lics, wld_lic)
> -
> -licenses = list(set(licenses))
> -return licenses
> +licenses = set(wildcard_licenses)
> +mapping = {
> +"GPL-3.0*" : ["GPL-3.0-only", "GPL-3.0-or-later"],
> +"LGPL-3.0*" : ["LGPL-3.0-only", "LGPL-3.0-or-later"],

If you are adamant about using "*" in these shortcuts (which I 
still think is a mistake), then you should add these two as well:

"AGPL-3.0*" : ["AGPL-3.0-only", "AGPL-3.0-or-later"],
"*GPL-3.0*" : ["GPL-3.0-only", "GPL-3.0-or-later", "LGPL-3.0-only", 
"LGPL-3.0-or-later", "AGPL-3.0-only", "AGPL-3.0-or-later"],

I believe the last one is what most really want to do, i.e., 
exclude all GPL-3.0 variants.

//Peter

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162614): 
https://lists.openembedded.org/g/openembedded-core/message/162614
Mute This Topic: https://lists.openembedded.org/mt/89490747/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 1/2] classes: rootfs-postcommands: include /etc/fstab in overlayfs_qa_check

2022-03-02 Thread Stefan Herbrechtsmeier

From: Stefan Herbrechtsmeier 

The systemd init manager support mount point configuration via mount
units and /etc/fstab. 'Mounts listed in /etc/fstab will be converted
into native units dynamically at boot and when the configuration of
the system manager is reloaded. In general, configuring mount points
through /etc/fstab is the preferred approach.' [1]

Read mount points from /etc/fstab to determine dynamic mount units.

[1] https://www.freedesktop.org/software/systemd/man/systemd.mount.html

Signed-off-by: Stefan Herbrechtsmeier 

---

 meta/classes/rootfs-postcommands.bbclass  | 38 +--
 meta/lib/oeqa/selftest/cases/overlayfs.py |  4 +--
 2 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index cd8986d8a9..e1276a220a 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -376,25 +376,45 @@ rootfs_reproducible () {
fi
 }
 
+# Perform a dumb check for unit existence, not its validity
 python overlayfs_qa_check() {
 from oe.overlayfs import mountUnitName
 
-# this is a dumb check for unit existence, not its validity
 overlayMountPoints = d.getVarFlags("OVERLAYFS_MOUNT_POINT") or {}
 imagepath = d.getVar("IMAGE_ROOTFS")
-searchpaths = [oe.path.join(imagepath, d.getVar("sysconfdir"), "systemd", 
"system"),
+sysconfdir = d.getVar("sysconfdir")
+searchpaths = [oe.path.join(imagepath, sysconfdir, "systemd", "system"),
oe.path.join(imagepath, d.getVar("systemd_system_unitdir"))]
+fstabpath = oe.path.join(imagepath, sysconfdir, "fstab")
+
+if not any(os.path.exists(path) for path in [*searchpaths, fstabpath]):
+return
+
+fstabDevices = []
+if os.path.isfile(fstabpath):
+with open(fstabpath, 'r') as f:
+for line in f:
+if line[0] == '#':
+continue
+path = line.split(maxsplit=2)
+if len(path) > 2:
+fstabDevices.append(path[1])
 
 allUnitExist = True;
 for mountPoint in overlayMountPoints:
-path = d.getVarFlag('OVERLAYFS_MOUNT_POINT', mountPoint)
-unit = mountUnitName(path)
+mountPath = d.getVarFlag('OVERLAYFS_MOUNT_POINT', mountPoint)
+if mountPath in fstabDevices:
+continue
+
+mountUnit = mountUnitName(mountPath)
+if any(os.path.isfile(oe.path.join(dirpath, mountUnit))
+   for dirpath in searchpaths):
+continue
 
-if not any(os.path.isfile(oe.path.join(dirpath, unit))
-   for dirpath in searchpaths):
-bb.warn('Unit name %s not found in systemd unit directories' % 
unit)
-allUnitExist = False;
+bb.warn('Mount path %s not found in fstat and unit %s not found '
+'in systemd unit directories' % (mountPath, mountUnit))
+allUnitExist = False;
 
 if not allUnitExist:
-bb.fatal('Not all mount units are installed by the BSP')
+bb.fatal('Not all mount paths and units are installed in the image')
 }
diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py 
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index 82007fade7..79d36fa93c 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -61,9 +61,9 @@ DISTRO_FEATURES += "systemd overlayfs"
 self.add_overlay_conf_to_machine()
 
 res = bitbake('core-image-minimal', ignore_status=True)
-line = getline(res, "Unit name mnt-overlay.mount not found in systemd 
unit directories")
+line = getline(res, " Mount path /mnt/overlay not found in fstat and 
unit mnt-overlay.mount not found in systemd unit directories")
 self.assertTrue(line and line.startswith("WARNING:"), msg=res.output)
-line = getline(res, "Not all mount units are installed by the BSP")
+line = getline(res, "Not all mount paths and units are installed in 
the image")
 self.assertTrue(line and line.startswith("ERROR:"), msg=res.output)
 
 def test_mount_unit_not_set(self):
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162612): 
https://lists.openembedded.org/g/openembedded-core/message/162612
Mute This Topic: https://lists.openembedded.org/mt/89502037/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 2/2] oeqa: selftest: overlayfs: add test for image with fstab entry

2022-03-02 Thread Stefan Herbrechtsmeier

From: Stefan Herbrechtsmeier 

Signed-off-by: Stefan Herbrechtsmeier 
---

 .../base-files/base-files_%.bbappend  |  2 +
 meta/lib/oeqa/selftest/cases/overlayfs.py | 82 +--
 2 files changed, 57 insertions(+), 27 deletions(-)
 create mode 100644 meta-selftest/recipes-test/base-files/base-files_%.bbappend

diff --git a/meta-selftest/recipes-test/base-files/base-files_%.bbappend 
b/meta-selftest/recipes-test/base-files/base-files_%.bbappend
new file mode 100644
index 00..205720982c
--- /dev/null
+++ b/meta-selftest/recipes-test/base-files/base-files_%.bbappend
@@ -0,0 +1,2 @@
+# This bbappend is used to alter the recipe using the test_recipe.inc file 
created by tests.
+include test_recipe.inc
diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py 
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index 79d36fa93c..56ae48ce64 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -107,7 +107,7 @@ OVERLAYFS_MOUNT_POINT[usr-share-overlay] = 
"/usr/share/overlay"
 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):
+def _test_correct_image(self, recipe, data):
 """
 Summary:   Check that we can create an image when all parameters are
set correctly
@@ -124,31 +124,6 @@ VIRTUAL-RUNTIME_init_manager = "systemd"
 
 # enable overlayfs in the kernel
 KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
-"""
-
-systemd_machine_unit_append = """
-SYSTEMD_SERVICE:${PN} += " \
-mnt-overlay.mount \
-"
-
-do_install:append() {
-install -d ${D}${systemd_system_unitdir}
-cat < ${D}${systemd_system_unitdir}/mnt-overlay.mount
-[Unit]
-Description=Tmpfs directory
-DefaultDependencies=no
-
-[Mount]
-What=tmpfs
-Where=/mnt/overlay
-Type=tmpfs
-Options=mode=1777,strictatime,nosuid,nodev
-
-[Install]
-WantedBy=multi-user.target
-EOT
-}
-
 """
 
 overlayfs_recipe_append = """
@@ -179,7 +154,7 @@ EOT
 
 self.write_config(config)
 self.add_overlay_conf_to_machine()
-self.write_recipeinc('systemd-machine-units', 
systemd_machine_unit_append)
+self.write_recipeinc(recipe, data)
 self.write_recipeinc('overlayfs-user', overlayfs_recipe_append)
 
 bitbake('core-image-minimal')
@@ -210,6 +185,59 @@ EOT
 line = getline_qemu(output, 
"upperdir=/mnt/overlay/upper/usr/share/another-overlay-mount")
 self.assertTrue(line and line.startswith("overlay"), msg=output)
 
+def test_correct_image_fstab(self):
+"""
+Summary:   Check that we can create an image when all parameters are
+   set correctly via fstab
+Expected:  Image is created successfully
+Author:Stefan Herbrechtsmeier 

+"""
+
+base_files_append = """
+do_install:append() {
+cat <> ${D}${sysconfdir}/fstab
+tmpfs/mnt/overlay tmpfs  
mode=1777,strictatime,nosuid,nodev  0  0
+EOT
+}
+"""
+
+self._test_correct_image('base-files', base_files_append)
+
+def test_correct_image_unit(self):
+"""
+Summary:   Check that we can create an image when all parameters are
+   set correctly via mount unit
+Expected:  Image is created successfully
+Author:Vyacheslav Yurkov 
+"""
+
+systemd_machine_unit_append = """
+SYSTEMD_SERVICE:${PN} += " \
+mnt-overlay.mount \
+"
+
+do_install:append() {
+install -d ${D}${systemd_system_unitdir}
+cat < ${D}${systemd_system_unitdir}/mnt-overlay.mount
+[Unit]
+Description=Tmpfs directory
+DefaultDependencies=no
+
+[Mount]
+What=tmpfs
+Where=/mnt/overlay
+Type=tmpfs
+Options=mode=1777,strictatime,nosuid,nodev
+
+[Install]
+WantedBy=multi-user.target
+EOT
+}
+
+"""
+
+self._test_correct_image('systemd-machine-units', 
systemd_machine_unit_append)
+
 class OverlayFSEtcRunTimeTests(OESelftestTestCase):
 """overlayfs-etc class tests"""
 
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162613): 
https://lists.openembedded.org/g/openembedded-core/message/162613
Mute This Topic: https://lists.openembedded.org/mt/89502039/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] libacpi: Build libacpi also for 'aarch64' machines

2022-03-02 Thread Kamil Dziezyk

Signed-off-by: Kamil Dziezyk 
---
 meta/recipes-bsp/libacpi/libacpi_0.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/libacpi/libacpi_0.2.bb 
b/meta/recipes-bsp/libacpi/libacpi_0.2.bb
index fa9e3d4894..6d4be76bab 100644
--- a/meta/recipes-bsp/libacpi/libacpi_0.2.bb
+++ b/meta/recipes-bsp/libacpi/libacpi_0.2.bb
@@ -22,7 +22,7 @@ UPSTREAM_CHECK_URI = "http://www.ngolde.de/libacpi.html;
 
 inherit lib_package
 
-COMPATIBLE_HOST = '(x86_64|i.86).*-(linux|freebsd.*)'
+COMPATIBLE_HOST = '(x86_64|i.86|aarch64).*-(linux|freebsd.*)'
 
 CFLAGS += "-fPIC"
 EXTRA_OEMAKE = '-e MAKEFLAGS= STRIP="echo"'
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162611): 
https://lists.openembedded.org/g/openembedded-core/message/162611
Mute This Topic: https://lists.openembedded.org/mt/89501736/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] Yocto Project Status WW09`22

Hi Stephen

On 3/1/22 16:52, Stephen Jolley wrote:
>
> Current Dev Position: YP 3.5 M4
>
> Next Deadline: 4th April. 2022 YP 3.5 M4 build
>
>  
>
> Next Team Meetings:
>
>   * Bug Triage meeting Thursday Mar. 3rd 7:30 am PDT
> (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09
> )
>   * Monthly Project Meeting Tuesday Mar. 1st at 8 am PDT
> (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
> )
> 
>   * Weekly Engineering Sync Tuesday Mar. 8th  at 8 am PDT
> (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
> )
> 
>   * Twitch -  See https://www.twitch.tv/theyoctojester
>
>  
>
> Key Status/Updates:
>
>   * We are now at feature freeze for 3.5, our next LTS release
>   * YP 3.3.5 is out of QA and pending release approval
>   * Inclusive language changes have merged however there are still:
>   o Incompatible license related variable changes
>   o Function variable name changes needed
>   o No migration documentation or documentation of the changes
>   o No documentation of the bitbake rename code
>   o No updates to the manual for the variable renames
>
> We do need people to pull things together and finish things off, help
> in doing that is needed and much appreciated.
>
>   * There is a pending patch to warn about old style license
> identifiers pending in master-next and due to be posted for
> review. On balance this is probably a good thing to get into the
> LTS but we’re open to input on that.
>   * The incompatible license changes will mean anyone using those
> variables will need to update what they’re doing carefully.
> Patches in master-next now pass testing and are due to be posted
> on the mailing list.
>   * The python build process change to use wheels has merged. That
> change has caused some disruption but was close enough to being
> ready it seemed worth making the final push for inclusion.
>   * The infrastructure move was successful and all services should be
> restored. There are some networking issues occurring on
> autobuilder builds which are preventing release builds at this
> time and are being looked into.
>   * As such, the M3 release build will likely happen late this week or
> early next week.
>   * If people see intermittent issues in their own builds,
> particularly if they’re the same as intermittent issues seen on
> the autobuilder, please do comment in the bugs mentioning when
> they happen as the frequency information does help us prioritize
> fixing the most common issues.
>   * Intermittent issues continue to be at record high levels and help
> is very much welcome in trying to resolve them. 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
> 
>
>  
>
> Ways to contribute:
>
>   * 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 3.5. See:
> 
> https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.5_Unassigned_Enhancements.2FBugs
> 
> 
>   * 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 us resolve CVE issues: CVE metrics
> 
> 
>  
>
>  
>
> YP 3.5 Milestone Dates:
>
>   * YP 3.5 M3 build date 2022/02/21
>   * YP 3.5 M3 Release date 2022/03/04
>   * YP 3.5 M4 build date 2022/04/04
>   * YP 3.5 M4 Release date 2022/04/29
>
>  
>
> Upcoming dot releases:
>
>   * YP 3.3.5  is out of QA
>   * YP 3.3.5 Release date 2022/02/25
>   * YP 3.1.15 build date 2022/03/14
>   * YP 3.1.15 Release date 2022/03/25
>   * YP 3.4.3 build date 2022/03/21
>   * YP 3.4.3 Release date 2022/04/01
>   * YP 3.3.6 build date 2022/03/28
>   * YP 3.3.6 Release date 2022/04/08
>   * YP 3.1.16 build date 2022/04/25
>   * YP

[OE-core] [PATCH 2/2] ipk: Decode byte data to string in manifest handling

2022-03-02 Thread Andrew Jeffery

```
File: 
'/home/andrew/src/openbmc/openbmc/meta/lib/oe/package_manager/ipk/manifest.py', 
lineno: 69, function: create_full
 0065:output = pm.dummy_install(pkgs_to_install)
 0066:
 0067:with open(self.full_manifest, 'w+') as manifest:
 0068:pkg_re = re.compile('^Installing ([^ ]+) [^ ].*')
 *** 0069:for line in set(output.split('\n')):
 0070:m = pkg_re.match(line)
 0071:if m:
 0072:manifest.write(m.group(1) + '\n')
 0073:
Exception: TypeError: a bytes-like object is required, not 'str'
```

Change-Id: Ifefb13bfa22c766d20ab9f73f7abe5163b3df86f
Signed-off-by: Andrew Jeffery 
---
 meta/lib/oe/package_manager/ipk/manifest.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager/ipk/manifest.py 
b/meta/lib/oe/package_manager/ipk/manifest.py
index 22669f97c082..ae451c5c70d3 100644
--- a/meta/lib/oe/package_manager/ipk/manifest.py
+++ b/meta/lib/oe/package_manager/ipk/manifest.py
@@ -62,7 +62,7 @@ class PkgManifest(Manifest):
 if len(pkgs_to_install) == 0:
 return
 
-output = pm.dummy_install(pkgs_to_install)
+output = pm.dummy_install(pkgs_to_install).decode('utf-8')
 
 with open(self.full_manifest, 'w+') as manifest:
 pkg_re = re.compile('^Installing ([^ ]+) [^ ].*')
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162609): 
https://lists.openembedded.org/g/openembedded-core/message/162609
Mute This Topic: https://lists.openembedded.org/mt/89500662/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] ipk: Import re in manifest module

2022-03-02 Thread Andrew Jeffery

```
File: 
'/home/andrew/src/openbmc/openbmc/meta/lib/oe/package_manager/ipk/manifest.py', 
lineno: 67, function: create_full
 0063:
 0064:output = pm.dummy_install(pkgs_to_install)
 0065:
 0066:with open(self.full_manifest, 'w+') as manifest:
 *** 0067:pkg_re = re.compile('^Installing ([^ ]+) [^ ].*')
 0068:for line in set(output.split('\n')):
 0069:m = pkg_re.match(line)
 0070:if m:
 0071:manifest.write(m.group(1) + '\n')
Exception: NameError: name 're' is not defined
```

Change-Id: I769a2ab5e57c7b60598ea0390b576d707356db9d
Signed-off-by: Andrew Jeffery 
---
 meta/lib/oe/package_manager/ipk/manifest.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oe/package_manager/ipk/manifest.py 
b/meta/lib/oe/package_manager/ipk/manifest.py
index ee4b57bcb0f5..22669f97c082 100644
--- a/meta/lib/oe/package_manager/ipk/manifest.py
+++ b/meta/lib/oe/package_manager/ipk/manifest.py
@@ -3,6 +3,7 @@
 #
 
 from oe.manifest import Manifest
+import re
 
 class PkgManifest(Manifest):
 """
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162608): 
https://lists.openembedded.org/g/openembedded-core/message/162608
Mute This Topic: https://lists.openembedded.org/mt/89500661/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] recipetool/devtool: Further SPDX identifier cleanups

Some of these are hard to know what to do with since the original source
files for the checksum aren't present. The safe option is to use "-only"
as often the main license is ambiguous and the source files themselves
determine the "or-later" possibility. The "-only" option therefore is
realistically what we need to use in this code.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/oelib/license.py | 22 +++---
 meta/lib/oeqa/selftest/cases/recipetool.py|  8 +--
 scripts/lib/recipetool/create.py  | 10 +--
 scripts/lib/recipetool/licenses.csv   | 72 +--
 4 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/oelib/license.py 
b/meta/lib/oeqa/selftest/cases/oelib/license.py
index 6ebbee589fb..3b359396b67 100644
--- a/meta/lib/oeqa/selftest/cases/oelib/license.py
+++ b/meta/lib/oeqa/selftest/cases/oelib/license.py
@@ -15,11 +15,11 @@ class SeenVisitor(oe.license.LicenseVisitor):
 
 class TestSingleLicense(TestCase):
 licenses = [
-"GPLv2",
-"LGPL-2.0",
-"Artistic",
+"GPL-2.0-only",
+"LGPL-2.0-only",
+"Artistic-1.0",
 "MIT",
-"GPLv3+",
+"GPL-3.0-or-later",
 "FOO_BAR",
 ]
 invalid_licenses = ["GPL/BSD"]
@@ -67,9 +67,9 @@ class TestComplexCombinations(TestSimpleCombinations):
 "FOO & (BAR | BAZ)": ["FOO", "BAR", "MOO"],
 "(ALPHA|(BETA)|OMEGA)": ["OMEGA", "DELTA"],
 "((ALPHA|BETA))|BAZ": ["BETA", "FOO"],
-"(GPL-2.0|Proprietary)": ["GPL-2.0", "BSD-4-clause", 
"MIT"],
+"(GPL-2.0-only|Proprietary)": ["GPL-2.0-only", 
"BSD-4-clause", "MIT"],
 }
-preferred = ["BAR", "OMEGA", "BETA", "GPL-2.0"]
+preferred = ["BAR", "OMEGA", "BETA", "GPL-2.0-only"]
 
 class TestIsIncluded(TestCase):
 tests = {
@@ -87,12 +87,12 @@ class TestIsIncluded(TestCase):
 [True, ["BAR", "FOOBAR"]],
 ("(FOO | BAR) & FOOBAR | BAZ & MOO & BARFOO", None, "FOO"):
 [True, ["BAZ", "MOO", "BARFOO"]],
-("GPL-3.0 & GPL-2.0 & LGPL-2.1 | Proprietary", None, None):
-[True, ["GPL-3.0", "GPL-2.0", "LGPL-2.1"]],
-("GPL-3.0 & GPL-2.0 & LGPL-2.1 | Proprietary", None, "GPL-3.0"):
+("GPL-3.0-or-later & GPL-2.0-only & LGPL-2.1-only | Proprietary", 
None, None):
+[True, ["GPL-3.0-or-later", "GPL-2.0-only", "LGPL-2.1-only"]],
+("GPL-3.0-or-later & GPL-2.0-only & LGPL-2.1-only | Proprietary", 
None, "GPL-3.0-or-later"):
 [True, ["Proprietary"]],
-("GPL-3.0 & GPL-2.0 & LGPL-2.1 | Proprietary", None, "GPL-3.0 
Proprietary"):
-[False, ["GPL-3.0"]]
+("GPL-3.0-or-later & GPL-2.0-only & LGPL-2.1-only | Proprietary", 
None, "GPL-3.0-or-later Proprietary"):
+[False, ["GPL-3.0-or-later"]]
 }
 
 def test_tests(self):
diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index ca3cf8942d9..510dae6badf 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -343,7 +343,7 @@ class RecipetoolCreateTests(RecipetoolBase):
 result = runCmd('recipetool create -o %s %s -x %s' % (recipefile, 
srcuri, tempsrc))
 self.assertTrue(os.path.isfile(recipefile))
 checkvars = {}
-checkvars['LICENSE'] = 'GPL-2.0'
+checkvars['LICENSE'] = 'GPL-2.0-only'
 checkvars['LIC_FILES_CHKSUM'] = 
'file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263'
 checkvars['SRC_URI'] = 
'https://github.com/logrotate/logrotate/releases/download/${PV}/logrotate-${PV}.tar.xz'
 checkvars['SRC_URI[md5sum]'] = 'a560c57fac87c45b2fc17406cdf79288'
@@ -363,7 +363,7 @@ class RecipetoolCreateTests(RecipetoolBase):
 result = runCmd(['recipetool', 'create', '-o', recipefile, srcuri + 
";rev=9f7cf8895ae2d39c465c04cc78e918c157420269", '-x', tempsrc])
 self.assertTrue(os.path.isfile(recipefile), 'recipetool did not create 
recipe file; output:\n%s' % result.output)
 checkvars = {}
-checkvars['LICENSE'] = 'LGPL-2.1'
+checkvars['LICENSE'] = 'LGPL-2.1-only'
 checkvars['LIC_FILES_CHKSUM'] = 
'file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34'
 checkvars['S'] = '${WORKDIR}/git'
 checkvars['PV'] = '1.11+git${SRCPV}'
@@ -386,7 +386,7 @@ class RecipetoolCreateTests(RecipetoolBase):
 self.fail('recipetool did not create recipe file; 
output:\n%s\ndirlist:\n%s' % (result.output, str(dirlist)))
 self.assertEqual(dirlist[0], 'socat_%s.bb' % pv, 'Recipe file 
incorrectly named')
 checkvars = {}
-checkvars['LICENSE'] = set(['Unknown', 'GPL-2.0'])
+checkvars['LICENSE'] = set(['Unknown', 'GPL-2.0-only'])
 checkvars['LIC_FILES_CHKSUM'] = 
set(['file://COPYING.OpenSSL;md5=5c9bccc77f67a8328ef4ebaf468116f4', 
'file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263'])
 # We don't check DEPENDS

Re: [OE-core][PATCH] multilib_global.bbclass: fix setting preferred version for canadian recipes

Also, Ross, use HOST_PREFIX please (insert grumpy face  >:-|   ).

Alex

On Wed, 2 Mar 2022 at 12:18, Richard Purdie
 wrote:
>
> On Wed, 2022-03-02 at 09:59 +0800, ChenQi wrote:
> > On 3/2/22 08:20, Richard Purdie wrote:
> > > On Tue, 2022-03-01 at 16:12 +0800, Chen Qi wrote:
> > > > Currently the TRANSLATED_TARGET_ARCH is not changed when trying
> > > > to set preferred version for canadian recipes.
> > > >
> > > > e.g.
> > > > ```
> > > > bitbake core-image-minimal -c populate_sdk -e > env
> > > > grep ^PREFERRED_VERSION_gcc-cross-canadian env
> > > > ```
> > > > The result is:
> > > > """
> > > > PREFERRED_VERSION_gcc-cross-canadian-x86-64="11.%"
> > > > """
> > > >
> > > > We need to explictly change DEFAULTTUNE to ensure 
> > > > TRANSLATED_TARGET_ARCH is
> > > > changed when trying to set the preferred version for multilib version of
> > > > the canadian recipes.
> > > >
> > > > e.g.
> > > > ```
> > > > bitbake core-image-minimal -c populate_sdk -e > env
> > > > grep ^PREFERRED_VERSION_gcc-cross-canadian env
> > > > ```
> > > > The result is:
> > > > """
> > > > PREFERRED_VERSION_gcc-cross-canadian-i686="11.%"
> > > > PREFERRED_VERSION_gcc-cross-canadian-x86-64="11.%"
> > > > """
> > > >
> > > > Signed-off-by: Chen Qi 
> > > > ---
> > > >   meta/classes/multilib_global.bbclass | 3 +++
> > > >   1 file changed, 3 insertions(+)
> > > This seems to break multilib builds:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/4844
> > >
> > > Cheers,
> > >
> > > Richard
> > >
> > Hi Richard and Ross,
> >
> > I looked at the above failure. It's not caused by this patch. It's
> > caused by the one below.
> >
> >package: do_package should depend on binutils
> >
> > I could reproduce this problem by cherry-picking this commit to latest
> > master branch. See detailed console output below.
>
> Sorry, it does look like it is Ross' change and not yours!
>
> Ross: I think yours may also be causing the sstate sigs issue in:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3233/steps/14/logs/stdio
>
> Cheers,
>
> Richard
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162606): 
https://lists.openembedded.org/g/openembedded-core/message/162606
Mute This Topic: https://lists.openembedded.org/mt/89471636/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/2] sstate: do not add TARGET_ARCH to pkgarch for cross recipes.

On Wed, 2022-03-02 at 09:49 +0100, Alexander Kanavin wrote:
> I just ran this locally, and it passed - probably caused by a different 
> commit?

I suspect Ross has a change which may be to blame...

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162605): 
https://lists.openembedded.org/g/openembedded-core/message/162605
Mute This Topic: https://lists.openembedded.org/mt/89396615/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] multilib_global.bbclass: fix setting preferred version for canadian recipes

On Wed, 2022-03-02 at 09:59 +0800, ChenQi wrote:
> On 3/2/22 08:20, Richard Purdie wrote:
> > On Tue, 2022-03-01 at 16:12 +0800, Chen Qi wrote:
> > > Currently the TRANSLATED_TARGET_ARCH is not changed when trying
> > > to set preferred version for canadian recipes.
> > > 
> > > e.g.
> > > ```
> > > bitbake core-image-minimal -c populate_sdk -e > env
> > > grep ^PREFERRED_VERSION_gcc-cross-canadian env
> > > ```
> > > The result is:
> > > """
> > > PREFERRED_VERSION_gcc-cross-canadian-x86-64="11.%"
> > > """
> > > 
> > > We need to explictly change DEFAULTTUNE to ensure TRANSLATED_TARGET_ARCH 
> > > is
> > > changed when trying to set the preferred version for multilib version of
> > > the canadian recipes.
> > > 
> > > e.g.
> > > ```
> > > bitbake core-image-minimal -c populate_sdk -e > env
> > > grep ^PREFERRED_VERSION_gcc-cross-canadian env
> > > ```
> > > The result is:
> > > """
> > > PREFERRED_VERSION_gcc-cross-canadian-i686="11.%"
> > > PREFERRED_VERSION_gcc-cross-canadian-x86-64="11.%"
> > > """
> > > 
> > > Signed-off-by: Chen Qi 
> > > ---
> > >   meta/classes/multilib_global.bbclass | 3 +++
> > >   1 file changed, 3 insertions(+)
> > This seems to break multilib builds:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/4844
> > 
> > Cheers,
> > 
> > Richard
> > 
> Hi Richard and Ross,
> 
> I looked at the above failure. It's not caused by this patch. It's 
> caused by the one below.
> 
>    package: do_package should depend on binutils
> 
> I could reproduce this problem by cherry-picking this commit to latest 
> master branch. See detailed console output below.

Sorry, it does look like it is Ross' change and not yours!

Ross: I think yours may also be causing the sstate sigs issue in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3233/steps/14/logs/stdio

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162604): 
https://lists.openembedded.org/g/openembedded-core/message/162604
Mute This Topic: https://lists.openembedded.org/mt/89471636/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] package: do_package should depend on binutils

2022-03-02 Thread Lee Chee Yang

Looks like this is causing problem with multilib 
https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/4844
https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/4844/steps/11/logs/errors


> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Ross Burton
> Sent: Tuesday, 1 March, 2022 11:26 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] package: do_package should depend on binutils
> 
> splitdebuginfo() in do_package uses objcopy, but there is no dependency.
> It usually gets pulled in via the toolchain but if INHIBIT_DEFAULT_DEPS="1"
> there is no dependency on a toolchain, so make it explicit.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/package.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index f822258150..4b72bf2039 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -53,6 +53,8 @@ ALL_MULTILIB_PACKAGE_ARCHS =
> "${@all_multilib_tune_values(d, 'PACKAGE_ARCHS')}"
>  # rpm is used for the per-file dependency identification  # dwarfsrcfiles is
> used to determine the list of debug source files  PACKAGE_DEPENDS +=
> "rpm-native dwarfsrcfiles-native"
> +PACKAGE_DEPENDS:append:class-target = "
> virtual/${TARGET_PREFIX}binutils"
> +PACKAGE_DEPENDS:append:class-nativesdk = "
> virtual/${SDK_PREFIX}binutils-crosssdk"
> 
> 
>  # If your postinstall can execute at rootfs creation time rather than on
> --
> 2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162603): 
https://lists.openembedded.org/g/openembedded-core/message/162603
Mute This Topic: https://lists.openembedded.org/mt/89478699/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 2/3] perl: Makefile.PL: Fix _PATH_LOG for deterministic build

2022-03-02 Thread Robert Yang




On 3/2/22 4:48 PM, Alexander Kanavin wrote:

Yes, but you do not need to submit the patch for inclusion, only to
file a ticket, and ask upstream what can be done about the issue.


Thanks, submitted a ticket to upstream and add the url in the patch:

Submitted a ticket to upstream: 
https://rt.cpan.org/Ticket/Display.html?id=141612

Upstream-Status: Inappropriate [OE specific]

Signed-off-by: Robert Yang 


And updated the patch in the PULL:


  git://git.openembedded.org/openembedded-core-contrib rbt/deterministic
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/deterministic

// Robert




Alex

On Wed, 2 Mar 2022 at 09:47, Robert Yang  wrote:


Hi

On 3/2/22 4:42 PM, Alexander Kanavin wrote:

Can you file a ticket upstream for this please, and include the link
in the patch?



This patch won't work for upstream, only work by cross building, let me check on
how to make it work for all cases.

// Robert



Alex

On Wed, 2 Mar 2022 at 08:13, Robert Yang  wrote:


It checks host's path such as /dev/log and uses it, this doesn't make sense for
cross build, and it causes undeterministic, for example, the contianer os
usually doesn't have /dev/log which leads to a different build result since
other host usually has /dev/log, so make it always use the default value to fix
the issue.

Signed-off-by: Robert Yang 
---
   ...Makefile.PL-Fix-_PATH_LOG-for-determ.patch | 34 +++
   meta/recipes-devtools/perl/perl_5.34.0.bb |  1 +
   2 files changed, 35 insertions(+)
   create mode 100644 
meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch

diff --git 
a/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
 
b/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
new file mode 100644
index 000..f6bcbce6856
--- /dev/null
+++ 
b/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
@@ -0,0 +1,34 @@
+From a73fff1fcf0def4ce93964f1b63fe3ad0967259d Mon Sep 17 00:00:00 2001
+From: Robert Yang 
+Date: Fri, 18 Feb 2022 09:44:26 +
+Subject: [PATCH] cpan/Sys-Syslog/Makefile.PL: Fix _PATH_LOG for deterministic
+
+It checks host's path such as /dev/log and uses it, this doesn't make sense for
+cross build, and it causes undeterministic, for example, the contianer os
+usually doesn't have /dev/log which leads to a different build result since
+other host usually has /dev/log, so make it always use the default value to fix
+the issue.
+
+Upstream-Status:Inappropriate [OE specific]
+
+Signed-off-by: Robert Yang 
+---
+ cpan/Sys-Syslog/Makefile.PL | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/cpan/Sys-Syslog/Makefile.PL b/cpan/Sys-Syslog/Makefile.PL
+index d09ba69..d44e58c 100644
+--- a/cpan/Sys-Syslog/Makefile.PL
 b/cpan/Sys-Syslog/Makefile.PL
+@@ -130,6 +130,8 @@ else {
+ $_PATH_LOG = "";
+ }
+
++# OE specific
++$_PATH_LOG = "";
+
+ # if possible, generate the code that handles the constants with
+ # ExtUtils::Constant, otherwise use cached copy in fallback/
+--
+2.31.1
+
diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb 
b/meta/recipes-devtools/perl/perl_5.34.0.bb
index a97da872032..8a1db7ed359 100644
--- a/meta/recipes-devtools/perl/perl_5.34.0.bb
+++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
@@ -20,6 +20,7 @@ SRC_URI = 
"https://www.cpan.org/src/5.0/perl-${PV}.tar.gz;name=perl \
  file://aacd2398e766500cb5d83c4d76b642fcf31d997a.patch \
  file://ea57297a58b8f10ab885c19eec48ea076116cc1f.patch \
  file://5bc1e5fdd87aa205011512cd1e6cc655bcf677fd.patch \
+   
file://0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch \
  "
   SRC_URI:append:class-native = " \
  file://perl-configpm-switch.patch \
--
2.31.1





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162602): 
https://lists.openembedded.org/g/openembedded-core/message/162602
Mute This Topic: https://lists.openembedded.org/mt/89496472/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 v3] pip_install_wheel: improve wheel handling


v4 is out.
I tried to make it work with the dist-dir/bdist-dir option, but 
apparently this isn't respected by setuptools in all of the tested recipes.
That's why I went with applying cleandirs on 
${SETUPTOOLS_SETUP_PATH}/dist, that should do the trick as well.


v4 is tested against all core python recipes, all the python recipes in 
my layers and a reasonable subset from meta-oe


On 02.03.22 09:06, Konrad Weihmann wrote:

My bad - one of the brackets in the name guessing slipped...
Will send a v4 soon

On 02.03.22 06:20, Khem Raj wrote:

this is causing 100+ packages to fail see

https://errors.yoctoproject.org/Errors/Build/142116/

I suggest to include meta-python for wider testing of such changes.

On Tue, Mar 1, 2022 at 12:14 PM Ross Burton  wrote:


On Tue, 1 Mar 2022 at 18:48, Khem Raj  wrote:

where the wheel file is called
pytest_runner-5.3.1-py3-none-any.whl


I'm thinking we should tell pip to install the wheels to a directory
we control and then just install *.whl.

IIRC the option was --dist-dir, and we can [cleandirs] that to ensure
it's clean on builds.

Ross






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162601): 
https://lists.openembedded.org/g/openembedded-core/message/162601
Mute This Topic: https://lists.openembedded.org/mt/89472354/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 v4] pip_install_wheel: improve wheel handling

- replace python3 prefix when guessing the wheel name
  as there are still plenty of recipes out there that do use
  python3 prefixes
- remove all previously generated wheels matching the glob
  to avoid installing any outdated blob via cleandirs
  in setuptools3 class.
  Unfortunetaly proposed dist-dir or bdist-dir are not
  respected by setuptools, likely due because they
  are overridable by the setup script
- don't use PV in glob, as PV doesn't necessarily align with the
  version used inside of the setuptools configuration.
  this will avoid having the user set PYPA_WHEEL in a lot
  of recipes
- respect SETUPTOOLS_SETUP_PATH in PIP_INSTALL_DIST_PATH
  and use B as a fallback only (in case this class is inherited
  without setuptools3 class being there as well).
  recipes like python3-smbus run in a subfolder of the
  workspace and were failing in before this adjustment

Signed-off-by: Konrad Weihmann 
---
v4: restructure name guessing to make wrongly placed brackets
being spottable more easily.
fix wrongly placed bracket to make name guessing work again
with pypi_package settings.
remove compile:prepend and use setuptools:do_compile cleandirs
option (see commit message for further explanation)
v3: remove in prepend to compile, not in install for obvious reasons
v2: fix python3 prefix string

 meta/classes/pip_install_wheel.bbclass | 8 +---
 meta/classes/setuptools3.bbclass   | 1 +
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/classes/pip_install_wheel.bbclass 
b/meta/classes/pip_install_wheel.bbclass
index 5b7e5cd706..3beff685bb 100644
--- a/meta/classes/pip_install_wheel.bbclass
+++ b/meta/classes/pip_install_wheel.bbclass
@@ -1,12 +1,14 @@
 DEPENDS:append = " python3-pip-native"
 
 def guess_pip_install_package_name(d):
+import re
 '''https://www.python.org/dev/peps/pep-0491/#escaping-and-unicode'''
-return (d.getVar('PYPI_PACKAGE') or d.getVar('BPN')).replace('-', '_')
+name = d.getVar('PYPI_PACKAGE') or re.sub(r"^python3-", "", 
d.getVar('BPN'))
+return name.replace('-', '_')
 
 PIP_INSTALL_PACKAGE ?= "${@guess_pip_install_package_name(d)}"
-PIP_INSTALL_DIST_PATH ?= "${B}/dist"
-PYPA_WHEEL ??= "${PIP_INSTALL_DIST_PATH}/${PIP_INSTALL_PACKAGE}-${PV}-*.whl"
+PIP_INSTALL_DIST_PATH ?= "${@d.getVar('SETUPTOOLS_SETUP_PATH') or 
d.getVar('B')}/dist"
+PYPA_WHEEL ??= "${PIP_INSTALL_DIST_PATH}/${PIP_INSTALL_PACKAGE}-*-*.whl"
 
 PIP_INSTALL_ARGS ?= "\
 - \
diff --git a/meta/classes/setuptools3.bbclass b/meta/classes/setuptools3.bbclass
index 12561340b0..564996c556 100644
--- a/meta/classes/setuptools3.bbclass
+++ b/meta/classes/setuptools3.bbclass
@@ -28,6 +28,7 @@ setuptools3_do_compile() {
 bbfatal_log "'${PYTHON_PN} setup.py bdist_wheel 
${SETUPTOOLS_BUILD_ARGS}' execution failed."
 }
 setuptools3_do_compile[vardepsexclude] = "MACHINE"
+do_compile[cleandirs] += "${SETUPTOOLS_SETUP_PATH}/dist"
 
 setuptools3_do_install() {
 cd ${SETUPTOOLS_SETUP_PATH}
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162600): 
https://lists.openembedded.org/g/openembedded-core/message/162600
Mute This Topic: https://lists.openembedded.org/mt/89497642/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/2] sstate: do not add TARGET_ARCH to pkgarch for cross recipes.

I just ran this locally, and it passed - probably caused by a different commit?

Alex

On Wed, 2 Mar 2022 at 08:24, Lee, Chee Yang  wrote:
>
> Need to update selftest too?
>
> sstatetests.SStateTests.test_sstate_allarch_samesigs
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3234/steps/14/logs/stdio
>
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Alexander Kanavin
> > Sent: Saturday, 26 February, 2022 11:02 PM
> > To: openembedded-core@lists.openembedded.org
> > Cc: Alexander Kanavin 
> > Subject: [OE-core] [PATCH 1/2] sstate: do not add TARGET_ARCH to pkgarch for
> > cross recipes.
> >
> > This is redundant (target arch is already in PN), and breaks compiling a 
> > cross-
> > canadian toolchain, as that needs populating the sysroot with two different
> > native-hosted toolchains built from cross recipes. Inserting TARGET_ARCH
> > allows only one or the other.
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  meta/classes/sstate.bbclass | 3 +--
> >  meta/lib/oe/sstatesig.py| 2 +-
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass index
> > 787172b408..dc9a2c085b 100644
> > --- a/meta/classes/sstate.bbclass
> > +++ b/meta/classes/sstate.bbclass
> > @@ -83,7 +83,6 @@ SSTATE_ARCHS = " \
> >  ${BUILD_ARCH} \
> >  ${BUILD_ARCH}_${ORIGNATIVELSBSTRING} \
> >  ${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS} \
> > -${BUILD_ARCH}_${TARGET_ARCH} \
> >  ${SDK_ARCH}_${SDK_OS} \
> >  ${SDK_ARCH}_${PACKAGE_ARCH} \
> >  allarch \
> > @@ -138,7 +137,7 @@ python () {
> >  elif bb.data.inherits_class('crosssdk', d):
> >  d.setVar('SSTATE_PKGARCH',
> > d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
> >  elif bb.data.inherits_class('cross', d):
> > -d.setVar('SSTATE_PKGARCH',
> > d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
> > +d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}"))
> >  elif bb.data.inherits_class('nativesdk', d):
> >  d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
> >  elif bb.data.inherits_class('cross-canadian', d):
> > diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py index
> > abcd96231e..2cf858e201 100644
> > --- a/meta/lib/oe/sstatesig.py
> > +++ b/meta/lib/oe/sstatesig.py
> > @@ -443,7 +443,7 @@ def find_sstate_manifest(taskdata, taskdata2, taskname,
> > d, multilibcache):
> >  elif "-cross-canadian" in taskdata:
> >  pkgarchs = ["${SDK_ARCH}_${SDK_ARCH}-${SDKPKGSUFFIX}"]
> >  elif "-cross-" in taskdata:
> > -pkgarchs = ["${BUILD_ARCH}_${TARGET_ARCH}"]
> > +pkgarchs = ["${BUILD_ARCH}"]
> >  elif "-crosssdk" in taskdata:
> >  pkgarchs = ["${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"]
> >  else:
> > --
> > 2.20.1
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162599): 
https://lists.openembedded.org/g/openembedded-core/message/162599
Mute This Topic: https://lists.openembedded.org/mt/89396615/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 2/3] perl: Makefile.PL: Fix _PATH_LOG for deterministic build

Yes, but you do not need to submit the patch for inclusion, only to
file a ticket, and ask upstream what can be done about the issue.

Alex

On Wed, 2 Mar 2022 at 09:47, Robert Yang  wrote:
>
> Hi
>
> On 3/2/22 4:42 PM, Alexander Kanavin wrote:
> > Can you file a ticket upstream for this please, and include the link
> > in the patch?
> >
>
> This patch won't work for upstream, only work by cross building, let me check 
> on
> how to make it work for all cases.
>
> // Robert
>
>
> > Alex
> >
> > On Wed, 2 Mar 2022 at 08:13, Robert Yang  wrote:
> >>
> >> It checks host's path such as /dev/log and uses it, this doesn't make 
> >> sense for
> >> cross build, and it causes undeterministic, for example, the contianer os
> >> usually doesn't have /dev/log which leads to a different build result since
> >> other host usually has /dev/log, so make it always use the default value 
> >> to fix
> >> the issue.
> >>
> >> Signed-off-by: Robert Yang 
> >> ---
> >>   ...Makefile.PL-Fix-_PATH_LOG-for-determ.patch | 34 +++
> >>   meta/recipes-devtools/perl/perl_5.34.0.bb |  1 +
> >>   2 files changed, 35 insertions(+)
> >>   create mode 100644 
> >> meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
> >>
> >> diff --git 
> >> a/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
> >>  
> >> b/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
> >> new file mode 100644
> >> index 000..f6bcbce6856
> >> --- /dev/null
> >> +++ 
> >> b/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
> >> @@ -0,0 +1,34 @@
> >> +From a73fff1fcf0def4ce93964f1b63fe3ad0967259d Mon Sep 17 00:00:00 2001
> >> +From: Robert Yang 
> >> +Date: Fri, 18 Feb 2022 09:44:26 +
> >> +Subject: [PATCH] cpan/Sys-Syslog/Makefile.PL: Fix _PATH_LOG for 
> >> deterministic
> >> +
> >> +It checks host's path such as /dev/log and uses it, this doesn't make 
> >> sense for
> >> +cross build, and it causes undeterministic, for example, the contianer os
> >> +usually doesn't have /dev/log which leads to a different build result 
> >> since
> >> +other host usually has /dev/log, so make it always use the default value 
> >> to fix
> >> +the issue.
> >> +
> >> +Upstream-Status:Inappropriate [OE specific]
> >> +
> >> +Signed-off-by: Robert Yang 
> >> +---
> >> + cpan/Sys-Syslog/Makefile.PL | 2 ++
> >> + 1 file changed, 2 insertions(+)
> >> +
> >> +diff --git a/cpan/Sys-Syslog/Makefile.PL b/cpan/Sys-Syslog/Makefile.PL
> >> +index d09ba69..d44e58c 100644
> >> +--- a/cpan/Sys-Syslog/Makefile.PL
> >>  b/cpan/Sys-Syslog/Makefile.PL
> >> +@@ -130,6 +130,8 @@ else {
> >> + $_PATH_LOG = "";
> >> + }
> >> +
> >> ++# OE specific
> >> ++$_PATH_LOG = "";
> >> +
> >> + # if possible, generate the code that handles the constants with
> >> + # ExtUtils::Constant, otherwise use cached copy in fallback/
> >> +--
> >> +2.31.1
> >> +
> >> diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb 
> >> b/meta/recipes-devtools/perl/perl_5.34.0.bb
> >> index a97da872032..8a1db7ed359 100644
> >> --- a/meta/recipes-devtools/perl/perl_5.34.0.bb
> >> +++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
> >> @@ -20,6 +20,7 @@ SRC_URI = 
> >> "https://www.cpan.org/src/5.0/perl-${PV}.tar.gz;name=perl \
> >>  file://aacd2398e766500cb5d83c4d76b642fcf31d997a.patch \
> >>  file://ea57297a58b8f10ab885c19eec48ea076116cc1f.patch \
> >>  file://5bc1e5fdd87aa205011512cd1e6cc655bcf677fd.patch \
> >> +   
> >> file://0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch \
> >>  "
> >>   SRC_URI:append:class-native = " \
> >>  file://perl-configpm-switch.patch \
> >> --
> >> 2.31.1
> >>
> >>
> >> 
> >>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162598): 
https://lists.openembedded.org/g/openembedded-core/message/162598
Mute This Topic: https://lists.openembedded.org/mt/89496472/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 2/3] perl: Makefile.PL: Fix _PATH_LOG for deterministic build

2022-03-02 Thread Robert Yang


Hi

On 3/2/22 4:42 PM, Alexander Kanavin wrote:

Can you file a ticket upstream for this please, and include the link
in the patch?



This patch won't work for upstream, only work by cross building, let me check on 
how to make it work for all cases.


// Robert



Alex

On Wed, 2 Mar 2022 at 08:13, Robert Yang  wrote:


It checks host's path such as /dev/log and uses it, this doesn't make sense for
cross build, and it causes undeterministic, for example, the contianer os
usually doesn't have /dev/log which leads to a different build result since
other host usually has /dev/log, so make it always use the default value to fix
the issue.

Signed-off-by: Robert Yang 
---
  ...Makefile.PL-Fix-_PATH_LOG-for-determ.patch | 34 +++
  meta/recipes-devtools/perl/perl_5.34.0.bb |  1 +
  2 files changed, 35 insertions(+)
  create mode 100644 
meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch

diff --git 
a/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
 
b/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
new file mode 100644
index 000..f6bcbce6856
--- /dev/null
+++ 
b/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
@@ -0,0 +1,34 @@
+From a73fff1fcf0def4ce93964f1b63fe3ad0967259d Mon Sep 17 00:00:00 2001
+From: Robert Yang 
+Date: Fri, 18 Feb 2022 09:44:26 +
+Subject: [PATCH] cpan/Sys-Syslog/Makefile.PL: Fix _PATH_LOG for deterministic
+
+It checks host's path such as /dev/log and uses it, this doesn't make sense for
+cross build, and it causes undeterministic, for example, the contianer os
+usually doesn't have /dev/log which leads to a different build result since
+other host usually has /dev/log, so make it always use the default value to fix
+the issue.
+
+Upstream-Status:Inappropriate [OE specific]
+
+Signed-off-by: Robert Yang 
+---
+ cpan/Sys-Syslog/Makefile.PL | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/cpan/Sys-Syslog/Makefile.PL b/cpan/Sys-Syslog/Makefile.PL
+index d09ba69..d44e58c 100644
+--- a/cpan/Sys-Syslog/Makefile.PL
 b/cpan/Sys-Syslog/Makefile.PL
+@@ -130,6 +130,8 @@ else {
+ $_PATH_LOG = "";
+ }
+
++# OE specific
++$_PATH_LOG = "";
+
+ # if possible, generate the code that handles the constants with
+ # ExtUtils::Constant, otherwise use cached copy in fallback/
+--
+2.31.1
+
diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb 
b/meta/recipes-devtools/perl/perl_5.34.0.bb
index a97da872032..8a1db7ed359 100644
--- a/meta/recipes-devtools/perl/perl_5.34.0.bb
+++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
@@ -20,6 +20,7 @@ SRC_URI = 
"https://www.cpan.org/src/5.0/perl-${PV}.tar.gz;name=perl \
 file://aacd2398e766500cb5d83c4d76b642fcf31d997a.patch \
 file://ea57297a58b8f10ab885c19eec48ea076116cc1f.patch \
 file://5bc1e5fdd87aa205011512cd1e6cc655bcf677fd.patch \
+   
file://0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch \
 "
  SRC_URI:append:class-native = " \
 file://perl-configpm-switch.patch \
--
2.31.1





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162597): 
https://lists.openembedded.org/g/openembedded-core/message/162597
Mute This Topic: https://lists.openembedded.org/mt/89496472/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 2/3] perl: Makefile.PL: Fix _PATH_LOG for deterministic build

Can you file a ticket upstream for this please, and include the link
in the patch?

Alex

On Wed, 2 Mar 2022 at 08:13, Robert Yang  wrote:
>
> It checks host's path such as /dev/log and uses it, this doesn't make sense 
> for
> cross build, and it causes undeterministic, for example, the contianer os
> usually doesn't have /dev/log which leads to a different build result since
> other host usually has /dev/log, so make it always use the default value to 
> fix
> the issue.
>
> Signed-off-by: Robert Yang 
> ---
>  ...Makefile.PL-Fix-_PATH_LOG-for-determ.patch | 34 +++
>  meta/recipes-devtools/perl/perl_5.34.0.bb |  1 +
>  2 files changed, 35 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
>
> diff --git 
> a/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
>  
> b/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
> new file mode 100644
> index 000..f6bcbce6856
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/perl/files/0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch
> @@ -0,0 +1,34 @@
> +From a73fff1fcf0def4ce93964f1b63fe3ad0967259d Mon Sep 17 00:00:00 2001
> +From: Robert Yang 
> +Date: Fri, 18 Feb 2022 09:44:26 +
> +Subject: [PATCH] cpan/Sys-Syslog/Makefile.PL: Fix _PATH_LOG for deterministic
> +
> +It checks host's path such as /dev/log and uses it, this doesn't make sense 
> for
> +cross build, and it causes undeterministic, for example, the contianer os
> +usually doesn't have /dev/log which leads to a different build result since
> +other host usually has /dev/log, so make it always use the default value to 
> fix
> +the issue.
> +
> +Upstream-Status:Inappropriate [OE specific]
> +
> +Signed-off-by: Robert Yang 
> +---
> + cpan/Sys-Syslog/Makefile.PL | 2 ++
> + 1 file changed, 2 insertions(+)
> +
> +diff --git a/cpan/Sys-Syslog/Makefile.PL b/cpan/Sys-Syslog/Makefile.PL
> +index d09ba69..d44e58c 100644
> +--- a/cpan/Sys-Syslog/Makefile.PL
>  b/cpan/Sys-Syslog/Makefile.PL
> +@@ -130,6 +130,8 @@ else {
> + $_PATH_LOG = "";
> + }
> +
> ++# OE specific
> ++$_PATH_LOG = "";
> +
> + # if possible, generate the code that handles the constants with
> + # ExtUtils::Constant, otherwise use cached copy in fallback/
> +--
> +2.31.1
> +
> diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb 
> b/meta/recipes-devtools/perl/perl_5.34.0.bb
> index a97da872032..8a1db7ed359 100644
> --- a/meta/recipes-devtools/perl/perl_5.34.0.bb
> +++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
> @@ -20,6 +20,7 @@ SRC_URI = 
> "https://www.cpan.org/src/5.0/perl-${PV}.tar.gz;name=perl \
> file://aacd2398e766500cb5d83c4d76b642fcf31d997a.patch \
> file://ea57297a58b8f10ab885c19eec48ea076116cc1f.patch \
> file://5bc1e5fdd87aa205011512cd1e6cc655bcf677fd.patch \
> +   
> file://0001-cpan-Sys-Syslog-Makefile.PL-Fix-_PATH_LOG-for-determ.patch \
> "
>  SRC_URI:append:class-native = " \
> file://perl-configpm-switch.patch \
> --
> 2.31.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162596): 
https://lists.openembedded.org/g/openembedded-core/message/162596
Mute This Topic: https://lists.openembedded.org/mt/89496472/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 v3] pip_install_wheel: improve wheel handling