thunderbird-esr140-bin

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

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.”