mv(dummdida.blogspot.com, dummdida.tumblr.com)

$subject says it all.

SimpleHTTPPutServer in python

Sometimes a small HTTP server which can be used with

$ curl -T dafile dahost.local

is handy. You can use it to upload small logfiles etc without any authentication, so something like tftp.

Python's own SimpleHTTPServer is a simple webserver, but it only supports GET and HEAD requests.
By simply deriving from that class you can create a small server supporting PUT.

Mozilla's rust in Fedora's PPA Copr

Copr is Fedora's answer to Ubuntu's PPA - IIUIC, so don't nail me on the definition.
Slavek give's a nice introduction into how Copr works and what it does.

Now - Copr can be used to create public repositories for 3rd-party packages like rust - which can not (yet) land in the official Fedora repos (in rusts's case because of the bundling other libs).
I had to uploaded a source rpm of rust and point Copr to it, so Copr can pick it up and do a chroot build.
Best is that Copr is also creating the appropriate repository and you only need the following repo file to install rust with dnf or yum.

# Add the following repo file
$ cat rust.repo 
[fabiand-rust-unofficial]
name=Rust packages (unofficial)
baseurl=http://copr-be.cloud.fedoraproject.org/results/fabiand/rust/
enabled=1
metadata_expire=7d
gpgcheck=0

# And install it
$ sudo dnf install rust

In general Copr seems to be nice - it's still abit rough around the edges, but that's expected. It can surely imagine that t's going to fit well into our existing infrastructure.

[Update] The copr landing page for rust and the package rust-0.6-2.fc18.x86_64.rpm link.

ORBX.js - is no open codec

I'm by no way an expert, but until now ORBX.js is - to me - not much more than a tech demo and not "the future".

ORBX seems to be a propietary video codec, which operates highly parallel - that there is ORBX.js - a javascript decoder for this codec - doesn't help the fact that it's proprietary. So I wonder what the fuzz is all about. As said: To me ORBX.js is currently not much more than a tech demo to illustrate JavaScript's (or more it's interpreters) capabilities. And currently I couldn't find any hint that ORBX - the codec - is going to be opened - which is also not as easy, as this would involve some sort of patent audit to sort out it's patent status.

At last I at least like the fact that it's now shown that there can be highly parallel video codecs, which can utilize the GPU from a high level language.
I wonder if this can be done with Dirac.

Parallel static python checks with Makefiles

To make testing fun I looked at improving the speed of static syntax checks.
The latest incarnation is now using make targets to represent a specific checks. The nice thing about this is, that you can use Make's -j switch to run those tests in parallel.

So basically it looks like this:

check-static-pep8: $(PYTHONSOURCES:%=%.pep8)
 @echo Passed $@

%.pep8:
 PYTHONPATH=. pep8 -r "$*"

The complete makefile is here and the numbers:

Simple:

...
---
 Passed check-local
---

real 0m22.875s
user 0m20.466s
sys 0m2.158s

And in parallel:

---
 Passed check-local
---

real 0m11.459s
user 0m34.780s
sys 0m3.325s

There is so much that can be done.

Woot - Mozilla's Firefox Mobile Nigtly has WebRTC support

Once and again I try the Nightly version of Mozilla Firefox.

Today I noticed that the Mobile version of Firefox has WebRTC support. Woot!?

That means you can go into about:config and set

media.peerconnection.enabled

to true.
If you've got a second mobile device or download the nightly desktop version (and enable peerconnection there too).
Then you can visit the webrtc reference application with the first device, and enter the given URL (at the bottom) on the second device to join the session.
E voilà you've got a working WebRTC (with video and audio) connection between your two devices.

Or even conversat.io ! Yes - use conversat.io - looks promissing. Maybe even for team (ovirt) meetings?

Enjoy and feed-back.

Testing oVirt Node in 4min (video)

My focus over the last year or so lay on bringing test automation to oVirt Node.
It was challenging because oVirt Node is based on a LiveCD - at boot and post-installtion. (The whole LiveCD is used as a r/o rootfs.)

To allow an automated testing of oVirt Node, I've been working on igor. It allows us to test oVirt Node on real hardware an in VMs.

When you throw all the new features (see below - libvirt-only, new igorc, new igor events service, junit-reports for jobs) together you can do a complete testsuite run on an oVirt Node ISO with one command.

And this is how it looks (view it in fullscreen to see all the nifty details, but this will leave you without the subtitles explaining what's happening):

0 00:00:00,000 --> 00:00:00,100 1 00:00:00,100 --> 00:00:03,000 Launching igorc 2 00:00:03,000 --> 00:00:12,000 igorc (left) extracts LiveCD, creates a profile and submits a new job 3 00:00:27,000 --> 00:00:32,000 igord created a VM (right) and boots it up (from a CD derived from the igord profile) 4 00:00:40,000 --> 00:01:00,000 VM (right) boots and the autoinstall is performed 5 00:01:36,000 --> 00:01:45,000 Installation finished (Ctrl-Alt-Del is sent to the VM to reboot [that's a known bug]) 6 00:01:58,000 --> 00:02:05,000 The VM now boots from HD 7 00:02:20,000 --> 00:02:27,000 An igor-service is now started in the background (within the VM) to communicate with igord 8 00:02:34,000 --> 00:02:39,000 The igor-service tells igord about the ocmpletion of the first testcase, which is then picked up by igorc (left). 9 00:02:39,000 --> 00:02:45,000 A couple of more testcases were completed (left) and a reboot is initiated (by the igor-service within the VM) 10 00:02:48,000 --> 00:03:10,000 The VM (right) reboots 11 00:03:46,000 --> 00:03:59,000 All testcases passed and the VM is torn down by igord

This is a big step forward - even if there are still some issues outstanding to achieve the goal to make testcase development fun.

Now that we've seen the fancy part some background and open issues.
One pitfall - up to this week - was the hurdle to get igor up an running. Igor used to require Cobbler - and cobbler is not easy to setup on Fedora 18 (which I use to build an test oVirt Node - which itself is based on Fedora 18 packages).

Anyhow - long story short - Igor has a "feature complete" "backend" for libvirt now, that means, igor doesn't need cobbler anymore. Furthermore I've added a brand new igor client (called igorc) which communicates with igord (the daemon doing all the coordination work).
This client has some "advanced" features  like pretty printing of junit results (Igor offers the result of the testruns in junit's XML format).

Some open issues:

• ovirt-node needs a target to build a testable ISO
• igor needs a feature to upload testsuites from the client side

All of this is up in the igor repository. ovirt-node related patches (e.g. merging of the igor plugin are pending). Just follow the node-devel ml to see when is is ready for daily usage.
That's it for now - thanks for watching.

Rust 0.6 for Fedora

The previous draft spec wasn't able to build rust with the official 0.6 sources. The spec file is now updated and you can build your own rust package using:

$ curl -O https://raw.github.com/fabiand/rust-spec/master/rust.spec
$ nice ionice rpmbuild --noclean -ba -v rust.spec

It is assumed that you've got a working fedora-package setup and an internet connection.

Changes are mainly that chrpath is used to remove rpaths from files. Rust is still using it's own libuv and llvm.

Getting EFI (OVMF) into libvirt

Finally it's working like a charm - booting a VM with EFI (instead of a BIOS).

lersek pointed me to a page describing how to test SecureBoot with Fedora this implies the usage of EFI. And that page contains a link to an rpm carrying the EFI payload. Awesome.

After installing the RPM you only need to tell libvirt to use that bootloader instead of the default one.

All you need to do:

# Install a prerequirement
$ sudo dnf install seavgabios-bin ipxe-roms ipxe-roms-qemu

# Install OVMF
$ sudo rpm -ivh http://fedorapeople.org/~crobinso/\
    secureboot/edk2.manual-0-0.20130221.944c84a6.x86_64.rpm

# Create a VM pointing to OVMF
$ sudo virt-install --name f18-uefi \
                    --ram 2048 \
                    --boot loader=/usr/share/edk2.manual/\
                                  ovmf-x64/OVMF-pure-efi.fd \
                    --disk f18-uefi.qcow,format=qcow2,size=10 \
                    --os-variant fedora18 \
                    --cdrom /path/to/Fedora-18-x86_64-DVD.iso

That's it! I'm truly amazed.

Btw.: oVirt Node can also be tested this way. Sadly it currently crashes under EFI.

Package management w/ dnf is fast

Yum feels slow sometimes. That's not new. I was impressed by zif and how much quicker it is. And now, once again I'm impressed how quick dnf is.
Besides beeing quick - dnf is also looking quite clean.
So let's see when it get's into a prominent position, for now you can install it on Fedora 18 by using

$ sudo yum install -y dnf

The commandset is not yet as comprehensive as yums, but the basics are working.

Debugging systemd

There was this issue where oVirt Node wouldn't restart after an auto-install. systemd got blocked by something. These two links helped me debugging this issue.

Upgrading from F16 to F18 - no need for a rolling release ...

It was last week when a couple of issues summed up and forced me to think about how to update my working machine from Fedora 16 to Fedora 18.
Basically I had the choice between running a fresh (after a decent backup)  install or upgrading from Fedora 16, via 17, to 18.
In general I really prefer doing fresh installs - as you get a clean system and old cruft is removed, but this time I tried to avoid to backup all the little pieces which somehow tangent my work environment.
Those pieces ain't mission critical, it's just that re-creating them is boring.
Long story short - I just went the upgrade path, with doing a fresh install being my fallback solution.

I ran pre-upgrade on the Fedora 16, which initially failed (It got confused by the EFI setup), but this could be fixed by manually adding the grub entry for booting up pre-upgrade.
It took a couple of hours until the upgrade was finished. But everything seemed to work. After trying a couple of applications, I installed fedup and - just waited. It felt a bit longer but also finally succeeded.
I was a bit concerned right after the update, because I was confronted with a dracut rescue shell. But a reboot helped.
It seems that there is a time out for lucks prompt, which drops you to the emergency shell in case you don't enter the password in time.

Now, two days later, everything is still working. Only the kerberos client UI is missing and I had to install realmd.
The thing about this is, that I actually didn't expect this upgrade path to work. I expected more hassles.

A package for rust - Mozilla's experimental language

Mozilla has picked up a language to address a couple of common issues in coding. The language they picked is rust.
It doesn't fit into my current environment, but it has some nice features, like lightweight threads (green threads) and message passing support which make it interesting for me to play with. These are two features which I am missing in vala - but they might just be a bit out of scope of vala's focus.

I've only played with rust a little, but to ease Fedora users access to this language I've created an initial specfile which can be used to build the package.
For convenience I'm also providing an rpm.

Rust is currently not suitable for an official inclusion into Fedora's repositories as it builds it's own patched version of llvm, does some stuff with rpaths, …. There is work to upstream the patches, but that's still far in the future.

So - pick it up and install it, look at the quite nice tutorial and get your hands dirty.

# Clone
git clone git://github.com/fabiand/rust-spec.git

# Build requirements
sudo yum install gcc gcc-c++ python perl curl fedora-packager

# Build it
cd rust-spec
rpmbuild -ba rust.spec

Edit: It is assumed that your env is set up for building packages

oVirt Node 2.6.1

Node 2.6.1- a very slim firmware-like Fedora for oVirt Node - has been released.
This minor release was necessary because our major TUI rework introduced a security hole. Get it here.

So whats new about Node 2.6.x?
Well, we've got plugins and a new TUI (a new installer TUI will follow shortly).
More can be found in the release notes.

And whats coming up?
It obvious that a "solid core" or this "firmware like"  properties of Node are well suited for other projects as well (think of OpenStack, Gluster, ...)
So a near term goal is to dro the oVirt specific bits (like vdsm) to make Node more general and easier to use for other projects.
And the new installer shall also land.

Nothing new, just GNOME 3

GNOME 3 is my favorite DE.
I really appreciate how much works has gone into GNOME. Into the UI and below the surface. Seen from my perspective GNOME - as on Fedora - turns into the best system-integrated DE. The control-center can actually be used to control system stuff - thanks to all the changes that happened below, within cups, systemd, pulseaudio, colord, ... To me Fedora feels more like one system, and not several layered components.
Sure, the changes were disruptive and not every one is happy with the results - but that's just normal. And I wonder about all this ranting and bashing on changes.
In the case of GNOME it's also nice and somewhat refreshing to see that there is a plan - a vision - of where to go and what to form.