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
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198887): https://lists.openembedded.org/g/openembedded-core/message/198887 Mute This Topic: https://lists.openembedded.org/mt/105729019/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
