January 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 989501] WARNING: CPU: 0 PID: 1690 at ../drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank+0x175/0x180 [drm]()
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.suse.com/show_bug.cgi?id=989501 http://bugzilla.suse.com/show_bug.cgi?id=989501#c22 --- Comment #22 from Nick Battle <nick.battle(a)gmail.com> --- I've tried this in 42.2 and I can't reproduce the issue. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1017783] Boot issues with Tumbleweed and Kernel 4.9 (booting stops at Loading initial ramdisk; kernel 4.9 does not boot)
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.opensuse.org/show_bug.cgi?id=1017783 http://bugzilla.opensuse.org/show_bug.cgi?id=1017783#c15 --- Comment #15 from Steve Wickert <steve.wickert(a)gmail.com> --- Apparently also having problems on Lenovo ThinkPad E570. I happened to be doing a new install yesterday on this new machine (just before the latest kernel update), and everything was fine. Now it won't boot from the internal disk. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 974762] New: kscreen permanently 'changes' the output
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.opensuse.org/show_bug.cgi?id=974762 Bug ID: 974762 Summary: kscreen permanently 'changes' the output Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: P.Suetterlin(a)royac.iac.es QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- My .xsession-errors are being filled (flooded - some 10 lines every few seconds) with messages kscreen: Primary output changed from KScreen::Output(Id: 448 , Name: "HDMI-0" ) ( "HDMI-0" ) to KScreen::Output(Id: 448 , Name: "HDMI-0" ) ( "HDMI-0" ) kscreen.kded: Change detected kscreen.kded: Saving current config to file kscreen.kded: Calculating config ID for KScreen::Config(0x195e940) kscreen.kded: Part of the Id: "e028b5cdfc5db2adad6d865224cc04a5" kscreen.kded: Config ID: "bee38305645990637e26de8f88c547ba" kscreen.kded: Config saved on: "/home/pit/.local/share/kscreen/bee38305645990637e26de8f88c547ba" See https://bugs.kde.org/show_bug.cgi?id=355928 The thread offers a partial solution (disabling debug messages from QT) and claims it is fixed in plasma 5.6. I am not sure if Leap will get an update to 5.6 (will it?) - some measure against the log-flooding and permanent config-writing would be nice -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 967260] emacs 24.3 tramp session crashes with backtrace
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.suse.com/show_bug.cgi?id=967260 http://bugzilla.suse.com/show_bug.cgi?id=967260#c7 --- Comment #7 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-RU-2017:0037-1: An update that has three recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1013572,1013849,967260 CVE References: Sources used: SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): emacs-24.3-19.2 SUSE Linux Enterprise Server 12-SP2 (src): emacs-24.3-19.2 SUSE Linux Enterprise Server 12-SP1 (src): emacs-24.3-19.2 SUSE Linux Enterprise Desktop 12-SP2 (src): emacs-24.3-19.2 SUSE Linux Enterprise Desktop 12-SP1 (src): emacs-24.3-19.2 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 909418] when ejecting DVD using hardware button, system thinks DVD is still mounted
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.suse.com/show_bug.cgi?id=909418 Andreas Stieger <astieger(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |1018399 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1018399] New: SUSE-RU-2017:0013-1 causes assert in PID1
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.opensuse.org/show_bug.cgi?id=1018399 Bug ID: 1018399 Summary: SUSE-RU-2017:0013-1 causes assert in PID1 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: SLES 12 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: wullinger(a)rz.uni-kiel.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:50.0) Gecko/20100101 Firefox/50.0 Build Identifier: As requested, this is a new bug report wrt to the update supposed to fix bug 909418 [https://bugzilla.suse.com/show_bug.cgi?id=909418] The "bound device" update seems not to properly handle the case when the device is already gone by the time the mount unit is updates. In particular Dell (and other) servers come with a virtual USB device in their remote access controllers. These frequently get mounted under /tmp/SECUPD by the official utilities, usually from /dev/sdb?. However, the device sometimes seems to disappear while still mounted. As of suse-ru-20170013-1, which imports commit ebc8968bc0b6fc460099041f5ae1262ca17eeb6e, this results in an unmanageable machine, because systemd ABRTs in PID 1. Relevant journal entries: systemd[11505]: Assertion 'dev' failed at src/core/device.c:301, function device_is_bound_by_mounts(). Aborting. FAT-fs (sdc): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. systemd[1]: Assertion 'dev' failed at src/core/device.c:301, function device_is_bound_by_mounts(). Aborting. systemd[1]: Caught <ABRT>, dumped core as pid 30128. systemd[1]: Freezing execution. At this point in time /tmp/SECUPD still appears mounted at can be unmounted. Problematic code path: It looks like it is valid for dev to be NULL in device_setup_unit(Manager *m, struct udev_device *dev, const char *path, bool main). At least there are various guards with if (dev) in the source. This is not checked before the (new) call to device_is_bound_by_mounts(), which itself does assert(dev). As a result, PID1 aborts and the system cannot be managed any more. I'm not familiar with the new logic, but the fix may be a simple guard condition inside device_is_bound_by_mounts(). Reproducible: Always Steps to Reproduce: 1. Have a Dell Server 2. Install SLES 12 3. Have Dell tools installed and started at boot 4. Install suse-ru-20170013-1 Actual Results: Systemd asserts in PID1 with systemd[11505]: Assertion 'dev' failed at src/core/device.c:301, function device_is_bound_by_mounts(). Aborting. systemd[1]: Assertion 'dev' failed at src/core/device.c:301, function device_is_bound_by_mounts(). Aborting. systemd[1]: Caught <ABRT>, dumped core as pid 30128. systemd[1]: Freezing execution. System is unmanagable, must be hard rebooted (systemctl -ff reboot) Expected Results: System remains in good health. Possibly: Filesystem is unmounted. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1018120] tolua++: version/date in generated code
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.suse.com/show_bug.cgi?id=1018120 http://bugzilla.suse.com/show_bug.cgi?id=1018120#c4 --- Comment #4 from Andreas Stieger <astieger(a)suse.com> --- The OpenQA failure is simply due to zypper preferring the package obsoleting package over the obsoleted one, on 42.2: https://openqa.opensuse.org/tests?match=%3A448753.tolua%2B%2B.6157 https://openqa.opensuse.org/tests/329242#step/qam_zypper_patch/1 Can you help me understand where conky gets republished? Is it server:monitoring/conky? Several issues here: osc buildinfo server:monitoring conky openSUSE_Leap_42.2 x86_64 | grep tolua <bdep name="tolua++" version="1.0.93" release="16.20" arch="x86_64" project="openSUSE:Leap:42.2" repository="standard" / This will not even an updated tolua++ package. Second, in 42.2 tolua++ was dropped in favor of lua51-toluapp. in the conky spec (for Factory): %if 0%{?suse_version} > 1320 || 0%{?suse_version} == 1315 && 0%{?is_opensuse} != 1 BuildRequires: libtolua++-5_1-devel %else BuildRequires: tolua++ %endif This could be tweaked, both in conky.spec and locally by preferring lua51-toluapp always. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1017841] New: [TRACKERBUG] Testing openSUSE Leap 42.3 Software Stack
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.suse.com/show_bug.cgi?id=1017841 Bug ID: 1017841 Summary: [TRACKERBUG] Testing openSUSE Leap 42.3 Software Stack Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other URL: https://progress.opensuse.org/issues/15728 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Maintenance Assignee: astieger(a)suse.com Reporter: astieger(a)suse.com QA Contact: qa-bugs(a)suse.de CC: lnussel(a)suse.com, maintenance(a)opensuse.org Found By: --- Blocker: --- This is the trackerbug for testing the Software Stack of openSUSE Leap 42.3. https://progress.opensuse.org/issues/15728 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1017360] Nvidia Community Repository has no option for 32-bit libraries
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.suse.com/show_bug.cgi?id=1017360 http://bugzilla.suse.com/show_bug.cgi?id=1017360#c4 Robert Nelson <rnelson(a)airflowsciences.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(rnelson@airflowsc | |iences.com) | --- Comment #4 from Robert Nelson <rnelson(a)airflowsciences.com> --- Bingo! You are right, they must not be referencing /etc/ld.so.conf.d in their dlopen() calls (which I agree is an application bug). When I run the following script, all is well: for i in libEGL_nvidia.so.0 libEGL.so.1 libGLdispatch.so.0 \ libGLESv1_CM_nvidia.so.1 libGLESv1_CM.so.1 libGLESv2_nvidia.so.2 libGLESv2.so.2 \ libGL.la libGL.so libGL.so.1 libGLX_nvidia.so.0 libOpenGL.so.0 do rm -f /usr/lib64/${i} ln -s /usr/X11R6/lib64/${i} /usr/lib64 done I did it this way instead of copying or linking everything, since with just these links, things will continue to work when a new version of the Nvidia driver comes out. However, updates to any of these /usr/lib64 files from other repositories (e.g., the one with the nouveau drivers) could replace my links, making things break again until the script is rerun. Still, this is better than having to go to nvidia.com and download and run their driver script with every update. The nvidia.com install apparently installs everything in /usr/lib and /usr/lib64, so this problem doesn't come up. Is there a reason the community repository doesn't do it this way? Perhaps you were trying to avoid the problem with updates from other repositories. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1018120] tolua++: version/date in generated code
by bugzilla_noreply＠novell.com 05 Jan '17

05 Jan '17

http://bugzilla.suse.com/show_bug.cgi?id=1018120 http://bugzilla.suse.com/show_bug.cgi?id=1018120#c3 --- Comment #3 from Olaf Hering <ohering(a)suse.com> --- lua51-toluapp/lua51-toluapp.spec has: Version: 1.0.93 %package -n toluapp-%{lua_major_version} Provides: tolua++ = %{version}-99.1 Obsoletes: tolua++ < %{version}-99.1 tolua++/tolua++.spec has: Version: 1.0.93 So one replaces the other. And conky/conky.spec has: BuildRequires: tolua++ So it gets republished all day. -- You are receiving this mail because: You are on the CC list for the bug.

1 0