|
Bugzilla – Full Text Bug Listing |
| Summary: | gmenudbusmenuproxy needs appmenu-gtk-module | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Cor Blom <cornelis> |
| Component: | KDE Workspace (Plasma) | Assignee: | E-Mail List <opensuse-kde-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | 20alexrod, cornelis, fabian, fvogt, sor.alexei |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Cor Blom
2018-09-18 15:51:00 UTC
The current version of appmenu-gtk-module in tumbleweed makes gtk apps crash in plasma (segmentation fault). So sticking to unity-gtk-module is better for now. (In reply to Cor Blom from comment #0) > gmenudbusmenuproxy (part of plasma5-workspace) requires appmenu-gtk-module > during runtime, not unity-gtk-module. It is since a few days in Factory. > Part of the package "vala-panel-appmenu". It does not - unity-gtk-module works just fine. (In reply to Cor Blom from comment #1) > The current version of appmenu-gtk-module in tumbleweed makes gtk apps crash > in plasma (segmentation fault). So sticking to unity-gtk-module is better > for now. If we were to switch to appmenu-gtk-module this would need to be done: gmenudbusmenuproxy gains two subpackages: gmenudbusmenuproxy-unity gmenudbusmenuproxy-appmenu which require unity-gtk-module or appmenu-gtk-module respectively and provide "gmenudbusmenuproxy-gtk-module" each. gmenudbusmenuproxy can than require that and the user/zypper is free to choose between those. There would need to be a script for appmenu-gtk-module to configure the GTK(3)_MODULES environment variable though. Would you mind to create a bug report against appmenu-gtk-module as it crashes? (In reply to Fabian Vogt from comment #2) > (In reply to Cor Blom from comment #0) > > gmenudbusmenuproxy (part of plasma5-workspace) requires appmenu-gtk-module > > during runtime, not unity-gtk-module. It is since a few days in Factory. > > Part of the package "vala-panel-appmenu". > > It does not - unity-gtk-module works just fine. It does not work fine with gtk2 apps. Gimp for example has two menubars, the one in the application and the global menu. This does not happen with appmenu-gtk-module. But it is the only difference I saw. (In reply to Fabian Vogt from comment #3) > Would you mind to create a bug report against appmenu-gtk-module as it > crashes? See bug #1115273 (In reply to Cor Blom from comment #5) > (In reply to Fabian Vogt from comment #3) > > Would you mind to create a bug report against appmenu-gtk-module as it > > crashes? > > See bug #1115273 The crash does not happen anymore in current Tumbleweed Are there any plans to do something with this bug? The new appmenu-gtk-module is also in Leap 15.2 and working fine there. Also with gtk2 apps like gimp. the unity module can be removed and the appmenu-gtk-module installed and it is working as expected. If the plan is to leave everything as it is and let the user choose what to do, it's better to close this bug, IMHO. Although the appmenu module is still developed, the unity variant not, as far as I can see. Meanwhile gmenudbusmenuproxy is able to enable the appmenu-gtk-module on demand, so no modifications to the packaging should be necessary anymore. However, this needs some testing and the migration would need a Conflicts: unity-gtk-module-common and I'm not fully sure how that would behave with upgrades... Test package is building here: https://build.opensuse.org/package/show/home:Vogtinator:boo1108846/plasma5-workspace Can you give this a try, maybe even test the upgrade scenario (Make sure unity-gtk*-module is installed, then zypper -v dup --from $aboverepo)? Can you also add 15.2? (In reply to Cor Blom from comment #9) > Can you also add 15.2? Done, it's building now. On 15.2 update removes the following: unity-gtk-module-common unity-gtk2-module unity-gtk3-module It leave the following installed, which I assume should also be removed (but maybe they are needed by something??): libunity-gtk2-parser0 libunity-gtk3-parser0 And it wants to install the following new packages: appmenu-gtk-module-common appmenu-gtk2-module appmenu-gtk3module libappmenu-gtk2-parser0 libappmenu-gtk3-parser0 I cannot test op 15.1 or TW at the moment, but I assume the result is the same. If necessary I can do a test on 15.1 later. (In reply to Cor Blom from comment #11) > On 15.2 update removes the following: > > unity-gtk-module-common > unity-gtk2-module > unity-gtk3-module Was manual conflict required or did zypper do that automatically? > It leave the following installed, which I assume should also be removed (but > maybe they are needed by something??): > > libunity-gtk2-parser0 > libunity-gtk3-parser0 Probably just kept because auto cleanup of deps is only possible with "zypper rm --clean-deps"... > And it wants to install the following new packages: > > appmenu-gtk-module-common > appmenu-gtk2-module > appmenu-gtk3module > libappmenu-gtk2-parser0 > libappmenu-gtk3-parser0 Sounds sensible. I assume it works fine with enabling/disabling the global menu? > I cannot test op 15.1 or TW at the moment, but I assume the result is the > same. If necessary I can do a test on 15.1 later. 15.1 doesn't have appmenu-gtk{2,3}-module packages, so the switch wasn't possible there. The issue was that plasma 5.18.4.1 is not yet available in 15.2, so I had to allow come incompatibility. It required manual intervention, the following:
Probleem: gmenudbusmenuproxy-5.18.4.1-lp152.514.1.x86_64 is in conflict met unity-gtk-module-common die geleverd is door unity-gtk-module-common-0.0.0+bzr20171202-lp152.3.6.x86_64
Oplossing 1: De volgende acties worden uitgevoerd:
verwijderen van unity-gtk-module-common-0.0.0+bzr20171202-lp152.3.6.x86_64
verwijderen van unity-gtk3-module-0.0.0+bzr20171202-lp152.3.6.x86_64
verwijderen van unity-gtk2-module-0.0.0+bzr20171202-lp152.3.6.x86_64
Oplossing 2: De volgende acties worden uitgevoerd:
verwijderen van gmenudbusmenuproxy-5.18.3-lp152.1.4.x86_64
verwijderen van plasma5-workspace-branding-openSUSE-84.87~git20190606T185118~3d37a0c-lp152.10.1.noarch
verwijderen van plasma5-desktop-5.18.3-lp152.1.5.x86_64
verwijderen van patterns-kde-kde_plasma-20181130-lp152.3.1.noarch
verwijderen van plasma5-desktop-emojier-5.18.3-lp152.1.5.x86_64
verwijderen van plasma5-desktop-lang-5.18.3-lp152.1.5.noarch
verwijderen van sddm-branding-openSUSE-0.18.0-lp152.4.10.x86_64
verwijderen van patterns-kde-kde-20181130-lp152.3.1.noarch
Oplossing 3: verouderde gmenudbusmenuproxy-5.18.3-lp152.1.4.x86_64 handhaven
Sorry, system is Dutch. :) I chose 1: removal ("verwijderen") of unity*. I don't know if with the right plasma versions available this intervention would have been necessary. Hereafter it is shown what will be done.
(In reply to Cor Blom from comment #13) > The issue was that plasma 5.18.4.1 is not yet available in 15.2, so I had to > allow come incompatibility. It required manual intervention, the following: That looks more like the conflicts cause the issue than the version jump. Can you try just "zypper in gmenudbusmenuproxy-5.18.4.1"? I'm not sure whether this conflict would be acceptable for a pretty much default upgrade. What happens if both modules are installed at once? Manual intervention is still required. The message say that there is a conflict that needs a solution. Then two options, similar like before, but without the plasma version conflicts. unity-module and appmenu-module can co-exist happily. Looking at a global menu with gimp, when both are installed the appmenu-module is used. (BTW, in my experience unity-module can be uninstalled without problems, but at a certain stage it wants to be installed again. Some package probably recommends it. Don't know which package. That was at least the case with a TW system, where zypper dup is the normal procedure.) (In reply to Cor Blom from comment #15) > Manual intervention is still required. The message say that there is a > conflict that needs a solution. Then two options, similar like before, but > without the plasma version conflicts. Ok, so something that has to be worked around... > unity-module and appmenu-module can co-exist happily. Looking at a global > menu with gimp, when both are installed the appmenu-module is used. It seems like both modules are loaded and used - that doesn't sound great. Is there some guarantee that only one (and which one) ends up being effective? > (BTW, in my experience unity-module can be uninstalled without problems, but > at a certain stage it wants to be installed again. Some package probably > recommends it. Don't know which package. That was at least the case with a > TW system, where zypper dup is the normal procedure.) Yes, gmenudbusmenuproxy recommends it depending on whether GTK2 and GTK3 are installed. (In reply to Fabian Vogt from comment #16) > > unity-module and appmenu-module can co-exist happily. Looking at a global > > menu with gimp, when both are installed the appmenu-module is used. > > It seems like both modules are loaded and used - that doesn't sound great. > Is there some guarantee that only one (and which one) ends up being > effective? I do not know. I can only speak about what I see when I use it and it is my impression that when both appmenu-* and unity-* are installed, gmenudbusmenuproxy prefers appmenu-* But I must say I only see a difference with gtk2 apps, as said before. I don't really know anything about the internal workings of gmenudbusmenuproxy. (In reply to Cor Blom from comment #17) > (In reply to Fabian Vogt from comment #16) > > > unity-module and appmenu-module can co-exist happily. Looking at a global > > > menu with gimp, when both are installed the appmenu-module is used. > > > > It seems like both modules are loaded and used - that doesn't sound great. > > Is there some guarantee that only one (and which one) ends up being > > effective? > > I do not know. Let's ask the maintainer then. > But I must say I only see a difference > with gtk2 apps, as said before. I don't really know anything about the > internal workings of gmenudbusmenuproxy. I just checked QT_LOGGING_RULES=*.debug=true gmenudbusmenuproxy here and it seems to connect to /com/canonical/unity and only after removing unity-gtk*-module it uses /org/appmenu/gtk/. I assume that appmenu-gtk2-module hides the menu bar but unity-gtk2-module is the one actually exporting the menu? Revisited global menus today and saw that libunity is deleted from Tumbleweed months ago. After having failed to build for weeks. Info was never provided :-/ Here's a SR to switch over: https://build.opensuse.org/request/show/1029582 |