On 04/29/2014 06:59 PM, Dr. H. Nikolaus Schaller wrote:
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? :)
Last time I talked to him he didn't know the list existed, are you sure you added him ?
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?
Im using my igep board to compile the packages that need to be of "armhf" arch, the "all" ones (with things like scripts or just dependencies) can be built on anything.
Multistrap is basically a more advanced version of debootstrap, so to run that no arm hardware is needed to make arm based images.
You can run the setup stage of the arm packages in qemu to save some time when running it on the actual hardware for the first time. You'll have to manually reconfigure some packages (like ssh keys) in the first boot script though.
I did try this once, but it seemed to take longer than to run in on the pandora itself. (So not really worth the effort when it's only running on my machine, but could be an option for making the image installation faster for end users)
I'll turn the multistrap scripts into a .deb too, so a fresh image can be generated from inside the debian install on the device as well. Or any device running debian really. (its not as easy to get going on non debian systems as debootstrap)
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:
It's called multistrap because it can deboostrap from multiple sources, no problems there.
- 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).
There's probably some way to (partially) automate this. I'll look into it.
- 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.
Don't forget the worst bit, the closed source parts. I don't expect any major problems from them now, but as with the pandora, some fun problem may come up later on when certain parts depend on obsolete packages.
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:
- fetch the sources (local / remote) - it just needs a list of packages and which version you want and where they can be found
- configure&patch the package
- (cross-)compile
- make the debian package
- 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
If you do debian packaging the "right" way, most of those steps can happen automatically. Don't forget that the packages should also be signed.
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 :)
IO seems to be the main bottleneck though, so anything with usb3/sata disk support should be fine.
There shouldn't be too many packages that need patching/compiling on real arm hardware anyway.
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.
Properly building debian packages is slightly more involved than just a simple (cross)compiler setup. When you're using something like pbuilder/cowbuilder it will create a near empty chroot with only the build-deps of the package, and will try to build it from there. It may be slightly overkill for our use though, but does give you some advantages (like proper dependency checking, compiling with all the up to date versions of the compiler and libs on the target system, and also beeing able to build stable/testing/unstable versions of packages).
There is also qemubuilder, which does all that in a qemu setup, but I haven't tried that yet. I don't expect it to be faster than running it on real arm hardware.
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.
it's a 720mhz 512mb igep2 board (basically the same as the 512mb pandora soc)
It did go a lot faster when using distcc though, I did some experiments with that as well. Setting it up is slightly involved, using a crosscompiler on the server end, and the compiler versions on the client and server didn't quite match, but it did work. I think it was something like 30 minutes for the kernel then. It's more a hack than a solid solution though.
It was doing the compiling from a usb2 connected HD (which also held the swap)