xterm entries do appear in "w" under startx

it's an option, look in edit->current profile. xterm should be consistent 
I'll agree. I believe the right default is not to update utmp/wtmp when 
opening a new terminal (and this is consistent with us running bash as a login
shell in the Xsession script).

Reassigning to XFree to toggle the xterm default.

Hmm, I think you misunderstood Havoc. It does set utmp/wtmp entries with run
login shell and Update utmp/wtmp checked if running X through gdm. I want it to
do the same with startx. I like to see the entries for terminal windows. In gdm
it only makes one utmp/wtmp entry for my four gnome-terminals even if I disable
factory. Personally I would prefer it made an entry for each terminal window.

Non login shells are subshells, however they are invoked, and should not
show up in utmp/wtmp.  Only true login shells should show up.

I make no claim as to wether or not there is a problem or not with xterm,
however we do not support xterm, we only provide it for convenience.  If
there is a problem with xterm in this regard, please report it to XFree86.org
upstream and/or Thomas Dickey the xterm maintainer.  If they believe
that xterm needs fixing, they'll do so, and we'll pick up the changes
during the next XFree86 release (4.3.0).

Here is how it is supposed to work: 

 - by default, opening a terminal window never updates utmp/wtmp
 - logging in via gdm should update utmp/wtmp because it runs
   bash as a login shell
 - logging in via startx should NOT update utmp/wtmp (because it was already 
   updated when you logged in to the console)

Basically utmp/wtmp gets updated whenever you have to log in (type your
password, etc.).

If you toggle the pref in gnome-terminal, then utmp/wtmp should update 
whenever you open a terminal. But not by default.

This is AFAIK how it currently behaves. Which part is behaving incorrectly?

I don't know what xterm currently does, but it should default to NOT updating
utmp/wtmp.

You aren't exactly clear. At first you say by default it never should. Does that
mean both in gdm and startx? Then you say if you st the preference in
gnome-terminal it should, but the preference shouldn't be the default. So the
preference have no effect in startx, but work through gdm?

startx/gdm has no relationship to what the terminal should do. The terminal
should never update utmp/wtmp, because it's assumed that you logged in on the
console then used startx, or logged in via gdm. Either way, you already logged in. 
So the terminal should not record an additional login.

Talking to you is like talking to a wall. You still haven't answered my
questions and seem to be ignoring the bug.

Well if you want to be rude about it, I won't bother to try and help. I've done
my best to explain my view on the matter and how I think it currently works. I
don't understand what questions remain for you; maybe try rephrasing your questions.

I do not think the behavior of the terminal app should be different for gdm vs.
startx. AFAIK the terminal defaults to the behavior which is correct for both, 
which is to NOT log to utmp/wtmp. What is the bug? What are you saying does not
work?

The bug title is "terminal does not register with w when using startx" - it is
not supposed to register with w, as I've explained. You can toggle a preference
if you want it to register. Are you arguing that it should register with w by
default? If so you will have to present an argument to that effect.
Are you saying the preference doesn't work? If so that's a bug, but 
has nothing to do with startx.

Indeed.  utmp/wtmp are for registering logins.  A login being either
initiated via gdm/xdm/kdm, ssh/telnet, local console login, or invoking
a login manually.

A terminal shell such as xterm, et al. being ran from inside an X session,
wether that X session was initiated by "startx" or by gdm/kdm/xdm does not
matter.  The login process is what gets logged to utmp/wtmp, not the
creation of a subshell.

I really do not see what the problem is here other than end user
misunderstanding of how utmp/wtmp semantics are supposed to work, and
wanting them to work some other way than they are designed and intended
to work.

Unless I'm presented with a real world bug, which I agree is a real world
bug, discussing it in any manner rude or otherwise is pointless.

Please contact the XFree86 team if you think xterm is buggy and should
be modified to do something it does not do right now.

Can we put this dead horse to rest now?

I could modify the %files list in XFree86.spec to solve the problem
another way perhaps:

# Unsupported software, now disabled
#%{_x11bindir}/xterm

yes, the preference doesn't work in startx, that is The Bug, but it does in gdm.
I would have thought it was clear that was what I was trying to say already. I
understand that it isn't supposed to work the way I want by default. But it is
supposed to be an option via the preference and they preference doesn't work in
a certain situtation, startx.

Oh, no, I did not understand what you were trying to say. You are saying the
preference doesn't do anything. Sorry about that.

Reassigning to hp for gdm preference thingie

utmp is also there for keeping track of live terminals. If it doesn't work, then
talk requests, finger, etc all stop working.

Despite having configured gnome-terminal months ago to always update wtmp/utmp,
it seems to have forgotten this configuration on upgrading. I've turned on the
'Run command as a login shell' and 'update utmp/wtmp records when command is
launched' preferences, exited gnome-terminal completely and restarted it, but
it's still not updating utmp and wtmp as requested. 

I logged in with gdm, if it's relevant; which I suspect it's not.

*** Bug 75408 has been marked as a duplicate of this bug. ***

I'm pretty sure utmp/wtmp are working (and that gnome-terminal has the right
defaults for this now) but if not we should notice prior to release.

Should be fixed now.

Sorry, yes -- it's fixed in Phoebe.