Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#35506 - pacman: epoch URL encoding issue

Attached to Project: Pacman
Opened by Andrew Gunnerson (chenxiaolong) - Monday, 27 May 2013, 19:00 GMT
Last edited by Allan McRae (Allan) - Tuesday, 28 May 2013, 03:27 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version 4.1.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Pacman currently has a problem downloading some packages from certain hosts (especially dropbox). A package with an epoch has a colon in the filename, which is changed to '%3A'.

For example, a package with epoch 1:

liboverlay-scrollbar-1:0.2.16.r359daily13.02.06-105-x86_64.pkg.tar.xz

is downloaded to /var/cache/pacman/pkg/ as

liboverlay-scrollbar-1%3A0.2.16.r359daily13.02.06-105-x86_64.pkg.tar.xz

This causes pacman to fail with this debug output: http://paste.kde.org/751730/ As you can see, everything looks fine, but the file in /var/cache/pacman/pkg/ contains '%3A' instead of ':'.

Both curl and wget can properly download the file on the command line. I'm not sure why pacman has an issue. Is this something that can be fixed in pacman?

Thanks in advance!
This task depends upon

Closed by  Allan McRae (Allan)
Tuesday, 28 May 2013, 03:27 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Dropbox issue
Comment by Dave Reisner (falconindy) - Tuesday, 28 May 2013, 01:10 GMT
This server also wrongly returns 200 on a missing resource.
Comment by Allan McRae (Allan) - Tuesday, 28 May 2013, 01:12 GMT
@Dave: I'm assuming we can fix this given curl works on the command line?
Comment by Andrew Gunnerson (chenxiaolong) - Tuesday, 28 May 2013, 02:54 GMT
Thanks for the comments!

@Allan: The standard "curl -O" works just fine in the command line: http://paste.kde.org/752018/
Comment by Andrew Gunnerson (chenxiaolong) - Tuesday, 28 May 2013, 03:12 GMT
I must apologize. This is a problem with Dropbox (I think), not pacman. It's curl that's automatically converting ':' to '%3A'. Running curl on the command line does *NOT* work as the resulting file is: http://paste.kde.org/752024/

I'm not sure how to fix this other than avoiding epochs. Sorry for the noise.

Loading...