Add AppImage support (and Travis)

[KurtPfeifle]

Reference: https://appimage.org/

You should add support for an ippsample (or maybe just "ipp") AppImage that provides a "universal" Linux binary that can be built automagically via GitHub and Travis.

In addition to the usual AppImage.yaml stuff, you'll probalby want a configure option and stuff in the makefiles to have a configurable prefix so that the AppImage commands can be "ipp.server", "ipp.tool", etc. rather than "ipp.ippserver", etc.

:-)

[KurtPfeifle]

As you can see, I cloned your issue #31 and modified it a bit :-)

In extension to what the AppImage website states about supporting "desktop applications", it also works perfectly well with command line tools.

I talked to the main developer of AppImage, @probono a bit on IRC, and he created a fast proof-of-concept ippsample-AppImage which worked flawlessly for me in a few quick tests. (ipptransform isn't yet included.)

It worked so well even, that probono for the first time became aware that his HP M276n did support PDF as an input job format:

 pdf-versions-supported (1setOf keyword) = adobe-1.2,adobe-1.3,adobe-1.4,adobe-1.5,adobe-1.6,adobe-1.7,iso-19005-1_2005,iso-32000-1_2008

Currently it works like this (on a Debian Stretch system):

 cd $Downloads
 wget https://transfer.sh/X0mFc/ippsample-git.4fbfa3f-x86_64.AppImage
 chmod +x ippsample-git.4fbfa3f-x86_64.AppImage
 ln -sf ${Downloads}/ippsample-git.4fbfa3f-x86_64.AppImage ${HOME}/bin/ippfind
 ln -sf ${Downloads}/ippsample-git.4fbfa3f-x86_64.AppImage ${HOME}/bin/ipptool
 ln -sf ${Downloads}/ippsample-git.4fbfa3f-x86_64.AppImage ${HOME}/bin/ippproxy
 ln -sf ${Downloads}/ippsample-git.4fbfa3f-x86_64.AppImage ${HOME}/bin/ippserver

Then (if $HOME/bin isn't in your path yet):

$HOME/bin/ippserver -vv -p 9631 "Testing the AppImage"

Using default configuration with a single printer.
Using default data directory "/tmp/ippserver.6337".
Using default spool directory "/tmp/ippserver.6337".
Ignore Avahi state 2.
Using default listeners for lenjessie2.fritz.box:9999.
serverCreatePrinter(resource="/ipp/print", name="Testing the AppImage", location="", make="Test", model="Printer", icon="(null)", docformats="application/pdf,image/jpeg,image/pwg-raster", ppm=0, ppm_color=0, duplex=0, pin=0, attrs=(nil), command="(null)", device_uri="(null)", proxy_user="(null)", strings=(nil))
Using ppm=0
Using ppm_color=0
[Printer Testing the AppImage] printer-more-info="https://lenjessie2.fritz.box:9999/ipp/print"
[Printer Testing the AppImage] printer-supply-info-uri="https://lenjessie2.fritz.box:9999/ipp/print/supplies"
[Printer Testing the AppImage] printer-uri="ipp://lenjessie2.fritz.box:9999/ipp/print"
[Printer Testing the AppImage] version=2.0
[....]
[....]
[Printer Testing the AppImage] pwg-raster-document-type-supported (1setOf keyword) black_1,cmyk_8,sgray_8,srgb_8,srgb_16
[Printer Testing the AppImage] reference-uri-schemes-supported (1setOf uriScheme) file,ftp,http,https
[Printer Testing the AppImage] sides-default (keyword) one-sided
[Printer Testing the AppImage] sides-supported (keyword) one-sided
[Printer Testing the AppImage] uri-authentication-supported (keyword) none
[Printer Testing the AppImage] uri-security-supported (keyword) tls
[Printer Testing the AppImage] which-jobs-supported (1setOf keyword) completed,not-completed,aborted,all,canceled,pending,pending-held,processing,processing-stopped
serverRun: 1 printers configured.
serverRun: 2 listeners configured.

So no more waiting for Snap to work, AppImage is already here! (I'll test it on some other systems than Debian Stretch, as soon as I have them available....)

I'm sure probono will send you a pull request soon enough :-)

[michaelrsweet]

[master 1e03dd8] Add --with-name-prefix configure option (default "ipp") to control the names of the installed applications, and then set the prefix for snaps to "" so that command names are ipp.find, ipp.server, etc.

[michaelrsweet]

Will consider supporting AppImage; the snaps support actually seems to be working really well on the "supported" platforms, and we also have people using docker.

Ultimately I would prefer that we support one or two of these mechanisms and not 1000, as our resources for this project are very limited (just Smith and I at the moment...)

[KurtPfeifle]

"Will consider supporting AppImage;"

Thanks -- this will be really useful. There's no simpler and easier method for the user. Everything is just one file, and it "just works".

The reason why my above symlinks were required first is because this AppImage contains not just one, but multiple binaries. If the AppImage is called via a symlink, it will execute that one embedded binary which matches the symlink name (ARGV[0]) it is called as. This may make it for some users to much hassle.

However, it would be no problem to build an AppImage for each of the command line tools, and one could also get rid of the "ugly" full name and the .AppImage extension.

"the snaps support actually seems to be working really well on the "supported" platforms,"

I can confirm that, because this afternoon for the first time I installed the required packages on my Debian Stretch: snapd, snap-confine and libsnappy1. After executing sudo snap install --edge --devmode ipp and fiddling a bit with the snap command line syntax I was able to successfully run a few tests.

Compared to the AppImage method I find it snappy slightly more complex. I've to remember to run "snap run ipp.tool --ls" instead of the standard "ipp.tool --ls" (as with AppImage).

The beauty with AppImage is that there is zero preconditions to install (it "just runs" on supported systems), whereas Snappy requires the core framework (or however they call it) to be present on the user system. And hasn't the snap package to be retrieved thru Canonical's store? (I don't know; maybe I err.) AppImage files however can be hosted anywhere; you just download and run them (after doing a chmod +x).

About the scope of "supported systems" I've not yet investigated. My gut feeling is that AppImage will currently work on a bigger number of OS systems than Snappy does.

"Ultimately I would prefer that we support one or two of these mechanisms and not 1000"

I understand that. Even though the "1000" may seem a bit overdone, beyond the mentioned Docker there also is the here so far unmentioned FlatPak. This gives four (I may be unaware of some more possibilities), which probably is already too much to support.

"our resources for this project are very limited (just Smith and I at the moment...)"

I'm sure that once the auto-building bits are enabled there will be not many extra resources required to keep it running. But the benefit will be huge, giving everybody with stakes in printing and in IPP a really easy access to the ISTO PWG tools.

---

_{Oh, and did you know you can now even download an AppImage of PowerShell 6.0.beta-something created by Microsoft themselves, running on Debian and many other Linux systems? See here: https://github.com/PowerShell/PowerShell/releases . Same thing: just download 1 file (admittedly: 76 MByte), make it executable, run it.}

[michaelrsweet]

Closing this issue for now; Travis CI is a dead-end, but I'm still open to AppImage and other packaging mechanisms that can be integrated with Github Actions...