Am 29.04.2014 um 13:32 schrieb Michael Mrozek:
Am Wed, 23 Apr 2014 14:36:21 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
thanks a lot for your reply :) DJWillis, are you there as well? :)
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.
That sounds good. Are you using an ARM PC to build an compile the packages, or are you already doing this using some way of cross-compiling?
(AFAIR, that's what DJWillis was working on, but maybe he can comment on that)
Or are you currently just assembling pre-compiled packages with that build-server setup?
Multistrap, with the help of a few scripts, then turns everything into a .tgz image that works basically the same as the angstrom images.
That's nice.
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.
Sounds good :) So very similar as we're doing it right now.
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)
Well, that's basically what we want as well.
For image building, we don't want to keep all packages on our own server - it would need a lot of space.
I think it's best to have three different sources for packages:
- Debian ARM Repo: Everything we just take as is. No recompilation,
etc. needed. The .debs will just be grabbed from the Debian repos directly.
Yes that works fine for the GTA04. Every 2-3 months apt-get update gives a bunch of security updates for free :)
- Recompiled / patched Debian packages: Some of Debians packages may
need to be recompiled or receive simple patches for the Pyra. The build server should grab the source from the official Debian repo, grab the patches from our server and compile them anew. The finished .deb should be on our own repo (which has higher priority than the debian one).
- Original packages: Meta-Packages (i.e. for Pyras Base system) as
well as original tools we code for the Pyra. Sourcecode should be available on our own server, the finished .deb as well.
Basically similar to what we're doing with Angstrom right now.
Is that the best way to go?
IMHO yes.
basically you need 5 decisions/steps:
1. fetch the sources (local / remote) - it just needs a list of packages and which version you want and where they can be found 2. configure&patch the package 3. (cross-)compile 4. make the debian package 5. copy to a public pool and update the repository index (the files you load with apt-get update)
Step 4 and 5 are quite simple (I am doing it for my packages with ~20 lines in a makefile plus a shell script to update the index).
Step 3 just needs a working toolchain (I am e.g. running one on Mac OS X that even can cross compile Linux kernels)
Step 2 is the most complex - because packages config is a fragile process and might have to run on the target machine And, there you have to add your packet specifc modification. I.e. it needs a database of recipies to modify-build packages
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)
Ah, so no crosscompiling yet.
Well, if crosscompiling would be too hard, I'd just grab one of the upcoming ARM server mainboards and will do compiling at my place.
Some Allwinner A80 please :)
Usually cross-compiling isn't hard - but there are exceptions of packages where the ./configure script does not properly detect cross-compilation or the cross-toolchain is missing something from a fully blown system. Or needs to be configured differently. Then it would be better to compile it on a target compatible hardware.
IMHO this can only be found out experimentally.
Hopefully, we won't need to recompile many packages.
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
Oops - 3.5 hours is a lot.
Maybe the machine did not have enough memory and started swapping.
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/ )
Thanks, good job :)
BR, Nikolaus