Reprise du message précédent :
Un ebuild a besoin que tu utilises une version nouvelle version de Portage, supportant la nouvelle API : EAPI 2. EAP2 est pratique parce qu'elle propose le gestion des dépendances par useflags.
 
Unmask la dernière version de Portage et hop ca va rouler!
 
Perso, j'ai la dernière version de Portage et ca va niquel!

Gentoo réparée! \o/ Ca fait plaisir!!
 
J'ai recompilé les applis dépendant de QT, et elle boote de nouveau! Oui oui j'ai explosé Grub en installant une Fedora en //  
 
Il faut que je fasse du ménage (j'en ai marre de compiler autant sur mon petit proco) et je passe petit à petit en stable (comprenez ~) pas mal d'ebuilds instables.  

Juste pour info : hier, j'ai mis à jour OpenRC (passage à la version openrc-0.5.3 en ~) et résultat ... ce matin pas moyen de booter : partition / montée en ro seulement! Aucun service de démarré ou presque! Bref, système inutilisable.
 
J'ai downgradé à la version 0.5.2 et hop ca remarche. Suite à cette maj hier, j'ai fais un etc-update. Soit je l'ai fais trop rapidement, soit il y a un bug dans cette nouvelle version.

tu as suivi le guide de migration baselayout 2 et open-rc  ??
 
http://www.gentoo.org/doc/fr/openrc-migration.xml

Ça boote sans problème chez moi avec openrc 0.5.3.

J'ai re-fais la maj et cette fois cest passé! Ca fait un moment que je tourne avec OpenRC et j'étais persuadé d'avoir suivis le guide de migration mais à priori j'avais sauté des étapes!

Dites, vous connaissez l'astuce (ou le USE flag) pour retrouver la preview des vidéos dans dolphin ?
 
C'est bizarre, car via KDE 4.3.3, ça fonctionnait bien, mais, là, toutes les nouvelles vidéos ajoutées n'ont plus cet aperçu (ce n'est pas un problème de taille).
 

 
Sinon, ça peut servir en cas de souci avec emerge @preserved-rebuild et e2fsprogs-libs.

Ça a certainement été désactivé parce que ça ne marche pas, j'ai la flemme de chercher mais je suis tombé sur des bugs disant qu'il y a des fuites mémoire colossales avec les preview de vidéos.

Ah ok, ça peut expliquer le truc (enfin, je n'avais pas de souci perso, mais je n'exploite que peu cette fonctionnalité, juste pour les previews de video youtube quoi!).

 
colossales, c'est le mot

Salut chers amis Gentooïstes...dites elle est où la 10.1, je ne l'ai pas moi
Ni dans /usr/portage/profiles/default/linux/x86/ ni ds amd64

C'est la version "live" CD (je n'arrive pas à joindre le site là).

 
Ah, ce serait une version seulement de cd bootable, rien à voir avec le système de profil Gentoo installé ?  

Pour voir les profiles dispos : eselect profiles list

Je suis d'accord avec j_c_p : la version 10.1 doit seulement correspondre à la version du LiveCD.

D'accord merci, il semble donc bien que autant 10.0 corresponde a des livecd/dvd ainsi qu'a un profil, autant 10.1 ne corresponde qu'aux livecd/dvd et non aux "profiles" Gentoo

Tout est là :

 
Tom_ : eselect profiles list .

Hum, j'ai un souci un peu étrange là, c'est exactement ce qui est décrit là, sauf que je pourrais ajouter que je récupère le focus plus ou moins bizarrement (genre quand le gestionnaire du desktop laisse la place à celui d'Xorg et vice et versa).
 
Rien de spécial dans les logs, et ça le fait sous KDE et XFCE, j'ai aussi pensé à un souci de fichier input de X, mais j'ai les dernières versions maintenant, et rien ne change!
Peut-être à voir du côté udev/hal en effet.
 
edit : peut-être voir aussi x11-drivers/xf86-input-evdev-2.3.1 (le passer en 2.3.2!)
En tout cas, c'est assez pénible ... genre, je peux naviger dans un topic ouvert et éditer mon post, mais plus moyen de changer d'onglet du navigateur/d'espace de travail ... ou alors, c'est le contraire .
 
edit2 : je penche plus pour dbus là, ainsi que ses USE flags dans les différents paquets (je viens déjà de mettre la dernière version) -> ok, c'était cela !

J'ai besoin de vos conseils et d'un peu de chance : en voulant faire diverses optimisations sur le temps de boot de mon eeePC je suis allé piocher des patchs de moblin (trouvés chez Ubuntu Lucid Lynx) pour le kernel, un pour xorg (cache de xkbcomp pour xorg 1.7) et j'ai changé un peu les cflags. J'ai aussi activé devtmpfs, pour maximiser les chances de tout casser avoir un démarrage éclair  
Résultat des courses : gdm ne démarre plus (c'est la version hard masquée, 2.28, autant ne pas faire les choses à moitié). Comme je ne me considère pas vaincu aussi facilement j'exclus l'hypothèse que ce soit le patch xorg le responsable, en effet c'est gconfd qui s'est mis à utiliser 100% du processeur. d'ailleurs lancer un bête gnome-terminal en ssh donne une erreur gconf.
Je lance l'habituel revdep-rebuild -qui ne trouve rien-, essaie quand même un xorg non patché, même résultat donc retour à la version custom.
Là je vois que networkmanager ne marche pas non plus, et donne des erreurs dbus, en le recompilant ça marche comme par enchantement. J'applique la même recette, recompile donc tout ce qui dépend de gconf, gtk et dbus, pour ne pas oublier trop de monde. Globalement ça marche, mais j'arrive maintenant à des bugs assez intéressants : empathy fait un "malloc(): memory corruption" dès qu'on le lance. Je suspecte donc le changement de clfags et je décide de faire un emerge -e world (-j3 --keep-going aussi pour l'histoire), sauf qu'il me dit qu'il lui faut plus de 4 jours . Vous pensez qu'il y a une solution plus subtile pour recompiler ce qu'il faut ?
 
Pour ceux qui veulent reproduire la situation voilà en détail les changements :
Les patchs du kernel : http://people.canonical.com/~sconklin/mobp/
celui de xorg vient d'un paquet ubuntu, je ne sais plus où je l'ai trouvé    
les clfags d'origine : -O2 -march=prescott -pipe -floop-interchange -floop-strip-mine -floop-block -msse2 -mfpmath=sse -fomit-frame-pointer
le nouveau cflag : -O2 -march=core2 -mtune=generic -fomit-frame-pointer -pipe
 
J'ai quand même réussi à booter sur le nouveau noyau sans problème avant de changer le xorg et le cflag, et c'était effectivement plus rapide. Le seul programme cassé à ce moment était powertop, mais ça ne vient peut-être même pas des patchs, je ne l'avais pas testé sur un 2.6.32 avant.

J'aime souvent tester des trucs un peu dangereux (ce qui explique l'état de ma Gentoo actuellement   il faut que je répare et stabilise tout ca) mais là il y a du niveau! Ils sont fous ces utilisateurs de Gentoo!  

Si tu veux gagner du temps pour les compils et que tu possèdes un pc fixe ou un portable puissant, compile dans un chroot par exemple pour générer des paquets binaires que tu pourras installer facilement sur ton eeePC. Tu as diverses solutions proposées ici : http://forums.gentoo.org/viewtopic-t-801125.html.

J'ai une petite question : pourquoi tu as viré les flags liés à Graphite ?

J'ai du mal à comprendre ce besoin d'accélérer à tout prix le démarrage : pourquoi ne pas juste mettre ton eeePC en veille et le sortir de la veille en cas de besoin ? C'est vrai qu'après ca peut être un défi de bricoler tout ca  

http://www.gentoo.org/doc/en/distcc.xml

Réduire le temps de démarrage c'est avant tout un "jeu", et en principe ça ne réduit en rien les possibilités du système. J'utilise quand même un Gnome normal, gdm, networkmanager, avahi et tous les utilitaires que je juge utiles.
La mise en veille c'est bien mais ça demande quand même de savoir si on compte utiliser l'ordinateur plus tard, alors que l'extinction c'est plus simple. Avec un ordinateur démarrant en moins de 30s on peut le sortir quand on a 5 minutes, et par la même occasion faire râler le voisin qui a un XP et/ou n'a pas de SSD.
 
Pour les cflags de graphite, je les ai enlevés parce que je n'ai remarqué aucune différence visible à l'oeil nu, sauf la compilation qui devient plus longue.
 
Pour les binpkgs c'est faisable mais je trouve la solution un peu lourde, des fois il m'arrive de ne pas avoir le fixe à disposition et de vouloir installer quand même quelque chose, ce qui m'obligerait à le faire en double. Je reste donc sur distcc que j'utilisais déjà.
 
L'estimation de genlop devait se baser sur des compilations faites sans distcc, c'est déjà presque fini (600/800 environ).
 
Mais surtout, quel serait l'intérêt de Gentoo si on n'expérimente pas des patchs externes, des options de compilations et des noyaux folkloriques ?

Je suis tout à fait d'accord : Gentoo est vraiment là distrib pour expérimenter des trucs!! Appliquer un patch est vraiment simple!! Je comprends bien la notion de "jeu/challenge"...c'est un truc que j'aime bien aussi.
 
Si tu fais une mise en veille sur le disque dur, le pc est éteint non ? Donc je ne vois pas ce que ca change avec le fait qu'il soit éteint puis rallumé normalement.

Mais il n'y a pas de disque dur ! C'est fait avec deux SSD de qualité douteuse, 4Go + 16Go très lents en écriture (surtout le second) mais rapides en lecture. L'hibernation (suspend to disk) obligerait à avoir une partition de swap de la taille de la RAM pratiquement, dans le pire des cas écrire 1 Gio de données sur le gros ssd serait impensable. Actuellement il n'y a pas de swap, je préfère garder le précieux espace pour mes fichiers.
 
Si je ne dis pas de bêtises le suspend to disk oblige à passer quand même par le bios, grub et le chargement du kernel, seule la partie de init est remplacée par la lecture de l'image de la ram. Je ne suis pas certain que ça apporterait un gain de temps, l'intérêt reste uniquement pour conserver la session.

Arf j'avais zappé la partie SSD du eeePC ...

+1
C'est fou tout ce merdier pour espérer gagner 6 demi secondes un quart au boot  

Je viens de découvrir un super script : Portpeek! Ce script permet de faire le ménage dans les fichiers package.keywords et package.unmask. Par exemple, il indique (et peut supprimer automatiquement) les programmes désormais considérés comme stable, les programmes dont la version présente dans un de ces fichiers n'existent plus dans l'arbre...  
 
J'en reparlais ici je pense, mais je vais prochainement essayer de repasser mon système en stable (~amd64 vers amd64). Donc j'ai essayé rapidement ce programme, et ca a l'air vraiment bien!  
 
Plus d'infos : http://www.mpagano.com/blog/?page_id=3

Tom_ : ca a l´air intéressant cet outil.
Souvent je veux mettre un outil à jour, et je dois passer plein de librairies en unstable. Mais après, je n´en ai plus besoin. Faudra que je teste ca.

Je rassure tout le monde, ma Gentoo est à nouveau totalement opérationnelle et même plus !
 
Puisque je parlais de temps de démarrage il y a quelques posts, voici le bootchart actiel :

 
Avec les dernières tentatives c'est le plus efficace, voilà ce qui a été fait :
/ en btrfs (noatime,compress,ssd_spread) sur les deux SSD
un initramfs qui fait le btrfscl -a, indispensable pour utiliser btrfs en mutli-device et monte le devtmpfs
utilisation de baselayout-2
scheduler noop
chargement des modules wifi et eeepc-laptop de manière asynchrone (blacklist et un modprobe das un script adhoc)
 
J'ai appliqué des patchs cités quelques posts plus tôt et j'ai modifié les dépendances pour enlever device-mapper et lvm que je n'utilise pas.
 
Le problème si on peut dire c'est qu'entre 7 et 10s ni le processeur ni les SSD sont utilisés au maximum, il y a certainement des améliorations possibles, quelqu'un aurait des idées ?
 
J'ai déjà essayé readahead et preload,  leur impact est négatif avec le scheduler noop (pas de ionice) et nul en CFQ, avec un système pas plus réactif que noop.
L'option compress de btrfs me semble utile d'une part pour accélérer les écritures -sans avoir mesuré les performaces- et d'autre part pour gagner un peu de place sur les 20 Gio du eeePC.

Intéressant comme expérience.    
 
Et BTRFS, ca donne quoi ? Niveau fiabilité, ca marche bien ? Ca me tenterait presque pour /usr/portage ...  

Au niveau de la fiabilité je ne peux pas dire, ça ne fait pas longtemps que je l'utilise. Je rsync mon home quand même de temp en temps    
Pour les performances je ne peux pas juger directement : mon ancien système utilisait deux partitions distinctes pour les SSD alors que maintenant j'utilise le "RAID" de btrfs. Quoi qu'il en soit le système est très réactif, rien de négatif à dire pour le moment.
C'est très efficace comme utilisation de l'espace disque : 161M pour /usr/portage (sans distfiles bien entendu).
 
Le plus étonnant c'est certainement l'interférence très différente avec le scheduler. Sur de l'ext4 noop rendait le système inutilisable, alors que là je ne vois pas de ralentissements particuliers...

Il faudrait renommer le topic,le titre prête à confusion, il n'y a pas de profil 10.1, c'est juste le nom d'une version de livedvd
 
Sinon quelqu'un sait-il si kde 4.4 rc1 va se retrouver dans la branche ~x86 un jour, ou bien si on ne peut avoir cette version qu'avec l'overlay via la version qui finit en 90 là ?

KDE-4.3.90 correspond à la version rc1 de KDE4. Et non normalement, elle ne sera pas ajoutée à Portage! Il faut passer par l'overlay kde.
 
Je trouve plus logique d'indiquer la version du livecd et que du profil, même si dans les deux cas ca ne veut pas dire grand chose avec Gentoo.

Ah d'accord pour la rc1, c'est dommage je voulais pas passer par l'overlay kde
 
Sinon c'est sur que la notion même de "version" n'a pas vraiment de sens avec Gentoo
 
Edit: mais sinon kde 4.4 final, il sera bien ajouté a portage ?

Oui bien sûr la version 4.4 sera ajoutée à Portage. Normalement, elle sera tout d'abord ajoutée dans l'overlay pour une première étape de testing, ensuite elle partira dans Portage en ~, et quelques semaines voire plus elle attérira en stable!  
 
Perso, je n'ai pas de soucis à utiliser cet overlay, ca marche plutôt bien!

Okay merci Tom_, je ne sais pas si je serais capable d'attendre 4.4 en ~x86 peut-être vais-je cracker pour l'overlay en 4.3.90... j'hésite

Je ne veux pas t'influencer mais les versions < 4.3.90 (j'ai pas eu le temps de la compiler encore) marchait très bien.  

 
Ah si la tu m'a influencé, je veux tester  tient maintenant

En lisant le forum gentoo j'ai remarqué que logrotate ne touche pas à emerge.log par défault. Ce qui veut dire que la plupart d'entre nous avons encore en mémoire la date d'installation de notre Gentoo.
 
Je vous annonce donc que le premier emerge --sync de mon ordinateur date du 14 janvier 2006   4 ans de Gentoo et toujours aussi satisfait.

Dommage que je change entièrement de config tout les ans à peu près

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 !