If like me you care about your data stored on your laptop, you certainly use a fully encrypted (excepted /boot) configuration based on lvm.

In my case I also like to create, build, fix packages locally with our tool osc. I’ve plenty of power, beefy ssd, so I dedicate a logical lvm for building cleanly package with qemu-kvm configuration, like obs does

Prepare the kvm building system

As root you create 2 lvm volume with lvcreate, one will be the build root, the other one will be the additional swap

In ~/.oscrc I enable the following parameters

build-type = kvm
build-device = /dev/mapper/vg0-lvobsbuild
build-swap = /dev/mapper/vg1-lvobsswap
build-memory = 4096
build-vmdisk-rootsize = 16000
build-vmdisk-swapsize = 4000
build-vmdisk-filesystem = ext4

You just have to adjust the Memory quantity and the device to what you create for your own environment.

Building with qemu-kvm

Once the preparation is done you could try to build a package

Skipping verification of package signatures due to secure VM build
Writing build configuration
Running build
No initrd that provides virtio support found. virtio accelleration disabled.
Run the following command as root to enable virtio:
 "env" "rootfstype=ext4" "mkinitrd" "-d" "/dev/null" "-m" "ext3 ext4 btrfs reiserfs binfmt_misc virtio_pci virtio_blk" "-k" "/boot/vmlinuz" "-i" "/boot/initrd-3.13.6-1.g4727218-desktop-virtio"
VM_IMAGE: /dev/mapper/vg0-lvobsbuild, VM_SWAP: /dev/mapper/vg1-lvobsswap
Creating ext4 filesystem on /dev/mapper/vg0-lvobsbuild
tune2fs 1.42.8 (20-Jun-2013)
Setting maximal mount count to -1
mkswap /dev/mapper/vg1-lvobsswap
Setting up swapspace version 1, size = 4194300 KiB
no label, UUID=935f0e2d-52d7-4013-8a7f-7d48c813a482
logging output to /tmp/obsbuild/.build.log...

As you can see, it warn you that you could create a -virtio initrd to use virtio acceleration (who contribute a patch for the typo

But the command line is not completely correct in our case. It need the -d to be filled with the lvm buildroot to work as expected. If you successfully create the initrd-virtio you still will face a number of trouble, due to the way mkinitrd work.

Defeating the errors

You remember that we have a fully encrypted volume group, and as a clever tool mkinitrd will feed the initrd with all the tools needed to boot your system.

But that mean it will forget the lv buildroot we ask, and will put unnecessary tools and options.

Typical errors with a non optimized -virtio initrd

[    3s] /usr/bin/qemu-kvm -no-reboot -nographic -vga none -net none -cpu host -kernel /boot/vmlinuz -initrd /boot/initrd-3.13.6-1.g4727218-desktop -append root=/dev/sda panic=1 quiet no-kvmclock nmi_watchdog=0 rw elevator=noop console=ttyS0 init=/.build/build -m 4096 -hda /dev/mapper/vg0-lvobsbuild -drive file=/dev/mapper/vg1-lvobsswap,if=ide,index=1,cache=none -smp 8
[    9s] FATAL: Error inserting nvidia (/lib/modules/3.13.6-1.g4727218-desktop/updates/nvidia.ko): No such device
[    9s]   WARNING: Failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.
[    9s]   Volume group "vg0" not found
[    9s]   WARNING: Failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.
[    9s]   Volume group "vg0" not found
[    9s] *** Note: only US keyboard layout is supported.
[    9s] *** Please ensure that the password is typed correctly.
[   41s] Waiting for device /dev/disk/by-id/ata-Corsair_Force_GT_blah-part2 to appear: ..............................Unlocking cr_sda2 (/dev/disk/by-id/ata-Corsair_Force_GT_blah-part2)
[   41s] Device /dev/disk/by-id/ata-Corsair_Force_GT_blah-part2 doesn't exist or access denied.
[   41s] Trying manual resume from /dev/vg0/lvswap
[   41s] resume device /dev/vg0/lvswap not found (ignoring)
[   41s] Trying manual resume from /dev/vg0/lvswap
[   41s] resume device /dev/vg0/lvswap not found (ignoring)
[   73s] Waiting for device /dev/sda to appear: ..............................Could not find /dev/sda.
[   73s] Want me to fall back to /dev/vg0/lvsuse? (Y/n)

Rescue you have as root to kill all build process.

for P in $(ps auxw| grep build | grep -v grep | awk {'print $2'} );do kill $P;done

Find a solution

We want an optimized -virtio initrd, which filter all the lvm and crypting tools we don’t need. Also there’s no need to encumber it with graphic blob.
Then I create a small script I’ve called patch-initrd-virtio (source below) which exactly do that work anytime I’ve a kernel change.
As it need to be run by root only, I normally place it in /root/bin/

patch-initrd-virtio sources

#!/usr/bin/env bash

# WTF License 1.0 
# Author Bruno Friedmann tigerfoot (at) opensuse.org

# Usage : this script will create an optimized virtio initrd without
# lvm, crypt, gfx tool
# by using the actual /boot/initrd symlink you have.
# Edit the 2 devices you target to use 
# 
DEVBUILD='/dev/vg0/lvobsbuild'
DEVSWAP='/dev/vg1/lvobsswap'

nokms(){
sed -i '/^NO_KMS_IN_INITRD/s/no/yes/' /etc/sysconfig/kernel
}

kms(){
sed -i '/^NO_KMS_IN_INITRD/s/yes/no/' /etc/sysconfig/kernel
}

echo "cleanup /tmp"
rm -fr /tmp/initrd*

# Patch the virtio initrd
if [ -z "$1" ];then
export VER=`uname -r`
else
export VER="$1"
fi
export INITRD="/boot/initrd-$VER-virtio"
echo "Setting nokms"
nokms

echo "Building -virtio initrd ..."
"env" "rootfstype=ext4,resume=$DEVSWAP,rootdev=$DEVBUILD,udevtimeout=2,udev_timeout=2,nosplash,noluks" "mkinitrd" "-B" "-d" "$DEVBUILD" "-m" "ext4 btrfs binfmt_misc virtio_pci virtio_blk" "-k" "/boot/vmlinuz-$VER" "-i" "$INITRD"

ls -l $INITRD

echo "Setting kms"
kms

# copy the *.virtio initrd to /tmp
cp -vfa $INITRD /tmp/initrd-virtio.gz

# ungzip it gzip -d initrd
cd /tmp
mkdir initrd.build
gzip -d initrd-virtio.gz

cd initrd.build

# uncpio cpio -id < ../initrd
cpio -id  ../initrd
rm -fv ../initrd-virtio
echo "rebuilding initrd ..."
find . | cpio --create --format='newc' > ../initrd-virtio
cd ../
echo "Compressing initrd ..."
# Install pigz if you want to save half an hour of your life.
if [ -x /usr/bin/pigz ];then
 pigz -9v initrd-virtio
else
 gzip -9v initrd-virtio
fi
# copy to /boot
cp -v initrd-virtio.gz $INITRD
echo "Done ..."

Usage of patch-initrd-virtio

Here’s the result of a run

cleanup /tmp
Setting nokms
Building -virtio initrd ...

Kernel image:   /boot/vmlinuz-3.13.6-1.g4727218-desktop
Initrd image:   /boot/initrd-3.13.6-1.g4727218-desktop-virtio
Root device:    /dev/vg0/lvobsbuild (mounted on / as ext4)
Resume device:  /dev/vg0/lvswap
enabling LUKS support for /dev/disk/by-id/ata-Corsair_Force_GT_blah-part2 (cr_sda2)
Microcode: Adding Intel microcode 06-2a-07
Kernel Modules: thermal_sys thermal processor fan libcrc32c xor raid6_pq btrfs binfmt_misc virtio virtio_ring virtio_pci virtio_blk dm-mod dm-crypt dm-log dm-region-hash dm-mirror dm-snapshot scsi_dh scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh_emc xhci-hcd hid-logitech-dj hid-holtek-kbd hid-lenovo-tpkbd hid-ortek hid-roccat hid-roccat-common hid-roccat-arvo hid-roccat-isku hid-samsung ohci-pci linear arc4 sha256_generic cryptd crct10dif-pclmul crc32-pclmul crc32c-intel ghash-clmulni-intel aes-x86_64 glue_helper gf128mul lrw ablk_helper aesni-intel
Features:       acpi dm intel_microcode block usb lvm2 luks btrfs resume.userspace resume.kernel
Did not refresh the bootloader. You might need to refresh it manually.
-rw------- 1 root root 29338540 Mar 15 18:18 /boot/initrd-3.13.6-1.g4727218-desktop-virtio
Setting kms
‘/boot/initrd-3.13.6-1.g4727218-desktop-virtio’ -> ‘/tmp/initrd-virtio.gz’
160249 blocks
removed ‘./boot/71-luks.sh’
removed ‘./config/luks.sh’
removed ‘../initrd-virtio’
rebuilding initrd ...
160239 blocks
Compressing initrd ...
initrd-virtio to initrd-virtio.gz
‘initrd-virtio.gz’ -> ‘/boot/initrd-3.13.6-1.g4727218-desktop-virtio’
Done ...

Finally start a build with -virtio activated

So with our new optimized initrd-virtio we can restart a fully qemu-kvm build with osc build –clean

Skipping verification of package signatures due to secure VM build
Writing build configuration
Running build
VM_IMAGE: /dev/mapper/vg0-lvobsbuild, VM_SWAP: /dev/mapper/vg1-lvobsswap
Creating ext4 filesystem on /dev/mapper/vg0-lvobsbuild
tune2fs 1.42.8 (20-Jun-2013)
Setting maximal mount count to -1
mkswap /dev/mapper/vg1-lvobsswap
mkswap: /dev/mapper/vg1-lvobsswap: warning: wiping old swap signature.
Setting up swapspace version 1, size = 4194300 KiB
no label, UUID=c19c873b-2b6c-4200-9575-a60adc581204
logging output to /tmp/obsbuild/.build.log...
[    0s] Using BUILD_ROOT=/tmp/obsbuild/.mount
[    0s] Using BUILD_ARCH=x86_64:i686:i586:i486:i386
[    0s] Doing kvm build in /dev/mapper/vg0-lvobsbuild
[    0s] 
[    0s] 
[    0s] c-3po.labaroche.ioda.net started "build postgresql-plr.spec" at Sat Mar 15 17:27:18 UTC 2014.
[    0s] 
[    0s] 
[    0s] processing specfile /home/bruno/openSUSE/obs/home:bruno_friedmann:branches:openSUSE:12.3:Update/postgresql-plr.openSUSE_12.3_Update/postgresql-plr.spec ...
[    0s] running changelog2spec --target rpm --file /home/bruno/openSUSE/obs/home:bruno_friedmann:branches:openSUSE:12.3:Update/postgresql-plr.openSUSE_12.3_Update/postgresql-plr.spec
[    0s] init_buildsystem --configdir /usr/lib/build/configs --cachedir /var/cache/build --prepare --clean --rpmlist /tmp/rpmlist.Vy31Li /home/bruno/openSUSE/obs/home:bruno_friedmann:branches:openSUSE:12.3:Update/postgresql-plr.openSUSE_12.3_Update/postgresql-plr.spec ...
[    1s] cycle: pam -> permissions -> coreutils
[    1s]   breaking dependency permissions -> coreutils
[    1s] [1/29] preinstalling filesystem...

Hope this give you the taste of building!

This has been one of the guidelines in my life for quite some time… It started as a curiosity a long time ago with Notify OSD and evolved to full project in openSUSE. It is important to acknowledge at this point the motivation provided by the openSUSE GNOME Team from which I’ve been getting plenty of guidance and help, namely from Vincent Untz (vuntz) and Dominique Leuenberger (Dimstar). Thanks to them, we have now a GNOME:Ayatana Project on OBS (openSUSE Build Service), currently being populated with the support libraries for Ayatana’s Unity and Indicators.

Susan Linton has made a small article for Linux Journal about this project in the past. Though some people pointed to me that it was advertising and excelling Ubuntu… I would like to leave a statement… We’re not taking a hike on Ubuntu visibility, and it isn’t bad at all, on the contrary… In fact it will help Ubuntu, us and many others… specially if some Ubuntu patches are accepted faster by upstream. I hope other RPM distributions will follow the way we, openSUSE, proudly seem to pioneering! From my personal point of view… a distribution ‘distributes’… and despite this software isn’t attractive for some openSUSE users, I’m happy it is available (totally or partially) for all those who want to test it… Wait… you don’t even need to install Ubuntu or changing the platform you run!

Due to several reasons, being the most important of them versioning, this repository will start on the next release of openSUSE in March 16th (World day of Conscience, interesting point). This is also interesting as if YOU are willing to improve a package or submit a package you can now do it to this repository.

This goes with a very huge cookie for Dimstar and Vuntz for taking care of this repository and making sure that everything will comply with the openSUSE Guidelines. You are my personal heroes.

It has been quite an interesting experience to be with openSUSE GNOME team which is full of knowledge and helpful in many ways. I can’t also forget to mention that last week Luis Medinas has taken tutorship of a Portuguese contributor to openSUSE GNOME, João Matias and will provide him the necessary help to integrate him on the workflow of the GNOME Team. My personal thanks to Luis for stepping into this task, which from my personal point of view is very important.

Regarding to Ayatana it is worth to mention that Dimstar provided some valuable help in fixing the dbusmenu package and taking care of the necessary patch submission in GTK and gdk-pixbuf to allow dbusmenu to build with introspection support and generate properly the Vala files required for other packages. This handicap beaten… we’re on the good road for better functionality. This patches also allowed to correct some behavior in some indicators, one fine example of this the ‘Me Menu’ which now displays correctly a  ‘dot’ on the selected status as the screenshot bellow shows:

In the last days, despite it’s Christmas season and soon new year…. I’ve been also working on providing additional extensions to enable some functionality on some indicators. This was the case of indicator-sound, which provides an alternative sound gadget that offers extended functionality with multimedia players. A fine example of this is Novell’s Banshee player which has astonishing out of the box implementation with the sound indicator from Ayatana by a small extension that can be enabled. I’m still wondering why so many people toss heavy critics at this indicator calling it ‘mac styled’… while to be honest I doubt such people have even seen OSX sound applet, which is more or less a direct copy of the one present in GNOME, the vertical switch. Interesting view nevertheless.

Indicator-sound has also been fixed and no longer requires the nasty hack in the previous package. Since I’m not an Ubuntu user, neither I have extensive experience on their Desktop, I’m not sure if the functionality present so far in the indicators is the one offered by Ubuntu. I plan to run a Open Beta on the Ayatana software repository during the last Milestone of Factory to all Factory users to collect more data and improve the packages, at least the indicators, as in the present since I have ATI hardware I don’t have FireGL enabled on Factory, so I can’t really push much on Unity and test it for the time being.

Another subject of plugins was Xchat which is GNOME’s premier IRC client. Novell’s Evolution also got it’s plugin which is found to be partially working. I haven’t tracked yet if there are patch submissions to Evolution from Ubuntu to enable indicator functionality. That’s for sure one of the next steps, and since Evolution is a bit of ‘in-house’, would be nice to have them approved upstream if submitted already, as it would serve openSUSE as well.

Most of this applications, evolution, xchat, gwibber, empathy, pidgin are supported by indicator messages which collects information from several messaging services and places them on a single indicator in a cascade style experience for the user. I personally find it weird as I’m not used to this, but seems nice. Unfortunalty some applications seem rely on patches to be fully supported, like empathy. I hope upstream accepts the patches from Ubuntu (if submitted) and we can also benefit from such changes in our side.

Basically to sum up everything in a short review…

* Indicators are working fully or partially depending on patch level on some applications. If upstream starts accepting Ubuntu patches (some shouldn’t be much of a problem), it will work out for Ayatana software in openSUSE as well.
* Unity – Though it builds already with some compiz packaged from git sources (to include glib mainloop patching), I have no way of testing it, neither I have done integration on it. Unfortunately both my systems have ATI hardware and I have no way of testing it on Factory which seems to be too much bleeding edge for ATI to keep up. It’s stalled a bit, but in the worst scenario will be available a few weeks after the next official release of openSUSE.
* During this wait time… we might see a new release of compiz with the patches upstreamed by Canonical, which will for sure help us also a lot. No need for hurry in Unity at this time.

My personal experience with this project has given me lots of knowledge about OBS, hacking Makefiles and configure scripts… debug skills… and specially I ended up loving the way openSUSE is built and how it works. I would take also this opportunity to make a small statement… all the development so far has been deployed over GNOME 2.32. Much of the software packaged already supports GTK3 and should be easy to migrate it to GNOME3. At the moment, since the next openSUSE release is still based on GNOME 2.32, I’m not testing all this software on GNOME3. It might take a few days/weeks to have it available for GNOME3 after it’s release, though from a personal perspective, what I’ve seen on GNOME3 seems to be overkill! It’s damn nice and I have no doubt GNOME3 will succeed as the ultimate Free Desktop.

I would also like to mention that I’m not testing this indicators with KDE. In case someone wants to do this, please feel free to nag me on IRC (#opensuse-gnome @ Freenode) and leave feedback. I’m focused only on GNOME2 and GNOME3 deployment of this software packages, though I will help in whatever way I can if someone wants to work them out for KDE.

I’m using a patched version of Metacity (patches were submitted upstream) which improves the display of buttons by improving overlaying of images (I think). Look at the sharp corners of the theme in the pic bellow. As always, Faenza Icon theme with Canonical’s light theme Radiance (not hacked). This is another change I hope that goes upstreamed soon.

My sincere congratulations to everyone working on the awesome GNOME3, I’m sure it will be a success and make the delights of many! My faith points that GNOME3 will change Desktop user experience forever!

Have a lot of fun…!

Nelson Marques

That is one reason why we consider it as one of the keys for success that the Build Service enables people to work together in a useful and non annoying way. We think of tools in the Build Service which help. That is difficult because some formalism and guidance (in business often called ‘process’) is needed to keep things going in a transparent and reproduceable way. Control should stay there where it needs to be, for example at the maintainer of a project. On the other hand collaboration tools should not constrict people and their working together.

Here is a little story of Karl who wants to change something in the openSUSE Factory project. He needs to work with the Factory maintainers and this is how that is planned for the future:

Karl, a developer working for a small software company, loves openSUSE but not really the one package Kabax because there is a packaging problem Karl has analyzed.

Karl wants to change that to make sure that the next version of openSUSE contains a good version of Kabax.

For that, a branch of Kabax in Factory is needed where the fixes can be put in, built and tested. Karl uses osc to create a branch. The package is not really maintained in Factory itself, because the few Factory maintainers can not care about all packages there. Kabax has a Devel Project entry in its meta data that points to the project where it is actually maintained by the expert Karsten.

Because of the devel project, osc branches not really from the Factory package but from the development project where the development happens by Karsten. That might be different from the Factory package, but is clearly the development version that soon will be synced to Factory. When that happens is up to Karsten and the maintainers of Factory.

In the branch Karl starts to work on Kabax and creates a beautiful patch. Since his branch package also lives on the Build Service, it builds live for all relevant repos and along the changes of the devel project.

Once Karl is happy with his work he raises the attention of Karsten on his change by creating a submit request. A request in general informs others of something somebody else has done which requires action. In the case of the submit request it tells Karsten that there is a valuable change to his package that should make it’s way to Factory. Karsten now accepts the request and Karls contribution is in.

The nice thing about all this is also that the branch packages as well as the requests are open and visible to everybody who is interested in. That gives us the transparency we need. And of course that does not only work for Factory but for all projects if one wants to change something on a package where he/she does not have permissions yet.

How do you like this story?