aurupdater

cssh

2026-08-30: rebuilt against new upstream commit, 3 real fixes needed

User asked for a rebuild after noticing upstream had moved (git ls-remote confirmed a new commit, cbe71513e at request time, vs. the published g6c92d89). Since pkgver() self-computes via git describe, no manual pkgver/pkgrel edit was needed – makepkg’s own “pkgver changed -> reset pkgrel to 1” handled that automatically once a build actually succeeded. Landed at 0.0.1.r22.g5892097-1 (8 new commits pulled in fixes/tests since r14). Took 5 build attempts, each surfacing a genuinely new issue (none were repeats):

  1. 3rdParty/linenoise/linenoise.c fails to compile: strcasecmp() used without #include <strings.h> (only <string.h>, no ‘s’, was included – a real missing-include bug in the vendored antirez/linenoise copy, not something introduced by the new commits). Newer gcc treats the implicit declaration as a hard error rather than a warning. Fixed with a standalone patch, linenoise-strcasecmp.patch, applied via a new prepare() (this package had none before).
  2. check()’s CsshFunctional test needs ssh-keygen (openssh) and hostname (inetutils), neither previously declared. Added both to a new checkdepends=() array (this package had none before) – test-only, correctly kept out of makedepends/depends.
  3. CsshFunctional still failed after that: ERROR: authentication with public key denied. Root cause: cssh.c calls ssh_userauth_publickey_auto(session, NULL, NULL), which tries every SSH identity in $HOME/.ssh (or an agent) – the disposable build user has none. mock_sshd’s own handle_auth() accepts any key unconditionally (SSH_PUBLICKEY_STATE_VALID always wins once a signature is presented – it’s not doing real trust validation), so this was purely a missing client-side fixture, not a server-side or protocol bug. Asked the user how to handle it (three options: generate a throwaway keypair in check(), skip check() for this release, or hold off) since it’s about their own test suite’s environment assumptions, not a routine packaging gap like #2. They picked generating a throwaway keypair: check() now ssh-keygens a disposable $HOME/.ssh/id_rsa (idempotent, skips if one somehow already exists) before running ctest. Passed cleanly after that (100% tests passed, all 3 remaining local-arch attempts).

All 4 local archs (i486/i686/pentium4/x86_64) built, tested, and published cleanly at 0.0.1.r22.g5892097-1. armv6h/armv7h/ aarch64 were not rebuilt this round – the whole ARM cluster (eurobuild3/4/5/14) was down for the entire session (confirmed via ping at the start, and repo_build_remote.sh’s own NBD-reachability preflight failing identically on all three remote-arch attempts) – they remain published at the older 0.0.1.r14.g6c92d89-2. Follow-up needed once the cluster is back: rebuild just the ARM archs (REPO_BUILD_ONLY_ARCH="armv6h armv7h aarch64") to bring them up to r22 too – this is exactly the gap the Architectures overview column now surfaces automatically (see TOOLING_NOTES.md’s repo_arch_diff.sh entry).

Note for future VCS-package rebuilds via repo_build_staged.sh: it never copies the built PKGBUILD/.SRCINFO back from the staging dir to arch/ (by design – only release artifacts come back), so a non--git-suffixed VCS package’s tracked pkgver=/pkgrel= fields stay stale at whatever they were before the build, even after a real successful publish. repo_diff_local_remote.sh has no way to know this (its “-VCS” caution tag only fires for *-git pkgnames), so it briefly showed a misleading CHANGED (implying cssh needed a rebuild it had already gotten) until manually synced. Fixed by hand here (pkgver/pkgrel set to what 0.0.1.r22.g5892097-1 actually built as, regenerated .SRCINFO) – do the same after any future cssh rebuild that changes the version, or this will recur every time.

2026-08-31: ARM rebuild to r22 – armv7h clean, armv6h/aarch64 each hit a different snag

ARM cluster came back up after being down for the prior session. Rebuilt armv6h/armv7h/aarch64 (REPO_BUILD_ONLY_ARCH) to bring them from the stale r14 up to r22.

2026-08-31: user fixed both issues upstream, full 7-arch rebuild

User patched the real root causes directly in their own upstream repo (git.andreasbaumann.cc/cgit/cssh, commits through b31d3d4) rather than carrying local workarounds indefinitely:

User also committed the AUR PKGBUILD changes to git themselves (arch/owned/cssh submodule, “removed local patching for strings.h”).

Rebuilt/published all 7 real archs (i486/i686/pentium4/x86_64/armv6h/ armv7h/aarch64; arm still SKIPPED, no real build target) in one repo_release.sh run with REPO_BUILD_ONLY_ARCH set to just those 7 – all built, tested (100% pass, all archs), signed, and published cleanly at 0.0.1.r24.gb31d3d4-1. Synced the tracked pkgver/pkgrel in PKGBUILD and regenerated .SRCINFO by hand afterward (same VCS- package staging gap noted above – repo_build_staged.sh doesn’t copy these back).

2026-09-01: user rebuild request, upstream cscp change broke every arch

Upstream had moved again (git ls-remote showed 6bd0546e vs the published b31d3d4, commit message “implemented cscp both for SCP and TFTP - generated man pages - split tests into cssh and cscp tests”). First rebuild attempt (i486/i686/pentium4/x86_64/ armv6h/armv7h, aarch64 deliberately deferred since eurobuild14 was mid-build for an unrelated package at the time) failed identically on every arch, starting with i486 on a totally fresh chroot:

ln: failed to create symbolic link '.../usr/bin/cscp': File exists
==> ERROR: A failure occurred in package().

Root cause: src/CMakeLists.txt now installs the cscp symlink itself (install(CODE "... create_symlink cssh ... bin/cscp") – cscp is still just cssh dispatched by argv[0], per the comment above it, not a real second binary). The AUR PKGBUILD’s own package() still had a manual ln -s cssh "$pkgdir/usr/bin/cscp" left over from before upstream did this itself – now redundant and colliding. Fixed by deleting that line from PKGBUILD (man pages are still only installed manually, no similar collision there; provides= ('cscp') is still correct, cscp is still provided, just via cmake’s own symlink now).

Confirmed this was deterministic/upstream-caused, not environment/ leftover-state noise, by reproducing on i486 – the very first arch attempted, always a genuinely fresh chroot.

Rebuilt clean afterward, all 7 real archs (arm still SKIPPED) in one repo_release.sh run including aarch64 (freed up by then) – built, tested (100% pass everywhere), signed, and published cleanly at 0.0.1.r25.g6bd0546-1. Synced tracked pkgver/pkgrel + regenerated .SRCINFO by hand again (same recurring VCS-package staging gap).

Unrelated near-miss worth remembering: mid-session, a duplicate repo_release.sh arch/owned/cssh invocation was accidentally launched while the first was still running (both target the same /data/INSTALL/cssh staging dir) – caught and killed within seconds, confirmed no orphaned remote process and no artifact loss, but it’s a real hazard: never launch a second repo_release.sh/ repo_build_staged.sh for a package already building, check kill -0 <pid> (or ps) on any prior invocation first.