Provide 32bit builds

[RazZziel]

Related to issue #91.

Binaries are being uploaded to https://bintray.com/raziel/generic. Please test on as many systems as possible, 32 and 64bit.

[probonopd]

Exciting work!
To merge this, binaries shouldn't be uploaded to https://bintray.com/raziel/generic. Also In don't think we should be mirroring bintray.sh in this repo; i'd like to maintain it in just one rather than two places (solution might be to wget it from AppImages repo on demand).

[RazZziel]

To merge this, binaries shouldn't be uploaded to https://bintray.com/raziel/generic

Of course, but I don't have your Bintray API key, and without it the build would fail and Travis won't accept the PR. You can just commit your changes to the branch to make it publish to your Bintray instead of mine, and then merge.

Also In don't think we should be mirroring bintray.sh in this repo; i'd like to maintain it in just one rather than two places (solution might be to wget it from AppImages repo on demand).

Makes sense, didn't came up with a solution that wasn't convoluted, like having the .sh in AppImageKit and make it a submodule of AppImages, but a wget would work fine as well.

Right now I think the only compatibility problem between my modifications and the AppImages repo would be that I use a space as separator between the package name and the version instead of a dash, because I think it's both more human-readable and easier to parse, but I can add a pattern to make it compatible with AppImages filenames

[shoogle]

We've been discussing similar issues over at MuseScore. If you are modifying @probonopd's bintray.sh then take a look at our bintray.sh to see how we solved them.

1. Here's how we extract the version from the AppImage filename.

2. We moved these lines right to the top of the file (they used to be here) to avoid the build failing on a pull request (because BINTRAY_API_KEY wouldn't be set in Travis environment on a PR).

3. Rather than uploading to a Bintray user account, we have an account for MuseScore as an organisation. This allows multiple collaborators to upload to the same repo. If @probonopd were to create an AppImage organisation then he could add you to it and give you upload privileges. We include an optional environment variable which developers can override to upload to their own repo for testing purposes if they don't have permission to upload to the official MuseScore one.
   We did it like this:

   # If you DO NOT have permission to upload to MuseScore's repo then set
   # $BINTRAY_REPO_OWNER in Travis environment to your own username.
   [ "$BINTRAY_REPO_OWNER" ] || BINTRAY_REPO_OWNER="musescore"
   

   but another way would be like this:

   # If you DO have permission to upload to MuseScore's repo then you can set
   # $BINTRAY_REPO_OWNER to "musescore" in Travis environment.
   [ "$BINTRAY_REPO_OWNER" ] || BINTRAY_REPO_OWNER=$BINTRAY_USER
   

4. We also treat nightlies differently to stable releases, but that's probably not something you are interested in right now.

[RazZziel]

Made it build without references to my account, defaulting to @probonopd credentials, but allowing me to override all the settings from my Travis environment (which apparently I'm allowed to change for my builds)

BINTRAY_USER="${BINTRAY_USER:-probono}"
BINTRAY_API_KEY="$BINTRAY_API_KEY" # env
BINTRAY_REPO="${BINTRAY_REPO:-AppImages}"
BINTRAY_REPO_OWNER="${BINTRAY_REPO_OWNER:-$BINTRAY_USER}" # owner and user not always the same
WEBSITE_URL="${WEBSITE_URL:-http://appimage.org}"
ISSUE_TRACKER_URL="${ISSUE_TRACKER_URL:-https://github.com/probonopd/AppImages/issues}"
VCS_URL="${VCS_URL:-https://github.com/probonopd/AppImages.git}" # Mandatory for packages in free Bintray repos

Either way, having a Bintray organization for AppImageKit, like (https://bintray.com/portablelinuxgames, separated from https://bintray.com/raziel/), is probably a good idea :)

We also treat nightlies differently to stable releases, but that's probably not something you are interested in right now.

That's actually pretty interesting in order to separate which version of AppImage developers should be using to create packages, and which versions are just for testing

[probonopd]

Do we really need https://raw.githubusercontent.com/RazZziel/AppImages/feature/bintray_for_AppImageKit/bintray.sh?

[RazZziel]

Only while AppImageCommunity/pkg2appimage#36 is not merged

[probonopd]

Which it is now ;-)

[RazZziel]

Awesome, URL changed

[probonopd]

Looks like stuff is broken at the moment. Please make sure that we don't have spaces in the filenames. Naming convention for the AppImages in my repo is MyApp-1.0-x86_64.AppImage (might be different for other repos).

[RazZziel]

Hmmm what's broken exactly? Github tells me all checks have passed here (https://travis-ci.org/probonopd/AppImageKit/builds/115799130 and https://travis-ci.org/probonopd/AppImageKit/builds/115799133)

[probonopd]

I think travis is not getting the correct result code, but looking at the log:

Creating package AppRun 5-37-gbb25042-i686...
{"message":"Package for path 'raziel/generic' was invalid"}
Uploading and publishing out/AppRun 5-37-gbb25042-i686...
{"message":"Failed to resolve package name"}
Adding Travis CI log to release notes...
{"message":"Package 'AppRun 5-37-gbb25042-i686' was not found"}

[RazZziel]

Hmm, indeed bintray.sh is not being triggered here right now because Skipping a deployment with the releases provider because the current build is a pull request., and https://travis-ci.org/probonopd/AppImageKit/jobs/115799134 doesn't fail properly

AppImage upload works

Uploading and publishing out/AppImageAssistant 5-37-gbb25042-i686.AppImage...
{"message":"success"}

Uploading and publishing out/AppImageExtract 5-37-gbb25042-i686.AppImage...
{"message":"success"}

Uploading and publishing out/AppImageMonitor 5-37-gbb25042-i686.AppImage...
{"message":"success"}

The problem only happens with AppRun, which is not an AppImage, so there must be a regression extracting metadata from a non-AppImage name

[probonopd]

Where are names like AppImageExtract 5-37-gbb25042-i686.AppImage coming from? Should be AppimageExtract or AppImageExtract-gbb25042-i686.AppImage...

[RazZziel]

#91 (comment)

Btw, I stopped using git rev-list --count HEAD for versioning, because it will give either wrong or empty results in docker Travis, so now I'm using only git describe --tags, which should provide a good enough output both for releases (0 commits after a tag) and for nightlies (>0 commits after a tag)
#91 (comment)
Travis by default fetches the last 50 commits (--depth=50), not the whole history, which seems to alter the output of git rev-list --count HEAD

#112 (comment):

Right now I think the only compatibility problem between my modifications and the AppImages repo would be that I use a space as separator between the package name and the version instead of a dash, because I think it's both more human-readable and easier to parse, but I can add a pattern to make it compatible with AppImages filenames

Summing up:

• AppimageExtract was not valid because it doesn't contain the package version, and it's not in the metadata either
• AppImageExtract-gbb25042-i686.AppImage was discarded because it was difficult to parse

It can be changed at the end of build.sh

[probonopd]

I don't agree with the "solution" of using a blank in #112 (comment) because it tends to be breaky. Instead, we should not parse the filename but use proper X-AppImage-... metadata in the .desktop file instead.

[RazZziel]

Blanks shouldn't be breaky if scripts are coded with a bit of care, and they could be replaced by underscore. Anyway using proper metadata should be way better indeed.

Would using underscores instead of blanks be fine for this PR while we implement metadata?

[probonopd]

Yes

[RazZziel]

Commited on 19f2a71, but depends on PR AppImageCommunity/pkg2appimage#39

[RazZziel]

Build passing again! Is this ready to merge?