Update 102.12.0 bb37

[mfschumann]

bot, build

[flathubbot]

Queued test build for eu.betterbird.Betterbird.

[flathubbot]

Started test build 45761

[flathubbot]

Started test build 45762

[flathubbot]

Build 45762 was cancelled

[flathubbot]

Build 45761 failed

[mfschumann]

bot, build

[flathubbot]

Queued test build for eu.betterbird.Betterbird.

[flathubbot]

Started test build 45768

[flathubbot]

Started test build 45769

[flathubbot]

Build 45768 was cancelled

[flathubbot]

Build 45769 failed

[flathubbot]

Started test build 46027

[flathubbot]

Build 46027 failed

[Erick555]

You need this patch temporarily.

[flathubbot]

Started test build 46204

[mfschumann]

You need this patch temporarily.

Thanks man!

[flathubbot]

Build 46204 failed

[mfschumann]

bot, build

[flathubbot]

Queued test build for eu.betterbird.Betterbird.

[flathubbot]

Started test build 46230

[flathubbot]

Build 46230 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/28851/eu.betterbird.Betterbird.flatpakref

[Betterbird]

You need this patch temporarily.

Why is the solution to change the source code to upgrade it beyond what is shipping in Mozilla 102 instead of simply using the compiler version that correctly matches the code being compiled? At the time of the inception of Mozilla 102, Rust 1.60.0 was the current version, not 1.70.0. This approach may work in this particular case, but basically you're shipping something that was never integration tested in this form. You brought forward parts of this changeset: https://hg.mozilla.org/mozilla-central/rev/a651d4323066#l33.13 which landed on Mozilla 111 in January 2023 totally out of context with the rest of the code base of Mozilla 102. At least I have zero knowledge of that particular Mozilla platform code and can only strongly advice against such backports.

The Betterbird build system pins the Rust compiler so it matches the code being compiled.

[Erick555]

flathub rust SDK extension is rolling release, it's not possible to pin it. You would need to drop the extension and bundle rust in app manifest.

Similar situation happens for rolling release distros like Arch. In the past new rust releases broke mozilla esr code every two months so things are better now but we need to deal with it from time to time.

At some point someone will backport the fix to esr code and thunderbird will catch it and then we can drop the patch.

[mfschumann]

I'd like to add that your argument holds for most Linux distributions, not only rolling ones. The distribution usually defines the toolchain and patches the software to make it build (e.g. Fedora 38 uses rust 1.70 with a patch of mp4parse for building TB, just as we do for the flatpak). Flathub also encourages this way of working by providing rolling-version SDKs only.

Don't get me wrong, I am all for reproducibility and well-tested software. I also agree that the current situation is less than ideal because software is built with a compiler (version) it was never intended to. But I think in order to really improve the current situation we should try to get a discussion going among SDK maintainers and flathub staff:

• What is the rationale behind providing rolling-version SDKs only?
• How can we guarantee reproducible, stable and well-tested builds using such an approach?
• Can fixed-version SDKs be provided as an alternative or addition to the rolling-version ones?

@hfiguiere Do you have an opinion on that topic or can you point me to the right place to get such a discussion going?