August 2011 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 678066] New: IPv6 Privacy Extensions are not enabled by default
by bugzilla_noreply＠novell.com 07 Jul '16

07 Jul '16

https://bugzilla.novell.com/show_bug.cgi?id=678066 https://bugzilla.novell.com/show_bug.cgi?id=678066#c0 Summary: IPv6 Privacy Extensions are not enabled by default Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: lnussel(a)novell.com ReportedBy: aj(a)novell.com QAContact: qa(a)suse.de Found By: Product Management Blocker: --- bnc#664550 made some changes to IPv6 Privacy extensions - and now a default installation does not have them enabled at all. It should really be enabled. -- 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 16

[Bug 711489] New: Package 'libffi' has no Description: field
by bugzilla_noreply＠novell.com 30 Jun '16

30 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=711489 https://bugzilla.novell.com/show_bug.cgi?id=711489#c0 Summary: Package 'libffi' has no Description: field Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: pth(a)novell.com ReportedBy: koenig(a)linux.de QAContact: qa(a)suse.de Found By: --- Blocker: --- running "pkg-config --libs libffi" fails with error Package 'libffi' has no Description: field $ rpm -qf /usr/lib64/pkgconfig/libffi.pc libffi45-devel-4.5.1_20101208-9.1.x86_64 workaround for now: # echo Description: foo >> /usr/lib64/pkgconfig/libffi.pc -- 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 673937] New: apache2: provide rpm macros file for 3rd party modules
by bugzilla_noreply＠novell.com 28 Jun '16

28 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=673937 https://bugzilla.novell.com/show_bug.cgi?id=673937#c0 Summary: apache2: provide rpm macros file for 3rd party modules Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Apache AssignedTo: bnc-team-apache(a)forge.provo.novell.com ReportedBy: lnussel(a)novell.com QAContact: qa(a)suse.de Found By: --- Blocker: --- 3rd party modules currently have code like this in the .spec file: %define apxs /usr/sbin/apxs2 %define apache_libexecdir %(%{apxs} -q LIBEXECDIR) Stuff like that should be put into a macro file with pre-computed values. e.g. /etc/rpm/macros.apache2 that is provided by apache2-devel. -- 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 597744] New: alpine: Missing umlaut in date column: our_strftime does not always return utf8-encoded strings
by bugzilla_noreply＠novell.com 28 Jun '16

28 Jun '16

http://bugzilla.novell.com/show_bug.cgi?id=597744 http://bugzilla.novell.com/show_bug.cgi?id=597744#c0 Summary: alpine: Missing umlaut in date column: our_strftime does not always return utf8-encoded strings Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86-64 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: kdevel(a)vogtner.de QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Alpine does not correctly encode non-utf-8-data from locale's time and date formatting. Reproducible: Always Steps to Reproduce: 1. open console/xterm with 8-Bit character encoding (i.e. ISO-8859-1) 2. start alpine with LANG=de_DE@euro 3. have an e-mail in your inbox with a date of March. Actual Results: The Date displayed is "M" Expected Results: "Mär" strftime may return non-utf8 data if operated in a non-utf8 environment. In The non-WINDOWS-case no change of encoding to utf8 is performed in our_strftime (pith/string.c) but utf8 is expected from functions calling our_strftime. -- Configure bugmail: http://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 558841] New: alpine: incorrect transformation patch included
by bugzilla_noreply＠novell.com 28 Jun '16

28 Jun '16

http://bugzilla.novell.com/show_bug.cgi?id=558841 http://bugzilla.novell.com/show_bug.cgi?id=558841#c0 Summary: alpine: incorrect transformation patch included Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: All OS/Version: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jengelh(a)medozas.de QAContact: qa(a)suse.de Found By: Beta-Customer Blocker: --- In alpine's operation-may-be-undefined-warning.diff, there is: - m = strtoul (++s,(char **) &s,10); - y = (*s == ':') ? strtoul (++s,(char **) &s,10) : 0; + s++; + m = strtoul (s,(char **) &s,10); + s++; + y = (*s == ':') ? strtoul (s,(char **) &s,10) : 0; But the last two + lines seem wrong. SUSE is incrementing s here before the test for ':', while the original patch only did it _after_. It should probably have been: s++; m = strtoul(s, (char **)&s, 10); if (*s == ':') { ++s; y = strtoul(s, (char **)&s, 10); } else { y = 0; } -- Configure bugmail: http://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 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 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 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

[Bug 601779] New: 32bit 'tree' doesn't show files 2GB and larger
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=601779 http://bugzilla.novell.com/show_bug.cgi?id=601779#c0 Summary: 32bit 'tree' doesn't show files 2GB and larger Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: x86 OS/Version: openSUSE 11.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jc(a)ymmv.dk QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 SUSE/3.5.9-0.1.1 Firefox/3.5.9 Hi On 32bit systems the 'tree' command dosn't show 'large' files. I have tested on a 64bit system as well, and the problem is only present on 32bit systems. I have done a fair amount of research, comparing compile-time arguments with those of 32bit Debian packages. In the end I think it comes down to the 'spec' file: In tree.spec the 'make' command is: %build make CFLAGS="$RPM_OPT_FLAGS" -which overrides the CFLAGS set in the Makefile: CFLAGS=-O2 -Wall -fomit-frame-pointer -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -which results in the binary being built with these flags instead: RPM_OPT_FLAGS="-O2 -g -m32 -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables" Now; If I change the spec file so that; %build make -then the compiler gets the flags as set in the Makefile, and the resulting binary works with files larger than 2G. I'm guessing that it's desirable to get $RPM_OPT_FLAGS passed to the compiler, but I'm unsure as to how one would 'merge' this variable with $CFLAGS from the Makefile? As for the severity of the bug: It doesn't break the system, but the functionality of the command is seriously hampered by this. It seems reasonable (to me) that it's a packaging bug, and therefore it should be easily fixed. I have confirmation from the opensuse(a)opensuse.org list that the bug is present on 11.0, so it seems to be an 'old' problem... Kind Regards, Jon Clausen Reproducible: Always Steps to Reproduce: 1. get or create a file larger than 2GB I used 'dd' to create two files - one 2GB, one 1KB smaller: dd if=/dev/zero of=2G bs=1k count=2097152 dd if=/dev/zero of=2G-1k bs=1k count=2097151 2. use 'tree /path/to/large/file' 3. observe output Actual Results: output from 32bit system: jon@nx8220:~> ll tmp/largefiles/ total 4194304 -rw-r--r-- 1 jon users 2147483648 2010-04-30 12:50 2G -rw-r--r-- 1 jon users 2147482624 2010-04-30 12:52 2G-1k jon@nx8220:~> tree tmp/largefiles/ tmp/largefiles/ `-- 2G-1k 0 directories, 1 file Expected Results: output from 64bit system: jon@cnu8092slm:~> ll tmp/largefiles/ total 4194304 -rw-r--r-- 1 jon users 2147483648 2010-04-30 12:58 2G -rw-r--r-- 1 jon users 2147482624 2010-04-30 12:58 2G-1k jon@cnu8092slm:~> tree tmp/largefiles/ tmp/largefiles/ |-- 2G `-- 2G-1k 0 directories, 2 files AFAICT the flag that makes the difference is -D_FILE_OFFSET_BITS=64 - which makes the binary use *stat64() rather than *stat() when files are 'large'. On 64bit systems I suppose everything uses *stat64() anyways, which is why the problem only surfaces on 32bit systems... ? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 17

[Bug 707860] New: Static buffers in minicom are too small
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=707860 https://bugzilla.novell.com/show_bug.cgi?id=707860#c0 Summary: Static buffers in minicom are too small Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: x86 OS/Version: openSUSE 11.4 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: Stromeko(a)NexGo.DE QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0 The terminal emulation minicom uses a static buffer for reading in config parameters. When you've got a path like: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 then it gets truncated and can't be used. Using the real device /dev/ttyUSB0 is not a good idea since udev may put this device on /dev/ttyUSB1 the next time. The buffer can be increased by setting #define PARS_VAL_LEN 196 in src/configsym.h (standard value is 64). If I build minicom with this change (and all the patches from https://build.opensuse.org/package/files?package=minicom&project=Base%3ASys…) then it will work with a configuration that references the above device. Reproducible: Always Steps to Reproduce: minicom -D /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 Actual Results: minicom: cannot open /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Co: No such file or directory Expected Results: minicom opening the serial port it had been given -- 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