Reprise du message précédent :
1072194522: Started emerge on: Dec 23, 2003 15:48:42
1072194522:  *** emerge --fetchonly >=sys-apps/portage-2.0.25
 
Une gentoo que j'administre, mais ce n'est pas moi qui l'ai installée !

 
Ah ouais pas mal ! perso je suis parti pour faire le même genre de record avec mon serveur, pour l'instant ça ne donne que ça:
 

 
Mais il en manque, l'installation du serveur n'a pas commencé par mysql...  

Bon par contre apres 7 ans de gentoo ~x86 je suis passe a Arch et au 64bits cet ete

Et alors comparé à Gentoo ca donne ? Pourquoi avoir quitté Gentoo?

Pour la baisse de qualite des ebuilds, au moins en ~x86 (trop souvent des erreurs de compil qui me faisaient perdre mon temps. Le temps de compil en arriere plan et nice 20 ne me genaient pas, mais les updates qui s'arretent tous les 3 packages a cause de problemes d'ebuild, si)
Je trouve qu'il manque certains raffinements de gentoo (notamment eselect opengl ) mais l'essentiel de ce qui m'interesse est la (distro sans release avec updates en permanence)

En même temps l'architecture à la pointe de nos jours, c'est l'amd64 (les ebuilds arrivent ensuite en x86).

ce n'est pas une raison je trouve

Sûr que la majorité présente ne doit pas laisser une minorité de côté .
Bon, aussi, de nos jours, rester en 32bits, c'est un peu rétrograde!

bah normalement l'un des « avantages » de gentoo était justement ce support de multiples architectures, de personnalisation de la distribution...
On a vraiment l'impression que gentoo meurt

Je suis tout à fait d'accord, mais je parlais de rester en 32bits, alors que l'on a un processeur 64 bits.
Quant à la mort de Gentoo, je trouve plutôt qu'elle se porte bien pour une "mourante".

Personnellement j'utilise les 2 mais gentoo plutôt côté serveur et Arch côté client. J'ai utilisé gentoo côté client mais j'ai été un peu déçu quand j'ai mis à jour gnome et que les 3/4 de mes menus ont disparu ²
Mis à part ce problème, ces 2 distributions ont leurs avantages :

• gentoo : les useflag. Par exemple, j'ai pas besoin de tout ce qui se réfère à X sur un serveur, pas de problème, je peux empêcher tout ça via les useflags. Pareil pour à peu près tout, IPv6, gtk, qt, etc... Emerge est pas mal niveau gestionnaire de paquet.
• arch : c'est simple d'utilisation (enfin c'est pas fait pour les newbies non plus), les binaires rendent les mises à jour plus rapide et c'est léger. Je trouve que niveau desktop, ça rempli bien son rôle dans la mesure où j'ai pas envie de compiler pendant toute la nuit. Sur mes serveurs (@home pour le moment), vu le nombre d'utilisateurs, c'est moins derrangeant.

Les 2 distributions ont de la documentation de bonne qualité, les paquets à jour sont disponibles très rapidement. Les 2 sont en rolling release. Après ça dépend des goûts de chacun, mais je trouve ces 2 distributions de très bonne qualité

Bon je sais que c'est pas une découverte pour beaucoup d'entre vous mais récemment j'ai testé le /tmp en tmpfs et quel gain de temps sur les compilations ! Avec ma nouvelle machine, une brute (core i5 750, 4go de ram) je me suis amusé à compiler openoffice en tmpsfs (il utilisait donc à peu près 3.5 go de ram - 500 mo utilisés par le système - et le reste de swap, et forcément le système était relativement lent pendant la compilation) et résultat, 1heure et 3min pour compiler tout Openoffice :-O
 
Je suis au passage passé au 64 bits et je m'attendais à des problèmes... J'en ai pour l'instant aucun, ça marche plutot très bien !

Chez moi .

Quel matériel ?? :-)

Celui qui est indiqué via la petite icône (AMD PhII 940).

Passage de Xorg-server-1.7 à Xorg-server-1.8 (dispo dans l'overlay X11) réalisé en suivant la page suivante : http://forums.gentoo.org/viewtopic-t-820551.html J'ai suivis ce guide en adaptant un peu et c'est passé tout seul.
 
Aucune difficulté particulière rencontrée.  

Juste par curiosité : certains d'entre vous sont-ils passés à Funtoo ?

J'y ai fait un tour, j'en suis revenu.

Pour quelles raisons ?

funtoo-cautionary (le package.mask spécifique à funtoo) est vraiment très chargé !
Je sait pas si ça a changé mais certains paquets n'étais même pas présents dans l'arbre (pas masqués, pas présents) comme les versions récentes d'udev bannies car elles cassent la compatibilité avec le noyau de RHEL.
 
La synchronisation de l'arbre via git est rapide mais moins robuste que rsync, suffit de modifier localement un fichier et ça marche plus (facile à réparer en entrant la bonne commande git directement, mais gênant quand-même)

 
Mouai . Drole d'argument .

Pourquoi drôle ? t'a jamais corrigé ebuild à la gruik pour que ça compile en te disant "pas la peine de passer par l'overlay, se sera corrigé au prochain sync".
 
Et quand emerge --sync te jette et que tu dois chercher dans la doc de git la commande à lancer pour synchroniser l'arbre en ignorant les fichiers modifiés, tu perd vite le temps que tu a gagné grâce à la synchronisation via git.

Non quand j'étais sous Gentoo je me rapelle pas avoir editer un ebuild comme un porc directement.
Et accesoirement, peut etre que le fait de bien connaitre git me permet de ne pas me soucier de ce que tu décris, et justement permet de rendre l'edit d'ebuild en local persistant et mergeable avec les modifs upstreams.
 
Donc je pense que le passage a Git (actuellement je suis sur OSX avec un package manager qui marche sous Git) est très bénéfique à Gentoo, et devrait permettre de faciliter les remontées de patches/update

Gentoo a l'intention de passer à Git pour la gestion de l'arbre Portage. D'après un mail sur ma mailing list, il reste encore quelques problèmes à corriger avant que la migration puisse avoir lieu.

Cette distribution m'a l'air d'avoir pas mal évolué depuis que je l'ai quittée. Ma période Gentoo c'était 2002-2005 (et à l'époque, compiler OOo, ça me prenait un peu moins de 5h avec un Athlon XP3200+  ).  
Le côté rolling release me manque.
Je sens que je vais me tâter ferme dans les semaines à venir. Archlinux a l'air sympa aussi.
 
Mode lurker = On
 

GCC 4.5 est sorti en upstream !
les nouveautés : http://gcc.gnu.org/gcc-4.5/changes.html
l'annonce sur DLFP : http://linuxfr.org/2010/04/14/26729.html
 
Il n'est pas encore dans portage mais ça devrait arriver assez rapidement (hard masked certainement). Pour moi ce sera un emerge -e world avec le -march=atom
 
PS : je m'excuse auprès des non gentooïstes pour la phrase qui risque d'être légèrement incompréhensible

Je suis passé à un gcc hardened depuis pas longtemps, alors il va falloir que j'attente que le patchset hardened soit prêt!  
 
Il y a des trucs intéressants dans le changelog ? J'ai vu que le forum Gentoo, il parlait du flag -flto. A voir ...  
 
edit : j'avais pas vu le lien vers linuxfr, je vais lire ca.

Après lecture de la news, LTO et les options qui vont avec semblent intéressant. A voir ce que ca donne dans la pratique cette histoire.

Tout dépend ce qui te plaisait sous gentoo... Si c'est juste le rolling release il y a d'autres solutions. Moi si j'y suis c'est pour sa stabilité hors du commun comparé aux autres distrib (même plus pour l'optimisation, une fois qu'on a du matériel récent on voit plus trop la différence hein)

 
[+ ou - HS]
Je n'ai pas l'impression d'être moins stable sous Ubuntu que j'ai pu l'être sous Gentoo. Mes machines ne redémarrent que pour les mises à jours du noyau.
Ce qui m'a fait quitter Gentoo à l'époque c'est justement que je ne voyais déjà plus trop de différence côté performance (pas de Troll, c'était juste mon impression pleine et entière, d'ailleurs même Ubuntu a fini par arrêter de faire des noyaux distincts par type de proco et faire un noyau generic), et j'y gagnais en rapidité d'installation/maintenance.
En revanche, ce qui me gêne avec Ubuntu, c'est que si tu deviens un tout petit peu impatient, tu pourris assez rapidement ton installation en ajoutant des dépôts (encore une fois c'est mon impression. Ex: le PPA pour firefox/thunderbird où tu perds la traduction en français. Alors oui, tu peux aller chercher le .xpi qui va bien à chaque mise à jour, mais ça en devient pénible). J'utilise majoritairement des PPA, mais il en faut quasiment un pour chaque logiciel que j'utilise couramment. D'où l'idée de revenir sur une distribution en rolling release (et que je connaissais, tant qu'à faire), plutôt que de "simuler" ce comportement pour certains logiciels dont j'ai une utilisation courante.
Surtout que je garde un très bon souvenir du fonctionnement général de Gentoo (même si j'en ai chié à l'époque pour la configuration de ma radeon 9600pro )
 
En espérant avoir été assez constructif et pas trop hors-sujet  
[/+ ou - HS]

Astuce du jeu (relative à la mise à jour mesa) : sdl-gfx à recompiler avant mjpegtools afin que ce dernier compile.

 
Voui je sais que... Je suis souvent un peu seul à faire ce constat. J'en tire pas trop de conséquences générales, ça doit être relatif à mon utilisation, je sais pas. J'ai tendance à pousser ma machine assez loin (multitâche intensif, reboot rare, avec machines virtuelles & co) et je supporte pas les plantages et gentoo est vraiment la seule distrib qui m'a donné satisfaction concernant la stabilité (debian stable aussi, mais j'aime avoir des versions des softs un peu à jour). Mais bon ça n'engage que moi on va dire...

Je viens de voir que gcc-4.4.3 est passé en stable!  
 
Bonne recompilation!
 
J'ai fais un peu de ménage sur ma distrib depuis quelques temps. J'ai viré tous les flags de compétition, et gardé le minimum! Et, il y a quelques mois, je suis passé en repassé en stable. Petit récit....
 
Comme j'ai déjà pu le dire ici, j'utilisais un système Gentoo ~amd64 (branche testing donc) avec un certain nombres d'ebuilds "instables" masqués ou sans keyword voire live (ebuild *-9999). Le résultat de tout cela est un excellent terrain de jeux sur lequel j'ai pu tester pas mal de choses, de nouveautés et bidouiller tel un geek!
Toutefois, je recontrais un problème de plus en plus pénible : je passais beaucoup de temps à essayer de faire marcher mon système (parfois des choses simples), à chercher des workarounds à droite et à gauche, à essayer de faire compiler tel ou tel ebuild ... Au final, j'avais un système relativement instable sur lequel j'avais régulièrement des choses cassées. Quand je ne suis pas en période de projets scolaires ou que je suis seul à utiliser ma machine, c'est gérable mais quand je dois utiliser ma machine c'est problématique d'avoir X cassé par exemple. Ou alors expliquez à votre copine qu'un truc donné ne marche plus parce que vous avez mis à jour un ebuild masqué et que maintenant vous avez X dépendances cassées et ... que la machine est inutilisable : donc là, vous avez droit à un "tu n'as qu'à utiliser Windows" Aie aie aie ca fait mal à son égo
Bref, ajouté à ca le fait que j'ai une machine qui n'est plus toute jeune, ma Gentoo devenait de plus en plus difficile et pénible à maintenir...
 
Quelle est la solution ? Allez voir ailleurs ? J'en avais pas vraiment envie. Alors suite à une discussion sur le forum Gentoo, j'ai décidé de repasser ma Gentoo en stable.
 
Comment faire cela ? Downgrader tout comme un porc en repassant la variable accept_keyword à "amd64" et en lancant un "emerge -e world" ? Certainement pas! Cette technique m'aurait sans doute mené droit à la catastrophe. J'ai alors décidé d'employer une technique nécessitant plus de patience! Elle consiste à lister les ebuilds installés et à les ajouter avec le keyword adéquat (~amd64) dans un fichier de keyword, de passer la variable accept_keyword à amd64 et de laisser le temps faire. En gros, on passe le système en stable en lui disant que tous les paquets installés sont en version ~ : avec le temps, ces ebuilds vont être passés en stable, et pourront être supprimé du fichier. C'est donc une longue étape!
 
J'ai commencé par lister tous les ebuilds installés et à les ajouter à mon fichier /etc/portage/package.keywords avec le keyword ~64. Ensuite, j'ai passé la variable accept_keyword à "amd64".
 
Maintenant, comment savoir quels ebuilds ont été stabilisé ? J'ai découvert un outil génial : portpeek! Initiallement (en Janvier si je me souviens bien), j'ai ajouté près de 1300 ebuilds dans un fichier de keyword. Après un premier passage de portpeek, il m'en restait plus que 700 ! Aujourd'hui, il me reste 280 ebuilds dans ce fichier! Sachant que j'ai fais du ménage sur mon système (déinstallation de pas mal de programmes + nettoyage du world à la mano), que certains ebuilds vont restés en testing un bon moment (OpenRC par exemple) et que j'utilise certains programmes encore stabilisés (par exemple, KDE4.4).
 
Cette "petite aventure" est une des raisons pour lesquelles j'apprécie beaucoup Gentoo : on en fait ce qu'on veut! On peut passer de branche en branche (moyennant patience)! On peut mixer des branches!!
 
Résultat : j'ai désormais un système beaucoup plus stable! Et la modularité de Gentoo me permet toujours d'installer des programmes "non stables" grâce aux keywords!

Je remarque que gcc-4.4 est stable en amd64 mais pas encore en x86. On n'a plus une version qui est en avance sur l'autre !
 
Environ 370 ebuilds dans packages.keyword sur mon amd64 "stable". Mais 27 sur le eeepc, déjà en ~x86  
J'adore cette distribution   on peut avoir quelquechose de stable ou bien une machine de test pour les versions de développement.

Je pose mon drapeau, je suis pas encore sous gentoo, et très franchement j'ai pas prévu d'y passer tout de suite, mais je trouve ce genre de distributions passionnante, donc je vais zieuter le topic

Je suis passé à X-Server 1.8.1 (depuis la 1.7.7) hier : tout fonctionne bien, mais, je ne suis pas arrivé à mettre mon kdm en azerty (je n'ai pas le flag hal actif pour le xorg-xserver).
J'ai bien tout de francisé à part cela (j'ai même revérifié via kdesu systemsettings, tout est bien réglé à ce niveau).
 
Sinon, à part dans kdm, je suis bien en azerty partout donc.

J'ai cassé lvm

Pareil pour kdm ici. Je n'ai pas pris le temps de regarder ca, je m'y suis fais. Si jamais tu trouve une solution, je veux bien la connaître.
 
Tu as cassé lvm, càd ? Tu as moyen de récupérer ca ou c'est mort ? :s

Ben j'ai un device qu'a disparu depuis le dernier shutdown. Pas eu le temps de chercher. J'espère que c'est juste un pb de config et pas un disque qu'est mort

Avec mon Phenom II 940 @3.4Ghz (pas de ccache) .