All,

 

As we now got DJWillis and skeezix in the mailing list as well, I think we should start working on the OS for the Pyra as well, so that it will be developed at the same time as the hardware.

 

Excellent idea.

 

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.

 

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.

 

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.

 

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.

 

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).

 

I don't know exactly how things with Debian work, so please correct me if I'm wrong.

 

Not wrong but incomplete ;). Not a problem however.

 

Our build server should...

 

* Grab selected package sources daily from Debian testing and recompile

  them with our parameters when they have been updated

* Offer the compiled packages in a Debian Pyra-Repository (which has

  higher priority than the normal repository)

* Offer additional packages specific for the Pyra (like libpnd,

  standard configuration, meta-package with all packages that are

  installed as default in our OS, our kernel, etc.)

* Have all our own packages and stuff available in a GIT

* Create files that can be used to fully reflash the OS using an SD

  Card (maybe once a week)

 

All very sane and the more we can automate from this stage the better things will be.

 

First step:

Set up the basic build server and compile the packages.

When that basic setup is working, we can think about what packages to include and build the meta-packages.

 

Is that the correct way to proceed?

 

Yes.

 

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.

 

It seems there are some in the community who want to help as well (many discussions going on in the forums), but as we all know, that's not really reliable...

 

Maybe they can help with custom libraries and packages when the build server is working.

 

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.

 

What do you all think?

 

I think it’s great, let’s start thinking about how we do it.

 

Cheers,

 

John