This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to detect a broken cygwin mirror?

On  3 Sep, luke replied to Christopher when he wrote:
>  >  However, since you raise the issue of md5sums, it's hard to see how 
>  >  your mirror could be bad and not have setup.exe complain about an 
>  >  incorrect md5. 
>  Righto.  I'll write a script to check our mirror, independent of 
>  setup.exe.  Then check ours, and pick another mirror site if 
> has broken.  (Though I'm not 100% certain that it's 
>  the explanation for my "Subject: Setup problem: incomplete nonexistent 
>  package" thread.) 

Well, I'm running setup now, installing everything, though my check
script reveals that 3 packages have problems (not the package that was
causing the problem before).

$   ~/script/md5cygchk -q /u/mirror/cygwin/release
    Summary of files with broken checksums:

    In ./binutils:
    md5.sum: FAILED
    md5sum: WARNING: 1 of 6 computed checksums did NOT match

    In ./check:
    check-0.8.4-1-src.tar.bz2: FAILED
    md5sum: WARNING: 1 of 3 computed checksums did NOT match

    In ./ncurses/libncurses5:
    libncurses5-5.2-1-src.tar.bz2: FAILED
    md5sum: WARNING: 1 of 3 computed checksums did NOT match

Before, it was failing after a minute (probably after it checked the
md5 sigs).  Now, it's been happily installing for an hour (in fact it's
running the Cygwin postinstall scripts now).

Since I told setup to install all, would you expect setup to fail,
reporting that at least one of the above packages is broken?  Because
it isn't complaining...

We first rsync-ed from; that has broken TeXmacs (and
more?).  Following that we rsync from, which
replaced TeXmacs.  But that still leaves us with the three problems
reported above.

What do you think of this idea, to try to get a good local mirror?  (It
relies on the fact that rsync will only download missing files, so it's
not as horrendous as it may seem at first):

for each host in
	rsync our mirror from the host
	check our mirror's checksums
	if check is good, break (otherwise, next in list)

Especially if we use the --update option.  Unless sluggish mirrors that
were way out of date would cause deletion of newer files?  Hmm, by my
reading, that wouldn't happen unless we specified --delete to rsync.

So this may be a good scheme.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]