Package Details: chirp 20170322-1

Git Clone URL: (read-only)
Package Base: chirp
Description: GUI tool for programming Ham Radios - COMPLETE version
Upstream URL:
Licenses: GPL3
Conflicts: chirp-daily, chirp-hg
Provides: chirp
Submitter: Dhraakellian
Maintainer: not_anonymous
Last Packager: not_anonymous
Votes: 22
Popularity: 0.514866
First Submitted: 2012-04-22 22:17
Last Updated: 2017-03-22 19:07

Required by (0)

Sources (1)

Latest Comments

not_anonymous commented on 2017-03-27 20:34

As you may have noticed; I am a "pro" user of pastebin, which means no pastebin file I create is
subject to automatic removal, so your concern about it disappearing would *only* be relevant if
I was to erase it. <- And this would be no different than erasing a comment here. i.e. There is
no reason to copy the my pastebins here. ** AND it clutters this area up !!

You are quite wrong about my using code not in the upstream source. In fact (and as I point out
in my pastebin !) the code I used for the pkgver() is directly in the upstream source, but is
NOT used in your "hg" package. It *IS* quite useful as I explain in the pastebin....

I could point out similar items that are wrong with your analysis, but they are of the nature of
my two comments above. Most especially when it comes to the build() section of my PKGBUILD. i.e.
Please check out for yourself how such things are being done in the ABS b4 suggesting that I am
doing something unusual, wrong, or un-warranted, as what I am doing is quite normal AND beneficial.

i.e. Please lets NOT go back and forth here on the same things. DIRECTLY and SIMPLY state your concerns
and then PLEASE read, in detail, my responses. This should not be a place for idle/repeating chatter IMHO.
We can, and should, do this kind of interaction "off-line" and perhaps come to some understanding there.

thurstylark commented on 2017-03-27 17:40

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

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.


# 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 .

# 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.
# 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.
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() .
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' .
conflicts=('chirp-daily' 'chirp-hg')
# This file has important instructions to the end user on how to get control over
# the serial ports, hence it is included.

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 !)


not_anonymous commented on 2017-03-15 20:05

My proposal to the TU considering "merging" the various chirps along with NOTES and SUGGESTIONS are at this link;

(This link also includes a complete explanation of "what" and "why" this PKGBUILD is scripted the way it is AND a comparison to the 'chirp-daily' and 'chirp-hg' packages.)

Scimmia commented on 2017-03-09 00:20

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

not_anonymous commented on 2017-03-08 11:18

**Everyone** please be patient, I am working out a way to fully explain ALL of the questions about this PKGBUILD and the install file in a simple, precise, and direct manner. It will be short and to the point as well !! This may take a few days, which is why I am asking for your patience. I promise that you will "get it". Really !!!!

not_anonymous commented on 2017-03-08 08:35

That's very funny as the name of the upstream package is also "chirp".

Scimmia commented on 2017-03-08 04:15

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.

not_anonymous commented on 2017-03-08 02:40

thurstylark, ALAS it would have been better if you waited a brief period of time for me to answer your questions BEFORE requesting a deletion. Heck I might have wanted to turn this over to you. I was hoping there might be some way you and I and the maintainer of chirp-daily could come to some agreement about how to consolidate the three PKGBUILDs since the upstream maintainers have (finally) abandoned the "stable-branch" and adopted a rolling-release. Now I am not so sure you will be receptive to input from others.

thurstylark commented on 2017-03-07 21:23

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.

All comments