400407 - Conflicting entries in removed-files.in break update process

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Ulf Stroehler]

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

Comment 1

[Daniel Boelzle [:dbo]]

- same for es-ES
- (at least) calendar-es-ES.jar is missing in chrome

Comment 2

[Stefan Sitter [:ssitter]]

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?

Comment 3

[Ulf Stroehler]

same for pt-BR also

Comment 4

[Simon Paquet [:sipaq]]

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.

Comment 5

[Simon Paquet [:sipaq]]

CC'ing ause as this bug concerns him.

Comment 6

[Simon Paquet [:sipaq]]

Attachment: Patch

I've taken the liberty to remove all the calendar-ab-CD.jar files to rule out any possibility of this ever happening again

Comment 7

[cmtalbert]

We absolutely can't break people when they upgrade to 0.7.

This blocks.

Comment 8

[cmtalbert]

Comment on attachment 285482 [details] [diff] [review]
Patch

r=ctalbert

Comment 9

[Daniel Boelzle [:dbo]]

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

Comment 10

[cmtalbert]

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.

Comment 11

[Simon Paquet [:sipaq]]

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.

Comment 12

[Daniel Boelzle [:dbo]]

(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.

Comment 13

[Simon Paquet [:sipaq]]

Patch checked in on MOZILLA_1_8_BRANCH and SUNBIRD_0_7_BRANCH after approval from Daniel via IRC.

Comment 14

[Stefan Sitter [:ssitter]]

Simon, the checkin on Trunk contains the changes from Bug 399809 too.

Comment 15

[Daniel Boelzle [:dbo]]

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).