It notifies me with desktop notification of failed build and of successful build that took longer than 30 seconds (and I got bored watching “The Matrix”). It requires colormake and notify-send installed and is activated by:

alias make=make-wrapper

#!/bin/bash
MINIMUM=30

ERR=$?
case $ERR in
0)
[[ $(($SECONDS - $START)) -gt $MINIMUM ]] && notify-send -t 3000 -u critical -i gtk-ok "make $1 OK"
;;
141)
tput setaf 1
echo "make stopped by ^C"
tput sgr0
;;
*)
notify-send -u critical -i gtk-dialog-error "make $1 FAILED:$ERR"
;;
esac
exit $ERR


Give old ‘make’ some flare ©, .

Just click your name in the top-right corner and select “System Settings”. The system settings window will appear.

There select “System Info”. (Yes… System Info) and there select “Graphics” tab. (Yes… Graphics)

Now all you need is to switch ON the “Forced Fallback Mode” and relogin.

After login you will be greeted with familiar two panel desktop with defaultish look. Panels work as always, with one exception – every widget is locked in place by default. To customize it you need to right-click it holding Alt button. And they may be aligned to the left, center or to the right of the panel – just by dragging them where you want with the middle mouse button, holding Alt of course. Try it by dragging the clock to the right position where it belongs. Right-clicking the panel (holding Alt button, remember) gives you the standard menu to customize the panel, add widgets and create new panels.

If you run Ubuntu, you can even get Unity’s Indicator Applets on the panel. See article for instructions.

How to restore GNOME 2 look to GNOME 3 desktop ©, .

Mer picks up the idea of MeeGo Core, and provides a very stripped down, mobile devices oriented Linux distribution. But this distribution is vendor oriented. Not end-user oriented. Mer’s goal is to provide a base that vendors can build on and create end-user oriented products.

There are two kinds of vendors. Ones providing a “hardware adaptation” and ones providing “user experience”.

Hardware adaptation lies below Mer, and makes Mer run on a specific hardware. Let it be an Intel CPU based PC or Netbook or an ARM SoC based mobile device or any other esoteric hardware.

User Experience vendor provides a layer on top of Mer, interacting with a live human user. This may be the MeeGo Tablet UX, MeeGo Netbook UX, Plasma Active, Cordia HD, MeeGo IVI or any other User Interface.

This allows for many combinations and decouples the effort. Of course you can be both hardware adaptation and user experience vendor, building a complete Product.

Have fun in the spirit of openness.

Mer – What is it all about? ©, .

I’ve spent a few months searching for a tablet device manufacturer in Shenzhen, willing to release the source of the Linux kernel used on the device. Finally the manufacturer of the Dreambook W7 tablet agreed to provide the source. So I got sample devices and started experimenting. I got MeeGo 1.1 to run successfully even using the binary kernel the Android runs on. So I decided to go public with the Cordia Tab project and get interested people around, waiting for the kernel source.

September 13th the news hit, that the manufacturer won’t release the kernel source and they are basically blackmailing us to either order a copious amount of the devices upfront or pay a few thousands USD “ransom” that will be returned after ordering even more tablets. Conditions impossible to meet for a community project with virtually no funding.

Searching for other manufacturers brought the same result as my previous attempts – every single manufacturer doesn’t care a button for GPL conditions and keeps the modified Linux kernel secret. Little wonder, as even giants like Dell fail to comply.

We cannot use the binary kernel provided for the Android build, as it lacks crucial features like devtmpfs and cgroups support. More importantly it locks us from any future upgrades – we need to be able to forward-port features to newer kernels.

Well… I will keep looking for the hardware, but for a moment I just got back to working on Cordia HD software, waiting to see what the future would come up with.

Cordia Tab kernel tale ©, .

I branched the updated GTK+ to my OBS project and ported required changes. After updating my GTK+ with freshly built one AppMenu started working. Mandatory screenshot follows.

My repository bases on GNOME:Ayatana, so you will need both to install:

# zypper ar http://download.opensuse.org/repositories/GNOME:/Ayatana/openSUSE_11.4/GNOME:Ayatana.repo
# zypper ar http://download.opensuse.org/repositories/home:/smoku:/unity/GNOME_Ayatana_openSUSE_11.4/home:smoku:unity.repo
# zypper install appmenu-gtk indicator-appmenu

Next add ‘Indicator Application Menu’ applet to your panel and relogin.

You may want to install other indicators and add them to panel:

# zypper search indicator-

Ayatana AppMenu under openSUSE ©, .

I don’t want to encrypt the whole /home partition, because I don’t like to watch the boot process of my computer waiting for the moment it wants to mount it and asks me for the disk encryption password. Then wait some more and enter the user password. I want to use just one password for both and let the login process do the magic for me.

Actually getting this setup under openSUSE is as easy as going to YaST -> User management -> Your user -> Edit -> Details and checking “Use encrypted home directory” checkbox. But I didn’t go this way for three reasons:

• I wanted to have my encryption key on a separate device (explanation at the next paragraph)
• I wanted to have a strong grip on what is going on under the hood in case of emergency (ie. system crash recovery)
• The automagic GUI simply did not work in my case ;-)

My laptop has an MMC reader, so I wanted to utilize Jaervosz idea of having disk encryption keys in my pocket every time I need to leave the computer unattended. This gives a very good physical keys analogy. Also might be useful in countries you are required by law to reveal your password to certain services. It’s easily verifiable that you gave the real password by logging to the machine. But you cannot be expected to reveal key file content of the MMC that got “damaged” or lost. (Of course it’s crucial to have a backup of the MMC content in some safe place.) I use a small (256MB) and quite fast (Class 4) MicroSD card I had spare left after a mobile phone.

Let’s start with an easy bit and encrypt swap first. I’m not that paranoid to fear of data leaking through swap, but this gives a nice checkpoint before following with putting your crucial $HOME data into a box you may be unable to open later. ;-)

Install some packages you will need:

# zypper install cryptsetup cryptconfig pam_mount

Put one line in /etc/crypttab file:

swap /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

and replace swap device entry in your /etc/fstab with /dev/mapper/swap like this:

/dev/mapper/swap   swap   swap   defaults   0 0
[...]

Add boot.crypto script to boot level:

# chkconfig --add boot.crypto
boot.crypto   0:off  1:off  2:off  3:off  4:off  5:off  6:off  B:on

Now reboot. You should have a /dev/mapper/swap encrypted device being used as swap:

# ls /dev/mapper
control  swap
# swapon -s
Filename		Type		Size		Used	Priority
/dev/mapper/swap	partition	10490408	0	-1

Congratulations. You may now follow with encrypting your real data.

Setting up LUKS encrypted loop device, pam_mount configs, etc. may be a bit cumbersome while doing everything by hand. Fortunately there is a tool to ease the pain – enter cryptconfig. It has a lot of tools off which we need to use only few.

First mount MMC on /mmc directory:

# mkdir /mmc
# mount /dev/mmcblk0p1 /mmc

Next you need to create an encrypted disk image file with associated key file. Unfortunately when I wanted to create a properly big image, cryptconfig complained that it won’t fit on my partition so I ended up creating a small one and enlarging it after. (BTW, You may want to use your own username instead of “user” ;-) Use your user password when asked for.

# cryptconfig create-image --key-file /mmc/user-home.key /home/user.img 20000
# cryptconfig enlarge-image --key-file /mmc/user-home.key /home/user.img 200000

Next add pam_mount to PAM and create its configuration file:

# cryptconfig pm-enable --key-file /mmc/user-home.key user

Next you need to tweak pam_mount configuration. I don’t want to mount /mmc content via fstab because that would make my laptop unbootable with MMC removed. Instead I engage pam_mount to do this for me. Add the following line just before the last line mounting your home in /etc/security/pam_mount.conf.xml file:

<volume fstype="auto" user="user" path="/dev/mmcblk0p1" mountpoint="/mmc"/>

But having a removable device connected and not present in fstab may cause that Volume Manager will want to mount it under removable /media. To mitigate this, add the following line to /etc/fstab:

/dev/mmcblk0p1   /mmc   auto   noauto   0 0

That’s it. You have completed the setup. Now you just need to fix your home directory image content permissions (it’s just an empty filesystem owned by root) and transfer your data.

Kill your current X session by tapping Ctrl-Alt-Backspace twice or reboot again. Log in to your account and you should see your desktop environment complaining it has no access to your home directory. Good – this means your encrypted home directory was mounted properly. Let’s fix it.

Switch to text mode console (Ctrl-Alt-F1), login as root and fix your home directory permissions:

# chown -R user:users ~user

Next the tricky part – transferring your data:

# mount -o bind /home /mnt
# rsync -rvaP /mnt/user/ /home/user/

After killing X again log in and verify that your desktop works correctly. After that you may cleanup by removing /mnt/user content:

# rm -rf /mnt/smoku/*
# rm -rf /mnt/smoku/.[a-zA-Z0-9]*
# umount /mnt

Congratulations. You have an encrypted home directory mounted on login, using a “physical key” in a form of a Memory Card. Reboot. :-)

P.S. You may want to make some other areas like /tmp inaccessible to anyone getting hands on your computer. I solved it by mounting /tmp with tmpfs. But that’s something for a different article.

Home directory encryption++ under openSUSE ©, .

Rebuilding the package didn’t help, so I started investigation. It turned out that the lua package SPEC “fixed” the CFLAGS= line in Makefile incorrectly, omitting $(MYCFLAGS) variable which is crucial to set POSIX support on Linux, thus most of POSIX support (ie. popen) was just skipped.

You will find fixed Lua and built LuaRocks packages at: http://codex.xiaoka.com/pub/packages/redhat/. Added bonus: Lua is patched to 5.1.4-3.

Lua 5.1.4-3 for CentOS with fixed io.popen ©, .

Cordia on Ideapad ©, .

It was over a month ago and, oh boy, was it a good change! :-) Last time I tried SuSE several years ago I was hit by RPM-hell badly, reverted to Gentoo and never looked back. Then I grew to binary packages distribution and switched to Ubuntu.

When Nokia decided to ditch Maemo and its Debian based underlying technologies I wasn’t happy. Then I needed to package some things for my MeeGo ports, met OBS and was amazed how great tool it is. Then I realized how good packaging tool RPM became during the years.

Having openSUSE as my main system gives me the solid base of stable and well tested system and access to bleeding edge software in the areas I want. OBS builds the most recent GNOME or web servers not only for the running (Factory) distribution but for the stable trees too. So I have the flexibility of mixed stable+experimental system I was used to running Gentoo, without the hassle of building it myself.

There is one more thing – openSUSE developers does not feel that they know better than the upstream developers and does not ditch features users are expecting to find in their desktop environment, replacing them with custom, unstable and incompatible thingies. You still have this vanilla feeling using openSUSE – with just a bit of chameleon branding sprinkled here and there.

Bienvenidos openSUSE ©, .

Porting the MeeGo Core was very easy. I already had experience with building MeeGo images, so the only thing to get was Archos specific knowledge. openAOS is a very good resource and I had SDE firmware with openAOS multi-bootloader installed in few hours. It took me a few hours more preparing Archos specific firmware and configuration packages and building the image. Also the device kernel needed a little fix to build fine under CodeSourcery toolchain. And there I had it – MeeGo Core on Archos running omapfb X11 driver.

The next thing required for MeeGo is the 3D acceleration. The UI uses it for nice animations and will not work without one. Unfortunately the SGX bundle for the stock device did not work for me at all. Besides that, BuBu that got it working reported problems with scrambled font rendering.

So I decided to try another approach. MeeGo non-oss repository has the SGX driver and GLES libraries available for N900 and Beagleboard. Archos 5it uses the same OMAP3430 with PowerVR as N900 so it should be able to use the MeeGo provided binaries. The only thing missing in Archos kernel was the DRI2 kernel level glue layer for PoverVR. So I decided to backport drivers/gpu/pvr from recent MeeGo 2.6.35.3 Linux kernel to Archos provided 2.6.27.10. It required support for OMAP clock notifications, so I backported these too. Using my kernel and modules I was able to get fbdev-sgx X11 driver and GLES acceleration up and running.

Next step was building MeeGo Handset UI image to test the now-working Core.

My Archos kernel binary and MeeGo Core image with SGX acceleration working is available at http://codex.xiaoka.com/pub/meego/archos/

MeeGo for Archos Generation 7 ©, .