Closed
Bug 951058
Opened 11 years ago
Closed 10 years ago
Unable to upload for validation add-on built with SDK 1.15
Categories
(addons.mozilla.org Graveyard :: Developer Pages, defect)
addons.mozilla.org Graveyard
Developer Pages
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: marc.chevrier, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20131209204824 Steps to reproduce: 1. click on "Upload a New Version" from my add-on page "Version History" 2. Select "All Platforms" 3. Select my xpi (see attachment) Actual results: An error is displayed: Your add-on failed validation with 1 error * Invalid file name in archive: / But when I click on "See full validation report", I have no error (only warnings). Expected results: Validation step should be successful. Nota: building same xpi with SDK 1.14 can be successfully uploaded.
Comment 1•11 years ago
|
||
This seems to be an error on the AMO side rather than the validator, since the standalone validation tool doesn't show the error. How did you create the extension package?
Status: UNCONFIRMED → NEW
Component: Add-on Validation → Developer Pages
Ever confirmed: true
Reporter | ||
Comment 2•11 years ago
|
||
I used tool 'cfx xpi' from SDK 1.15 to create my xpi file.
Comment 3•11 years ago
|
||
Adding some SDK people to look into the packaging problem. However, this is still a bug on the AMO code that checks the add-on *before* validation.
Comment 4•11 years ago
|
||
I did a couple of things: 1. downloaded the attached xpi and used the validator to validate it, this worked as expected. 2. took a different add-on project I have, packaged it with 1.15, then validated it with the validator. This also worked fine. I don't think the packaging is the issue. FYI I used the validator here: https://addons.mozilla.org/en-US/developers/addon/validate
Comment 5•11 years ago
|
||
Try (2), but instead of only validating it, try uploading it to the staging server. The problem seems to happen with an AMO pre-validation that is separate from the validator.
Comment 6•11 years ago
|
||
By uploading I mean to actually submit it as a new add-on, instead of using the /validate page.
Comment 7•10 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #6) > By uploading I mean to actually submit it as a new add-on, instead of using > the /validate page. The this is completely an AMO bug, and not an SDK bug right?
Comment 8•10 years ago
|
||
Looks like an AMO bug, yes.
Workaround for this bug: 1. Open up the xpi as an archive 2. Remove the empty directory inside that has the same name as the folder where cfx xpi was ran This worked for me, and after these steps the add-on still works properly.
Reporter | ||
Comment 10•10 years ago
|
||
Thanks for the workaround. In my case, I have am empty directory with name '/'. Removing this empty directory solves the problem. So, clearly, the problem is NOT on AMO side, but on cfx tool side. The tool generates a wrong xpi file.
Comment 11•10 years ago
|
||
(In reply to Marc Chevrier from comment #10) > Thanks for the workaround. In my case, I have am empty directory with name > '/'. Removing this empty directory solves the problem. > > So, clearly, the problem is NOT on AMO side, but on cfx tool side. The tool > generates a wrong xpi file. I don't necessarily see it that way. Has anything changed in cfx? Not lately ( until we release 1.16 ). Bu every time I release the SDK I make sure the validator works with it, so it does not seem like most users will run into this to me. I guess I want two answers: - when did cfx start adding empty directories, and under what conditions? - when did the validator start caring about empty directories?
Reporter | ||
Comment 12•10 years ago
|
||
- cfx starts to generate erroneous xpi with version 1.15 (1.14 is OK). No special condition. Same sources used with 1.14 (even with option --strip-sdk) generates a correct xpi. - validator starts to reject xpi when I starts to use 1.15 to package my add-on.
Comment 13•10 years ago
|
||
This problem still appears to be present in addon-sdk-1.17. I worked around it with `zip -d *.xpi "\/"`
Comment 14•10 years ago
|
||
This patch is equal to this pull-request: https://github.com/mozilla/addon-sdk/pull/1731
Attachment #8526797 -
Flags: review?(clouserw)
Comment 15•10 years ago
|
||
Comment on attachment 8526797 [details] addonsdk I'm not a reviewer for the addon-sdk. I'd suggest evold@m.c
Attachment #8526797 -
Flags: review?(clouserw) → review?(evold)
Comment 16•10 years ago
|
||
any news with this patch? If evold@m.c is busy, any other reviewer?
Flags: needinfo?(evold)
Flags: needinfo?(clouserw)
Comment 17•10 years ago
|
||
Comment on attachment 8526797 [details] addonsdk I'm sorry, we are not going to release any new versions of cfx, our future plan is to uplift most functionality to firefox itself & expose cli interface via nodejs (this project lives under https://github.com/mozilla/jpm) Given that no official release will be made for CFX any more I do not think there is much point in me reviewing this patch.
Attachment #8526797 -
Flags: review?(evold)
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Updated•10 years ago
|
Flags: needinfo?(evold)
Updated•10 years ago
|
Flags: needinfo?(clouserw)
Assignee | ||
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•