Package Details: chirp-hg 1:r2879.2c4bb936f964-1

Git Clone URL: (read-only, click to copy)
Package Base: chirp-hg
Description: GUI tool for programming ham radios, built from hg repo
Upstream URL:
Keywords: ham radio uhf vhf
Licenses: GPL3
Conflicts: chirp
Provides: chirp
Submitter: thurstylark
Maintainer: thurstylark
Last Packager: thurstylark
Votes: 26
Popularity: 0.006793
First Submitted: 2016-06-04 04:37 (UTC)
Last Updated: 2017-04-18 17:15 (UTC)

Required by (1)

Sources (1)

Latest Comments

MarsSeed commented on 2022-07-01 20:16 (UTC) (edited on 2022-07-01 20:16 (UTC) by MarsSeed)

And I also suggest that you implement a Mercurial tag based pkgver().

The following code will generate a version like 0.4.0.r1282.gc965de0b862b:

pkgver() {
    cd chirp.hg
    hg log -r . --template '{latesttag}.r{latesttagdistance}.g{node|short}\n' | sed 's/^release_//;s/_/./g'

MarsSeed commented on 2022-07-01 20:06 (UTC) (edited on 2022-07-01 20:06 (UTC) by MarsSeed)

Please kindly enable testing in PKGBUILD's check() function.

Test dependencies (a.k.a, checkdepends) for [testenv:unit] and [testenv:driver] are available on AUR.

0b100100 commented on 2021-12-08 10:02 (UTC) (edited on 2021-12-08 10:19 (UTC) by 0b100100)

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

micwoj92 commented on 2021-12-03 20:14 (UTC)

Probably can be fixed if you install libffi7 package.

davvore33 commented on 2021-12-03 20:11 (UTC)

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/", line 26, in <module> import gtk File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/", line 30, in <module> import gobject as _gobject File "/usr/lib/python2.7/site-packages/gobject/", line 47, in <module> from gobject.constants import * File "/usr/lib/python2.7/site-packages/gobject/", line 24, in <module> import gobject._gobject ImportError: cannot open shared object file: No such file or directory

might be a problem with python2

thurstylark commented on 2017-04-20 15:04 (UTC)

Specifically regarding the inclusion of chirpc: Upstream confirmed that it's not ready for release, and not getting very much development attention[1]. In this case, I will avoid putting it in the main package for the time being. Since it's still useful, I'm considering adding a split package just for chirpc and its documentation. [1]:

thurstylark commented on 2017-04-19 15:00 (UTC)

Not only was it poorly written (removed necessary quoting, unnecessary use of export, unnecessary file creation, inconsistent/ambiguous pkgver creation, superfluous build() function, inclusion of unreleased software...), it was an exact copy of chirp, and it was done despite my numerous attempts to communicate these exact objections.

Scimmia commented on 2017-04-18 22:38 (UTC)

Muflone, if you look at the commit he made it should be obvious why. It was complete and total crap.

muflone commented on 2017-04-18 21:18 (UTC)

@thurstylark Is there a reason to have just removed not_anonymous from the package co-mantainers, immediately after the packages merge?

muflone commented on 2017-04-09 23:10 (UTC)

@thurstylark please co-maintain this package together with not_anonymous, maintainer of the chirp package as we'll merge the chirp package into chirp-hg

muflone commented on 2017-04-09 23:09 (UTC)

I'm not YET going to delete this package as I hope the chirp and chirp-hg maintainers will agree in merging chirp into chirp-hg. This package has no reasons to exist and the updated PKGBUILD to fetch sources from hg confirms the deletion reasons. So not_anonymous, please ask to thurstylark to comaintain the chirp-hg package together, then please file a request to merge this package into chirp-hg.

thurstylark commented on 2017-03-27 17:40 (UTC)

I'm going to reiterate Scimmia's comment: Explanations of why you're doing things wrong doesn't change that they're wrong. Since nothing has changed on this front, my comment from 2017-03-07 remains relevant. I will refrain from repeating myself. ---- The pkgver function is out of line for this situation for reasons detailed in my previous comment. I totally understand what you are trying to accomplish by using a versioning format closer to upstream, but the problem is that this format lacks the accuracy necessary for meaningful troubleshooting because it is ambiguous. I also agree that the ability to use that version number format is advantageous for enabling the version check code that exists in the project, but again, it's checking against a semi arbitrary number because of the way it was generated. And this is the crux of the pkgver issue: It is wholly inappropriate for a PKGBUILD to *generate* a version number. A version number *must* be fetched or discerned from upstream. This is a difficult issue for this software in particular because the canonical "stable" release is automatically generated from a mercurial repo. According to Arch packaging guidelines, a non-VCS package should be pulling a fixed source, but that would mean updating the pkgver manually every day like chirp-daily. A VCS package like chirp-hg will pull the latest sources and use unambiguous versioning, but it suffers the issues that all VCS packages have; namely, the user will see confusing version numbers and cannot be alerted of a new version. I'm not saying I have the answer for this problem, or that chirp-hg is the answer for this problem. I *am* saying that the pkgver and prepare functions as they exist in cd801b5 is *not* a valid solution to the problem. ---- The inclusion of hamradio-menus as a hard dependency is still incorrect. Some people do not care about or do not use desktop files for launching graphical programs, so requiring a package whose sole purpose is to handle the included desktop files is inappropriate. Admittedly the inclusion of desktop-file-utils as a hard dep to chirp-hg was cargo-culted from the PKGBUILD I used a template, and should also be moved to an optdep. ---- Including a superfluous build function in this PKGBUILD cannot be justified by saying other python packages do the same, especially in this situation where the `build` command to is undefined *and* is not a step used in the upstream installation documentation. This is cargo-culting at its finest, and should be removed. ---- Installing scripts that are not included with upstream source releases, and are not included in the install procedure (as defined by upstream) are not appropriate to include in a release package. Such scripts are most commonly still in development and are not suitable for release. It is upstream's decision to include or exclude parts of its code in releases. The exclusion of these scripts does not make the package incomplete. Completeness is defined by the upstream source. If one still wishes to package these scripts, I suggest making a separate package named 'chirp-experimental' or similar which contain just the scripts in question and their documentation. ---- As far as merging, I propose merging chirp-daily with chirp. Keep chirp-daily's pkgver, source, and update situation (manually updating), and only update on a monthly or similar basis after testing for stability. This does away with the need for a pkgver function altogether, enables the use of the pkgver in `` for version checking, and removes the ambiguity born of generating a pkgver using date(1). Additional changes should include removing the build function wholesale (from both chirp and chirp-daily), moving hamradio-menus to an optdep, adding and populating a checksums array, improving the prepare function by using $pkgver in place of $VERSION in the sed command, fixing the quoting in the sed command, and removing the two lines above it. Making these changes to chirp will bring this package and its related packages more into line with Arch packaging standards, and will provide a user experience similar to the majority of other AUR packages by reducing confusion due to fragmentation. These changes also allow space for chirp-hg to continue existing as is: to serve the same purpose as other VCS packages.

thurstylark commented on 2017-03-27 14:33 (UTC)

Because we cannot guarantee the permanence of the information given in a pastebin reply, I'm reposting the previous comment here. Please comment *here* in the future so the conversation is all in one place. **BEGIN** # NOTES: 15-MAR-17 # FIVE important items to consider (now that there is a TU that is considering # merging the three "chirp" packages; chirp (this package), chirp-daily, and chirp-hg); # # - The 'pkgver()' for this package allows the software to alert the user of an upgrade # when the program is started. This is an important feature the upstream authors have # written into the program. The "conventional" hg 'pkgver()' script (as used in the # chirp-hg PKGBUILD) does NOT enable this feature. # # - The 'prepare()' for this package is also required for this "alert' feature to work. # Again the prepare() in the "chirp-hg" PKGBUILD will not allow this to work. # # - There are numerous examples of packages that use vcs repos but for various reasons # do NOT use "-<whatever/vcs>" in the 'pkgname=' as there are no stable release and therefor # no need to differentiate it from another PKGBUILD that represents the 'stable-release'. # # - The current "chirp-hg" and "chirp-daily" PKGBUILDs do not install ALL of available binaries # and their associated help-documentation. # # - The "chirp" PKGBUILD has been part of the aur for a very long time (8 years ???). # The "chirp-daily" and "chirp-hg" PKGBUILDS are *much* newer. Merging ALL three PKGBUILDs will # not accomplish anything of value since ALL of the code in ALL three of the current PKGBUILDS # comes from the very same upstream repo. (** The tarball that "chirp-daily" uses is automatically # generated whenever this upstream repo is changed BUT does not contain all of the upstream coding.) # # # SUGGESTIONS for the TUs. # # ^^^^ What is to be done then ? Well, the chirp-hg repo is redundant, newer, and does NOT # have anything to offer that this PKGBUILD doesn't have. Any decision on merging # should take this into account. Since the "Maintainer:" of the "chirp-hg" PKGBUILD is cited in # two places below, his PKGBUILD can be "merged" into this one. (And I would suggest leaving # the chirp-daily PKGBUILD as is, as it *DOES* represent a working verion (albeit incomplete). # # # Maintainer: not_anonymous <> # Contributor: Erez Raviv ( # Contributor: Mathew Hiles ( # Contributor: David Thurstenson # Contributor: Nicholas Tryon (KC2YTG) <dhraak at gmail dot com> # I would hope all package Maintainers would eagerly seek out all # previous contributors to the packages. So..I am restoring those # names I can find AND adding the names of the contributors to # the chirp-hg & chirp-daily PKGBUILDS . pkgname=chirp # Although this package is sourced from an hg repo, the authors do NOT distribute # "releases". Instead automatically generated tarballs that are created # **EVERY** time there is **ANY** change in the hg-repo. Also see the notes above. pkgver=20170306 # Because the automatic releases mentioned above are referenced by date; I am using # the same coding in pkgver() & prepare() that the upstream authors are using to tag # the tarball releases. More on the internal tagging (Help-About, for instance) # below in comments in the prepare(), AND in the notes above. pkgrel=1 pkgdesc="GUI tool for programming Ham Radios - COMPLETE version" # "COMPLETE" i.e. contains ALL of the docs and executables as mentioned below # in package(). Although the hg-repo has all the docs and binaries the author's # recommended install procedure does NOT install all of them !! (Go figure..) # Please see the comments below in package() . arch=('any') url="" license=('GPL3') depends=('python2-lxml' 'python2-pyserial' 'pygtk' 'hamradio-menus') # The upstream author's (included) .desktop file will not be used UNLESS the # associated 'hamradio-menus' package is installed. ** so..'hamradio-menus' really # isn't an optdepends. & 'desktop-file-utils' is already in the dep. tree w/ the # inclusion of 'hamradio-menus' . makedepends=('mercurial') options=('!emptydirs') provides=('chirp') conflicts=('chirp-daily' 'chirp-hg') install=$pkgname.install # This file has important instructions to the end user on how to get control over # the serial ports, hence it is included. source=("$pkgname::hg+$pkgname.hg") pkgver() { cd $srcdir/$pkgname date +%Y%m%d # The upstream authors automatically use dating everywhere else. # Please also see the notes above in pkgver= & below in the prepare() as well as # the notes above. } prepare() { cd $srcdir/$pkgname sed -i -e 's|/usr/sbin|/usr/bin|g' # Good idea de: David Thurstenson date +%Y%m%d > build/version export VERSION=$(cat build/version) sed -i -e 's/^CHIRP_VERSION.*$/CHIRP_VERSION=\"'$VERSION'-arch-dev\"/' chirp/ # This coding above is the SAME coding as the authors' are using when # creating their "daily-release" tarballs, and seemed VERY approriate to use here. # # It does a couple of important things; # - Enables the use of an included software feature that alerts the user of a new # release. # - Replaces the tag shown in the Help-About window. This tag is from when the # authors were using this upstream repo for unstable development work. # (This repo tagging has never been changed, and still shows version 0.3.0-dev.. # and the last stable release was 0.4.1 !!! <- It appears that this software is NOW # using a "rolling release" model and the "stable-release" model has been abandoned.) } build() { cd $srcdir/$pkgname python2 build # 'grep python2 build -r /var/abs' will show this is a great way to # handle python builds !! It can also prevent some odd/unwelcomed runtime behavior # if there was only the " install" invocation as used below in package() . } package() { cd $srcdir/$pkgname python2 install --root="$pkgdir/" --optimize=1 install -m755 chirpc $pkgdir/usr/bin # A *very* cool binary that is not included when using the ' install...' # And for some unknown reason this is also left out of the upstream tarballs that # are used in the chirp-daily arch package ! In fact several useful exec. binaries # are left out of the chirp-daily's upstream tarball but are in the hg-repos. # ^^^ Go figure !! rm -rf $pkgdir/usr/share/doc/$pkgname/COPYING # This license is already installed in correct location. This is both redundant # and un-necessary in archlinux. install -m644 README.chirpc $pkgdir/usr/share/doc/$pkgname install -m644 README.rpttool $pkgdir/usr/share/doc/$pkgname # Docs that are NOT installed for included binaires when using the # ' install...' (They are the ONLY form of docs for these binaries !) } md5sums=('SKIP') sha256sums=('SKIP') **END**

Scimmia commented on 2017-03-09 00:20 (UTC)

Explanations of why you're doing things wrong doesn't change that they're wrong.

Scimmia commented on 2017-03-08 04:15 (UTC) (edited on 2017-03-08 04:49 (UTC) by Scimmia)

not_anonymous, before getting all high and mighty, you might want to look at your PKGBUILD. It has many problems, not the least of which is that the pkgname is wrong.

thurstylark commented on 2017-03-07 21:23 (UTC)

A few questions/comments regarding the update to this package: What dev-mode hooks are missing from chirp-hg and chirp-daily that this package enables? I am unable to find anything different about this package in comparison to the others that would enable such a feature. Even though upstream uses a date for versioning, using date(1) for $pkgver is unwise for a few reasons: 1. The PKGBUILD uses date(1) without specifying a timezone which can result in variations between users based on their configured timezone 2. While a date might be much more human-readable than the mercurial revision ID, it misrepresents the true contents of the package as they exist on the user's machine. A revision ID communicates exactly what existed in the upstream repository before installing 3. Because of the prior two points, using the date for $pkgver fosters miscommunication between the users and developers/community when asking for support, as the developers/community will assume by the format that the version number refers to the release of that same version when it does not. pkgver() seems to do some interesting things, but most importantly, it uses export on a generically named variable, which has the potential to break many things. Past that, it calls date(1) just to put its output into a file, then turns around and puts the contents of that file in a variable using cat in a subshell, *then* uses that variable in a sed command. Furthermore, the desired string *already exists* in $pkgver, so the first two parts of this series of commands are completely superfluous. Why is build() being used to run `python2 build` when the upstream documentation never mentions needing to do such a thing for installing in a Linux environment? hamradio-menus should be an optional dependency, and not a hard dependency. Unlike the other packages in the depends array, hamradio-menus is not necessary for the operation of this application.

thurstylark commented on 2017-03-07 19:12 (UTC)

pacaur has problems with .SRCINFO regarding VCS packages. I cannot (and should not be expected to) test with every AUR helper out there. If pacaur or another AUR helper doesn't work properly, use makepkg directly.

65b commented on 2016-12-04 00:18 (UTC)

Check .SRCINFO for mismatching data with PKGBUILD. Fails upgrade in pacaur

GI_Jack commented on 2016-11-05 22:42 (UTC)

-- Exception: -- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/chirpui/", line 227, in run self.__radio.sync_in() File "/usr/lib/python2.7/site-packages/chirp/", line 642, in sync_in raise errors.RadioError("Failed to communicate with radio: %s" % e) RadioError: Failed to communicate with radio: 'Serial' object has no attribute 'setTimeout

xyproto commented on 2016-09-22 12:00 (UTC)

This package is pinned to a commit/tag/branch/version (which is currently version 0.4.1, by dowloading chirp-0.4.1.tar.gz). The "-git" suffix is normally only used when the package is not pinned to any specific version, but always use master/HEAD. I think this package is fine like it is.

thurstylark commented on 2016-06-04 02:17 (UTC)

Since chirp moved to a rolling-release model, I suggest taking this package down and letting chirp-daily become the main package.

hax404 commented on 2014-11-18 16:58 (UTC)

0.4.1 is out

commented on 2014-05-03 18:42 (UTC)

0.4.0 PKGBUILD @

commented on 2014-03-25 17:39 (UTC)

0.4.0 is out, flagged.