Package Details: chirp-next 20241101-1

Git Clone URL: https://aur.archlinux.org/chirp-next.git (read-only, click to copy)
Package Base: chirp-next
Description: GUI tool for programming ham radios, built from chirp-next
Upstream URL: https://chirpmyradio.com/projects/chirp/wiki/Home
Licenses: GPL-3.0-or-later
Conflicts: chirp, chirp-daily
Provides: chirp
Submitter: WT5A
Maintainer: WT5A (schinfo)
Last Packager: schinfo
Votes: 76
Popularity: 2.43
First Submitted: 2023-01-22 22:04 (UTC)
Last Updated: 2024-11-01 11:49 (UTC)

Latest Comments

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 Next › Last »

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.

not_anonymous commented on 2017-03-08 01:52 (UTC) (edited on 2017-03-08 04:03 (UTC) by not_anonymous)

- See this for info on installing licenses (that are already in the system via references in a PKGBUILD's license=) AND, perhaps more importantly where ALL license files should go !! ^^^^^ https://wiki.archlinux.org/index.php/PKGBUILD#license - namcap suggests that the function of desktop-file-utils is already being done with makepkg..and in fact it is !! ie. listing it as a dep is not required IF you do this next item: - hamradio-menus is NOT an optional dep *IF* you want this GUI based op to show up in the menus !!!

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

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 Next › Last »