Package Details: pear-http-request2 2.2.1-2

Git Clone URL: (read-only, click to copy)
Package Base: pear-http-request2
Description: Provides an easy way to perform HTTP requests.
Upstream URL:
Keywords: broken to-be-deleted unneeded unused-lib wrong-name
Licenses: BSD3
Submitter: javitonino
Maintainer: MarsSeed
Last Packager: javitonino
Votes: 2
Popularity: 0.000000
First Submitted: 2015-08-27 11:48 (UTC)
Last Updated: 2015-12-31 09:08 (UTC)

Latest Comments

javitonino commented on 2015-12-31 09:10 (UTC)

I have updated the checksums. It seems that pear is slowly repacking everything. Last week I updated the ldap packages. but this seemed OK. Anyway, thanks for the tip.

snoewchen commented on 2015-12-31 08:36 (UTC)

Yes, indeed, they built new zip files upstream. Unpacking the tgz file and repacking it again yields a file with the size 109,716 that matches the official file ( exactly - except bytes 4, 5, 6, and 7 (if I am not mistaken, that's the modification time of the original file)

snoewchen commented on 2015-12-31 08:03 (UTC)

That's weird - it seems to me the file "HTTP_Request2-2.2.1.tgz" changed upstream (silently) - may be it got repackaged?. The old file size was 107,339 - but now it is 109,716 (new md5sum: 3549103543209ebbbd065f49e62d9eca) I found an old version of the tgz at - unpacked and compared the content - the content is exactly the same. A binary comparison of the tgz files reveals that right at the start of the file (around byte 11) the new tgz file seems to have the optional header field "original file name" set whereas the old tgz file has not. At that point I stopped the investigation. I have no idea if a repackaging upstream is a valid explanation and why the package numbers are not bumped if that's the case. (clamscan claims the file is o.k)