Planet Ergo

I recently, very recently, purchased a Lenovo X220, fully beefed up with an i7 processor, 8GB of RAM, and the largest SSD (Intel 160GB), amongst other things.

Installing Fedora 16 (of course) went smooth (as was to be expected, as I know other people with Lenovo X220's). It's nicely locked down now, with startup, BIOS, GRUB passphrases, limited boot devices (SSD only) and an encrypted VG -which I can afford doing now without slowing down the entire system too much.

As a Kolab Systems employee, running multiple Kolab servers, naturally I install Kontact, the Kolab client, and I tend to do this using a fresh install (i.e. no copying data from the old laptop, no upgrading).

Fedora 16 includes a 4.7.4 KDE PIM stack, which turns out to not work for me. Having configured the Kolab accounts, it seems I cannot get to the messages in my Kolab INBOX -other folders work just fine.

In any case, I decided to try rawhide; the version of the KDE PIM stack included in rawhide at this moment is 4.7.95, KDE's latest release en route to 4.8 - this too, however, did not work for me.

So, I decided to try and build from GIT - my first time ever. KDE has a utility for this, called kdesrc-build. It's use is pretty straight-forward, but I had to install some build requirements on my system. This is what I have installed now:

# yum -y install \
    alsa-lib-devel attica-devel avahi-devel boost-devel bzip2-devel check-devel cups-devel \
    cyrus-sasl-devel dbus-devel dbusmenu-qt-devel enchant-devel fontconfig-devel \
    freetype-devel gamin-devel gettext-common-devel gettext-devel giflib-devel \
    glib2-devel glibc-devel glib-devel gnutls-devel gpgme-devel grantlee-devel \
    gstreamer-devel gstreamer-plugins-base-devel herqq-devel ilmbase-devel jasper-devel \
    kdebase-workspace-devel kdelibs-devel kdepimlibs-devel keyutils-libs-devel krb5-devel \
    libacl-devel libattr-devel libcom_err-devel libdrm-devel libgcrypt-devel \
    libgpg-error-devel libical-devel libICE-devel libjpeg-turbo-devel libpng-devel \
    libselinux-devel libsepol-devel libSM-devel libstdc++-devel libtasn1-devel \
    libudev-devel libutempter-devel libX11-devel libXau-devel libxcb-devel \
    libXcomposite-devel libXcursor-devel libXdamage-devel libXext-devel libXfixes-devel \
    libXft-devel libXi-devel libXinerama-devel libxkbfile-devel libxml2-devel libXpm-devel \
    libXrandr-devel libXrender-devel libXScrnSaver-devel libxslt-devel libXt-devel \
    libXtst-devel libXv-devel libXxf86misc-devel libXxf86vm-devel mesa-libGL-devel \
    mesa-libGLU-devel mysql-devel OpenEXR-devel openldap-devel openssl-devel \
    pcre-devel phonon-devel polkit-devel polkit-qt-devel PyKDE4-devel PyQt4-devel \
    python-devel qca2-devel qt-devel qt-gstreamer-devel qtwebkit-devel raptor2-devel \
    shared-desktop-ontologies-devel sip-devel soprano-devel sqlite-devel strigi-devel \
    xorg-x11-proto-devel xz-devel zlib-devel

Consider installing the "Fedora Packager" group as well;

# yum -y install @fedora-packager

After following the setup instructions, you should first initialize your copy of the various sources (otherwise failures would cause you to need to manually cleanup subversion repositories, for example):

$ kdesrc-build --src-only

This, when you run it for the first time, can take quite a while.

Once it's done, you can start building stuff:

$ kdesrc-build

This, too, can take quite a while. Furthermore, it requires a lot of energy, and drains my 7.5 hour battery life in about 90 minutes ;-)

UPDATE^1: The build dependencies for gwenview need to be added to the list of build requirements; exiv2-devel.

I'm having a great time at FUDCon in Panama. For one, the weather is much better then back in Wales... :P Parties are at the villa of les Chiles Loco (the crazy Chileans), and last untill about 3am in the morning. Plenty of beer and plenty of barbeque steak usually do the trick for me :)

My first session on Thursday, titled "Why You Are All Idiots", was post-poned because someone from Dell needed to have his session on what seems to have been the busiest FUDCon day so far. Irony has it, the talk was on "Virtualization with KVM", and while my schedule was freed up, I went to assist Dell Panama with their KVM / Live-migration demonstration setup they were going to show on Friday :)

So, after all, my first session was on Friday, and on "Cloud", following two other presentations on virtualization, and the second was on "Software, RPM, Packaging, Guidelines and Build Systems... but why?", starting off in a small series of talks on packaging and the koji build system.

Other people are having many interesting talks as well -but in Spanish. Since I only hablo pocitto espanol (and that's about it), it is sometimes hard to follow. For most of today -outside of my "Why You Are All Idiots" and two lightning talks, I've been working to get a working GNOME3 desktop environment on my laptop.

Looking forward to FUDPub.

Please allow me to describe my day of travelling yesterday;

Having woken up at 05:30am ET, I started at Detroit airport, as I just so happened to be in the area already. From Detroit, a Continental (now United) flight to Newark (oops, high building, zig, oops, high building, zag, touch-down). Short layover, continued my trip to Miami -from the air it looks much like in the CSI series.

Note to self: do not wear black shoes, black trousers and a black T-shirt when travelling through Miami as you have to go outside to the designated smoking area which has no shaded area anywhere near it.

From Miami, I had an endurable Copa flight to Panama City, where immigration lines are as bad as they are in the U.S. Alejandro picked me up, dropped me off at the hotel, and took me back to Cuidad del Saber, where I met up with the rest of the guys -about 18 hours after I started.

One too many beers and a barbeque later, Alejandro drove me back to the hotel for some well-deserved, long-needed rest.

Today, I've been preparing some of the sessions I'm going to pitch or try and squeeze in the schedule, including but not limited to the following titles;

• Cloud
• Why You Are All Idiots
• Software, Packaging, RPM, Guidelines, Build Systems... but why?

I suppose other sessions I could/should also be doing are on Spins, Fedora Trademark / EMEA / NPO, Extended Life-cycle Support, Configuration Management with Puppet and Fedora in the Enterprise. I can pitch'em all, but I'll have to see which ones actually make it on the rather tight schedule ;-)

I recently purchased a SIP phone, one of those hardware devices, so I'm now online on Fedora Talk as well. It's not that softphones such as Ekiga or Twinkle wouldn't work, they just wouldn't work as well while I'm connected to a VPN (with my laptop). A Siemens C475 IP DECT solves the problem of lag for me ;-)

I'm on extension 5100680, so if you need me, and you have Fedora Talk, give me a quick call!

In response to Mairin Duffy, whom, by the way, I respect very much, and I think deserves your respect as well.

Mo does an awesome job engaging an audience in Free Software that would have otherwise be left to their own fate wading through a hell for the rest of their lives, an audience that would never have been moved by us mortals focused on the technical side of things. I can't wait to hear of the results on SXSW, honestly. Note I know I'm leaving out an awful lot appreciation for other work she's done [for all of us] over many, many years of passionate engagement in what you probably care just as passionately about, as does the rest of us.

That said, however, on the subject of ownership... yes indeed we do make it. That doesn't say anything about the ownership though. I think every single one of us community members have given the Fedora brand the value it has today. Though I'm doubtful it requires the level of, or means through which it is getting such, protection to date, I do realize how something as valuable to so many of us must have someone be the owner in order to protect it.

However, history shows us that the people giving something value, and as such own that something, are not necessarily the ones deciding what to do with it. This, I think, is the underlying thought behind the recent protests - not whether we make it, but to what extent we actually own what we make.

My blog is now included on Fedora's "Planet Edited" - mind you various people won't like me for calling it censored. Originally, I thought the censored version of planet was going to filter out the 'I had this-and-that for breakfast' type of blog posts, which, usually anyway, have nothing to do with Fedora at all. However, after some clarification from Andrea Veri, it seems a relation between the posts content and Fedora isn't sufficient - the blog post must be specifically about Fedora.

I suppose what this will result in is a series of blog posts from team leaders and whatever other semi-official titles you can attach to the wide variety of Ninjas within the Fedora Project. Speculating about content, I can think of announcements, progress reports, invititations to attend meetings either in person or virtually, but also; event reports from our Ambassadors, speculation on pre-mature ideas and concepts, and blog posts like this one, from... let's call'em "opinion-makers" shall we?

I think that's great. It's censored, as technical posts like my post on noop I/O schedulers in KVM environments through Puppet and Augeas apparently do not seem to fit the filter "about Fedora" though I think they are related to Fedora or at the very least interesting to some small amount of Fedora people. However, as I've said, my misunderstanding of what the censored version of planet was about was clarified.

Ultimately, Planet Edited is what our dear self-regulating community should want from the original planet - but without the censorship. Somehow people on the original planet are unable to, forget or refuse to show constraint in what they'll make end up on the Fedora Planet... they omit the appropriate tagging or include an all inclusive feed on Planet. I'm one of those people including their entire blog on planet, but then again bits and bytes in Free Software is about all I live and breath for.

Let's not forget it is planet.fedoraproject.org that now has a moderated version to achieve the exact same measure of control over content, but top-down. It's supposed to work the other way around... anyone of us should show constraint pushing something out to planet, asking "Is this what I would like to see others post to planet?" - bearing in mind I lose it every once in a while, too. Now though, Planet Edited is going to make people feel excluded, not necessarily a positive influence on anyone's gut feeling. The people with their blog included in the edited version of Planet -like me- are now on some sort of virtual pedestal, with more exposure to the general audience - also the electorate. I think the moderated version of our planet is restrictive, divisive and exclusive, whereas I would want our community to be more inclusive - and yes that includes girl scouts.

For a virtualization environment, it often makes sense to use a kernel I/O scheduler that does not take into account whether and/or which hardware seek time penalty may or may not be applicable for the disks used. Hence, where in my case I use a storage device over iSCSI, I want to set the noop scheduler for the hypervisors (which use iSCSI), and all guests on it (which use logical volumes). Neither the hypervisors nor the guests will experience a seek time penalty, so I thought, and so scheduling their I/O does not need to be optimized for such. The noop scheduler does exactly that.

On a side-note: Luckily, all guests run Linux ;-)

Using Puppet and Augeas, it's particularly easy to just manage the kernel cmdline options. In the Puppet manifest:

    # If the system is virtualized, just use the noop I/O scheduler
    # for all block devices
    if ( $is_virtual ) {
        augeas { "kernel_elevator_noop":
            context => "/files/etc/grub.conf",
            changes => "setm title kernel/elevator noop",
            onlyif => "get title/kernel/elevator != noop"
        }
    }

To change the I/O scheduler during runtime, just use:

# echo noop > /sys/block/<device>/queue/scheduler

For a full, more verbose description of what to do (including loading the necessary kernel module, etc.), check out this awesome, short walk-through.

For some reason, the audience at Barcamp today decided to not vote en-mass for my session on Fedora Extended Life-cycle Support, so I only got 21 votes. 21 votes by the way is an awful lot in comparison to previous FUDCons I've been at, I suppose the sessions that did make it must have had 30+ votes each! My session on Packaging for ISVs didn't make it either, FWIW.

Whenever you see Max Spevack wearing his birthday present T-shirt today or tomorrow, please do bet him one american dollar on something ;-)

It's the start of day -2 of FUDCon Tempe, good morning!

On today's schedule: preparing sessions on ISV packaging, with a real-life scenario revolving Kolab Groupware, a session on Fedora Spins and the Fedora Spins SIG, and perhaps I get around to preparing a talk on Ruby today as well.

Max again is tied up in meetings, as are his companions, however I'm no longer all alone here in the main hotel; Ben "Southern Gentleman" Williams has arrived, and so has Ian "ianweller" Weller.

I start this post with a little story-telling on some "horrible" traveling; Arriving at Cardiff International Airport, it appeared my flight to Amsterdam was cancelled. It's a regular service, but the delay was still 4 hours. I was planning on an overnight stay with friends in the south of the Netherlands, a good 2 hours of travelling by train away from the airport, so obviously I arrived there a little late; 22:00 or something like that.

The following morning, I had to catch a plane at 10:25 in the morning, so my departure from my overnight stay was a good 6:00 in the morning (boarding time on US flights starts 2 hours in advance, and they have strict rules on accepting check-in luggage, too). 22 and a half hours later, I'm sitting in the Marriott Courtyard Hotel, FUDCon's primary lodging location, sipping a beer with Max Spevack. 22 and a half hours... it's not fun. I can confidently state, endangering repetition; I love to go places but I hate to travel.

Anyway, Ryan Rix and Robyn Bergeron met up with us, and I just have to quote Robyn saying:

"No, Ryan, she was all over your buttons."

'nuff said. After picking up Harish Pillay from FUDCon's secondary lodging location, we had dinner at what is called a Tavern right across the street.

Long story short, today Max and his companions are in meetings all day, so I'm all alone in the hotel lobby bogging the free wifi.

Preparing my slide deck for a session on Fedora's Extended Life-cycle Support (ELS) initiative, sub-titled "the why, the what,  the how and the who", I figured I might as well publish them here -since so many people can simply not make it to FUDCon, however regrettable.

So, attached to this post is a bunch of slides on the subject. I hope you enjoy!

You are somewhere in a Sun Belt state in the U.S., and it's nearing the and of January. For some, this sounds like a hopeless situation. For others, it is the opportunity of a lifetime!

Here's 10 things to do in Tempe, Arizona, nearing the end of January, 2011, while FUDCon is taking place.

1. Bacula Backup and Recovery; Get some insight on the subject and engage a Bacula Systems Certified Trainer on the subject. I'd love to insert a "Tuesdays at noon" type of thing, but we're just not sure when exactly such sessions would be taking place. It's not important either, there's at least 9 other things to do!
2. Koji Build Systems. Do you use it? Do you use it because you need something happening downstream? Are you a third-party repository enthusiast? Let's get to it, and have at least one session on the build system suite.
3. Long Term Support (LTS), Extended Lifecycle Support (ELS), or whatever you may want to call an extention on the regularly supported time period of updates coming to a stable Fedora release. I like the latter terminology better. If you're interested in stopping it though, please stay away?
4. Spins. Custom spins, localized spins, remixes or bluntly put, dwarf forks. How can we make sure all this momentum is harnassed and nurtured up and until the point little projects become proud masters of the universe with our help.
5. Packaging Guidelines and the Package Review Process. I've had my share, how about you?
6. Cyrus IMAP; first-hand experience of a) How Fedora Rules the Universe, b) What Upstreams Expect From Distributors and c) How To NOT Behave As A Distributor.
7. The Ever So Awesome Fedora Cloud. I'm not sure where it's at, but I do think I know a little something about what cloud is all about. It's time to get that first concept implementation for Metadata DNS going, while showing off a complete Open Source stack for Any Company(TM) in a demo-environment with public access of sorts.
8. Fedora Hosted Groupware. I know Fedora Infrastructure to have looked at Zarafa, not to say I have shamelessly plugged it back in the day. In the interest of full disclosure, I now work for Kolab Systems -another Groupware ISV, this time fully open source and free software.
9. Puppet. Modules. Modules. Modules. Cross-platform consistency. Approaches. Packaging. Writing modules (why and how)
10. Beer, meat (that's me), friends, laughs (that's me too!). I can think of very little more I need in life.

Unhelp! My broadcom wireless, which I reported to have been broken, miraculously started working again!

It must have been something I did... but I don't remember :( I know I kept the notebook upside down for a while... maybe that's it!

Help!

My broadcom wl stopped working!

Since I just use the Acer Aspire One as sort of like a radio station (BBC 1Xtra is available through iPlayer only from within the UK), while my main workstation is connected to a VPN making it appear as if I'm in Switzerland... it's not that great a priority.

Thought I'd share ;-)

A Fedora Remix is available for testing purposes, and for a "popularity contest", that is a Single CD Installer.

What is a Single CD Installer?

This Single CD Installer is installation media intended to be used for quick, base installations of Fedora, contained on a single CD image. As such, it will get you a basic Fedora installation with only the packages installed that you need to continue to build your server or desktop after the initial installation.

It includes no modifications to the installer image, and no updates to the original packages released with Fedora 13, and should therefore be considered very lightweight installation media as opposed to a CD image set or DVD image.

What's different with the Single CD Installer media?

Because there is no packages available to select on the media, the Single CD Installer media includes a kickstart, used with the default ISOLINUX menu option, to skip package selection during the installation procedure. The packages selected all fall within the Core and Base package groups, resulting in about 405 packages to be installed on the new system.

This is the exact same behaviour as if you were to manually deselect all package groups and categories in the regular installation procedure, but for the Base package group.

Where to get the Single CD Installer media for Fedora 13?

We prefer distribution through Jigdo, as it is more efficient then torrent, but for your convenience, we have included torrent downloads as well: i386 and x86_64. You can find the Jigdo here.

Reporting Errors

Please use the Fedora Unity Bug Tracker for reporting errors.

Dear Red Hat,

please do not abuse the privileges your employees have on Fedora Project's systems to enable two of your employees to make CVS commits to packages I own without any prior communication whatsoever.

Please consider the possibility that some of us voluntarily put significant amounts of work towards your upstream, and may experience the aforementioned as offensive and degrading.

It would have been just as effective to contact me prior to forcibly giving two of your employees co-maintainance, because frankly I'd feel honoured that Red Hat has a stake in one or the other package I own or co-maintain. It's the fact nobody asked me anything -or even told me- that offends me.

Despite the fact that the employees in question are relatively new to Fedora (their accounts have been registered within the past two months), I don't know where they come from nor what their respective history in Free Software is. For all I know, they may be very experienced and skilled packagers, and they may perfectly well know what stake I hold in my packages -and I primarily have a stake in the packages I own, or I wouldn't be the owner- but I have trouble trusting new users to commit to about 1200 packages all of a sudden.

Kind regards,

Yours sincerely,

Jeroen van Meeuwen

So, I've finally done it, and I'd like to think I've come a long way.

Having focussed on how to make available for everyone, Ruby 1.9.1 without the implied requirement of having to run an unstable Rawhide and us (the Ruby SIG) running around in circles trying to figure out stuff as we go along, meanwhile compromising the development path of a single Fedora release (6 months, you know, is very, very short, especially with freezes and deadlines and such).

Ergo, here we go with a repository for all enthusiasts: http://mirror.nl.ergo-project.org/repositories/feature-f12-ruby-1.9.1/

For a proper installation of the configuration of such repository, which still is in the "let's figure this thing out" stage, use the -release package; It'll install the yum repository configuration for you.

Please, pretty-please provide your feedback. You can reach us over the Ruby SIG mailing list, or me personally via commenting on this blog post, or sending me a message at jeroen.van.meeuwen@ergo-project.org.

Worth mentioning is that I've made sure the minimal stack allows installation: ruby and puppet. If not your own personal development laptop, at least you can continuously manage a set of servers running with this Ruby 1.9.1 stack, and thus revert any change that does not break puppet itself ;-)

Software packaging... *sigh*

There's too many systems, and too many platforms required to build for each of those systems. Hence, I'm submitting the Debian packaging and build toolchain to Fedora.

I've started with packaging debhelper, debconf, po-debconf, dh-make and pbuilder. I've also submitted them to Fedora for review. If you have a spare moment, please chime in on the following bugzilla's:

• debhelper
• dh-make
• debconf
• po-debconf
• pbuilder

Next on my list are:

• debomatic
• cowbuilder
• debianutils
• debootstrap
• devscripts

After a short visit to Linux Solutions in Paris, I've been working with Xavier Lamien on setting up Koji for RPM Fusion. We would make full use of the External Repository support, in order to import Red Hat Enterprise Linux (RHEL), CentOS, Extra Packages for Enterprise Linux (EPEL) and Fedora, so that packages can be built for Enterprise Linux 4 & 5, Fedora 11, 12, 13 and Rawhide.

Working on such, I thought it would be nice to share a few details on the subject, such as the way I've set up tag inheritance + external repositories + free + nonfree in RPM Fusion. Hence, here's a overview diagram of how it's set up. I've also made a more extensive document on the subject, for those of you wanting to set up there own buildsystem. This however will probably become a book sometime.