On 04/23/2014 02:50 AM, Michael Mrozek wrote:
Hi,
production is coming along nicely. We got the first prototype of the case, the base PCB will be finished within this month as well, and in May the CPU PCB will hopefully be done as well.
So it's time to get that OS server going.
I wanted to get things rolling here. I know both aTc and DJWillis has worked on that - and I wanted to check what the status is.
How far are we into getting a working Debian Buildserver for our ARM OS (incl. repos)?
I'd like to start working on optimized themes and standard installed software as well as the first-boot-setup in about June, and we also need to package the SGX drivers, optimize stuff like SDL, etc. and create Debian packages from it.
What's your current status and plans / ETA to get this to work?
I've been mostly looking at how to automatically generate firmware images, and how to create .debs that are maintained on a git repo.
Unfortunately, the things we want to use them for aren't very documented.
Building images is relatively easy though, I've already got a basic setup for pandora that uses multistrap to build a complete image by pulling in packages from the official debian repos, and a few from my own repo. Multistrap, with the help of a few scripts, then turns everything into a .tgz image that works basically the same as the angstrom images.
You extract it to an sd card, and at first boot it configures all the packages that need to be run on the native hardware (multistrap already tries to do as much as possible on the build server), it then runs a first-run-wizard to set up some basics (currently just a non-interactive script that sets some sane defaults), and you end up with a fully working debian install.
As for packaging, I'm currently trying to find a simple workflow to create/maintain/build debian packages from a git repo.
git-buildpackage seems the best option here. As with all debian packaging, all its docs focus mainly on how to package up sources from other projects, where you just take a source.tgz from someone else and turn it into a .deb, instead of maintaining everything yourself on a single git repo. (That is, a repo for each package, debian packaging isn't nearly as nice as oe, where you can easily have a big collection of recipes on a single git)
I do have a few test packages set up, but still haven't managed to find a really smooth workflow for everything. Everything does work (automatically generating a changelog based on the git commits, incrementing the version number, building the package, and adding a git tag if it succeeded), but I still have it complaining about a few things. I haven't tested its feature of automatically uploading the generated .debs yet, but that shouldn't be too hard. Every stage seems very configurable. It could probably be set up to compile the packages on a remote machine too.
The packages that it currently takes care of are a meta package that just depends on everything needed for an xfce image, and a config package with the default touchscreen settings. These have the advantage that they don't need any crosscompiling/building on arm hardware, so its a bit faster to test.
I do have an arm board set up for compiling, and as expected for debian, everything there works the same as on my desktop machine, just slower. (properly building packages is quite slow anyway, when using pbuilder it sets up an empty chroot with only the dependencies specified in the package, and tries to compile things from there)
Some things that i didn't spend too much time on:
I created a .deb of the pandora kernel using make-kpkg in crosscompile mode. (also without crosscompiling on my arm board, but that took 3.5 hours). It doesn't generate an uImage, and it's not really the proper way of doing a kernel package anyway.
I also tried a bit of messing about with debians multiarch stuff (for crosscompiling .debs), but that doesn't seem to be fully functional yet. Ubuntu seem to be much further along in the arm department for that.
And I dug up some info on overriding config files from other packages, but haven't tried to do anything with it yet. ( http://debathena.mit.edu/config-package-dev/ )