Home Home > 2016 > 01
Sign up | Login

Archive for January, 2016

Running live image from RAM

January 29th, 2016 by

Some time back I wrote a patch to KIWI that allows running openSUSE live entirely from RAM(tmpfs).

A brief 360° overview of my first board turn

January 18th, 2016 by

You’ve certainly noticed that I didn’t run for a second turn, after my first 2 years. This doesn’t mean the election time and the actual campaign are boring 🙂

If you are an openSUSE Member, we really want to have your vote, so go to Board Election Wiki and make your own opinion.

The ballot should open tomorrow.


Why not a second turn?

Being a board member (present at almost every conference call, reading the mailing lists and other task) consume free time. It has increased during the last semester too. And we’ve got some new business opportunities here at Ioda-Net Sàrl in 2015, and those need also my attention for the next year(s). I prefer to be a retired Board member, than not being able to handle my responsabilities.
But I’m not against the idea of a "I’ll be back" in a near future. Moreover with a bit more bandwidth in my free time, I will be able to continue my packaging stuff, and other contributions.

What a journey!

With the new campaign running, I found funny to bring back to light my 2013 platform written 2 years ago. And spent 5 minutes on checking the differences with today. I’m inviting you to discover the small interview between me and myself 🙂

1. Which sentences would you say again today?

I’m a "Fucking Green Dreamer" of a world of collaboration, which will one day offer Freedom for everyone.

Clearly still a day by day mantra and leitmotiv. But even if I’m dreaming, I never forget that
Freedom has a price : Freedom will only be what you do for it.


Li-f-e at BITA Show 2016

January 10th, 2016 by

BITA IT Show, the biggest IT exhibition in western India is coming to town on 24-26 January, We will be there promoting Li-f-e. If you are in this part of the world, drop in to check it out.

Highlights of development sprint 13

January 7th, 2016 by

As promised in the previous post on this blog, we’ll try to keep you updated about what is happening in the YaST world. Before Christmas we finished an specially short sprint, interrupted by another successful Hackweek. Although we always reserve some time for bug fixing, the last two sprints has been quite focused in looking into the future, implementing new solutions for old problems and trying to prepare replacements for some legacy stuff we have been carrying on for too long. Here you are the highlights.

SCR replacement

For low level access to the system, YaST uses its own library called SCR, inherited from the old YCP days. It’s used to call scripts and also to read and write files. Its design is showing its age and using it from Ruby is unnecessary complex. We feel SCR is one of the biggest source of confusion for newcomers to YaST development. Last but not least, SCR is only used by YaST which means all the maintenance work fall to us.

We want to use a new approach for the future. For running scripts we plan to use a Ruby gem called Cheetah and for accessing configuration files we plan to rely on Augeas.

Taking some improvements that were needed in YaST2-Bootloader and the drop of perl-bootloader as starting points (or as an excuse, if you prefer), we have used this sprint to develop all the moving parts that will allow us to easily use Cheetah and Augeas within YaST.

For Cheetah, we have contributed two features to the upstream project: chroot support and the ability to provide environment variables.

For Augeas we have developed an object oriented layer called Config Files Api (shortly CFA). The idea of CFA is to provide specific functionality by mean of plugins. Of course, the first plugin we have developed is aimed to manipulation of all the Grub2 configuration files.

The next step will be to integrate these new components into the next versions of YaST2-Bootloader, hitting your Tumbleweed repositories soon. Of course, after all the usual manual and openQA testing.

Libstorage replacement

Another low level layer that has been a constant source of headache for YaST developers is libstorage. We use it -specially in the installer and the partitioner- to access disks, partitions, volumes and all that. Once again, the original design have fundamental flaws that limit us in many ways and we have been dreaming for quite some time about writing a replacement for it.

To make this rewrite fit into the Scrum process, we are using the new redesigned library (find the code at Github and the packages at OBS) to write prototypes for the installer partitioning proposal and for a new partitioning YaST module.

This new module is only intended as a testbed to showcase the development of the new library and to drive its integration process. It’s not intended for end users, but after this sprint it can already do some things that are impossible with the current partitioner and even shows some nice graphs really useful for debugging and verifying the behavior of the library.

Libstorage Tech Preview: action graph

If you don’t mind to break your system using unsupported software, you can always fetch the code or the packages.

AutoYaST integration tests

Testing is crucial in software development. And integration tests are a must when you are developing an installer. During the last sprints, we have been developing and improving our own solution for testing AutoYaST-driven installations, consisting on a set of tests and a framework to run them.

The goal for this sprint was to de-couple the tests and the framework. Making it possible to reuse our tests in openQA. As a side effect, we wanted to ease the installation and usage of our testing framework.

Both goals were achieved, now you can install AutoYaST Integration Tests (not a very original name) following the instructions available in the repository and there is already an openQA instance directly running the separately available tests.


Snapper development documentation

Last but not least, as a side effect of the development (and the Scrum principles), we have improved the Snapper’s development documentation. Enjoy it at the usual Snapper repository.

That’s all folks. Next sprint starts next week and will be three weeks long, so expect more news during the first days of February.