python-caja fails to build with Python 3.8.0b1.
The build no longer links to libpython, resulting in undefined references to Python API like Py_Initialize.
Code that embeds Python (rather than building an extension module) needs to pass `--embed` to any `python3-config --libs` invocation to build with Python 3.8.
For the build logs, see:
For all our attempts to build python-caja with Python 3.8, see:
Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.8:
Let us know here if you have any questions.
I don't have any idea to fix that because i am not a python programmer. Most of my packages are using C.
Feel free to do a pull request to fix the issue.
Created attachment 1580930 [details]
Fix configure.ac for Python 3.8
@Petr: many thanks for the very detailed problem ino you provide.
@Wolfgang: this is not a Python language problem: only an autoconf/pkg_config one.
The patch should make python-caja buildable with Python 3.8. I tried building (successful), but not executing, thus additional tests should be performed.
i `ve added Patricks patch from upstream to f29/30 and rawhide branches.
So, you guys can switch building to 3.8 if you like.
Note, there are a few packages which depends on python-caja. All not my packages.
Is the patch applied? From the commit it doesn't appear so.
Only added to git for all branches.
I am confused. What good does the patch do in git if it is not applied?
I don`t know when you want to switch to python38 and want to rebuilt all packages.
By the way, i am missing python38-devel package in repos, so it doesn't makes sense to edit spec file for me.
python38-devel is not a thing.
Testing and mass rebuild of packages is happening in copr now, from dist git, against updated python3-devel. The patch seems that it is backwards compatible with 3.7, correct?
> The patch seems that it is backwards compatible with 3.7, correct?
Yes it is. Patch does not do anything bad when building with 3.7 or even lower :-)
are you interested to take over this package as maintainer?
I don't really need it for myself and i don't use any package which depend on it.
This would also help to reduce my work overload to maintain MATE desktop in fedora + Mate upstream work.
And you know much more about python than me :).
I can be a co-maintainer to help you (in Fedora, not in EPEL), but I won't take the primary position.
This can be: when you make a new upstream release available, you alert me so I can package it. When there are BZs for it, I can act.
You keep the hand on the package.
If you want, we can continue this discussion via our private e-mails...
BTW: I did not know much of Python in last December: I'm a good old C guy too!
i added you as co-admin to the package.
FEDORA-2019-428951b756 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-428951b756
we shouldn't use a developer version (1.23.x) for stable branch f30.
I really prefer 1.22 release + a patch.
Can we revoke this update before it is in stable?
Ok , you build it already for rawhide :/
than we can't revoke the build.....'
For the moment i do not push any MATE developer version (1.23.x) to rawhide, because it isn't clear when MATE will release 1.24.
I just want to avoid that a future stable fedora release use unstable developer tarballs.
....i will enable your update again.
> For the moment i do not push any MATE developer version...
Sorry for having done that, I thought it will help. But what is your criterion for stable/developer version ? Is is an even/odd minor version number? Since it is stored on the download server just beside the older versions, it looks like a normal release.
Do we have to follow a global MATE versioning, or are MATE package versions independent from each other?
Also I'm not 100% sure, but i think that, unless rules have changed, we can revoke f29 and f30 even if already in rawhide: the requirement is that versions should be monotonically ascendent within Fedora versions... to be checked!
In any case, I did test 1.23.0 in F29 and rawhide successfully.
Np, you couldn't know that. Even are stable release and odd are developer versions, same like in many other projects, eg. gnome.
> Do we have to follow a global MATE versioning, or are MATE package versions independent from each other?
It depends, some packages depends on other and some new changes needs to be done in several packages together.
So using the same version is better in most cases. And you don't need to think about compatibility ;)
I think for python-caja it doesn't hurt to have another version than other packages.
Beside from python version changes there are no changes. And no package from Mate upstream depends on python-caja. Only a few 3-party applications which i don't use and know very well.
So it is ok for now.
python-caja-1.23.0-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
python-caja-1.23.0-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-67fe748419
python-caja-1.23.0-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.