VINDICATORs wrote:Tu récupère une version stable pour tes paquets, voir mieux la version à support long. Là tu dois sans doute récupéré la version de développement.

J'utilise le lien qui est donné par Mozilla sur leur site mdn a savoir https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/. Lorsque tu télécharges les binaires proposé par le site, ils sont bien en version finale donc je me dit qu'il doit y avoir une astuce afin d'avoir aussi une version finale. J'ai aussi essayer d'utiliser le dépôt git mais j’obtiens le même résultat. La dernière version "LTS" est la version 27 il me semble et j'ai le même résultat.

nouvo09 wrote:

je sais que je parle de centos sur un forum FEDORA

Il sert à quoi alors le forum Centos ?

Comme je l'écris dans mon post je fais mes test sur mon PC perso en FEDORA et de toute façon mon problème est indépendant du système donc peu importe le forum sur lequel je vais, tout ce que je cherche c'est compiler Firefox en version finale.

nouvo09 wrote:Alors pourquoi ne pas prendre le binaire sur le site Mozilla ?

Tous simplement parce que je souhaiterais supprimer des fonctionnalités comme la mise à jour (les utilisateurs ont généralement le compte root) et aussi le crash report (demande du client pour cause de site sensible).

Malheureusement, si tu savais ce que certaine personne sont capable de faire avec un compte root. Le premier exemple qui me viens à l'esprit est dans l'un des services de la boite ou je bosse, les PC sont masterisé en ubuntu 12.04, une personne a appelé la hotline pour signaler que sont poste ne démarrais plus. Après avoir discuté avec lui, j'ai appris que grâce à ces droits sudo il avait migré son PC en ubuntu 14.04 tous ça parce qu'il avait vu un message en ouvrant un terminal. C'est pour sa que je souhaiterais verrouillé la chose au maximum et comme on peux retirer la fonction en compilant le soft je voulais passer par la. Enfin on a notre propre dépôt pour pouvoir rajouter des soft dans le master et je ne pense pas que yum prenne en charge les fichiers tar.

nouvo09 wrote:

je ne pense pas que yum prenne en charge les fichiers tar.

non mais tu peux packager toi-même.

Le but est justement de faire un RPM mais avant il faut que je puisse compiler une version finale or pour l'instant j'ai une version nightly. On en revient donc a mon premier post et à ma question d'origine : comment faire ?

En effet la version esr serais pas mal, le tar que je récupère et celui donné sur le site mdn ou alors j'ai aussi cette adresse : https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/. Le tar est fournit parmi des binaires en version stable. Je viens de voir ton lien et il fourni uniquement des binaires et pour ce qui est du dépôt git je vais aller y faire un tour histoire de voir ce que ça donne. Enfin pour le src rpm, je vais devoir réinstaller ma machine de test en f20 car à l'heure actuelle elle est en f21.

VINDICATORs wrote:Euh? t'écoute ce que je te dis????

Utilise mock, il te construira un environnement pour la version de fedora que tu souhaite faire les paquets! Donc ta nullement besoin de toucher à ton système.

Tu dois même pouvoir en faire pour CentOS/RHEL...

Et en plus tu n'a pas besoin de te limiter à l'architecture de ton ordi...

Oui j'ai bien "écouter" ce que tu m'as dit et le lien que tu donnes dans ton précédent post est celui des binaires. J'utilise mon PC perso en fedora pour tester et créer le spec, Au boulot j'ai une machine dédié en centos 6.4 64 bits avec tous ce qui faut pour créer des RPM.
Pour ce qui est de ne pas toucher au système c'est uniquement lors de l'installation du paquet, c'est pour ça que j'installe tous dans /opt.

Mon principal soucis pour l'instant et juste de compiler une version finale fonctionnelle. Pour l'instant tous ce que je fais c'est créer un fichier mozconfig dans la racine du répertoire et ensuite je fais juste un make -f client.mk build; make -f client.mk package, ensuite je récupère le tar et je test. Sur mon PC perso j'ai aussi un compte utilisateur pour packager et pour ce qui est de l'architecture, mon PC possède un I5 donc en 64 bits et les postes sur lequel sera installé mon paquet sont toute des stations de calcul en xeon (voir en bi-xeon) 64 bits
La création du RPM se fera quand j'aurai une version stable et nom pas nightly et en plus comme j'ai téléchargé les src rpm, j'ai un exemple à partir duquel démarrer.

marc2006 wrote:Oui l'environnement de construction est sous un utilisateur spécifique 😉

http://doc.fedora-fr.org/wiki/RPM_:_environnement_de_construction

Les parties qui t'intéressent sont les suivantes :
2- Création de l'utilisateur (builder, ou mock, ou autre, peu importe)
3- Installation des outils (je pense que pour toi, il suffit de faire un

yum install rpmdevtools yum-utils

)
4- Création de l'arborescence (en fait, il s'agit juste de lancer la commande

rpmdev-setuptree

)
7- Construction à partir du fichier SPEC

En fait, après avoir crée l'arborescence (étape 4), il faut que tu récupères le .src.rpm de firefox que tu auras récupéré des dépôts par yumdownloader (qui ne peut pas être une nightly sauf si tu es en rawhide lol) et que tu "l'installes". Il va s'installer dans les répertoires de l'utilisateur dans les dossiers appropriés.

Puis après à toi de modifier le .spec, et après hop reconstruction à partir du spec et tu obtiens le rpm =)
Rien ne t'empêche après de modifier l'archive utilisée par le .spec par une autre archive, récupérée du site de mozilla par exemple d'un des liens donnés par VINDICATORs 🙂

Merci pour les infos mais comme je l'ai dit plus haut je n'en suis pas encore a cette étape la et j'ai une machine dédié avec un compte utilisateur pour la packaging, j'y ai installé tous les outils nécessaire de la même façon que sur FEDORA (il existe aussi un méta paquet "fedora packageur") j'ai simplement eu a mettre à jour python car la version sur centos est bloqué à la 2.6.6 alors que Firefox demande la version 2.7. pour la compilation. je me suis installé un dokuwiki sur un hébergeur gratuit et je me suis fais un tuto en utilisant entre autre le lien que tu donne dans ton post et je me suis fais mon propre squelette de fichier spec. Avant Firefox j'ai réussi à packagé gcc, make, cmake et keepass 2, bien évidemment les paquets ne sont pas de la même qualité que ceux fournit par la distrib car je n'incorpore pas de patch et divers autre modif, mais ils sont quand même fonctionnel et cela me permet d'avoir la dernière version de gcc sur ma machine centos et aussi sur FEDORA avant mon passage à la 21.
Pour ce qui est d'utiliser le fichier spec des src RPM de FEDORA ce ne sera pas possible tel quel car après en avoir lu un, ils sont fait pour fonctionner uniquement pour FEDORA. Ils y a des patchs pour FEDORA et Red Hat, qui est le packageur, incorpore des patchs spéciaux pour FEDORA. Je vais m'en servir de model et probablement récupérer 2 ou 3 infos utiles. Enfin comme le disait VINDICATORs, je me suis tourné vers le dépôt git de mozilla et en creusant un peux j'ai trouver un dépôt..... mercurial a cette adresse et la tu as les branches aurora, beta et release et en plus il y a aussi le dépôt l10n pour les fichiers de langues. J'ai lancé une compilation avant de partir du boulot et j'aurais le résultat demain matin, j’espère donc que cette fois si ce sera la bonne. A voir maintenant l'ajout de la traduction et la création du spec.

Autre chose : tu n'est pas obligé d'installer les fichiers srcrpm, tu peu très bien les télécharger et ensuite les "décompresser" en utilisant rpm2cpio FichierRpm.rpm | cpio --extract.

Si tu souhaites m'aider, je veux bien merci tout ce fera en 64 bits. Pour ce qui est de la version des dépendances, c'est Firefox qui demande d'avoir python 2.7 et j'ai d’ailleurs trouver 3 paquets à installer sur le site rpm search. Voici une liste des paquet à installer pour compiler Firefox :

yum groupinstall 'Development Tools' 'Development Libraries' 'GNOME Software Development'
yum install autoconf213 glib-static yasm alsa-lib-devel pulseaudio-libs-devel libXt-devel hunspell-de

Je te donne aussi le contenu du fichier mozconfig à mettre à la racine du répertoire de compilation

ac_add_options --enable-optimize
ac_add_options --enable-extensions=default
ac_add_options --enable-application=browser
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-webm
ac_add_options --enable-webrtc
ac_add_options --enable-ogg
ac_add_options --enable-system-hunspell
ac_add_options --enable-libnotify
ac_add_options --with-system-zlib
ac_add_options --with-system-bz2
ac_add_options --with-pthreads
ac_add_options --with-distribution-id=org.mozilla
ac_add_options --disable-updater
ac_add_options --disable-crashreporter
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-libjpeg-turbo
ac_add_options --disable-cpp-exceptions
ac_add_options --disable-system-sqlite
ac_add_options --without-system-libvpx
ac_add_options --prefix=/opt/mozilla/firefox
mk_add_options MOZ_MAKE_FLAGS="-j4"

Ensuite pour compiler, il te suffit (toujours en étant à la racine du répertoire) de lancer la commande :

make -f client.mk build

En ce qui concerne les sources, je suis passer par le dépôt mercurial car les dépots srcrpm n'ont pas été synchroniser sur le serveur du client mais je peux éventuellement les récupérer sur rpm search ou rpm find et éventuellement faire un tour sur epel.
Pour infos le dépôt mercurial se synchronise comme ceci :

hg clone https://hg.mozilla.org/releases/mozilla-release release

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