January 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 856655] New: color selection script in Vim menu.vim generates syntax errors
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=856655 https://bugzilla.novell.com/show_bug.cgi?id=856655#c0 Summary: color selection script in Vim menu.vim generates syntax errors Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: suse(a)tlinx.org QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 In installing vim 7.4.052 I get a menu.vim that has errors in it when vim (or gvim) starts: > gvim menu.vim Error detected while processing /usr/share/vim/vim/menu.vim: line 354: E327: Part of menu-item path is not sub-menu The offending lines (commented out in my version) "" Setup the Edit.Color Scheme submenu "" get NL separated string with file names "let s:n = globpath(&runtimepath, "colors/*.vim") " "" split at NL, Ignore case for VMS and windows, sort on name "let s:names = sort(map(split(s:n, "\n"), 'substitute(v:val, "\\c.*[/\\\\:\\]]\\([^/\\\\:]*\\)\\.vim", "\\1", "")'), 1) " "" define all the submenu entries "let s:idx = 100 "for s:name in s:names " exe "an 20.450." . s:idx . ' &Edit.C&olor\ Scheme.' . s:name . " :colors " . s:name . "<CR>" " let s:idx = s:idx + 10 "endfor "unlet s:name s:names s:n s:idx " -------------- I guess the above allows some nifty color selection -- but unfortunately it seems to generate an annoying error message. Commenting it out isn't a solution, but it works if you don't need the functionality... Reproducible: Always Steps to Reproduce: 1. install vim/gvim; run vim/gvim; error message is shown in starting window 2. 3. Actual Results: get error message Expected Results: vim/gvim starts immediately w/no error messages -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 3

[Bug 855454] New: Kernel Driver for NVIDIA 96.43.23 missing
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=855454 https://bugzilla.novell.com/show_bug.cgi?id=855454#c0 Summary: Kernel Driver for NVIDIA 96.43.23 missing Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: i586 OS/Version: openSUSE 13.1 Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: kschwi(a)web.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0 Installation of NVIDIA Driver 96.43.23 finds depencies to nvidia-gfx-kmp = 96.43.23. There is no kernel driver for this graphic driver available in the reposiotory. Reproducible: Always Steps to Reproduce: 1. Install x11-video-nvidia-96.43.23-23.1.i586.rpm 2. 3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 8

[Bug 858713] New: openSUSE:13.1/mozjs17 build is corrupted, only contains one file
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=858713 https://bugzilla.novell.com/show_bug.cgi?id=858713#c0 Summary: openSUSE:13.1/mozjs17 build is corrupted, only contains one file Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: BuildService AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: lazytiger(a)gmx.net QAContact: adrian(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 The rpm only contains the file "/usr/share/doc/packages/mozjs17/README.html" but there should be a lot more (e.g. the "js17" binary)! See https://build.opensuse.org/package/show/openSUSE:13.1/mozjs17 Faulty RPM: http://download.opensuse.org/distribution/13.1/repo/oss/suse/x86_64/mozjs17… Reproducible: Always Also, the mozjs17.spec isn't running autoconf-2.13 like the manual suggests under https://developer.mozilla.org/en-US/docs/SpiderMonkey/Build_Documentation (but I'm not very familiar with creating RPMs so I don't know if it's a bug or not) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 3

[Bug 837609] VUL-1: CVE-2013-4400: libvirt: libvirt 1.1.2 contains new setuid binary
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=837609 https://bugzilla.novell.com/show_bug.cgi?id=837609#c28 James Fehlig <jfehlig(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|security-team(a)suse.de |jfehlig(a)suse.com --- Comment #28 from James Fehlig <jfehlig(a)suse.com> 2014-01-15 15:24:22 UTC --- It is still installed with normal permissions (and hence useless) due to the issue I noted in #24. I'll have to do some spec file hackery to handle the build failure on SLE11, e.g. don't even build virt-login-shell on SLE11. I suppose I should take this bug again until that is fixed... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 854116] New: cannot uninstall libvirt-daemon
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=854116 https://bugzilla.novell.com/show_bug.cgi?id=854116#c0 Summary: cannot uninstall libvirt-daemon Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: KVM AssignedTo: jfehlig(a)suse.com ReportedBy: dmueller(a)suse.com QAContact: jdouglas(a)suse.com Found By: --- Blocker: --- rpm -e libvirt-daemon redirecting to systemctl stop libvirtd Skipped: virtlockd is overwritten by a native systemd unit error: %preun(libvirt-daemon-1.1.2-9.1.x86_64) scriptlet failed, exit status 2 error: libvirt-daemon-1.1.2-9.1.x86_64: erase failed -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 2

[Bug 803002] New: smpppd does not configure pppd to reconnect after LCP echo failures due to heavy load
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=803002 https://bugzilla.novell.com/show_bug.cgi?id=803002#c0 Summary: smpppd does not configure pppd to reconnect after LCP echo failures due to heavy load Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: PC OS/Version: openSUSE 12.1 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: archie(a)dellroad.org QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0 I have openSUSE configured to connect over a DSL line via PPPoE: # /etc/sysconfig/network/ifcfg-dsl0 BOOTPROTO='none' DEVICE='eth0' MODEM_IP='10.0.0.13' NAME='DSL Connection' PPPD_OPTIONS='' PPPMODE='pppoe' PROVIDER='provider5' STARTMODE='auto' UDI='' USERCONTROL='yes' VPIVCI='8/35' When the eth0 ethernet interface comes up, the pppd process is properly started, it connects, and everything is great. Running pstree shows that things are working: |-smpppd-ifcfg --up --rc -i ifcfg-dsl0 | `-pppd logfd 7 call pppoe eth0 mtu 1492 mru 1492 ipcp-accept-local ipcp-accept-remote idle 900 defaultroute replacedefaultroute nodetach usepeerdns ifname dsl0 ipparam 'ifcfg-dsl0' 'provider5' user username(a)example.com passwordfd 8 However, when there is heavy download traffic on the line, sometimes four consecutive LCP echo request and/or reply packets will get dropped, causing the PPP session to terminate (see logs starting at 21:43:13): Feb 9 20:21:03 rebound pppd[15791]: Plugin rp-pppoe.so loaded. Feb 9 20:21:03 rebound pppd[15791]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5 Feb 9 20:21:03 rebound pppd[15791]: Plugin passwordfd.so loaded. Feb 9 20:21:03 rebound pppd[15791]: pppd 2.4.5 started by root, uid 0 Feb 9 20:21:08 rebound pppd[15791]: PPP session is 1893 Feb 9 20:21:08 rebound pppd[15791]: Connected to 00:30:83:16:3d:43 via interface eth0 Feb 9 20:21:08 rebound pppd[15791]: Renamed interface ppp0 to dsl0 Feb 9 20:21:08 rebound pppd[15791]: Using interface dsl0 Feb 9 20:21:08 rebound pppd[15791]: Connect: dsl0 <--> eth0 Feb 9 20:21:08 rebound pppd[15791]: CHAP authentication succeeded: CHAP authentication success, unit 13425 Feb 9 20:21:08 rebound pppd[15791]: CHAP authentication succeeded Feb 9 20:21:08 rebound pppd[15791]: peer from calling number 00:30:83:16:3D:43 authorized Feb 9 20:21:09 rebound pppd[15791]: local IP address 1.2.3.4 Feb 9 20:21:09 rebound pppd[15791]: remote IP address 5.6.7.8 Feb 9 20:21:09 rebound pppd[15791]: primary DNS address 2.2.2.2 Feb 9 20:21:09 rebound pppd[15791]: secondary DNS address 2.2.2.3 Feb 9 20:21:09 rebound pppd[15791]: Script /etc/ppp/ip-up finished (pid 15971), status = 0x0 Feb 9 21:43:13 rebound pppd[15791]: No response to 4 echo-requests Feb 9 21:43:13 rebound pppd[15791]: Serial link appears to be disconnected. Feb 9 21:43:13 rebound pppd[15791]: Connect time 82.1 minutes. Feb 9 21:43:13 rebound pppd[15791]: Sent 20606504 bytes, received 463895045 bytes. Feb 9 21:43:13 rebound pppd[15791]: Connection terminated. Feb 9 21:43:14 rebound pppd[15791]: Script /etc/ppp/ip-down finished (pid 16478), status = 0x0 Feb 9 21:43:14 rebound pppd[15791]: Exit. At this point, the DSL connection is dead and will never come back. I have to then go down into the basement and manually restart networking (or, at least the ethernet interface). This is a bug. The connection should automatically reconnect in this situation. >From my research, the solution to this is to provide the persist option to pppd: persist Do not exit after a connection is terminated; instead try to reopen the connection. Apparently this can be done explicitly by smppd-ifcfg or by adding "persist" to /etc/ppp/options. However, I haven't fully tested this but it seems like it should work. Reproducible: Always Steps to Reproduce: 1. Configured DSL line over PPPoE 2. Create heavy traffic in both directions 3. Wait an hour or two for 4 consecutive PPP LCP echo failures 4. Watch the DSL line go down and never recover Actual Results: Feb 9 21:43:13 rebound pppd[15791]: Connection terminated. Feb 9 21:43:14 rebound pppd[15791]: Script /etc/ppp/ip-down finished (pid 16478), status = 0x0 Feb 9 21:43:14 rebound pppd[15791]: Exit. Expected Results: Should have reconnected. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11

[Bug 753932] New: DST (Europe) - Time correctly changes at midnight, but its reset to previous setting on reboot
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c0 Summary: DST (Europe) - Time correctly changes at midnight, but its reset to previous setting on reboot Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: openSUSE 12.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jorge.adriano(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 It's always been this way for me in openSUSE. At midnight the time on my clock will correctly fast forward one hour. I finish work, shutdown. When I reboot the next day the clock is back to pre-DST, i.e. one hour late. Reproducible: Always Steps to Reproduce: 1. Go back to the 24th of March and wait for midnight I guess 2. Shutdown computer 3. Reboot Actual Results: Wrong time Expected Results: Correct time -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 63

[Bug 749706] New: systemd-cryptsetup ignores timeout parameter of /etc/crypttab
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=749706 https://bugzilla.novell.com/show_bug.cgi?id=749706#c0 Summary: systemd-cryptsetup ignores timeout parameter of /etc/crypttab Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: openSUSE 12.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: endym(a)gmx.net QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 In the openSUSE 12.1 installation I chose to encrypt the whole home partition. When booting the systemd cryptsetup.service ask for the passphrase. If the passphrase is not entered within about 80 seconds, the boot process continues automatically (of course without mounting the home partition) to the user login screen (KDM). This behavior is very annoying because of: 1. an average user will login now and will not see his normal desktop, but a fresh KDE desktop without access to his data 2. if you are not root you have to reboot now To disable the timeout I added the option "timeout=0" in /etc/crypttab (fourth parameter): cat /etc/crypttab cr_sdb3 /dev/disk/by-id/ata-WDC_WD2500BEVS-60UST0_WD-WXE808P0A960-part3 none timeout=0 But this does not change anything. The timeout is still enabled. dmesg (after timeout): systemd[1]: Job dev-mapper-cr_sdb3.device/start timed out. systemd[1]: Job cryptsetup(a)cr_sdb3.service/start failed with result 'dependency'. systemd[1]: Job home.mount/start failed with result 'dependency'. systemd[1]: Job fsck(a)dev-mapper-cr_sdb3.service/start failed with result 'dependency'. systemd[1]: Job dev-mapper-cr_sdb3.device/start failed with result 'timeout'. systemd-cryptsetup[1882]: Timed out systemd-cryptsetup[1882]: Failed to query password: Timer expired systemd[1]: cryptsetup(a)cr_sdb3.service: main process exited, code=exited, status=1 systemd[1]: Unit cryptsetup(a)cr_sdb3.service entered failed state. rpm -q systemd: systemd-37-3.6.1.x86_64 uname -srvom: Linux 3.1.9-1.4-desktop #1 SMP PREEMPT Fri Jan 27 08:55:10 UTC 2012 (efb5ff4) x86_64 GNU/Linux Reproducible: Always Steps to Reproduce: 1. Encrypt the home partition with the YaST partition manager 2. Add the option "timeout=0" in /etc/crypttab (fourth parameter) 3. Reboot 4. Do not enter the passphrase - wait about 80 seconds Actual Results: Boot process is continued automatically of course without mounting the home partition. Expected Results: systemd waits forever for passphrase entry (boot process stopp) For additional information see this forum thread: http://forums.opensuse.org/forums/english/get-technical-help-here/install-b… -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 23

[Bug 749035] New: System hangs after entering Runlevel 0 on a sysvinit Shutdown (cause known)
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=749035 https://bugzilla.novell.com/show_bug.cgi?id=749035#c0 Summary: System hangs after entering Runlevel 0 on a sysvinit Shutdown (cause known) Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: openSUSE 12.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: andrew.williams(a)gmx.net QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Firefox/10.0.2 SeaMonkey/2.7.2 Messages just before the hang include error while loading shared libraries libsystemd-daemon.so.0 INIT: no more processes left in this runlevel (the first of those lines may look slightly different) The system then hangs. I have normally done an ESC by then so I get to see the messages but they are not logged. Whatever - I know the cause and have a workaround. - My system has /usr (and /var, so this does not get logged) as separate partitions. - Package systemd places libsystemd-daemon.so.0 in /usr/lib64 - /usr has been unmounted by the time I get to this point. Obviously the workaround is to copy libsystemd-daemon.so.0 from /usr/lib64 to /lib64, I assume a final fix would be to put there in the first place. Reproducible: Always Steps to Reproduce: 1. Have /usr as a seperate partition 2. add init=/sbin/sysvinit to /boot/grub/menu.1st 3. shutdown, directly from a command-line or indirectly via kde4 Actual Results: The system hangs after entering runlevel 0. shutdown -r does not reboot, shutdown -h does not power off. I have no problems with loss of data, everything had already been cleanly unmounted. Expected Results: reboot or system halt with power off -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 9

[Bug 813373] New: usb 3.0 device connected to usb 3.0 port doesn't get disconnected
by bugzilla_noreply＠novell.com 15 Jan '14

15 Jan '14

https://bugzilla.novell.com/show_bug.cgi?id=813373 https://bugzilla.novell.com/show_bug.cgi?id=813373#c0 Summary: usb 3.0 device connected to usb 3.0 port doesn't get disconnected Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Hotplug AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: dutchkind(a)txoriaskea.org QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 When I connect a usb 3.0 external harddisk to the usb 3.0 port on my notebook, and afterward remove it using KDE's device notifier, it gets unmounted but not disconnected, which means udev still sees the device although it's not physically connected anymore. This results in having to reboot (or probably restart udev) to be able to reconnect the device again. When I connect the same device to a usb 2.0 port it behaves as expected, the device is disconnected according to /var/log/messages. I have seen the same problem a while ago with systemrescuecd after an upgrade of it to the latest udev, so I think that is where the problem is. But that is a live cd and therefore not such a problem. Reproducible: Always Steps to Reproduce: 1. Connect device to usb 3.0 port 2. Disconnect 3. Device seems still there Actual Results: Device doesn't disappear after removal Expected Results: Device should disappear after removal -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11