Les utilisateurs sont capables de tout. Du meilleur. Mais pas souvent. Alors que pour faire le pire, ils sont toujours fichus de déployer des trésors d'ingéniosité. Et quand je dis des trésors, je pèse mes mots...
Dernier exemple en date, un collector. Légèrement désoeuvré en fin de soirée, je décide de m'occuper en faisant du openSUSE-SAV sur un chan IRC officiel. Plutôt de bonne humeur, j'ai trouvé de la bonne musique dans ma médiathèque préférée. Ça part donc plutôt bien...
Arrive un utilisateur, avec une question magique. Problème classique, il se bat un peu avec ses pilotes vidéos. Jusque là, rien de mal. Il a une carte ATi, ça part mal. Et il a réussi à installer les pilotes pour cartes nVidia sur sa machine.
En toute franchise, j'ai cru à un canular. Vraiment. Un gars qui vient là pour tester la réaction des intervenants du canal. Un autre désoeuvré, mais dans un esprit légèrement moins coopératif que le mien. Sauf que non, vu les réponses du gars, ça a l'air sérieux. Il l'a vraiment fait.
C'est dans des moments comme ça que je me souviens pourquoi j'interviens dans ce genre de situations... Eh oui... c'est débile, hein. Souvent je me dis de toutes façons, si les gens lisaient le manuel, ils s'en sortiraient seuls. Ils ont qu'à se démerder, zut... Si seulement c'était si simple...
Il y a des gens, dont j'espère faire partie dans une mesure raisonnable, qui s'en sorte bien face à un ordinateur. Avec un système correct, un manuel à eu près clair, et un peu de temps, ils s'en sortent pas trop mal. Y a aussi des gens qui prennent le temps, après d'expliquer.
Mais à côté de ça... y a leur équivalents, leur pendant, ces gens qui sont là pour assurer l'équilibre naturel de notre univers. Qui ne comprennent rien à l'univers de l'informatique. Mais ils en ont besoin, que ce soient pour des raisons de productivité (les gens au travail, nda) ou pour des raisons de philosophie (les libristes non-geeks, nda). Et il faut bien les aider, y a pas de raisons.
C'est pour ça que j'essaie d'intervenir. Je trouve que c'est une bonne raison. Mais parfois, faut s'accrocher pour pas le balancer le clavier.... :p
PS : je me bats encore avec l'utilisateur. Ce serait plus simple s'il était pas obligé de rebooter toutes les minutes pour passer de son live cd à son système en dur. Le pire c'est qu'il a l'air d'avoir vraiment cassé son système, ce con... :D
05/04/2010
Quand on n'a pas de tête....
...on se sert de ses logiciels pour remplacer. Par exemple, je fais une mise à jour, elle casse un bout de mon installation (ça part mal). Je veux revenir en arrière, mais j'ai pas été rigoureux... erf. Je peux démarrer, me logguer en root, rpm et zypper marchent. Le contraire serait étonnant. Pas de panique, on va pouvoir récupérer les derniers paquets installés sur le système. La formule magique est la suivante :
rpm alimente une base de données, que nous alimentons chaque fois que nous l'utilisons, directement ou par le biais de zypper, pour installer un paquet. Cette base de données contient, entre autres, la date de dernière installation des paquets présents dans le système. Donc on interroge rpm (c'est le -q) sur toute l'installation (c'est le -a), on classe en mettant le dernier installé en premier (c'est le --last), et on filtre avec une redirection de flux.
Ici je filtre avec un head, arbitrairement, on peut faire mieux avec un grep en précisant la date d'installation.
Amusez-vous!
rpm -q -a --last|head -20rpm alimente une base de données, que nous alimentons chaque fois que nous l'utilisons, directement ou par le biais de zypper, pour installer un paquet. Cette base de données contient, entre autres, la date de dernière installation des paquets présents dans le système. Donc on interroge rpm (c'est le -q) sur toute l'installation (c'est le -a), on classe en mettant le dernier installé en premier (c'est le --last), et on filtre avec une redirection de flux.
Ici je filtre avec un head, arbitrairement, on peut faire mieux avec un grep en précisant la date d'installation.
Amusez-vous!
04/04/2010
Imposer la version d'un logiciel avec zypper
Hé oui, encore un post pour les utilisateurs d'openSUSE (ou d'ark linux, il me semble qu'ils utilisent zypper ;) ). Et aussi pour me servir de pense bête. J'aime bien faire d'une pierre deux coups :p
Problème du jour : imposer la version d'un logiciel depuis la ligne de commande. Je me suis légèrement battu pour faire marcher baskets, aujourd'hui. C'est passé, non sans une petite lecture du manuel de zypper ;)
Donc permière chose, je fais une recherche avec zypper, sur baskets :
Moi je veux le paquet qui est en haut de la ligne. Pour que ça marche. Parceque je suis sous KDE4.4 .
Du coup, on va forcer la version, sur l'appel de zypper, en respectant la syntaxe
Du coup pour moi ça donne ça :
et à la fin, on a bien :
Et basket marche. Donc je suis content :)
Problème du jour : imposer la version d'un logiciel depuis la ligne de commande. Je me suis légèrement battu pour faire marcher baskets, aujourd'hui. C'est passé, non sans une petite lecture du manuel de zypper ;)
Donc permière chose, je fais une recherche avec zypper, sur baskets :
zypper se -s baskets Chargement des données du dépôt... Lecture des paquets installés... S | Nom | Type | Version | Arch | Dépot --+--------------------+---------------+---------------------+--------+-------------------- v | basket | paquet | 1.80-4.5 | x86_64 | KDE4.4Community v | basket | paquet | 1.0svn20091126-1.81 | x86_64 | KDE4.4Playground v | basket | paquet | 1.80-4.5 | i586 | KDE4.4Community v | basket | paquet | 1.0svn20091126-1.81 | i586 | KDE4.4Playground i | basket | paquet | 1.0.3.1-9.5 | x86_64 | openSUSE-11.2-Oss v | basket | paquet | 1.0.3.1-9.5 | i586 | openSUSE-11.2-Oss | basket | paquet source | 1.80-4.5 | noarch | KDE4.4Community | basket | paquet source | 1.0svn20091126-1.81 | noarch | KDE4.4Playground(je vous épargne une partie de la sortie, c'est pas forcément toujours utile)
Moi je veux le paquet qui est en haut de la ligne. Pour que ça marche. Parceque je suis sous KDE4.4 .
Du coup, on va forcer la version, sur l'appel de zypper, en respectant la syntaxe
zypper in paquet=versionDu coup pour moi ça donne ça :
zypper in basket=1.80-4.5et à la fin, on a bien :
Chargement des données du dépôt... Lecture des paquets installés... S | Nom | Type | Version | Arch | Dépot --+--------------------+---------------+---------------------+--------+-------------------- i | basket | paquet | 1.80-4.5 | x86_64 | KDE4.4Community v | basket | paquet | 1.0svn20091126-1.81 | x86_64 | KDE4.4Playground v | basket | paquet | 1.80-4.5 | i586 | KDE4.4Community v | basket | paquet | 1.0svn20091126-1.81 | i586 | KDE4.4Playground v | basket | paquet | 1.0.3.1-9.5 | x86_64 | openSUSE-11.2-Oss v | basket | paquet | 1.0.3.1-9.5 | i586 | openSUSE-11.2-Oss | basket | paquet source | 1.80-4.5 | noarch | KDE4.4Community | basket | paquet source | 1.0svn20091126-1.81 | noarch | KDE4.4Playground
Et basket marche. Donc je suis content :)
31/03/2010
Eclipse et openSUSE
En bon développeur Java (ça va quand même arriver à toute vitesse, là...) j'utilise un EDI qui va bien. Eclipse, en l'occurence. Et, petit rappel pour ceux au fond qui ne suivent pas, j'utilise aussi openSUSE. Et comme je suis sous KDE, qu'Eclipse se sert de GTk, et qu'en plus les conf GTk sont faites pour windows, y a eu des petits problèmes...
En fait, certains boutons deviennent inaccessibles. Certaines parties des fenêtres sont soudainement insensibles aux clics de souris. Restent la touche tabulation et les raccourcis clavier... Ou alors, on fouine un peu, et on passe par les manip's que je décris ici. Ça marche pas torp mal...
Deux choses sont à régler. La première (en fait y a pas d'ordre, mais mettons que ce soit la première), choisir un thème gtk pour KDE. Dans certaines versions de KDE4, aucun choix n'est fait par défaut, c'est un peu gênant... donc, dans la "Configuration du système" de KDE4, allez dans apparence, styles et polices gtk, et choisissez un thème GTk, par exemple Clearlooks (qui marche très bien)... On a réglé le problème de l'absence de configuration GTk.
Passons au problème de compatibilité avec les options GTk pour Windows. C'est un peu plus compliqué. Il va falloir ouvrir un terminal, se logguer en root, et aller modifier le fichier /usr/bin/eclipse . Comme pour la plupart des logiciels, il s'agit d'un script de lancement pour passer les bons paramètres au binaire.
On va ajouter des choses au début du fichier, histoire d'assurer que tous les boutons sont accessibles. On a besoin de ces trois lignes :
Surtout de la première, en fait, les autres devraient déjà être présentes. C'est un appel pour préciser le comportement des éléments GTk.
A priori, ça devrait marcher mieux ;)
Amusez vous!
En fait, certains boutons deviennent inaccessibles. Certaines parties des fenêtres sont soudainement insensibles aux clics de souris. Restent la touche tabulation et les raccourcis clavier... Ou alors, on fouine un peu, et on passe par les manip's que je décris ici. Ça marche pas torp mal...
Deux choses sont à régler. La première (en fait y a pas d'ordre, mais mettons que ce soit la première), choisir un thème gtk pour KDE. Dans certaines versions de KDE4, aucun choix n'est fait par défaut, c'est un peu gênant... donc, dans la "Configuration du système" de KDE4, allez dans apparence, styles et polices gtk, et choisissez un thème GTk, par exemple Clearlooks (qui marche très bien)... On a réglé le problème de l'absence de configuration GTk.
Passons au problème de compatibilité avec les options GTk pour Windows. C'est un peu plus compliqué. Il va falloir ouvrir un terminal, se logguer en root, et aller modifier le fichier /usr/bin/eclipse . Comme pour la plupart des logiciels, il s'agit d'un script de lancement pour passer les bons paramètres au binaire.
On va ajouter des choses au début du fichier, histoire d'assurer que tous les boutons sont accessibles. On a besoin de ces trois lignes :
export GDK_NATIVE_WINDOWS=1
ECLIPSE_OPTS=""
VM_OPTS=""Surtout de la première, en fait, les autres devraient déjà être présentes. C'est un appel pour préciser le comportement des éléments GTk.
A priori, ça devrait marcher mieux ;)
Amusez vous!
24/03/2010
Installation de la carte BCM4312 sous openSUSE 11.2
Avoir une carte wifi, c'est bien, pouvoir la faire marcher, c'est encore mieux... de préférence sur le système qui nous intéresse. Dans mon cas, je suis censé travailler avec une carte de chez Broadcomm, et comme très souvent avec ces cartes, c'est un peu compliqué... mais bon, vous allez voir, on va s'en sortir avec openSUSE, bon gré mal gré.
Installation sur le noyau de base
Première approche : Broadcomm, contre toute attente, fournit un pilote pour le noyau par défaut de SUSE. Bonne nouvelle, donc, qui s'accompagne de deux mauvaises nouvelles : le pilote est fermé (pouah pouah pouah) et nécessite de changer de noyau. Donc on perd les optimisations desktop du noyau par défaut.
Attention ça va aller très vite :
Ajoutez le dépôt Packman, présent dans les dépôts communautaires.
Cherchez le paquet broadcomm-wl, ou installez le directement avec
Le solveur de dépendances va vous proposer d'installer d'autres paquets, notamment un kernel-debug, dans la bonne architecture. Faites, redémarrez sur le noyau débug qui s'est automatiquement ajouté dans le grub, et c'est à peu près tout...
Vous aurez peut-être à blacklister deux pilotes : ssb et b43. Pas de chance si vous avez besoin de ssb pour votre carte ethernet, donc, ce sera soit l'une, soit l'autre...
Vous aurez peut être besoin de blacklister des choses... a priori ça se fait tout seul, sinon, ça se passe dans
dans le mien on trouvera des choses genre :
Installation avec un nouveau noyau
Ça vous a plu? Ben c'est pas fini... Comme dit plus haut, wl, c'est pas libre, bouh! et surtout, le pilote ne permet pas de passer la carte en mode Moniteur, indsipensable notamment pour fiare un peu d'audit wifi. Qu'à cela ne tienne, on va changer de noyau, pour avoir un pilote qui va bien. C'est aussi possible de patcher celui qu'on utilise actuellement, mais c'est moins intéressant, moins formateur, et beaucoup trop rapide.
Changement de noyau, donc... permière chose, récupérer des sources. Pour ça, il nous faut un dépôt qui va bien, en l'occurence, le dépôt
Ca peut bien entendu se faire par yast, ou par zypper avec
Après, il faut récupérer les sources du kernel qui nous intéresse, genre un 2.6.33 (ou une rc d'un 2.6.34, mais c'est un peu plus risqué, c'est une rc ;) ) en l'installant par yast (par zypper c'est un peu plus long, faut être précis et attentif ;) )
Compilation, donc, je vais passer très vite...
Là vous êtes dans la partie chiante de la manipulation. Vous allez devoir sélectionner les bouts du kernel que vous voulez intégrer ... ça comprend des pilotes, mais aussi des bouts indispensables, genre les couches réseau... prenez bien le temps de lire les docs, l'utilisation de l'interface ncurses est assez simple. Comptez une bonne heure de lecture, et peut être une ou deux tentatives pour que le kernel tourne ;)
avant de pouvoir l'utiliser, après avoir sauvé le fichier .config ;) il reste à compiler et installer la chose. Donc
De ce que j'ai pu voir, pas besoin de modifier de fichier pour le grub, un reboot et ça repart... choisissez le bon kernel, si ça passe c'est bon. J'espère que vous n'avez pas oublié ssb et b43 dans la config sinon faudra recommencer...
Reste donc à récupérer un firmware qui va bien :
s'occupe de ça pour vous.
Ensuite, un petit
suivi d'un
Amusez vous!
Installation sur le noyau de base
Première approche : Broadcomm, contre toute attente, fournit un pilote pour le noyau par défaut de SUSE. Bonne nouvelle, donc, qui s'accompagne de deux mauvaises nouvelles : le pilote est fermé (pouah pouah pouah) et nécessite de changer de noyau. Donc on perd les optimisations desktop du noyau par défaut.
Attention ça va aller très vite :
Ajoutez le dépôt Packman, présent dans les dépôts communautaires.
Cherchez le paquet broadcomm-wl, ou installez le directement avec
zypper in broadcomm-wlLe solveur de dépendances va vous proposer d'installer d'autres paquets, notamment un kernel-debug, dans la bonne architecture. Faites, redémarrez sur le noyau débug qui s'est automatiquement ajouté dans le grub, et c'est à peu près tout...
Vous aurez peut-être à blacklister deux pilotes : ssb et b43. Pas de chance si vous avez besoin de ssb pour votre carte ethernet, donc, ce sera soit l'une, soit l'autre...
Vous aurez peut être besoin de blacklister des choses... a priori ça se fait tout seul, sinon, ça se passe dans
50-broadcom-wl-blacklist.confdans le mien on trouvera des choses genre :
# modules blacklisted for broadcom-wl
blacklist bcm43xx
blacklist ssb
blacklist b43
blacklist ndiswrapperInstallation avec un nouveau noyau
Ça vous a plu? Ben c'est pas fini... Comme dit plus haut, wl, c'est pas libre, bouh! et surtout, le pilote ne permet pas de passer la carte en mode Moniteur, indsipensable notamment pour fiare un peu d'audit wifi. Qu'à cela ne tienne, on va changer de noyau, pour avoir un pilote qui va bien. C'est aussi possible de patcher celui qu'on utilise actuellement, mais c'est moins intéressant, moins formateur, et beaucoup trop rapide.
Changement de noyau, donc... permière chose, récupérer des sources. Pour ça, il nous faut un dépôt qui va bien, en l'occurence, le dépôt
http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/Ca peut bien entendu se faire par yast, ou par zypper avec
zypper ar http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/Après, il faut récupérer les sources du kernel qui nous intéresse, genre un 2.6.33 (ou une rc d'un 2.6.34, mais c'est un peu plus risqué, c'est une rc ;) ) en l'installant par yast (par zypper c'est un peu plus long, faut être précis et attentif ;) )
Compilation, donc, je vais passer très vite...
cd /usr/src/linux2.6.****/
make clean
make mrproper
make menuconfig
Là vous êtes dans la partie chiante de la manipulation. Vous allez devoir sélectionner les bouts du kernel que vous voulez intégrer ... ça comprend des pilotes, mais aussi des bouts indispensables, genre les couches réseau... prenez bien le temps de lire les docs, l'utilisation de l'interface ncurses est assez simple. Comptez une bonne heure de lecture, et peut être une ou deux tentatives pour que le kernel tourne ;)
avant de pouvoir l'utiliser, après avoir sauvé le fichier .config ;) il reste à compiler et installer la chose. Donc
make
make modules_install
make installDe ce que j'ai pu voir, pas besoin de modifier de fichier pour le grub, un reboot et ça repart... choisissez le bon kernel, si ça passe c'est bon. J'espère que vous n'avez pas oublié ssb et b43 dans la config sinon faudra recommencer...
Reste donc à récupérer un firmware qui va bien :
install_bcm43xx_firmwares'occupe de ça pour vous.
Ensuite, un petit
rmmod b43
rmmod ssb
modprobe b43suivi d'un
iwlist scan devrait vous donner de bonnes nouvelles.Amusez vous!
07/02/2010
abcde, utilisation un peu plus avancée.
Vous vous souvenez certainement d'abcde (pour another basic cd encoder) évoqué ici. Là, ce qu'il fait ne me va pas trop : par défaut, il encode les ogg avec un niveau de qualité à 3 (la qualité en ogg est mesurée de -1 à 10. Plus c'est élevé, mieux c'est). En gros, ça fait du 120kbps. Un peu trop bas. Donc j'aimerais un qualité 5, pour être aux environs de 192kbps. Reste à trouver comment le lui dire...
Pour ça, j'ai du chercher un peu :
Nous donnes les infos importantes. En utilisant l'option
C'est déjà plus satisfaisant.
Pour ça, j'ai du chercher un peu :
man abcdeman oggencNous donnes les infos importantes. En utilisant l'option
-o vorbis d'abcde, je peux passer des options à oggenc, qui est utilisé par abcde. genre une "-q 5", parceque ça me fait plaisir. A la fin, ça donne ça:abcde -o vorbis:"-q 5"C'est déjà plus satisfaisant.
Amarok, petit retour d'expérience.
Je suis tombé par hasard sur le site d'amarok, mon lecteur audio favori... quelle ne fut pas ma surprise de constater que j'avais quelques versions de retard... mais que font les packageurs d'openSUSE???
En fait, c'est la configuration de mes dépots qui laisse à désirer... Qu'à cela ne tienne, je fais la mise à jour, le paquet étant dans mes dépôts habituels. Pas de problèmes, heureusement. Du moins pendant la mise à jour. (En fait si, un léger problème de dépendance. Zypper m'a presque déçu, y'avait une solution simple. Comme toujours c'est de ma faute, c'est moi qui l'empêche de changer de fournisseur pour un paquet sans me prévenir. Faudrait que je revoie ça :p )
C'eut été trop beau que tout se passe sans casse. Je lance la version mise à jour... et celle-ci fout le bordel dans la base de données sqlite existante, qui référence ma collection. Pas grave. Je m'y attendais, en fait... du coup, un petit
dégage le tout. Plus de préférences amarok, tout oublié, on repart sur des bases saines. Deuxième surprise : amarok va me chercher les dossiers cachés, maintenant :(. Donc je précise un peu mieux les fichiers à traiter, et ça passe... (en fait, c'est aussi un peu de ma faute. On n'a pas idée de faire des liens symboliques sur des dossiers cachés... )
C'est enfin utilisable... Et là, surprise : je retrouve enfin les sensations d'utilisations que j'avais avec la version... 1.4. Le développement d'amarok 2 touche au but sacro-sain de l'utilisabilité. C'est finalement arrivé. On retrouve une interface agréable, fluide, intuitive, et puissante. L'esthétisme est de nouveau au rendez vous. On récupère le play-back pour les cd audios...
D'autres améliorations en vrac : la récupération des jaquettes est plus performante, c'est nettement mieux. Les panneaux principaux d'amarok sont bien mieux agencés. Et on retrouve enfin des boutons utiles directement dans l'interface. Plus besoin de passer par les menus et sous-menus pour provoquer une lecture aléatoire de la playlist, par exemple...
En bref, donc, que du bonheur :)
En fait, c'est la configuration de mes dépots qui laisse à désirer... Qu'à cela ne tienne, je fais la mise à jour, le paquet étant dans mes dépôts habituels. Pas de problèmes, heureusement. Du moins pendant la mise à jour. (En fait si, un léger problème de dépendance. Zypper m'a presque déçu, y'avait une solution simple. Comme toujours c'est de ma faute, c'est moi qui l'empêche de changer de fournisseur pour un paquet sans me prévenir. Faudrait que je revoie ça :p )
C'eut été trop beau que tout se passe sans casse. Je lance la version mise à jour... et celle-ci fout le bordel dans la base de données sqlite existante, qui référence ma collection. Pas grave. Je m'y attendais, en fait... du coup, un petit
rm -r ~/.kde4/share/apps/amarokdégage le tout. Plus de préférences amarok, tout oublié, on repart sur des bases saines. Deuxième surprise : amarok va me chercher les dossiers cachés, maintenant :(. Donc je précise un peu mieux les fichiers à traiter, et ça passe... (en fait, c'est aussi un peu de ma faute. On n'a pas idée de faire des liens symboliques sur des dossiers cachés... )
C'est enfin utilisable... Et là, surprise : je retrouve enfin les sensations d'utilisations que j'avais avec la version... 1.4. Le développement d'amarok 2 touche au but sacro-sain de l'utilisabilité. C'est finalement arrivé. On retrouve une interface agréable, fluide, intuitive, et puissante. L'esthétisme est de nouveau au rendez vous. On récupère le play-back pour les cd audios...
D'autres améliorations en vrac : la récupération des jaquettes est plus performante, c'est nettement mieux. Les panneaux principaux d'amarok sont bien mieux agencés. Et on retrouve enfin des boutons utiles directement dans l'interface. Plus besoin de passer par les menus et sous-menus pour provoquer une lecture aléatoire de la playlist, par exemple...
En bref, donc, que du bonheur :)
Inscription à :
Articles (Atom)
