allow create pre-built wheezy arm docker image w/ dependencies #118
Conversation
|
(Let me note that according to your commit history, you grabbed those other armv6l binaries from a RaspberryPi. However, Debian armel binaries can't mix with Raspbian binaries if have any floating point, because they use a different ABI, which I'm sure you're aware. I don't know best way to handle this. Maybe should put them in seperate folders. But if you eventually are going to build those binaries from source, then you won't have this issue.) |
|
Looks like something is broken at the moment which is possibly unrelated to your PR. |
|
As I mentioned before to @RazZziel, these lines in bintray.sh need to be swapped to prevent the build failing on a PR due to $BINTRAY_API_KEY not being set. (The file gets fetched from the AppImages repository here.) |
|
Didn't implement yet it because it wasn't actually failing on my PRs :| |
|
It seems that Travis is entirely disabled for PRs on the AppImages repo. Perhaps @probonopd will want to consider enabling it to build (but not upload) for testing purposes? |
|
@shoogle No because it could be a security risk (could access credentials). |
|
I meant in AppImageKit: #112 Builds go like: |
|
@probonopd Travis doesn't make secure variables available to pull requests. If you enabled PR builds $BINTRAY_API_KEY wouldn't be set on those PRs, so if someone submitted a PR with |
|
Still failing with I guess trying to rebuild https://travis-ci.org/probonopd/AppImageKit/builds/115767354 doesn't work because it doesn't count as PR anymore, but I guess ammending with no changes the commit and push-forcing it would work. |
|
Ah, oh, wait: That's long gone, now it's tanen from |
|
I'm thinking it is better to compile those /binary-dependnencies/ from source...can I add those lines neasted of fetching from repo. I'm noticing if I'm on a different release (e.g. jessie v. wheezy), then those .so files are different versions. Also should they be statically compiled? |
Indeed, I'm doing that in feature/build_3rd_party_dependencies, but haven't it PRd yet because I want to do it after #112 is stable and merged.
So you're on jessies and the binaries are on wheezy? I have some wheezies lying around, I can fetch the libraries if you want
Ideally, but wouldn't mind too much as long as it works "fine enough" for now, as we'll quickly upgrade to building the dependencies. If you merge this branch in |
|
I rebased againt master. Those binary-dependencies were from wheezy, but again I think best if build those dependencies from source to avoid any issues. |
|
(I had previously branched from feature/32bit_builds_docker but now I see a few other of your commits are included...I'm new to this git thing, so it might be best if you disregard this or make the relevant changes yourself.) |
|
Ah! My bad, makes complete sense you were rebased against However, the proper course of action would be waiting for #112 and then And don't worry about Git, it's a pain worth to getting used to :) |
|
I'll wait for that. And I think I'll try adding lines to build those binary dependencies from source rather. I'm suspecting unwanted things will happen when dealing with libs from Debian "armel" vs raspian's arm6, which has hardware float abi. And I'm notcing in the commit message for arm7l binaries for arm that they were grabbed from Raspbian, but be aware that Raspbian is always armv6, even on an armv7 RPi2 or RPi3... |
The build of those dependencies should already be done in feature/build_3rd_party_dependencies, although it was not tested in ARM
We can always remove all existing ARM libaries in the repo and fetch them from the Qemu VM that's gonna be used in Docker |
Just tried out that branch, and was able to build AppImageKit, and I notice the new binaries appear, so seems to be good, although I haven't tried packing a program as AppImage with that branch yet. |
if pass --fetch-dependencies-only to then quit build prematurely before actually compile added python as apt-get dependency, which is needed if build on a fresh minimal debian wheezy
|
ok, did a clean chekout of master and only included my small change to build.sh. I'm no longer including those binaries in this PR, since it seems feature/build_3rd_party_dependencies is taking care of making those (and I'm told it is not good practice to put binaries in git code repositories). |
allow create pre-built wheezy arm docker image w/ dependencies
|
"Use desktop-file-validate, closes #118" was a typo |
added wheezy armel & armhf binaries, downloaded from https://packages.debian.org/wheezy/{armhf,armel}/{unionfs-fuse,ruby-vte,libvte9,libglade2-0}/download (note: wheezy is oldest debian that has these as binary)
if pass --fetch-dependencies-only to build.sh then quit build prematurely before actually compile
added python as apt-get dependency, which is needed if build on a fresh minimal debian wheezy