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