#include <hallo.h> * Raúl Sánchez Siles [Mon, Jan 12 2009, 11:10:16AM]:
> Get:1 http://ftp.dat.etsit.upm.es lenny/main perl-modules 5.10.0-19 [3189kB] Not enough information. However, it's delivered correctly from the cache and seems to be "reproducible", so the problem is already persisted in the cache. (*) Could you run: apt-get -dyqff -o Debug::Acquire::Http=true install perl-modules apt-get clean apt-get -dyqff -o Debug::Acquire::Http=true install perl-modules and show the output starting with HTTP? > Hints appreciated as well as tests I could perform to find out what the > problem > could be. Quick fix: # find /var/cache/apt-cacher-ng/. -name 'perl-modules*5.10.0-19*' Move that files out of the cache to some other safe location (called dirA). Then do your upgrade (should work but we are not done yet *g* ). Run the same command again, copy the new created files to another directory, dirB. Then run: diff dirA/perl-modules_5.10.0-19_all.deb dirB/perl-modules_5.10.0-19_all.deb diff dirA/perl-modules_5.10.0-19_all.deb.head dirB/perl-modules_5.10.0-19_all.deb.head ls -la dirA/perl-modules_5.10.0-19_all.deb dirB/perl-modules_5.10.0-19_all.deb sha1sum dirA/perl-modules_5.10.0-19_all.deb dirB/perl-modules_5.10.0-19_all.deb and show me the output. Regards, Eduard. (*) I quick guess: the delivering server was confused, i.e. you started the download at the moment of the server upgrade or so, therefore few bytes of that file are missing. IIRC the current code for expiration w/ contents checks might detect corrupted files, but I it would keep incomplete ones... not sure, maybe the code is a bit too safe and not smart enough to the size mismatch in the metadata. -- <HE> Myon: Einigkeit und Recht und Allohol! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
