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?
Thanks a lot :)
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/ )
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 :)
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
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)