Install and enter the SDK under /srv/mer (HADK followers pls point home e.g. MER_ROOT=$HOME/mer instead, and your $HOME should not be mounted with nosuid or nodev options! Then perform mkdir without sudo. It will cause less issue along the way, until proper fix):

The platform SDK aims to offer an alternative image that can be run like a virtual machine using the guide Platform_SDK_on_VirtualBox
Don't bother with this unless you're running Windows or something too non-linuxy to make the chroot SDK work.

To avoid any confusion, there are two types of SDKs: Application SDKs and Platform SDKs. Application SDK's are the ones that deal with Qt applications and libraries, HTML5, etc, while Platform SDK's are for developing the platform, compiling native code and other things revolving around the platform developer/hacker needs.

The platform SDK offers an image that typically can be run in a chroot environment or in a virtual machine, which contains tools like gcc, Scratchbox2, MIC (image creator), spectacle, osc, qemu, etc, to make it easier for a developer to work with Mer.

The SDK must be installed on a standard filesystem and "nosuid" must not be set. (Note: recent ecryptfs will automatically use and enforce nosuid. Automounted usb drives typically have "nosuid" set too.)

Before entering the SDK you may want to make an SDK equivalent of ".profile" to give you a nice prompt to remind you that you are in the SDK. This also reads the bash autocompletion scripts from inside the chroot.

You should find that you are operating under your normal username and that your home directory is available as /home/<username> and any other mountpoints are mounted under /parentroot/*

You have sudo rights automatically. If sudo fails within the sdk, make sure that the filesystem the sdk is on is not mounted with the "nosuid" parameter. "mount" on the host system gives you this information, add "suid" as parameter in fstab, if necessary.

Mer images are build using mic image creator. Mic takes a kickstart file that defines the image to be created as input. To create a Mer image with the platform SDK simply call mic as you would do on any other system. For example

NOTE: in case of facing "not enough disk space left" or similar the problem is most probably that the kernel on your host is too old. To run Mer SDK you should be running kernel 2.6.37 or newer on your host.

The platform SDK's rootfs has some useful packages preinstalled that are listed below. If you're missing something you can use zypper to install the needed extra packages or if not available in the repositories compile them yourself.

The SDK image is (as of 5 June 2012) pinned to specific static repositories and upgrades are carried out using "sdk-upgrade" which allows the repos to be updated to latest, next or set to point to any Mer Core/SDK release pairing.

Recent SDK versions no longer have "sdk-upgrade" and you will need to run "sdk-version"(with different arguments) in order to upgrade different components of the SDK.

You may be prompted to remove the unstable Tools:Testing repo - and you really should as that's now going to be used by the Tools team for sharing experimental packages. Then follow the steps indicated.

Old SDKs which don't have sdk-version should execute these steps before moving on to the appropriate upgrade process:

sudo zypper ref
sudo zypper in sdk-chroot

Now run the following command

sudo sdk-upgrade

If it fails skip this part; if it succeeds then run:

sudo zypper ref
sudo zypper in sdk-chroot

This release needs to install the correct script and then exit/re-enter the SDK:

usage: [--latest | --next] [--core <release>] [--sdk <release>] [-h|--help]
By default reports the current versions from the repos
Alternatively updates the zypper repos to point to the "latest",
"next" or specified Mer / SDK releases. It does not run zypper
ref or zypper up by default (use --go for that).
--core <release> : Use Mer Core <release>
eg: --core 0.20120517.1
<release> can be "next" or "latest" from
http://releases.merproject.org/releases/{latest,next}-release

If command is not present,
used to enter the SDK and begin working. The SDK bash shell is a
login shell. See below for .profile handling
Must be preceded by a 'mount' to setup the SDK.
May be used in multiple terminals and simply enters the
chroot

If command is present,
used to execute an arbitrary command from within the SDK chroot
environment. The environment variable MERSDK is set to 1 to allow
SDK detection.

Options:

-u System user to link into SDK (not needed if using sudo)
-m Devices to bind mount from host: none, all (default)
root, home
-r The root of the SDK to use - normally derived from the
pathname of /srv/mer/sdks/sdk3/mer-sdk-chroot
-h Show this help

Profile

Entering the SDK runs the user's normal .profile and any (SDK)
system profile entries. It will not execute the host's system
profile entries.

The environment variable MERSDK is set to 1 to allow .profile to
detect the SDK.

If the user has a ~/.mersdk.profile then it is sourced after the
normal .profile handling (this allows the common use case of
setting a profile to be handled).

Hooks

If the user specified has a .mersdkrc in their /root, it will be
sourced to allow hook functions to be defined. Hooks are run as
root. No commands should be executed immediately.

These hooks are usually used to define symbolic links from any
/parentroot/data type filesystems into the SDK root to setup
system specific shared caches or filesystem layouts etc

You can use the ~/.mersdkrc file to check and link the standard mic and osc cache directories to those in parentroot.

Note that multiple *concurrent* instances of mic should not share the same cache (it's OK to share from different SDKs and different terminals provided they're not running and accessing the cache at the same time).