offer fat binaries for all supported platforms

[ThomasWaldmann]

It would be nice to have some (semi-)automated way to offer vorta (and borg) as pyinstaller fat binary for vorta releases:

• macOS (see also Packaged version doesn't start on old versions of macOS #79)
• Linux
• later: FreeBSD (see also port to freebsd #125)

Could use similar automation as seen in borg's Vagrantfile.

If easy enough, it could be done for every release or else just now and then.

[ThomasWaldmann]

btw, recently wanted to install vorta for an ubuntu user.

after preparing virtual env etc. wondered why I can't pip install vorta and then noticed I have only python 3.5 on ubuntu xenial (similar problem on debian stretch btw).

so, a fat linux binary with everything would really help for such cases.

[m3nu]

It's on my list. Really. :-)

[Hofer-Julian]

I recently read this tutorial: https://www.mfitzp.com/article/packaging-pyqt5-apps-with-fbs/

Might this be interesting for vorta?

[m3nu]

We already use Pyinstaller, which this project wraps. They just solve a few other problems on top of it. Some are already solved in Vorta (finding asset files, making installers), some aren't that relevant (shipping different files for each OS). Maybe these guys solve them better, but they also impose their folder structure on the project, which could be a bad thing.

Still good to know it exists. May be useful for a green field project that needs installers for many OSs.

[Hofer-Julian]

I see :)

[m3nu]

Added the first Linux binary. It got fairly large. 2x of macOS. UPX or zipping didn't make much difference. I guess there are more libraries included.

Would be helpful is someone could test it on different Linux platforms, like Arch or Debian.

[ThomasWaldmann]

I've seen a similar size difference for borg itself, so seems to be normal.

[ThomasWaldmann]

debian stretch (whonix, to be precise):

$ ./vorta-linux64 
[2469] Error loading Python lib '/tmp/_MEIMBkOkG/libpython3.6m.so.1.0': dlopen:
   /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found
   (required by /tmp/_MEIMBkOkG/libpython3.6m.so.1.0)

Seems you need an older build platform. The borg 1.1.x binaries are still built on wheezy (which is out of support though). For borg 1.2 I guess we'll go to Debian stretch.

[ThomasWaldmann]

i also get a ton of issues on fedora-29, but not sure if they are caused by vorta or if just my VM is broken somehow.

[m3nu]

Thanks for testing. Will try some older VMs then.

[ThomasWaldmann]

about the huge size of the fat binaries: do you just include the borg fat binary? guess that means that a lot of stuff gets into the vorta fat binary twice (once bundled into the inner borg binary, once bundled again for the outer vorta binary). this could be optimized in future.

[m3nu]

True. Currently the Borg bin is embedded as well. (I actually didn't replace the macOS bin, which could explain some errors. Let me fix that.)

Having only 1 Python bin, etc for everything would be nice. I'm just not sure which borg command would be used in that case.

[ThomasWaldmann]

After thinking about it: maybe it would be best not to bundle borg into the vorta fat binary at all.

While vorta offers a good GUI for many functions, there are likely quite some cases for which the user would still need to use the command line. But we don't get a callable borg if it just lives inside the vorta fat binary.

So easiest would be if users either install borg from their dist or grab the borg fat binary separately and put it somewhere into the PATH.

[m3nu]

Compared to the total size, the Borg binary isn't too bad. 15MB out of 80MB. Could still be useful as fallback and for non-tech users.

(Also updated the Linux bin just now. Has the correct borg bin now.)

[logix2]

The Vorta Linux binary works for me, but not the automatically start at login option. When I enable that, Vorta crashes:

Traceback (most recent call last):
  File "vorta/views/misc_tab.py", line 29, in <lambda>
  File "vorta/views/misc_tab.py", line 38, in save_setting
  File "vorta/autostart.py", line 49, in open_app_at_startup
  File "vorta/autostart.py", line 70, in get_setuptools_script_dir
  File "distutils/cmd.py", line 107, in ensure_finalized
  File "setuptools/command/install.py", line 38, in finalize_options
  File "distutils/command/install.py", line 390, in finalize_options
  File "distutils/cmd.py", line 286, in set_undefined_options
  File "distutils/dist.py", line 846, in get_command_obj
  File "setuptools/dist.py", line 638, in get_command_class
  File "distutils/dist.py", line 832, in get_command_class
distutils.errors.DistutilsModuleError: invalid command 'build'
Aborted (core dumped)

The options stays enabled when I relaunch Vorta, but it doesn't automatically start on login (using Ubuntu 18.10/Gnome Shell).

[m3nu]

Autostart on Linux is a fairly new feature. I guess it fails in this line:

File "vorta/autostart.py", line 70, in get_setuptools_script_dir

@Hofer-Julian, maybe autostart can just run the command from the standard PATH env instead of guessing where it is? What happens if the user moves it? Should be a common problem.

[Hofer-Julian]

Autostart on Linux is a fairly new feature. I guess it fails in this line:

File "vorta/autostart.py", line 70, in get_setuptools_script_dir

@Hofer-Julian, maybe autostart can just run the command from the standard PATH env instead of guessing where it is? What happens if the user moves it? Should be a common problem.

I just wanted to start a discussion if that might be the better solution.
Autostart wouldn't work anymore if vorta would be installed in a virtual environment (which is not in the PATH) but I guess that wouldn't be that bad

[m3nu]

Took another shot at the fat bin challenge by combining our Travis file with a certain project's Vagrantfile. This compiles Vorta on Debian Jessie (oldstable). I tested it on Ubuntu 18.4 and it worked there as well.

Some more testing would be good. It's not going into the background for now because those settings are tailored to macOS. Will need some small changes.

https://files.qmax.us/vorta-linux64.gz

[Hofer-Julian]

The binary does not work under Fedora 29. I get the following error message (the first line is normal, I get it always under Wayland)

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
GLib-GIO-Message: 19:38:21.905: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

(vorta-linux64:7709): GdkPixbuf-WARNING **: 19:38:21.941: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.

[Hofer-Julian]

Maybe, if the fat-binary-apporach is that problematic, we can look into Appimage until we have a working Flatpak.

[m3nu]

I guess it needs to be compiled for each OS family: Debian/Ubuntu, Fedora/CentOS/RedHat.

I'll try with CentOS next and we'll see if it works on Fedora. Will also look if Appimage or Flatpak is appropriate.

[m3nu]

Some more options:

• https://www.riverbankcomputing.com/static/Docs/pyqtdeploy/introduction.html (complicated, needs compiling of libs, by the PyQt folks)
• https://github.com/probonopd/linuxdeployqt/ (by the creators of Qt, also outputs AppImages)

[nah-ko]

Hello,
Referring to #79 issue, I've just install Vorta on my old Macbook running under 10.12.6 after uninstalling DMG package. I've run pip install vorta but then PyQT5 version 5.14 were installed instead of 5.11 as mentionned in Vagrant file (pip install pyqt5==5.11.3). So, be sure to install this version before installing vorta.

Now it works, even if I must launch it in foreground...

[samuel-w]

I have created this script to generate a Vorta appimages. The result is 100MB large though.
https://gist.github.com/samuel-w/4e3d1f59896f87f4f4b35c330879b6e5

[Hofer-Julian]

Not sure if we want to offer appimages.
In my experience they are far less portable than one might hope for.

[samuel-w]

Yeah, looking into it I'll have to bundle a lot of libraries for it to be truly portable. We should stick with flatpak and pip for Linux for now.