February 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 858703] New: "Invalid arguments for the Label widget" in yast2 firewall module
by bugzilla_noreply＠novell.com 13 Apr '17

13 Apr '17

https://bugzilla.novell.com/show_bug.cgi?id=858703 https://bugzilla.novell.com/show_bug.cgi?id=858703#c0 Summary: "Invalid arguments for the Label widget" in yast2 firewall module Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 AssignedTo: yast2-maintainers(a)suse.de ReportedBy: aspiers(a)suse.com QAContact: jsrain(a)suse.com Found By: Development Blocker: --- [first reported in bug 851769 comment #13] With yast2-firewall-3.0.1-2.1.4.noarch, if I launch "yast2 firewall", click "Interfaces", select "crowbar-br0" which is an openvswitch bridge I configured for use as a GRE tunnel, and click Change then I get an error dialog: UI Syntax Error Invalid arguments for the Label widget Check the log file! And y2log contains: 2014-01-13 13:21:02 <3> indian.linksys.moosehall(30549) [Ruby] modules/NetworkInterfaces.rb:1468 No such device: crowbar-br0 2014-01-13 13:21:02 <1> indian.linksys.moosehall(30549) [Ruby] yast/ops.rb:62 Index 0 is out of array size 2014-01-13 13:21:09 <1> indian.linksys.moosehall(30549) [Ruby] yast/ops.rb:62 Index 0 is out of array size 2014-01-13 13:21:09 <3> indian.linksys.moosehall(30549) [libycp] firewall/uifunctions.rb:303 Invalid arguments for the Label widget: `Label (nil) 2014-01-13 13:21:09 <2> indian.linksys.moosehall(30549) [ui] YCPDialogParser.cc(parseLabel):1213 THROW: Invalid arguments for the Label widget 2014-01-13 13:21:09 <2> indian.linksys.moosehall(30549) [ui] YCP_UI.cc(OpenDialog):585 CAUGHT: Invalid arguments for the Label widget 2014-01-13 13:21:09 <3> indian.linksys.moosehall(30549) [libycp] firewall/uifunctions.rb:303 UI::OpenDialog() failed 2014-01-13 13:21:09 <1> indian.linksys.moosehall(30549) [ui] YPushButton.cc(setFunctionKey):188 Guessing button role YOKButton for YPushButton "Close" at 0x7f53583df860 from function key F10 A valid workaround appears to be to manually edit FW_DEV_EXT in /etc/sysconfig/SuSEfirewall2. -- 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 10

[Bug 841046] New: SuSEfirewall2: support IPv6 in FW_TRUSTED_NETS
by bugzilla_noreply＠novell.com 13 Apr '17

13 Apr '17

https://bugzilla.novell.com/show_bug.cgi?id=841046 https://bugzilla.novell.com/show_bug.cgi?id=841046#c0 Summary: SuSEfirewall2: support IPv6 in FW_TRUSTED_NETS Classification: openSUSE Product: openSUSE Factory Version: 13.1 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Network AssignedTo: lnussel(a)suse.com ReportedBy: ro(a)suse.com QAContact: qa-bugs(a)suse.de CC: mt(a)suse.com Found By: Development Blocker: --- little patch for ipv6 support: mirrorbrain:/sbin # diff -u SuSEfirewall2 SuSEfirewall2.rudi --- SuSEfirewall2 2013-09-18 12:15:17.000000000 +0200 +++ SuSEfirewall2.rudi 2013-09-18 12:15:10.000000000 +0200 @@ -1482,6 +1482,12 @@ net="$1" proto="$2" port="$3" + iptables="$IPTABLES $IP6TABLES" + case "$net" in + *:*) iptables="$IP6TABLES" ;; + [0-9]*.*.*.*) iptables="$IPTABLES" ;; + esac + if [ -n "$4" ]; then error "Too many arguments in FW_TRUSTED_NETS -> $nets" elif [ -z "$net" ]; then @@ -1491,9 +1497,9 @@ elif check_proto_port "$proto" "$port" "" 'FW_TRUSTED_NETS'; then for chain in $input_zones; do # trusted networks can be on any interface ... chain=input_$chain - $LAC $IPTABLES -A $chain ${LOG}"-`rulelog $chain`-ACC-TRUST " -m state --state NEW -s $net $proto $port - $LAA $IPTABLES -A $chain ${LOG}"-`rulelog $chain`-ACC-TRUST " -s $net $proto $port - $IPTABLES -A $chain -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -s $net $proto $port + $LAC $iptables -A $chain ${LOG}"-`rulelog $chain`-ACC-TRUST " -m state --state NEW -s $net $proto $port + $LAA $iptables -A $chain ${LOG}"-`rulelog $chain`-ACC-TRUST " -s $net $proto $port + $iptables -A $chain -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -s $net $proto $port done fi done -- 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 844198] New: /run/user/0 is not available for Kerberos caches
by bugzilla_noreply＠novell.com 11 Apr '17

11 Apr '17

https://bugzilla.novell.com/show_bug.cgi?id=844198 https://bugzilla.novell.com/show_bug.cgi?id=844198#c0 Summary: /run/user/0 is not available for Kerberos caches Classification: openSUSE Product: openSUSE Factory Version: 13.1 Beta 1 Platform: i686 OS/Version: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: lynn(a)steve-ss.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1632.0 Safari/537.36 SUSE/31.0.1632.0 Automounted kerberised cifs shares need a root cache available. The beta expects the cache to be at /run/users/0/ but this directory is only produced if root has logged in. Hence, cifs.upcall cannot find the cache as it cannot be produced becaue the directory is not present. Previous to 13.1, the cache was created at /tmp which is not a problem, since /tmp always exists. Reproducible: Always Steps to Reproduce: 1.cd to a directory which corresponds to an autofs kerberized cifs mount 2. 3. Actual Results: Cannot cd to xyz. The directory does not exist. Expected Results: The directory is mounted. The workaround is to use systemd tmpfiles or create the cache directory in /etc/init.d/boot.local -- 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 7

[Bug 747783] New: systemd: 'service openvpn start' triggers spamming of all terminals
by bugzilla_noreply＠novell.com 11 Apr '17

11 Apr '17

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c0 Summary: systemd: 'service openvpn start' triggers spamming of all terminals 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: gp(a)suse.com QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 1. become root 2. # service openvpn start 3. Watch as every terminal will be spammed with something like Broadcast message from root(a)trevally.site (Fri, 17 Feb 2012 17:28:14 +0100): Password entry required for 'Enter Auth Username:' (PID 17770). Please enter password with the systemd-tty-ask-password-agent tool! This does not make any sense since I am already in the terminal with the prompt; why bother all other terminals? Reproducible: Always -- 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 19

[Bug 755603] New: The gnome keyring socket is not owned with the same credentials as the user login
by bugzilla_noreply＠novell.com 11 Mar '17

11 Mar '17

https://bugzilla.novell.com/show_bug.cgi?id=755603 https://bugzilla.novell.com/show_bug.cgi?id=755603#c0 Summary: The gnome keyring socket is not owned with the same credentials as the user login Classification: openSUSE Product: openSUSE 12.2 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome(a)forge.provo.novell.com ReportedBy: mvyskocil(a)suse.com QAContact: qa-bugs(a)suse.de CC: vuntz(a)suse.com, vcizek(a)suse.com Found By: Development Blocker: --- Created an attachment (id=484752) --> (http://bugzilla.novell.com/attachment.cgi?id=484752) copy the credential checking code from git.gnome.org Running command via sudo fills my log errors as appears in $SUBJECT $ sudo ls Password: xxxx and then log contains following Apr 4 10:20:01 zelva sudo: The gnome keyring socket is not owned with the same credentials as the user login: /run/user/mvyskocil/keyring-5MIqXs/control Apr 4 10:20:01 zelva sudo: gkr-pam: couldn't unlock the login keyring. Apr 4 10:20:01 zelva sudo: mvyskocil : TTY=pts/5 ; PWD=/home/mvyskocil ; USER=root ; COMMAND=/usr/bin/ls Apr 4 10:20:01 zelva systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus However that's not true $ echo $GNOME_KEYRING_CONTROL /run/user/mvyskocil/keyring-5MIqXs $ ls -n $GNOME_KEYRING_CONTROL/* srwxr-xr-x 1 10112 100 0 4. dub 09.33 /run/user/mvyskocil/keyring-5MIqXs/control srwxr-xr-x 1 10112 100 0 4. dub 09.33 /run/user/mvyskocil/keyring-5MIqXs/gpg srwxr-xr-x 1 10112 100 0 4. dub 09.33 /run/user/mvyskocil/keyring-5MIqXs/pkcs11 srwxr-xr-x 1 10112 100 0 4. dub 09.33 /run/user/mvyskocil/keyring-5MIqXs/ssh $ id uid=10112(mvyskocil) gid=100(users) groups=100(users),10(wheel),33(video),41(xok),113(vboxusers),404(lighttpd),1194(vpn) $ id -u 10112 $ id -ru 10112 so the 10112 is my *real* id and keyring sockets are really owned by this id. $ cat /proc/$GNOME_KEYRING_PID/loginuid 10112 and even the process runs with the same uid, so there is really **no** surprise in my configuration. I did a bit more and copy the part of gnome-keyring-daemon, however even getsockopt returns the id 10112, like getuid does. $ ./creds uid=10112, geteuid()=10112 I would say the best way to debug would be patch gnome-keyring-daemon and print the values of uid and getuid on error, but I haven't a time to do that yet. BTW: as google returns most of suse related things for $SUBJ, I suspect some misconfiguration in our pam stack. -- 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 786679] New: usability issues with man
by bugzilla_noreply＠novell.com 16 Feb '17

16 Feb '17

https://bugzilla.novell.com/show_bug.cgi?id=786679 https://bugzilla.novell.com/show_bug.cgi?id=786679#c0 Summary: usability issues with man Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: P5 - None Component: Documentation AssignedTo: ke(a)suse.com ReportedBy: aspiers(a)suse.com QAContact: ke(a)suse.com Found By: Development Blocker: --- This bug has two parts - a minor behavioural issue, and a minor documentation issue. As per FATE #303433, the default behaviour of man when there are multiple sections offering the requested man page was changed in June 2008. The old behaviour can be reverted by setting the MAN_POSIXLY_CORRECT environment variable. Whilst this was an improvement on the prior situation, there seems to be a minor behavioural issue when two versions of the same man page are on the manpath, e.g. $ manpath | tr : '\n' manpath: warning: $MANPATH set, ignoring /etc/manpath.config /home/adam/share/man /home/adam/.rvm/rubies/ruby-1.9.3-p194/share/man /home/adam/.rvm/man /opt/kde3/share/man /usr/local/man /usr/share/man /home/adam/.GIT/3rd-party/rvm/man $ ls -l ~/share/man/man1/git-commit.1 lrwxrwxrwx 1 adam users 46 Sep 26 13:19 /home/adam/share/man/man1/git-commit.1 -> ../../../.STOW/git/share/man/man1/git-commit.1 $ man -aw git-commit /usr/share/man/man1/git-commit.1.gz /home/adam/.STOW/git/share/man/man1/git-commit.1 $ man git-commit Man: find all matching manual pages (set MAN_POSIXLY_CORRECT to avoid this) * git-commit (1) git-commit (1+) Man: What manual page do you want? Man: However, if I enter '1+' and hit Enter, I still get the version from /usr/share. Likewise, $ man 1+ git-commit No manual entry for git-commit in section 1+ Perhaps I am wrong to expect this to work, which brings me onto the documentation issue: it is not clear how this is supposed to work, because while man-db-2.5.1-listall.dif patches src/man.c to introduce MAN_POSIXLY_CORRECT, it does not patch man/man1/man.man1 to correspondingly amend the documentation. So it would also be good if the changed behaviour and MAN_POSIXLY_CORRECT were documented. This would presumably help the patch get accepted upstream too. (Incidentally I notice that 2.5.1 is 4 years behind the current version 2.6.3, so it might be worth refreshing at some point soon.) -- 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 854323] New: libpgf OpenMP digikam memory leak when thumbnailing and face recognition - fix available in pgf SVN
by bugzilla_noreply＠novell.com 03 Feb '17

03 Feb '17

https://bugzilla.novell.com/show_bug.cgi?id=854323 https://bugzilla.novell.com/show_bug.cgi?id=854323#c0 Summary: libpgf OpenMP digikam memory leak when thumbnailing and face recognition - fix available in pgf SVN Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Applications AssignedTo: kde-maintainers(a)suse.de ReportedBy: rickscafe.casablanca(a)gmx.net QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 The version of libpgf that is shipped with 13.1 produces a massive memory leak with digikam. This happens when initially thumbnailing a larger picture collection or when trying face recognition on a collection. In both cases digikam will eat up all RAM plus swap. At least part of the problem is libpgf and it was fixed in SVN, though has not been released yet. See http://sourceforge.net/p/libpgf/code/HEAD/tree/ *** trunk 2013-11-08 rs [r123] fix memory leak in Encoder w/ OpenMP *** I compiled r123 which identifies as 6.13.45 and it does indeed fix the memory leak with digikam. The fix should be included in a libpgf update to 13.1 RH Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1023241 KDE Bug: https://bugs.kde.org/show_bug.cgi?id=326525 Reproducible: Always Steps to Reproduce: 1. backup digikam collection db and start from scratch 2. initial scan/tumbnailing uses all available RAM 3. face recognition uses all available RAM Actual Results: system runs out of memory or gets very slow due to digikam eating all RAM Expected Results: memory usage should be stable -- 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 845245] New: chmod and chgrp make unnecessary disc writes
by bugzilla_noreply＠novell.com 23 Jan '17

23 Jan '17

https://bugzilla.novell.com/show_bug.cgi?id=845245 https://bugzilla.novell.com/show_bug.cgi?id=845245#c0 Summary: chmod and chgrp make unnecessary disc writes Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: R.Vickers(a)cs.rhul.ac.uk QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 Using chmod or chgrp alters the last-change time of a file even if no changes are actually made. This may seem like a very minor matter, but if you are dealing with a large number of files (for example with the -R option) then there are a number of bad consequences: (1) system performance is impacted while the command is running (2) incremental backups take longer and consume more space (3) restores after a disc failure take much longer because many large incremental backups have to be processed We use cron jobs to set correct permissions on shared directories, because it is not fair on users to expect them to manage this themselves. On one file system we find a third of the files are backed up every night because of this, and it extended the recovery time after a disc failure by many hours. Reproducible: Always Steps to Reproduce: $ touch test $ chmod 700 test $ stat test $ chmod 700 test $ stat test Actual Results: The Change time is updated after every chmod. Expected Results: The Change time should only be updated if the mode was changed. -- 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 851394] New: nouveau failed to idle channel 0xcccc0001
by bugzilla_noreply＠novell.com 09 Jan '17

09 Jan '17

https://bugzilla.novell.com/show_bug.cgi?id=851394 https://bugzilla.novell.com/show_bug.cgi?id=851394#c0 Summary: nouveau failed to idle channel 0xcccc0001 Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: abergmann(a)suse.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- I just can into a problem with a GeForce 7300 LE VGA controller. Under X the system is unstable and is crashing. [ 865.851006] nouveau E[Xorg[3304]] failed to idle channel 0xcccc0001 [Xorg[3304]] [ 880.852005] nouveau E[Xorg[3304]] failed to idle channel 0xcccc0001 [Xorg[3304]] [ 895.852004] nouveau E[Xorg[3304]] failed to idle channel 0xcccc0001 [Xorg[3304]] I found the following bug describing this problem: https://bugs.launchpad.net/ubuntu/+source/linux-lts-quantal/+bug/1097178 -- 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 680125] New: dlclose() can not unload all dynamic libraries
by bugzilla_noreply＠novell.com 02 Jan '17

02 Jan '17

https://bugzilla.novell.com/show_bug.cgi?id=680125 https://bugzilla.novell.com/show_bug.cgi?id=680125#c0 Summary: dlclose() can not unload all dynamic libraries Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Development AssignedTo: pth(a)novell.com ReportedBy: gotterdammerung(a)web.de QAContact: qa(a)suse.de Found By: --- Blocker: --- Created an attachment (id=419657) --> (http://bugzilla.novell.com/attachment.cgi?id=419657) test program which opens a dl from cmdline, closes it and checks if it is still open User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.9.2.15) Gecko/20110310 Gentoo Firefox/3.6.15 A call to dlclose() does not unload some dynamic libraries, even if the reference count drops to zero and no other loaded libraries use symbols in it. See attached test programm. Some libraries like 'pthread' exhibit this behaviour and it propagates up the dependency chain. This breaks programs which rely on reloading of affected dynamic libraries. Reproducible: Always Steps to Reproduce: 1. compile test program with 'g++ test.cpp -otest -ldl' 2. run 'for file in /usr/lib64/lib*.so; do ./test $file; done | grep failed' Actual Results: see attachment #2 Expected Results: /usr/lib64/librt.so failed. (at least that is what happens on my gentoo machine) AFAIK, x86_64 and x86 are both affected. Related: [[bugzilla:645652]] -- 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