As part of the desktop rebase in 7.6, we need to rebase mutter to the version that is shipped with GNOME 3.28.
Rebase branch: http://pkgs.devel.redhat.com/cgit/rpms/mutter/log/?h=private-rhel-7.6-rebase
This needs help from people who understand mutter -- Florian, Carlos, Jonas can you take a look please?
I've rebased the patches as much as I could, and dropped the rest.
0001-monitor-manager-xrandr-Force-an-update-when-resuming.patch is one of the dropped patches that doesn't seem to have gotten merged upstream -- is it still needed? Can someone rebase it in that case and add it back in private branch, please?
I've edited the following patches to apply, review appreciated:
Dropped patches are too numerous to list here, please take a look at the branch.
Also, when commiting patches, it would be really nice to organize them so that we have a section with "Backported patches from upstream" and another one with "RHEL downstream patches" so that it's clear which ones need rebasing and which can be dropped when updating to a new version.
Also, any chance to get a few more of the patches upstream? :)
Also ended up dropping 0001-monitor-manager-xrandr-Work-around-spurious-hotplugs.patch -- is it still needed? Can someone rebase it in that case, please?
Why did you drop 0001-monitor-manager-xrandr-Work-around-spurious-hotplugs.patch. Have Xvnc stopped turning off/on its outputs?
Whether 0001-monitor-manager-xrandr-Force-an-update-when-resuming.patch is needed anymore depends on whether it still reproduces on the hardware it reproduced on before, since it seems like a work-around missing hotplug events.
The rest of the branch (rebased patches and dropping of patches that seem to have landed upstream) looks good to me.
Right, that's exactly the part that needed help :) Can you rebase the two patches and add them back on the private rebase branch please? I only dropped them to get things building quickly in the rebase COPR (https://copr.devel.redhat.com/coprs/klember/rhel-7-gnome-3-28/)
If you need to test building the package, please request access in the copr.
Forgot to say thanks for the help!
I went and reimplemented the force-reload-on-resume patch on top of todays mutter, but when finding the corresponding bug upstream, I noticed that Rui had mentioned that the bug should already be fixed in linux-4.5. Any chance to get this rechecked by QA without the patch?
Sure, added tpelka from QA to CC who can maybe help recheck it. I'll just note that we have kernel-3.10.0-862.3.2.el7 in RHEL 7 right now, which may or may not have that fix backported.
(In reply to Kalev Lember from comment #8)
> Sure, added tpelka from QA to CC who can maybe help recheck it. I'll just
> note that we have kernel-3.10.0-862.3.2.el7 in RHEL 7 right now, which may
> or may not have that fix backported.
Note that we have kernel-3.10.0-874.el7.rhel76drm.03.x86_64 from http://file.rdu.redhat.com/~btissoir/RHEL-7.6-xorg-rebase which if I'm not mistaken should include all (or majority) planned DRM backported fixes for rhel7.6.
The commit that should fix the issue according to Rui (from the upstream bug report) is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2dc2f761dea65069485110d24eaa5b0d5d808b07. Is that one backported?
Benjamin do you know?
that commit has been included in v4.5, so we should already have it in a released 7.5 kernel. I can not remember the exact kernel we rebased in 7.5, but it was more in the v4.1X than v4.0X
Speaking of potentially dropping/upstreaming patches, Florian, what crash does 0001-monitor-manager-Consider-external-layout-before-defa.patch fix? The commit message is about better initial configuration, but the git log is about a crash and links to https://bugzilla.redhat.com/show_bug.cgi?id=1481386.
To check: are we okay with dropping:
Can somebody confirm that those patches are already upstream please? We should have already built packages a few weeks ago, and I'm still desperate for the rebase to not be cancelled. Thanks.
Verified on RHEL-7.6-20180812.n.0
Parag, looks like something going wrong with Caribou, do you know what's going on here?
It has become very confusing for me why Desktop team or gnome-shell maintainers do not want to obsolete caribou package in rhel-7.6
Ohh, is the issue that it just needs to be removed for things to work correctly? Can you file a bug to obsolete caribou please, if that's the case?
No no its just one issue to make sure QE people while reporting bug will not give below debug message while reporting bugs
"caribou-gtk-module.c: line 1028: unexpected error additionally: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Caribou.Keyboard was not provided by any .service files (g-dbus-error-quark"
We do have issues currently and need explicit testing of new OSK under Gnome, Gnome Classic and Gnome on Wayland sessions.
For obsoleting caribou package we have now 2 bugs already reported
1) bug 1624229 Drop Caribou package from the Final 7.6 release
2) bug 1625882 - gnome-shell should obsolete Caribou*
I think currently the first priority to be given for this separate OSK bug 1625700 which anyways also getting discussed in bug 1521077
I have tested successfully new OSK functionality under Wayland session but somehow OSK has stopped appearing in most of the applications.
I tested on recent snapshot2.
bug 1625882 should be now resolved - I mean gnome-shell should obsolete it for 7.6.
I guess we can now move mutter to verified.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.