The trashiest blog in the World...

Recherche dans la documentation francophone de Fedora : la face PHP

trashy — Wed, 26 May 2010 21:47:00 +0200

Il y a quelques jours, je vous annonçais la création et la mise en ligne d'un bot IRC qui permet d'effectuer des recherches dans la documentation francophone de Fedora.
Si votre mémoire est bonne (ou si vous avez suivi le lien de la ligne au dessus :-p) ; vous saurez que j'ai utilisé le moteur de recherche Apache Solr pour arriver à mes fins.

Quelque jours plus tôt encore, je parlais brièvement de l'API PHP pour Solr, ainsi que de la mise à disposition sur les dépôts Fedora (et EPEL !) de l'extension php-pecl-solr.

Il fallait absolument faire quelque chose de tout cela ! Bon... OK... mon côté petit développeur du dimanche à pris le dessus, d'accord...

J'ai donc utilisé l'API PHP/Solr et utilisé l'indexation que j'avais préalablement effectuée pour MrBot afin de produire une interface de recherche un brin plus évoluée que le simple résultat renvoyé sur IRC.
Voici le résultat : http://fedoradoc.ulysses.fr.

Cette interface apporte, entre autres, les fonctionnalités suivantes :

la recherche de termes dans les titres et/ou le texte des articles du wiki,
un « suggest »
la possibilité de filtrer sur une ou plusieurs catégories,
le sur-lignage des termes recherchés dans les résultats,
la présentation d'un extrait de texte qui permet de contextualiser le résultat.

L'intégration de cette « interface » sur le site fedora-fr.org n'est pas à l'ordre du jour pour différentes raisons :

le serveur actuellement en place ne possède pas assez de mémoire vive pour faire tourner les services actuels plus l'index Solr,
je n'ai pas envie de « perdre mon temps » à intégrer ça dans MediaWiki (ça ne m'intéresse vraiment pas d'apprendre à utiliser leur API),
il faut laisser leur chance à d'autres de contribuer,
...

En revanche, j'ai un peu pêché sur le nom de l'application ; j'étais en panne d'inspiration :'( Ça donne donc php-docfr-solrsearch, mais au diable le nom, cela importe bien moins que les fonctionnalités (illustration parfaite de l'expression « se raccrocher aux branches » diront les esprits chagrins)

Bien évidemment, tout le code source est sous licence libre (GPLv3 en l'occurrence), et disponible sur mon dépôt mercurial. Voici quelques liens « agréables », sinon « utiles » :

Bien entendu, les retours, les commentaires constructifs, les patches (on peut toujours rêver), les intégrations à MediaWiki (ben oui, on peut rêver, non ?) sont les bienvenus !

Je suis bien conscient que le fonctionnement actuel n'est pas parfait et que des incohérences et bogues peuvent survenir. Tout ça sera fort certainement corrigé au fur et à mesure.

French documentation, IRC and searching

trashy — Sat, 15 May 2010 15:34:00 +0200

bochecha on #fedora-fr tells me that would be a good idea to translate my last blog post in english. So, here it is! Thanks to him for his help on the present translation

In march 2008, eponyme annouced arrival on the french IRC channels of a bot he has developped : trustyRC.

For about two years now, trustyRC has endlessly answered to users requests on the french documentation, on the FAS (Fedora Account System), ...

But he's now tired. eponyme is off on new adventures, and two major issues remains with trustyRC:

FAS datas has to be updated by hand ; that was rarely achieved (someone has to think of it, and have the guts, we all know that!),
search within French Fedora's documentation only asks to Mediawiki and gets an HTML result, although everyone knows that MediaWiki base search is very rather limited, and is simply not functionnal. As such, search results are not as relevant as we would like them to be, but let's not blame that poor trustyRC.

Recently, I've been taking a close look at Apache Solr (a Lucene-based search solution); I've also recently added php-pecl-solr extentsion in Fedora's repositories

My goal was to index french documentation wiki ; because I know quite well datas and queries (at least from IRC) that are perfomed; that was a good comparison point for me.
Result is quite impressive, Solr's search power is really not comparable to the one a "simple" PHP application like MediaWiki can provide. Solr can, among others, remove special characters (like our beloved 'é', 'è', or 'à' ), lower case characters, split terms, highlighting, faceting, ... For example, a search on terms like réseau, reseau and network would produce - on the index I'm working on - the same results.

In order to test that indexation and search system, I needed a public querying interface. That was a good opportunity to make some tests against several IRC bots. I've decided to not contribute to trustyRC mainly because I do not have required skills. Instead, I've taken a look and tested several existing python bots; I found a few but only Supybot really satifies me (in fact, that was the only one that did not reconnect every five minutes to freenode network ).

The result? A Supybot plugin for French documentation, connected on French IRC Fedora channels, with the name MrBot!

External plugins loaded into this Supybot instance are:

the French documentation search plugin (developped by myself, sources are available under BSD license),
an (X)HTML validation plugin, just for fun (I've developped it as well, its based on Phenny validation plugin, and code source is also available under BSD license),
the Fedora plugin you could use to query FAS and know, for example, who maintains a specific package,
the Koji plugin which give some informations against Koji builders,
the Bugzilla plugin that displays details on each valid bugzilla URL entered (or with a string like bug #{bug number}).

MrBot usage for the documentation stands as follows:

.wiki what I search: search in wiki titles. If that did not return any results, then it will perfom a plain text search automatically,
.wiki plain what I search: force plain text search only,
.wiki solr {solr query}: query with a Solr request (principally for my testing usage).

Searching with the wiki command will return two links maximum, not showed results count will also be returned.

For most functions, it is possible to ask MrBot in private:

/msg MrBot wiki what I search

To check an URL validity against W3C validator:

.validate blog.ulysses.fr
.validate http://blog.ulysses.fr

Fedora services querying:

.whoowns package: returns package maintainer name (FAS)
.fas fasname: returns FAS account informations for the user. You'd probably use these command in private and not on a channel.
.branches package: returns active baracnhes list for specified package
.what package: returns a brief package description
.list Fedora: shows available commands for Fedora plugin

Documentation francophone, IRC et recherches

trashy — Sat, 15 May 2010 12:49:00 +0200

En mars 2008, eponyme nous annonçait l'arrivée sur les canaux IRC francophones de Fedora d'un bot programmé par ses soins : trustyRC.

Voilà donc un peu plus de deux ans maintenant que trustyRC faisait son travail, répondant inlassablement aux requêtes des utilisateurs sur la documentation francophone, sur le FAS (Fedora Account System), ...

Mais la fatigue l'a malheureusement gagné. eponyme s'est tourné vers d'autres horizons, et deux problèmes principaux persistaient avec trustyRC :

les données du FAS devaient être mises à jour à la main ; ce qui n'est fait que très rarement (il faut y penser et en avoir le courage, on connaît tous ça !),
la recherche sur la documentation francophone de Fedora ne faisait qu'interroger le MediaWiki et récupérer un résultat HTML. Or, chacun sait que la recherche MediaWiki de base est entravée de limitations pour le moins étranges, et n'est simplement pas fonctionnelle. Les résultats ne sont en conséquence souvent pas à la hauteur de nos espérances ; ce n'est cependant pas la faute de trustyRC, le pauvre.

Depuis peu, je m'intéresse de très près à Apache Solr (une solution de recherche web basée sur le projet Lucene) ; j'ai même très récemment ajouté l'extension php-pecl-solr dans les dépôts Fedora.

Je me suis donc fixé comme but d'indexer le wiki de la documentation francophone ; puisque je connais assez bien les données et certaines recherches effectuées régulièrement (notamment sur IRC) ; c'était un bon point de comparaison pour moi.
Le résultat est assez impressionnant, la puissance de recherche de Solr n'est en rien comparable à celle d'une « simple » application PHP. comme MediaWiki Solr permet, entre autres, la suppression des caractères accentués, la mise en minuscule des caractères, le découpage de termes, le sur-lignage, le filtrage, ... Pour exemple, une recherche sur les termes réseau, reseau et network renvoie - pour l'index sur lequel j'ai travaillé - les mêmes résultats.

Afin de pouvoir tester ce système d'indexation et de recherche un peu plus avant, il me fallait une interface d'interrogation publique. Je me suis dit que ce serait une bonne occasion de refaire quelques tests de bots IRC. J'ai choisi de ne pas contribuer à trustyRC principalement car je n'ai pas les compétences requises. Au lieu de cela, j'ai cherché et testé les bots existants en python ; j'en ai trouvé plusieurs, mais seul Supybot m'a réellement satisfait (en fait, c'était le seul à ne pas subir de déconnexions très régulières du réseau FreeNode ).

Le résultat ? Un plugin Supybot pour la documentation francophone, connecté sur les canaux francophones Fedora sous le doux nom de MrBot !

Les plugins externes chargés dans cette instance de Supybot sont :

le plugin de recherche dans le wiki fedora-fr (développé par votre serviteur, les sources sont disponibles sous licence BSD),
un plugin de validation (X)HTML pour m'amuser (également développé par votre serviteur, sur la base du plugin de validation de Phenny, dont les sources sont également disponibles sous licence BSD),
le plugin Fedora qui permet d'interroger les FAS et savoir, par exemple, qui maintient un paquet spécifique,
le plugin Koji qui nous donne quelques informations sur les builders Koji de Fedora,
le plugin Bugzilla qui affiche des détails sur une entrée du bugzilla de Fedora lorsqu'un lien valide est posté (ou une chaîne de la forme bug #{numéro de bogue}).

L'utilisation de MrBot pour la recherche wiki se fait de la façon suivante :

.wiki ce que je cherche : effectue une recherche dans les titres du wiki. Si aucun résultat n'est trouvé, une recherche dans les textes sera effectuée automatiquement,
.wiki plain ce que je cherche : effectue une recherche dans les textes uniquement,
.wiki solr {requête solr} : permet d'interroger l'index avec une requête Solr (principalement implémenté pour mes tests).

L'interrogation via la commande wiki renverra au maximum deux URL ; le nombre de résultats non renvoyés sera également spécifié entre parenthèses.

Vous remarquerez que le caractère d'interrogation est désormais le . (point) ; alors que trustyRC répondait à un ! (point d'exclamation). Pourquoi ce changement ? Parce que j'en avais envie, na !
Toute plaisanterie mise à part ; un bot Supybot est déjà présent sur certains canaux Fedora anglophones - zodbot sur #fedora-devel par exemple - qui répond au . ; l'utilisation du même caractère permet simplement un peu d'harmonie.

Pour la majorité des fonctions, il est également possible d'interroger MrBot en message privé :

/msg MrBot wiki ce que je cherche

Pour vérifier qu'une URL donnée est valide W3C :

.validate blog.ulysses.fr
.validate http://blog.ulysses.fr

L'interrogation des services Fedora :

.whoowns paquet : renvoie le nom (FAS) du mainteneur du paquet
.fas fasname : renvoie des informations sur le compte FAS d'un utilisateur. Vous devriez probablement utiliser cette commande en message privé plutôt que sur un canal.
.branches paquet : renvoie la liste des branches actives pour le paquet spécifié
.what paquet : renvoie une description courte du paquet
.list Fedora : affiche la liste des commandes disponibles pour le plugin Fedora

Tchao facebook - Je reprends ma vie privée

trashy — Sat, 15 May 2010 01:17:00 +0200

Il y a quelque temps, je m'inscrivais sur Facebook ; en grande partie à cause du fameux (et, au demeurant, fort dangereux) effet Lemming !

Non pas que je sois particulièrement fan de ce genre de systèmes ; mais les copains étaient là-bas, c'était rigolo. Au début. Et encore...
Je vous passerai mes humeurs concernant les contenus divers et variés ; j'ai trouvé au final que l'ensemble des informations que je recevais relevait plus du spam qu'autre chose. Et du spam ; j'en ai déjà beaucoup dans mes emails, merci beaucoup !

En dehors de ces considérations personnelles, ce qui m'inquiète le plus se résume en deux points :

les failles de sécurité fréquentes et pas toujours corrigées rapidement,
la politique sur la vie privée adoptée par ce système. On pourra citer par exemple des modifications plus ou moins abusives du contrat d'utilisation, des sanctions arbitraires pas forcément justifiées. Un peu de lecture supplémentaire, l'activité de la vie privée en ligne par Tristan Nitot (cet article ne parle pas que de Facebook par ailleurs) sera également instructive en la matière.

C'est ce dernier point, et notamment un graphique montrant l'évolution des paramètres de vie privée par défaut de facebook qui m'ont décidé à finalement supprimer mon compte (Tristan Nitot a fait echo de cet article en français sur son blog).
Certains pensent qu'il n'est pas possible de supprimer réellement un compte facebook et qu'on ne peut que le désactiver. C'est faux, il est possible de supprimer un compte facebook, même si visiblement, il faut vraiment être motivé pour trouver la façon de faire (encore une chose que je n'aime guère... Ont-ils à ce point « peur de perdre » des utilisateurs et/ou leurs données par ailleurs ? ) !

Donc, voilà, c'est fait, j'ai demandé la suppression de mon compte facebook :

Votre compte a été désactivé du site et sera effacé de façon définitive d'ici 14 jours. Si vous vous connectez à votre compte dans les 14 prochains jours, votre compte sera réactivé et vous pourrez annuler votre demande.

14 jours pour supprimer un compte, je trouve cela très long : j'ai décidé de partir, pourquoi conserver mes données encore deux semaines supplémentaires ?

Si vous souhaitez conserver votre compte facebook, je ne saurai que trop vous inviter à lire ce petit tutoriel qui devrait vous permettre de bloquer une partie des « fuites » de votre vie privée depuis facebook

Notez finalement que mon épouse, avec laquelle je n'avais pourtant pas parlé de ces problèmes de vie privée, avait elle aussi décidé de supprimer son compte facebook. N'ayant pas trouvé le lien, elle l'avait simplement désactivé, et a été fort contente lorsque je lui ai donné la façon de le supprimer définitivement

L'API PHP pour Solr en route vers les dépôts...

trashy — Fri, 14 May 2010 18:43:00 +0200

L'API PHP5 pour Solr sera bientôt disponible dans les dépôts officiels de Fedora !

J'avais il y a peu décidé de tester cette solution, et j'en suis pleinement satisfait ; je donne donc suite en proposant l'extension php-pecl-solr sur les dépôts officiels de Fedora. Pour les plus impatients, les build Koji sont là : http://koji.fedoraproject.org/koji/packageinfo?packageID=10338

Extension Solr pour PHP

trashy — Tue, 27 Apr 2010 08:08:00 +0200

Ces temps-ci, je m'intéresse de très près à Apache Solr (notamment pour le travail).

Solr représente grosso modo la partie serveur du bien connu Apache Lucene (qui est lui même un système d'indexation et de recherche avancé écrit en Java).

Solr est un outil sous forme de servlet Java qui vous permet d'indexer des documents et de faire des recherches via une API web (REST), il propose de nombreuses fonctionnalités. En outre, il rend l'accès et la configuration d'index Lucene plus simple (via notamment des fichiers de configuration XML).

Solr est un outil open Source très actif, et utilisé à de nombreux endroits. Des plugins de recherche basés sur Solr existent notamment pour Drupal et eZ Publish.

Il existe aussi une extension PHP PECL pour Solr qui vous permet d'utiliser une instance de Solr depuis un script PHP5. Cette extension n'est pas disponible dans les dépôts officiels de Fedora, c'est pourquoi j'ai rapidement créé un RPM qui la fournit (afin de pouvoir tester ses possibilités depuis quelques applications personnelles).

Le paquet est disponible ici :
http://odysseus.x-tnd.be/fedora/php-pecl-solr/

Ce paquet a été construit sous Fedora 12 en 64 bits, avec la version de PHP fournie pour cette plate forme sur le dépôt de Remi. J'envisage de proposer ce paquet en revue pour les dépôts officiels, mais seulement si je l'utilise (pour le moment, je teste, on verra après :p).

J'espère que ce paquet pourra être utile à certains

Java et internationalisation

trashy — Fri, 16 Apr 2010 23:26:00 +0200

Je développe régulièrement en Java ; que ce soit pour des projets personnels (applications « de bureau » basées sur Swing principalement) ou pour le boulot.

Dans le développement d'une application, songer à un système d'internationalisation assez rapidement est je pense généralement bénéfique pour deux raisons :

il est alors possible de traduire rapidement et facilement votre application en d'autres langues (ben oui, c'est fait pour !),
la relecture des chaînes originales ou traduites par une tierce personne est grandement facilitée ; nul besoin de pousser l'application dans ses derniers retranchements pour qu'elle affiche le message d'erreur qui ne devrait jamais être affiché :-p

Lorsque j'ai débuté en Java, je travaillais sur un logiciel de gestion de cantines scolaires, et l'implémentation d'un système i18n - bien que non requis par le « cahier des charges » de l'époque - m'est apparue naturelle.
J'ai en conséquence potassé un peu Java, et découvert les histoires de ResourceBundle et de fichiers .properties. J'ai rapidement trouvé un plugin pour l'IDE que j'utilisais (et que j'utilise toujours d'ailleurs - Eclipse) qui facilitait la saisie des chaînes.

Voici en gros à quoi ressemble une telle chaîne dans un programme java, en deux parties. D'abord, dans le fichier source .java :

System.out.println(Messages.getString("myapp.says.hello"));

Ensuite, dans le fichier .properties localisé qui va bien (ici, le français) :

myapp.says.hello=Un bonjour de mon application

Premier problème : la chaîne contenue dans le fichier Java est totalement dénuée de sens, et par moments (voire même souvent), il faut se référer au fichier .properties pour savoir quel était le message prévu.

Second problème : depuis quelques années, je n'avais pas ou très très peu utilisé ce système (pour le boulot, on utilise Cocoon qui fournit son propre système d'internationalisation, basé sur des fichiers XML) ; et le plugin que j'avais trouvé à l'époque ne fonctionne plus avec les versions récentes de Eclipse. Pire : je ne suis pas parvenu à trouver une quelconque application qui me permette de gérer « facilement » ces fichiers.

Et là, c'est un gros problème. En effet, les fichiers .properties sont de simples fichiers textes ; mais dans lesquels les caractères spéciaux tels les accents, les guillemets («»), etc doivent être encodés en unicode. Pour vous donner un exemple :

myapp.prefs=Pr\u00E9f\u00E9rences

Relire et éditer pareilles chaînes de caractères est difficile sinon impossible (personnellement, j'abandonne au bout de moins de 5 lignes en lecture). Une faute de frappe dans les caractères unicode empêche le catalogue complet de se charger, et à priori sans lever d'exception (nous n'avons tout du moins pas trouvé comment faire ).

Je me suis très récemment décidé à essayer de travailler un peu sur mon logiciel de gestion de Cantines, et me suis retrouvé face à ce problème lorsque j'ai voulu modifier une chaîne existante. ; du bonheur en barres

En cherchant un peu, j'ai découvert le projet gettext-commons qui permet d'internationaliser des applications Java avec les méthodes gettext ! Dans l'application, on se retrouve donc avec quelque chose dans le genre de :

System.out.println(i18n.tr("Preferences"));

Chaîne qui sera ensuite extraite automatiquement du code source, ajoutée dans un fichier .po lequel fichier vous pourrez traduire en utilisant un des nombreux outils disponibles. Je préfère nettement cette solution à la première
Pour ne rien gâcher au plaisir, gettext-commons supporte la pluralisation, la contextualisation, le remplacement de variables dans les chaînes, ... La documentation est assez claire pour mettre en place ce système facilement et rapidement dans un projet.

Seul bémol pour le moment : il faut générer le fichier jar localisé pour voir le résultat dans votre application, c'est parfois un peu lourd (ou bien j'ai sauté la partie de la doc qui explique comment faire autrement :-p )

Petite note tant que j'y suis ; c'est normalement documenté (mais je n'ai pas retrouvé la page) ; méfiez-vous des apostrophes dans les chaînes où vous souhaitez effectuer un remplacement de variables. En effet, la chaîne suivante (quel que soit le système utilisé) :

L'application {0} est perdue.

S'afficherait de la sorte :

Lapplication {0} est perdue.

Sans apostrophe, et sans que la variable n'ait été remplacée, donc !
Pour ces cas de figure, il suffit d'échapper l'apostrophe avec une autre apostrophe (!) et le tour est joué. Ainsi :

L''application {0} est perdue.

Donnera :

L'application monappli est perdue.

Relooking en masse...

trashy — Thu, 25 Mar 2010 08:31:00 +0100

Voilà quelque temps, suite à un article lu sur Alsacréations sur l'utilisation de HTML5 et de CSS3, je me suis décidé à faire et à mettre en ligne mon site perso (adresse qui auparavant ne faisait que lister les sites hébergés sur ce domaine) basé sur ces technologies.

Les éléments CSS3 utilisés (notamment les couleurs transparentes, arrondis et ombrages) fonctionnent parfaitement sous :

Firefox 3.6
Epiphany
Arora

Et donc probablement avec la majorité des navigateurs basés sur Gecko ou Webkit. Comme d'habitude, Internet Explorer est à la traîne, mais le rendu reste tout de même correct (bien que moins joli) sous IE 7 et 8. IE6 quant à lui n'est simplement pas supporté, n'en ayant pas sous la main, je ne sais même pas à quoi ça peut ressembler avec cette antiquité

Un petit coup de frénésie, et désormais le thème du site est également appliqué à :

la présentation de mon Curriculum Vitae (sources),
mon dépôt Subversion (sources : XSL, CSS - plus les liens symboliques vers la CSS principale, le script JS pour IE ainsi que les images de mon site perso),
mon dépôt Mercurial (sources).

Le thème est sous licence Creative Commons - Paternité - Pas de modification.

C'est tout de même bien plus agréable quand tout se « ressemble » :-p

HTML5 et XSL...

trashy — Sat, 20 Mar 2010 19:04:00 +0100

Suite à la récente mise en ligne de la nouvelle version de mon site perso, j'avais décidé d'utiliser également ce thème pour mon Curriculum Vitae.

Mon site perso et mon cv sont désormais tous deux en HTML5, et basés sur le même thème

Côté technique, j'ai utilisé Smarty pour mon site perso, aucun souci. Pour mon CV, j'ai utilisé XSLT, et c'est là que j'ai eu un petit problème... En effet, la déclaration doctype HTML5 est la suivante :

<!DOCTYPE html>

Super... Sauf que, en XSL, pour générer un doctype, il faut avoir recours à l'un ou l'autre (ou les deux en même temps) des attributs doctype-public et doctype-system de la balise xsl:output. Pour une déclaration XHTML 1.1, on aurait donc :

<xsl:output method="xml" doctype-public="-//W3C//DTD XHTML 1.1//EN" doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" encoding="UTF-8" indent="yes" omit-xml-declaration="yes"  />

Et en sortie :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Si les attributs doctype-public et doctype-system sont tous deux absents, aucune déclaration de doctype ne sera rendue en sortie. On peut envisager de mettre une valeur vide, mais en sortie, on aura "" (alors que dans le cas de HTML5 ; on ne veut rien !).

Les spécifications actuelles de HTML5 fournissent une alternative via la DOCTYPE legacy string) :

The DOCTYPE legacy string should not be used unless the document is generated from a system that cannot output the shorter string.

En français, grossièrement : à n'utiliser que s'il est impossible au système de générer une chaîne plus courte. C'est mon cas ! Super ! J'achète !
Dans la XSL, on pourra donc mettre :

<xsl:output method="xml" doctype-system="about:legacy-compat" encoding="UTF-8" indent="yes" omit-xml-declaration="yes"  />

Et ainsi obtenir en sortie :

<!DOCTYPE html SYSTEM "about:legacy-compat">

Et voilà qui m'a sauvé la mise, j'ai du mal à voir comment j'aurai pu utiliser une feuille de style CSS commune sur une page en XHTML 1 et une autre en HTML5

Installer Redmine 0.9 sur CentOS

trashy — Tue, 16 Mar 2010 22:36:00 +0100

Pour les besoins du boulot, je me suis récemment plongé dans les différents logiciels de gestion de projets. J'en avais sorti quelques uns du lot en fonction de critères qui nous sont propres, à savoir : Redmine, DotProject, Collabtive, ...
Une seconde, puis une troisième sélection ont laissé en lice Redmine et DotProject.

DotProject - en dehors de son interface pour le moins vieillotte - avait semblé répondre à nos attentes, mais voilà : la dernière version stable n'est pas compatible PHP 5.3, et la branche 2.0 du logiciel ne semble plus évoluer au profit de la future version 3 qui sera basée sur Zend Framework. Cette ré-écriture n'en est qu'à son tout début. Pas très engageant que tout cela...

Redmine de son côté semble bénéficier d'un développement très régulier, et d'une communauté relativement importante et vivante. Un hic : c'est du ruby-on-rails ; et je ne connais pas le moins du monde cette technologie.

Autre « souci » à prendre en considération, le serveur sur lequel devra tourner cette application est sous CentOS et non sous Fedora ; je vais y revenir sous peu...

Donc, je me lance, je récupère une version 0.8 de Redmine que j'essaie d'installer sur mon PC du boulot, en Fedora 12. Pas trop de problèmes à noter, j'ai balbutié un peu et me suis complètement cassé les dents lorsque j'ai voulu brancher apache sur l'installation...

Entre temps, je découvre qu'une demande de revue a été faite sur le Bugzilla pour redmine ! Youpi En y regardant de plus près, la page des pré-requis de Redmine m'apprend que la version de Rails de Fedora 12 n'est pas suffisante (2.3.4) ; de même que la version de Rack (1.0.0). Je vérifie sous Fedora 13, on a un Rails en 2.3.5 et un Rack en 1.1.0. Ça devrait aller.

Oui, mais... ça devrait La version de Rack requise est la version 1.0.1, strictement. Ni la version 1.0.0, ni la version 1.1.0 ne fonctionnent ! En local et à des fins de tests, il est toujours possible d'installer la bonne version du composant avec la commande :

$ gem install rack -v 1.0.1

Il est bien entendu hors de question que je lance une telle commande avec un utilisateur privilégié, la bonne version de rack reste donc installée sur un compte utilisateur local ; du coup, l'intégration dans apache ne fonctionne pas (ben oui, la version système de rack n'est pas la bonne, suivez un peu ). Un petit coup d'oeil sur ma CentOS m'apprend que de ce côté je ne dispose pas non plus de la bonne version de Ruby, etc. Y'a plus qu'à ; comme dirait l'autre.

Dans un premier temps, je crée un utilisateur dédié à ce service :

# useradd -r -m redmine

Ensuite, je récupère la dernière version du trunk de Redmine (récupérer cette version n'est pas une obligation, bien loin de là ; mais l'intégration il y a quelques jours de la notion de sous-tâches directement dans Redmine m'intéressait au plus haut point :-p ).

$ svn co http://redmine.rubyforge.org/svn/trunk ./redmine

Voyons à installer les versions de Ruby et consorts dont nous avons besoin. J'ai re-compilé un certain nombre de paquets sur mon dépôt personnel EL5 (en version 64bits uniquement) à cet effet :

ruby
rubygems
rubygem-actionmailer
rubygem-actionpack
rubygem-activerecord
rubygem-activeresource
rubygem-activesupport
rubygem-fcgi
rubygem-mocha
rubygem-rack
rubygem-rails
rubygem-sqlite3-ruby
ruby-mysql
ruby-RMagick
ImageMagick-6.5.8.10

Pour bénéficier de ces versions, vous pouvez soit les récupérer sur mon dépôt à l'adresse http://rpms.ulysses.fr/el5/x86_64/ ; soit installer mon dépôt :

# rpm -ivh http://rpms.ulysses.fr/el5/x86_64/trashy-release-el5-1.noarch.rpm

Pour ensuite installer les programmes (ruby-RMagick n'est requis que pour l'export PNG des diagrammes de Gantt. Vous pouvez l'omettre si cette fonctionnalité ne vous est pas utile ) :

# yum --enablerepo=trashy install rubygem-rails ruby-mysql ruby-RMagick

/!\ ATTENTION /!\ Ce dépôt personnel est intrusif et remplace des paquets de base de CentOS. Ne l'activez pas par défaut, ou alors à vos risques et périls.

Nous voilà parés ; tous les composants logiciels sont présents, nous pouvons procéder à l'installation. Dans un premier temps, créons notre base MySQL (PostgreSQL est également supporté, référez-vous à la documentation de Redmine pour connaître la procédure à suivre) :

$ mysql -u root -p
mysql> create database redmine character set utf8;
mysql> create user 'redmine'@'localhost' identified by 'my_password';
mysql> grant all privileges on redmine.* to 'redmine'@'localhost';
mysql> flush privileges;

Depuis le dossier où vous avez stocké votre Redmine (/var/www/redmine dans mon cas), copiez le fichier config/database.yml.example vers config/database.yml puis éditez-le de la sorte :

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: my_password
  encoding: utf8
  socket: /var/lib/mysql/mysql.sock

Les variables sont bien entendu à renseigner en fonction des choix que vous avez faits. Notez l'ajout de l'entrée socket sans laquelle je m'étais heurté à de jolies erreurs (il semblerait que ce soit un bogue d'un des composants ruby).
Redmine permet l'utilisation de diverses instances (production, développement, ...). Vous devrez donc dupliquer les informations relatives à la base dans les différentes instances que vous souhaitez utiliser. Une fois de plus, référez-vous à la documentation de Redmine pour en savoir plus à ce sujet.

Puisque j'ai utilisé une version SVN ultérieure à la révision 3055 ; j'ai eu à lancer la commande :

$ rake generate_session_store

Initialisons ensuite la base de données, et profitons-en pour y placer quelques données par défaut :

$ RAILS_ENV=production rake db:migrate
(in /var/www/redmine)
==  Setup: migrating ==========================================================
-- create_table("attachments", {:force=>true})
   -> 0.0812s
[...]
$ RAILS_ENV=production rake redmine:load_default_data
(in /var/www/redmine)

Select language: bg, bs, ca, cs, da, de, el, en, es, eu, fi, fr, gl, he, hr, hu, id, it, ja, ko, lt, nl, no, pl, pt, pt-BR, ro, ru, sk, sl, sr, sv, th, tr, uk, vi, zh, zh-TW [en] fr
====================================
Default configuration data loaded.

Fort bien ! Nous avons désormais une installation de Redmine fonctionnelle Certains répertoires doivent être accessibles en écriture, mais le checkout svn ayant été fait avec l'utilisateur redmine qui se chargera de lancer le serveur de tests, nous n'avons pas à nous en préoccuper... Lançons donc ce fameux serveur :

$ ruby script/server webrick -e production
=> Booting WEBrick
=> Rails 2.3.5 application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2010-03-16 20:15:58] INFO  WEBrick 1.3.1
[2010-03-16 20:15:58] INFO  ruby 1.8.6 (2010-01-11) [x86_64-linux]
[2010-03-16 20:15:58] INFO  WEBrick::HTTPServer#start: pid=14469 port=3000

Et voilà ; en vous connectant à http://monhote:3000 vous accéderez à votre instance Redmine. admin est le login et le mot de passe par défaut. Vous aurez peut-être à ouvrir le port 3000 pour la durée de ce test, ne l'oubliez pas

Vient ensuite la mise en ligne de l'application... À des fins de tests, je me suis risqué à essayer une technique très peu orthodoxe depuis apache... Mais qui n'a pas fonctionné comme escompté. Voici le fichier de configuration que j'avais utilisé (en substance) :

<VirtualHost *:80>
  ServerName redmine.mondomaine.com

  ErrorLog /var/log/httpd/redmine_error_log
  AccessLog /var/log/httpd/redmine_access_log combined

  ProxyPass / http://localhost:3000/
  ProxyPassReverse / http://localhost:3000/
</VirtualHost>

Un peu barbare, certes, mais c'était pour tester « rapidement ». Cette configuration a d'ailleurs fonctionné... Sur certains postes Sur d'autres, j'avais la page de login correcte ; et une fois loggué ; plus de CSS ni de JS. Pas top donc. J'ai décidé de pousser le test plus loin, et d'utiliser le mod_fcgid pour accéder à cette application. Il faudra pour ce faire installer les composants qui vont bien :

# yum --enablerepo=trashy install mod_fcgid rubygem-fcgi

Créons ensuite le fichier de configuration apache qui va bien (/etc/httpd/conf.d/redmine.mondomaine.com.conf par exemple) :

<VirtualHost *:80>
        ServerName redmine.mondomaine.com

        # Logs :
        ErrorLog /var/log/httpd/redmine_errors.log
        CustomLog /var/log/httpd/redmine_access.log combined

        # Dossier contenant les pages
        DocumentRoot /var/www/redmine/public/

        <Directory /var/www/redmine/public/>
                Options Indexes ExecCGI FollowSymLinks
                Order allow,deny
                Allow from All
                AllowOverride All
        </Directory>
</VirtualHost>

Côté redmine, copiez le fichier fcgi d'exemple vers sa destination finale :

$ cp public/dispatch.fcgi.example public/dispatch.fgci

Attribuons maintenant les droits adéquats aux dossiers :

# cd /var/www/redmine
# chown -R apache:redmine files log tmp public/plugin_assets
# chown -R redmine: files/.svn log/.svn tmp/.svn

N'oubliez pas de spécifier ensuite quelle instance de Redmine devra être démarrée (production, development, ...). Pour ce faire, éditez le fichier config/environment.rb puis décommentez (et éditez au besoin) la ligne :

ENV['RAILS_ENV'] ||= 'production'

Pour vérifier que ça ne va pas vous claquer de suite entre les doigts, essayez simplement de lancer le dispatch.fcgi en ligne de commande (vous pouvez ignorer sereinement les erreurs sur les accès aux fichiers de log pour l'heure) :

$ /var/www/redmine/public/dispatch.fcgi

Enfin, une fois que tout est OK, relancez votre serveur apache :

# service httpd restart

Et admirez le résultat

Il m'est arrivé, en fonction des configurations, que ça ne fonctionne pas comme escompté... Dans ce cas, l'une des premières choses à faire, est de commenter les ifModule (et leur contenu, évidemment) pour les mod_cgi mod_fastcgi ; ça ma « sauvé la vie »

GCompris 9.1 sur Fedora !

trashy — Tue, 26 Jan 2010 17:59:00 +0100

La version 9.1 de l'excellent logiciel éducatif GCompris est disponible dans le dépôt "updates-testing" pour Fedora 11 et 12.

Cette version corrige de nombreux bogues présents dans la version 9.0 ; je vous invite à l'installer, à le tester, à le noter dans bodhi (pour Fedora 12 et pour Fedora 11), et à reporter les éventuels problèmes, améliorations ou autres

Pour l'installer :

$ su -lc 'yum --enablerepo=updates-testing install gcompris gcompris-sound-fr'

Pour la mise à jour, remplacez « install » par « update » dans la précédente commande. Les sons sont disponibles dans plus de 20 langues, si vous voulez entendre autre chose que du français.

GCompris 9.0

trashy — Thu, 07 Jan 2010 21:06:00 +0100

La toute dernière mouture du logiciel éducatif GCompris est disponible.

Pour ceux qui ne connaissent pas, GCompris est un logiciel éducatif qui propose énormément d'activités éducatives variées aux enfants de plus de deux ans (ma fille n'a que 18 mois, mais nombre d'activités la font déjà bien rire ; gageons qu'elle appréciera GCompris en temps utile ).

Cette nouvelle mouture apporte de nombreuses corrections et améliorations, je vous laisse lire l'annonce officielle de la sortie de GCompris 9.0 pour les détails.

N'hésitez pas à participer au projet, que ce soit d'un point de vue idées, développement, ou simplement en le testant ! D'ailleurs, pour le dernier point, la version 9.0 de GCompris sera sous peu disponible dans les dépôts testing pour Fedora 12 (la version pour Fedora 11 n'a pas compilé malheureusement) ; n'hésitez pas à tester ces versions et à me remonter les soucis que vous rencontreriez !

Un grand coup de chapeau à l'équipe de GCompris pour leur formidable travail depuis tant d'années

Pour les impatients, les paquets pour Fedora 12 sont dores et déjà disponibles su Koji : http://koji.fedoraproject.org/koji/taskinfo?taskID=1908061

Curriculum Vitae en PDF : au régime sans sel !

trashy — Mon, 04 Jan 2010 19:55:00 +0100

« Comme je n'ai pas trouvé ça sur internet... » (Merci à pingou pour cette superbe introduction...)

Mais je m'égare, expliquons auparavant les faits. J'ai passé pas mal de temps ce week-end à refaire mon Curriculum Vitae ; tant du point de vue technique que du point de vue contenu.

La chose est stockée dans un fichier XML ; la version HTML est présentée à l'aide d'une transformation XSLT assurée par PHP, la version PDF à l'aide de TCPDF.
L'ancienne version PDF utilisait une police de caractères qui n'était malheureusement pas libre. J'ai donc décidé d'utiliser dorénavant DejaVu.

Jusque là, rien de bien problématique me direz-vous, et vous avez parfaitement raison. Mais (oui, il y a un « mais »)... La nouvelle version PDF pèse 1004Ko, ce qui est beaucoup trop.

Une solution simple glanée sur le web consiste à utiliser les commandes ghostscript prévues à cet effet : pdf2ps et ps2pdf. Je me lance :

$ pdf2ps cv.pdf cv.ps
$ ps2pdf cv.ps cv_light.pdf

Le résultat, un fichier de 116Ko. Très bien ! Mais ce nouveau fichier n'inclus pas les polices de caractères utilisées, le rendu en serait donc parfaitement escamoté sur les plates-formes n'en disposant pas :

$ pdffonts cv_light.pdf
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------

Une brève discussion sur IRC m'apprend qu'un ou deux petits paramètres supplémentaires à la commande ps2pdf me seraient fort utiles. Je tente donc à nouveau :

$ ps2pdf -dEmbedAllFonts=true -dUseFlateCompression=true -dOptimize=true cv.ps cv_light.pdf

Même résultat, pas de police embarquée dans mon PDF (mais, que fait la police ?). Après moult recherches, c'est finalement Pikachu_2015 qui a trouvé la solution (mille mercis à lui - et encore c'est peu !) pour son aide qui, une fois de plus, s'avère fort précieuse : en utilisant la commande pdftops en lieu et place de pdf2ps et le problème n'existe plus !

$ du -sh cv.pdf
1004K	cv.pdf
$ pdftops cv.pdf cv.ps
$ ps2pdf -dEmbedAllFonts=true -dUseFlateCompression=true -dOptimize=true cv.ps cv_light.pdf
$ pdffonts cv_light.pdf 
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
WBKNZC+DejaVuSans-Bold_00            TrueType          yes yes no       8  0
LNOFXB+DejaVuSans_00                 TrueType          yes yes no      10  0
IVPSUP+DejaVuSans-Oblique_00         TrueType          yes yes no      12  0
$ du -sh cv_light.pdf 
44K	cv_light.pdf

Et voilà ! En espérant que cette petite astuce pourra servir à d'autres. Il est probable que l'utilisation d'options adéquates passées à pdf2ps renverraient le même résultat, mais je ne les ai pas trouvées.
Prochaine étape : réussir à faire maigrir le fichier PDF généré par PHP directement...

Migration VMWare vers KVM

trashy — Sun, 03 Jan 2010 21:34:00 +0100

Pour les besoins de mon travail, j'avais dû, il y a plus d'un an, mettre en place un système de virtualisation sur l'un de nos serveurs (qui tourne sous CentOS 5).

Je m'étais à l'époque tourné vers VMWare server, qui a rempli son office jusqu'ici. Seulement voilà, le module noyau refuse de se compiler aujourd'hui, et je trouve que le client graphique laisse fort à désirer : les touches du clavier ne sont pas mappées correctement, nous avons régulièrement des gels (voire des plantages !) du serveur Xorg sur les postes clients lorsque nous l'utilisons, .... Si nous n'avions virtualisé que des systèmes Linux, cela ne poserait pas vraiment de problèmes, mais ce n'est malheureusement pas le cas.

Aujourd'hui, KVM est disponible sous CentOS, je me suis donc attelé à son installation et à sa configuration. Comme d'habitude, un petit yum install suffit, pas de soucis notables de ce côté là. Restait à migrer les machines virtuelles existantes sous VMWare vers KVM.

Nous avons trois machines virtuelles qu'il fallait migrer :

une Mandriva Corporate Server 4 en 32 bits
une CentOS 5 en 64 bits
un Windows XP en 64 bits

La solution réside en l'utilisation de virt-convert qui prend en entrée le dossier de la VM VMWare, et qui ressort une image et un fichier de configuration pour libvirt. La syntaxe est la suivante :

# virt-convert /var/lib/vmware/Virtual\ Machines/CentOS5 /home/vms/CentOS5

Lancée telle quelle, cette commande faisait plus ou moins son travail : j'avais bien le fichier de configuration XML et un disque au format RAW, mais ce disque était vide !
Je ne sais pas trop si c'est dû à l'utilisation de fichiers successifs de 2Go pour le disque, ou encore à l'allocation dynamique de l'espace ; toujours est-il que virt-convert ne parvenait pas à s'y retrouver.

Fort heureusement, VMWare fournit la commande vmware-vdiskmanager qui m'a permis de solutionner mon problème :

# cd /var/lib/vmware/Virtual\ Machines/CentOS5
# vmware-vdiskmanager -r CentOS5.vmdk -t 0 CentOS5-copy.vmdk
Creating disk 'CentOS5-copy.vmdk'
  Convert: 49% done.

Une fois la conversion du disque terminée, recréons un dossier qui contiendra les données que l'on va migrer :

# cd /var/lib/vmware/Virtual\ Machines
# mkdir mig_CentOS5
# mv CentOS5/CentOS5-copy.vmdk mig_CentOS5/CentOS5.vmdk
# cp -av CentOS5/CentOS5.vmx* mig_CentOS5/

Nous obtenons ainsi le dossier /var/lib/vmware/Virtual\ Machines/mig_CentOS5 que nous allons pouvoir migrer avec virt-convert :

# virt-convert -o virt-image /var/lib/vmware/Virtual\ Machines/mig_CentOS5 /home/vms/CentOS5
Generating output in 'virt-image' format to /home/vms/CentOS5
Converting disk 'CentOS5.vmdk' to type raw...
Converting disk '/dev/hda' to type raw...
Done.

Super, on a désormais une machine virtuelle utilisable Le dossier /var/lib/vmware/Virtual\ Machines/mig_CentOS5 n'est plus utile, on peut le supprimer sans état d'âme aucun.

Reste un petit point de détail : la référencer dans votre système. La commande virsh permet cela normalement, mais le fichier XML généré par virt-convert ne lui plaira pas. Utilisons donc la commande virt-image de la façon suivante :

virt-image /home/vms/CentOS5/CentOS5.virt-image.xml

Si tout s'est passé comme escompté, cette commande va ajouter la nouvelle machine virtuelle, que vous pourrez alors utiliser comme d'habitude.

Dans la théorie, tout cela est bien beau ; mais dans la pratique il en est autrement :

la machine CentOS : pas de problème au démarrage, mais l'interface graphique n'a pas réussi à se charger en raison du changement « matériel » de carte graphique. Quelques adaptations dans le xorg.conf ont suffit à corriger le problème, rendant la machine virtuelle à nouveau pleinement opérationnelle.
la machine Mandriva : kernel panic au lancement Il est possible qu'en jouant avec les options du noyau je parvienne à la lancer à nouveau, je n'ai cependant pas eu de temps à y consacrer pour le moment.
la machine Windows : écran bleu. reboot. écran bleu. reboot. En mode normal ou en mode sans échec, ce ne serait pas rigolo sinon ! Bon, celle là ; je crois qu'il va falloir la réinstaller, je ne vois aucune solution...

Conclusion : un taux de réussite de 33%, c'est mieux que rien ; mais on peut en déduire que la migration de machine virtuelles n'est malheureusement pas une science exacte.

chroot et SSH

trashy — Thu, 29 Oct 2009 18:52:00 +0100

Il arrive parfois que l'on souhaite avoir recours aux fonctionnalités du chroot sur un système...

Ce terme barbare désigne une façon de faire bien connue sous FTP ; qui consiste à modifier la racine du système pour que l'utilisateur soit restreint à son chroot.

Pour ceux d'entre vous qui utilisent mock, c'est d'ailleurs comme cela qu'il procède pour construire vos paquets : il installe un système Fedora en chroot sur votre disque. Le système installé devient totalement indépendant, et il est possible de l'utiliser pour lancer des commandes sans affecter le moins du monde votre système principal.

En SFTP, ce système n'existait pas avant la version 4.8 de OpenSSH.

Bon, voyons un exemple... Je souhaite créer un utilisateur 'pitivier', et lui donner un accès SFTP sur mon serveur. Accessoirement, je souhaite qu'il ne puisse se connecter qu'en SFTP, et pas accéder à un shell via une connexion SSH standard...

Je vais donc ajouter mon utilisateur ; son dossier personnel sera créé dans /home/pitivier. Déjà, il pourra se connecter en shell, mais là n'est pas le véritable problème ; car en se connectant en SFTP, l'utilisateur 'pitivier' pourra aussi accéder à d'autres fichiers et dossiers, un peu partout sur le système (en fonction des droits de ces derniers, bien évidemment).
En bref, l'utilisateur pourra lister tout ce qui se trouve sous /, /home/, /etc... Mais aussi consulter certains des fichiers (dans /etc par exemple), que 'pitivier' n'est pas censé voir, ou qui ne lui apportent strictement rien

L'utilisation d'un système de chroot permet de re-définir la racine du système : si l'on chroot 'pitivier' dans son dossier utilisateur, ce dernier deviendra la racine pour 'pitivier' ! Prenons un exemple :

/home/pitivier/Documents

deviendra, une fois chrooté :

/Documents

Super, comment on fait ? On y arrive...

Configuration de sshd et préparation du système

Déjà, on utilisera Fedora, et pas sa petite soeur vieille fille... En effet, sous CentOS5, l'actuelle version de OpenSSH est la 4.3 ; dans laquelle le système de chroot n'a pas encore été implémenté. Re-compilation ou google-age de RPM existants, à votre guise.
Fedora 11, pour sa part, embarque la version 5.2 de OpenSSH, et ne nous posera pas le moindre souci.

Créons dans un premier temps le dossier où tout sera chrooté (on y reviendra par la suite, ne vous inquiétez pas) :

# mkdir --parents /chroot/home

Il est possible de chrooter un ou plusieurs utilisateurs. Nous nous intéresserons ici au second cas de figure, et créerons un groupe dédié aux utilisateurs qui seront chrootés. Nommons-le 'sftponly' :

# groupadd sftponly

Configurons à présent le démon SSH. Éditez le fichier /etc/ssh/sshd_config, et modifiez comme suit :

#Subsystem      sftp    /usr/libexec/openssh/sftp-server
Subsystem       sftp    internal-sftp

Nous allons maintenant configurer les options de connexion pour le groupe adéquat :

Match group sftponly
       ChrootDirectory /chroot/home/%u
       X11Forwarding no
       AllowTcpForwarding no
       ForceCommand internal-sftp

Quelques explications :

ChrootDirectory : définit la racine de notre chroot. Ici, nous utiliserons /chroot/home/{nom_de_l_utilisateur}
ForceCommand : force la commande sftp ici, ce qui interdit à l'utilisateur la "simple" connexion via SSH

Pour le reste des options disponibles, je vous laisse consulter à loisir la documentation de sshd_config.

À noter : le répertoire dans lequel le chroot sera effectif doit appartenir à l'utilisateur root. Dans le cas présent, pour l'utilisateur pitivier, /chroot/home/pitivier devra appartenir à root :

# chown root.root /chroot/home/pitivier

Dans le cas contraire, le log (/var/log/secure) ronchonnerait, vous informant que les droits ne seraient pas corrects.

Bien entendu, une fois le service sshd configuré, pensez à le relancer :

# service sshd restart

Ajout d'un utilisateur

Bon, désormais, le système est configuré, ajoutons notre utilisateur (avec le groupe adéquat, sinon ça ne sert pas à grand chose :-p) :

useradd pitivier -g sftponly

Par défaut sous Fedora, la précédente commande va créer le dossier /home/pitivier. Il va nous falloir le recopier au bon endroit, cet emplacement ne sera pas utilisé (beh non, puisque l'utilisateur sera chrooté ;-)) :

# mv /home/pitivier /chroot/home/
# chown root.root /chroot/home/pitivier

Note : si l'envie vous prenait de modifier le répertoire home de l'utilisateur, comme par exemple de la façon suivante :

# usermod --home /mon/repertoire/utilisateur/cool/pitivier

Il faudrait alors créer le répertoire /chroot/mon/repertoire/utilisateur/cool/pitivier

Conclusion

Désormais, l'utilisateur 'pitivier' ne peut plus se connecter qu'en SFTP, pas en SSH. De plus, il sera confiné à son répertoire personnel.

Un souci cependant avec cette technique : 'pitivier' n'a pas les droits d'écriture dans /chroot/home/pitivier... J'ai peut-être (voire même sûrement) loupé quelque chose, mais dans le cas pratique particulier qui m'a intéressé ce jour (et dont je vous fait « profiter »), c'était bien suffisant :-p

Nouvelle galette : 0.63.2

trashy — Wed, 07 Oct 2009 00:51:00 +0200

J'avais annoncé ici même en début d'année (le 06 Janvier pour être précis) la sortie de Galetre 0.63.

Depuis - le 21 mai - une version corrective à vu le jour, et je remet le couvert aujourd'hui, avec Galette 0.63.2 ! Vous pourrez récupérer cette version à l'adresse : http://download.gna.org/galette/galette-0.63.2.tgz

Il s'agit principalement d'une version corrective, voici la liste (non exhaustive) des modifications :

pour la 0.63.1
- certaines préférences n'étaient pas correctement initialisées à l'installation
- sur certains hébergeurs, les fonctions exif ne sont pas disponibles, on utilise GD dans ce cas (bogue #12836)
- le XHTML était parfois mal formé en raison des sessions PHP (bogue #13071)
- correction de notices PHP dans les logs (patch #1133)
- suppression des fonctions posix qui sont dépréciées dans PHP 5.3
- ajout d'un fichier .htcaccess pour interdire la lecture du dossier des images depuis le web
pour la 0.63.2
- la date de fin d'adhésion était incorrecte pour un exercice (bogue #13010)
- les dons n'apparaissaient pas dans la bonne couleur dans le tableau (bogue #13009)
- les entrées d'historique lors de l'ajout ou de la modification d'une contribution ne comportaient pas le login de l'adhérent - comme c'est le cas lors de l'ajout/la modification d'un adhérent (bogue #13011)
- lors d'une installation sous windows, certains caractères du chemin étaient interprétés - “\n” par exemple (bogue #14162)
- lors de l'enregistrement d'une photo ou d'un logo personnalisé avec un canal PNG transparent, ce canal n'était pas sauvegardé, et l'image se voyait donc attribuer une couleur de fond par défaut (bogue #14327)
- l'ajout de restrictions (depuis la 0.63.1) sur l'affichage des photos envoyées empêchait tout logo personnalisé de s'afficher correctement (bogue #14442)
- lorsque l'on modifiait la langue d'un adhérent, la session courante se trouvait traduite dans cette langue (bogue #14443)
- certains caractères, comme les apostrophes, étaient mal encodés dans le sujet des mailings (bogue #14449)
- l'envoi de mail était toujours tenté, même si la fonctionnalité avait été désactivée dans les préférences (bogue #14450)

Je ne suis pas forcément mécontent des améliorations apportées à cette version, mais il faut tout de même avouer que c'est un peu léger... En deux ans de Galette (et, oui, cela fait déjà deux ans...) j'ai tout de même fait un peu plus que cela, mais sans encore avoir eu l'occasion (ou le courage, peut-être) de sortir une nouvelle version).

La prochaine version de Galette sera entièrement récrite en php5/objet, possèdera de nombreuses nouvelles fonctionnalités (dont je n'ai pas forcément la paternité - nous rendrons à César ce qui lui appartient en temps voulu) ; ainsi qu'un nouveau design (pas à la hauteur du récent changement de design du site, mais ce sera déjà pas mal :-D).

Pour vous, fidèles lecteurs ( ! ), une nouveauté presque en primeur (beh oui, les listes de Galette ont les vraies primeurs...) : j'ai commencé l'intégration d'un système de plugins dans Galette, qui demanderait à être bien amélioré : mais qui m'a déjà permis (sur une demande spécifique) de développer un plugin pour la gestion de clubs automobiles. En espérant que ce sera utile au plus grand nombre ! Prochaine étape côté plugins : un plugin Sport qui reprendrait les fonctionnalités de feu Galette-sport, que je n'ai pas eu l'occasion de faire évoluer depuis que je me suis retrouvé propulsé à la tête du projet... Amis sportifs, je pense à vous (je vais même au boulot en vélo tous les jours désormais !!! ;-)).

Voilà les quelques news du pays enchanté de Galette, @ bientôt !

tuxmath dans les dépôts Fedora

trashy — Fri, 12 Jun 2009 08:31:00 +0200

Il y a quelque temps, je vous parlais ici même de l'empaquetage de tuxmath, un logiciel éducatif.

Grâce aux conseils de Bouska, j'avais décidé de proposer l'inclusion de tuxmath aux dépôts officiels de Fedora, la revue a été acceptée, le paquet envoyé sur le CVS et les builds lancés

Côté tuxtype, j'ai proposé un patch correctif pour la mise à jour vers la dernière version, ainsi que pour respecter les règles inhérentes aux polices de caractères fournies directement par les logiciels. J'ai également (à l'instant) demandé à être co-mainteneur de ce paquet. Wait and see

tuxmath devrait arriver dans les dépôts sous peu, en updates-testing dans un premier temps, puis assez rapidement en stable si quelques personnes font des retours de tests positifs.

Un très, très beau cadeau... Maintenant consommé !

trashy — Sat, 30 May 2009 18:46:00 +0200

À l'occasion du sommet européen des développeurs OpenSource (FOSDEM) 2008, plusieurs de mes amis qui ont un point commun en leur participation à la communauté francophone de Fedora nous avaient offert un très beau cadeau (un coffret Smartbox Escapade Gourmande).

Ce cadeau nous avait fait grand plaisir, à ma moitié et moi-même, et nous avions décidé d'un commun accord de se le garder sous le coude pour l'occasion.

Et bien voilà, l'occasion est arrivée !!

Ma dulcinée, ma fille et moi tenons à remercier encore et encore l'ensemble des personnes qui ont participé à ce magnifique cadeau !

Ce vendredi 29 mai je fêtais mes 2x ans (mettez ce que vous voulez à la place du 'x' ), et nous fêtons ma douce moitié et moi notre premier anniversaire de mariage ce dimanche 31 mai. Quelles plus belles occasions aurions nous pu trouver pour notre Escapade Gourmande ?

Nous avons quelque peu hésité devant le nombre de possibilités offertes par le cadeau, et nous avons finalement décidé de nous rendre au « Domaine de Fompeyre », à Bazas (Aquitaine) ; situé à une soixantaine de kilomètres de Bordeaux.
Nous nous attendions évidemment à quelque chose de très bien, mais ce fût bien plus que cela, tout simplement magnifique !

L'endroit est situé sur une hauteur, avec une vue imprenable sur la ville et sa cathédrale. Le cadre est très beau, très agréable et aussi très calme (ce qui nous change de la circulation bruyante et incessante sous nos fenêtres). Voyez plutôt...

En outre - en plus de ce cadre hors du commun - l'ambiance y était calme et détendue, le personnel et les autres clients de l'hôtel fort sympathiques.

Première surprise, à notre arrivée, le réceptionniste nous informe qu'ils nous ont un peu surclassés pour que nous puissions avoir suffisamment de place avec notre « pitchoune ». Nous avons fortement apprécié l'attention, il est vrai que ce n'est pas toujours évident d'emmener notre bébé de 10 mois dans ce genre d'aventures. La chambre est fort jolie, la vue magnifique, que du bonheur !!

Je ne me souviens plus si je vous ai déjà parlé du cadre fort agréable de ce charmant endroit... Voilà une brève synthèse du panorama auquel nous avions droit depuis notre chambre :

Après que nous nous soyons extasiés sur le panorama et le confort de la chambre (Zia s'est surtout intéressée à la moquette, aux prises de courant, et aux recoins ), nous avons décidé de profiter de la piscine intérieure qui est chauffée (nous avons préféré une piscine chauffée pour la petite). C'était la première fois que Zia allait à la piscine, et elle a adoré.

Retour à la chambre ensuite, pour prendre une rapide douche avant d'aller manger. Au menu :

terrine de foie gras de canard maison (succulent),
magret de canard (délicieux)
assiette de fromages (bon, j'aime pas le fromage...)
ronde des dessert : morceau de gâteau au chocolat et morceau de gâteau au citron accompagnés d'un sorbet (un rien gourmand )

La boisson n'était pas comprise dans la formule ; mais nous avons accompagné le tout d'un très bon Bordeaux blanc un peu fruité.

En résumé : un vrai régal !

Cerise sur le gâteau, l'équipe ayant appris que c'était mon anniversaire...

Petites anecdotes : il a fallu que quelqu'un entonne « Joyeux Anniversaire » pour que toute la salle le reprenne en choeur. Je ne savais plus où me mettre, un trou de souris aurait été à ma disposition que je m'y serait rué avec fougue
Zia était avec nous et s'était réveillée peu de temps auparavant, je m'étais levé pour aller la chercher lorsque le serveur est arrivé avec le « gâteau », beaucoup de personnes ont donc cru qu'il s'agissait de son anniversaire, mais je me suis bien gardé de leur signifier que tel n'était pas le cas.

Cette attention m'a particulièrement touché, je tiens à remercier vivement l'équipe du restaurant (peut-être que l'un d'entre eux tombera sur ce billet un de ces jours) ; ainsi que l'ensemble des personnes présentes dans la salle à ce moment là

À la fin du repas, retour à la chambre où nous avons pris un peu de repos ma foi fort bien mérité. Le lendemain matin, nous avons eu le bonheur de prendre le petit déjeuner sur le balcon de notre chambre.

Ensuite, nouveau détour par la piscine pour tester le jacuzzi... Je n'avais encore jamais eu l'occasion d'essayer, et désormais, je me dis que d'en avoir un à la maison pour me délasser après la création d'un paquet RPM pas piqué des vers serait vraiment l'idée du siècle

D'autres photos de ce moment de détente sont visibles sur notre galerie.

Voilà donc, nous avons passé un moment extrêmement agréable, nous sommes tous les trois ravis de ce séjour. Merci, merci, merci, merci, ... - je ne le dirai jamais assez !

tuxtype2 et tuxmath

trashy — Sun, 17 May 2009 14:42:00 +0200

Une brève discussion sur IRC hier soir m'a fait découvrir un logiciel éducatif que je ne connaissais pas encore sous Linux : TuxMath.

Je me suis également rendu compte que ce programme n'était pas empaqueté pour Fedora, et que son équivalent pour le clavier, TuxType, datait de l'an dernier...

Bref, je me suis dit que de mettre à jour TuxType et d'intégrer TuxMath dans les dépôts officiels serait une bonne idée. En cherchant quelque peu sur le bugzilla, j'ai vu un bogue encore ouvert pour TuxType : https://bugzilla.redhat.com/show_bug.cgi?id=477472
Ce bogue concerne l'inclusion de fichiers de polices de caractères dans les paquets ; mais je ne sais pas comment le corriger... Du coup, je ne souhaite pas m'occuper moi-même de la mise à jour de TuxType, ni de la demande d'intégration de TuxMath dans les dépôts officiels.

En revanche, je voulais essayer ces deux programmes sur ma Fedora, je les ai donc construits et mis à disposition sur mon dépôt personnel. Les paquets sont disponibles pour Fedora 9 et 10 en i386 et en x86_64. Pour installer le dépôt :

# rpm -ivh http://rpms.ulysses.fr/fc10/x86_64/trashy-release-fc10-1.noarch.rpm

Pour Fedora 9, utiliser l'URL : http://rpms.ulysses.fr/fc9/x86_64/trashy-release-fc9-1.noarch.rpm

Pour installer les deux programmes :

# yum --enablerepo=trashy install tuxtype2 tuxmath

J'ai installé ces deux programmes sur l'ordinateur de mon épouse afin qu'elle puisse les tester, et elle est actuellement en train de se prendre la tête sur TuxMath

Les paquets ont été uniquement testés sous Fedora 10 en x86_64, je n'ai as d'autre version sous la main...

Amusez-vous bien !

Décret sur l'accessibilité des sites publics : enfin !

trashy — Sat, 16 May 2009 21:32:00 +0200

Le décret sur l'accessibilité des sites publics a enfin été signé et publié au Journal Officiel !!

Depuis 2005, et l'adoption de la loi loi n°2005-102 du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées, de nombreuses personnes dans les milieux du web appelaient de leurs vœux le décret correspondant.

En effet, cette loi sans décret n'obligeait personne à effectivement adopter une logique d'accessibilité dans les sites webs des services publics. Bien que certains aient déjà sauté le pas, que ce soit par décision de « responsables informatique » ou de développeurs sensibles à ce genre de sujets, d'autres - principalement pour éviter de dépenser trois sous qui pour une fois auraient été dépensés de façon fort utile - prenaient pour excuse l'absence de décret pour ne pas rendre leur site conforme aux différentes normes (X)HTML.

Désormais, c'est chose faite, et j'espère que l'accès et l'ergonomie presque pitoyable que nous devons aujourd'hui endurer sur certains sites gagnera un peu en qualité !

Je vous accorde que le respect de standards n'est pas forcément un gage de qualité et encore moins d'ergonomie, mais on a bien le droit de rêver un peu, non ?