Re: Bug#63124: apt-get isn't getting new Package lists
On Fri, 28 Apr 2000, Matthew Hawkins wrote:
> > > Well the local /var/state/apt/lists/ keeps it uncompressed, I can't
> > > really show that the files are different if I quote one compressed and
> > > the other uncompressed now, can I?
> >
> > gzip -d foo | wc -c
>
> You complained that I showed the uncompressed version as apt takes the
> compressed one. Now you insist I use it. Please be a little more
> consistent.
Eh? I am being very consistent, I want you to verify unquestionably that
the gzip file is the same as the ungziped version and different from the
one APT gets.
> > or md5sum is good too.
>
> If I md5sum two files, one of which is compressed and the other not -
> the sum will be different. What's the point to that?
zcat foo.gz | md5sum
> I already _know_ the files are different. They're different sizes for
> crying out loud!
You are *assuming* that the Packages.gz == Packages, there could be a
problem with the mirror.
> > It has to! It cannot make this up! It goes to the network and pulls down
> > whatever is there. *IT CANNOT CREATE A PACKAGE FILE FROM THIN AIR* :>
>
> I'm not saying it created a package file out of thin air, I'm saying it
> is not getting the UPDATED file. It already has a file, it's x bytes
You said you erased everything in /var/state/apt/lists - if this is so,
where did the old file come from???
> Notice the small size discrepency - that's today's packages, which apt
> has not retrieved. I have tried deleting the files in
> /var/state/apt/lists/ (which worked yesterday) but to no avail today.
If you did do that then where did the old file come from??
> Apt-get on the client machine is not updating its local status lists
> with this newer Packages file. It is simply keeping its existing one.
This only happens if the server (or intemediate proxy) says the file has
not changed.
> company mirror, and two separate official debian mirrors. I've given my
> sources.list file, apt.conf, stated I don't have http_proxy set. Surely
You could have a 'transparet proxy' in your way, that is becoming
increasingly common and frequently causes these sorts of problems.
> there's enough information there to see that there is a problem with
> apt? What more do you want? Oh, btw it's the same story today, and
It is extrmely unlikely that this is an apt bug, the code to determine
newness is really trivial and relies on the server side. I assume you are
using Apache, so run apt-get update and look at the apache access log and
see what it says.
Jason
Reply to: