Le blog d'Emmanuel

Just so you know, the Fedora-fr community will be present at the 2019 edition of Paris Open Source Summit. This year, POSS will be held on December 10th and 11th from 9am to 6pm and, like every year, will be held at Dock Pullmann, in Aubervilliers. We will have a stand on the associative village (booth A34, to be quite exact).

We will be there to answer any questions about Fedora, offer to burn an image of Fedora 31 on your USB key. We will have Fedora goodies for people who are interested. Feel free to come to the Salon if you have time during the 2 days in question and drop by to say hi if you're there!

One recurring subject on the bugzilla support mailing list is the installation of the Perl modules that Bugzilla requires to function. When you are installing on a Linux distribution, the recommended course of action is to use the packages supplied by the distribution. But, on some distributions, these can be of a version lower than what is required by Bugzilla.

One such distribution is RHEL. Version 7 came out in 2014 and its long support life cycle make it popular for people to use it as a base for their bugzilla instance. Using Bugzilla 4.4 is easy because all Bugzilla's mandatory Perl packages are available by default but Bugzilla 5.0 came out after RHEL7 was released and a number of Perl modules aren't available or are outdated. Users then try to install the missing modules themselves, which is something easy to get wrong. I decided to see if this could be made simpler.

My first step was to see if the modules could be supplied in EPEL, a third-party software repository for RHEL and CentOS but some of the modules concerned are in RHEL which makes them impossible to update via EPEL. Another solution is the use of Fedora's COPR, an easy way for Fedora developers to maintain third party repositories for Fedora and/or RHEL.

It took some amount of tweaking to find the package versions that allow you to run Bugzilla 5.0.x without replacing RHEL7's entire Perl stack but the end result is here. Activating a COPR repo is pretty straightforward:

• dnf install dnf-plugins-core
• dnf copr enable eseyman/bugzilla-5.0

At which point, you can install bugzilla just like any other application:

• dnf install bugzilla

The bugzilla package will be updated everytime a new version of Bugzilla is released and its support will end when the Bugzilla developers end support for the 5.0 branch.

As you may not know, I'm a member of Fedora's Perl SIG, the group of people who maintain the Perl ecosystem by providing timely reviews, acting as package co-maintainers and assisting with related security issues.

As it turns, the SIG watches over a lot of packages, over 2600 of them. As you can imagine, this generates a lot of mail, an amount that increases as time goes on and more perl modules are added to the distribution. And this doesn't even take into account mass rebuilds or the fact that all perl modules are rebuilt when a new version of perl is added to rawhide. Over the month of June (when we updated perl to 5.22.x and then rebuilt everything for GCC 5, we got 8000+ emails sent to the list).

Needless to say, it's easy to lose track of information when you're bombarded with this amount of mail. To help cope, I now split the mail received from the perl-devel mailing list into several folders:

• pkgdb mail is sent to its own folder
• bug mail is sent to its own folder
• mail about broken dependencies also has its own folder
• mail about git commits have their own folder
• mail about orphaned packages is sent to its own folder
• everything else perl-devel-related is sent to one folder

At one point, git commits and tarball uploads were separated in different folders but the number of uploads were small enough that I put the two together.

Since I use procmail to filter my incoming mail, here's the relevant stanza in my .procmailrc:

:0:
* ^List-Id: Fedora perl development team
* ^X-Fedmsg-Topic: org.fedoraproject.prod.pkgdb
mailing-lists/fedora-perl-devel-pkgdb

:0:
* ^List-Id: Fedora perl development team
* ^X-Bugzilla-Reason: CC
mailing-lists/fedora-perl-devel-bugs

:0:
* ^List-Id: Fedora perl development team
* ^Subject: Broken dependencies:
mailing-lists/fedora-perl-devel-deps

:0:
* ^List-Id: Fedora perl development team
* ^X-Fedmsg-Topic: org.fedoraproject.prod.git
mailing-lists/fedora-perl-devel-git

:0:
* ^List-Id: Fedora perl development team
* ^Subject: Orphaned Packages
mailing-lists/fedora-perl-devel-orphan

:0:
* ^List-Id: Fedora perl development team
mailing-lists/fedora-perl-devel

The french ambassadors have, every time a new version of Fedora came out, organised a release party for it (we skipped Fedora 18 because the timing of the release didn't make it practical to organise an event). We call these the Recontres Fedora ("Fedora Encounters" or "Fedora Meetings") to stress the importance of developers and end-users meeting each other. When Fedora 19 came out at the begining of July, we decided to have a release party but to do it in september so that everybody could be present.

We set up a date with Parinux, the Paris Linux user group and decided to have the event on the first saturday of september. Universcience, who had already given us a huge hand for FUDCon Paris, again helped us out by hosting the event. A wiki page was set up, a ticket was filed for swag and we started looking for speakers for the conferences. Truth be told, I worried quite a bit before the event that it would go terribly wrong. We ended up not getting the swag, speakers were hard to come by and few people signed up to the wiki page.

However, the release party happened with little difficulties. A number of Fedora ambasadors (nobrakal, bertux, bouska ...) came for the event, people came to the event with usb keys which allowed us to copy a Live Fedora iso on them so that they could try Fedora at home. I had to cancel my conference because I was too busy setting up the event to do it but Misc's conferenece on Ansible was very well done and attracted a small crowd.

I'm actually looking forward to the Rencontres Fedora 20.

I will be one of several Fedora developers manning the booth A35 at Solutions Linux, a two-day event in Paris promoting FLOSS business solutions. Booth A35 is in the community village so don't hesitate to drop bye and say hi.

Ceux qui suivent l'actualité de Fedora savent que la Beta de Fedora 15 est sorti la semaine dernière. J'ai profité du weekend pour l'installer sur deux PC. L'un d'entre eux n'ayant pas de cartes graphique digne de ce nom, je me suis retrouvé avec le mode fallback de Gnome. Passons rapidement, celui-ci ne fera l'affaire pour personne, j'en ai peur.

L'installation sur le portable s'est mieux passé. J'ai alors pu profiter pleinement des nouveautés de Fedora 15. Firefox 4 permet (enfin) de voir les vidéos Youtube sans avoir à installer Flash sur son ordinateur, Gnome 3 (dont je redoutais qu'il soit plus difficile à prendre en main que ça). Le ventilateur du portable s'emballant au bout d'une heure d'utilisation, je n'ai pas pu tester longtemps mais ça semble prometteur.

L'actualité a aussi été marquée ces derniers temps par la sortie de FVWM 2.6.0. Pour ceux qui ont commencé à utiliser les distributions GNU/Linux après la sortie de les versions 1.0 de GNOME et KDE, ça marquera un retour aux sources. Avant Gnome et KDE, FVWM était le gestionnaire par défaut des distributions, en raison de sa très grande configurabilité.

J'ai donc pris les archives disponibles sur fvwm.org, compilé des rpms et j'ai installé sur ma machine. Force est de constater que très peu de choses ont changés en 10 ans (la sortie de 2.4.0 date de 2001). La configuration par défaut est toujours aussi brut et FVWM est toujours (voire encore plus) configurable. Je sens que je vais l'installer sur les machines qui n'ont pas la configuration matériel nécessaire pour Gnome 3.

L'autre nouveauté du projet, c'est l'abandon du cycle de développement actuel (on me souffle dans l'oreillette que 10 ans entre chaque version d'un logiciel, c'est long). Les développeurs de FVWM préparent une migration de CVS à git pour gérer leur code source et comptent utiliser les fonctionnalités de git pour développer les fonctionnalités majeures dans des branches spéciales. Une fois le développement d'une fonctionnalité terminé, on fusionne la branche principale avec la branche de développement et on se retrouve avec une version stable de FVWM qui contient la fonctionnalité en question. Les fonctionnalités seront donc disponibles des que possible aux utilisateurs de FVWM.