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.

mesa 10.2 from git for Fedora 20

Nicolas Chauvet

This has started as a attempt to test the improvements of the freedreno ARM driver, so I've made an updated mesa package (and newer libdrm) specially for testing.

You can grab it installing the kwizart-release repository and

yum update --enablerepo=kwizart-testing libdrm\* mesa\*

The updated mesa 10.2 package from git20140209 is available for i686 x86_64 and armv7hl. The final version is scheduled in 3 months from now (so it could be in Fedora 21 by default). This is a different branch from the 10.1 branch to be release soon.

I'm not interested in xorg-x11-drv-vmware in this case, and there is an ABI break behind, so

yum remove xorg-x11-drv-vmware

Also an interesting feature of the mesa 10.2 branch is the OpenMAX IL feature on AMD devices. I try to maintain libomxil-bellagio within fedora, so I'm interested in feedbacks on this topic. The AMD GPU I can test on doesn't seem to be compatible with the feature. But there are also probably few issues with libomxil-bellagio given the lack of upstream activity.

VLC from RPM Fusion should be compatible with OpenMAX IL, and gstreamer has a plugin that should enter into Fedora at some point (currently in review).

Also the packaging git work is currently ahead of the fedora rawhide spec, so there are probably few patches that can be used in the next fedora package.

Nouveau dépôt : remi-php56

Remi Collet

Les RPM pour Fedora ≥ 19 et  Enterprise Linux (RHEL, CentOS...) de PHP 5.6 et de ses extensions sont désormais disponibles dans le nouveau dépôt expérimental dédié : remi-php56.

Sur le modèle du dépôt remi-php55, je viens d'ouvrir un nouveau dépôt pour PHP 5.6.

Attention Attention ; il s'agit actuellement d'une version 5.6.0-dev, donc pour test, à ne pas utiliser en production. Les extensions pecl ne sont pas toutes encore disponibles.

Pour Enterprise Linux vous disposez désormais de 4 dépôts :

  • remi qui contient les paquets communs, PHP 5.4 et les extensions PHP qui ne dépendent pas de la version utilisée.
  • remi-php55 qui contient les paquets PHP 5.5 et les extensions
  • remi-php56 qui contient les paquets PHP 5.6 et les extensions
  • remi-test qui contient "vraiment" les paquets à tester.

Pour Fedora il s'agit d'un dépôt temporaire, lorsque le version 5.6 sera stable, ils rejoindront le dépôt remi.

Remarques :

  • Si vous activez remi-php56 vous devez aussi activer remi.
  • Les RPM des extensions C ont désormais un suffixe .remi.5.4 ou .remi.5.5 ou .remi.5.6.
  • Ce nouveau dépôt est défini dans la nouvelle version du paquet remi-release (version 5.10-1, 6.5-1, 19-2 ou 20-2).

J'espère ne rien avoir oublié, n'hésitez pas à me signaler le moindre problème sur le forum.

avril 2014

Premier Samedi Date : samedi 5 avril 2014 Horaires : de 14h00 à 18h00 Lieu : Carrefour Numérique, Cité des Sciences et de lIndustrie, Paris Pour une nouvelle installation ou pour des ajustements de votre distribution GNU/Linux Fedora, Mageia ou Ubuntu, venez nous retrouver le samedi 5 avril 2014 au Carrefour Numérique de la Cité des Sciences […]

GLPI version 0.84.5

Remi Collet

GLPI (Gestionnaire Libre de Parc Informatique) version 0.84.5 est publiée. Les RPM sont disponibles dans le dépôt remi pour Fedora ≥ 15 et EL ≥ 5.

Le dépôt remi-test est donc nettoyé, et pourra être utilisé pour la prochaine 0.85 (les beta-tests viennent de commencer).

Annonces des versions :

La documentation est disponible en PDF : glpidoc-0.84.3-fr.pdf

Cette version est aussi disponible dans les dépôts officiels de Fedora 20 (sans extension).

Actuellement dans le dépôt :

  • glpi-0.84.5-1
  • glpi-appliances-1.9.0-1
  • glpi-data-injection-2.3.0-1
  • glpi-behaviors-0.84.1-1
  • glpi-fusioninventory-0.84.0.2.0-1
  • glpi-ocsinventoryng-1.0.2-1
  • glpi-pdf-0.84-1
  • glpi-reports-1.7.2-1
  • glpi-webservices-1.4.1-1

Attention Attention: l'assistant d'installation est pour des raisons de sécurité uniquement accessible depuis le serveur sur lequel GLPI est installé. Voir le fichier de configuration (/etc/httpd/conf.d/glpi.conf) pour élargir temporairement cette autorisation si besoin.

Vous êtes invités à tester ces versions sur un environnement spécifique et à remonter vos questions, commentaires ou problèmes sur

Les RPM de GLPI et de quelques extensions ainsi cette page seront régulièrement mis à jour.

Advanced Intrusion Detection Environment (AIDE)

Matthieu Saulnier

Système de sécurité HIDS

AIDE est un système de détection de l'intègrité de l'hôte (HIDS: Host Integrity Detection System). La machine hôte contient un système de fichier qui permet de faire fonctionner le système d'exploitation. Les fichiers vitaux du système d'exploitation sont principalement la cible des attaques informatiques. L'intègrité d'une machine hôte est compromise si ses fichiers parvenaient à être modifiés par un moyen quelconque utilisé par un attaquant. AIDE est un logiciel qui permet de détecter si une intrusion a eu lieu, mais ne sert pas à empècher une intrusion. C'est un détecteur et non un système de réponse adaptée à une situation précise (logiciel de contre-mesure). Il permet donc d'avoir un rapport exhaustif sur l'intègrité du système d'exploitation. En fait ce logiciel indique juste quels fichiers ont été modifiés, créés, supprimés, en comparant ceux actuellement présent sur le système d'exploitation avec ceux d'une base de données initialisée par l'administrateur de la machine. Il est d'usage de créer cette base de données avant de raccorder la machine au réseau la rendant sujette au risque de compromission. Personnellement avant d'avoir découvert AIDE dans ce très bon guide, j'avais installé sur mon serveur un autre HIDS : Tripwire. Maintenant Tripwire et AIDE cohabitent sur la même machine, les HIDS ne font jamais de conflits entre-eux.

Installation sur Fedora 20

L'installation et la mise en route sont encore plus simple que pour Tripwire :

# yum install aide

Puis créer la base de données initiale contenant la liste des fichiers du système d'exploitation ainsi que leurs sommes de contrôle :

# aide --init

Cette commande prend du temps, prévoir un café pendant que ça tourne. Lorsque la commande aura rendu le prompt, la base de données écrite par AIDE sera toujours dans le fichier /var/lib/aide/aide.db.new.gz. La base de données utilisée pour effectuer le test d'intègrité sera toujours dans le fichier /var/lib/aide/aide.db.gz. Aussi avant de lancer les tests il convient de copier la base de données nouvellement créée au bon emplacement :

# scp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

AIDE et SELinux

Les deux fichiers qui viennent d'être créés n'ont pas les bons contextes SELinux.

# ll -Z /var/lib/aide/
-rw-------. root root unconfined_u:object_r:var_lib_t:s0 aide.db.gz
-rw-------. root root unconfined_u:object_r:var_lib_t:s0 aide.db.new.gz

Du coup si on lance les tests avec l'utilisateur root qui possède le contexte :

# id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Le processus ne sera pas cloisonné et donc ça marchera. Par contre, si on lance AIDE dans un Cron, alors le processus sera cloisonné et SELinux nous fera un joli refus d'accès AVC. Heureusement il y a un contexte prévus par défaut dans le module de règles targeted, au lieu d'appliquer de nouveaux contextes l'opération ressemble plutôt à une restauration des contextes initialement prévus par le module de règles :

# restorecon -vR /var/lib/aide/
restorecon reset /var/lib/aide/aide.db.gz context unconfined_u:object_r:var_lib_t:s0->unconfined_u:object_r:aide_db_t:s0
restorecon reset /var/lib/aide/aide.db.new.gz context unconfined_u:object_r:var_lib_t:s0->unconfined_u:object_r:aide_db_t:s0

La target prévue était aide_db_t, j'ignore encore pourquoi ce contexte n'a pas été appliqué dès la création des fichiers malgrès que le service restorecond soit actif. (Service systemd livré avec le paquet policycoreutils-restorecond qui n'est pas toujours installé par défaut).

Rapport journalier

On peut automatiser le contrôle d'intègrité dans un Cron affin de suivre l'évolution du système d'exploitation au jour le jour. Le rapport est vraiment bien détaillé et permet de voir l'impact d'une mise à jour ainsi que les développements de l'admin, très utile pour la recherche d'une avarie. Le script Cron est tout simple, mais il n'est pas livré avec le paquet, il faut donc l'ajouter à la main :

# cat /etc/cron.daily/z-aidereport.sh
#!/usr/bin/bash

aide --update --verbose=20
cp -f /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz && echo "Updated database file: aide.db.gz"

Avec les bonnes permissions (chmod +x). Le nom du script est important, ici je le fais commencer par la lettre Z car les scripts du répertoire /etc/cron.daily/ sont exécutés dans l'ordre alphabétique, il sera donc lancé après tous les autres. Le rapport sera alors envoyé par email à l'utilisateur root de la machine. Prelink étant retiré définitivement de Fedora à partir de la version 20, pas besoin de le désactiver pour éviter les faux positifs dans le rapport des HIDS.

Checkdns 0.5-15

Matthieu Saulnier

Introduction

La chronique continue, avec cette fois-ci la mise à jour d'un paquet que je viens de récupérer du dépôt. Son propriètaire précédent ne montrant plus signe de vie, ses paquets sont devenus "orphelins" et sont automatiquement retirés du dépôt s'ils ne trouvent pas un nouveau propriètaire. Ces événements sont annoncés sur la liste de diffusion de développement du Projet Fedora. Récupérer un ancien paquet n'est pas une opération anodine, car même si le paquet est déjà fait, il est resté un certain temps sans aucune maintenance et donc n'a pas suivi les dernières évolutions d'empaquetage de la distribution. Les tickets du bugzilla s'empilent sur son dos tandis que la dernière activité des développeurs du logiciel remonte à 2005 (dans le jargon on dit que « Upstream est mort »). Avant de se porter acquéreur d'un paquet nouvellement orpheliné, il convient de vérifier que les tickets de bugzilla ouverts contre ce paquet puissent être fermés, soit par une mise à jour produite par les développeurs du logiciel (appelés Upstream pour les intîmes), soit par une mise à jour du paquet produite par le packageur. Le seul ticket ouvert concerne une évolution d'empaquetage, que je vais donc devoir résoudre avec cette mise à jour.

Prérequis

Toujours avoir le groupe de paquets Empaqueteur Fedora installé sur votre machine.

# yum install @rpm-development-tools

Récupération des sources du paquet

Même si le paquet est marqué comme "orphelin" et qu'il est donc retiré du dépôt, son code source restera toujours accessible. Ainsi les sources de n'importe quel paquet qui a été présent au moins une fois dans le dépôt fedora par le passé peuvent être récupérées. Dans le cas présent vu que je suis son nouveau propriètaire le cas ne se pose pas mais je tenais à le signaler. Comme d'habitude, on clône le dépôt à code source de checkdns sur le disque dur :

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

Si vous ne possédez pas votre propre compte FAS, l'option -a de la commande est obligatoire (-a pour "anonyme", sans spécifier de compte FAS). Aussitôt on vérifie que la version du logiciel empaquetée est bien la dernière version du logiciel parue :

casper@blackbird:~/fedora-scm/checkdns$ egrep 'URL|Version|Source0' checkdns.spec
Version:        0.5
URL:            http://www.enderunix.org/checkdns/
Source0:        http://www.enderunix.org/checkdns/%{name}-%{version}.tar.gz

Si j'ai également fait apparaitre l'url du tarball, c'est parce que le site en PHP a un comportement un peu étrange, du coup je voulais vérifier la présence du fichier et d'un éventuel nouveau tarball. Il s'avère que tout est en ordre, le paquet contient bien la dernière version du logiciel.

Les modifications du RPM

Certes, cette mise à jour n'implique pas beaucoup le logiciel empaqueté, mais l'opération de taille consiste à faire le ravalement de façade du paquet, en résolvant en premier le ticket du bugzilla.

Fixer le bug

Le rapporteur du bug nous informe d'un changement approuvé par le Comité d'Empaqueteur Fedora concernant les paquets fournissants des tâches Cron. Ces paquets doivent désormais avoir une dépendance sur le paquet "crontabs" lorsqu'ils ajoutent une tâche dans le répertoire /etc/cron.d/, et les fichiers de tâche doivent avoir les permissions en 0640. Le rapporteur donne même un exemple sur le paquet Cacti en pièce jointe du ticket. Du coup, on incrémente le tag Release du paquet, et on applique les changements imposés par la nouvelle Guideline d'empaquetage des fichiers de tâche Cron. En l'occurence on ajoute une dépendance sur le paquet crontabs qui possède le répertoire %{_sysconfdir}/cron.d/, et on ajuste les permissions du fichier de tâche Cron en 640 conformément à la guideline.

--- checkdns.spec.orig  2014-02-25 01:58:14.926521141 +0100
+++ checkdns.spec       2014-02-25 01:58:55.330904343 +0100
@@ -1,6 +1,6 @@
 Name:          checkdns
 Version:       0.5
-Release:       14%{?dist}
+Release:       15%{?dist}
 Summary:       A Domain Name Server analysis and reporting tool
 
 Group:         Applications/Internet
@@ -11,7 +11,7 @@ Source1:      checkdns.cron
 Patch0:                checkdns-0.5.config_location.patch
 BuildRoot:     %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
-Requires:      httpd, bind
+Requires:      httpd, bind, crontabs
 Requires(pre): shadow-utils
 
 %description
@@ -45,7 +45,7 @@ install -p checkdns $RPM_BUILD_ROOT/%{_s
 install -d $RPM_BUILD_ROOT/%{_sysconfdir}
 sed -e '/html_output_dir/s@usr/local/apache/htdocs@var/www/html@' -e '/lang_file/s@local/@@' checkdns.conf-dist > $RPM_BUILD_ROOT/%{_sysconfdir}/checkdns.conf
 install -d $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d
-install -p -m 0644 %{SOURCE1} $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d/%{name}
+install -p -m 0640 %{SOURCE1} $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d/%{name}
 install -d $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}
 install -p -m 0644 checkdns.css $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}
 install -d $RPM_BUILD_ROOT/%{_datadir}/%{name}
@@ -70,6 +70,10 @@ getent passwd checkdns >/dev/null || use
 %config(noreplace) %{_localstatedir}/www/html/%{name}/checkdns.css
 
 %changelog
+* Tue Feb 25 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxxxx> - 0.5-15
+- Add requirement on crontabs (Fix RHBZ #947058)
+- Fix modes of cron job file in %%install section
+
 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@
xxxxxxxxxxxxxxxxx> - 0.5-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

Supprimer les tags obsolètes

Ce paquet est resté très longtemps sans maintenance, il contient pas mal de tags qui ont été rendu obsolètes par l'évolution de l'empaquetage Fedora. Le plus flagrant étant le tag BuildRoot qui n'est plus nécessaire depuis Fedora 10. Petite visite historique du paquet et nettoyage de fond en comble sont au programme.

  • Le tag Group était obligatoire, maintenant il ne l'est plus.
  • La racine de construction (BuildRoot) n'a plus besoin d'être nettoyée au début de la section %install.
  • La ligne %defattr indique les propriètaire et groupe par défaut (root:root), elle n'est donc plus nécéssaire depuis que ce standard est inclus automatiquement dans la partie %files.

Mais le ravallement de façade n'est pas tout à fait terminé...

--- checkdns.spec.orig  2014-02-25 02:02:19.251839258 +0100
+++ checkdns.spec       2014-02-25 02:07:40.471855789 +0100
@@ -3,13 +3,11 @@ Version:      0.5
 Release:       15%{?dist}
 Summary:       A Domain Name Server analysis and reporting tool
 
-Group:         Applications/Internet
 License:       GPLv2+
 URL:           http://www.enderunix.org/checkdns/
 Source0:       http://www.enderunix.org/checkdns/%{name}-%{version}.tar.gz
 Source1:       checkdns.cron
 Patch0:                checkdns-0.5.config_location.patch
-BuildRoot:     %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 Requires:      httpd, bind, crontabs
 Requires(pre): shadow-utils
@@ -39,7 +37,6 @@ export CFLAGS
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
 install -d $RPM_BUILD_ROOT/%{_sbindir}
 install -p checkdns $RPM_BUILD_ROOT/%{_sbindir}
 install -d $RPM_BUILD_ROOT/%{_sysconfdir}
@@ -51,8 +48,6 @@ install -p -m 0644 checkdns.css $RPM_BUI
 install -d $RPM_BUILD_ROOT/%{_datadir}/%{name}
 cp -rp lang $RPM_BUILD_ROOT/%{_datadir}/%{name}
 
-%clean
-rm -rf $RPM_BUILD_ROOT
 
 %pre
 getent passwd checkdns >/dev/null || useradd -d \
@@ -60,7 +55,6 @@ getent passwd checkdns >/dev/null || use
 :
 
 %files
-%defattr(-,root,root,-)
 %doc AUTHORS ChangeLog COPYING INSTALL LICENSE README THANKS TODO
 %config(noreplace) %{_sysconfdir}/checkdns.conf
 %config(noreplace) %{_sysconfdir}/cron.d/%{name}
@@ -73,6 +67,8 @@ getent passwd checkdns >/dev/null || use
 * Tue Feb 25 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxxxx> - 0.5-15
 - Add requirement on crontabs (Fix RHBZ #947058)
 - Fix modes of cron job file in %%install section
+- Remove obsoletes tags in spec file
+- Remove %%clean section in spec file

 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@
xxxxxxxxxxxxxxxxx> - 0.5-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

Cleanup de la section %install

Pourquoi faire en deux commandes l'équivalent d'une seule commande ? La commande `install` permet de créer le répertoire parent et d'y placer un fichier en une seule passe, très utile lorsque le fichier doit être renommé. Par contre les répertoires sont ignorés, la commande `cp` devra être utilisée à la place.

--- checkdns.spec.orig  2014-02-25 02:37:57.972868958 +0100
+++ checkdns.spec       2014-02-25 03:27:48.157016352 +0100
@@ -37,14 +37,11 @@ export CFLAGS
 make %{?_smp_mflags}
 
 %install
-install -d $RPM_BUILD_ROOT/%{_sbindir}
-install -p checkdns $RPM_BUILD_ROOT/%{_sbindir}
+install -D -p %{name} $RPM_BUILD_ROOT/%{_sbindir}/%{name}
 install -d $RPM_BUILD_ROOT/%{_sysconfdir}
 sed -e '/html_output_dir/s@usr/local/apache/htdocs@var/www/html@' -e '/lang_file/s@local/@@' checkdns.conf-dist > $RPM_BUILD_ROOT/%{_sysconfdir}/checkdns.conf
-install -d $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d
-install -p -m 0640 %{SOURCE1} $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d/%{name}
-install -d $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}
-install -p -m 0644 checkdns.css $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}
+install -D -p -m 0640 %{SOURCE1} $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d/%{name}
+install -D -p -m 0644 %{name}.css $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}/%{name}.css
 install -d $RPM_BUILD_ROOT/%{_datadir}/%{name}
 cp -rp lang $RPM_BUILD_ROOT/%{_datadir}/%{name}
 
@@ -69,6 +66,7 @@ getent passwd checkdns >/dev/null || use
 - Fix modes of cron job file in %%install section
 - Remove obsoletes tags in spec file
 - Remove %%clean section in spec file
+- Cleanup %%install section in spec file
 
 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@xxxxxxxxxxxxxxxx> - 0.5-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

Ajout de la Description en français

J'ai pour habitude de traduire la description de mes paquet en français, mais ça fera l'objet de la prochaine mise à jour.

Essais de construction

Avant de mettre en ligne les changements (commit + push), on peut toujours tester si le paquet se construit correctement. Certains packageurs utilisent Mock, personnellement mon mock est hors-service depuis un moment, du coup j'utilise Koji en remplacement. Pour celà il faut créer un SRPM depuis le contenu du dépôt Git, tout simplement avec la commande :

casper@blackbird:~/fedora-scm/checkdns$ fedpkg srpm

Puis lancer le build du SRPM sur l'infrastructure de construction de Fedora :

casper@blackbird:~/fedora-scm/checkdns$ koji --user=fantom build --scratch --nowait f21 /home/casper/fedora-scm/checkdns/checkdns-0.5-15.fc21.src.rpm

Si tous les tests passent, alors on peut commiter et pusher les changements, et bien sûr on construit le paquet pour les différentes branches de Fedora depuis le Git en ligne. Vu que les changements sont mineurs on va les appliquer jusqu'à la branche f19 (en partant de Rawhide). Pour commiter et pusher en une seule commande, il faut ajouter l'option -p :

casper@blackbird:~/fedora-scm/checkdns$ fedpkg commit -m "Fix RHBZ #947058" -p

Et enfin on builde pour la branche Rawhide.

Construction pour f20 et f19

Les modifications que nous venons de valider avec la construction du paquet Rawhide peuvent être appliquées aux autres branches sans risque. Dans notre dépôt local on change de branche :

$ fedpkg switch-branch f20

Puis on applique les changements automatiquement réalisés dans la branche master (la branche en perpétuel développement, assimilée à Rawhide) :

$ git merge master

Les changements sont appliqués seulement dans notre dépôt local, il convient de les pousser en ligne avant de pouvoir demander la construction du paquet à partir du dépôt Git :

$ fedpkg push

On peut désormais construire le paquet pour f20 :

$ fedpkg build --nowait

L'option --nowait est utile lorsqu'on travaille à la chaîne, en effet sans cette option la commande ne rend le prompt du terminal seulement à la fin de la construction du paquet. Du coup le terminal est monopolisé pour 5 à 10', mais avec cette option dès que la tâche est lancée sur Koji la commande rend automatiquement le prompt en 10". Lorsqu'il y a plusieurs branches à mettre à jour c'est une option qui permet vraiment de gagner du temps.

Création de l'update Bodhi

Dans le précédent billet nous avons utilisé la commande `fedpkg update` qui lance un editeur en mode console. Éditeur au choix défini par la variable d'environnement $EDITOR :

$ echo $EDITOR
emacs -nw

L'inconvénient de cette méthode est qu'il faut remplir à la main le petit formulaire, certes il n'y a que 2 ligne à compléter, mais bon... Pour changer nous allons le faire en une commande par branche (f20 et f19), ce qui est beaucoup plus rapide. Concrètement, avec la commande il faut marquer le paquet construit comme étant paquet de mise à jour pour le dépôt, cette commande peut être lancée n'importe où, pas besoin d'être dans le dépôt Git pour la lancer (à l'inverse de `fedpkg update`). En revanche, le fait de ne pas avoir le petit formulaire interractif nous oblige à fournir toutes les informations nécessaire du premier coup. Dans le cas de checkdns il faut spécifier le numéro du bug fixé par l'update (#947058), le type d'update (avancement, sécurité, bugfix), le commentaire décrivant l'update pour les testeurs, et bien sûr où le paquet doit aller avec cette marque (dépôt updates-testing).

casper@blackbird:~$ bodhi -u fantom -n -b 947058 -t bugfix -N "Fix RHBZ #947058" -R testing checkdns-0.5-15.fc20
Creating a new update for checkdns-0.5-15.fc20
Update successfully created
================================================================================
     checkdns-0.5-15.fc20
================================================================================
    Release: Fedora 20
     Status: pending
       Type: bugfix
      Karma: 0
    Request: testing
       Bugs: 947058 - Add a missing requirement on crontabs for the cron job to
           : the spec file
      Notes: Fix RHBZ #947058
  Submitter: fantom
  Submitted: 2014-02-25 03:20:43
   Comments: bodhi - 2014-02-25 03:21:00 (karma 0)
             This update has been submitted for testing by fantom.

  https://admin.fedoraproject.org/updates/checkdns-0.5-15.fc20


Pour f19 il suffit de remplacer fc20 par fc19, et le paquet correspondant sera aussi marqué. Attention, je tiens à rappeler que seuls les paquets construits depuis leurs dépôts à code source Git (donc avec la commande `fedpkg build` uniquement) peuvent être marqués en tant que mise à jour potentielle par Bodhi.

Poezio 0.8-1

Matthieu Saulnier

Cette nuit vient de sortir la version 0.8 tant attendue. Cette version majeure succède à la précédente sortie stable 0.7.5 datant de plus de deux ans, même si le dépôt GIT continuait d'avoir une certaine activité régulière. Au niveau des nouveautés je vous invite à lire le post d'un des développeurs, il y en a pas mal. De mon coté rien à signaler à part qu'elle est déjà présente dans les dépôts Rawhide et f20. Bons tests !

libmemcached-last-1.0.18

Remi Collet

Le RPM de la nouvelle version 1.0.18 de la biliothèque libmemcached de communication avec le serveur memcached est disponible dans le dépôt remi pour Fedora et Enterprise Linux. Il est aussi dans le dépôt rawhide.

Pour Fedora ≥ 19

yum --enablerepo=remi install libmemcached

Pour Fedora ≤ 18 et Enterprise Linux le paquet se nomme "libmemcached-last". De cette manière il est possible d'installer la nouvelle version de la bibliothèque  tout en conservant la version du système.

yum --enablerepo=remi install libmemcached-last-libs

Par contre, il n'est pas possible d'installer libmemcached-last + libmemcached.

Si vous avez besoin de la version système pour d'autres applications :

  • libmemcached (commandes +ancienne bibliothèque) + libmemcached-last-libs (bibliothèque v11).

Si vous n'avez pas besoin de la version système :

  • libmemcached-last (commandes) + libmemcached-last-libs (bibliothèque v11).

RPM disponibles pour Fedora 15 à 20 et Enterprise Linux 6.

OCS Inventory NG 2.1

Remi Collet

OCS Inventory NG version 2.1 est disponible. Les RPM sont dans le dépôt remi-test (Fedora ≥ 18 et RHEL / CentOS). Il s'agit d'une version majeure.

Open Computer and Software Inventory Next Generation est une application destinée pour aider l'administrateur système ou réseau surveiller la configuration des machines du réseau et les logiciels qui y sont installés.

Site officiel : http://www.ocsinventory-ng.org/.

Bien sur l'installation se fait avec YUM :

yum --enablerepo=remi,remi-test install ocsinventory

Le paquet ocsinventory est un pseudo paquet qui permet d'installer en même temps :

  • ocsinventory-server : le serveur de communication (Communication server)
  • ocsinventory-reports : la console d'administration (Administration console)
  • mariadb-server ou mysql-server : le serveur de base de données

Il reste bien sûr possible d'installer séparément les 3 serveurs sur des machines différentes.

Après l'installation, connectez vous sur http://localhost/ocsreports/ pour configurer l'application et créer la base de données (ou corriger le schéma en cas de mise à jour).

Je vous invite à lire le billet : Guide d'installation d'OCS et GLPI qui vous facilitera sans doute l'installation (cet article nécessite sans doute une actualisation).

Bien évident, je compte sur vos tests et retours sur cette application, partenaire incontournable de GLPI (même si l'extension fusioninventory est une alternative qui monte). Si les retours sont satisfaisant, je pousserais la version dans remi est dans les dépôts officiels fedora et EPEL.

Les paquets sont aussi déjà disponible dans Fedora rawhide et dans EPEL-7 Beta.

Le paquet de l'agent version 2.1 est aussi disponible (ocsinventory-agent-2.1).

Serveur

Agent

Assemblée Générale du 15 février 2014

Association Borsalinux-Fr

L'Assemblée Générale de l'association a lieu à partir de 18h au

Dock's Café 21 avenue Corentin Cariou Paris (75019).

  • Métro : ligne 7 station Porte de la Villette

L'ordre du jour est le suivant:

1- Présentation du le bilan moral de l'activité de l'association par le Conseil d'Administration;

2- Présentation du bilan financier de l'activité de l'Association par le Conseil d'Administration et du budget 2014.

3- Présentation des événements et des actions pour l'année 2014.

À qui envoyer sa procuration ?

Pour les procurations vous pouvez vous baser sur ce modèle. Vous pouvez transmettre vos procurations par courrier postale, ou par courrier électronique à condition que celui-ci soit signé.

Attention, un membre actif ne pourra détenir plus de deux procurations, conformément à notre règlement intérieur.

Ci-dessous est la liste des personnes qui ont confirmé leur venue à cette Assemblée Générale du 15 février 2014 :

Nom Accepte les procurations Adresse
Emmanuel Seyman OUI 133 rue de Silly, 92100 Boulogne-Billancourt
Alexandre Moine OUI
Fabien Archambault OUI

kmod-crystalhd for HW vidéo decoding

Nicolas Chauvet

If you have a Broadcom Crystal HD device such as the newer model: 02:00.0 Multimedia controller: Broadcom Corporation BCM70015 Video Decoder Crystal HD

Then this version still lack upstream linux kernel support (even in staging). There is a need to compile an external tree that start to diverge with the few fixes that are made in the staging version. Unfortunately I don't see any improvement with the support of this device. Exept that Android for x86 and it's 3.10 kernel seems to properly handle it (probably using distro patches).

So here is a package that can be installed on Fedora 20 for i686 and x86_64.

yum install akmod-crystalhd

I'm using the vlc-extras sub-package for the vlc crystalhd plug-in in order not to add a dependency that can be used in rare cases.

vlc --codec crystalhd multimedia.mp4

PHP 5.4.25 et 5.5.9

Remi Collet

Les RPM de PHP version 5.5.9 sont disponibles dans le dépôt remi pour Fedora et dans le dépôt remi-php55 pour Enterprise Linux.

Les RPM de PHP version 5.4.25 sont disponibles dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...).

Annonces des versions :

Installation de PHP 5.5

yum --enablerepo=remi-php55,remi update php\*

Installation de PHP 5.4

yum --enablerepo=remi update php\*

Et bientôt dans les mises à jour officielles:

À noter :

  • la version EL6 est construite avec RHEL-6.5
  • pour php 5.5, l'extension Zip est désormais fournit dans le paquet php-pecl-zip.
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

Informations, lire :

mars 2014

Premier Samedi Date : samedi 1≤up>er mars 2014 Horaires : de 14h00 à 18h00 Lieu : Carrefour Numérique, Cité des Sciences et de lIndustrie, Paris Pour une nouvelle installation ou pour des ajustements de votre distribution GNU/Linux Fedora, Mageia ou Ubuntu, venez nous retrouver le samedi 1≤up>er mars 2014 au Carrefour Numérique de la Cité des Sciences […]

février 2014

Premier Samedi Date : samedi 1≤up>er février 2014 Horaires : de 14h00 à 18h00 Lieu : Carrefour Numérique, Cité des Sciences et de lIndustrie, Paris Pour une nouvelle installation ou pour des ajustements de votre distribution GNU/Linux Fedora, Mageia ou Ubuntu, venez nous retrouver le samedi 1≤up>er février 2014 au Carrefour Numérique de la Cité des Sciences […]

Fedora 20 Release Party Tunisia

Fedora Tunisia

The Fedora 20 Release Party in Shanghai was successfully held at ESPRIT, Higher Private School of Engineering and Technology Tunisia on Dec 29. It was organised by Fedora Ambassador Sidki KBOUBI and Esprit Libre free software club.

read more

Fedora 20 Release Party Tunisia

Fedora Tunisia

The Fedora 20 Release Party in Tunisia was successfully held at ESPRIT, Higher Private School of Engineering and Technology Tunisia on January 29. It was organised by Fedora Ambassador Sidki KBOUBI and Esprit Libre free software club.

read more

Grunt, Bower, LESS & Bootstrap

Guillaume Kulakowski
Dans mon dernier billet, j'avais évoqué mon engouement pour Bower, une solution de gestion de dépendances web. J'avais alors regretté le fait de ne pas pouvoir exécuter des tâches post-installation afin de retravailler la version distribuée de Bootstrap pour lalléger (comme on peut le faire ici). Comme j'en avais émis l'idée dans ce même billet, j'ai entrepris de ne plus utiliser Bower directement mais de lutiliser au travers de Grunt.

grunt-bower.png

Si vous ne connaissez pas encore Grunt, il s'agit d'un ordonnanceur au même titre que Maven, ant, ou encore Phing, mais basé sur nodejs et utilisant une syntaxe JavaScript.

Installation de Bower & Grunt sous Fedora 20

Après avoir installé nodejs et npm via yum, il faudra installer Bower et Grunt avec npm. En effet, Bower est absent des dépôts Fedora et Grunt est bien disponible mais sans grunt-cli, ce qui en enlève tout lintérêt...

sudo yum install npm -y
sudo npm install bower grunt grunt-cli -g

Notez au passage le fait que l'on fasse l'installation avec l'option -g pour avoir Grunt et Bower installés au niveau du système (/usr/lib/node_modules). Les autres installations se feront toujours à l'aide de npm mais sans cette option. Ceci permet de tout avoir à la racine du projet web, dans un répertoire node_modules (qu'il faudra exclure de la gestion de sources).

Voila, maintenant on rajoute un fichier packages.json et on installe les dépendances avec un npm install :

{
  "name": "Boldy",
  "version": "1.1.2",
  "description": "The Boldy theme for Dotclear",
  "repository": {
    "type": "git",
  },
  "author": "Guillaume Kulakowski",
  "homepage": "http://www.llaumgui.com",
  "devDependencies": {
    "bower": "latest",
    "grunt": "~0.4.2",
    "grunt-contrib-uglify": "latest",
    "grunt-contrib-concat": "latest",
    "grunt-contrib-less": "latest",
    "grunt-bower-task": "latest",
    "grunt-contrib-watch": "latest"
    "grunt-contrib-cssmin": "latest"
  }
}

J'ai maintenant un environnement de travail avec Bower et Grunt ainsi que les plugins nécessaires à mon projet.

Le fichier Gruntfile.js

La configuration des tâches Grunt passe par le fichier Gruntfile.js, j'ai mis le mien et vais en détailler les tâches :

module.exports = function(grunt) {
  'use strict';
 
  // Force use of Unix newlines
  grunt.util.linefeed = '\n';
 
  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    bowerrc: grunt.file.readJSON('.bowerrc'),
 
    // Path configuration from Gruntfile.js
    dirs: {
      'vendor': '<%= bowerrc.directory %>',
      'bootstrap': {
        'js': '<%= dirs.vendor %>/bootstrap/js',
        'less': '<%= dirs.vendor %>/bootstrap/less'
      },
      'css': 'css',
      'less': 'less',
      'js': 'js'
    },
 
    src: {
      output: {
        'bootstrap': {
          'js': '<%= dirs.vendor %>/bootstrap/my/js/bootstrap.js',
          'css': '<%= dirs.vendor %>/bootstrap/my/css/bootstrap.css'
        },
        'boldy': {
          css: {
            'screen': '<%= dirs.css %>/screen.css',
            'indefero': '<%= dirs.css %>/indefero.css'
          },
          js: '<%= dirs.js %>/global.js'
        }
      },
 
      input: {
        bootstrap: {
          'js': [
            '<%= dirs.bootstrap.js %>/dropdown.js',
            '<%= dirs.bootstrap.js %>/tooltip.js',
            '<%= dirs.bootstrap.js %>/collapse.js',
            '<%= dirs.bootstrap.js %>/transition.js',
            '<%= dirs.bootstrap.js %>/carousel.js'
          ],
          'less': [
            '<%= dirs.less %>/bootstrap.less'
          ]
        },
        indefero: '<%= dirs.css %>/indefero.src.css',
        less: '<%= dirs.less %>/boldy_boot.less',
        js: [
          '<%= dirs.vendor %>/jquery-cookie/jquery.cookie.js',
          '<%= src.output.bootstrap.js %>',
          '<%= dirs.vendor %>/scroll-to-top/jquery.scrollToTop.min.js',
          '<%= dirs.js %>/js/post.js',
          '<%= dirs.vendor %>/async-gravatars/async-gravatars.js',
          '<%= dirs.vendor %>/jquery-colorbox/jquery.colorbox-min.js',
          '<%= dirs.vendor %>/nwxforms/src/nwxforms.js',
          '<%= dirs.js %>/boldy.js'
        ]
      },
    },
 
    // Banner
    banner: '/*!\n' +
              ' * Boldy for Dotclear v<%= pkg.version %>\n' +
              ' * Original theme by Site5 (http://www.s5themes.com)\n' +
              ' * Under a GPLv2 http://www.gnu.org/licenses/gpl-2.0.txt\n' +
              ' * Ported on Dotclear by <%= pkg.author %> (<%= pkg.homepage %>)\n' +
              ' * Copyright 2012-<%= grunt.template.today("yyyy") %> <%= pkg.author %>\n' +
              ' */',
 
 
 
    /********************************** Task **********************************/
    // Bower
    bower: {
      install: {
        options: {
          targetDir: '<%= dirs.vendor %>',
          cleanTargetDir: true,
          layout: 'byComponent',
          install: true,
          copy: false,
          verbose: true
        }
      }
    },
 
 
    // Concatenation
    concat: {
      bootstrap: {
        src: '<%= src.input.bootstrap.js %>',
        dest: '<%= src.output.bootstrap.js %>'
      },
    },
 
 
    // LESS
    less: {
      boldy: {
        options: {
          compress: true,
          cleancss: true,
          report: 'gzip',
          strictImports: true,
        },
        files: { '<%= src.output.boldy.css.screen %>': '<%= src.input.less %>'},
      },
      boldy_debug: {
          options: {
            compress: false,
            cleancss: false,
            report: 'none',
            strictImports: true,
          },
          files: { '<%= src.output.boldy.css.screen %>': '<%= src.input.less %>'},
      },
      bootstrap: {
        files: { '<%= src.output.bootstrap.css %>': '<%= src.input.bootstrap.less %>'}
      }
    },
 
 
    // Watcher
    watch: {
      boldy: {
        files: ['less/*.less'],
        tasks: ['less:boldy_debug'],
        options: {
          spawn: false,
        },
      },
    },
 
 
    // CSSmin
    cssmin: {
      boldy: {
        options: {
          report: 'gzip',
          banner: '<%= banner %>'
        },
        files: {
          '<%= src.output.boldy.css.indefero %>': '<%= src.input.indefero %>'
        }
      }
    },
 
 
    // Uglify
    uglify: {
      boldy: {
        options: {
          report: 'gzip',
          banner: '<%= banner %>'
        },
        files: {
          '<%= src.output.boldy.js %>': '<%= src.input.js %>',
        }
      }
    }
 
  });
 
 
  // Load plugins
  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.loadNpmTasks('grunt-contrib-concat');
  grunt.loadNpmTasks('grunt-contrib-less');
  grunt.loadNpmTasks('grunt-bower-task');
  grunt.loadNpmTasks('grunt-contrib-watch');
  grunt.loadNpmTasks('grunt-contrib-cssmin');
 
 
  // Callable tasks
  grunt.registerTask('default', ['boldy', 'cssmin', 'concat:bootstrap', 'uglify']);
  grunt.registerTask('w', ['watch:boldy']);
 
  grunt.registerTask('bootstrap', ['concat:bootstrap', 'less:bootstrap']);
  grunt.registerTask('boldy', ['less:boldy']);
 
  grunt.registerTask('full', ['bower', 'bootstrap', 'default']);
  grunt.registerTask('all', ['full']); // Alias
};

Tâche bower

Via le plugin grunt-bower-task.

Cette tâche est là pour exécuter Bower au travers de Grunt, notez que le plugin n'interprète pas le .bowerrc, je l'ai donc chargé moi même (bowerrc: grunt.file.readJSON('.bowerrc')) afin de passer les mêmes options à la tâche Grunt qu'à Bower.

Tâche Bootstrap

Via les plugins grunt-contrib-less & grunt-contrib-concat.

Le but de cette tâche est de ne pas utiliser la version distribuée de Bootstrap mais de reconstruire ma propre version. Pour celà,

  • je reconstruis le JavaScript à partir des sources et du plugin concat,
  • je recompile les CSS à partir d'une version allégée du bootstrap.less :
/* -- BEGIN LICENSE BLOCK ---------------------------------------
# This file is part of Boldy, a theme for Dotclear
#
# Theme by Site5 (http://www.s5themes.com)
# under a GPLv2 http://www.gnu.org/licenses/gpl-2.0.txt
# Ported on Dotclear by Guillaume Kulakowski (http://www.llaumgui.com)
#
# -- END LICENSE BLOCK ----------------------------------------- */
 
// Core variables and mixins
@import "../vendor/bootstrap/less/variables.less";
@import "../vendor/bootstrap/less/mixins.less";
 
// My override
@import "bootstrap_variables.less";
//@import "bootstrap_mixins.less";
 
// Reset
@import "../vendor/bootstrap/less/normalize.less";
@import "../vendor/bootstrap/less/print.less";
 
// Core CSS
@import "../vendor/bootstrap/less/scaffolding.less";
@import "../vendor/bootstrap/less/type.less";
@import "../vendor/bootstrap/less/code.less";
@import "../vendor/bootstrap/less/grid.less";
//@import "../vendor/bootstrap/less/tables.less";
@import "../vendor/bootstrap/less/forms.less";
@import "../vendor/bootstrap/less/buttons.less";
 
// Components
@import "../vendor/bootstrap/less/component-animations.less";
//@import "../vendor/bootstrap/less/glyphicons.less";
@import "../vendor/bootstrap/less/dropdowns.less";
//@import "../vendor/bootstrap/less/button-groups.less";
//@import "../vendor/bootstrap/less/input-groups.less";
@import "../vendor/bootstrap/less/navs.less";
@import "../vendor/bootstrap/less/navbar.less";
//@import "../vendor/bootstrap/less/breadcrumbs.less";
@import "../vendor/bootstrap/less/pagination.less";
@import "../vendor/bootstrap/less/pager.less";
//@import "../vendor/bootstrap/less/labels.less";
//@import "../vendor/bootstrap/less/badges.less";
//@import "../vendor/bootstrap/less/jumbotron.less";
@import "../vendor/bootstrap/less/thumbnails.less";
@import "../vendor/bootstrap/less/alerts.less";
//@import "../vendor/bootstrap/less/progress-bars.less";
//@import "../vendor/bootstrap/less/media.less";
@import "../vendor/bootstrap/less/list-group.less";
@import "../vendor/bootstrap/less/panels.less";
@import "../vendor/bootstrap/less/wells.less";
//@import "../vendor/bootstrap/less/close.less";
 
// Components w/ JavaScript
//@import "../vendor/bootstrap/less/modals.less";
@import "../vendor/bootstrap/less/tooltip.less";
//@import "../vendor/bootstrap/less/popovers.less";
@import "../vendor/bootstrap/less/carousel.less";
 
// Utility classes
@import "../vendor/bootstrap/less/utilities.less";
@import "../vendor/bootstrap/less/responsive-utilities.less";

Remarquez que j'utilise mes propres variables après celles de Bootstrap afin de les écraser et de modifier Bootstrap directement à la source.

Tâche Boldy

Via les plugins grunt-contrib-uglify, grunt-contrib-less & grunt-contrib-cssmin.

Comme en recompilant Bootstrap à partir des sources LESS j'ai adhéré au concept de LESS, j'ai réécrit le thème de mon blog en LESS.

Cette tâche boldy sert donc :

  • à générer le CSS minifié à partir des sources LESS (grunt-contrib-less),
  • à minifier la CSS pour mon thème indefero qui reste en CSS (grunt-contrib-cssmin),
  • et à minifier les Javascripts (grunt-contrib-uglify).

Tâche watch

Via le plugin grunt-contrib-watch.

Pour compiler du LESS en CSS, il y a 2 méthodes.

  • soit passer par le less.js qui va parser en JS les fichiers LESS à chaque chargement de page (2 à 3 secondes pour mon blog),
  • soit passer par une tâche watch dans Grunt, qui va écouter les modifications sur les fichiers LESS et recompiler un CSS.

C'est cette dernière solution que j'ai retenu et donc c'est à cela que sert la tâche watch.

En conclusion

Pour conclure, je dirais que la mise en place de ces outils (surtout pour la première fois) est certes chronophage, mais une fois que ça tourne, pour mettre à jour les libs (Bootstrap, jQuery, etc.), une seule ligne de commande suffit (grunt full). De plus, une fois Grunt et Bower en place (et maîtrisés), passer de CSS à LESS a été super simple.

Pour finir, je regrette presque que nodejs n'ait pas été inclus dans Fedora plus tôt car il propose de formidables outils indispensables aux développeurs (front) web.

Et pour voir ce que ça donne, une petite vidéo:

Grunt, Bower, LESS & Bootstrap

Guillaume Kulakowski
Dans mon dernier billet, j'avais évoqué mon engouement pour Bower, une solution de gestion de dépendances web. J'avais alors regretté le fait de ne pas pouvoir exécuter des tâches post-installation afin de retravailler la version distribuée de Bootstrap pour lalléger (comme on peut le faire ici). Comme j'en avais émis l'idée dans ce même billet, j'ai entrepris de ne plus utiliser Bower directement mais de lutiliser au travers de Grunt.

grunt-bower.png

Si vous ne connaissez pas encore Grunt, il s'agit d'un ordonnanceur au même titre que Maven, ant, ou encore Phing, mais basé sur nodejs et utilisant une syntaxe JavaScript.

Installation de Bower & Grunt sous Fedora 20

Après avoir installé nodejs et npm via yum, il faudra installer Bower et Grunt avec npm. En effet, Bower est absent des dépôts Fedora et Grunt est bien disponible mais sans grunt-cli, ce qui en enlève tout lintérêt...

sudo yum install npm -y
sudo npm install bower grunt grunt-cli -g

Notez au passage le fait que l'on fasse l'installation avec l'option -g pour avoir Grunt et Bower installés au niveau du système (/usr/lib/node_modules). Les autres installations se feront toujours à l'aide de npm mais sans cette option. Ceci permet de tout avoir à la racine du projet web, dans un répertoire node_modules (qu'il faudra exclure de la gestion de sources).

Voila, maintenant on rajoute un fichier packages.json et on installe les dépendances avec un npm install :

{
  "name": "Boldy",
  "version": "1.1.2",
  "description": "The Boldy theme for Dotclear",
  "repository": {
    "type": "git",
  },
  "author": "Guillaume Kulakowski",
  "homepage": "http://www.llaumgui.com",
  "devDependencies": {
    "bower": "latest",
    "grunt": "~0.4.2",
    "grunt-contrib-uglify": "latest",
    "grunt-contrib-concat": "latest",
    "grunt-contrib-less": "latest",
    "grunt-bower-task": "latest",
    "grunt-contrib-watch": "latest"
    "grunt-contrib-cssmin": "latest"
  }
}

J'ai maintenant un environnement de travail avec Bower et Grunt ainsi que les plugins nécessaires à mon projet.

Le fichier Gruntfile.js

La configuration des tâches Grunt passe par le fichier Gruntfile.js, j'ai mis le mien et vais en détailler les tâches :

module.exports = function(grunt) {
  'use strict';
 
  // Force use of Unix newlines
  grunt.util.linefeed = '\n';
 
  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    bowerrc: grunt.file.readJSON('.bowerrc'),
 
    // Path configuration from Gruntfile.js
    dirs: {
      'vendor': '<%= bowerrc.directory %>',
      'bootstrap': {
        'js': '<%= dirs.vendor %>/bootstrap/js',
        'less': '<%= dirs.vendor %>/bootstrap/less'
      },
      'css': 'css',
      'less': 'less',
      'js': 'js'
    },
 
    src: {
      output: {
        'bootstrap': {
          'js': '<%= dirs.vendor %>/bootstrap/my/js/bootstrap.js',
          'css': '<%= dirs.vendor %>/bootstrap/my/css/bootstrap.css'
        },
        'boldy': {
          css: {
            'screen': '<%= dirs.css %>/screen.css',
            'indefero': '<%= dirs.css %>/indefero.css'
          },
          js: '<%= dirs.js %>/global.js'
        }
      },
 
      input: {
        bootstrap: {
          'js': [
            '<%= dirs.bootstrap.js %>/dropdown.js',
            '<%= dirs.bootstrap.js %>/tooltip.js',
            '<%= dirs.bootstrap.js %>/collapse.js',
            '<%= dirs.bootstrap.js %>/transition.js',
            '<%= dirs.bootstrap.js %>/carousel.js'
          ],
          'less': [
            '<%= dirs.less %>/bootstrap.less'
          ]
        },
        indefero: '<%= dirs.css %>/indefero.src.css',
        less: '<%= dirs.less %>/boldy_boot.less',
        js: [
          '<%= dirs.vendor %>/jquery-cookie/jquery.cookie.js',
          '<%= src.output.bootstrap.js %>',
          '<%= dirs.vendor %>/scroll-to-top/jquery.scrollToTop.min.js',
          '<%= dirs.js %>/js/post.js',
          '<%= dirs.vendor %>/async-gravatars/async-gravatars.js',
          '<%= dirs.vendor %>/jquery-colorbox/jquery.colorbox-min.js',
          '<%= dirs.vendor %>/nwxforms/src/nwxforms.js',
          '<%= dirs.js %>/boldy.js'
        ]
      },
    },
 
    // Banner
    banner: '/*!\n' +
              ' * Boldy for Dotclear v<%= pkg.version %>\n' +
              ' * Original theme by Site5 (http://www.s5themes.com)\n' +
              ' * Under a GPLv2 http://www.gnu.org/licenses/gpl-2.0.txt\n' +
              ' * Ported on Dotclear by <%= pkg.author %> (<%= pkg.homepage %>)\n' +
              ' * Copyright 2012-<%= grunt.template.today("yyyy") %> <%= pkg.author %>\n' +
              ' */',
 
 
 
    /********************************** Task **********************************/
    // Bower
    bower: {
      install: {
        options: {
          targetDir: '<%= dirs.vendor %>',
          cleanTargetDir: true,
          layout: 'byComponent',
          install: true,
          copy: false,
          verbose: true
        }
      }
    },
 
 
    // Concatenation
    concat: {
      bootstrap: {
        src: '<%= src.input.bootstrap.js %>',
        dest: '<%= src.output.bootstrap.js %>'
      },
    },
 
 
    // LESS
    less: {
      boldy: {
        options: {
          compress: true,
          cleancss: true,
          report: 'gzip',
          strictImports: true,
        },
        files: { '<%= src.output.boldy.css.screen %>': '<%= src.input.less %>'},
      },
      boldy_debug: {
          options: {
            compress: false,
            cleancss: false,
            report: 'none',
            strictImports: true,
          },
          files: { '<%= src.output.boldy.css.screen %>': '<%= src.input.less %>'},
      },
      bootstrap: {
        files: { '<%= src.output.bootstrap.css %>': '<%= src.input.bootstrap.less %>'}
      }
    },
 
 
    // Watcher
    watch: {
      boldy: {
        files: ['less/*.less'],
        tasks: ['less:boldy_debug'],
        options: {
          spawn: false,
        },
      },
    },
 
 
    // CSSmin
    cssmin: {
      boldy: {
        options: {
          report: 'gzip',
          banner: '<%= banner %>'
        },
        files: {
          '<%= src.output.boldy.css.indefero %>': '<%= src.input.indefero %>'
        }
      }
    },
 
 
    // Uglify
    uglify: {
      boldy: {
        options: {
          report: 'gzip',
          banner: '<%= banner %>'
        },
        files: {
          '<%= src.output.boldy.js %>': '<%= src.input.js %>',
        }
      }
    }
 
  });
 
 
  // Load plugins
  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.loadNpmTasks('grunt-contrib-concat');
  grunt.loadNpmTasks('grunt-contrib-less');
  grunt.loadNpmTasks('grunt-bower-task');
  grunt.loadNpmTasks('grunt-contrib-watch');
  grunt.loadNpmTasks('grunt-contrib-cssmin');
 
 
  // Callable tasks
  grunt.registerTask('default', ['boldy', 'cssmin', 'concat:bootstrap', 'uglify']);
  grunt.registerTask('w', ['watch:boldy']);
 
  grunt.registerTask('bootstrap', ['concat:bootstrap', 'less:bootstrap']);
  grunt.registerTask('boldy', ['less:boldy']);
 
  grunt.registerTask('full', ['bower', 'bootstrap', 'default']);
  grunt.registerTask('all', ['full']); // Alias
};

Tâche bower

Via le plugin grunt-bower-task.

Cette tâche est là pour exécuter Bower au travers de Grunt, notez que le plugin n'interprète pas le .bowerrc, je l'ai donc chargé moi même (bowerrc: grunt.file.readJSON('.bowerrc')) afin de passer les mêmes options à la tâche Grunt qu'à Bower.

Tâche Bootstrap

Via les plugins grunt-contrib-less & grunt-contrib-concat.

Le but de cette tâche est de ne pas utiliser la version distribuée de Bootstrap mais de reconstruire ma propre version. Pour celà,

  • je reconstruis le JavaScript à partir des sources et du plugin concat,
  • je recompile les CSS à partir d'une version allégée du bootstrap.less :
/* -- BEGIN LICENSE BLOCK ---------------------------------------
# This file is part of Boldy, a theme for Dotclear
#
# Theme by Site5 (http://www.s5themes.com)
# under a GPLv2 http://www.gnu.org/licenses/gpl-2.0.txt
# Ported on Dotclear by Guillaume Kulakowski (http://www.llaumgui.com)
#
# -- END LICENSE BLOCK ----------------------------------------- */
 
// Core variables and mixins
@import "../vendor/bootstrap/less/variables.less";
@import "../vendor/bootstrap/less/mixins.less";
 
// My override
@import "bootstrap_variables.less";
//@import "bootstrap_mixins.less";
 
// Reset
@import "../vendor/bootstrap/less/normalize.less";
@import "../vendor/bootstrap/less/print.less";
 
// Core CSS
@import "../vendor/bootstrap/less/scaffolding.less";
@import "../vendor/bootstrap/less/type.less";
@import "../vendor/bootstrap/less/code.less";
@import "../vendor/bootstrap/less/grid.less";
//@import "../vendor/bootstrap/less/tables.less";
@import "../vendor/bootstrap/less/forms.less";
@import "../vendor/bootstrap/less/buttons.less";
 
// Components
@import "../vendor/bootstrap/less/component-animations.less";
//@import "../vendor/bootstrap/less/glyphicons.less";
@import "../vendor/bootstrap/less/dropdowns.less";
//@import "../vendor/bootstrap/less/button-groups.less";
//@import "../vendor/bootstrap/less/input-groups.less";
@import "../vendor/bootstrap/less/navs.less";
@import "../vendor/bootstrap/less/navbar.less";
//@import "../vendor/bootstrap/less/breadcrumbs.less";
@import "../vendor/bootstrap/less/pagination.less";
@import "../vendor/bootstrap/less/pager.less";
//@import "../vendor/bootstrap/less/labels.less";
//@import "../vendor/bootstrap/less/badges.less";
//@import "../vendor/bootstrap/less/jumbotron.less";
@import "../vendor/bootstrap/less/thumbnails.less";
@import "../vendor/bootstrap/less/alerts.less";
//@import "../vendor/bootstrap/less/progress-bars.less";
//@import "../vendor/bootstrap/less/media.less";
@import "../vendor/bootstrap/less/list-group.less";
@import "../vendor/bootstrap/less/panels.less";
@import "../vendor/bootstrap/less/wells.less";
//@import "../vendor/bootstrap/less/close.less";
 
// Components w/ JavaScript
//@import "../vendor/bootstrap/less/modals.less";
@import "../vendor/bootstrap/less/tooltip.less";
//@import "../vendor/bootstrap/less/popovers.less";
@import "../vendor/bootstrap/less/carousel.less";
 
// Utility classes
@import "../vendor/bootstrap/less/utilities.less";
@import "../vendor/bootstrap/less/responsive-utilities.less";

Remarquez que j'utilise mes propres variables après celles de Bootstrap afin de les écraser et de modifier Bootstrap directement à la source.

Tâche Boldy

Via les plugins grunt-contrib-uglify, grunt-contrib-less & grunt-contrib-cssmin.

Comme en recompilant Bootstrap à partir des sources LESS j'ai adhéré au concept de LESS, j'ai réécrit le thème de mon blog en LESS.

Cette tâche boldy sert donc :

  • à générer le CSS minifié à partir des sources LESS (grunt-contrib-less),
  • à minifier la CSS pour mon thème indefero qui reste en CSS (grunt-contrib-cssmin),
  • et à minifier les Javascripts (grunt-contrib-uglify).

Tâche watch

Via le plugin grunt-contrib-watch.

Pour compiler du LESS en CSS, il y a 2 méthodes.

  • soit passer par le less.js qui va parser en JS les fichiers LESS à chaque chargement de page (2 à 3 secondes pour mon blog),
  • soit passer par une tâche watch dans Grunt, qui va écouter les modifications sur les fichiers LESS et recompiler un CSS.

C'est cette dernière solution que j'ai retenu et donc c'est à cela que sert la tâche watch.

En conclusion

Pour conclure, je dirais que la mise en place de ces outils (surtout pour la première fois) est certes chronophage, mais une fois que ça tourne, pour mettre à jour les libs (Bootstrap, jQuery, etc.), une seule ligne de commande suffit (grunt full). De plus, une fois Grunt et Bower en place (et maîtrisés), passer de CSS à LESS a été super simple.

Pour finir, je regrette presque que nodejs n'ait pas été inclus dans Fedora plus tôt car il propose de formidables outils indispensables aux développeurs (front) web.

Et pour voir ce que ça donne, une petite vidéo:

Grunt, Bower, LESS & Bootstrap

Guillaume Kulakowski
Dans mon dernier billet, j'avais évoqué mon engouement pour Bower, une solution de gestion de dépendances web. J'avais alors regretté le fait de ne pas pouvoir exécuter des tâches post-installation afin de retravailler la version distribuée de Bootstrap pour lalléger (comme on peut le faire ici). Comme j'en avais émis l'idée dans ce même billet, j'ai entrepris de ne plus utiliser Bower directement mais de lutiliser au travers de Grunt.

grunt-bower.png

Si vous ne connaissez pas encore Grunt, il s'agit d'un ordonnanceur au même titre que Maven, ant, ou encore Phing, mais basé sur nodejs et utilisant une syntaxe JavaScript.

Installation de Bower & Grunt sous Fedora 20

Après avoir installé nodejs et npm via yum, il faudra installer Bower et Grunt avec npm. En effet, Bower est absent des dépôts Fedora et Grunt est bien disponible mais sans grunt-cli, ce qui en enlève tout lintérêt...

sudo yum install npm -y
sudo npm install bower grunt grunt-cli -g

Notez au passage le fait que l'on fasse l'installation avec l'option -g pour avoir Grunt et Bower installés au niveau du système (/usr/lib/node_modules). Les autres installations se feront toujours à l'aide de npm mais sans cette option. Ceci permet de tout avoir à la racine du projet web, dans un répertoire node_modules (qu'il faudra exclure de la gestion de sources).

Voila, maintenant on rajoute un fichier packages.json et on installe les dépendances avec un npm install :

{
  "name": "Boldy",
  "version": "1.1.2",
  "description": "The Boldy theme for Dotclear",
  "repository": {
    "type": "git",
  },
  "author": "Guillaume Kulakowski",
  "homepage": "http://www.llaumgui.com",
  "devDependencies": {
    "bower": "latest",
    "grunt": "~0.4.2",
    "grunt-contrib-uglify": "latest",
    "grunt-contrib-concat": "latest",
    "grunt-contrib-less": "latest",
    "grunt-bower-task": "latest",
    "grunt-contrib-watch": "latest"
    "grunt-contrib-cssmin": "latest"
  }
}

J'ai maintenant un environnement de travail avec Bower et Grunt ainsi que les plugins nécessaires à mon projet.

Le fichier Gruntfile.js

La configuration des tâches Grunt passe par le fichier Gruntfile.js, j'ai mis le mien et vais en détailler les tâches :

module.exports = function(grunt) {
  'use strict';
 
  // Force use of Unix newlines
  grunt.util.linefeed = '\n';
 
  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    bowerrc: grunt.file.readJSON('.bowerrc'),
 
    // Path configuration from Gruntfile.js
    dirs: {
      'vendor': '<%= bowerrc.directory %>',
      'bootstrap': {
        'js': '<%= dirs.vendor %>/bootstrap/js',
        'less': '<%= dirs.vendor %>/bootstrap/less'
      },
      'css': 'css',
      'less': 'less',
      'js': 'js'
    },
 
    src: {
      output: {
        'bootstrap': {
          'js': '<%= dirs.vendor %>/bootstrap/my/js/bootstrap.js',
          'css': '<%= dirs.vendor %>/bootstrap/my/css/bootstrap.css'
        },
        'boldy': {
          css: {
            'screen': '<%= dirs.css %>/screen.css',
            'indefero': '<%= dirs.css %>/indefero.css'
          },
          js: '<%= dirs.js %>/global.js'
        }
      },
 
      input: {
        bootstrap: {
          'js': [
            '<%= dirs.bootstrap.js %>/dropdown.js',
            '<%= dirs.bootstrap.js %>/tooltip.js',
            '<%= dirs.bootstrap.js %>/collapse.js',
            '<%= dirs.bootstrap.js %>/transition.js',
            '<%= dirs.bootstrap.js %>/carousel.js'
          ],
          'less': [
            '<%= dirs.less %>/bootstrap.less'
          ]
        },
        indefero: '<%= dirs.css %>/indefero.src.css',
        less: '<%= dirs.less %>/boldy_boot.less',
        js: [
          '<%= dirs.vendor %>/jquery-cookie/jquery.cookie.js',
          '<%= src.output.bootstrap.js %>',
          '<%= dirs.vendor %>/scroll-to-top/jquery.scrollToTop.min.js',
          '<%= dirs.js %>/js/post.js',
          '<%= dirs.vendor %>/async-gravatars/async-gravatars.js',
          '<%= dirs.vendor %>/jquery-colorbox/jquery.colorbox-min.js',
          '<%= dirs.vendor %>/nwxforms/src/nwxforms.js',
          '<%= dirs.js %>/boldy.js'
        ]
      },
    },
 
    // Banner
    banner: '/*!\n' +
              ' * Boldy for Dotclear v<%= pkg.version %>\n' +
              ' * Original theme by Site5 (http://www.s5themes.com)\n' +
              ' * Under a GPLv2 http://www.gnu.org/licenses/gpl-2.0.txt\n' +
              ' * Ported on Dotclear by <%= pkg.author %> (<%= pkg.homepage %>)\n' +
              ' * Copyright 2012-<%= grunt.template.today("yyyy") %> <%= pkg.author %>\n' +
              ' */',
 
 
 
    /********************************** Task **********************************/
    // Bower
    bower: {
      install: {
        options: {
          targetDir: '<%= dirs.vendor %>',
          cleanTargetDir: true,
          layout: 'byComponent',
          install: true,
          copy: false,
          verbose: true
        }
      }
    },
 
 
    // Concatenation
    concat: {
      bootstrap: {
        src: '<%= src.input.bootstrap.js %>',
        dest: '<%= src.output.bootstrap.js %>'
      },
    },
 
 
    // LESS
    less: {
      boldy: {
        options: {
          compress: true,
          cleancss: true,
          report: 'gzip',
          strictImports: true,
        },
        files: { '<%= src.output.boldy.css.screen %>': '<%= src.input.less %>'},
      },
      boldy_debug: {
          options: {
            compress: false,
            cleancss: false,
            report: 'none',
            strictImports: true,
          },
          files: { '<%= src.output.boldy.css.screen %>': '<%= src.input.less %>'},
      },
      bootstrap: {
        files: { '<%= src.output.bootstrap.css %>': '<%= src.input.bootstrap.less %>'}
      }
    },
 
 
    // Watcher
    watch: {
      boldy: {
        files: ['less/*.less'],
        tasks: ['less:boldy_debug'],
        options: {
          spawn: false,
        },
      },
    },
 
 
    // CSSmin
    cssmin: {
      boldy: {
        options: {
          report: 'gzip',
          banner: '<%= banner %>'
        },
        files: {
          '<%= src.output.boldy.css.indefero %>': '<%= src.input.indefero %>'
        }
      }
    },
 
 
    // Uglify
    uglify: {
      boldy: {
        options: {
          report: 'gzip',
          banner: '<%= banner %>'
        },
        files: {
          '<%= src.output.boldy.js %>': '<%= src.input.js %>',
        }
      }
    }
 
  });
 
 
  // Load plugins
  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.loadNpmTasks('grunt-contrib-concat');
  grunt.loadNpmTasks('grunt-contrib-less');
  grunt.loadNpmTasks('grunt-bower-task');
  grunt.loadNpmTasks('grunt-contrib-watch');
  grunt.loadNpmTasks('grunt-contrib-cssmin');
 
 
  // Callable tasks
  grunt.registerTask('default', ['boldy', 'cssmin', 'concat:bootstrap', 'uglify']);
  grunt.registerTask('w', ['watch:boldy']);
 
  grunt.registerTask('bootstrap', ['concat:bootstrap', 'less:bootstrap']);
  grunt.registerTask('boldy', ['less:boldy']);
 
  grunt.registerTask('full', ['bower', 'bootstrap', 'default']);
  grunt.registerTask('all', ['full']); // Alias
};

Tâche bower

Via le plugin grunt-bower-task.

Cette tâche est là pour exécuter Bower au travers de Grunt, notez que le plugin n'interprète pas le .bowerrc, je l'ai donc chargé moi même (bowerrc: grunt.file.readJSON('.bowerrc')) afin de passer les mêmes options à la tâche Grunt qu'à Bower.

Tâche Bootstrap

Via les plugins grunt-contrib-less & grunt-contrib-concat.

Le but de cette tâche est de ne pas utiliser la version distribuée de Bootstrap mais de reconstruire ma propre version. Pour celà,

  • je reconstruis le JavaScript à partir des sources et du plugin concat,
  • je recompile les CSS à partir d'une version allégée du bootstrap.less :
/* -- BEGIN LICENSE BLOCK ---------------------------------------
# This file is part of Boldy, a theme for Dotclear
#
# Theme by Site5 (http://www.s5themes.com)
# under a GPLv2 http://www.gnu.org/licenses/gpl-2.0.txt
# Ported on Dotclear by Guillaume Kulakowski (http://www.llaumgui.com)
#
# -- END LICENSE BLOCK ----------------------------------------- */
 
// Core variables and mixins
@import "../vendor/bootstrap/less/variables.less";
@import "../vendor/bootstrap/less/mixins.less";
 
// My override
@import "bootstrap_variables.less";
//@import "bootstrap_mixins.less";
 
// Reset
@import "../vendor/bootstrap/less/normalize.less";
@import "../vendor/bootstrap/less/print.less";
 
// Core CSS
@import "../vendor/bootstrap/less/scaffolding.less";
@import "../vendor/bootstrap/less/type.less";
@import "../vendor/bootstrap/less/code.less";
@import "../vendor/bootstrap/less/grid.less";
//@import "../vendor/bootstrap/less/tables.less";
@import "../vendor/bootstrap/less/forms.less";
@import "../vendor/bootstrap/less/buttons.less";
 
// Components
@import "../vendor/bootstrap/less/component-animations.less";
//@import "../vendor/bootstrap/less/glyphicons.less";
@import "../vendor/bootstrap/less/dropdowns.less";
//@import "../vendor/bootstrap/less/button-groups.less";
//@import "../vendor/bootstrap/less/input-groups.less";
@import "../vendor/bootstrap/less/navs.less";
@import "../vendor/bootstrap/less/navbar.less";
//@import "../vendor/bootstrap/less/breadcrumbs.less";
@import "../vendor/bootstrap/less/pagination.less";
@import "../vendor/bootstrap/less/pager.less";
//@import "../vendor/bootstrap/less/labels.less";
//@import "../vendor/bootstrap/less/badges.less";
//@import "../vendor/bootstrap/less/jumbotron.less";
@import "../vendor/bootstrap/less/thumbnails.less";
@import "../vendor/bootstrap/less/alerts.less";
//@import "../vendor/bootstrap/less/progress-bars.less";
//@import "../vendor/bootstrap/less/media.less";
@import "../vendor/bootstrap/less/list-group.less";
@import "../vendor/bootstrap/less/panels.less";
@import "../vendor/bootstrap/less/wells.less";
//@import "../vendor/bootstrap/less/close.less";
 
// Components w/ JavaScript
//@import "../vendor/bootstrap/less/modals.less";
@import "../vendor/bootstrap/less/tooltip.less";
//@import "../vendor/bootstrap/less/popovers.less";
@import "../vendor/bootstrap/less/carousel.less";
 
// Utility classes
@import "../vendor/bootstrap/less/utilities.less";
@import "../vendor/bootstrap/less/responsive-utilities.less";

Remarquez que j'utilise mes propres variables après celles de Bootstrap afin de les écraser et de modifier Bootstrap directement à la source.

Tâche Boldy

Via les plugins grunt-contrib-uglify, grunt-contrib-less & grunt-contrib-cssmin.

Comme en recompilant Bootstrap à partir des sources LESS j'ai adhéré au concept de LESS, j'ai réécrit le thème de mon blog en LESS.

Cette tâche boldy sert donc :

  • à générer le CSS minifié à partir des sources LESS (grunt-contrib-less),
  • à minifier la CSS pour mon thème indefero qui reste en CSS (grunt-contrib-cssmin),
  • et à minifier les Javascripts (grunt-contrib-uglify).

Tâche watch

Via le plugin grunt-contrib-watch.

Pour compiler du LESS en CSS, il y a 2 méthodes.

  • soit passer par le less.js qui va parser en JS les fichiers LESS à chaque chargement de page (2 à 3 secondes pour mon blog),
  • soit passer par une tâche watch dans Grunt, qui va écouter les modifications sur les fichiers LESS et recompiler un CSS.

C'est cette dernière solution que j'ai retenu et donc c'est à cela que sert la tâche watch.

En conclusion

Pour conclure, je dirais que la mise en place de ces outils (surtout pour la première fois) est certes chronophage, mais une fois que ça tourne, pour mettre à jour les libs (Bootstrap, jQuery, etc.), une seule ligne de commande suffit (grunt full). De plus, une fois Grunt et Bower en place (et maîtrisés), passer de CSS à LESS a été super simple.

Pour finir, je regrette presque que nodejs n'ait pas été inclus dans Fedora plus tôt car il propose de formidables outils indispensables aux développeurs (front) web.

Et pour voir ce que ça donne, une petite vidéo:

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


Page générée le 19 nov 2014 à 10:20