Hi,
Am 07.03.2014 um 04:30 schrieb Michael Mrozek:
Am Thu, 6 Mar 2014 22:12:58 -0000 hat "John Willis" John.Willis@Distant-earth.com geschrieben:
Hi,
As mentioned, I'd like to use Debian (testing), as it has pretty good package management and is well-known. If someone prefers a different one, let me know :)
To be honest I have Yocto/OpenEmbedded going as well but I can see the sense in sticking with Debian IF we can minimise the trade offs.
Well, Yocto / OpenEmbedded still seems to miss tons of packages that a normal OS has (LibreOffice, etc.), so Debian would be better.
I'd like to stick to standard Debian as much as possible, so we've got as little work as possible as well.
It's not a small job regardless of how we cut it. We need to get an OS tuned for the hardware regardless.
True, but we can try to keep that as little as possible. I see no reason, for example, to recompile most programs available on Debian.
We'd need to take care of the base system. Most of the driver stuff probably happens in the kernel, most of the rest could mostly be standard Debian stuff without any patches (hopefully).
I see the differences to standard Debian as: * most optimizations are kernel level * only a minority of standard packages will benefit from NEON * there will be non-standard packages
Right now we're running the rootfs of the GTA04 and I switch to debian unstable repos and installed all kinds of programs with it - without any issues. They work fine.
Standard Debian is compiled without NEON optimization though, so I guess we should at least recompile most of the base packages we need.
It is not just NEON that is lacking but that can sorted with some work once we have something setup to build the packages.
It's mostly build parameters we need to change, I guess?
As recompiling needs some CPU power, I was thinking of renting another small server which will only be used as build server for the OS.
Remember that Debian is an 'on device' OS, Angstrom and the likes got picked for the OpenPandora due to the ease (relative term) of cross compiling.
Okay. So it would make sense setting up a complete ARM QEMU rootfs on the server?
I tried to find ARM Root Servers you can rent, but I haven't found one yet.
The key question is if you need a new server at all or if it can be a side-job of some desktop Debian or the existing server.
That IMHO largely depends on the frequency of updates and how many non-standard and optimized standard packages exist. If there are 10 packages per week you can even trigger it manually...
And differently to OpenEmbedded you don't have to recompile everything over and over. Just compile the package that has been changed.
Things have changed a lot in this area but we are still really going to want to be using a Qemu setup tweaked for the OMAP or an actual device :o to do most of the builds if we want to optimise beyond the generic. I have started to play with this already, based on what I played with when I got involved with the Raspian Debian port (a downstream rebuild but the same principle).
Okay... are there many OMAP-specific things when recompiling? I know there are some parameters you set in your compiler, but most of them are generic ARM stuff (like NEON). Is the OMAP special here?
Our build server should...
[wall of text removed]
All very sane and the more we can automate from this stage the better things will be.
The hardest step will probably to get this all working. Once it works, I don't think much should break there. Debian provides its own sources (unlike Angstrom, which links to non-existant sourcecodes after a while...)
This is a good hint. Keeping the sources and patches in git is important.
But as soon as they are compiled/packaged there should also be a snapshot of the sources as a src package. So that others don't have to find out on which commit some package is based on.
DJWillis, do you think you can find some time to set this up?
I want to, I have started with the ARM emu build setup on my rigs and that has been churning packages for a while for testing (based on the OpenPandora setup). I have the usual work commitments so I'll have to see how this is going to work out.
Okay. Let me know if I should rent a root server so you can set it up directly there.
And let me know what speed / memory / etc. we need :)
IMHO this is very difficult to estimate in advance.
I would set up the build system on a Debian (e.g. virtual machine) first and make it working to include everything we need.
And after having it working make a performance analysis which can answer the need for speed / memory. And finally migrate the setup to some new root server.
If we do this all out in the open (or at least as open as we can be) then it is easy for them to see where things are and pitch in. I can't see it being a bad place to be but custom Debian is a new approach. Most of what we have learnt from the OpenPandora OS crapshoot is relevant and we know that frankly if we don't make it almost self-maintaining from the start it will rot and no amount of wishful thinking will fix it without hard labour.
Yep, exactly!
Even if it's more complex setting up such a system in the beginning - it certainly is worth it in the end!
BR, Nikolaus