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

[Lutz Vieweg]

On 08/01/2017 06:18 AM, Dirk Hohndel wrote:
>> 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?

I packaged just the Arch-Linux provided subsurface binaries, as in:
https://www.archlinux.org/packages/community/x86_64/subsurface/
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/subsurface
- that's also where the numbering "4.6.4-2" comes from.

Of course, the same could be done quickly for any other version,
provided it runs fine on some source system.

> I wonder about USB devices like the Cobalt... will they need extra support
> as well?

"makeaoi" reports if the "strace" it does while running
"makeaoi trace somedir subsurface" contains ioctl()s not
yet supported.

Looking at
https://github.com/libusb/libusb/blob/73d15d1f8eee372e0609d072f3df705f7de18214/libusb/os/linux_usbfs.h#L145
I would assume that usage of libusb does imply using additional
ioctl()s, but as long as it is documented what parameters/structures
they take, it is not difficult to add them to the range of ioctls()
supported by unionfs-fuse.

> And then of course that whole BLE mess :-/

I may later be able to lend a BLE-talking "Perdix" for trying this.
(Of course we would know sooner if somebody owning such a device
would try. :-) )

>> - 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?

I did not notice any visual difference. There might be "tearing" when
quickly moving the globe in a large-sized "marble" display, but that
seems of minor cosmetic relevance.

>> 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...

Ah, I see, in https://subsurface-divelog.org/downloads/test/

I will try to compare both AppImage versions (but can still only try the D9).

Regards,

Lutz Vieweg