Bug 2294207

I'll need the whole clone of the original ticket bellow, but in short `mutter` has currently just soft dependency on `mesa-dri-drivers`. That causes troubles when using xwayland-run in buildroot, resulting in non-transparent errors.




+++ This bug was initially created as a clone of Bug #2293271 +++

Trying to replace `xvfb-run` by `xwfb-run` for package build in mock, it does nothing on the first look. Once I have discovered the `-e` option, I was able to get this log:

~~~
$ cat error.log 
Date: 2024-06-20 CEST
[13:08:41.550] weston 13.0.0
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 13.0.0
[13:08:41.550] Command line: weston --no-config --backend headless --socket wayland-994
[13:08:41.550] OS: Linux, 6.9.0-64.fc41.x86_64, #1 SMP PREEMPT_DYNAMIC Mon May 13 11:58:46 UTC 2024, x86_64
[13:08:41.550] Flight recorder: enabled
[13:08:41.550] Starting with no config file.
[13:08:41.550] Output repaint window is 7 ms maximum.
[13:08:41.550] Loading module '/usr/lib64/libweston-13/headless-backend.so'
[13:08:41.555] Registered plugin API 'weston_windowed_output_api_v2' of size 16
[13:08:41.555] Color manager: no-op
[13:08:41.555] Output 'headless' attempts EOTF mode: SDR
[13:08:41.555] Output 'headless' using color profile: stock sRGB color profile
[13:08:41.555] Output 'headless' enabled with head(s) headless
[13:08:41.555] Compositor capabilities:
               arbitrary surface rotation: no
               screen capture uses y-flip: no
               cursor planes: no
               arbitrary resolutions: no
               view mask clipping: no
               explicit sync: no
               color operations: no
               presentation clock: CLOCK_MONOTONIC_RAW, id 4
               presentation clock resolution: 0.000000001 s
[13:08:41.556] Loading module '/usr/lib64/weston/desktop-shell.so'
[13:08:41.556] launching '/usr/libexec/weston-keyboard'
[13:08:41.556] launching '/usr/libexec/weston-desktop-shell'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
Xwayland glamor: GBM Wayland interfaces not available
Failed to initialize glamor, falling back to sw
Traceback (most recent call last):
  File "/usr/bin/xwfb-run", line 132, in <module>
    if xwayland.create_xauth_entry(args.xauth_proto) != 0:
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/wlheadless/xwayland.py", line 108, in create_xauth_entry
    with subprocess.Popen(xauth_command_line, stdin = subprocess.PIPE) as proc:
         ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/subprocess.py", line 1036, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        pass_fds, cwd, env,
                        ^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
                        gid, gids, uid, umask,
                        ^^^^^^^^^^^^^^^^^^^^^^
                        start_new_session, process_group)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/subprocess.py", line 1966, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'xauth'
~~~

From the error message and looking at the source code [1] it seems that the `xauth` is required. And indeed, installing `/usr/bin/xauth`, the replacement works just fine.



[1]: https://gitlab.freedesktop.org/ofourdan/xwayland-run/-/blob/0.0.3/src/wlheadless/xwayland.py?ref_type=tags#L108

Reproducible: Always

Actual Results:  
Missing `xauth` dependency results in hidden failure

Expected Results:  
`xauth` is installed and `xwfb-run` works just fine

Not sure if it was not worth of improving the error message upstream

--- Additional comment from Vít Ondruch on 2024-06-20 13:36:40 CEST ---

Actually, trying with `mutter`, there is missing `dbus-run-session`

--- Additional comment from Vít Ondruch on 2024-06-20 13:44:31 CEST ---

And more errors later:

~~~
$ cat error.log 
libmutter-Message: 13:36:58.259: Running Mutter (using mutter 46.2) as a Wayland display server
libmutter-Message: 13:36:58.261: Enabling experimental feature 'scale-monitor-framebuffer'

(mutter:997): libmutter-WARNING **: 13:36:58.275: Failed to make thread 'KMS thread' realtime scheduled: Failed to acquire RTKit D-Bus proxy: Could not connect: No such file or directory
libEGL warning: MESA-LOADER: failed to open swrast: /usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)

libmutter-Message: 13:36:58.276: Created surfaceless renderer without GPU
Failed to setup: Unable to initialize the Clutter backend: no available drivers found.
~~~

That means missing:

~~~
$ rpm -qf /usr/lib64/dri/swrast_dri.so
mesa-dri-drivers-24.1.0-1.fc41.x86_64
~~~

--- Additional comment from Vít Ondruch on 2024-06-20 14:11:56 CEST ---

BTW the behavior is also weird, not having `mutter` available, but running `xwfb-run -c mutter` results in error:

~~~
dbus-run-session: failed to exec 'mutter': No such file or directory
Traceback (most recent call last):
  File "/usr/bin/xwfb-run", line 129, in <module>
    xwayland.cleanup()
    ~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/wlheadless/xwayland.py", line 147, in cleanup
    self.remove_xauth_entry()
    ~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/wlheadless/xwayland.py", line 120, in remove_xauth_entry
    xauth_command_line = ['xauth', 'remove', os.environ['DISPLAY']]
                                             ~~~~~~~~~~^^^^^^^^^^^
  File "<frozen os>", line 716, in __getitem__
KeyError: 'DISPLAY'
~~~

Which is a bit misleading. At first, I thought I have to set `DISPLAY` env variable.

--- Additional comment from Vít Ondruch on 2024-06-20 14:18:28 CEST ---

(In reply to Vít Ondruch from comment #2)
> That means missing:
> 
> ~~~
> $ rpm -qf /usr/lib64/dri/swrast_dri.so
> mesa-dri-drivers-24.1.0-1.fc41.x86_64
> ~~~

It seems mutter has soft dependency on mesa-dri-drivers [1]. The question is what does it means for this case.




[1]: https://src.fedoraproject.org/rpms/mutter/blob/rawhide/f/mutter.spec#_118

--- Additional comment from Olivier Fourdan on 2024-06-25 09:01:59 CEST ---

Yes, the package xwayland-run requires both dbus-run and xauth.

For the compositors, it's not so simple though. In my copr [1] I had the default set to mutter and therefore an explicit requirement on that particular compositor (the choice for mutter was based on the Fedora Workstation defaulting on GNOME, and also because recent RHEL versions do not ship any other compositor).

The package in Fedora adopted a different approach by having a dependency on multiple possible compositors [2] and retaining the default compositor as weston. But the caveat there is that there is no way for the package to guarantee that all of the possible compositors that xwayland-run supports is actually installed, so I am not sure what's best.

As for the errors, I suggest redirecting the errors to a file or even stdout (e.g. "xwfb-run -c mutter -e /dev/stdout -- xdpyinfo") to get the full picture oif what is actually happening.

[1] https://download.copr.fedorainfracloud.org/results/ofourdan/xwayland-run/rhel-9-x86_64/06705342-xwayland-run/xwayland-run.spec
[2] https://src.fedoraproject.org/rpms/xwayland-run/blob/rawhide/f/xwayland-run.spec

--- Additional comment from Vít Ondruch on 2024-06-25 11:12:14 CEST ---

1) In the current form, I think the biggest issue is that xwfb-run stays silent even though there are major issues.

2) I think that xwfb-run should better handle the errors. We can install some dependencies via RPM, but the upstream experience is probably not better. So if e.g. `mutter` is not found, it should be obvious on the first look and there should not be confusion with missing `DISPLAY` env etc. IOW missing dependencies should not display backtrace and should be handled gracefully.

3) I am assuming that you are going to add the `xauth` dependency

4) For the multiple compositors, there are more options I think that the `Requires: (weston or cage or kwin-wayland or mutter or gnome-kiosk)` is mostly OK, but it should probably be `(weston or cage or kwin-wayland or (mutter and mesa-dri-drivers) or gnome-kiosk)` (not tested). Not sure if the order matters, but I believe that e.g. `Suggests: weston` might help resolver to give `weston` preference. The old way would be if all supported compositors had e.g. `Provides: xwaylad-run-compositor` provide and xwayland-run included `Requires: xwaylad-run-compositor` + `Suggests: weston`.

--- Additional comment from Olivier Fourdan on 2024-06-25 13:49:06 CEST ---

(In reply to Vít Ondruch from comment #6)
> 1) In the current form, I think the biggest issue is that xwfb-run stays
> silent even though there are major issues.

That's irrelevant for tthis issue though, which is about the package dependencies.

Surely, error handling could be improved, but that's an issue for upstream.
> 
> 2) I think that xwfb-run should better handle the errors. We can install
> some dependencies via RPM, but the upstream experience is probably not
> better. So if e.g. `mutter` is not found, it should be obvious on the first
> look and there should not be confusion with missing `DISPLAY` env etc. IOW
> missing dependencies should not display backtrace and should be handled
> gracefully.

Same, patches upstream are welcome, btw.
 
> 3) I am assuming that you are going to add the `xauth` dependency

That's up to Neil to decide actually.
 
> 4) For the multiple compositors, there are more options I think that the
> `Requires: (weston or cage or kwin-wayland or mutter or gnome-kiosk)` is
> mostly OK, but it should probably be `(weston or cage or kwin-wayland or
> (mutter and mesa-dri-drivers) or gnome-kiosk)` (not tested). Not sure if the
> order matters, but I believe that e.g. `Suggests: weston` might help
> resolver to give `weston` preference. The old way would be if all supported
> compositors had e.g. `Provides: xwaylad-run-compositor` provide and
> xwayland-run included `Requires: xwaylad-run-compositor` + `Suggests:
> weston`.

Same, that's up to Neil to decide, but I doubt that adding a provide to all compositors to satisfy what is an unrelated depedennt package is a good solution.

mesa-dri-drivers is irrelevant here, there is absolutely no dependency between xwayland-run and mesa.

--- Additional comment from Vít Ondruch on 2024-06-25 14:48:53 CEST ---

(In reply to Olivier Fourdan from comment #7)
> mesa-dri-drivers is irrelevant here, there is absolutely no dependency
> between xwayland-run and mesa.

There is dependency if `mutter` is used. I might have skipped to mention the exact error. The problem is that `mutter` declares just soft dependency on `mesa-dri-drivers`, which is not enough for Fedora buildroot, where soft dependencies are not installed. Of course you might say that "if you want to use xwayland-run with `mutter`, please add also dependency on `mesa-dri-drivers`", but the problem is that is not really easy to figure this out.

--- Additional comment from Olivier Fourdan on 2024-06-25 15:00:14 CEST ---

(In reply to Vít Ondruch from comment #8)
> 
> There is dependency if `mutter` is used. I might have skipped to mention the
> exact error. The problem is that `mutter` declares just soft dependency on
> `mesa-dri-drivers`, which is not enough for Fedora buildroot, where soft
> dependencies are not installed. Of course you might say that "if you want to
> use xwayland-run with `mutter`, please add also dependency on
> `mesa-dri-drivers`", but the problem is that is not really easy to figure
> this out.

Well, I disagree, that would be a dependency problem in mutter, not xwayland-run.

Again, xwayland run has no dependency on Mesa and should not list any.