October 2015 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 927968] M17N/fonts-config: Bug
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.novell.com/show_bug.cgi?id=927968 http://bugzilla.novell.com/show_bug.cgi?id=927968#c6 --- Comment #6 from Bernhard Wiedemann <bwiedemann(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (927968) was mentioned in https://build.opensuse.org/request/show/335128 Leap:42.1 / fonts-config -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 912279] Changing font preferences of serif, sans, and monospace needs manually running fonts-config
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.novell.com/show_bug.cgi?id=912279 http://bugzilla.novell.com/show_bug.cgi?id=912279#c13 --- Comment #13 from Bernhard Wiedemann <bwiedemann(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (912279) was mentioned in https://build.opensuse.org/request/show/335128 Leap:42.1 / fonts-config -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 907685] fontconfig: wrong link to documentation in fc-list.1
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.novell.com/show_bug.cgi?id=907685 http://bugzilla.novell.com/show_bug.cgi?id=907685#c3 --- Comment #3 from Bernhard Wiedemann <bwiedemann(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (907685) was mentioned in https://build.opensuse.org/request/show/335127 Leap:42.1 / fontconfig -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 947697] cannot boot from extended partition
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.suse.com/show_bug.cgi?id=947697 http://bugzilla.suse.com/show_bug.cgi?id=947697#c13 Steffen Winterfeldt <snwint(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Steffen Winterfeldt <snwint(a)suse.com> --- patch has been submitted -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 948064] 4.3-rc2 hangs
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

1 0

[Bug 947593] Distributor field is missing from Yast Boot Loader in Leap 42.1 Beta 1
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.suse.com/show_bug.cgi?id=947593 http://bugzilla.suse.com/show_bug.cgi?id=947593#c9 --- Comment #9 from Josef Reidinger <jreidinger(a)suse.com> --- (In reply to Roman Bysh from comment #7) > Josef, > > This is an extreme disappointment for the openSUSE community user. In fact, > we worked very hard with Michael Chang over a number of months to add these > features so that the Yast Boot Loader finally evolved. And offered something > the other distros did not offer. > > This took a number of years of begging on Bugzilla and email until we found > the right people that understood our requests. > > The openSUSE Leap 42.1 distro - which has incorporated the core from SuSE > Enterprise is supposed to be a step up in stability and features. You have > downgraded the Yast Boot Loader. Same change is done also in SuSE Enterprise. It is not downgrading only opensuse. We use same version for opensuse and SLE. > > The upgrade from Grub1 to Grub2 introduced a boot loader that uses scripts. > In their haste, the developers had forgotten to allow the user to edit and > customize their entries. At least in Grub1 we could edit the "menu.lst" > file. To make it clarify: 1) you still can edit final generated config, but it will be overwritten, so you need to copy your manually crafted version over it again. 2) grub2 have many options how to affect script, one of it is /etc/default/grub where is simple config option and among them is DISTRIBUTOR, which can be manually adjusted and YaST2 will respect it. > > Many appreciate the ability to customize via the gui so that they can clean > up the entries according to their work environment. The Grub2 scripts hunt > down the entries without regard of the appearance of the entry. Now you want > to go back to this in 2015-2016? No, my goal is to make gui reasonably small, as too many entries confuse not so experienced users. As I said, we do not limit your expert changes in config. But goal of YaST is not to provide all options available in config file in gui, but to provide consistent UI that helps users with common operations in easy way. And to be honest changing distributor is not common nor critical, because system will boot without such change and default is reasonable enough. > > Our entries appears as: > openSUSE 42.1 Beta 1 (x86_64) (on /dev/sdb1) > > We do not like this. We want it to appear as: > openSUSE 42.1 Beta 1 This is not affected by distributor field. Distributor field is "openSUSE 42.1 Beta 1". arch and location is added by grub2 script and setting distributor do not help you. > > or whatever in the final release. > > Can you at least offer another Yast Boot Loader with the "Distribution" > option in the Leap 42.1 repository. It is not option as bootloader is used in installer, so we need unified version. Of course you can build your own version in your build service home with reverted patch - https://patch-diff.githubusercontent.com/raw/yast/yast-bootloader/pull/260.… (In reply to Roman Bysh from comment #8) > The reason for disabling the "Distributor field" in the gui/ncurses version > of the Yast Boot Loader is an unrealistic reason for removal when using a > text-based tool such as zypper. It is very often used way how to upgrade opensuse distributions. SLE do not support it, so it is opensuse mainly way to upgrade distribution and in installation it is needed to have reasonable good default ( empty distributor flag ). Ability to change it can cause more harm then benefit for newbie users if they change it. > > Why not remove the gui fields for "Vga mode" or "Console resolution"? You > can always edit and add them to the "Optional Kernel Command Line > Parameters" field. To be honest I already considering it, but in the end there is part of users that need it ( due to bad firmware of graphic card ) and e.g. vga mode helps users to pick correct resolution and same for console resolution. So it is critical for part of users to boot and helps them to have bootable system. > > It's the same difference. You are penalizing the functional gui use field on > the Yast Boot Loader because there is a limitation of a text-based > installation tool. It is not text-based installation tool. It is upgrade tool. Regarding penalizing...I need to have balance in UI, we cannot always add fields. I e.g. add ability to set password for bootloader which is non-trivial task and more people use it then changing distributor field. Even now there is three tabs which looks too much for me and I am trying to reduce it only to reasonable options. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 948352] New: the HP service HPLIP Status Service can not start.
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.novell.com/show_bug.cgi?id=948352 Bug ID: 948352 Summary: the HP service HPLIP Status Service can not start. Classification: openSUSE Product: openSUSE Factory Version: 2015* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Printing Assignee: jsmeix(a)suse.com Reporter: mcaj(a)suse.com QA Contact: jsmeix(a)suse.com Found By: --- Blocker: --- HI since drop KDE4 and using PLASMA as default desktop for KDE there is a trouble with HP application HPLIP Status Service. The program can not start and end up with the messages "No system tray detect on this system Unable to start, exiting" I'm using the latest version from OSS repo: Repository: Main Repository (OSS) Name: hplip Version: 3.15.6-1.2 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: up-to-date step to reproduce: 1. instal the latest openSUSE Tumbleweed 2. select KDE PLASMA as default desktop 3. install hplip Martin -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 947704] "Calling the YaST module `inst_proposal has failed"
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.suse.com/show_bug.cgi?id=947704 http://bugzilla.suse.com/show_bug.cgi?id=947704#c8 Arvin Schnell <aschnell(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Arvin Schnell <aschnell(a)suse.com> --- OK, then it just fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 934202] New: NFS: nfs4_handle_delegation_recall_error: unhandled error -13.
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.suse.com/show_bug.cgi?id=934202 Bug ID: 934202 Summary: NFS: nfs4_handle_delegation_recall_error: unhandled error -13. Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: nfbrown(a)suse.com Reporter: tchatzimichos(a)suse.com QA Contact: qa-bugs(a)suse.de CC: mcaj(a)suse.com, mpluskal(a)suse.com, ncutler(a)suse.com Found By: --- Blocker: --- This bug was reported first in the internal SUSE ticketing system. I am copy-pasting all the current comments from that ticket to this one: **** Nathan Cutler ****: Ever since the migration from login.suse.cz to nfs.suse.cz that took place over the weekend 2015-05-30 and 2015-05-31, my workstation's NFS home (pantograf.suse.cz) in unstable. The problem manifests approx. once every 3-4 hours of usage. Randomly, for no apparent reason. First, I/O to /home partition starts to hang. Load average starts to rise and a mystery process "10.100.2.89-man" appears in "top" listing. This process is unkillable even with SIGKILL. Running programs continue to work as long as they do not attempt I/O to the home partition, then they freeze up. The only fix I know of is to reboot the machine. Referring to the log, the problem appears to be apparmor-related: 2015-06-03T10:52:33.390867+02:00 pantograf kernel: [ 1066.488685] audit: type=1400 audit(1433321553.389:49): apparmor=" DENIED" operation="sendmsg" profile="/usr/bin/lessopen.sh" pid=5183 comm="file" laddr=10.100.12.15 lport=830 faddr=10.1 00.2.89 fport=2049 family="inet" sock_type="stream" protocol=6 2015-06-03T10:52:33.390885+02:00 pantograf kernel: [ 1066.488720] nfs: RPC call returned error 13 2015-06-03T10:52:33.391849+02:00 pantograf kernel: [ 1066.489192] audit: type=1400 audit(1433321553.390:50): apparmor=" DENIED" operation="sendmsg" profile="/usr/bin/lessopen.sh" pid=5183 comm="file" laddr=10.100.12.15 lport=830 faddr=10.1 00.2.89 fport=2049 family="inet" sock_type="stream" protocol=6 2015-06-03T10:52:33.391856+02:00 pantograf kernel: [ 1066.489204] nfs: RPC call returned error 13 2015-06-03T10:52:33.414853+02:00 pantograf kernel: [ 1066.512310] audit: type=1400 audit(1433321553.413:51): apparmor=" DENIED" operation="sendmsg" profile="/usr/bin/lessopen.sh" pid=5178 comm="lessopen.sh" laddr=10.100.12.15 lport=830 fad dr=10.100.2.89 fport=2049 family="inet" sock_type="stream" protocol=6 2015-06-03T10:52:33.414863+02:00 pantograf kernel: [ 1066.512326] nfs: RPC call returned error 13 2015-06-03T10:52:33.415875+02:00 pantograf kernel: [ 1066.513919] audit: type=1400 audit(1433321553.414:52): apparmor=" DENIED" operation="sendmsg" profile="/usr/bin/lessopen.sh" pid=5185 comm="lessopen.sh" laddr=10.100.12.15 lport=830 fad dr=10.100.2.89 fport=2049 family="inet" sock_type="stream" protocol=6 2015-06-03T10:52:33.415888+02:00 pantograf kernel: [ 1066.513935] nfs: RPC call returned error 13 2015-06-03T10:52:33.416857+02:00 pantograf kernel: [ 1066.514853] audit: type=1400 audit(1433321553.415:53): apparmor=" DENIED" operation="sendmsg" profile="/usr/bin/lessopen.sh" pid=5185 comm="file" laddr=10.100.12.15 lport=830 faddr=10.1 00.2.89 fport=2049 family="inet" sock_type="stream" protocol=6 2015-06-03T10:52:33.416869+02:00 pantograf kernel: [ 1066.514868] nfs: RPC call returned error 13 2015-06-03T10:52:33.417857+02:00 pantograf kernel: [ 1066.515346] audit: type=1400 audit(1433321553.416:54): apparmor=" DENIED" operation="sendmsg" profile="/usr/bin/lessopen.sh" pid=5185 comm="file" laddr=10.100.12.15 lport=830 faddr=10.1 00.2.89 fport=2049 family="inet" sock_type="stream" protocol=6 2015-06-03T10:52:33.417867+02:00 pantograf kernel: [ 1066.515358] nfs: RPC call returned error 13 Please advise. Update: I disabled AppArmor so those messages are gone But the I/O lockups continue. After examining the log closer, I believe this is the relevant message: 2015-06-03T16:52:33.508329+02:00 pantograf kernel: [13191.933894] NFS: nfs4_handle_delegation_recall_error: unhandled error -13. **** Neil Brown ****: I'm pretty sure that I've seen exactly this bug already. I just need to remember which one... I don't think this is related to kerberos at all. It is purely an NFSv4 state management issue. It is a bit like 831029, but maybe not exactly the same. I'll have a more thorough look after the weekend. Exactly which kernel do you have on your client? NeilBrown **** Nathan Cutler ****: Linux pantograf 3.16.7-21-desktop #1 SMP PREEMPT Tue Apr 14 07:11:37 UTC 2015 (93c1539) x86_64 x86_64 x86_64 GNU/Linux **** Theo Chatzimichos ****: Just for the record, Martin Caj's PC runs KDE with the same kernel version, and it has mounted the NFS /home since Friday. I just checked its dmesg and didn't see such error messages reported. The machine is now on low load though since Martin is away **** Nathan Cutler ****: It only happens if you actually use the desktop. I can leave KDE running all night, all day and as long as I do not use the machine, or use it only via ssh from home, nothing happens. The I/O freezes only happen when I am sitting physically at the machine, clicking in Thunderbird, Pidgin, Firefox, etc. When Martin gets back I will work with him to reproduce it. Nathan **** Martin Pluskal ****: Hi I have also encountered those issues (on current TW with kernel 4.1.0-rc6-2.g8f2a4d1-desktop) I have captured dmesg after issuing "rpcdebug -m nfs -s all" - see http://users.suse.cz/~mpluskal/bugs/nfs_issues/dmesg.txt.xz - perhaps it contains something useful. Kind regards Martin **** Neil Brown ****: I've had a bit more of a look at this and I think it is a new problem. There have been quite a few different bugs which involve the nn.nn.nn.nn-man thread spinning, but this doesn't seem to fit the pattern of any of them. So maybe it would be best to open a bug on bugzilla. The "unhandled error -13." is an NFS4ERR_ACCES error. When the client tried to open some file, the Netapp gave it a delegation. It presumably then opened the file again without telling the server, on the strength of that delegation. At some point the delegation needed to be returned so the client requested explicit opens from the server. One of those failed with "EACCESS" meaning the user on the client didn't seem to have permission. That is very odd. The state management thread then goes into a spin. This suggests that it was the state management thread which decided that the delegation needed to be returned. Maybe it got some sort of state error. I cannot easily find a path through the code that would make it spin, but it is fairly complex code. One thing that might help is to capture the content of /proc/PID/stack for the threads that is using all the CPU time. Capture that a dozen times or so in quick succession. Or maybe capture hundreds and discard the duplicates. The other thing that could be useful is a tcpdunp trace of NFS (port 2049) traffic between client and server when the problem occurs. So if you can reliably trigger it, that should be easy to get. -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 942178] New: NFS4 Java file lock problem with kernel 3.16.7-24.1
by bugzilla_noreply＠novell.com 01 Oct '15

01 Oct '15

http://bugzilla.opensuse.org/show_bug.cgi?id=942178 Bug ID: 942178 Summary: NFS4 Java file lock problem with kernel 3.16.7-24.1 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: timo.boehme(a)ontochem.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When locking a file on a NFS4 mounted file system via Java FileLock class under Linux kernel 3.16.7-24.1 this is not recognized by another Java program on another OpenSuse computer with kernel 3.16.7-21.1. Going back to kernel 3.16.7-21.1 all is fine. The NFS4 file system is mounted as rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=XXX.XXX.XXX.XXX,local_lock=none,addr=XXX.XXX.XXX.XXX on both machines. According to http://stackoverflow.com/questions/23562369/is-a-filelock-a-posix-advisory-… the Java FileLock class (Sun Java 6) uses POSIX fcntl locks. The problem is critical because the standard Java Logging implementation is now broken. The implementation tests if it can exclusively lock the .lck file which secures a lock file. If the machine with kernel 3.16.7-24.1 created this file (and locked it) the other machine gets nevertheless an exclusive lock on the .lck file assuming it created the file and moves the lock file from the first process away. Somehow it seems like the local_lock parameter is set to another value than 'none' despite the fact that the mount option was 'none'. -- You are receiving this mail because: You are on the CC list for the bug.

1 11