[PlanetCCRMA] Re: Size Mismatch Problem

[Andrew Wilson]

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?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20040725/a43714bf/attachment.html>