CentOS 64bits 6.4 sur le site de vault c'est bien ça ?
Euh bonne question, en fait le master a été fait en aout dernier et il me semble « qu’à cette époque » c’était la dernière version en cours
Pour les src RPM j’ai pas fait gaffe, mais j’ai utilisé ceux de FEDORA 21 donc c’est pour ça que j’ai eu la version 33.1 mais de toute façon j’ai toujours une version nightly. J’ai terminé la compilation à partir de la branche stable du dépôt mercurial et j’ai toujours une version nightly, donc pour moi peu importe où tu prends les sources la solution viens forcement du fichier mozconfig.
Il te faut vraiment la version 33.1 (dispo en tar sur le site de firefox mais alors on ne pourra pas utiliser le source rpm, sans les patchs donc, mais le fichier spec doit pouvoir être réutilisable) ?
La version 33.1 est la dernière dispo et elle est compatible avec centos 6.4 donc elle est très bien comme sa et de toute façon je pense rester sur cette version sa devrait aller pour l’instant. Les patchs ne sont pas une réel obligation la version devrait bien fonctionnée comme sa et je me pencherais dessus si j’ai des remontés d’utilisateur et de toute facon la mise à jour n’est pas prévu pour un déploiement de masse mais uniquement suite à un appel hotline. Le fichier spec doit pouvoir etre réutilisatble pour les future versions 33.x oui.
Niveau fichier mozconfig, tu as mis le paramètre "--without-system-libvpx", mais webm est activé donc normalement il doit être pris en compte, c'est volontaire ?
Oui c’est volontaire car la compilation demande une version >= 1.3.0 et la version installé sur le master est la 0.9.0, j’aimerais éviter de faire des mises à jour inutile qui risquerais de cassé quelque chose dans le master ou ailleurs, c’est aussi pour cela que je n’utilise pas le paramètre --enable-startup-notification.
Donc si je comprends bien, je dois remplacer tout ça par les lignes que tu donnes en haut, right ? Bon, j'ai une erreur, forcément gcc est obsolète lol Je viens de récupérer une version 4.8 🙂 (parfois j'obtiens une erreur sur pthread, mais si je redémarre avec la commande make -f ... ca marche lol sinon, je comprends pas j'ai dû modifier des fichiers .py car il ne trouvait pas ordereddict ni une fois Counter donc j'ai mis from collections tout le temps ! alors que sous python ca marche, je ne vois pas^^ idem pour simplejson, j'ai mis import json à un moment plutôt que simplejson)
Disons que c’est avec ce fichier la que je compile mais si tu veux y apporter des modifs tu peux, les seul lignes obligatoire sont :
ac_add_options --disable-updater
ac_add_options --disable-crashreporter
ac_add_options --prefix=/opt/mozilla/firefox
Pour gcc, mes nombreuses recherches m’ont permis de trouver que mozilla conseillais au minimum la version 4.9 à cause d’un bug dans gcc si mes souvenirs sont bon. Comme j’utilise la version 4.9.2 je n’ai pas ce genre de soucis (Si tu as besoin d’infos je peux t’aider pour la compilation de gcc) et pour lancer la compilation il te faut juste faire un make -f client.mk build, il n’y a aucun fichier à modifier. Pour infos les tar.gz que tu trouves sur le site sont générer à partir de la commande make -f client.mk package.
EDIT2 : apparemment, le "nightly" qui apparait est normal, ça ne veut pas dire que c'est une version de dev mais tu ne peux pas utiliser le nom firefox car c'est protégé et donc, en recompilant, tu ne peux plus utiliser le nom firefox pour le paquet 🙂
Si c’est ça alors mon plus gros problème est résolu et en regardant le spec du src RPM j’ai vu que Red Hat utilise un fichier clé fournit par mozilla, c’est peut être grâce à ça qu’on obtient une version finale. En ce qui concerne les paquets que je créer, je n’utilise jamais le nom d’origine pour éviter que le système le voit comme une mise à jour (le but étant de faire des installations parallèles). Tous mes paquets s’appellent infogérant-toto.XXX.el6.rpm
