View Issue Details

IDProjectCategoryView StatusLast Update
0007879Kali LinuxGeneral Bugpublic2022-12-08 16:50
Reporterpeerj Assigned Tosbrun  
Status assignedResolutionopen 
Product Version2022.3 
Summary0007879: chirp (transfering config data to/from HAM radios) errors out

Trying to download a config (to be modified and re-uploaded into the device) gives this error:

"ERROR: Failed to clone: module 'collections' has no attribute 'Callable'"
(taken from the cmdline, but identical to an error msg box).

This seems to be a well-known issue:

The last one is from the issue tracker of the developer.

Steps To Reproduce

Attach cable (HAM handheld radio <-> cable <-> computer with kali).
Start chirp.
Radio -> Download.
Choose Port, Vendor, Model.
The LED on the device blinks. So the cable is working and the device reacting.
Progress bar runs the whole line.
Error msg box appears with error msg as described above and in many other messages.

Additional Information

One might hope that this will resolve "itself", because the error seems to be reported at many places.
But since it seems to exist since some months already, the developer(s) might need some help.




2022-08-19 18:00

reporter   ~0016613

This might be a python 2/3 issue -- see this thread:[email protected]/msg1857150.html

"Just tried using this software to program my radio and found out it stopped
working. I remember it was everything fine a few months ago. Probably this is
caused by changes in Python 3.10.5"

"The Debian packaged version is much older than the current version."

"The problem with chirp is that upstream isn't moving to python 3, the
porting branch seems stalled:;



2022-08-19 18:05

reporter   ~0016614

More analyses of the error and its ramifications in different porting paths:



2022-10-14 19:56

reporter   ~0016978

This is kind of a history of the problem ("early warning" from 2013):

This reiterates the problem several years later (2018):

And here the main author explains the work to be done (2019):
In short: "CHIRP has historically been built on pygtk, which is not available in Python3 and never will be. Python2 is deprecated and will eventually be unsupported on major platforms.
In order to facilitate a move to Python3 for the core of CHIRP, something has to be done about the UI. The pygobject libraries provide an imperfect compatibility layer, but support seems rough and stability is suspect.
This issue is to coordinate the work on a UI re-write using wxPython, which is well-supported, long-lived, and generates native widgetry on the big three major platforms."
Also, he states "Target version set to chirp-py3", which doesn't seem to exist yet.

Starting chirp with python2 like this isn't enough:

$ python2 /usr/bin/chirpw
Traceback (most recent call last):
File "/usr/bin/chirpw", line 11, in <module>
import wx
ImportError: No module named wx

So maybe a better workaround would be to create a kali package which by default envelops chirp with some code to start it using python2 and the relevant python2-pygtk library?

There seem to be some remnants of gtk2 in kali (see "apt-cache search gtk2"), but none for python2 ("apt-cache search gtk | grep python"). So maybe the library could be re-included, if only for chirp?

OTOH, on this page: -- section "chirp-py3", one can see some ongoing development regarding chirp's py3 issues.
But from browsing through the open issues, not sure if there is real progress.

So maybe some temporary solution regarding the missing libraries would be in order, for the time it takes upstream to advance with py3 compatibility?



2022-12-08 16:50

manager   ~0017229

Debian has uploaded a new version 1:20221106+py3-1.

It fixes issues with python3.

Issue History

Date Modified Username Field Change
2022-08-19 17:54 peerj New Issue
2022-08-19 18:00 peerj Note Added: 0016613
2022-08-19 18:05 peerj Note Added: 0016614
2022-10-14 19:56 peerj Note Added: 0016978
2022-10-24 08:43 daniruiz Assigned To => sbrun
2022-10-24 08:43 daniruiz Status new => assigned
2022-12-08 16:50 sbrun Note Added: 0017229