[PlanetCCRMA] Re: Size Mismatch Problem

[Axel Thimm]

--E13BgyNx05feLLmH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 24, 2004 at 10:08:58AM +0800, Andrew Wilson wrote:
> Thanks for the suggestions.
>=20
> Just an update: =20
>=20
> Over the past couple of days I am still getting the problem, however it
> doesn't consistently happen on all the files (with the exception of the
> srclist file).  So I have not been able to do an apt-get update against
> the planet repository without getting a size mismatch error.
>=20
> I have also converted to the ATrpms mirror. (This process has a couple
> of catches, but I think definitely worthwhile doing).

What catches are there? I'd like to remove as amny as possible :)

> All the files from other repositories were OK with the exception of
> occassional ftp exceed user limit type errors.

Probably for jpackage, I suppose? It is good that apt is so fault
tolerant.

> The planetccrma files still showed a size mismatch error.  Again, with
> the exception of the srclist file, the other ones did not consistently
> fail.=20

you mean also when using planetccrma.atrpms.net? Then the expiry
settings are not working for you :(

> I'd love to be able to debug this.  What does the "size mismatch" error
> actually mean?

I means that the size as stored in one of the base files does not
match the actual size of the target file. I.e. the two files are out
of sync. That can almost only happen if you have cached one of the,
especially when you are seeing it so long.

Try using wget --cache=3Doff on the files to be downloaded, before using
apt. --cache=3Doff adds a "Pragma: no-cache" header that cache systems
and proxies should respect and go renew their copy. The immediately
next apt-get operation should see fresh copies (at least in theory).

Also post the results (date & md5sums) of the manually downloaded
files, so we can compare with the actual contents.

> Thanks again for your help.
>=20
> Andrew
>=20
> On Wed, 2004-07-21 at 08:42, Fernando Pablo Lopez-Lezcano wrote:
>=20
> > On Mon, 2004-07-19 at 04:10, Axel Thimm wrote:
> > > On Mon, Jul 19, 2004 at 12:17:12PM +0200, David Fraser wrote:
> > > > Axel Thimm wrote:
> > > > >On Mon, Jul 19, 2004 at 05:09:48PM +0800, Andrew Wilson wrote:
> > > > >>pkglist.updates
> > > > >>pkglist.planetccrma
> > > > >>srclist.planetccrma
> > > > >>
> > > > >>fail to download with a "Size Mismatch" error.  I left it for a
> > > > >>while to see if it was a temporary error due to a repository
> > > > >>update etc.  However I have been getting the error for a couple of
> > > > >>weeks now.
> > >=20
> > > > >I don't have any issues. This is commonly seen on cached lines. Do=
 you
> > > > >have a transparent squid or otherwise, you can turn off? Or is your
> > > > >ISP doing the caching for you?
> > >=20
> > > > I've often had problems like this. It would be great if there was a=
 more=20
> > > > intelligent way to try debug them ...
> > > > I'm sure that they're not just caching problems as I've checked MD5=
 sums=20
> > > > from other hosts in other countries and still had the problems...
> > >=20
> > > On Mon, Jul 19, 2004 at 06:34:56PM +0800, Andrew Wilson wrote:
> > > > I am not running any local proxy or caching.  My ISP does run a
> > > > proxy so I need to confirm that this is not the problem. =20
> > > >=20
> > > > However the problem has been extending over a couple of weeks which
> > > > is a long time to hold something in cache.  Also the update process
> > > > was working fine on Fedora Core 1 (plus RH9 and RH8).  It was also
> > > > possible to retrieve using wget (also http).
> > > >=20
> > > > My guess is still with something I have broken, but I am game to
> > > > check anything.
> > >=20
> > > The mirror at planetccrma.atrpms.net has a server side expiry
> > > mechanism to overcome intermediate proxys caching the metadata.
> > >=20
> > > Could you try this (It is updated once a day at 19:00 CEST)? If it
> > > works it is a caching issue, if not, it is something else.
> >=20
> > It would be nice to know what happened if you try the atrpms mirror. If
> > there is something I can do at the server side I would do it (Axel: how
> > do you set that expiry mechanism?)
--=20
Axel.Thimm at ATrpms.net

--E13BgyNx05feLLmH
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBAhwbQBVS1GOamfERAnKyAJwIBW1qurd0JUzKcRGo6qfXzp5i0ACfUwFw
6ogHZy7drwQq3R8zqVnAQbg=
=OwT8
-----END PGP SIGNATURE-----

--E13BgyNx05feLLmH--