Last week I was at LinuxTag in Berlin. It was a great event. This time it was my second year there. I really enjoyed the first year and so I did this time as well. I spoke to many people, learned new interesting stuff and my todo list got again somehow longer 😉 And I believe that I also showed some interesting stuff to the people at our booth. I was speaking about GNOME Shell to anybody who happened to be nearby and everybody liked it! Good work, GNOME guys!
I’m glad I was able to be there and I want to share few pictures from the event with you, so even if you couldn’t make it there, you’ll see at least a little bit of what we were doing. We had a lot of fun 😉

My last but not least GSoC idea. This is about actual tool that already exists but is currently a little bit broken and needs rewrite with a bigger picture in mind.

What is fillup?

As this project is named fillup-ng, it is obviously supposed to be replacement for existing utility called fillup. Let’s talk a little bit about what fillup currently does. It is used to parse sysconfig files. These files has syntax similar to shell scripts with only variables definitions. The difference is that comments in these scripts has their meaning. And fillup is used to merge them automatically somehow. Basic operation are following. You’ve got some configuration file on your system and new version cames in from package. What now? Classical solution is not to touch anything and let user resolve it manually. But fillup can do some clever things. Sometimes you want to use values specified with old configuration file and add new settings that wasn’t available in previous version. Sometimes, you want to keep only values that are in both configuration files as old configuration options are not supported anymore. It may happen that you want to replace some variables. Probably not while installing package but when running some graphical tool… If you are interested in more details, take a look at it’s man page.

This post is about one idea for GSoC 2011 regarding openSUSE Connect. I already wrote about it some time ago, but now is time to elaborate a little bit more.

First of all, let me state, that I already found a qualified student, that wants to work on this idea and that has also some good suggestions. So I’m not searching for a student with this post, but I want to share with you the goals of this project and why I think it is important.

Last week I managed to attend virtual openSUSE 11.4 Release party in Second Life. I got registered there especially to able to attend this event so it took me some time to figure out how it all works. Although I’m still learning how Second Life works, I’m now able to perform basic tasks and move around freely. Big thanks to Morgane Marquis for helping me. I’m still learning new stuff and it’s fun.

Another of GSoC ideas that I volunteered to mentor for our GSoC was adding support for BitBake to the openSUSE Build Service. In this post I want to talk about why do I think that BitBake support for openSUSE Build Service will be useful and why do I think that OpenEmbedded is actually pretty cool.

What is BitBake? Why is OpenEmbedded cool?

BitBake is a build system used mainly by OpenEmbedded. In a way it is kind of similar to what openSUSE does for us. It takes one sources and makes it possible to build them for many distributions. There are some differences though. Let’s start with few notes a out OpenEmbedded. BitBake description will make more sense once you’ll know what OpenEmbedded is. It’s a meta distribution. You can think about it as a common code base for multiple distributions. It has many packages. It also contains distribution settings. Same source can be built in different ways for various distributions. Each distribution can choose which version of which package does it want to have in which release. It can choose package management system, preferred providers for virtual packages and many other things. BitBake is then used to build whole distribution out from BitBake recipes. From recipes that all maintainers from all distributions work on together at one place. And yes, it doesn’t support spec or dsc files. You have to write .bb files. But it will build .rpm, .deb, .opk or .tgz out of it. All from one recipe. And that recipe is easier to write and more powerful then spec. If you never tried packaging for Debian, trust me that it is also much easier than Debian packaging. I actually had a presentation on openSUSE Conference 2009 about what can be done in BitBake and how it makes packagers life easier. Let’s quickly mention few features that BitBake has.

Last week I started introducing my GSoC ideas. This is continuation of that post series. Today I’ll be writing about OpenID provider plugin for Elgg, what is it good for and why we need it.

What is Elgg and why should you care?

Elgg is a soacial networking platform. It is written in PHP and it has quite general design. It supports plugins that can change nearly anything. It also has quite vivid community around. Community that among other things provides lots of plugins. And it is of course open source. All these features were reasons why we chose Elgg as a platform for openSUSE Connect.
If you are not familiar with openSUSE Connect, let me quickly explain what is it. As you may have already guess from previous paragraph, it is social network for our (openSUSE) users. We (Boosters) are still working on if, improving it and adding new functionality. But as it now, it was already used for example for our last board elections. It also gathers various user data that can be make accessible using API. And of course it allows people to follow each other, engage in discussions or do the polls asking our community for its opinion.

You must already heard about this from everybody. Google Summer of Code 2011 is nearby and openSUSE wants to participate. Currently we are collecting ideas and mentors and we are going to apply. I also came up with few projects and volunteered to mentor them. I saw Thomas Thym introducing his GSoC ideas and I think it’s great to write a blog posts that introduce projects. So I’ll join and here comes the first project that many of you were waiting for – SaX 3.