aurupdater

swig4.4

Build times (auto-updated)

2026-11-04: removed .nvchecker.toml – was producing a permanent false UPD

A full update_cycle.sh run flagged UPD maintained/swig4.4 4.4.0 4.5.1 – investigated before acting (per the project’s “verify before acting on a flag” convention) and checked this file’s own history first: this package is deliberately pinned to 4.4.0 (the last release with working Python 2 SWIG codegen, used by [[obexftp]]) – bumping to 4.5.1 would defeat the entire point and break obexftp’s Python 2 bindings again. Did not touch the PKGBUILD.

Root cause of the false flag: .nvchecker.toml tracked real upstream swig’s git tags directly, with no .nvchecker-gate.toml – since this package is permanently behind by design, that config would flag “UPD” on every single future cycle forever, pure noise. User confirmed: removed .nvchecker.toml entirely (not gated – there’s no future version to wait for, this isn’t a temporary “upstream is ahead of Arch’s repackage” situation like [[libarchive-static]]’s gate use case). Package now shows as untracked (“?”) in check_for_updates_maintained.sh, same as other intentionally-static packages. If the Python 2 SWIG situation is ever revisited, re-add tracking then.

2026-11-01: created to unblock obexftp’s Python 2 bindings, then moved private/ -> maintained/ for a real AUR submission

Category correction: first created under private/ (reasoning: not based on any existing AUR page, same rationale as [[cmake2]]/ [[elasticsearch6]]/[[optdb5.3]] – “last version before upstream did something that breaks a local need”). User corrected this immediately after: since the plan is to publish it to AUR as a real public package, it’s obviously maintained/ (per arch/README.md: “maintained” = we are the AUR maintainer of it), not private/ (“not suitable to be published on the AUR”). The build recipe itself (pinning an old release) is the same shape of thing private/’s existing examples do, but that’s not what decides the category here – whether it ends up as a real public AUR package does. Moved via rm -rf private/swig4.4 + scripts/add_maintained.sh swig4.4 (the project’s own new-AUR-submission tool – handles the “are we really the AUR maintainer” check, which correctly no-ops here since the package doesn’t exist on AUR yet), then copied the PKGBUILD back in and regenerated .SRCINFO. Rebuilt+published again from the new location to confirm the move didn’t break anything – clean, same 4.4.0-1. Not yet actually pushed to AUR – that’s the user’s own step (git add/commit/push in maintained/swig4.4, same as every other package this project maintains); this entry documents the package, not that the AUR page exists yet.

Root cause chain: [[obexftp]]’s 2026-10-19 perl-ABI rebuild attempt failed in its Python SWIG bindings (clientPYTHON_wrap.c:1280:3: error: "This version of SWIG only supports Python >= 3.5") because the official swig package (4.5.1-1) dropped Python 2 wrapper-code generation. User decided then to leave obexftp alone rather than disable Python bindings or port to Python 3, flagging “fork an older swig” as a future direction.

Researched the exact cutoff by cloning github.com/swig/swig and searching Lib/python/pyrun.swg’s history for the only supports Python error string: commit f505f2566 (“Python: Drop PY_VERSION_HEX= 2.7Python 2 path.git describe –tags f505f2566^confirms **v4.4.0is the last tagged release before that commit** -- confirmed directly by diffingpyrun.swgat that tag (still has thePY_VERSION_HEX < 0x02070000guard, no>= 3.5`-only error).

Package: _pkgname=swig, pkgname=swig4.4, built from git+.../swig#tag=v4.4.0, ./configure --prefix=/opt/swig4.4 (coexists with the real /usr-installed swig, same /opt/<pkgname> + suffixed-symlink pattern as [[cmake2]]’s “-2” binaries – here /usr/bin/swig4.4 and /usr/bin/ccache-swig4.4 symlink back to /opt/swig4.4/bin/). No check() – upstream’s own test suite needs ruby/java/tcl/php/lua/r/go/boost checkdepends, overkill for this pinned-version utility package. depends copied straight from the official swig PKGBUILD (libgcc libstdc++ glibc pcre2 zlib); sha512sums=('SKIP') for the git source, consistent with how this project treats git sources elsewhere.

Built+published cleanly first try, x86_64 only (matches obexftp’s own arch=('x86_64') – no reason to build other archs yet). swig -version reports 4.4.0; swig -swiglib correctly reports its own /opt/swig4.4/share/swig/4.4.0 (not the system swig’s lib dir) – verified the installed pyrun.swg there still has the Python 2 guard.

Used by: [obexftp] – confirmed working end to end: obexftp’s _obexftp-python.so built and ships in the package again, first time since the 2026-10-19 regression.

If another local package ever needs Python-2-capable SWIG codegen, point its build at /opt/swig4.4/bin/swig the same way rather than creating a second pinned-swig package.

2026-11-01 (same day): real git history, not a from-scratch PKGBUILD

User asked to merge in gitlab.archlinux.org’s official swig packaging history up to the 4.4 fork point – the same spirit as scripts/merge_gitlab_history.sh, but that script doesn’t apply mechanically here: it’s built to reconcile an already-diverged AUR history against gitlab’s tip (git merge --allow-unrelated-histories onto an existing master with commits), whereas maintained/swig4.4 had zero commits at the time and we specifically want gitlab’s history only up to 4.4.0, not its tip (4.5.1). A merge is the wrong verb when there’s nothing on our side yet to reconcile.

What actually happened instead, respecting [[feedback_never_git_commit_or_push]] throughout (no new commit created by me at any point – only pointing a branch ref at an already-existing commit, and leaving content changes staged/unstaged exactly like every other PKGBUILD edit this session):

  1. git remote add gitlab https://gitlab.archlinux.org/archlinux/packaging/packages/swig.git && git fetch gitlab.
  2. Found the real fork point: git log --oneline main -- PKGBUILD in a scratch clone showed three commits at pkgver=4.4.0 before it moved to 4.4.1 (eef2178 4.4.0-1, 0ff4d87 4.4.0-2, 4261166 4.4.0-3 “rebuild with lua 5.5”) – took the last one, confirmed via the 4.4.0-3 tag (git rev-parse '4.4.0-3^{commit}' == 4261166...).
  3. rm -f PKGBUILD .SRCINFO (our from-scratch versions, already backed up to /tmp) then git checkout -b master 4.4.0-3 – this makes master point at gitlab’s own, already-existing commit, inheriting its entire real history (every swig packaging commit back to whenever this gitlab repo started), no merge commit needed since there was nothing of ours to reconcile against.
  4. Rewrote PKGBUILD as an edit on top of the inherited file (not a fresh file) – kept Felix Yan’s upstream prepare() fixes verbatim (the stl_no_default_constructor/li_std_list test-suite sed deletions, the R-crash cherry-pick b16a7c958a5...) since they’re genuine upstream fixes for this exact version, just swapped every $pkgname-as-directory-name reference to ${_pkgname} (the real extracted dir is still literally swig, from the git URL, regardless of what pkgname is renamed to – same _pkgname/pkgname split as the original draft, just layered onto real inherited content instead of writing it from nothing). Demoted Felix Yan et al. to # Contributor: lines, added our own # Maintainer:. Dropped check()/checkdepends (unchanged from the original draft’s reasoning – heavy test matrix, not needed for this scoped use). depends=('gcc-libs' 'glibc' 'pcre2' 'zlib') is this version’s real historical deps (differs slightly from the original draft, which had copied the current 4.5.1 PKGBUILD’s libgcc+libstdc++ split instead).
  5. Rebuilt+republished to confirm the rewrite still works – clean, same 4.4.0-1.

Net result: maintained/swig4.4’s master is a real fork of the official packaging lineage, not an orphan history starting from our own first commit – git log shows Felix Yan’s actual commits going back through every swig version bump, with our pin-to-4.4/rename/coexistence changes sitting as uncommitted content on top, ready for the user’s own first commit to seal the fork.