October 2016 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1001790] kde "suspend when lid is closed" settings are ignored
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.opensuse.org/show_bug.cgi?id=1001790 http://bugzilla.opensuse.org/show_bug.cgi?id=1001790#c5 --- Comment #5 from Wolfgang Bauer <wbauer(a)tmo.at> --- (In reply to Adam Liebermann from comment #4) > > So I suppose we can close this then? > imo the more serious issue is ignoring kde settings as suspend is unreliable > in linux in general Well, I cannot confirm that, it works perfectly fine here (since years). But that might depend on the actual hardware of course. > and it should be possible to disable it at least. Yes. > > It's probably systemd's logind that's doing this. > > You can configure it in /etc/systemd/logind.conf though, see "man logind.conf", in particular the "HandleLidSwitch=" setting. > > do i understand it right, it's openSUSE's default configuration? AFAICS openSUSE doesn't change the upstream systemd defaults in 42.2. IOW, all options are commented out in /etc/systemd/logind.conf. According to the comments in the file, the upstream defaults seem to be: HandleLidSwitch=suspend HandleLidSwitchDocked=ignore LidSwitchIgnoreInhibited=yes So yes, logind automatically suspends if the lid is closed, unless the laptop is docked. And the last one (LidSwitchIgnoreInhibited=yes) is what the KDE bug report was about. Apparently this got ignored in systemd due to a bug that got "fixed" in 231, preventing KDE (and probably other desktops) to enforce their own settings regarding HandleLidSwitch. I have no idea about systemd's state in 42.2 regarding this though, and I don't have a laptop here to check. 42.2 comes with systemd 228 which should not be affected, but the "fix" may have been backported, I don't know. OTOH, there may have been a bug in Plasma/powerdevil 5.8 beta (which we currently have in 42.2), unfortunately I see no change in 5.8 final, but I cannot find an open KDE bug report about that either. > i suppose that would also affect other DEs like gnome, right? > shouldn't the default be changed to something that lets the desktop > environments decide? If I understand the mentioned KDE bug report correctly, KDE/powerdevil does inhibit logind's automatic lid handling. For other desktop environments I don't know, but I would be surprised if GNOME wouldn't do that as well. If the desktop doesn't support that (or there's no desktop running at all), logind takes over. This is not a bug but a feature, and IIRC there was some discussion about that a while ago, when it was introduced. But again, logind is configurable. And that's unrelated to KDE anyway. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1000988] YaST Software Management crashed on second start under KDE Session
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.suse.com/show_bug.cgi?id=1000988 http://bugzilla.suse.com/show_bug.cgi?id=1000988#c1 Imobach Gonzalez Sosa <igonzalezsosa(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |igonzalezsosa(a)suse.com, | |srid(a)rkmail.ru Flags| |needinfo?(srid(a)rkmail.ru) --- Comment #1 from Imobach Gonzalez Sosa <igonzalezsosa(a)suse.com> --- Hi Iakov, I've tried to reproduce this bug but it worked fine for me. Please, could you attach YaST2 logs so we can get more information? Please, check https://en.opensuse.org/openSUSE:Report_a_YaST_bug Make YaST crash and type "save_y2logs /tmp/y2logs.tgz". Then attach the resulting file (/tmp/y2logs.tgz). Thanks in advance! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 999123] kontact5 locks up on start
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.suse.com/show_bug.cgi?id=999123 http://bugzilla.suse.com/show_bug.cgi?id=999123#c5 --- Comment #5 from Wolfgang Bauer <wbauer(a)tmo.at> --- (In reply to Iakov Karpov from comment #4) > Still happens with openSUSE 42.2 Beta 2 (KDE Applications 16.08). It took > for me 20 minutes of killing/restarting akonadi to make kmail work. Was this a fresh installation, or an upgrade from Beta1? If you had a "broken" installation, an upgrade to Beta2 won't fix it either, because it has been decided to revive kdepim4 and therefore kdepim5 will still not replace kdepim4 automatically (which should have also fixed a mixup of packages). Can you please post a list of the installed akonadi/kdepim/baloo and kmail packages? rpm -qa | grep -ie "akonadi|kdepim|baloo|kmail" It should work fine in general now, at least the reporter of bug#996805 confirmed that. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1001790] kde "suspend when lid is closed" settings are ignored
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

1 0

[Bug 1002550] New: Qemu: net: Infinite loop in mcf_fec_do_tx
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.opensuse.org/show_bug.cgi?id=1002550 Bug ID: 1002550 Summary: Qemu: net: Infinite loop in mcf_fec_do_tx Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: mikhail.kasimov(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Reference: http://seclists.org/oss-sec/2016/q4/8 ================================================== Hello, Quick Emulator(Qemu) built with the ColdFire Fast Ethernet Controller emulator support is vulnerable to an infinite loop issue. It could occur while processing packets on the transmit queue in 'mcf_fec_do_tx'. A privileged user/process inside guest could use this issue to crash the Qemu process on the host leading to DoS. Upstream patch -------------- -> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05557.html This issue was reported by Li Qiang of 360.cn Inc. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F ================================================== -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1001790] laptop wakes up from suspend when laptop lid is closed after few secs and kde settings are ignored
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.opensuse.org/show_bug.cgi?id=1001790 http://bugzilla.opensuse.org/show_bug.cgi?id=1001790#c4 --- Comment #4 from Adam Liebermann <opensuse_org(a)xibo.at> --- > So I suppose we can close this then? imo the more serious issue is ignoring kde settings as suspend is unreliable in linux in general and it should be possible to disable it at least. > It's probably systemd's logind that's doing this. > You can configure it in /etc/systemd/logind.conf though, see "man logind.conf", in particular the "HandleLidSwitch=" setting. do i understand it right, it's openSUSE's default configuration? i suppose that would also affect other DEs like gnome, right? shouldn't the default be changed to something that lets the desktop environments decide? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1002557] New: Qemu: net: pcnet: infinite loop in pcnet_rdra_addr
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.opensuse.org/show_bug.cgi?id=1002557 Bug ID: 1002557 Summary: Qemu: net: pcnet: infinite loop in pcnet_rdra_addr Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: mikhail.kasimov(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Reference: http://seclists.org/oss-sec/2016/q4/9 ================================================= Hello, Quick Emulator(Qemu) built with the AMD PC-Net II emulator support is vulnerable to an infinite loop issue. It could occur while receiving packets via pcnet_receive(). A privileged user/process inside guest could use this issue to crash the Qemu process on the host leading to DoS. Upstream patch -------------- -> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07942.html This issue was reported by Li Qiang of 360.cn Inc. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F ================================================= -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1002549] New: Qemu: net: inifinte loop in imx_fec_do_tx() function
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.opensuse.org/show_bug.cgi?id=1002549 Bug ID: 1002549 Summary: Qemu: net: inifinte loop in imx_fec_do_tx() function Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: mikhail.kasimov(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Reference: http://seclists.org/oss-sec/2016/q4/7 ======================== Hello, Quick Emulator(Qemu) built with the i.MX Fast Ethernet Controller emulator support is vulnerable to an infinite loop issue. It could occur while processing packets on the transmit queue in 'imx_fec_do_tx'. A privileged user/process inside guest could use this issue to crash the Qemu process on the host leading to DoS. Upstream patch -------------- -> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05556.html This issue was reported by Li Qiang of 360.cn Inc. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F ======================== -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 954143] Leap (KDE5) doesn't know what to do with an .rpm file. Chrome 64bit and Skype tested.
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.suse.com/show_bug.cgi?id=954143 http://bugzilla.suse.com/show_bug.cgi?id=954143#c23 Ancor Gonzalez Sosa <ancor(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maintenance(a)opensuse.org Flags| |needinfo?(maintenance@opens | |use.org) --- Comment #23 from Ancor Gonzalez Sosa <ancor(a)suse.com> --- I'm all for changing this for TW, SLE-12-SP2 and Leap 42.2. I'm not sure whether it makes sense to release the "fix" for 42.1. It would be actually introducing a change in behavior, something not expected in a stable release. Maintenance updates are meant for real breakage or security problems, not to change the behavior (like file associations) to something more convenient. Anyways, I will leave that for the maintenance team to decide (putting needinfo). On the other hand, I trying to adapt to contributed fix to also handle the situation commented in comment#22. The solution suggested in that comment (introducing a new package including a script to handle the command line) looks a little bit overkill. I'm trying to fix it only in the desktop file. The desktop file as it is now in Tumbleweed works with Thunar (XFCE file manager) even if there are spaces, but not in Dolphin (KDE one). -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1002583] New: gem2rpm - old opensuse.spec.erb template
by bugzilla_noreply＠novell.com 03 Oct '16

03 Oct '16

http://bugzilla.suse.com/show_bug.cgi?id=1002583 Bug ID: 1002583 Summary: gem2rpm - old opensuse.spec.erb template Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: mrueckert(a)suse.com Reporter: kstreitova(a)suse.com QA Contact: qa-bugs(a)suse.de CC: tampakrap(a)opensuse.org Found By: --- Blocker: --- It seems that rubygem-gem2rpm package for openSUSE:Leap (and openSUSE:13.2) contains a different opensuse.spec.erb template than it is in openSUSE:Tumbleweed. This causes that one can't use openSUSE:Leap for generating a specfile from gem for those specfiles that were previously generated within gem2rpm on openSUSE:Tumbleweed (e.g. rubygem-puppet package). Is it possible to synchronize them? Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

1 0