Description of problem: /usr/share/aclocal-1.11/python.m4 contains a definition of AM_PATH_PYTHON which encapsulates the configuration magic for building an extension module against one version of python. I'm working towards packaging a secondary Python 3 stack in Fedora (see https://fedoraproject.org/wiki/Features/Python3F13 ), intended to be parallel-installable with the primary Python 2.6 stack, and this means that for various library packages I'll want to configure them to build python against both Python 2 and Python 3. I'm about to attach a hacked-up version of python.m4 as python3.m4, which defines an AM_PATH_PYTHON3 macro. I'm using this in my version of rpm's configure.ac in order to configure rpm to build two sets of python bindings, one for /usr/bin/python, the other for /usr/bin/python3 (see bug 531543) (Note that I have to manually delete a couple of cache entries, to avoid AC_CACHE_CHECK from picking up the cached 2.6 Python.h when testing for the 3.1 Python.h, similarly for the libs) Version-Release number of selected component (if applicable): automake-1.11-2.fc11.noarch
Created attachment 368273 [details] Hacked up python3.m4, from python.m4, defining an AM_PATH_PYTHON3
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Does this look sane? Note that python3 is now available in rawhide: http://lists.fedoraproject.org/pipermail/devel/2010-January/129185.html
Have you had a chance to look at this?
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm not sure if my patch is correct, but I'm increasingly trying to support building Python extensions against multiple python runtimes within a single rpm build - we have two python runtimes in Fedora 13: python 2, python 3, and in Fedora 14 I want to double this by adding debug builds of these that add lots of useful reference tracking, but change ABI, giving four python configurations. Each has a different path for its include files and a different DSO to link against. So is there a sane way to do this kind of thing within the autotools, and from within an rpmbuild?
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Ping?
Still appears to be a problem with /usr/share/aclocal-1.7/python.m4 in automake17-1.7.9-15.fc17.1.noarch
Created attachment 621351 [details] Example with double environments Hello Dave, I see several possible solutions: 1. in your case is the cleaning of cashed variables quite good solution .. because this situation appears like unusual case 2. disable cashing of variables inside python.m4 3. add your python3.m4 script (seem like strongly non-upstream-able due to code duplicities) 4. fix python.m4 and its AM_PATH_PYTHON macro to allow client to build against multiple python environments (which looks like upstream-able solution if the fix does not break existing applications). Do you think this feature would be suitable also for automake upstream? It seems like it could be usable outside of Fedora but I'm not a python-plugin developer so I can not say .. How this is done on other systems now? I'm attaching simple patched python.m4 with an example for the (4) case, what do you think about it? Usage would be something like that: AM_PATH_PYTHON([2.7],,,2) AM_PATH_PYTHON([3.0],,,3) Thanks, Pavel
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Would be nice to have this one as more packages are adding python3 support.
I would like to look at this once more; could somebody point me to packages dealing with this topic? Some package installing both python3 & python2 stuff and using automake's AM_PATH_PYTHON.
Hi Pavel, abrt uses AM_PATH_PYTHON - https://github.com/abrt/abrt/blob/master/configure.ac (line 59).
(In reply to Jakub Filak from comment #14) > Hi Pavel, abrt uses AM_PATH_PYTHON - > https://github.com/abrt/abrt/blob/master/configure.ac (line 59). Thanks, Jakube! I tried propose concept: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17811 The bad news about this patch is that we can not apply that downstream only, and even if upstream will fix that, we will still need to wait for official upstream release (packages distributed with this feature may be re-autoreconfed only with capable automake). Still not sure what I should advice to packagers in general. I'll think about some general downstream solution.
Testing build: $ sudo yum install http://copr-be.cloud.fedoraproject.org/results/praiskup/scrach-builds/fedora-rawhide-x86_64/automake-1.14.1-5.fc20%7epreview/automake-1.14.1-5.fc21%7epreview.noarch.rpm
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Python2 is EOL'ed, shortly.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
We currently do not support python2 anymore in Fedora and moving forward to python3, closing this issue. If you consider this to be investigated, please feel free to reopen it.
RHEL7 (and EPEL7) still provide support for python2 till finally EOL'ed somewhen in 2024 or later. We should keep this bug as relevant, especially for several known c++ legacy with python bindings. No idea about version for automake though and python 2.7 is officially EOL since 2020-01-01. Let's give it another chance.
Raphael, what is your expectation about this bugzilla? What do you actually hope to achieve here?
Miro, is this tutorial outdated with python 2 in samples? https://www.gnu.org/software/automake/manual/html_node/Python.html Someone tries actually to build rrdtool via autotools and fails due to incompatibilities with python 3.10 . https://issueexplorer.com/issue/oetiker/rrdtool-1.x/1135
How could the Fedora automake package fix either of these?
Upstream first, the patch was already proposed so perhaps that needs a revamp or just a ping.
Considering this bug is open for Fedora, and since python2 isn't supported any longer, this bug will be closed. If it happens that this problem shows up to be blocking any build in RHEL, then a corresponding bug should be open against RHEL. From the current perspective, the effort to fix this issue would be too high in regard of any benefit that could be expected.