aurupdater

thunderbird-esr140-bin

Build times (auto-updated)

Fork of [[thunderbird-esr-bin]], frozen on the Thunderbird 140.x ESR train.

2026-10-01: 140.16.0 -> 140.17.0, routine point release + background-task kill quirk

Routine nvchecker UPD flag from update_cycle.sh. Both tarballs (x86_64, linux-i686 shared by pentium4/i686) confirmed present on archive.mozilla.org before bumping; PGP key unchanged (checked proactively via update_pgp_key_dir.sh, no rotation this run, same key as [[thunderbird-esr-bin]]). updpkgsums clean across all 3 source groups.

Harness quirk, not a package problem: the repo_release.sh run for this package (and only this package, not [[mdcat]] or [[thunderbird-esr-bin]] built moments before) got killed twice in a row almost immediately after launch when run via the session’s normal backgrounded-bash mechanism – no OOM, no relevant process competing, no cron job at that moment. Worked around by launching it as a detached nohup ... &; disown process instead (invisible to whatever was killing the backgrounded task) and polling its PID directly. Left a stale .building.lock in /data/INSTALL/thunderbird-esr140-bin/ each of the two killed attempts – cleared by hand per repo_build_staged.sh’s own documented recovery (rm -rf .../.building.lock), confirmed via ps aux first that nothing was actually still running against it. If this recurs for other packages, try the same nohup/disown workaround before assuming a real build problem.

Build itself was clean: same known-harmless noise as before (gdk-pixbuf SVG-loader symbol lookup error/command failed to execute correctly in the disposable post-install chroot hook, and a namcap ImportError: libalpm.so.14 during i686 checkpkg from a 64-bit pyalpm mismatch) – neither affects the actual package; sign+publish succeeded cleanly for all 3 arches (x86_64/pentium4/i686), old 140.16.0-1 archived.

2026-09-16: 140.15.0 -> 140.16.0, routine point release

Now a real AUR submodule (the hand-off below happened between this entry and the fork one) – updated the normal way: confirmed both linux-x86_64/linux-i686 tarballs existed on archive.mozilla.org (HTTP 200) before bumping, updpkgsums (safe here, no bespoke checksum logic like linux-lts515), .SRCINFO regen, PGP key dir refreshed first. pkgrel stayed at 1. Built+published via repo_release.sh across all 3 archs (x86_64/pentium4/i686 – no ARM, Mozilla only ships x86 binaries for Thunderbird) cleanly; only noise was the known-harmless chroot post-install g_module_open() failed ... libpixbufloader-svg.so: libxml2.so.2 / “command failed to execute correctly” (gdk-pixbuf’s svg loader missing a lib in the disposable test-install chroot, not a real package defect – upload succeeded). Confirmed via repo_arch_status.sh against the live remote repo.

This was also the first real build to actually exercise the site’s new build-status instrumentation (build_status/*.status, see memory/TOOLING_NOTES.md’s 2026-09-15/16 entry) – confirmed working end-to-end against a real build for the first time (the previous attempt, linux-lts515, never got a chance to since its repo_build.sh invocation predated the edit). Also surfaced a real watch_current_builds.sh bug: it briefly self-terminated between the x86_64 and pentium4 phases because a single empty poll during the inter-arch gap looked identical to “done” – fixed there (now needs two consecutive empty polls).

2026-09-03: created, forked at 140.15.0

Mozilla shipped Thunderbird 153 “Meadow” (2026-07-21), starting a new ESR train; 140.x ESR stays supported only until roughly mid-September 2026, after which 153.x becomes the sole active ESR. Crucially, 153.x dropped Linux i686/pentium4 builds entirely – archive.mozilla.org only publishes a linux-x86_64/ tree under 153.*esr/, confirmed by checking the release directory listing (linux-i686/ 404s). thunderbird-esr-bin builds for x86_64/pentium4/i686, so moving it straight to 153.x would silently drop 32-bit support.

Forked the package here instead of just letting 32-bit support lapse: this package tracks the 140.x line (still arch=('x86_64' 'pentium4' 'i686')) for 32-bit users and anyone who needs to stay on the old ESR, while thunderbird-esr-bin itself moved on to 153.x (x86_64 only). Bumped to 140.15.0 (the newest 140.x point release available) before freezing, rather than forking at the stale 140.14.1 the mainline package happened to be pinned at.

Packaging is otherwise an exact copy of thunderbird-esr-bin at fork time – same _pkgname=thunderbird, same install layout (/opt/thunderbird, /usr/bin/thunderbird, etc.), same validpgpkeys (Mozilla’s release key covers both ESR trains). Because the install paths are identical, conflicts includes thunderbird-esr-bin (and vice versa) – these are mutually-exclusive alternatives, not side-by-side installable. .nvchecker.toml kept its 140.* regex so this package will keep picking up any further 140.x point releases as UPD until Mozilla actually EOLs the train; after that it should just go quiet (no matching releases left) and doesn’t need special handling.

Not yet a real AUR package as of this writing – prepared as a plain local directory under arch/maintained/, not a git submodule, since creating a brand-new AUR package is a real public action the user needs to do themselves (see arch/scripts/add_aur_package.sh, which only vendors packages that already exist on AUR). Already built, signed, and published to the private repo (all 3 arches) despite not being an AUR package yet – that part doesn’t depend on AUR.

Hand-off: creating the AUR package (user-run, not automated)

From inside arch/maintained/thunderbird-esr140-bin/ (checked thunderbird-esr-bin’s real tracked file list as the ground-truth template – keys/pgp/*.asc is tracked there, despite an older, apparently inaccurate, note elsewhere that it’s kept untracked):

cd arch/maintained/thunderbird-esr140-bin
git init
git add PKGBUILD .SRCINFO thunderbird-esr140-bin.install \
        thunderbird-esr140-bin.desktop vendor.js .nvchecker.toml \
        keys/pgp/14F26682D0916CDD81E37B6D61B7B526D98F0353.asc
git commit -m "Initial import: thunderbird-esr140-bin 140.15.0-1, forked from thunderbird-esr-bin"
git remote add origin ssh://aur@aur.archlinux.org/thunderbird-esr140-bin.git
git push -u origin master

That push is what actually creates the package on AUR (public, under the user’s maintainer account). Once it succeeds:

cd arch
rm -rf maintained/thunderbird-esr140-bin
scripts/add_maintained.sh thunderbird-esr140-bin

add_maintained.sh re-clones it as a proper submodule (and runs the maintainer-check against the now-live AUR page). After that, treat it like any other maintained package (routine updpkgsums bumps, FEEDBACK.txt checks, etc.) until it goes EOL upstream. The user still needs to commit the resulting .gitmodules/submodule change in the arch repo itself – not done here per “never use git to check in code.”