February 2007 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 197858] X server wakes up on any ACPI event
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=197858 sndirsch(a)novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #42 from sndirsch(a)novell.com 2007-02-01 06:47 MST ------- Thanks. Package submitted. Closing as fixed for STABLE/Factory. -- 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 0

[Bug 224897] New: KDE Preset Actions - Browser (HomePage) launches wrong url.
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=224897 Summary: KDE Preset Actions - Browser (HomePage) launches wrong url. Product: SUSE Linux 10.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: 178155(a)glocalnet.net QAContact: kde-maintainers(a)suse.de I've mapped my keyboard multimedia keys with xmodmap, to launch my preset browser which is Firefox I mapped one of the keys to XF86WWW. In KDE settings there are some preset actions, one of them is called "Browser (HomePage)" and is set to react when pressing the XF86WWW key. The command that is executed is called "KHOTKEYS_BROWSER". The browser is launched but instead of going to my homepage it tries to load "www.mozillafirefox.desktop"... -- 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 16

[Bug 146438] cardbus cards not seen by kernel (parent bridge misconfigured)
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=146438 bk(a)novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Comment #45 from bk(a)novell.com 2007-02-01 06:43 MST ------- The patch was submitted by the resplonsible maintainer to mainline http://lists.infradead.org/pipermail/linux-pcmcia/2006-June/003703.html and is in mainline since 2.6.18, so it did become part of 10.2 and this bug is fixed in all distributions which use a kernel based on 2.6.18 or newer. I wrote a detailed description of the patch which isn't found anywhere else so far, so I paste it here and close it: Short description: ------------------ This patch fixes detection of the CardBus cards in many notebooks due to a too low subordinate number of the parent PCI-PCI bridge It fixes the subordinate number of the parent PCI-PCI bridge of CardBus bridges when one is probed, before registering the CardBus bridge with the kernel and scanning its slot for devices. Longer description: ------------------- On a number of Laptops, the PCI scans do not find any CardBus cards because the parent bridge of the CardBus bridge is not configured so that Type 1 PCI configuration cycles can reach the CardBus cards. On one of the affected Laptops, a Samsung X20, Windows XP does a full pci bus renumbering, so the problem is not seen with Windows. Booting with pci=assign-busses does the same but since ACPI may contain references to PCI busses and we do not translate them yet, it may break things. The generic solution used in 2.6.13 was to only increase the subordinate number, but since this was done during PCI bus discovery, it was not safe to it at this point and taken out with the next release. This patch does the same but takes care that it can never cause create a PCI bus configuration with overlapping bus numbers which was the reason why the solution of 2.6.13 was moved to pci=assign-busses. Description of the fix: ======================= Principles: ----------- Reference: PCI-PCI Bridges: PCI Configuration Cycles and PCI Bus Numbering: http://www.science.unitn.it/~fiorella/guidelinux/tlk/node72.html --------------------------------------------------------------------------- It is up to each individual operating system to allocate bus numbers during PCI configuration but whatever the numbering scheme used the following statement must be true for all of the PCI-PCI bridges in the system: ``All PCI busses located behind a PCI-PCI bridge must reside between the seondary bus number and the subordinate bus number (inclusive).'' If this rule is broken then the PCI-PCI Bridges will not pass and translate Type 1 PCI configuration cycles correctly and the system will fail to find and initialise the PCI devices in the system. --------------------------------------------------------------------------- What the patch may not do: -------------------------- The patch may not raise the subordinate number of any PCI-PCI bridge so that it overlaps with the bus ranges of other PCI-PCI bridges. It has the checks neccesary to ensure that this does not happen. What the patch does: -------------------- Called from Cardbus controller probe function, before the controller is registered, so before the devices on it can be scanned, a new function call is inserted. This function works the following way: > If the parent of the cardbus parent is a root bridge, do nothing. (The root bridge does not hide Cardbus devices, it was always ok) > The parent of the cardbus bridge has been identified as the PCI-PCI bridge who's subordinate bus number may be raised to pass and translate Type 1 PCI configuration cycles so that they can reach the devices behind the CardBus brodge, it's called bridge_to_fix. > The subordinate number the parent of the bridge_to_fix is used as the initial upper limit to which we could theoretically raise the subordinate number of the bridge_to_fix. (there is no point in exceeding the range of the parent, childs will got get Type 1 PCI configuration cycles for those anyway) > For each child bridge of the parent bridge (equal to: for each silbling and the bridge_to_fix itself), do: -> If the silbling's secondary bus number is higher than the subordinate of the bridge_to_fix (thus, it is a bridge which we have to care for when raising the subordinate of the bridge_to_fix to prevent overlapping) *and* if this silbling's secondary bus number is smaller than the upper limit, then update the upper limit to the secondary bus number of the silbling minus 1. This is repeated for all silbling bridges of the bridge_to_fix (and for the bridge_to_fix itself too, but for this to have any effect, it's secondary must be higher than it's subordinate which should never be the case but even if it is [then, the PCI config of it is totally broken and won't work anyway] is that the subordinate of it will only be raised to it's secondary minus one, so it won't have any effect) -> The upper_limit is then left at the last free bus number to which the subordinate of the cardbus parent bridge could be raised without reaching a bus number which is allocated for a different silbling bridge on the same bus and without leaving the bus range of the parent. I tested these checks to work by modifying the relevant data structures and verifying the results, so I certify that with all these tests, the upper limit was always right. If this upper limit is lower than the subordinate number of the cardbus bridge, a warning message which says which shows this constraint for raising the subordinate of the bridge_to_fix is logged. If the upper limit is higher than the subordinate of the bridge_to_fix (this means it could be raised to this limit, it is never reduced, so nothing can break), the following is done: The subordnate bus number to assign is set to the upper_limit or to the subordinate bus number of the cardbus bridge (this is the number which we want to have), whatever value is smaller. A message which logs that we raise the subordinate number of bridge_to fix to its new value is logged. The subordinate field of the PCI struct of the bridge_to_fix is set to the new subordnate bus number and the PCI config byte PCI_SUBORDINATE_BUS is set to the new number. That's it all. There are related follow-up bugs which are concerned with the kernel boot message which warns of hidden PCI busses, which is made obsolete by this patch for the cases which this patch fixes: * bug 237229 has the best initial comments * bug 225672 also tracks it (may be come a duplicate of 237229) * bug 191194 mentions it, but is about a different issue -- 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 0

[Bug 203535] /opt/kde3/bin/start_kdeinit needs setuid root
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=203535 llunak(a)novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #13 from llunak(a)novell.com 2007-02-01 06:35 MST ------- Has this been actually done? I don't see it anywhere in /work/SRC/all/BASE/permissions . -- 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 0

[Bug 240287] New: Workflow with "Read user data from previous installation" with user authentification is confusing
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=240287 Summary: Workflow with "Read user data from previous installation" with user authentification is confusing Product: openSUSE 10.3 Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: yast2-maintainers(a)suse.de ReportedBy: aj(a)novell.com QAContact: jsrain(a)novell.com Consider: * just select the "Read user data from previous installation" button and do not press "Choose" (see screenshot) * Press "next" to go to the next screen. What happens: The "Read user" box opens and afterwards you're still in the same screen. Expected behaviour: The "Read user" box opens and afterwards you're in the *next* screen. -- 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 241045] New: saving packages in cache
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=241045 Summary: saving packages in cache Product: openSUSE 10.3 Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: libzypp AssignedTo: kkaempf(a)novell.com ReportedBy: nderkach(a)gmail.com QAContact: kkaempf(a)novell.com Is it possible to have an option for saving downloaded packages in cache? -- 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 1

[Bug 127552] Buffer Overflow Bug in OpenMotif 2.2.3
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=127552 schwab(a)novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX ------- Comment #13 from schwab(a)novell.com 2007-02-01 06:24 MST ------- Can't do anything without a test 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, or are watching someone who is.

1 0

[Bug 139567] Subdomain stops postfix/cyrus working
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=139567 aj(a)novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|misch(a)multinet.de | Resolution| |WONTFIX ------- Comment #6 from aj(a)novell.com 2007-02-01 06:16 MST ------- No reaction for 8 months, closing as CANTFIX. -- 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 0

[Bug 130230] USB transmission is very erratic with Auerswald telephony equipment
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=130230 aj(a)novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX ------- Comment #30 from aj(a)novell.com 2007-02-01 06:15 MST ------- Bug is stale, closing as WONTFIX. -- 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 0

[Bug 137095] Cifs modules freezes the system
by bugzilla_noreply＠novell.com 01 Feb '07

01 Feb '07

https://bugzilla.novell.com/show_bug.cgi?id=137095 aj(a)novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|oberg(a)isy.liu.se | Resolution| |WONTFIX ------- Comment #14 from aj(a)novell.com 2007-02-01 06:14 MST ------- STill in NEEDINFO for 7months. Markings as WONTFIX. -- 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 0