Bug 249329
| Summary: | comms/chirp: update to 20200213 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Charlie Li <vishwin> | ||||
| Component: | Individual Port(s) | Assignee: | hamradio (Nobody) <hamradio> | ||||
| Status: | Closed Not Accepted | ||||||
| Severity: | Affects Many People | CC: | db, felix, kevans, rene, swills | ||||
| Priority: | --- | Keywords: | patch | ||||
| Version: | Latest | Flags: | vishwin:
maintainer-feedback+
|
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Charlie Li
2020-09-15 10:01:51 UTC
(In reply to Charlie Li from comment #0) Thanks for this! *** Bug 249588 has been marked as a duplicate of this bug. *** Created attachment 218388 [details]
Proposed python3 hack
Try this instead? We could continue to pull the daily builds, then run it through 2to3 (ick) there are still a few python files that need special patching.
I don't have an interface to test with. :-(
There are more than a few files that need special attention after running 2to3. Not only does the py3 branch reflect that, but even my attempts to run under Python 3 on the default branch essentially only gets the first screen of the pygobject-based GUI running; dialogs and radio programming do not work at all. Both branches also have pygtk2-isms that need pruning/refactoring because they don't work under pygobject despite the latter's compatibility "layer"; the import and export dialogs are prime examples of not functional. This is what I mean by our (as in what's in phab) patches not going upstream for now, since there is *that* much work and cleanup to do in the default branch. The wxPython-based GUI is very much still half-baked (and hasn't had much activity since way earlier this year it seems), I would say in an even worse usability state than pygobject. Not to mention that it feels significantly slower. Hey Diane, chirp got removed this morning because we passed the expiration date, would you like to revive it with your python3 fix or should I? No longer blocks 249337 as it was removed on 2020-10-16. Closing as "WONTFIX" for now to shut bugzilla up from sending weekly reminder emails to hamradio@. Because there is no real direction upstream regarding Python 3 (and as a result *multiple* forks exist), there is too much work to be done in order to resurrect this port. Converting much of the non-radio driver code to Python 3, especially the old pygtk2 GUI to use pygobject3 instead, is the easy part. The difficult and not really technical part is how not to break existing driver functionality and to keep up with driver updates. For those less aware, the radio drivers are effectively (mostly) reverse-engineered binary protocols fed into/out of pyserial. They all assume Python 2's string and binary handling; Python 3 does all that differently (Unicode string defaults, etc etc). Automated or guided tooling to convert Python 2 to 3 does not work here; it is an entirely manual effort to analyse the code itself, then either run test suites (if available) or attempt to (re)program physical radios whilst praying that the more expensive radios don't get bricked in the process. The original upstream author and maintainer has stated multiple times that he does not care for Python 3 support, especially when flatpaks exist. Obviously flatpak is not an option here, but even when they are, every couple months someone (naively) asks about Python 3 support on the mailing list, and the cycle repeats itself with no real results (other than maybe more forks). If anyone would like to *actively* work on this, feel free to comment or reopen, but be sure to show receipts. Note that the effort required will amount to at least two days nonstop of just manual conversion on the mercurial revision you end up with, and that's not counting any more commits in the interim. Don't think about possibly getting compensated for any of it, because this is amateur radio after all. A discord that always finds itself in those mailing list discussions is whether to continue porting the GUI to wxPython 4 or not. Having used that interface, it is woefully incomplete and much slower/heavier than pygtk2/pygobject3. For the purposes of this port, unless a consensus gets reached upstream (and not in the forks), resurrections using wxPython 4 will not be entertained; only pygobject3 will be considered. |