Provide binaries for ARM

[RazZziel]

Probably should target armv6l (Raspberry Pi B+).

As #91 but for ARM. These containers may come handy:

  - DOCKER_IMAGE=ryankurte/docker-arm-embedded
  - DOCKER_IMAGE=amardomingo/docker-build-arm
  - DOCKER_IMAGE=philipz/raspberry-pi-crosscompile

Stuff to check out:

• https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/

[probonopd]

Very cool, wow!

[ericfont]

I think I built AppImageKit using the qemu-arm inside docker trick (https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/). Here is my Dockerfile (ericfont/armv7hf-debian-qemu-AppImageKit@1c2b696). Maybe someone can take a look at this log of output from running and tell me if something looks suspicious:
sucesfful-build-armv7-in-docker.txt

There were 3 libs and unionsfs-fuse missing in the AppImageKit/binary-dependencies dir...I manually added using:

apt-get install fuse libglade2-0 libvte9 ruby-vte unionfs-fuse
cp /usr/lib/libglade-2.0.so.0 AppImageKit-5/binary-dependencies/armv7l/
cp /usr/lib/libvte.so.9 AppImageKit-5/binary-dependencies/armv7l/
cp /usr/lib/ruby/vendor_ruby/1.8/arm-linux-eabihf/vte.so AppImageKit-5/binary-dependencies/armv7l/
cp /usr/bin/unionfs-fuse AppImageKit-5/binary-dependencies/armv7l/

My question for @probonopd is if there is anything specific about the libs that are incuded in binary-dependencies (for instance, were they built with a special compiler)? Is what I did is OK? Why does your build script not grab these dependencies in addition to the ones it already grabs?

Oh, and I think python2 should be added as a dependency.

[RazZziel]

Looks awesome @ericfont! Do you think it could be integrated with our Travis, just by referencing the docker image in .travis like we do for 32bit builds? Maybe by creating a simplified Dockerfile, that sets up the dependencies but doesn't actually run the build?

Regarding the binary dependencies, there's a WIP in the experimental branch to build these dependencies, but for now in master they should be included in the repo. If we create a PR on top of 32bit_builds_docker, we can integrate the binaries in the PR for now, and later on, in another PR, remove all the binary dependencies, from all architectures, and either build them or fetch them on the fly from the build machine.

[ericfont]

creating a simplified Dockerfile, that sets up the dependencies but doesn't actually run the build

yes, I think that is wise and can easily be done. (as it is now, the base docker image includes a bunch of musescore dependencies...I can create a fresh docker file that just does apt-get for the minimum that is needed).

[shoogle]

Regarding this simplified Dockerfile, ideally it should use the same dependency list as the recipe so that you don't have to maintain the list in two places. Perhaps modify build.sh so that you can pass in an optional argument to fetch dependencies but not actually build.

[RazZziel]

Hmmm ideally that argument shouldn't be needed, the dependencies should be the same on all architectures; it may happen that some dependency is already installed on some architecture, but the script should make sure all needed dependencies are installed.

In this case, we're talking only about apt-get install python, right?

(Please note: Right now I'm only talking about dependencies fetched from the repos, not about the stuff in the binary-dependencies directory, which is incomplete for both armv6l and armv7l)

[shoogle]

But the dependencies might change over time, and then it would be a pain to update them in both build.sh and the Dockerfile. That's why @probonopd's Dockerfiles simply run the recipe and then clean up the build afterwards. I'm suggesting you save doing the build by having a "--fetch-dependencies-only" argument to the recipe (or in this case build.sh).

Edit: I was talking about repo dependencies too, but all of them, not just python.

[RazZziel]

Hmmm, I agree dependencies shouldn't be duplicated in the Dockerfile, and reside only in build.sh (so they can run inside our outside Docker), but I think I'm not understanding completely: what's the use case for ./build.sh --fetch-dependencies-only, when the dependencies AFAIK are only needed in order to run ./build.sh? From the perspective that AppImageKit is built right now in #112 with docker run -i -v "${PWD}:/AppImageKit" "$DOCKER_IMAGE" /bin/bash -c "/AppImageKit/build.sh"

[shoogle]

The Dockerfile is there to create a Docker Image, and it is the image that gets used during the build on Travis. The Dockerfile itself is not used at all during the build on Travis. As you yourself said above:

Maybe by creating a simplified Dockerfile, that sets up the dependencies but doesn't actually run the build?

The best way to set up those dependencies is to run the apt-get lines from build.sh. Then, when it's time to do the actual build on Travis, it will run quicker because the Docker image that it fetches will already contain the dependencies.

[RazZziel]

Oh! Ok. Though the docker image was being created on the fly based on the Dockerfile. Now everything makes sense. Thanks!

[shoogle]

I thought the same first time I saw it! ;)

[probonopd]

My question for @probonopd is if there is anything specific about the libs that are incuded in binary-dependencies (for instance, were they built with a special compiler)? Is what I did is OK? Why does your build script not grab these dependencies in addition to the ones it already grabs?

No, nothing special, but use the oldest ones you can find that work for you (so that they run even on older distros).

[ericfont]

ok, well Debian Wheezy contains the oldest ARM ones I can find. (There is currently no such thing as CentOS 6 arm binaries I can find on internet). I've forked your repo and I'm adding a "--fetch-dependencies-only" argument to AppImageKit ./build.sh, which will simply exit build.sh after grabbing dependencies (oh, and I'm adding python to apt-get...maybe I should add a python to yum and pacman as well?): feature/32bit_builds_docker...ericfont:origin/feature/arm_builds_docker

Now I'm going to make a minmal docker image that contains these fetched dependencies, based off debian wheezy using resin's qemu-arm.