Re: Users Digest, Vol 186, Issue 1
Re:-
On 01/06/2024 21:38, users-request@lists.chirpmyradio.com wrote:
I don't want to specify a specific version here because it's specified in the package and mentioned when you install (see above). Putting it here is just asking for it to be stale if it doesn't get updated the next time we bump. However, I'll be glad to add to the page that if you see something like the above error message it means your python is too old if you think it's necessary for clarity.
(Sorry to shout, but...)
Yeah, but please don't do that again. Your responses here have already been quite rude and I'm sure the other volunteers who work on this (and the docs, thanks Jeff!) will join me in appreciating you being a lot more respectful. Thanks!
--Dan
OK Dan. Apologies for "shouting", but things could be somewhat easier for us (the less experience Python users out here) than your good self, who only get involved with installs and updates when needed.
Just having something on the download page (and in the archive) that states what the minimum Python version (and wxPython perhaps) is needed for any particular version of Chirp, would save "A Lot" of user time (+ cost for those on a $-per-kByte connection) and confusion re Chirp, when they find after waiting (and or paying for) the download, that it won't install.
I see you updated the download info page some hours ago now, at least your name is at the bottom of the page, not Jeff's. (Sorry, I don't know who Jeff is in this respect.)
As to "needing" to update my distro (LMDE 5 just now) that is still in full support for nearly another 80 days, it keeps telling me.
I don't doubt that things move on over time, that's the nature of stuff, but some appreciation for us the users would help us a lot.
As for what pipx is telling us when it fails, that's rather cryptic and embedded in a lot of other text, and looks at first, to be something that was spat out as some code crashed and burnt.
OK. For now, I've installed one of the 2024 January 11th version, as that still works with Python 3.9.x So I have the use of Chirp again, for now.
FYI: There are several LTS versions of Linux, that last a lot longer than the 2 to 2 1/5 years of the mainstream distro's. Many are popular with Radio Amateurs, just because they /*do not*/ keep messing messing with utility version changes and such. "Stability" is preferable to many of us, rather than living on the bleeding edge of development. If a distro (as mine is) still receives security patches, that for the most part, is all we need.
However... For those who would like to know if it's viable to try to install a CHIRP update, before doing so.
First, in a terminal command line session. (Ctrl + Alt + T will launch a fresh terminal/command line session.) These commands will show you what you are running. (The '$' indicates the command line prompt, you do not need to enter it.) The result is shown on the next line.
Find out the currently installed Python version.
$ python3 --version Python 3.9.2
(https://devguide.python.org/versions/%C2%A0 is good to view, in relation to what you discover above. 3.9.x doesn't die, until October 2025, nearly a year and a half away, just for info...)
To find out the installed version of wxpython...
$ python3 -c "import wx;print(wx.__version__)" 4.0.7
Both as discovered on my present system.
In a downloaded .whl file, using an archive browser, look for the folder 'chirp-yyymmdd.dist-info' (Where yyyymmdd equals the date part of whatever file you downloaded.)
In that folder, look in the file METADATA and you'll find a string (it is a plain text file) like:- 'Requires-Python: >=3.7,<4' That (in this case) indicates that a Python version between 3.7 and 4 is needed.
(Greater or equal to v3.7 and less than v4 That example comes from the 20240111 dated .whl file.)
If you download the .tar.gz file instead, look for the file 'requirements.txt' Again, that has some minimum version info re wxpython, but not python itself, that can be found in the file PKG-INFO Again, both are plain text files.
Sadly, you do have to download an entire file first to discover that info in either case..
Frankly, I'd suggest doing that first, */before/* uninstalling an existing working version of Chirp!
Oh, I'd also keep a local copy of the downloaded file, especially when you do install it successfully. You may need it to repair things if something else goes bad, or to revert to a known working state if a future install goes bad. Perhaps without i'net access at that time.
FYI: The immediate past day-job (thankfully I'm retired now!) I used to be the customer support and service guru, in-house and on-site, both hardware and software.
I learnt very early on, that making as much information available to users, /before/ they commit themselves, saves a lot of time, effort (and cost) and greatly increases a customers likelihood to come back for more of whatever we were doing at the time, and giving us more of their money! That is with hardware, and especially software!
Yes, Chirp is largely free to us the users, other than the cost of time and effort to install and learn. For that we are all grateful indeed. But wasting even "free" time does not go down well with many of us. Retired I might be now, but I'm as busy as ever, just working for other "managers". (Domestic and/or feline!)
73.
Dave G8KBV.
Just having something on the download page (and in the archive) that states what the minimum Python version (and wxPython perhaps) is needed for any particular version of Chirp, would save "A Lot" of user time (+ cost for those on a $-per-kByte connection) and confusion re Chirp, when they find after waiting (and or paying for) the download, that it won't install.
I've provided links to the source files in the repo that dictate the package and python requirements on the linux install page. I've also added your examples about finding the wx and python versions for users that might hit this problem in the same way you did. Hopefully that will help them do the research necessary if they require it.
I'll consider dropping a file into the build directory at some point that will expose those in more succinct terms, but I have to be honest, I'm not sure it's really all that important and worth the time.
I see you updated the download info page some hours ago now, at least your name is at the bottom of the page, not Jeff's. (Sorry, I don't know who Jeff is in this respect.)
Jeff is one of the contributors to the text on the page, his name is in the history of the page, and he replied recently to to one of the other threads asserting that the instructions don't work. When he saw some missing info on the page a while back, he helped constructively to make it better.
As to "needing" to update my distro (LMDE 5 just now) that is still in full support for nearly another 80 days, it keeps telling me.
I don't doubt that things move on over time, that's the nature of stuff, but some appreciation for us the users would help us a lot.
Right now, the ~98% of users that run the Windows and macOS builds are running on much newer bits than the (comparatively) few Linux users. Even still, we have a number of exceptions in the code specifically to make things work on the ancient version of wxWidgets that is in most distros (4.0.7, just like yours). A quick survey shows 21 places in the code where we do something specific for Linux so it works better for the users.
Just the other day, I added a new feature that turned out not to work the same way on 4.0.7 and I had to write _more_ code (on my night and weekend time) to make it work for Linux users as well as the others. Chirp also has a whole chunk of code in it to make installing a desktop/app icon easier for linux users since the new way of installing python packages (which we're forced to comply with) can't do it.
Until several weeks ago, we still had some of those non-trivial hacks in place for older Pythons like 3.7 which lack some of the inbuilt ways of packaging extra data (like the stock configs, etc). In an effort to reduce the maintenance overhead, I removed those to bump the minimum version when adding some extra stuff to make it more streamlined. I did that based on the fact that Ubuntu 24.04 was being released that month, which would place the last LTS of it to not support at least 3.10 at *four* years old and three major versions ago. That was a measured decision, not one made on a whim, specifically with the impact to the users in mind. Ubuntu (and derivatives) are the largest chunk of that 2% of users for which that work is relevant, so like it or not, it's the benchmark.
So, please, again, show some respect for those of us spending their Sunday mornings trying hard to cater to a fraction of the 2% of users that run older distros by not claiming a lack of "appreciation." It would be *easier* to just say chirp "doesn't work on linux", drop the install instructions (which have to shift over time because of changes in the distros and python itself) and remove all the linux-specific bits in the code which require maintenance.
You know what hasn't changed in a long time? The installation instructions for macOS and Windows :)
FYI: The immediate past day-job (thankfully I'm retired now!) I used to be the customer support and service guru, in-house and on-site, both hardware and software.
Good to know. Please provide your phone number and I'll be glad to list it on the page for extended support. Charge whatever rate you feel appropriate :)
--Dan
Stories like this play in the back of my head when I hear hams complain about their preferred program not running inside Linux.
That a distribution has an LTS marking does not mean that the user is expected to run the original, non-updated release for the length of the vendor's support.
I am familiar with Ubuntu LTS which they release every two years, and has semi-annual updates (20.04 LTS, then 20.04.1, 20.04.2, and 20.04.3) before and after the next LTS release is delivered (22.04 LTS) and the cycle continues (See: https://wiki.ubuntu.com/Releases ) - during an LTS release lifetime (5 years) the user is expected to perform regular updates to keep the release current in some meaningful way. LTS releases are intended to appeal to the "it works, leave it alone" type of users, which is not represented by someone that wants to run the latest end-user software on say a 4 year-old distribution.
Just because the folks that put together your Linux distribution decided to provide *security* updates for 5 years doesn't obligate independent software developers to support that 5 year-old distribution and whatever development libraries/tools you have on your system that may date back to the distributions release date years ago.
I've never attempted to run Chirp on Linux, though I do use Linux rather extensively in my personal use (about half my computers run it), I simply prefer to run my hobby-related software on Windows.
And from a previous post in this thread - is there anyone out in the real world paying a "per Kb download fee" to download software? And you need not uninstall your previous installation of Chirp to install the latest release, that is one of the very first things mentioned in the installation directions - the instructions merely indicate to need to not have Chirp running when upgrading.
Upgrading: You do NOT need to uninstall an existing version of CHIRP before installing a newer one. Just install the new one and it will replace the existing copy! However, be sure to quit CHIRP before installing the new version!
That is on the page where you click to choose Chirp-Next to download (see: https://chirpmyradio.com/projects/chirp/wiki/Download ).
And this just rubbed me the wrong way:
Yes, Chirp is largely free to us the users, other than the cost of time and effort to install and learn. For that we are all grateful indeed. But wasting even "free" time does not go down well with many of us.
Two points "largely free"? What? It is "free" full stop, no if, no buts - the time spent learning a software package isn't a cost, it's an investment.
Second, its interesting that your "free time" is so valuable that you took the time to complain about the ONLY solution, free or commercial, available to program your radios on a Linux system (no OEM I'm aware of supplies radio programming software that runs on any Linux distribution), because you struggled in your very particular environment, and then flexed about your career spent supporting end-users to somehow back up your view of how things should be. There were some useful nuggets in your post, but your complaints got in the way of the good ideas and suggestions you offered.
I'm not part of the Chirp team, but I do feel I am part of the Chirp end-user community, and in that capacity I want to express my unqualified appreciation for all the hard work they choose to do, to provide us with a very useful tool like Chirp.
Take care,
Ken, N2VIP
On Jun 2, 2024, at 09:58, Dan Smith via Users users@lists.chirpmyradio.com wrote: So, please, again, show some respect for those of us spending their Sunday mornings trying hard to cater to a fraction of the 2% of users that run older distros by not claiming a lack of "appreciation." It would be *easier* to just say chirp "doesn't work on linux", drop the install instructions (which have to shift over time because of changes in the distros and python itself) and remove all the linux-specific bits in the code which require maintenance.
You know what hasn't changed in a long time? The installation instructions for macOS and Windows :)
Upgrading: You do NOT need to uninstall an existing version of CHIRP before installing a newer one. Just install the new one and it will replace the existing copy! However, be sure to quit CHIRP before installing the new version!
That is on the page where you click to choose Chirp-Next to download (see: https://chirpmyradio.com/projects/chirp/wiki/Download ).
You're absolutely right Ken, but there's an additional wrinkle here. CHIRP itself updates in place no problem, but pipx has some of its own restrictions in that regard and an uninstall->install cadence seems to work the most reliably in the most places. So our download directions recommend that method. But, good point about that statement on the download page - perhaps it needs to be updated to make it clear that it applies to the two main OSes only.
Very well said on all the rest. Thanks for being part of the wider set of "support team" contributors :)
--Dan
Note that I do not use pipx. I do my updates with pip using the command `pip install --upgrade chirp-20240504.tar.gz` and it does the install/upgrade flawlessly This is on Fedora 40 and it has worked this way since Fedora 37 for me with upgrades to each version in between (both of the OS and chirp).
This was the most recent update done this way ---------------- $ pip install --upgrade chirp-20240531.tar.gz Defaulting to user installation because normal site-packages is not writeable Processing ./chirp-20240531.tar.gz Preparing metadata (setup.py) ... done Requirement already satisfied: pyserial in /usr/lib/python3.12/site-packages (from chirp==20240531) (3.5) Requirement already satisfied: requests in /usr/lib/python3.12/site-packages (from chirp==20240531) (2.31.0) Requirement already satisfied: yattag in /usr/lib/python3.12/site-packages (from chirp==20240531) (1.14.0) Collecting suds (from chirp==20240531) Downloading suds-1.1.2-py3-none-any.whl.metadata (1.7 kB) Requirement already satisfied: charset-normalizer<4,>=2 in /usr/lib/python3.12/site-packages (from requests->chirp==20240531) (3.3.2) Requirement already satisfied: idna<4,>=2.5 in /usr/lib/python3.12/site-packages (from requests->chirp==20240531) (3.7) Requirement already satisfied: urllib3<3,>=1.21.1 in /usr/lib/python3.12/site-packages (from requests->chirp==20240531) (1.26.18) Downloading suds-1.1.2-py3-none-any.whl (144 kB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 144.8/144.8 kB 483.8 kB/s eta 0:00:00 Building wheels for collected packages: chirp Building wheel for chirp (setup.py) ... done Created wheel for chirp: filename=chirp-20240531-py3-none-any.whl size=1758674 sha256=718a39f58671f620f635d2773d2adc33efe40f875f5044a71a13a0abd2e309b8 Stored in directory: /home/jvian/.cache/pip/wheels/9f/35/0e/5edd8aa001bb272a87eb2456ec350efd9c68666894fab622af Successfully built chirp Installing collected packages: suds, chirp Attempting uninstall: chirp Found existing installation: chirp 20240504 Uninstalling chirp-20240504: Successfully uninstalled chirp-20240504 Successfully installed chirp-20240531 suds-1.1.2 -------------------------------
Jeff KI7GJG
On Sun, Jun 2, 2024 at 3:17 PM Dan Smith via Users < users@lists.chirpmyradio.com> wrote:
Upgrading: You do NOT need to uninstall an existing version of CHIRP
before installing a newer one. Just install the new one and it will replace the existing copy! However, be sure to quit CHIRP before installing the new version!
That is on the page where you click to choose Chirp-Next to download
(see: https://chirpmyradio.com/projects/chirp/wiki/Download ).
You're absolutely right Ken, but there's an additional wrinkle here. CHIRP itself updates in place no problem, but pipx has some of its own restrictions in that regard and an uninstall->install cadence seems to work the most reliably in the most places. So our download directions recommend that method. But, good point about that statement on the download page - perhaps it needs to be updated to make it clear that it applies to the two main OSes only.
Very well said on all the rest. Thanks for being part of the wider set of "support team" contributors :)
--Dan _______________________________________________ Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
Note that I do not use pipx. I do my updates with pip using the command `pip install --upgrade chirp-20240504.tar.gz` and it does the install/upgrade flawlessly This is on Fedora 40 and it has worked this way since Fedora 37 for me with upgrades to each version in between (both of the OS and chirp).
I imagine this works for you only because you've upgraded from before Fedora 38. The python community is moving to a model where you are barred from installing non-distro packages into the regular namespace, and thus pipx (or venv) is required. Here are the details:
https://packaging.python.org/en/latest/specifications/externally-managed-env...
All new installs of every distro I've seen now have the flag enabled, which means pip refuses to do anything unless it's inside a venv. Fedora rolled this in 38, AFAIK. It's a major hassle for users, IMHO, and it seems a really unfortunate change to me. But, it's something upstream python and the distros have decided for us, so we just have to deal with it.
--Dan
I imagine this works for you only because you've upgraded from before
Fedora 38. The python community is moving to a model where you are barred from installing non-distro packages into the regular namespace, and thus pipx (or venv) is required. Here are the details:
Not quite. The pip command (at least the fedora version) now will automatically install packages inside the user space, specifically under ~/.local/lib/pythonX.XX/site-packatges/ and the executables under ~/.local/bin unless it is being run as the root user. This does not require using a venv to function, but does only operate as the user similar to a venv.
I install system packages as the root user, but packages such as chirp (and others) using pip as my regular user to avoid overwriting system packages when version dependencies may differ.
Yes, this is a change from earlier designs but avoids the necessity of a venv while still having what seems the same advantages. I have not needed a venv to install anything for quite some time, even on my RPi which runs ubuntu and uses octoprint which originally did require the venv.
I believe that for other distros pipx may perform similarly.
Jeff KI7GJG
On Tue, Jun 4, 2024 at 3:12 PM Dan Smith via Users < users@lists.chirpmyradio.com> wrote:
Note that I do not use pipx. I do my updates with pip using the command `pip install --upgrade chirp-20240504.tar.gz` and it does the install/upgrade flawlessly This is on Fedora 40 and it has worked this way since Fedora 37 for me with upgrades to each version in between (both of the OS and chirp).
I imagine this works for you only because you've upgraded from before Fedora 38. The python community is moving to a model where you are barred from installing non-distro packages into the regular namespace, and thus pipx (or venv) is required. Here are the details:
https://packaging.python.org/en/latest/specifications/externally-managed-env...
All new installs of every distro I've seen now have the flag enabled, which means pip refuses to do anything unless it's inside a venv. Fedora rolled this in 38, AFAIK. It's a major hassle for users, IMHO, and it seems a really unfortunate change to me. But, it's something upstream python and the distros have decided for us, so we just have to deal with it.
--Dan _______________________________________________ Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
Not quite. The pip command (at least the fedora version) now will automatically install packages inside the user space, specifically under ~/.local/lib/pythonX.XX/site-packatges/ and the executables under ~/.local/bin unless it is being run as the root user. This does not require using a venv to function, but does only operate as the user similar to a venv.
This has been how pip works on all platforms for quite a while and it's separate from the externally-managed flag. Pip (and python) consider a bare user install to be in the same package "namespace" as the rest of the system if not in a venv.
I install system packages as the root user, but packages such as chirp (and others) using pip as my regular user to avoid overwriting system packages when version dependencies may differ.
Me too, and I have done so for years :)
Yes, this is a change from earlier designs but avoids the necessity of a venv while still having what seems the same advantages. I have not needed a venv to install anything for quite some time, even on my RPi which runs ubuntu and uses octoprint which originally did require the venv.
I believe that for other distros pipx may perform similarly.
User installs are still not allowed with the externally-managed flag. Here's an example from an attempted user install on Ubuntu 24.04:
ubuntu@39107696c71a:/$ pip install --user requests error: externally-managed-environment
× This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install.
If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.12/README.venv for more information.note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification.
I don't have a Fedora system handy to confirm, but unless they decide not to roll out that flag, Fedora will break in this way when they do.
Debian and Ubuntu are already there. Looks like Arch has as well:
https://bbs.archlinux.org/viewtopic.php?id=286788
(that shows a user install failing).
Even homebrew on macOS has marked their python environment as externally-managed, even though it's a whole python toolchain installed for a single user :)
The comments from this post also show people discussing it breaking --user installs:
https://www.jeffgeerling.com/blog/2023/how-solve-error-externally-managed-en...
--Dan
Hi - I’m trying to install CHIRP on Ultramarine (Fedora) using pipx but get the error “unable to parse package spec: ./chirp-20250124-py3-none-any.whl”
The downloaded file is just in downloads - do I need to move it somewhere else for pipx to find it ?
Very much just learning Linux so at a copy/paste command line knowledge level.
Actually - I have solved this. Some more googling revealed that I needed to cd ~/downloads then run the install script.
Next step to try serial cable
Cheers,
Pete
On Sat, 25 Jan 2025 at 19:10, peterbeatty--- via Users < users@lists.chirpmyradio.com> wrote:
Hi - I’m trying to install CHIRP on Ultramarine (Fedora) using pipx but get the error “unable to parse package spec: ./chirp-20250124-py3-none-any.whl”
The downloaded file is just in downloads - do I need to move it somewhere else for pipx to find it ?
Very much just learning Linux so at a copy/paste command line knowledge level. _______________________________________________ Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
Fedora rolled this in 38, AFAIK. It's a major hassle for users, IMHO, and
it seems a really unfortunate change to me.
I did a new clean install with Fedora 39 and this is still the update method I use with pip instead of pipx.
Jeff KI7GJG
On Tue, Jun 4, 2024 at 3:12 PM Dan Smith via Users < users@lists.chirpmyradio.com> wrote:
Note that I do not use pipx. I do my updates with pip using the command `pip install --upgrade chirp-20240504.tar.gz` and it does the install/upgrade flawlessly This is on Fedora 40 and it has worked this way since Fedora 37 for me with upgrades to each version in between (both of the OS and chirp).
I imagine this works for you only because you've upgraded from before Fedora 38. The python community is moving to a model where you are barred from installing non-distro packages into the regular namespace, and thus pipx (or venv) is required. Here are the details:
https://packaging.python.org/en/latest/specifications/externally-managed-env...
All new installs of every distro I've seen now have the flag enabled, which means pip refuses to do anything unless it's inside a venv. Fedora rolled this in 38, AFAIK. It's a major hassle for users, IMHO, and it seems a really unfortunate change to me. But, it's something upstream python and the distros have decided for us, so we just have to deal with it.
--Dan _______________________________________________ Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
Ken, great points, and I wish everybody had the written communication skills you have. The world would be a better place.
Joel, K5KZX
On 6/2/24 11:10 AM, Ken Hansen via Users wrote:
Stories like this play in the back of my head when I hear hams complain about their preferred program not running inside Linux.
That a distribution has an LTS marking does not mean that the user is expected to run the original, non-updated release for the length of the vendor's support.
I am familiar with Ubuntu LTS which they release every two years, and has semi-annual updates (20.04 LTS, then 20.04.1, 20.04.2, and 20.04.3) before and after the next LTS release is delivered (22.04 LTS) and the cycle continues (See: https://wiki.ubuntu.com/Releases ) - during an LTS release lifetime (5 years) the user is expected to perform regular updates to keep the release current in some meaningful way. LTS releases are intended to appeal to the "it works, leave it alone" type of users, which is not represented by someone that wants to run the latest end-user software on say a 4 year-old distribution.
Just because the folks that put together your Linux distribution decided to provide *security* updates for 5 years doesn't obligate independent software developers to support that 5 year-old distribution and whatever development libraries/tools you have on your system that may date back to the distributions release date years ago.
I've never attempted to run Chirp on Linux, though I do use Linux rather extensively in my personal use (about half my computers run it), I simply prefer to run my hobby-related software on Windows.
And from a previous post in this thread - is there anyone out in the real world paying a "per Kb download fee" to download software? And you need not uninstall your previous installation of Chirp to install the latest release, that is one of the very first things mentioned in the installation directions - the instructions merely indicate to need to not have Chirp running when upgrading.
Upgrading: You do NOT need to uninstall an existing version of CHIRP before installing a newer one. Just install the new one and it will replace the existing copy! However, be sure to quit CHIRP before installing the new version!
That is on the page where you click to choose Chirp-Next to download (see: https://chirpmyradio.com/projects/chirp/wiki/Download ).
And this just rubbed me the wrong way:
Yes, Chirp is largely free to us the users, other than the cost of time and effort to install and learn. For that we are all grateful indeed. But wasting even "free" time does not go down well with many of us.
Two points "largely free"? What? It is "free" full stop, no if, no buts - the time spent learning a software package isn't a cost, it's an investment.
Second, its interesting that your "free time" is so valuable that you took the time to complain about the ONLY solution, free or commercial, available to program your radios on a Linux system (no OEM I'm aware of supplies radio programming software that runs on any Linux distribution), because you struggled in your very particular environment, and then flexed about your career spent supporting end-users to somehow back up your view of how things should be. There were some useful nuggets in your post, but your complaints got in the way of the good ideas and suggestions you offered.
I'm not part of the Chirp team, but I do feel I am part of the Chirp end-user community, and in that capacity I want to express my unqualified appreciation for all the hard work they choose to do, to provide us with a very useful tool like Chirp.
Take care,
Ken, N2VIP
On Jun 2, 2024, at 09:58, Dan Smith via Users users@lists.chirpmyradio.com wrote: So, please, again, show some respect for those of us spending their Sunday mornings trying hard to cater to a fraction of the 2% of users that run older distros by not claiming a lack of "appreciation." It would be *easier* to just say chirp "doesn't work on linux", drop the install instructions (which have to shift over time because of changes in the distros and python itself) and remove all the linux-specific bits in the code which require maintenance.
You know what hasn't changed in a long time? The installation instructions for macOS and Windows :)
Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
Seconded.
Sent from my iPhone
On 2 Jun 2024, at 18:57, Joel McClure via Users users@lists.chirpmyradio.com wrote:
Ken, great points, and I wish everybody had the written communication skills you have. The world would be a better place.
Joel, K5KZX
On 6/2/24 11:10 AM, Ken Hansen via Users wrote: Stories like this play in the back of my head when I hear hams complain about their preferred program not running inside Linux.
That a distribution has an LTS marking does not mean that the user is expected to run the original, non-updated release for the length of the vendor's support.
I am familiar with Ubuntu LTS which they release every two years, and has semi-annual updates (20.04 LTS, then 20.04.1, 20.04.2, and 20.04.3) before and after the next LTS release is delivered (22.04 LTS) and the cycle continues (See: https://wiki.ubuntu.com/Releases ) - during an LTS release lifetime (5 years) the user is expected to perform regular updates to keep the release current in some meaningful way. LTS releases are intended to appeal to the "it works, leave it alone" type of users, which is not represented by someone that wants to run the latest end-user software on say a 4 year-old distribution.
Just because the folks that put together your Linux distribution decided to provide *security* updates for 5 years doesn't obligate independent software developers to support that 5 year-old distribution and whatever development libraries/tools you have on your system that may date back to the distributions release date years ago.
I've never attempted to run Chirp on Linux, though I do use Linux rather extensively in my personal use (about half my computers run it), I simply prefer to run my hobby-related software on Windows.
And from a previous post in this thread - is there anyone out in the real world paying a "per Kb download fee" to download software? And you need not uninstall your previous installation of Chirp to install the latest release, that is one of the very first things mentioned in the installation directions - the instructions merely indicate to need to not have Chirp running when upgrading.
Upgrading: You do NOT need to uninstall an existing version of CHIRP before installing a newer one. Just install the new one and it will replace the existing copy! However, be sure to quit CHIRP before installing the new version!
That is on the page where you click to choose Chirp-Next to download (see: https://chirpmyradio.com/projects/chirp/wiki/Download ).
And this just rubbed me the wrong way:
Yes, Chirp is largely free to us the users, other than the cost of time and effort to install and learn. For that we are all grateful indeed. But wasting even "free" time does not go down well with many of us.
Two points "largely free"? What? It is "free" full stop, no if, no buts - the time spent learning a software package isn't a cost, it's an investment.
Second, its interesting that your "free time" is so valuable that you took the time to complain about the ONLY solution, free or commercial, available to program your radios on a Linux system (no OEM I'm aware of supplies radio programming software that runs on any Linux distribution), because you struggled in your very particular environment, and then flexed about your career spent supporting end-users to somehow back up your view of how things should be. There were some useful nuggets in your post, but your complaints got in the way of the good ideas and suggestions you offered.
I'm not part of the Chirp team, but I do feel I am part of the Chirp end-user community, and in that capacity I want to express my unqualified appreciation for all the hard work they choose to do, to provide us with a very useful tool like Chirp.
Take care,
Ken, N2VIP
On Jun 2, 2024, at 09:58, Dan Smith via Users users@lists.chirpmyradio.com wrote:
So, please, again, show some respect for those of us spending their Sunday mornings trying hard to cater to a fraction of the 2% of users that run older distros by not claiming a lack of "appreciation." It would be *easier* to just say chirp "doesn't work on linux", drop the install instructions (which have to shift over time because of changes in the distros and python itself) and remove all the linux-specific bits in the code which require maintenance.
You know what hasn't changed in a long time? The installation instructions for macOS and Windows :)
Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
Two great comments.
Thanks.
Paul 5b8ba
On Sun, Jun 2, 2024 at 11:23 PM Joel McClure via Users < users@lists.chirpmyradio.com> wrote:
Ken, great points, and I wish everybody had the written communication skills you have. The world would be a better place.
Joel, K5KZX
On 6/2/24 11:10 AM, Ken Hansen via Users wrote:
Stories like this play in the back of my head when I hear hams complain
about their preferred program not running inside Linux.
That a distribution has an LTS marking does not mean that the user is
expected to run the original, non-updated release for the length of the vendor's support.
I am familiar with Ubuntu LTS which they release every two years, and
has semi-annual updates (20.04 LTS, then 20.04.1, 20.04.2, and 20.04.3) before and after the next LTS release is delivered (22.04 LTS) and the cycle continues (See: https://wiki.ubuntu.com/Releases ) - during an LTS release lifetime (5 years) the user is expected to perform regular updates to keep the release current in some meaningful way. LTS releases are intended to appeal to the "it works, leave it alone" type of users, which is not represented by someone that wants to run the latest end-user software on say a 4 year-old distribution.
Just because the folks that put together your Linux distribution decided
to provide *security* updates for 5 years doesn't obligate independent software developers to support that 5 year-old distribution and whatever development libraries/tools you have on your system that may date back to the distributions release date years ago.
I've never attempted to run Chirp on Linux, though I do use Linux rather
extensively in my personal use (about half my computers run it), I simply prefer to run my hobby-related software on Windows.
And from a previous post in this thread - is there anyone out in the
real world paying a "per Kb download fee" to download software? And you need not uninstall your previous installation of Chirp to install the latest release, that is one of the very first things mentioned in the installation directions - the instructions merely indicate to need to not have Chirp running when upgrading.
Upgrading: You do NOT need to uninstall an existing version of CHIRP
before installing a newer one. Just install the new one and it will replace the existing copy! However, be sure to quit CHIRP before installing the new version!
That is on the page where you click to choose Chirp-Next to download
(see: https://chirpmyradio.com/projects/chirp/wiki/Download ).
And this just rubbed me the wrong way:
Yes, Chirp is largely free to us the users, other than the cost of time
and effort to install and learn. For that we are all grateful indeed. But wasting even "free" time does not go down well with many of us.
Two points "largely free"? What? It is "free" full stop, no if, no buts
- the time spent learning a software package isn't a cost, it's an
investment.
Second, its interesting that your "free time" is so valuable that you
took the time to complain about the ONLY solution, free or commercial, available to program your radios on a Linux system (no OEM I'm aware of supplies radio programming software that runs on any Linux distribution), because you struggled in your very particular environment, and then flexed about your career spent supporting end-users to somehow back up your view of how things should be. There were some useful nuggets in your post, but your complaints got in the way of the good ideas and suggestions you offered.
I'm not part of the Chirp team, but I do feel I am part of the Chirp
end-user community, and in that capacity I want to express my unqualified appreciation for all the hard work they choose to do, to provide us with a very useful tool like Chirp.
Take care,
Ken, N2VIP
On Jun 2, 2024, at 09:58, Dan Smith via Users <
users@lists.chirpmyradio.com> wrote:
So, please, again, show some respect for those of us spending their
Sunday mornings trying hard to cater to a fraction of the 2% of users that run older distros by not claiming a lack of "appreciation." It would be *easier* to just say chirp "doesn't work on linux", drop the install instructions (which have to shift over time because of changes in the distros and python itself) and remove all the linux-specific bits in the code which require maintenance.
You know what hasn't changed in a long time? The installation
instructions for macOS and Windows :)
Users mailing list users@lists.chirpmyradio.com
https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com
To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email
users-owner@lists.chirpmyradio.com
List archives:
https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/ _______________________________________________ Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
Dave B
you stated
Chirp is largely free to us the users, other than the cost of time
and effort to install and learn.
This comment is not fair to Dan who maintains Chirp and makes it available for the rest of us. He puts forth the effort to maintain the app, as well as funding the web site where it is hosted for your use. You whine when there is a little hiccup that is the result of your own decision to remain on an older and soon to be unsupported linux distro.
Chirp is free 100%. If you wish to use it then it is entirely up to you if you choose to invest the time and effort (and apparently $) to download it and install it. If you are using linux you should already be familiar with the continual upgrades that occur (even on the LTS distros) over time as security and bug fixes are made available. You should also be aware of changes in the languages being used (such as python) that also require the application developers (such as Dan) to invest more of their time and effort to keep the app functional as the various distros are changed.
Luckily for Dan, the changes that occurred with the update from python 3.11 to python 3.12 did not impact chirp the same as the change from 3.9 to 3.10. Dan kept chirp functional on the older python 2.7 until it was totally removed from almost all distros before releasing chirp-next to migrate from python 2 to python 3.
You should be grateful that apps you wish to use (and almost all are free and developed & maintained by persons who contribute their time and expertise for free) are kept current. It is your choice to remain on an older distro that by your own statement is only in support for another 80 days (LMDE shows security support ends July 1 2024). That means it is your choice to accept whatever the consequences are for this decision.
Ubuntu releases an LTS version every 2 years, a semi-annual update to that distro, and many minor updates in between. In fact, LMDE 6 was released a year ago and recommendations to upgrade apparently were ignored by you so you are stuck with python 3.9 when an upgrade at any time over the past year would have given you either python 3.10 or 3.11 and your current complaints about python would have been moot.
Users choose what linux version to run and when to upgrade. It does not fall as a responsibility of the app developer to keep you informed of every little detail. That responsibility falls on the shoulders of the thousands or or even tens or hundreds of thousands of users to keep themselves informed and up to date.
Stop whining about something that you chose to do 2 years ago and get current on the situation as it is today !!! You are using linux and it is your responsibility to deal with whatever may happen as the FOSS world changes daily.
Jeff KI7GJG
On Mon, Jun 3, 2024 at 3:07 PM Dave B via Users < users@lists.chirpmyradio.com> wrote:
Re:-
On 01/06/2024 21:38, users-request@lists.chirpmyradio.com wrote:
I don't want to specify a specific version here because it's specified
in the package and mentioned when you install (see above). Putting it here is just asking for it to be stale if it doesn't get updated the next time we bump. However, I'll be glad to add to the page that if you see something like the above error message it means your python is too old if you think it's necessary for clarity.
(Sorry to shout, but...)
Yeah, but please don't do that again. Your responses here have already
been quite rude and I'm sure the other volunteers who work on this (and the docs, thanks Jeff!) will join me in appreciating you being a lot more respectful. Thanks!
--Dan
OK Dan. Apologies for "shouting", but things could be somewhat easier for us (the less experience Python users out here) than your good self, who only get involved with installs and updates when needed.
Just having something on the download page (and in the archive) that states what the minimum Python version (and wxPython perhaps) is needed for any particular version of Chirp, would save "A Lot" of user time (+ cost for those on a $-per-kByte connection) and confusion re Chirp, when they find after waiting (and or paying for) the download, that it won't install.
I see you updated the download info page some hours ago now, at least your name is at the bottom of the page, not Jeff's. (Sorry, I don't know who Jeff is in this respect.)
As to "needing" to update my distro (LMDE 5 just now) that is still in full support for nearly another 80 days, it keeps telling me.
I don't doubt that things move on over time, that's the nature of stuff, but some appreciation for us the users would help us a lot.
As for what pipx is telling us when it fails, that's rather cryptic and embedded in a lot of other text, and looks at first, to be something that was spat out as some code crashed and burnt.
OK. For now, I've installed one of the 2024 January 11th version, as that still works with Python 3.9.x So I have the use of Chirp again, for now.
FYI: There are several LTS versions of Linux, that last a lot longer than the 2 to 2 1/5 years of the mainstream distro's. Many are popular with Radio Amateurs, just because they /*do not*/ keep messing messing with utility version changes and such. "Stability" is preferable to many of us, rather than living on the bleeding edge of development. If a distro (as mine is) still receives security patches, that for the most part, is all we need.
However... For those who would like to know if it's viable to try to install a CHIRP update, before doing so.
First, in a terminal command line session. (Ctrl + Alt + T will launch a fresh terminal/command line session.) These commands will show you what you are running. (The '$' indicates the command line prompt, you do not need to enter it.) The result is shown on the next line.
Find out the currently installed Python version.
$ python3 --version Python 3.9.2
(https://devguide.python.org/versions/ is good to view, in relation to what you discover above. 3.9.x doesn't die, until October 2025, nearly a year and a half away, just for info...)
To find out the installed version of wxpython...
$ python3 -c "import wx;print(wx.__version__)" 4.0.7
Both as discovered on my present system.
In a downloaded .whl file, using an archive browser, look for the folder 'chirp-yyymmdd.dist-info' (Where yyyymmdd equals the date part of whatever file you downloaded.)
In that folder, look in the file METADATA and you'll find a string (it is a plain text file) like:- 'Requires-Python: >=3.7,<4' That (in this case) indicates that a Python version between 3.7 and 4 is needed.
(Greater or equal to v3.7 and less than v4 That example comes from the 20240111 dated .whl file.)
If you download the .tar.gz file instead, look for the file 'requirements.txt' Again, that has some minimum version info re wxpython, but not python itself, that can be found in the file PKG-INFO Again, both are plain text files.
Sadly, you do have to download an entire file first to discover that info in either case..
Frankly, I'd suggest doing that first, */before/* uninstalling an existing working version of Chirp!
Oh, I'd also keep a local copy of the downloaded file, especially when you do install it successfully. You may need it to repair things if something else goes bad, or to revert to a known working state if a future install goes bad. Perhaps without i'net access at that time.
FYI: The immediate past day-job (thankfully I'm retired now!) I used to be the customer support and service guru, in-house and on-site, both hardware and software.
I learnt very early on, that making as much information available to users, /before/ they commit themselves, saves a lot of time, effort (and cost) and greatly increases a customers likelihood to come back for more of whatever we were doing at the time, and giving us more of their money! That is with hardware, and especially software!
Yes, Chirp is largely free to us the users, other than the cost of time and effort to install and learn. For that we are all grateful indeed. But wasting even "free" time does not go down well with many of us. Retired I might be now, but I'm as busy as ever, just working for other "managers". (Domestic and/or feline!)
Dave G8KBV.
-- Created on and sent from a Unix like PC running and using free and open source software: _______________________________________________ Users mailing list users@lists.chirpmyradio.com https://lists.chirpmyradio.com/postorius/lists/users.lists.chirpmyradio.com To unsubscribe, send an email to users-leave@lists.chirpmyradio.com To report this email as off-topic, please email users-owner@lists.chirpmyradio.com List archives: https://lists.chirpmyradio.com/hyperkitty/list/users@lists.chirpmyradio.com/
participants (9)
-
Dan Smith -
Dave B -
Jeffrey Vian -
Joel McClure -
Ken Hansen -
Paul Mooney -
Peter Beatty -
peterbeatty＠gmail.com
-
Roger Jane