4.9.3 AppImage issue

[Paul Buxton]

Hmm, when googling stuff I did come across an appimage script that
looked to be modifying a path in a packaged dbus library..
https://fossies.org/diffs/digikam/6.0.0_vs_6.1.0/project/bundles/appimage/04-build-appimage.sh-diff.html
Do you know what library is actually failing to find the file?

On Thu, Sep 19, 2019 at 8:47 AM David Tillotson <david at acmelabs.co.uk> wrote:
>
> Deleting my manually created file, and re-running the appimage, it seems to be searching /usr/local/var/lib/dbus/ and /etc/, so doesn't see the existing one in /var/lib/dbus/
> Creating a symlink /usr/local/var/lib/dbus -> /var/lib/dbus works (which may be more "correct" than my manual file). Looks like this is an odd path issue somewhere, most likely local to my system. I'll do some more testing, and see whether this may be worth documenting.
>
> David Tillotson
> On 19 Sep 2019, at 07:59, Paul Buxton <paulbuxton.mail at googlemail.com> wrote:
>>
>> So, I think I have a better handle on Appimage. It isn't a container
>> in the same way as chroot/docker. So we do not package up or mirror
>> any system files, it basically contains the libraries for the
>> application and preprends it's folder containing these to the
>> LD_LIBRARY_PATH. A side effect of this is that if we depend on a
>> library that isn't included but happens to be on your system we will
>> continue on quite happily.
>> I don't think we can realistically actually add the file in question
>> to the Appimage as it isn't something we can (or should) be packaging
>> up.
>>
>> From this thread
>> https://lists.dyne.org/lurker/message/20190308.124740.2b7329de.en.html
>> it looks like Devuan (at least back in March) doesn't supply
>> /etc/machine-id as it normally is created by systemd at installation
>> time. But if I am reading correctly dbus supplies
>> /var/lib/dbus/machine-id which will often be a symbolic link to the
>> /etc one.
>>
>> What happens if you run dbus-uuidgen --get (after removing the file
>> you created).
>> Is it possible something was squiffy in your dbus installation?
>> The manpage for dbus-uuidgen suggests it is normally called in the
>> post installation process.
>> If you don't have one, then perhaps try running dbus-uuidgen --ensure
>>
>>
>> Paul
>>
>> On Wed, Sep 18, 2019 at 9:14 PM David Tillotson <david at acmelabs.co.uk> wrote:
>>>
>>>
>>>  On Wed, 18 Sep 2019 20:03:00 +0100
>>>  Paul Buxton <paulbuxton.mail at googlemail.com> wrote:
>>>
>>>>  Hmm, this looks pertinent
>>>>  https://wiki.debian.org/MachineId
>>>
>>>
>>>  Interesting article. Reading that, I'm now even more puzzled as to what
>>>  this is for. Every claimed use is already covered by other mechanisms
>>>  as far as I know.
>>>
>>>>  Can I ask when you added the file, was that in your local system, or
>>>>  did you somehow insert it into the appimage? My guess is the former...
>>>
>>>
>>>  You are right with that guess - not sure how it would be added to the
>>>  appimage!
>>>
>>>>  The end of that article assumes that chroot/container environments
>>>>  would populate the machine id from the host system into the container.
>>>>  I confess I am not 100% clear on how Appimage works, but I suspect it
>>>>  is combining the folders in the Appimage mount with the host system
>>>>  folders, and as your system doesn't use systemd this file doesn't
>>>>  exist.
>>>
>>>
>>>  That does seem to be what is happening - creating a valid(ish) file
>>>  works, so whatever is using it doesn't care what is in the file.
>>>  Changing the file to a different one (32 1s) had no effect.
>>>
>>>>  I will try and understand a bit more about how appimage works and see
>>>>  if I can suggest a proper solution unless someone who knows better can
>>>>  fix it first. :-)
>>>
>>>
>>>  I would guess that adding a file to the appimage would work, if I could
>>>  figure out how. I'm happy to test any attempted fixes in the meantime.
>>>
>>>>  On Wed, Sep 18, 2019 at 9:05 AM David Tillotson
>>>>  <david at acmelabs.co.uk> wrote:
>>>>>
>>>>>
>>>>>  I have discovered an issue with the layest AppImage, that seems to
>>>>>  be the result of an assumption by the included systemd components.
>>>>>
>>>>>  On my Devuan system, I was unable to launch the AppImage, and on
>>>>>  checking found that it was due to a missing file
>>>>>  ("/usr/local/var/lib/dbus/system-id" or "/etc/system-id"). An empty
>>>>>  file isn't sufficient, as dbus expects a 32 char hex string, so I
>>>>>  just created a random one, which worked.
>>>>>
>>>>>  Hopefully this is just a flaw in the AppImage build, and not
>>>>>  another step along the path from GNU/Linux to Systemd/GNU/Linux! ;-)
>>>>>
>>>>>  David Tillotson
>>>>> ________________________________
>>>>>
>>>>>  subsurface mailing list
>>>>>  subsurface at subsurface-divelog.org
>>>>>  http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>>
>>>