Arch Linux User Repository

There was no harassment involved.

I wanted to make sure if the package gets further maintained or not. This wasn't clear to me as waiting for upstream to release something more appealing is IMO no reason to postpone a simple version upgrade for two weeks.

I understand that right now the situation with the python2 dependencies is not optimal, but they are all still maintained.

When the time comes and these dependencies are gone from the AUR, the daily builds are probably already on the python3 branch, which is actively maintained by upstream.

I orphaned the packaged because 0b100100 wouldn't stop harassing me via email long enough to let me get any meaningful work done, over the main holiday season of the year, when everyone is busy with not being on the PC.

Hi dhtseany, Thank you for stepping in as the new maintainer. What speaks against the daily builds? Will they be dropped by upstream?

The non-flatpak version still compiles on Arch, so I don't see a reason to wait until something changes upstream. Furthermore, if the package does not get updated it will end up as an orphan again.

The following PKGBUILD file is what I have come up with (newest version with some cleanup done): http://ix.io/3HVJ

FYI: The python3 branch of chirp (directly cloned from the mercurial repository) is already on AUR [1]

[1] https://aur.archlinux.org/packages/chirp-hg-py3/

edit: added some further info

Hi everyone, I just took ownership of this package since I've been actively following along with development of the py3 version of chirp. For the time being the unpopular but technically functional flatpak version works with installation instructions provided in another recent comment I made. In the mean time I'd appreciate your patience while we wait for upstream to release something that I would at least consider a beta level product. Once there's something to maintain I'll be happy to have co-maintainers help me out but for right now there's not much help needed.

Hi ashleyr, Thank you for maintaining this great package until now. I would be delighted to jump in as a (co-)maintainer.

Hi Everyone,

I am no longer able to make any progress on keeping chirp up to date for a number of reasons. Not the least of which is I no longer can run it on my installation due to Python2 being deprecated.

Therefore I'm going to disown the package, and hope that someone else can take it on.

73's. Ash.

@max_meyer I don't have the ability to verify that the build works as I have no python2 packages any longer.

I've updated the PKGBUILD after verifying the version and hash match, however there is no solution yet from upstream to support python3.

I'm happy to keep bumping the build along if people let me know, but there is little I can do to verify it.

@ashleyr Would you mind updating the package? I also updated the hash value. Thank you.

# Maintainer: Erez Raviv (erezraviv@gmail.com)
# Maintainer: Ashley Roll (ash@digitalnemesis.com)
pkgname=chirp-daily
pkgver=20210724
pkgrel=1
pkgdesc="Latest build for GUI tool for programming ham radios"
arch=('any')
url="http://chirp.danplanet.com/"
license=('GPL3')
depends=('python2-lxml' 'python2-pyserial' 'pygtk')
optdepends=('hamradio-menus')
options=(!emptydirs)
conflicts=(chirp)
provides=(chirp)
install=
sha256sums=('6b793a155c3639ffa2bfe34042fffce7d64a8bccd54aba375a85827c34fdad71')
DLAGENTS=("https::/usr/bin/curl -k -o %o %u")
source=("https://trac.chirp.danplanet.com/chirp_daily/daily-$pkgver/chirp-daily-$pkgver.tar.gz")

build() {
  tar xvf $pkgname-$pkgver.tar.gz
}

package() {
  cd "$pkgname-$pkgver"
  python2 setup.py install --root="$pkgdir/" --optimize=1
}

I think we all need to take a step back and remember that we're here for the Arch-specific packaging and installation process, not the primary development branch to submit bug reports. The people receiving the comments are likely getting annoyed with all of the Python-hate they keep receiving, even though upstream are the people who should be receiving the flak for this. Don't blame the AUR maintainers for problems outside of their span of control. The instructions for the flatpak method, while not ideal, will get us why while the upstream devs sort this out so consider that we're all here complaining about problems that technically have a fix to get back in business, and even if you don't like the fix, it's still an option and will get us by for a few more months while we wait on upstream. Please be more chill with each other, especially when we're talking to package maintainers who are doing this for free.

python2-lxml and python2-pyserial have been yeeted out of community, however due to bugs with AUR that are pending are blocked from being added to AUR.

python2-pyserial is easy to get compiled, python2-lxml adds a whole bunch of py2 deps that I've already purged from my system, and really really not spending the time getting python2 to work.

Python2 EOL'd in Jan 2020. This was a 5 year, yes, 5 year extension from 2015. It was announced in 2010.

10 years to see this shitshow coming, and I vividly remember all the pants shitting and doomsaying about how py3 was some unholy conspiracy about something, so people just continued to both not port, and write py2 progs. Now, a year and change after py2 deps are being removed from Arch, slowly because ITS UNSUPPPORTED

Yea, does not install because of phython2 deps. Flatpak version does not work. Plus flatpak sux. Removed all flatpak software and flatpak itself.

I ain't gonna be using this software. Remove this from AUR it's out of date.

@dhtseany Thanks for the flatpak details. Hopefully that will enable people to keep using chirp, until a python3 version is released. Its not ideal, but we can't control either end of the dependencies..

Unfortunately I can't add you as a co-maintainer because I am not the maintainer, just another co.. @gearshift would have to add you. I've just been keeping the version mostly up to date as people let me know it needs updating.

If anyone finds out that a python3 version is available (even for test) please let me know and I'll do my best to get it going again. I don't often look at the chirp web site, so pinging me here is the best bet.

Cheers, Ash.

@ashleyr Thanks for your reply and don't get discouraged, there's still hope that we can get this sorted! First, if you need a co-maintainer go ahead and promote me and I'll be happy to lend a hand on this one as I'm just getting into using Chirp and I see myself using it for a while.

I've been researching the progress of Chirp's move from py2 -> py3 and I can see from their development branch that they've been making progress, as recently as March 7th 2021 so it isn't like the project went dead. I think with a little bit more patience those of us on Arch should see this fixed sooner than later.

In the meantime, for those users like myself who landed here and need to get this app working, here's my workaround that got me to a point of download/uploading my config from my Baofeng UV-5R:

1. Install flatpak:

$ sudo pacman -S flatpak

2. Next go to the Chirp download page and download the latest .flatpak file (as of writing this it's chirp-daily-20210310.flatpak)
https://trac.chirp.danplanet.com/chirp_daily/LATEST/

3. Install the .flatpak file:

$ sudo flatpak install chirp-daily-20210310.flatpak

4. The easiest way I could get Chirp to communicate with /dev/TTYUSB0 was to run the app as root so first su to root:

$ sudo su

5. Finally, run the app with it's full name:

# flatpak run com.danplanet.chirp

Disclaimer: Much like docker and other container-based images, it's not advisable to run a flatpak as root however in this case setting my normal user as a member of the group uucp didn't help so the su -> flatpak route was the only way I could get it communicating.

It seems that we are between a rock and a hard place.

https://chirp.danplanet.com/issues/7859 https://chirp.danplanet.com/issues/495 https://chirp.danplanet.com/issues/7431

Arch has dropped/is dropping support for python2, as are most of the other distros.

The Chirp Devs have known about this for a long time, but we have not seen a python3 compatible version yet.

The Chirp Devs are suggesting that people try using the flatpak available for download. Details in the first list (Bug 7859)

I'm afraid I am out of my depth trying to get this package running again, so I'll have to bow out of maintaining it, sorry.

Hi, python2-lxml and python2-pyserial are no longer valid packages.

Edit: Through a bit of trial and error I can confirm that python-pyserial is not a drop-in replacement for python2-pyserial as I catch errors during the build if I update the PKGBUILD manually to require the dependencies list.

Anyone got any ideas what happened to python2-pyserial?

Here is an updated PKGBUILD for the 20210310 version

# Maintainer: Erez Raviv (erezraviv@gmail.com)
# Maintainer: Ashley Roll (ash@digitalnemesis.com)
pkgname=chirp-daily
pkgver=20210310
pkgrel=1
pkgdesc="Latest build for GUI tool for programming ham radios"
arch=('any')
url="http://chirp.danplanet.com/"
license=('GPL3')
depends=('python2-lxml' 'python2-pyserial' 'pygtk')
optdepends=('hamradio-menus')
options=(!emptydirs)
conflicts=(chirp)
provides=(chirp)
install=
sha1sums=(54729ac1e888f3fe8fa61f78f1e30a59c9d1b2e3)
DLAGENTS=("https::/usr/bin/curl -k -o %o %u")
source=("https://trac.chirp.danplanet.com/chirp_daily/daily-$pkgver/chirp-daily-$pkgver.tar.gz")

build() {
  tar xvf $pkgname-$pkgver.tar.gz
}

package() {
  cd "$pkgname-$pkgver"
  python2 setup.py install --root="$pkgdir/" --optimize=1
}

works fine on my TYT with $sudo chirpw

Thanks @gearshift, I pushed the 20200807 update. Let me know if there are any issues.

Thanks ashleyr, I added you as a co-maintainer. blacknight, if more help is needed I'll ask again in the comments.

I would be willing to help co-maintain also.

@gearshift I'd be happy to take on the co-maintenance of the package with you.

@gearshift I don't use chirp very often, so I'll decline. I'm also deleting my other package now that this one is up-to-date.

ashleyr or kiankasad, if you are still interested in helping out I can add you as co-maintainers.

I created another PKGBUILD which will fetch the latest version automatically. Unfortunately, it isn't as secure, because the SHA-1 hashes can't be created dynamically. For now, I've created a new package, chirp-daily-latest. If you'd like to incorporate this PKGBUILD, I'll go ahead and delete that other package.

PKGBUILD with latest version: https://pastebin.com/xntanAHW

gearshift, I've prepared an update to the latest version if you want it.

I'm new, but if you are looking for help maintaining, I'd be happy to take on a co-maintainership.

Thanks gearshift, latest update seems to be working great and has solved my issue!

kayin_zz, I often forget to update it so flagging it as outdated helps. If you think you can do a better job I can add you a a co-maintainer.

chrismin13, I updated the package. See if you're still getting that.

Is this package still being maintained?

Whenever I build this, my default application for opening directories gets changed from Nautilus (GNOME's File Manager) to CHIRP. Could you please address this issue in the next update?

Here's the output of gio mime inode/directory:

Default application for “inode/directory”: chirp.desktop
Registered applications:
    chirp.desktop
    org.gnome.Nautilus.desktop
Recommended applications:
    chirp.desktop
    org.gnome.Nautilus.desktop

lehthanis, according to the CHIRP website https://chirp.danplanet.com/projects/chirp/wiki/Running_Under_Linux it doesn't require python2-suds so I removed it from the dependencies.

What are we supposed to do about missing python2-suds now?

Seeing as zashi didn't bother fixing things before disowning it, I fixed them myself. It should work now.

erezraviv please let me know in a comment if you're going to continue maintaining this package because I really want to give it back to you. I already added you as a co-maintainer.

I remembered why I disowned this package in the first place. I started using chirp-hg.

@zashi Why did you change (and break) the source url format and replace the upstream supplied sha1sum with your own md5sum? You should reverse your changes back to what is was originally. Then all you need to do is update the pkgver and sha1sums to the newest versions (20190205 and 37be6e6f5d05704c73589d4075725947fe16ca29).

Don't forget to increment pkgrel after updating.

I generated it, it was wrong. I generated it again. Thought I had it fixed. So annoying >_<

I'll fixit (I hope).

I generated it, it was wrong. I generated it again. Thought I had it fixed. So annoying >_<

I'll fixit (I hope).

Looks like the checksum has a mismatch for the download. Just FYI.

Thank you!

oops. Comma removed

The comma between pygtk and python2-suds needs to be removed to build correctly.

Good catch. I'll add it

FYI importing remote data sources (ie: radioreference.com) requires python-suds or python2-suds -- I just installed both:

Suds library required for RadioReference.com import. Try installing your distribution's python-suds package.