cc meego-sdk and no snips to retain context.
On 07/08/10 20:52, Carsten Munk wrote:
One of the very first steps of porting MeeGo to your device, ARM or
X86, is to generate a reference device image - often you take the
reference device that is most close to your target device.
This is done through kickstart files, provided on repo.meego.com and
using the image-creator (henceforth mic2) tool. However mic2 is not
the best in terms of portability to other Linux distributions, mostly
because of the requirements/bugs of dependant packages on other
distros (pykickstart, yum, qemu, etc).
In #meego-arm IRC channel, we have to resort to telling people to
install a Fedora VM and install mic2 in there. That's a bit of a
failure as we should be able to provide a full solution within MeeGo
itself for building MeeGo images.
I think this should be very do-able through OBS. Now we are very close to having
a community/public setup I think that would be a good place to start.
We are currently providing the MeeGo SDKs (currently Handset or
Netbook) as image files. These are used through chroot methods or
booting in QEMU.
My proposal is that in these SDK's:
* that we include mic2 as well as it's dependencies, including the
static QEMU binaries for ARM image building. In fact, my personal
image building exists in a Fedora chroot underneath a Ubuntu system so
it is technically possible.
I'm guessing this is as easy as adding a command-line
--extra-pkgs=mic2
and many months ago I started work on getting the OBS kiwi code to run mic2 so
you could just install osc and literally "osc build" to get an image from a
project that contained a .ks file
I rebased it here:
http://gitorious.org/~lbt/opensuse/lbt-build/commits/kiwi-mic2-experimental
(It doesn't work)
Note that building images is resource intensive. Whilst the OBS can do this we'd
probably follow the opensuse OBS lead and make it a local-only operation by default.
Challenges are the usual when it comes to ARM and QEMU: vdso,
mmap_min_address, selinux and so on (easily diagnosable). As well, in
general this approach means you need a SSSE3 processor to generate a
ARM chroot. For those who doesn't have that, they can use Fedora VM's
in case.
When someone wants to generate a MeeGo image, we can then point them
to the SDK image for easy image generation instead of going out of the
way to install another distribution.
Ideally, for someone wanting to adapt MeeGo on a device we should have
a short path for customizing MeeGo:
Package up your software with spectacle (and/or .spec). Upload to your
company/community OBS. Take that binary package, in the RPM
repository, generated by your OBS. Add repository line to a kickstart
file, package name to %packages. Build new image in SDK. Deploy.
And that's a compelling device porter environment.
How does this proposal sound?
So I like it... I hope we can get that OBS opened RSN.
David
Best regards,
Carsten Munk
Nokia N900 hardware adaptation team member
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
