It smells like something is not linked explicitly to libpython.

Could it be we need to use python-3.X-embed instead?  See also
a similar bug for nbdkit: https://bugzilla.redhat.com/show_bug.cgi?id=1718294

Ignore previous comment.

It looks as if the code shouldn't using using PyImport_Cleanup.  Note
that it is marked as deprecated here:

https://docs.python.org/3/c-api/import.html

I have raised this issue with upstream.

> It looks as if the code shouldn't using using PyImport_Cleanup.

Oh wait, I misread the error "/lib64/libpython3.9.so.1.0 returned Cannot resolve PyImport_Cleanup".

I removed PyImport_Cleanup() from libpython on purpose: you should really not call it.

"The C function PyImport_Cleanup() has been removed. It was documented as: “Empty the module table. For internal use only.” (Contributed by Victor Stinner in bpo-36710.)"

https://docs.python.org/dev/whatsnew/3.9.html#removed

Maybe Coccinelle has a good reason to call it? If yes, I'm open to discuss reverting my change in Python 3.9 :-)

> I have raised this issue with upstream.

Did you open a public issue? I don't see anything at https://github.com/coccinelle/coccinelle/issues

I mentioned it here: https://systeme.lip6.fr/pipermail/cocci/2020-January/006785.html
I did not open a formal bug.

It sounds as if Cocci probably should not be calling this private
API, and if you removed it then you exposed that previously hidden
bug.  Anyway we can see what they say.

This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Still present in coccinelle-1.0.9-0.1.111d328fee1303f14a5b9def835301d849e41331.fc33

I reported the bug upstream: https://github.com/coccinelle/coccinelle/issues/189

I also proposed a fix: https://github.com/coccinelle/coccinelle/pull/190 (not tested)

This comment is mass posted to all bugs blocking the Python 3.9 tracker, sorry if it is not 100 % relevant. When in doubt, please ask.


The Python 3.9 rebuild is in progress in a Koji side tag.

If you fix this bug, please don't rebuild the package in regular rawhide, but do it in the side tag with:

    $ fedpkg build --target=f33-python

The rebuild is progressing slowly and it is possible this package won't have all the required build dependencies yet. If that's the case, please just leave the fix committed and pushed and we will eventually rebuild it for you.

You are not asked to go and try rebuild all the missing dependencies yourself. If you know there is a bootstrap loop in the dependencies, let me know and we can untangle it together.

If you want to test your fix or reproduce the failure, you can still use the Copr repo mentioned in the initial comment of this bug: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/

Note mainly for my own benefit.

This has been fixed upstream:
https://github.com/thierry-martinez/pyml/commit/8b26fdb9f60c3a66b58f2ecc1b2136a833f55612

We probably need to add pyml as a separate BR so that coccinelle stops using the
bundled version, and make sure the fix is in Fedora.

Since this is a complex multi-package fix I think I prefer to wait until Python 3.9
is actually in Rawhide.

Python 3.9 update: The f33-python side tag is currently being merged.

New builds in f33-python are no longer possible, but python3 is not yet updated to Python 3.9 in rawhide. You can check when Python is Python 3.9 with:

    $ koji wait-repo f33-build --build python3.9-3.9.0~b1-3.fc3

And build the packages normally after that.

It turns out that the pyml library isn't packaged in Fedora and we are
carrying the right Bundled tags & exceptions.  I have built the package
in Fedora Rawhide now against Python 3.9.0~b1-4.fc33:

https://koji.fedoraproject.org/koji/taskinfo?taskID=45171978

Thanks for fixing the package!