openSUSE Bugs March 2009

bugs@lists.opensuse.org

1 participants
2070 discussions

[Bug 479195] New: Install-time VNC server crashes on connection
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=479195 Summary: Install-time VNC server crashes on connection Classification: openSUSE Product: openSUSE 11.0 Version: Final Platform: x86 OS/Version: openSUSE 11.0 Status: NEW Severity: Major Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jra(a)baylink.com QAContact: jsrain(a)novell.com Found By: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 When attempting to use the VNC installation to install the OS remotely on a bare machine, the VNC server crashes when a VNC viewer client attempts to connect to it, after the VNC password is given and accepted. I've tried this with the current UltraVNC viewer, 1.0.5, as well as the TightVNC viewer 1.3.10; I also tried switching the Ultra viewer from ZRLE to Tight mode. The crash happens just after connection, after (or as) the first desktop screen is being painted on the viewer window -- sometimes I can see the entire screen, and then a memory-scribble stride pattern is painted across it before the disconnect ("error WriteExact"); sometimes it crashes in the middle of painting the screen. This has happened on 2 separate servers; one an ASUS P5WDG with an RTL8169 card; one a SuperMicro C2SBC-Q with whatever the stock NIC is on that. I gather another bug on this was merged into a 10.3 bug about after-install VNC problems; I would recommend against merging this bug with *anything* -- if there's another bug on this problem, BZ declines to provide it to me in a search. I'm going to install a *LOT* of 11.0 server this year; this is a P2 bug for me. Reproducible: Always Steps to Reproduce: 1. Start an 11.0 install with "VNC=1" on the command line 2. Specify a static IP, net mask, no gateway, and hit ESC at DNS 3. Try to connect and observe crash 4. Blather, wince, repeat Actual Results: The VNC server crashes, leaving a red error dialog on the system console screen saying "A failure occurred during the installation" (or something within 5% of that) Expected Results: I should be able to perform a graphical install through the VNC connection -- 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 5

[Bug 465930] New: Very slow upload speeds with iwl3945 driver
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=465930 Summary: Very slow upload speeds with iwl3945 driver Classification: openSUSE Product: openSUSE 11.1 Version: RC 2 Platform: i586 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: victorrz(a)gmail.com QAContact: qa(a)suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121300 SUSE/3.0.5-2.5 Firefox/3.0.5 Upload speeds are around 50-80KB/s with downloads speeds approx 1MB/s on the iwl3945 wireless connection to a 54G router running WPA2. Windows XP upload and download rates are equal at around 1MB/s. This behavior seems similar to the bug report in this thread: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/288948 dmesg ouptput: iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks iwl3945: Copyright(c) 2003-2008 Intel Corporation iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 iwl3945 0000:03:00.0: setting latency timer to 64 iwl3945: Detected Intel Wireless WiFi Link 3945ABG iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels phy0: Selected rate control algorithm 'iwl-3945-rs' iwl3945 0000:03:00.0: PCI INT A disabled iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 iwl3945 0000:03:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006) firmware: requesting iwlwifi-3945-1.ucode Registered led device: iwl-phy0:radio Registered led device: iwl-phy0:assoc Registered led device: iwl-phy0:RX Registered led device: iwl-phy0:TX Reproducible: Always Steps to Reproduce: 1.Use the iwl3945 wireless connection to copy a large file using ssh or smb. 2. 3. -- 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 20

[Bug 370872] New: "pccardctl eject" hangs in state D
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=370872 Summary: "pccardctl eject" hangs in state D Product: openSUSE 11.0 Version: Alpha 2plus Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: seife(a)novell.com QAContact: qa(a)suse.de CC: fseidel(a)novell.com Found By: Development During suspend, one thing we do is eject PCMCIA card with "pccardctl eject". I quite frequently see that command hanging in state D, which makes suspend fail. Attempting to shut down the machine cleanly lead to a hang when the sound modules are unloaded, a clean shutdown does only happen if i do a sysrq-e to kill the hanging processes and make init proceed. I have seen this with various 3G/UMTS CardBus cards, both USB-serial based and nozomi based, so i believe this to be a generic PCMCIA issue. Will attach sysrq-T -- 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 108

[Bug 490733] New: npviewer.bin[PID]: segfault at **** ip *** sp *** error 4 in libpthread-2.8.so[****+**]
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=490733 Summary: npviewer.bin[PID]: segfault at **** ip *** sp *** error 4 in libpthread-2.8.so[****+**] Classification: openSUSE Product: openSUSE 11.0 Version: Final Platform: i686 OS/Version: openSUSE 11.0 Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: robin.listas(a)telefonica.net QAContact: sndirsch(a)novell.com Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-1.1 Firefox/3.0.7 npviewer.bin segfaults continuously when opening web pages with firefox: Mar 31 16:42:00 nimrodel kernel: npviewer.bin[19702]: segfault at b5be9030 ip b781e520 sp bfbf9240 error 4 in libpthread-2.8.so[b7817000+14000] Mar 31 16:42:03 nimrodel kernel: npviewer.bin[19717]: segfault at b5b9c030 ip b77d1520 sp bfdac3f0 error 4 in libpthread-2.8.so[b77ca000+14000] Mar 31 16:42:13 nimrodel kernel: npviewer.bin[19744]: segfault at b5c28030 ip b785d520 sp bfd39ad0 error 4 in libpthread-2.8.so[b7856000+14000] Mar 31 16:42:14 nimrodel kernel: npviewer.bin[19759]: segfault at b5c30030 ip b7865520 sp bf83fe80 error 4 in libpthread-2.8.so[b785e000+14000] This sample was when browsing <http://www.eweek.com/c/a/Windows/Microsoft-TomTom-Settle-Patent-Infringemen…>, but I think it happens with every page. It has been happening for months. The browser seems to work fine, I don't see ill effects - AFAIK System: openSUSE 11.0, updates current. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-1.1 Firefox/3.0.7 plugins: File name: npwrapper.libflashplayer.so Shockwave Flash 9.0 r159 File name: npwrapper.libtotem-basic-plugin.so The Totem 2.22.0 plugin handles video and audio streams. File name: npwrapper.libtotem-cone-plugin.so The Totem 2.22.0 plugin handles video and audio streams. File name: npwrapper.libtotem-gmp-plugin.so The Totem 2.22.0 plugin handles video and audio streams. File name: npwrapper.libtotem-mully-plugin.so DivX Web Player version 1.4.0.233 File name: npwrapper.libtotem-narrowspace-plugin.so The Totem 2.22.0 plugin handles video and audio streams File name: npwrapper.nphelix.so Helix DNA Plugin: RealPlayer G2 Plug-In Compatible version 0.4.0.626 built with gcc 3.3.3 on Jul 26 2007 File name: npwrapper.nppdf.so The Adobe Reader plugin is used to enable viewing of PDF and FDF files from within the browser. File name: npwrapper.opensc-signer.so This plugins handles web signatures using OpenSC smart card library. File name: npwrapper.nsdejavu.so This is the DjView-4.1 version of the DjVu plugin. See DjVuLibre. File name: libnpjp2.so File name: npwrapper.so nspluginwrapper is a cross-platform NPAPI plugin viewer, in particular for linux/i386 plugins. This is beta software available under the terms of the GNU General Public License. File name: gxineplugin.so will start external gxine media player for embedded media streams Extensions: Beagle indexer 1.1.0 Diccionario español/España 1.2.1 Flashblock 1.5.9 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 11

[Bug 481835] New: Icewm lacks many 86_64 pkgs, default cannot be installed wap.
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=481835 Summary: Icewm lacks many 86_64 pkgs, default cannot be installed wap. Classification: openSUSE Product: openSUSE 11.2 Version: Alpha 0 Platform: x86-64 OS/Version: SuSE Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: monkey9(a)iae.nl QAContact: qa(a)suse.de Found By: Beta-Customer At this time, it is not possible to have a clock and all the other widgets that come with the default ice-wm. Will this change in the near future? -- 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 487170] New: VM start up fails during install attempt when "Sparse Image File" is unchecked
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=487170 Summary: VM start up fails during install attempt when "Sparse Image File" is unchecked Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Xen AssignedTo: cgriffin(a)novell.com ReportedBy: rschweikert(a)novell.com QAContact: qa(a)suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-1.4 Firefox/3.0.7 FirePHP/0.2.4 When the user un-checks the "Create Sparse Image File" check box in the "Virtual Disk" dialog and then proceeds to create the VM the procedure fails with the error message "Failed to start VM" It also appears as if the creation procedure will fail if a location other than the default is specified for the VM file. Reproducible: Always Steps to Reproduce: 1.Start "Create VM" app 2.Choose SLED 11 as the OS in the VM 3.Set max memory to 1024 4.In the virtual disk dialog un-check "Create Sparse Image File" 5.Select install source (in my case ISO image on local disk) 6.Start VM creation Case 2: 1.Start "Create VM" app 2.Choose SLED 11 as the OS in the VM 3.Set max memory to 1024 4.In the virtual disk dialog change the default location (/vm_images_lcl/xen in my case with 777 on both directories) 5.Select install source (in my case ISO image on local disk) 6.Start VM creation Actual Results: Triggers error with "Failed to start VM" Expected Results: Fixed size VM file of specified size (8 GB in my case) -- 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 490763] New: KRunner in kde 4.2.1 if finds several matching element in history disappears
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=490763 Summary: KRunner in kde 4.2.1 if finds several matching element in history disappears Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: i586 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace AssignedTo: kde-maintainers(a)suse.de ReportedBy: nafradi(a)yahoo.com QAContact: qa(a)suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-1.1.6 Firefox/3.0.7 After pressing alt+F2 and starting a command to KRuner it disappears when the bottom part with the icons appears. The KRuner "icon" on the bottom task manager is still visible and by clicking to maximize it it appears again. One can make it disappear by resize it as well Reproducible: Always Steps to Reproduce: 1. alt +f2 2. type something which has more element in the history than its width Alternatively 1. alt +f2 2. type something with only few found icons 3. resize the window to make it too small Actual Results: the KRuner window disappears Expected Results: define some minimal size and/or open a scroll bar. -- 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 489077] New: YaST buttons clickable but may have no immediate effect
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=489077 User jsmeix(a)novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=489077#c442475 Summary: YaST buttons clickable but may have no immediate effect Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: All OS/Version: SuSE Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Usability AssignedTo: mschmidkunz(a)novell.com ReportedBy: jsmeix(a)novell.com QAContact: qa(a)suse.de CC: kmachalkova(a)novell.com, alpha096(a)virginbroadband.com.au Found By: Development When a YaST module runs, then in the YaST user interface the buttons in the dialogs are usually always clickable (i.e. at any time the user can click a button) even when at the same time YaST is busy with something else so that YaST cannot immediately do what the click requests and in the end the user's click action has no immediate effect. After YaST had finished why it was busy while the user clicked, the click event will be actually processed so that the actual effect of the button click happens delayed. As far as I know this is just the normal behaviour of any usual application. For example when my web-browser (e.g. Firefox) is busy with downloading a huge amount of data or when it is busy with starting a helper application like the Adobe Reade to view a downloaded PDF there is no immediate effect whe I click a button in the web-browser's menue. Therefore the issue in YaST is no bug but nevertheless the usability feeling is bad so that I filed this enhancement request for the next openSUSE version so that we can find out how we could improve the situation. Here some bug reports where the issue becomes really annoying for the user: https://bugzilla.novell.com/show_bug.cgi?id=442173#c4 ------------------------------------------------------------------- clicking the [Abort] button has not the expected effect. One can click [Abort] but then one must wait all the time until the GUI has completed its job (i.e. until the list finally shows up) and afterwards the module is aborted just when the reason for the abort request is no longer valid. ------------------------------------------------------------------- bug #442475 ------------------------------------------------------------------- Cancel button ineffective while starting the module .. If a Yast Application stalls at any point, using the Cancel Button has NO effect on the Yast Application. .. IG ANY YAST Module hangs for any reason on completion of settings you have to wat for it to time out- Abort or Canceled are ignore ------------------------------------------------------------------- https://bugzilla.novell.com/show_bug.cgi?id=481299#c5 ------------------------------------------------------------------- no matter the cause - the user cannot terminate the process .. As a conventional user the only option now is to shut down/restart the PC ------------------------------------------------------------------- My current personal thoughts: Usually there is only one single process which is running. When this single process is busy with something else it cannot process what a button click requests. This is a limitation of the core operating system and we cannot do anything here on the YaST module level with reasoable effort - this means that it is impossible regarding the effort when each YaST module author would have to implement his module as a multi-process or multi-threaded thingy. The core operating system can immediately kill any process at any time by sending appropriate signals to the process. When a signal was sent to a process, the normal operation of the process is interrupted by the core operating system and the process is forced to act on the signal's request. To kill a process usually first SIGTERM is sent to it and if this doesn't have an effect SIGKILL is sent. Those signals can be usually sent by using the window controls of the window wherein the YaST module runs. For example I run fvwm2 as window manager and here I have for each window a dropdown menue with the entries "Delete" which sends SIGTERM so that where the YaST module can respond with a "Really Abort ?" popup dialog so that the YaST module can do some cleanup and terminate with a clean state "Destroy" which sends SIGKILL where the YaST module cannot respond at all because the core operating system will immediately kill the process regardless what the state is afterwards On the other hand the "Cancel/Abort" button in a YaST module does not send a signal to the YaST module process so that its normal operation is not interrupted - instead the "Cancel/Abort" buttons are just normal buttons where a button click is processed when normal operation allows to react on button clicks. This behaviour is intentional because the meaning of the "Cancel/Abort" button in a YaST module is not to kill it but to request for normal termination exactly like the "Quit/Exit" buttons in any other application. We might discuss if it makes sense to have an additional "Kill" button in the dialogs of YaST modules which does send a SIGTERM but do other applications have it? Or should we also in YaST simply rely on the window manager (or on [Ctrl]+[C] via keyboard) to send kill signals? Back to the initial issue in this bug: As far as I see the root cause of user annoyance is that for the user it is not clear when a button click has no immediate effect (because the process is buys otherwise). I think this can be improved by providing better feedback to the user what is going on behind the surface. Some suggestions: a) Gay out the buttons when the process cannot respond to them immendiately? I think this cannot be implemented correctly because then also for any stort-time action of the process the buttons would be grayed off and on all the time (i.e. results some kind of button flickering). b) Change the graphical representation of the button after it was clicked so that the user can see that his click request was noticed. Usually when the process is busy otherwise the cursor is changed to a busy-cursor so that both the busy-cursor together with the clicked-button shows the user what is actually going on. As far as I see the graphical representation of the button already changes after it was clicked but the effect is so minimal that I didn't noticed it up to now. c) When when the process is busy with something where the autor of the YaST module knows that it can be time-consuming, he would like to show a busy popup notification. But here the problem is the word "can" - i.e. the autor of the YaST module only knows that it may be time-consuming under whatever circumstances which are beyond his control (e.g. when re-starting a service). Therefore he does not want to show a busy popup notification in any case because when it is not time-consuming there would be a flickering popup (appear and disappear almost at the same time). Currently my personal workaround to avoid the flickering is that when I show a busy popup where I don't know for sure it is time-consuming I do an additional "sleep 1 second" so that the busy popup stays at least for one second. d) When when the process is busy with something where the author of the YaST module does not know that it can be time-consuming (e.g. in bug #442173), the underlying YaST system (e.g. the YaST UI) might be able to provide better feedback than just the busy-cursor? -- 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 471741] New: Installation Fails with DVD Read Error Despite Physical Media Being Perfectly Good
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=471741 Summary: Installation Fails with DVD Read Error Despite Physical Media Being Perfectly Good Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86-64 OS/Version: openSUSE 11.1 Status: NEW Severity: Critical Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: alpha096(a)virginbroadband.com.au QAContact: jsrain(a)novell.com Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.5) Gecko/2008121300 SUSE/3.0.5-0.1 Firefox/3.0.5 Start Default KDE 4.1 Installation. At copying files stage error: Subprocess failed. Error: RPM failed: /bin/sh: error in loading shared libraries: libreadline.so.5 cannot open shared object file: No such file or Directory error: %post(glibc-32-bit-2.9-2.3.x86_64) scriptet failed, exit status 127 IGNORE ABORT RETRY RETRY == YES Same error Reproducible: Always Steps to Reproduce: 1.Insert X_64 DVD 2. 3. Actual Results: ERROR Response Expected Results: It installs without script error: Needs assistance of description of error response. -- 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 22

[Bug 490785] New: gwenview: F8 no longer works
by bugzilla_noreply＠novell.com 01 Apr '09

01 Apr '09

https://bugzilla.novell.com/show_bug.cgi?id=490785 Summary: gwenview: F8 no longer works Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Applications AssignedTo: kde-maintainers(a)suse.de ReportedBy: jw(a)novell.com QAContact: qa(a)suse.de Found By: --- in kde3, F8 was a shortcut to open the "move to ..." dialog, while browsing thumbnails. This keybinding is missing in gwenview-2.1.3 from kde4-gwenview-4.1.3-4.6 -- 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

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Bugs March 2009