wheeee… 8)

• Time daemon (timed)
• Mode Control Entity (MCE)
• Sharing Framework
• Non-Graphics-Feedback (NGF)
• Profiles
• Qt style APIs (QmSystem)

Arjan van de Ven explains:

Recently we have been evaluating these features and feel that these  technologies, as integrated into MeeGo, haven’t reached the maturity that we want to commit them into MeeGo 1.2 core.

As a result we are proposing to, for MeeGo 1.2, not include these  components in the official architecture diagram or the compliance spec since either means a compatibility commitment going forward as well as a requirement for everyone who makes products with the MeeGo brand to include these components. As these things mature going forward, we hope that for MeeGo 1.3 we can put a much more mature policy layer as part of the core architecture and compliance set.

He also notes that the components are not removed, but as the result of removing them from the compliance specification not all MeeGo 1.2 products have to include them.

On follow-up Jussi Liukkonen points out:

I would consider this a prudent approach. APIs we cannot comfortably commit to, we should not commit to. And these APIs have not settled yet.

However, the functionalities these components implement are quite important for actual products. I expect we’ll see a number of 1.2 based products, more or less relying on these implementations.

These components are mostly driven by Nokia. This move just might be a test for Nokia to see if they are truly engaged to MeeGo in the future. If Nokia does the necessary work to keep them for 1.3 and truly shows the motivation and engagement then the components will be available in the future, too.

On the other hand if Nokia drops the ball completely and stops maintaining these components I’m not sure if Intel is willing to drag them along alone. By removing these components from compliance specification Intel can drop them in the future if no one is left to maintain and develop them further.

Nomovok’s strategy and direction however does not change. We continue to commit our selves on MeeGo and that direction seems very strong in long term.

Unfortunately at this moment our situation is pretty hard. To be honest the past few weeks have been filled with uncertainty and confusion. We are actively searching for new ventures and we believe strongly in the potential of MeeGo.

I am certain though real talent always has demand and talent we sure have

Qt 4.7.2 has now been released. This is a maintenance release which contains bug-fixes based on feedback and contributions since the Qt 4.7.1 release back in November. It also marks the official release of Qt Quick.

See the full announcement for more details.

I also wanted to give him a hand, so I wrote to USB_ModeSwitch forums hoping that something could come out of this. I only wish I had time to work on this my self, but as always, I don’t.

Anyway my father had a problem. He could not take colored prints as the colors were horribly misaligned. I investigated the problem just to notice that others had problems with color printing, too, and I was almost ready to give up (after a long long search and many tender thoughts on Canon). Then I just had an idea; let’s try using lower resolution. I lowered the print resolution from 600×600 dpi to 300×300 dpi and voilà the colored print came out just like it should!

I quickly updated the OpenPrinting database entry of the printer and decided to blog about this in hope that others who are giving some rough love with head to their desks can also benefit from this information.

God, I hate proprietary drivers. And Canon.

Last weekend I had to recover an eCryptfs encrypted home directory created with ubuntu jaunty installer from a backup. I thought that it would go smoothly, after all I had written down the recovery passphrase when I installed the system some time a go. Well, it wasn’t all that smooth.

After like 1,5 hours or so I finally had the backup decrypted and I thought that it would be useful to others, too, if I share my findings as I discovered from emergency googling that others are struggling from the same problem and no one has provided any complete solution.

The backup was on external USB HDD, but it should not matter as long as you have your old encrypted .Private somewhere at hand.

First you need to make sure ecryptfs-utils is installed:

$ sudo aptitude install ecryptfs-utils

Create a directory where the backup is opened:

$ cd /mnt
$ sudo mkdir OldHome

Then create a symbolic link to your backup of your old .Private:

$ sudo ln -s /media/3e8ea0ac-xxxx-xxxx-a35a-8ff17406fdb8/home/user/.Private OldPrivate

Now, here’s the part that was missing from all the instructions. At least Ubuntu is using filename encryption to hide the real filenames. You need two keys for accessing: one for accessing the file content and one to decrypt the filenames to be meaningful. To get the key do:

$ sudo ecryptfs-add-passphrase --fnek
Passphrase:

Enter the recovery passphrase: the long one you had to manually write down to a piece of paper when you installed the system. Then you should have a similar output as the following:

Inserted auth tok with sig [xxxxxxxxxxxxxxx] into the user session keyring
Inserted auth tok with sig [yyyyyyyyyyyyyyyy] into the user session keyring

Now, write down the second signature [yyyyyyyyyyyyyyyy].

Now you are ready to decrypt the backup:

$ sudo mount -t ecryptfs OldPrivate OldHome/
Passphrase:
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]:
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [xxxxxxxxxxxxxxx]: yyyyyyyyyyyyyyyy
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=yyyyyyyyyyyyyyyy
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=xxxxxxxxxxxxxxx
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Would you like to proceed with the mount (yes/no)? : yes
Would you like to append sig [df3c98e4c85db0c5] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? : no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs

Now you are able to access the decrypted backup in OldHome directory and you also have correct filenames.

# Huawei E1692
DefaultVendor=  0x12d1
DefaultProduct= 0x1446

MessageContent="55534243000000000000000000000011060000000000000000000000000000"

then run:

$ sudo usb_modeswitch

and you should have a working mobile broadband modem instead of a $180 80MB USB storage stick.

The next Ubuntu release, Karmic Koala, will have usb_modeswitch installed by default which will improve the user experience for many many people. Udev will handle the switch automatically so that the expensive modems just work