It is on the TODO list.

I would like to clarify what we propose to do for this.

Should packagemanager set http_proxy environment variable from GCOnf settings
on startup?

I have found that if "Direct internet connection" is set in Network Proxy
Preferences, i.e. GConf key /system/proxy/mode has value "none", then
http_proxy environment variable is not set when a user logs into GNOME.

If /system/proxy/mode has a value other than "none" then http_proxy environment
variable is set when a user logs into GNOME.

I suggest that packagemanager should do the following:

1) If /system/proxy/mode changes to "none" the environment variable http_proxy
is unset.

2) if /system/proxy/mode changes to a value other than "none" the environment
variable http_proxy is reset

3) If /system/http_proxy/port or system/http_proxy/host changes and 
/system/proxy/mode has a value other than "none" then the environment variable
http_proxy is reset.

1) I think environment variable http_proxy should have a higher priority than
gconf settings.

2) If you have enabled a http proxy in prefs (i.e. gconf settings), I think the
http_proxy is automatically set by gnome-terminal, it might not work for
Package Manager, if you don't run it from CLI.

So I think Package Manager should take http_proxy env variable first, if
http_proxy is not set, it should check gconf settings.

hello,
Could you please confirm that the problem described below derives from this
bug?
Is there no way to work around this problem until a fix is provided?

Thank you in advance.

Best Regards,

Y. Adam


Problem:
=======
Impossible to install any additional package with Package manager.

Behavior:
========
After having selected a package to be installed (openoffice or any other) 
a windows shows up an remains for several minutes :

+-----------------------------------------------------+
| Checking package dependencies...                    |
| =======****======================================   |
| Details>                                            |
|   Evaluation started.                               |
|   Gathering packages information, please wait...    |
+-----------------------------------------------------+


After which a second window comes up with an error message saying:

+-----------------------------------------------------+
|   Please check the network connection.              |
|   Is the repository accessible?                     |
+-----------------------------------------------------+

The major configuration items are:
=================================
- opensolaris 2008.11
- running on: xVM VirtualBox
- host: Windows XP Pro
- Network adapter: host interface (VM1 external)

Remarks: 
========
- TCP/IP and Internet workig properly
- http://pkg.opensolaris.org/release/en/index.shtml can be accessed with
Firefox
- Autoproxy configuration set up the same way in Firefox and desktop
application


Wireshark traces on host system:
39    11.438336    20.32.9.92    72.5.123.21    TCP    34620 > http [SYN] Seq=0
Win=49640 Len=0 MSS=1460 WS=0

Can you try setting http_proxy environment variable in a gnome-terminal and
then run pfexec packagemanager?

When packagemanager is run from the menu on clicking on icon, gksu
packagemanager is run so I think that it may be root's proxy setting that will
be looked for.

(In reply to comment #6)
> Can you try setting http_proxy environment variable in a gnome-terminal and
> then run pfexec packagemanager?
> 
> When packagemanager is run from the menu on clicking on icon, gksu
> packagemanager is run so I think that it may be root's proxy setting that will
> be looked for.

We have some more logs, but it still doesn't work but I am not sure I set the
variable with the appropriate syntax (you can see below). 
Wireshark shows the same behaviour.

I have also tried with 'pkg' - same result.

To make sure that the proxy settings were correct, I have switched System and
firefox from autoproxy to manual with the same hardcoded values than the ones
used for the test you suggested.

Thank you.

Best Regards,

Y. Adam

PS: console logs:


dc32@devcenter32:~$ set http_proxy="http://20.45.33.124:8080"
dc32@devcenter32:~$ pfexec pkg install openoffice
pkg: 0/1 catalogs successfully updated:
    1: Transfer from 'opensolaris.org' timed out: timed out.
2: Transfer from 'opensolaris.org' timed out: timed out.
3: Transfer from 'opensolaris.org' timed out: timed out.
4: Transfer from 'opensolaris.org' timed out: timed out.

dc32@devcenter32:~$ set http_proxy="http://20.44.34.33:8080"
dc32@devcenter32:~$ pfexec packagemanager
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/lib/python2.4/threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/bin/packagemanager", line 2023, in get_manifests_for_packages
    filtered = True)
  File "/usr/bin/packagemanager", line 1907, in get_manifest
    manifest = img.get_manifest(package, filtered)
  File "/usr/lib/python2.4/vendor-packages/pkg/client/image.py", line 979, in
get_manifest
    m = self.__get_manifest(fmri)
  File "/usr/lib/python2.4/vendor-packages/pkg/client/image.py", line 950, in
__get_manifest
    m = self.__fetch_manifest_with_retries(fmri)
  File "/usr/lib/python2.4/vendor-packages/pkg/client/image.py", line 791, in
__fetch_manifest_with_retries
    raise failures
TransportFailures: 1: Transfer from 'http://pkg.opensolaris.org/release' timed
out: timed out.
2: Transfer from 'http://pkg.opensolaris.org/release' timed out: timed out.
3: Transfer from 'http://pkg.opensolaris.org/release' timed out: timed out.
4: Transfer from 'http://pkg.opensolaris.org/release' timed out: timed out.


Exception in thread Thread-4:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/lib/python2.4/threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/bin/packagemanager", line 1202, in __show_package_info
    pkg_info = self.__get_pkg_info(pkg.get_name(), installed)
  File "/usr/bin/packagemanager", line 1163, in __get_pkg_info
    get_action_info=True)
  File "/usr/lib/python2.4/vendor-packages/pkg/client/api.py", line 683, in
info
    mfst = self.img.get_manifest(f, filtered=True)
  File "/usr/lib/python2.4/vendor-packages/pkg/client/image.py", line 979, in
get_manifest
    m = self.__get_manifest(fmri)
  File "/usr/lib/python2.4/vendor-packages/pkg/client/image.py", line 950, in
__get_manifest
    m = self.__fetch_manifest_with_retries(fmri)
  File "/usr/lib/python2.4/vendor-packages/pkg/client/image.py", line 791, in
__fetch_manifest_with_retries
    raise failures
TransportFailures: 1: Transfer from 'http://pkg.opensolaris.org/release' timed
out: timed out.
2: Transfer from 'http://pkg.opensolaris.org/release' timed out: timed out.
3: Transfer from 'http://pkg.opensolaris.org/release' timed out: timed out.
4: Transfer from 'http://pkg.opensolaris.org/release' timed out: timed out.


dc32@devcenter32:~$

export VARIABLE=value  # for Bourne, bash, ksh, and related shells
setenv VARIABLE value  # for csh and related shells

So, try export http_proxy=http://xxx.xxx.xxx.xxx:8080

It worked with the right syntax: (export)

Thanks for your help.

Best Regards,

Y. Adam

dc32@devcenter32:~$ set http_proxy='http://20.44.34.33:8080'
dc32@devcenter32:~$ export http_proxy='http://20.44.34.33:8080'
dc32@devcenter32:~$  pfexec pkg install openoffice
PHASE                                          ITEMS
Indexing Packages                            554/554 
DOWNLOAD                                    PKGS       FILES     XFER (MB)
openoffice                                   0/1    176/3932   6.15/151.65 


So the work around is:
- use package manager to find the necessary packages
- set (export) the http_proxy value
- use "pkg install" to install the identified packages 
(the latter might also work with packagemanager - didn't try).

(In reply to comment #5)
> hello,
> Could you please confirm that the problem described below derives from this
> bug?
> Is there no way to work around this problem until a fix is provided?

You will need to start the packagemanager with http_proxy in your env.

Simply:

$ http_proxy=http://someproxy.com:8080 gksu /usr/bin/packagemanager

(In reply to comment #10)

Please note that the same problem and workaround apply for the UPDATE MANAGER.
Hopefully the fix you will provide will fix them both at once.

The following command allowed me to install the updates of today:

dc32@devcenter32:~$ http_proxy='http://20.44.34.33:8080'  gksu
/usr/bin/updatemanager -r

(note that if the fix is in the update... your fix won't be install
automatically ... for those having the problem!).

Best regards,

Y. Adam

> (In reply to comment #5)
> > hello,
> > Could you please confirm that the problem described below derives from this
> > bug?
> > Is there no way to work around this problem until a fix is provided?
> 
> You will need to start the packagemanager with http_proxy in your env.
> 
> Simply:
> 
> $ http_proxy=http://someproxy.com:8080 gksu /usr/bin/packagemanager

Dropped to P3 - this will be fixed when NWAM can supply PM with the proxy
settings even though PM is running as root. 

This will not be addressed for June 2009 release.

Just thought I'd point out that one could use the -k feature with gksu if
http_proxy was set in the end user's environment when proxy settings are set
globally.

(In reply to comment #12)
> Dropped to P3 - this will be fixed when NWAM can supply PM with the proxy
> settings even though PM is running as root. 
> This will not be addressed for June 2009 release.

If Manual Proxy configuration is set in Network Proxy preferences 
then http_proxy environment variable is set when Package Manager is started
when gksu -k is used.

If we then change the setting, Package Manager does not become aware of the
changed setting. 

Thus, using gksu -k will pick up the correct value for http_proxy environment
variable. It will not fix the problem Calum described, that Package Manager
does not react to the changes in the settings.

There are two issues here.

1) If the user has http proxy settings specified in GConf these are not used
when user activates Package Manager or Update Manager from icon or menu.

This can be fixed by a simple script which sets http_proxy environment variable
and then calls gksu to invoke Package Manager or Update Manager.

2) When the user changes proxy settings Package Manager or Update Manager does
not subscribe to these changes.

The problem here is that Package Manager and Update Manager do not run as the
user who launched them.

The webrev http://cr.opensolaris.org/~padraig/ips-1835-v1/ ensures that
http_proxy is set, if required, before Package Manager or Update Manager is
invoked from a desktop file.

*** Bug 9252 has been marked as a duplicate of this bug. ***

I have changed the summary of this bug to reflect the issue remaining to be
resolved.

The issue about Package Manager and Update Manager not using user's GNOME proxy
settings when invoked from the menu item or desktop icon will be fixed as 9574,

On b122:
After being hit by another side-effect of this problem, bug 9252 provided a
solution.

pkg.sun.com/opensolaris/extra requires an HTTPS connection.
However, when GNOME is set up to use the same proxy for all protocols, it
doesn't set https_proxy, only http_proxy.

So https_proxy must still be set manually for updates to work.

pkg & packagemanager should also use http_proxy for all protocols if the other
environment variables are not set.

gnome-terminal only sets http_proxy.
It would be good if it can also sets https_proxy, ftp_proxy, and all_proxy (if
the user clicked use the same proxy for all protocols).

But it still wouldn't work for autoconfiguration proxy.

Perhaps libproxy can resolve this problem.

Laurent,

Please open a new bug for your issue.
Are you using /usr/lib/pm-launch to start PackageManager? This should set the
proxy settings.

This bug is for the issue of Package Manager not responding to changes in GNOME
proxy settings.

Sorry, I added my comment here because my bug is bug 9252, which has been
marked as a duplicate of this one by Shawn. I'll de-duplicate it.