https://bugzilla.novell.com/show_bug.cgi?id=490004
Summary: UMTS support broken after latest updates: not allowed
to own the service
"org.freedesktop.NetworkManager.PPP"
Classification: openSUSE
Product: openSUSE 11.1
Version: Final
Platform: i586
OS/Version: openSUSE 11.1
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Mobile Devices
AssignedTo: zoz(a)novell.com
ReportedBy: gp(a)novell.com
QAContact: qa(a)suse.de
CC: security-team(a)suse.de
Found By: Product Management
After the latest set of updates, I no longer am able to establish a UMTS
connection via NetworkManager.
>From /var/log/NetworkManager:
Mar 28 09:12:22 rana NetworkManager: <info> (/dev/noz0): device state change:
4 -> 5
Mar 28 09:12:22 rana NetworkManager: <WARN> constructor(): Failed to acquire
PPP manager service: Connection ":1.6" is not allowed to own the service
"org.freedesktop.NetworkManager.PPP" due to security policies in the
configuration file
Mar 28 09:12:22 rana NetworkManager: nm_ppp_manager_start: assertion
`NM_IS_PPP_MANAGER (manager)' failed
Mar 28 09:12:22 rana NetworkManager: <WARN> nm_signal_handler(): Caught signal
11. Generating backtrace...
--
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.
https://bugzilla.novell.com/show_bug.cgi?id=469784
Summary: Nautilus : disapearing scroll bar using tabs
Classification: openSUSE
Product: openSUSE 11.1
Version: Final
Platform: x86-64
OS/Version: openSUSE 11.1
Status: NEW
Severity: Normal
Priority: P5 - None
Component: GNOME
AssignedTo: bnc-team-gnome(a)forge.provo.novell.com
ReportedBy: jc(a)phocean.net
QAContact: qa(a)suse.de
Found By: ---
Created an attachment (id=267925)
--> (https://bugzilla.novell.com/attachment.cgi?id=267925)
nautilus scroll bar issue
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.5)
Gecko/2008121300 SUSE/3.0.5-1.1 Firefox/3.0.5
When I open a new tab in Nautilus and then go back to the first tab, the scroll
bar has disapeared.
Refreshing the window makes the scroll bar reappearing.
Please check the screenshots.
Reproducible: Always
Steps to Reproduce:
1. Open Nautilus on a folder that requires scrolling
2. Open a new tab (ctrl-t)
3. Go back to the first tab : the scroll bar has disappeared
4. Refreshing the window (F5) makes the scroll reappearing
--
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.
https://bugzilla.novell.com/show_bug.cgi?id=463365
Summary: Vertcal scroll-bar disappears while switching tabs using
Nautilus
Product: openSUSE 11.1
Version: Final
Platform: 32bit
OS/Version: openSUSE 11.1
Status: NEW
Severity: Minor
Priority: P5 - None
Component: GNOME
AssignedTo: bnc-team-gnome(a)forge.provo.novell.com
ReportedBy: russo.giansergio(a)tiscali.it
QAContact: qa(a)suse.de
Found By: Community User
Vertical scrollbar disappears when switching from one tab to another one in
Nautilus (icon-view mode with more than one tab opened).
To reinstate the bar a window refresh or resize is needed.
--
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.
https://bugzilla.novell.com/show_bug.cgi?id=442475
Summary: The Cancel and Skip Refresh still does Not Operate with
a Higher Priory than the Yast Application Itself
Product: openSUSE 11.0
Version: Final
Platform: x86-64
OS/Version: openSUSE 11.0
Status: NEW
Severity: Enhancement
Priority: P5 - None
Component: YaST2
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: alpha096(a)virginbroadband.com.au
QAContact: jsrain(a)novell.com
Found By: Customer
If a Yast Application stalls at any point, using the Cancel Button has NO
effect on the Yast Application. There needs to have both Cancel and Skip
Refresh and Abort buttons operate with a much higher Priority that the Yast
Application itself.
Using the 'Skip Refresh' button certainly does work most of the time but not
100% of the time - Its Priority still needs to be higher.
The cancel or Abort buttons - never close or stop a misbehaving Yast
Application or abouts the saving of a Yast Application and is essentially
useless.
Both Abort, Cancel and Skip Refresh, all need to operate with the Highest CPU
authority or always higher than the Yast Application itself.
We have taken for granted that both cancel or Abort buttons never function
after we commit to any changes via a Yast Application Window and perhaps it is
long overdue for us to correct 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.
https://bugzilla.novell.com/show_bug.cgi?id=476298
Summary: Creating an NTP Server in Yast and Selecting Open
Firewall Does Not Add NTP Services to Allowed Services
List in the Firewall
Classification: openSUSE
Product: openSUSE 11.0
Version: Final
Platform: x86-64
OS/Version: openSUSE 11.0
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: alpha096(a)virginbroadband.com.au
QAContact: jsrain(a)novell.com
Found By: ---
Created an attachment (id=273130)
--> (https://bugzilla.novell.com/attachment.cgi?id=273130)
1 of 2 images
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.6)
Gecko/2009012700 SUSE/3.0.6-0.1 Firefox/3.0.6
If we create a Public NTP Server via Yast ans we select Open Firewall in the
Securities Options the NTP Service Permissions is not added to the list of
Allowed Services
Reproducible: Always
Steps to Reproduce:
1.Yast
2.Network Services
3.NTP Server
4.Creat Public NTP Server and open Firewall option.
Actual Results:
NTP Services are not automatically added to allowed services so the NTP Server
will never test or function at all
Expected Results:
When the Open Firewall Box is checked the NTP Server should be auto added to
the Firewall's Allowed Services
--
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.
https://bugzilla.novell.com/show_bug.cgi?id=479005
Summary: bluetooth-applet shouldn't specify pairing code
Classification: openSUSE
Product: openSUSE 11.1
Version: Final
Platform: i686
OS/Version: openSUSE 11.1
Status: NEW
Severity: Normal
Priority: P5 - None
Component: GNOME
AssignedTo: bnc-team-gnome(a)forge.provo.novell.com
ReportedBy: riggwelter(a)opensuse.org
QAContact: qa(a)suse.de
Found By: ---
When pairing with a device that requires a code, bluetooth-applet tells you the
code to use rather than the old behaviour of asking the user to specify it.
This is fine when pairing with a device such as a phone which asks the user for
the code.
The problem comes when pairing with a device with no input facility - such as
speakers. These have their own hard-coded codes which makes it impossible to
pair with them.
--
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.