Pour ce qui est de la compilation, j'évite pour l'instant de toucher aux variables cflag et autre à partir du momment ou sa marche je n'ai pas trop envie de me prendre la tête. Pour recompiler un srpm tu peux faire sa :

rpm --rebuild toto-1.3-2.src.rpm

je ne sais pas comment faire sous ma F20 pour compiler pour une CentOS je n'ai jamais testé

Que tu compiles sous fedora ou sous centos, sa ne change rien au fichier spec. De toute façon j'ai ce que je voulais à savoir une version finale de Firefox et pour ce qui est du fichier spec, je pense avoir un fichier spec exploitable. je doit vérifier encore 2 ou trois choses mais sa devrais aller. Merci beaucoup pour ton aide.

remi wrote:Bah... je compile habituellement directement dans un tmpfs de 12G. Oui, ça aide beaucoup.

Je m'en suis fait un de 14 Go et j'ai retesté une compilation et je n'ai pas vu de différence. C'est peut être la RAM qui est trop vieille et c'est pour ca que je n'ai pas de gain par rapport au disque dur, en tous cas merci pour l'info, je réutiliserais sa pour d'autres occasions.

par contre le xpi je comprends maintenant que le fichier tar du langpacks contient des xpi xD Bon je suppose que le langpack est incompatible donc, mais ca ne devrait rien changer lol

J'ai regarder comment sa se passe et il suffit juste de le décompresser avec la commande unzip.

--disable-multilib c'est aussi ce que j'ai utilisé et je n'ai aucune erreur particulière pour la compilation de gcc c’était juste pour savoir comment tu avais fait c'est tous

Directement dans le rpm ? Flash je pense c'est possible, en copiant les fichiers directement aux bons emplacements, mais le langpack je ne sais pas où récupérer le dernier en date ! Peut-être en récupérant le source rpm de fedora...

Oui il suffi juste de copier le fichier .so dans firefox/browser/plugins, donc rien de bien compliqué. Pour le language pack tu peux partir du fichier xpi qui se trouve ici c'est la méthode qui est utilisé par Red Hat dans le src RPM que j'ai vu sauf que eux le font avec 5 ou 6 langues différente.

remi wrote:J'ai longtemps maintenu les rétro-portages des applications Mozilla dans mon dépôt
Les anciens spec doivent donc trainer sur mon github [1] il reste peut-être des trucs intéressant dedans.

Ça devient juste une torture de l'esprit pour faire les choses proprement..
De mémoire, je devais utiliser les SCL de python27 et de devtoolset (pour gcc 4.8)
Sans parler que c'est un petite heure de compilation par paquet (sur une machine un peu optimisée et prévue pour)

perso, j'ai abandonné, trop d'effort pour le peu d'intérêt que cela représente.
- la version en standard (version ESR) est correctement maintenue
- la version officielle de chez Mozilla doit fonctionner
- utilisee C6 en desktop, c'est juste du vice


[1] https://github.com/remicollet/remirepo

Merci pour l'info, mais je ne compte pas suivre l'évolution des version je m’arrêterais à la version 33.x. Comme je compte aussi y intégrer le plugin flash, je referais probablement un paquet avec la mise à jour et c'est tous. Par contre ta machine est sacrément optimisé ou éventuellement dopé car j'ai un quad core 3.3 Ghz et 16 Go de ram et je met 3 heures pour compiler. Enfin connaissant ta valeur pour ce qui est de la création de RPM, ton site est le premier auquel j'ai rendu visite lorsque j'ai commencer à faire des RPM et aussi lorsque j'ai décider de m’attaquai à Firefox et il me semble avoir vu une référence à ton dépôt git et j'ai récupérer certain fichier qui apparement date de l’université ausssi :hammer:

marc2006 wrote:Ben fait, tu n'as pas le choix pour les patchs, bon je viens d'enlever le duckduckgo, mais les autres ne fonctionnent pas, enfin il me demande lors de la compilation quel fichier il faut patcher. J'en conclus que les patchs ne sont plus bons pour la dernière version ? (j'ai pris le source rpm de centos, mais je travaille sur le source tar de firefox 33.1.1).

Ou peut-être tu as une solution ?

Pour l'erreur de GLIBC, gcc en dernière version est installé sur /usr/local, mais le chemin de la compilation est celui du gcc du système. J'ai mis dans le fichier spec export LIBDIR=/usr/local/lib64 pour voir au lieu de export LIBDIR='%{_libdir}'.

J'ai utilisé ton .mozconfig là, il est en train de compiler ... Dans le fichier spec, j'ai supprimé toute la partie if ... ac_add_options ... car je voulais être sûr qu'il utilisait le fichier .mozconfig renseigné.

Après, j'ai laissé le langpack de la version 31.2.0 ... Je sais pas trop ce que ca va donner lol
PS : on dirait qu'à un moment, j'ai l'impression de voir un message WARNING de configure qui ne reconnait pas beaucoup des paramètres du mozconfig oO J'avais vu ça hier, mais en lançant la commande make manuellement (pas du spec). J'ai aussi l'impression qu'il ne prend pas en compte la ligne mk_add_options MOZ_MAKE_FLAGS="-j4" car c'est lent lol dans le fichier SPEC, il y a bien un if pour donner une valeur à ce paramètre mais n'a pas l'air de prendre en compte la valeur du SPEC.

Si tu veux juste tester le mozconfig histoire de voir s'il y a une erreur, un bon vieux ./configure fonctionne très bien. Pour les question de variables d'environnement, un script dans /etc/profil.d fonctionne très bien et sa te permet de modifier la variable PATH et la variable LD_LIBRARY_PATH. Au fait petite question, quand tu as compilé GCC, dans les options du configure, est ce que tu as utilisés l'option --disable-multilib et comment as tu fais pour les dépendances ?

Enfin pour Firefox et les patch ne t’embête pas avec sa, il marchera très bien sans et tous ce que je vais rajouter c'est le language pack fr et le plugin flash.

En arrivant au boulot vendredi matin, ma compilation était terminée et le résultat était encor et toujours une version nightly. J'ai don retester avec les lignes suivantes

export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
ac_add_options --enable-official-branding

et sa marche, tu arrives bien à avoir une version finale. En regardant dans l'aide, il est dit que l'on a pas le droit d'utilisé --enable-official-branding sans l'accord de mozilla, j'ai donc retester sans et la compilation fonctionne mais la fonction de packaging plante tous comme le make install. Donc maintenant mon fichier mozconfig ressemble à sa :

c_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 --enable-address-sanitizer

ac_add_options --without-system-libvpx
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 --disable-gamepad
ac_add_options --disable-parental-controls
ac_add_options --disable-logging

ac_add_options --prefix=/opt/mozilla/firefox
mk_add_options MOZ_MAKE_FLAGS="-j4"
export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1

Pour ce qui est de la création du spec, je n'ai pas encor commencer et en plus du ducduc go je pensais aussi utilisé le patch Red Hat sur la config du navigateur.
En ce qui concerne ton erreur, j'ai l'impression que le problème ne viens pas du chemin de la librairie mais plutôt de la version si tu regarde biens l'erreur suivante :

/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

Ensuite la version de gcc est installé dans /opt et pour les librairies j'utilise la variable LD_LIBRARY_PATH et je n'ai aucun soucis

Enfin oui le rpm est le but finale de ma démarche et une fois fini et comme j'aime avoir mal je voudrait embrayé sur Thunderbird et xulrunner.

Je n'utilise pas mock car les paquets sont pour moi et quelques pote qui ont la même version de fedora que moi et pour ce qui est de centos j'ai une machine a disposition au boulot. Hier soir avant de partir, j'ai relancer une compilation avec les paramètres suivant en +

export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
ac_add_options --enable-official-branding

Après à voir si c'est pas normal l'histoire du nightly. Voir si ce n'est pas juste un fichier spec de compilation qui le marque comme ça.

C'est ce que je vais essayer de faire dans la matinée, si ma compilation d'hier soir n'a rien donné je vais utilisé la clé de Red Hat pour relancer une compilation et voir ce que sa donne. Si sa marche, je laisserais tombé et je packagerais des versions nightly.

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

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

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.

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.

Bonjour,

merci pour l'info, j'ai suivis ton conseil mais ça n'a rien donnée. J'ai compiler les sources du RPM mais j’obtiens toujours une version nightly, la solution doit être dans le fichier mozconfig ou dans le fichier spec malheureusement je piétine toujours. Si quelqu'un a une autre suggestion pertinente je suis preneur.

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 ?

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: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).

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.

Bonjour,

dans le but de faire un package de Firefox, de Thunderbird et de Xulrunner sur un master centos 6.4 figé, je me suis donc renseigné sur le net à gauche et à droite et j'ai finalement réussi à compiler une version de Firefox qui fonctionne. mon problème c'est que lorsqu’on lance Firefox on obtient une version nightly. Sur mon PC perso sa ne me gênerais pas plus que sa mais les packages sont pour un cadre professionnel et destiné à des chercheurs qui sont pour la plus part développeur sous Linux. Je souhaiterais donc savoir si quelqu'un connaît le moyen de compiler une version finale. Pour ce qui est du packaging je pense m'en sortir seul. Pour information sous centos 6.4 la version de Firefox est en 17.0.8 et je souhaiterais installer la 33.1, je sais qu'il serais plus facile de migrer en 6.5 mais cela est hors de question car c'est une exigence du client. Il doit probablement aussi existé des packages déjà tous fais mais contrairement à la création de package, je maîtrise parfaitement l'utilisation de yum et de plus le but du jeux est aussi de faire une installation en parallèle afin de pouvoir revenir en arrière sans problème en cas de soucis

D'avance merci

PS : je sais que je parle de centos sur un forum FEDORA, mais c'est la même famille et pour ma défense je m’entraîne sur mon PC perso qui vient de passer de FEDORA 20 à FEDORA 21 :-D

Bonjour,

J'ai tester le passage vers fedora 21 sur un poste de test et à la fin du téléchargement des packages, le processus est sortie en erreur car les clés pour les dépôts RPMFusion n’étaient pas installé. J'ai donc installé les RPM à partir du dépôt et c'est passé sans soucis. Je suis donc passé sur mon portable qui a eu le même problème et qui a été résolu de la même façon que précédemment par contre pour mon fixe j'ai carrément été obligé de désinstaller les dépôts, de lancer FEDUP, de réinstaller les dépôts et de réinstaller des logiciel comme Firefox et VLC qui ne fonctionnaient plus par manque de dépendances. Et maintenant tous ce petit monde fonctionne normalement

Le seul problème que je n'ai pas encore résolu est celui du logiciel eclipse qui ne démarre pas car il cherche la version 1.7 de java et il ne la trouve pas et après une recherche dans les dépôts elle n'existe plus et il ne reste que la 1.8.

Dans ce cas précis c'est pas faut, mais au boulot je bosse sur des machine en centos 5.5 et en mandriva 2010 et comme les dépôts ne sont soit plus maintenus soit inexistants faire des installations dans /opt sa peux aider a revenir en arrière. je pense par exemple à Firefox ou Thunderbird voir meme d'autre logiciel que l'on install dans ce répertoire lors du make install ou de la décompression du tar.gz. A partir de la je testerais mon rpm sur une VM et je modifierais la section files en conséquence en cas de soucis. Merci pour ton aide.

En effet je vais voir sa merci pour l'info. Dans les tutos présent sur le site j'ai vu que l'on pouvait tester la "qualité" du paquet avec rpmlint. Si je lance la commande j'ai des messages d'erreur de ce genre la :

keepassx.x86_64: E: explicit-lib-dependency libgcrypt
keepassx.x86_64: E: explicit-lib-dependency zlib
keepassx.x86_64: W: spelling-error Summary(en_US) Logiciel -> Geologic, Ecologic, Logic
keepassx.x86_64: W: spelling-error Summary(en_US) de -> DE, ed, d
keepassx.x86_64: W: spelling-error Summary(en_US) gestion -> gestation, ingestion, digestion
keepassx.x86_64: W: spelling-error %description -l en_US Keepass -> Keep ass, Keep-ass, Keepsake
keepassx.x86_64: W: spelling-error %description -l en_US un -> UN, nu, in
keepassx.x86_64: W: spelling-error %description -l en_US logiciel -> geologic, ecologic, logic
keepassx.x86_64: W: spelling-error %description -l en_US de -> DE, ed, d
keepassx.x86_64: W: spelling-error %description -l en_US gestion -> gestation, ingestion, digestion
keepassx.x86_64: W: spelling-error %description -l en_US qui -> quin, quit, quid
keepassx.x86_64: W: spelling-error %description -l en_US permet -> permit, pelmet, cermet
keepassx.x86_64: W: spelling-error %description -l en_US geré -> germ, Gere
keepassx.x86_64: W: spelling-error %description -l en_US des -> eds, es, dies
keepassx.x86_64: W: spelling-error %description -l en_US stoquées -> toques
keepassx.x86_64: W: spelling-error %description -l en_US dans -> sand, sans, fans
keepassx.x86_64: W: spelling-error %description -l en_US une -> rune, tune, dune
keepassx.x86_64: W: spelling-error %description -l en_US données -> doyennes
keepassx.x86_64: W: spelling-error %description -l en_US chiffré -> chiffon
keepassx.x86_64: W: spelling-error %description -l en_US à -> e, s, i
keepassx.x86_64: W: spelling-error %description -l en_US l'aide -> Adelaide
keepassx.x86_64: W: spelling-error %description -l en_US d'un -> dun, Dunn
keepassx.x86_64: W: spelling-error %description -l en_US chiffrage -> chiffonier
keepassx.x86_64: W: incoherent-version-in-changelog (2014-04-06) ['2.0-alpha6.fc20', '2.0-alpha6']
keepassx.x86_64: W: invalid-license BSD GPL-2 GPL-3 LGPL-2.1 LGPL-3
..........

keepassx.x86_64: E: dir-or-file-in-opt /opt/keepassx2/share/keepassx/icons/application/16x16/actions/entry-new.png
keepassx.x86_64: E: dir-or-file-in-opt /opt/keepassx2/share/keepassx/icons/application/16x16/actions/document-save.png
keepassx.x86_64: E: dir-or-file-in-opt /opt/keepassx2/share/keepassx/icons/application/22x22/actions/document-save.png
keepassx.x86_64: E: dir-or-file-in-opt /opt/keepassx2/share/keepassx/icons/application/16x16/actions/entry-delete.png
1 packages and 0 specfiles checked; 142 errors, 23 warnings.

J'en ai mis un extrait car il liste tous les fichiers se trouvant dans /opt. Est ce que c'est problématique ou alors est ce que sa va passer à l'installation ? Je vais l'installer sur une VM et voir ce que ça donne. Grace à toi, Je vais aussi pouvoir avance sur mes autres paquet à partir des binaires de Firefox et Thunderbird.

J'ai éditer le fichier spec en mettant %setup -q -n keepassx-2.0 et je viens de réessayer en mettant %setup -q -n keepassx-2.0-alpha6 puis en tapant la commande rpmbuild -ba keepass.spec et maintenant sa fonctionne merci. Il me reste maintenant à régler le probléme du raccourci ainsi que la partie %files qui donne un résultat plutôt étrange. Je souhaiterais en effet que l'applis s'installe dans /opt afin de toucher au système le moins possible et de pouvoir revenir en arrière.