I am trying `xwayland-run` with `alexandria`: ~~~patch $ git diff diff --git a/alexandria.spec b/alexandria.spec index 35bca24..4cc9d5f 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 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 ~~~ Given this [1] line: ~~~ Requires: (weston or cage or kwin-wayland or mutter or gnome-kiosk) ~~~ I'd think that weston would be installed, but running the build in mock, I can see: ~~~ Installing: ... snip ... rubygem-webmock noarch 3.18.1-2.fc40 fedora 149.9 KiB rubygem-zoom x86_64 0.5.0-32.fc40 fedora 43.3 KiB xwayland-run noarch 0.0.4-4.fc41 local 89.7 KiB Installing dependencies: ... snip ... avahi-glib x86_64 0.8-26.fc40 fedora 19.6 KiB avahi-libs x86_64 0.8-26.fc40 fedora 166.3 KiB cage x86_64 0.1.5-3.fc40 fedora 64.9 KiB cairo x86_64 1.18.0-3.fc40 fedora 1.7 MiB cairo-gobject x86_64 1.18.0-3.fc40 fedora 35.2 KiB ... snip ... vulkan-loader x86_64 1.3.283.0-2.fc41 fedora 512.5 KiB wavpack x86_64 5.7.0-1.fc41 fedora 580.0 KiB wlroots0.16 x86_64 0.16.2-2.fc40 fedora 1.0 MiB xcb-util-errors x86_64 1.0.1-3.fc40 fedora 40.5 KiB ... snip ... Transaction Summary: Installing: 336 packages ~~~ And later failure: ~~~ ... snip ... + xwfb-run -- rake spec:unit Failed to start the compositor: [Errno 2] No such file or directory: 'weston' ... snip ... ~~~ Not sure if this should be addressed here by additional: ~~~ Suggests: weston ~~~ Or if this should be brought to DNF, because it would be natural to prefer the first dependency. [1]: https://src.fedoraproject.org/rpms/xwayland-run/blob/5c1d0499606368a3f0005f89d18c92011dd27299/f/xwayland-run.spec#_18 Reproducible: Always Actual Results: `cage` is installed, when `weston` is the expected default compositor Expected Results: `weston` should be pulled in, because that is the expected default compositor.
(In reply to Vít Ondruch from comment #0) > […] > Actual Results: > `cage` is installed, when `weston` is the expected default compositor > > Expected Results: > `weston` should be pulled in, because that is the expected default > compositor. I cannot comment on why 'cage' ins installed instead of 'weston' considering the order (or if the order actuall matter at all), but it is worth noting that the compositor to use is configurable from the command line and the "default" compositor can be configured for the user or system wide using the configuration files. From "man xwfb-run": OPTIONS […] -c COMPOSITOR, --compositor COMPOSITOR Use the compositor class implementation. […] FILES wlheadless.conf Sets the default compositor to use. The file is searched in wlheadless directory relative to the paths specified in the standard environment variables XDG_DATA_HOME and XDG_DATA_DIRS. [DEFAULT] Compositor = weston So all that to say unless we install all supported compositors, there is no way to guarantee that the default compositor is installed. At least the error mesage is explicit now :
(In reply to Vít Ondruch from comment #0) > […] > Not sure if this should be addressed here by additional: > > ~~~ > Suggests: weston > ~~~ That would not be enough for Fedora buildroot, where soft dependencies are not installed, remember https://bugzilla.redhat.com/show_bug.cgi?id=2293271#c8 > Or if this should be brought to DNF, because it would be natural to prefer > the first dependency. That's a good point, do we have that documented somewhere?
(In reply to Olivier Fourdan from comment #2) > (In reply to Vít Ondruch from comment #0) > > […] > > Not sure if this should be addressed here by additional: > > > > ~~~ > > Suggests: weston > > ~~~ > > That would not be enough for Fedora buildroot, where soft dependencies are > not installed, remember > https://bugzilla.redhat.com/show_bug.cgi?id=2293271#c8 To my knowledge, DNF / libsolv abuses this to adjust the priorities should there be multiple options: https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/#_package_preference > > Or if this should be brought to DNF, because it would be natural to prefer > > the first dependency. > > That's a good point, do we have that documented somewhere? My hope is that Neal will know. But if not, I'll report that.
(In reply to Olivier Fourdan from comment #1) > At least the error mesage is explicit now : Very helpful indeed 👍 Thanks a lot.
This is something odd with DNF5 where the solutions don't make intuitive sense. I've seen similar reports from people trying to manage their Fedora KDE systems with DNF 5 and I've gotten broken openSUSE Tumbleweed system upgrades with DNF5 because of stuff like this. Reassigning to dnf5 to deal with.
According to the documentation on boolean dependencies (see https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html, https://github.com/openSUSE/libsolv/blob/master/doc/libsolv-pool.txt#boolean-dependencies), there is no inherent ordering in OR'ed requirements. All the options are considered equally valid, with none being preferred over the others. Based on my understanding of libsolv, if there are multiple ways to resolve the requirement, one of the rules libsolv uses is simple lexicographic order. This might explain why the `cage` package was preferred over the `weston` package. Your solution with `Suggests: weston` (or the reverse one with `Enhances`) should work. However, for the solver, this is merely a hint and does not guarantee much. If you rely on the weston package, you have to use `Requires: weston`.
I have proposed "short-circuit" evaluation for libsolv here: https://github.com/openSUSE/libsolv/issues/570 In the meantime, I think this should be addressed in `xwayland-run`
I'm addressing it with a Suggests hint for now.
FEDORA-2024-d9cf66325f (xwayland-run-0.0.4-6.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-d9cf66325f
FEDORA-2024-6e7cf1ac24 (xwayland-run-0.0.4-6.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6e7cf1ac24
FEDORA-EPEL-2024-548e4fdb7d (xwayland-run-0.0.4-6.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-548e4fdb7d
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-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-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-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.