Closed Bug 486278 Opened 15 years ago Closed 14 years ago

sq.xpi for 3.0.8 uninstallable on ubuntu

Categories

(Mozilla Localizations :: sq / Albanian, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: asac, Assigned: besnik)

Details

(Keywords: fixed1.9.0.11)

Attachments

(1 file)

try to install sq.xpi from http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0.8/linux-i686/xpi/sq.xpi ... it fails. Seems there is some illegal syntax.
fwiw, this is about firefox 3
Flags: blocking1.9.0.9?
Flags: blocking1.9.0.10?
FWIW, the error you get is:

"Firefox could not install this item because "install-8gm..rdf" (provided by the item) is not well-formed or does not exist. Please contact the author about this problem."
The problem is a leading empty line in install.rdf, which I think is due to the trailing empty line here
  http://mxr.mozilla.org/l10n/source/sq/browser/defines.inc
Good catch.

Besnik, can you create a patch to remove the trailing empty line there? And make sure that we don't have the same problem on the hg repos?
CCed Arne Goeje who found this issue during launchpad imports.
Not going to block on an uninstall failure, doubly so for a language pack with a small number of users. Will approve a patch for an appropriate release, please request approval when you have one.
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.9?
Flags: blocking1.9.0.10?
Jumping in with a patch for CVS.

Besnik, mind pasting a link to an hg changeset so that we can make sure this is fixed on the hg repos, too?
Attachment #370671 - Flags: approval1.9.0.10+
Checking in browser/defines.inc;
/l10n/l10n/sq/browser/defines.inc,v  <--  defines.inc
new revision: 1.7; previous revision: 1.6
done
Checking in mail/defines.inc;
/l10n/l10n/sq/mail/defines.inc,v  <--  defines.inc
new revision: 1.3; previous revision: 1.2
done

FIXED on cvs, leaving open for hg trunk and 1.9.1
Keywords: fixed1.9.0.10
For trunk:   171:13f2b36d4ad0
Ooops, /mail should be fixed as well. Here you are:

for 1.9.1:     172:aad318ac78c2
for trunk:     159:29a28a56432a
Since we haven't cut over into a post3.0.8 relbranch yet this fix will be in 1.9.0.9 rather than 1.9.0.10, won't it? Or do you already have a 1.9.0.9 tag in the l10n repo?
I figured that the timestamp I sent in for .8 would end up being used for .9, but there's no real conscious decision behind that.
marking FIXED, should be alright by now.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: