Summary: | x11-libs/gtk+:3 - wayland optionality concerns | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | poncho <poncho> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | IN_PROGRESS --- | ||
Severity: | normal | CC: | alexander, gentoo, ikorot01, ks, leho, leohdz172, oescorza, poncho, sam, tout76, unheatedgarage, yaroslav.isakov |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugzilla.gnome.org/show_bug.cgi?id=780544 https://bugs.gentoo.org/show_bug.cgi?id=677494 https://github.com/gentoo/gentoo/pull/21985 https://bugs.gentoo.org/show_bug.cgi?id=680496 https://bugs.gentoo.org/show_bug.cgi?id=873520 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 717146, 665348 | ||
Attachments: | build.log |
Description
poncho
2017-07-14 09:09:04 UTC
3.24.2-optional-wayland.patch must be incomplete then apparently include <gdk/gdkwayland.h> was introduced here: https://git.gnome.org/browse/gnome-control-center/commit/panels/common/gsd-device-manager-udev.c?h=gnome-3-24&id=8f9259ac06db4c2830fa9e79227bb56abdee86ca not sure whether just reverting this commit is the right solution though. I've added a patch that should fix this, but I'm still concerned about the wayland optionality stuff we have here: * If gtk+[wayland] is present, then those codepaths still get used in gnome-control-center and probably other gnome modules due to GDK_WINDOWING_WAYLAND being defined. Our optional-wayland patch here doesn't force GDK_WINDOWING_WAYLAND to undefined, so if you compile gnome-control-center with USE=-wayland but gtk+ happens to be compiled with USE=wayland, it'll still use gdkwayland stuff to some extent, probably thus falling over after gtk+ is recompiled without wayland (as the deps would allow). In fact, I couldn't reproduce the problem or test the fix because of that, as I have gtk+[wayland] - gnome-control-center[-wayland] worked fine for me. * Even with --disable-wayland for our patch passed, I see wacom panel still have -lwayland and co stuff in its LIBS We should think about GDK_WINDOWING_WAYLAND handling for all of GNOME, or maybe consider it's time to hard require wayland to not bother with any of this - at least it's not a plethora of X libs and wayland is the future or something... Re-titling the bug for this, but please test if the gdkwayland fix works for you. You should see a "3.24.2-fix-without-gdkwayland.patch" getting applied if your rsync is caught up. commit f5563dcc576c5a36e990b2d74eafa7e7809cafe7 Author: Mart Raudsepp <leio@gentoo.org> Date: Sat Jul 15 07:12:49 2017 +0300 gnome-base/gnome-control-center: Fix compilation with USE=-wayland without gtk+[wayland] Gentoo-bug: 624960 Package-Manager: Portage-2.3.5, Repoman-2.3.2 gnome-base/gnome-control-center/files/3.24.2-fix-without-gdkwayland.patch | 47 +++++++++++++++++++++++++++++++++++++++++++++++ gnome-base/gnome-control-center/gnome-control-center-3.24.2.ebuild | 2 ++ 2 files changed, 49 insertions(+) (In reply to Mart Raudsepp from comment #3) > Re-titling the bug for this, but please test if the gdkwayland fix works for > you. You should see a "3.24.2-fix-without-gdkwayland.patch" getting applied > if your rsync is caught up. The fixed patch works for me, thanks :) *** Bug 627966 has been marked as a duplicate of this bug. *** This issue just bit me. What should I mask so I can safe downgrade gnome so I can reboot? (In reply to Michael Cook from comment #6) > This issue just bit me. What should I mask so I can safe downgrade gnome so > I can reboot? Running ~amd64, I've been getting errors since we got Gnome 3.24--setting wayland globally fixed the problem for me. Also, I had to apply this patch: https://bugs.gentoo.org/show_bug.cgi?id=627960#c4 Issue still exists in 3.24.3. I'll have a look. (In reply to Mart Raudsepp from comment #3) > I've added a patch that should fix this, but I'm still concerned about the > wayland optionality stuff we have here: > > * If gtk+[wayland] is present, then those codepaths still get used in > gnome-control-center and probably other gnome modules due to > GDK_WINDOWING_WAYLAND being defined. Our optional-wayland patch here doesn't > force GDK_WINDOWING_WAYLAND to undefined, so if you compile > gnome-control-center with USE=-wayland but gtk+ happens to be compiled with > USE=wayland, it'll still use gdkwayland stuff to some extent, probably thus > falling over after gtk+ is recompiled without wayland (as the deps would > allow). In fact, I couldn't reproduce the problem or test the fix because of > that, as I have gtk+[wayland] - gnome-control-center[-wayland] worked fine > for me. > > * Even with --disable-wayland for our patch passed, I see wacom panel still > have -lwayland and co stuff in its LIBS > > We should think about GDK_WINDOWING_WAYLAND handling for all of GNOME, or > maybe consider it's time to hard require wayland to not bother with any of > this - at least it's not a plethora of X libs and wayland is the future or > something... Actually, digging into this I remember I made clutter & co USE=wayland locked to the value of gtk+ due to this. > or maybe consider it's time to hard require wayland to not bother with any of this
Yes. Think of all the other useful stuff that could be done with the time/energy it takes to provide clearly difficult to implement options, such as `USE=-wayland`. Could make sense if we had enough manpower or it was technically trivial. Both pre-conditions evaluate to a strictly typed `false` value.
Looking forward to reaching 3.26 sometime soon.
Retitling to be more about the gdkx.h issue as already meant. This is now regarding globally for GDK_WINDOWING_X11 guards, not just about gnome-control-center. I also removed gnome-terminal gtk+[X] dep for now, as it works fine with pure wayland and we have users that want it for such purpose. The problem is the changing of this on gtk+ after the fact, and not only just for gnome-terminal or gnome-control-center. Could use a USE subslot, eh. gtk+:3[X:=,wayland:=] or something without exposing it in IUSE - rebuild if the USE flag setting changes :D Can we please get this added to the app-i18n/ibus ebuilds as x11-libs/gtk+:3[=wayland] DEPENDs. app-i18n/ibus suffers from the same problem and must be (re-)built to correspond with gtk+:3 'wayland' USE state. Example break: 1. USE=wayland emerge -1 x11-libs/gtk+:3 app-i18n/ibus 2. USE=-wayland emerge -1 x11-libs/gtk+:3 * Updating gtk3 input method module cache ... Cannot load module /usr/lib64/gtk-3.0/3.0.0/immodules/im-ibus.so: /usr/lib64/gtk-3.0/3.0.0/immodules/im-ibus.so: undefined symbol: gdk_wayland_display_get_type *** Bug 736974 has been marked as a duplicate of this bug. *** *** Bug 811372 has been marked as a duplicate of this bug. *** I keep meaning to add a pkg_postinst based on if USE=wayland changed in gtk+ at least to warn about this. *** Bug 882623 has been marked as a duplicate of this bug. *** *** Bug 885051 has been marked as a duplicate of this bug. *** *** Bug 914907 has been marked as a duplicate of this bug. *** *** Bug 928300 has been marked as a duplicate of this bug. *** |