DCC version 1.3.103/2.3.103 released

[Vernon Schryver]

Version 1.3.103 of the DCC source is in
http://www.dcc-servers.net/dcc/source/dcc.tar.Z  and
http://www.rhyolite.com/dcc/source/dcc.tar.Z

Commercial version 2.3.103 of the DCC Reputation code is in the usual place.

The CHANGES file starts with
    Quiet RedHat versus Debian error message from rcDCC reported by Ken Rea.
    Deal with corrupt /var/dcc/map reported by Steve Martin instead of
        calling abort().
    Fix error in libexec/fetch-testmsg-whitelist reported by Horst Scheuermann
        and William Taylor.
    Tweak ./configure and makefiles to try to avoid the mysterious,
        unreproducable linking problem reported by John Levine.
    Fix bug with `./configure --with-max-log-size=0` reported by
        Valentin Schmid.
    `./configure --with-max-log-size=KB` now also applies to dccproc log files.
    Generate man pages with /var/dcc and other directories replaced by
        local ./configure choices.  This is intended to help the FreeBSD
        package and similar redistributions.


/var/dcc/libexec/updatedcc should automagically fetch, build, and
install the commercial or free version, depending on the .updatedcc_pfile
file, unless you have installed a version of Linux with the broken
default `sort` collating sequence since last upgrading.  If so, an
easy way to get the old updatedcc script working is to delete the
entire /var/dcc/build/dcc directory before running updatedcc.


Vernon Schryver    vjs@...
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

[Petar Bogdanovic-6]

On Thu, Feb 26, 2009 at 03:08:00AM +0000, Vernon Schryver wrote:
>
>     Generate man pages with /var/dcc and other directories replaced by
> local ./configure choices.  This is intended to help the FreeBSD
> package and similar redistributions.


Minor inconsistency:

--- configure.orig      2009-02-26 09:11:12.000000000 +0100
+++ configure   2009-02-26 09:11:57.000000000 +0100
@@ -3471,8 +3471,8 @@
     NetBSD)
        # default to /usr/local/man/man8 and use nroff files, possibly
        #   compressed via /usr/share/mk on versions well after 1.4.2.
-       mancat=cat
-       MAN8='dcc.0 $(SUBDIR_MAN0)'
+       mancat=man
+       MAN8='dcc.8 $(SUBDIR_MAN8)'
        MAN8INST=''
        # force NetBSD to install the man pages
        USE_DCCMANINSTALL='install maninstall: dccmaninstall'
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

[Vernon Schryver]

> From: Petar Bogdanovic

> Minor inconsistency:
>
> --- configure.orig      2009-02-26 09:11:12.000000000 +0100
> +++ configure   2009-02-26 09:11:57.000000000 +0100
> @@ -3471,8 +3471,8 @@
>      NetBSD)
>         # default to /usr/local/man/man8 and use nroff files, possibly
>         #   compressed via /usr/share/mk on versions well after 1.4.2.
> -       mancat=cat
> -       MAN8='dcc.0 $(SUBDIR_MAN0)'
> +       mancat=man
> +       MAN8='dcc.8 $(SUBDIR_MAN8)'
>         MAN8INST=''
>         # force NetBSD to install the man pages
>         USE_DCCMANINSTALL='install maninstall: dccmaninstall'

I fetched a current version of NetBSD, and found that it still wants
.0 instead of .8 man pages to avoid running groff on every `man` command.
It also seems that
   - bsd.man.mk is not included by including bsd.subdir.mk
   - it wants the list of man pages in $(MAN) instead of $(MAN8) or $(MAN0)
   - my efforts to try to use the NetBSD bsd.man.mk led it to
      /usr/local/man/man/man8, which didn't work at all.
   - I never did manage to get it to use or want compressed man pages.

So I think the best solution is change the comment.  That's certainly
a smaller change.  I think it's more likely to continue working.


Vernon Schryver    vjs@...


P.S. Why delete .c files when `make` is interrupted?  Since I was just
  installing tarballs, that did me no harm.  If I were writing new code,
  I would have feed all available NetBSD CDROMs to a shredder and then
  burned the bits.  (I didn't investigate.  It's probably a /usr/share/mk
  rule that makes *.c depend on something.)

P.P.S. Why does NetBSD still want to build lint libraries by default?
  Who has needed lint in this century?  Doesn't everyone use prototypes
  and turn on sufficient compiler warnings?

P.P.P.S. Setting gcc to make warnings cause errors (NOGCCERROR) is good for
  testing, when you do not enable many warnings, or you know all there
  is to know about the target platform and so know there will be no
  warnings.  It is an unwise default.
   
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

[Petar Bogdanovic-6]

On Sat, Feb 28, 2009 at 04:45:28PM +0000, Vernon Schryver wrote:

> > From: Petar Bogdanovic
>
> > Minor inconsistency:
> >
> > --- configure.orig      2009-02-26 09:11:12.000000000 +0100
> > +++ configure   2009-02-26 09:11:57.000000000 +0100
> > @@ -3471,8 +3471,8 @@
> >      NetBSD)
> >         # default to /usr/local/man/man8 and use nroff files, possibly
> >         #   compressed via /usr/share/mk on versions well after 1.4.2.
> > -       mancat=cat
> > -       MAN8='dcc.0 $(SUBDIR_MAN0)'
> > +       mancat=man
> > +       MAN8='dcc.8 $(SUBDIR_MAN8)'
> >         MAN8INST=''
> >         # force NetBSD to install the man pages
> >         USE_DCCMANINSTALL='install maninstall: dccmaninstall'
>
> I fetched a current version of NetBSD, and found that it still wants
> .0 instead of .8 man pages to avoid running groff on every `man` command.

I am unable to reproduce that problem. After applying the patch above
and doing `./configure --mandir=/usr/pkg/man && make install' in a
pretty clean NetBSD chroot, I get this:

        /usr/pkg/man/man8/dcc.8
        /usr/pkg/man/man8/cdcc.8
        /usr/pkg/man/man8/dbclean.8
        /usr/pkg/man/man8/dccd.8
        /usr/pkg/man/man8/dblist.8
        /usr/pkg/man/man8/dccm.8
        /usr/pkg/man/man8/dccifd.8
        /usr/pkg/man/man8/dccproc.8
        /usr/pkg/man/man8/dccsight.8


> P.S. Why delete .c files when `make` is interrupted?

When interrupting `make' in the dcc source directory?

I can't reproduce that as well:

        # find . -name '*.c' | wc -l
              76
        # make
        all ===> dcclib
        #   compile  dcclib/aop.o
        cc -O2   -I../include          -c    aop.c -o aop.o
        objcopy -x aop.o
        #   compile  dcclib/aop.so
        cc -O2   -I../include          -c    -fPIC -DPIC aop.c -o aop.so
        objcopy -x aop.so
        #   compile  dcclib/ask.o
        cc -O2   -I../include          -c    ask.c -o ask.o
        objcopy -x ask.o
        #   compile  dcclib/ask.so
        cc -O2   -I../include          -c    -fPIC -DPIC ask.c -o ask.so
        objcopy -x ask.so
        #   compile  dcclib/ck.o
        cc -O2   -I../include          -c    ck.c -o ck.o
        objcopy -x ck.o
        #   compile  dcclib/ck.so
        cc -O2   -I../include          -c    -fPIC -DPIC ck.c -o ck.so
        objcopy -x ck.so
        #   compile  dcclib/ck2str.o
        cc -O2   -I../include          -c    ck2str.c -o ck2str.o
        objcopy -x ck2str.o
        #   compile  dcclib/ck2str.so
        cc -O2   -I../include          -c    -fPIC -DPIC ck2str.c -o ck2str.so
        objcopy -x ck2str.so
        #   compile  dcclib/ckbody.o
        cc -O2   -I../include          -c    ckbody.c -o ckbody.o
        objcopy -x ckbody.o
        #   compile  dcclib/ckbody.so
        cc -O2   -I../include          -c    -fPIC -DPIC ckbody.c -o ckbody.so
        objcopy -x ckbody.so
        #   compile  dcclib/ckfuz1.o
        cc -O2   -I../include          -c    ckfuz1.c -o ckfuz1.o
        objcopy -x ckfuz1.o
        #   compile  dcclib/ckfuz1.so
        cc -O2   -I../include          -c    -fPIC -DPIC ckfuz1.c -o ckfuz1.so
        objcopy -x ckfuz1.so
        #   compile  dcclib/ckfuz2.o
        cc -O2   -I../include          -c    ckfuz2.c -o ckfuz2.o
        objcopy -x ckfuz2.o
        #   compile  dcclib/ckfuz2.so
        cc -O2   -I../include          -c    -fPIC -DPIC ckfuz2.c -o ckfuz2.so
        ^C
        # find . -name '*.c' | wc -l
              76


> P.P.S. Why does NetBSD still want to build lint libraries by default?

When does that happen?



   Petar Bogdanovic



_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

[Vernon Schryver]

> > I fetched a current version of NetBSD, and found that it still wants
> > .0 instead of .8 man pages to avoid running groff on every `man` command.

> I am unable to reproduce that problem. After applying the patch above
> and doing `./configure --mandir=/usr/pkg/man && make install' in a
> pretty clean NetBSD chroot, I get this:
>
> /usr/pkg/man/man8/dcc.8
> /usr/pkg/man/man8/cdcc.8
> /usr/pkg/man/man8/dbclean.8
> /usr/pkg/man/man8/dccd.8
> /usr/pkg/man/man8/dblist.8
> /usr/pkg/man/man8/dccm.8
> /usr/pkg/man/man8/dccifd.8
> /usr/pkg/man/man8/dccproc.8
> /usr/pkg/man/man8/dccsight.8

There are two parts to that problem.  One is whether NetBSD needs the
special "install:maninstall" dependency and the odd dccmaninstall rule
for installing man pages.  I prefer to use whatever the target system
prefers.  If I remove the man page installation rules from Makefile.inc2,
`make manistall` doesn't work.

The second part is that the man command use `groff` to generate
text files from .8 files every time `man dcc` is run.  That is the
pause while it says "man: Formatting manual page..."


> > P.S. Why delete .c files when `make` is interrupted?
>
> When interrupting `make' in the dcc source directory?

Yes, I think it was `make install`

> I can't reproduce that as well:

I saw it only once, which was too many.  That one time it emptied
the dcclib directory of all except 4 .c files.  It could be a rule
that makes .c files the results of something.  `make` historically
deleted generated files at a failure including a single unless they
were in marked .PRECIOUS or something.  I don't see anything with
`make -dg1`, but that doesn't mean anything.  Maybe it somehow
decided to make the purge target as part of stopping the `make`.
All I know is that I interrupted `make` and found lots of .c files gone.


> > P.P.S. Why does NetBSD still want to build lint libraries by default?
>
> When does that happen?

When the "NOLINT" line in Makefile.inc is removed:


Vernon Schryver    vjs@...
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc