Arch Linux User Repository

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

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

@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

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.

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 setup.py 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 `__init__.py` 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.

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 <nmlibertarian@gmail.com> # Contributor: Erez Raviv (erezraviv@gmail.com) # Contributor: Mathew Hiles (matthew.hiles@gmail.com) # Contributor: David Thurstenson thurstylark@gmail.com # 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="http://chirp.danplanet.com/" 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+http://d-rats.com/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' setup.py # Good idea de: David Thurstenson thurstylark@gmail.com date +%Y%m%d > build/version export VERSION=$(cat build/version) sed -i -e 's/^CHIRP_VERSION.*$/CHIRP_VERSION=\"'$VERSION'-arch-dev\"/' chirp/__init__.py # 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 setup.py build # 'grep python2 setup.py 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 "setup.py install" invocation as used below in package() . } package() { cd $srcdir/$pkgname python2 setup.py install --root="$pkgdir/" --optimize=1 install -m755 chirpc $pkgdir/usr/bin # A *very* cool binary that is not included when using the '...setup.py 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 # '...setup.py install...' (They are the ONLY form of docs for these binaries !) } md5sums=('SKIP') sha256sums=('SKIP') **END**