November 2014 - openSUSE Bugs - openSUSE Mailing Lists

[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 905558] New: "zypper -ve" throws strange dependency errors for some applications (firefox, thunderbird...)
by bugzilla_noreply＠novell.com 15 Feb '17

15 Feb '17

http://bugzilla.opensuse.org/show_bug.cgi?id=905558 Bug ID: 905558 Summary: "zypper -ve" throws strange dependency errors for some applications (firefox, thunderbird...) Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)forge.provo.novell.com Reporter: madworm_de.novell(a)spitzenpfeil.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Build Identifier: The only way to get rid of this error is to completely remove the offending applications. Nothing else works. --- linux-m086:/home # zypper ve Loading repository data... Reading installed packages... Problem: nothing provides appdata(firefox.appdata.xml) needed by application:Firefox-.noarch Solution 1: deinstallation of application:Firefox-.noarch Solution 2: break application:Firefox-.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): --- Pressing (1) doesn't do anything. In this case it only goes away after removing all the MozillaFirefox rpms. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 899755] New: Better integration between zypper and PackageKit needed
by bugzilla_noreply＠novell.com 06 Feb '17

06 Feb '17

http://bugzilla.opensuse.org/show_bug.cgi?id=899755 Bug ID: 899755 Summary: Better integration between zypper and PackageKit needed Classification: openSUSE Product: openSUSE Factory Version: 201409* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)forge.provo.novell.com Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- on openSUSE Factory and 13.2, PackageKit gets a bigger role due to the usage of gnome-software, which also checks the repo metadata in the background if the user types anything in the Overview screen (like: I want to start gimp, but don't have it installed; g-software will find it and suggest it right away; based on appstream data) now, this makes PackageKit almost permanently around (we still have it configured now to terminate after 15s idle, whenever you type anything in g-s, it's being fired up). Preferably, the PK daemon would not need to have to be terminated at all, but would be allowed to run. PK is built in a way that a lock is taken whenever an action on the DB happens (refresh, get-updates, install,...) using ZyppJob::ZyppJob. This should be enhanced to be able to share the lock with other things relying on zypp. As far as I've seen, zypper currently simply agressibly wants the packagekitd to terminate, regardless if it's there in idle or having a lock on the DB. This is a rude attack. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[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 902612] New: systemd automounts manually umounted devices again
by bugzilla_noreply＠novell.com 02 Feb '17

02 Feb '17

http://bugzilla.opensuse.org/show_bug.cgi?id=902612 Bug ID: 902612 Summary: systemd automounts manually umounted devices again Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: sweet_f_a(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Just noticed that systemd automatically mounts devices again allthough I've manually umounted them. Here is what I did $ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered) ## umount and disable that lvm device $ umount /mnt/local $ lvchange -an vg0/local systemd[1]: Stopping File System Check on /dev/vg0/local... systemd[1]: Stopped File System Check on /dev/vg0/local. ## enable device again $ lvchange -ay vg0/local systemd[1]: Found device /dev/mapper/vg0-local. systemd[1]: Found device /dev/disk/by-uuid/177a415d-174d-4c30-8897-5502c0419ef8. systemd[1]: Found device /dev/disk/by-id/dm-uuid-LVM-uF33oY4c9yu00EPAP42a8A2XZCfQTRRPGfiv0cNZRwPKIRJnOboscsc1z60174dd. systemd[1]: Found device /dev/disk/by-id/dm-name-vg0-local. systemd[1]: Found device /dev/dm-0. systemd[1]: Found device /sys/devices/virtual/block/dm-0. systemd[1]: Starting File System Check on /dev/vg0/local... systemd-fsck[6386]: /dev/mapper/vg0-local: clean, 648240/3276800 files, 9308645/13107200 blocks systemd[1]: Started File System Check on /dev/vg0/local. systemd[1]: Mounting /mnt/local... kernel: [ 5542.579700] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,user_xattr systemd[1]: Mounted /mnt/local. $ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered) So what kind of automount is this? How to disable this odd behaviour? -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 907715] New: Predictable iSCSI device links are not being created any more in /dev/disks/by-path
by bugzilla_noreply＠novell.com 01 Feb '17

01 Feb '17

http://bugzilla.opensuse.org/show_bug.cgi?id=907715 Bug ID: 907715 Summary: Predictable iSCSI device links are not being created any more in /dev/disks/by-path Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: f+novell(a)congenio.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When an iSCSI target is connected, its corresponding device link under /dev/disk/by-path/ip-<IP_ADDR>:<PORT>-iscsi-<IQN>-iscsi-lun-<LUN#>-part<PART#> is not being created any more. This is extremely limiting, because the real scsi device (say, /dev/sdg1) is quite unpredictable. The reason for this is a patch in upstream systemd: http://cgit.freedesktop.org/systemd/systemd/commit/?id=e98bbfd2074e2b1079b7… Lee Duncan of SuSE Labs has pointed that one out to upstream maintainers (http://lists.freedesktop.org/archives/systemd-devel/2014-October/024155.html) but the bug is still in openSUSE 13.2. Fedora had that one fixed as well (see https://bugzilla.redhat.com/show_bug.cgi?id=1161779) In order to fix this, this patch should be applied: Index: systemd-210/src/udev/udev-builtin-path_id.c =================================================================== --- systemd-210.orig/src/udev/udev-builtin-path_id.c +++ systemd-210/src/udev/udev-builtin-path_id.c @@ -547,6 +547,7 @@ } else if (streq(subsys, "scsi")) { parent = handle_scsi(parent, &path); supported_transport = true; + supported_parent = true; } else if (streq(subsys, "cciss")) { parent = handle_cciss(parent, &path); supported_transport = true; -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 905645] New: mdm doesn't work
by bugzilla_noreply＠novell.com 27 Jan '17

27 Jan '17

http://bugzilla.opensuse.org/show_bug.cgi?id=905645 Bug ID: 905645 Summary: mdm doesn't work Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: mgonnelly(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 613796 --> http://bugzilla.opensuse.org/attachment.cgi?id=613796&action=edit Log file including login time Trying to use mdm from http://download.opensuse.org/repositories/X11:/Cinnamon:/Factory/openSUSE_1… Seems to login correctly but no desktop session is started. Log files contain GLib-CRITICAL errors but these are cosmetic and can be worked around as reported here: https://github.com/linuxmint/mdm/issues/76 -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[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 902697] New: Cannot start software witin YAST e.g Network Settings or Software Repositories
by bugzilla_noreply＠novell.com 20 Jan '17

20 Jan '17

http://bugzilla.opensuse.org/show_bug.cgi?id=902697 Bug ID: 902697 Summary: Cannot start software witin YAST e.g Network Settings or Software Repositories Classification: openSUSE Product: openSUSE Factory Version: 201408* Hardware: i586 OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: f.leerink(a)xs4all.nl QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 611307 --> http://bugzilla.opensuse.org/attachment.cgi?id=611307&action=edit yast2 error message from Konsole After the Yast CONTROL Center software started successfully and I click e.g Network Settings you can see by the rotating stick that that program is started but that is all that happened. If I try to start ,as root, yast2 from the konsole I get the following error message: inux-vbye:/home/frans # yast2 static QPlatformTheme* QKdeTheme::createKdeTheme(): Unable to determine KDEHOME Run command: /sbin/yast2 add-on & [BUG] Segmentation fault at 0x000378 ruby 2.1.2p95 (2014-05-08 revision 45877) [i586-linux-gnu] [NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries. Bug reports are welcome. For details: http://www.ruby-lang.org/bugreport.html /sbin/yast2: line 440: 2669 Aborted $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS See attatchment for more details I have installed this system yesterday and have applied all available updates. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 904484] New: Nouveau x.org stays dark after resume from suspended state
by bugzilla_noreply＠novell.com 20 Jan '17

20 Jan '17

http://bugzilla.opensuse.org/show_bug.cgi?id=904484 Bug ID: 904484 Summary: Nouveau x.org stays dark after resume from suspended state Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: bnc-team-xorg-bugs(a)forge.provo.novell.com Reporter: lmuelle(a)suse.com QA Contact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: Development Blocker: No Suspend and resume worked for this system with openSUSE 13.1, kernel-default-3.11.10-21.1, with the Nouveau x.org driver. After a fresh install suspend works and resume is possible too. Afterwards I'm able to login over the network with ssh for example. Unfortunately the display stays black. Compared with bug#904483 (s2ram case) it doesn't help to go back to an openSUSE 13.1 kernel. -- You are receiving this mail because: You are on the CC list for the bug.

1 4