Igor - Testing an OS on real and virtual hardware

Working on oVirt Node is nice, this minimal, firmware like, rock-solid, (non-official) Fedora "spin", is oVirts "hypervisor".

One challenge is to keep Node rock-solid.
Typically you can add unit tests to your software to shield yourself from regressions (or at least discover them early) but adding tests to Node wasn't that easy as Node is a complete "operating system" and not just one component. It is currently composed of approximately 450 packages - all of these change independetly.

We were looking for a way to automate some basic tests on development or released images. But a requirement to run the tests is a running Node. This means testing requires an installation (and subsequent a removal or "freeing" of th eused host) on different hardware, including virtual machines.
So we needed a tool that could control the whole life-cycle (provision, run tests, and freeing) of a machine (either real or virtual) and which is also monitoring the progress of a testsuite, to act accordingly (e.g. killing it if it times out).
We did not find such a tool and came up with igor.

Igor expects a working PXE environment (so a lan with some DHCP and PXE server like Cobbler) and some hosts or a libvirtd instance. It is expected that all hosts (real and virtual) boot via PXE from the PXE server.

In such an environemtn Igor can control the PXE server to modify the configuration for existing hosts (or add configuration for short-living hosts like a VM) to install an oVirt Node image.
After changing the PXE configuration and booting up the host Igor steps back and either waits for a controlled ending of the testsuite (signaled via a RESTlike API) or a timeout. When it receives such a signal it shuts down the host and restores the original PXE configuration.

So that's a first build-block of how we automated the testing of oVirt Node. I haven't gone into detail how the testcases look like and how we are actually testing our TUI. Also I didn't mention the client which is running on (an edited) oVirt Node image tu actually run the tests.

Igor can be found here and is intended to be used on a developers machine (or in conjuction with jenkins).

p.s.: It is getting interesting when Igor is paired with a client using python-uinput to inject mouse and keyboard events.

bobthegnome, gcalctool and vala

gcalctool is the friendly calculater in GNOME. And now - after several others (at least cheese, zeitgeist, gnome-games)- it is ported to vala! Wow.

This didn't happen out of the blue, it was someone actually doing it - bobthegnome and PioneerAxon made this happen.
What does this mean? gcalctool should be easier to maintain and maybe attract even more contributors, as you don't have to deal with the whole boilerplate. And - Vala is gaining momentum. Nice. Cheers.

Opus now/soon in gstreamer-plugins-bad-free

Opus is a new audio codec covering a wide range of use cases. You can read more about the codec (at least) here and here.

If you want to get started with it, just try a freshly rebuild gstreamer-plugins-bad-free package which packages the opus plugin.
You will be able to use the en- and decoders in your normal gst pipeline.

It should soon land as an update on Fedora near you.

[Update]
The update has landed in updates testing:

su -c 'yum update --enablerepo=updates-testing gstreamer-plugins-bad-free-0.10.23-11.fc18'

Easier streaming with presence-0.4.8

Presence is a small - but yet flexible - tool to do simple and high-quality streaming (using dirac+vorbis over RTP) in a local broadcast domain.
When not using the MDNS feature this can also be endpoints on any routable network.
Not shown on in the screen shot, but a feature, is picture-in-picture mode for secondary streams.

Anyhow, this new release (0.4.8) contains an improvement related to publishing a stream. It's now done in two clicks with reasonable defaults, even for low-end machines.

Install or update it now on Fedora 16/17/18:

$ sudo yum clean metadata
$ sudo yum install --enablerepo=updates-testing presence
# or
$ sudo yum update --enablerepo=updates-testing presence

Or - hero-like -using this one-click technology.

The release was motivated by my new Logitech HD Pro Webcam C920 which is working out of the box on Fedora - so YUV and MJPEG besides the (unsupported) h.264 support.

 

When looking at the video quality of this camera and two built-in cameras of laptops, this is clearly a big step forward in image quality - So a decent camera is always a good way to improve a video conference.

As said, the video quality is great - and using MJPEG it can deliver a 720p video with up to 24fps, so ideal for telepresence. 

Screenshotting /dev/vcs

If you ever wanted to know how to take a "screenshot" of a VCS (where your login prompt is displayed) you can use the following snippet:

cat ../tests/igor/libs/common/vcs.py 
#!/bin/env python
#
# bash only:
# su -c 'cat /dev/vcs3 | fold -w $(stty size | cut -d " " -f 2) > /tmp/term'
#


import Image, ImageDraw
import subprocess
import argparse
import sys


def execute(cmd):
    proc = subprocess.Popen(cmd, shell=True, \
                            stdout=subprocess.PIPE, \
                            stderr=subprocess.STDOUT)
    (stdout, stderr) = proc.communicate()
    proc.wait()
    return str(stdout)

def get_size_of_tty(n):
    """Return the number of rows and cols of tty n
    """
    cmd = "stty -F /dev/tty%d size" % n
    rows, cols = execute(cmd).split(" ")
    return (int(rows), int(cols))

def capture_vcs(n, fold_at):
    """Return the contents of vcs n
    Thsi can also be used with (bash) fold -w
    """
    tty = "/dev/vcs%d" % n
    cmd = "cat %s | fold -w %d" % (tty, fold_at)
    return execute(cmd)

def image_from_vcs(n, stridex=6, stridey=12):
    """Create an image from vcs n
    """
    height, width = get_size_of_tty(n)
    im = Image.new(Image.MODES[6], (width * stridex, height * stridey))
    draw = ImageDraw.Draw(im)
    nl = 0
    screen = capture_vcs(n, fold_at=width)
    for line in screen.split("\n"):
        draw.text((0, stridey * nl), line)
        nl += 1
    return im

def screenshot_from_vcs(n, filename, format="png"):
    """Create a screenshot of a vcs and write it to a file
    """
    im = image_from_vcs(args.vcs)
    im.save(open(filename, "wb"), format.upper())

if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Create a screenshot from ' +
                                                 'a console.')
    parser.add_argument('vcs', type=int,
                        help='The VCS/TTY to be captured')
    parser.add_argument('--format', metavar='t', type=str,
                        choices=['png'], default="png",
                        help='The image format')
    parser.add_argument('file', metavar='dst', type=str,
                        help='The destination file')
    args = parser.parse_args()
    screenshot_from_vcs(args.file, args.format.upper())

The images can be used to create a screen capture of your console.

Auto bash wrapper creation for python functions and oVirt Node CI testing

There is currently working going on on bringing CI testing to oVirt Node - our smallish Fedora based "hypervisor".
Enabling automated testing is quite a challenge, because Node is not using anaconda/kickstart for installation, works with a read-only rootfs and uses a snack/newt based TUI. Many existing automated testing solutions have problems with some these aspects - because they rely on kickstart or on ATK.

Anyhow, the testcases which are run on Node are typically written in bash or python. There are a couple of common functions that are needed in both languages (e.g. to communicate with the testing server or providing a common logging function).
It's quite error prone to have functions in both languages providing the same functionality, and that was the point where I looked for a method to automatically or "natively" call python functions from bash (not calling bash from python).
Searching didn't lead to any good alternative, therefor I've come up with the this bash snippet which creates bash functions for all callables of a given python module.
This might not be perfet, but it does the job in our case.

The TUI testing - while we are at it - is now done using uinput.

Doing PXE with libvirt / virt-manager

Installing hosts using PXE is a well known thing.
Why not do it within libvirt? Or: How do I do this in libvirt?
Do I need to setup my own dhcp server to pass the bootp option? Nope.
Just use libvirts default dnsmasq and add the bootp dhcp option.

All you need to do is editing the default network configuration using virsh (no way o do it from virt-manager).

# virsh net-destroy default
# virsh net-edit
  Now add "<bootp file='/pxelinux.0' server='$PXESERVERIP' />" under /network/ip/dhcp
# virsh net-start default

All done.
Just have a look at the definition here to read about more features.

Using oVirt Node with virt-manager

Virtualization is already an ubiquitous technique.
Fedora provides packages for many of the Linux virtualization components through the yum virtualization group.

$ sudo yum groupinstall virtualization

Well, anyway - When doing virtualization you need a host, hosting your virtualized guests. If you don't want to do this on your local machine - because it hasn't got the capabilities, isn't beefy enough, ... - you can use oVirt Node as a hypervisor on a second machine which you can easily manage from Fedora using virt-manager.
This can be useful for a small working group or developers.

oVirt Node is based on Fedora and optimized to quickly get a hypervisor up an running. You actually do not need to care about all the constraints - networking, services, storage, ... - you need to consider if you setup a hypervisor yourself (which can also be done with  Fedora). It is also stripped down (~150MB) to preserve most of the RAM and storage space to the virtualized guests.

Anyhow:

1. Download oVirt Node
2. Install it on a machine with a recent Intel or AMD processor
3. Log into the installed Node using admin and
1. Configure a network interface
2. Press F2 to drop to the console and run
3. /usr/libexec/ovirt-config-password 
1. set a root password
2. enable SSH access
4. Optional: ssh-copy-id your ssh key to node to allow a password-less login
5. User virt-manager to create a new connection (File -> New Connection) to the installed Node (IP can be found on the Node's Status page)
   URI: qemu+ssh://$OVIRTNODE/system

($OVIRTNODE needs to replaced accordingly)
Actually oVirt Node is intended to be used with oVirt Engine, which can manage from one up to a couple of hundreds (?) of Nodes.
But the Engine setup itself is not as easy as just using virt-manager :)
At least - Engine would be the next step to get used to the oVirt components.

P.s.: You can use virsh vol-upload to get some data onto the node.

Booting Fedora using Qemu and EFI

Thanks Harald.
After reading accross Harald's blog post mentioned above, I tried to boot one of the recent Fedora 17 composes. Sadly Qemu refused to find the attached (emulated) CD drive, but passing my primary hda (as a snapshot) worked like a charm: Fedora 16 ran in qemu with an EFI bios (OVMF).

Auto-Installing oVirt Node

oVirt - maybe you've heard about it. It's a project to create an open IaaS "virtualization management system" - So a bit like OpenStack, but different.
Fedora is the base for oVirt's hypervisor: "Node". Basicaly this is a stripped down Fedora, enriched with a couple of packages to prvide just enough to host some virtual guests and do some basic configuration.

Personally I'd like to use Node in conjunction with Gnome Boxes or virt-manager. But this is currently not possible - but we might get closer to it when solving this bug.
Anyhow, to quickly install oVirt Node you just need to add two (or three) additional kernel arguments:

BOOTIF=ethX storage_init

You should/could also add

adminpw=$ADMINPW

ADMINPW=$(openssl passwd -salt SALT) is a salted password, so you can log in (as admin) after the installation. Alternatively you can boot into single mode to reset the password.

The parameters above install oVirt node without user intervention,  setup networking on ethX and erase all data on the disk and create a defautl (lvm based) partitioning scheme.
The next step would be adding Node to oVirt Engine - or wait until it can be managed by virt-manager, which is much quicker to set-up :)

gstreamer as a multimedia backend in Firefox

Wow. After such a long time it happened. Gstreamer can be used as a multimedia backend in Firefox!

So what does this mean? I believe not much yet for the enduser, at least this is a very nice infrastructure change to enable stuff like hardware acceleration e.g. on mobile devices. And from my point of view also a good separation: Do one thing and do it well. Let gstream do the multimedia stuff and Mozilla all that compositing.

Maybe this can be enabled in Fedora - at compile time - to get an maybe accelerated experience. or better codec support e.g. h264 for those who need it (e.g. by using Fluendos codec pack) or even my always favored Dirac!

ICD and pocl

There is no official release from pocl yet, but I noticed that there is now some work going on to bring ICD to pocl. Very nice.
This will allow us to have more than one open CL implementation on our systems - as long as all of them honor ICD.

Migrate your fav. packages to a new workstation.

Once in a while we are setting up our workstations - yet again.
I often faced the problem to migrate my finest selection of packages from my former system, to the new one.
Groups are surely one way to install roughly those packages you need on the new system, but in very rare cases your package selection is unique.

The following snippet might help you, to install the packages of DA_OLD_HOST on your new system.
On your new host:

$ ssh $DA_OLD_HOST 'rpm -qa --qf "%{NAME}\n"' \
  | xargs yum install -y --skip-broken

Hint: It seems as if something is broken with the fedora mirros, you can work around problems by commenting the mirrorlist and uncommenting the baseurl option in the appropriate yum repo .conf.

Package management using zif.

As yum was introduced I was happy about it's features. Also some of the later features like history and the rollback are nice and handy.
But yum can be slow.

If you want to use a different rpm high-level management system with a comparable featureset to yum give zif a try:

$ sudo yum install -y zif-tools PackageKit-zif

This also installs the zif backend for PackageKit - which appears to the user as the package update dialog.
Many known commands will work:

$ zif search yum
$ sudo zif install -y livecd-tools
$ zif # will print help

They did it. A smallish OpenCL example running on Mesa's r600.

This happened somewhat unexpected while looking again at the state of open OpenCL implementations (so pocl and clover).

Suddenly some hero told me that there is a smallish OpenCL example which actually works with Mesa's OpenCL implementation (actually this is bound to r600 based devices). So what is awesome if this ain't?

What you need:

• tstellar's clover-r600-master branch
• Fedora 16 (okay, it might also work somewhere else), with rawhide clang and llvm
• and the example code
• oh - and - important -  an appropriate card e.g. HD6310 (AMD E-350/E-450) or some other evergreen GPU

What actually has to be done is - this time - left to the user.
A few hints:

• Look at the comment in line 96 of src/gallium/state_trackers/clover/llvm/invocation.cpp and swap comments (there are r600 patches for LLVM which can be applied to get around this).
• The implementation expects the opencl libs to reside in /usr/local/lib/opencl - so install or softlink
• Set LD_LIBRARY_PATH to mesa/lib when building the example
• You need to provide the OpenCL headers

The present support is currently just basic, but it's awesome to see this progress.

What you get:

There are 1 platforms.
There are 1 GPU devices.
clCreateContext() succeeded.
notkernel
main
clCreateCommandQueue() succeeded.
clCreateProgramWithSource() suceeded.
build log:
clBuildProgram() suceeded.
clCreateKernel() suceeded.
clCreateBuffer() succeeded.
clSetKernelArg() succeeded.
--------------------------------------------------
[...]
clEnqueueReadBuffer() suceeded.
pi = 3.141590

Let's see when I can build gst-plugins-opencl against mesa. And "they" include zack, steckdenis, and tstellar.

Some more informations using this tool:

$ make clInfo CFLAGS="-I$PATH_TO_CL_HEADERS" LDFLAGS="-lOpenCL -L$MESAPATH/lib"
$ sudo LD_LIBRARY_PATH="$MESAPATH/lib" ./clInfo
Found 1 platform(s).
platform[(nil)]: profile: FULL_PROFILE
platform[(nil)]: version: OpenCL 1.1 MESA 8.0.0
platform[(nil)]: name: Default
platform[(nil)]: vendor: Mesa
platform[(nil)]: extensions: 
platform[(nil)]: Found 1 device(s).
[...]

Fedora 17 Alpha declared GOLD - Try the shell in qemu.

Robyn Bergeron announced: Fedora 17 Alpha release (RC4) was declared GOLD [Source].
This release ships Mesa with llvmpipe (and several other enhancements to allow software rendering), this way gnome-shell can actually be run in a non-accelerated graphics environment - like qemu is.

Just fetch - today or the 28th - an ISO of your flavor (live CDs come in GNOME, KDE, LXDE and XFCE) and run it with qemu:

$ sudo qemu-kvm -smp 2 -m 1024 -net user -net nic \
  -cdrom Fedora-17-Alpha-x86_64-Live-Desktop.iso

Sadly qemu's curl support is still broken, otherwise we could just run:

$ sudo qemu-kvm -smp 2 -m 1024 -net user -net nic \ 
  -cdrom "http://dl.fedoraproject.org/pub/alt/stage/\
17-Alpha.RC4/Live/x86_64/\
Fedora-17-Alpha-x86_64-Live-Desktop.iso"

Give spice a try - or: Smooth VNC.

Who doesn't know it: You are controlling your laptop via VNC, but all youtube videos scrolling through windows seems to be sluggish and parts of the window don't get updated - you see black patches everywhere.
Being in such a situation I wanted to try spice.

On Fedora 16 there is a spice Xserver where you can launch any program like you are used to do. So how does this help to improve the situation? Well, spice has an highly optimized protocol to deliver data from a server to a client e.g. it detectes videos played fast moving content on the server side, which are transmitted using mjpeg (AFAIK).
Anyhow, here we go (on the server side):

$ export CLIENT_ADDR=cut-n-paste
$ sudo yum install --enablerepo=updates-testing \
    xorg-x11-server-Xspice
$ sudo iptables -I INPUT -s $CLIENT_ADDR -j ACCEPT
$ Xspice --port 59007 --disable-ticketing :1.0 & 
$ { sleep 2 ; \
    export DISPLAY=:1.0 ; \
    metacity & \
    gnome-terminal ; }

This launches an Xspice server, listening on port 59007 and starts a metacity and gnome-terminal instance after 2 seconds within that server. The first line opens the appropriate ports.
Afterwards fetch spicec, the spice client (something like remmina, oh, has remmina already a spice plugin?) and connect it to the server:

$ export SERVER_ADDR=cut-n-paste
$ sudo yum install --enablerepo=updates-testing \
    spice-client
$ spicec -h $SERVER_ADDR -p 59007

A nice thing about spice is, that it's an xserver, so you can use xrandr to change the resolution at runtime. Nice.

$ xrand -s 1680x1050
$ firefox
# or, to connect to your original desktop via 
# VNC, but to transmit the desktop via spice 
# to your client. yey.
$ vncviewer localhost

Maybe this helps some lost soul to get a saner my-remote-desktop-over-a-network experience.
A last thing: Does someone know how to tell Fedora what X server to start on boot?

Linking OpenCL - Oh, wait ...

OpenCL is a nice way to utilize vector processors or multi cores.
But when it comes to writing and linking our software against a OpenCL it doesn't seem to open anymore. Because currently you need to link to one specific OpenCL implementatio, like AMD's or Intel's.
Okay, that might in the normal case not be to problematic, but as Fedora Packager I don't want to link some software to one specific implementation, if there are several.
This problem already appeared to the arch people and they just pulled the - so called - ICD loader out of one of the available implementations into the libCL package, to solve this problem.

ICD loader
So how does this help? ICD is a mechanism specified by Khronos to allow several OpenCL implementations to be installed side-by-side without disturbing each other. And the ICD loader allows to freely choose between one of the available ones (if it supports ICD), as the loader redirects the API calls to the choosen implementation.

What we need is some kind of just-an-ICD-loader which provides /lib64/libOpenCL.so which is the in turn using the actual implementation (e.g. pocl or the upcoming nouveau / clover [hopefully AMD to] thing).

There are already some open ICD implementations available, maybe those can be reused.

gst-plugins-cl - OpenCL plugins for gstreamer, written in Vala.

Some of you may know OpenCL - the open computing language. This language allows us to write kernels in a C99 dialect, which can be run on data - in parallel.
A common use case for such a language - and processing concept - is the classical convolution - which was my motivation. Sure, this can also be realized using the frequency domain, but - hey - I feel fine in the spatial one.

Anyhow, there are bindings for OpenCL - which is vendor (NVidia, AMD, Intel, F/LOSS, ...) and hardware (GPU vs. CPU - AMD, Intel, IBM Cell, ...) independent for many languages, including MatLab, python, C, C++  and so on ...
In my case I needed a way to apply some filter function (or [OpenCL] kernel) to a video stream from some FireWire camera.
The experienced reader might directly associate FireWire with gstreamer our multimedia framework of choice under linux.
I had the option to Gather the data from a gstreamer pipeline reading the FireWire camera or create a gstreamer element providing, as of wrapping, the OpenCL functionality. The mentioned plugin does the latter, it provides a couple of elements to apply some OpenCL kernel to the data of a gstreamer pipeline.

You need vala and some gstreamer sources to build this project:

$ sudo yum install gstreamer-devel vala

.. might be a good start.
You also need some OpenCL implementation, as of today pocl can be used, but it's just intensively tested with the Nvidia implementation of it's GPU SDK and with Intel OCL SDK.
Building the plugin is quite simple

$ ./autogen.sh
$ ./configure
$ make

Testing should also be quite easy:

$ export GST_PLUGIN_PATH=src/.libs/
$ gst-launch audiotestsrc ! clkernel ! autoaudiosink

This doesn't do much, as the default kernel just passes the data - but at least you can test if the OpenCL is available. There are currently three plugins:

• clkernel - An element to manipulate any buffer
• clkernel2d - An element to manipulate a 2D buffer, like an gray image/video
• clvideofilter - An element to manipulate an RGBA image/video

The OpenCL kernel can reside in an external file. You can pass the filename of that file and the kernel to use to the element:

$ gst-launch audiotestsrc \
  ! clkernel kernel-file=mykernellib.cl kernel-name=somekernel \
  ! autoaudiosink

Have a look at the sources or kernel.cl and kernel2.cl files (they are plaintext files, the kernel are build on the fly - heard of JIT?) in the src directory to see what kind of signature the kernel has to provide. (This should be documented more thoroughly).
If you've got more than one platform which is OpenCL capable you can use the platform-idx property to specify a specific platform.

This plugins should help to offload some functionality to one or more devices (like GPU, CPU and accelerator, like the CELL) and you don't need to care about the details.
This can now be used to do things like color conversion, all sorts of filtering, mixing and what else can be done in parallel.
Thos plugins are just a start, it would be nice to be able to provide more sinks which then can be used as an input to the kernels.

~ https://gitorious.org/valastuff/gst-plugins-cl

Notes about writing a gstreamer plugin in vala.

Median/max/sobel filters/OpenCL kernels applied to 

Sintel using Intels OCL SDK and a gstreamer plugin.

Vala, as some of you may know, is a "compiler for the GObject type system". This means, vala is providing a high-level language with e.g. literals for (nearly) all features of gobject and glib. Because vala get's translated to C, it easily integrates with existing C code. Vala code can also be used from C (and other languages, most easily using gobject intropsection) too.

Gstreamer is a nice multimedia framework - and component of the GNOME ecosystem, now more related to freedesktop.org - and is also based on gobject/glib. So it is quite obvious to use vala to build gstreamer plugins and elements.

A gstreamer plugin is organized as a plugin, which wraps one or more elements, which provide the actual functionality. Detailed informations on how to write plugins can be found in the plugin writers guide.

But what is needed to write a plugin and elements in vala? And if it's good to do so.

gst_plugin_desc and plugin_init ()
There are two special structures that need to appear in a Gstreamer plugin: A plugin description (namely the Gst.PluginDesc [vala class]) and the plugin_init () function.
The identifiers of these structures (struct and function) need to match those expected by gstreamer. The plugin description identifier needs to be called gst_plugin_desc and the plugin_init() function also needs to have this name.
In vala it is important to place these methods on the toplevel of your file, and not within a namespace, otherwise vala will prefix the resulting C functions with prefix dervied from the namespace. An alternative is to use a CCode attribute for those structures, but why do this if it can be done easier (as described before).
An working example with correctly named plugin description and init function can be found here.

Namespace
Because of the naming you should also put your elements of the plugin within a Gst namespace e.g. namespace Gst.Myplugin. Because this translates to C structures (generated by vala) prefixed by gst_myplugin_… and the gst (or Gst or GST) prefix is needed, because the buildsystem is looking for those symbols and exports them.
Look in the example above or below to see where to put the element and what kind of namespace to use.

Elements: Gst.BaseTransform
It's quite easy to implement a simple filter. This can be done by subclassing Gst.BaseTransform and overriding (so providing an implementation for) a couple of functions. Have a look here to find out what you need to implement. Or here to see an actual working implementation.

gst-template and buildsystem
You can use the plugin template provided by gstreamer but you obviously need to modify the buildsystem to generate c code from the vala files.
Have a look at this Makefile.am.

Packages & Testing
The basic requirements can be met with the following packages:

$ sudo yum install gstreamer-devel \
gstreamer-plugins-base-devel gstreamer-plugins-base-devel-docs \
vala devhelp

Have you finally compiled your sources try the plugin with gst-launch, remember to add the hidden .libs dir to your path:

$GST_PLUGIN_PATH=src/.libs/ gst-launch  videotestsrc ! myelem ! autovideosink

So yes - you can write gstreamer plugins in vala - so what element are you going to write today?

fontkodo - Searching through a selection of f/loss repositories.

Fontkodo - best experienced with Firefox, but it also works with others - indexes the repositories hosted at

• git.gnome.org
• git.kernel.org
• git.freedesktop.org
• git.freesmartphone.org
• code.entropywave.com
• git.fedorahosted.org
• pkgs.fedoraproject.org 

so covering spec files, python, vala, c, and java code, and images.The focus is therefor on Fedora, GNOME, and vala related code: To aid finding spec files, vala examples and digging through vapis.

Maybe this is useful for some starters which want to look at real world example code.
Search for vala files using "lang:vala" or pngs with a miracle using "lang:png beefy".
To find specfiles requiring orc and hosted at pkgs.fedoraproject.org try "origin:pfo lang:spec orc".

redis-2.4.6 lands in updates-testing

Redis -a very nice persistent key-value store with knowledge about lists and sets - 2.4 brings some syntax change / new features.
If you are using redis on Fedora 16 you can test 2.4.6 using the updates-testing repo:

# su -c 'yum update --enablerepo=updates-testing redis-2.4.6-1.fc16'

This update also introduces a systemd unit file, which could also get some attention to see if it works like expected.

This is the second sunny day with temperatures just above 0°c.

Spieglein - Sharing public keys via display and webcam (or so)

Sharing (cryptographic) keys is still mandatory in or cryptography landscape.
A nice exmaple is our ~/.ssh/authorized_keys file which contains a list of public ssh keys which are allowed to login.
One way to exchange those keys is using ssh-copy-id.

Another one is using a webcam and some display - like the ones found in laptops or mobile phones (but even white paper works ;)
The principle is quite simple, just QR encode your public key and point the webcam at the screen to get a picture of the QR encoded public key and decode it.
Voila you've got your own copy of the public key. And it's quite hard to intersect photons on their way from the display to the webcam, so your copy can be trusted.

It is as easy as encoding the image

$ bash create_pubkey_qr.sh 

This results in a image like this:

Now, on the receiving computer, run

$ ./look_for_qr.vala

And point the webcam at the surface displaying the QR code in question ...

You might need to install some dependencies using

$ sudo yum install -y vala glib2-devel qrencode \
gstreamer-plugins-bad-free-extras

Just look here for a working example.

Kontinuität - And transforming XML into a UI.

Das frohe neue Jahr hat fahrt aufgenommen - es beginnt fröhlich stürmisch mit frischem Wind.

During the holidays I had some time and looked into xsl transforms again.
This time I needed a nice way to build a simple UI for a specific XML document.
My initial intention was to use a visitor pattern to transform the XML document into a corresponding Gtk UI, but then my eyes catched GtkBuilder.
GtkBuilder builds a UI from an XML definition.
And there it is, an ideal case for xslt: XSL ransform allow you to transform an XML document into some other plain-text document, this includes into other XML or - quite common - XHTML documents.

The simple document looked something like this:

<document id="document" title="About something" author="Jane Doe">
  <text id="intro">Hello World.</text>
  <text id="more">This is something like <i>xml-to-gtk</i></text>
</document>

Using this xsl stylesheet and a bit of glue, resulted in a UI looking like this:

 

Not pretty - but - hey - there are also other techniques that take some markup to built UIs, just think of clutter ...