December 2009 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 536476] New: Software Installation - Remaining size not decreased on skipping a package after download failure
by bugzilla_noreply＠novell.com 15 Sep '11

15 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=536476 Summary: Software Installation - Remaining size not decreased on skipping a package after download failure Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: rkrell(a)gmx.net QAContact: jsrain(a)novell.com Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090730 SUSE/3.5.2-3.1 Firefox/3.5.2 The remaining size (may be even the number of packages) is not decreased on skipping a package for instance after a download failure. At the end of the installation YaST still shows the space in the Remaining that would be needed for installation of the missing packages. Reproducible: Always -- Configure bugmail: http://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 492647] New: Remove 'slab' Presentation of Yast and Most All Menu System and Standardise Default Menu System
by bugzilla_noreply＠novell.com 10 Sep '11

10 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=492647 Summary: Remove 'slab' Presentation of Yast and Most All Menu System and Standardise Default Menu System Classification: openSUSE Product: openSUSE 11.2 Version: Alpha 0 Platform: x86-64 OS/Version: openSUSE 11.0 Status: NEW Severity: Enhancement Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome(a)forge.provo.novell.com ReportedBy: alpha096(a)virginbroadband.com.au QAContact: qa(a)suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-1.1.6 Firefox/3.0.7 When we open Yast in Gnome the response is 1 big slab of root applications and whilst this was originally much small the amount of root application has increased. We need to remove the slab of root Yast Menus. The same concept is required for the rationalisation of the user menu system - After many many years I can always find what I am looking for and what I need, but a recent public critique was not so kind. I decided to either validate or forget about the public critique. I presented 3 Entirely New to Linux home users with medium technical skills and left them alone. Ever negative feedback that was provided focused solely the Memu style 'slab' of applications in Yast because when you enter Yast the full screen of available application cannot all be seen as it extends off the Monitor. The other issue was that this same 'slab' issue in multiple user/system/non-root applications was hugely confusing. The 'Computer Menu initially opens well but heaven help any one who clicks on 'more applications' The other Menus being Applications, Places, System and Computer Menus all require consistent rationalisation of type, content and usage. On the very plus side is the wonderful faultless performance of applications and Yast - Its rock solid at a time where KDE often falls over. Give the user a good consist and menu, Direct multiple clipboard selection, different wallpapers per virtual desktop, much more default eye kandy and it will win hands down over KDE and miserable Vista, in my opinion. I have pasted an extract out of a public critique on SLED and its URL as of 23 March 2009 Reproducible: Always Steps to Reproduce: 1.Enhancement 2.Enhancement 3.Enhancement Actual Results: See Description Extract text from http://blogs.zdnet.com/perlow/?p=9716 QUOTE..... My gripes with SLED 11 are also not just related to Novell’s insufficient QA, although clearly this is the product’s biggest problem. I also have design issues as to how they laid out the interface for their updated “Slab” enhancements to GNOME. In both openSUSE 11.1 and SLED 11, there are 3 distinct “views” by which programs and settings can be accessed — a “Control Center”, an “Applications Browser” and then “Yast2″. Each of these views contain a large amount of icons, particularly the “Applications Browser” which is several pages long. This is so overwhelming that it takes a long time to figure out in which interface a particular program or configuration option is actually located. This problem, which is a disease I shall refer to as “Iconitis” is also a design element I also take issue with in Windows Vista and Windows 7’s Control Panel, but Novell’s implementation is much more confusing and counter-intuitive. Ideally, I’d like to see ONE Control Panel/Applications Browser with organizational tabs or tree drill-downs so that you don’t have to switch between UIs to find what you need. Access to the Administrative icons should require super-user or authenticated user privileges. Can OEMs and Enterprises address the overwhelming amount of presented apps in the Application Browser using imaging and scripted installs? Yes, but again I say Novell should not assume everyone is going to do this. The default install and menu configuration should not be this unweildy for an end-user. While the technology itself in SLED 11 is impressive, Novell clearly has a lot of work to do before I can recommend deployment of SLED 11 as an enterprise desktop. UNQUOTE..... -- Configure bugmail: http://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 531449] New: ssl support in bzr broken
by bugzilla_noreply＠novell.com 08 Sep '11

08 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=531449 Summary: ssl support in bzr broken Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: mt(a)novell.com QAContact: qa(a)suse.de Found By: --- I've used bzr first time, so maybe this is "normal", but I don't thing so ;-) # zypper in bzr $ bzr branch https://code.launchpad.net/~duplicity-team/duplicity/trunk /usr/lib64/python2.6/site-packages/bzrlib/transport/http/_urllib2_wrappers.py:254: DeprecationWarning: socket.ssl() is deprecated. Use ssl.wrap_socket() instead. ssl = socket.ssl(self.sock, self.key_file, self.cert_file) /usr/lib64/python2.6/site-packages/bzrlib/transport/http/_urllib2_wrappers.py:255: DeprecationWarning: FakeSocket is deprecated, and won't be in 3.x. Use the result of ssl.wrap_socket() directly instead. self.sock = httplib.FakeSocket(self.sock, ssl) bzr: ERROR: exceptions.AttributeError: sendall Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/bzrlib/commands.py", line 849, in run_bzr_catch_errors return run_bzr(argv) File "/usr/lib64/python2.6/site-packages/bzrlib/commands.py", line 795, in run_bzr ret = run(*run_argv) File "/usr/lib64/python2.6/site-packages/bzrlib/commands.py", line 495, in run_argv_aliases return self.run(**all_cmd_args) File "/usr/lib64/python2.6/site-packages/bzrlib/builtins.py", line 878, in run from_location) File "/usr/lib64/python2.6/site-packages/bzrlib/bzrdir.py", line 888, in open_tree_or_branch bzrdir = klass.open(location) File "/usr/lib64/python2.6/site-packages/bzrlib/bzrdir.py", line 766, in open return BzrDir.open_from_transport(t, _unsupported=_unsupported) File "/usr/lib64/python2.6/site-packages/bzrlib/bzrdir.py", line 803, in open_from_transport redirected) File "/usr/lib64/python2.6/site-packages/bzrlib/lazy_import.py", line 125, in __call__ return obj(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/bzrlib/transport/__init__.py", line 1621, in do_catching_redirections return action(transport) File "/usr/lib64/python2.6/site-packages/bzrlib/bzrdir.py", line 780, in find_format transport, _server_formats=_server_formats) File "/usr/lib64/python2.6/site-packages/bzrlib/bzrdir.py", line 1634, in find_format return format.probe_transport(transport) File "/usr/lib64/python2.6/site-packages/bzrlib/bzrdir.py", line 2617, in probe_transport server_version = medium.protocol_version() File "/usr/lib64/python2.6/site-packages/bzrlib/smart/medium.py", line 593, in protocol_version client_protocol.query_version() File "/usr/lib64/python2.6/site-packages/bzrlib/smart/protocol.py", line 769, in query_version self.call('hello') File "/usr/lib64/python2.6/site-packages/bzrlib/smart/protocol.py", line 617, in call self._request.finished_writing() File "/usr/lib64/python2.6/site-packages/bzrlib/smart/medium.py", line 421, in finished_writing self._finished_writing() File "/usr/lib64/python2.6/site-packages/bzrlib/transport/http/__init__.py", line 575, in _finished_writing data = self._medium.send_http_smart_request(self._buffer) File "/usr/lib64/python2.6/site-packages/bzrlib/transport/http/__init__.py", line 552, in send_http_smart_request code, body_filelike = t._post(bytes) File "/usr/lib64/python2.6/site-packages/bzrlib/transport/http/_urllib.py", line 138, in _post accepted_errors=[200, 403])) File "/usr/lib64/python2.6/site-packages/bzrlib/transport/http/_urllib.py", line 78, in _perform response = self._opener.open(request) File "/usr/lib64/python2.6/urllib2.py", line 389, in open response = self._open(req, data) File "/usr/lib64/python2.6/urllib2.py", line 407, in _open '_open', req) File "/usr/lib64/python2.6/urllib2.py", line 367, in _call_chain result = func(*args) File "/usr/lib64/python2.6/site-packages/bzrlib/transport/http/_urllib2_wrappers.py", line 634, in https_open return self.do_open(HTTPSConnection, request) File "/usr/lib64/python2.6/site-packages/bzrlib/transport/http/_urllib2_wrappers.py", line 528, in do_open headers) File "/usr/lib64/python2.6/httplib.py", line 931, in _send_request self.endheaders() File "/usr/lib64/python2.6/httplib.py", line 888, in endheaders self._send_output() File "/usr/lib64/python2.6/httplib.py", line 760, in _send_output self.send(msg) File "/usr/lib64/python2.6/httplib.py", line 739, in send self.sock.sendall(str) AttributeError: sendall bzr 1.8 on python 2.6 (linux2) arguments: ['/usr/bin/bzr', 'branch', 'https://code.launchpad.net/~duplicity-team/duplicity/trunk'] encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'de_DE.UTF-8' plugins: launchpad /usr/lib64/python2.6/site-packages/bzrlib/plugins/launchpad [unknown] *** Bazaar has encountered an internal error. Please report a bug at https://bugs.launchpad.net/bzr/+filebug including this traceback, and a description of what you were doing when the error occurred. -- Configure bugmail: http://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 557993] New: clicfs crashes under certain circumstances
by bugzilla_noreply＠novell.com 06 Sep '11

06 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=557993 http://bugzilla.novell.com/show_bug.cgi?id=557993#c0 Summary: clicfs crashes under certain circumstances Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Live Medium AssignedTo: coolo(a)novell.com ReportedBy: ms(a)novell.com QAContact: qa(a)suse.de Found By: --- Blocker: --- I have changed kiwi to use the mkinitrd tool run-init to boot into the system. While doing this I found some problems if the system is based on clicfs: 1) if you don't boot with ROOTFS_FSCK="0" the clicfs process crashes when the filesystem check runs 2) if you boot with exec /lib/mkinitrd/bin/run-init -c /dev/console /mnt /bin/bash -c \ "/preinit ; . /include ; cleanImage ; exec /sbin/init $option" the clicfs process crashes after a while. If you use cd /mnt && exec chroot . /bin/bash -c \ "/preinit ; . /include ; cleanImage ; exec /sbin/init $option" it works fine if also ROOTFS_FSCK="0" is set Could you take a look at these issues. I worked around them in the current code: /usr/share/kiwi/modules/KIWILinuxRC.sh Thanks -- Configure bugmail: http://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 510454] New: Icecream fails to build when the compile lines starts with absolute path to source file
by bugzilla_noreply＠novell.com 05 Sep '11

05 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=510454 Summary: Icecream fails to build when the compile lines starts with absolute path to source file Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: All OS/Version: Linux Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: sunsetbrew(a)sunsetbrew.com QAContact: qa(a)suse.de Found By: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Icecream fails to build when the compile lines starts with absolute path to source file. The package this was found in is glibc-2.7 Root Cause: Icecc assumes that if the first argument starts with a / character, it is the instruction to use a different compiler. The code is in client/main.c if ( arg.size() > 0 && arg.at(0) == '/' ) job.setCompilerName(arg); The Error looks something like. % icecc /tmp/workspace/glibc-2.7/build-tree/armel-libc/misc/stub-syscalls.c -c -std=gnup... ICECC[23778] 11:23:47: couldn't find any stub-syscalls.c ICECC[23778] 11:23:47: could not find stub-syscalls.c in PATH. On fix may be to just eliminate that code from the script; however, it was put there for a reason i expect so I don't want to break it. Reproducible: Always Steps to Reproduce: 1. touch /tmp/empty.c 2. icecc /tmp/empty.c -c 3. Actual Results: ICECC[14950] 12:12:07: couldn't find any empty.c ICECC[14950] 12:12:07: could not find empty.c in PATH. Expected Results: A compiled file -- Configure bugmail: http://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 558048] New: Data DVDs are mounted with type=UDF, some directories are hidden
by bugzilla_noreply＠novell.com 05 Sep '11

05 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=558048 http://bugzilla.novell.com/show_bug.cgi?id=558048#c0 Summary: Data DVDs are mounted with type=UDF, some directories are hidden Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: folkyvolk(a)gmx.de QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Opera/9.80 (X11; Linux i686; U; de) Presto/2.2.15 Version/10.01 When I put a data dvd in my drive, opensuse automatically mounts it, and kde asks what to do. I get a directory listing, but many directories are missing. In ms windows these entries are displayed. After much fiddling I managed to display the entries by remounting the dvd with type=iso9660 (which was auto-mounted as udf before). This is a bad default behaviour. I don't know if this is a lack of the udf sepc or simply a bug. Please do something about that. For most users will think "linux can't read data cds correctly". Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: http://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 494244] New: Erratic scrollwheel behavior
by bugzilla_noreply＠novell.com 05 Sep '11

05 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=494244 Summary: Erratic scrollwheel behavior Classification: openSUSE Product: openSUSE 11.2 Version: Alpha 0 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org AssignedTo: bnc-team-xorg-bugs(a)forge.provo.novell.com ReportedBy: captain.magnus(a)opensuse.org QAContact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-72.4 Firefox/3.0.7 Gigabyte Laser mouse (GM-M6000). When using the scrollwheel to scroll down, the behavior is erratic, as it decides to scroll up instead (almost like, scroll down a few times, then up once, then scroll down again). I honestly don't know if this is an issue with X, or broken hardware (the mouse is brand new) If there's any config/log/trace, except what's below, that I can provide, please let me know; SaX2 puts this into xorg: Section "InputDevice" Driver "mouse" Identifier "Mouse[1]" Option "Buttons" "7" Option "Device" "/dev/input/mice" Option "Name" "Elan Microelectronics PS/2+USB Mouse" Option "Protocol" "explorerps/2" Option "Vendor" "Sysp" EndSection And here's the output from hwinfo --mouse 45: USB 00.0: 10503 USB Mouse [Created at usb.122] UDI: /org/freedesktop/Hal/devices/usb_device_4f3_212_noserial_if0 Unique ID: +u4I.nJzOKkg+Fr9 Parent ID: 7eqy.v+N+B0xY+P6 SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0 SysFS BusID: 6-2:1.0 Hardware Class: mouse Model: "Elan Microelectronics PS/2+USB Mouse" Hotplug: USB Vendor: usb 0x04f3 "Elan Microelectronics Corp." Device: usb 0x0212 "PS/2+USB Mouse" Revision: "23.24" Compatible to: int 0x0210 0x0015 Driver: "usbhid" Driver Modules: "usbhid" Device File: /dev/input/mice (/dev/input/mouse0) Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event1, /dev/input/by-id/usb-04f3_PS.2+USB_Mouse-event-mouse, /dev/input/by-path/pci-0000:00:1d.0-usb-0:2:1.0-event-mouse, /dev/input/by-id/usb-04f3_PS.2+USB_Mouse-mouse, /dev/input/by-path/pci-0000:00:1d.0-usb-0:2:1.0-mouse Device Number: char 13:63 (char 13:32) Speed: 1.5 Mbps Module Alias: "usb:v04F3p0212d2324dc00dsc00dp00ic03isc01ip02" Driver Info #0: Buttons: 5 Wheels: 1 XFree86 Protocol: explorerps/2 GPM Protocol: exps2 Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #41 (Hub) Reproducible: Always -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 47

[Bug 515555] New: [GNOME:Factory/gobby04] dependency problem with gobby04-lang
by bugzilla_noreply＠novell.com 04 Sep '11

04 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=515555 Summary: [GNOME:Factory/gobby04] dependency problem with gobby04-lang Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: x86-64 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software AssignedTo: mboman(a)novell.com ReportedBy: buschmann23(a)opensuse.org QAContact: opensuse-communityscreening(a)forge.provo.novell.com Found By: Community User Gobby04 needs gobby-lang = 0.4.10 which is not available. gobby04-lang does not provide it. The problem seems to be the %define _name gobby in the spec file. -- Configure bugmail: http://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 557609] New: preload gets stuck in read loop on boot has to be killed
by bugzilla_noreply＠novell.com 01 Sep '11

01 Sep '11

http://bugzilla.novell.com/show_bug.cgi?id=557609 http://bugzilla.novell.com/show_bug.cgi?id=557609#c0 Summary: preload gets stuck in read loop on boot has to be killed Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: x86-64 OS/Version: openSUSE 11.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: alext(a)novell.com QAContact: qa(a)suse.de Found By: --- Blocker: --- On and after boot, the preload gets stuck in a read loop that consumes all IO for the disks and interferes with normal operation. Iotop output as follows: PID USER DISK READ DISK WRITE SWAPIN IO> COMMAND 461 root 57.08 M/s 0 B/s 0.00 % 99.99 % preload /var/cache/preload/prepared The preload process reads at 34 to 57 MB/s reading the prepared file of size 4.5 MB seemingly forever. After 8 minutes, I kill the preload process and the machine IO goes back to zero. Contents of /var/cache/preload are: [zuul:Desktop]$ ll -h /var/cache/preload/ total 7.1M -rw-r--r-- 1 root root 30K 2009-11-15 13:15 Firefox.preload -rw-r--r-- 1 root root 58K 2009-11-15 13:15 gdm.preload -rw-r--r-- 1 root root 284K 2009-11-15 13:15 kde.preload -rw-r--r-- 1 root root 21K 2009-11-15 13:15 kdm.auto.preload -rw-r--r-- 1 root root 38K 2009-11-15 13:15 kdm.preload -rw-r--r-- 1 root root 230K 2009-11-15 13:15 Khelpcenter.preload -rw-r--r-- 1 root root 81K 2009-11-15 13:15 OpenOffice.preload -rw-r--r-- 1 root root 4.5M 2009-11-21 11:45 prepared -rw-r--r-- 1 root root 1.9M 2009-11-21 11:45 trace.gz This happens almost on every boot. -- Configure bugmail: http://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 558144] New: Logitech Quickcam Communicate STX on usb not recognised by gspca driver module
by bugzilla_noreply＠novell.com 31 Aug '11

31 Aug '11

http://bugzilla.novell.com/show_bug.cgi?id=558144 http://bugzilla.novell.com/show_bug.cgi?id=558144#c0 Summary: Logitech Quickcam Communicate STX on usb not recognised by gspca driver module Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: i386 OS/Version: openSUSE 11.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: harvey(a)nimmo.de QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.4) Gecko/20091016 SUSE/3.5.4-1.1.2 Firefox/3.5.4 lsusb provides Bus 002 Device 002: ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX lsmod provides gspca_main 26752 1 gspca_zc3xx gspca_zc3xx 50144 0 Either the wrong gspca module for the camera is selected or the right module is not in the driver package any more. The camera was working with skype and kopete under OS11.1. (no experience with cheese under OS11.1) Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: The webcam does not work with skype: coloured snow nor with cheese: coloured test screen. There is a poor picture using kopete. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 24