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:
1. Debian ARM Repo: Everything we just take as is. No recompilation, etc. needed. The .debs will just be grabbed from the Debian repos directly.
2. 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).
3. 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?
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.
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 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 :)