[124] in bug-owl
owl on NetBSD
daemon@ATHENA.MIT.EDU (gschmidt@surcease-of-sorrow.renega)
Mon Feb 3 21:21:42 2003
From: gschmidt@surcease-of-sorrow.renegadebiology.com
Date: Mon, 3 Feb 2003 21:22:13 -0500
To: bug-owl@mit.edu
Message-ID: <20030204022213.GC5026@surcease-of-sorrow.renegadebiology.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
You might be interested to know that I have successfully compiled owl
(out of cvs in the ktools locker) under i386 NetBSD, with the kth
Kerberos that's in the NetBSD distribution. I'm far from an owl power
user, but everything I've tried works so far, including zcrypt
decryption.
The compilation was fairly uneventful. There were a lot of include
path and library name mixups, which I hacked around by putting all of
the relevant Kerberos and crypto libraries in LDFLAGS. Also the
prototype of des_ecb_encrypt in zcrypt.h didn't match mine; commenting
it out restored universal love. All in all, a few configure.in tweaks
should be all that's necessary for a clean compile on this platform.
I did tickle one non-owl bug. Running owl inside screen inside an
xterm, with (at least?) the screen session running on a NetBSD host,
owl will draw the status bar with line-drawing characters instead of
dashes, but due to apparent termcap confusion, the curses library
linked by screen will redraw the status line incorrectly when
redrawing the screen session, for example after typing C-a n C-a p.
Specifically, it won't generate a closing ^O to leave line-drawing
mode after finishing the status line, meaning that the terminal is
left in line-drawing mode and the user sees garbage instead of zephyrs
until the next time owl (as opposed to screen) redraws the status
line. Even more specifically, curses seems to think that ^]]m will
turn off both reverse video and line drawing mode, while xterm thinks
that it does only the former. This isn't an owl bug -- it happens
anytime xterm and screen try to collaborate to deal with inverse video
line drawing characters -- but users of NetBSD under owl are likely to
encounter it.
Packaging owl for NetBSD might be interesting and seems like it'd be
relatively straightforward. I'm game to help if you like, and I know
at least one NetBSD developer.
Thanks for the software,
geoff
