Closed Bug 400407 Opened 12 years ago Closed 12 years ago

Conflicting entries in removed-files.in break update process

Categories

(Calendar :: Sunbird Only, defect, major)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ulf.stroehler, Assigned: sipaq)

References

Details

Attachments

(1 file)

Testing the Sunbird Update ("betatest" channel) 0.5 -> 0.7 reveals a problem for the Swedish Win32 version. Restarting SB after the Update fails withe an Error Message. Neither different L10n versions nor platforms seem to be affected.

The problem can as well be reproduced by forcing the update locally, w. previously downloaded *.mar files. Both *.mar file types seem affected; the partials as well as the complete *.mar file.

Steps To Reproduce (STR):
=========================

1. download and install Sunbird 0.5 sv_SE installer.exe
2. edit "Program Files/Mozilla Sunbird/defaults/pref/channel_prefs.js" and 
3. change 
pref("app.update.channel", "release"); 
to 
pref("app.update.channel", "betatest");
4. launch SB and trigger Update

Actual Result:
==============

Update is downloaded and installed, but after re-start SB displays the following Error Message and refuses to work:

>> "XML-tolkningsfel: odefinierad entitet
>> Adress: chrome://calendar/content/calendar.xul
>> Radnummer 80, Kolumn 1:<window id="calendar-window"
>>         title="&mainWindow.title;"
>>         onload="calendarInit()"
>>         onunload="calendarFinish()"
>> ^      <menuitem id="list-calendars-context-new"
>> ------^      <menuitem label="&calendar.context.newtodo.label;"
>> ------^"

Expected Result:
================

SB should start w/o any probs after the Update

Reproducible:
=============

Always
- same for es-ES
- (at least) calendar-es-ES.jar is missing in chrome
Summary: L10n: SB sv_SE: Update 0.5 -> 0.7 corrupts SB on win32 → L10n: SB Update 0.5 -> 0.7 corrupts SB on win32
During creation of RC1 ause had a script error that resulted in only creating files for AB locales but not AB-CD locales. Maybe a similar issue?
same for pt-BR also
Per the discussion in #build it seems that the following entries in removed-files.in are the culprits for this behaviour

http://lxr.mozilla.org/mozilla1.8/source/calendar/installer/removed-files.in#58
http://lxr.mozilla.org/mozilla1.8/source/calendar/installer/removed-files.in#66
http://lxr.mozilla.org/mozilla1.8/source/calendar/installer/removed-files.in#69

It seems that at the end of the update cycle, Sunbird tries to remove these files, which we shipped in the 0.2 timeframe. But since we have localizations with the same locale code, this leads to conflicts like broken chrome.

Resolution from #build: Create new installers and new update files.

Requesting blocking-calendar0.7 for this.
Assignee: nobody → bugzilla
Flags: blocking-calendar0.7?
Summary: L10n: SB Update 0.5 -> 0.7 corrupts SB on win32 → Conflicting entries in removed-files.in break update process
Version: Trunk → unspecified
Status: NEW → ASSIGNED
CC'ing ause as this bug concerns him.
Attached patch PatchSplinter Review
I've taken the liberty to remove all the calendar-ab-CD.jar files to rule out any possibility of this ever happening again
Attachment #285482 - Flags: review?(ctalbert)
We absolutely can't break people when they upgrade to 0.7.

This blocks.
Flags: blocking-calendar0.7? → blocking-calendar0.7+
Blocks: 399865
Comment on attachment 285482 [details] [diff] [review]
Patch

r=ctalbert
Attachment #285482 - Flags: review?(ctalbert) → review+
Comment on attachment 285482 [details] [diff] [review]
Patch

I don't understand that: why shouldn't we remove most of the above files (except for es-ES, sv-SE, pt-BR) when upgrading from sunbird 0.2? why not just

>-chrome/calendar-es-ES.jar
>-chrome/calendar-pt-BR.jar
>-chrome/calendar-sv-SE.jar
I think that we are removing most of these so that we don't ever run into this situation again.    Even though that is rather unlikely.

Holding off on checking this in until we hear from Simon regarding Daniel's question in Comment 9.
Yes, the reason for this change was to rule out any chance of this ever happening again. 

In addition I do not believe that we still have that many 0.2 users and the entries in removed-files.in were always just a general cleanup measure and not a measure to avoid bugs simply because the chrome structure then and now is totally different.

Daniel, if you can give me a short feedback, then I can check this in on the weekend.
(In reply to comment #11)
> Yes, the reason for this change was to rule out any chance of this ever
> happening again. 
Why should we clean up any files then? ;)

I think it makes sense to properly clean up, even Sunbird 0.2. Counter-proposal: We could add some scripting to ause's release scripts to avoid that in the future, i.e. check removed-files.in against ${MOZ_OBJDIR}/dist/bin.

> In addition I do not believe that we still have that many 0.2 users and the
> entries in removed-files.in were always just a general cleanup measure and not
> a measure to avoid bugs simply because the chrome structure then and now is
> totally different.
I agree that it's just "nice to have" (e.g. bug 398309 never blocked), but w.r.t. this bug, I still see no urging reason to just remove the jars we deliver with 0.7 from removed-files.in.
Patch checked in on MOZILLA_1_8_BRANCH and SUNBIRD_0_7_BRANCH after approval from Daniel via IRC.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Simon, the checkin on Trunk contains the changes from Bug 399809 too.
Simon has removed the whole list on SUNBIRD_0_7_BRANCH only, but removed only es-ES, pt-BR and sv-SE on branch and trunk. I filed follow-up bug 400540 for scripting (comment #12).
Target Milestone: --- → 0.7
You need to log in before you can comment on or make changes to this bug.