Python 2.7 will reach end-of-life in January 2020, over 9 years after it was released. This falls within the Fedora 31 lifetime. Packages that depend on Python 2 are being switched to Python 3 or removed from Fedora: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages Python 2 will be retired in Fedora 32: https://fedoraproject.org/wiki/Changes/RetirePython2 To help planning, we'd like to know the plans for pdf-stapler's future. Specifically: - What is the reason for the Python2 dependency? (Is it software written in Python, or does it just provide Python bindings, or use Python in the build system or test runner?) - What are the upstream/community plans/timelines regarding Python 3? - What is the guidance for porting to Python 3? (Assuming that there is someone who generally knows how to port to Python 3, but doesn't know anything about the particular package, what are the next steps to take?) This bug is filed semi-automatically, and might not have all the context specific to pdf-stapler. If you need anything from us, or something is unclear, please mention it here. Thank you.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
There's curently no official support from upstream.
Do you have any plan to support Python 3 downstream?
Please answer the above questions. If you don't, the package can be orphaned: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages If you need any information or help, or if you need some more time, please let us know.
> If you need any information or help, or if you need some more time, please let us know. WBU, no.
I am the original packager. It is very unlikely that upstream will wake up to fixing this issue. I considered rewriting the python2 code in python3 (and perhaps renaming the project because the maintainer is unresponsive) but found that most of the functionality is supported in poppler-utils (at least whatever I need anyway). Is there anything that pdf-stapler provides that is not provided by pdfunite pdfseparate pdfdetach in poppler-utils. Hopefully poppler-utils is not itself on the chopping block.
> I considered rewriting the python2 code in python3 (and perhaps renaming the project because the maintainer is unresponsive) What does that mean exactly? There are at least two options: 1. Fork the code at upstream (on GitHub) and try to send a pull request. No need to rename the project. Be aware of depending bug #1518829 introducing availability of a new version from upstream. That said, upstream is not fully inactive and could get moved to add support for python3. 2. Retire the project due to dead upstream. For option#2 there's no need to do anything because this bug will be handled automagically considered to a dead package then.
What is your plan? This package can be orphaned/retired if you don't want to maintain it anymore.
As mentioned in the other depending bug #1518829, as a co-maintainer I'm not interested in continuation of a python2 package. Upstream currently supports py2 only.
Then, please, orphan/retire it as soon as possible.
(In reply to Lumír Balhar from comment #12) > Then, please, orphan/retire it as soon as possible. I can't command the orphan/retire action because of commit ACL. It has to be done by an admin.
My suggestion is to wait for a new official release done by upstream or let's try to build from a git snapshot as mentioned with python3 support in the issue. https://github.com/hellerbarde/stapler/issues/54
I am going to take a look at how hard it would be to make this Python 3 compatible.
I've managed to port it to Python 3 compatible form. It was pretty easy and the patch is not big so if the upstream rejects it and/or don't do a new release, we can maintain it in RPM for a while. Could you please try to prepare a new spec with this patch?
PR: https://github.com/hellerbarde/stapler/pull/55
The plan here is kinda straightforward so please don't forget to update the package even the upstream won't merge the PR and/or do a new release. The current plan is to remove packages with dependency on Python 2 from Fedora 32 in the middle of November 2019. If you want to keep your package in Fedora after that date and you cannot port it to Python 3 yet, you need to request a FESCo exception for the package and all its Python 2 dependencies (even transitive) [1]. If you don't want to maintain it anymore, and nothing in Fedora uses it, you can retire it or just remove the Python 2 part from it (subpackage, module, bindings, etc.). If you're considering filing the exception request, let us know. We can help (for example, we can help find all the dependencies). [1] https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions
I was waiting to see if upstream would accept the PR for python3 from earlier this week. I will give them another week otherwise do the patch for Fedora 31.
Looks like there is no response upstream.
(In reply to Petr Viktorin from comment #20) > Looks like there is no response upstream. Yes, indeed, as I suspected. (I wrote two personal e-mails earlier to both the maintainer and the original creator of stapler.) I think the package should be forked, perhaps with a new name to avoid conflicts, in case the maintainer wakes up. I will think about what to do about this. We need a resolution soon. Any suggestions welcome.
> I think the package should be forked, perhaps with a new name to avoid > conflicts, in case the maintainer wakes up. If you plan to maintain it and provide some sort of support for it, the fork might be a good way to go. But the patch I provided upstream is not that big so it might also make sense to use it downstream and wait for a while what will happen with this tool.
If the patch applied cleanly to the currently packaged version, you could just use it directly as a Fedora patch. But it seems it doesn't. Maybe a fork on GitHub would be the best way to go. I'd advise keeping the old name, since the intention is to merge back as soon as the original upstream becomes active again.
Taking this in bug #1518829. *** This bug has been marked as a duplicate of bug 1518829 ***
*** Bug 1606418 has been marked as a duplicate of this bug. ***