I've been tracking -current for a few years now, and find that
typically it is actually pretty stable. The two items that will
cause trouble are documentation problems, and a kernel/userland
change that I miss.
I have a system dedicated to building a SNAP everyday at
2am EST (11pm PST). I would be more than happy to set this job
up to mail out the last 100 lines of the build log. As an example
of successful builds for Sept, I have the following :
drwxr-xr-x 20 root wheel 1024 Sep 8 15:13 4.0-19990908-SNAP
drwxr-xr-x 20 root wheel 1024 Sep 10 12:13 4.0-19990910-SNAP
drwxr-xr-x 20 root wheel 1024 Sep 12 18:22 4.0-19990912-SNAP
drwxr-xr-x 21 root wheel 1024 Sep 14 11:44 4.0-19990914-SNAP
drwxr-xr-x 20 root wheel 1024 Sep 16 06:40 4.0-19990916-SNAP
drwxr-xr-x 20 root wheel 1024 Sep 17 06:05 4.0-19990917-SNAP
drwxr-xr-x 20 root wheel 1024 Sep 18 06:16 4.0-19990918-SNAP
drwxr-xr-x 20 root wheel 1024 Sep 22 16:30 4.0-19990922-SNAP
drwxr-xr-x 20 root wheel 1024 Sep 24 06:58 4.0-19990924-SNAP
drwxr-xr-x 20 root wheel 1024 Sep 27 07:06 4.0-19990927-SNAP
Unfortunately, I have no way of making these SNAPs publicly
available due to the firewall I live behind. If someone can
allocate the space, I can ftp the SNAP out. The above SNAPs have
no local mods in them. Local mods are kept on a seperate system
and applied at installation time.
Let me know if this would help resolve some of the questions
you might have.
The tail of the log file for 0927 (with NODOC=YES) is attached
below.
-John
touch release.4
Making fixit floppy.
disklabel: ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders per group to 6.
Warning: 2432 sector(s) in last cylinder unallocated
/dev/rvn0c: 5760 sectors in 2 cylinders of 1 tracks, 4096 sectors
2.8MB in 1 cyl groups (6 c/g, 12.00MB/g, 1472 i/g)
super-block backups (for fsck -b #) at:
32
1921 blocks
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/vn0c 2667 984 1470 40% 631 839 43% /mnt
>>> Filesystem is 2880 K, 1470 left
>>> 2000 bytes/inode, 839 left
touch release.9
0 blocks
Setting up CDROM distribution area
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
Setting up FTP distribution area
0 blocks
0 blocks
Release done
+ echo make release Finished
make release Finished
---> make world ran 264 min 1 sec
---> Mon Sep 27 07:00:00 EDT 1999 - Creating /pub/FreeBSD/4.0-19990927-SNAP
---> Mon Sep 27 07:06:36 EDT 1999 - build of 4.0-19990927-SNAP was a success.
---> make world/release ran 271 min 0 sec
> Bill Paul wrote:
> >
> > I realize this is -current and all and mistakes happen, but make
> > release basically constitutes a 'full build' of FreeBSD and if it
> > doesn't work, especially for a whole week, it looks kinda bad.
>
> Does it? I thought -current wasn't supposed to work at all, except
> by accident, and anyone actually using a functional current ought to
> say their prayers before login in.
>
> > Unfortunately, when the snapshots on current.freebsd.org fall over,
> > nobody knows exactly what causes the problem except Jordan, and he
> > keeps gnawing through his limbs to excape the traps I set for him.
>
> Yeah, that he does. :-)
>
> > When somebody breaks the build at M$, the offender is made to wear
> > a viking hat. I would suggest a similar punishment for those who
> > break our own build, except that I suspect many of you are wearing
> > viking hats already.
>
> Alas, I think it would be a bad idea. Some people my interpret this
> as "gets to wear a viking hat", ie, in a positive way. :-)
>
> - --
> Daniel C. Sobral (8-DCS)
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> Rule 69: Do unto other's code as you'd have it do unto yours
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
> ------------------------------
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
