This reverts commit 26b9a3e4.

The ibus applet is now started only for languages that need it.

This function is not used anywhere, and obviously was not even tested, given the
typo (${dialob_text}) it contains.

Conflicts:
	config/chroot_apt/preferences

Conflicts:
	auto/config
	config/chroot_apt/preferences

Note that:

* linux-compiler-gcc-4.8-x86 is needed to install linux-headers-3.12-*
* linux-kbuild-3.12 is only available from sid right now

This is a no-op without the userspace tools and with no profile shipped,
but it will make it easier to fix this part of the situation.

Else, on Wheezy, this test consistently fails:

  74.977% of the memory is filled with the pattern,
  but more than 76.280% was expected

With this change, this tests passes every time for me,
and pattern coverage after erasing the memory is 0%,
so it seems that our memory erasing process works fine.

Besides:

  * when testing by hand, we have never checked how much memory the pattern
    covers;
  * we now have an anti-test that verifies pattern coverage when we don't erase
    memory;

... so, the check this commit is touching is merely an added bonus.

Our kexec initscript depends on /etc/default/locale, that is only created at
login time.

This is meant to workaround Wheezy's "free -b" bug (Debian#733898).

Conflicts:
	features/step_definitions/encryption.rb

First, the pinentry window is not automatically focused in the "Symmetric
encryption and decryption using gpgApplet" feature, for some reason, while it is
focused in the others. So, we click on it to give it focus.

Second, on a fast (bare metal) test setup, when one immediately types the
passphrase, the first character is lost. So, we had a little sleep time. I have
not found any *visible* change during this time, so I can think of no other way
we detect when pinentry is ready to receive our input.

Install virtualbox-guest-utils: we don't install it through a chroot_local-hook anymore, and it has do be done somehow.

We already grep for the pattern after rebooting, no need to do it
before.

At this time, the display resolution is different from the one on startup,
so Sikuli can't find TailsBootSplash.png.

This should be more robust.

... using virsh as ruby-libvirt 0.4 does not support the reset method :(

We display something more precise (and generally < 100%) soon after, so it makes
no sense displaying "Memory fill progress: 100%".

This command won't ever return anything to us, so it's useless (and broken) to
wait for the remote shell to reply anything to us.

As previously noted, pgrep sometimes detects itself, which breaks the detection
that all fillram instances have vanished.