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

Easybashgui 10.0.0

Matthieu Saulnier

Introduction

Cet article inaugure une petite chronique dont l'idée m'est apparue pendant l'exécution de tâches répétitives (ie: mon travail IRL). J'ai en effet réalisé que le Web foisonne d'éléments pour la construction initiale de paquets RPM, d'ordre théorique (wikis, documentations...) et d'ordre pratique (articles de blog, paquets du dépôt Fedora...). Sauf que, un paquet RPM est voué à évoluer dès sa création, les modifications provenants du programme empaqueté ou paquet en lui-même pour correspondre aux évolution du système d'empaquetage global. On ne pousse pas un paquet dans le dépôt puis on l'oublie. En se tournant vers le Web à la recherche de divers éléments, j'ai vu que la partie théorique est certes correctement abordée (wiki fedoraproject), mais que la partie pratique était juste absente. Devant ce vide, je me suis dit qu'avec mes quelques paquets il fallait tenter quelque chose... Cette chronique a plusieurs objectifs, donner une illustration pratique du processus de mise à jour afin de suciter la curiosité chez les néohpytes (oui le Projet Fedora manque de packagers pour les paquets préexistant, c'est un fait avéré), et afin de suciter la critique chez les empaqueteurs experts. Car ma technique est loin d'être parfaite, il y a toujours une occasion pour s'améliorer.

Prérequis

Avoir le groupe de paquets Fedora Packager installé sur votre machine

# yum install @rpm-development-tools

Récupération des sources du paquet

Chaque paquet du dépôt Fedora possède un petit dépôt de code source dans lequel le propriètaire du paquet peut travailler. Ce petit dépôt est visitable en ligne ici pour Easybashgui, il contient les fichiers nécessaires à la construction du RPM à savoir le fichier SPEC et l'archive source du programme empaqueté, et il utilise le système de contrôle de version GIT. On ne dit pas « télécharger » un dépôt mais « cloner », nous allons donc cloner le dépôt du paquet Easybashgui sur notre disque dur:

casper@blackbird:~/fedora-scm$ fedpkg clone -a easybashgui

L'option -a signifie « anonyme » juste parce que les accès aux dépôts sont contrôlés par les comptes FAS. La première chose à vérifier est que le paquet embarque bien la dernière version du logiciel:

casper@blackbird:~/fedora-scm/easybashgui$ egrep 'URL|Version' easybashgui.spec
Version:        8.0.1
URL:            https://sites.google.com/site/easybashgui/

Rendons-nous sur le site à l'url indiquée. Sur la page Download on voit que la version actuelle du logiciel est la 10.0.0, il est temps de mettre à jour le paquet.

Récupération des sources du logiciel

Comme nous venons de le voir, les sources du logiciel sont hébergées sur la plateforme d'hébergement Github, qui offre un système de téléchargement de l'archive source assez spécial. En fait Github dispose lui-aussi d'un système de contrôle de version, avec la possiblité d'associer un commit à un tag. Ici le commit (court) est « ad4222f », et le tag est défini arbitrairement par le développeur qui indique ici la version de son logiciel. Il nous manque encore une information avant de pouvoir commencer, la version longue de l'identifiant du commit, que l'on obtient en cliquant sur l'identiant court: ad4222f0082adc877a35c0f3984b2cc7c8319d9b. Après cette petite navigation dans Github, nous disposons de toutes les information requises pour modifier le SPEC.

casper@blackbird:~/fedora-scm/easybashgui$ head -1 easybashgui.spec                                                                                                     
%global commit f39fd3b22e7af267613d35de659b94c3f55b9fb1

On peut remplacer l'ancien commit qui indiquait la version 8.0.1 par le nouveau:

casper@blackbird:~/fedora-scm/easybashgui$ sed -i s/f39fd3b22e7af267613d35de659b94c3f55b9fb1/ad4222f0082adc877a35c0f3984b2cc7c8319d9b/ easybashgui.spec

On met à jour le tag « Version »:

casper@blackbird:~/fedora-scm/easybashgui$ sed -i 's/Version:        8.0.1/Version:        10.0.0/' easybashgui.spec

Et enfin on ajoute une entrée au %changelog:

--- easybashgui.spec.orig       2014-01-20 01:18:32.637223701 +0100
+++ easybashgui.spec    2014-01-20 01:19:52.216888031 +0100
@@ -78,6 +78,9 @@ chmod 644 easybashgui_test.sh
 
 
 %changelog
+* Mon Jan 20 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxx> - 10.0.0-1
+- Update to 10.0.0
+
 * Tue Aug 06 2013 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxx> - 8.0.1-1
 - Update to 8.0.1
 - Upstream has moved sources on github

Avec ces modifications, nous pouvons désormais télécharger l'archive à la version du logiciel souhaitée avec l'outil « spectool »:

casper@blackbird:~/fedora-scm/easybashgui$ spectool -g -S easybashgui.spec

Maintenant commence le travail d'investigation pour savoir ce qui a changé dans le logiciel qu'il faut répercuter et adapter dans le RPM. J'ai pour habitude de copier l'archive dans ~/Téléchargements/ pour l'extraire et pouvoir fouiller en profondeur dedans.

L'évolution du logiciel

Jusqu'à la version 8.0.1 je n'utilisais pas le Makefile fourni car il était partiellement erroné (au niveau des modes des fichiers), aujourd'hui il apparait que tout est OK pour les modes des fichiers sources, nous allons donc désormais l'utiliser. Dans la partie %install du SPEC il va falloir tout remplacer par la commande « make install ».

On voit aussi que le développeur a trié ses fichiers sources dans les répertoires icons/ lib/ scr/ ce qui n'était pas le cas dans la version précédente. Du coup, la commande 'sed' dans la partie %prep du SPEC va être cassée. Sauf que, en cherchant dans l'archive, le fichier "easybashgui_test.sh" manque à l'appel, en conséquence nous allons supprimer la commande 'sed' qui n'a plus lieu d'exister.

Du coté des fichiers qui vont être installés par le RPM, le nom de certains fichiers installés a changé, par exemple l'ancien "easydialog.sh" se nomme désormais "easydialog". L'emplacement des deux fichiers de bibliothèque a également changé. Tous ces changements seront répercutés sur la section %files du SPEC.

Et enfin malgrès le développement intensif de cette bibliothèque, les dépendances indispensables à son bon fonctionnement (tag Requires dans le SPEC) semblent inchangés.

Les modifications du RPM

On ouvre son éditeur de texte préféré et on modifie le fichier SPEC dans l'ordre précédemment énoncé.

La partie %install

--- easybashgui.spec.orig       2014-01-20 01:56:56.976175885 +0100
+++ easybashgui.spec    2014-01-20 23:46:11.130181100 +0100
@@ -44,27 +44,7 @@ sed -i "s@#!/usr/bin/env bash@@" easybas
 
 
 %install
-# Install binaries :
-mkdir -p %{buildroot}%{_bindir}/
-install -pm 755 %{name}                     \
-                %{name}-debug               \
-                easydialog.sh               \
-                %{buildroot}%{_bindir}/
-# Install lib files :
-mkdir -p %{buildroot}%{_libexecdir}/%{name}/
-install -pm 755 %{name}.lib                          \
-                easybashlib                          \
-                %{buildroot}%{_libexecdir}/%{name}/
-# Install shared files :
-mkdir -p %{buildroot}%{_datadir}/%{name}/
-install -pm 644 Ok.xpm                            \
-                Attenzione.xpm                    \
-                %{buildroot}%{_datadir}/%{name}/
-# Install man file
-mkdir -p %{buildroot}%{_mandir}/man1/
-install -pm 644 %{name}.1* %{buildroot}%{_mandir}/man1/
-# Fix mode of easybashgui_test.sh :
-chmod 644 easybashgui_test.sh
+make install DESTDIR=%{buildroot}
 
 
 %files

La partie %prep

--- easybashgui.spec.orig       2014-01-20 23:49:16.987846224 +0100
+++ easybashgui.spec    2014-01-20 23:54:40.296437416 +0100
@@ -35,8 +35,6 @@ lancé ou non.
 
 %prep
 %setup -qn %{name}-%{commit}
-# Remove shebang from easybashgui_test.sh :
-sed -i "s@#!/usr/bin/env bash@@" easybashgui_test.sh
 
 
 %build

La partie %files

Cette partie mérite quelques explications avant de balancer le diff. En effet si on lit le Makefile on aperçoit que les fichiers de documentation (README, EasyBashGUI-license) sont installés par le 'make install'. Rien d'extraordinaire en soi, sauf que dans cette partie existe déjà une macro sensée copier automatiquement ces fichiers doc dans le répertoire /usr/share/doc/ et d'assigner la proprièté de ces fichier au paquet. La copie des fichiers de la macro %doc fait un peu doublon avec le Makefile, mais il faut toutefois que la proprièté des fichiers soit assignée au paquet. Pour cela nous allons simplement ajouter le répertoire des fichiers doc à la liste des fichiers dont le paquet est propriètaire, et enlever la macro %doc. Pour la traduction des macros de chemin de fichier, c'est par ici (juste au cas où).

--- easybashgui.spec.orig       2014-01-21 00:55:31.425925488 +0100
+++ easybashgui.spec    2014-01-21 01:00:31.694894978 +0100
@@ -46,13 +46,13 @@ make install DESTDIR=%{buildroot}
 
 
 %files
-%doc README EasyBashGUI-license easybashgui_test.sh
 %{_bindir}/%{name}
 %{_bindir}/%{name}-debug
-%{_bindir}/easydialog.sh
+%{_bindir}/easydialog
 %{_datadir}/%{name}/
-%{_libexecdir}/%{name}/
+%{_prefix}/lib/%{name}/
 %{_mandir}/man1/%{name}.1*
+%{_docdir}/%{name}/
 
 
 %changelog

La partie %changelog

Ah tiens, plus haut j'ai omis de préciser... que toutes nos modifications doivent être consciencieusement consignées dans le Changelog du paquet. Alors pas la peine d'écrire un roman, il faut être bref et précis. En voici un exemple:

--- easybashgui.spec.orig       2014-01-21 01:10:16.772114046 +0100
+++ easybashgui.spec    2014-01-21 01:16:30.220338188 +0100
@@ -58,6 +58,10 @@ make install DESTDIR=%{buildroot}
 %changelog
 * Mon Jan 20 2014 Matthieu Saulnier <fantom@
xxxxxxxxxxxxxxx> - 10.0.0-1
 - Update to 10.0.0
+- Use makefile instead of scriplet in %%install section
+- Remove sed statement in %%prep section
+- Remove %%doc macro in %%files section
+- Update %%files section according the makefile
 
 * Tue Aug 06 2013 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxx> - 8.0.1-1
 - Update to 8.0.1

Vous aurez remarqué que dans le changelog j'ajoute un « % » avant chaque nom de section, c'est juste pour que ces macros ne soit pas interprétées au moment de la construction du paquet. Alors ça y est, nous allons enfin pourvoir le construire ce paquet. Mais avant...

Enregistrement des modifications du GIT

N'oublions pas que nous sommes encore dans notre petit dépôt GIT et que toutes les modifications que nous venons d'apporter n'ont pas encore d'identifiant d'enregistrement. Mais avant il faut encore ajouter l'archive source aux fichiers « sources » (c'est comme ça qu'il s'appelle) et « .gitignore » du dépôt. L'archive sera également mise en ligne en une seule passe.

casper@blackbird:~/fedora-scm/easybashgui$ fedpkg new-sources easybashgui-10.0.0-ad4222f.tar.gz

Et enfin on enregistre les changements, en ajoutant un message expliquant sommairement ces modifications:

casper@blackbird:~/fedora-scm/easybashgui$ fedpkg commit -m "Update to 10.0.0 version"

Cet enregistrement n'est présent que sur notre disque dur, il faut donc synchroniser notre dépôt local avec le dépôt en ligne. Pour cela on dit qu'on « pousse » les modifications, d'où la commande suivante:

casper@blackbird:~/fedora-scm/easybashgui$ fedpkg push

Construction du paquet pour Rawhide

Maintenant nos modifications sont mises en ligne, nous pouvons construire le paquet contenant la dernière version du logiciel, mais seulement pour la branche Rawhide. Explication. Tout ce que nous venons de faire était dans la branche "master" du GIT, cette branche est la première branche à être modifiée, et elle correspond à la branche en évolution permanante de Fedora, c'est à dire Rawhide. Si tout se passe bien dans cette branche, alors on peut copier les changement dans les branches plus anciennes telles que f20 puis f19.

casper@blackbird:~/fedora-scm/easybashgui$ fedpkg build --nowait
Building easybashgui-10.0.0-1.fc21 for rawhide
Created task: 6432471
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6432471

Si le build a réussi, alors cette version du paquet sera présente d'office dans f21, f22, etc... jusqu'à ce que l'on remette à jour la branche master.

Faire une update pour f20

Si les changements du logiciel n'influancent pas de façon majeure l'expérience utilisateur et développeur d'une version de Fedora, alors nous pouvons produire une mise à jour pour cette version. Il faut que la version soit tout de même en court de support par le Projet, en l'occurence f20 et f19. Commençons par changer de branche dans notre dépôt local:

casper@blackbird:~/fedora-scm/easybashgui$ fedpkg switch-branch f20

Puis on applique les changements fait dans la branche master aux fichiers de la branche f20, heureusement pour nous tout cela est fait automatiquement avec une seule commande:

casper@blackbird:~/fedora-scm/easybashgui$ git merge master

On n'oublie pas de synchroniser cette branche de notre dépôt local avec la branche du dépôt en ligne:

casper@blackbird:~/fedora-scm/easybashgui$ fedpkg push

Et on peut enfin construire notre paquet. Cette branche n'étant pas une branche de test, les échecs de constructions sont plutôt rares, pour ma part c'était à chaque fois parce que j'avais poussé un peu précipitament les changements de master avant que sa reconstruction du paquet ne soit terminée.

casper@blackbird:~/fedora-scm/easybashgui$ fedpkg build --nowait
Building easybashgui-10.0.0-1.fc20 for f20-candidate
Created task: 6436984
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6436984

Lorsque ce paquet sera construit, il sera taggé en tant que paquet candidat de mise à jour, ce qui signifie qu'il ne sera poussé dans aucun dépôt (updates-testing, updates) avant que je ne le déclare apte. Typiquement je dois remplir un petit descriptif qui permettra aux utilisateurs de connaître la nature de cette mise à jour (sécurité, avancement, etc..), les bugs qu'il corrige, et c'est ce formulaire assigné au paquet qui permettra aux testeurs de lui donner une note et un commentaire. C'est également cette étiquette qui permet de suivre la progression du paquet dans les différents dépôts (updates-testing, puis updates).

casper@blackbird:~/fedora-scm/easybashgui$ fedpkg update
Creating a new update for  easybashgui-10.0.0-1.fc20
Password for fantom:
Creating a new update for  easybashgui-10.0.0-1.fc20
Update successfully created
================================================================================
     easybashgui-10.0.0-1.fc20
================================================================================
    Release: Fedora 20
     Status: pending
       Type: enhancement
      Karma: 0
    Request: testing
      Notes: Update to 10.0.0
  Submitter: fantom
  Submitted: 2014-01-21 23:09:01
   Comments: bodhi - 2014-01-21 23:09:04 (karma 0)
             This update has been submitted for testing by fantom.

  https://admin.fedoraproject.org/updates/easybashgui-10.0.0-1.fc20

Après cette opération, le paquet est taggé en tant que paquet de mise à jour en attente. En attente avant d'effectivement intègrer le dépôt updates-testing, il y sera poussé sous 24/48h environ. Ce délai est nécessaire pour laisser le temps à la personne en charge de la clé de signature GPG du Projet Fedora d'aposer la signature sur ce paquet. D'ici 7 jours, si la mise à jour ne reçoit aucune note négative, je la pousserais dans le dépôt updates comme le veut le règlement des mises à jour de Fedora.

Et pour f19 ?

Renouveler l'opération pour f20 en adaptant :-D


Paquet linux_logo customisé

Matthieu Saulnier L'autre jour (bon d'accord il y a plus d'un mois) je regardais le film Iron Man 2 où j'ai vu que le système d'exploitation Stark possèdait son logo en ascii art (vous savez la scène du procès où Tony pirate les écrans du tribunal avec son smartphone...) et ça m'a rendu un peu jaloux de voir la réalité passer pour de la science-fiction. Alors je me suis souvenu qu'un petit paquet fournit déjà ce genre de gadget ô combien indispensable, linux_logo est un petit programme qui permet d'afficher des logos de distributions linux dans le terminal. Seulement voilà, il ne fournit aucun logo pour Fedora. D'autres avant moi on eu l'idée d'ajouter le logo fedora via le fichier de configuration du programme, mais j'ai préféré effectuer cet ajout en amont, directement dans le rpm source. Cette solution est plus facile à distribuer, non seulement entre mes divers pc, mais aussi peut-être pour vous cher lecteur.

Le mode d'utilisation reste inchangé:
$ linux_logo -L list | grep -i fedora
        11      Classic Yes     fedora          Fedora Logo
        12      Banner  Yes     fedora          Fedora Banner
        13      Banner  Yes     fedora          Fedora Banner (little)



On peut aussi personnaliser le message en texte blanc sous la bannière :
linux_logo -L 12 -F "Bienvenue sur l'hôte #H\n#V, Compilé #C \n#P #X #T, #R, #U"

linux_logo_fedora
Une fois la commande ajoutée dans le bashrc, l'ouverture de terminaux (avec un raccourci clavier bien sûr) devient du plus bel effet :-)
Les rpms et rpms source sont disponible dans mon petit Entrepôt.

Surveiller la sortie d'une nouvelle version de Fedora

Matthieu Saulnier Comme vous le savez déjà, la version alpha de Fedora 19 ne va pas tarder à être disponible au téléchargement par Bittorrent. J'ai donc mis au point un tout petit script bash chargé de surveiller à ma place la présence des fichiers torrent correspondants sur http://torrents.fedoraproject.org/ . Ce petit script doit donc poller tous les jours les URLs des fichiers, mais aussi s'arrêter tout seul une fois les bons fichiers téléchargés. Il n'y a rien d'extraordinaire là-dedans, mis à part que j'ai rendu ce script un peu plus « smart » en le rendant opérationnel pour toutes les futures nouvelles versions. Mais bon, télécharger des fichiers, ce n'est pas suffisant, puisque je devrais les lancer dans transmission moi-même. Non, là où celà devient intéréssant c'est que les fichiers torrent seront ajoutés automatiquement à Transmission Daemon, qui démarrera les téléchargements des ISOs. C'est hélas encore insuffisant, puisqu'en 24 mois de fonctionnement le script va très rapidement saturer /var/lib/transmission. J'ai donc ajouté une suppression automatique des torrents Fedora âgés de plus d'un an, ce qui devrait stabiliser le remplissage de /var/lib/transmission à 100Gio. Il va sans dire que je recommande vivement de faire un volume logique LVM à part pour /var/lib/transmission.

Maintenant que les fonctionnalités sont détaillées, voyons un peu comment ça marche. En fait le script est placé dans /etc/cron.daily pour le polling journalier, et surtout reste synchronisé avec le cycle de développement de Fedora. Il s'appuie sur deux petits fichiers pour fonctionner correctement :
/var/lib/transmission/currentversion.txt
/var/lib/transmission/versionstatus.txt
Concrètement, currentversion.txt contient le numéro de la dernière version sortie (à l'heure actuelle "18"), et versionstatus.txt contient le status de ce numéro de version (à l'heure actuelle "stable"), puisqu'au moment où j'écris ces lignes Fedora 18 stable est la dernière version sortie de Fedora, Fedora 19 alpha n'étant pas encore sortie. Ces deux fichiers vont donc indiquer au script de rechercher une potentielle Fedora 19 alpha, et s'il ne trouve pas, recommencera demain. S'il la trouve, il télécharge les torrents, les ajoute dans Transmission Daemon, puis écrit "alpha" dans versionstatus.txt. Pourquoi n'écrit-il pas '19' dans currentversion.txt ? Parce que ces fichiers sont renseignés non pas pour l'utilisateur, mais pour le fonctionnement du script, mais ne vous inquietez pas, il y a une logique derriière tout ça. Reprenons, le script a récupéré F19 alpha et a édité son fichier, maintenant il va poller tous les jours pour récupérer F19 bêta. S'il ne trouve pas F19 bêta il réessayera demain, s'il la trouve, il récupère les torrent, les ajoute, puis édite ses fichiers. Et il écrit "beta" dans versionstatus.txt. Puis le script recommence à chercher, cette fois Fedora 19 stable. S'il trouve rien, il recommencera demain, et s'il la trouve, il écrira '19' dans currentversion.txt et 'stable' dans versionstatus.txt. La boucle est bouclée, le script cherchera donc une potentielle Fedora 20 alpha, et continuera de fonctionner ainsi à l'infini. L'explication sur le fait que les deux fichiers ne reflètent pas la vraie situation du cycle de développement de Fedora est toute simple : le script incrémente la valeur de currentversion.txt dans tous les cas, car il ne peut pas savoir dans quels cas incrémenter ou non. (Il y a moyen d'implémenter facilement cette fonctionnalité, mais vu que ce sont des fichiers dédiés au fonctionnement du script et non à l'utilisateur...) Pour ce qui est de la suppression des torrents Fedora d'un an d'ancienneté, la vérification à lieu à chaque exécution du script, soit tous les jours également, donc pas de stress à ce niveau là.

Si vous avez envie d'être les premiers à seeder Fedora,
Si vous avez un LV de plus de 100Gio pour /var/lib/transmission dans votre fstab,
Alors vous pouvez installer le RPM :
Le SRPM est bien évidemment dispo :
Pour finir, assurez-vous que les services systemd crond et transmission-daemon sont bien lancés, puis laissez rouler...

PackageDB-cli 1.1.0

Pierre-Yves Chibon

rpm.pngsource.png

Version 1.1.0 du client text pour pkgdb.

Release 1.1.0 of the command-line interface for pkgdb.

English version (no French)

I have pushed to testing few days ago a new version of packagedb-cli (aka pkgdb-cli).

With this new version:

  • You can adopt an orphaned package
  • The user name if not specified can be retrieved from the fedora_cert file (if presents)
  • If the package is orphaned, it is now highlighted
  • Approve all the request for someone but only the requested ACLs (not all ACLs)

There has also been some bugs fixed thanks to sochotni and ppisar who reported them on the trac.

Feel free to test and comment the updates:

PackageDB-cli 1.0.0

Pierre-Yves Chibon

rpm.pngsource.png

Version 1.0.0 du client text pour pkgdb.

Release 1.0.0 of the command-line interface for pkgdb.

English version (no French)

This morning has just been reviewed and approved the rpm for packagedb-cli (Thanks Elad!).

I am waiting for the SCM to be validated and I will upload and build this first release.


I am looking forward to hear your suggestions, comments and bug reports on the trac of the project



PS: If you rebuild the src.rpm from the review, I was pointed out that the USAGE in --help is not quite accurate, this is already fixed in git and will fixed at import.

Dependency graph

Pierre-Yves Chibon

source.png

A small script to generate the dependency graph from spec file

Un petit script pour générer le graph des dépendances à partir de fichier spec

English version

I maintain some R packages which have a quite nice dependency graph. Every time I fight to find back the order in which I should build them. So yesterday I started a small script which would give me the dependencies in a graph so that I could see the information I am looking for.

I came up with a small python script relying on pydot.

The last version is available there: http://project.pingoured.fr/misc/file/12447ca38f25/generateDependencyList.py

You run it as:

$ python generateDependencyList.py -f ~/GIT/
dependencygraph.svg has been generated

The output can look like this dependencygraph.png or dependencygraph-2.png (These pictures has been converted from svg to png and reduced)

sochotni pointed out that it actually does a similar job than rpmorphan, too bad, it was fun to do :-)

R2spec/R2rpm 3.0.0

Pierre-Yves Chibon

rpm.pngsource.png

New release of R2spec

Nouvelle version de R2spec

English version

This time it is there, the new release of R2spec is on its way and I have to say it brings a huge bunch of new features!

R2spec now comes with a new flavour, R2rpm which allows you to generate directly rpm from the R libraries.

Since I already announced it I won't spend to much time on it.

Check the changelog at the bottom for all the info !

I would like to thanks José Matos and Allen S. Rout for their help to build and improve this release.



French version

Et voila, une nouvelle version de R2spec est dans les tuyaux et je dois dire qu'elle amène tout un tas de nouveautés.

R2spec vous apporte maintenant un nouvel outil, R2rpm qui comme son nom l'indique permet de construire directement un rpm pour une bibliothèque R.

Bon comme je l'ai déjà annoncé je ne vais pas trop m'attarder là-dessus.

Regardez donc le changelog ci-dessous pour toutes les infos !

Je voudrais aussi remercier José Matos et Allen S. Rout pour leur aide dans la construction et l'amélioration de cette release.


Version 3.0.0 -- 05th May 2019
- Features added
  * R2spec can now be called from an external script
  * Use template via jinja2 to generate the spec files (Based on an idea of Allen S. Rout)
  * Create the R2rpm script which directly builds the rpm
  * Add a man page for R2rpm
  * Add the -p option which enable to build a spec from a package name
  * Parse the PACKAGES file from the repositories to find the information for the packages
  * Make the print of the TODO optional in the API
  * Give the opportunity to use mock to build the RPMs (rpmbuild being the default)
  * Enable to specify the mock command in the conf file
  * Enable to change the argument given to rpmbuild via the conf file 
      (to build srpm instead of rpm for example)
- Bugs correction
  * Fix the addition of the R- prefix to the dependencies
  * Rewrite the reading of the DESCRIPTION file from R
  * Do not enforce the spec and the source directory, reads the rpmmacros instead
     Thanks to José Matos for this function
  * Fix the summary if it ends with a dot "."
  * Capitalize the summary by default
  * Change UTF-8 to utf-8 to make emacs happy
  * Fix the spec file for the dependencies of this new release
  * Fix some bugs while trying to generate the RPM/SPEC from a tarball

R2rpm on cran

Pierre-Yves Chibon

Building cran RPM via R2rpm

Construire des RPMs du cran avec R2rpm

English format

Using the PACKAGES file from the CRAN I was able to generate a list of 670 packages that do not depend on anything else than R.

This morning I ran R2rpm on the first 100, it took around 3h and there are the results:

89 packages built
['ADGofTest', 'AMORE', 'AlgDesign', 'Animal', 'BGSIMD', 'BMN', 'BPHO', 'BayesValidate', 'Bhat', 'BiasedUrn', 'Biodem', 'Bolstad', 'Bolstad2', 'BootCL', 'CAVIAR', 'CCP', 'CDFt', 'CHsharp', 'CORElearn', 'CTT', 'ClinicalRobustPriors', 
'ComPairWise', 'CompetingRiskFrailty', 'ConvCalendar', 'CreditMetrics', 'CvM2SL1Test', 'CvM2SL2Test', 'DEA', 'DEMEtics', 'DEoptim', 'DTDA', 'DTK', 'Davies', 'Defaults', 'DiversitySampler', 'EMJumpDiffusion', 'EbayesThresh', 
'ElectroGraph', 'ExPD2D', 'FBN', 'FITSio', 'FKBL', 'FNN', 'Flury', 'GPArotation', 'GWRM', 'GeneF', 'GillespieSSA', 'HAPim', 'HI', 'HMM', 'HMR', 'ISOcodes', 'Imap', 'Iso', 'JADE', 'JudgeIt', 'Kendall', 'LDtests', 'LIStest', 'LearnBayes', 
'LearnEDA', 'LogitNet', 'LowRankQP', 'MAMSE', 'MCE', 'MKLE', 'MLDA', 'MLEcens', 'MMG', 'MMIX', 'MPV', 'MSVAR', 'MTSKNN', 'ModelGood', 'Multiclasstesting', 'NMFN', 'NORMT3', 'OPE', 'ORIClust', 'ORMDR', 'Oarray', 'OrdMonReg', 
'PBSddesolve', 'PLIS', 'POT', 'PSAgraphics', 'Peaks', 'PearsonICA']

11 packages failed
['BioStatR', 'BoSSA', 'BradleyTerry', 'BradleyTerry2', 'CPE', 'Cairo', 'FracSim', 'GDD', 'KFAS', 'MImix', 'OAIHarvester']

Damn this is good ! :-)

R2spec / R2rpm

Pierre-Yves Chibon

rpm.pngsource.png

New version of R2spec in the pipes

Une nouvelle version de R2spec dans les tuyaux

English version

There is a new version of R2spec in the pipes, this version fixes some bugs and introduces some new features. The main of these features is the presence of R2rpm now.

R2rpm generate the complete rpm directly from a url, the sources or simply the name of the package. It builds the package twice, once to determine the %file section and once to generate the RPM.

I fixed the length of the %description so that it is not bigger than the mandatory 75 characters, the summary is also corrected if it ends with a dot.

Tonight I have been playing with this new version, I was able to generate in the fly a bit more than 70 RPMs for R libraries in just few minutes (ok maybe it tooks a couple of hours :-)).

All the RPMs work, there are not rpmlint compliant so there would need more work if we want to integrate them into the repository but it is a good basis.

Something that I still want to do before to release officially the version 3.0.0 is the possibility to build the dependencies of a given package. Basically, this would allow to build RPM for one package and all the packages of which it depends.

For those who would like to test you can find the source, srpm and rpm in https://fedorahosted.org/releases/r/2/r2spec/ (latest release so far 3.0.0-0.4).

Do not hesitate to test it and report any issue you find in it :-)

Hope you like it !

Guake 0.4.1 - 2

Pierre-Yves Chibon

English version

Quickly, I have rebuilt Guake 0.4.1 to include the french translation.

The builds can be found:
https://admin.fedoraproject.org/updates/guake-0.4.1-2.fc12
https://admin.fedoraproject.org/updates/guake-0.4.1-2.fc11



French version

J'ai inclus la traduction français de Guake dans une mise à jour du RPM.

La mise à jour est en attente de testing :
https://admin.fedoraproject.org/updates/guake-0.4.1-2.fc12
https://admin.fedoraproject.org/updates/guake-0.4.1-2.fc11

Guake 0.4.1

Pierre-Yves Chibon

Guake 0.4.1 is released !

La version 0.4.1 de Guake est sortie !

English version

Guake 0.4.1 has been released, has been built and is pending for the testing repository. For reference, Guake is a top-down terminal in the same style than Tilda, Yakuake or the consol in the game quake. It is made for Gnome

Among the new feature we have quite a number of new locales available, the switch to Transifex really helped us on that ! A certain amount of bugs are also fixed in this release.

The new release is called: "I was just joking" (you'll have to go through the archive of the mailing-list to get that one ;-)).

I hope you will enjoy this new version

If you test it, don't forget to comment on bodhi ;-)



French version

Guake 0.4.1 est sorti, compilé et en attente pour le dépôt updates-testing. Pour rappel Guake est un terminal de type top-down qui s'affiche en haut de l'écran à la façon de Tilda, de Yakuake ou de la console de quake (le jeu ;-)), il est prévu pour Gnome.

Parmi les nouveautés on notera un plus grand nombre de traductions disponibles, le passage à Transifex nous ayant bien aidé pour ça. Un certain nombre de bogues sont aussi corrigés dans cette version

Cette nouvelle version est appelée "I was just joking" (il vous faudra aller dans les archives de la liste de diffusion pour la comprendre celle-la ;-) ).

J'espère que vous aimerez cette nouvelle version.

Pour les testeurs n'oubliez pas de mettre un mot sur bodhi ;-)



changes since 0.4.0:

Updated translation and new translation:

 * Italian
 * French
 * Portuguese/Brazilian
 * Novergian
 * German
 * Polish
 * Greek
 * Hungarian

Bugs/Features:

 * Change start message #168
 * Add an option to the preference windows to create new tab in cwd #146
 * Preferences windows are resizable #149
 * Guake's windows not shown when ran for the first time #174
 * Implement dbus interface to script with guake #150, #138, #105, #126, #128, #109
 * Command line arguments implemented
   -n create a new tab
   -e execute a command on a defined tab
   -r rename a tab
   -t toggle visibility
 * Improve regex to use character classes (improve the support of certain locales) #156
 * Ask user if he really wants to quit when there is a child process #158
 * Double click on a tab allows you to rename the tab #165
 * Add more information on the INSTALL file 
 * Tray icon position fixed #161

Infrastructure:

 * Move from guake-terminal.org to guake.org
 * Set up a mailing-list at: http://lists.guake.org/cgi-bin/mailman/listinfo/guake

makeBuild.py

Pierre-Yves Chibon

source.png

A small script to automate the build in different branch

Un petit script pour faire le build de rpm dans différentes branches.

English version

For some time now, I am using a small script to run the make tag and make build in the different branch when I update one of my packages

With that all I do is

  • Update the devel branch (source and spec)
  • run make x86_64
  • Eventually run a make tag build for devel to test it if it buils fine in rawhide
  • Copy the source and spec files to the other branch
  • commit
  • run the script adapted as needed

It works smoothly and save time when I have to update several packages :-)

(Logic and sources below)


French version

J'utilise depuis quelque temps un petit script python tout simple qui me fais make tag, et make build dans les différentes branches et pour plusieur paquets s'il faut.

Grâce à ce script lorsque je fais une mise à jour, je fais:

  • Mise à jour la branche devel (fichier spec et sources)
  • make x86_64 pour vérifier que ça se construit bien
  • Parfois je fais un make tag build dans devel pour vérifier qu'il n'y a pas de problèmes en rawhide
  • Copie des fichiers sources et .spec dans les autres branches du cvs
  • Commit
  • J'adapte puis fais marcher le script

Il marche tranquilement et me fais gagner du temps lorsque j'ai tout une série de paquets à construire.

(Logique et fichier ci-dessous)



#!/usr/bin/python
#-*- coding: utf-8 -*-
 
#
# For each package in packagelist
#   do
#     cvs co package
#     cd package
#     for each branch in branchlist
#       do
#         cd version
#         make tag
#         BUILD_FLAGS="--nowait" make build
#
 
 
import os
 
cvsfolder = '/home/pingou/CVS'
packagelist = ['R-hgu95av2probe', 'guake', 'R-pls']
branchlist = ['devel', 'F-11', 'F-10']
#branchlist = ['F-11', 'F-10']
 
for package in packagelist:
        os.chdir(cvsfolder)
        print '*'*50
        print '%s/%s' %(packagelist.index(package) + 1,len(packagelist)), ' '*10, package
        print '*'*50
        print 'cvs co %s' %package
        os.system('cvs co %s' %package)
        os.chdir('%s/%s' %(cvsfolder, package))
        for branch in branchlist:
                print '\n *** ', branch
                os.chdir('%s/%s/%s' %(cvsfolder, package, branch))
                print 'make tag'
                os.system('make tag')
                print 'BUILD_FLAGS="--nowait" make build'
                os.system('BUILD_FLAGS="--nowait" make build')

makeBuild.py

makeBuild.py

Pierre-Yves Chibon

source.png

A small script to automate the build in different branch

Un petit script pour faire le build de rpm dans différentes branches.

English version

For some time now, I am using a small script to run the make tag and make build in the different branch when I update one of my packages

With that all I do is

  • Update the devel branch (source and spec)
  • run make x86_64
  • Eventually run a make tag build for devel to test it if it buils fine in rawhide
  • Copy the source and spec files to the other branch
  • commit
  • run the script adapted as needed

It works smoothly and save time when I have to update several packages :-)

(Logic and sources below)


French version

J'utilise depuis quelque temps un petit script python tout simple qui me fais make tag, et make build dans les différentes branches et pour plusieur paquets s'il faut.

Grâce à ce script lorsque je fais une mise à jour, je fais:

  • Mise à jour la branche devel (fichier spec et sources)
  • make x86_64 pour vérifier que ça se construit bien
  • Parfois je fais un make tag build dans devel pour vérifier qu'il n'y a pas de problèmes en rawhide
  • Copie des fichiers sources et .spec dans les autres branches du cvs
  • Commit
  • J'adapte puis fais marcher le script

Il marche tranquilement et me fais gagner du temps lorsque j'ai tout une série de paquets à construire.

(Logique et fichier ci-dessous)



#!/usr/bin/python
#-*- coding: utf-8 -*-
 
#
# For each package in packagelist
#   do
#     cvs co package
#     cd package
#     for each branch in branchlist
#       do
#         cd version
#         make tag
#         BUILD_FLAGS="--nowait" make build
#
 
 
import os
 
cvsfolder = '/home/pingou/CVS'
packagelist = ['R-hgu95av2probe', 'guake', 'R-pls']
branchlist = ['devel', 'F-11', 'F-10']
#branchlist = ['F-11', 'F-10']
 
for package in packagelist:
        os.chdir(cvsfolder)
        print '*'*50
        print '%s/%s' %(packagelist.index(package) + 1,len(packagelist)), ' '*10, package
        print '*'*50
        print 'cvs co %s' %package
        os.system('cvs co %s' %package)
        os.chdir('%s/%s' %(cvsfolder, package))
        for branch in branchlist:
                print '
 *** ', branch
                os.chdir('%s/%s/%s' %(cvsfolder, package, branch))
                print 'make tag'
                os.system('make tag')
                print 'BUILD_FLAGS="--nowait" make build'
                os.system('BUILD_FLAGS="--nowait" make build')

makeBuild.py

Guake 0.4.0 is released

Pierre-Yves Chibon

English version

The latest version of guake (0.4.0) released yesterday has been built and is pending for the testing repository. For reference, Guake is a top-down terminal in the same style than Tilda, Yakuake or the consol in the game quake. It is made for Gnome

The amount of feature and bug correction is quite nice for this release (see the list at the bottom).

I would like to thanks Lincoln and Aleksandar (aka SnapShot) for the great work they have been doing ! :-)

The new release is called: "Frequency response" (the naming process is quite simple in fact... go to wikipedia and click to see a random page :-D ).

I hope you will enjoy this new version

If you test it, don't forget to comment on bodhi ;-)



French version

La nouvelle version de Guake (0.4.0) est compilé et en attente d'atteindre le dépôt updates-testing. Pour rappel Guake est un terminal de type top-down qui s'affiche en haut de l'écran à la façons de Tilda, de Yakuake ou de la console de quake (le jeu ;-)), il est prévut pour Gnome.

La liste de nouveautées pour cette nouvelle version est plutôt sympatique et je dois avouer que Guake 0.4.0 a vraiment bien évolué depuis sa dernière version (voir la liste ci-dessous).

Pour tout le travail accomplis je souhaite remercier Lincoln et Aleksandar (aka SnapShot) qui ont vraiment fais un boulot magnifique ! :-)

Au fait, cette nouvelle version est appelée "Frequency response" (le choix du nom fut assez facile: aller sur wikipedia et prendre le nom d'une page aléatoire :-D)

J'espère que vous aimerai cette nouvelle version.

Pour les testeurs n'oubliez pas de mettre un mot sur bodhi ;-)



* Font Bold are fixed
* New behavior with url (can copy without select)
* German translation
* Capacity to directly go to the preference windows (in both command line and through the menu)
* Correct the acquisition of the shortcut
* Resize the length of the window on the fly
* Start pop-up can be desactivated
* Trail icon is optionnal
* Tab ordering is fixed (or should be) New release from the git repo:
* Correct the acquisition of the shortcut
* Resize the length of the window on the fly
* Start pop-up can be desactivated
* Trail icon is optionnal
* Tab ordering is fixed
* Size of the bottom bar is smaller
* Enhance support for dual screen
* Improve support of the different shell

Guake 0.4.0 is released

Pierre-Yves Chibon

English version

The latest version of guake (0.4.0) released yesterday has been built and is pending for the testing repository. For reference, Guake is a top-down terminal in the same style than Tilda, Yakuake or the consol in the game quake. It is made for Gnome

The amount of feature and bug correction is quite nice for this release (see the list at the bottom).

I would like to thanks Lincoln and Aleksandar (aka SnapShot) for the great work they have been doing ! :-)

The new release is called: "Frequency response" (the naming process is quite simple in fact... go to wikipedia and click to see a random page :-D ).

I hope you will enjoy this new version

If you test it, don't forget to comment on bodhi ;-)



French version

La nouvelle version de Guake (0.4.0) est compilé et en attente d'atteindre le dépôt updates-testing. Pour rappel Guake est un terminal de type top-down qui s'affiche en haut de l'écran à la façons de Tilda, de Yakuake ou de la console de quake (le jeu ;-)), il est prévut pour Gnome.

La liste de nouveautées pour cette nouvelle version est plutôt sympatique et je dois avouer que Guake 0.4.0 a vraiment bien évolué depuis sa dernière version (voir la liste ci-dessous).

Pour tout le travail accomplis je souhaite remercier Lincoln et Aleksandar (aka SnapShot) qui ont vraiment fais un boulot magnifique ! :-)

Au fait, cette nouvelle version est appelée "Frequency response" (le choix du nom fut assez facile: aller sur wikipedia et prendre le nom d'une page aléatoire :-D)

J'espère que vous aimerai cette nouvelle version.

Pour les testeurs n'oubliez pas de mettre un mot sur bodhi ;-)



* Real transparency
* Font Bold are fixed
* New behavior with url (can copy without select)
* German translation
* Capacity to directly go to the preference windows (in both command line and through the menu)
* Correct the acquisition of the shortcut
* Resize the length of the window on the fly
* Start pop-up can be desactivated
* Trail icon is optionnal
* Tab ordering is fixed (or should be) New release from the git repo:
* Size of the bottom bar is smaller
* Enhance support for dual screen
* Improve support of the different shell

Guake Git version

Pierre-Yves Chibon

New release of Guake from the git repo

Nouvelle version de Guake issue du repo Git

English version (French below)

A new version of Guake has arrived in the updates-testing repo. The release based on the git version of February 10th.

There is a short list (probably incomplete) of the new feature and bugs corrected:

  • Correct the acquisition of the shortcut
  • Resize the length of the window on the fly
  • Start pop-up can be desactivated
  • Trail icon is optionnal
  • Tab ordering is fixed (or should be)

To test:

yum update --enablerepo=updates-testing guake

Be aware that this version is still under development so there are still some bugs remaining ;-) (It is also the reason why this release will stay in updates-testing)



French version

Une nouvelle version de Guake est arrivé dans le dépôt updates-testing. Cette version est basé sur le dépôt git du 10 février.

Voici une liste rapide et surement incomplête des nouvelles fonctionnalités et des bogues corrigés:

  • Correction de l'acquisition des raccourcis clavier
  • Possibilité de régler la hauteur de la fenêtre directement
  • Possibilité de désactiver le pop-up de notification au démarrage
  • L'icone de barre des taches est maintenant optionnelle
  • Le problème dans l'agencement des tabs est résolue (enfin devrai :p)

Pour tester:

yum update --enablerepo=updates-testing guake

Soyez avertis que cette version est toujours en dévelopement et donc que tous les bugs ne sont pas encore corrigés ;-) (Raison pour laquelle cette version va rester dans updates-testing

Guake Git version

Pierre-Yves Chibon

New release of Guake from the git repo

Nouvelle version de Guake issue du repo Git

English version (French below)

A new version of Guake has arrived in the updates-testing repo. The release based on the git version of February 10th.

There is a short list (probably incomplete) of the new feature and bugs corrected:

  • Correct the acquisition of the shortcut
  • Resize the length of the window on the fly
  • Start pop-up can be desactivated
  • Trail icon is optionnal
  • Tab ordering is fixed (or should be)

To test:

yum update --enablerepo=updates-testing guake

Be aware that this version is still under development so there are still some bugs remaining ;-) (It is also the reason why this release will stay in updates-testing)



French version

Une nouvelle version de Guake est arrivé dans le dépôt updates-testing. Cette version est basé sur le dépôt git du 10 février.

Voici une liste rapide et surement incomplête des nouvelles fonctionnalités et des bogues corrigés:

  • Correction de l'acquisition des raccourcis clavier
  • Possibilité de régler la hauteur de la fenêtre directement
  • Possibilité de désactiver le pop-up de notification au démarrage
  • L'icone de barre des taches est maintenant optionnelle
  • Le problème dans l'agencement des tabs est résolue (enfin devrai :p)

Pour tester:

yum update --enablerepo=updates-testing guake

Soyez avertis que cette version est toujours en dévelopement et donc que tous les bugs ne sont pas encore corrigés ;-) (Raison pour laquelle cette version va rester dans updates-testing

R2spec_2.2

Pierre-Yves Chibon

rpm.pngsource.png

Small typo correction

Quelques corrections et mise en forme

English version (Français ci-dessous)

Thanks to the remarks made by juba I have made some corrections on the code (mainly some indentation problems).

I also have change a bit the layout of the man page for a nicer one (I would like to point out this Create a man page, that help me to achieve this).

I have been asked the question: What is the interest in comparison to the normal R installation management system ? and I would like to say few words about it.

Here below are the advantages that come to my mind while replying to this question on IRC (#R on irc.freenode.net):

  • Availibility via yum
  • File in the correct part of the filesystem
  • Quality of the files checked (UTF8 - end of line of Windows...)
  • Correct dependencies management since the R guidelines says that R CMD check should be ran for each package, and R CMD check checks for all the dependencies (requires and suggests)
  • Better update system

At the end, I think making RPMs of the R libraries is really interesting for the end users or the system administrator who has an easy way to install and update the libraries of their choice.

Just my though...

Help yourself:



French version Grâce aux judicieuses remarques de juba j'ai corrigé quelques erreurs dans le code (principalement des problèmes d'indentation due aux différents éditeurs utilisé)

J'ai aussi changé un peu la page man pour la rendre plus jolie. À noter cette page Crée une page man qui m'a bien aidé dans cette entreprise.

On m'a aussi posé la question Quel est l'intérêt de ce système par rapport au système d'installation classique des bibliothèques de R ? je voudrais revenir là dessus.

Voici les quelques arguments qui me sont venus à l'esprit en répondant à cette question:

  • Disponibilité dans yum
  • Placement des fichiers dans les bons répertoire du système
  • Vérifications de la qualité des fichiers (encodage UTF8, retrait/substitution des fin de lignes de Windows...)
  • Bonne gestion des dépendances puisque les guidelines pour les RPMs R recommande l'utilisation systématique de la commande R CMD check qui vérifie la disponibilité de toutes les dépendances (requires et recommandées)
  • Meilleur moyen de mise à jour du système

Je pense qu'en fait faire des RPMs de bibliothèque R est vraiment intéressant pour les utilisateurs et les administrateurs système qui peuvent installer et mettre à jour sans problème et de façons très facile les bibliothèques de leur choix.

Enfin ce n'est que mon avis :)" class="smiley

Les classiques:

R2spec_2.2

Pierre-Yves Chibon

rpm.pngsource.png

Small typo correction

Quelques corrections et mise en forme

English version (Français ci-dessous)

Thanks to the remarks made by juba I have made some corrections on the code (mainly some indentation problems).

I also have change a bit the layout of the man page for a nicer one (I would like to point out this Create a man page, that help me to achieve this).

I have been asked the question: What is the interest in comparison to the normal R installation management system ? and I would like to say few words about it.

Here below are the advantages that come to my mind while replying to this question on IRC (#R on irc.freenode.net):

  • Availibility via yum
  • File in the correct part of the filesystem
  • Quality of the files checked (UTF8 - end of line of Windows...)
  • Correct dependencies management since the R guidelines says that R CMD check should be ran for each package, and R CMD check checks for all the dependencies (requires and suggests)
  • Better update system

At the end, I think making RPMs of the R libraries is really interesting for the end users or the system administrator who has an easy way to install and update the libraries of their choice.

Just my though...

Help yourself:



French version Grâce aux judicieuses remarques de juba j'ai corrigé quelques erreurs dans le code (principalement des problèmes d'indentation due aux différents éditeurs utilisé)

J'ai aussi changé un peu la page man pour la rendre plus jolie. À noter cette page Crée une page man qui m'a bien aidé dans cette entreprise.

On m'a aussi posé la question Quel est l'intérêt de ce système par rapport au système d'installation classique des bibliothèques de R ? je voudrais revenir là dessus.

Voici les quelques arguments qui me sont venus à l'esprit en répondant à cette question:

  • Disponibilité dans yum
  • Placement des fichiers dans les bons répertoire du système
  • Vérifications de la qualité des fichiers (encodage UTF8, retrait/substitution des fin de lignes de Windows...)
  • Bonne gestion des dépendances puisque les guidelines pour les RPMs R recommande l'utilisation systématique de la commande R CMD check qui vérifie la disponibilité de toutes les dépendances (requires et recommandées)
  • Meilleur moyen de mise à jour du système

Je pense qu'en fait faire des RPMs de bibliothèque R est vraiment intéressant pour les utilisateurs et les administrateurs système qui peuvent installer et mettre à jour sans problème et de façons très facile les bibliothèques de leur choix.

Enfin ce n'est que mon avis :)" class="smiley

Les classiques:

R2spec_2.2

Pierre-Yves Chibon

rpm.pngsource.png

Small typo correction

Quelques corrections et mise en forme

English version (Français ci-dessous)

Thanks to the remarks made by juba I have made some corrections on the code (mainly some indentation problems).

I also have change a bit the layout of the man page for a nicer one (I would like to point out this Create a man page, that help me to achieve this).

I have been asked the question: What is the interest in comparison to the normal R installation management system ? and I would like to say few words about it.

Here below are the advantages that come to my mind while replying to this question on IRC (#R on irc.freenode.net):

  • Availibility via yum
  • File in the correct part of the filesystem
  • Quality of the files checked (UTF8 - end of line of Windows...)
  • Correct dependencies management since the R guidelines says that R CMD check should be ran for each package, and R CMD check checks for all the dependencies (requires and suggests)
  • Better update system

At the end, I think making RPMs of the R libraries is really interesting for the end users or the system administrator who has an easy way to install and update the libraries of their choice.

Just my though...

Help yourself:



French version Grâce aux judicieuses remarques de juba j'ai corrigé quelques erreurs dans le code (principalement des problèmes d'indentation due aux différents éditeurs utilisé)

J'ai aussi changé un peu la page man pour la rendre plus jolie. À noter cette page Crée une page man qui m'a bien aidé dans cette entreprise.

On m'a aussi posé la question Quel est l'intérêt de ce système par rapport au système d'installation classique des bibliothèques de R ? je voudrais revenir là dessus.

Voici les quelques arguments qui me sont venus à l'esprit en répondant à cette question:

  • Disponibilité dans yum
  • Placement des fichiers dans les bons répertoire du système
  • Vérifications de la qualité des fichiers (encodage UTF8, retrait/substitution des fin de lignes de Windows...)
  • Bonne gestion des dépendances puisque les guidelines pour les RPMs R recommande l'utilisation systématique de la commande R CMD check qui vérifie la disponibilité de toutes les dépendances (requires et recommandées)
  • Meilleur moyen de mise à jour du système

Je pense qu'en fait faire des RPMs de bibliothèque R est vraiment intéressant pour les utilisateurs et les administrateurs système qui peuvent installer et mettre à jour sans problème et de façons très facile les bibliothèques de leur choix.

Enfin ce n'est que mon avis :)

Les classiques: