hashcash
Build times (auto-updated)
- x86_64: 54s (2026-10-19 18:14 UTC, MAKEFLAGS=-j6)
- i686: 51s (2026-10-19 18:15 UTC, MAKEFLAGS=-j6)
- pentium4: 59s (2026-10-19 18:16 UTC, MAKEFLAGS=-j6)
Category: local-install (rebuilt only so archlinuxaba/the cluster gets it too;
not maintained/adapted/owned by us — see arch/scripts/install_only_packages).
First-time addition, no prior checkout on this machine.
Denial-of-service counter-measure tool for email/spam.
Build notes (2026-08-19)
- Same pattern as
openssl-1.0: upstreambuild()already branches on${CARCH}(make generic-opensslfor x86_64,make x86-opensslfor everything else) butarch=('x86_64')only ever exposed the x86_64 path. Extended toarch=('x86_64' 'i686' 'pentium4')– built cleanly on all three arches on the first try. pkgrel5->5.1(local-install, X.Y scheme).
2026-10-19: catch-up bump 5.1 -> 29.1, cluster had a newer local install than archlinuxaba
User reported a pacman -Syu warning on a cluster node: local (1.22-29) is
newer than archlinuxaba (1.22-5.1). Investigated where 1.22-29 could have
come from: real AUR upstream (azon) is still at 1.22-5; checked
archlinux32/Erich Eckner’s repos too (archlinux32/packages only patches
official core/extra packages, no AUR packages there at all; Eckner’s
crux.eckner.net CRUX ports do carry hashcash, but was unreachable to fetch
directly, and the only signal available – search-engine snippets – suggested
an even lower release there, not higher). No explanation found for 29 –
most likely a one-off local rebuild on that cluster node that never made it
back into this project’s tracked PKGBUILD.
Per the established precedent for this exact situation (see
memory/PKGREL_VS_PKGVER.md’s pcmciautils case: “go forward from whatever is
already live, never back to what would’ve been ideal”), bumped straight to
29.1 rather than trying to reconcile with AUR’s real 5. Built+published
cleanly on all 3 archs (x86_64/i686/pentium4).