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