ptool uses host-python, failing on hosts without python2

[jluebbe]

On systems where only python3 is installed, image creation fails with: …/build-qcom-wayland/tmp-glibc/work/qcm6490-qcom-linux/gen-partition-bins/1.0-r0/temp/run.do_compile.121105: 142: …/build-qcom-wayland/tmp-glibc/work/qcm6490-qcom-linux/gen-partition-bins/1.0-r0/recipe-sysroot-native/usr/bin/ptool.py: not found.

This is cause by the hard-coded #! line:

$ head -1 …/build-qcom-wayland/tmp-glibc/work/qcm6490-qcom-linux/gen-partition-bins/1.0-r0/recipe-sysroot-native/usr/bin/ptool.py
#!/usr/bin/python

It should probably be #!/usr/bin/env python3 instead so that the python3 binary from the sysroot is used.

[FantomJAC]

gen_partition.py has the similar issue too. My proposal is to rather modify recipe to force using Python from sysroot (which is recommended by Poky).

diff --git a/recipes-devtools/partition-utils/gen-partition-bins_1.0.bb b/recipes-devtools/partition-utils/gen-partition-bins_1.0.bb
index da88927..dbd24f3 100644
--- a/recipes-devtools/partition-utils/gen-partition-bins_1.0.bb
+++ b/recipes-devtools/partition-utils/gen-partition-bins_1.0.bb
@@ -12,7 +12,7 @@ do_compile[depends] += " \
    "
 do_compile() {
     # ptool to generate partition bins
-    ${STAGING_BINDIR_NATIVE}/ptool.py -x ${DEPLOY_DIR_IMAGE}/partition.xml
+    ${PYTHON} ${STAGING_BINDIR_NATIVE}/ptool.py -x ${DEPLOY_DIR_IMAGE}/partition.xml
 }

 inherit deploy
diff --git a/recipes-devtools/partition-utils/partition-confs_1.0.bb b/recipes-devtools/partition-utils/partition-confs_1.0.bb
index 349aa72..352afb6 100644
--- a/recipes-devtools/partition-utils/partition-confs_1.0.bb
+++ b/recipes-devtools/partition-utils/partition-confs_1.0.bb
@@ -23,7 +23,7 @@ PARTCONF:qcs9100 = "qcs9100-partitions.conf"

 do_compile() {
     # Generate partition.xml using gen_partition utility
-    ${STAGING_BINDIR_NATIVE}/gen_partition.py \
+    ${PYTHON} ${STAGING_BINDIR_NATIVE}/gen_partition.py \
         -i ${WORKDIR}/${PARTCONF} \
         -o ${B}/${MACHINE}-partition.xml
 }

[jluebbe]

Nevertheless, the tool's #! line should also be fixed.

[FantomJAC]

I don't know if it's a definitive fix. The name of the command can be arbitrary and we should not rely on some particular name, rather the recipe shall follow what Yocto tool set provide - in this case python3native class explicitly provides PYTHON sys env for this particular purpose.

[ricardosalveti]

I think we need to fix both places, so we can cover cases when running the tool manually and also under OE/Yocto (which should indeed use ${PYTHON} as the interpreter.

Thanks for the report and suggestions, let me follow up on this internally to make sure this is included in the next BSP update.

[quaresmajose]

I believe one solution for this will be bring the python3native to provide the yocto python environment

inherit python3native

[FantomJAC]

@quaresmajose You would still need to use ${PYTHON} to invoke python from python3native class.

[ricardosalveti]

The suggested fix was proposed internally, at some point it will reflect into the kirkstone branch.

[quaresmajose]

@quaresmajose You would still need to use ${PYTHON} to invoke python from python3native class.

Yes, we need the two addiction and the proposal fix reflect that.