[chirp_devel] chirp status in Fedora 31
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:
1) 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.
2) 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.
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
Ideally a Python 3 port can happen at some point, but until it does, flatpak/snap will probably be better distribution channels.
This. :)
I did a little experimenting with a chirp snap a long while back, but nothing worth keeping. I still have on my winter todo list to look at such a formal integration with the existing build process.
--Dan
----- Original Message -----
Ideally a Python 3 port can happen at some point, but until it does, flatpak/snap will probably be better distribution channels.
What's the problem with the Python 3 port? I think it's the only correct approach worth the time investment, because Python 2 will be unsupported/unmaintained soon and sticking with the unmaintained interpreter/libraries will lead to even more problems over time.
I ported myself more than 10 packages to Python 3 for Fedora including kernel perf tools. I think I could help with the port in case you accept such patches
thanks & regards
Jaroslav
participants (4)
-
Dan Smith -
Jaroslav Skarvada -
Jim Lieb -
Nolan Darilek