All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* btrfs-tools-native build python error
       [not found] <CAMWxwJ0znPDyQAKAwv8PL9GwyCCEpW9+2SDmXsygNyK26_xF-A@mail.gmail.com>
@ 2024-04-25 12:29 ` Lean Sheng Tan
  2024-04-25 16:33   ` [OE-core] " Ross Burton
  0 siblings, 1 reply; 14+ messages in thread
From: Lean Sheng Tan @ 2024-04-25 12:29 UTC (permalink / raw
  To: openembedded-core; +Cc: Hansen, Alexander, John Chung

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

Hi,
Good day to openembedded community!

This is my first post - hope this is the right place to ask for help
regarding a build issue, as refer from here:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/71017/comment/195b742f_6cf8da09/

Currently, we saw this issue when building this on openBMC which is based
on Yocto:-
The error found when manually run bitbake btrfs-tools-native is as follows:

>  checking for a Python interpreter with version >= 3.4... python3
>  checking for python3...
> /home/apwillia/local/builds/lf-build-yosemite4/tmp/hosttools/python3
>  checking for python3 version... 3.11
>  checking for python3 platform... linux
>  checking for GNU default python3 prefix... ${prefix}
>  checking for GNU default python3 exec_prefix... ${exec_prefix}
>  checking for python3 script directory (pythondir)...
> ${libdir}/python3.11/site-packages
>  checking for python3 extension module directory (pyexecdir)...
> ${libdir}/python3.11/site-packages
>  checking for python-3.11... no
>  configure: error: Package requirements (python-3.11) were not met:
>
>  No package 'python-3.11' found


To bypass this, we have to manually remove in OpenBMC with this tweak:

> PACKAGECONFIG:remove:pn-btrfs-tools-native = "python"


May I know if this is a real bug, or if we did miss something from our
configuration?

Thank you again for the help!

Best Regards,
Sheng

[-- Attachment #2: Type: text/html, Size: 2539 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-04-25 12:29 ` btrfs-tools-native build python error Lean Sheng Tan
@ 2024-04-25 16:33   ` Ross Burton
  2024-04-25 16:45     ` Lean Sheng Tan
       [not found]     ` <17C993B983870D20.19690@lists.openembedded.org>
  0 siblings, 2 replies; 14+ messages in thread
From: Ross Burton @ 2024-04-25 16:33 UTC (permalink / raw
  To: sheng.tan@9elements.com
  Cc: openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

On 25 Apr 2024, at 13:29, Sheng Lean Tan via lists.openembedded.org <sheng.tan=9elements.com@lists.openembedded.org> wrote:
> 
> Hi,
> Good day to openembedded community!
> 
> This is my first post - hope this is the right place to ask for help regarding a build issue, as refer from here:
> https://gerrit.openbmc.org/c/openbmc/openbmc/+/71017/comment/195b742f_6cf8da09/
> 
> Currently, we saw this issue when building this on openBMC which is based on Yocto:-
> The error found when manually run bitbake btrfs-tools-native is as follows:
>  checking for a Python interpreter with version >= 3.4... python3
>  checking for python3... /home/apwillia/local/builds/lf-build-yosemite4/tmp/hosttools/python3
>  checking for python3 version... 3.11
>  checking for python3 platform... linux
>  checking for GNU default python3 prefix... ${prefix}
>  checking for GNU default python3 exec_prefix... ${exec_prefix}
>  checking for python3 script directory (pythondir)... ${libdir}/python3.11/site-packages
>  checking for python3 extension module directory (pyexecdir)... ${libdir}/python3.11/site-packages
>  checking for python-3.11... no
>  configure: error: Package requirements (python-3.11) were not met:
> 
>  No package 'python-3.11' found
> 
> To bypass this, we have to manually remove in OpenBMC with this tweak:
> PACKAGECONFIG:remove:pn-btrfs-tools-native = "python"
> 
> May I know if this is a real bug, or if we did miss something from our configuration?

It looks like the native btrfs-tools is trying to build against the host python:

>  checking for python3... /home/apwillia/local/builds/lf-build-yosemite4/tmp/hosttools/python3

So the problem is that your build host doesn’t have python3-dev or similar installed.

That dependency in btrfs-tools might be actually not required, or you might want to make the recipe depend on python3-native. 

Ross

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-04-25 16:33   ` [OE-core] " Ross Burton
@ 2024-04-25 16:45     ` Lean Sheng Tan
       [not found]     ` <17C993B983870D20.19690@lists.openembedded.org>
  1 sibling, 0 replies; 14+ messages in thread
From: Lean Sheng Tan @ 2024-04-25 16:45 UTC (permalink / raw
  To: Ross Burton
  Cc: openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

Hi Ross,
Thank you for your quick response!
That makes sense now.

Regarding your statement:
"That dependency in btrfs-tools might be actually not required, or you
might want to make the recipe depend on python3-native."
May I know if something has to be fixed from the meta-openembedded or
generic yocto build?
If not, what would be the best way to approach it?

Thanks again.

Best Regards,
Sheng


On Thu, 25 Apr 2024 at 18:34, Ross Burton <Ross.Burton@arm.com> wrote:

> On 25 Apr 2024, at 13:29, Sheng Lean Tan via lists.openembedded.org
> <sheng.tan=9elements.com@lists.openembedded.org> wrote:
> >
> > Hi,
> > Good day to openembedded community!
> >
> > This is my first post - hope this is the right place to ask for help
> regarding a build issue, as refer from here:
> >
> https://gerrit.openbmc.org/c/openbmc/openbmc/+/71017/comment/195b742f_6cf8da09/
> >
> > Currently, we saw this issue when building this on openBMC which is
> based on Yocto:-
> > The error found when manually run bitbake btrfs-tools-native is as
> follows:
> >  checking for a Python interpreter with version >= 3.4... python3
> >  checking for python3...
> /home/apwillia/local/builds/lf-build-yosemite4/tmp/hosttools/python3
> >  checking for python3 version... 3.11
> >  checking for python3 platform... linux
> >  checking for GNU default python3 prefix... ${prefix}
> >  checking for GNU default python3 exec_prefix... ${exec_prefix}
> >  checking for python3 script directory (pythondir)...
> ${libdir}/python3.11/site-packages
> >  checking for python3 extension module directory (pyexecdir)...
> ${libdir}/python3.11/site-packages
> >  checking for python-3.11... no
> >  configure: error: Package requirements (python-3.11) were not met:
> >
> >  No package 'python-3.11' found
> >
> > To bypass this, we have to manually remove in OpenBMC with this tweak:
> > PACKAGECONFIG:remove:pn-btrfs-tools-native = "python"
> >
> > May I know if this is a real bug, or if we did miss something from our
> configuration?
>
> It looks like the native btrfs-tools is trying to build against the host
> python:
>
> >  checking for python3...
> /home/apwillia/local/builds/lf-build-yosemite4/tmp/hosttools/python3
>
> So the problem is that your build host doesn’t have python3-dev or similar
> installed.
>
> That dependency in btrfs-tools might be actually not required, or you
> might want to make the recipe depend on python3-native.
>
> Ross

[-- Attachment #2: Type: text/html, Size: 3695 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
       [not found]     ` <17C993B983870D20.19690@lists.openembedded.org>
@ 2024-04-25 17:40       ` Lean Sheng Tan
  2024-05-01 21:27         ` Patrick Williams
  0 siblings, 1 reply; 14+ messages in thread
From: Lean Sheng Tan @ 2024-04-25 17:40 UTC (permalink / raw
  To: sheng.tan
  Cc: Ross Burton, openembedded-core@lists.openembedded.org,
	Hansen, Alexander, John Chung, patrick

[-- Attachment #1: Type: text/plain, Size: 4528 bytes --]

Hi Ross,
Here is the background of this:
Initially we found this issue, when we are trying to build the Arm FVP for
openbmc, as you can see from the discussion here:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/70070/comment/4a963c24_75b11840/

So thanks to the kind help from Patrick Williams (cc'ed here), he proposed
to try this fix:

> diff --git a/poky/meta/recipes-kernel/perf/perf.bb
> b/poky/meta/recipes-kernel/perf/perf.bb
> index 11fa917649..d39265367b 100644
> --- a/poky/meta/recipes-kernel/perf/perf.bb
> +++ b/poky/meta/recipes-kernel/perf/perf.bb
> @@ -54,7 +54,7 @@ PROVIDES = "virtual/perf"
>  inherit linux-kernel-base kernel-arch manpages


 # needed for building the tools/perf Python bindings
> -inherit_defer ${@bb.utils.contains('PACKAGECONFIG', 'python',
> 'python3targetconfig', '', d)}
> +inherit_defer ${@bb.utils.contains('PACKAGECONFIG', 'python',
> 'setuptools3-base python3targetconfig', '', d)}


However, it is still not working. I added a workaround with this patch:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/71017

Still, Patrick thinks that this should not be the case, and the proper fix
should be done via OpenEmbedded.

Currently we are not sure how to fix this properly and don't have any idea.
Much appreciated if you or anyone have any idea on this!

Thank you,
Sheng


On Thu, 25 Apr 2024 at 18:45, Lean Sheng Tan via lists.openembedded.org
<sheng.tan=9elements.com@lists.openembedded.org> wrote:

> Hi Ross,
> Thank you for your quick response!
> That makes sense now.
>
> Regarding your statement:
> "That dependency in btrfs-tools might be actually not required, or you
> might want to make the recipe depend on python3-native."
> May I know if something has to be fixed from the meta-openembedded or
> generic yocto build?
> If not, what would be the best way to approach it?
>
> Thanks again.
>
> Best Regards,
> Sheng
>
>
> On Thu, 25 Apr 2024 at 18:34, Ross Burton <Ross.Burton@arm.com> wrote:
>
>> On 25 Apr 2024, at 13:29, Sheng Lean Tan via lists.openembedded.org
>> <sheng.tan=9elements.com@lists.openembedded.org> wrote:
>> >
>> > Hi,
>> > Good day to openembedded community!
>> >
>> > This is my first post - hope this is the right place to ask for help
>> regarding a build issue, as refer from here:
>> >
>> https://gerrit.openbmc.org/c/openbmc/openbmc/+/71017/comment/195b742f_6cf8da09/
>> >
>> > Currently, we saw this issue when building this on openBMC which is
>> based on Yocto:-
>> > The error found when manually run bitbake btrfs-tools-native is as
>> follows:
>> >  checking for a Python interpreter with version >= 3.4... python3
>> >  checking for python3...
>> /home/apwillia/local/builds/lf-build-yosemite4/tmp/hosttools/python3
>> >  checking for python3 version... 3.11
>> >  checking for python3 platform... linux
>> >  checking for GNU default python3 prefix... ${prefix}
>> >  checking for GNU default python3 exec_prefix... ${exec_prefix}
>> >  checking for python3 script directory (pythondir)...
>> ${libdir}/python3.11/site-packages
>> >  checking for python3 extension module directory (pyexecdir)...
>> ${libdir}/python3.11/site-packages
>> >  checking for python-3.11... no
>> >  configure: error: Package requirements (python-3.11) were not met:
>> >
>> >  No package 'python-3.11' found
>> >
>> > To bypass this, we have to manually remove in OpenBMC with this tweak:
>> > PACKAGECONFIG:remove:pn-btrfs-tools-native = "python"
>> >
>> > May I know if this is a real bug, or if we did miss something from our
>> configuration?
>>
>> It looks like the native btrfs-tools is trying to build against the host
>> python:
>>
>> >  checking for python3...
>> /home/apwillia/local/builds/lf-build-yosemite4/tmp/hosttools/python3
>>
>> So the problem is that your build host doesn’t have python3-dev or
>> similar installed.
>>
>> That dependency in btrfs-tools might be actually not required, or you
>> might want to make the recipe depend on python3-native.
>>
>> Ross
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#198706):
> https://lists.openembedded.org/g/openembedded-core/message/198706
> Mute This Topic: https://lists.openembedded.org/mt/105729019/6757431
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> sheng.tan@9elements.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 7170 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-04-25 17:40       ` Lean Sheng Tan
@ 2024-05-01 21:27         ` Patrick Williams
  2024-05-02  9:28           ` Alexander Kanavin
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Williams @ 2024-05-01 21:27 UTC (permalink / raw
  To: Lean Sheng Tan
  Cc: Ross Burton, openembedded-core@lists.openembedded.org,
	Hansen, Alexander, John Chung

[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]

On Thu, Apr 25, 2024 at 07:40:15PM +0200, Lean Sheng Tan wrote:
> >> > The error found when manually run bitbake btrfs-tools-native is as
> >> follows:
> >> >  checking for a Python interpreter with version >= 3.4... python3
> >> >  checking for python3...
> >> /home/apwillia/local/builds/lf-build-yosemite4/tmp/hosttools/python3
> >> >  checking for python3 version... 3.11
> >> >  checking for python3 platform... linux
> >> >  checking for GNU default python3 prefix... ${prefix}
> >> >  checking for GNU default python3 exec_prefix... ${exec_prefix}
> >> >  checking for python3 script directory (pythondir)...
> >> ${libdir}/python3.11/site-packages
> >> >  checking for python3 extension module directory (pyexecdir)...
> >> ${libdir}/python3.11/site-packages
> >> >  checking for python-3.11... no
> >> >  configure: error: Package requirements (python-3.11) were not met:
> >> >
> >> >  No package 'python-3.11' found
> >> >
> >> > To bypass this, we have to manually remove in OpenBMC with this tweak:
> >> > PACKAGECONFIG:remove:pn-btrfs-tools-native = "python"

I dug into this a bit more by starting from first principles.  Building
with an unchanged poky with the crops/poky docker container works.  Just
like you would expect, `PYTHON` gets set to `python3-native/python3`:

```
# $PYTHON [3 operations]
#   set /rundir/meta/conf/bitbake.conf:574
#     "${@sys.executable}"
#   set /rundir/meta/classes-recipe/python3native.bbclass:9
#     "${STAGING_BINDIR_NATIVE}/python3-native/python3"
```

So, I did the same thing in our OpenBMC tree:

```
# $PYTHON
#   set /home/apwillia/private/dev/openbmc/openbmc/meta/conf/bitbake.conf:574
#     "${@sys.executable}"
PYTHON="/usr/lib/python-exec/python3.11/python3"
```

Somehow, `python3native.bbclass` is never inherited (also checked the
`INCLUDE HISTORY`).

The `btrfs-tools_6.8.bb` uses the new-ish `inherit_defer`, so I did some
more change there to debug:

```
- inherit_defer ${@bb.utils.contains('PACKAGECONFIG', 'python', 'setuptools3-base', '', d)}
+ inherit_defer ${@bb.utils.contains('PACKAGECONFIG', 'python', 'setuptools3-base', 'this_doesnt_exist' + d.getVar('PACKAGECONFIG').replace(' ', '/'), d)}
```

This resulted in:
```
ERROR: ParseError at /home/apwillia/private/dev/openbmc/openbmc/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.8.bb:46: Could not inherit file classes/this_doesnt_exist/////programs/////convert//////////crypto-builtin//.bbclass
```

So... not only are we not getting the `setuptools3-base` side of the
`inherit_defer`, but `PACKAGECONFIG` doesn't even contain `python`.
Which is not true because:

```
# pre-expansion value:
#   "     programs     convert     python     crypto-builtin "
PACKAGECONFIG="     programs     convert     python     crypto-builtin "
```

What is going on here?  Well, this:

```
meta-phosphor/conf/distro/include/phosphor-pkg-tweaks.inc
6:# Disable python from btrfs-tools
7:PACKAGECONFIG:remove:pn-btrfs-tools = "python"
```

We explicitly remove `python` from the _target_ btrfs-tools
`PACKAGECONFIG`, because we don't want it on-device (since that pulls
python itself as a side-effect).  If I remove this _target_ setting
everything works fine for the native package:

```
# $PYTHON [3 operations]
#   set /home/apwillia/private/dev/openbmc/openbmc/meta/conf/bitbake.conf:574
#     "${@sys.executable}"
#   set /home/apwillia/private/dev/openbmc/openbmc/meta/classes-recipe/python3native.bbclass:9
#     "${STAGING_BINDIR_NATIVE}/python3-native/python3"
#   exported ast.py:52 [eval]
#     [export] "1"
# pre-expansion value:
#   "${STAGING_BINDIR_NATIVE}/python3-native/python3"
export PYTHON="/home/apwillia/local/builds/lf-build-yosemite4/tmp/work/x86_64-linux/btrfs-tools-native/6.8/recipe-sysroot-native/usr/bin/python3-native/python3"
```

It seems to me like `inherit_defer` is broken.  Why is the _target_
variable being used for a _native_ recipe?

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-01 21:27         ` Patrick Williams
@ 2024-05-02  9:28           ` Alexander Kanavin
  2024-05-02 12:52             ` Patrick Williams
  0 siblings, 1 reply; 14+ messages in thread
From: Alexander Kanavin @ 2024-05-02  9:28 UTC (permalink / raw
  To: patrick
  Cc: Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

On Wed, 1 May 2024 at 23:27, Patrick Williams via
lists.openembedded.org <patrick=stwcx.xyz@lists.openembedded.org>
wrote:
> What is going on here?  Well, this:
>
> ```
> meta-phosphor/conf/distro/include/phosphor-pkg-tweaks.inc
> 6:# Disable python from btrfs-tools
> 7:PACKAGECONFIG:remove:pn-btrfs-tools = "python"
> ```
>
> We explicitly remove `python` from the _target_ btrfs-tools
> `PACKAGECONFIG`, because we don't want it on-device (since that pulls
> python itself as a side-effect).  If I remove this _target_ setting
> everything works fine for the native package:

It's not a target setting. PACKAGECONFIG without qualifier overrides
applies to all variants.

Alex


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-02  9:28           ` Alexander Kanavin
@ 2024-05-02 12:52             ` Patrick Williams
  2024-05-02 12:57               ` Alexander Kanavin
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Williams @ 2024-05-02 12:52 UTC (permalink / raw
  To: Alexander Kanavin
  Cc: Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

On Thu, May 02, 2024 at 11:28:54AM +0200, Alexander Kanavin wrote:
> On Wed, 1 May 2024 at 23:27, Patrick Williams via
> lists.openembedded.org <patrick=stwcx.xyz@lists.openembedded.org>
> wrote:
> > What is going on here?  Well, this:
> >
> > ```
> > meta-phosphor/conf/distro/include/phosphor-pkg-tweaks.inc
> > 6:# Disable python from btrfs-tools
> > 7:PACKAGECONFIG:remove:pn-btrfs-tools = "python"
> > ```
> >
> > We explicitly remove `python` from the _target_ btrfs-tools
> > `PACKAGECONFIG`, because we don't want it on-device (since that pulls
> > python itself as a side-effect).  If I remove this _target_ setting
> > everything works fine for the native package:
> 
> It's not a target setting. PACKAGECONFIG without qualifier overrides
> applies to all variants.

I'm not convinced this is true.  As I wrote, the final result of
PACKAGECONFIG is exactly what I expect; it includes `python` for the
btrfs-tools-native and doesn't for the plain btrfs-tools:

```
# pre-expansion value:
#   "     programs     convert     python     crypto-builtin "
PACKAGECONFIG="     programs     convert     python     crypto-builtin "
```

I've also tried switching to this, which is very clearly a "target"
qualifier and have the same exact results; it applies on "native"
`inherit_defer` evaluations:

btrfs-tools_%.bbappend with...
```
PACKAGECONFIG:remove:class-target = "python"
```

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-02 12:52             ` Patrick Williams
@ 2024-05-02 12:57               ` Alexander Kanavin
  2024-05-02 13:01                 ` Alexander Kanavin
                                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Alexander Kanavin @ 2024-05-02 12:57 UTC (permalink / raw
  To: Patrick Williams
  Cc: Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

On Thu, 2 May 2024 at 14:52, Patrick Williams <patrick@stwcx.xyz> wrote:

> I'm not convinced this is true.  As I wrote, the final result of
> PACKAGECONFIG is exactly what I expect; it includes `python` for the
> btrfs-tools-native and doesn't for the plain btrfs-tools:
>
> ```
> # pre-expansion value:
> #   "     programs     convert     python     crypto-builtin "
> PACKAGECONFIG="     programs     convert     python     crypto-builtin "
> ```

Run experiments with plain poky and changes in local.conf, and that
will convince you.

> I've also tried switching to this, which is very clearly a "target"
> qualifier and have the same exact results; it applies on "native"
> `inherit_defer` evaluations:
>
> btrfs-tools_%.bbappend with...
> ```
> PACKAGECONFIG:remove:class-target = "python"
> ```

class-target:remove, not the other way around.

Alex


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-02 12:57               ` Alexander Kanavin
@ 2024-05-02 13:01                 ` Alexander Kanavin
  2024-05-02 13:06                 ` Patrick Williams
  2024-05-02 13:34                 ` Patrick Williams
  2 siblings, 0 replies; 14+ messages in thread
From: Alexander Kanavin @ 2024-05-02 13:01 UTC (permalink / raw
  To: Patrick Williams
  Cc: Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

On Thu, 2 May 2024 at 14:57, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> > I've also tried switching to this, which is very clearly a "target"
> > qualifier and have the same exact results; it applies on "native"
> > `inherit_defer` evaluations:
> >
> > btrfs-tools_%.bbappend with...
> > ```
> > PACKAGECONFIG:remove:class-target = "python"
> > ```
>
> class-target:remove, not the other way around.

Ha, I got both of these wrong. Sorry.

Alex


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-02 12:57               ` Alexander Kanavin
  2024-05-02 13:01                 ` Alexander Kanavin
@ 2024-05-02 13:06                 ` Patrick Williams
  2024-05-02 13:34                   ` Alexander Kanavin
  2024-05-02 13:34                 ` Patrick Williams
  2 siblings, 1 reply; 14+ messages in thread
From: Patrick Williams @ 2024-05-02 13:06 UTC (permalink / raw
  To: Alexander Kanavin
  Cc: Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

On Thu, May 02, 2024 at 02:57:30PM +0200, Alexander Kanavin wrote:
> On Thu, 2 May 2024 at 14:52, Patrick Williams <patrick@stwcx.xyz> wrote:
> 
> > I'm not convinced this is true.  As I wrote, the final result of
> > PACKAGECONFIG is exactly what I expect; it includes `python` for the
> > btrfs-tools-native and doesn't for the plain btrfs-tools:
> >
> > ```
> > # pre-expansion value:
> > #   "     programs     convert     python     crypto-builtin "
> > PACKAGECONFIG="     programs     convert     python     crypto-builtin "
> > ```
> 
> Run experiments with plain poky and changes in local.conf, and that
> will convince you.
> 
> > I've also tried switching to this, which is very clearly a "target"
> > qualifier and have the same exact results; it applies on "native"
> > `inherit_defer` evaluations:
> >
> > btrfs-tools_%.bbappend with...
> > ```
> > PACKAGECONFIG:remove:class-target = "python"
> > ```
> 
> class-target:remove, not the other way around.

This is almost never correct and there is not a single example of it in
poky.  There _are_ examples of exactly what I wrote.

If you do `PACKAGECONFIG:class-target:remove` and there is not already
an explicit `PACKAGECONFIG:class-target` defined, this in effect creates
a _new_ _empty_ variable `PACKAGECONFIG:class-target`.  This is nearly
never what you want.  You typically want to take the base contents of
`PACAKGECONFIG` and remove something from it explicitly for the
`class-target` class.  What I wrote is exactly how to do that and what
there are multiple examples of in poky (see tclibc-barmetal.inc,
no-gplv3.inc, meta-openembedded uim_1.8.8.bb).

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-02 13:06                 ` Patrick Williams
@ 2024-05-02 13:34                   ` Alexander Kanavin
  2024-05-02 13:39                     ` Patrick Williams
  0 siblings, 1 reply; 14+ messages in thread
From: Alexander Kanavin @ 2024-05-02 13:34 UTC (permalink / raw
  To: Patrick Williams, Richard Purdie
  Cc: Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

On Thu, 2 May 2024 at 15:06, Patrick Williams <patrick@stwcx.xyz> wrote:

> This is almost never correct and there is not a single example of it in
> poky.  There _are_ examples of exactly what I wrote.
>
> If you do `PACKAGECONFIG:class-target:remove` and there is not already
> an explicit `PACKAGECONFIG:class-target` defined, this in effect creates
> a _new_ _empty_ variable `PACKAGECONFIG:class-target`.  This is nearly
> never what you want.  You typically want to take the base contents of
> `PACAKGECONFIG` and remove something from it explicitly for the
> `class-target` class.  What I wrote is exactly how to do that and what
> there are multiple examples of in poky (see tclibc-barmetal.inc,
> no-gplv3.inc, meta-openembedded uim_1.8.8.bb).

Right, I just reproduced this. To me this looks like conditions in
inherit_defer operate on PACKAGECONFIG value that is assembled without
considering class overrides, and that might be a bug.

How to see the issue:
PACKAGECONFIG:remove:class-target:pn-btrfs-tools = "python"

bitbake btrfs-tools-native

You might be able to work around this by avoiding :remove and setting
PACKAGECONFIG directly.

Alex


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-02 12:57               ` Alexander Kanavin
  2024-05-02 13:01                 ` Alexander Kanavin
  2024-05-02 13:06                 ` Patrick Williams
@ 2024-05-02 13:34                 ` Patrick Williams
  2 siblings, 0 replies; 14+ messages in thread
From: Patrick Williams @ 2024-05-02 13:34 UTC (permalink / raw
  To: Alexander Kanavin
  Cc: Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

On Thu, May 02, 2024 at 02:57:30PM +0200, Alexander Kanavin wrote:
> On Thu, 2 May 2024 at 14:52, Patrick Williams <patrick@stwcx.xyz> wrote:
> 
> > I'm not convinced this is true.  As I wrote, the final result of
> > PACKAGECONFIG is exactly what I expect; it includes `python` for the
> > btrfs-tools-native and doesn't for the plain btrfs-tools:
> 
> Run experiments with plain poky and changes in local.conf, and that
> will convince you.
> 

Done.  This is with the latest poky and crops/poky docker container.

1. PACKAGECONFIG:remove:pn-btrfs-tools = "python"

bitbake -ne btrfs-tools-native results:
    PACKAGECONFIG="     programs     convert     python     crypto-builtin "

bitbake -ne btrfs-tools results:
    PACKAGECONFIG="     programs     convert          crypto-builtin  "

2. PACKAGECONFIG:remove:pn-btrfs-tools-native = "python"

bitbake -ne btrfs-tools-native results:
    PACKAGECONFIG="     programs     convert          crypto-builtin "

bitbake -ne btrfs-tools results:
    PACKAGECONFIG="     programs     convert     python     crypto-builtin  "

These are the exact same results I am seeing with our openbmc tree and
exactly what is expected to me.  Still, `inherit_defer` gets the
incorrect evaluation results.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-02 13:34                   ` Alexander Kanavin
@ 2024-05-02 13:39                     ` Patrick Williams
  2024-05-02 13:50                       ` Richard Purdie
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Williams @ 2024-05-02 13:39 UTC (permalink / raw
  To: Alexander Kanavin
  Cc: Richard Purdie, Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

On Thu, May 02, 2024 at 03:34:43PM +0200, Alexander Kanavin wrote:
> On Thu, 2 May 2024 at 15:06, Patrick Williams <patrick@stwcx.xyz> wrote:
> 
> > This is almost never correct and there is not a single example of it in
> > poky.  There _are_ examples of exactly what I wrote.
> >
> > If you do `PACKAGECONFIG:class-target:remove` and there is not already
> > an explicit `PACKAGECONFIG:class-target` defined, this in effect creates
> > a _new_ _empty_ variable `PACKAGECONFIG:class-target`.  This is nearly
> > never what you want.  You typically want to take the base contents of
> > `PACAKGECONFIG` and remove something from it explicitly for the
> > `class-target` class.  What I wrote is exactly how to do that and what
> > there are multiple examples of in poky (see tclibc-barmetal.inc,
> > no-gplv3.inc, meta-openembedded uim_1.8.8.bb).
> 
> Right, I just reproduced this. To me this looks like conditions in
> inherit_defer operate on PACKAGECONFIG value that is assembled without
> considering class overrides, and that might be a bug.

Worse is that it seems to always operate on the `class-target`
overrides.  It is as if, at the point that `inherit_defer` evaluates, it
is not known if it is a native or target class and so the default
`CLASSOVERRIDE` from base.bbclass takes precedence over what comes from
native.bbclass.

> 
> How to see the issue:
> PACKAGECONFIG:remove:class-target:pn-btrfs-tools = "python"
> 
> bitbake btrfs-tools-native
> 
> You might be able to work around this by avoiding :remove and setting
> PACKAGECONFIG directly.
> 
> Alex

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [OE-core] btrfs-tools-native build python error
  2024-05-02 13:39                     ` Patrick Williams
@ 2024-05-02 13:50                       ` Richard Purdie
  0 siblings, 0 replies; 14+ messages in thread
From: Richard Purdie @ 2024-05-02 13:50 UTC (permalink / raw
  To: Patrick Williams, Alexander Kanavin
  Cc: Lean Sheng Tan, Ross Burton,
	openembedded-core@lists.openembedded.org, Hansen, Alexander,
	John Chung

On Thu, 2024-05-02 at 08:39 -0500, Patrick Williams wrote:
> On Thu, May 02, 2024 at 03:34:43PM +0200, Alexander Kanavin wrote:
> > On Thu, 2 May 2024 at 15:06, Patrick Williams <patrick@stwcx.xyz> wrote:
> > 
> > > This is almost never correct and there is not a single example of it in
> > > poky.  There _are_ examples of exactly what I wrote.
> > > 
> > > If you do `PACKAGECONFIG:class-target:remove` and there is not already
> > > an explicit `PACKAGECONFIG:class-target` defined, this in effect creates
> > > a _new_ _empty_ variable `PACKAGECONFIG:class-target`.  This is nearly
> > > never what you want.  You typically want to take the base contents of
> > > `PACAKGECONFIG` and remove something from it explicitly for the
> > > `class-target` class.  What I wrote is exactly how to do that and what
> > > there are multiple examples of in poky (see tclibc-barmetal.inc,
> > > no-gplv3.inc, meta-openembedded uim_1.8.8.bb).
> > 
> > Right, I just reproduced this. To me this looks like conditions in
> > inherit_defer operate on PACKAGECONFIG value that is assembled without
> > considering class overrides, and that might be a bug.
> 
> Worse is that it seems to always operate on the `class-target`
> overrides.  It is as if, at the point that `inherit_defer` evaluates, it
> is not known if it is a native or target class and so the default
> `CLASSOVERRIDE` from base.bbclass takes precedence over what comes from
> native.bbclass.
> 
> > 
> > How to see the issue:
> > PACKAGECONFIG:remove:class-target:pn-btrfs-tools = "python"
> > 
> > bitbake btrfs-tools-native
> > 
> > You might be able to work around this by avoiding :remove and setting
> > PACKAGECONFIG directly.

It is an ordering issue.

The trouble is that class-native comes from native.bbclass which is a
BBCLASSEXTEND. The class extension code happens right at the end of
parsing (for obvious reasons) and this is after inherit_defer is
evaluated.

So it is a rather horrible side effect of how the class overrides work.
Sadly inline python like this is difficult to defer indefinitely and is
why immediate expansion is generall painful and a bad idea :(

I'm not entirely sure we can fix that.

Cheers,

Richard







^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2024-05-02 13:50 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <CAMWxwJ0znPDyQAKAwv8PL9GwyCCEpW9+2SDmXsygNyK26_xF-A@mail.gmail.com>
2024-04-25 12:29 ` btrfs-tools-native build python error Lean Sheng Tan
2024-04-25 16:33   ` [OE-core] " Ross Burton
2024-04-25 16:45     ` Lean Sheng Tan
     [not found]     ` <17C993B983870D20.19690@lists.openembedded.org>
2024-04-25 17:40       ` Lean Sheng Tan
2024-05-01 21:27         ` Patrick Williams
2024-05-02  9:28           ` Alexander Kanavin
2024-05-02 12:52             ` Patrick Williams
2024-05-02 12:57               ` Alexander Kanavin
2024-05-02 13:01                 ` Alexander Kanavin
2024-05-02 13:06                 ` Patrick Williams
2024-05-02 13:34                   ` Alexander Kanavin
2024-05-02 13:39                     ` Patrick Williams
2024-05-02 13:50                       ` Richard Purdie
2024-05-02 13:34                 ` Patrick Williams

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.