Please provide AppImage for download on GitHub Releases

[probonopd]

Please provide the AppImage for download on GitHub Releases, thanks. Possibly you might be interested in https://github.com/probonopd/uploadtool which simplifies this.

Reference: AppImage/AppImageHub#15

[Beep6581]

@aferrero2707 as you are the author of appimage/appimage.sh, will that script still work, and are there any changes required for having the AppImages appear on the releases page?

[aferrero2707]

I will have a look at the script again, to see if it still works. However, I think it would be a good idea to adapt it to use linuxdeployqt.

I'll keep you informed here.

[Beep6581]

@aferrero2707 please note that I will merge branch treeclean into master soon.

[aferrero2707]

I have just created a new AppImage for testing, using linuxdeployqt. The package is available here.

@Beep6581 @jcelaya @probonopd - would you be able to test it and provide me some feedback? It seems to run fine on Ubuntu 17.04.

[Beep6581]

@aferrero2707

$ ./hdrmerge-2559148-x86_64.AppImage
Segmentation fault (core dumped)

$ gdb hdrmerge-2559148-x86_64.AppImage
GNU gdb (Gentoo 8.0.1 vanilla) 8.0.1
(...)
(gdb) r
Starting program: /home/morgan/downloads/hdrmerge-2559148-x86_64.AppImage
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
process 12170 is executing new program: /tmp/.mount_hdrmer5CdbcG/usr/bin/hdrmerge
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

Program received signal SIGSEGV, Segmentation fault.
0x000000000000ce90 in ?? ()

[aferrero2707]

@probonopd - any suggestion on how to debug the segfault reported by @Beep6581? I do not have experience with linuxdeployqt, and how to eventually turn on verbose execution...

[probonopd]

Looks like that this means that libthread_db.so.1 does not match libpthread.so.0. Please do not bundle either one. Nor any other library from https://github.com/AppImage/AppImages/blob/master/excludelist.

[aferrero2707]

@probonopd - there is no libpthread.so.* library in the bundle:

$ find /tmp/.mount_hdrmer1m7l7F/ -name "*.so*"

/tmp/.mount_hdrmer1m7l7F/usr/lib/libQtCore.so.4
/tmp/.mount_hdrmer1m7l7F/usr/lib/libQtGui.so.4
/tmp/.mount_hdrmer1m7l7F/usr/lib/libXau.so.6
/tmp/.mount_hdrmer1m7l7F/usr/lib/libXdmcp.so.6
/tmp/.mount_hdrmer1m7l7F/usr/lib/libXext.so.6
/tmp/.mount_hdrmer1m7l7F/usr/lib/libXi.so.6
/tmp/.mount_hdrmer1m7l7F/usr/lib/libXrender.so.1
/tmp/.mount_hdrmer1m7l7F/usr/lib/libXt.so.6
/tmp/.mount_hdrmer1m7l7F/usr/lib/libalglib.so.3.8
/tmp/.mount_hdrmer1m7l7F/usr/lib/libaudio.so.2
/tmp/.mount_hdrmer1m7l7F/usr/lib/libexiv2.so.12
/tmp/.mount_hdrmer1m7l7F/usr/lib/libffi.so.6
/tmp/.mount_hdrmer1m7l7F/usr/lib/libfreetype.so.6
/tmp/.mount_hdrmer1m7l7F/usr/lib/libgomp.so.1
/tmp/.mount_hdrmer1m7l7F/usr/lib/libjasper.so.1
/tmp/.mount_hdrmer1m7l7F/usr/lib/libjpeg.so.8
/tmp/.mount_hdrmer1m7l7F/usr/lib/liblcms2.so.2
/tmp/.mount_hdrmer1m7l7F/usr/lib/libpcre.so.3
/tmp/.mount_hdrmer1m7l7F/usr/lib/libpng12.so.0
/tmp/.mount_hdrmer1m7l7F/usr/lib/libraw_r.so.18

The appimage package is generated with linuxdeployqt, so it should automatically take into account the recommended excludelist, right?

@Beep6581 - what is the result of a bt command after the SIGSEGV?

[Beep6581]

@aferrero2707

(gdb) bt
#0  0x000000000000ce90 in ?? ()
#1  0x00007ffff7de807a in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x00007ffff7de819b in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7decafe in ?? () from /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff4da0b30 in _dl_catch_error () from /lib64/libc.so.6
#5  0x00007ffff7dec245 in ?? () from /lib64/ld-linux-x86-64.so.2
#6  0x00007ffff26dd03d in ?? () from /lib64/libdl.so.2
#7  0x00007ffff4da0b30 in _dl_catch_error () from /lib64/libc.so.6
#8  0x00007ffff26dd8e0 in ?? () from /lib64/libdl.so.2
#9  0x00007ffff26dd0f1 in dlopen () from /lib64/libdl.so.2
#10 0x00007ffff6a156b8 in ?? () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtCore.so.4
#11 0x00007ffff6a1059a in ?? () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtCore.so.4
#12 0x00007ffff6a106d8 in QLibrary::resolve(char const*) () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtCore.so.4
#13 0x00007ffff6a10778 in QLibrary::resolve(QString const&, int, char const*) () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtCore.so.4
#14 0x00007ffff72f834a in ?? () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#15 0x00007ffff72fbfd5 in ?? () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#16 0x00007ffff72fc8dc in ?? () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#17 0x00007ffff72e0df1 in QGtkStyle::QGtkStyle() () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#18 0x00007ffff726b601 in QStyleFactory::create(QString const&) () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#19 0x00007ffff6f7e561 in QApplication::style() () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#20 0x00007ffff6fe857f in ?? () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#21 0x00007ffff6fed2b1 in ?? () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#22 0x00007ffff6f7ea78 in QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#23 0x00007ffff6f7ee19 in QApplication::QApplication(int&, char**, bool, int) () from /tmp/.mount_hdrmer4MoXWA/usr/bin/../lib/libQtGui.so.4
#24 0x000000000041ec41 in hdrmerge::Launcher::run() ()
#25 0x0000000000418d68 in main ()

[aferrero2707]

I have prepared a new version of the AppImage, which seems to at least fix the issues reported by @Beep6581. It also uses an updated build environment based on QT 5.8. The new package can be downloaded from here: https://github.com/aferrero2707/hdrmerge-appimage/releases/tag/continuous

[Beep6581]

@aferrero2707 how do we proceed to make this AppImage official, automated and public?

[aferrero2707]

@Beep6581 Automated: I plan to follow the same approach as for RawTherapee, i.e. a Travis cron job that runs daily and than compares the hash of the current git HEAD against the one of the last packaged version. If they do not match, a new package is prepared and uploaded... what do you think?

Official and public: I would say that this is up to you hdrmerge developers to decide how and when to make the AppImage packages official and easier to download. The uploading to the GitHub release page of the hdrmerge-appimage repository is easy and automated. I can also easily duplicate the most recent package as hdrmerge-latest.AppImage on github, so that you could simply put a link to it on the official downloads page and be sure that people will always get the latest version by following such link...

[Beep6581]

@aferrero2707 "automated" sounds good. "Official and public", the packages should appear in this project in the "releases" page, so what do I need to do to facilitate that? If you make a PR I can merge that, but if you need more access then @jcelaya would need to add you as a contributor.

[aferrero2707]

@Beep6581 @jcelaya - which release folder would you like to use to keep those daily snapshots?

In order to upload the packages, I most lilely only need a valid access token and the name of the release tag (I'm using continuous for other projects). However, I am not sure wether I need to be a contributor of the repository in order to be allowed to use the token...

Once the token is generated (the repo access should be enough), you should send it to me privately. It will be stored in my Travis CI account as an environment variable in such a way that it will be hidden from any build log or other public document.

[Beep6581]

@aferrero2707 could you elaborate on the first two questions - what do you mean by "release folder", and what is the significance of the "release tag"?

[aferrero2707]

@Beep6581 - sure! For example, the latest release is here: https://github.com/jcelaya/hdrmerge/releases/tag/v0.5.0 It is tagged as v0.5.0, and each release tag has its own page (what I called "folder") where you can put a description and any number of artefacts, like the release tarballs or binary packages.

Where should we put the daily appimages?

[Beep6581]

@aferrero2707 I'm still not sure what possible answers there are to "where", but using the word "nightly" sounds appropriate.

[aferrero2707]

@Beep6581 it could be as simple as having a https://github.com/jcelaya/hdrmerge/releases/tag/nightly release where new packages are stored whenever new commits are pushed to the master branch.

Sounds reasonable?

[Beep6581]

@aferrero2707 yes!

[aferrero2707]

@Beep6581 @jcelaya I've added both of you as collaborators of the hdrmerge-appimage repository, I hope this is fine for you.

The automated daily packaging is now fully functional, we will just need to move the uploading to a dedicated release here whenever possible. Until then, packages will be available from this link.

[aferrero2707]

@jcelaya @Beep6581 for the moment I have copied the existing AppImage packages manually into a new "Nightly builds" release. This will be automated whenever @jcelaya can provide a github token.

[jcelaya]

@aferrero2707 AFAIK tokens are per-user, not per-repo. If I give you a token, you would be able to access any of my repos, wouldn't you? Can you use your own token now that you are a collaborator in the HDRMerge repo?

Javi

2018-04-05 19:19 GMT+02:00 aferrero2707 notifications@github.com:

@jcelaya https://github.com/jcelaya @Beep6581 https://github.com/Beep6581 for the moment I have copied the existing AppImage packages manually into a new "Nightly builds" release https://github.com/jcelaya/hdrmerge/releases/tag/nightly. This will be automated whenever @jcelaya https://github.com/jcelaya can provide a github token.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jcelaya/hdrmerge/issues/109#issuecomment-379011173, or mute the thread https://github.com/notifications/unsubscribe-auth/AB9t_l3DI75NRH3749hMxm2qZHyUi-iDks5tllIXgaJpZM4O8C7h .

[aferrero2707]

@jcelaya you must be absolutely right! I will try and see if it works with my own token...

[aferrero2707]

@jcelaya works perfectly! The nightly AppImage packages are now up and running...

[luzpaz]

Can we get an appimage for the tagged releases as well ?

[Beep6581]

Yes.

[aferrero2707]

@luzpaz @Beep6581 @jcelaya let me have a look... I will make a release AppImage manually for now, then set-up a mechanism similar to what we have for RawTherapee

EDIT: the best would be to push the release to a "releases" branch, so that changes can be automatically detected and they can trigger the build of the updated packages...

[Beep6581]

@aferrero2707 I will use the same branching scheme here as in RT - releases get finalized in a release-x.y branch, then merged into releases and tagged.

If making a release manually complicates anything, then best if you wait for the 0.6 tag, which I will make soon but not just yet.

[aferrero2707]

@Beep6581 perfect! I will wait for the 0.6 tag. AFAIK, there should be no difference between development and release builds for HDRMerge, apart for the package naming...