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 python-volatility'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 python-volatility. 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.
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.
According to the procedure described in https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages the package was now orphaned. If you think it was a mistake, you can provide the answers and claim the package back. Let us know if you need any help or just need more time.
Hello, I would like to claim the volatility package. >- 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?) Software is written in python2 and is not working yet on python3. >- What are the upstream/community plans/timelines regarding Python 3? Upstream claims to be working on python3 support ( https://github.com/volatilityfoundation/volatility/issues/471 ), but I have not seen any progress within last year (https://github.com/volatilityfoundation/volatility/issues/155). Most recent issue on github is this one: https://github.com/volatilityfoundation/volatility/issues/598 > 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?) Package is forensics framework for dissecting and parsing binary structures in the memory dumps. A lot of stuff depends on how the string used to work in python2 and logic will have to be rewritten to python3 binary arrays. Best regards Michal Ambroz
Well, it seems that the upstream is not active. Do you plan to port this package or request an exception?
No response from the upstream in the most recent issue. It seems that the upstream has no tests so the porting won't be easy. Do you have any plans?
I've talked to Michal during LinuxDays in Prague. I think the best course of action here is to request an exception to keep this. It only depends on python2-setuptools and python2-crypto. The dependency on setuptools seems to be optional (although removing it might result in .egg-info becoming a regular file that replaces a directory, so I'd only remove it if no other package requests an exception for setuptools).
Just get an exception for python2-setuptools? It already has a separate python2 SRPM; keeping it alive might be less work than ripping it out. And it's a build-only dependency here.
Michale, what is your plan, please?
> Michale, what is your plan, please? If possible I would like to keep the package for now as it is. It is currenlty working only in python2 at the moment and it is certainly giving the value as it is. I will hope that the upstream will start migrating to python3, but so far I have not seen any significant movement to that. Michal Ambroz
(In reply to Michal Ambroz from comment #13) > > Michale, what is your plan, please? > If possible I would like to keep the package for now as it is. > It is currenlty working only in python2 at the moment and it is certainly > giving the value as it is. Then, you have one month and one day to request a fesco exception (for example: https://pagure.io/fesco/issue/2243). Let us know if you need any help.
Fesco request raised as https://pagure.io/fesco/issue/2247
Created attachment 1629346 [details] Spec file for volatility3 Here's an attached specfile for volatility3 that can be packaged in addition to volatility but replaces it on F32+. It has a new license, so I've asked at https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/OHECHDPLDJ7LLFUZXQMBBAXEXYTQMXOR/
Thank you Miro for the SPEC, its more that I would be hoping for. Submitting the package review reuqest for it. Would you consider the python2-pycrypto -> pycryptodomex patch resulting from the fesco review to be worth of updating the packages in supported releases to reduce the dependecy on unsupported python2-pycrypto?
(In reply to Michal Ambroz from comment #17) > Would you consider the python2-pycrypto -> pycryptodomex patch resulting > from the fesco review to be worth of updating the packages in supported > releases to reduce the dependecy on unsupported python2-pycrypto? I don't have a strong opinion. Whatever works for you. Several observations: - there are other packages depending on pycrypto - pycrypto cannot be removed from Fedora 31 anyway (too late) - the pycrypto maintainer at least seems responsive, unlike the pycryptodomex one
*** This bug has been marked as a duplicate of bug 1775092 ***