I have filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=14638 to capture and track this necessary change. Konrad, you don't seem to have a BZ account? so I couldn't CC you.

As most of you are now aware, Python 3.10 deprecated the use of distutils, with removal in 3.12 (~Octover 2023). https://bugzilla.yoctoproject.org/show_bug.cgi?id=14610 I have begun a branch to

I agree. The argument against is that having things outside python-core (CPython) allows for a more nimble, agile development process. But this feels like it assumes that there are infinite developers

Thank you for the list, this helps immensely. Perhaps we should start a Wiki to capture these. This good news is typing_extensions uses flit_core, so there will be a path soon. This gives me more

As of now I think the most viable solution would be if setuptools and all that toml parsing stuff would be moved into python-core, but I have no idea if that is somehow on the python upstream's

In the things that I maintain I so far came across javaproperties -> using setup.cfg jsonschema -> using setup.cfg tomli -> same typing_extensions -> using just pyproject.toml for the first ones I

Can you list some examples, so we can start a todo list? I have come across one or two, but it is difficult to search for them. It would really help me to have some test cases. (I have a similar issue

I believe the commit log in [2] clearly explains why it is done in such a hacky way due to a circular dependency. Since OpenEmbedded is not alone here and other source distros are having similar

Hi all, recently more and more python module (preferably downloaded from pypi) do not contain a setup.py anymore. I remember there were attempts to use https://github.com/pypa/build instead, but to

That version had a bug, needed: -if argv[1][0] == '--': +if argv[1].startswith('--'): I've attached an updated version of the patch. Jacob

Here is a slightly more intelligent version, based on top of your patch that adjusts BUILD_RANLIB. It should hopefully handle the meson breakage. Jacob

this patch is fine, and perhaps should be submitted to gcc mailing list regardless. wrappers seems least intrusive and perhaps wholesome at this point without many downsides. So I would suggest we

wrote: FWIW the above breaks meson which tries to run "ar D--version" after the above change. The intercept script is going to have to be a little more "clever" :/ Cheers, Richard

I think this would be something really useful to fix. For ranlib, we can probably just patch BUILD_RANLIB to add the flag. For ar, we need to remove the u option so it can only really be done with an

I've attached an oe-core patch that adds the wrappers above to native and cross builds. Jacob

We also clearly need to extend automated reproducibility testing to native recipes - I’ll look into that. It’s fine to have core items in repro exception list, we just need to know what they

Hi, Some days ago there was a patch in OE-Core that updated the Upstream-Status tags in a couple of the gcc patches. I figured this wouldn't cause too much of rebuilding thanks to hashequiv, but it

There will be an OpenEmbedded Developer Virtual Meeting (OEDVM) held on Friday, 03 December 2021. This will be the day after the Yocto Project® Summit 2021.11 concludes. The scheduled time will

Er, yes. What was I thinking exactly? :) Anyway, you all knew what I meant! I think anything with two or more such operators should just error as that has never been supported and shouldn't/couldn't

But this 2nd example is what might be difficult to spot and most likely needs the leading space as well, right? Especially when there is some override like VAR2:append:machine-foo:distro-foo =