Bug 490345 - libproxy generates ominous cryptic misleading message for normal condition
Summary: libproxy generates ominous cryptic misleading message for normal condition
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: libproxy
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nicolas Chauvet (kwizart)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-15 15:02 UTC by John Ellson
Modified: 2009-03-16 22:55 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-16 22:55:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description John Ellson 2009-03-15 15:02:18 UTC
Description of problem:
When starting music via gstreamer in SecondLife the logs contains the message:
 *** Unable to locate PAC! Falling back to direct...
which, given that streaming isn't working, looks a lot like a warning I should be worried about.

It wasn't easy to track down who was generating the message.   Why would i know what a "PAC" was?

Given that I don't use any proxies, this is a normal condition.  In which case the message should be suppressed entirely, or at least made less ominous and less cryptic.

I suggest:

* libproxy was unable to find any proxy configuration environment settings, so is assuming direct connection.
   

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. SecondLife on system without proxies
2. start streaming music
3.
  
Actual results:
 *** Unable to locate PAC! Falling back to direct...

Expected results:
Since there are no proxies, and no environment settings for them, this is the normal condition and so should not be generating any warnings, or other ominious messages.

Additional info:

Comment 1 Nicolas Chauvet (kwizart) 2009-03-16 12:25:14 UTC
I don't know which protocol SecondLife uses for streaming but you probably should consider to search this way (along with which codecs it needs) and ask the gstreamer maitainer.

PAC is provided either by the mozjs module (for xulrunner) or the webkit-gtk ones.
If there is no PAC, direct connection is assumed and failing back to direct is expected.

For the record, which libproxy module do you have currently installed ?
rpm -qa libproxy\*

Comment 2 John Ellson 2009-03-16 12:34:40 UTC
libproxy-0.2.3-10.fc11.x86_64
libproxy-0.2.3-10.fc11.i586

Comment 3 Nicolas Chauvet (kwizart) 2009-03-16 12:39:50 UTC
no, that's not possible... redo the command:
rpm -qa libproxy\*

Comment 4 John Ellson 2009-03-16 21:12:13 UTC
ok, there are spme related packages:

# rpm -qa libproxy\*
libproxy-0.2.3-10.fc11.x86_64
libproxy-webkit-0.2.3-10.fc11.x86_64
libproxy-bin-0.2.3-10.fc11.x86_64
libproxy-debuginfo-0.2.3-10.fc11.x86_64
libproxy-0.2.3-10.fc11.i586
libproxy-devel-0.2.3-10.fc11.x86_64
libproxy-kde-0.2.3-10.fc11.x86_64
libproxy-gnome-0.2.3-10.fc11.x86_64
libproxy-python-0.2.3-10.fc11.x86_64
libproxy-mozjs-0.2.3-10.fc11.x86_64

Comment 5 Nicolas Chauvet (kwizart) 2009-03-16 21:23:13 UTC
Either libproxy-mozjs or libproxy-webkit need to be installed and is a mandatory rpm requirement, so it was expected to be installed...

Actually i don't see any problem from libproxy itself... Why do you think the problem is there ?

Comment 6 John Ellson 2009-03-16 21:48:58 UTC
The "problem" is the message generated by libproxy for this normal operating condition.

 *** Unable to locate PAC! Falling back to direct...


It *looks* like a warning message.
It fails to indicate who generated it.
It expects the user to know what a "PAC" is.

Since the condition is normal, it shouldn't be generated at all.


It happened to be adjacent to messages for a, probably, unrelated problem

Comment 7 Nicolas Chauvet (kwizart) 2009-03-16 22:55:09 UTC
Okay I got it:
Issue forwarded upstream:
http://code.google.com/p/libproxy/issues/detail?id=42

I don't think this issue will be fixed until the next 0.3 version is stabilized.
So closing this bug to UPSTREAM


Note You need to log in before you can comment on or make changes to this bug.