bug AMO pour MAJ

[commando]

Salut,

Je précise d'abord que ce qui suis a été signalé par moi-même sur le forum AMO, en anglais, mais non répondu...

Voici le problème bloquant que je rencontre:
Pour une nouvelle version de mon addon, je vois cette erreur: "ne correspond pas au module".
C'est le même UUID, et la version passe les tests (0 erreurs, 3 avertissements).
Pour preuve, quand je veux proposer un nouveau addon avec la nouvelle version, je vois cette erreur: "Identifiant UUID dupliqué".
Donc je ne peux pas mettre à jour mon addon.

Il y a quelque mois, pas de soucis, maintenant il y a beaucoup de changements sur AMO. Y en a-t-il un qui bloque les processus de mise à jour? Genre je suis en attente de choix de revue?
Sinon j'ai vu qu'il y en avait qui avait des bugs bloquants sur leur compte AMO, mais pas sur tous les comptes AMO. Suis-je entré dans ce cas?

Bref, si ça continue, je demanderai comment faire pour mettre son propre système de mise à jour sans SSL ni HTTPS, car je n'ai pas les moyens de me mettre en serveur dédié rien que pour ça... Sans parler du prix du SSL.

[martin]

Quand j'ai des réactions "bizarres" avec AMO, je commence par basculer la page en langue anglaise (en bas de page, Autres langues -> english US), et souvent j'ai moins de problème.

Sinon essaie, en plus, de supprimer l'entrée précédente qui a posé problème (dans la page "fichiers et versions", puis de la resoumettre.

Et enfin, si tu bloques toujours, essaie d'aller les voir sur irc, ils sont assez réactifs en général (mais anglais obligatoire). C'est sur le channel #addons je crois.

[commando]

Je suis passé sur la version anglaise pour... avoir la traduction interne des messages d'erreurs pour le rapporter sur le forum AMO! Et c'est bien réussi, car j'ai les même erreurs...

Pour l'entrée précédente qui a posé problème: elle n'avait pas posé problème. Et celle qui pose problème n'arrive même pas à rentrer dans AMO. Comment supprimer quelque chose qui n'existe pas?

Pour l'irc, je préfère un forum ou un email pour écrire dans une langue étrangère, même l'anglais. Et de toute façon, jamais réussi à me mettre vraiment au irc. Même en français, j'évite.

Bref, merci, mais je vais attendre sur le forum AMO. En parallèle, j'ai mis le statut de mon addon en "revue préliminaire". Il semblerai, à la lecture de la nouvelle page des statuts (et versions), qu'il y a une nouvelle obligation de ce côté ("must be"...). Ici, je voudrais savoir si quelqu'un qui n'a jamais soumis son addon à une revue de Mozilla a le même problème. Ou le même problème alors que la revue est faite (mais j'en doute de plus en plus).

[martin]

Pour l'irc, je préfère un forum ou un email pour écrire dans une langue étrangère, même l'anglais. Et de toute façon, jamais réussi à me mettre vraiment au irc. Même en français, j'évite.

Je comprend, je t'indiquais juste le moyen le plus efficace et rapide de contacter ceux qui gèrent AMO .

Par contre je n'ai pas retrouvé ton message sur le forum d'AMO

Et j'ai oublié de te répondre pour héberger soi même une extension sans https, il faut utiliser McCoy pour signer son extension. Une mini explication et howto postés sur ce forum.

[commando]

Sur le forum AMO, je m'appelle kommando.
Voici le sujet pour ce "bug": https://forums.mozilla.org/addons/viewt ... =10&t=2308.

Pour MAJ sans https, j'avais fais des recherches il y a un ou deux ans. J'ai juste réussi à générer une clé via McCoy, et à la mettre dans l'install.rdf. Rien compris au reste, donc voilà.
Comment dire dans l'install.rdf où et quoi chercher? (quoique celle-là ça me dit quelque chose...)
L'update.rdf est à mettre où? (aussi, mais moins, n'y a pas une histoire de serveur et de lien dans l'install.rdf?)
On fait comment pour le SHA1 sous Windows?
Que faut-il faire côté xpi et côté serveur à chaque changement de nouvelle version?

Bref, j'espère que ce sera une semaine à un mois de prise de tête, puis tranquillité dans mon propre hébergement. Car là, je vois que je suis à la merci du moindre problème AMO (je sais, c'est un peu tard pour la prise de conscience). En plus, je vais avoir peut être un soucis de licence avec cette histoire de peut être faire une revue avant toute MAJ. Et dire que dans la MAJ, que je n'arrive pas à mettre dans AMO, je règle plusieurs gros problèmes, dont celui de la licence...

[martin]

Voici le sujet pour ce "bug": https://forums.mozilla.org/addons/viewt ... =10&t=2308.

personnellement j'aurai précisé le nom de ton extension, pour qu'ils puissent regarder.

Pour l'hébergement perso, reprenons point par point . Ca a l'air compliqué, mais en fait c'est plutôt simple.

- En premier, le serveur sur lequel on télécharge l'extension doit servir les fichiers xpi avec le type mime 'application/x-xpinstall', et les fichiers rdf avec le type mime 'text/rdf' ou 'text/xml'.
Si le serveur utilise Apache, et autorise les fichiers htaccess, il suffit de mettre un fichier nommé .htaccess à la racine, qui contient:

Code : Tout sélectionner

AddType application/x-xpinstall .xpi
AddType text/rdf .rdf

Pour les autres serveurs, ben, voir leur doc...

- Pour pouvoir préciser où une extension peut trouver une mise à jour, il faut ajouter une entrée <em:updateURL> dans son fichier install.rdf.
(lorsque l'extension est hébergé sur AMO, cette entrée <em:updateURL> *ne doit pas* être présente).
Cette entrée contient un lien vers un fichier rdf, indiquant les mises à jour. On verra ce fichier plus loin.

exemple:

Code : Tout sélectionner

    <em:updateURL>http://example.com/myextension/update.rdf</em:updateURL>

L'extension ne pourra s'installer que si cette entrée est présente et contient un lien en https, OU si cette entrée est présente et que le fichier install.rdf contient également une entrée <em:updateKey>.
Pour générer cette clé, on utilise McCoy : Keys -> Create New Key , puis on la copie, dans McCoy Keys -> Copy Public Key.
On peut "couper" cette clé avec des espaces et retours à ligne dans le install.rdf.

exemple

Code : Tout sélectionner

    <em:updateKey>MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDs4OX3iPlCEm+UAizCzN7gkg
        8iFqPHE1ngFowSoRidczyLtk39x1J0+edUUxx9Y57dKGyAAVZsuMHNGszJ9yT2j/HVMWjjNX
        k+U02BEgVnE5iiAPZOH0o5AkqtdlbeUCV3xt6hQq1Rxxn1lY/bE2DvNyA+LP6Sr6BWnoxw3M
        SObwIDAQAB/em:updateKey>

- lorsque une nouvelle version de l'extension est disponible, il faut donc générer un fichier update.rdf, à mettre au bon endroit sur le serveur, c-a-d correspondant à l'adresse updateURL utilisée.
Un exemple d'un tel fichier est disponible sur MDN.


Sinon voici un autre exemple:

Code : Tout sélectionner

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:em="http://www.mozilla.org/2004/em-rdf#">

    <!--liste des mises à jour disponible-->
    <rdf:Description rdf:about="urn:mozilla:extension:myextensionuuid@myname.com">
        <em:updates>
            <rdf:Seq>
                <rdf:li resource="urn:mozilla:extension:myextensionuuid@myname.com:1.1"/>
            </rdf:Seq>
        </em:updates>
    </rdf:Description>

    <!--Détails sur les mises à jour indiquées-->
    <rdf:Description rdf:about="urn:mozilla:myextensionuuid@myname.com:1.1">
        <em:version>1.1</em:version>
        <em:targetApplication>
            <rdf:Description>
                <!-- firefox -->
                <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
                <em:maxVersion>4.0.*</em:maxVersion>
                <em:minVersion>3.0</em:minVersion>
                <!-- lien vers la nouvelle version de l'extension -->
                <em:updateLink>http://example.com/myextension/myextension-1.1.xpi</em:updateLink>
                <!-- somme SHA1 du ficher xpi -->
                <em:updateHash>sha1:84cae508582d4cbdfb3d89fc89d0b2426d62901a</em:updateHash>
            </rdf:Description>
        </em:targetApplication>
    </rdf:Description>
</rdf:RDF>

La somme SHA1 du fichier xpi peut s'obtenir dans un terminal avec

sha1sum monextension-1.1.xpi

sur Linux.
Sur windows, je ne sais pas, mais Google semble indiquer pas mal de solution:
sha1sum+windows ou sha1+windows

Attention, ce nombre SHA1 est a recalculer à chaque fois que l'on recrée le fichier xpi, même si on ne change aucun des fichiers qu'il contient (la date de création du fichier n'est pas la même par exemple).

Enfin, il faut de nouveau utiliser McCoy pour signer ce fichier update.rdf. On ouvre McCoy, on sélectionne la même clé que celle utilisée pour install.rdf, et Update -> Sign Update Manifest, et sélectionner notre ficher update.rdf.
On peut enfin mettre notre fichier update.rdf sur notre serveur.

Voilà, j'espère que çà t'aidera.

Une petite note: ton extension ne peut être mise à jour que si la version précédente contient les bonnes informations dans le install.rdf (updateURL et updateKey), ce qui n'est évidement pas le cas si elle installée depuis AMO.

Sinon, rien n'empêche de publier une extension sur AMO, et de la publier également sur son propre serveur.

[commando]

Merci beaucoup. J'ai déjà l'impression d'avoir compris à 90% l'ensemble de la procédure
Par contre, je m'y collerai avec 3 versions de tests, et des essais grandeur nature, dans les prochains jours (quelque chose comme probablement entre aujourd'hui et la fin de semaine prochaine), car l'apparence de la complexité n'est pas effacée... Et je veux être sûr à 100% dans la compréhension ET dans la pratique avant de me séparer définitivement d'AMO pour l'hébergement de l'extension.

En attendant, comme sur AMO c'est statu quo, et que je n'ai pas envie de changer d'UUID à cause de AMO: comment, avec la version actuelle d'AMO, on passe notre addon du statut "hébergé sur AMO" à "hébergé sur un site externe, mais avec les pages AMO, un lien dans AMO pour le téléchargement, la page stat, etc" ? Faut-il préalablement supprimer toutes les versions hébergées sur AMO ? Ou bien c'est impossible, c'est un choix irréversible, et je suis bon pour mettre comme une 2°extension avec un autre UUID ?