Element-web: Please provide an Element AppImage for Linux

Created on 8 Aug 2017  ·  88Comments  ·  Source: vector-im/element-web

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.

feature p3 packaging
Source
picture probonopd
👍17 ❤3 👎1

Most helpful comment

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

picture huguesdk on 3 Aug 2020
👍5 ❤1

All 88 comments

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 picture t3chguy on 8 Aug 2017

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

t3chguy picture t3chguy on 8 Aug 2017

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

t3chguy picture t3chguy on 8 Aug 2017

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 picture probonopd on 8 Aug 2017

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

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

probonopd picture probonopd on 8 Aug 2017

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 #3718 (FlatPak support)

uhoreg picture uhoreg on 15 Aug 2017
👍1

any updates on this?

Serkan-devel picture Serkan-devel on 11 Mar 2018

I would appreciate this as well

chaossec picture chaossec on 12 Mar 2018

I have created a PR for this: #6422.

aidalgol picture aidalgol on 30 May 2018

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.

aidalgol picture aidalgol on 30 May 2018
👍1

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?

Mikaela picture Mikaela on 31 May 2018

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.

probonopd picture probonopd on 31 May 2018
👍2

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

TheAssassin picture TheAssassin on 1 Mar 2019
👍2

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

zilti picture zilti on 25 Apr 2019
👍2

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

uhoreg picture uhoreg on 25 Apr 2019

https://github.com/AppImage/AppImageUpdate

TheAssassin picture TheAssassin on 25 Apr 2019
👍4

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

zilti picture zilti on 10 Jul 2019

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

TheAssassin picture TheAssassin on 10 Jul 2019
👍1

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.

zilti picture zilti on 2 Aug 2019
👍2

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.

TheAssassin picture TheAssassin on 2 Aug 2019

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

eX00r picture eX00r on 5 Sep 2019
👍3

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

zilti picture zilti on 10 Oct 2019
👍1

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.

zilti picture zilti on 19 Dec 2019
👍2

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

karansapolia picture karansapolia on 1 Jan 2020
👍3 ❤1

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

zilti picture zilti on 20 May 2020

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.

t3chguy picture t3chguy on 20 May 2020

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.

probonopd picture probonopd on 23 May 2020

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

zilti picture zilti on 25 May 2020

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?

huguesdk picture huguesdk on 3 Jun 2020

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.

probonopd picture probonopd on 6 Jun 2020

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

t3chguy picture t3chguy on 6 Jun 2020

@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
Sarcasm picture Sarcasm on 29 Jul 2020

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

probonopd picture probonopd on 30 Jul 2020

@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 #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)
huguesdk picture huguesdk on 30 Jul 2020
👍1

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.

huguesdk picture huguesdk on 30 Jul 2020

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

srevinsaju picture srevinsaju on 30 Jul 2020

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

probonopd picture probonopd on 30 Jul 2020

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

srevinsaju picture srevinsaju on 30 Jul 2020

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.

huguesdk picture huguesdk on 30 Jul 2020

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

srevinsaju picture srevinsaju on 30 Jul 2020

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

huguesdk picture huguesdk on 30 Jul 2020

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 picture srevinsaju on 30 Jul 2020
👍1

@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 picture srevinsaju on 30 Jul 2020
👍1

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!

srevinsaju picture srevinsaju on 30 Jul 2020

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 picture huguesdk on 30 Jul 2020

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

srevinsaju picture srevinsaju on 30 Jul 2020
👍1

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 picture huguesdk on 31 Jul 2020

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

huguesdk picture huguesdk on 31 Jul 2020

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

srevinsaju picture srevinsaju on 31 Jul 2020
👍2

@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 :tada:)

srevinsaju picture srevinsaju on 31 Jul 2020

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.

huguesdk picture huguesdk on 31 Jul 2020

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 picture srevinsaju on 31 Jul 2020

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 :smile: . Can travis use centos images?

srevinsaju picture srevinsaju on 31 Jul 2020

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

srevinsaju picture srevinsaju on 31 Jul 2020

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

There is an example here:

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

Sarcasm picture Sarcasm on 31 Jul 2020

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.

huguesdk picture huguesdk on 31 Jul 2020

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 picture srevinsaju on 31 Jul 2020

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.

srevinsaju picture srevinsaju on 31 Jul 2020

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

Sarcasm picture Sarcasm on 31 Jul 2020

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

srevinsaju picture srevinsaju on 31 Jul 2020
❤1

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

huguesdk picture huguesdk on 31 Jul 2020

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?

Sarcasm picture Sarcasm on 31 Jul 2020

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?

huguesdk picture huguesdk on 31 Jul 2020

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 picture Sarcasm on 31 Jul 2020
👍4

@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 picture srevinsaju on 31 Jul 2020

It works for me on Xubuntu 18.04 @srevinsaju :+1:

probonopd picture probonopd on 31 Jul 2020
😄1 👍1

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

huguesdk picture huguesdk on 31 Jul 2020
👍1

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! :tada:

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

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)
Sarcasm picture Sarcasm on 1 Aug 2020
🎉1

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.

srevinsaju picture srevinsaju on 1 Aug 2020

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,…

huguesdk picture huguesdk on 1 Aug 2020

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

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.

probonopd picture probonopd on 1 Aug 2020

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.

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

srevinsaju picture srevinsaju on 1 Aug 2020
👍2 🎉1

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

Sarcasm picture Sarcasm on 1 Aug 2020
❤2 🎉1 👍1

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?

huguesdk picture huguesdk on 3 Aug 2020
🎉2

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 picture srevinsaju on 3 Aug 2020
👍1

Released :tada: :
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

srevinsaju picture srevinsaju on 3 Aug 2020

Great, thank you very much for your hard work! :+1:

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

Sarcasm picture Sarcasm on 3 Aug 2020

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?

srevinsaju picture srevinsaju on 3 Aug 2020

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?

huguesdk picture huguesdk on 3 Aug 2020

@huguesdk Great! I will do like that then!

srevinsaju picture srevinsaju on 3 Aug 2020

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 picture Sarcasm on 3 Aug 2020

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

srevinsaju picture srevinsaju on 3 Aug 2020

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 picture srevinsaju on 3 Aug 2020

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

srevinsaju picture srevinsaju on 3 Aug 2020
👍3 🎉2

Looks good!

Sarcasm picture Sarcasm on 3 Aug 2020
❤3

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

image

probonopd picture probonopd on 3 Aug 2020
👍2 😄1

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

huguesdk picture huguesdk on 3 Aug 2020
👍5 ❤1

Flatpak, appimage, snap they would be great... :+1:

gafarma89 picture gafarma89 on 21 Aug 2020
❤1 👍1
Was this page helpful?
0 / 5 - 0 ratings

Related issues

n-o-o-b picture n-o-o-b  ·  3Comments
anoadragon453 picture anoadragon453  ·  3Comments
NotAFile picture NotAFile  ·  3Comments
bagage picture bagage  ·  3Comments
turt2live picture turt2live  ·  3Comments