# thunderbird-patches: the patch set behind the Betterbird fork > This repository is the patch collection that turns a stock Mozilla Thunderbird source tree into Betterbird, applied with a build script that fetches the right ESR revision, applies the series and runs mach build. It suits someone who wants to build the fork themselves, and it requires a full Thunderbird build environment. **Betterbird/thunderbird-patches** — Betterbird is a fork of Mozilla Thunderbird. Here are the patches that provide all the goodness. - Repository: https://github.com/Betterbird/thunderbird-patches - Stars: 1,008 · Forks: 47 - Language: Shell - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/betterbird-thunderbird-patches ## What the repository actually contains Betterbird is a fork of Mozilla Thunderbird, and this repository holds the patches that provide all of the goodness, with the project site at betterbird.eu for details. So the split is clear. The fork's source of truth is Thunderbird itself, and everything Betterbird changes lives here as a set of patches against the Mozilla tree. That is why the primary language is listed as Shell: the repository is mostly patch files plus a build script that applies them. The top level shows how the versions are organised. There are directories named 91/, 102/, 115/, 128/, 140/ and 153/, one per Thunderbird ESR generation, plus build/, install-on-linux/, metadata/, BetterbirdLauncher/ and the usual repository files. Inside each version directory are the patch series and the version specific configuration. The README refers to NN as a placeholder for the version you want to build, and says that currently 140 and 153 are supported. So the six directories are the history, and two of them are live. The patch directories are named by what they contain: NN/branding, NN/bugs, NN/features and NN/misc, plus NN/series-M-C and NN/series, and the file NN/NN.sh which the build script reads. That naming is the difference between a patch dump and a maintained fork, because it makes the change set reviewable by area. ## The build script, and what it automates The build process is automated for Windows, Linux and Mac through a build script at build/build.sh, and the README enumerates what that script does. It pulls mozilla-esrNN and comm-esrNN, with the comm-esrNN repository going into the mozilla-esrNN/comm/ subdirectory. It updates to the versions noted in NN/NN.sh with hg up -r , and the README is explicit that the patches apply to exactly those revisions. It puts NN/series-M-C into mozilla-esrNN/.hg/patches, renaming series-M-C to series, and puts NN/series into mozilla-esrNN/comm/.hg/patches. It puts all patches from NN/branding, NN/bugs, NN/features and NN/misc into mozilla-esrNN/comm/.hg/patches, then moves the ones ending in *-m-c.patch into mozilla-esrNN/.hg/patches. It fetches the quick-track patches. It applies the patches using hg qpush -a, and the README notes that this would fail if the series placement steps were omitted. It copies mozconfig into the mozilla-esrNN directory. Then it builds normally using./mach build and builds an installer using./mach package. The order of those steps is the substance. A patch series has to be in the right series file, in the right order, and against the right revision, and hg qpush is what enforces the dependency chain. The note that applying the patches would fail if the series placement steps were omitted is a warning to anyone who tries to apply patches by hand. The quick-track mechanism is worth understanding on its own. The README says the builds sometimes include patches taken from bugzilla.mozilla.org when they quick-track fixes, that those patches are not stored here, and that they have a comment in the series file pointing to the original changeset. The script fetches them, and the README notes that hg qimport cannot be used because it adds the patch to the series file where it is already present. ## The Linux build, and the 16 GB memory requirement The instructions assume you know how to build Thunderbird, and the ones given are the Betterbird specific additions on top of the Mozilla ones. The resource requirement is stated up front. To build successfully on Linux you need at least 16 GB of memory or swap space. The README records the machines it was executed on successfully, a Hetzner CPX41 cloud server with 8 CPUs, 16 GB RAM and 240 GB disk running Ubuntu 20.04, and an Ubuntu 22.04 VM with 8 CPUs, 24 GB RAM and 90 GB disk. That is a large requirement for a mail client, and it is a consequence of building the whole of Thunderbird rather than a small component. It is the practical difference between running Betterbird and producing it. The dependency list follows the Firefox Linux build instructions: apt update, then git, python3, python3-dev, python3-pip and curl, then libdbusmenu-gtk3-dev, then Mercurial, either from the distribution if it is new enough or installed for the user with pip, then Rust via rustup with option 1, then a rustup override set to the required version, with the exact version found in NN/NN.sh. Then the working directory and the copy steps: ```bash mkdir build && cd build git clone https://github.com/Betterbird/thunderbird-patches.git cp thunderbird-patches/build/build.sh . ./build.sh NN ``` For subsequent builds you only need to repeat the last step, since the script re-fetches and re-applies from the pinned revision. One platform caveat is worth noting. Building for aarch64 is also supported, but you need to run the build on an aarch64 machine, which the README says you can hire at Amazon EC2, because./mach bootstrap does not work on Linux aarch64, so there is a separate guide at build/build-env-aarch64.MD. ## Mac and Windows, and the same three commands The Mac and Windows paths differ only in the setup, and the build itself is the same four commands, which is the payoff of automating it in a script. For Mac, the requirements are Xcode from the Apple App Store or developer.apple.com, which requires an Apple ID, and the README notes the dependency between the Xcode version and the macOS version with a link to the release list. The hardware combinations the project used are listed, and they are the practical answer to the question of which Mac to build on. Betterbird 140 on Mac Intel and Silicon: macOS 15.5 with Xcode 16.4 and SDK 15.5. Betterbird 153 on Mac Intel: macOS 15.7.7 with Xcode 26.3 and SDK 26.2. And Betterbird 153 on Mac Silicon: macOS 26.5.2 with Xcode 26.6 and SDK 26.5. The setup is Homebrew first, with a note that the latest Homebrew may install cargo and rust into /usr/local/bin, which has to be removed so it does not clash with rustup-init. Then the Xcode modifications, `sudo xcode-select --switch /Applications/Xcode.app` and `sudo xcodebuild -license`, and if necessary adding /opt/homebrew/bin to the PATH in.zshenv. Then Mercurial with `brew install hg`, then Rust, then the rustup override, then wget, and then the same mkdir, clone, cp and./build.sh NN sequence. The README also points out that the Thunderbird documentation for macOS build prerequisites is incomplete, which is why the Firefox build instructions are followed instead. For Windows, the instruction is to follow the System Preparation from the Firefox build instructions, and also the Thunderbird documentation for Windows build prerequisites, then start a shell with start-shell.bat, and then run the same four commands. One platform-specific note appears in the build details. The README says Linux users should note that 08-branding-m-c.patch patches a Windows installer script making use of Windows PowerShell, and that this part of the build system should not be triggered, which is the kind of detail you only learn by reading the patches. ## Ansible build support that was removed One line in the README is a piece of project history worth keeping, because it describes a change of direction. The README notes that the Ansible-betterbird build has been replaced and is no longer supported. Ansible is the usual way to reproduce a build across machines, and for a project that produces binaries for several platforms it is the obvious tool. Replacing it with a shell script driven by an NN placeholder is a different philosophy: the script assumes you are at a machine, already provisioned, and it takes care of the part that is specific to Thunderbird. The consequence is that the platform setup is documented rather than automated. On Linux you are told to install a specific set of packages, on Mac which Xcode and macOS combination to use, on Windows to follow the System Preparation section. Each of those is a manual step, and each is also the place where a new contributor is most likely to get stuck, which is why the README is generous with links to the upstream Firefox and Thunderbird instructions it copies from. The copy is deliberate and visible. The Linux steps are described as the first part of the Firefox build instructions copied below, and the Mac steps as the first part of the previous Firefox build instructions. Rather than restating upstream guidance and letting it rot, the project points at the source and quotes the parts that matter. For the repository itself, the state is a maintained patch set with an automated apply-and-build step, six ESR branches carried in the tree with two currently supported, and a licence reported as one GitHub cannot classify even though a LICENSE file is present at the top level. The last push was on 2026-10-15 and there are no GitHub releases, because the artifacts this project produces are Thunderbird builds rather than packages of its own. ## Conclusion Adopt this repository if you need to build Betterbird from source, because the patch set is versioned per Thunderbird ESR branch and the build script pins the exact hg revision each patch applies to, so a rebuild is reproducible. Do not adopt it if you only need the client, because the source build is a long operation with a large memory requirement. Before you start, check the supported branches, 140 and 153 at present, and note the Linux memory floor of at least 16 GB of memory or swap, and that aarch64 has to be built on aarch64 hardware because mach bootstrap does not work there. ## FAQ ### What is the Betterbird thunderbird-patches repository? Betterbird is a fork of Mozilla Thunderbird, and this repository holds the patches that provide the fork's changes, with details at betterbird.eu. The top level carries one directory per Thunderbird ESR generation, 91, 102, 115, 128, 140 and 153, with 140 and 153 currently supported, and each holding branding, bugs, features and misc patch directories. ### What does build.sh do when I run it? It pulls mozilla-esrNN and comm-esrNN, updates to the revision pinned in NN/NN.sh, places the series files and the patches into the right .hg/patches directories, fetches the quick-track patches, applies everything with hg qpush -a, copies mozconfig in, and then runs ./mach build followed by ./mach package to produce an installer. For later builds you only repeat the ./build.sh NN step. ### What are the requirements for building Betterbird on Linux? At least 16 GB of memory or swap space. The README records successful builds on a Hetzner CPX41 with 8 CPUs, 16 GB RAM and 240 GB disk running Ubuntu 20.04, and an Ubuntu 22.04 VM with 8 CPUs and 24 GB RAM. Building for aarch64 is supported but has to happen on aarch64 hardware because ./mach bootstrap does not work there. ### How are upstream bug fixes pulled into the Betterbird patches? The builds sometimes include patches taken from bugzilla.mozilla.org when fixes are quick-tracked. Those patches are not stored in this repository; they carry a comment in the series file pointing to the original changeset, and build.sh fetches them. The README notes that hg qimport cannot be used for this because it would add the patch to the series file where it is already present. ## Sources - [Betterbird/thunderbird-patches on GitHub](https://github.com/Betterbird/thunderbird-patches) - [Issues](https://github.com/Betterbird/thunderbird-patches/issues) - [README](https://github.com/Betterbird/thunderbird-patches/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/betterbird-thunderbird-patches