May 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 853313] New: GroupWise client crashes, because Java uses too small stack alignment
by bugzilla_noreply＠novell.com 06 Jun '16

06 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=853313 https://bugzilla.novell.com/show_bug.cgi?id=853313#c0 Summary: GroupWise client crashes, because Java uses too small stack alignment 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: schwab(a)suse.com ReportedBy: vojtech(a)suse.com QAContact: qa-bugs(a)suse.de CC: matz(a)suse.com Found By: Beta-Customer Blocker: No The GroupWise client crashes on openSUSE 13.1 because it uses Java and Java's JIT generates code with too small stack alignment compared to what the (new) 32-bit ABI dictates. Vectorized string operations in glibc depend on the full alignment and the application segfaults. It'd be good for backwards compatibility with (arguably broken) old applications to be able to set an environment variable to use non-vectorized string operations even on modern CPUs. -- 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 859673] New: WINS name lookup unreliable
by bugzilla_noreply＠novell.com 31 May '16

31 May '16

https://bugzilla.novell.com/show_bug.cgi?id=859673 https://bugzilla.novell.com/show_bug.cgi?id=859673#c0 Summary: WINS name lookup unreliable Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Samba AssignedTo: samba-maintainers(a)SuSE.de ReportedBy: bart(a)bartvanassche.be QAContact: samba-maintainers(a)SuSE.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Since a long time I'm using openSUSE and WINS name lookup for name resolution. This worked fine in every previous openSUSE version I have been running but seems to be unreliable in openSUSE 13.1. Reproducible: Always Steps to Reproduce: 1. Disable the firewall # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination 2. Enable bridging # cat /etc/sysconfig/network/ifcfg-br0 BOOTPROTO='dhcp' BRIDGE='yes' BRIDGE_FORWARDDELAY='0' BRIDGE_PORTS='enp8s0' BRIDGE_STP='on' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NAME='' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' # cat /etc/sysconfig/network/ifcfg-enp8s0 BOOTPROTO='none' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='manual' USERCONTROL='no' 3. Install the samba-client RPM # rpm -qf /usr/lib64/libnss_wins.so.2 samba-client-4.1.3-3.12.1.x86_64 4. Enable WINS name lookup # grep wins /etc/nsswitch.conf hosts: files wins mdns_minimal [NOTFOUND=return] dns 5. Test WINS name lookup $ nmblookup ubuntu-vm 192.168.1.124 ubuntu-vm<00> $ host ubuntu-vm Host ubuntu-vm not found: 2(SERVFAIL) $ ping ubuntu-vm ping: unknown host ubuntu-vm Actual Results: Name lookup via WINS not working. Expected Results: Name lookup via WINS working. -- 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 869133] New: Dead keys produce incorrect results in non-Qt applications
by bugzilla_noreply＠novell.com 30 May '16

30 May '16

https://bugzilla.novell.com/show_bug.cgi?id=869133 https://bugzilla.novell.com/show_bug.cgi?id=869133#c0 Summary: Dead keys produce incorrect results in non-Qt applications Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: X.Org AssignedTo: bnc-team-xorg-bugs(a)forge.provo.novell.com ReportedBy: psychonaut(a)nothingisreal.com QAContact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 I use a keyboard layout which uses dead keys to produce accented characters In all Qt and KDE applications (Konsole, Kwrite, Skype, Clementine, etc.) the dead keys work as expected. However, in every non-Qt application I've tried (LibreOffice, Eclipse, gedit, etc.), some (but not all) dead key combinations produce incorrect results. For example, my XKB symbol map includes the following line: key <AD01> { [ apostrophe, quotedbl, dead_acute, dead_diaeresis ] }; So if I press AltGr+' e I expect to get é, and if I press AltGr+' c I expect to get ć. However, only the first of these works in non-KDE applications When I type AltGr+' c elsewhere, I get ç! Reproducible: Always Steps to Reproduce: 1. Switch to a keyboard map which binds dead_acute to AltGr+' 2. Type AltGr+' c in a non-Qt application. Actual Results: ç Expected Results: ć Possibly related to Bug 817940, which is another problem with dead keys. (Though in that case the dead keys aren't working at all; in my case they are working but producing incorrect results.) -- 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 4

[Bug 659905] New: Error in GRUB installation & configuration
by bugzilla_noreply＠novell.com 20 May '16

20 May '16

https://bugzilla.novell.com/show_bug.cgi?id=659905 https://bugzilla.novell.com/show_bug.cgi?id=659905#c0 Summary: Error in GRUB installation & configuration Classification: openSUSE Product: openSUSE 11.4 Version: Milestone 4 of 6 Platform: i686 OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Bootloader AssignedTo: jsrain(a)novell.com ReportedBy: lassaad(a)pochta.ru QAContact: jsrain(a)novell.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.6.12-1.2 Firefox/3.6.12 In the Bootloader installation procedure I get an error, so I can't instal GRUB, I've tried many installation option like install on MBR, on sda, on /root but it doesn't work. so I quit installation and when I try to install GRUB manually I get the same error. There are some screenshots of my installation: This is my partitions setup http://yfrog.com/0rdiskpartitionsp My installation setting http://yfrog.com/5einstallationsettingsp GRUB installation ERROR http://yfrog.com/1gerrorgrubp Reproducible: Always Steps to Reproduce: 1.start live USB installation (my CD-ROM is broken) 2.set my "/" on sda5 (ext4) 3.wait until the GRUB error appear in the end of installation Actual Results: when I restart, no GRUB, I get error " no operating system... " and in the /boot directory, there is no vmlinuz or initrd files. only mbr.backup and grub folder. Expected Results: setup the GRUB, and end the installation. -- 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 14

[Bug 822774] New: perl-Bootloader doesn't rotate it's log
by bugzilla_noreply＠novell.com 20 May '16

20 May '16

https://bugzilla.novell.com/show_bug.cgi?id=822774 https://bugzilla.novell.com/show_bug.cgi?id=822774#c0 Summary: perl-Bootloader doesn't rotate it's log Classification: openSUSE Product: openSUSE Factory Version: 13.1 Milestone 0 Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: P5 - None Component: Basesystem AssignedTo: snwint(a)suse.com ReportedBy: lazy.kent(a)opensuse.org QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- perl-Bootloader doesn't rotate it's log. In my system /var/pbl.log size is 9.8 MB since 2013-01-05. It should provide a pbl file in /etc/logrotate.d/. -- 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 15

[Bug 828693] New: Zarafa-spooler does not work when started by systemd
by bugzilla_noreply＠novell.com 03 May '16

03 May '16

https://bugzilla.novell.com/show_bug.cgi?id=828693 https://bugzilla.novell.com/show_bug.cgi?id=828693#c0 Summary: Zarafa-spooler does not work when started by systemd Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: ian.hodge(a)verrinus-consulting.ltd.uk QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=547291) --> (http://bugzilla.novell.com/attachment.cgi?id=547291) Output of strace User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; NET4.0C; .NET4.0E) When systemd is used to start zarafa-spooler the process starts but does not pickup and deliver any message from zarafa-server. If the spooler is started on the command line it works correctly. If systemd is replaced by sysvinit as the boot mechanism, the spooler also works correctly. This is true on openSUSE 12.1, 12.2 and 12.3 with zarafa 7.0.x and zarafa 7.1.x from the opensuse repository. I'm assuming this is a problem to do with the very limited execution environment systemd passes on to process it starts and that there is something special that the zarafa-spooler needs that isn't being provided by systemd. Note that all zarafa processes are still using /etc/init.d scripts rather than unit files. As it stands my mailserver does not survive a reboot as it needs manual intervention to get it to deliver mail. Reproducible: Always Steps to Reproduce: 1. # systemctl start zarafa-spooler.service 2. send an email from within zarafa 3. Actual Results: The mail will sit in outbox forever and not be delivered. Expected Results: Zarafa-spooler will pick up the mail and deliver it to the local MTA (postfix) for delivery. If the spooler is stopped and started on the command line ie. # systemctl stop zarafa-spooler.service # /usr/sbin/zarafa-spooler The mail is immediately picked up from the outbox and delivered. -- 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 12

[Bug 692440] New: OpenVPN should have a sysconfig entry to pick which VPN configurations are enabled
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=692440 https://bugzilla.novell.com/show_bug.cgi?id=692440#c0 Summary: OpenVPN should have a sysconfig entry to pick which VPN configurations are enabled Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jmatejek(a)novell.com QAContact: qa(a)suse.de Found By: --- Blocker: --- in Debian/Ubuntu, it is possible to configure OpenVPN service to only start some of the available .confs in /etc/openvpn. This is useful when you have more than one openvpn config, such as home and work VPNs and you don't want to use them simultaneously. Also, their init script takes an optional argument that specifies name of the conf to start/stop openSUSE starts all OpenVPN confs automatically and you cannot choose which ones to use. It would be nice to have this feature. -- 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 14

[Bug 864302] New: GNU tar rpm cannot dealt with large uid_t
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=864302 https://bugzilla.novell.com/show_bug.cgi?id=864302#c0 Summary: GNU tar rpm cannot dealt with large uid_t Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: All OS/Version: openSUSE 13.1 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: external.martin.konold(a)de.bosch.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 SUSE/31.0.1650.63 Name : tar Version : 1.26 Release : 19.1.2 Cannot deal with large uid_t. Reason: Default format got changed from GNU to POSIX. Problem: In contrast to what the GNU tar documentation claims --format=posix cannot deal with large uids. Reproducible: Always Steps to Reproduce: 1. create directory hierarchy testdir/ with large uidnumber e.g. 20000001. 2. tar cvf deleteme.tar testdir/ 3. echo $? will give a 2. Actual Results: $? is 2 Expected Results: $? should be 0. tar cvf --format=gnu gives the expected result. This is a regression from older versions of OpenSuSE which used to have --format=gnu as a default format. E.g. OpenSuSE 11.3: km82rt@rt-z9854:~> tar --version tar (GNU tar) 1.23 km82rt@rt-z9854:~> tar –help | tail -5 *Dieses* „tar“ hat als Voreinstellung: --format=gnu -f- -b20 --quoting-style=escape --rmt-command=/usr/libexec/rmt --rsh-command=/usr/bin/rsh OpenSuSE 13.1: km82rt@rt-ccs7560:tmp> tar --version tar (GNU tar) 1.26 km82rt@rt-ccs7560:tmp> tar --help | tail -5 *This* tar defaults to: --format=posix -f- -b20 --quoting-style=escape --rmt-command=/usr/lib/rmt --rsh-command=/usr/bin/rsh The misleading documentation is available from http://www.gnu.org/software/tar/manual/html_section/Formats.html Format | UID File Size File Name Devn -------+----------------------------------------- gnu | 1.8e19 Unlimited Unlimited 63 oldgnu | 1.8e19 Unlimited Unlimited 63 v7 | 2097151 8GB 99 n/a ustar | 2097151 8GB 256 21 posix | Unlimited Unlimited Unlimited Unlimited Workaround: Go back to +export DEFAULT_ARCHIVE_FORMAT="GNU" -export DEFAULT_ARCHIVE_FORMAT="POSIX" in tar.spec and recreate the tar RPM. The current bug breaks many existing shell scripts which evaluate the exit code of tar. The bug is often triggered in setups using idmap_rid. For obvious reasons there is no way in large installation to change the uid to values which accomodate the buggy tar implementation. -- 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 14

[Bug 823292] New: Man page for sudo does not match version supplied
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=823292 https://bugzilla.novell.com/show_bug.cgi?id=823292#c0 Summary: Man page for sudo does not match version supplied Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Documentation AssignedTo: ke(a)suse.com ReportedBy: michael(a)aperantos.com QAContact: ke(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.29.13 (KHTML, like Gecko) Version/6.0.4 Safari/536.29.13 I normally use 'sudo -E -s' to gain a root shell retaining my user account's home directory as $HOME. As openSUSE sets the 'always_set_home' option in /etc/sudoers I had turned this off, but despite this it would set the home directory to the target user. After asking about this on the community forum ( https://forums.opensuse.org/english/get-technical-help-here/install-boot-lo… ) I discovered that the version of sudo provided with openSUSE is compiled with the set_home option enabled. Turning this option off in /etc/sudoers resulted in the expected behaviour. The man page provided in the default openSUSE installation states for set_home that "This flag is off by default." This is wrong and made it impossible to discover the cause of the unexpected behaviour. Ideally I do not think the program should be compiled in a non-standard way, especially when the default configuration of the /etc/sudoers file includes a stronger setting so it would only apply to those who customize their configuration. But as there will have been a decision made to make it this way, the documentation needs to be updated to reflect this difference. Reproducible: Always Steps to Reproduce: man sudo Actual Results: This flag is off by default. Expected Results: This flag is on by default. -- 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 13

[Bug 700229] New: telnet crashes glibc when using "-b" parameter
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=700229 https://bugzilla.novell.com/show_bug.cgi?id=700229#c0 Summary: telnet crashes glibc when using "-b" parameter Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: x86-64 OS/Version: openSUSE 11.4 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: novell-web(a)zmi.at QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 I wanted telnet to source from another IP, using "-b" parameter: # telnet -b eth1 10.10.10.10 Trying 10.10.10.10... telnet: eth1: Name or service not known: Success Speicherzugriffsfehler I tried that twice, then looked into dmesg: [60254.321495] telnet[28275] general protection ip:7f733a452a63 sp:7fff6839fbe0 error:0 in libc-2.11.3.so[7f733a393000+164000] [60350.030095] telnet[29348] general protection ip:7f7169480a63 sp:7fff37e01070 error:0 in libc-2.11.3.so[7f71693c1000+164000] This is on openSUSE 11.4, but I first discovered it in 11.2, where it puts more details on the screen: # telnet -b eth0:1 10.127.128.5 25 Trying 10.127.128.5... telnet: eth0:1: Name or service not known: Success *** glibc detected *** telnet: munmap_chunk(): invalid pointer: 0x00007fff0a06ace8 *** ======= Backtrace: ========= /lib64/libc.so.6[0x7f825d605d06] /lib64/libc.so.6(freeaddrinfo+0x20)[0x7f825d64d510] telnet[0x7f825dd61939] telnet(main+0x34f)[0x7f825dd5a1ff] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f825d5b1a7d] telnet[0x7f825dd59d59] ======= Memory map: ======== 7f825cf6b000-7f825cf81000 r-xp 00000000 ca:01 16518 /lib64/libgcc_s.so.1 7f825cf81000-7f825d180000 ---p 00016000 ca:01 16518 /lib64/libgcc_s.so.1 7f825d180000-7f825d181000 r--p 00015000 ca:01 16518 /lib64/libgcc_s.so.1 7f825d181000-7f825d182000 rw-p 00016000 ca:01 16518 /lib64/libgcc_s.so.1 7f825d182000-7f825d18d000 r-xp 00000000 ca:01 3184 /lib64/libnss_files-2.10.1.so 7f825d18d000-7f825d38d000 ---p 0000b000 ca:01 3184 /lib64/libnss_files-2.10.1.so 7f825d38d000-7f825d38e000 r--p 0000b000 ca:01 3184 /lib64/libnss_files-2.10.1.so 7f825d38e000-7f825d38f000 rw-p 0000c000 ca:01 3184 /lib64/libnss_files-2.10.1.so 7f825d38f000-7f825d391000 r-xp 00000000 ca:01 17973 /lib64/libdl-2.10.1.so 7f825d391000-7f825d591000 ---p 00002000 ca:01 17973 /lib64/libdl-2.10.1.so 7f825d591000-7f825d592000 r--p 00002000 ca:01 17973 /lib64/libdl-2.10.1.so 7f825d592000-7f825d593000 rw-p 00003000 ca:01 17973 /lib64/libdl-2.10.1.so 7f825d593000-7f825d6e4000 r-xp 00000000 ca:01 3936 /lib64/libc-2.10.1.so 7f825d6e4000-7f825d8e4000 ---p 00151000 ca:01 3936 /lib64/libc-2.10.1.so 7f825d8e4000-7f825d8e8000 r--p 00151000 ca:01 3936 /lib64/libc-2.10.1.so 7f825d8e8000-7f825d8e9000 rw-p 00155000 ca:01 3936 /lib64/libc-2.10.1.so 7f825d8e9000-7f825d8ee000 rw-p 00000000 00:00 0 7f825d8ee000-7f825d92c000 r-xp 00000000 ca:01 3177 /lib64/libncurses.so.5.6 7f825d92c000-7f825db2b000 ---p 0003e000 ca:01 3177 /lib64/libncurses.so.5.6 7f825db2b000-7f825db2f000 r--p 0003d000 ca:01 3177 /lib64/libncurses.so.5.6 7f825db2f000-7f825db35000 rw-p 00041000 ca:01 3177 /lib64/libncurses.so.5.6 7f825db35000-7f825db53000 r-xp 00000000 ca:01 4324 /lib64/ld-2.10.1.so 7f825dd26000-7f825dd28000 rw-p 00000000 00:00 0 7f825dd4f000-7f825dd52000 rw-p 00000000 00:00 0 7f825dd52000-7f825dd53000 r--p 0001d000 ca:01 4324 /lib64/ld-2.10.1.so 7f825dd53000-7f825dd54000 rw-p 0001e000 ca:01 4324 /lib64/ld-2.10.1.so 7f825dd54000-7f825dd6a000 r-xp 00000000 ca:01 9058 /usr/bin/telnet 7f825df6a000-7f825df6b000 r--p 00016000 ca:01 9058 /usr/bin/telnet 7f825df6b000-7f825df6d000 rw-p 00017000 ca:01 9058 /usr/bin/telnet 7f825df6d000-7f825df9b000 rw-p 00000000 00:00 0 [heap] 7fff0a058000-7fff0a06d000 rw-p 00000000 00:00 0 [stack] 7fff0a098000-7fff0a099000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Abgebrochen Seems this bug dates a while back. While 11.2 is not in bugfix phase anymore, 11.3 and 11.4 should be fixed, please. Reproducible: Always Steps to Reproduce: 1. use "telnet -b eth0 <IP address>" Actual Results: crash in glibc Expected Results: should work :-) -- 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 34