Long awaited round 1 of NeXT patches.

[Andre Lucas]

Noted, thanks. That's amazing, now the only field that can be relied on
to be in struct utmp is ut_line. Anyone want to kill that too? ;-) I'm
sure some OS can store it as device numbers, just to wind people up.

What's your theory on the NeXT utmp failures? I'm looking to do a new
release of liblogin tonight (the ut_name fixes will be in) and fresh
openssh patches for 1.2.2. If you're still having utmp trouble, you
might want to run it up and send me the output from testlogin -v (as
root).

Is there any chance you can send me any of the following:

- utmp.h  (and any relevant files it includes)
- if they exist, utmpx.h, lastlog.h, paths.h and any dependencies

Ta,
-Andre

Ben Lindstrom wrote:
> 
> This is about 90% of the core work.  I omited a few files from the patch
> set since they are basicly small blocks of #ifndef HAVE_NEXT/#endif to
> get it to compile.
> 
> Daimen, feel free to let me know what you applied and what your
> rejecting and why.. so I can work on cleaning things up.
> 
> Andre, Only thing of note you may want to look into is NeXT does not
> use  "ut_user" in it's lastlog.  It uses "ut_name"  and it does not
> have a "ut_type" (It's part of the above patch in the login.c
> part).
> 
> BTW, this patch is against 1.2.2 (since it was released before I was
> able to relase my patch. =)
> 
> Known issues with my port (and my internal tree):
> 
> 1) lack of utmp entries.  I think I know what is wrong.
> 2) lack of signal capturing in readpass.c (I omited this from
>         the patch) due to lack of sigaddset, sigemtyset, and
>         sigprocmask functions outside of using libposix.
> 3) lost of warning.  Most are ignorable.
> 4) Current patch *IS NOT* complete enough to support out of box
>         next compiling.
> 
> But it works against 1.2.2x ssh both client/server and works with
> itself.  So it's progress.
> 
8<!-- patch omitted -- 8<