Arch Linux User Repository

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.

@davvore33: Can be fixed by rebuilding python2-gobject2 against the newest libffi package as the libffi.so.7 compat library got removed from libffi.

Probably can be fixed if you install libffi7 package.

freshly installed Traceback (most recent call last): File "/usr/bin/chirpw", line 131, in <module> from chirp.ui import mainapp File "/usr/lib/python2.7/site-packages/chirp/ui/mainapp.py", line 26, in <module> import gtk File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 30, in <module> import gobject as _gobject File "/usr/lib/python2.7/site-packages/gobject/__init__.py", line 47, in <module> from gobject.constants import * File "/usr/lib/python2.7/site-packages/gobject/constants.py", line 24, in <module> import gobject._gobject ImportError: libffi.so.7: cannot open shared object file: No such file or directory

might be a problem with python2

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.