<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
Thanks for the suggestions.<BR>
<BR>
Just an update: <BR>
<BR>
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.<BR>
<BR>
I have also converted to the ATrpms mirror. (This process has a couple of catches, but I think definitely worthwhile doing). All the files from other repositories were OK with the exception of occassional ftp exceed user limit type errors. <BR>
<BR>
The planetccrma files still showed a size mismatch error. Again, with the exception of the srclist file, the other ones did not consistently fail. <BR>
<BR>
I'd love to be able to debug this. What does the "size mismatch" error actually mean?<BR>
<BR>
Thanks again for your help.<BR>
<BR>
Andrew<BR>
<BR>
On Wed, 2004-07-21 at 08:42, Fernando Pablo Lopez-Lezcano wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>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.
>
> > >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?
>
> > I've often had problems like this. It would be great if there was a more
> > intelligent way to try debug them ...
> > I'm sure that they're not just caching problems as I've checked MD5 sums
> > from other hosts in other countries and still had the problems...
>
> 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.
> >
> > 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).
> >
> > My guess is still with something I have broken, but I am game to
> > check anything.
>
> The mirror at planetccrma.atrpms.net has a server side expiry
> mechanism to overcome intermediate proxys caching the metadata.
>
> 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.
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?)
-- Fernando
_______________________________________________
PlanetCCRMA mailing list
PlanetCCRMA@ccrma.stanford.edu</FONT>
<A HREF="http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma"><U>http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma</U></A>
<FONT COLOR="#737373"></I></FONT></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>