Reprise du message précédent :

KDE4 utilise beaucoup l’accélération matérielle opengl de la carte graphique avec les effets 3D "playskool" activées par défaut, du coup si le pilote de ta carte graphique est bogué alors KDE va merder aussi,

la solution: utiliser le rendu "XRender" au lieu de "OpenGL" dans les options avancées de KDE4, et désactiver les effets de bureau 3D

http://oi40.tinypic.com/k9vrko.jpg

avec ma carte graphique ati radeon 9000 le rendu "XRender" est le seul choix qui permet de faire fonctionner KDE4 sans bugs graphiques, je précise que j'utilise le pilote libre radeon

OK, merci, je testerai ça ce soir
 
Pourtant j'ai une carte récente (Nvidia GTX260), avec les pilotes proprio ...

j'ai un comportement bizarre:
 
j'ai installé arandr pour gérer le dual screen, mais sur le deuxième écran, j'ai un morceau du coté droit des fenêtes que j'ai sur le screen 1 qui apparait sur le screen 2.
 
une idée d'où ca vient?

 
Dans ton layout généré par arandr, les écrans ne se montent pas un peu l'un sur l'autre (en tout bien tout honneur bien sûr...) ?

ha ouais exact xD
 
merci

 
mais effectivement il doit rester des vieux fichiers qui font que ca marche pas top, mais où ? il faudrait que tu regardes en affichant tous les fichiers cachés, et tout ce qui ressemble à du kde tu dégages (méthode non académique mais bon )

Pourquoi ne pas simplement passer la swappiness a 0 ou 1?
Ca ne l'utilisera qu'en ultime recours en cas de saturation memoire et ca ne t'empechera pas d'hiberner.

juste que j'ai lu ca stout ^^
 
je suis pas fixé sur la technique

normalement il suffit de virer le dossier caché /home/user/.kde

à mon avis il doit avoir un  problème d’accélération matérielle, un truc lié à dri2, faudrait lui demander s'il avait de bonnes perfs dans les jeux 3D ou s'il utilisait des effets 3D dans les autres gestionnaires de bureau,

il serait intéressant aussi de regarder dans les logs ( Xorg ),

sinon les récentes mises à jour ont apporté des fichiers "pacnew", notamment pour le fichier de configuration /etc/pam.d/login, il est conseillé de renommer le fichier login en login.old et le fichier login.pacnew en login tout court

Drapal jvais essayer de m'y m'être

il faut bien suivre le tutoriel d'installation sur le wiki d'archlinux afin d'éviter les erreurs classiques d'oublie de paquets et d'édition de fichiers de configuration,
 
il faut aussi de préférence avoir déjà utilisé une distribution linux et avoir bien assimilé les concepts de base d'un système linux

J'ai eu pas mal de distrib différentes et je bosse sous linux, pense qu'en suivant le tuto ça ira !

Je vois vraiment pas pourquoi on fait tout un plat de l'installation d'Archlinux, parce qu'avec un tuto, c'est vraiment tout simple (un peu long, mais tout simple).

le problème c'est que les débutants n'ont pas l'habitude d'une installation 100% texte avec des étapes d'édition manuelle de fichiers de configuration avec vi ou nano

celui qui vient d'ubuntu il va pleurer au début,

donc lecture obligatoire et attentive du tutoriel archlinux sur le site officiel

http://wiki.archlinux.fr/Installation

Le mieux est si possible d'avoir un autre PC connecté au net à côté pour pouvoir suivre l'installation pas à pas avec le tuto officiel et d'aller fouiller sur le wiki si besoin (ou imprimer le tuto si pas d'autre pc à côté)

 
ou d’ouvrir la doc dans un autre TTY :-)

Ou, au risque de faire trop XXe siècle, d'imprimer le tuto.

edit : ha non rien, j'avais pas vu que ça avait été dit.

J'ai déjà fait ça plusieurs fois : le wiki débutant en navigateur mode texte dans un TTY différent de cleui de l'installeur, mais pour le coup avec quelqu'un qui regarde à côté tu passes vraiment pour foufurieux

on peut aussi résumer en quelques lignes la procédure d'installation dans un fichier texte et on l'imprime,
 
c'est ce que j'avais fait lors de ma première d'installation d'archlinux dans virtualbox, à chaque étape de l'installation je résumais ça dans un fichier texte afin plus tard de pouvoir refaire la même installation sans prise de tête ( notamment pour installer kde, xinit pour startx, configurer dolphin, les imprimantes, samba )

Ou alors avec un smartphone à côté ça convient bien aussi

Toutafé

En théorie. Moi j'ai pas eu la présence d'esprit de préférer la netinstall et j'ai mis un bout de temps avant de pouvoir seulement installer xorg, à cause de la fameuse histoire de pacman qui bute sur un conflit de paquets. Sans le forum idoine, j'étais bien marron

Attention lors de votre prochaine mise à jour : http://archlinux.fr/news/le-repert [...] symbolique

la version intégrale ici, qui donne d'autres astuces en cas de problèmes :
 
https://wiki.archlinux.org/index.ph [...] iki:usrlib

les premiers problèmes suite à cette mise à jour :
 
https://bbs.archlinux.org/viewtopic.php?id=144989

La mise à jour qui va prendre 1h pour trouver tous les fichiers qui n'appartiennent à aucun package dans /lib \o/

10 minutes, si tu suis correctement le guide donné plus haut

leur guide est foireux car j'ai toujours une erreur qui m'empêche de faire la mise à jour de glibc :
 
au début j'ai tapé ces commandes :
 
pacman -Syu --ignore glibc
 
là tout de suite il m'a proposé de mettre à jour d'abord pacman, j'ai accepté et ensuite il a installé des tonnes de paquets ( 72 dont le dernier kernel ),
 
une fois tout le bazar installé je tape alors la commande :
 
pacman -Su
 
et là c'est le drame avec le message d'erreur :
Erreur: la validation de la transaction a échoué ( conflit de fichiers )
glibc: /lib est déjà présent dans le système de fichiers
Des erreurs se sont produites, aucun paquet n'a été mis à jour
 

Le guide permet justement de résoudre ce problème  

justement j'ai lu le guide et je n'arrive toujours pas à résoudre ce problème

quand je fais le grep préconisé dans la dernière partie du guide :

ça me montre alors que le package glibc-2.16.0-1 utilise des fichiers se trouvant dans /lib,

et que le repertoire /lib n'a aucun propriétaire

je précise que archlinux tourne dans virtualbox, et que ma version d'archlinux est du 32 bits ( pas la version 64 bits, j'ai l'impression que les auteurs de ce "guide" n'ont testé leur préconisations qu'avec la version 64 bits d'archlinux, si ça se trouve ça merde qu'avec la version 32 bits )

comment sortir de ce merdier ?

j'ai trouvé la solution :

il fallait déplacer le répertoire : /lib/modules vers un repertoire de sauvegarde :

mv /lib/modules /home/toto/backup

tant que vous ne ferez pas ça l'update échouera,

en gros il faut que dans /lib il n'y ai que des fichiers appartenant au package glibc, s'il y a des vieux restes de fichiers appartenant à aucun paquet ( des modules de vieux kernels type 3.2.1 ) alors l'update refusera de se faire,

mais avant de faire ça il faut vérifier qu'aucun de ces fichiers dans /lib/modules n'est utilisé par un paquet d'archlinux ( en tapant les commandes find et grep ), même si aucun fichier n'appartient à un paquet il faudra quand même déplacer /lib/modules vers un autre endroit,

le problème c'est l'article dans le wiki ne l'indique pas explicitement, la formulation laisse à penser que la suppression ( ou le déplacement ) du dossier /lib/modules est optionnel

Même souci rencontré hier, et comme un con (tête un peu ailleurs) j'ai déplacé tout ce qui se trouvait dans /lib
 
Evidemment après plus grand chose ne fonctionnait
Un boot sur clé USB Archlinux pour réparer et c'était réglé.
 
Le déplacement de /lib/modules a effectivement suffit.
 
Allan McRae est revenu là-dessus sur son blog : http://allanmcrae.com/2012/07/upda [...] e-install/

c est un peu n importe quoi cet update

 
Ouaip, c'est assez peu user friendly...

le problème c'est le tutoriel d'archlinux qui est mal foutu, ça laisse à penser que le simple fait de taper ces commandes peut suffire :

pacman -Syu --ignore glibc
pacman -Su

or bien sûr ce n'est pas suffisant car pour que l'update de glibc fonctionne il faut que dans le repertoire /lib il n'y ai que des fichiers appartenant à glibc, et strictement rien d'autre ( pas de fichiers orphelins ou de vieux trucs appartenant à des kernels désinstallés type /lib/module/arch-kernel3.2.1, ni de fichiers appartenant à un paquet installé ),

ce qui suppose de faire un ménage à la main dans /lib en ne laissant que les fichiers appartenant à glibc,

j'ai mis une heure trente à comprendre ça, la lecture du wiki ne l'indiquant pas de manière claire et limpide

J'ai été un peu emmerdé aussi, même après avoir fait le ménage.
 
Au final j'ai supprimé à la main des fichiers  dans /lib/ qui n'appartenaient plus à aucun paquet, ainsi que dans /var/lib/pacman/local/
 
et ça roule

c'est un peu barbare de supprimer manuellement des trucs dans /var/lib/pacman/local,  
 
normalement il suffisait soit de supprimer les fichiers orphelins ( appartenant à aucun paquet ) dans /lib, soit de désinstaller le paquet problématique qui possede des fichiers dans /lib ( paquet qu'il faudra réinstaller une fois la mise à jour de glibc effectuée )

Votre truc ca m'a pris meme pas 5 minutes a comprendre sans lire le wiki ou le forum.
Faut pas abuser non plus

c'est normal si tu n'as rien installé manuellement au niveau noyau, le /lib sera propre par défaut avec uniquement les fichiers de glibc,

mais là j'utilise archlinux sous virtualbox, donc installation des vboxguest additions d'oracle, ce qui laisse des traces dans /lib/modules même en désinstallant tout ça avec le script d'oracle, l'article du wiki n'insiste pas assez là dessus,

j'ai deux installations d'achlinux, une sur le PC portable qui n'a pas posé problème, l'autre dans une machine virtuelle virtualbox, c'est celle là qui a posé problème avec les déchets dans /lib/modules

Je trouve un peu aussi. Hier, j'ai merdé (mea culpa) avec la machine d'un pote, ça s'est fini avec une Arch qui bootait plus et 2h de galère en démarrant sur le CD d'installation à base de chroot pour réussir à refaire partir le cabouin.

Ce matin, j'ai fait mon portable : obligé de virer les paquets issus de AUR pour réussir à passer la mise à jour en douceur, en 10 minutes c'était fait. Faut dire que j'ai bien eu le temps de comprendre hier vu la merde que j'avais fichue ²

Reste que ce genre de MAJ, faut pas que ce soit tous les deux jours. Je sais que ça fait un peu parti de la règle du jeu avec Arch et je l'accepte vu les avantages que cette distrib apporte, mais bon, quand même. D'autant plus que j'ai l'impression qu'un automatisme aurait été possible non ? Genre un cp -r /lib /usr/lib puis ln -s /usr/lib lib depuis / ? Ou quelque chose du genre ?

disons qu'ils auraient pu faire passer les infos sur la maj un peu en avance ...