[380] in NetBSD-Development
Problems with /afs/sipb/project/sipb-athena
daemon@ATHENA.MIT.EDU (jhawk@MIT.EDU)
Fri Jan 13 05:39:15 1995
From: jhawk@MIT.EDU
Date: Fri, 13 Jan 95 05:38:44 -0500
To: netbsd-dev@MIT.EDU
Cc: svalente@MIT.EDU
As I've mentioned previously to some of you, I'm some what unhappy
with the lack of a single, complete, source tree for all of the Athena
stuff that has been ported to NetBSD (and Linux). Some of you are
quick to point out that this is what /afs/sipb/project/sipb-athena is
for, though it doesn't seem to be used very well.
This morning I went through those packages mentioned in the README
(that means I skipped jot, login, movemail, olh, and write),
and attempted to build them all. Some of them worked without any
problems, but a significant number had some problem. This is unfortunate
(we should and must have a current build tree that is useful).
I attempted to make a rudimentary top-level makefile in /afs/sipb/project/
sipb-athena/0NetBSD. In that directory there is also a file called
Problems, which repeats some of what I'm about to say, but also
contains non-critical problem information, so it may be worth reading.
The following programs are claimed to exist by the README, but now
do not:
afs-nfs
attach
from
lpr
reactivate
sendmail
tex
xcluster [included w/ dash]
xdm
The following programs do not build cleanly per the directions,
for the specified reason:
* kerberos make depend fails in lib/krb
* moira make fails w/ ``can't cd to util/et''
* mh mhconfig fails
* olc olcd.c won't compile (built-in fuction `sin'
declared as non-function...)
telnet Fails to recognize ^M in line mode.
* zephyr Imake template errors
So anyway, those of you responsible for these packages should
make sure that you fix things up so that these programs _work_.
They should all build cleanly with a minimum of fuss.
Also:
Where do imake and xmkmf come from? Is the user expected
to build them first? ?? How do Yoav's changes affect this?
I will be tackling /afs/sipb/project/netbsd/dev/athena next,
and will make some effort to bring it into line with /afs/sipb/project/
sipb-athena, if at all possible. At some point after that I'll actually
try to deal with the problems, but hopefully the perpetrators will have
fixed them, first :-)
It also seems disturbing that the original location of these source
files is not documented (dev cell, <foo>dev locker, whatever), nor
are context diffs included. This means that when the next version of,
say, hesiod, comes out, it will not be clear just what changes were
necessary to support it.
Use the SOURCE, Luke!
--jhawk But it's BROKEN, Ben!
SHOOT THE PROGRAMMER!
