John Willis
Fri, 09 Jan 2009 03:03:07 -0800
Hi, As a number of Angstrom/OE devs know the OpenPandora project is using Open Embedded and the base Angstrom distribution as a basis for the OpenPandora stock distribution.
Whilst this has been going very well I am very conscious that most discussion is on IRC or via mails (or the odd forum/blog posts, nothing that I would ascribe any great credence to). This is not really an ideal way to communicate so I would like to layout a quick very high level mail explaining what we are doing and how this may sit long term with the core OE/Angstrom efforts. I suppose this is a formal introduction. One thing I will make very clear is that I personally dont see the need for things like forks and would be very reticent to ever go down that road. I wish to see the Pandora incorporated into OE/Angstrom as a supported platform from day one and I would like users to be able to make a mirror of the shipping file system using mainline GIT (or specific SRCREV's for releases) with the minimal amount of overlaying of patches/recipes etc. (some of this may be unavoidable as we carry a few non GPL'ed firmware binaries and possibly codec's etc., not really 100% sure how to work that all out). Currently the Pandora support (from an Open Embedded GIT perspective) consists of a machine configuration (omap3-pandora.conf) and a number of minor patches (things like pointercal, psplash splashscreen etc.). A version of omap3-pandora.conf has been in mainline OE for a while now. This is then pulled together with a separate metadata tree with a custom kernel recipe, whilst we also use the Linux-OMAP recipes and tree (and push patches) we maintain our own kernel GIT as we have to carry some 'non mainline' patches to get the kernel stable enough for a product to ship and patching the kernel heavily via OE is something we would rather not do. Doing that is going to upset the people who want to run Debian, Gentoo or any other random distro on there device and one of the design considerations was to be very flexible regards things like that. Add to that a number of custom tasks and image definitions for building our images, branding them and a few misc recipes for packaging things like device firmware and a device specific library and you have all the components used to make an OpenPandora 'powered by Angstrom' distribution. Moving forward I would like to investigate what customisation we have done maybe suitable for mainline inclusion (happy to start presenting patches) and understand if there is any precedent for working this way (base as part of OE with 'branding' and less open or generic stuff in a separate tree) and generally build up some relationships with the wider OE/Angstrom community. There is a very good reason we have gone with Open Embedded/Angstrom, for what we want to do it is head and shoulders above other options to its great credit. Kind Regards, John Willis -- > What is a grue? The grue is a sinister, lurking presence in the dark places of the earth. Its favourite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale. _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel