Reprise du message précédent :
Trouvé    
 
Entre ipconfig de klibc et celui de busybox, apparemment la syntaxe diffère quelque peu, et là où un ip=dhcp suffisait, dorénavant il faut préciser l'interface, et un ip=eth0 fonctionne très bien  

réinstall en cours avec kde workspace en 4.4

J'ai un problème avec mon curseur de souris sur mon desktop.
En fait, j'utilise openbox comme wm mais j'avais installé xfce comme DE (j'ai donc la gestion des paramètres de xfce). Mais xfce4-mouse-settings n'a pas l'air d'agir sur le comportement de ma souris
Il existe un autre outil pour gérer ça ? Comment résoudre ce problème ? (parce que la souris sans fil est vraiment trop rapide c'est chiant ).

J'ai été confronté au problème récemment (j'ai toujours trouvés les capteurs laser trop sensibles/rapides), et j'ai trouvé ZE méthode pour régler l'accéleration et la sensibilité au poil de cul près
Indépendamment de tout WM/DE.

Tu copies /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi dans /etc/hal/fdi/policy et dans cette partie du fichier (input.mouse), tu copies deux lignes, pour que ça ressemble à ça :

AccelerationProfile c'est le mode d'accéleration, 2 (Polynomial) est le meilleur d'après mes essais (et c'est celui que recommandent les devs) :  précis au pixel près à basse vitesse, et accélère bien quand il faut.
ConstantDeceleration te permet d'appliquer un coefficient pour réduire la vitesse de la souris, c'est ce chiffre que tu devras adapter en fonction de tes goûts.
(là c'est le mien pour une MX Revolution)

La doc est là : http://xorg.freedesktop.org/wiki/D [...] on#Options

Ensuite tu redémarres HAL et tu débranches/rebranches ta souris.

Ça m'a changé la vie ce truc

Et pour udev, y a une astuce actuellement ? (autant se passer petit à petit de hal)

 
Ben à mon avis il y aura une autre méthode quand le remplaçant de HAL sera arrivé dans Xorg, ce genre de truc ça se gère pas direct dans udev (je peux me tromper).
 
Sinon tu peux mettre ça à l'ancienne dans ton xorg.conf

@deK : ça a l'air d'aller mieux, merci

hello de lu
petite constatation :
j'avais un pb avec le demarrage de Xorg sur un eeepc701 (intel i810) sur le kernel2.6.30-ARCH.
alors j'ai mis le kernel-eee (version 2.6.32) et le pb était réglé (xorg fonctionne impec), mais comme ce kernel est allégé de
certains modules dont j'ai absolument besoin, je me suis attelé à tenter de résoudre le pb avec le 2.6.30-ARCH.
après quelques lectures, je me décide à installer le 2.6.32-ARCH avec "pacman -S kernel26", de la il me configure tout.
je reboot et làa pb, il ne trouve pas mon /dev/sda1 pour monter le FS /, apparemment c'est un pb avec l'initrd généré lors de l'install  
 
j'essaye alors de booter sur l'entrée fallback et miracle cela fonctionne au pwal. xorg+xfce4 demarre...  
comme je suis un n00b, à quoi sert cette entrée "fallback", y a t'il des limitations par rapport
à un initrd normal?

Tu ne mets pas à jour ton système ?    
 
Parce que fonctionner en mettant à jour uniquement le kernel, c'est pas terrible.
Enfin ça ne garantit pas le bon fonctionnement de la distrib, la seule version réputée stable est celle du jour.
 
Fallback c'est la même chose que l'initrd standard, sauf que tous les modules sont inclus, et donc meilleure compatibilité.
 
Un conseil, fais un petit "pacman -Syu" avant qu'on commence à regarder ton problème  

Le fallback, c'est en cas de problème justement et la différence avec initrd normal c'est que le fallback contient tout les modules (alors que le normal est censé contenir que les modules que tu as besoin)

j'avais pris une img d'installe pour booter sur clef qui me semblait la plus récente possible. mais c'est qd même le kernel 2.6.30-ARCH qui est venu avec.
 
ah ok  
et comment puis je tenter de recréer un initrd générique mais "sur mesure" pour mon eeepc??
car de toute façon, le fait que tous les modules soit présents ne me gène pas outre mesure puisque j'ai
aussi une entrée grub spéciale avec le kernel-eee monolitique et qui fonctionne bien avec Xorg.

Oui mais depuis tu n'as pas fait de mise à jour, donc ?

(sinon oui, si tu as pris une image Core en 2009.08, c'est le 2.6.30 qui s'installe)

il me semble qu'au 1er demarrage non, mais les suivants le temps de config le réseau et pacman,
j'avais déjà tappé un pacman -Sy, notamment qd j'ai ajouté le repo toofishes pour le kernel-eee

Oui mais -Sy ça ne te met à jour que la bdd de paquets, ça ne met en rien à jour ton système    
 
Je veux dire que c'est une mauvaise idée d'utiliser Arch en ne mettant jamais  à jour, plus tu resteras up-to-date, moins tu auras de problèmes.
Là tu as une Arch qui date de août dernier pour le système de base (Core), mixée avec des paquets récents pour ce que tu as installé depuis.
Et avec un kernel récent, depuis que tu as mis à jour ton kernel.
 
C'est ... gruik.

il faut mettre à jour tous les combien(s) alors?
c'est assez ennuyant comme méthodologie si j'utilise mon eee en semi-embarqué, je dois développer
des scripts qui "dialoguent" avec un driver nommé ftdi (lié à usbserial). j'aimerais bien m'en occuper le moins
souvent possible qd tout fonctionnera comme je souhaite. juste allumé et éteindre.  
faut également que je pense à installer evtouch et faire des tests avec mon touchscreen 7p

Ben à la limite tu peux le laisser à une date donnée où tout fonctionne bien, mais là c'est boiteux ce que tu as (un mix de vieux et nouveaux paquets)
T'as déjà de la chance qu'il y ait pas eu de gros changement entre deux et que ça t'ait pas pété à la gueule

Fais un pacman -Syu maintenant, mets ton truc en place et si ça tourne bien, tu pourras ne plus toucher à rien si ça te fait envie.

Néanmoins, Arch n'est pas vraiment la distribution adaptée à ce type d'usage, pour ça une Debian stable est bien plus adaptée

Pour la fréquence de mise à jour : le plus souvent possible
Plus sérieusement, mettre à jour quotidiennement est une bonne idée, : pour dire, en laissant passer une semaine sans mettre à jour, l'update suivante tape facilement plus de 500Mo.

j'ai déjà testé mais ça boot pas assez vite  
néanmoins je vais faire une vraie MAJ comme tu le proposes avant de faire mes tests plus avancés

bon,
0) j'ai installé yaourt
1) j'ai fait la MAJ pacman -Syu : impec \\o//
2) j'ai "compilé" xf86-input-evtouch : impec \\o// (reste à faire le test avec mon touch 7p)
3) mes 2 kernels eee et générique semblent fonctionné impec avec Xorg+xfce4 \\o//
eee : boot en exactement 23sec
generique : boot en exactement 34sec
4) j'ai installé le bluetooth et mon gps est bien exploité \\o//
5) j'ai installé wine et mes logiciels de diag démarrent \\o// (reste à tester avec le module ftdi_sio voir comment la com
se passe)

comme les kernels sont exactement de même version 2.6.32.8, je peux copié certains
modules de générique vers eee pour m'en servir au besoin avec modprobe?

Non, les modules sont spécifique à un noyau et non à une version de noyau  

ok je m'en doutais un peu, mais une confirmation ne fait pas de mal.  
 
j'ai testé la com (ftdi) /dev/ttyUSB0 ==> com4(wine) ==> logiciel de diag.
ça fonctionne la 1ere fois, les datas se lisent. puis ensuite lors d'une nouvelle
requête ça ne fonctionne plus comme si le device restait occupé ou locké en exclusif.
est ce qu'il faut que j'aille voir dans "udev-rules" pour faire un réglage lors
de la création du device?

ABS est down chez moi, chez vous ça marche ?

 
pour accélérer le boot il faut mettre le timeout de grub à 0, et mettre tout les démons en @

certains démons supportent pas le @, tu finiras en plantage de qualitaÿ

Et les @ sont aussi pris en compte au shutdown, chose qu'on ne sait pas forcément et qui peut bien foutre la merde quand par exemple le réseau se coupe avant que les démons qui l'utilisent soient réellement tués.

 
jamais eu ce soucis, par contre il faut faire attention à les mettre dans le bon ordre

je l'ai mis à 1, histoire d'avoir le temps de "switcher" entre mes 2 kernels.
concernant l'eeepc, j'ai gardé les partoches EFI pour le boot booster du bios.
et je n'ai mis que le bluetooth avec le @, mis en ! syslog-ng et cron dont je n'ai pas besoin.
j'ai essayé slim hier également, je pensais régler un pb avec wine+appli et un ecran externe : je ne sais pas pourquoi
il me tue mon X qd je lance une appli et que l'eeepc est branché sur ecran externe   .
 
comme cela n'a pas réglé le pb  
alors, je préfère booter X avec rc.local "su user -c startxfce4",
cela évite de demarrer 2x le serveur X et l'extinction est également plus rapide

http://www.archlinux.org/news/487/

Tiens je ne connaissais pas Packer
 
http://phollow.fr/2010/02/le-wrapp [...] rch-linux/
 
C'est vrai qu'il est rapide, mais il manque quand même le support de ABS

quelqu'un sait faire marcher wicd et un truc de battery avec cairo-dock?
j'ai installé cairo-dock-%3d, ça m'a lair pas mal. mais pas de menu de xfce, ni de wicd
ou de niveau de "pile".
si vous avez des astuces je suis preneur  

C'est bon, ABS est re-up

Hello je poste ici car par de réponse sur un autre topic:  
 
je cherche un truc tout simple: quand on fait une recherche avec l'outil de windows, on peut faire des opérations sur les fichiers trouvés (ex les couper pour les coller à un autre endroit). Quel logiciel sous linux permet de faire ca? pas Thunar ni catfish ni l'outil de gnome  ... en ligne de commande c'est un peut compliqué ... (même si c'est largement faisable).
Je trouve ça un maque énorme pour la manipulation des fichiers sous linux ...
 
 
merci

1) C'est pas compliqué en console.
2) L'outil de recherche qui vient avec KDE permet de copier mais pas de couper ( ou s'il le permet j'ai pas vu ).

 
 
avec gnome aussi copier mais pas couper :-/
 
en console quand il s'agit de choisr des fichiers différents si, ca peut rapidement devenir fastidieux ex: reconnaissance à vue de titre mp3 dans une liste ...

Avec KDE tu peux faire un copy et un delete juste après (en gardant la sélection). Ca revient à un cut mais en 2 clics
Sinon si tous tes fichiers sont dans un même dossier tu peux utiliser la Filter bar

C 'est réglé avec les dernères maj, les problemes avec libjpeg (et libpng)?

Pour les paquets officiels, il ne me semble pas qu'il y ait eu de problème particulier : c'est juste que les miroirs ont mis un peu de temps à répercuter toutes les mises à jours nécessaires, mais c'est OK depuis pas mal de temps  

Dites j'ai un petit problème avec scilab :  
 
resolving dependencies...
looking for inter-conflicts...
:: java-saxon6 conflicts with saxon. Remove saxon? [Y/n]  
error: failed to prepare transaction (could not satisfy dependencies)
:: go-openoffice: requires saxon
 
Dans ce genre de cas comment ça se passe ? Je compile à la main et je cale scilab dans /opt/ ?

Supprime saxon en forcant, s'il veut pas faut supprimer go-office, ensuite installer java-saxon6 et réinstallé go-office ..  
 
Enfin je tenterais çà ..

J'avais essayé, quand je réinstalle go-openoffice il me réclame saxon

ce qui me semble normal, vu que saxon semble être la version plus récente de java-saxon6 :
extra/saxon 9.2.0.2-1 [installed]
     XSLT 2.0 / XPath 2.0 / XQuery 1.0 processor for Java - the open source Home Edition
community/java-saxon6 6.5.5-3
     XSLT 1.0 processor for Java

Hello !
 
Juste un petit message pour fêter mon arrivée sur Arch, je reviendrai surement très rapidement vers vous pour la suite, meme si mon système est pleinement opérationel après quelques heures
 
A très bientôt !

Bienvenue à toi