September 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 869806] New: autofs '-hosts' broken by update to 5.0.8
by bugzilla_noreply＠novell.com 20 Sep '14

20 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=869806 https://bugzilla.novell.com/show_bug.cgi?id=869806#c0 Summary: autofs '-hosts' broken by update to 5.0.8 Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: nosliwg(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 After updating to autofs-5.0.8-19.8.1.x86_64, NFS mounts are no longer available via the autofs '-hosts' map. Two NFS shares exist on the network, and both can be mounted manually (using 'mount -t nfs server:/path'). Before the update, both could also be accessed using autofs by using the "/net -hosts" entry in auto.master. After update, attempting to access either share on the client returns "No such file or directory". A workaround is to replace /net -hosts --timeout=60 with /net /etc/auto.net --timeout=60 in auto.master. Issuing "service autofs status" gives Mar 19 21:53:37 gregpad automount[15428]: lookup_init:136: lookup(yp): map auto.master: Local domain name not set Mar 19 21:53:37 gregpad systemd[1]: Started Automounts filesystems on demand. Mar 19 21:53:39 gregpad automount[15428]: get_exports: lookup(hosts): exports lookup failed for naspad Mar 19 21:53:39 gregpad automount[15428]: key "naspad" not found in map source(s). (gregpad is the name of the client; naspad is the name of one of the servers which has an NFS share). I don't know if this was happening before the update. NIS (yp) is installed but is not enabled. /etc/hosts lists the client and server, and this setup seems to work for other commands (e.g., mount, showmount). Reproducible: Didn't try Steps to Reproduce: 1. Set up autofs with previous version: in the auto.master config file, add the line '/net -hosts --timeout=60'. 2. update to autofs-5.0.8-19.8.1.x86_64 (on the client) 3. attempt to view an NFS share under /net: e.g., 'ls /net/fileserver', where 'fileserver' is a server on the network which hosts an NFS share Actual Results: Attempts to access NFS shares in /net give "No such file or directory". The servers are recognized and listed under /net (e.g., /net/fileserver), but their NFS contents cannot be viewed. I did not attempt to reproduce the problem, as this would require downgrading to the previous version of autofs (I don't know how). Expected Results: I would expect 'ls /net/fileserver' to give a listing of NFS shares hosted by 'fileserver'. This was the (correct) behaviour before upgrading to the latest version of autofs. -- 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 897617] New: Long shuting down/restart - system hangs for about 90 seconds
by bugzilla_noreply＠novell.com 20 Sep '14

20 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=897617 https://bugzilla.novell.com/show_bug.cgi?id=897617#c0 Summary: Long shuting down/restart - system hangs for about 90 seconds Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: 32bit OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: scripter1(a)gmx.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=607082) --> (http://bugzilla.novell.com/attachment.cgi?id=607082) shutdown-log with human readable timecodes User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 When shutting down or restarting system from graphical environment (KDE4) or from console after logout system get stuck for about 90 seconds and then it closes/restarts. I added systemd debuging options to boot options and used debug.sh (from http://freedesktop.org/wiki/Software/systemd/Debugging/#Shutdown_Completes_… but with human readable timecodes option) to get shutdown-log and i found info that rsyslog.service does not exit properly and after 90 seconds systemd is killing it. Full shutdown-log in attachment. Reproducible: Always Steps to Reproduce: 1.Try to shutdown or restart system 2. 3. Actual Results: System shutsdown long - it takes about 90 seconds to poweroff/reboot Expected Results: System should shutdown fast and then poweroff/reboot laptop In case it is important this is Advent laptop (rebranded ESC G335) with installed Intel Core Duo T2600 processor and 2GB RAM memory. It has also additionally installed in inside USB a small USB Bluetooh dongle. -- 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 1

[Bug 895219] New: /etc/sysconfig/network/routes not set
by bugzilla_noreply＠novell.com 20 Sep '14

20 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=895219 https://bugzilla.novell.com/show_bug.cgi?id=895219#c0 Summary: /etc/sysconfig/network/routes not set Classification: openSUSE Product: openSUSE Factory Version: 201408* Platform: x86-64 OS/Version: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: wicked-maintainers(a)suse.de ReportedBy: bwiedemann(a)suse.com QAContact: qa-bugs(a)suse.de Found By: Development Blocker: --- on openSUSE 20140829 (x86_64) I used yast2 lan to configure extra routes > cat /etc/sysconfig/network/routes 192.168.0.0 192.168.11.5 255.255.0.0 - 10.0.0.0 192.168.11.5 255.0.0.0 - > cat /etc/sysconfig/network/ifcfg-enp1s0 BOOTPROTO='dhcp4' ... but those routes seem to be ignored by wicked even when explicitly calling rcnetwork restart -- 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 6

[Bug 897619] New: Connected via VNC client:=?UTF-8?Q?=20changes=20geometry=20after=20logon=20to=201920=C3=971200?=, and KDE crashes after logout .
by bugzilla_noreply＠novell.com 20 Sep '14

20 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=897619 https://bugzilla.novell.com/show_bug.cgi?id=897619#c0 Summary: Connected via VNC client: changes geometry after logon to 1920×1200, and KDE crashes after logout . Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: 64bit OS/Version: openSUSE 13.1 Status: NEW Severity: Critical Priority: P5 - None Component: KDE4 Workspace AssignedTo: kde-maintainers(a)suse.de ReportedBy: alkas(a)volny.cz QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=607083) --> (http://bugzilla.novell.com/attachment.cgi?id=607083) crash information - detailed User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Please see the attachment, too. - What I was doing when the application crashed: Logout (logoff) I have worked across the genuine VNC viewer connection. The VNC1 daemon has the geometry 1024×768 pixels. After login it itself have changed this geometry to 1920×1200 pixels. Why? My monitor has only 1200×1024 pixels, I guess. Despite that, all worked fine until I did logoff/logout, then the KDE process crashed. This occurs with VNC connection only and not using the computer's console. On the console also the geometry change does not occur. Reproducible: Sometimes Steps to Reproduce: 1. Log on via VNC viewer/client 2. Make some work. Not necessary. 3. Log out, KDE will crash. Not always crashes KDE only, sometimes crashes OS. Actual Results: Crashes, someimes offers sending a bug information. Expected Results: Logout and display the logon screen, possibly alternatively disconnect the VNC client. was observed in previous versions of OS, too -- 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 0

[Bug 868596] New: Login in ru.opensuse.org is broken
by bugzilla_noreply＠novell.com 20 Sep '14

20 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=868596 https://bugzilla.novell.com/show_bug.cgi?id=868596#c0 Summary: Login in ru.opensuse.org is broken Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Wiki AssignedTo: opensuse-bugs(a)opensuse.org ReportedBy: egdfree(a)opensuse.org QAContact: adrian(a)suse.com CC: xyliu(a)suse.com Found By: --- Blocker: --- Xiyuan Liu <xyliu(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xyliu(a)suse.com AssignedTo|bnc-team-screening(a)forge.pr |opensuse-bugs(a)opensuse.org |ovo.novell.com | User-Agent: Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 I try to login in ru.opensuse.org wiki, but i redirected to wrong URL. Login in en.opensuse.org work fine. Reproducible: Always Steps to Reproduce: 1. open http://ru.opensuse.org 2. put login data 3. oops Actual Results: redirect to http://ru.opensuse.org/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1… -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug.

1 4

[Bug 858556] New: springlobby doesn't find wxwidgets libraries and doesn't launch.
by bugzilla_noreply＠novell.com 20 Sep '14

20 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=858556 https://bugzilla.novell.com/show_bug.cgi?id=858556#c0 Summary: springlobby doesn't find wxwidgets libraries and doesn't launch. Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: Other OS/Version: SUSE Other Status: NEW Severity: Minor Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: vdziewiecki(a)suse.com QAContact: qa-bugs(a)suse.de CC: sbrabec(a)suse.com Found By: --- Blocker: --- Springlobby cannot find the libraries it needs. Actual results: wojtek@42ka:~> springlobby springlobby: error while loading shared libraries: libwx_baseu_net-2.8.so.0: cannot open shared object file: No such file or directory LD_LIBRARY_PATH=/usr/lib64/wx-2.8-wxcontainer/ springlobby - works ok Expected results: springlobby starts normally. -- 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 897412] New: installation stalls at installation of bootloader
by bugzilla_noreply＠novell.com 20 Sep '14

20 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=897412 https://bugzilla.novell.com/show_bug.cgi?id=897412#c0 Summary: installation stalls at installation of bootloader Classification: openSUSE Product: openSUSE Factory Version: 201409* Platform: x86-64 OS/Version: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Installation AssignedTo: yast2-maintainers(a)suse.de ReportedBy: macmillan.hugh(a)gmail.com QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 3 differently dated Factory ISOs have stopped installing at the installation of bootloader section. KDE Live x86_64 20140904 DVD Snapshot x86_64 20140909 KDE Live x86_64 20140915 With the live ISOs I can finish the install by pressing abort after pressing abort and then choosing to proceed. The Install does precisely that. I am unable to reproduce the state of continuing the install as the screen appears not to accept mouse clicks due to frozen state. Reproducible: Always Steps to Reproduce: 1.Fire up ISO from USB 2.Proceed to Desktop 3.Commence installation 4.edit proposal to exclude separate home 5.permit default file system and set / as mpount point 6.install grub2 to root partition 7. proceed with install Actual Results: install hangs at installation of bootloader On KDE Live this is at 86% On DVD Snapshot this is at 95% Expected Results: The installer should complete successfully. I can see no bar in my hardware to impede completion. -- 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 890882] New: Dropdown menus and tooltips leave frame shadows in Firefox
by bugzilla_noreply＠novell.com 19 Sep '14

19 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=890882 https://bugzilla.novell.com/show_bug.cgi?id=890882#c0 Summary: Dropdown menus and tooltips leave frame shadows in Firefox Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Minor Priority: P5 - None Component: Firefox AssignedTo: bnc-team-mozilla(a)forge.provo.novell.com ReportedBy: nenad(a)latinovic.info QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Hi again. As the title states: In Firefox 31, when using a dropdown menu of any sort, or hovering to reveal a tooltip, when the menu or tooltip closes, it leaves a frame where it used to be open, and it stays that way until you open something else, a menu, or another tooltip. I've been trying to printscreen it, but it disappears when i press the printscreen button. I don't know if it's a compositing issue of some sort, but i tried it out in KDE & qtcurve within that, and it doesn't happen there. So it's most surely a GNOME related issue. It also shouldn't be a theme related issue, since i use Gnome's Adwaita theme. Would be grateful if someone manages to look into it. Thanks again for your great work! Reproducible: Always Steps to Reproduce: 1.open a dropdown menu or tooltip 2.close the tooltip/menu 3.shadow frame remains until opening another menu Actual Results: Shadow frame remains. Expected Results: The menu/tooltip should close normally, without leaving shadows. Gnome Adwaita theme. -- 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 1

[Bug 897550] New: home:DarkSS/miniracer: Bug
by bugzilla_noreply＠novell.com 19 Sep '14

19 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=897550 https://bugzilla.novell.com/show_bug.cgi?id=897550#c0 Summary: home:DarkSS/miniracer: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Major Priority: P5 - None Component: 3rd party software AssignedTo: dap(a)open.by ReportedBy: giorgosk67(a)gmail.com QAContact: opensuse-communityscreening(a)forge.provo.novell.com Found By: Community User Blocker: No Miniracer, doesn't seems able to run. Here's the konsole output: giorgos-Παρ 19/09/2014 06:33 μμ~>miniracer ln: failed to create symbolic link «/home/giorgos/.MiniRacer/engine.glx»: File not found /usr/bin/miniracer: line 38: ./engine.glx: No such file or directory giorgos-Παρ 19/09/2014 06:33 μμ~> -- 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 0

[Bug 897353] New: db3 full scan slowness - affects rpmdb
by bugzilla_noreply＠novell.com 19 Sep '14

19 Sep '14

https://bugzilla.novell.com/show_bug.cgi?id=897353 https://bugzilla.novell.com/show_bug.cgi?id=897353#c0 Summary: db3 full scan slowness - affects rpmdb Classification: openSUSE Product: openSUSE Factory Version: 201409* Platform: All OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: klaussfreire(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=606898) --> (http://bugzilla.novell.com/attachment.cgi?id=606898) Test scripts User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 bsddb3 full scans (those performed by filter-less cursor walking) scan the backing file in random order, causing a much slower scan. This is a problem that affects rpmdb, which uses those kinds of scans while listing packages. Reproducible: Always Steps to Reproduce: Download attached test scripts 1. python bsdcreate.py 2. echo 3 | sudo tee /proc/sys/vm/drop_caches 3. time python bsdtest.py 4. time python bsdtest.py 5. echo 3 | sudo tee /proc/sys/vm/drop_caches 6. time ( cp fruit /dev/null ; python bsdtest.py ) Actual Results: First run (step 3) takes a long time, much longer than second (step 4) and third (step 5), even though step 5 also reads from disk, it does so in sequential order which is much faster Expected Results: First and third run should take about the same time, the scan should be done in physical order to leverage kernel both read-ahead and rotating media's higher pefromance for sequential reads. There's another script, bsdtest_fadvise.py, that issues a posix_fadvise call to preload the file before initiating the scan. This also results in far better performance, and would be an appropriate workaround for "rpm -qa" (which does such a scan). For that to work, python-fadvise must be installed from https://github.com/lamby/python-fadvise As the package database grows, it's becoming important to optimize this. -- 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