Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1738053 - pdf-stapler depends on Python 2
Summary: pdf-stapler depends on Python 2
Keywords:
Status: CLOSED DUPLICATE of bug 1518829
Alias: None
Product: Fedora
Classification: Fedora
Component: pdf-stapler
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ranjan Maitra
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1606418 (view as bug list)
Depends On: 1518829
Blocks: F29FTBFS F31_PY2REMOVAL
TreeView+ depends on / blocked
 
Reported: 2019-08-06 12:44 UTC by Lumír Balhar
Modified: 2019-11-17 09:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-17 09:33:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github hellerbarde stapler issues 54 0 'None' 'open' 'Needs python3 support for Fedora 31' 2020-03-19 07:13:11 UTC
Github hellerbarde stapler pull 55 0 'None' 'open' 'Python 3 compatibility, new tests and tox configuration for stapler' 2020-03-19 07:13:11 UTC

Description Lumír Balhar 2019-08-06 12:44:29 UTC
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.

Comment 1 Ben Cotton 2019-08-13 16:56:11 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 2 Ben Cotton 2019-08-13 17:04:22 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 3 Raphael Groner 2019-08-13 17:12:25 UTC
There's curently no official support from upstream.

Comment 4 Lumír Balhar 2019-08-21 13:27:31 UTC
Do you have any plan to support Python 3 downstream?

Comment 5 Lumír Balhar 2019-08-29 05:30:15 UTC
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.

Comment 6 Lumír Balhar 2019-09-05 10:42:23 UTC
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.

Comment 7 Raphael Groner 2019-09-05 10:56:13 UTC
> If you need any information or help, or if you need some more time, please let us know.

WBU, no.

Comment 8 Ranjan Maitra 2019-09-06 16:57:26 UTC
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.

Comment 9 Raphael Groner 2019-09-08 20:31:11 UTC
> 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.

Comment 10 Lumír Balhar 2019-09-16 18:49:26 UTC
What is your plan? This package can be orphaned/retired if you don't want to maintain it anymore.

Comment 11 Raphael Groner 2019-09-17 07:25:00 UTC
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.

Comment 12 Lumír Balhar 2019-09-17 09:42:56 UTC
Then, please, orphan/retire it as soon as possible.

Comment 13 Raphael Groner 2019-09-17 09:58:55 UTC
(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.

Comment 14 Raphael Groner 2019-09-17 14:48:44 UTC
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

Comment 15 Lumír Balhar 2019-09-26 06:47:23 UTC
I am going to take a look at how hard it would be to make this Python 3 compatible.

Comment 16 Lumír Balhar 2019-09-26 08:00:31 UTC
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?

Comment 17 Lumír Balhar 2019-09-26 08:00:55 UTC
PR: https://github.com/hellerbarde/stapler/pull/55

Comment 18 Lumír Balhar 2019-10-03 09:29:11 UTC
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

Comment 19 Ranjan Maitra 2019-10-03 19:08:16 UTC
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.

Comment 20 Petr Viktorin (pviktori) 2019-10-16 15:20:17 UTC
Looks like there is no response upstream.

Comment 21 Ranjan Maitra 2019-10-16 16:56:49 UTC
(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.

Comment 22 Lumír Balhar 2019-10-17 07:57:50 UTC
> 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.

Comment 23 Petr Viktorin (pviktori) 2019-10-17 14:20:40 UTC
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.

Comment 24 Raphael Groner 2019-11-17 09:33:27 UTC
Taking this in bug #1518829.

*** This bug has been marked as a duplicate of bug 1518829 ***

Comment 25 Raphael Groner 2019-11-17 09:33:58 UTC
*** Bug 1606418 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.