Reprise du message précédent :
Bon, j ai facilement reussi a faire tout remarcher. Le hal n etait pas lance.
Par contre, il m a switche mon clavier suisse qwertz en un clavier americain qwerty. Comment changer ca ???
y a plein de de variable d'environnement.

Il faut configurer Hal, avec un fichier fdi. Voir la partie sur "With HAL (with xf86-input-evdev)" du guide suivant :  http://www.gentoo.org/proj/en/desk [...] -guide.xml. Par exemple tu copies /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi dans /etc/hal/fdi/policy, et tu le modifies pour qu'il supporte ton layout.

Je viens de le faire, ca ne marche pas.
more /etc/hal/fdi/policy/10-keymap.fdi  

 
 
Je continue les investigations.

chezmoicamarche.com

Non, le problème, c'était:
 
     <merge key="input.xkb.layout" type="string">fr_CH</merge>
      <merge key="input.xkb.variant" type="string" />  
 
qui a été modifié en  
 
<merge key="input.xkb.layout" type="string">ch</merge>
<merge key="input.xkb.variant" type="string">fr</merge>
 
Et maintenant ça marche !

Jolie reprise Tom_ .
 
Sinon, passage à xorg-server 1.5.3 sans trop de difficulté (j'utilise hal pour la première fois, ce qui fait monter mon nombre de processus, on dirait presque du Windows là ) avec un xorg.conf très simplifié du coup, juste que je n'ai plus la touche Ver Num activée pour kdm (je n'ai pas trouvé comment ajouter le paramètre avec hal et le fichier fdi).
 

 
Sinon, passage au Quad Core (Phenom 2) ce week-end (je suis faible, j'ai craqué à l'usure avec mon monocore sous Gentoo, et puis strigi sous KDE4 m'a eu ).

Merci.
 
Pour Kdm et le verrouillage numérique, il suffit de configurer Kdm. Jette un œil ici : http://ubuntuforums.org/showthread.php?t=780693.
 
Il faudra que tu nous donnes des nouvelles de ce quad core sous Gentoo. Ca risque de te changer la vie.  

 
Je suis passé d'un xp1800+ a un e6600 avec raptor il y a 2 ans et demi. Ca a changé ma vie. J'ai fait +/- x4 pour les temps de compilation

Pareil en passant du XP1700+ a un E6400.
(m'enfin peut-être pas aussi vite).

Ah au fait GCC-4.4 est sorti officiellement, vous êtes prêts à faire chauffer le CPU ?  
 
A priori, il n'y a pas encore de paquet pour Gcc-4.4 mais il y a des ebuilds live pour les dingues  

Bof, je viens de faire le GCC mettre l'optione Core2.

Bon, je suis sous ma Gentoo avec le PhenomII là .
 
Un petit compte rendu-rapide du prermier boot (il me reste 2/3 trucs à régler) :
- j'ai eu un souci avec udev (141) et mon réseau (eth0 n'existe pas !), bref, juste une règle persistant à enlever, mais il fallait le savoir (udev gardait ma config forcedeph en mémoire, du coup, ça n'allait pas forcément).
- j'ai eu de la chance d'avoir le bios qui va bien pour reconnaître mon processeur (j'avais une petite appréhension là-dessus).
- un petit souci est présent avec la mise à jour de l'heure : je n'arrive pas à communiquer avec le bios (heure utc dans celui-ci, j'ai une erreur inconnue au boot et je ne suis pas en baselayout-2, bref, j'ai 2h d'avance jusqu'à ce que ntp intervienne et ça recommence à chaque boot).
 

 
  -> edit : ok, il fallait rajouter l'option rtc dans le noyau (petit oubli).
 
Voilà, mise à part quelques légers soucis de mise en place (genre le ventilorad ne tourne pas, mais non, en fait, c'est normal, c'est le bios qui le gère désormais !), ça tourne très bien.
Il me reste à remettre mon système sur un disque dur plus performant (qui est déjà installé, juste à le partionner etc ... et remettre mes 2 disques durs sata Hitachi 160Go en secondaire).
 
Voilà, à partir d'une configuration athlon64 en amd64, c'est simple d'upgrader, vu que c'est une compatibilité ascendante.
 
Quelques remarques avec les premières compilations :
- c'est très rapide (1h pour compiler le system complet environ) !
avant : MAKEOPTS="-j2" CFLAGS="-march=athlon64 -O3 -ftracer -pipe"
après : MAKEOPTS="-j5" CFLAGS="-march=amdfam10 -O3 -ftracer -pipe"
- gcc 4.3.3 compile en boucle sans s'arrêter avec les nouvelles options : passer à la révision -r2 résout le souci (je m'en suis aperçu après 1h, le même passage passait en boucle)
 
La nouvelle config est la suivante :
-Phenom 940 (3Ghz, 4 core) avec Noctua NH-C12P
-Gigabyte MA790X-UD4
-8 Go DDR 1066
-1 Hitachi 500Go sata (16Mo de cache)
avec aussi
- 7900GTO 512Mo
- 2 * Hitachi 160Go sata (8Mo de cache) etc ...
 

 
edit : j'ai chrooté depuis OpenSuse 11.1   .

8 Go de Ram ???
 
Tu fais quoi avec ça ?

On est souvent à deux utilisateurs en même temps (NX) et je fais aussi un peu d'Xplane de temps à autre.
 
Ça sert aussi quand tu compiles OpenOffice en faisant d'autres tâches annexes, bref, ça sert.
 
edit : python-2.5 ça sert encore si l'on a python-2.6 d'installé ?
 
edit2 : ok, c'est parti pour recompiler quelques paquets sympathiques, genre koffice, openoffice etc ... (merci python ).

Ué, pis au prix de la ram, ce serait con de se priver
 

Exactement .
 
Sinon, je viens de modifier mes paramètres de compilation en enlevant le -pipe (erreur à la recompilation de gcc sinon), du coup :

Bon, j'ai enfin pris le temps de passer à xorg 1.5

Le problème est que Xorg est en stable, mais pas le noyau contenant GEM, nécessaire pour avoir le UXA (dont je ne sais toujours pas l'utilité réélle).

http://www.rojtberg.net/67/exa-uxa-dri-gem-ttm/

Juste par curiosité, c'est quoi ton utilisation de NX @home ? Des vieux pc à recycler ?  
 

Et ca fonctionne bien Python-2.6? Perso j'avais essayé quand il est officiellement sortis et il y a avait pas mal de scripts de "made in Gentoo" qui déconnaient, mais bon ça a du être corrigé.
 
En tout cas, tu as une une jolie config, ça doit bien fonctionner. Ça donne envie.   Et pourquoi un proc AMD et par un Intel ?  

 
Bizarre y'a une compatibilité ascendante avec 2.5
En faite, elle permet de mettre des warnings vis à vis de ce qui ne fonctionnera plus en Python 3

Pour le NX, ça sert essentiellement à madame pour se loguer en parallèle sur le pc fixe via son portable (un core duo, 2Ghz, 1Go de ram, avec une Geforce7, sous OpenSuse 10.3) .
 
Sinon, pour Python-2.6, pas de souci là si ce n'est quelques paquets à recompiler (genre openoffice, etc ... comme dit plus haut).
 
Question temps de compilation, j'en ai eu pour 1h10 pour openoffice, ça va quoi .
 
Et puis, pour la question Amd ou Intel, l'Amd se débrouille bien pour la compilation (cf le test Hardware.fr par exemple), et j'ai toujours eu des configs Amd (qui fonctionnaient très bien sous Linux d'ailleurs) .

Y a t'il des utilisateurs de Paludis ici?
Etes vous contents... ou pas?
Ca fait au moins 2 ans que je me dis qu'il faudrait que j'essaye et je n'ai toujours pas saute le pas.

Sur la fin de mon utilisation Gentoo, je l'ai utilisé oui parce que j'en pouvais plus de Portage
Beaucoup mieuc déjà à l'époque, ça a du se confirmer ajd

Sors d'ici traitre

J'ai utilise portage pendant 3 mois avant de franchir le pas il y a plus d'un an maintenant. Je me vois pas revenir vers portage ; c'est plus une question d'habitude en fait, car je n'ai pas de "mauvaise" experience sous portage.  
C'est plus l'approche systematique de Paludis qui part sur des bases "saines" dixit Ciaram McCreesh que j'aime. Mais apres, quand on lit ses posts sur portage, il a l'air un peu extremiste...
 
Enfin, quoiqu'il en soit, j'ai jamais eu de soucis particuliers avec paludis.

Merci pour les commentaires sur paludis  

Mon avis sur la comparaison Gentoo/Arch:
Deja elle se ressemble beaucoup sur la philosophie , destiné aux poxer-users (il faut le dire!), respect de KISS, peu d'intervention sur les paquets.
Gentoo bénéficie d'une excellent communauté (en particulier son forum), que Arch essaie de rattraper mais ca met du temps. La doc est aussi excellent, etc..
Par contre Gentoo ne se remet pas en cause facilement, et transporte des trucs que je trouve mal concu, comme l'arbre portage (~100k fichiers y'a qql années, ca a encore du augmenter), et Portage en lui-même . C'est quand meme une part essentiel d'une distribution que son système de gestion de paquet.
Deja Python ? Manque de performances, pas forcement plus simple à maintenir (cf les problemes qu'ils ont eu avec les liveebuild, les différentes versions de paquet en // ..etc..), et surtout un risque vis-à-vis de la dépendance python
Paludis tente de répondre à ce probleme en corrigeant à peu près tous les défauts de Portage ..mais doit garder une compatibilité avec l'arbre .. Alors que pacman n'a pas ce problème (liste des fichiers ~400 ko)
Autre point important : le nombre de paquets dispo.
Officiellement, il doit etre plus important sous Gentoo (à vérifier), mais si on ajoute AUR, la bdd de arch est tout simplement gigantesque (je crois pas que j'ai deja eu besoin de compiler quelquechose à la main !)
Après il reste toujours le point fort de Gentoo, l'utilisation des USE. (pour l'optimisation, je n'ai jms vu la diff par rapport à arch). C'st sur, y'a des dépendances sur certains paquets dans Arch qui me sont inutiles, et des fonctionnalités compilés dont je n'ai pas du tout besoin ..

Amis gentoistes, j'ai une petite question. J'ai voulu faire un "emerge -e system" et au lieu d'une centaine de paquets à recompiler, j'en avais plus de 300 dont des bouts de kde-4, xine-lib etc ... J'ai l'impression d'avoir un peu tout et n'importe quoi dans mon "system", vous savez d'où ca peut venir ?  
 
Merci d'avance

as-tu vérifié tes USE?

essaie un tree aussi pour voir qui est le coupable

Chezmoicamarche    

Et rien d'anormal dans la liste des 120 packages
 

300 paquets chez moi (mais ça dépend de la variable USE).

Quels sont les USE qui te rajoutent 180 packages  
J'en ai pourtant une chiee...

Je ne comprends pas trop le lien avec les USE et le fait d'avoir 100 ou 300 paquets dans system.  
 
Normalement system comprends les applis de base nécessaires au bon fonctionnement du système, mais pas d'applications de niveau utilisateur. Celle-ci sont contenues dans la partie world alors j'ai du mal à voir comment elles se retrouvent dans system. :s

Certes, mais je n'ai pas approfondi la question là.
 
Sinon :

USE="emacs"    
Forcement.......

Bah, oui, mais ce n'est pas négociable emacs .
 
nb : ces infos sont fournies via emerge --info.

Gcc-4.4 est dans l'arbre, Gnome-2.26 et Openoffice-3.1 devraient y entrer aussi prochainement, Kde-4.2.3 est dans l'overlay kde-testing, alors dégainez vos cpu.

Bah si tu as l'useflag doc qui installe un certains paquet et que tu as l'useflag jadetex qui nécessites d'autres paquets tu fini vite avec toute la suite Latex installé en dépendance soit ~50 paquets. C'est un exemple.
 
Pour ça que moi ça me prend du temps mais je gère tous mes useflags par paquet. Dans mon make.conf j'ai que :

c'est assez radical. Perso je gère les USE globaux dans make.conf, les locaux (ou les globaux que je dois modifier pour un paquet) dans package.use.