Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : WorkLand

git-flow sous Fedora

Johan Cwiklinski

Il y a quelques semaines, j'entendais parler de git-flow, un ensemble d'extensions Git qui aide à respecter le modèle de développement Git de Vincent Driessen ; modèle que je ne connaissais pas d'avantage. git-flow simplifie les choses pour suivre ce modèle.

À l'occasion de la sortie de la nouvelle version de Galette (pleins de nouveautés !! :-p ), et de la migration des sources du projet de Subversion vers Git ; j'ai décidé d'utiliser git-flow.

Premier constat : pas de paquet disponible dans les dépôts :'(
Un RPM de git-flow pour Fedora 16 est donc désormais disponible dans le dépôt trashy (si d'aventure quiconque aurait envie de l'intégrer dans les dépôts officiels, le fichier SPEC et le SRPM sont disponibles ;)" class="smiley )

Une fois le RPM installé, la commande git flow est disponible :

 % git flow version
0.4.2-pre

L'autocomplétion des commandes Git est une aide plus qu'appréciable au quotidien, si vous souhaitez en bénéficier pour git-flow ; il vous faudra installer un script d'autocompleteion pour git-flow (bash ou zsh). Une fois le fichier correspondant à votre shell récupéré, il suffit de faire un source fichier pour que la complétion soit disponible :-)" class="smiley

Bien que je n'aie encore que peu d'expérience avec cet outil, je trouve assez pratique que ce soit lui et non moi qui soit en charge de savoir quelle doit être la branche d'origine, ou encore qu'il se charge automatiquement lors d'une correction de bogue du merge vers les branches de développement et stable, ainsi que la création du tag.
Tout dans git-flow peut être fait à l'aide de commandes Git uniquement, on peut donc facilement choisir de l'utiliser ou non...

Un outil fort intéressant à mes yeux !

Java et internationalisation

Johan Cwiklinski

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 :-(" class="smiley ).

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 :-D" class="smiley

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 :-)" class="smiley
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.

Nouvelle galette : 0.63.2

Johan Cwiklinski

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 ( ! :-D" class="smiley ), 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 !

Subversion : comment créer un miroir de façon sécurisée ?

Johan Cwiklinski

Sur un serveur (que nous nommerons s_svn), nous avons un dépôt SVN, nous souhaitons mettre un miroir de ce dépôt sur un second serveur (s_miroir).

Nous verrons comment utiliser la commande svnsync avec SSH pour parvenir à nos fins.

Tout d'abord, un peu de réflexion (ça fait mal, mais on va se forcer :-D). Nous avons, sur chacun des deux serveurs, un utilisateur nommé 'svn'. Depuis s_miroir, l'utilisateur devra avoir un accès SSH sur s_svn, de préférence avec une clé SSH dépourvue de mot de passe, afin de pouvoir automatiser le processus. Il faudra donc penser à restreindre un peu cet accès, nous ne souhaitons pas que l'utilisateur svn de s_miroir ait un accès inconditionnel à s_svn sans mot de passe aucun ;-)" class="smiley

Commençons par mettre en place la clé SSH. Sur s_miroir, créons la clé :

[svn@s_miroir ~]$ ssh-keygen
enerating public/private rsa key pair.
Enter file in which to save the key (/home/svn/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/svn/.ssh/id_rsa.
Your public key has been saved in /home/svn/.ssh/id_rsa.pub.

La clé créée, nous pouvons l'installer sur le serveur qui héberge le dépôt SVN :

[svn@s_miroir ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub svn@s_svn

Pour plus de sécurité, nous allons restreindre l'accès sur s_svn à la seule commande dont s_miroir ait besoin. La commande en question est svnserve -t, nous allons utiliser les possibilités de SSH pour cela.

[svn@s_svn ~]$ vim ~/.ssh/authorized_keys

Cherchez la ligne qui permet à s_miroir de s'authentifier. Chaque ligne est constituée par défaut de la façon suivante :

type     identifiant_cle     utilisateur

Dans notre cas, nous aurons donc (où {identifiant} est une suite de caractères alphanumériques imbuvable) :

ssh-rsa {identifiant} svn@s_miroir

Pour restreindre à la seule commande qui nous intéresse, il suffit d'ajouter command="svnserve -t" au début de la ligne, ce qui donne donc :

command="svnserve -t" ssh-rsa {identifiant} svn@s_miroir

Avec cette méthode, svnserve -t sera systématiquement utilisée lors d'une connexion avec la clé de l'utilisateur svn sur s_miroir.

Mettons en place maintenant le miroir en lui même. Il faut tout d'abord créer un dépôt svn :

[svn@s_miroir ~]$ mkdir ~/depot_svn
[svn@s_miroir ~]$ svnadmin create ~/depot_svn

Certaines opération sur les propriétés des révisions seront changées lors de la synchronisation, il peut donc être bienvenu de restreindre ces opérations sur le dépôt. Pour ce faire, créez le fichier hooks/pre-revprop-change dans votre dépôt :

[svn@s_miroir ~]$ vim ~/.depot_svn/hooks/pre-revprop-change

Et insérez-y le contenu suivant :

#!/bin/sh
USER="$3"

if [ "$USER" = "svnsync" ]; then exit 0; fi

echo "Only the svnsync user can change revprops" >&2
exit 1
EOF

Pensez ensuite à rendre ce script exécutable :

[svn@s_miroir ~]$ chmod +x ~/.depot_svn/hooks/pre-revprop-change

On initialise le nouveau dépôt :

[svn@s_miroir ~]$ svnsync init --username svnsync file:///home/svn/depot_svn svn+ssh://s_svn/chemin/vers/le/depot
Copied properties for revision 0

Et enfin on lance la procédure :

[svn@s_miroir ~]$ svnsync sync --username svnsync file:///home/svn/depot_svn
Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
Committed revision 3.
Copied properties for revision 3.
...

Notez l'utilisation de l'utilisateur 'svnsync' dans ces deux commandes. Si vous l'omettez, le script créé plus tôt interdira la modification des propriétés de révision, et la synchronisation ne pourra pas avoir lieu.

Une fois la synchronisation initiale terminée, vous avez un miroir de votre dépôt svn sur s_miroir :-)" class="smiley Pour automatiser la tâche, vous pouvez créer une tâche cron sur la commande de synchronisation (la seconde donc, le 'svnsync init' ne devra plus être exécutée).

Galette 0.63 RC2

Johan Cwiklinski

La seconde Release Candidate pour la version 0.63 de Galette vient de voir le jour !

La « bête » est disponible sur l'espace de téléchargement de Gna! :
http://download.gna.org/galette/galette-0.63-RC2.tgz

N'hésitez pas à tester cette mouture, à la pousser dans ses derniers retranchements, et éventuellement à rapporter les bogues et autres coquilles que vous pourriez constater (en espérant qu'il n'y en aie pas :-p).