June 2008 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 376058] New: A very promising Xen management tool
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=376058 Summary: A very promising Xen management tool Product: openSUSE 11.0 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Xen AssignedTo: cgriffin(a)novell.com ReportedBy: willem(a)neteyes.nl QAContact: qa(a)suse.de Found By: Beta-Customer Requesting to see if it is possible to add the following tool in Xen Opensuse: http://www.enomalism.com/fileadmin/mockup/mgt/# (the link brings you to a demo site) One of the drawbacks heard is that Xen as in OpenSUSE has a too simple yet unfriendly management interface (virt-manager). This interface might just change that! Project site : http://www.enomalism.com/ The Enomalism2 project has entered Beta state and is originally written for Fedora. They are looking to expand. Can it be ported to OpenSUSE? I do not have much experience with packaging & programming but willing to contribute where I can. Seems like a very valuable add-on! Regards, Wj -- 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 7

[Bug 340215] New: btdownloadgui has no .desktop file
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=340215 Summary: btdownloadgui has no .desktop file Product: openSUSE 10.3 Version: Final Platform: Other OS/Version: openSUSE 10.3 Status: NEW Severity: Normal Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome(a)forge.provo.novell.com ReportedBy: rodrigo(a)novell.com QAContact: qa(a)suse.de Found By: Development btdownloadgui (part of BitTorrent-gtk package) doesn't have a .desktop file, so it does not show up on the app menus. -- 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 331599] New: Brightness is increased/ decreased about 2 steps instead of 1 step
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=331599 Summary: Brightness is increased/decreased about 2 steps instead of 1 step Product: openSUSE 10.3 Version: Final Platform: x86-64 OS/Version: openSUSE 10.3 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: ray(a)openland.cz QAContact: qa(a)suse.de Found By: --- I have Asus A6Km notebook and when buttons for LCD brightness control are used, it makes change equal to 2 steps (it looks like button is pressed for two times). I found, it is caused by hotkey daemon introduced in 10.3, because buttons for brightness are not software controlled (these two buttons work even hotkey daemon or asus-laptop kernel module are not used). I solved it by commenting out two lines in /usr/share/hotkey-setup/asus.rules: # Keycodes for Asus and Samsung P35 hotkey ATKD 00000030,115 # KEY_VOLUMEUP hotkey ATKD 00000031,114 # KEY_VOLUMEDOWN hotkey ATKD 00000032,113 # KEY_MUTE hotkey ATKD 0000004f,236 # KEY_BATTERY hotkey ATKD 00000061,192 # KEY_F22 /* Stand-in for KEY_VIDEOMODECYCLE */ hotkey ATKD 00000050,155 # KEY_MAIL hotkey ATKD 00000051,150 # KEY_WWW hotkey ATKD 00000052,148 # KEY_PROG1 hotkey ATKD 0000005d,238 # KEY_WLAN #hotkey ATKD 0000001,225 # KEY_BRIGHTNESSDOWN #hotkey ATKD 0000002,224 # KEY_BRIGHTNESSUP Hope it helps. I am not 100% sure, but I think lot of Asus laptops has same behavior. -- 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 14

[Bug 251657] New: rsync - Ports for SuSEfirewall added via packages
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=251657 Summary: rsync - Ports for SuSEfirewall added via packages Product: openSUSE 10.3 Version: Alpha 1plus Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Basesystem AssignedTo: ro(a)novell.com ReportedBy: locilka(a)novell.com QAContact: qa(a)suse.de There is a new feature: FATE #300687: Ports for SuSEfirewall2 added via packages implemented in SuSEfirewall2 and YaST2-Firewall. This functionality offers to define needed ports for particular package. The definition is then transparently used in Firewall. Please, add such definition into the package mentioned in $subject by following steps in this article: http://en.opensuse.org/SuSEfirewall2/Service_Definitions_Added_via_Packages Thanks PS: "Remote Synchronization" or "Rsync Server" seems to be possible name for the service. -- 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, or are watching someone who is.

1 5

[Bug 405044] New: X: huge cursor fails to obey DPI
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=405044 Summary: X: huge cursor fails to obey DPI Product: openSUSE 11.0 Version: Final Platform: x86 OS/Version: Linux Status: NEW Severity: Normal Priority: P5 - None Component: X.Org AssignedTo: sndirsch(a)novell.com ReportedBy: jengelh(a)gmx.de QAContact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: Beta-Customer I run my X server with the "-dpi 96" argument, because otherwise, fonts would be ridiculously large, as I have resolution 1280x1024, but a X virtual desktop size of 2944x2208 configured. However, the SVG mouse cursor that appears when using Firefox, xterm or LyX, and possibly other programs, is much larger than it would with a virtual desktop size of 1280x1024, in other words, it does not obey the DPI setting. Does not happen with all programs, for example, pidgin is exempt -- it uses the normal cursor that the window manager (icewm) provides. BTW, why does not Firefox and the others use the WM's mouse cursor too but have to roll their own, what gives? -- 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 16

[Bug 369450] New: zypper install hides rpm %post script output
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=369450 Summary: zypper install hides rpm %post script output Product: openSUSE 10.3 Version: Final Platform: x86-64 OS/Version: Linux Status: NEW Severity: Normal Priority: P5 - None Component: libzypp AssignedTo: dmacvicar(a)novell.com ReportedBy: archie(a)dellroad.org QAContact: dmacvicar(a)novell.com Found By: Customer All other tools I've used to install RPMs (e.g., apt, smart, rpm, etc.) will show you the output of the RPM's scriptlets. zypper(1) however does not. This is a problem because often these messages are important for the person doing the installation to see, e.g., "Don't forget to do XXX after you install this" etc. Even when zypper is given the "-v" flag this output is suppressed. Please change zypper to show the output of the RPM scriptlets to stdout, or at least do so when "-v" is supplied. Versions: zypper-0.8.25-0.1 libzypp-3.26.8-0.1 -- 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 16

[Bug 341956] New: halt -f -p doesn't power off HP Compaq 6715b
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=341956 Summary: halt -f -p doesn't power off HP Compaq 6715b Product: openSUSE 10.3 Version: Final Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: astarikovskiy(a)novell.com ReportedBy: mhopf(a)novell.com QAContact: qa(a)suse.de CC: trenn(a)novell.com Found By: --- On this laptop when shutting down the machine it doesn't power off. We finally tried 'halt -f -p' - the machine doesn't power off, and you can even log into it via ssh or a different console after that - though it behaves a little bit strange (e.g. the cursor doesn't blink any longer). Tested kernel is 2.6.22.12-0.1. Tested kotd kernel kernel-default-2.6.22.12-SL103_BRANCH_20071114160351.i586.rpm Also tested HEAD kotd kernel-default-2.6.24_rc2_git4-20071114171135.i586.rpm - this one works nicely. Machine is g19, when booted :-] -- 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 330742] New: Metadata is not being locked during editation
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=330742 Summary: Metadata is not being locked during editation Product: openSUSE.org Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: BuildService AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: prusnak(a)novell.com QAContact: adrian(a)novell.com Found By: --- If I change package metadata too quickly (or when buildservice is overloaded) I get following error: "Your flag configuration seems to be too complex to be saved through this interface. Please use OSC." When I inspect metadata (with OSC) I see: <package name="pv" project="home:prusnak:test"> <title>Pipe Viewer</title> <description>Pipe Viewer</description> <build> <enable repository='Debian_Etch'/> <enable repository='Fedora_7'/> <enable repository='Mandriva_2007'/> <enable/> <disable repository='Fedora_7'/> <enable repository='Mandriva_2007'/> <disable/> </build> <person userid="prusnak" role="maintainer"/> </package> => multiple tags for one repository (even with opposing meaning) -- 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 401653] New: pulseaudio: doesn't work after suspend/resume cycle
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=401653 Summary: pulseaudio: doesn't work after suspend/resume cycle Product: openSUSE 11.0 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Sound AssignedTo: tiwai(a)novell.com ReportedBy: teheo(a)novell.com QAContact: qa(a)suse.de Found By: --- If audio was playing when suspend occurs, after resuming pulseaudio dies horribly and the application which was playing audio fails too. This can be worked around by adding the following script. # cat /etc/pm/sleep.d/99pasuspend #!/bin/bash case "$1" in hibernate|suspend) sudo -u tj pactl suspend-sink 1 ;; thaw|resume) sudo -u tj pactl suspend-sink 0 ;; esac The user part should be the user for pa. Dunno how that can be achieved tho. Maybe this can be done via dbus? -- 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 400958] New: package-manager incorrectly "upgrades" from x86_64 packages to i586 packages
by bugzilla_noreply＠novell.com 19 Feb '09

19 Feb '09

https://bugzilla.novell.com/show_bug.cgi?id=400958 Summary: package-manager incorrectly "upgrades" from x86_64 packages to i586 packages Product: openSUSE 11.0 Version: RC 3 Platform: x86-64 OS/Version: openSUSE 11.0 Status: NEW Severity: Normal Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers(a)forge.provo.novell.com ReportedBy: mhutchinson(a)novell.com QAContact: qa(a)suse.de Found By: --- I have the Mono OBS repo in my repos list. This offers newer packages for gnome-sharp2, art-sharp2, gconf-sharp2 and some others. However, for some reason the i586 packages are slightly newer than the x86_64 packages (xxx.7 rather than xxx.6), and package-manager upgrades to them instead of the x86_64 packages. This breaks things. The packages that have a dependency on these are all noarch. These have a dependency on x86_64 library files. However, i586 versions of these files are also on my system through a -32-bit packages. These have a dependency on noarch files from the Mono runtime, even though them Mono runtime is arch-dependent. It could be argued that the gnome-sharp packages should have a dependency on the arch of the mono runtime. However, package-manager shouldn't offer to "upgrade" from x86_64 packages to i586 packages. -- 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 17