June 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1043266] Port KDE Plasma 5.8.7 LTS release to Leap 42.2
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043266 http://bugzilla.suse.com/show_bug.cgi?id=1043266#c1 Fabian Vogt <fabian(a)ritter-vogt.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |captainuppervolta(a)hotmail.c | |om, fabian(a)ritter-vogt.de Flags| |needinfo?(captainuppervolta | |(a)hotmail.com) Severity|Critical |Normal --- Comment #1 from Fabian Vogt <fabian(a)ritter-vogt.de> --- (In reply to Fred Brubine from comment #0) > Bugfix release 5.8.7 contains critical fixes, and was released on 5/23/2017 > but is still not showing up in yast2 as available for my OpenSUSE 42.2 > 64-bit installation. > http://news.softpedia.com/news/kde-plasma-5-8-7-lts-desktop-environment- > released-with-over-60-improvements-515970.shtml I don't see any critical fixes we don't already have in our packages, so for now I don't think it's necessary. Which fixes are you referring to? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1037891] All YaST module window names show "ruby" instead of a more specifc name (was: Yast module windows in Plasma: generic x window icon and grouped as "ruby" in task manager)
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1037891 http://bugzilla.suse.com/show_bug.cgi?id=1037891#c21 --- Comment #21 from Josef Reidinger <jreidinger(a)suse.com> --- ok, so we at least move forward. I will check this icon issue, how to do it in qt properly. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1003964] CVE-2016-7039: Kernel: net: unbounded recursion in the vlan GRO processing
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

1 0

[Bug 1042529] YaST submodule windows don't remember their size and position when opened as standalone programs
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1042529 http://bugzilla.suse.com/show_bug.cgi?id=1042529#c2 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #2 from Stefan Hundhammer <shundhammer(a)suse.com> --- We could use the window title as a handle to identify different main windows. Based on that, we would need to use QSettings (which is quite trivial) to store and retrieve window position and size for each of those main windows. http://doc.qt.io/qt-5/qsettings.html QSettings uses .ini file format, but in addition to the usual settings groups, you can use paths for each key. We could normalize the window title (replace all nonstandard characters that won't work for a key with "_", for example) and use that as a path component for settings keys, e.g. /main_win/my_window_title/pos /main_win/my_window_title/size There are very likely limitations that we would have to accept, such as all those values getting invalid when the system language changes because the UI only gets the translated window title (which would change in that case). Restoring both position and size when opening a window is quite trivial. Storing them would have to be done in that window's destructor which might depend on the lifetime of that window being as long as that module runs (which is always the case IMHO). When there are multiple main windows in the same module, however, it might get somewhat inconsistent. All in all I'd guess this is one day initial work and then one or two additional days for fiddling with fringe cases we'd discover while testing it for different modules and different desktop environments / window managers. One caveat is that since YaST is always running as root, the settings would be stored in root's home directory, i.e. they would be shared amont all users on that machine that use YaST. For normal PCs, this is a non-issue, but for real multi-user environments this might become somewhat annoying. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043113] New: Impossible to install libudev-devel without first downgrading libudev1
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.opensuse.org/show_bug.cgi?id=1043113 Bug ID: 1043113 Summary: Impossible to install libudev-devel without first downgrading libudev1 Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: ncutler(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This is on a vanilla Leap 42.3 VM in OpenStack (using a very recent Leap 42.3 OpenStack image from OBS): libudev1 in installed (it's part of the base system). Notice the version number 228-26.4 target137074025075:/home/ubuntu # zypper up libudev1 Loading repository data... Reading installed packages... No update candidate for 'libudev1-228-26.4.x86_64'. The highest available version is already installed. Resolving package dependencies... Nothing to do. In order to build something from source, I need libudev-devel. But it cannot be installed without first downgrading libudev1: target137074025075:/home/ubuntu # zypper in libudev-devel Loading repository data... Reading installed packages... Resolving package dependencies... Problem: libudev-devel-228-26.3.x86_64 requires libudev1 = 228-26.3, but this requirement cannot be provided uninstallable providers: libudev1-228-26.3.x86_64[openSUSE-Leap-42.3-Oss] Solution 1: downgrade of libudev1-228-26.4.x86_64 to libudev1-228-26.3.x86_64 Solution 2: do not install libudev-devel-228-26.3.x86_64 Solution 3: break libudev-devel-228-26.3.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c] (c): -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1043338] New: spelling error in packages-i18n-libqt - entry 40
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.opensuse.org/show_bug.cgi?id=1043338 Bug ID: 1043338 Summary: spelling error in packages-i18n-libqt - entry 40 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: ada.lovelace(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build Identifier: I found a spelling error during translations in libqt: The Qt 5 DBus library - development files. Aditionally, it contains Qt5's qdbusxml2cpp and qdbuscpp2xml binaries. You should use "Additionally" instead of "Aditionally". Reproducible: Always Steps to Reproduce: 1. Use libqt 2. Read packages-i18n/libqt (entry 40) Actual Results: spelling error -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 987184] CryptLVM installation does not work on new install if the HDD contains old LVM setup
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=987184 Ludwig Nussel <lnussel(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 987184] CryptLVM installation does not work on new install if the HDD contains old LVM setup
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=987184 http://bugzilla.suse.com/show_bug.cgi?id=987184#c8 --- Comment #8 from Oliver Kurz <okurz(a)suse.com> --- Created attachment 728207 --> http://bugzilla.suse.com/attachment.cgi?id=728207&action=edit ylog of issue on openSUSE Leap 42.3 current build I could reproduce the issue on the most recent openSUSE Leap 42.3 build. y2logs attached. Last lines there: ``` 2017-06-08 04:31:58 <1> hp(3770) [libstorage] Storage.cc(setCryptType):2870 device:/dev/sda2 val:true enc_type:luks 2017-06-08 04:31:58 <1> hp(3770) [libstorage] Storage.cc(findVolume):6564 device:/dev/sda2 ret:true c->device:/dev/sda v->device:/dev/sda2 2017-06-08 04:31:58 <1> hp(3770) [libstorage] Volume.cc(setEncryption):1843 val:true typ:luks 2017-06-08 04:31:58 <1> hp(3770) [libstorage] Volume.cc(isTmpCryptMp):3755 find mp: ret:false 2017-06-08 04:31:58 <1> hp(3770) [libstorage] Volume.cc(setEncryption):1890 ret:-3014 2017-06-08 04:31:58 <1> hp(3770) [libstorage] Storage.cc(setCryptType):2891 ret:-3014 2017-06-08 04:31:58 <3> hp(3770) [Ruby] modules/Storage.rb:2689 SetCrypt sint ret: -3014 ``` -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1037891] All YaST module window names show "ruby" instead of a more specifc name (was: Yast module windows in Plasma: generic x window icon and grouped as "ruby" in task manager)
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1037891 http://bugzilla.suse.com/show_bug.cgi?id=1037891#c20 --- Comment #20 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Josef Reidinger from comment #19) > Now I am totally confused. You mention, that it blocks 42.3 accept of new > ruby bindings, so how TW can block it? The presence of this bug and no confirmed fix blocked it. Due to the SLE update crawler the updated package slipped unintentionally into 42.3 already though, so I declined the blocked sr yesterday already. > BTW I found that that also TW now have the latest ruby-bindings[1], so only > remaining issue is original one with behavior in KDE. Indeed, the current openQA run confirms this: https://openqa.opensuse.org/tests/416559#step/live_installation/11 While the window title is now correct, the window icon is still wrong. So only the original issue with the invalid WM_CLASS remains. > [1] > https://build.opensuse.org/package/show/openSUSE:Factory/yast2-ruby-bindings -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1037891] All YaST module window names show "ruby" instead of a more specifc name (was: Yast module windows in Plasma: generic x window icon and grouped as "ruby" in task manager)
by bugzilla_noreply＠novell.com 08 Jun '17

08 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1037891 http://bugzilla.suse.com/show_bug.cgi?id=1037891#c19 --- Comment #19 from Josef Reidinger <jreidinger(a)suse.com> --- Now I am totally confused. You mention, that it blocks 42.3 accept of new ruby bindings, so how TW can block it? BTW I found that that also TW now have the latest ruby-bindings[1], so only remaining issue is original one with behavior in KDE. [1] https://build.opensuse.org/package/show/openSUSE:Factory/yast2-ruby-bindings -- You are receiving this mail because: You are on the CC list for the bug.

1 0