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.

PHP 5.6.0 Release Candidate

Remi Collet

La première Release Candidate de PHP 5.6.0 est publiée, voir PHP 5.6.0RC1 is available.

Les RPM sont disponibles dans le dépôt remi-php56 pour Fedora 19 à 20 et pour Enterprise Linux 5 à 7 (RHEL, CentOS)

emblem-important-4-24.pngAttention : il s'agit d'une version destinée aux tests a ne pas utiliser en production.

Changement dans les paquets :

  • Le nouveau paquet php-dbg fournit le debogueur interactif
  • Chaque fichier de configuration (/etc/php.d) est préfixé par un numéro garantissant un order de chargement correct.

Installation :

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

Cette nouvelle version est un des changements attendus pour Fedora 21, voir PHP 5.6

PHP 5.6.0RC1 est aussi déjà disponible dans Fedora rawhide.

Documentation :

Fonctionnant avec la version de développement depuis plus mois, je n'ai pas rencontrer de problème avec les applications que j'utilise ou les suite de tests que je fait tourner lors de la construction de paquets.

La plupart des extensions sont aussi disponibles.

RHEL-7, EPEL-7, remi-7 et PHP

Remi Collet

Red Hat Enterprise Linux 7 est publiée, voir : Red Hat Enterprise Linux 7 now Generally Available

EPEL

Le dépôt EPEL pour RHEL-7 est ouvert (toujours en beta)

Installation :

wget http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.1.noarch.rpm
yum install epel-release-7-0.1.noarch.rpm

Vous avez donc à votre disposition une pile PHP assez complète (version 5.4.16).

A noter, RHSCL 1.1 fournit aussi php55 (version 5.5.6).

Remi

Pour les adeptes des dernières versions, ou pour les extensions supplémentaires le dépôt remi est aussi ouvert :

Installation :

wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
yum install remi-release-7.rpm

Et vous pouvez disposer au choix de 3 versions

  • PHP 5.4.29 dans le dépôt remi
  • PHP 5.5.13 dans le dépôt remi-php55
  • PHP 5.6.0beta4 dans le dépôt remi-php56

CentOS 7 est en cours de préparation et devrait être disponibles dans quelques jours/semaines.

PHP 5.4.29 et 5.5.13

Remi Collet

Les RPM de PHP version 5.5.13 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.29 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:

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.0RC
  • 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

emblem-notice-24.pngInformations, lire :

Changement de MTA

Matthieu Saulnier

Sur toutes mes machines les nombreux emails envoyés par le démon Cron doivent être relayés par un Mail Transport Agent (MTA). J'utilise pour cela Postfix que j'ai l'habitude de déployer. Sur une installation minimale de Fedora, il n'y a pas vraiment changement de MTA puisqu'il y en a aucun installé d'office. En revanche, sur une installation standard de Fedora en laissant Anaconda installer GNOME3, il y aura un MTA installé par défaut (Ssmtp). Pas la peine d'essayer de le supprimer à coup de "yum remove", ce n'est pas lui qui va poser problème à Postfix, mais plutôt la configuration système faite avec des liens symboliques. Ai-je bien dit "problème" ? Ah oui c'est vrai, il est énoncé dans le log, le problème.

mai 23 01:16:54 mosquito systemd[1]: Starting Postfix Mail Transport Agent...
mai 23 01:16:56 mosquito aliasesdb[997]: newaliases: In sSMTP aliases are read from a plain text file
mai 23 01:16:56 mosquito aliasesdb[997]: touch: impossible d'obtenir les attributs de « /etc/aliases.db »: Aucun fichier ou dossier de ce type
mai 23 01:16:59 mosquito postfix/postfix-script[1187]: starting the Postfix mail system
mai 23 01:16:59 mosquito postfix/master[1189]: daemon started -- version 2.10.3, configuration /etc/postfix
mai 23 01:16:59 mosquito systemd[1]: Started Postfix Mail Transport Agent.

Après installation, le démon démarre bien, il en demeure pas moins hors-service, en effet le fichier aliases.db est un fichier vital pour son fonctionnement. Normallement, la commande newaliases est censée créer ce fichier, d'ailleurs cette commande est lancée à la fin de l'installation du paquet postfix. Sauf qu'elle échoue, même si on la lance manuellement, avec toujours le même message d'erreur :

newaliases: In sSMTP aliases are read from a plain text file

Le système utilise des liens symboliques pour définir les commandes par défaut à utiliser dans certaines situations, dont la façon de délivrer du courrier, ce type de configuration permet de se passer du libre arbitre de l'administrateur quand le système doit choisir quel programme est à utiliser, indispensable lorsqu'il y a plusieurs MTA installés sur le système. Tant que le MTA à utiliser par défaut ne sera pas /usr/sbin/sendmail.postfix, la commande newaliases restera en erreur. Il existe donc pour l'administrateur souhaitant changer les commandes par défaut un programme qui s'occupe de tout :

man alternatives

Et dans notre cas de figure, on va lancer la commande pour sélectionner Postfix :

mosquito:~# alternatives --config mta

Il existe 2 programmes qui fournissent « mta ».

  Sélection    Commande
-----------------------------------------------
*  1           /usr/sbin/sendmail.ssmtp
 + 2           /usr/sbin/sendmail.postfix

Entrez pour garder la sélection courante [+] ou saisissez le numéro de type de sélection :2

Une fois validé, newaliases devrait correctement créer le fichier aliases.db. Avant de redémarrer le service Postfix, veillez à restaurer les contextes SELinux sur ce fichier, dans le cas contraire Postfix ne redémarrera pas :

mai 28 15:58:31 mosquito systemd[1]: Starting Postfix Mail Transport Agent...
mai 28 15:58:31 mosquito aliasesdb[7044]: postalias: fatal: open /etc/aliases.db: Permission denied
mai 28 15:58:31 mosquito postfix/postalias[7046]: fatal: open /etc/aliases.db: Permission denied
mai 28 15:58:34 mosquito postfix/postfix-script[7128]: starting the Postfix mail system
mai 28 15:58:34 mosquito postfix/master[7130]: daemon started -- version 2.10.3, configuration /etc/postfix
mai 28 15:58:34 mosquito systemd[1]: Started Postfix Mail Transport Agent.

Un simple restorecon -v /etc/aliases.db fera l'affaire.

Monkey Boy : 20 Large Blurred Backgrounds

Thomas Bouffon

Mort de Chiliproject et migration vers Redmine

Johan Cwiklinski

Depuis un certain temps (voire même un temps certain), j'utilise Chiliproject pour gérer les demandes de Galette - entre autres.

J'avais tout d'abord opté pour Redmine, avant de switcher vers Chiliproject dès la création du projet. Seulement voilà, aujourd'hui, Chiliproject semble inactif. Pas de commits depuis près d'un an, plus d'activité apparente des développeurs principaux sur les forums et autres, ... Étant moi même en charge d'un projet Open Source, je ne peux pas leur jeter la pierre, je comprends parfaitement que l'on puisse avoir d'autres centres d'intérêts et priorités. On peut avoir une vie en somme :-)" class="smiley

Le fait est que je ne souhaite pas conserver trop longtemps un projet qui n'est plus maintenu, et qui n'évoluera visiblement plus à l'avenir. La migration vers un autre projet (à condition d'en trouver un qui soit dores et déjà utilisable) ne saurait se faire sans perdre les données existantes ; et les nombreux tickets (résolus ou non) créés ces dernières années.

La solution la moins pire semble de simplement revenir à Redmine (c'est encore le projet qui s'approche le plus de Chiliproject, évidemment). Ce ne serait pas aussi rigolo si ça pouvait fonctionner sans encombres, la base de données n'est pas tout à fait compatible et requiert des modifications.

Une première documentation sur la migration de Chiliproject vers Redmine est disponible, ainsi qu'un programme Java qui se charge d'une partie de la conversion (il reste quelques requêtes à jouer à la main). Cette méthode n'a pas fonctionné pour moi, le programme tombe sur une chaîne alors qu'il attend un entier... Et c'est la fin des haricots !

En continuant mes recherches, j'ai trouvé une seconde documentation sur la migration de Chiliproject vers Redmine, qui référence la première trouvée, en ajoutant quelques remarques, et surtout un script - Ruby cette fois - de migration de la base ; ce dernier est celui qui a fonctionné pour moi.

J'ai installé mon instance de Redmine sur une CentOS6 ; qui a le « gros défaut » de fournir une version 1.8.7 de Ruby, incompatible avec le script de migration :-/" class="smiley Fort heureusement, les Software Collections existent, et sont très facilement utilisables. Récupérez le dépôt adéquat (wget http://people.redhat.com/bkabrda/scl_ruby193.repo), installez la version adéquate de Ruby (yum install ruby193 ruby19-ruby-devel).

Beaucoup de dépendances requises par Redmine ne sont pas disponibles dans les dépôts, il faut « obligatoirement » en passer par l'installation de gems locaux (ce qui n'est pas très propre, mais je n'ai pas trouvé mieux...) ; et c'est pour cela que j'ai dédié une machine virtuelle aux installations de Redmine/Chiliproject.

Je suppose que l'installation des seuls gems requis par le script de migration suffisent, mais pour le test, j'ai installé les dépendances de Redmine. J'ai rencontré quelques erreurs, j'ai brodé. La procédure pour la mise à jour au final est la suivante (l'instance de Redmine étant préalablement installée et fonctionnelle) :

cd /var/www/redmine
scl enable ruby193 "gem install bundle"
scl enable ruby193 "bundle install --without postgresql sqlite test development"
wget https://gist.githubusercontent.com/pallan/6663018/raw/b6823dd7b4286c328e249a17f4cfb0bd9ef59373/chiliproject_to_redmine.rb
scl enable ruby193 "ruby chiliproject_to_redmine.rb"

Il suffit alors de relancer Redmine pour tester si tout s'est correctement déroulé, après avoir allumé un (ou plusieurs !) cierges ;-)" class="smiley

phpCompatInfo version 3

Remi Collet

Les RPM pour installer la nouvelle version majeure de phpCompatInfo sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL, CentOS...).

Blog officiel : http://php5.laurent-laville.org/compatinfo/blog/

Comme d'autres logiciels, cet outil essentiel pour les mainteneurs d'applications PHP a abandonné la distribution pear au profit de composer... :(

Le distribution officielle se fait désormais sous forme d'une grosse archive .phar incluant toutes les dépendances, ce qui n'est évidement pas acceptable pour les RPM.

Les paquets sont donc adaptés pour utiliser les bibliothèques systèmes (nikic/php-parser, phpunit/timer, symfony...)

Installation

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

Utilisation

Attention, la syntaxe a changé !

$ cd /chemin/a/analyser
$ phpcompatinfo -v analyser:run . extension

A noter : l'argument . n'est pas un chemin mais le nom d'un "provider" définit dans le fichier de configuration.

Le fichier de configuration utilisé étant par ordre de priorité :

  • Fichier définit par la variable d'environnement COMPATINFO
  • Fichier compatinfo.json du dossier courant
  • Fichier utilisateur, ~/.config/phpcompatinfo.json
  • Fichier système, /etc/phpcompatinfo.json (fournit)

Comme d'habitude, vos retours sont les bienvenus.

9 ans et 40 millions

Remi Collet

Après 9 ans dexistence,  les 20 millions atteint il y a un an et demi, le cap des 40 millions de RPM téléchargés depuis le dépôt remi, ou un des 17 miroirs dans le monde, vient d'être franchi (16 millions uniquement pour EL-5, 17 pour EL-6). Soit environ 35 000 par jour.

Merci de votre fidélité.

Vous pouvez m'encourager en faisant un don de quelques euros qui permettra de financer l'hébergement du site principal, et sans doute une nouvelle machine pour 2015. Encore merci à ceux qu'ils l'ont fait.

phpMyAdmin version 4.2

Remi Collet

Les RPM pour installer la nouvelle version majeure de phpMyAdmin sont disponibles dans le dépôt remi pour Fedora et Enterprise Linux (RHEL, CentOS...).

Site officiel : http://www.phpmyadmin.net/

Je ne sais pas encore si cette nouvelle version majeure sera aussi disponible dans les mises à jour officielles de Fedora ou de EPEL, mais la mise à jour semble bloquée par les règles sur les bibliothèques embarquées. Donc il est disponible pour fedora 15 à 20 et enterprise linux 5 à 7 (à condition d'utiliser une version de php suffisante, aussi disponible dans le dépôt).

Comme toujours :
yum --enablerepo=remi install phpMyAdmin

Je vous laisse découvrir cette nouvelle version qui intègre beaucoup de nouveautés (ajax, graphique, préférences, ...), et remonter vos impressions.

juin 2014

Premier Samedi Date : samedi 7 juin 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 7 juin 2014 au Carrefour Numérique de la Cité des Sciences […]

ETickets4Hikashop V1.1 : Gestion des variantes !

Thomas Bouffon

La version 1.1 d'ETickets4hikashop gère maintenant les variantes : en créant des variantes de votre concert, vous pourrez proposer des tarifs spécifiques, des places, ou plusieurs dates pour un même évènement.

Vous n'aurez besoin de remplir que le cadre de l'article principal, et toutes les variantes seront automatiquement des billets electroniques.

Elle est disponible à la page téléchargements.

ETickets4Hikashop V1.1 : Gestion des variantes !

Thomas Bouffon

La version 1.1 d'ETickets4hikashop gère maintenant les variantes : en créant des variantes de votre concert, vous pourrez proposer des tarifs spécifiques, des places, ou plusieurs dates pour un même évènement.

Vous n'aurez besoin de remplir que le cadre de l'article principal, et toutes les variantes seront automatiquement des billets electroniques.

Elle est disponible à la page téléchargements.

PHPUnit 4.1

Remi Collet

Les RPM de PHPUnit version 4.1 sont disponibles dans le dépôt remi-test pour fedora et Enterprise Linux (CentOS, RHEL...).

Jusqu'à la version 3.7, PHPUnit et ses composants était principalement distribué dans le canal PEAR "phpunit". Chaque composant étant donc distribué dans un RPM dédié de la même manière.

Depuis la version 4.0, le paquet pear fournit uniquement un grosse archive .phar, contenant l'ensemble des composants. C'est la méthode de diffusion choisi par l'auteur. Ce mode de distribution n'est, hélas, pas du tout acceptable pour une distribution RPM.

De plus, ce canal pear, doit être prochainement fermé (avant la fin de l'année).

J'ai donc passé un peu de temps sur cette mise à jour : chaque composant est désormais construit à partir des sources github. Le mécanisme d'autoload étant maintenu.

Installation :

yum --enablerepo=remi,remi-test install php-phpunit-PHPUnit

Merci de tester cette nouvelle version, qui devrait bientôt être poussée dans Rawhide (Fedora 21) et EPEL-7.

PHP 5.4.28 and 5.5.12

Remi Collet

RPM of PHP version 5.5.12 are available in remi repository for Fedora and in remi-php55 repository for  Enterprise Linux.

RPM of PHP version 5.4.28 are available in remi repository Enterprise Linux (RHEL, CentOS...).

Version announcements:

PHP 5.5 installation:

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

PHP 5.4 Installation:

yum --enablerepo=remi update php\*

And soon in the official updates:

security-medium-2-32.png In this version, permissions on the Unix Domain Socket used by php-fpm are restricted. If you use this configuration, check the needed rights. Default provided configuration use a Network Socket, so is not concerned.

emblem-important-2-24.pngTo be noticed :

  • EL6 rpm are now build using RHEL-6.5
  • for php 5.5, the zip extension is now provided by the php-pecl-zip package.
  • a lot of new extensions are also available, see the PECL extension RPM status page

emblem-notice-24.pngInformation, read:

PHP 5.4.28 et 5.5.12

Remi Collet

Les RPM de PHP version 5.5.12 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.28 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:

security-medium-2-32.png Cette version restreint les permissions par défaut sur la Unix Domain Socket utilisée par php-fpm. Si vous utilisez cette configuration, vérifiez les droits. Le configuration par défaut utilise une Network Socket, donc n'est pas concernée.

emblem-important-2-24.pngÀ 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

emblem-notice-24.pngInformations, lire :

Xnee 3.18

Matthieu Saulnier

Rpm_logo.png

Nouvel épisode de la chronique d'empaqueteur pour le Projet Fedora. Au programme, grosse session packaging qui sera étalée dans plusieurs posts. On commence avec Xnee qui a un ticket bugzilla ouvert. Ce ticket a été ouvert automatiquement par le script de surveillance des nouvelles versions logiciel de Fedora, très pratique pour être instantanément averti de la sortie d'une nouvelle version de Xnee.

Synchronisation du dépôt local

Avec les paquets ayants une faible activité de développement, il arrive fréquemment que le dépôt local sur notre disque ne soit pas synchrone avec le dépôt en ligne. En effet, tous les 6 à 12 mois environ, tous les paquets de la distribution sont reconstruits au cours d'un « mass-rebuild ». Les mass-rebuild sont généralement lancés suite à l'évolution majeure du compilateur ou bien d'une bibliothèque utilisée par de nombreux paquets. Les changements engendrés sur mon paquet ne sont pas énorme, la release est incrémentée et une nouvelle entrée est ajoutée au Changelog dans la branche master (la branche utilisée par Rawhide). Il faut donc veiller avant de commencer à travailler que l'on possède bien la dernière version du dépôt de code source.

casper@blackbird:~/fedora-scm/Xnee$ fedpkg pull
Depuis ssh://pkgs.fedoraproject.org/Xnee
 * [nouvelle branche] f20        -> origin/f20
Already up-to-date.

Récupération du tarball

Commençons par récupérer le nouveau tarball en modifiant le fichier SPEC comme suit :

--- a/Xnee.spec
+++ b/Xnee.spec
@@ -1,8 +1,8 @@
 Summary:       X11 environment recorder
 Summary(fr):   Enregistreur de l'environnement X11
 Name:          Xnee
-Version:       3.16
-Release:       2%{?dist}
+Version:       3.18
+Release:       1%{?dist}
 
 License:       GPLv3+
 URL:           http://www.gnu.org/software/xnee/
@@ -139,6 +139,9 @@ make test
 
 
 %changelog
+* Mon Apr 28 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxxxxx> - 3.18-1
+- Update to 3.18
+
 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@xxxxxxxxxxxxxxxxxx> - 3.16-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

 

Puis on peut télécharger les nouvelles sources avec la commande spectool :

casper@blackbird:~/fedora-scm/Xnee$ spectool -g -S Xnee.spec
Getting http://ftp.gnu.org/gnu/xnee/xnee-3.18.tar.gz to ./xnee-3.18.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1817k  100 1817k    0     0   378k      0  0:00:04  0:00:04 --:--:--  378k

J'ai toujours l'habitude d'en avoir une copie dans ~/Téléchargements/ afin de pouvoir l'extraire et l'étudier plus en détail.

Étude de la nouvelle version

Souvenez-vous que le paquet passe directement de la version 3.16 à 3.18, on va sauter la 3.17. Du coup il va sûrement y avoir pas mal de changement au niveau du programme. Pour nous aider à nous y retrouver, le développeur renseigne le fichier texte nommé « NEWS », qui est également présent dans le RPM au passage.

Changes in version 3.18 ('Abbado')
==============================

  Removed incorrect comments.

Changes in version 3.17 ('Seeger')
==============================

  * New features:

  * Fixed bugs:

    Savannah:
    Mayhem:    #715746 "cnee crashes with exit status 139"
    Works with X.org 1.14.*


Changes in version 3.16
==============================

  * New features:

    Gnee can record XInput events

  * Fixed bugs:

    Savannah:

On voit ici qu'il s'agit de nouvelles compatibilités avec Xorg, de correction de bugs, et d'amélioration du code (les commentaires c'est important ^^).

Répercutions sur le SPEC

Concrètement, il y en a aucune. Cela ne dispense pas de faire une relecture complète du SPEC, et de remettre en cause tous les "quickfix". Ce serait pertinent de lancer un build hors SCM pour chaque élément à remettre en cause, puis de procéder à divers tests sur les RPMs obtenus et relire les logs de compilation. C'est d'ailleurs cette petite routine de contrôle qualité qui m'a indiqué ce qu'il y avait encore à améliorer, chaque détail compte.

Contrôle qualité

La mise à jour des paquets Fedora ne consiste pas à incrémenter des numéros de version puis lancer la construction, ça serait trop facile. D'autant plus que les vieux paquets comme celui de Xnee (mon premier paquet Fedora) ont la fâcheuse tendance de trainer une couche de résidus, léger certes, mais quand même. Rpmlint est un programme qui automatise un grand nombre de tests, il est très utilisé pendant la revue d'intégration d'un nouveau paquet dans le dépôt Fedora.

$ rpmlint Xnee*3.18* cnee*
Xnee-devel.x86_64: W: spelling-error Summary(fr) nécéssaires -> nécessaires
Xnee-devel.x86_64: W: spelling-error %description -l fr nécéssaires -> nécessaires
Xnee-devel.x86_64: W: spelling-error %description -l fr lib -> lob, lin, li
Xnee-devel.x86_64: W: no-documentation
5 packages and 0 specfiles checked; 0 errors, 4 warnings.

Ces erreurs ont été introduites pendant la mise à jour du * Thu Aug 16 2012 d'après le ChangeLog. Nous allons donc les corriger.

Dernières modifications du SPEC

Dans le SPEC les erreurs sont situées au niveau du sous-paquet Xnee-devel :

diff --git a/Xnee.spec b/Xnee.spec
index 1c9dcb7..51992bb 100644
--- a/Xnee.spec
+++ b/Xnee.spec
@@ -1,8 +1,8 @@
 Summary:       X11 environment recorder
 Summary(fr):   Enregistreur de l'environnement X11
 Name:          Xnee
-Version:       3.16
-Release:       2%{?dist}
+Version:       3.18
+Release:       1%{?dist}
 
 License:       GPLv3+
 URL:           http://www.gnu.org/software/xnee/
@@ -41,7 +41,7 @@ quel client Xnee ou interface.
 
 %package devel
 Summary:       Files needed for building applications with libxnee
-Summary(fr):   Fichiers nécéssaires pour construire des applications avec libxnee
+Summary(fr):   Fichiers nécessaires pour construire des applications avec libxnee
 Requires:      Xnee-libs%{?_isa} = %{version}-%{release}
 
 %description devel
@@ -50,8 +50,8 @@ necessary for developing programs which use the xnee-lib library.
 
 %description devel -l fr
 Le paquet xnee-devel inclue les fichiers d'en-tête et bibliothèques
-nécéssaires au développement des programmes utilisant la bibliothèque
-xnee-lib.
+nécessaires au développement des programmes utilisant la bibliothèque
+libxnee.
 
 
 %package -n cnee
@@ -139,6 +139,10 @@ make test
 
 
 %changelog
+* Mon Apr 28 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxxxxxx> - 3.18-1
+- Update to 3.18
+- Fix spelling-error in summary and description
+
 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@xxxxxxxxxxxxxxxxxxx> - 3.16-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

 

Enregistrement des modifications

Avant de commiter il faut d'abord uploader le nouveau tarball, sinon on devra faire un nouveau commit juste après l'upload :

casper@blackbird:~/fedora-scm/Xnee$ fedpkg new-sources xnee-3.18.tar.gz
Uploading: 2ffd7832026c871d0fb0f63e06c71519  xnee-3.18.tar.gz
######################################################################## 100,0%
Uploaded and added to .gitignore: xnee-3.18.tar.gz
Source upload succeeded. Don't forget to commit the sources file

C'est même indiqué par la commande « Don't forget to commit the sources file ».

casper@blackbird:~/fedora-scm/Xnee$ fedpkg commit -m "Update to 3.18" -p

C'est commité et pushé en une seule passe, on va donc passer au build.

Construction du paquet pour Rawhide

Comme toujours on travaille dans la branche master du dépôt Git, donc on impacte seulement Rawhide. C'est une sécurité, si jamais mon paquet devait introduire de l'instabilité dans la distribution, les versions stables de Fedora ne seront pas touchées. Bien sûr cela concerne les paquets principaux, mes petits paquets ne sont pas des dépendances d'autres paquets, et par conséquent s'ils ne sont pas stable ils ne menacent en rien la stabilité légendaire de Fedora. Mais ça permet toujours aux testeurs de vérifier et rapporter des bugs avant que le paquet n'arrive dans les branches stables.

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

Il est possible que certains packageurs mettent à jour seulement Rawhide (la future F21) et pas les branches stables (F20, F19), ça m'est arrivé sur certain paquets. C'est autorisé par le réglement des Mises à jour de Fedora pour les updates n'apportant ni correctifs de bug ni correctifs de faille de sécurité. Les deux pratiques sont bonnes et ça dépend vraiment du bon vouloir du packageur en fait...

Mise à jour pour F20

On applique les changements de la branche master à la branche f20 du dépôt Git. Pour cela il faut d'abord changer de branche :

casper@blackbird:~/fedora-scm/Xnee$ fedpkg switch-branch f20
La branche f20 est paramétrée pour suivre la branche distante f20 depuis origin.

Puis on applique les modifications de la branche master :

casper@blackbird:~/fedora-scm/Xnee$ git merge master
Mise à jour 7fe7be6..81328d5
Fast-forward
 .gitignore |  1 +
 Xnee.spec  | 14 +++++++++-----
 sources    |  2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

Ensuite on synchronise le dépôt en ligne avec la commande :

casper@blackbird:~/fedora-scm/Xnee$ fedpkg push
Total 0 (delta 0), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
To ssh://fantom@pkgs.fedoraproject.org/Xnee
   7fe7be6..81328d5  f20 -> f20

Et enfin on peut demander la construction du paquet à partir du dépôt de code source en ligne :

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

Lorsque le paquet sera effectivement construit, il sera taggué comme paquet de mise à jour potentielle pour le dépôt updates-testing. Il ne reste donc plus qu'à le tagguer en tant que mise à jour effective du paquet Xnee présent dans le dépôt Fedora, à l'aide du système de Mise à jour Fedora, Bodhi. Il ne faut pas oublier d'assigner le ticket de Bugzilla à l'update.

casper@blackbird:~/fedora-scm/Xnee$ bodhi -u fantom -n -b 1059676 -t enhancement -N "Update to 3.18" -R testing Xnee-3.18-1.fc20
Creating a new update for Xnee-3.18-1.fc20
Password for fantom:
Creating a new update for Xnee-3.18-1.fc20
Update successfully created
================================================================================
     Xnee-3.18-1.fc20
================================================================================
    Release: Fedora 20
     Status: pending
       Type: enhancement
      Karma: 0
    Request: testing
       Bugs: 1059676 - Xnee-3.18 is available
      Notes: Update to 3.18
  Submitter: fantom
  Submitted: 2014-04-29 17:19:16
   Comments: bodhi - 2014-04-29 17:19:31 (karma 0)
             This update has been submitted for testing by fantom.

  https://admin.fedoraproject.org/updates/Xnee-3.18-1.fc20


Dans 7 jours le paquet passera du dépôt updates-testing au dépôt updates, uniquement avec la commande que je dois lancer manuellement :

$ bodhi -u fantom -R stable Xnee-3.18-1.fc20

L'option -R signifiant "request" pour demander le passage en stable, et Xnee-3.18-1.fc20 indiquant le nom du paquet construit par Koji.

Présent à la table ronde "Evolution des meilleures pratiques du développement web" à Solutions Linux & Open Source 2014

Guillaume Kulakowski

Je serais présent au salon Solutions Linux & Open Source 2014 qui se déroulera les 20 et 21 mai au Cnit de Paris La Défense.

Cette années, en plus d'arpenter les allées de la partie pro ou du village gaulois, vous pourrez également me retrouver au track "Développement web : la nouvelle donne Open Source" :

Les technologies Web semblent évoluer sans cesse plus vite. Les performances et les capacités, des navigateurs ne cessent daugmenter. Tous les ans, un ou plusieurs nouveaux frameworks open source à la mode apparaissent. Dans ce contexte, comment tirer au mieux partie de ces innovations ? Quels outils et quels workflows pour les développeurs et pour les équipes ? Comment sorganiser pour rester au top ? Des experts techniques et des chefs de projets expérimentés débattront de ces sujets et répondront aux questions de lassistance.

Animateur : Stéphane VINCENT, Responsable des Offres et de l'Innovation, Alterway

Intervenants :

  • Gilles GUIRAND, CTO, Kaliop
  • Guillaume KULAKOWSKI, Expert technique en solutions Open-source, CGI
  • Jean-François LEPINE, Consultant technique, Alterway

Présent à la table ronde "Evolution des meilleures pratiques du développement web" à Solutions Linux & Open Source 2014

Guillaume Kulakowski

Je serais présent au salon Solutions Linux & Open Source 2014 qui se déroulera les 20 et 21 mai au Cnit de Paris La Défense.

Cette années, en plus d'arpenter les allées de la partie pro ou du village gaulois, vous pourrez également me retrouver au track "Développement web : la nouvelle donne Open Source" :

Les technologies Web semblent évoluer sans cesse plus vite. Les performances et les capacités, des navigateurs ne cessent daugmenter. Tous les ans, un ou plusieurs nouveaux frameworks open source à la mode apparaissent. Dans ce contexte, comment tirer au mieux partie de ces innovations ? Quels outils et quels workflows pour les développeurs et pour les équipes ? Comment sorganiser pour rester au top ? Des experts techniques et des chefs de projets expérimentés débattront de ces sujets et répondront aux questions de lassistance.

Animateur : Stéphane VINCENT, Responsable des Offres et de l'Innovation, Alterway

Intervenants :

  • Gilles GUIRAND, CTO, Kaliop
  • Guillaume KULAKOWSKI, Expert technique en solutions Open-source, CGI
  • Jean-François LEPINE, Consultant technique, Alterway

Présent à la table ronde "Evolution des meilleures pratiques du développement web" à Solutions Linux & Open Source 2014

Guillaume Kulakowski

Je serais présent au salon Solutions Linux & Open Source 2014 qui se déroulera les 20 et 21 mai au Cnit de Paris La Défense.

Cette années, en plus d'arpenter les allées de la partie pro ou du village gaulois, vous pourrez également me retrouver au track "Développement web : la nouvelle donne Open Source" :

Les technologies Web semblent évoluer sans cesse plus vite. Les performances et les capacités, des navigateurs ne cessent daugmenter. Tous les ans, un ou plusieurs nouveaux frameworks open source à la mode apparaissent. Dans ce contexte, comment tirer au mieux partie de ces innovations ? Quels outils et quels workflows pour les développeurs et pour les équipes ? Comment sorganiser pour rester au top ? Des experts techniques et des chefs de projets expérimentés débattront de ces sujets et répondront aux questions de lassistance.

Animateur : Stéphane VINCENT, Responsable des Offres et de l'Innovation, Alterway

Intervenants :

  • Gilles GUIRAND, CTO, Kaliop
  • Guillaume KULAKOWSKI, Expert technique en solutions Open-source, CGI
  • Jean-François LEPINE, Consultant technique, Alterway

Présent à la table ronde "Evolution des meilleures pratiques du développement web" à Solutions Linux & Open Source 2014

Guillaume Kulakowski

Je serais présent au salon Solutions Linux & Open Source 2014 qui se déroulera les 20 et 21 mai au Cnit de Paris La Défense.

Cette années, en plus d'arpenter les allées de la partie pro ou du village gaulois, vous pourrez également me retrouver au track "Développement web : la nouvelle donne Open Source" :

Les technologies Web semblent évoluer sans cesse plus vite. Les performances et les capacités, des navigateurs ne cessent daugmenter. Tous les ans, un ou plusieurs nouveaux frameworks open source à la mode apparaissent. Dans ce contexte, comment tirer au mieux partie de ces innovations ? Quels outils et quels workflows pour les développeurs et pour les équipes ? Comment sorganiser pour rester au top ? Des experts techniques et des chefs de projets expérimentés débattront de ces sujets et répondront aux questions de lassistance.

Animateur : Stéphane VINCENT, Responsable des Offres et de l'Innovation, Alterway

Intervenants :

  • Gilles GUIRAND, CTO, Kaliop
  • Guillaume KULAKOWSKI, Expert technique en solutions Open-source, CGI
  • Jean-François LEPINE, Consultant technique, Alterway

Page générée le 19 déc 2014 à 21:00