Please provide an Element AppImage for Linux

[element-hq]

Please provide an Element AppImage for Linux

[huguesdk]

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

[karansapolia]

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

[srevinsaju]

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

[TheAssassin]

https://github.com/AppImage/AppImageUpdate

[Sarcasm]

Ah okay, good to know it's possible to get the AppImage working rootless.

I found a way:

# cat /proc/sys/user/max_user_namespaces
0
# echo 640 > /proc/sys/user/max_user_namespaces

Source https://unix.stackexchange.com/a/479759/88925

Thank you!

[Sarcasm]

The behavior with the GLIBC 2.17 version seems identical now between Arch and CentOS 7.
Looks ready to me. 👍

[probonopd]

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

[gafarma89]

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

[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.

[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.

[eX00r]

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

[srevinsaju]

I bundled the required libs as mentioned by @probonopd. The GLIBC version is now fixed, (previously I was assuming), got in some regex and add those to the appimage now. now the GLIBC indicates the original version. I might remove / deprecate the GLIBC2.23 version, as it might be redundant now.

🎉 I hope its ready @Sarcasm @huguesdk
https://github.com/srevinsaju/element-appimage/releases/tag/continuous

[Sarcasm]

Looks good!

[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?

[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)

[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.

[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.

[srevinsaju]

My mistake. Ubuntu 16.04 provides GLIBC 2.23 and not 2.17, and hence it failed on Centos 7. I will try to use travis to create an even more compatible appimage. Thanks for testing

[probonopd]

It works for me on Xubuntu 18.04 @srevinsaju 👍

[huguesdk]

i confirm that it works without errors on centos 7 on my side! 👍🥳🎉

are you planning to have an appimage for each release or only build continuously from the master branch?

[t3chguy]

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

[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.

[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]

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

[huguesdk]

@Sarcasm: i was able to build an appimage for centos 7. it was working for riot 1.5 (electron 6), but needed to be launched with --no-sandbox in order to work. the latest versions (since 1.6.8) use electron 9, and although the appimage runs, it only shows a blank screen, and an error is output to stderr:

[18029:0730/112006.154552:FATAL:platform_shared_memory_region_posix.cc(254)] This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 /dev/shm' to fix.

/dev/shm has the correct permissions.

without --no-sandbox it fails with this error:

[7838:0722/101648.868196:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

to work around this, the chrome-sandbox binary has to be set as suid root, but inside an appimage, this doesn’t work of course. the other solution is to call:

sudo sysctl kernel.unprivileged_userns_clone=1

as explained in element-hq/element-web#13171.

so, currently, i found no way to run the appimage of the latest version without sudo rights.

here is my recipe to build the latest version as an appimage (with seshat working!):

1. prerequisites: have a recent version of node.js on your path, with yarn installed, and have rust installed as explained here with rustc and cargo accessible on your path
2. download the element sources from: https://github.com/vector-im/riot-desktop/releases/latest
3. unpack it
4. enter the directory
5. yarn install
6. yarn run fetch --noverify --cfgdir element.io/release
7. yarn run build:native
8. edit package.json and change build.linux.target from deb to AppImage.
9. yarn build

you should have an appimage in the dist subdirectory. to make it run properly, though, i had to do a few more tweaks:

1. extract dist/Element-x.x.x.AppImage in an empty directory by running it with --appimage-extract
2. edit squashfs-root/AppRun: in the atexit() function, add this argument after "$BIN" on both exec lines: --force-color-profile=srgb (or the colors will look washed out)
3. download sqlcipher from https://github.com/sqlcipher/sqlcipher/releases (i used version 4.4.0)
4. build it
5. copy libsqlcipher.so.0* to squashfs-root/usr/lib
6. repack the appimage with appimagetool-x86_64.AppImage squashfs-root Element-x.x.x.AppImage (appimagetool can be found here)

[srevinsaju]

Yes, you are right. I am building appimages continuously (CI) on ubuntu-18.04 Github Actions. Maybe using Ubuntu 16.04 might fix the first error (lib64/libstdc++.so.6) but might make the AppImage a bit more bulky. Regarding libsqlcipher.so: thanks for providing the logs. I will try to add libsqlcipher into the appimage. (I assumed it to be linked automatically by the cc compiler). Let me check into it. Thanks again

[srevinsaju]

@huguesdk Fixed the libsqlcipher.so Error. Minimum requirements for the current build GLIBC 2.27. I will try building on Ubuntu 16.04 soon

[srevinsaju]

Agreed. I will remove the GLIB 2.27 version after you have tested it on centos.

[srevinsaju]

I will use CentOS 7 as the base, and will update this thread 😄

[huguesdk]

@srevinsaju: that’s great news, thanks a lot for all your work and the time spent!

i’m not able to test before monday. i’ll do it then.

[Sarcasm]

I was confused at first, because I got the same errors.
Then, I checked continuous.yml and I realized that there is an issue with the AppImage names:

• Element-v1.7.2-9-geb4bf9e-GLIBC-2.17.AppImage : this is the Ubuntu image
• Element-v1.7.2-9-geb4bf9e-GLIBC-2.27.AppImage : is the CentOS, GLIBC 2.17 image

No more (important) errors when running the latter image on CentOS 7! 🎉

Thanks a lot, I know it wasn't easy to get there, kudos to you. 👍

FYI, not sure it matters, but using the CentOS 7 image (2.27 with the current naming) on Arch, I get an error:

Seshat unexpected error: Error: libcrypto.so.10: cannot open shared object file: No such file or directory
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/tmp/.mount_ElemenlKt7JD/resources/app.asar/node_modules/matrix-seshat/lib/index.js:15:16)
    at Module._compile (internal/modules/cjs/loader.js:967:30)

[srevinsaju]

I will build from both, tagged release and latest continuous release. I will release under stable and continuous tag. I hope that would be the best.

[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 😄

[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]

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.

[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.

[Mikaela]

Has AppImage gotten support for automatic updates or would it require deleting everything and downloading a new version from riot.im every time a new release comes?

[uhoreg]

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

[zilti]

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

[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.

[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.

[zilti]

Step 1 got, imo, more convoluted. I had/have everything to produce an AppImage "the old way" before they made this two-repository thing here: https://github.com/zilti/riot-web.AppImage

[huguesdk]

indeed, an official appimage of riot desktop would be much appreciated.

i’m struggling with building an appimage of riot desktop with seshat included. what is the best way of doing this?

[probonopd]

If you can point me toward a working build of Riot for Ubuntu xenial, I can give a hand at turning it into an AppImage.

[t3chguy]

@probonopd https://riot.im/download/desktop/ for the Official Debian&Ubuntu apt repo

[Sarcasm]

@probonopd : Would be super interested to test riot-desktop as an App image, to see if this makes it possible to use on CentOS 7 (where the flatpak does not work, and building is complicated).

Edit: nevermind, I built it using https://github.com/AppImage/pkg2appimage, but it does not solve my CentOS 7 issue, looks like Ubuntu Xenial libstdc++ is more recent than the one on CentOS 7.

For the record, I used AppImage/pkg2appimage like this:

git clone https://github.com/AppImage/pkg2appimage.git
cat <<'EOF' > recipes/Element.yml
app: element-desktop
binpatch: true

ingredients:
  packages:
    - element-desktop
  dist: xenial
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ xenial main universe
    - deb http://packages.riot.im/debian xenial main

script:
  - mv opt/Element/* usr/bin/ ; rm -rf opt/
EOF
./pkg2appimage-with-docker recipes/Element.yml
./out/Element-1.7.2.glibc2.16-x86_64.AppImage

[probonopd]

In this case building Riot on e.g., trusty would probably solve your issue @Sarcasm

[huguesdk]

appimagehub has now an entry for element, pointing to this repository maintained by @srevinsaju. it doesn’t include libsqlcipher and requires cxxabi_1.3.9 and glibc_2.27 for seshat to work. it needs to be launched with --force-color-profile=srgb to avoid washed out colors.

[srevinsaju]

@huguesdk Please try the latest one from : https://github.com/srevinsaju/element-appimage
The new build should get updated on the appimagehub soon

[probonopd]

The new build should get updated on the appimagehub soon

Since AppImageHub points to https://github.com/srevinsaju/element-appimage/releases it is always up to date :)

[srevinsaju]

oh, great!, maybe @huguesdk should get a new copy from the appimagehub to fix that error.

[huguesdk]

the version i tested was the latest one. i’m not saying that it doesn’t work. i’m just saying that for seshat to work with this appimage (to be able to search for encrypted messages), one needs to have libsqlcipher installed and at least cxxabi_1.3.9 and glibc_2.27. to avoid washed-out colors i need to use --force-color-profile=srgb, but this may depend on the window manager used and the display configuration.

the errors i’m mentioning above are coming from the appimage that i built myself with the recipe i’m describing, but i guess that on centos 7, the same errors would happen with the one built from @srevinsaju’s repo.

[srevinsaju]

@huguesdk I would be glad if you could provide the terminal logs of the Appimage from my repository, so I can possibly fix any errors. Seshat does work for me. So I was just curious why it doesn't work for you.

[huguesdk]

@srevinsaju: oh, actually, with your appimage, it works on centos 7 without --no-sandbox and without the sandbox errors i have above with my own appimage! 👍

these are the errors i have on centos 7 related to seshat:

Keytar unexpected error: Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /tmp/.org.chromium.Chromium.wtXNIY)
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/tmp/.mount_ElemenLaJ9AO/resources/app.asar/node_modules/keytar/lib/keytar.js:1:14)
    at Module._compile (internal/modules/cjs/loader.js:967:30)
Seshat unexpected error: Error: libsqlcipher.so.0: cannot open shared object file: No such file or directory
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/tmp/.mount_ElemenLaJ9AO/resources/app.asar/node_modules/matrix-seshat/lib/index.js:15:16)
    at Module._compile (internal/modules/cjs/loader.js:967:30)

i think that the 1st error is due to the fact that the build is done on a more recent distribution than centos 7 (which is quite old) (but i don’t know what problem this error may cause). the 2nd error is due to the fact that the appimage does not contain libsqlcipher.so.0, and this library is not provided by centos 7 either.

[srevinsaju]

Ok. I am surprised by the same size of both the appimages. Maybe @huguesdk can test the 2.17 GLIBC AppImage generated by Ubuntu 16.04 image. The releases have been updated. Thanks!

[huguesdk]

thanks a lot! i don’t have access to a centos machine at the moment. i’ll test tomorrow.

normally, building on an older distribution should not increase the size of the appimage. if it works, it’s generally better to build on the oldest possible distribution to increase the compatibility (mainly due to glibc and libstdc++ versions).

[huguesdk]

unfortunately, it still does not work. ☹ i think supporting centos 7 is difficult, as it is quite old already. it ships with glibc 2.17 and libstdc++ 4.8.5 (cxxabi_1.3.7). the error i’m having now is:

Keytar unexpected error: Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /tmp/.org.chromium.Chromium.ljPgab)
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/tmp/.mount_ElemenjSTOn1/resources/app.asar/node_modules/keytar/lib/keytar.js:1:14)
    at Module._compile (internal/modules/cjs/loader.js:967:30)
Seshat unexpected error: Error: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/tmp/.mount_ElemenjSTOn1/resources/app.asar/node_modules/matrix-seshat/lib/index.js:15:16)
    at Module._compile (internal/modules/cjs/loader.js:967:30)

including libcrypto.so.1.0.0 from here, the 2nd error becomes:

Seshat unexpected error: Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /tmp/.org.chromium.Chromium.FoLN2t)
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/home/huguesd/tmp/squashfs-root/resources/app.asar/node_modules/matrix-seshat/lib/index.js:15:16)
    at Module._compile (internal/modules/cjs/loader.js:967:30)

the other appimage (for glibc 2.27) fails the same way, but requiring libcrypto.so.1.1.

[huguesdk]

i’ve seen that the oldest ubuntu distribution that github workflow provides is ubuntu 16.04. would it be an option to use travis ci instead, which provides ubuntu 14.04 (and even 12.04)?

[srevinsaju]

@huguesdk I built a new appimage on trusty tahr, (GLIBC 2.17). I guess this should work! Releases have been updated. I have not bundled libcrypto, I will add them after your testing on CentOS. It works on my Arch Linux. (I took some time to understand travis, and its build ecosystem. Sorry for the delay, and I learnt a lot of new stuff 🎉)

[huguesdk]

wow, that was fast, thanks! the only error there is now is this:

Seshat unexpected error: Error: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /tmp/.org.chromium.Chromium.uulHJq)
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/tmp/.mount_ElemenJPqEeN/resources/app.asar/node_modules/matrix-seshat/lib/index.js:15:16)
    at Module._compile (internal/modules/cjs/loader.js:967:30)

i did a grep in all the files of the app, and the only one containing glibc_2.18 is app.asar.

[srevinsaju]

Hmm, suspicious, maybe Ubuntu Trusty Tahr is using GLIBC 2.18 instead of GLIBC 2.17. I will get a docker image and test it locally

[srevinsaju]

app.asar includes matrix-seshat which is a Rust compiled / optimized binary. Getting updated libraries on Ubuntu 12.04 is going to be a challenge 😄 . Can travis use centos images?

[srevinsaju]

oh, sed. ubuntu Trusty is using GLIB C 2.19, my bad. CentOS7 is really a very old distro.

[Sarcasm]

Just a thought, but it looks like you can run on a centos:7 container with Github Actions.

There is an example here:

• https://github.com/ninja-build/ninja/pull/1712/files#diff-3197f5fdf00d858a9334b31db5a81992R12-R13

In anycase, great work.
A working Element for CentOS 7 would be great (for me)!

[huguesdk]

all the gnu/linux flavors i could find in the travis ci documentation was ubuntu. there is also circle ci, maybe that is an option? i hope the build succeeds on ubuntu 12.04, good luck and thanks again!

@Sarcasm: actually, the appimage already works on centos, it is only seshat (for searching encrypted messages) that does not work.

[srevinsaju]

I will try on Ubuntu 12.04. The only problem is Rust compiler, which is not easily available on Ubuntu 12.04 (EOL on 2017 September), Anyway I shall try my luck.

[srevinsaju]

Ubuntu 12.04 is very old (GLIBC 2.15-0ubuntu10.18),

Thanks for this link: https://github.com/vector-im/riot-web/issues/4766#issuecomment-667086721, this seems useful.

[Sarcasm]

FYI, CentOS 7 EOL is 2024, so might be a better base than Ubuntu 12.04.

I tested the latest image, and I just get a a blank window, so I assume @huguesdk when you say it works, is when you run the AppImage as sudo user? As per your comment here: https://github.com/vector-im/riot-web/issues/4766#issuecomment-666273931

[huguesdk]

@Sarcasm sorry: i tested it on two different centos 7 machines. i don’t have access to the one on which i tested my own appimage. i’ve just noticed that on the one i’m using now my own appimage works too (same as the latest appimage from @srevinsaju), unless i use --no-sandbox, in which case i have a blank screen. i don’t know how the two machines differ in their configuration. they’re both centos 7.2.1511.

what is the error you’re seeing when launching with the latest appimage?

[Sarcasm]

With Element.AppImage I get an error:

[17476:0731/145305.828373:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_Elemen3uoohV/chrome-sandbox is owned by root and has mode 4755.
zsh: trace trap (core dumped)  ./Element.AppImage
# command exited with status SIGTRAP                                                                                                                                                                                                           

With Element.AppImage --no-sandbox I get a blank screen and some more messages:

Element AppImage Build
Seshat unexpected error: Error: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /tmp/.org.chromium.Chromium.tpHmB8)
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/tmp/.mount_ElemenSktG3P/resources/app.asar/node_modules/matrix-seshat/lib/index.js:15:16)
    at Module._compile (internal/modules/cjs/loader.js:967:30)
$HOME/.config/Element exists: yes
$HOME/.config/Riot exists: no
(node:18213) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
No update_base_url is defined: auto update is disabled
[18326:0731/145617.271161:FATAL:platform_shared_memory_region_posix.cc(254)] This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 /dev/shm' to fix.

If I extract the AppImage, fix the chrome-sandbox, I get something that works.
What I'd like to have is to run with --no-sandbox, and have something that works, which I hope a native CentOS 7 build could resolve.

For you, it works because you run the Element.AppImage as sudo user right?

[huguesdk]

no, i’m running it as a normal user, without sudo rights. i did not install nor configure this machine myself. i know that something has been done to allow for some other electron app to work. maybe some selinux tweak?

[srevinsaju]

@huguesdk @Sarcasm An appimage built on CentOS 7. https://github.com/srevinsaju/element-appimage/releases/tag/continuous

Took some time though. The centos7 version is marked with GLIB2.17. Let me know if it works!

PS: Please ignore other releases. the continuous tag is the latest

[srevinsaju]

Thanks for the error message, I will add a copy of libcrypto to the appimages. Maybe it was already found in /usr by default on Arch, Ubuntu, Xubuntu - (my test systems), and hence I was not able to reproduce the errors, and my centos 7 had a copy of libcrypto, (am not sure why, didn't try with a fresh centos7 image)

Edit: oh my bad, didn't notice the difference in naming. Will fix it quick.

[huguesdk]

i think adding libcrypto to the appimage is a good idea, because its name changes a lot between versions: libcrypto.so.6, libcrypto.so.1.0.0, libcrypto.so.1.1, libcrypto.so.10,…

[probonopd]

The following libraries need to be privately bundled inside the AppImage, see

• AppImageCommunity/pkg2appimage@6c7473d
• http://stackoverflow.com/questions/32644157/forcing-a-binary-to-use-a-specific-newer-version-of-a-shared-library-so

So please bundle inside the AppImage:

• libssl.so.1
• libssl.so.1.0.0
• libcrypto.so.1
• libcrypto.so.1.0.0

As a general rule of thumb, all libraries that are not listed on https://github.com/AppImage/pkg2appimage/blob/master/excludelist should be bundled based on our experience.

[srevinsaju]

Released 🎉 :
Stable: https://github.com/srevinsaju/element-appimage/releases/tag/stable points to latest tagged release
Beta: https://github.com/srevinsaju/element-appimage/releases/tag/continuous points to "built from master" release

[Sarcasm]

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?

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.

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)?

[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?

[Thatoo]

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

[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 : element-hq/element-web#13885
• Debian : element-hq/element-web#6153
• Docker : element-hq/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.

[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.