No L10n updates on Lanikai/Thunderbird 3.1 branch

RESOLVED FIXED in Thunderbird 3.1b1

Status

defect
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

Trunk
Thunderbird 3.1b1
Dependency tree / graph

Firefox Tracking Flags

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

Details

Attachments

(1 attachment)

Assignee

Description

10 years ago
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 generatesnippet.py, 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):

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2010/01/2010-01-05-03-comm-central-l10n/thunderbird-3.1a1pre.si.win32.complete.mar

when it should be:

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2010/01/2010-01-05-03-comm-1.9.2-l10n/thunderbird-3.1a1pre.si.win32.complete.mar

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 generatesnippet.py.

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 http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-sk/1264084514.1264085093.11200.gz related to this bug?
Assignee

Comment 2

10 years ago
(In reply to comment #1)
> Are the Thunderbird WINNT 5.2 comm-1.9.2 l10n builder failures like
> http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-sk/1264084514.1264085093.11200.gz
> 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

Updated

10 years ago
Assignee: gozer → bugzilla
Depends on: 539938
Assignee

Updated

10 years ago
Depends on: 544869
Assignee

Comment 4

10 years ago
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 generatesnippet.py 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+
Assignee

Updated

10 years ago
Whiteboard: [waiting on bug 539938 landing on 1.9.2]
Assignee

Comment 5

10 years ago
Checked in: http://hg.mozilla.org/comm-central/rev/a4091bd22816

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]
Assignee

Comment 6

10 years ago
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
Assignee

Comment 7

10 years ago
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
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.