Prusaslicer: Provide Slic3r AppImage for Linux

[probonopd]

Version

1.31.6-prusa3d

Operating system type + version

ubuntu-16.04-desktop-amd64.iso

Behavior

Slic3r should be distributed as a self-contained bundle that does not require the user to install additional libraries from the distribution using the package manager. An AppImage could do this job well.

_Is this a new feature request?_ Yes

I have generated a proof-of-concept AppImage at https://bintray.com/probono/AppImages/Slic3r/_latestVersion#files based on the official binaries provided on GitHub Releases. I expect some fine-tuning to be necessary to make this work with most common desktop Linux distributions. To use, simply download, set the executable bit, and run. No installation, no root rights, no package manager needed.

Known to work on

• ubuntu-16.04-desktop-amd64.iso
• maui-1-64bit.iso

Known _not_ to work on

• CentOS-7-x86_64-LiveGNOME-1511.iso (libstdc++.so.6: version `CXXABI_1.3.8' not found (required by lib/site_perl/5.22.0/auto/Slic3r/XS/XS.so) - this means that the official binaries provided on GitHub Releases have been compiled on a build system newer than CentOS 7, and hence it is not working
• ubuntu-14.04.1-desktop-amd64.iso for the same reason

It would be good if the official binaries provided on GitHub Releases could be compiled on debian oldstable, Ubuntu trusty or something like that. It would increase compatibility with older target systems (Linux distributions) a lot.

[CReimer]

Why AppImage? There are at least three different approaches to some kind of universal Linux package. So why should AppImage be prefered?

It is not the developers' responsibility to provide users with packages for every Linux distribution. Just provide source code or a precompiled Debian package.
Just because some people think they have to adopt their already flawed application distribution technique they use for Windows onto Linux doesn't make the whole concept a good idea.

Debian is usually not my favourite distribution. It took them forever to finally adopt systemd. But when people come up with such fundamentally flawed ideas I'm happy there is a conservative distribution like Debian which has enough influence on the whole Linux community to prevent such a nonsense from spreading.

[probonopd]

Why AppImage?

To have upstream-provided and tested "known good" builds that run on most Linux distributions without having to mess around with installing runtimes or stuff. Just download, make executable, run.

It is not the developers' responsibility to provide users with packages for every Linux distribution.

With this mindset, desktop Linux will always be a second-rate desktop operating system behind macOS and Windows, where users can just go to the original application author's website, and download a _known good_ version right from the original author.

[dsaiko]

I strongly support the idea and voting for this feature.
In general it may open the doors to commercial software on Linux.

[bubnikv]

I will look into the appimage probably at the time of the next release of
the Slic3r Prusa Edition. I thing though, that this way of installation
packaging, however functional it may be, is about the worst method to
distribute binaries in terms of network load, hard drive and a run time
memory. OSX works somehow different, at least the bundled libraries are
linked statically, so only pieces of libraries which are called are being
linked. The appimage packs half the Linux distribution "just for case". By
the way, our Linux binary package does something similar, it packs most of
the dependencies. Maybe the biggest advantage of the appimage is the
listing of the core shared libraries, which are supposed to already be
available on the target system.

On Dec 31, 2016 5:42 PM, "dsaiko" [e-mail] wrote:

I strongly support this idea and voting for this feature.
In general it may open the doors to commercial software on Linux.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Slic3r/issues/78#issuecomment-269872700, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFj5I4tEY1yGgNzaq4DjFnUMLIA6T2ERks5rNoXZgaJpZM4LXMqa
.

[probonopd]

@bubnikv thanks for looking into it. Cura is provided as an AppImage already. You are free to choose what you put inside the AppImage - you could do something similar to what is done on macOS, namely use specifically-compiled executables and libraries as ingredients that only have the dependencies that are actually needed.

[bubnikv]

It is near to impossible to link the Perl stuff statically. The same most
likely applies to Python therefore cure. I already spent some time with
that idea. Just to give you the perspective, it took me about 50 working
hours to compile Perl and all the dependencies on Windows with MS compiler
suite. I believe my time is better spent by implementing software features
and fixing bugs and slowly getting rid of the Perl.

On Dec 31, 2016 7:15 PM, "probonopd" [e-mail] wrote:

@bubnikv https://github.com/bubnikv thanks for looking into it. Cura is
provided as an AppImage already. You are free to choose what you put inside
the AppImage - you could do something similar to what is done on macOS,
namely use specifically-compiled executables and libraries as ingredients
that only have the dependencies that are actually needed.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Slic3r/issues/78#issuecomment-269876415, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFj5I-Py4xjoRIXgp2J6W0k8rg6DKMtTks5rNpulgaJpZM4LXMqa
.

[bubnikv]

Well, I looked into the wiki and I think I need some volunteer help to make it happen.

Skimming through the wiki
https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages

The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on

What are the base dependencies? This is not listed anywhere and it has to be found out by a time demanding trial and error. Sorry, I don't currently have time for that, but a volunteer could help.

To ensure that the AppImage runs on the intended base systems, it should be thoroughly tested on each of them. The following testing procedure is both efficient and effective: Get the previous version of Ubuntu, Fedora, and openSUSE Live CDs and test your AppImage there.

The same applies here. I don't currently have time to go trough a plethora of distributions, install them into a virtual box and find out the missing dependencies.

I already prepared a standalone linux installation, built on a Debian 3.16.7 64bit and tested on the ArchLinux, Ubuntu and Fedora.

https://github.com/prusa3d/Slic3r/releases
https://github.com/prusa3d/Slic3r/releases/download/version_1.31.6/Slic3r-1.31.6-prusa3d-linux64-full-201611202210.tar.bz2

To make the AppImage, I am nearly there as long as my binary package contains all the dependencies required on all the target Linux systems. What are the target linux distros and their versions is unknown to me and it is left to the volunteer to list them out and test on them.

I think a volunteer may even try to reorganize my binary package into the AppImage format and try to build the AppImage.

Thanks for a help.

[probonopd]

What are the base dependencies? This is not listed anywhere and it has to be found out by a time demanding trial and error. Sorry, I don't currently have time for that, but a volunteer could help.

The person who makes the AppImage can decide which target systems (Linux distributions) they want to support. As a general rule of thumb, I think Ubuntu LTS-1 and any debian, Fedora, openSUSE version later than that is a reasonable set. In practice, I build on Ubuntu trusty and bundle everything but a defined set of packages and libraries.

I don't currently have time to go trough a plethora of distributions, install them into a virtual box and find out the missing dependencies.

Users and I can help with that; I use a hard disk full of Live ISOs from all major distributions and the testappimage script for this purpose. Makes it really quick to test. It loop-mounts the Live ISO and chroots into it.

I already prepared a standalone linux installation, built on a Debian 3.16.7 64bit and tested on the ArchLinux, Ubuntu and Fedora.

That makes it a whole lot easier, then we can use this as ingredients for the AppImage. Should greatly reduce the amount of work if you already have this in place.

To make the AppImage, I am nearly there as long as my binary package contains all the dependencies required on all the target Linux systems.

Yes. AppImage does no secret magic there -- it is essentially just a self-mounting filesystem image that executes the payload.

I think a volunteer may even try to reorganize my binary package into the AppImage format and try to build the AppImage.

In fact this is exactly what I have done:
https://github.com/probonopd/AppImages/blob/master/recipes/meta/Slic3r.yml

The resulting AppImage can be tested here, let me know if something is wrong:
https://bintray.com/probono/AppImages/Slic3r#files

Thanks!

[bubnikv]

Thanks for your effort.

I tested your appimage on ArchLinux, Ubuntu 16.04 and Fedora 24. On ArchLinux and Ubuntu it works, but on Fedora 24 I am getting the following error message:

Would you please help fixing this issue?

My understanding is, I just need to integrate the packing process using your Slic3r.yml recipe to produce the AppImage, right? If so, then I shall integrate it into our build system.

Thanks again,
Vojtech

[probonopd]

Hi Vojtech, thanks for giving this a try. I will need to investigate this _XEatDataWords issue. Most likely we need to bundle a library more or one less.

Yes, it is a matter of running something like

wget https://github.com/probonopd/AppImages/raw/master/recipes/meta/Recipe
bash Recipe Slic3r.yml

on an Ubuntu or debian system (e.g., Travis CI), and the AppImage will be generated.

[lordofhyphens]

As of https://github.com/alexrj/Slic3r/commit/d7f3393c262ed53e475764497a76e2c0ea90959a upstream Slic3r sticks all of its dependencies in its ./local-lib dir. This works for Windows and OSX (and should work for Linux distros), permitting use of PAR::Packer archives with less headache.

This means that upstream Slic3r no longer needs root to install from source (so long as cpanm and local::lib are present, which can be from a package manager), and shouldn't trample an existing Perl install.

[bubnikv]

@probonopd Would you please help me with the format of the "VERSION" file? I see you are converting dashes to dots, but I was not able to find any reference to what format is allowed in the VERSION and what is it used for. Thanks.

[probonopd]

The VERSION file does currently _not_ end up in the AppImage, any string contained therein is currently only used by the Recipe script to determine the version part of the AppImage filename. As per convention, AppImage files are named AppName-version-x86_64.AppImage, with dashes as the separators between AppName, Version, and architecture. The "version" part of this filename is taken from the VERSION file, if it exists. Hope this makes it clear.

[bubnikv]

@probonopd thank you, that is clear. I have the AppImage integrated into our build system, so the the next official binary build will include the AppImage.

Here is the result for the current master. Please let me know whether it is fine, or whether I shall change something.
Slic3r-1.33.3.4-prusa3d-linux64-full-gce8973b-201702132057.AppImage.zip

[probonopd]

Thank you @bubnikv. Quickly ran it on netrunner-17-64bit.iso, runs fine here. When you distribute the AppImages, please don't put them into a zip or other archive (I assume this was just done in order to be able to attach it to this GitHub Issue).

[bubnikv]

Yes, I only zipped it for the GitHub to swallow. Thanks for all our Linux
users for your help.

On Feb 13, 2017 10:43 PM, "probonopd" [e-mail] wrote:

Thank you @bubnikv https://github.com/bubnikv. Quickly ran it on
netrunner-17-64bit.iso, runs fine here. When you distribute the
AppImages, please don't put them into a zip or other archive (I assume this
was just done in order to be able to attach it to this GitHub Issue).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Slic3r/issues/78#issuecomment-279531986, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFj5I8kGFVP_XKvtoHiFVFIGztHgAw6bks5rcM5mgaJpZM4LXMqa
.

[bubnikv]

Done, closing.