> On Jul 30, 2017, at 2:44 PM, Lutz Vieweg <l...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface