Please provide AppImage for download on GitHub Releases #1092
Milestone
Comments
|
Good timing. Working on our 3.10.0 release bits soon. 😄 |
|
k, to make this happen, what do we need to do? Is there an example "best practice" one I can look at and pretty much cut-n-paste what they did? 😉 |
|
Check out https://github.com/probonopd/uploadtool |
|
k, I'll probably muck around with this tomorrow and see if I can figure it out. 😄 |
justinclift
modified the milestones:
3.11.0 - Where we take over the world! :D,
3.10.0 - A Rubber Cactus Has Many Uses
|
@deepsidhu1313 You mentioned an interest in Snap packaging on Linux. Any interest in AppImage packages too? 😄 Ahhh, ignore that. Seems things are mostly setup atm and just needs a bit of tweaking (as per below). |
|
In case you are not aware, the AppImage is already being built for each git push on Travis CI. It is just not uploaded to GitHub Releases yet. |
|
k. Looking at it now. I've just done the token generation and added the env variable to Travis. Next step figuring out what to put in .travis.yml |
|
k, seem to have gotten an initial first pass of things working: Is there any way to change the title for the release it generates to "Continuous Linux build" instead of just "Continuous build"? Pretty sure it'll be confusing to newbie users on Windows and/or OSX otherwise. 😄 |
|
... and then looking at the source there's an obvious |
Sure, it's just a bash script... |
|
@justinclift Good you handled AppImage packaging. But be sure you are using Ubuntu 14.04 contain image in travis. If this creates problems for you upgrade it to 'xenial'. Some interesting links: |
Can you elaborate on this? AppImages generated on trusty should run on newer distributions as well; if not, it's a bug. |
|
@deepsidhu1313 Thx... I'm just getting the scripting to work atm. It's pretty simple stuff, but the iteration time is pretty slow so it'll probably take another hour or two. Haven't even looked at tested the generated images yet. Which I should probably do eh? 😁 |
|
Yes they can be used. But by default some of the packages are not available
in Ubuntu repos like qt's latest version. Which is clear from travis file
that you are installing from other ppa. I m not sure but lets say deb built
via this method using external ppa will need latest(or same version) Qt
libraries to run. But most of the regular users dont have this ppa added to
their system. For testing your code its good, if you are controlling the
libraries and packages. But for deployment it can cause problems or bugs.
If you agree i would like to say even for testing it is better to assume
that user doesnt have special repos or ppa added to their system and it is
a default system available.
As in previous issue different version of sqlite or sqlcipher can cause
compatibility issues between db files.
…On Sep 2, 2017 11:36 AM, "probonopd" ***@***.***> wrote:
If this creates problems for you upgrade it to 'xenial'.
Can you elaborate on this? AppImages generated on trusty should run on
newer distributions as well; if not, it's a bug.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1092 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVA8n3d1fQARF4nuV8jfYo284ov7V13ks5seYQTgaJpZM4O78O9>
.
|
|
With AppImage this will not cause problems or bugs, since the subset of Qt that is required to run this application will be privately bundled inside the AppImage. This means that to run the AppImage, the user will not need the PPA. That's the whole point of it! |
|
@deepsidhu1313 Hmmm, don't AppImages bundle all of the needed dependencies internally? If so, that means there shouldn't be any missing external libraries when deployed, as all of the needed pieces are contained inside the AppImage itself. So the PPA's (and packages in them) configured for the users' system shouldn't have any kind of effect. |
Not all, only those that cannot reasonably be expected to already be present on all target systems (e.g., glibc). But the subset of Qt that this specific application needs to run will be bundled by |
|
Ahhh, no worries. 😄 |
|
My apologies i guess i got confused between nomenclature. I thought
AppImage is ios or macos thing. :simle:. So it is alternate for snap
packages. I should have googled it before assuming.
…On Sep 2, 2017 12:26 PM, "Justin Clift" ***@***.***> wrote:
Ahhh, no worries. 😄
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1092 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVA8rfaK_IlkIdNQvazb5-gAHBkd_J0ks5seY_dgaJpZM4O78O9>
.
|
|
AppImage is the direct equivalent of an |
|
Libraries were the reason i was working on snap package. Built a snap
package successfully but unable to launch sqlitebrowser from global
command. However binary file from inside the snap package works just fine.
If AppImage has more pros than snap i guess i will give it a try.
|
|
Providing an AppImage would have, among others, these advantages:
|
|
But again, _the AppImage is already being built for each git push. It's just a matter of uploading it to GitHub Releases. |
|
So anybody working on AppImage other than Justin ??
|
|
Ok. Sounds good.
|
|
AppImages are available under Continous linux build tag. Please test these
builds so that we xan repeat the process for stable build.
|
probonopd
added a commit
to AppImage/appimage.github.io
that referenced
this issue
Feb 21, 2019
|
Thanks for providing an AppImage. Please |
|
Still getting |
I am exporting the VERSION variable. We tried nightly build of linuxdepoyqt which caused our build to fail as we are using xenial image in our build. If you can please provide a solution to the notification problem at every continuous release (Every time it runs (once for every single commit), it then causes a new
we can deal this in separate issue. This issue is turning into more of some Epic book story. (Title can be " Quest to release AppImage." 😄 , I am open to title suggestions, lets close this issue with Epic title) |
|
Wonder if it'd be possible to upload the continuous Linux builds to somewhere other than the GitHub releases area? eg maybe have them uploaded to nightly build server, same as our windows and macOS builds? The uploading bit itself (eg rsync/scp) is probably feasible. Not sure how to make the authentication piece work though, as the nightlies server requires a ssh public key. No idea (yet) how we'd provide that to the script in a way which doesn't make it publicly available. Guessing other people have already solved that problem though...? |
Please build on trusty, since this is currently the oldest still-supported version of Ubuntu. Else your AppImage will not run on all still-supported versions of Ubuntu. Thanks. |
|
trusty EOL is in one month. People have already migrated to latest LTS or
going to migrate soon. No body wants to run insecure system. Give me a
solid statistical number of user base, dependent on trusty build for
sqlitebrowser, i am ready to volunteer few more hours. But if you ask me it
is not worth.
For example, Here is snap package metrics, and it is still in dev mod.
…On Sat, Feb 23, 2019 at 9:03 AM probonopd ***@***.***> wrote:
we are using xenial image in our build
Please build on trusty, since this is currently the oldest still-supported
version of Ubuntu. Else your AppImage will not run on all still-supported
versions of Ubuntu. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1092 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVA8vgcQtGUFMwWH2BnX5nYWAz7qOO8ks5vQVhKgaJpZM4O78O9>
.
--
Regards
Navdeep Singh Sidhu
|
|
Heh Heh Heh, you'll need to manually attach that pic. 😄 |
|
|
|
Hi. Still no AppImage for the June release, but it gets its separate "Continuous build" section. Is this the final form of releasing, like it's not going to change anymore? What about this issue then? |
|
Well, tried to run "Continuous build". Guess what? Logsgdb backtrace/proc/xxxx/mapsMy system: |
|
@ratijas Oops. I created the Windows and Linux builds for the 3.12.0 release, but adding in an AppImage completely slipped my mind. Looking at our Release process wiki page (mostly used as a reminder), it already had a note about it, which I somehow missed. 😦 Just updated that page now, so it's more obvious for next time. @deepsidhu1313 Would you be up for creating an AppImage for the We could add that to the 3.12.0 downloads, and also create a blog entry about it so people know it's available now. |
|
@ratijas For the error pieces there, I personally have no idea. It clearly has a lot of mentions of SSL in there, but that aside... I'm not sure where to even start. |
|
The backtrace says that the crash happens while loading a certificate file and I assume the SSL errors are printed while that is happening. To me this looks like the SSL library is not included in the AppImage file or something similar. |
|
Sorry guys, I have been recently very occupied with work. I will try building it on my forked repo then will create merge request if everything goes well. |
|
@deepsidhu1313 No worries at all, we all go through stages like that. 😁 |
|
For me, current continuous build AppImage runs well under Ubuntu 18.04.
|
|
I've made a change in order to get continuous AppImage builds in the v3.12.x and the generated image is working for me. Using this, we could manually upload that AppImage when we release v3.12.2. The change is not expected to be merged to the master branch, and having a unified version would require a more elaborated configuration. The current image does not match v3.12.1 because we have already advanced one commit in the branch. My intention was that the continuous release would be called |
|
That's a good idea. For the naming problem, is it something that could be solved by simply hard coding the correct name? It seems the config file there is only used for the |
|
Yes, that's the simplest approach. We can do that until someone comes up with a more general solution. |
|
Have you tried using the environment variables provided by Travis instead, especially |
mgrojo
added a commit
that referenced
this issue
Feb 6, 2021
The command `git rev-parse --abbrev-ref HEAD` is not returning the branch name in the travis server, and for the version in AppImage filename it would be enough to have the short commit id. Note that these changes are branch dependant. See issue #1092
mgrojo
added a commit
that referenced
this issue
Feb 6, 2021
Travis environment variables are used. See issue #1092
|
Thanks, @FriedrichFroebel, that's very useful. |
|
Closing this since we have had AppImage for quite a while now 😃 I'd say any remaining issues with the AppImages (if there are any) are probably a new issue. |
|
Thank you very much @MKleusberg. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please provide the AppImage for download on GitHub Releases, thanks.
Reference:
AppImage/appimage.github.io#15
The text was updated successfully, but these errors were encountered: