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
Actually, trying with `mutter`, there is missing `dbus-run-session`
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 ~~~
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.
(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
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
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`.
(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.
(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.
(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.
(In reply to Olivier Fourdan from comment #9) > Again, xwayland run has no dependency on Mesa and should not list any. I have reported this against mutter: bug 2294207. Lets see what the other side thinks.
FWIW, Weston requires mesa-dri-drivers: https://src.fedoraproject.org/rpms/weston/blob/rawhide/f/weston.spec#_74
Same for sway: https://src.fedoraproject.org/rpms/sway/blob/rawhide/f/sway.spec#_74
I posted https://gitlab.freedesktop.org/ofourdan/xwayland-run/-/merge_requests/13 to improve error reporting (like xauth not being installed)
I am surprised that Xwayland doesn't have a dependency on xauth. I kind of would expect if xwayland is installed, xauth should be there, but I am not opposed to adding xauth to xwayland-run.
In general, I've been recommending applications to use wlheadless-run(1) instead of xwfb-run(1), since the former tests things as Wayland clients instead of X11 clients.
(In reply to Neal Gompa from comment #14) > I am surprised that Xwayland doesn't have a dependency on xauth. I kind of > would expect if xwayland is installed, xauth should be there, but I am not > opposed to adding xauth to xwayland-run. Nope, xauth is not required to run Xwayland (or any other xserver actually). The only package that has a requirement on xauth is Xvfb [1], precisely because the xvfb-run script uses xauth. Similarly, xauth is required by xwfb-run, not Xwayland. [1] https://src.fedoraproject.org/rpms/xorg-x11-server/blob/rawhide/f/xorg-x11-server.spec#_320
(In reply to Neal Gompa from comment #15) > In general, I've been recommending applications to use wlheadless-run(1) > instead of xwfb-run(1), since the former tests things as Wayland clients > instead of X11 clients. That is good point, which could be probably elaborated somewhere. Nevertheless, trying with `alexandria`, it fails with a lot of errors such as: ~~~ $ wlheadless-run -c mutter -- rake spec:unit libmutter-Message: 09:54:45.697: Running Mutter (using mutter 46.2) as a Wayland display server libmutter-Message: 09:54:45.697: Enabling experimental feature 'scale-monitor-framebuffer' (mutter:999): libmutter-WARNING **: 09:54:45.713: Failed to make thread 'KMS thread' realtime scheduled: Failed to acquire RTKit D-Bus proxy: Could not connect: No such file or directory libmutter-Message: 09:54:45.746: Created surfaceless renderer without GPU libmutter-Message: 09:54:45.763: Using Wayland display name 'wayland-996' Window manager warning: Failed to set environment variable WAYLAND_DISPLAY for gnome-session: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.gnome.SessionManager" does not exist (mutter:999): mutter-WARNING **: 09:54:45.764: Failed to acquire org.freedesktop.locale1 proxy: Could not connect: No such file or directory (mutter:999): libmutter-WARNING **: 09:54:45.767: Failed to connect to colord daemon: Could not connect: No such file or directory /usr/bin/ruby -rbundler/setup -rsimplecov -Ilib -w -I/usr/share/gems/gems/rspec-support-3.13.1/lib:/usr/share/gems/gems/rspec-core-3.13.0/lib /usr/share/gems/gems/rspec-core-3.13.0/exe/rspec --pattern spec/alexandria/\*\*/\*_spec.rb /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/lib/alexandria/library_store.rb:61: warning: assigned but unused variable - e /usr/share/gems/gems/nokogiri-1.16.6/lib/nokogiri/version/info.rb:76: warning: statement not reached dbus-daemon[998]: [session uid=1000 pid=998] Activating service name='org.a11y.Bus' requested by ':1.2' (uid=1000 pid=1025 comm="/usr/bin/ruby-mri -rbundler/setup -rsimplecov -Ili" label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") dbus-daemon[998]: [session uid=1000 pid=998] Successfully activated service 'org.a11y.Bus' /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/lib/alexandria/ui/ui_manager.rb:728: warning: assigned but unused variable - book /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/lib/alexandria/ui/ui_manager.rb:728: warning: assigned but unused variable - isbn /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/lib/alexandria/ui/ui_manager.rb:728: warning: assigned but unused variable - library /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/lib/alexandria/ui/ui_manager.rb:714: warning: assigned but unused variable - books_to_add /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/lib/alexandria/ui/ui_manager.rb:701: warning: assigned but unused variable - title *****dbus-daemon[998]: [session uid=1000 pid=998] Activating service name='org.gnome.GConf' requested by ':1.4' (uid=1000 pid=1045 comm="gconftool-2 --recursive-list /apps/alexandria" label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") dbus-daemon[998]: [session uid=1000 pid=998] Successfully activated service 'org.gnome.GConf' ... snip ... Gdk-CRITICAL **: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed from /usr/share/gems/gems/gobject-introspection-4.2.2/lib/gobject-introspection/loader.rb:713:in `invoke' from /usr/share/gems/gems/gobject-introspection-4.2.2/lib/gobject-introspection/loader.rb:364:in `block (2 levels) in initialize' from /usr/share/gems/gems/gobject-introspection-4.2.2/lib/gobject-introspection/loader.rb:363:in `catch' from /usr/share/gems/gems/gobject-introspection-4.2.2/lib/gobject-introspection/loader.rb:363:in `block in initialize' from /usr/share/gems/gems/gobject-introspection-4.2.2/lib/gobject-introspection/loader.rb:362:in `each' from /usr/share/gems/gems/gobject-introspection-4.2.2/lib/gobject-introspection/loader.rb:362:in `initialize' from /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/lib/alexandria/ui/about_dialog.rb:28:in `new' from /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/lib/alexandria/ui/about_dialog.rb:28:in `initialize' from /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/spec/alexandria/ui/about_dialog_spec.rb:12:in `new' from /builddir/build/BUILD/alexandria-0.7.9-build/alexandria-book-collection-manager-0.7.9/spec/alexandria/ui/about_dialog_spec.rb:12:in `block (2 levels) in <top (required)>' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:263:in `instance_exec' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:263:in `block in run' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:511:in `block in with_around_and_singleton_context_hooks' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:468:in `block in with_around_example_hooks' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/hooks.rb:486:in `block in run' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/hooks.rb:626:in `block in run_around_example_hooks_for' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:352:in `call' from /usr/share/gems/gems/webmock-3.18.1/lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:457:in `instance_exec' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:457:in `instance_exec' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/hooks.rb:390:in `execute_with' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/hooks.rb:628:in `block (2 levels) in run_around_example_hooks_for' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:352:in `call' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/hooks.rb:629:in `run_around_example_hooks_for' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/hooks.rb:486:in `run' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:468:in `with_around_example_hooks' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:511:in `with_around_and_singleton_context_hooks' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:259:in `run' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example_group.rb:646:in `block in run_examples' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example_group.rb:642:in `map' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example_group.rb:642:in `run_examples' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/example_group.rb:607:in `run' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/runner.rb:121:in `block (3 levels) in run_specs' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/runner.rb:121:in `map' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/runner.rb:121:in `block (2 levels) in run_specs' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/configuration.rb:2091:in `with_suite_hooks' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/runner.rb:116:in `block in run_specs' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/reporter.rb:74:in `report' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/runner.rb:115:in `run_specs' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/runner.rb:89:in `run' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/runner.rb:71:in `run' from /usr/share/gems/gems/rspec-core-3.13.0/lib/rspec/core/runner.rb:45:in `invoke' from /usr/share/gems/gems/rspec-core-3.13.0/exe/rspec:4:in `<main>' ... snip ... ~~~
(In reply to Vít Ondruch from comment #17) > $ wlheadless-run -c mutter -- rake spec:unit You probably want to add some extra arguments like I did at https://src.fedoraproject.org/rpms/libhandy/pull-request/5#request_diff to make sure Mutter doesn't try to do fancy stuff like connecting to the session management bus. For your command, that would be $ wlheadless-run -c mutter --sm-disable --virtual-monitor 1024x768 -- rake spec:unit
Actually the failure reported in comment 17 is more about the client failing to start because of the lack of monitor, so I wonder we would be better adding the virtual monitor from wlheadless-run when using mutter based compositors (it used to do that, in the first versions)
(In reply to Niels De Graef from comment #18) > (In reply to Vít Ondruch from comment #17) > > $ wlheadless-run -c mutter -- rake spec:unit > > You probably want to add some extra arguments like I did at > https://src.fedoraproject.org/rpms/libhandy/pull-request/5#request_diff to > make sure Mutter doesn't try to do fancy stuff like connecting to the > session management bus. For your command, that would be > > $ wlheadless-run -c mutter --sm-disable --virtual-monitor 1024x768 -- rake > spec:unit Thank you. I don't think I would ever find this example in PR :) I was trying to look for examples, but the only available is qt6-qtbase.spes, but I don't think the test case is enabled and there are no additional options specified. But still, I'd expect some sensible defaults. I don't know why everybody should specify `--virtual-monitor 1024x768` when the screen resolution typically does not matter. (In reply to Olivier Fourdan from comment #19) > Actually the failure reported in comment 17 is more about the client failing > to start because of the lack of monitor, so I wonder we would be better > adding the virtual monitor from wlheadless-run when using mutter based > compositors (it used to do that, in the first versions) Yes, I think this is along the lines what I said above.
(In reply to Vít Ondruch from comment #20) > > But still, I'd expect some sensible defaults. I don't know why everybody > should specify `--virtual-monitor 1024x768` when the screen resolution > typically does not matter. > It's not about the resolution, it's the lack of monitor. The defaults come from mutter actually, which is the reason I am not sure this really belongs to xwayland-run.
I'm afraid this bug is becoming unmanageable. It would be much easier if you could open a separate bug for separate issues, instead of adding new problems in this bug here.
(In reply to Olivier Fourdan from comment #22) > I'm afraid this bug is becoming unmanageable. > > It would be much easier if you could open a separate bug for separate > issues, instead of adding new problems in this bug here. I don't disagree. Lets address my initial comment. IOW I believe these are the minimal changes required for alexandria: ~~~ $ git diff diff --git a/alexandria.spec b/alexandria.spec index 35bca24..465e757 100644 --- a/alexandria.spec +++ b/alexandria.spec @@ -108,7 +108,7 @@ BuildRequires: rubygem(rspec) # https://github.com/mvz/alexandria-book-collection-manager/issues/124 %BothRequires rubygem(rexml) # rspec test -BuildRequires: %{_bindir}/xvfb-run +BuildRequires: %{_bindir}/xwfb-run weston BuildRequires: %{_bindir}/ping BuildRequires: rubygem(webmock) BuildRequires: rubygem(json) @@ -314,8 +314,7 @@ ping -w3 www.google.co.jp && \ sed -i spec/alexandria/book_providers_spec.rb -e "\@Alexandria::BookProviders::SBNProvider@{n;s|it|xit|}"; } -xvfb-run \ - -s "-screen 0 640x480x24" \ +xwfb-run -- \ rake spec:unit find . -name \*.testsuite | while read f ~~~ But to make this work, adding `Requires: %{_bindir}/xauth` or similar to xwayland-run is needed (according to comment 16).
FEDORA-EPEL-2024-548e4fdb7d (xwayland-run-0.0.4-4.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-548e4fdb7d
FEDORA-2024-6e7cf1ac24 (xwayland-run-0.0.4-4.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6e7cf1ac24
FEDORA-2024-d9cf66325f (xwayland-run-0.0.4-4.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-d9cf66325f
FEDORA-2024-d9cf66325f has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-d9cf66325f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d9cf66325f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-6e7cf1ac24 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6e7cf1ac24` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6e7cf1ac24 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2024-548e4fdb7d has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-548e4fdb7d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2024-548e4fdb7d (xwayland-run-0.0.4-6.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-d9cf66325f (xwayland-run-0.0.4-6.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-6e7cf1ac24 (xwayland-run-0.0.4-6.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.