python 2 deprecation - assistance required
patrick at stwcx.xyz
Thu Feb 27 09:05:25 AEDT 2020
Brad (and everyone else),
Wanted to give an update on the sdbusplus conversion to python3. There
are lots of issues I've solved already that I want to give visibility to
as others are doing similar conversions. Also, there 7 recipes with bad
dependencies that break when sdbusplus moves to python3 because they
previous got their dependencies indirectly from sdbusplus; these need to
be fixed before we can complete the move.
* All of the code is done in sdbusplus and ready for merge, but I am
holding off on merging it until we are good to go on openbmc/openbmc.
* The recipes for meta-phosphor are available to convert sdbusplus to
I will update this commit once we are ready to merge 29055 with the
SRCREV update instead of a patch file.
* The recipe changes at 29692 fails to build the complete
openbmc/openbmc due to problems in other recipes. Many recipes
assumed they were getting their "python requirements" indirectly from
sdbusplus (which is bad). When I change sdbusplus to use python3, but
those recipes still expect python2 (and modules) they fail to build.
I ran with 'bitbake obmc-phosphor-image -k' and find the following
I'm not going to have time to fix all of these myself, so it would be
nice if the maintainers of each of these repositories would fix up
their dependencies in the Yocto recipe.
Often this means something like DEPENDS += "python-native python-yaml"
* I'm seeing a regular failure with python3 and build systems like
meson, which OE has also observed. For some reason even if we DEPEND
on "python-native" or "python3-native" meson cannot find the
setuptools module correctly. We have to also DEPEND on "python" (the
non-native variant). Since we don't actually install python anymore,
it doesn't make sense that we have to DEPEND on it either because that
means we are building a big target package for no reason.
Maybe someone could tackle this with upstream rather than us having to
piecemeal every recipe.
* python3-setuptools does some funny mangling of our shebang's when we
use setuptools to install a python script. OE's distutils3.bbclass
takes care of this, but often we have some hybrid autotools/setuptools
repository so we cannot use this bbclass. I've added a workaround
If you are using another build system (or not using this bbclass) you
might also run into this with other recipes. I suspect, since we
aren't using python-on-target anymore, this only affects -native
packages, which might only ever be sdbus++?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the openbmc