On Sun, 7 Dec 2003, j wehrli wrote:
> Brian Chase wrote:

> I have extra vaxen currently powered off. I have IDLE; 2 VaxStation
> 3100/72 32MB MEM and 3 VaxStation 4000/90 32MB MEM.

Ooh, VS4000/90s, nice.

> What should I setup to help? I think they have NetNSD 1.6 on them
> currently as I try to track release best I can.
>
> Is 1.6 the right version to set up a native built box that tracks
> -current? I have 384/128 DSL with 5 static IPs and a 60GB NetBSD
> fileserver that can spare 10 or 20 GB for the VAXEN effort. I would be
> willing to buy another if needed and it helps keep NetBSD working on
> VAX.

I'd recommend against building -current from any of the 1.6 releases.
(Not to be confused with the 1.6[A-Z] names under -current which lead
the way to the 2.0 release).  The first step is to get a working
-current snapshot for VAX available on the NetBSD site.  There are a
number of fixes and enhancements in -current that should make the build
process easier.  So once we get a snapshot available, it should be
simple for people to track and compile -current on their own.

You've got plenty of bandwidth for the task.  It's actually pretty easy
to keep your sources updated with only a 56kb/s dialup, but that initial
cvs checkout sure is painful.  In terms of space, the full -current
source tree is taking up around 670MB on my disk for a single copy.
Once you start compiling things, it gets up around the 1GB range.

If you aren't already familiar with it, see the following details on
using NetBSD's anoncvs server to track -current:
http://www.netbsd.org/Documentation/current/#using-anoncvs

With checkout and updates, I'd suggest running them on your fileserver
if it's a fairly fast system.  I do this to make sure that things move
as quickly as possible.  And I also use the built-in compression
supported for cvs, (i.e. something like "cvs -z7 update -dP").  This
puts an extra computational load on the cvs repository server, but since
it cuts my transfers times in half, I figure I'm conserving their
bandwidth.

> I figure I would set up a native build box and then perhaps second box
> to boot and run your regression tests. I have little knowledge of the
> testing setup NetBSD kernel uses. Please advise on a setup preference. I
> prefer to leave only one VAX server on 7/24 since I already have several
> PC and servers running and have a small house with 100A power. On the
> plus side winter is here and the basement could use the heat :)

If you want to put up one of your VS4000/90A systems, that'd be great,
as long as you're comfortable with doing that sort of thing.  I know
some ISPs don't allow and actively work to prevent their customers from
running services on their home systems; but maybe that's not your
situation since you've got five static IPs.  Letting strangers in on
your home network with root access, even on a single machine, is a bit
risky unless a) you don't care, or b) your trust level of the users
corresponds appropriately to your ability to secure your network and
systems.

> I suppose after that I could look into a pkgsrc builder. It seems that
> even native binaries for NETBSD releases is lacking let alone for
> current packages. Lots of compile cycles for that I am sure.

Fast boxes will definitely help with the pkgsrc cause.  I think the 2.0
release is still far enough away that we don't need to worry about the
packages /just/ yet, unless you want to tackle them for the impending
1.6.2 release.

> I have
> limited skills to diagnose kernel or package problems but I do not mind
> donating electric power and vax cycle for NetBSD. I would not mind
> allowing NetBSD/Vax folks to SSH in to view/adjust things and perform
> regressions.

I'm no expert in this myself, but one of the best ways to learn is to
dive in and see what breaks.  You can start by reading what's at that
link I mentioned about, and then checking out a copy of -current.

As of yet, I've not been able to properly build the installation sets.
The build dies with inconsistencies in the "checkflist" phase of the
make.  I think this might be due to the VAX port still using gcc 2.95.x
instead of gcc 3.x.  Tonight I'll upload a tarball of my most recent
build results, and I'll write up some instructions for manually
installing them.

-brian.