Added augeas.vapi and augeas.dep.

If you have ever dreamed of using augeas from vala, your dreams have been heard - just before christmas.
The binding is nearly complete, just aug_span is missing. So dive into xml using augeas, even in relative paths.

Da - Presence lands in fedora

Finally, presence - that small video tool - has landed in the fedora-updates repo.

You can install it using:

$ sudo yum install presence

That's all there is to do.

De-Duping files on BTRFS.

Brave souls can test BTRFS for a couple of Fedora releases.

Removing duplicate/redundant files on filesystems is a common thing, e.g. when creating regular backups or so. On ext4 this can be realized using traditional hardlinks.
Hardlinks all point to the same blocks on the logical drive below. So if a write happens to one of the hardlinks, this also "appears" in all other hardlinks (which point to he same - modified - block).
This is no problem in a backup scenario, as you normally don't modify backuped files.

In my case I wanted to remove redundant files that might get modified and the changes shouldn't be reflected in all other copies. So what I want to achieve is to let several links (files) point to the same block for reading, but if a write happens to one block this should be just happen to the one file (link). So, copy the file on write. Wait, don't we know that as CoW? Yep.

Luckily BTRFS allows cow files using the cp --reflink command.
The following snippet replaces all copies of a file with "light weight" aka cow copies.

#!/bin/bash
# Usage: dedup.sh PATH_TO_HIER_WITH_MANY_EXPECTED_DUPES
mkdir sums
find $@ -type f -print0 | while read -d $'\0' -r F
do
  echo -n "$F : "
  FHASH=$(sha256sum "$F" | cut -d" " -f1);
  # If hashed, it's probably a dupe, compare bytewise 
  # and create a reflink (so cow)
  if [[ -f "sums/$FHASH" ]] && cmp -s "sums/$FHASH" "$F";
  then
    echo "Dup." ;
    rm "$F" ;
    cp --reflink "sums/$FHASH" "$F" ;

  # It's a new file, create a hash entry.
  else
    echo "New." ;
    cp --reflink "$F" "sums/$FHASH" ;
  fi
done
rm sums/*
rmdir sums

And in general, btrfs didn't yet eat my data, it even survived two power losses ...
Update: Updated to handle files with special characters. This script also makes some assumptions, e.g. the files should not be modified while running this script.

OpenCL on Fedora: A quick look at building pocl.

Finally a 3.0 release candidate of llvm is packaged for Fedora and available via rawhide. Many of the current OpenCL implementations like pocl and clover depend on llvm-3.0 and with this release it is finally an easy thing to build pocl on Fedora.
pocl has some other pre-requirements besides clang/llvm, after installing them you can just build the software as usual:

$ sudo yum install --enablerepo=rawhide llvm-devel llvm clang \
libtool-ltdl

$ git clone 
$ bzr branch lp:pocl
$ bash autogen.sh
$ ./configure
$ make
$ make check

Another approach to modfiy structured files (like config or XML files)

Have you ever wondered if there is a more convenient way to modify xml documents, beside libxml2? Sure, there is the nice dom within Firefox, but outside of that?
Well, there is augeas. AFAIK initially a project to standardize the interface to modify configuration files, in other words a common syntax for different formats.
Files are parsed trough so called lenses. Those lenses transform the actual file (e.g. httpd.conf or passwd) into a tree, which than can be modified by a set of augeas commands.
As lenses are bi-directional the same lense can be used to read a file, and to dump the (internal augeas) tree back into a valid configuration file. A nice concept, ey?

A back to the topic, one of the lenses - Xml.lns - can be used to modify XML files.
The following example creates a dummy xml file and modifies it using augtool.

$ sudo yum install augeas tidyp

$ cat > abc.xml <<EOF
<world poo="bar">
<child>Hi there.</child>
</world>
EOF

$ augtool -LA -e <<EOF
# Load XML lense
set /augeas/load/xml/lens "Xml.lns"
set /augeas/load/xml/incl "$PWD/abc.xml"
load

# Dump internal tree
print /files

# Add a note
set /files/$PWD/abc.xml/world/note/#attribute/timestamp "now"
set /files/$PWD/abc.xml/world/note/#text "Wtf"

# Change the text of a node.
set /files/$PWD/abc.xml/world/child/#text "Hello World."

# Insert a new child after the present child
ins child after /files/$PWD/abc.xml/world/child
set /files/$PWD/abc.xml/world/child[2]/#text "Hello Mars."

# Insert a new child - anywhere ..
set /files/$PWD/abc.xml/world/child[3]/#text "Hello Jupiter Jones."

# More children
set /files/$PWD/abc.xml/world/child[4]/child/child/#text "Hello Mars."

print /files/$PWD/abc.xml

save
print /augeas//error
EOF

$ tidyp -xml -i -q < abc.xml

$ unlink abc.xml

With the help from the people at #augeas on freenode, I found out that (a) there is a small bug preventing the usage of relative paths and (b) You need a little knowledge about the format you are writin to. In the (xml) example above, you need to specify attributes before specifying a #text node, because they are written first. If they were specified the other way round, augeas would fail while saving.

Using lokkit to handle your firewall.

Some common thing is to turn of the firewall if a freshly installed machine isn't reachable from the outside, as fidling with iptables is not everyones passion.

lokkit is another way to open some ports to the public.

Just use

$ sudo lokkit --list-services

to see what services/ports can be managed/opened using lokkit. For me it's quite common to open ports for ssh, ipsec and mdns afer a fresh installation

$ sudo lokkit -s ssh
$ sudo lokkit -s mdns
$ sudo lokkit -s ipsec

Let's see if there will be something new in the near future to handle - somtimes quite complex (see virtualization) - iptable setups.

How to get a link to your public hardware data (smolt profile).

Smolt is a tool to gather data about your hardware in a distribution independent way. Hardware data can be interesting for a couple of reasons, e.g. developers get detailed informations about hardware involved in bugs.
When opted-in, a smolt profile is created for your hardware after the installation, on the first boot (via firstboot). There is smoltSendProfile (part of the smolt package), which can be used to re-send your hw data.
But there is no easy way to get a link to your public profile - this should be changed, but until then ..
- if you are interested - you can use the following lines, to determine the URL to your public profile:

$ python <<EOF
import sys
sys.path.append ("/usr/share/smolt/client")
import smolt 
print (smolt.get_profile_link(smolt.smoonURL, smolt.getPubUUID ()))
EOF

Securing peer connections using IPSec

If some application or transport protocol doesn't specify a way to encrypt it's contents, it might be still enough to encrypt a lower layer.

IPSec is a way to encrypt IP packets (actually it is an alternative to IP).

The script after the break can be used to secure a connection - like an RTSP stream - between two peers using a pre shared key (psk).

The journal - or system wide logging.

A couple of days ago I mentioned the idea of a session wide logging daemon.
Today the folks around systemd introduced "the journal", an improved logging approach for systemd based systems.

presence is up for review.

To get presence into Fedora a so called "review" is needed - as you might know. If not it's a must to do one.
So if you needed something entertaining tonight, just grab a nice bottle of Beck's beer (or Bionade Holunder) and a box of Pringles (or Rosinen) and enjoy the few spec file lines.

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=754554

yum update fails in Fedora 16 because of broken certificates

Today (and also the last days) I ran into trouble when updating my system.
yum update ran silently in to the error:

$ sudo yum update -y
Geladene Plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
Fehler: Cannot retrieve repository metadata (repomd.xml) for repository:
fedora. Please verify its path and try again

That didn't tell me a lot about the error, also a yum clean metadata didn't help.
After a bit of googling I stumbled across the URLGRABBER_DEBUG variable which tells yum to debug all URL fetching stuff, this lead me to the error:

$ sudo URLGRABBER_DEBUG=1 yum update -y
Geladene Plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
...
Could not get metalink https://mirrors.fedoraproject.org/metalink?
repo=fedora-debug-16&arch=x86_64 error was
14: Peer cert cannot be verified or peer cert invalid
Fehler: Cannot retrieve repository metadata (repomd.xml) for repository: 
fedora. Please verify its path and try again

It was discovered last year that such errors are not passed to the user, but it might be a good idea to fix this.
To get around the error you can temporarily disable the verification of hosts using yum's setopt switch:

$ sudo yum update --setopt=sslverify=false

Session wide logging in GNOME.

Currently each application in GNOME is using GLib's logging functionality or something custom.
Errors written to stdout get logged in ~/.xsession-errors - and other places we don't know about.

What I would like, is to have a central place for application related logging. This could have many benefits:

• Users have a single place to look out for errors applications didn't (yet) tell them about.
• A logging daemon can keep a history and this could help solving bugs, e.g. it could be added to abrt reports.
• Leads to less clutter in ~/.xsession-errors

If such a daemon is introduced, it should to be easy to integrate and be backwards compatible. In my eyes talking to this daemon can easily be realized by providing a GLogFunc, which handles the appropriate communication with the daemon. Additional features - like searching or exporting - could also be provided by the DBus interface, bt this is not important for logging itself.

And this is what I suggest:

slogd a simple logging daemon, providing a DBus interface to log messages.  This daemon also has an example backend which logs the messages into a sqlite database (via GDA).

libslogc a very tiny library to communicate with the daemon and slogc, a small tool wrapping libslogc. libslogc also provides slog_client_log (...), a GLogFunc to be used from C.

And there is finally simple.c, a small example on how to integrate libslogc. (Well, there ain't much to do.)

The code can be found at https://gitorious.org/valastuff/slog.
This is a prototype to get some feedback and see what other people think about a central logging daemon.

Wrapping OpenCL™ in Vala℠

Because of the recent stirs regarding OpenCL in our FLOSS ecosystem (think about clover, pocl, libclc and there is one I am missing ...) and some demand on my side, I tried to use OpenCL (in form of Intel's OCL SDK - as clover and pocl require some bleeding edge clang/llvm) from Vala - my favorite language in the ecological niche of GNOME.

My first attempt was a straight binding of the cl.h without modeling the intended OO structures. Modeling the intended structure is possible, but there are more things to do, like run-time checks (ever heard of ErrorCode?) ..
Yesterday I ended in writing a small set of wrapper classes in vala (so effectively a GLib wrapper around the low-level OpenCL C API), calling the native C functions via the created low-level API.
Today I got first basic kernel running, that's nice progress (I just tested in on a CPU, GPUto go ...)
This wrapper removes a lot of the boilerplate (and checks) needed to get OpenCL and a kernel running.

There is still much room for improvement in the wrapper, much can be cleaned up and VAPI can be restructured to incorporate the OO structure of OpenCL.
This could lead to a simpler wrapper.

Well, it's start - like the projects mentioned in the first paragraph ...
Dig into it at gitorious.

Presence and adjustable video quality.

Presence - a small vala, gstreamer, clutter and dirac/schroedinger - based bi-directional video tool, is configurable now.

You can actually use it to establish uni- or bi-directional audio/video streams in trusted/local networks. Sometimes this can be handy, as those streams can be set-up to have a much better quality than generic VoIP solutions ...
You can even receive more than one stream.

Currently you can adjust the video size, the compression quality and the framerate to get the optimal balance between performance and capabilities of the underlying hardware.
A next thing is to tune those parameters automagically - but I'll need to find out how to detect dropped frames or an increased latency. Additional there should be a way to adjust the latency/buffer on the receiving side, to match the amount of data coming in.

Find it on gitorious.

Presence now has »picture in picture (PiP)« mode.

The next branch of presence gained PiP support, this allows the parallel view of "secondary" streams besdes the primary one. Some refactoring needs to be done, before it lands in master.
Another thing on the todo list are more convenient dialogs. Maybe someone has some styling ideas?
If you wonder how I got Big Buck Bunny into presence, just continue reading.

Insight into an GObject's lifetime.

I just needed a quick way to get an overview over the lifetime of a specific instance of a Vala class.
Thus I need some informations about it's creation - and more important - it's destruction time.
robster pointed me to gobject-list a small library which is preloaded and tracks gobjects' _ref and _unref calls - so a great tool for vala code.

It's simple to get it up and running on Fedora:

$ sudo yum install libunwind-devel glib2-devel
$ git clone git://git.collabora.co.uk/git/user/danni/gobject-list.git
$ make
...
$ cd /path/to/myapp/
$ LD_PRELOAD=/path/to/libgobject-list.so myvalaapp | grep MyClass

More can be found in Danielle's initial post and more about vala's memory management can be found here.

Expressing vapi dependencies in automake.

Today I ran into trouble defining dependencies between different vala files I use within presence.
Automake allows to define dependencies based on targets (like a library libui.a or sources ui.c). But how can I add a dependency on a .vapi? (This dependency might be needed, because app is using some code from libui.)

If I just add a dependency on the library level, make fails when looking for the library while generating the C-Code. Look at the following example:

app_SOURCES = main.vala
app_LIBADD = libA.a libB.a

In the above example main.vala already needs informations about libA and libB when valac is generating the C-Code. But this doesn't work in a parallel build, when libA or libB's vapi is not yet generated.
So I needed to tell automake/make somehow to depend on the .vapi files of libA/libB - but how? Automake doesn't know about vapis and doesn't provide any targets for them.

But it seems as this can be solved like this: You can tell automake to depend on the .c file corresponding to your .vala (and so .vapi) file, as the .c file is generated at the same time the vapi is generated. And - oh wonder - automake has targets for the c files generated by valac, therefor it's possible to use the .c files as dependencies when you mention them in the _SOURCES part of the target in question.

app_SOURCES = main.vala libA.c libB.c
app_LIBADD = libA.a libB.a

Adding the .c files to the sources doesn't do any harm, but allows app to depend on the availability of (a) the vapis and (b) the libs for libA and libB. So dependencies on both levels (code generation and linking).

Have a look at this Makefile.am for my real world example.

There is a high probability that I've missunderstood or forgot something. Hints and comments are welcome.

Fixed: Suspend and Resume on Lenovo x121e

Lately - after using suspend and resume extensively - I've quickly noticed, that the wireless card doesn't come back to live after resume. After filing a bug and getting help - it was somewhat dump not to update my bios after right away - I got the bug fixed using this BIOS/EFI update from Lenovo.
While burning the ISO onto a CD-ROM I found this bug: When nautilus removes the CD drive from the system and doesn't eject the CD-ROM when pressing the "eject" button in nautilus' sidebar.
A last word regarding suspend and resume - I am not completely convinced that the wireless always returns from suspend ...

substanziell - Backup your subatance.io document.

substance.io is a nice document authoring and publishing for the web - but sometimes it has it hickups and you can loose parts of your document. No good, but - hey - let's make backups.
After exporting your cookies (using some Export cookies Firefox add-on), you can use the following while-loop to backup your progress regularly into a a clean git repository.

while true ; 
do \
  curl -O -b cookies.txt \
    http://substance.io/$USERNAME/$DOCUMENTNAME.latex ; \
  git commit -asm"Auto-save." ; \
  sleep 60 ; \
done

And thanks to _mql for getting back some lost lines.

Da sein - Introducing presence a tool for »videoconferencing«

Intended purpose: Use this application to transmitt audio and video in an n-to-m-peers fashion in quite high quality and with a hopefully low latency. This can be the case in scenarios like connecting video walls, e-lecture or simple bi-directional two people communication.

Intended audience and requirements: This application is designed for an elite circle of users who are in a situation with:

• no NAT problems, e.g. IPv6 users
• one multicast domain or access to their DNS records
• quite high bandwidth, like 2 Mb/s
• secured transport way, aka VPN or or non-public network
• multi-core systems (single core Intel Atoms are a no-go), but something like an AMD E-350
• Fedora 16

Design: Trageting a very specific need (near-realtime bi-directional a/v transmission in a good quality, not caring about bandwidth and security) this tool also doesn't follow public standars like RFCs, but more builds ontop of available features (e.g. gstreamers rtpgstpay). On the other side standards are use:

• RTSP stream control
• dirac video codec
• vorbis audio codec
• mdns service discovery
• Mx based interface
• Fulscreen mode
• IPv6 support

Currently presence is some kind of beta. Find out more on the appropriate page.

Update on EFI and Fedora 16 Live images.

Somehow Fedora 16 re-gained EFI support - after it was lost in the beginning of the Fedora 16 process. The trouble seems to be introduced partly because of the migration to grub2 or changes to anaconda.
But as of Fedora 16 TC1 also the Live CDs support EFI! Look here to learn how to make a bootable USB media from the iso you downloaded.

As we already know, the installation DVDs already support EFI, since rc3 (or so).
Participate and provide some feedback (e.g. via IRC or bugzilla) on bugs when testing out the media.

Building gcc-4.3.4 on Fedora 15

Currently you need to rely on proprietary drivers to use CUDA or OpenCL on a GPU under Linux.

There is clover a OpenCL implementation capable of running on a CPU - but in my case I had to use CUDA. And CUDA requires gcc 4.3.4, which is not available for Fedora 15 natively, so we have to build it our self.
Actually it is quite straight to build it.
Install some requirements:

$ sudo yum install glibc-devel.i686 glibc-devel.x86_64 \
    gmp-devel mpfr-devel

Fetch the source:

$ mkdir gcc
$ cd gcc
$ curl -O \
   "ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-4.3.4/gcc-4.3.4.tar.bz2"

And finally configure, build and install it. It took around 20minutes on my machine. I installed this gcc version not in my native PATH, as I didn't want any collisions, I choose ../build as a suitable destination. In this case you have to remember to modify your PATH and LD_LIBRARY_PATH environment variables. So the app (e.g. nvcc) in question is looking in the right path when calling gcc.

$ export DST="${PWD}/../build"
$ mkdir "$DST"
$ nice ./configure --prefix="$DST" \
    --with-gmp=/usr/lib/ --with-mpc=/usr/lib/ --with-mpfr=/usr/lib/
$ nice make -j8
$ make install

I can also consider adding the --program-suffix=4.3.4 to add the given suffix to all binaries, this makes sense when you install this build into %{_bindir} and %{_libdir}.
Finally you can launch nvcc or whatever application is requiring gcc-4.3.4.

$ PATH="${DST}/bin:$PATH" LD_LIBRARY_PATH="${DST}/lib64:${DST}/lib" \
    nvcc [...]

Hinterher - Tracing vala (c-) code with systemtap.

As many others I've read Richard's post on tracing shared library calls using SystemTap (stap). This reminded me about a problem with vala a while back, which was about how to profile vala code.
Taking the following snippet, we will trace the calls to of methods of the Foo class, for some profiling.

$ cat <<EOF > foo.vala
using Gee;

class Foo : Object
{
  public void do ()
  {
    print ("done");
    }
}


void main()
{
  var map = new HashMap ();
  map["one"] = 1;
  map["two"] = 2;
  map["forty"] = 40;
  print ("%d\n", map["forty"] + map["two"]);

  var f = new Foo ();
  f.do ();
  f.do ();
}
EOF
$ vala --pkg libgee-1.0 --debug --save-temps foo.vala

Have a look at the C-code derived from the vala snippet above and look at the function names, to build a regular expression for the to-be-watched function calls. It is important to compile the snippet using the --debug switch, this enables stap to look out for the functions in question.
Additionally we need the following stap snippet (normally found in .stp files), to add the appropriate hooks to the kernel. The following stap script get's compiled into a kernel module and watches the mathod calls on instances of the Foo class.

$ cat <<EOF > foo.stp
#!/usr/bin/stap

global last;

function display_time () {
  now = gettimeofday_us ();
  delta = 0;
  if (last > 0)
    delta = now - last;
  last = now;

  printf ("%d (+%d):", now, delta);
}

probe begin {
  last = 0;
  printf ("ready\n");
}

# Modify to match the C signatures of teh methods in question
probe process("/home/fabiand/tmp/sl")
            .function("foo_[a-z]*") ? {
  display_time();
  printf ("\t%s %s\n", probefunc(), $$parms);
}
EOF

Now we've got the binary to trace and the script to watch the appropriate function calls, next is to compile/launch the script before we finally launch our binary.

$ sudo stap -tv foo.stp
ready

And on a different terminal run the binary:

$ ./sl
42

This should get the above stap call, to spit out the following (or comparable) lines:

1318412226924288 (+0): foo_new 
1318412226924298 (+10): foo_get_type 
1318412226924309 (+11): foo_construct object_type=0x11afe30
1318412226924317 (+8): foo_class_init klass=0x11aff30
1318412226924324 (+7): foo_instance_init self=0x11a7180
1318412226924330 (+6): foo_do self=0x11a7180
1318412226924348 (+18): foo_do self=0x11a7180

First there is an absolute timestamp, followed by the delta between two (matched) function calls in brackets. The delta does not mean that the function call took so long, it is more the time between two function calls matching the regexp in the .stp file, so there can be an arbitary number of function calls between two listed ones.

EFI ➫ Fedora

Ain't unicode chars nice? :)

Finally, after much work EFI (much thanks to the anaconda team and all those testers) support is quite mature in Fedora 16 Beta. There are still some issues (➫ bugzilla) but in general it's working.

Hardware: It's not easy to see if your hardware supports EFI booting, best is took in your BIOS and see if the magic EFI keyword appears somewhere.

Boot media: If you want to try out an EFI boot media you've got two or three common ways of doing so.

1. First you try the Fedora 16 Beta DVD or netinst images.
   You can write those images to a DVD using nautilus (right click on the iso ...).
   Note: If you want to use them via a USB-stick you need to use the livecd-iso-to-disk tool, part of the  livecd-tools package. Also remember to pass the --efi switch. In generall it should look somewhat like the following example:

$ sudo livecd-iso-to-disk --format --efi \
  Fedora16-DVD.iso  /dev/sdg



2. The other way is to use the efidisk.img which can be found in the images directory of the DVD images. This image can be written to a USB-stick using dd:

   $ sudo dd if=efidisk.img of=/dev/sdg
   

Also note that the LiveCD images are not yet now bootable on a native EFI system.  Normally those systems will fall back to a legacy BIOS boot, which also makes it hard to determine if a system is booted via EFI or BIOS. (The path /sys/firmware/efi exists on systems booted via EFI)

EFI plus some boot optimizations can then finally lead to quick boot process.

Bodenständig - gswitcheroo reached some point.

Gswitcheroo, a small daemon to handle vgaswitcheroo, is now in a state that helps me.

Currently it suggests to switch to the discrete graphics card (an ATI card in my case), if an external monitor is detected non boot. If no external monitor is detected, it suggests to discable the discrete card, to save power. And because hybrid setups just appear in laptops, it usually makes sense to save some watts.

During the last weeks I've learned that it is not possible, to determin if a monitor is connected, when the discrete card is disabled. If I wanted to detect a hot-plugged monitor, I would need to do some polling (including turning the discrete card on and off), but this didn't seem to be to good, so I skipped it and just provided the basic functionality described above.

From vala to js - with emscripten.

Stumbling over emscripten again. A fun tool to compile llvm bytecode to JavaScript.
After installing some basic dependencies via

$ sudo yum install vala clang js

and a bit of glue (see below) and you can quickly run code written in vala using a JavaScript interpreter. All this can be done with all code clang compiles, so there is no more magic than normal involved.

$ cd /tmp
$ git clone https://github.com/kripken/emscripten.git
$ wget http://closure-compiler.googlecode.com/files/compiler-latest.zip
$ unzip compiler-latest.zip

Now that all software is in place, do some configurations by editing ~/.emscripten:

$ cat <<EOF ~/.emscripten
# path where you cloned emscripten
EMSCRIPTEN_ROOT=os.path.expanduser("~/tmp/emscripten") 
# I needed to link EMSCRIPTEN_ROOT/src/tmp to this path e.g. 
TEMP_DIR='/tmp' 

LLVM_ROOT=os.path.expanduser('/usr/bin/')
#LLVM_GCC=... # we don't have that on fedora
COMPILER_OPTS = ['-m64'] # Change to your arch!

SPIDERMONKEY_ENGINE = [os.path.expanduser('/usr/bin/js'), '-m']
COMPILER_ENGINE=SPIDERMONKEY_ENGINE
JS_ENGINE=SPIDERMONKEY_ENGINE
CLOSURE_COMPILER = os.path.expanduser('~/tmp/emscripten/closure-compiler.jar')

TIMEOUT=None
EOF

Basically now everything is in place. Using the following snippet

struct FooBar
{
	int m;
	public void wtf ()
	{
		stdout.printf ("Wtf!\n"); // The \n is important.
	}
}

void main()
{
	FooBar f = FooBar ();
	f.wtf ();
}

... we can compile and execute the whoole thing using the following lines:

$ valac --profile=posix --ccode vaem.vala
$ clang -emit-llvm -S -o vaem.ll vaem.c
$ ./emscripten.py va/vaem.ll -o vaem.js
$ js -m vaem.js
Wtf!
$

We need to use the posix profile, otherwise we need to compile the whole glib/gobject system using emscripten. Another way of creating JavaScript from vala code is using maja.

DisplayLink and vgaswitcheroo.

DisplayLink: Just something I wanted to share. The problem with current 'modern' laptops can be, that they don't provide a VGA port, which is often required to connect beamers (the reason why I needed one of those adapters). One way to to solve this, is to use some DisplayLink adapter, which allows to connect display via USB.

But it is hard to find real DisplayLink adapters, it took me two random and one informed transaction to get a supported adapter:LogiLink USB to DVI/VGA/HDMI Multi-Display Adapter (UA0077).

This adapter has quite good support in Fedora after installing the xorg-x11-driver-displaylink package.

$ sudo yum install xorg-x11-driver-displaylink
$ sudo modprobe sisusbvga

Use dmesg to find out about the assigned framebuffer-device (fb). Now the driver is available and the appropriate kernel module loaded but you still need to dump the following file into /etc/X11/xorg.conf.d/

# /etc/X11/xorg.conf.d/displaylink.conf
Section "Device"
        Option       "fbdev"     "/dev/fb2"    # use the device given in dmesg
	Identifier   "DLCard"
	Driver       "displaylink"
EndSection

vgaswitcheroo: Well, I didn't find out much more on the vgaswitcheroo side. I didn't find a way to determin if a monitor is connected to the discrete card, when this card is turned of (it seems that on some setups the integrated card get's "infos" about monitors connected to the discrete card, but not on mine). But I wont continue to poll for a monitor on the discrete card, so I'll just provide some trayicon (or how i's called in the shell slang), which enables the user to switch between the cards.

Alliteration - Fedora Fusion

I got my hands on a Lenovo x121e (5051) - an AMD Fusion E-350 powered laptop. So how does Fedora 16 Alpha 15 on that device?

Reasons? Much new things to test: EFI, AMD Fusion E-350, HDMI + VGA. And a quite low price tag at about € 360.
Like Fedora somewhat on the bleeding edge.

What works? Everything I tested so far. Wireless (Atheros), Graphics (ATI Radeon), Harddrive, USB, ...
And all those shiny things worked out of the box (!). No manual intervention needed, so a silent a cautious A+.

What doesn't? I just noticed some graphics glitches in gnome-shell, but maybe those will get fixed until the final release.

EFI: I could boot into Fedora 16 Alpha Live Desktop using the legacy fallback. EFI seems to work, but there are currently issues booting Fedora 16 with EFI, so I went back and use Fedora 15 updates-testing booted via EFI and BTRFS partitions.

qemu and backing images.

I always wondered but never really looked up how backing files can be used with qemu. I came back to this when stumbling across  the curl backend which brings http and ftp support to qemu and landed in fedora recently.
The idea is basically to use some master image accessed via http, e.g. residing in some object store, as a backing file for the actual image. This is a quite flexible setup. No need for iscsi or so.
Oh yes, the thing about a backing file is that all reads are happening on the backing file, until a block is written (also know as cow [copy on write]).

It turned out that the magic is happening while creating an image, not when running it:

$ qemu-img create -f qed -o backing_file=http://..../amaster.iso instance.qed 20G
$ sudo qemu-kvm -hda instance.qed

Sadly we can't test this on stock Fedora, as curl is enabled but currently broken in qemu. Maybe this ain't a bug at all or the bug is already fixed upstream (there are some fresh changes to curl), so this can be tested at some near point in the future.
It is also to note, that backing files also integrates well with libvirt.

Poll, no poll, poll.

While working on gswitcheroo I needed a reliable way to determine if a monitor get's connected to the HDMI port of the discrete card. But monitoring the HDMI port when the corresponding discrete card is powered off, doesn't seem to work.
A temporary solution is to power on the discrete card once and again, to see if a some monitor got connected. airlied point out, that maybe the integrated card is able to detect connected monitors. But in the first trial it didn't really work.

What also didn't work, was monitoring status changes of the discrete (radeon) card using udev (using udevadm monitor).  Time for more investigations.

Zyklisch - gswitcheroo is up and quasi working.

Tonight I had a bit of time and got gswitcheroo in a usable state.
gswitcherd is launched by systemd and gswitcher is launched gnome-session-manager. All fine.

If gswitcherd detects a connected HDMI port on boot it tries to turn on the discrete card (effectively turning off the integrated). Sadly there is currently a bug (or so) in vgaswitcheroo which prevents the successful switching from one to another card between plymouth and gdm. Maybe this will be fixed at some point - or not be needed at all ...

Another problem is about looking up the HDMI status (to automagically detect what card to use). This is just possible if the discrete card is powered on, but this ain't the case when we are using the integrated card. The current solution is to power on the discrete card once and again, to determine the HDMI status.

Beside all problems gswitcher will notify you about a freshly connected monitor and will ask you to log out (and back in).

Innendrin - A vala binding for TinyCC

Sunday night, best time to write some lines.

TinyCC (aka TCC) is a small but hyper fast C compiler. Unlike other C compilers, it is meant to be self-relying: you do not need an external assembler or linker because TCC does that for you. 

This vapi allows to call tcc from within vala, a small example is given below. I used it in conjunction with genetic programming.

using TCC;
void main(string[] args)
{
	State s = new State();
	s.add_include_path (args[1] + "/include");
	s.add_include_path ("/usr/include/");
	s.set_lib_path (args[1]);
	s.compile_string  ("""
#include <tcclib.h>
void main(int argc, char** argv) {
	printf("Hello %s\n", argv[0]);
}        
""");
	s.run ({"world."});
}

Rollo - gswitcheroo, a small daemon for vgaswitcheroo.

I'm working on a small library/daemo/client which wrap some functionallity of  vgaswitcheroo, a small kernel feature to handle hybrid graphic setups found in some laptops.

The main intention is to allow the user to switch to the required card
Sometimes this switch is required, because just one of the cards is connected to the external output of the laptop - which can be used to connect a beamer.

The current code can be found at https://gitorious.org/valastuff/gswitcheroo.
daemon and client should be working by now, but the installation bits need some work.

My intention is to add some configuration point to gnome-control-center. A first suggestion was to use the "System information" -> Graphics-Tab.
Any suggestions and early adopters?

EFI + KVM?

To test out the EFI support of some distributions (especially Fedora), I tried to get qemu-kvm to use provide an EFI interface. This can be achieved by calling qemu with the -L switch, to use an alternate EFi bios file (like the one from tianocore: OVMF), instead of the default bios.

To get qemu-kvm up and running, try the following on a recent Fedora 15 setup:

mkdir efiboot

cd efiboot

# Get ovmf, a binary providing the efi interface
mkdir ovmf
cd ovmf
wget "http://downloads.sourceforge.net/project/edk2/OVMF/OVMF-X64-r11337-alpha.zip?r=http%3A%2F%2Fsourceforge.net%2Fapps%2Fmediawiki%2Ftianocore%2Findex.php%3Ftitle%3DOVMF&ts=1315395958&use_mirror=dfn"
unzip OVMF-X64-r11337-alpha.zip

cd ..

# Create a seperate folder with all relevant binaries and replace some of them
mkdir qemu
cd qemu
ln -s /usr/share/qemu/* .
ln -s ../ovmf/OVMF.fd efi.bin
ln -s ../ovmf/CirrusLogic5446.rom vgabios-cirrusefi.bin

cd ..

# Create an image and try the distribution in question ...
qemu-img create -f qed a.img 10G
qemu-kvm -L qemu/ -bios efi.bin -m 1024 -hda a.img \
   -cdrom ../Fedora-16-Alpha-x86_64-DVD.iso
# Expecting this to boot, but after the efi boot manager, the booting after grub (?) stalls ...

It turns out that Fedora won't boot on this qemu-kvm setup, instead Ubuntu worked like a charm - but someone already worked on this a couple of years ago.

The Fedora docs mention that the provided efidisk.img should boot on an EFI based system, but this also did not work as expected. Any hints?

Brüken bauen - Using vala code from JavaScript

GObject based libraries can be called - thanks GObject introspection - quite easy from javascript (as well as e.g. python).
As vala builds on gobject, all code generated by vala can be introspected - when compiled with a fine selection of compiler switches.

Let's pretend that we have got a small library written in vala and want to use it from gjs - maybe because the that library is wrapping another non-gobject library or doing some heavy calculations.

To build a introspectable library a good practice is, to just use valac to generate the appropriate c-code and handle the build manually - or by using some build system.
When invoking valac it is important to pass the two both of switches --library and --gir. It is also important to specify the GIR name (--gir) in the format NAME-VERSION.gir whereas the library (--library) name expects just NAME-VERSION.

Build
Up to now it's just theory. The following lines guide you trough this process, step by step (testShared.vala is taken from here):

$ ls
testShared.vala

$ valac --ccode --header=testShared.h \
   --gir=TestShared-0.1.gir \
   --library=TestShared-0.1 \
   --pkg=gio-2.0 testShared.vala

$ ls
TestShared-0.1.gir  TestShared-0.1.vapi
testShared.c testShared.h
testShared.vala

$ gcc -fPIC -shared -o libTestShared.so \
   $(pkg-config --libs --cflags gobject-2.0) \
   testShared.c 

$ ls *.so
libTestShared.so
 

Typelib
After building the library we finally need to build the introspection data using g-ir-compiler (part of gobject-introspection-devel):

$ g-ir-compiler --shared-library=libTestShared.so \
   --output=TestShared-0.1.typelib TestShared-0.1.gir

$ ls *.gir *.typelib
TestShared-0.1.gir
TestShared-0.1.typelib

Testing
To finally test our introspectable data, why use gjs. We import the library using the (gjs specific) "imports.gi" keyword:

const TestShared = imports.gi.TestShared;
print('Square of 42: ' + TestShared.square (42));

On the commandline it looks like this:

$ GI_TYPELIB_PATH=. LD_LIBRARY_PATH=. \
   gjs --command="const TestShared = imports.gi.TestShared; \
   print('Square of 42: ' + TestShared.square (42));"
** (gjs:12175): DEBUG: Command line: gjs
** (gjs:12175): DEBUG: Creating new context to eval console script
Square of 42: 1764
$

Done. We managed to call a library function from gjs using GObject introspection. The creation of the (important) typelib should be included in you favorite build tools, one example using cmake can be found (again) here.

Oone final reminder: Not just vala code can be imported, but all gobject based libraries (e.g. libgtop2 for system informations, clutter for fancy UIs and more)

Is there something I forgot? Tell me :)


❧

Interpretieren und Rechnen - Vala binding for libmatheval.

libmatheval is small library of procedures for evaluating mathematical functions.

The appropriate vapi to use this library from vala can be found around the corner.
The usage of libmatheval is quite easy, here an example:

#!/usr/bin/vala --pkg libmatheval
using matheval;
void main ()
{
    var e = Evaluator.create ("x + y^2");
    print("e.evaluate_x:\t%s = %g\t\t| x = 4\n", 
        e.get_string(), e.evaluate_x (4));
}

More functions calls can be found here.

Klein - Elementary things.

Elementary OS always caught or users attention because of it's design principles, which lead to a very aesthetic appearance (including the gtk elementary theme) and some very nice applications like postler.

Anyhow, this time it got my attention because it's favored programming language seems to be vala. Surprise :)

A part of this effort is also to improve the programming experience by providing an - in loose words - integrated development environment - an editor (scratch + vala plugin) and build system (cmake). Nice.

Vereinfachte Ausgangsschrift - A couple of code lines.

To get started with vala you need the vala-to-c-compiler valac, common development tools and libraries.
Detailed instructions about the needed build tools can be found at the GNOME Development Tools page. And the most recent vala compiler can be obtained from the official vala page. Vala is packaged for all major distributions, e.g it can be installed on Fedora using yum:

$ sudo yum install vala

If all requirements are met, put the lines below into a file named printargs.vala:

void main (string[] args)
{
  foreach (var arg in args)
  {
    print ("Argument: %s\n", arg);
  }
}

As we have got some code now, we need to compile it using valac, the compiler which compiles vala to c and subsequently calls a c-compiler to build an executable.

$ valac printargs.vala
$ ./printargs some arguments
Argument: ./printargs
Argument: some
Argument: arguments

If you wonder what C-Code valac generated, call valac with the following switches:

$ valac --save-temps printargs.vala
$ cat printargs.c

Wenn es sich bezieht - Progress on OpenStack in Fedora

Lately Mark McLoughlin made some great progress in packaging several OpenStack components for Fedora. Because of his work, all important OpenStack components (Nova, Swift, Glance) will land in Fedora 16.

Lose Enden - What it is all about.

The release of GNOME 3 included more than a visual overhaul. The underlying libraries were partly cleaned up and gained new features.

One of these features that gained more ground was gobject introspection (gi). Libraries using GObject can then easily be called from languages like python or Javascript if the support introspection.

This is where vala jumps in. Vala is language which tries to support the C# syntax but uses GObject and compiles to C, which then is compiled into binaries using common C compilers.

So what is the benefit? As all executables and libraries created by vala or based on GObject, their functions and classes etc. can be called natively from gjs (a JavaScript interpreter) and python (using pygi)
Also most GNOME related libraries are build using GObject.

This leads us to the situation where you can use a scripting language and have access to a comprehensive stack of libraries regarding the GNOME desktop environment.

• Rapid development? JavaScript.
• Layout? Glade.
• Style? CSS.
• Library? Vala.

It's not just theory. Look at gnome-shell or gnome-documents.