Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

appimage-run: init #41762

Merged
merged 1 commit into from Jun 23, 2018
Merged

appimage-run: init #41762

merged 1 commit into from Jun 23, 2018

Conversation

tilpner
Copy link
Member

@tilpner tilpner commented Jun 9, 2018

Motivation for this change

This adds a best-effort hack to run AppImages, which currently don't
work out-of-the-box on NixOS. This is not preferable to using packaged
applications, but may help users if the application they want to run
is not in nixpkgs.

It uses the package list from the Steam chroot, but without Steam
packages.

As with steam-run, this does little sandboxing. I have an alternative
expression that uses bubblewrap to isolate the users data from
the to-be-run AppImage.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

export APPDIR="$SQUASHFS_ROOT/squashfs-root"
export APPIMAGE_SILENT_INSTALL=1

cd "$SQUASHFS_ROOT"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this happen after the [ ! -x ... ] check? Now you'd have to specify absolute paths when cd-ing into $SQUASHFS_ROOT and checking paths afterwords

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well spotted, thank you. Should work with relative and absolute paths now (tested a few times)

@orivej
Copy link
Contributor

orivej commented Jun 11, 2018

Why don't you run the appimage unextracted?

@tilpner
Copy link
Member Author

tilpner commented Jun 11, 2018

@orivej It uses FUSE, which needs fusermount, which is SUID, which is not allowed in the sandbox buildFHSUserEnv uses. At least that's how I interpret this:

fusermount: /nix/store/v6l2sacryfr88yqq0pq7sia8wfgm9q31-wrapper.c:203: main: Assertion `!(st.st_mode & S_ISUID) || (st.st_uid == geteuid())' failed.

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information
open dir error: No such file or directory

It can be done prettier, without a user env (by extracting into the store and patching there), but I don't see how it could be done with unextracted AppImages and without any kind of FHS env. :/

@dtzWill
Copy link
Member

dtzWill commented Jun 14, 2018

Not sure how common this is among AppImage files but apparently the one for https://moo.do wants gtk3, adding that was useful.

Although now getting an error that appears to be from electron -- which tells me everything I wanted to know about this AppImage anyway (I was wondering if it was a wrapper for the web interface or an actual program haha).

Anyway might be worth adding gtk3 deps too, especially since they're the "norm" these days. Steam apps probably use a lot less GTK :).

For the curious:

module.js:545
    throw err;
    ^

Error: Cannot find module '/tmp/tmp.0ZAiHnYRdi/squashfs-root/resources/electron.asar/browser/init.js'
    at Function.Module._resolveFilename (module.js:543:15)
    at Function.Module._load (module.js:473:25)
    at Function.Module.runMain (module.js:683:10)
    at startup (bootstrap_node.js:196:16)
    at bootstrap_node.js:622:3

Seems to work with the latest Cutter appimage! \o/

https://github.com/radareorg/cutter/releases/download/v1.4/Cutter-v1.4-x86_64.AppImage

Hmm well it launches but has problems opening files:

Setting r2 prefix = "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr"  for AppImage.
Setting PYTHONHOME = "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr"  for AppImage.
PYTHONHOME = "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr"
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "cutter_jupyter.py", line 124, in start_jupyter_async
  File "<decorator-gen-7>", line 2, in initialize
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/site-packages/traitlets/config/application.py", line 87, in catch_config_error
    return method(app, *args, **kwargs)
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/site-packages/notebook/notebookapp.py", line 1507, in initialize
    self.init_webapp()
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/site-packages/notebook/notebookapp.py", line 1270, in init_webapp
    self.jinja_environment_options
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/site-packages/notebook/notebookapp.py", line 156, in __init__
    default_url, settings_overrides, jinja_env_options)
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/site-packages/notebook/notebookapp.py", line 179, in init_settings
    sys_info = get_sys_info()
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/site-packages/notebook/_sysinfo.py", line 98, in get_sys_info
    return pkg_info(path)
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/site-packages/notebook/_sysinfo.py", line 89, in pkg_info
    platform=platform.platform(),
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/platform.py", line 1360, in platform
    libcname, libcversion = libc_ver(sys.executable)
  File "/tmp/tmp.yWsn4FtF6H/squashfs-root/usr/lib/python3.6/platform.py", line 169, in libc_ver
    with open(executable, 'rb') as f:
IsADirectoryError: [Errno 21] Is a directory: '/tmp/tmp.yWsn4FtF6H/squashfs-root'

It's quite possible neither of these are representative of general AppImage behavior, in fact I originally came to comment that this seems good to merge and we can improve as we go :).

@tilpner
Copy link
Member Author

tilpner commented Jun 15, 2018

@dtzWill Thanks for testing! I mostly ran the Patchwork, Patchbay, and HexoEditor AppImages (and Subsurface didn't work) with it.

Cutter

This error is because Python uses PATH to determine sys.executable. In our case, it will return an empty string, which causes the current directory to be opened.

This can be fixed by export PATH="$PATH:$PWD/usr/bin" just before executing AppRun.
I don't know if this is the AppImages task, or mine, but since this is a compatibility hack anyway... I'll just set it.

This adds a best-effort hack to run AppImages, which currently don't
work out-of-the-box on NixOS. This is not preferable to using packaged
applications, but may help users if the application they want to run
is not in nixpkgs.

It uses the package list from the Steam chroot, but without Steam
packages.
@tilpner
Copy link
Member Author

tilpner commented Jun 15, 2018

I also switched from extracting to a mktemp dir, to extracting into $XDG_CACHE_HOME/appimage-run/<sha256 of appimage>. Opinions?

@dtzWill
Copy link
Member

dtzWill commented Jun 16, 2018

Sounds good to me.

Also, tried again with Cutter and.. success! \o/

@dtzWill
Copy link
Member

dtzWill commented Jun 23, 2018

Looks good to me, anything left to address?

@tilpner
Copy link
Member Author

tilpner commented Jun 23, 2018

Not from my side, just waiting for someone with the permission to merge :)

@dtzWill dtzWill merged commit 19ef534 into NixOS:master Jun 23, 2018
@grwlf
Copy link
Contributor

grwlf commented Jul 3, 2018

Hi. I have an issue regarding this PR (tested locally by cherry-picking to nixos-18.03). Details are here lutzroeder/netron#120

In short - AppImage application named Netron crashes with "(netron:21909): GLib-GIO-ERROR **: No GSettings schemas are installed on the system" while trying to show OpenFile GTK dialog. Interesting questions are:

  1. Does the application interacts with system GTK or use its private version of the library (maybe via sockets)?
  2. If it does, then how to stop this interaction? Setting XDG_DATA_DIRS or similar variables before running the appimage doesn't seem to work.

Should I open separate Issue for this?

@tilpner tilpner deleted the appimage-run branch July 10, 2018 10:21
@schmittlauch
Copy link
Member

@tilpner Do you plan to add some documentation about running AppImages and packaging best practices (appimage-run vs appimage-tools) to the nixpkgs manual? That'd be great and you seem to be very familiar to this.

@tilpner
Copy link
Member Author

tilpner commented Feb 25, 2019

@schmittlauch There already is (but there could always be more). See https://github.com/NixOS/nixpkgs/blob/master/doc/functions/appimagetools.xml

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/why-does-nix-need-to-wrap-appimages/23042/5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants