Archive for February, 2010

HP ProLiant and Linux users ? You should look at SDR


As with every big corporation, sometimes you dislike what is being done in it. But sometimes, you really feel the power of what it is to belong to the #1 in IT, and feel really proud of what some of your colleagues are achieving.

The Linux on Proliant engineering team lead by Estella Jangaon really got it. And what is said in this HP magazine, page 31 is true: They improved a lot the ProLiant integration into the Linux ecosystem, as well as Linux support on ProLiant.

Not only do they have the right approach to publish all drivers they can under the GPL, and to integrate them upstream, but they also modified the way ProLiant Support Packs were delivered from a compressed tar file containing packages installed with a script, to a real repository of packages, that you can point to with
and use as easyly as doing yum install hp-smh. Isn’t that great !

So I’m seeing my Debian/Ubuntu friends ranting and thinking, that everything is always rpm based and done for RHEL/SLES only. No, it’s just wrong ! You’ll recognize here the clever touch of Bryan Gartner, the man behind and LinuxCOE. So indeed, yes, you can ™ just type as well apt-get install hp-smh and enjoy the possibility to become a member of the ProLiant ecosystem and check by yourself that “Linux simply runs better on ProLiant”

So if you dream to test it, just read the SDR web page in order to know how to proceed.

Now I just need to improve enough so that this team can use it, and deliver also Mandriva packages and urpmi support 😉

And the best in that story, is that they remain accessible and open, as true deep technologists. So even if it’s not usual in corporation to distinguish individuals, be sure that without these individuals we, HP Open Source and Linux community members, would not be able to be proud of where we are today. So kudos to Estella and Bryan, and keep up the excellent work. to include rpmbootstrap


The upcoming version of will provide a new package called rpmbootstrap. Easy to guess what it does no ?!

Well for those of you Debian/Ubuntu/… fans, who already routinely use debootstrap, it will be no surprise. rpmbootstrap aims to become the debootstrap of rpm world. So it will allow you to create chroot (VE in pb terminology) for supported rpm based distro, in which you’ll be able to do what you have to do. And for pb, what it has to do is building packages.

So the first good news, is that pb in 0.9.9 will support both debootstrap and rpmbootstrap out of the box (on top of rinse and mock). The second good news, is that rpmbootstrap will be delivered jointly with it, trying to follow rpm distros evolution and providing an easy to build VE to build packages in them. Of course, you’ll be able to make a snapshot of that VE to always start over from a known state.

I was initialy tempted to continue to make patches to rinse. But I soon realized that the version I had was a bit far from what rinse provided, without benefiting from the integration I wanted for pb. Also, I couldn’t easily benefit from all the low level libs I now have in perl to help me deal with distro and conf files very efficiently.

I already had the centralized post-install script written for rinse, that I could integrate easily in rpmbootstrap. And writing just that new script took me some 8 hours. Was very easy with the libs ! And now I have a fully integrated solution to cover the whole build lifecycle. I tested it successfully with fedora 12, and I now need to check with other older Fedora distro, and add support for urpmi for mandriva and zipper for opensuse. As well as some tests with RHEL and SLES. But the whole infrastructure is there, just a couple of conf files entries are needed and a bit of code around.

Now, once I solve the package signage on rpm side (using a gpg-agent from perl), I’ll be able to publish version 1.0.

New MondoRescue committer


Building a community is difficult. But maintaining it is as well. Sometimes people involved in projects see their interests changing, and the MondoRescue project is like any other here. Andree Leidenfrost seems to have less and less time to dedicate to the project, and I can understand that easily, having met him in Australia back in 2007, and knowing his involvement at work and also the new challenges he has in his personal life. Anyway, Andree stays in the project and can contribute as long as he wants as I’m trusting his submissins, and ideas around the project.

And today, a new committer just did his first checkin into the Subversion tree !! So it’s really nice to see that other long time users of the tool, are becoming more and more interested in it, up to the point of wanting to dedicate a bit of time. So welcome to Victor in the team, and I hope this is just the start of a long collaboration 😉

But even if you’re not able to commit patches to a prject, there are multiple ways of being useful to one: help each other on the mailing list, create bug reports, translate the documentation, or messages, improve the Wiki, or the documentation, … or simply use the tool and report bugs or enhancement requests. All thoese activities are needed to have a project remaining alive. And I hope that this year will see more and more good new around the MondoRescue project; so that it delivers always more services to its user base.

FLOSS needs more standards


Following Fosdem 2010, I’m more and more convinced that in order for our community to progress more rapidly and deeply, we need some more standards to build upon.

I’ve participated to an excellent talk around the joint translation effort of packages cross-distributions, and we clearly need more initiatives like that.

A first one I’m thinking of is a Changelog format standard. The FSF is pretty evasive on it, and many major FLOSS programs have completely different format. I think we now have the sufficient maturity to delegate to the Linux Foundation the realization of a ChangeLog format standard that will contain all the info needed and able to be processed automatically. We need at least for each modification the version, the date and the authors, maybe a tag/id, then lines describing what has been done. I’m sure some other clever people will find more useful info to add, but that should not make 20 pages of specifications. And after that it’s defined, every GNU program could adopt it, as well as the Linux kernel, Apache projects, … and that would help a lot in order of automatic processing of them (for creating some content in packages, to rewrite svn2cl, cvs2cl and create git2cl, hg2cl which would then be more obvious).

Of course, we should also work at improving the LSB and its FHS. Too many packages today place tools in different places for no good reason IMO. Again maturity is high enough to standardize all those places, making cross-distribution work much easier, as well as ISVs work ! Why would partprobe be in /bin on one distro and /usr/sbin on another 😦

There are sufficient reasons to have differences. And we all like that. But we shouldn’t create artifical ones ! So each time it’s possible, we should group and remove all those useless differences which do not bring added value, but create more hassle to deal with Linux. Using the mailing list is a very good start which should be encouraged.