Bug 275276 - qapt-batch doesn't honour proxy settings
Summary: qapt-batch doesn't honour proxy settings
Status: RESOLVED FIXED
Alias: None
Product: muon
Classification: Unmaintained
Component: qaptworker (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Jonathan Thomas
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-09 12:10 UTC by Markus Hansmair
Modified: 2011-06-19 18:55 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 1.1.85, 1.1.4
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Hansmair 2011-06-09 12:10:14 UTC
Version:           unspecified (using KDE 4.6.2) 
OS:                Linux

I'm sitting in an enterprise environment behind an HTTP proxy. When starting a KDE application that tries to automagically install further software (e.g. dragon tries to install libavcodec-extra-52) the notifier and a 'download' icon appear in the control bar. After clicking the 'download' icon, the dialog with the desired packages is presented, then my password is prompted (apparently for sudo) and finally qapt-batch is started and tries to download.

But it tries to connect directly to some download site (verified with netstat -apn) which fails. I've checked the environment qapt-batch runs with and it contains http_proxy (set at the very start of my X session via ~/.xsessionrc). Additionally our proxy is also configured in the general KDE settings. (E.g. rekonq runs flawlessly.) 

Reproducible: Always

Steps to Reproduce:
Run behind some HTTP proxy and launch a KDE application, that tries to install some additional software (e.g. dragon, amarok)

Actual Results:  
qapt-batch gets stuck while trying to download

Expected Results:  
Downloading additional packages should use the HTTP proxy specified either by http_proxy or the general KDE settings.

Ubuntu Natty 11.04, qapt-batch 1.1.2-0ubuntu1, libqapt-runtime 1.1.2-0ubuntu1, libqapt1 1.1.2-0ubuntu1
Comment 1 Jonathan Thomas 2011-06-09 17:22:18 UTC
Thinking about it, this is probably a case of DBus spawning the qapt-worker process in a non-shell environment where the env variables aren't being set. I know I had to manually set language variables for localization, so it may be the case that I'll have to do the same thing for proxies.

In the meantime, putting a config entry like this in /etc/apt.conf (or in a file in /etc/apt.conf.d/ should work around the issue by setting the proxy on the application level for apt:

Acquire {
http {
Proxy "http://foouser:barpassword@wwwcache.rdg.ac.uk:8080/";
No-Cache "false";
Max-Age "86400";
No-Store "false";
};
};
Comment 2 Jonathan Thomas 2011-06-19 18:54:15 UTC
Git commit 9943c063f5dc2a53252c8700c704b136a852bf4e by Jonathan Thomas.
Committed on 19/06/2011 at 18:40.
Pushed by jmthomas into branch '1.1'.

Send the value of the http_proxy env var to the worker, since it normally runs
in a shell-less environment with no env vars defined.

BUG:275276
FIXED-IN: 1.1.85, 1.1.4

Conflicts:

	src/backend.cpp

M  +17   -2    src/backend.cpp     
M  +3    -0    src/worker/org.kubuntu.qaptworker.xml     
M  +5    -0    src/worker/worker.cpp     
M  +1    -0    src/worker/worker.h     

http://commits.kde.org/libqapt/9943c063f5dc2a53252c8700c704b136a852bf4e
Comment 3 Jonathan Thomas 2011-06-19 18:54:15 UTC
Git commit e29c463dcec3ac0a0b44c5e9e62ac58814de52ff by Jonathan Thomas.
Committed on 19/06/2011 at 18:40.
Pushed by jmthomas into branch 'master'.

Send the value of the http_proxy env var to the worker, since it normally runs
in a shell-less environment with no env vars defined.

BUG:275276
FIXED-IN: 1.1.85, 1.1.4

M  +21   -4    src/backend.cpp     
M  +3    -0    src/worker/org.kubuntu.qaptworker.xml     
M  +5    -0    src/worker/worker.cpp     
M  +1    -0    src/worker/worker.h     

http://commits.kde.org/libqapt/e29c463dcec3ac0a0b44c5e9e62ac58814de52ff
Comment 4 Jonathan Thomas 2011-06-19 18:55:37 UTC
That should do it. :)

I tested with a fake proxy "localhost:8888" to see if the qapt-worker would pick up on it. It seemed to work, since I got DNS resolution errors as expected.