Project

General

Profile

Actions

Bug #9543

closed

Can't install chirp-daily in Ubuntu 20.04

Added by S Michael Smith over 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/12/2021
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
Installation
Platform:
Linux
Debug Log:
I read the instructions above:

Description

I have attempted in several ways to install chirp 20211105 to a new Ubuntu 20.04. Python 2 is no longer supported, but I attempted to change code for Python 3 syntax without success. There seem to be too many problems, and I got as far as an issue with 'make' for the localizations. I attempted to use flatpak, but that fails in my plain vanilla installation, apparently due to certificate or some similar issue. Basically, I have had 0 success getting flatpak to work for anything, and it complains about no runtime, unacceptable TLS certificate, etc. Finally, I tried to pull the deb package from the launchpad ppa, but that complained of all sorts of errors. Using apt to install lists several python libraries that are "not installable", and I can't seem to find them. These are

chirp-daily : Depends: python-libxslt1 but it is not installable
Depends: python-gtk2 but it is not installable
Depends: python-libxml2 but it is not going to be installed
Depends: python-serial but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

Surely someone has solved this?

How is it possible to install chirp in Ubuntu 20.04? I used to use it in 2014.04 without any problems whatsoever...

Actions #1

Updated by Jim Unroe over 2 years ago

  • Status changed from New to Feedback

On distributions that have dropped python2 and other CHIRP dependencies, the recommended way to install CHIRP is by using the flatpak.

Jim KC9HI

Actions #2

Updated by S Michael Smith over 2 years ago

Thanks, Jim, but as I mentioned, I can't get flatpak to work for any install. I don't know what's wrong with it, but it seems to have something to do with TLS. I've sought help with that, but no avail. Fortunately, I have an older machine with Ubuntu 14.04, which I installed on with success. I really need to get it running on 20.04, though.

Actions #3

Updated by S Michael Smith over 2 years ago

BTW, I'm KY4IX...

Actions #4

Updated by S Michael Smith over 2 years ago

Also, isn't there a Python 3 version under way? I'm not great with Python, but would be glad to help if I can understand the build tree and source.

Actions #5

Updated by Jim Unroe over 2 years ago

S Michael Smith wrote:

Thanks, Jim, but as I mentioned, I can't get flatpak to work for any install. I don't know what's wrong with it, but it seems to have something to do with TLS. I've sought help with that, but no avail. Fortunately, I have an older machine with Ubuntu 14.04, which I installed on with success. I really need to get it running on 20.04, though.

I went back to using Windows just before the Linux distributions started dropping support for Python2. However someone else recently mentioned that they had no success at installing and using the CHIRP flatpak so I decided to give it a go myself. So I swapped out the hard drive in my PC, installed Ubuntu 21.04 and then I believe that I followed the instructions on "this page":https://piratesinteepees.org/installing-chirp-in-ubuntu-20-04/ to install the flatpak. It worked fine for me. I didn't mess with the auto-update script.

"This page":https://boondockplan.wordpress.com/2020/11/27/chirp-via-flatpak/ that shows another method. I didn't try it, though.

Jim KC9HI

Actions #6

Updated by Jim Unroe over 2 years ago

S Michael Smith wrote:

Also, isn't there a Python 3 version under way? I'm not great with Python, but would be glad to help if I can understand the build tree and source.

Very slowly. Join the CHIRP developer mailing list (find a link on "this page":https://chirp.danplanet.com/projects/chirp/wiki/Developers). I am sure they would be happy to have the additional help.

Jim KC9HI

Actions #7

Updated by S Michael Smith over 2 years ago

Thanks Jim,
I have tried all of these. Here's an example of what I get just by trying to update flatpak (yes, I've reinstalled it and done everything I can think of):

$ flatpak update -v
F: No installations directory in /etc/flatpak/installations.d. Skipping
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /home/smichaelsmith/.local/share/flatpak
Looking for updates…
Nothing to do.
F: flathub:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: Updating appstream data for remote flathub
F: Fetching summary file for remote ‘flathub’
F: Failed to download optional summary
F: Error updating: Error updating appstream2: Unable to load summary from remote flathub: Unacceptable TLS certificate; Error updating appstream: Unable to load summary from remote flathub: Unacceptable TLS certificate
F: gnome-nightly:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: Updating appstream data for remote gnome-nightly
F: Fetching summary file for remote ‘gnome-nightly’
F: Failed to download optional summary
F: Error updating: Error updating appstream2: Unable to load summary from remote gnome-nightly: Unacceptable TLS certificate; Error updating appstream: Unable to load summary from remote gnome-nightly: Unacceptable TLS certificate
F: chirp-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp1-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp2-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp3-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp4-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp5-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp6-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp7-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp8-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400
F: chirp9-origin:x86_64 appstream age 18446744073709551615 is greater than ttl 86400

This is all from ordinary flatpak installation, but I can't seem to find any way to get help from flatpak. Also, here's an attempt to set remote:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: Unacceptable TLS certificate

This is all I can get from it...

Actions #8

Updated by S Michael Smith over 2 years ago

h1. Success!

The magic was "sudo dpkg-reconfigure ca-certificates" and just letting it do its thing. Once certificates were fixed, the process worked!

Actions #9

Updated by S Michael Smith over 2 years ago

One other thing needed on Ubuntu 20.04 (and likely most Ubuntu distros):

sudo usermod -a -G tty $USER
sudo usermod -a -G dialout $USER

to set permissions to access /dev/ttyUSB0, which is the usual serial port for the Baofeng USB adapter (unless other serial USB devices are already present). Otherwise you may get a "permission denied" notice when trying to connect the radio.

BTW, only the Baofeng FTDI adapter will work for Baofeng radios on Linux; a different chip type appears to only work on some Windows systems. Similar issues may occur for other adapters of different radio manufacturers in Linux systems.

Actions #10

Updated by Jim Unroe over 2 years ago

S Michael Smith wrote:

One other thing needed on Ubuntu 20.04 (and likely most Ubuntu distros):

sudo usermod -a -G tty $USER
sudo usermod -a -G dialout $USER

to set permissions to access /dev/ttyUSB0, which is the usual serial port for the Baofeng USB adapter (unless other serial USB devices are already present). Otherwise you may get a "permission denied" notice when trying to connect the radio.

This is no different that is has always been. I have only ever had to add my user to the "dialout" group, though.

BTW, only the Baofeng FTDI adapter will work for Baofeng radios on Linux; a different chip type appears to only work on some Windows systems. Similar issues may occur for other adapters of different radio manufacturers in Linux systems.

I have never had an issue with any programming cable on Linux that was due to the USB-to-Serial chip. I only have a small number of mobile radios with the only programming cable I have has an FTDI chip. With virtually everything else on a regular basis (except DMR radios), has a Prolific chip. I do programming cables with chips from the common chip bendors (FTDI, Prolific, Silicon Labs, WCH, etc) and they all worked fine with Linux. Linux just works.

My go to 6-in-1 programming cable has the Prolific end-of-life chip that requires use of the older Prolific v3.2.0.0 device driver in Windows Vista, 7, 8, 10 and 11 (v2.0.2.1 for Windows XP). I use it with Windows, Linux and macOS to program Baofeng, AnyTone, Retevis, Kenwood and any other of the various radios that I have that require the Kenwood 2-pin connection. I do on occasion have to re-install and select the older Prolific driver whenever Windows thinks it is in my best interests to upgrade the device driver.

Jim KC9HI

Actions #11

Updated by Bernhard Hailer about 2 years ago

  • Status changed from Feedback to Closed
  • Model affected changed from (All models) to Installation
  • Platform changed from Windows to Linux

This appears to be resolved.

Actions

Also available in: Atom PDF