Closed Bug 538132 Opened 13 years ago Closed 13 years ago

No L10n updates on Lanikai/Thunderbird 3.1 branch


(Thunderbird :: Build Config, defect)

Not set


(blocking-thunderbird3.1 beta1+, thunderbird3.1 beta1-fixed)

Thunderbird 3.1b1
Tracking Status
blocking-thunderbird3.1 --- beta1+
thunderbird3.1 --- beta1-fixed


(Reporter: standard8, Assigned: standard8)




(1 file)

Since starting to build Thunderbird 3.1 on mozilla-1.9.2 we haven't been producing L10n nightly snippets so the update mechanism isn't working for them.

Having a look at what is going on:

- The en-US snippets are generated primarily in the buildbotcustom code and use the milestone (similar to branch) to generate the location of the mar file on ftp.

- The L10n snippets use, this uses the repository name as provided in application.ini for the ftp location.

So for L10n builds, we're getting a snippet that points to (for example):

when it should be:

So when aus comes to take the update, it can't find the file and fails to publish the update.

I see two possible solutions:

1) Do nothing, wait until we branch comm-central into comm-1.9.2 and the issue will resolve itself.

The problem here is that this will mean L10n folks can't get updates until we branch (afaik this is currently expected to be around alpha 1 in 2-3 weeks, but that doesn't help those who want to prepare in advance).

2) Have buildbot, or maybe the makefiles, be able to override the obtained application.ini name for the repository by passing environment variables/extra arguments to

This would support us in this configuration, and allow us to support similar configurations fully in the future.
Flags: blocking-thunderbird3.1+
Are the Thunderbird WINNT 5.2 comm-1.9.2 l10n builder failures like related to this bug?
(In reply to comment #1)
> Are the Thunderbird WINNT 5.2 comm-1.9.2 l10n builder failures like
> related to this bug?

No, please file a bug blocking bug 540585, I'm pretty sure its a regression from that bug.
Standard8, as far as I can tell, this doesn't actually block alpha1 from shipping.  I'm adjusting the flags to reflect that.  Please change if you disagree.

I think we're going to want to do _something_ about this fairly quickly, given that string freeze is currently aimed at the end of beta1.  Assigning to gozer on the assumption that he's the right person to own this bug.  Gozer, feel free to push back if you disagree.
Assignee: nobody → gozer
blocking-thunderbird3.1: --- → beta1+
Flags: blocking-thunderbird3.1+
Target Milestone: Thunderbird 3.1a1 → Thunderbird 3.1b1
Assignee: gozer → bugzilla
Depends on: 539938
Depends on: 544869
Once we get bug 539938 attachment 422228 [details] [diff] [review] landed on 1.9.2 (approval has been requested) then we can land this patch.

This patch means that we'll pass a branch argument to which will be correctly set to comm-central or comm-1.9.2 by buildbot (once buildbot has been updated to the latest version of buildbotcustom - bug 544869).

Once we get the branch set correctly, then the snippet information will point to the correct directory for the mar file and hence update snippets will work again.
Attachment #425795 - Flags: review?(gozer)
Attachment #425795 - Flags: review?(gozer) → review+
Whiteboard: [waiting on bug 539938 landing on 1.9.2]
Checked in:

This should be the last bit of the puzzle so that we have l10n updates on 3.1 builds. It has landed in time for today's nightlies, so we'll see what happens.
Whiteboard: [waiting on bug 539938 landing on 1.9.2]
Ok, I'm not sure what has happened, we're now appear not to be getting l10n updates on trunk (3.2 builds) or lanikai (3.1 builds).

We do seem to have got en-US builds. It could be that the aus server is backed up or overloaded, so I'm going to assign to gozer and get him to check that over.
Assignee: bugzilla → gozer
I've just re-checked this today and it turns out that aus probably just needed some time to sort itself out following the correctness fixes.

I've been able to update 3.1b1pre to yesterday's build en-GB (today's isn't out yet) on Mac, and I've been given correct data for Windows and Linux builds.

Hence I believe this is now fixed.
Assignee: gozer → bugzilla
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.