Messages étiquettés patch

Cent fois sur le métier remettre son ouvrage

Un pas en avant, et un pas en arrière, c’est toujours de sous dépensés pour rien.

Le Régent a une certaine vision du développement logiciel. Dans cette vision, submergée de papillons et de cornes d’abondance, la logique a fait place à la magie.

Comment être sûr de planter un projet :
- un Chef sans envergure incapable de toute décision ;
- un Régent qui trouve tout trop cher, et donc incapable de lâcher un centime ;
- des Esclaves tellement fouettés qu’ils font tout a minima ;
- un Client qui aurait pu être Chef s’il ne faisait pas partie d’une autre société tellement il ne sait pas ce qu’il veut.

Encore un exemple récent.

Le code est gelé depuis trois semaines, les documents finalisés commencent à sortir. Le Chef a l’excellente idée de se demander, si, finalement, tous ces petits problèmes mineurs le sont vraiment. En effet, il est bien temps ! Après tout, pourquoi les réunions hebdomadaires de trois heures tenues depuis deux mois devraient le rassurer (ou, accessoirement, servir à quelque chose) ?

Après quelques jours d’un effort titanesque, le Chef a retrouvé le nom du logiciel, le chemin d’accès à la base de faits techniques, et les gens du SI lui ont même rappelé ses identifiants, fournis quatorze mois plus tôt. Qui aurait pu deviner que tout cela ait pu servir un jour ? Le Chef peut enfin obtenir la liste des problèmes connus : pour cela, il envoit un mél à un Esclave pour qu’il la lui fournisse fissa.

Aïe ! quel malheur ! mais quelle est donc cet intitulé qu’il trouve sous Excel ? « FT AB13-22 (dit « pan dans ta face ») : problème flou qui fait peur ». Frôlant l’apoplexie, il trouve le temps d’émettre un ordre copieux demandant impérieusement une correction immédiate de ce problème extrêmement sensible. Il peut rentrer sereinement se reposer après ce dur labeur : nous sommes quand même mardi, il est déjà 15h31.

Un Esclave prend le relais. Ne comprenant rien à la description du problème, il peut bien entendu fournir une analyse pertinente sans rien connaître du contexte ni pouvoir rencontrer l’auteur, qui a été dégraissé deux jours plus tôt. Tirant à pile-ou-face-ou-bleu, il explique « il suffit de supprimer une fonction ». Non mais. Encore une victoire de canard : cinq heures de facturées sans coup férir.

Un autre Esclave poursuit. Il supprime la dite fonction, tente de retrouver les tests à passer, qui sont au mieux soit obsolètes, soit pas les bons. Par exemple, la validation des centrales inertielles consiste à vérifier si la température anale du chat de la voisine est bien inférieure à celle de l’ébullition de l’eau sur Jupiter. La réponse est bien évidemment « peut-être », la modification est livrée, le problème considéré corrigé.

Bon, c’est sûr, il faut reprendre une nouvelle fois les documents qui avaient failli ré-émerger du circuit de signature pour les amender, mais quelle satisfaction de savoir le travail bien fait !

Une semaine se passe, le Chef revient tout juste de son repos, mais tout n’est pas bel et bon : depuis que le problème FT AB13-22 a été corrigé, de nouveaux soucis se sont fait jour. D’aucuns diraient que c’est pire qu’avant. Sentant que le moment est idéal pour affirmer sa position en éblouissant ses collaborateurs de tout son savoir, sans omettre d’asseoir un peu plus son charisme animal, le Chef convoque en réunion tous les Esclaves et déclame :

« Bon, ben, tant pis. On revient en arrière. Euh. C’est balistique. Ha ! oui, au fait, bonjour. »

Fin de la réunion. Ça va être un peu compliqué. C’est un peu comme si vous achetiez une planche dans un magasin de bricolage pour monter une étagère, et qu’au moment de passer à la caisse, le responsable du magasin interrompait la vente pour vous annoncer : « désolé monsieur, nous ne pouvons vous vendre ce produit, car nous allons reconstituer l’arbre dont elle est issue afin de le replanter comme si de rien n’était. Les enfants aimaient y faire de la balançoire. »

Même avec la meilleure volonté du monde, on ne peut pas retirer en deux coups de cuiller à pot une vieille modification, d’autant plus si depuis d’autres strates d’améliorations/régressions se sont basées dessus. Faites livrer deux containers d’huile de coude. Paraîtrait qu’ils n’en ont pas au service logistique. Faudrait songer à les virer ceux-là aussi.

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: , , , , ,