[PlanetCCRMA] Re: Size Mismatch Problem
Andrew Wilson
djazz@myrealbox.com
Sun Jul 25 20:08:00 2004
--=-WrRpb0eaFFdVY+HtcHjw
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
On Sat, 2004-07-24 at 16:21, Axel Thimm wrote:
[snip]
> > 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 :)
Well probably of my own doing, however:
I was an existing user of the ccrma repository. So my sources.list and
vendors.list files were setup for good ccrma. I was assuming that to
move to ATrpms all I had to do was modify the sources.list and
vendors.list file for ATrpms.
* Firstly I couldn't see anywhere which described the structure of the
repository, web site address etc.
* So then I looked for a sample sources.list. Didn't find one on the
ATrpms site but did on some discussion groups.
* Then went look for the information to create a new entry in the
vendors.list file. Was all there except for the fingerprint.
* So then I took the "newbie" way. Downloaded and installed the
kick-start package and then did the appropriate updates and I was away.
Well not totally as I had to know that because I was using an existing
apt-get the sources.list.rpmnew and vendors.list.rpmnew needed to be
renamed first.
All in all it was quite painless.
> > 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.
Yup. You got it in one.
> > The planetccrma files still showed a size mismatch error. Again, with
> > the exception of the srclist file, the other ones did not consistently
> > fail.
>
> you mean also when using planetccrma.atrpms.net? Then the expiry
> settings are not working for you :(
When I wrote the last submission, it applied to planetccrma.atrpms.net.
However, I just did another apt-get update and all the ".atrpms" updates
worked. First time in a long time. So problem fixed? Hope so.
I will monitor and if I see another error I'll follow your advice below,
clear the cache and get the date and MD5 checksums for the files.
Thanks again for your help.
Andrew
> > 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=off on the files to be downloaded, before using
> apt. --cache=off 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.
> >
> > Andrew
> >
> > On Wed, 2004-07-21 at 08:42, Fernando Pablo Lopez-Lezcano wrote:
> >
> > > 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?)
--=-WrRpb0eaFFdVY+HtcHjw
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!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>
On Sat, 2004-07-24 at 16:21, Axel Thimm wrote:<BR>
<BR>
[snip]<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>> 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 :)</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
Well probably of my own doing, however:<BR>
<BR>
I was an existing user of the ccrma repository. So my sources.list and vendors.list files were setup for good ccrma. I was assuming that to move to ATrpms all I had to do was modify the sources.list and vendors.list file for ATrpms. <BR>
<BR>
* Firstly I couldn't see anywhere which described the structure of the repository, web site address etc.<BR>
* So then I looked for a sample sources.list. Didn't find one on the ATrpms site but did on some discussion groups.<BR>
* Then went look for the information to create a new entry in the vendors.list file. Was all there except for the fingerprint.<BR>
* So then I took the "newbie" way. Downloaded and installed the kick-start package and then did the appropriate updates and I was away. Well not totally as I had to know that because I was using an existing apt-get the sources.list.rpmnew and vendors.list.rpmnew needed to be renamed first. <BR>
<BR>
All in all it was quite painless.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>> 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.</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
Yup. You got it in one.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>> The planetccrma files still showed a size mismatch error. Again, with
> the exception of the srclist file, the other ones did not consistently
> fail.
you mean also when using planetccrma.atrpms.net? Then the expiry
settings are not working for you :(</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
When I wrote the last submission, it applied to planetccrma.atrpms.net. <BR>
<BR>
However, I just did another apt-get update and all the ".atrpms" updates worked. First time in a long time. So problem fixed? Hope so.<BR>
<BR>
I will monitor and if I see another error I'll follow your advice below, clear the cache and get the date and MD5 checksums for the files.<BR>
<BR>
Thanks again for your help.<BR>
<BR>
Andrew<BR>
<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>> 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=off on the files to be downloaded, before using
apt. --cache=off 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.
>
> Andrew
>
> On Wed, 2004-07-21 at 08:42, Fernando Pablo Lopez-Lezcano wrote:
>
> > 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?)</I></FONT></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-WrRpb0eaFFdVY+HtcHjw--