Bug 1030873

Yes, it is planned. This in fact never work well if you pick something outside of DE selection like enlightment or mate.

a) So if DE want to set its preferred DM, it should do it in its post install script.

b) same as other, it should be set in post install script or we can drop value and make reasonable default in DM itself.

this still works for DE that is kept in DE selection like KDE and GNOME, but others are just simple packages.

Is it acceptable for you?

Josef

(In reply to Josef Reidinger from comment #1)
> Yes, it is planned. This in fact never work well if you pick something
> outside of DE selection like enlightment or mate.
> 
> a) So if DE want to set its preferred DM, it should do it in its post
> install script.
> 
> b) same as other, it should be set in post install script or we can drop
> value and make reasonable default in DM itself.
> 
> this still works for DE that is kept in DE selection like KDE and GNOME, but
> others are just simple packages.
> 
> Is it acceptable for you?

(Not the person you asked)

There is no install script for DEs. DEs consist of many packages and multiple DEs can be installed. The default needs to be well-defined and chosen by the user.

(In reply to Fabian Vogt from comment #2)
> (In reply to Josef Reidinger from comment #1)
> > Yes, it is planned. This in fact never work well if you pick something
> > outside of DE selection like enlightment or mate.
> > 
> > a) So if DE want to set its preferred DM, it should do it in its post
> > install script.
> > 
> > b) same as other, it should be set in post install script or we can drop
> > value and make reasonable default in DM itself.
> > 
> > this still works for DE that is kept in DE selection like KDE and GNOME, but
> > others are just simple packages.
> > 
> > Is it acceptable for you?
> 
> (Not the person you asked)
> 
> There is no install script for DEs. DEs consist of many packages and
> multiple DEs can be installed. The default needs to be well-defined and
> chosen by the user.

question is why it have to be defined and selected during installation. Usually we have one DM in pattern and this DM can remember preferred DE, so in the end it is set just not in installation, but later. Which is closer to modern trends to have small installation and select it during first boot.

If the new desktop selection should go to 42.3 we need to keep DEFAULT_WM, we may look for alternatives in Factory though.

Could we add a special provides to patterns that makes YaST set DEFAULT_WM for now?

lslezak - is it possible? see comment#4

(In reply to Ludwig Nussel from comment #4)
> If the new desktop selection should go to 42.3 we need to keep DEFAULT_WM,
> we may look for alternatives in Factory though.
> 
> Could we add a special provides to patterns that makes YaST set DEFAULT_WM
> for now?

We would probably want some slightly fancy logic to disable autologin in the case someone selects multiple providers for the DEFAULT_WM, ie if someone installs both Enlightenment and LXQt from the other selection or any other combo of multiple DE's.

(In reply to Ludwig Nussel from comment #4)
> If the new desktop selection should go to 42.3 we need to keep DEFAULT_WM,
> we may look for alternatives in Factory though.
> 
> Could we add a special provides to patterns that makes YaST set DEFAULT_WM
> for now?

if we can modify pattern to have provides, why we cannot modify them to have post-install that modify it in fact? I see no difference. We can even create rpm macro for it. if default value is something like undef and it is modified only if it is set to undef, it will work.

we could add some sed call of course. It's not the same though as that would happen always, not just if yast is used for initial installation. So for 42.3 some yast based method would be preferred IMO.

For TW I'd probably suggest to get rid of DEFAULT_WM and use e.g. update-alternatives instead.

(In reply to Ludwig Nussel from comment #8)
> we could add some sed call of course. It's not the same though as that would
> happen always, not just if yast is used for initial installation. So for
> 42.3 some yast based method would be preferred IMO.
> 
> For TW I'd probably suggest to get rid of DEFAULT_WM and use e.g.
> update-alternatives instead.

but we have in yast same problem. What should be done if more then one is provided? what if provided WM is lxde, xfce and e17? which one we should pick? note that pattern beside desktop selection is not exclusive choice, so we can get more then one.

Hmm, don't set any and the the DM figure it out. Maybe it just turns off autologin.

(In reply to Josef Reidinger from comment #7)
> 
> (In reply to Ludwig Nussel from comment #4)
> > If the new desktop selection should go to 42.3 we need to keep DEFAULT_WM,
> > we may look for alternatives in Factory though.
> > 
> > Could we add a special provides to patterns that makes YaST set DEFAULT_WM
> > for now?
> 
> if we can modify pattern to have provides, why we cannot modify them to have
> post-install that modify it in fact? I see no difference. We can even create
> rpm macro for it. if default value is something like undef and it is
> modified only if it is set to undef, it will work.

We could probably make the macro smart enough to detect if its already been set and if it has get the macro to disable autologin instead.

(In reply to Ludwig Nussel from comment #10)
> Hmm, don't set any and the the DM figure it out. Maybe it just turns off
> autologin.

I think it depends on DM. When I am testing it, some DMs have inside list of priority for DE and others also, but one which we probably do not like :)

The custom selection installs lightdm. I did some tests and AFAICT lightdm just doesn't auto login if nothing is set. So should be fine, no extra code needed. KDE and GNOME have their own displaymanager and we can set the default session for those.

(In reply to Ludwig Nussel from comment #13)
> The custom selection installs lightdm. I did some tests and AFAICT lightdm
> just doesn't auto login if nothing is set. So should be fine, no extra code
> needed. KDE and GNOME have their own displaymanager and we can set the
> default session for those.

Just as long as it also sets lightdm as the displaymanager, in the past the installer also did this based off that screen so when enlightenment was selected manually from the patterns screen rather then from the radio button lightdm would be installed, however xdm would be run on the first boot (SUSEStudio images also had this issue)

To comment #4: Special provides for DEFAULT_WM would be tricky, as commented later, there might be more patterns providing that flag selected to install.

What about adding DEFAULT_WM to the roles definition?

(In reply to Ladislav Slezák from comment #15)
> To comment #4: Special provides for DEFAULT_WM would be tricky, as commented
> later, there might be more patterns providing that flag selected to install.
> 
> What about adding DEFAULT_WM to the roles definition?

roles already set it, it is not problem. Problem is with WM that are not in roles, but in custom role so selected by pattern, not by role.

Maybe the problem is somewhere else: We do not run the desktop selection
dialog anymore. We run another one, which was created just for openSUSE.

In "old days", DS dialog used this functionality:
https://github.com/yast/yast-packager/blob/17d980f16f65c4a659241b15193bc68db8ac0e20/src/modules/DefaultDesktop.rb#L206-L225
and this configuration was used: https://github.com/yast/skelcd-control-openSUSE/blob/master/control/control.openSUSE.xml#L149-L239
Maybe it's not the case anymore.

(In reply to Lukas Ocilka from comment #17)
> Maybe the problem is somewhere else: We do not run the desktop selection
> dialog anymore. We run another one, which was created just for openSUSE.
> 
> In "old days", DS dialog used this functionality:
> https://github.com/yast/yast-packager/blob/
> 17d980f16f65c4a659241b15193bc68db8ac0e20/src/modules/DefaultDesktop.rb#L206-
> L225
> and this configuration was used:
> https://github.com/yast/skelcd-control-openSUSE/blob/master/control/control.
> openSUSE.xml#L149-L239
> Maybe it's not the case anymore.

it is still used, but only for desktops that are in roles. So for KDE and GNOME. The other doesn't use it as it is selected via patterns.

Now tracking in Trello to integrate this task in our scrum team workflow:

    https://trello.com/c/TSqEweVd

lightdm uses default.desktop as fallback. That one could be manged by update-alternatives.

(In reply to Ludwig Nussel from comment #21)
> lightdm uses default.desktop as fallback. That one could be manged by
> update-alternatives.

Another .desktop file in /usr/share/xsession? Pollutes the drop down selection of any DM that has a session picker... I vote against it

looks easy to adjust gdm-default-wm.patch to skip default.desktop in one place and use it in the other.

(In reply to Dominique Leuenberger from comment #22)
> (In reply to Ludwig Nussel from comment #21)
> > lightdm uses default.desktop as fallback. That one could be manged by
> > update-alternatives.
> 
> Another .desktop file in /usr/share/xsession? Pollutes the drop down
> selection of any DM that has a session picker... I vote against it

That can be fixed easily by looking at the file and if it's a symlink with target in the same directory, skip it. Needs to be implemented in the major DMs at least, so gdm, lightdm and sddm.

Also, currently sddm does not even look at the "Hidden=" property so in the default KDE Plasma install there are already two duplicates ("kde-plasma", "plasma5", "icewm" and "icewm-session") and nobody complained until now. Not that easy to fix as sddm's internal structure does not make it possible for a session to exist and not get shown to the user (urgh).

(In reply to Fabian Vogt from comment #24)
> (In reply to Dominique Leuenberger from comment #22)
> > (In reply to Ludwig Nussel from comment #21)
> > > lightdm uses default.desktop as fallback. That one could be manged by
> > > update-alternatives.
> > 
> > Another .desktop file in /usr/share/xsession? Pollutes the drop down
> > selection of any DM that has a session picker... I vote against it
> 
> That can be fixed easily by looking at the file and if it's a symlink with
> target in the same directory, skip it. Needs to be implemented in the major
> DMs at least, so gdm, lightdm and sddm.

I implemented it this way and for Xfce/LXQt/Plasma/IceWM and enlightenment in a home branch: https://build.opensuse.org/project/monitor/home:favogt:autologin

Please test and review before I make submit requests.

I made patches for sddm and lightdm, but am not familiar with gdm at all. I didn't add a default.desktop for GNOME because it doesn't work with anything other than GDM anyway (or did that get fixed meanwhile?)

WMs like IceWM have a default priority of 15, small desktops like LXQt, Xfce and enlightenment 20 and the two big ones GNOME and KDE Plasma have the highest priority of 25.

This is an autogenerated message for OBS integration:
This bug (1030873) was mentioned in
https://build.opensuse.org/request/show/495787 42.3 / plasma5-session

Except for icewm and lxqt-common all requests are now accepted in the devel projects and should arrive in factory soon, to be forwarded to 42.3 if it proves to work fine.

Great, thanks! If gdm needs fixes could you please open a separate bug for GDM and the gnome team, describing what needs to be done?

This is an autogenerated message for OBS integration:
This bug (1030873) was mentioned in
https://build.opensuse.org/request/show/497434 Factory / icewm

This is an autogenerated message for OBS integration:
This bug (1030873) was mentioned in
https://build.opensuse.org/request/show/500023 Factory / icewm

This is an autogenerated message for OBS integration:
This bug (1030873) was mentioned in
https://build.opensuse.org/request/show/500045 Factory / icewm

we are still failing to have auto-login but the SRs seem to be accepted -> https://openqa.opensuse.org/tests/420710#step/first_boot/21

what's missing?

(In reply to Oliver Kurz from comment #33)
> we are still failing to have auto-login but the SRs seem to be accepted ->
> https://openqa.opensuse.org/tests/420710#step/first_boot/21
> 
> what's missing?

Indeed, it looks like I changed it everywhere except for lxde, whoops.
I'll submit that soon.

(In reply to Fabian Vogt from comment #34)
> (In reply to Oliver Kurz from comment #33)
> > we are still failing to have auto-login but the SRs seem to be accepted ->
> > https://openqa.opensuse.org/tests/420710#step/first_boot/21
> > 
> > what's missing?
> 
> Indeed, it looks like I changed it everywhere except for lxde, whoops.
> I'll submit that soon.

0620 has the changed lxde-common merged - yet, autologin did not work, see

 https://openqa.opensuse.org/tests/425981#

Created attachment 729751 [details]
y2logs from a local reproducer

As noted, despite lxde now also setting up the default.desktop, this does not work.

While debugging this locally, it shows that /etc/sysconfig/windowmanager STILL has the default set to 'xfce' - even though xfce is not being installed in my local test.

/var/adm/filleup-templates/sysconfig.windowmanager (from aaa_base) has the defalut setting DEFAULT_WM="kde-plasma" - on my install /etc/sysconfig/windowmanager has DEFAULT_WM="xfce" - so definitively yast (or some thing else) must have changed the default.

Thanks. This is important to Leap 42.3

In my quick test:

Pattern selected for installation: patterns-openSUSE-lxde_laptop-20150918-26.5.x86_64.rpm

Logs say:
clients/desktop_finish.rb:128 Package xorg-x11-server selected or installed, desktop min_x matches
clients/desktop_finish.rb:136 Setting logon manager  - package selected
clients/desktop_finish.rb:142 Setting window manager icewm - package selected
clients/desktop_finish.rb:166 Default desktop: icewm
clients/desktop_finish.rb:167 Default logon manager:
clients/desktop_finish.rb:199 Logon manager shutdown:
clients/desktop_finish.rb:207 sysconfig/displaymanager/DISPLAYMANAGER=

And yes, for some reason, icewm-1.3.12-4.4.x86_64.rpm has been actually installed

The answer to WTF is here: https://github.com/yast/skelcd-control-openSUSE/blob/openSUSE-42_3/control/control.openSUSE.xml#L243-L253

And here: https://github.com/yast/yast-installation/blob/SLE-12-SP3/src/lib/installation/clients/desktop_finish.rb#L122-L164

Installer tries to match the "selected desktop" using "installed packages",
there is NO lxde definition in <supported_desktops/> so no wonder it's
not found.

Guys, as you know what to put there, would you mind creating a PR
for the control file change?

There's actually one thing that does not make sense to me. According to the
code, default desktop should the first one in the list, but ...

This

clients/desktop_finish.rb:118 Desktop order: ["min_x", "server", "kde", "gnome", "xfce", "min_x", "enlightenment"]

Comes from my test, and the control file for 42.3 contains
<default_desktop>kde</default_desktop>

(In reply to Lukas Ocilka from comment #38)
> In my quick test:
> 
> Pattern selected for installation:
> patterns-openSUSE-lxde_laptop-20150918-26.5.x86_64.rpm
> 
> Logs say:
> clients/desktop_finish.rb:128 Package xorg-x11-server selected or installed,
> desktop min_x matches
> clients/desktop_finish.rb:136 Setting logon manager  - package selected
> clients/desktop_finish.rb:142 Setting window manager icewm - package selected
> clients/desktop_finish.rb:166 Default desktop: icewm
> clients/desktop_finish.rb:167 Default logon manager:
> clients/desktop_finish.rb:199 Logon manager shutdown:
> clients/desktop_finish.rb:207 sysconfig/displaymanager/DISPLAYMANAGER=
> 
> And yes, for some reason, icewm-1.3.12-4.4.x86_64.rpm has been actually
> installed
> 
> The answer to WTF is here:
> https://github.com/yast/skelcd-control-openSUSE/blob/openSUSE-42_3/control/
> control.openSUSE.xml#L243-L253
> 
> And here:
> https://github.com/yast/yast-installation/blob/SLE-12-SP3/src/lib/
> installation/clients/desktop_finish.rb#L122-L164
> 
> Installer tries to match the "selected desktop" using "installed packages",
> there is NO lxde definition in <supported_desktops/> so no wonder it's
> not found.
> 
> Guys, as you know what to put there, would you mind creating a PR
> for the control file change?

this behavior is in fact wrong. If custom is selected, then no desktop should be selected and should be kept empty, so it should be autoselected.

see https://github.com/yast/yast-installation/blob/master/src/lib/installation/widgets/system_roles_radio_buttons.rb#L56

The answer is:

1. When I was installing the system, I chose "Min X server"
2. Then I selected the LXDE pattern
3. Additionally, "desktops" are sorter according to the order
   <order config:type="integer">1</order>
4. Three desktops have the same order
   <name>kde</name>
   <name>gnome</name>
   <name>server</name>
   (then they are "sorted" and the result is: "server", "kde", "gnome")

Possible solution in control file

1. Adjust sorting
2. Add more packages to <packages/>
3. Add LXDE

BTW, we are reaching limits of the old use cases combined with new(er)
role-selection dialog. They don't seem to play well together.

(In reply to Josef Reidinger from comment #40)
> this behavior is in fact wrong. If custom is selected, then no desktop
> should be selected and should be kept empty, so it should be autoselected.

I'm not getting your message ...

My behavior is wrong or the behavior of Yast or some particular behavior
of some part?

(In reply to Ludwig Nussel from comment #37)
> Thanks. This is important to Leap 42.3

Ludwig, this bug is reported for Tumbleweed. Leap uses different desktop
selection dialog. I was actually testing Leap DVD, instead of TW. But as
it seems, Josef talks about the TW behavior. This really makes a huge
difference. So, what are your expectations here?

Created attachment 729885 [details]
Different desktop selection dialogs: Leap vs TW

(In reply to Lukas Ocilka from comment #44)
> (In reply to Ludwig Nussel from comment #37)
> > Thanks. This is important to Leap 42.3
> 
> Ludwig, this bug is reported for Tumbleweed. Leap uses different desktop
> selection dialog. I was actually testing Leap DVD, instead of TW. But as
> it seems, Josef talks about the TW behavior. This really makes a huge
> difference. So, what are your expectations here?

we are talking about leap 42.3 and TW. There should be same dialog.

What I mean by previous sentence, is that new desktop selection intentionally set default desktop to nil and in such case I hope it skip writting it to /etc/sysconfig/windowmanager and it will select desktop according to default.desktop but maybe it is not that case. I have to check it

So result from my check of code.

new desktop selection use method SetDesktop
https://github.com/yast/yast-packager/blob/master/src/modules/DefaultDesktop.rb#L284 where is mentioned that nil means no desktop selected.

but later in finish client it will pick one, which is wrong:

https://github.com/yast/yast-installation/blob/master/src/lib/installation/clients/desktop_finish.rb#L84

so in fact fix should be to change this condition and skip finish client if Desktop is set to "nil" and let default.desktop decide instead of yast.

My apologies, I was testing some ancient build of Leap 42.3
(dist.suse.de is way obsolete now)

Anyway, thinking about Josef's solution... It may work, we only need
to make sure that we don't break SLE. The whole code in finish client
will need unit tests with these scenarios AND maybe even some refactoring.

short analysis of this bug from yast side.

Problem is that desktop finish client trying to quess desktop from some predefined packages and it won't work for all desktop. Correct behavior for it should be to not write anything if no desktop is selected.

The biggest challenge here is that same code also use SLED and SLES, so we have to be careful what is going to go there, to avoid breakage of it. One possibility is to have specific finish client on opensuse that replace one from SLE. So both code streams have own one.

Yes, this must work on 42.3.

The blind fallback to gnome doesn't make much sense either. To make the code handle nil is wrong on SLE anyways. The default on SLE is sle-classic rather than gnome. So there should be no harm done if nothing gets written.

Considering the current state, copy & paste (decoupling) is the best
way to change openSUSE behavior and keep SLE the same.

So back to comment#36 I wonder where the relation to SLE is. xfce is not on SLE yet we get this string set by yast on Leap. If we'd hit some SLE fallback code we'd see "gnome" according to the code referenced in commment#50.

Solution: Installer in Leap 42.3 will not write any default desktop
or other sysconfig values of no desktop has been selected. Installer
will not guess the desktop (and related settings) anymore in that case.

Considering SLE behavior - it will not change (SLE 12 SP3), but it will
change in SLE 15 where we plan to unify the solution with openSUSE.

(In reply to Dominique Leuenberger from comment #36)
> Created attachment 729751 [details]
> y2logs from a local reproducer
> 
> As noted, despite lxde now also setting up the default.desktop, this does
> not work.
> 
> While debugging this locally, it shows that /etc/sysconfig/windowmanager
> STILL has the default set to 'xfce' - even though xfce is not being
> installed in my local test.
> 
> /var/adm/filleup-templates/sysconfig.windowmanager (from aaa_base) has the
> defalut setting DEFAULT_WM="kde-plasma" - on my install
> /etc/sysconfig/windowmanager has DEFAULT_WM="xfce" - so definitively yast
> (or some thing else) must have changed the default.

I am testing my fix and it keeps there kde-plasma ( yast do not touch that file ) and result is that desktop env is icewm. So if needed, what should write there to have default.desktop working?

(In reply to Josef Reidinger from comment #56)
> 
> I am testing my fix and it keeps there kde-plasma ( yast do not touch that
> file ) and result is that desktop env is icewm. So if needed, what should
> write there to have default.desktop working?

From the tests I did, DEFAULT_WM should be set to "" - then default.desktop triggers (alternatively, we can also put 'default' - as in the end it just represents the .desktop file name

as for the current setting remaining kde_plasma, that makes sense, as this would now mean that the default is properly defined in /var/adm/filleup-templates/sysconfig.windowmanager (from aaa_base)

In the current versions, this file contains "kde-plasma"; if we need to change this to 'default' ot '', I don't see a problem doing so (and yast no longer changing it, unless a specific role was selected, i.e GNOME or KDE.

(In reply to Dominique Leuenberger from comment #58)
> as for the current setting remaining kde_plasma, that makes sense, as this
> would now mean that the default is properly defined in
> /var/adm/filleup-templates/sysconfig.windowmanager (from aaa_base)
> 
> In the current versions, this file contains "kde-plasma"; if we need to
> change this to 'default' ot '', I don't see a problem doing so (and yast no
> longer changing it, unless a specific role was selected, i.e GNOME or KDE.

that would be perfect. As change to yast2-installation have to go also to SP3 so I would like to have it minimal. For TW and SLE15 we can do whatever makes more sense. But keeping default defined by distro sounds very reasonable for me. So I will prepare pull request to SP3 and if you can modify aaa_base to contain e.g. that default.

Thanks

(In reply to Josef Reidinger from comment #59)
> that would be perfect. As change to yast2-installation have to go also to
> SP3 so I would like to have it minimal. For TW and SLE15 we can do whatever
> makes more sense. But keeping default defined by distro sounds very
> reasonable for me. So I will prepare pull request to SP3 and if you can
> modify aaa_base to contain e.g. that default.
> 
> Thanks

https://github.com/openSUSE/aaa_base/pull/42

IIRC, this still also requires a change in yast for TW, right? - as in my tests done so far the default was reset to XFCE for some reason

yes, yast change is at https://github.com/yast/yast-installation/pull/579

BTW I am targetting change to SP3, so probably also aaa_base have to be changed for leap42.3

YaST fix send to SP3 and also TW.

reassigning to dominique for aaa_base part.

In a discussion with Dominique we agreed for TW to

- get rid of DEFAULT_WM
- try to add some code to aaa_base to migrate the DEFAULT_WM setting to update-alternatives. aaa_base already needs coreutils which is the only dependency of update-alternatives anyways.
- remove the patch that reads DEFAULT_WM it from GDM
- make GDM fall back to default.desktop first, then potentially gnome.desktop
- apply the same logic to wayland sessions

SDDM already doesn't read DEFAULT_WM so broken in that regard already since it's introduction

(In reply to Ludwig Nussel from comment #63)
> In a discussion with Dominique we agreed for TW to
> 
> - get rid of DEFAULT_WM
> - try to add some code to aaa_base to migrate the DEFAULT_WM setting to
> update-alternatives. aaa_base already needs coreutils which is the only
> dependency of update-alternatives anyways.
> - remove the patch that reads DEFAULT_WM it from GDM
> - make GDM fall back to default.desktop first, then potentially gnome.desktop
> - apply the same logic to wayland sessions
> 
> SDDM already doesn't read DEFAULT_WM so broken in that regard already since
> it's introduction

well, in such case we have to update once more yast module, as we write DEFAULT_WM when user select other roles like KDE or GNOME. So if user select KDE role but install also GNOME pattern, what will be selected?

DEFAULT_WM would simply be deprecated and not be written/read at all anymore

Release Notes would need to be updated to indicate that the 'default' desktop is configured by means of update-alternatives, selecting the corresponding DE/WM

(In reply to Josef Reidinger from comment #64)
> [...]
> well, in such case we have to update once more yast module, as we write
> DEFAULT_WM when user select other roles like KDE or GNOME. So if user select
> KDE role but install also GNOME pattern, what will be selected?

Depends on the priorities of update-alternatives. Right now the value gets written but SDDM ignores it...

(In reply to Ludwig Nussel from comment #66)
> (In reply to Josef Reidinger from comment #64)
> > [...]
> > well, in such case we have to update once more yast module, as we write
> > DEFAULT_WM when user select other roles like KDE or GNOME. So if user select
> > KDE role but install also GNOME pattern, what will be selected?
> 
> Depends on the priorities of update-alternatives. Right now the value gets
> written but SDDM ignores it...

so role based desktop selection will be only about package selection, right?

Right now mostly yes. The server option also sets textmode for example

I think we can close this by now:

* the role based selector does not need to worry for it
* lightdm no longer reads /etc/sysconfig/windowmanager, but relies on /usr/share/xsessions/default.desktop, which in turn is handled by update-alternatives

As can be seen in openQA, the lxde tests are back to functional since those changes were introduced, meaning autologin for lxde is back operational oto

https://openqa.opensuse.org/tests/474741

This is an autogenerated message for OBS integration:
This bug (1030873) was mentioned in
https://build.opensuse.org/request/show/591767 15.0 / enlightenment

This is an autogenerated message for OBS integration:
This bug (1030873) was mentioned in
https://build.opensuse.org/request/show/611218 42.3 / lxqt-common

openSUSE-RU-2018:1476-1: An update that has two recommended fixes can now be installed.

Category: recommended (low)
Bug References: 1030873,1049719
CVE References: 
Sources used:
openSUSE Leap 42.3 (src):    lxqt-common-0.11.0-4.3.1

This is an autogenerated message for OBS integration:
This bug (1030873) was mentioned in
https://build.opensuse.org/request/show/809716 15.2 / enlightenment