Re: [OE-core] btrfs-tools-native build python error
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 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198924): https://lists.openembedded.org/g/openembedded-core/message/198924 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
On Thu, May 02, 2024 at 03:34:43PM +0200, Alexander Kanavin wrote: > On Thu, 2 May 2024 at 15:06, Patrick Williams 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 signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198923): https://lists.openembedded.org/g/openembedded-core/message/198923 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
On Thu, May 02, 2024 at 02:57:30PM +0200, Alexander Kanavin wrote: > On Thu, 2 May 2024 at 14:52, Patrick Williams 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 signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198922): https://lists.openembedded.org/g/openembedded-core/message/198922 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
On Thu, 2 May 2024 at 15:06, Patrick Williams 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198921): https://lists.openembedded.org/g/openembedded-core/message/198921 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
On Thu, May 02, 2024 at 02:57:30PM +0200, Alexander Kanavin wrote: > On Thu, 2 May 2024 at 14:52, Patrick Williams 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 signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198919): https://lists.openembedded.org/g/openembedded-core/message/198919 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
On Thu, 2 May 2024 at 14:57, Alexander Kanavin 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198918): https://lists.openembedded.org/g/openembedded-core/message/198918 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
On Thu, 2 May 2024 at 14:52, Patrick Williams 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198917): https://lists.openembedded.org/g/openembedded-core/message/198917 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
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 > 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 signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198915): https://lists.openembedded.org/g/openembedded-core/message/198915 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
On Wed, 1 May 2024 at 23:27, Patrick Williams via 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198906): https://lists.openembedded.org/g/openembedded-core/message/198906 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
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
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 wrote:
>
>> On 25 Apr 2024, at 13:29, Sheng Lean Tan via 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 (#198707):
https://lists.openembedded.org/g/openembedded-core/message/198707
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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] btrfs-tools-native build python error
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 wrote:
> On 25 Apr 2024, at 13:29, Sheng Lean Tan via 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/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] btrfs-tools-native build python error
On 25 Apr 2024, at 13:29, Sheng Lean Tan via 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 (#198705):
https://lists.openembedded.org/g/openembedded-core/message/198705
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]
-=-=-=-=-=-=-=-=-=-=-=-
