Bug#1032468: file-roller: does not work - no error messages except on stderr (org.freedesktop.DBus.Error.ServiceUnknown)

[Simon McVittie]

Control: severity -1 important
Control: tags -1 + moreinfo unreproducible

On Tue, 07 Mar 2023 at 17:00:57 +0100, Vincent Lefevre wrote:
> Justification: renders package unusable

It is not the case that file-roller is unusable. There must be something
specific to the system where you reproduced this (and possibly other
systems) that is not the same as in the environment where I tested.

I tried to reproduce this in a virtual machine. In case the problem was
the absence of GNOME, I didn't use GNOME, and in case the problem was
a missing dependency, I didn't install Recommends.

The base VM was the output of autopkgtest-build-qemu(1) for bookworm.
This is not *completely* minimal: it has systemd-logind, among other
things.

For the test environment, I installed:

* wget, with Recommends (to download the test file)
* firefox-esr, file-roller, openbox, xdm and xorg, without Recommends

and then rebooted and logged in. In an xterm in the openbox environment,
after using wget to download the test file you named:

`file-roller Math-MPFR-4.25.tar.gz` works as expected for me.

`firefox-esr ./Math-MPFR-4.25.tar.gz`, followed by choosing
"Archive Manager" to handle the file, also works as expected for me.

> merged-usr: no

This might possibly be relevant? Non-merged /usr is no longer a supported
configuration for bookworm, except as a transitional state while upgrading
from bullseye to bookworm.

On Mon, 13 Mar 2023 at 01:32:59 +0100, Vincent Lefevre wrote:
> Outside of Firefox, file-roller
> appears to work, but it takes at least 25 seconds before the window
> appears!

This often indicates a D-Bus method call timing out. Running

    dbus-monitor --session

in the same environment as file-roller will log the D-Bus method calls
that are happening, which should give some indication of which specific
call is timing out.

Reading the system log (the systemd journal) might also provide useful
information.

Similarly, when launching file-roller from Firefox, using dbus-monitor
and reading the system log should reveal more information about how and
why it's failing to start.

> BTW, I'm a bit surprised that this is related, as the file-roller
> package does not depend on libdbus-1-3 (there's also no mention
> of dbus in the description and the man page).

Many desktop components use the D-Bus protocol to communicate. libdbus-1-3
is not the only commonly-used implementation of the D-Bus protocol
(there are implementations in GLib and in libsystemd), and the fact that
a component uses D-Bus is an implementation detail which wouldn't make
sense to mention in a man page, in the same way that "is written in C++"
wouldn't be relevant in a man page.

In this particular case, "Failed to register: %s" seems likely to be
coming from gio/gapplication.c in glib2.0.

file-roller appears to have the single-instance design, where the first
instance of file-roller that is run claims a D-Bus name, and the second
and subsequent instances send messages to the first instance asking
it to implement the desired UI. gapplication is one implementation of
that design, and it might be the messages being exchanged between the
instances that are timing out.

"GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown" means the
machine-readable part of the error message sent by the D-Bus implementation
was that error code, which means: a message was sent to a D-Bus service
that doesn't exist.

": org.freedesktop.DBus.Error.ServiceUnknown" means that the
human-readable part of the error message was set equal to the
machine-readable part. This is unusual. Normally, a ServiceUnknown
error message would come from either dbus-daemon or dbus-broker, but
when dbus-daemon produces those errors, it sets the human-readable part
to something more human-readable, normally this:

    The name %s was not provided by any .service files

... and you say you don't have dbus-broker installed, so it can't be that
either. So there must be something different going on here.

Is there anything unusual about the way you installed Firefox or
file-roller? (For instance if they are installed as Flatpak, Snap or
AppImage apps, or running in some sort of sandbox, or running remotely?)

What desktop environment are you using? Or if the answer is "a desktop
environment that I made myself out of individual components", which
components?

Are you using dbus-daemon or dbus-broker or something else to provide
the D-Bus session bus?

Is there anything else unusual going on, for example involving containers
or distributed systems?

    smcv