Working Proof of Concept: "AppImage with everything", prepared on Arch, can download from D9 on CentOS

Dirk Hohndel dirk at hohndel.org
Mon Jul 31 21:18:04 PDT 2017


> On Jul 30, 2017, at 2:44 PM, Lutz Vieweg <lvml at 5t9.de> wrote:
> 
> Hi,
> 
> this weekend I followed up on my attempts to enhance "makeaoi" such that it
> can package applications even if they need to access device files.
> 
> And I succeeeded in that I was now able to prepare a Subsurface AppImage
> on an Arch Linux installation that runs on at least CentOS and is able
> to download dives from a Suunto D9 there. You can download this
> Proof-of-Concept AppImage at:
> 
> https://transfer.sh/2tLny/subsurface-4.6.4-2-x86_64.AppImage

Really cool.
Is that a stock 4.6.4? What's the version number scheme you use?

> (BTW: Tunneling ioctl()s to device files wasn't the largest part of the
> necessary enhancements - I also had to write poll() support for
> unionfs-fuse, which was a pain since the FUSE documentation on how
> to implement poll() is extremely terse/confusing/incomplete.)
> 
> Remember you can unpack AppImages with "--appimage-extract", this
> allows for faster startup, you can look into the "packlist.txt" and
> scripts if you like, and also you can invoke "extractdirectory/dctool"
> which I also packed into this image, if you just want to test
> dive computer transfers.
> 
> Caveats: So far, I could only test accesses to a Suunto D9. It is
> reasonable to assume that other DCs conncted to serial (USB) ports
> should work as well.
> I could not test Bluetooth connected DCs, as I do not have such at
> hand. It is not unlikely that connecting to such requires additional
> ioctl()s to be tunneled, this would need to be added to the big switch at
> https://github.com/lvml/unionfs-fuse/blob/fake_dev/src/fuse_ops.c#L338

I wonder about USB devices like the Cobalt... will they need extra support
as well? And then of course that whole BLE mess :-/

> Notice that Qt5 (unrelated to packaging) seems to have two interesting habits:
> 
> - For unknown reasons Qt5 performs an open() on any executable it can
>  find in $PATH - this means a "makeaoi trace directory subsurface"
>  will leave the names of all those executables in "files.txt" -
>  I of course removed them for the "packlist.txt"
> 
> - Qt5 seems to try using all kinds of modern X visuals and direct
>  rendering mechanisms, before it falls back to using plain old X11,
>  which is more than enough performance-wise for subsurface.
>  Thus I did exclude all the fancy GPU-dependent DRI modules from
>  the AppImage, they are not really needed and would probably bring
>  a lot of compatibility issues (some even use completely undocumented
>  ioctl).

Interesting. Does that have any impact on the visual experience of what
is actually rendered on screen?

> Of course, manually prepared AppImages, built on "older operating systems"
> might still be the better / smaller / more compatible(?) solution, I just
> thought that since it seems to be a tedious and problematic task at the
> moment for the Subsurface maintainers to create more recent AppImages,
> I should give the "AppImage with everything" idea a try, since it is really
> not much work to create or update such images once a working executable
> is available on one machine.

I have managed to fix a couple of the bugs with the current AppImage
creation and have a current 4.6.4.675 image up that I hope people will
test...

/D


More information about the subsurface mailing list