Please provide an Element AppImage for Linux

[probonopd]

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

Example Riot AppImage:
https://bintray.com/probono/AppImages/Riot/_latestVersion#files

Made using:
https://github.com/AppImage/AppImages/blob/master/recipes/meta/Riot.yml

electron-builder has native support for generating AppImages, so it should be very easy to do.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

[t3chguy]

I don't think the core devs have enough bandwidth to monitor all the additional release formats, there was a FlatPak PR from community that has gone stale for this reason too. ++ Why not use the AppImage option inside electron-builder..?

[t3chguy]

Also making an arbitrary file from the internet executable and running it sounds like such a great recipe...

[t3chguy]

Finally, you should probably specify -web or -electron
assuming the latter

[probonopd]

Also making an arbitrary file from the internet executable and running it sounds like such a great recipe...

It's would not be "arbitrary" if it came from the original upstream authors and was signed with their key. Linus Torvalds likes the concept btw.

[probonopd]

Why not use the AppImage option inside electron-builder..?

That's what I suggest. Should be easy to use that.

[uhoreg]

Also making an arbitrary file from the internet executable and running it sounds like such a great recipe...

Security-wise, there isn't much difference between marking a file downloaded from https://riot.im/... executable and running it, and installing a package downloaded from https://riot.im/.... In fact, running an appimage downloaded from riot.im could be considered less risky, because it only runs under the user's permissions, whereas installing a package can run a script with root privileges.

BTW, related to #656 (FlatPak support)

[Serkan-devel]

any updates on this?

[chaossec]

I would appreciate this as well

[aidalgol]

I have created a PR for this: element-hq/element-web#6422.

[aidalgol]

Also making an arbitrary file from the internet executable and running it sounds like such a great recipe...

Security-wise, there isn't much difference between marking a file downloaded from https://riot.im/... executable and running it, and installing a package downloaded from https://riot.im/.... In fact, running an appimage downloaded from riot.im could be considered less risky, because it only runs under the user's permissions, whereas installing a package can run a script with root privileges.

There is a sandboxing program called firejail that has support for appimages. I already run most applications under this.

[probonopd]

Not only are there updates (although I don't like "automatic"), there are even binary delta updates which means you only download the few MB that have actually changed. See AppImageUpdate.

[TheAssassin]

I would love to see an AppImage asap. Making one is very easy with electron-builder.

[zilti]

You can drop the .deb package. It's not needed anymore if you provide an AppImage, and an AppImage is easier to build.

[uhoreg]

Do AppImages have an update mechanism? If not, then I'd say that the .deb packages are still needed.

[TheAssassin]

https://github.com/AppImage/AppImageUpdate

[zilti]

Is anyone working on this? Is there something I can provide to it, or help with, to make it happen?

[TheAssassin]

@zilti you could try to make some AppImage with electron-builder from the repository, I think it's already using it. We might be able to prepare a PR then.

[zilti]

Yes, it suffices to change "linux""target" to "appimage" in package.json. Or to add "appImage" to "build", as in

"appImage": {
      "category": "Network;InstantMessaging;Chat",
      "desktop": {
        "StartupWMClass": "riot"
      }
    }

and I added "build:electron:appimage": "yarn build && build -l appimage" as well as a target, but I couldn't figure out how to integrate it into "build:electron" or anything else.

[TheAssassin]

So it'll take little effort to make some in the CI I guess. I'd really like to use them. I hate chatting in a browser.

[eX00r]

Please let me know if there is an up-to-date usable appImage. Would really appreciate if one is provided officially.

[zilti]

Any news on this? It's such a small fix...

[zilti]

This is basically all that is needed: https://github.com/zilti/riot-web.AppImage/blob/master/package.json.patch

In that same repo I build the AppImage using CircleCI. It also gets signed with my key.

[karansapolia]

Would love to have an appImage for Riot. I use Fedora and would appreciate a desktop app more.

[zilti]

Thanks to the new, convoluted way to build this I will no longer build an AppImage. I hoped the devs would take this as a starting point to provide their own, but apparently they rather focus on making it more complicated to build from source in the first place (a second repository!), and completely ignore any offered contributions for an AppImage. drops mic

[t3chguy]

convoluted

Its actually simpler, it supports building straight from a riot-web tarball so you no longer have to build the webpack stuff as well as the electron stuff.

The additional complexity in the new repository is required for building native code such as Seshat.

There's even a docker build image to help.

[probonopd]

There are two steps involved:

1. Produce what goes into an AppImage
2. Produce the AppImage

Is 1 or 2 what is "convoluted"?

Once there are suitable binaries, it should be rather easy to put them into an AppImage. Let me know if I can help.

[srevinsaju]

Great, thank you very much for your hard work!

A few questions:

When I got to https://github.com/srevinsaju/element-appimage/releases (linked from https://appimage.github.io/element/), "Stable AppImage Release" assets are collapsed by default, but the ones for the "Beta AppImage Release" aren't.
Wouldn't be better to have both of them NOT collapsed, so downloading the AppImage is one click away?

@Sarcasm, GitHub automatically expands the Latest Release and the rest and collapsed. I guess, its not manually possible to expand the release. But what I may be able to do, would be to generate a Github Page (gh-pages) which is an HTML file, which should have two buttons, Stable and Beta, which would automatically redirect you to the correct appimage.

There is a 1.4MB difference between the 2 images out of about 88MB. Proportionally, the difference is low.
Is there any advantage apart from that to keep the GLIB 2.23 release in addition to the more portable GLIB 2.17 one?
I'm thinking, someone not familiar with the details of GLIBC ABI will have a hard time picking up the right version.

GLIB 2.17 has more compatibility than GLIB 2.23. as the GLIB 2.17 is built on Cent OS 7 directly, the other one is built on Ubuntu Trusty (16.04). I am not sure if there is any improvement in performance, that is a question I am looking to find a solution for. In a few days, in case, I will be removing GLIB 2.23 version, as it might become redundant. But I'm unsure if I should. Can someone guide me regarding this? I am having very less experience with C

At this time, the Stable release points provides Element-v1.7.3-rc.1-GLIBC-2.17.AppImage.
rc.1 does not sound "Stable" to me, release candidates are more like in the "Beta" category.
Wouldn't be better for "Stable" to point to the non-release candidate official tag (1.7.2 at the time of this writing)?

Hmm, yes

git describe --tags `git rev-list --tags --max-count=1`

The output points to 1.7.3.rc1
Do you know a better git command to extract the latest stable release from a repository?

[huguesdk]

i think that the latest release information is stored internally by github (as a reference to a tag), but that you cannot get this information directly from the repository only. this is the documentation on how to get the information (including the tag name) of the latest release: https://docs.github.com/en/rest/reference/repos#get-the-latest-release

maybe you can also get the tarball of the latest release instead of using the repository?

[srevinsaju]

@huguesdk Great! I will do like that then!

[Sarcasm]

Oh I see, I'm surprised to see stable above the continuous build, but but that continuous is the Latest release.
No problem then, if that's how Github works, it's not on you.

Concerning GLIBC, I wouldn't know how to compare either.
If an issue is seen with the GLIBC 2.17, it would be worth to compare with GLIBC 2.23 or later, but I don't think performance will be worse with GLIBC 2.17 on a newer system, because you build with GLIBC 2.17 but you don't bundle it, so in the end, it's the host version that is used at runtime.
I think, what can change, is that GLIBC 2.17 does not support some features that GLIBC 2.23 does.

[srevinsaju]

Lol, riot-desktop got moved to element-desktop. Need to patch that too!

[srevinsaju]

Oh I see, I'm surprised to see stable above the continuous build, but but that continuous is the Latest release.
No problem then, if that's how Github works, it's not on you.

Concerning GLIBC, I wouldn't know how to compare either.
If an issue is seen with the GLIBC 2.17, it would be worth to compare with GLIBC 2.23 or later, but I don't think performance will be worse with GLIBC 2.17 on a newer system, because you build with GLIBC 2.17 but you don't bundle it, so in the end, it's the host version that is used at runtime.
I think, what can change, is that GLIBC 2.17 does not support some features that GLIBC 2.23 does.

@Sarcasm are you on #element? can you DM me on matrix / IRC?

[srevinsaju]

@Sarcasm @huguesdk Done. Now the stable release points to the released version on element-desktop repository.
Redundant GLIB version have been removed!!

[Sarcasm]

Looks good!

[probonopd]

Now, looking forward to a download button for Linux on the landing page:

[huguesdk]

@srevinsaju: great, thanks! i think it would be worth advertising about your appimage on #twim:matrix.org.

[gafarma89]

Flatpak, appimage, snap they would be great... 👍

[Thatoo]

An appimage for x86 and and appimage for arm would be awesome!

[srevinsaju]

The Element Desktop does not include instructions to build ARM builds, although its possible to build a standalone element appimage without its dependencies. Until then, I would not be able to update the Element AppImage continuous builds with ARM builds. x86 looks easy to build, and I can work on it this christmas 😄

[Thatoo]

That is a happy news to know an appimage is on the way for Element.

On arm topic... there are several requests about arm packages but none have any success:

• Manjaro : Fails to build on aarch64 element-web#13885
• Debian : Debian package for ARM element-web#6153
• Docker : Official docker image for ARM element-web#15227
  and now an arm appimage topic in here.
  Hopefully there will soon be instructions to build ARM builds. Maybe we should open a dedicated issue (ARM builds) pointing to these 4 topics.

[srevinsaju]

Yes, agreed. That would solve a lot of issues, even for distro packagers

[Thatoo]

OK, then, done. Hopefully it'll help.

[Thatoo]

The Element Desktop does not include instructions to build ARM builds, although its possible to build a standalone element appimage without its dependencies. Until then, I would not be able to update the Element AppImage continuous builds with ARM builds. x86 looks easy to build, and I can work on it this christmas smile

@srevinsaju Thank you for providing an x86 appimage. Awesome!
Someone is explaining here how to build for arm, element-hq/element-web#6153 , do you think you could provide an arm appimage too?

[chaperonRose]

Hello,
Is there any news about providing an official AppImage ?
That's a good idea to drop off the problem of maintening several packages.
Thanks

[t3chguy]

@chaperonRose no, the team does not have the resources to maintain a new & unfamiliar to us packaging format. It would increase work significantly and we are a small team.