[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc_2.2.5-9.woody.4.deb is missing

Bob Nielsen <nielsen@oz.net> writes:

> Today's release of 2.2.5-10 appears to have resolved the problem.

For unstable perhaps, but not for us folks sticking with testing.

On a side note, I get this:

  # /usr/bin/apt-get -d upgrade
  Readin Package Lists... Done
  Building Dependency Tree... Done
  The following packages will be upgraded
    glibc-doc libc6
  2 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
  Need to get 6081kB of archives. After unpacking 0B will be used.
  Do you want to continue? [Y/n]
  Get:1 http://security.debian.org woody/updates/main libc6 2.2.5-9.woody.4 [3382kB]
  Get:2 http://security.debian.org woody/updates/main glibc-doc 2.2.5-9.woody.4 [2698kB]
  Fetched 6081kB in 10s (594kB/s)
  Failed to fetch http://security.debian.org/pool/updates/main/g/glibc/libc6_2.2.5-9.woody.4_i386.deb  MD5Sum mismatch
  Failed to fetch http://security.debian.org/pool/updates/main/g/glibc/glibc-doc_2.2.5-9.woody.4_all.deb  MD5Sum mismatch
  E: Some files failed to download

I checked file sizes in /var/cache/apt/archives/partial and they match
what is in my Packages file for woody updates.  The md5sum obviously
don't so at least apt-get is sane.

The totally weird thing is that the md5sums for second and later
attempts differ from those for the first attempt.  So I have

  1st attempt --> file sizes OK, md5sums don't match those in Packages
  2nd attempt --> file sizes OK, md5sums don't match those in Packages
                  and differ from those of first attempt download
  3rd attempt --> file sizes OK, md5sums don't match those in Packages
                  and differ from those of first attempt download
                  BUT identical to those of second attempt download
  4th and later attempts identical to 3rd attempt

Assuming the packages on security.debian.org have the md5sums listed
in the Packages file, I'm now wondering if our proxy is mangling the
packages during the download and mangling them again when caching.
FWIW, I believe our proxy uses DeleGate and a quick look over at


learns that it is possible to set it up to do on the fly conversion.

My Packages file says:

  a730d3b53c235b172a0d34028e438fc0        2698500 glibc-doc
  f099723966e3593e6a048f2f9167a178        3382190 libc6

I have seen similar behaviour here before trying to install additional
packages from sources I do not mirror locally.  Funny thing is that my
mirror is kept up-to-date using the same transmission protocol that is
used by apt-get (HTTP in my case) and those don't get screwed up.  Can
it be that conversion is only active during parts of the day?

Sorry to ramble on a bit.  Any insights are welcome.
Olaf Meeuwissen                            EPSON KOWA Corporation, CID
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97  976A 16C7 F27D 6BE3 7D90
LPIC-2               -- I hack, therefore I am --                 BOFH

To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: