aurupdater

thunderbird-esr-bin

Build times (auto-updated)

Build times (auto-updated)

Binary-tarball ESR package (Mozilla releases, per-arch source arrays). Routine updates are a straight pkgver bump + updpkgsums + .SRCINFO regen – no build-system quirks.

2026-10-21: routine bump 153.5.0 -> 153.5.1

Caught by a STATES.txt refresh right after the mdcat/check_ssl_cert session (a genuinely new point release, not stale state). Same standard recipe as below: tarball confirmed, PGP key unchanged, updpkgsums + .SRCINFO regen. Published cleanly, x86_64 only, no connection failures.

2026-10-17: routine bump 153.4.0 -> 153.5.0

Tarball existence confirmed on archive.mozilla.org before touching PKGBUILD. Ran scripts/update_pgp_key_dir.sh proactively first (Mozilla release key unchanged). Straight pkgver bump + updpkgsums + .SRCINFO regen, built via repo_release.sh from the arch/maintained/thunderbird-esr-bin path. Published cleanly, old 153.4.0-1 archived, no connection failures in the log.

2026-09-03: ESR-train switch 140.x -> 153.x, i686/pentium4 dropped, forked [[thunderbird-esr140-bin]]

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. Rebased this package onto 153.2.0 (the newest 153.x point release at the time).

arch changed from ('x86_64' 'pentium4' 'i686') to ('x86_64') – confirmed via archive.mozilla.org/pub/thunderbird/releases/153.2.0esr/ that Mozilla no longer publishes linux-i686/ builds for the 153.x train (only linux-x86_64/; the i686 path 404s), unlike 140.x which still ships both. Removed the source_pentium4/source_i686/sha512sums_pentium4/ sha512sums_i686 arrays entirely rather than leaving them stale.

32-bit users (and anyone needing to stay on the old ESR) now go to the new sibling package [[thunderbird-esr140-bin]], forked off this package at 140.15.0 just before this switch and frozen on the 140.x train (arch=('x86_64' 'pentium4' 'i686') unchanged there). The two packages conflicts each other (same install paths/binary name – mutually exclusive alternatives, not side-by-side installable), matching the existing conflicts=('thunderbird' 'thunderbird-bin') pattern this package already used.

.nvchecker.toml’s regex changed from >(140.*)esr/< to >(153.*)esr/< to track the new train going forward.

thunderbird-esr140-bin was prepared as a plain local directory only (not yet a git submodule / real AUR package) – creating a brand-new AUR package is a user-run action, not something this pipeline automates.

2026-09-03, stale-build cleanup: dropping arch=() to ('x86_64') left the old 140.14.1-1 i686/pentium4 builds orphaned in the live repo (no new build for those arches ever ran to trigger repo_publish.sh’s own archive-old-version step). Moved both .pkg.tar.zst/.sig pairs to archive/<arch>/ on the repo host and ran repo-remove against each arch’s db by hand (via a throwaway script sourcing repo_lib.sh’s repo_ssh/repo_remove_remote helpers, deleted after use) – confirmed clean via repo_arch_status.sh afterward (x86_64 only, 153.2.0-1).

2026-09-03: AUR comment answered – ESR-train question

IngoMeyer (2026-09-03 07:25) asked whether this package intends to stick with 140 ESR even though 153 ESR already exists. andreas_baumann replied same day (07:47) explaining the .nvchecker.toml had been watching 140 and missed the 153 release, and that the package was being split into this one (rebased onto

  1. plus a new thunderbird-esr140-bin for anyone needing to stay on 140 – i.e. the ESR-train switch documented above was made in response to this comment, not independently. Answered in-thread; no further action.

2026-08-21: 140.13.0 -> 140.14.0, Mozilla signing-subkey rotation

Routine bump (tarball existence confirmed on archive.mozilla.org before touching PKGBUILD). First build_all_archs.sh attempt failed on all 3 arches with unknown public key 678E455D76767AA3 during PGP source verification – Mozilla rotated their release-signing subkey on 2026-08-06 (previous subkeys all show [expired]/[revoked] via gpg --show-keys once fetched). validpgpkeys itself (the master key fingerprint 14F26682D0916CDD81E37B6D61B7B526D98F0353) was still correct – only the local keys/pgp/ cache was stale.

Fix: hkps://keys.openpgp.org has the new subkey (both keyserver.ubuntu.com and pgp.mit.edu returned “No data” for it, the old SKS pool is effectively frozen for this kind of update); ran gpg --keyserver hkps://keys.openpgp.org --recv-keys 678E455D76767AA3 then scripts/update_pgp_key_dir.sh from inside this package dir to regenerate keys/pgp/14F26682D0916CDD81E37B6D61B7B526D98F0353.asc (a local key cache makepkg reads automatically during the chroot build, no network keyserver access needed at build time). Rebuild then passed PGP verification cleanly on all 3 arches. See [[feedback_update_pgp_keys_every_build]] – now doing this proactively for every package with validpgpkeys, not just after a failure like this one.

Built directly in-place via build_all_archs.sh inside this package dir rather than staged under /data/INSTALL (should have used repo_release.sh from the start – see [[feedback_build_staged_by_default]]); signed+published the 3 arch files directly with repo_sign.sh/repo_publish.sh, then manually cleaned the leftover downloaded tarballs/*-package.log/*-namcap.log out of the tracked tree afterward. keys/pgp/ was deliberately kept (untracked, same pattern as linux-lts515’s own keys/pgp/).

2026-07-22: version bump + AUR-reported desktop/icon fix

Bumped 140.12.1 -> 140.13.0 (routine nvchecker UPD flag).

While in there, checked FEEDBACK.txt for this package (per updated workflow – check AUR comments for every touched package, not just UPD-flagged ones) and found three related comments about the taskbar/icon not showing correctly under GNOME/Wayland (generic “Wayland” icon shown instead of Thunderbird’s), spanning 2025-12-17 to 2026-07-21:

Applied the lower-risk, user-confirmed fix: added StartupWMClass=thunderbird-esr to thunderbird-esr-bin.desktop (this package’s source .desktop file, installed as thunderbird.desktop per package()’s $_pkgname.desktop naming – unchanged). Did not rename the installed desktop filename (guoxh’s suggestion) – that’s a bigger, unconfirmed change (would need to also update the install= script, conflicts=, and any icon-cache MIME associations) and the StartupWMClass line alone is the one an actual user confirmed fixed the symptom.

If a future AUR comment says the icon/taskbar issue persists after this fix, revisit guoxh’s rename suggestion next.

2026-10-01: version bump 153.3.1 -> 153.4.0

Routine nvchecker UPD flag from a full update_cycle.sh run. PGP key checked proactively first (update_pgp_key_dir.sh) – unchanged, no rotation this time. updpkgsums + repo_release.sh, no issues. Checked FEEDBACK.txt: thread already ANSWERED (latest comment is own reply from 2026-09-03), nothing new.

2026-09-19: version bump 153.2.0 -> 153.3.1

Routine nvchecker UPD flag from a full update_cycle.sh run. PGP key already current (checked proactively). updpkgsums + repo_release.sh, no issues. Checked FEEDBACK.txt: no new AUR comments since the 2026-09-03 thunderbird-esr140-bin split thread (both flagged as already seen).