Messages étiquettés fedora

Fedora – configurer Emacs pour la coloration syntaxique du OCaml

Chose amusante, je n’ai pas réussi à obtenir la coloration syntaxique du OCaml grâce à l’a-priori bien nommé paquetage « ocaml-emacs ». Peut-être n’est-ce tout simplement pas son rôle.

Par contre, le paquetage « emacs-tuareg » y réussi plus ou moins, avec quelques lacunes, mais c’est déjà mieux que rien. Pour que cela fonctionne, ne pas oublier d’ajouter à son .emacs favori :

;;; OCaml

(setq auto-mode-alist
 (append '(("\\.ml[iyl]?$" .  tuareg-mode ))
 auto-mode-alist))

(autoload 'tuareg-mode "tuareg.elc" "Mode for OCaml programs" t)

 

Tags: , ,

Fedora – Déployer un dépôt git

ou comment j’ai déployé git avec mes ouatmille machines pour travailler tout seul sur mes projets.

Principe de fonctionnement

Vu que je suis le seul développeur, je vais à la fois être le développeur et l’intégrateur. Alors, on ne va pas s’embêter : un dépôt accessible en lecture écriture sur le serveur, et une foultitude de comptes autorisés.

Configuration du serveur

Comme l’explique très bien la documentation de git, deux protocoles de communication sont utilisés :

  • le protocole git:// pour les accès en lecture ;
  • le protocole ssh:// pour les accès en écriture.

La machine hôte de votre projet doit donc activer ces services, et autoriser les connections idoines. Ce qui revient à :

  • pour git:// : installer le paquet git-daemon, ouvrir le port 9418 et activer les services git et inetd dont il dépend ;
  • pour ssh:// : installer le paquet openssh-server, ouvrir le port 22 et activer le service sshd.

On va aussi créer un pseudo-utilisateur, qui hébergera les dépôts git sur son compte, qui, par un heureux hasard totalement fortuit, sera également le répertoire système tel que configuré dans /etc/xinet.d/git

# useradd -d /var/lib/git -N -M -s /usr/bin/git-shell git
# mkdir /var/lib/git/.ssh
# chown -R git /var/lib/git

Identification des participants

Chaque machine depuis laquelle je compte éditer le projet doit être identifiée (c’est surtout valable pour les accès en écriture). Le livre « Pro git » explique très bien comment générer une clef pour chaque participant.

host$ ssh-keygen
host$ scp ~/.ssh/id_rsa.pub server:/tmp/host.id_rsa.pub
server# cat /tmp/host.id_rsa.pub >> /var/lib/git/.ssh/authorized_keys

Initialisation du dépôt

Créons donc un projet, à partir de rien.

cd /var/lib/git
git init --bare MonProjet.git

Visibilité du dépôt

Le projet est donc accessible via deux URL :

  • git://server/MonProjet.git pour les accès publics en lecture uniquement (via git clone);
  • git@server:~/MonProjet.git pour les accès privés en lecture (toujours via git clone) et en écriture (via git push).

Tags: ,

Fedora – Patcher un logiciel à partir de son SRPM finalement

Bon, reprenons. Après avoir joué avec la configuration cachée de rhythmbox, j’ai trouvé une politique de mélange satisfaisante. Malheureusement, à chaque fois qu’on active/désactive la lecture aléatoire, cette préférence disparaît. Autant dire que c’est intolérable, et qu’il va vraiment falloir mettre les mains dans le cambouis. Reprenons donc où nous en étions précédemment.

Écriture du patch

Vu que de nombreuses politiques sont possibles, mais qu’on retombe toujours sur la même en passant en mode aléatoire, c’est forcément quelque part en dur dans le code. Commençons par trouver quel callback gère l’activation du mode aléatoire.

Dans rb-shell-player.c, on trouve l’initialisation du menu « Contrôle », la définition du raccourci clavier, et… le fameux callback :

static GtkToggleActionEntry rb_shell_player_toggle_entries [] =
{
{ "ControlPlay", GTK_STOCK_MEDIA_PLAY, N_("_Play"), "<control>space", N_("Start playback"), G_CALLBACK (rb_shell_player_cmd_play) },
{ "ControlShuffle", GNOME_MEDIA_SHUFFLE, N_("Sh_uffle"), "<control>U", N_("Play songs in a random order"), G_CALLBACK (rb_shell_player_shuffle_changed_cb) },
{ "ControlRepeat", GNOME_MEDIA_REPEAT, N_("_Repeat"), "<control>R", N_("Play first song again after all songs are played"), G_CALLBACK (rb_shell_player_repeat_changed_cb) },
{ "ViewSongPositionSlider", NULL, N_("_Song Position Slider"), NULL, N_("Change the visibility of the song position slider"), G_CALLBACK (rb_shell_player_view_song_position_slider_changed_cb), TRUE },
};

Dans le même fichier, un peu plus loin, on tombe sur la définition de la fonction rb_shell_player_shuffle_changed_cb. Son fonctionnement est assez simple : elle lit l’état d’activation, l’inverse, et applique une politique définie par deux états d’activation :

  • la lecture aléatoire ;
  • la lecture en boucle.

Cette fonction est codée sous la forme d’une table d’association à deux dimensions, appelée state_to_play_order, que l’on retrouve en tête de fichier :

static const char* const state_to_play_order[2][2] =
 {{"linear",    "linear-loop"},
 {"shuffle",    "random-by-age-and-rating"}};

Il suffit donc de changer « shuffle » par « random-by-age », et le tour devrait être joué.

Pour faire le patch, il faut d’abord copier le fichier d’origine, modifier le fichier comme décrit, puis utiliser la commande diff :

# cp rb-shell-player.c rb-shell-player.c.shuffle
# ... édition de rb-shell-player.c ...
# diff -up rb-shell-player.c.shuffle rb-shell-player.c > ../../rb-better-use-random-by-age.patch

Modification du fichier SPEC

Il faut maintenant ajouter notre patch à la liste des patchs à appliquer  lors de la construction du RPM de rhythmbox. Il va également falloir trouver un numéro de version pour le RPM qui devra permettre de mettre à jour la version officielle, sans rentrer en conflit avec les numéros des prochaines versions officielles. Le plus simple est encore de suffixer le numéro de version du RPM bâtit, par exemple en le passant de 4 à 4.1.

En vert, voici les modifications appliquées à rhythmbox.spec :

Version: 0.12.8
Release: 4.1%{?dist}
License: GPLv2+ with exceptions and GFDL
...
Patch2: 0001-Don-t-load-AFC-devices-using-the-MTP-plugin.patch
Patch3: rb-better-use-random-by-age.patch
...
%patch2 -p1 -b .no-mtp-for-afc
%patch3 -p1 -b .shuffle
...

Construction du nouveau RPM, publication, et fin

Il n’y a plus qu’à finaliser tout ceci en produisant le RPM patché :

# rpmbuild -ba --clean --sign SPECS/rhythmbox.spec

puis en ajoutant le nouveau RPM à votre dépôt. La prochaine mise-à-jour yum fera le reste.

Tags: , , , , ,

Fedora – Patcher un logiciel à partir de son SRPM, ou pas

Quelque chose m’énerve dans le fonctionnement de rhythmbox : j’ai 8.534 morceaux à écouter et pourtant, même en lecture aléatoire, je retombe toujours sur les mêmes. En tout cas j’en ai l’impression (ce qui est totalement différent). Alors je voudrais faire deux choses :

  1. Modifier la règle de lecture aléatoire pour n’autoriser à la lecture que les fichiers les moins lus ;
  2. Éventuellement, vérifier la façon dont est fait le mélange des morceaux et le corriger pour éviter tout biais le cas échéant.

Comme mes études ont coûté beaucoup d’argent à mes parents en leur temps, et que je ne veux pas me prendre la tête à tout reconstruire de zéro, on va essayer de faire ça bien, à partir du SRPM de rhythmbox, pour en patcher le contenu, et produire un nouveau rpm qui sera dans mon propre dépôt, avec mon patch.

Télécharger un SRPM

yum n’est pas fait pour déployer les paquetages sources. Pour cela, il faut déjà avoir installé yumdownloader :

# yum install yum-utils

Grâce à ce petit utilitaire, on va pouvoir récupérer le paquetage source de rhythmbox à moindre frais :

# yumdownloader --source rhythmbox

Magie des nuits d’Arabie, un magnifique SRPM vient d’apparaître dans le répertoire courant :

# ls
rhythmbox-0.12.8-4.fc13.src.rpm

Installer les dépendances du SRPM d’origine

Comme on va vouloir chercher à reproduire ce logiciel presque à l’identique, autant commencer par en installer les dépendances. rpmbuild les donne bien volontiers :

# rpmbuild --rebuild rhythmbox-0.12.8-4.fc13.src.rpm
erreur: Dépendances de construction manquantes:
 libgpod-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 gnome-media-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 brasero-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 gstreamer-plugins-base-devel >= 0.10 est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 totem-pl-parser-devel >= 2.21.1 est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 gnome-vfs2-devel >= 2.7.4 est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 avahi-glib-devel >= 0.6 est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 libmusicbrainz3-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 dbus-devel >= 0.90 est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 dbus-glib-devel >= 0.70 est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 libnotify-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 gstreamer-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 gnome-doc-utils est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 pygtk2-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 libsoup-devel >= 2.3.0 est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 lirc-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 libmtp-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 gstreamer-python-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 libgudev-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 libgnome-keyring-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64
 libSM-devel est nécessaire pour rhythmbox-0.12.8-4.fc13.x86_64

Ah ! oui, quand même ! Bon, on ne se décourage pas :

# rpmbuild --rebuild rhythmbox-0.12.8-4.fc13.src.rpm 2>&1 | grep est | cut -d ' ' -f 1 | xargs yum install -y

et tout ce petit monde est installé en deux temps, trois mouvements.

Déployer le contenu du SRPM pour le patcher

Ce n’est pas la partie la plus compliquée. D’abord, installer le rpm source :

# rpm -i rhythmbox-0.12.8-4.fc13.src.rpm

Puis déployer l’archive de code d’origine :

# tar xjf rhythmbox-0.12.8.tar.bz2

qui nous créé un joli répertoire rhythmbox-0.12.8.

Écriture du patch … et changement de plan

On rentre dans le vif du sujet ! En fouillant un peu le projet, on tombe rapidement sur tout un tas de fichiers qui prennent (déjà !) en charge différentes manières d’opérer la lecture aléatoire :

# ls shell/rb-play-order-random*
shell/rb-play-order-random-by-age-and-rating.c
shell/rb-play-order-random-by-age.c
shell/rb-play-order-random-by-rating.c
shell/rb-play-order-random.c
shell/rb-play-order-random-equal-weights.c

Sac-à-papier ! C’est déjà tout fait ! Mais alors, pourquoi diable ce choix n’est-il pas disponible via l’interface graphique de rhythmbox ? Typiquement, ce que je souhaite, c’est appliquer la politique « random-by-age ».

Appliquer une politique donnée dans rhythmbox

On reprend les fondamentaux : je cherche « rhythmbox random age » dans Google, et paf ! Le premier lien m’instruit comment opérer une configuration moins immédiate de rhythmbox et de le régler enfin comme je le souhaite. Pour information, voici la marche à suivre :

# gconf-editor

Menu « /apps/rhythmbox/state », paramètre « play_order ». Il faut passer sa valeur de « shuffle » à « random-by-age » dans mon cas précis. Et le tour est joué.

Conclusion

L’investissement financier de mes parents n’est toujours pas rentabilisé. Même en cherchant à travailler intelligemment, je n’ai pas été suffisamment paresseux. À ma décharge, il n’était pas évident a priori que :

  • rhythmbox propose en natif de modifier la politique qui régit la lecture aléatoire, vu que ce n’est pas dans l’interface du logiciel ;
  • de connaître le nom de la politique qui correspond à mon besoin, et donc de trouver la bonne requête Google qui vient à mon secours.

Désolé donc, ce ne sera pas cette fois qu’on ira au bout de la manipulation, les développeurs de GNOME ont presque trop bien travaillé. Mais il y aura bientôt une autre occasion de reprendre ce thème et de l’adresser complètement !

Tags: , , , ,