Upstream, this software supports Python 3. Please provide a Python 3 package for Fedora. According to the Python packaging guidelines [0], software must be packaged for Python 3 if upstream supports it. The guidelines give detailed information on how to do this, and even provide an example spec file [1]. The current best practice is to provide subpackages for the two Python versions (called "Common SRPM" in the guidelines). Alternatively, if nothing depends on your Python2 package, you can just switch to Python 3 entirely. It's ok to do this in Rawhide only, however, it would be greatly appreciated if you could push it to Fedora 24 as well. If anything is unclear, or if you need any kind of assistance with the porting, you can ask on IRC (#fedora-python on Freenode), or reply here. We'll be happy to help! [0] https://fedoraproject.org/wiki/Packaging:Python [1] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
Hello Greg, Do you need any help adding Python 3 support to the RPM? If you need more instructions, a [guide] for porting Python-based RPMs is available. [guide] http://python-rpm-porting.readthedocs.org/en/latest/index.html
(In reply to Tomas Orsava from comment #0) > Upstream, this software supports Python 3. Please provide a Python 3 > package for Fedora. I'm not sure that's completely true: $ python3 /usr/bin/git-restore-mtime Traceback (most recent call last): File "/usr/bin/git-restore-mtime", line 165, in <module> lsfileslist.add(os.path.relpath(line.strip(), workdir)) File "/usr/lib64/python3.4/posixpath.py", line 448, in relpath start_list = [x for x in abspath(start).split(sep) if x] TypeError: Can't convert 'bytes' object to str implicitly There's an upstream pull request related to Python 3: https://github.com/MestreLion/git-tools/pull/16 Also, in case it's not clear, this package contains python scripts, but does not contain a python module for end user consumption. So my understanding is that the only thing to adjust would be the "Requires" tag to require "python3" (or equivalent) on Fedora once git-tools runs properly on python 3.
Submitted upstream issue in github: https://github.com/MestreLion/git-tools/issues/23
My apologies, I must have made a mistake. Hopefully upstream gets it ported soon. Thank you for your time!
(In reply to Tomas Orsava from comment #4) > My apologies, I must have made a mistake. Hopefully upstream gets it ported > soon. > > Thank you for your time! No problem, and thanks for the helpful information in the original bug report!
(In reply to Greg Bailey from comment #2) > Also, in case it's not clear, this package contains python scripts, but does > not contain a python module for end user consumption. So my understanding > is that the only thing to adjust would be the "Requires" tag to require > "python3" (or equivalent) on Fedora once git-tools runs properly on python 3. You'll also need to change the shebangs to: #!/usr/bin/python3 Otherwise the scripts will still be run by Python 2. Once done, you can safely remove the python require and no need to depend explicitly on python3 as RPM will list /usr/bin/python3 as a dependency automagically. (Also, I'm reopening this, as CLOSED UPSTREAM would mean this is fixed upstream, which is not the case).
> (Also, I'm reopening this, as CLOSED UPSTREAM would mean this is fixed > upstream, which is not the case). If you click the text "Status:" next to the drop down menu with resolutions, you'll get to a page describing them. This is what they list CLOSED-UPSTREAM being for: "The problem described has been filed in an upstream bug tracker or reported to the upstream mailing list. This typically includes almost all feature requests and enhancements, and most bugs that we don't consider release showstoppers. (Moving bugs upstream typically increases the chance that someone will have time to look at it, and often the upstream developer or bug owner even works at Red Hat. Moving bugs upstream simply allows us to keep everything in one place, and work better with open source community developers outside of Red Hat. We only keep bugs open on redhat.com to track our immediate short-term items, or issues with our patches and/or packaging, or because the upstream package in question has poor bug tracking. The main focus of development for most packages is the upstream community, even when Red Hat is a big contributor to the community.) Some upstream bug trackers include http://bugzilla.gnome.org, http://bugs.kde.org, and http://bugzilla.mozilla.org. This resolution should not be used for Red Hat Enterprise Linux bugs." Therefore I think we should again close this as CLOSED-UPSTREAM, should we not?
Oh, I'm deeply sorry, I always understood it differently, never clicked that link. My bad, sorry for the unnecessary noise.