Another option is to use a containerized app delivery mechanism like flatpak. Then you can pin to a runtime containing Python 2, build the app, and not mix app artifacts/dependencies with those on your system.
I have such a build here. Note that it hasn't been updated in a while, and I'd recommend building it locally vs. installing from the flatpak repo which may no longer work:
https://gitlab.com/ndarilek/chirp
Unfortunately I don't think Flathub wants non-versioned builds, which is why I never contributed it there. It may also be possible to automate the builds, but I gave up on that. Happy to accept contributions from anyone willing to take this work further. Alternatively, maybe it can be integrated into CHIRP's own build infrastructure? Ideally a Python 3 port can happen at some point, but until it does, flatpak/snap will probably be better distribution channels.
On 11/18/19 2:36 PM, Jim Lieb via chirp_devel wrote:
I upgraded one of my desktops from F30 -> F31 last night. The system upgrade downloader refused because dependencies for chirp were no longer present. In order to continue the upgrade, I first removed chirp.
After the upgrade I then attempted to (re)install chirp and found that it is not in the F31 repositories. A little research found chirp stuck in the update queue. In other words, it didn't make the gate for F31 release and will continue to have problems due to its dependence on Python 2.
The following is the most recent testing log output of the Fedora build system:
.... cut here ....
results:
- arch: x86_64
checkname: dist.rpmdeplint item: chirp-20190812-1.fc31 outcome: FAILED scenario: x86_64 type: koji_build
conflicting requests: nothing provides python2dist(future) needed by chirp-20190812-1.fc31.noarch conflicting requests: nothing provides python2dist(future) needed by chirp-20190812-1.fc31.noarch
.... cut here ....
This is a failure for both the x86_64 and armhfp builds. Package python2dist has been dropped as part of the Py2->3 changes as best as I can see. This leaves two choices:
- The packager (hobbes1069) changes the build to use what is left of Py2 in
Fedora. This is chancy because Python on Linux/UNIX is not friendly to mixing system objects and local (user built) objects. Not to mention that Py2 is an upstream zombie at this point.
- Chirp gets a Py3 workover so it can fit into the new universe. I know there
has been some Py3 effort but I see nothing (yet) in the Hg repo.
Note that this would also be a problem for a private build from source as there is no Py2 infrastructure left in the distro, meaning one would have to do a whole Py2 local install (/usr/local) and then hack bits so that chirp uses that while not breaking system "stuff" base on Py3 such as dnf, the package installer.
I have also attached the latest relevant Python 2 email from the Fedora team. This relates to the FTBFS message above.
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers