thunderbird-esr-bin

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

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:

• GuillaumeZITTA (2025-12-17) reported manually adding StartupWMClass=thunderbird-esr to /usr/share/applications/thunderbird.desktop fixed taskbar grouping (e.g. “Dash to Panel” GNOME extension not recognizing the window).
• MaKaNu (2026-01-02) reported the installed desktop file’s Icon= points at thunderbird, but the icon doesn’t show – symptom consistent with GNOME Shell/Wayland matching a running window to its launcher via StartupWMClass (or WM_CLASS) rather than reading the window’s own icon; without a match it falls back to a generic icon.
  • Note: GuillaumeZITTA’s report describes editing thunderbird.desktop directly (the installed name), not this package’s source file thunderbird-esr-bin.desktop – the same filename issue guoxh’s comment below points at. Worth revisiting if this fix alone doesn’t fully resolve it.
• guoxh (2026-07-21) suggested instead renaming the installed .desktop file itself to thunderbird-esr.desktop to fix the icon.

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.