pamac behind proxy?

[ericho]

Hi, It is possible to use pamac behind a proxy?
If I start pamac-updater the application is unable to reach the servers.
pacman works ok with the general environment http_proxy but pamac does not.

I tried to dig in the code but i'm not sure where to start.

Thanks.

[ghost]

A python solution to this problem was added recently to cinnamon settings:

linuxmint/cinnamon@85be30d

[manjaro]

We changed to vala. So we can't implement this solution into pamac2

[guinux]

@ericho : Is this issue already exists with the last code ? If yes, can you tell me the method you use to export the http_proxy environment variable ?

[ericho]

I just updated, but i'm not sure If I have the last version.
My environment variables are stored in /etc/environment

After run pamac-updater, the program get stuck and then this traceback appears.

Traceback (most recent call last):
File "/usr/bin/pamac-updater", line 228, in
transaction.refresh()
File "/usr/lib/python3.4/site-packages/pamac/transaction.py", line 269, in refresh
Refresh(force_update)
File "/usr/lib/python3.4/site-packages/dbus/proxies.py", line 145, in call
**keywords)
File "/usr/lib/python3.4/site-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

[manjaro]

@ericho you're still using the python version. Please install pamac2:

sudo pacman -U http://repo.manjaro.org.uk/pool/overlay/pamac-2.0rc2-2-i686.pkg.tar.xz
sudo pacman -U http://repo.manjaro.org.uk/pool/overlay/pamac-2.0rc2-2-x86_64.pkg.tar.xz

... and try again.

[ericho]

what is the version of vte needed to run pamac2?

[guinux]

pamac2 needs vte3 >= 0.38
http://repo.manjaro.org.uk/pool/sync/vte-common-0.38.2-1-i686.pkg.tar.xz
http://repo.manjaro.org.uk/pool/sync/vte-common-0.38.2-1-x86_64.pkg.tar.xz
http://repo.manjaro.org.uk/pool/sync/vte3-0.38.2-1-i686.pkg.tar.xz
http://repo.manjaro.org.uk/pool/sync/vte3-0.38.2-1-x86_64.pkg.tar.xz

[ericho]

I ran pamac-updater and it is still unable to connect.

Synchronizing package databases...
Error: failed retrieving file 'core.db' from mirror.dacentec.com : Connection timed out after 10000 milliseconds
Error: failed retrieving file 'core.db' from mirror.jmu.edu : Connection timed out after 10000 milliseconds
Error: failed retrieving file 'core.db' from mirrors.ucr.ac.cr : Connection timed out after 10000 milliseconds
Error: failed retrieving file 'core.db' from mirror.catn.com : Connection timed out after 10000 milliseconds

Is there something that I can do to debug or provide more info?
Who is the responsible to make the connection, pamac2 or libalpm or another library?

[snachx]

Same problem here, the latest version of pamac doesn't work behind a proxy.

I tried all kinds of methods:

1. set the http_proxy and https_proxy in /etc/environment
2. set .bashrc for both root user and current user.
3. use gsettings to set gnome proxy

None of those works. Could you please help to solve this problem?

[ghost]

As i say, the solution is in the link that i provide. Apparently no one take a look of this... Let me explain, what is there, is a code that can extract the proxy setting from gnome and create a dictionary with all properties from the connection (the proxy). This NOT need an special python library, is only the mechanism and the mechanism can be ported easy to vala...

[snachx]

@manjaro
https://developer.gnome.org/ProxyConfiguration/
Gnome Project officially recommends using GProxyResolver API. And the solution adopted by cinnamon which using gsettings as @lestcape mentioned also works. I don't know vala and I have no time to read the source code deeply, is there someone helps solving this?

[philmmanjaro]

We are always glad for suggestions. When Guillaume will find time, he'll take a look at it.

[guinux]

I know the problem. There is the same issue with pacman and pamac. It's the fault of libalpm download function which use a unconfigurable timeout of 10s.
You can configure pacman to use a custom download command but it's not yet supported by pamac:
https://wiki.archlinux.org/index.php/Improve_pacman_performance#Using_wget

[ghost]

@guinux hey, manjaro have not a different pacmac implementation? I need to patch how handled the libalpm signals, because they are handled different in manjaro and in arch... https://github.com/lestcape/Cinnamon-Installer/blob/master/installer_modules/ci_pac.py#L480 I really don't use manjaro or arch, this not affect me at all.

[snachx]

@guinux
My problem is different from @ericho , it is not connection timeout error but resolve host error.
What you said is not the reason of my problem. In my environment, pacman has no problem when http_proxy and https_proxy are correctly set.
I checked the proxy's log and there's no output when using pamac, it means that there's no requests started through the proxy, but when I use pacman, everything is OK.
I also tried to configure pacman to use wget, pamac still doesn't work.

Error: failed retrieving file 'core.db' from lug.mit.edu : Could not resolve host: lug.mit.edu
Error: failed retrieving file 'core.db' from mirror.jmu.edu : Could not resolve host: mirror.jmu.edu
Error: failed retrieving file 'core.db' from mirror.dacentec.com : Could not resolve host: mirror.dacentec.com

[guinux]

@lestcape: libalpm signals are the same in manjaro and arch. What do you want to do?
@snachx: ok, I will investigate when I have time.

[ghost]

@guinux thats is an old history. As cinnamon can run on differents architectures with different packages format, packages managers, packages names, and libraries. Is problematic decide on time, how to install a package. In some extensions (applets, desklets...) will required dependencies to hard (normal) packages. Currently, the way to resolve this problematic, is alert the user that he need to install this packages, but i think is possible make this automatically, if the devs provide the dependencies for his extensions in concordance to the distro where the extension can be installed. Then we can perform an instalation automatically if some one provide a "backend", for the system libraries, in the manjaro case the backend that i use for libalpm is the pamac python implementation that i convert on a plugin to my application.

As the first approximation, i only take on account make a tool for install one package, but now i want to be more general and use this in the problematic of the cinnamon extensions. The model that i have is more or less similar to packages-kit, where is needed a backend for my program. This is working well on manjaro, but i tested it on arch and for some reason, the libalpm signals have differents parameters, so i checked the parameters and reorganised then, according of how i want to use it . I think is because manjaro have a fork of libalpm or a fork of the python bindings at less. I don't know because i resolve the problem in that way i don't take a deep look to this. Now you say that is a fault of libalpm, and i interpret of this that you are using the arch libalpm implementation. This then was interesting for me, as I had a different idea, no more.

[guinux]

No you were right, now I remember that manjaro uses a patched version of
pyalpm.

[philmmanjaro]

Well, we are still using the SyncFirst option for manjaro-system. That is why we have a patch for our pacman.

[ghost]

@philmmanjaro Yes, only a comment about this. I suppose was better put the new parameters at the end, not override any other parameter, and check if the new parameters exist inside the function. In this way, we can continue with the old compatibility and add new behaviours without affecting the old one in an easy way. I don't recommend change it again to this way, just to be take in account for new patches...

[philmmanjaro]

@lestcape: I assume you're talking about this patch. If you have a better way to solve this issue, I'm open for it. @guinux created that patch for us. Any solution is appreciated. Having the option to use pamac behind a proxy would be nice to have ...

[ghost]

@philmmanjaro as i can see, in this patch there are not any problematic things, i was talking about other thing... i.e. this patch not affected the external interface of libalpm or the bindings, this is the only thing that need to be taking on account (try to not affect the library interface). This will help to be easy support manjaro and arch at the same time. If someone will develop an app for arch and you want to port it to manjaro and manjaro has a different interface in some library, you will need to patch this application, what i talk is about reduce to the minimum this inconvenient. I don't say that anything is wrong. About help, well, i don't consider will be helpful use my first lines of code in vala. First i need to learn. Sorry.

[angiest]

I believe I have a similar problem with pamac (Manjaro, Arch, Antergos).

My proxy at work seems to be doing .... something, that causes curl to fail with similar (example taken from the pacman command):

core 121.8 KiB 29.7M/s 00:00 [######################] 100%
error: failed retrieving file 'extra.db' from mirror.rit.edu : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds

If I modify pacman.conf to use wget, it does complete successfully. Is there a reason why the setting in pacman.conf is not being honored by pamac?

[guinux]

I tried to fix this issue in v3.0.0, tell me if it's works.

[jetm]

@guinux: pamac through a proxy is working for me. Thanks!

[angiest]

I continue seeing this on 3.0:

Error: community.db: failed retrieving file 'community.db' from lug.mtu.edu : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds

Just about any mirror. This seems to be due to my work firewall/proxy as everything works perfectly at home.

For pacman and octopi I am using wget and it works.

[guinux]

Please try again with v3.1.0

[angiest]

The update hasn't hit repos or the AUR yet. I'll test it once it is
available.

On Mon, Feb 22, 2016 at 7:05 AM, guinux notifications@github.com wrote:

Please try again with v3.1.0

—
Reply to this email directly or view it on GitHub
#2 (comment).

We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time.
- TS Eliot, "Little Gidding," from "Four Quartets"

[guinux]

It's fixed in v4