Since chirp is now using CloudFlare and the download aborts with error 403 during build, I now used my own server for this. So I copy the current “chirp-${pkgver}.tar.gz” to https://schinfo.de/chirp/

This should solve the problem. Please let us know if anyone else has problems.

chirp-next-1:20260522-1 will build just fine, but I cannot run it. When running from console, I get:

ModuleNotFoundError: No module named 'yattag'.

On 2024-12-28 I see this should be fixed with python-yattag-1.16.1-1, but this is already installed. I tried re-installing it, but this also did not work.

Is there a newer version of python-yattag to be pulled in now? Or is it something to do with virtualenv/venv that Python cannot find it? (Python is a bit out of my wheelhouse, I don't know how to look deeper sorry). Thanks!

EDIT: I removed chirp-next and dependencies, cleaned the build directories, rebuilt, re-installed them and now it runs.

Since chirp is now using CloudFlare and the download aborts with error 403 during build, I now used my own server for this. So I copy the current “chirp-${pkgver}.tar.gz” to https://schinfo.de/chirp/

This should solve the problem. Please let us know if anyone else has problems.

Quick fix. If you have the package and the makepkg script (snapshot) from here, edit the PKGBUILD file to:

# Maintainer: WT5A <K5TRP[at]onlyhams[dot]ca>
# Maintainer: Helmut Stult <hst[at]e-mail[dot]de>
# Thanks to the maintainer(s) of chirp-daily

pkgname=chirp-next
pkgver=20260130
pkgrel=1
epoch=1
pkgdesc="GUI tool for programming ham radios (Local Source Build)"
arch=('any')
url="https://chirpmyradio.com/projects/chirp/wiki/Home"
license=('GPL-3.0-or-later')
depends=('python-pyserial' 'python-requests' 'python-suds'
         'python-yattag' 'python-wxpython' 'python-lark-parser')
optdepends=('hamradio-menus: XDG menus for ham radio software')
makedepends=('python-build' 'python-installer' 'python-wheel' 'python-setuptools')
options=(!emptydirs)
conflicts=('chirp' 'chirp-daily')
provides=(chirp)
install=$pkgname.install

# Pointing to the local file in the base directory
source=("chirp-${pkgver}.tar.gz")

# Since you have the file, we use 'SKIP' or the specific hash.
# I kept your hash here to ensure the file you have is the correct one.
sha1sums=('9b62a2aaedd1d9f54ca21be99761bf0ef91f791e')

build() {
    cd "chirp-${pkgver}"
    python -m build --wheel --no-isolation
}

package() {
  _site_packages=$(python -c "import site; print(site.getsitepackages()[0])")
  cd "chirp-$pkgver"
  python -m installer --destdir="${pkgdir}" dist/*.whl

  install -D -m644 "chirp/share/chirpw.1" "${pkgdir}/usr/share/man/man1/chirp.1"
  install -D -m644 "chirp/share/chirp.desktop" "${pkgdir}/usr/share/applications/chirp.desktop"
  install -D -m644 "chirp/share/chirp.png" "${pkgdir}/usr/share/pixmaps/chirp.png"

  # Ensure locale directory exists and copy
  mkdir -p "${pkgdir}${_site_packages}/chirp"
  cp -dr --preserve=mode,timestamp "chirp/locale/" "${pkgdir}${_site_packages}/chirp/locale"
}

Then makepkg -si as normal.

Given the cloudflare issue it might be better to build directly from git (I have not seen recent tags but if the release cycle is merely weekly (as it seems to be), it shouldn't be too hard to track it).

AFAIK this is the official repo https://github.com/kk7ds/chirp

EN: Issue by Cloudflare (Verifying you are human. archive.chirpmyradio.com needs to review the security of your connection before proceeding.)

RU: Крч чет разрабы врубили защиту от клауд и она не даёт курл скачать архив. Вот такие пироги)

There is issue with Cloudflare. Update is failing :/

Once the epoch has been set, it should not be removed again. Any release without the epoch set to 1 (or larger if needed) will be regarded as an older version.

EDIT: To provide some more context; you generally only ever need to use the epoch when the versioning scheme that the software uses is changed or if it has no stable versioning number (and you can't use a commit count or something).
Once the epoch is set, any package without it or a lower number will be regarded as outdated, a higher number is always more recent. If the epoch is equal, normal version matching is done (pkgver and pkgrel).
That means, you can really never ever remove it again, only keep the value set or increase it at some point in the future.

In most, if not all other cases, bumping the pkgrel is the way to go to trigger/force a rebuild if the software version(ing scheme) has otherwise stayed the same but things like the packaging have changed.

@schinfo I think you may eliminate the epoch parameters with the upcoming update cycle.

Problem is fixed with "epoch"

@schinfo Have you tried using the PKGBUILD's "epoch" feature?