Closed Bug 1567725 Opened 2 months ago Closed 2 months ago

Where to find l10n files or sources for Thunderbird 68.x


(Thunderbird :: Build Config, defect, P1, blocker)



(thunderbird_esr68 fixed, thunderbird69 fixed, thunderbird70 fixed)

Thunderbird 70.0
Tracking Status
thunderbird_esr68 --- fixed
thunderbird69 --- fixed
thunderbird70 --- fixed


(Reporter: c.schoenert, Assigned: rjl)



(Keywords: regression)


(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Within Debian we package the l10n files for the UI language separately for every language. For this we create a dedicated source tarball (with the files for Thunderbird itself and on more with the files for the Lightning extension) from which later within the build process we create the required folder / file structure to make the language available within Thunderbird.

For the Lightning extension I extract the required files from the pre-build binaries which I can find on the URL stanza like this:$LANG

Until TB 67.0b3 I could use the the XPI files which did include the l10n strings for the Thunderbird UI from an URL like:

Since the first beta of TB 68 this folder isn't existing anymore on the CDN. So currently I can't add the needed source to the build of recent Thunderbird beta versions anymore as I don't which alternatives I have.

Seems like the build process and also the deployment has changed here for TB 68 and greater. What can I do to be able to provide dedicated l10n packages to the Thunderbird within Debian?
I've looked into existing pre-build binaries of TB 68 beta versions and especially into the omni.ja archive. There is a folder localization which is including obviously a l10n folder for the language of the pre-build binary. As I download these files already I can extract the files from the included omni.ja archive more or less easily. But where I need to place these files later so Thunderbird will recognize the language automatically then?

What else can I do?

Flags: needinfo?(rob)

Those files should be where indicated; I'm basing that on the fact that the xpi directory is present and populated for Firefox 68.0.1 ESR.

This is fallout from the declarative artifact work in bug 1552960, most likely c-c:49774aa1a8ef. With the changes to how artifacts get uploaded, I suspect that code won't work. I'll work on this Monday.

I consider this to be a serious enough regression that it should block the 68.0 release.

Assignee: nobody → rob
Severity: normal → blocker
Type: enhancement → defect
Component: Message Reader UI → Build Config
Ever confirmed: true
Flags: needinfo?(rob)
Keywords: regression
Priority: -- → P1
Regressions: 1552960
Target Milestone: --- → Thunderbird 68.0
When I checked the current daily builds, I found that the langpacks are
getting uploaded. That means the removal of that beetmove transform I
mentioned in comment 1 is not the issue.

The problem is occurring because Firefox has an additional step to sign
their langpacks before they get uploaded. Thunderbird does not sign addons
currently, so I had to change the base dependency for target.langpack.xpi
artifacts in thunderbird_candidates.yml to match thunderbird_nightly.yml.

To verify, I copied the change to the comm-esr68 branch and generated a
full task graph using the parameters.yml file from 68.0b5-build2. The
taskgraph I generated has an additional artifact listed in each of the
beetmover-repackage-* tasks as expected.

Simplified full-task-graph.json output:
  "beetmover-repackage-bg-win64-shippable/opt": {
    "task": {
      "payload": {
        "artifactMap": [
                  "pub/thunderbird/candidates/68.0b5-candidates/build1/win64/bg/Thunderbird Setup 68.0b5.exe",
                  "pub/thunderbird/candidates/68.0b5-candidates/build1/win64/bg/Thunderbird Setup 68.0b5.msi",
Attachment #9079633 - Flags: review?(geoff)
Comment on attachment 9079633 [details] [diff] [review]

[Approval Request Comment]
Regression caused by (bug #): 1552960
User impact if declined: There are no language packs available for versions 68 and 69 beta. This prevents users from being able to create a multi-locale installation and also breaks the packaging process used by Debian.
Testing completed (on c-c, etc.): n/a as c-c does not exhibit this bug due to c-c using a different artifact manifest file. Try jobs also use the "nightly" manifest file. I did generate the full taskgraph locally and verified the correct data in the output as described in the attachment comments.
Risk to taking this patch (and alternatives if risky):
There is low to zero risk as this only affects the release promotion process.
Attachment #9079633 - Flags: approval-comm-esr68?
Attachment #9079633 - Flags: approval-comm-beta?

Rob, the target is the cycle when the patch lands. Tracking flags tell us which versions are fixed/affected.

Target Milestone: Thunderbird 68.0 → Thunderbird 70.0
Attachment #9079633 - Flags: review?(geoff) → review+
Attachment #9079633 - Flags: approval-comm-esr68?
Attachment #9079633 - Flags: approval-comm-esr68+
Attachment #9079633 - Flags: approval-comm-beta?
Attachment #9079633 - Flags: approval-comm-beta+

Pushed by
Fix dependency issue with langpack beetmover. r=darktrojan DONTBUILD

Closed: 2 months ago
Resolution: --- → FIXED

beetmoves or beetmover? Surely a mover carries out moves ;-)

Fix for build signing failure on 69.0b1-build1. This will need to land on
comm-central, comm-beta, and comm-esr68.
Flags: needinfo?(jorgk)
Fix for build signing failure on 69.0b1-build1. This will need to land on
comm-central, comm-beta, and comm-esr68.

V2 with "Follow-up" spelled right.
Attachment #9080048 - Attachment is obsolete: true
Pushed by
Follow-up: Use default source_path_modifier for langpack uploads. rs=bustage-fix,jorgk
You need to log in before you can comment on or make changes to this bug.