A brief word on the OpenSSL Heartbleed bug

With the OpenSSL Heartbleed bug still making headlines around the world we thought you would like to know the status of Mageia 3 and 4.

All the following updates included a Heartbleed fix backported from openssl-1.0.1g

  • openssl-1.0.1e-1.5.mga3.i586.rpm dated 7 April 2014
  • openssl-1.0.1e-1.5.mga3.x86_64.rpm dated 7 April 2014
  • openssl-1.0.1e-8.2.mga4.i586.rpm dated 7 April 2014
  • openssl-1.0.1e-8.2.mga4.x86_64.rpm dated 7 April 2014

You can find the advisory here and if you like you can also subscribe to the updates-announce mailing list and be notified when updates are released.

Soon back in the air and on the roads…

There will be possibilities to meet with me in some exotic places (at least for me as I never travelled there before in May !

I’ll first be in Wien, Austria, early May but that’s to celebrate somewhere my 50th birthday (half a century as my kids like to call that ;-)) and during vacations so won’t talk something else than early music or rchitecture and pictures of the nice building over there !!

But after that, I’ll attend the UEFI plugfest in Seatlle again, and be in charge of managing the interface between Linux distributions and HP. So if you plan to attend, and want to test your Linux distribution on nice shiny UEFI hardware platforms, feel free to contact me so we can organize that meeting over there.

The week after that I’ll be in Japan to present again during a LinuxCon event ! I’m very lucky first to be retained as a presenter to talk another time about Mageia. And then to be sponsored by our VP & Deputy General Counsel, Cloud Computing and Open Source Eileen Evans who is leading HP’s Open Source Program Office and allowing me to attend.

So feel free to drop me a mail if you want to chat about any topic I can decently talk about such as Disaster Recovery and Imaging or Continuous Packaging and some other surely HP related !

See you there.

Filed under: FLOSS Tagged: Event, HP, HPLinux, Japan, Linux, LinuxCon, LinuxFoundation, Mageia, Open Source, UEFI

On change management and display servers

There’s been a post, titled Why the display server doesn’t matter. It received a few responses:

Aaron and Martin are not saying anything that hasn’t been said before. What I find interesting is how the communication is happening. Martin is a well known developer and has spent a lot of effort on porting KDE to Wayland. Aaron communicates a lot :P Now I know various developers will hate “change management” courses and the theory, but one thing that is stressed during such courses is to acknowledge and understand what people affected by a change are saying.

Looking into the responses given by “Canonical” (in quotes because I’m not sure if every response was from a Canonical person) towards the various feedback given regarding the change (Mir as additional display server), one common theme is highlighted by the various responses: “it doesn’t matter”, “it is just a bug in the application”, “it is just a bug in the toolkit”, “the toolkit abstracted wrongly”, etc. Sometimes these answers are conflicting. Saying partly that the toolkit abstracts it, while also saying that currently the toolkit is lacking should indicate that there is a problem (at least in the communication).

Despite the pain caused by this change, there is no acknowledgement. Just a repeat of “it doesn’t matter”. As a result, the very people you need to make this change happen will feel ignored and being dismissed. You need these people, yet they’re being dismissed. What gives? It seems headed towards failure. Why not acknowledge and try to understand?

Goodbye to a good friend

John from 1989It’s with great sadness that this month we said goodbye to one of our own. John Bowden (aka Led43) lost his battle with cancer on Saturday 8th March.

John was one of life’s good guys. An enthusiastic supporter and contributor, when his health allowed. Mainly as part of the QA team, almost since the beginning, but often also helping people out in the main #mageia IRC channel on irc.freenode.net

He was really an inspiration to us all. With multiple health problems and a recent bereavement himself, he still enjoyed doing whatever he was able to help the community. When he was first diagnosed with cancer he asked that, should the worst happen, his hardware be of benefit to Mageia, which just shows the kind of person he was. Our thanks to him for that. He was always positive and confident he would beat the cancer, originally wanting to be free of it by Christmas, and was hoping to be able to get everything set up to help with testing the Mageia 4 release. Sadly it was not meant to be and we have lost a good friend. He will be missed.

Our thoughts are with his family at this difficult time. The photo is an old one from 1989 chosen by his sister Judy and one he would have liked.

Still working on MondoRescue 3.2 to make it available ASAP

Even if stuff do not progrees at the speed I’d like them to progress (lots of travels on HP side since early 2014 and 4 concerts to perform on the private side) I’ve tried to improve the 3.2 version I published unofficially as beta. Interestingly enough, even when I do not announce that packages are delivered, there are people who do use them !!! Which gave me some feedback (you can guess it wasn’t that positive), so in fact it’s already my second delivery :-) and it contains some interesting new features:

  • mindi now uses the new mr-kernel-get-modules perl script which allows now in mindi to just mention end modules names andd not dependencies anymore, which are now computed by the script !! This will help a lot to maintain the list of modules, which was always impacted by low-level dependencies changes at kernel level.
  • Support of symlinks for newest distributions based on systemd such as Fedora, Mageia, … is now finally working !! Again this was done exporting the existing wrong code into a separate perl script which now operates correclty. This is part of the global willingness to recode most of mindi and some of mondo in perl. This took quite a long time, as of course, we need to stay compatible (a word systemd team doesn’t care about of course) with other tools, and older distributions. Side note, this is probably one of the reason MondoRescue is still appreciated by its community :-)
  • The introduction of a dependency on a perl function was incorrect and people trying to install from packages gave feedback that they had errors dof course ue to that. This is now fixed, as project-builder.org indeed had an issue because a low level function was depending on a higher level function not part of the perl modules provided for MondoRescue. With 0.12.5 of project-builder.org this is completely solved.
  • Now I still have regressions with the isolinux menus, NFS on Mageia 4 and systemd not working anymore (change of network NIC name is the root cause). However the ldlinux.c32 issue for syslinux > 5.x is now solved.

Next week is the TES, so won’t have much time to work on it. Expect news the week after.

Filed under: FLOSS Tagged: Fedora, Linux, Mageia, Mondorescue, Open Source, project-builder.org

Cantor’s script editor news

A small blogpost about Cantor before Brazilian Carnival parties.

KDE 4.13 is feature freeze now and I developed some improvements in Cantor’s script editor. It will be available in next KDE stable release around April 16.

Now Python 2 and Scilab backends have support to script editor! See some pictures:

python_script_editorCantor Script Editor for Python

scilab_script_editor Cantor Script Editor for Scilab

You can access script editor in menu bar View -> Show Script Editor. The script editor is based in kate-part, so you have syntax highlighting, line numbering, mini-map, and all cool stuffs from Kate. You have a Run Script button too, so you can just push this button and the script will be load in Cantor worksheet, as you can see in examples.

There is news for others Cantor backends too. Now script editor load default syntax highlighting for each backend – in old versions it did not happen. And, if you push New button, the new script editor will have the default syntax highlighting working too.

It is the news about my work in Cantor for KDE 4.13. I intent improve Python 2 backend and script editor for future releases.

But now it is time to go to Brazilian street parties! Happy Carnival! ;)

KF5 on Mageia

After some weeks of work, we now have in mageia the First Alpha of KF5.

This is the first step to have this new Version usable, as we now need to wait for the runtime and workspace pieces to be available, we miss a task-framework or task-kf5 but this will come later.

This is about 60 New src.rpms.


Have fun !

My thoughts on the default init system for Debian discussion


The Debian tech committee is deciding on the default init system for Debian. Personally I’m totally biased and think the only realistic choice is systemd. I loved Upstart when it was written, but actually I think the default init system is really of no concern at all.

What you get with systemd is something which strives to be “the basic building block for Linux” (just watch one of the presentations regarding systemd). All the other init systems either don’t want to do this, or actively strive to do as little as possible. As a consequence, loads of functionality offered by systemd is either only available with systemd, or the alternatives (Canonical logind) are striving to follow what systemd does. There could be lots of alternative implementations as various extra functionality is available through D-Bus interfaces. D-Bus means that the same functionality could be offered by something else.

Note that I read and follow loads of projects. Distribution wise I follow openSUSE, Gentoo, Debian, Mageia, Fedora and Ubuntu (last one minimally as development is not mailing list focused). Then obviously GNOME, systemd, freedesktop, KDE (very minimally), various websites, etc. I’ve noticed that not everyone reads as much as I do :-P

Relying on an init system

One item in the upcoming Tech Committe vote is the following two options

Tight coupling

Software may require a specific init system to be pid 1.

However, where feasible, software should interoperate with
all init systems; maintainers are encouraged to accept
technically sound patches to enable interoperation, even if it
results in degraded operation while running under the init system
the patch enables interoperation with.

Loose coupling

Software outside of an init system’s implementation may not require
a specific init system to be pid 1, although degraded operation is

Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.

What I don’t like

There are a bunch of things that I dislike about the current status. I think I’d do this totally differently. I like the following quote:

We work for the developer community, helping everyone to work together and make progress. We try not to get in the way.

Anyone who is working in a committee (release team/ctte/etc) has the ability to direct the project. And you’re seen and should be seen as someone who decides. The point is to serve the project and allow people to make progress. On any committee you should not decide, you’re just announcing a decision which was made by others. The same people who are asking you for a decision could be the ones who have actually made the decision. Though always ensure that everyone knows who’s in charge :-P

Lack of distinction of package importance for the distribution

Say you have a package which nobody depends on. Let’s take for example “GNOME Logs”. Nothing depends on it and it is a GUI for the journal (which comes with systemd). Meaning: it relies on a specific init system, and in this case systemd. With “loose coupling”, “GNOME Logs” would not be allowed because it only works with systemd. So I consider “loose coupling” bad. Or would “GNOME Logs” suddenly considered “part of an init system’s implementation”?.

Now consider a package which you need in the distribution. Loads of stuff depends on it and pretty much a requirement to have. With “tight coupling”, the package maintainer could just enable some systemd support, mention other support is not feasible and force the whole of Debian to whatever init system that package maintainer prefers. Allowing maintainers of low level packages to be able to change the Tech Committee decision seems bad. So I consider “tight coupling” bad.

There is a total lack of distinction between the importance of packages as well as the default init system. A low level package could just undo the Tech Committee decision with “tight coupling”. While at the same time, “loose coupling” is a bad option as well as a package which nobody depends on should be totally fine to rely on a specific init system.

Lack of importance for the default

Above choices have no relation to the default init system. Say the Debian GNOME maintainers make systemd a dependency. How is this bad if the default for Debian would be systemd? Say Tech Committe choses Upstart and Debian GNOME maintainers make systemd a dependency. Isn’t the default something that should be considered?

Both options actually encourage maintainers to ensure their packages work with multiple init systems. What if you don’t care? Accepting a patch one time is hugely different from having to maintain the patch.

Now aside from this, if I was maintaining some package that offered better support for whatever init system Debian will use by default, then I’d want to rely on it. Seems nothing wrong with this. It is the default after all.

Burden is placed with package maintainers

If “loose coupling” is chosen and your package doesn’t work with other init systems, then you’re expected to make it work. Say Debian goes for systemd and upstream removes support for anything other than systemd? Too bad, go and implement that support! Say “tight coupling” is chosen and someone offers a patch to make it work on a different init system. Lots of software now depends on this patch. Next upstream comes out and the patch has to be rewritten totally. Well, you’re the packager so good luck uploading the new version.

A one time patch is not maintenance free. The only difference to me between both options who writes the initial patch. Eventually the maintenance burden will be with the packager.

Multiple init system support is always a requirement

Both options demand multiple init system support. With “tight coupling”, packagers are still encouraged to accept patches from a different init system. The burden with “tight coupling” is just with the packagers of the other init system. With “loose coupling”, packagers are forced to ensure it works with multiple init systems.

To me it seems that either way, multiple init system is always a requirement. Just differs where the Tech Committee places the burden.

Doesn’t answer the current issues

To me it seems like the current voting options are not in line with why the question was sent to the ctte. I’ll give a few examples.

logind D-Bus API

GNOME really likes the logind D-Bus API, even if it isn’t a requirement (fallback is the unmaintained ConsoleKit). Now Canonical forked the logind daemon to offer an alternative provider for this API, this fork might be enhanced. At the moment that fork is NOT working in Debian. So can the Debian GNOME packagers or can’t these packagers have GNOME depend on logind and who should do the work?

A reminder on what “loose coupling” means:

Software outside of an init system’s implementation may not require a specific init system to be pid 1

With “loose coupling”, you could argue that an alternative exists, have logind provide a fake package such as “logind-dbus-api” and be done with it. Up to others to package the alternative. Then you can just rely on “logind-dbus-api” and you’re not requiring one init system, though in practice you are, or maybe you are not :-P.

“Loose coupling” seems the option that most of the Upstart supporters will be voting for. Can GNOME require logind API or not? There are alternative implementations. The Canonical fork will likely work with Upstart. But what about other init systems? If those alternative implementations aren’t available or working under all of the init systems, then you might end up requiring a few. Is this bad or not? Or is “a specific init” bad if you want one, but ok if at least two are supported?

I notified the GNOME distributors about this freedesktop.org change back in January 2012 (started with ConsoleKit deprecation, I already wrote multiple blogposts about ConsoleKit and logind explaing this in great detail).

UPower 1.0

For UPower 1.0, some functionality is removed and instead you’re expected to rely on systemd (or anything similar, in practice there is nothing else AFAIK) as that already had the functionality UPower was offering before. This functionality will be gone. With “tight coupling”, that’ll force systemd slowly in more and more things as whatever relied on UPower, now also should have systemd as a dependency. With “loose coupling”, I guess loads of patches in the packages making use of UPower 1.0 to duplicate the functionality UPower 1.0 offered before? Or maybe change UPower 1.0 and make the API different between Debian and non-Debian? It all doesn’t really make sense to me.

I notified the GNOME distributors about this freedesktop.org change back in October 2013.

Glosses over the ability to provide alternative implementations

Say a package requires a D-Bus API provided by systemd, but it could be reimplemented by something else? I fail to see how that is a bad dependency to have. What matters is the interface is implementable by something else. If the API is stable or not. These things should be taken into consideration IMO. It seems to not have been considered at all.

I think it is much better to quality in what way dependencies are allowed. A dependency that currently is tied to a specific init system, while it doesn’t have to be, seems like a totally ok dependency to have. If it is important then someone will eventually do the work. If not, it wasn’t important enough.

CTTE seem to have skipped opportunities for a more thorough analysis

In the whole discussion, I never saw anyone from ctte mention that Debian/Hurd doesn’t make use of sysvinit. I have the strong suspicion that nobody from the Tech Committee went out to ask the porters for their ideas. Then again for the various package maintainers. There was a call, some people who maintain a wiki page, that is it. The problems which resulted in this issue to be raised to the Tech Committee: I don’t think any of the current voting options is going to give satisfactory answer.

Same for checking other distributions. Even Gentoo allows packagers to depend on specific init systems.

Lack of importance of impact on QA

Loads of distributions have switched to systemd. Especially the distributions with a lot of people behind them (paid or not). Now even Gentoo is ok with a systemd dependency. On Gentoo the packagers added a systemd dependency since a few months ago. I know that on Mageia the period where we tried to support multiple init systems had a bad impact on QA. Mageia got way more stable after we switched to systemd only instead of trying to support multiple. There was also a period where Gentoo provided a lot of fixes to GNOME to solve the various bugs GNOME had with trying to support both. But since then loads of code has been moved around. Debian is going to be facing such bugs for the first time with almost nobody to help them out.

Now obviously Debian has loads of volunteers so given enough time and effort everything gets fixed. But it seems pretty much a given that there is a huge extra burden that will be specific to just Debian. The impact on QA (and thus your release schedule) seems like something you should consciously consider.

Consideration to meritocracy

Mageia switched to systemd because everyone who works on the low level bits wanted it that way and they made it happen. To me it always seems good to give consideration to what the people who do the most work in the affected area think. I have no idea though what the ideas are amongst them in Debian.

Guaranteed to be followed up by a GR

I’m pretty sure this will result in another vote, but then open for all of the Debian developers. I don’t like “gut feeling”, I prefer meritocracy. I think it’ll be decided by the gut feeling Debian developers have.

Basic building block vs nothing

To me, the Tech Committee voting is inadequate and misguided. One of the choices strives to be a basic building block. There are interfaces with stability guarantees, but other init systems would just be followers. Further, as systemd strives to be a basic building block, various other projects have or are going to rely on the offered functionality.

Theoretically such functionality can be offered by another init system. Which I like. But currently the Tech Committee seems to have the opinion it is just an init system discussion. This seems an awfully simplistic assumption.

Debian/Hurd and Debian/FreeBSD

Already various differences

Various people really care about Debian/Hurd and Debian/FreeBSD. I find it terribly odd that various people think that there is a requirement that every software should be available under every port. This in direct contrast with the current situation. Debian/Hurd does NOT use sysvinit. According to a porter, sysvinit is not portable. For Debian/Hurd a few hacks had to be added to work around assumptions. On both ports it relies on Linux compatibility layers.

I don’t really understand the purpose of Debian/Hurd and Debian/FreeBSD. By some people, it seems that every current Debian package works under those ports. No matter how low level that package is, it MUST be portable. By some others, FreeBSD offers ZFS and using that on your server in combination with having “apt” is great.

To me it seems terribly odd to have the assumption that everything should be the same while it isn’t at the moment.

Already GNOME barely works on the ports

Another huge problem seems to be that the GNOME packagers want to rely on systemd. This would exclude GNOME from Debian/Hurd and Debian/FreeBSD. However, most GNOME packages already do NOT work on any of the ports. That GNOME works on the real FreeBSD doesn’t mean it automatically is in great shape on Debian/FreeBSD! So there is no practical change, though now people notice the actual situation. I guess it is easier to just assume Debian/Hurd and Debian/FreeBSD are at a good level and a “default system init” has a noticeable impact. It does not. The Debian GNOME packagers wanting to add a dependency is of similar unimportance.


None, I’m just following with interest.

Mageia 4 on time for Fosdem and …

Anne has announced that Mageia 4 is now available just on time for Fosdem !

I updated all the computers at home without any trouble (two under Gnome Shell, one under KDE, and the last one now under Cinnamon).

We did a full review of the Python stack, now Mageia provide byte compiled Python modules, and as you can see in the Mageia Applications Database, here there are a lot of new Python and Python 3 modules.

I'm also really happy that Bruno packaged Ansible my favorite IT automation tool, with a urpmi module.

Mageia have also new scientific, engineering softwares like OpenFoam, Su2, Paraview, ...

For the next months, I will try to give more time to the Security team to help them for security updates, and also the Sysadmin team to work on an Mageia version of the Fedora tool fedmsg, because it seems we need somthting like that for our infrastructure.

Thanks again, all Mageia's contributors !

Mageia 4 on time for Fosdem but …

Anne has announced that Mageia 4 is now available just on time for Fosdem !

But I won’t be at Fosdem this year again (I’m attending an HP event instead)

And while there are good reasons for Mageia to be my distribution of choice, I won’t update my laptop this week, as I’m presenting during this HP event, and want to stay on the safe side. And for my home computer, well, I generally do it after my laptop ;-)

But anyway, great job done by the Mageia team and lots of good apps in this new version, including OpenStack and UEFI ! Enjoy and try it. It’s really worth it !

Filed under: FLOSS Tagged: Event, Fosdem, Linux, Mageia, Open Source, OpenStack, UEFI