Re: 4.9.3 AppImage issue
So to summarise. Your machine-id is in /var/lib/dbus Our dbus library is looking in /usr/local/var/lib/dbus, and also /etc Just checking my local machine (Windows with WSL running Ubuntu 18, not exactly representative), and I appear to have /etc/machine-id,and /var/lib/dbus/machine-id but not /usr/local/lib/dbus. I can check a more realistic machine tomorrow. But looking at the Appimage build, we build dbus from source, and looking at the dbus project code, it looks like the path that is searched is a build time option. makefile.am: .. DDBUS_MACHINE_UUID_FILE=\""$(localstatedir)/lib/dbus/machine-id"\ .. I am not 100% clear where localstatedir comes from, but I think perhaps we want to change the configuration of the dbus build to specify it to be /var instead of /usr/local/var I will poke around some more when I get some time. Paul On Thu, Sep 19, 2019 at 6:26 PM David Tillotson wrote: > > I did try that, and the machine-id file in /var/lib/dbus/ was updated, but > the appimage doesn't use that. Whether this is an inherent appimage issue, or > a local issue is currently unclear. I'll set up fresh Devuan and Debian > installs on VMs when I have the time, and see what that shows. > > David Tillotson > On 19 Sep 2019, at 16:00, Paul Buxton wrote: >> >> So maybe try the dbus-uuidgen --ensure? >> >> On Thu, Sep 19, 2019 at 10:29 AM David Tillotson >> wrote: >>> >>> >>> On Thu, 19 Sep 2019 09:02:36 +0100 >>> Paul Buxton wrote: >>> 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? >>> >>> >>> I should really have grabbed this sooner: >>> dbus[2410]: D-Bus library appears to be incorrectly set up: see the >>> manual page for dbus-uuidgen to correct this issue. (Failed to open >>> "/usr/local/var/lib/dbus/machine-id": No such file or directory; Failed >>> to open "/etc/machine-id": No such file or >>> directory) >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libdbus-1.so.3(_dbus_print_backtrace+0x1f) >>> [0x7f7e1c495721] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libdbus-1.so.3(_dbus_abort+0xd) >>> [0x7f7e1c48ff42] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libdbus-1.so.3(_dbus_warn_check_failed+0xf2) >>> [0x7f7e1c47bb52] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libdbus-1.so.3(dbus_get_local_machine_id+0x78) >>> [0x7f7e1c45aeb9] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libQt5DBus.so.5(_ZN15QDBusConnection14localMachineIdEv+0xe) >>> [0x7f7e23f7c0ae] >>> /tmp/.mount_SubsurOd39gI/usr/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so(+0x8671) >>> [0x7f7e120af671] >>> /tmp/.mount_SubsurOd39gI/usr/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so(+0xcd68) >>> [0x7f7e120b3d68] >>> /tmp/.mount_SubsurOd39gI/usr/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so(+0xd5a3) >>> [0x7f7e120b45a3] >>> /tmp/.mount_SubsurOd39gI/usr/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so(+0xdc21) >>> [0x7f7e120b4c21] >>> /tmp/.mount_SubsurOd39gI/usr/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so(+0x12e65) >>> [0x7f7e120b9e65] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libQt5Gui.so.5(_ZN28QPlatformInputContextFactory6createERK7QString+0x16e) >>> [0x7f7e2b423f9e] >>> /tmp/.mount_SubsurOd39gI/usr/plugins/platforms/../../lib/libQt5XcbQpa.so.5(_ZN15QXcbIntegration10initializeEv+0x2d) >>> [0x7f7e13ca407d] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libQt5Gui.so.5(_ZN22QGuiApplicationPrivate20eventDispatcherReadyEv+0x19) >>> [0x7f7e2b4358c9] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libQt5Core.so.5(_ZN23QCoreApplicationPrivate4initEv+0x9be) >>> [0x7f7e2a08880e] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libQt5Gui.so.5(_ZN22QGuiApplicationPrivate4initEv+0x1c) >>> [0x7f7e2b43723c] >>> /tmp/.mount_SubsurOd39gI/usr/bin/../lib/libQt5Widgets.so.5(_ZN19QApplicationPrivate4initEv+0x9) >>> [0x7f7e2c336489] ./Subsurface-4.9.3-x86_64.AppImage(main+0x9c) >>> [0x4ce69c] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) >>> [0x7f7e291f22e1] ./Subsurface-4.9.3-x86_64.AppImage() [0x4d3a2d] Aborted >> >> ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 AppImage issue
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 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 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 wrote:
>>>
>>>
>>> On Wed, 18 Sep 2019 20:03:00 +0100
>>> Paul Buxton 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
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@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>>
>>>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 AppImage issue
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, 07:59, at 07:59, Paul Buxton
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
>wrote:
>>
>> On Wed, 18 Sep 2019 20:03:00 +0100
>> Paul Buxton 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
>> > 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@subsurface-divelog.org
>> > >
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 AppImage issue
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 wrote:
>
> On Wed, 18 Sep 2019 20:03:00 +0100
> Paul Buxton 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
> > 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@subsurface-divelog.org
> > > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
