zypper est surpuissant...

Pour les gens qui ne seraient pas au courant, openSUSE 11.3 est sortie tout récemment. Et contrairement à mes habitudes, je ne l'ai pas installée de suite, ma machine personnelle étant actuellement ma machine de boulot...
Pas grave, me dis-je : j'ai voulu profiter de la bande passante phénoménale de l'école qui m'emploie en ce moment. 2 Go de mise à jour, normalement, fait en une demi-heure... donc début d'installation à 17h. Et hop, zypper dup.

À 17h50, je quitte le bureau... et la mise à jour n'était pas finie (merci latex...). Je dois donc débrancher le câble réseau, en faisant le pari :

"Zypper va y arriver..."

Arrivé chez moi, je sors la machine de sa veille... et plus de clavier. Arrêt brutal de la machine, il me manque à peu près 300 paquets, dans le lot... Donc redémarrage. Je retrouve mon clavier, mais pas d'interface graphique (KDE était pas content... étrange :-p ). Console virtuelle, deuxième zypper dup...

Au fur et à mesure de l'installation, j'ai commencé à retrouver des fonctionnalités. Après installation propre de kdm, j'ai pu accéder à un bureau, puis à firefox. Et à la fin, redémarrage... et tadam, j'y suis. Je roule sur une 11.3 toute fraîche.

Donc dans l'histoire, zypper a réussi à reprendre un upgrade (pas une simple mise à jour, hein, un upgrade) après une mise en veille ratée et un redémarrage.

Chapeau.

Reverse engineering

Je suis, en ce moment, plongé assez profondément dans l'étude des codes d'un logiciel complexe. L'objectif est d'extraire un bout de librairie pour travailler aussi bien, mais en codant moins. Je vous rassure, c'est un logiciel libre, il s'appelle BEAM. Et c'est pour inclure dans un autre logiciel libre, donc ça va ;-)

Le problème, dans ce petit exercice, c'est la taille des codes... J'ai un peu plus de 1700 classes (sans compter les classes de test, d'ailleurs), au total. Et c'est pas forcément évident de comprendre les liens entre les classes et package. Bref, il me fallait un logiciel de reverse engineering performant, pour pouvoir faire de l'UML vite et gagner du temps.

J'ai cur pouvoir compter sur ArgoUML. Et ben non. face à la taille de la tâche, ce cher logiciel me claquait dans les pattes. Il commençait par passer une bonne demi-heure à mouliner (et pourtant mon dual-core ne fait pas semblant de compter, en général... :-p ), et à la fin, il n'était plus franchement utilisable. Après, c'est peut être de ma faute, mais bon...

Du coup, changement de plan, je cherche un suppléant. Et je tombe sur BOUML. J'étais plutôt sceptique, au début, l'expérience précédente m'avait refroidie. D'autant que le logiciel, écrit en C, s'appuie sur qt3, et que c'est pas forcément très courant sur ma machine. Mais je me dégonfle pas, je le cherche dans mes dépôts. Et je l'installe, ni une ni deux.

Après un peu de prise en main, je trouve une bonne méthode pour faire l'import des classes qui m'intéressent intelligemment. Je commence par spécifier l'ensemble du jdk comme bibliothèque de base. Pas d'objections. Puis j'ajoute les dossiers contenant les sources en omettant juste les classes de test. Toujours pas d'objections. Je lance l'opération... et en cinq minutes c'était fait.

Je me retrouve donc avec un logiciel libre (j'ai du oublier de le dire avant ^_^ ) hyper efficace. Mes classes sont toutes là, liées entre elles et avec les classes du jdk. Les imports sont hyper rapides, et le logiciel sait résoudre les dépendances sur plusieurs niveaux. Tout petit bémol : au-delà d'une centaine de classes affichées simultanémént, il commence à ramer un peu... mais un diagramme de classe avec autant de monde, c'est pas super rationnel :-p

En clair, c'est un très bon logiciel. Pour les gens qui ont besoin de ce genre de choses... il vaut le coup :-)

MPD, MPC, Intel et openSUSE...

Sacré quartet évoqué dans le titre. Petits rappels. Pour les deux premiers, au moins. MPD, pour Music Player Daemon, est comme son nom l'indique une programme tournant en tâche de fond, qui permet d'émettre de la musique vers une sortie choisie. On peut même l'utiliser comme base pour faire de la diffusion par le réseau. Non, ne partez pas, c'est pas le but, ici.
Pour contrôler MPD, on peut utiliser un logiciel adéquat. certains sont graphiques, pas celui que j'utilise. L'objectif estt de libérer de la mémoire, afin d'être vraiment à l'aise en utilisant Eclipse, OpenOffice, Firefox, ArgoUML, Kate, tous avec pleins de trucs d'ouverts... Donc j'économise sur le lecteur audio. Même au niveau de l'interface. Mpc est donc fait pour moi :-).

Je vais d'abord vous montrer comment j'ai fait marcher le machin, chez moi, sur une carte son Intel. J'ai du tatonné un peu, ça m'arrivera pas deux fois ;-) . Et vous l'aurez compris, je vais présenter les manip's sur une openSUSE, avec des opérations tout à fait typiques de cette magnifique (et VERDOYANTE) distribution GNU/Linux. Pour les autres, vous pourrez aussi trouver quelques petites choses utiles à la fin. Peut être.

La partie facile : l'installation des deux logiciels. Un simple

zypper in mpc mpd

et le tour est joué, zypper est incroyable.

Pour la suite... MPD s'appuie sur une base de données où il garde les infos sur votr base de données. Il va donc falloir qu'il soit capable de trouver le fichier où est la base, et d'écrire dedans. D'ailleurs ce sera pas le seul fichier utile.

Créez un répertoire .mpd dans votre dossier personnel, et ajoutez-y des fichiers nommés database errors.log log mpd.log state tag_cache
Pour créer un fichire vide, par exemple database, faites
touch database
Ajoutez enfin un répertoire nommé playslists. Pour tous ces éléments, une petite modification s'impose encore. Placez vous dans le répertoire .mpd
cd ~/.mpd
Nous alons changer les droits sur les fichiers créés avant. mpd sera lancé par l'utilisateur mpd, qui appartient au groupe audio. Donc on modifie les droits d'accès en conséquence :
chown mpd:audio *

La suite est un peu sale. L'utilisateur et le groupe doivent avoir accès en lecture et écriture. Donc
chmod ug+rw *


Et il faut pouvoir rentrer dans le dossier. Donc
chmod a+x playlist
Et on arrête de donner des droits d'accès à tort et à travers (parceque c'est pas optimal. Mais y a mieux, et j'ai pas cherché ;-) )

La chose n'est toujours pas prête. On va devoir modifier le fichier de configurattion de MPD, qui se situe dans /etc. Avec nano pour moi, ce que vous voulez pour vous, mais il faut être root ;-) :

nano /etc/mpd.conf
vous allez modifier les valeurs suivantes :
music_directory : l'endroit où est votre musique, sur votre disque.
playlist_directory : Vous devez pointer le répertoire playlist créé précédemment. Donc a priori :
"/home/votrelogin/.mpd/playlist/"

db_file : "/home/votrelogin/.mpd/database"
log_file : "/home/votrelogin/.mpd/log"
state_file : "/home/votrelogin/.mpd/state"

J'ai laissé la variable pid par défaut, à savoir "/var/lib/mpd/mpd.pid", mais j'ai du créer le fichier qui va bien, je crois. dans le doute :
touch /var/lib/mpd/mpd.pid

user : laissez "mpd", on a fait les modifs pour ;)

Pour les utilisateurs d'une carte son Intel de type ICH9 (ou plus généralement celle qui utilisent le module snd_hda_intel), la section audio output devra ressembler à ça :

audio_output {
type "alsa"
name "Intel G45 DEVCTG"
# device "hw:0,0" # optional
format "44100:16:2" # optional
mixer_device "default" # optional
mixer_control "Master" # optional
mixer_index "0" # optional
}

Je sais, c'est étrange de virer la section device. Mais chez mois ça marche comme ça :-) .


À ce stade, la chose est prête à être lancée. Dans une console root :
mpd --create-db
rcmpd start
devrait passer sans problème. On crée ensuite la collection :
mpc update

Enfin, quelques petits trucs. J'aime bien être efficace, donc les deux scripts suivants peuvent être tout à fait pratique :

#!/bin/bash
if mpc |grep -q paused
then
mpc play
else
mpc pause
fi

ce script, que j'ai magnifiquement appelé pause, met en pause la lecture si mpc lit un fichier, et la remet en marche si mpc est en pause.

#!/bin/bash
if mpc|grep -q 'random: off'
then
mpc random on
else
mpc random off
fi
De même, ce programme (que j'ai nommé random) active ou désactive la lecture aléatoire.

Placez les deux scripts dans /home/votrelogin/bin . et rendez les exécutables avec un chmod u+x, aussi ;-) . L'avantage de les mettre dans ~/bin, c'est que vous pourrez les appeler très vite. Sous KDE, vous pourrez même utiliser le lanceur d'applications. Bref, la vie est belle :)

Enfin, j'ai aussi quelques petits alias (qui ne sont utilisables que depuis une console où vous êtes loggés en votre nom ). À mettre dans .bashrc (qui peut être créé pour l'occasion). :

alias next='mpc next'
alias stop='mpc stop'
alias play='mpc play'



Une dernière chose pour la route : mpd est un démon, il peut être lanccé automatiquement au démarrage. Pour les gens de chez suse, passez par YaST, trouvez le module qui gère les niveaux d'exécution, passez en mode expert, et cochez les cases 3 et 5 pour mpd. Prudence, cependant, si le démon est arrêté alors qu'une lecture est en cours, elle sera reprise automatiquement au démarrage suivant. Donc pour la discrétion... ;-)

Amusez-vous !

Montage automatique d'un périphérique... depuis la console.

Y a des jours où c'est pas facile... quand il s'agit de faire de l'aide sur IRC, en général, ça va, quand les gens ont un minimum de connaissance... mais parfois... et allez expliquer comment monter simplement un périphérique, avec un utilisateur qui n'est pas capable de trouver le nom du disque en question, et encore moins l'identifiant des partitions qu'il contient...

Du coup, après plus d'une heure perdue, ou presque, à essayer de glaner des infos pour lui faire faire les bonnes manip' avec mount, j'ai fini par me demander quel outil simple existait pour remplacer les gestionnaires d'évènements HAL présents dans KDE ou Gnome.

Un petit tour... sur IRC :D et je trouve une réponse satisfaisante (en moins de trente secondes, efficacité raisonnable :p )

On va utiliser un script Python, nommé halmount. Faut l'installer, d'abord, il est dans le paquet ivman :

zypper in ivman

Ensuite...

man halmount nous donne des informations utiles. Notamment si on veut, ce qui est le cas de mon utilisateur débutant, monter tous les machins présents automatiquement.

halmount

nous liste les possibilités,

halmount -a

monte toutes les choses non montées et montables automatiquement

Amusez vous !

Lancer une application graphique par SSH

Chose assez inhabituelle pour moi, j'ai deux machines qui tournent bien à disposition. Donc je peux m'amuser un peu avec... Question du jour : comment lancer une application graphique au travers de SSH, sans VNC ou autre outils de ce genre... Le but étant... euh... bon, y a pas vraiment de but. Mais je suis sur que ça peut servir.

Première chose : je pars du principe que vous savez activer sshd correctement sur la machine serveur, et ce avec ouverture du pare-feu. Pour les utilisateurs d'openSUSE, c'est assez simple : dans YaST, Pare-Feu, Services autorisés, ajouter SSH dans la zone externe. Et configurer votre interface réseau pour qu'elle soit dans la zone externe (ce qui est bien plus sûr, en passant... ;-) )

Une fois la chose faite, sshd et X11 démarrés sur le serveur, placez vous sur la machine cliente, ouvrez un terminal, et lancez la connection ssh :
ssh -X user@machine

Je pars du principe que user a les sur X11... Notez le "-X" dans la commande qui va permettre d'importer les variables relatives à l'environnement graphique.

Jusque là, ça va... Nous allons maintenant devoir autoriser les directives allant vers le serveur X à être prises en copte depuis notre machine. Supposons que notre machine s'appelle patate . À travers la connexion SSH, nous autorisons patate à lancer des commandes faisant intervenir X11 :
xhost +patate
Nous supposons ici que le serveur connaît le nom de notre machine. Si ce n'est pas le cas, utilisez une adresse IP, par exemple :
xhost +192.168.0.10
Ce n'est pas fini, cependant... les variables X11 actuelles sont relatives à la machine cliente... il va donc falloir changer un peu les choses  en corrigeant la variable DISPLAY :
export DISPLAY=:0.0
Et normalement, c'est bon... :-) pour tester, lancez xterm depuis la machine cliente :
xterm
Mieux, xdg -open marche tout à fait convenablement de cette façon :-)

Amusez vous !

Installation d'awesome pour openSUSE 11.2

En traînant sur des blogs, je suis tombé sur la page d'awesome, un bureau qui se présente comme étant un gestionnaire de fenêtres hautement configurable hautement novateur, et particulièrement adapté pour les développeurs. Comme j'aime bien me faire chi** à configurer ce genre de choses, je décide de l'installer. Coup de chance, il est dans mes dépôts, donc un
zypper in awesome
a suffi. Pour ceux qui n'ont pas cette veine, passez par ce site pour la recherche de paquets. Ou ajoutez le dépôt X11, et faites l'install avec zypper.

Et là, problème : utilisateur de KDE, je ferme ma session, me retrouve dans KDM, et pas de traces d'awesome... erf. Du coup, je fouine un peu, et je me retrouve à rajouter un fichier dans
/usr/share/kde4/apps/kdm/sessions/
C'est le répertoire où KDE va regarder, pour savoir quels sont les environnements de bureaux installés. Pour chaque bureau, un fichier .desktop. Donc on rajoute un fichier
awesome.desktop
et on met les choses suivantes dedans :
[Desktop Entry]
Encoding=UTF-8
Name=awesome
Comment=awesome
Exec=awesome
Type=XSession
TryExec=awesome
Et o ntrouve enfin awesome dans la liste des bureaux disponibles. Pour la suite (l'utilisation) reportez vous aux manuels divers. Mais je confirme : ça a l'air hautement cool :)

Amusez-vous!

Interactions de communautés.

Petite mise en contexte

De nombreux remous ont agité la communauté Alionet à la fin de l'année 2009. À l'époque, la communauté Kaméléon-Facile (KF) s'est dissoute. KF hébergeait une documentation très importante, qui servait officiellement de documentation à Alionet. Du jour au lendemain, la communauté Alionet s'est donc retrouvée sans site pour sa documentation.  Nous avons donc envisagé plusieurs solutions, et sommes tombés d'accord avec l'équipe qui assure l'organisation du projet Linuxpedia . Et nous avons alors commencé la migration, dont la description des étapes n'est pas le but de ce billet.

Cet état de fait a provoqué l'apparition d'un problème original. Nous partons de deux communautés a priori distinctes : on a des utilisateurs d'openSUSE réunis au sein d'un forum, et des utilisateurs de systèmes libres qui alimentent un wiki très vaste (plus de 2500 pages... ). Bien sur, on compte quelques personnes qui jouent sur les deux tableaux, qui contribuent à la fois au forum et au wiki... mais elles sont assez peu nombreuses, en fait. La problématique suivante est donc apparue. Les membres des deux communautés cherchent à répondre à leur besoin d'informations auprès de l'outil de leur choix, ici un forum d'une part, et un wiki d'autre part. Les attentes sotn donc propres, même si elles peuvent avoir des points commun.

De plus, Linuxpedia a un statut un peu particulier : il s'agit d'une documentation traitant de problèmes très différents. Il faut donc réussir à inclure une documentation pour une distribution spécifique, ici openSUSE, dans un cadre très général. Point positif, l'expérience n'est pas la première du genre pour Linuxpedia, qui abrite par exemple la documentation de la distribution Nutyx. Point négatif : il est nécessaire de repenser la structure de la documentation qui était proposée par Kaméléon-Facile...

Une situation à démêler...

Que ce soit pour Linuxpedia ou pour Alionet, les projets à mener sont toujours le fruit de l'attente, puis de la mise en oeuvre, de la communauté. Malheureusement, dans notre cas, la situation est extrêmement complexe. En effet, les pages à étudier sur l'ancienne documentation sont nombreuses, et doivent être mises en ligne au sein de Linuxpedia. Malheureusement, aucune architecture n'est prévue pour ce genre d'entreprise, il est donc nécessaire de tout reconstruire. De plus, Linuxpedia possède ses propres règles, qu'il serait impensable pour la communauté Alionet de ne pas suivre. L'association entre les deux  communautés doit être pérennes, sans quoi le projet mourra. Et si le projet est intéressant pour Alionet, puisqu'il permet une remise en ligne et un renouveau de la documentation, il l'est également pour Linuxpedia. En effet, cette intégration permet l'apport de nouvelles connaissances, et un partage de ressources entre les commaunutés. Il est tout à fait naturel d'envisager un transfert de compétences d'une communauté à l'autre, de façon tout à fait transparente.

Dans le cadre ainsi présenté, comment réaliser la migration? Bien entendu, les communautés sont maîtresses de la chose. Cependant, il est plus qu'indispensable de réussir à transmettre les informations clairement, surtout lors des premières phases de reconstruction : la construction de l'architecture, et le transfert des documentations les plus importantes vers la nouvelle ossature. À ce niveau d'interactions, je pense qu'il est plus habile de faire communiquer des représentants de la communauté en cercle restreint, plutôt que la communauté dans son ensemble. Cela permet de limiter les problèmes de communication, et de simplifier les processus de décision.

Attention cependant, il faut toujours garder à l'esprit la règle suivante : une décision ne peut jamais être prise par une seul personne, sans consentement des autres, et de préférence avec un large soutient. Dans notre cas, la communication a connu deux niveaux distincts, peut être trois. D'une part, l'équipe d'administration d'Alionet a construit peu à peu une architecture d'accueil, qui a longtemps été débattue avant d'arriver à un résultat satisfaisant tout le monde. D'autre part, nous avons été, et sommes toujours, engagé dans un dialogue étroit avec le staff de Linuxpedia. Ceux-ci ont ainsi pu émettre des critiques vis-à-vis du résultat que nous proposions, et améliorions peu à peu.

En choisissant cette approche, nous avons effectué l'hypothèse suivante : nous pensons être capable d'effectuer un travail qui sera satisfaisant pour la communauté. Cette hypothèse est dangereuse, car elle nous impose une très grande prudence. En effet, on peut très rapidement s'éloigner de ses objectifs, oublier quel est l'intérêt du travail que nous accomplissons, et imposer finalement un résultat décevant, sans être plus capable de comprendre pourquoi les membres sont déçus.

Et les membres de la communauté dans tout ça...

Le pari était risqué. Nous serons bientôt fixé sur la qualité de notre travail, il est très proche de la mise en ligne, la plupart des phases de migration subissent des finitions  ces jours-ci. Nous avons fait le choix discutable de parler au nom de la communauté, tout en sachant que nous ne pouvons pas la représenter pleinement.

Car après tout, ces différents projets appartiennent tous aux diverses commautés. De même que Linuxpedia ne pourrait continuer son aventure sans la contribution de ses rédacteurs, Alionet mourrait sans les interventions prolifiques de certains de ses membres, toujours prompts à défendre la carte graphique veuve et le chipset wifi orphelin.

Le travail des équipe d'administration n'est qu'une simplification pour les utilisateurs. Il permet de résoudre de façon à peu près transparente les interférences qui secouent naturellement les mouvements de ce genre de projets. Transparente pour les utilisateurs. Suite à une discussion avec un membre de l'équipe technique de Linuxpedia, ce soir (enfin, hier soir, mais bon... ), il est ressorti qu'après tout, nous ne sommes que des membres de ces communautés. Même en étant administrateurs, nous sommes aussi de simples contributeurs. Avec une contrainte supplémentaire : ce que nous faisons peut rendre la vie de la communauté plus simple. Mais ça peut aussi la détruire.