> To: Mike Long <mike.long@analog.com>
 > cc: kenh@cmf.nrl.navy.mil, current-users@NetBSD.ORG
 > Subject: Re: sup-server brokenness... 
 > From: "Michael L. VanLoon -- HeadCandy.com" <michaelv@HeadCandy.com>
 > 
 > As far as I know, *official* mirrors have always had unrestricted
 > access through a different (confidential) sup port.  They don't
 > compete with users for connections.  We certainly did at
 > ftp.iastate.edu (but we only mirrored, we didn't serve sup
 > connections).  Sup mirrors should be up to date by now if they were
 > configured correctly to begin with.

Some things:

1) could someone post a list of official mirrors which offer sup
   access, preferrably with indication of whether they currently
   are up-to-date.

2) that in addition to the collections we already have, these be
   added:  bin, sbin, usr.bin, usr.sbin, lib, libexec, share,
   covering these directories under src, and miscsrc covering the
   rest (distrib, etc, regress).  That way I wouldn't have to
   sup down the 'src' collection, which is near-impossible to get
   without something crashing midway.  I have had this type
   of problem almost every time I had to get the full src package
   (now it was SUP: Invalid message count -1 midway through),
   also before the current rush of problems.

3) That after the 1.1 release is out, that 'core' take a brain-
   storming about replacing sup with something else.  These are
   the problems I see with sup:

   a) When sup'ing from the master, there is no indication of
   when the database was completely updated last, or what
   sub-collections exist, or what their configuration files are.
   b) When sup'ing from a mirror, there is no indication of
   when the slave was updated.  Really we want to get the
   latest timestamp from the master (the one that doesn't exist in
   paragraph a) above) which was last successfully transferred to
   the slave.
   c) There's no easy way to maintain the same collections on
   mirrors as on the master (well it could be done, by ftp-ing
   the configuration files and running some script on them).
   I do this manually for the moment.

SUP has worked mostly OK for me, so don't take this as a flame,
just suggestions.
If the master sup site is fast and reliable, these issues
aren't so pressing, but once it is down for a while things
get ugly, with lots of people wanting to sup at the same time
from the master.

For those who are in Scandinavia (or for that sake elsewhere)
and need a sup mirror you are free to use ours, but - alas - it is
yet not updated with the src package.
Here's a supfile sample for sup'ing from our mirror:

current-mirror release=ksrc-common     host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=ksrc-i386       host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=src             host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=doc             host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=othersrc        host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=games           host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=gnu             host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror

This should have the same release= possibilites as sup.netbsd.org
except for domestic, and is maintained via cron.

Your friendly Norwegian NetBSD fan,

  -  Arne H. J.