[pacman-dev] [arch-dev-public] [signoff] pacman 3.2.0

Xavier shiningxc at gmail.com
Sun Aug 3 19:26:30 EDT 2008


On Sun, Aug 3, 2008 at 8:26 PM, Xavier <shiningxc at gmail.com> wrote:
>
> What really bothers me here is that it looks like a libdownload issue,
> yet it is reported as a pacman 3.2.0 regression. And libdownload has
> not changed for ages.
> So is that issue really reproducible without problems with 3.2.0, and
> when you go back to 3.1.4, everything works perfectly fine again?
> This is so odd :/
> Are you sure it could not have been caused by another change, like a
> change in the ftp server, or some network settings, or whatever?
>

So trying to reproduce the issue, I first tried to set up vsftpd.
It worked perfectly with ncftp and firefox, but no luck with
libdownload :P The only thing it told me is :
error: failed retrieving file 'custom.db.tar.gz' from 127.0.0.1 : File
unavailable (e.g., file not found, no access)

So well, I gave up, and tried with pure-ftpd. And this time. exactly
the same error as Andy, "Command okay"
So I started inspecting the download code between 3.1.4 and 3.2.0.
While the core mostly stayed the same, it has been heavily refactored,
so some small details could have changed. I finally found one
difference that caught my eyes :
  /* remove trailing slashes, just to clean up the rest of the code */
  for(int i = strlen(u->doc) - 1; u->doc[i] == '/'; --i)
    u->doc[i] = '\0';

I removed the trailing slash on my Server line in pacman.conf, and it
worked perfectly...

So I patched pacman to remove an eventual trailing slash, and the
patch will follow quickly.
But I wonder if libdownload should not be patched as well. "Command
ok" seems rather misleading. Returning the following error would be
much better if it is possible :
     [DLERR_URL]         Invalid URL



More information about the pacman-dev mailing list