Bug #7877
closedPython3 syntax errors
0%
Description
Hi,
we are trying to return chirp back to fedora (it was removed together with the python2, so Fedora 32 is now without chirp). I packaged the py3 branch and created Fedora review request for it [1]. During the Fedora build process all the python sources are compiled, which revealed some syntax errors. I fixed them (all the fixes should be python-2.7 compatible). I will post the patch to the mailing list. I opened this bug as a tracking bug according to the DevelopersProcess.
Related issues
Updated by Bernhard Hailer almost 4 years ago
- Status changed from New to Feedback
- Platform changed from Windows to Linux
Some first feedback: Chirp currently depends on Python 2.7 (it uses PyGTK).
We are working on a port, but also on ways to package Python 2.7 inside Chirp for short term.
Thanks for your work!
Updated by Jaroslav Škarvada almost 4 years ago
Bernhard Hailer wrote:
Some first feedback: Chirp currently depends on Python 2.7 (it uses PyGTK).
We are working on a port, but also on ways to package Python 2.7 inside Chirp for short term.
Thanks for your work!
Thanks for info.
This is patch for the port (i.e. the py3 branch).
It seems that py3 chirp version can use gtk2 through the gobject introspection - this is unsupported from GTK upstream, but it could work for Fedora in short term (we still have gtk2 in the Fedora rawhide IMHO).
It seems there is also the WX version of the GUI in the py3 branch, which I didn't test much, but at least it started and seems it's somehow usable in Fedora rawhide (at least).
Unfortunately we cannot use chirp with bundled python2 interpreter - I think no distro can use it for downstream packaging, so this wouldn't help distro packagers. Even people installing chirp themselves side of the distro's repos would take risk about possible security vulnerabilities in the unmaintained interpreter.
Updated by Dan Smith almost 4 years ago
- Status changed from Feedback to Rejected
Jaroslav, I can't apply your patch, which seems to have been auto-translated to py3 syntax. The problem is that the syntax is far from the biggest problem in converting these drivers. Just because they're importable after the conversion, doesn't mean they actually work. In the best case, they crash with byte/string issues, and at worst they work enough to put a radio into program mode and then fail, which might cause the radio to reset its memory or worse. The drivers that are importable now are those that I have hand-converted and tested. The effort to do so is quite non-trivial.
I would appreciate if you not package anything from the py3 branch at this point, just because it's in such a half-working state. The wx UI is what I plan to move to at some point, but it's far from usable by regular people, IMHO. I've been trying to do my new driver development with it and there are a number of issues still, aside from all the missing features. The normal gtk UI in compatibility mode also seems to work, but has been very unstable in my experience and there are plenty of things in it that are also not compatible, causing weird crashes or hangs.
I know it's not a great situation, but the distro's decision to remove python2 on principle has made it what it is. I'm going to close this as invalid for clarity (since it's not just syntax that is the problem) and say it duplicates #495, which is the issue I've been using to track py3 work.
Updated by Jaroslav Škarvada almost 4 years ago
OK, understood.
From the list of drivers with syntax errors I own the UV3R. I will test it and fix runtime errors I will encounter. I will post new patch for it.
FYI regarding the current py3 tip I was able to successfully program my UV5R radio with it.