[806] in athena10
Re: Changes to debathena-gdm-config
daemon@ATHENA.MIT.EDU (Anders Kaseorg)
Fri Jan 9 16:23:25 2009
Date: Fri, 9 Jan 2009 16:22:55 -0500 (EST)
From: Anders Kaseorg <andersk@MIT.EDU>
To: athena10@mit.edu
In-Reply-To: <2C5DD76A-4A85-4CD3-AC56-82C1449F5EAD@mit.edu>
Message-ID: <alpine.DEB.2.00.0901091621440.11108@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1257098496-1419104217-1231536175=:11108"
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---1257098496-1419104217-1231536175=:11108
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Here is a log of our Zephyr conversation today.
debathena / xsession / wdc 11:17 (rubber_ducky.sysdaemon)
So conversations have finally started on the Athena 10 list about
the X session, but I feel we are no closer to consensus on what to d=
o
to remedy the problems I have reported.
debathena / xsession / wdc 11:19 (rubber_ducky.sysdaemon)
In a related note, Athena Release team has agreed that desupporting
WINDOW_MANAGER is the right thing, but implicit in that is that we'l=
l
instruct users to create their own .xsession file to specify session=
,
and window manager. We are apparently not yet all agreed that a use=
r
generated .xsession will work, or is the right approach.
debathena / xsession / geofft 11:20 (Our Slogan : Vulnerability Is Pos=
sible !!!)
I have a suspicion that there are two types of sessions - one that
call session managers like gnome-session, and one that calls window
managers themselves, and that only one of them is problematic.
debathena / xsession / quentin 11:24 (Quentin Smith)
wdc: I think I missed something. I know you reported problems, but I
didn't actually see a description of the problems you had.
debathena / xsession / quentin 11:24 (Quentin Smith)
(other than the user confusion, which was already responded to on th=
e
list)
debathena / xsession / wdc 11:29 (rubber_ducky.sysdaemon)
Can you see what's in MIT Jira?
The most detailed analysis I made is there at:
https://jira.mit.edu/jira/browse/ATN-1
I apologize for not doing it in the debathena trac, but ended up
creating an issue tracker for Athena 10 distinct from debathena.
This was the first issue I really worked there because it seemed
most relevant to cluster Athena 10 systems, and least relevant to
debathena.
debathena / xsession / geofft 11:33 (Our Slogan : Vulnerability Is Pos=
sible !!!)
I'd be okay putting this _just_ in the Athena 10 cluster config, but
I suspect this doesn't fully address Anders' concerns about staying
close to upstream.
debathena / xsession / geofft 11:36 (Our Slogan : Vulnerability Is Pos=
sible !!!)
I'm heading afk for most of the rest of the day.
debathena / xsession / andersk 13:06 (Anders Kaseorg)
wdc: I still don=E2=80=99t think there is a clear explanation of exa=
ctly what
the problems are.
debathena / xsession / andersk 13:07 (Anders Kaseorg)
You have described that there may vaguely be some confusion related
to the presence of different options, but nobody has described what
actual problems this confusion leads to.
debathena / xsession / andersk 13:07 (Anders Kaseorg)
The presence of multiple options is not, in itself, a bug.
debathena / xsession / andersk 13:09 (Anders Kaseorg)
If one of these options leads to certain doom for the unsuspecting
user, then we should fix that option, not remove it.
debathena / xsession / andersk 13:10 (Anders Kaseorg)
Does this make sense?
debathena / xsession / wdc 14:17 (rubber_ducky.sysdaemon)
andersk: Does the stuff in https://jira.mit.edu/jira/browse/ATN-1
provide a rich enuf sense of the problem, or am I still not making s=
ense.
Perhaps to summarize:
There is no indication to someone seeing the list of sessions for th=
e first time
that choosing one of the Failsave options needs NOT be undone by cho=
osing
one of the other options. From that starting point, someone who kno=
ws
"Gee we use GNOME" causes them to pick the GNOME option which isn't =
the
right option to choose. After they choose that option the GNOME stan=
dard
login session not the Athena Standard login session is what they get=
=2E
Yes, changing from "run X Client" session to "Athena" will help.
But it is unclear if the stock Gnome session that happens to be layi=
ng
around in what's installed is actually useful. The "Secure Remote C=
onnection"
option is also what happens to be laying around. Again, it's non-to=
xic,
but it's also non-useful.
<continued next z-gram>
debathena / xsession / andersk 14:18 (Anders Kaseorg)
As ghudson pointed out, the =E2=80=9CRun X Client=E2=80=9D and =E2=
=80=9CGNOME=E2=80=9D options are
now identical, so this doesn=E2=80=99t matter.
debathena / xsession / wdc 14:18 (rubber_ducky.sysdaemon)
Good design means pruning away superfluous choice.
What we have now is bad design. It is more glaring a bad design
because the crufty session options that nobody uses are not sitting =
in
an obscure menu hanging off a button nobody presses like in the stoc=
k
Ubuntu greeter. The cruft is now first-class options in a button man=
y
are expected to press.
debathena / xsession / andersk 14:22 (Anders Kaseorg)
If we were designing the sessions menu from scratch, then I might
agree with you. (There are some additional details that necessitate
these different options under some circumstances, though.)
debathena / xsession / andersk 14:22 (Anders Kaseorg)
However, that is not our job.
debathena / xsession / andersk 14:23 (Anders Kaseorg)
If you think that the sessions menu is poorly designed, you should
file an Ubuntu bug report.
debathena / xsession / andersk 14:23 (Anders Kaseorg)
Even if there is a problem, I do not think that the design is _so_
bad that we need to take it upon ourselves to replace it.
debathena / xsession / jdreed 14:24 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Hrm, I just sent mail before I noticed we were chatting online
debathena / xsession / ghudson 14:24 (Steel and circuits will make me =
whole)
My current thinking is that (1) someone should file a bug report to
get the name "run Xclient script" changed to "System default session=
"
or something, and (2) the remaining problems are not subtantial
enough to warrant a local change.
debathena / xsession / wdc 14:24 (rubber_ducky.sysdaemon)
The usability red flag I'm waving is this:
How the session options list gets populated was pre-existing design.
When we chose to implement the Athena greeter interfacing trivially
to that method, we populated very visible menus with superfluous,
and difficult to understand options.
I agree that its not our job to re-design how the sessions menu gets=
populated
per se, but our greeter design has optimized us into a bad place. C=
an
we improve on where we've landed?
debathena / xsession / wdc 14:26 (rubber_ducky.sysdaemon)
Ghudson: if the GNOME option is identical to the one we have crafte=
d,
can we get rid of ours?
This also begs the question: can we get rid of that useless and dist=
racting
"Secure Terminal Session" that is discovered in the default director=
y
next to the GNOME session?
debathena / xsession / andersk 14:26 (Anders Kaseorg)
We have not crafted any of those options.
debathena / xsession / andersk 14:26 (Anders Kaseorg)
They are _all_ upstream.
debathena / xsession / ghudson 14:26 (Steel and circuits will make me =
whole)
Anders is correct.
debathena / xsession / andersk 14:27 (Anders Kaseorg)
Also, even though the Ubuntu default GDM theme hides the Session men=
u
behind another menu, the upstream GNOME GDM theme does not, IIRC.
debathena / xsession / jdreed 14:27 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I think calling this a menu "redesign" is a poor choice of words. W=
e're
essentially commenting out a few broken session options that don't w=
ork
in our environment. It takes like 2 seconds to re-enable them, it's
not like we're deleting the files or packages.
debathena / xsession / andersk 14:29 (Anders Kaseorg)
None of the options are broken in our environment (with the possible
exception of Secure Remote Connection?).
debathena / xsession / jdreed 14:29 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Secure Remote Connection is the one I was thinking of.
And what about the "Failsafe" ones. Do they actually mean "don't ru=
n my
dotfiles" now? because they didn't, for a while
debathena / xsession / andersk 14:29 (Anders Kaseorg)
And if Secure Remote Connection is broken, I find it unlikely that
our environment is responsible for breaking it. We should
investigate.
debathena / xsession / wdc 14:30 (rubber_ducky.sysdaemon)
Secure Remote Connection is not "broken" per se.
For the 4 systems on campus that offer you a Sun X terminal session,
it will dutifully negotiate a connection and let you begin
the process of logging in.
debathena / xsession / jdreed 14:30 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Bill: Wait, what? Secure Remote Connection is ssh, not XDMCP
debathena / xsession / wdc 14:32 (rubber_ducky.sysdaemon)
Perhaps I'm mistaken. I thought it was XDMCP.
debathena / xsession / jdreed 14:32 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
There is an XDMCP login option, but it's elsewhere
debathena / xsession / jdreed 14:34 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
"Secure Remote Connection" appears to only work with stock Ubuntu ma=
chines.
I cannot use it to ssh into Athena or OS X, for example. That is br=
oken.
debathena / xsession / andersk 14:34 (Anders Kaseorg)
Okay. That=E2=80=99s a bug, then.
debathena / xsession / jdreed 14:34 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I understand and agree with the philosophy of "If it's a bug, report=
it
upstream.", but that does not necessarily imply "If it's not a bug, =
suck it up."
debathena / xsession / wdc 14:36 (rubber_ducky.sysdaemon)
I just read /usr/lib/gdm/gdm-ssh-session
I was mistaken and it is ssh, not XGMCP, sorry.
However, it wants to run /etc/X11/Xsession on the remote side.
I'm not sure that's the right thing for it to be wanting to do
in a general case.
debathena / xsession / andersk 14:36 (Anders Kaseorg)
If it=E2=80=99s not a bug, there=E2=80=99s nothing to suck up. The =
previous
discussion seemed to be running with the assumption that the =E2=80=
=9CGNOME=E2=80=9D
option just plain didn=E2=80=99t work. This is not the case.
debathena / xsession / andersk 14:37 (Anders Kaseorg)
If there is a usability bug, that is a different argument.
debathena / xsession / jdreed 14:37 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Out of curiousity, are wdc and I the only people who run -workstatio=
n as
their primary machine. Because we're the only people who seem to ru=
n into
these things.
debathena / xsession / andersk 14:37 (Anders Kaseorg)
The SIPB office has several Debathena workstations.
debathena / xsession / wdc 14:38 (rubber_ducky.sysdaemon)
We may have gotten into this "bug/not-bug" discussion because my
concern that we have a usability problem kept getting replied to wit=
h,
"That's not a bug." "Yes it is." "No it isn't." (see Argument Clin=
ic).
debathena / xsession / jdreed 14:38 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
The SIPB office has a Vax too. It just seems like everyone is using=
-standard
or -login
debathena / xsession / andersk 14:40 (Anders Kaseorg)
wdc: Well, you said, for example:
> Knowing I needed to run GNOME, I picked #2, broke things, and neve=
r
> really clued into how, "You're just supposed to know to Run Xclien=
t
> Script".
This is why I continued to press for clarification about what exactl=
y
broke.
debathena / xsession / amb 14:40 (xyloid xanthops)
I use -workstation on one of my two desktops (cithotr), but it's bro=
ken in
a whole bunch of ways due to random testing and probably wants a rei=
nstall.
I'm still not sure I'd see login problems without looking for them.
(We're going to switch part of the W92 test cluster to debathena, th=
ough.)
debathena / xsession / tabbott 14:40 (Timothy G Abbott)
I think -login without -workstation is basically only used on Linerv=
a
and some hall dialups. A lot of people's personal desktops and hall
workstations are -workstation.
Of course, it may be the case that most people don't click around on
the session types except to run a different session (e.g. I run the
"Window Maker" session on the SIPB machines)
debathena / xsession / jdreed 14:41 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I'm refering to Anders' assertion that we should not be in the busin=
ess
of disabling functionality because it's confusing or incompatible wi=
th our
environment.
debathena / xsession / tabbott 14:41 (Timothy G Abbott)
most people just type their username and password, and it works for
them.
debathena / xsession / wdc 14:41 (rubber_ducky.sysdaemon)
If I were approaching the Athena Greeter from first principles,
I would say offer only Failsafe logins and the one Athena default
we know about. Interestingly, geofft's elimination of members in th=
e
search path did precisely that.
debathena / xsession / kaduk 14:41 (very subtle joke)
Looking in from outside, it really seems like you are talking
past each other.
Whether or not something is a "bug" or "broken" is mostly independen=
t
of whether it is a configuration setting that is not appropriate
for the intended environment.
debathena / xsession / andersk 14:42 (Anders Kaseorg)
Okay, let=E2=80=99s move forward. I think we=E2=80=99ve identified =
two potential
issues.
debathena / xsession / andersk 14:42 (Anders Kaseorg)
Firstly, =E2=80=9CRun Xclient script=E2=80=9D, =E2=80=9CGNOME=E2=80=
=9D, and possibly =E2=80=9CLast session=E2=80=9D
may be mostly redundant with each other.
debathena / xsession / andersk 14:43 (Anders Kaseorg)
Secondly, =E2=80=9CSecure remote connection=E2=80=9D doesn=E2=80=99t=
work.
debathena / xsession / andersk 14:43 (Anders Kaseorg)
Is that correct?
debathena / xsession / jdreed 14:44 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Ugh, Unicode.
Yes, I believe those are correct.
debathena / xsession / wdc 14:45 (rubber_ducky.sysdaemon)
That is pretty much what I see, yes.
We also need to verify that the Failsafe options on offer actually
do something that matches Athena user expectations.
debathena / xsession / andersk 14:45 (Anders Kaseorg)
Okay. So three potential issues.
debathena / xsession / andersk 14:47 (Anders Kaseorg)
The SSH option really does seem to be broken, and is harmful because
it hangs the GDM session. I propose dealing by selectively divertin=
g
either /usr/share/xsessions/ssh.desktop or
/usr/lib/gdm/gdm-ssh-session.
debathena / xsession / andersk 14:47 (Anders Kaseorg)
Also, reporting some kind of bug upstream.
debathena / xsession / jdreed 14:47 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
3) Failsafe GNOME still runs .cshrc.mine, which it does not on Athen=
a 9.
debathena / xsession / andersk 14:49 (Anders Kaseorg)
Okay. The failsafe options need closer investigation and probably
some fixes. That would seem to be basically orthogonal to the
session directories question, because the failsafe options are not
generated from session files.
debathena / xsession / wdc 14:49 (rubber_ducky.sysdaemon)
Are you proposing to divert it until the bug is fixed?
If so then we should plan what we're going to do about the "Last Ses=
sion"
issue.
debathena / xsession / andersk 14:50 (Anders Kaseorg)
I was proposing to deal with the three issues separately. I have
proposed solutions to the second and third issues, leaving the first
issue for last because I believe it is the most controversial.
debathena / xsession / wdc 14:50 (rubber_ducky.sysdaemon)
Ah. Ok. Continue.
debathena / xsession / jdreed 14:51 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
The solutions for #2 and #3 seem fine to me. So, on to #1
debathena / xsession / tabbott 14:51 (Timothy G Abbott)
Bill: Yeah, we'd be diverting it until the bug is fixed.
debathena / xsession / jdreed 14:52 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
In addition to Secure Remote Connection not working, I believe havin=
g
"Make Default" be the default button on the session selection dialog=
is
a usability bug.
debathena / xsession / andersk 14:54 (Anders Kaseorg)
The Last Session option can be also somewhat separated from the firs=
t
issue and discussed independently of the other two redundant options=
=2E
So let=E2=80=99s do that.
debathena / xsession / andersk 14:55 (Anders Kaseorg)
Are we really going to remove a bunch of functionality just because
it pops up a clear dialog box with a non-optimal default button?
debathena / xsession / jdreed 14:56 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I didn't say remove it. We're removing it because it's broken. But=
while
we're reporting the bug about it being broken, it might be worth rep=
orting
a usability bug
debathena / xsession / andersk 14:56 (Anders Kaseorg)
The user was almost certainly using the mouse to select a session
from the list, anyway, and the default button only matters for
keyboard navigation.
debathena / xsession / andersk 14:57 (Anders Kaseorg)
It=E2=80=99s a separate issue. The dialog with the Make Default but=
ton is
shown for all sessions, not just SSH.
debathena / xsession / andersk 14:57 (Anders Kaseorg)
Or are you saying that the default on that dialog should be differen=
t
for SSH and, say, KDE?
debathena / xsession / wdc 14:58 (rubber_ducky.sysdaemon)
We could just avail ourselves of the xsesssion config option to stop=
offering
the "Last Session" option.
My problem with "Last Session" was I didn't know it didn't apply to
Failsafe options. But maybe I was exhibiting above-average clueless=
ness
to assume that any option I selected would become the default when
I saw that "Last Session" option. Thinking about it some more, I gu=
ess
I still don't understand what "Last Session" is supposed to be for.
Is it there because without it, one really MUST choose a session fro=
m
the proffered list, and it can't just highlight the last one for you
as a default?"
debathena / xsession / jdreed 14:58 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Oh, I didn't realize it was a gdm thing. That's fine. I still thin=
k it's
a usability bug, but we're keeping GDM, so it's moot
debathena / xsession / andersk 14:59 (Anders Kaseorg)
If you just log in using a username and password, you get the same
result as using the Last Session option.
debathena / xsession / wdc 15:00 (rubber_ducky.sysdaemon)
Re: Make Default: It could be that I said to myself, "What? This is=
n't
already the default?" and got myself into trouble.
debathena / xsession / andersk 15:00 (Anders Kaseorg)
But there is a clear dialog box that prompts you before making any
changes to what this result is.
debathena / xsession / andersk 15:01 (Anders Kaseorg)
This is why Last Session is preselected in the sessions menu as the
default option.
debathena / xsession / andersk 15:01 (Anders Kaseorg)
If you don=E2=80=99t make any change to the default option, you won=
=E2=80=99t affect
your session.
debathena / xsession / wdc 15:01 (rubber_ducky.sysdaemon)
If we turn off the "offer Last Session" option, what happens?
debathena / xsession / andersk 15:03 (Anders Kaseorg)
I think that will cause it to never offer to remember a change to
your session type.
debathena / xsession / andersk 15:04 (Anders Kaseorg)
I=E2=80=99m not sure whether that means that KDE users would have to=
manually
select KDE every time they want to log in.
debathena / xsession / jdreed 15:06 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Where is the "last session" data stored, anyway? The user's homedir=
?
debathena / xsession / wdc 15:06 (rubber_ducky.sysdaemon)
I'm trying to guess at what the "solution of least surprise" would b=
e.
debathena / xsession / wdc 15:06 (rubber_ducky.sysdaemon)
jdreed: I think its .dmrc in the user's home dir.
debathena / xsession / wdc 15:07 (rubber_ducky.sysdaemon)
I think it would be bad if KDE users had always to hand-select that =
option.
But how do they get KDE now? We don't offer it to them in any greet=
er option.
Wouldn't they be setting their own .xsession in their home dir?
debathena / xsession / jdreed 15:08 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
wdc: I believe installing KDE adds a session option for it. For exa=
mple,
after installing twm, I now have a "TWM" session option
debathena / xsession / andersk 15:08 (Anders Kaseorg)
We don=E2=80=99t install KDE now. If KDE was installed, it would be
available in the sessions menu next to GNOME.
debathena / xsession / wdc 15:09 (rubber_ducky.sysdaemon)
Ah. And that is an argument against lobotomizing the xsession searc=
h
path.
debathena / xsession / andersk 15:09 (Anders Kaseorg)
Right.
debathena / xsession / wdc 15:09 (rubber_ducky.sysdaemon)
In passing I'll note that I didn't know that BOTH GNOME and "Run X S=
ession"
were from upstream.
debathena / xsession / wdc 15:10 (rubber_ducky.sysdaemon)
twm becomes an X session option?
But I thought we put twm into the list of stuff now installed
by default with debathena-extras. Or was that just a "recommends".
debathena / xsession / jdreed 15:11 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I installed twm by hand on my machine
debathena / xsession / jdreed 15:11 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
and yes, TWM becomes an xsession option
debathena / xsession / ghudson 15:12 (Steel and circuits will make me =
whole)
That's interesting, insofar as I think we had plans to install a
bunch of window managers.
debathena / xsession / wdc 15:12 (rubber_ducky.sysdaemon)
My notes say tabbot checked in a change that causes
twm, mwm, wmaker, and ratpoison to be dependencies of debathena-extr=
a-software.
debathena / xsession / wdc 15:12 (rubber_ducky.sysdaemon)
s/tabbot/tabbott/
debathena / xsession / tabbott 15:12 (Timothy G Abbott)
Right, but that may not yet have been built in the Athena 10 reposit=
ories
debathena / xsession / andersk 15:12 (Anders Kaseorg)
It hasn=E2=80=99t been built in the Debathena repository at least.
debathena / xsession / jdreed 15:13 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
TWM provides /usr/share/xsessions/twm.desktop
debathena / xsession / andersk 15:15 (Anders Kaseorg)
After disabling the Last Session option, it seems the .dmrc file is
ignored, even if it was edited by hand.
debathena / xsession / tabbott 15:15 (Timothy G Abbott)
hmm. For some reason I thought broder had uploaded
debathena-extra-software 0.7 in Debathena.
debathena / xsession / broder 15:15 (Evan Broder)
I've done very few uploads lately, so that's pretty unlikely
debathena / xsession.d / andersk 15:16 (Anders Kaseorg)
We should have a script that fetches all the source packages from th=
e
repository and compares them with svn.
debathena / xsession / tabbott 15:16 (Timothy G Abbott)
well, it is clear I was wrong.
debathena / xsession.d / tabbott 15:16 (Timothy G Abbott)
isn't that what ood-packages does?
debathena / xsession.d / broder 15:16 (Evan Broder)
Yes
debathena / xsession.d / broder 15:16 (Evan Broder)
I'm looking at its output now
debathena / xsession.d / tabbott 15:16 (Timothy G Abbott)
Can we set up a cron job that runs ood-packages and emails debathena=
@
with the results?
debathena / xsession.d / tabbott 15:16 (Timothy G Abbott)
whenever there are any
debathena / xsession.d / broder 15:17 (Evan Broder)
Only if I can punt the obsolete packages from both repos first
debathena / xsession.d / tabbott 15:17 (Timothy G Abbott)
(or zephyrs the class, if we want it to be less annoying)
debathena / xsession / jdreed 15:18 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
If removing LastSession causes it to break for users who want to ins=
tall
something else (KDE), then we should keep it. I can live with that.
However, we should do something to avoid having N window managers in=
the
session window. Something that could easily be reverted by local sy=
sadmins
for example. It seems that changing the gdm search path is the eas=
iest, but
maybe there's a better way
debathena / xsession / andersk 15:19 (Anders Kaseorg)
Here=E2=80=99s the thing. Removing sessions from the GDM search pat=
h means
that you can _never_ use those sessions, even by manually editing
.dmrc.
debathena / xsession / ghudson 15:19 (Steel and circuits will make me =
whole)
What about adding sessions earlier in the search path and disabling =
them?
debathena / xsession / ghudson 15:19 (Steel and circuits will make me =
whole)
(This came up as an option in yesterday's conversation.)
debathena / xsession / andersk 15:20 (Anders Kaseorg)
.dmrc uses the same search path as the Sessions menu. So if you put
a fake session earlier in the search path with the same name, .dmrc
will point to the fake session.
debathena / xsession / jdreed 15:22 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Sure, but gdm.conf is a config file. It's designed to be edited. S=
o we
disable it as per geofft, and then create the following stock answer=
:
Q: How do I get other sessions, like KDE, GNOME, TWM, etc to show up=
in the
GDM Greeter?
A: Edit this one line in /etc/gdm.conf and reboot.
debathena / xsession / jdreed 15:22 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
/etc/gdm/gdm.conf, whatever
debathena / xsession / jdreed 15:23 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
It's not like we're hardcoding the search path in gdm.
debathena / xsession / andersk 15:24 (Anders Kaseorg)
It isn=E2=80=99t just about having those options show up in the GDM =
greeter.
If the extra sessions aren=E2=80=99t in the path, that completely pr=
events
those sessions from being used.
debathena / xsession / jdreed 15:25 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Which path? I thought geofft's changes only affected gdm.conf.debat=
hena.
debathena / xsession / andersk 15:26 (Anders Kaseorg)
geofft=E2=80=99s change to gdm.conf was to replace
SessionDesktopDir=3D/usr/share/gdm/BuiltInSessions/:/usr/share/xsess=
ions/:
/var/lib/menu-xdg/xsessions/:/etc/dm/Sessions/
with a path that only consists of one directory that we control.
debathena / xsession / andersk 15:26 (Anders Kaseorg)
This removes the alternative sessions from the menu, and also
prevents them from ever being used.
debathena / xsession / jdreed 15:26 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
So if someone wants to use them, they comment out our PATH and uncom=
ment
the default one. What's wrong with that?
debathena / xsession / andersk 15:27 (Anders Kaseorg)
Even then, they can only use that session on a machine they control.
They won=E2=80=99t be able to use it on a cluster machine.
debathena / xsession / jdreed 15:27 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
And if they use it on a cluster machine, does gdm fail miserably, or=
does it
give them the Athena session on a cluster machine? I really don't c=
are if
people can't use KDE on cluster machines, that's not what cluster ma=
chines
are for.
debathena / xsession / wdc 15:28 (rubber_ducky.sysdaemon)
To add to confusion: We were going to tell people "Write your own
.xsession file if you wanted a special window manager," by way
of de-supporting the WINDOW_MANAGER .environment variable.
debathena / xsession / jdreed 15:29 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Let's not add to confusion right now, since we've just narrowed ever=
ything
down
debathena / xsession / jdreed 15:30 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I have confirmed that if I select a session type which is not instal=
led,
I get a prompted that says "What do you want to do." One of the but=
tons is
"Just log in", and that works.
debathena / xsession / wdc 15:30 (rubber_ducky.sysdaemon)
Alas, the confusion is relevant because we're debating now whether o=
r not
it's ok for new window managers, slated to land in the Cluster confi=
g,
should show up in the session menu.
debathena / xsession / andersk 15:30 (Anders Kaseorg)
> I really don't care if people can't use KDE on cluster machines
Is this just because we don=E2=80=99t install KDE? What about Windo=
wMaker,
which we do (will?) install?
debathena / xsession / jdreed 15:31 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Then we put it in the directory which we control.
debathena / xsession / wdc 15:31 (rubber_ducky.sysdaemon)
jdreed: Sorry I don't understand that last comment by you.
debathena / xsession / jdreed 15:32 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I was responding to Anders.
debathena / xsession / andersk 15:32 (Anders Kaseorg)
So you do want the window managers that we do install to be in the
session menu?
debathena / xsession / amb 15:32 (xyloid xanthops)
Did I miss something? What new window managers are these? We added=
some to the release,
but I don't think there was any intention of putting twm, ratpoison,=
etc. into the login
menu.
debathena / xsession / jdreed 15:33 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
amb: Installing the twm package puts it in the menu, whether we inte=
nd to or not
debathena / xsession / andersk 15:34 (Anders Kaseorg)
jdreed, what exactly are you proposing, then?
debathena / xsession / andersk 15:34 (Anders Kaseorg)
I think that what you=E2=80=99ve described is the upstream default, =
which I
am arguing we should keep: all the window managers that are installe=
d
appear in the sessions menu.
debathena / xsession / jdreed 15:37 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
So, my proposal is the following:
Change gdm.conf to look like this:
#SessionDesktopDir=3D/usr/share/gdm/BuiltInSessions/:/usr/share/xses=
sions/:\
/var/lib/menu-xdg/xsessions/:/etc/dm/Sessions
SessionDesktopDir=3D/usr/share/debathena-gdm-config/sessions
Then /usr/share/debathena-gdm-config/sessions contains:
athena.desktop (provides the word "Athena" in the login menu)
terminal.desktop (provides "Terminal-only" in hte login menu)
and the failsafes.
And then we tell people who want things like KDE, TWM, etc in there =
on
their private workstations to uncomment the line in gdm.conf, and co=
mment
out our line.
debathena / xsession / jdreed 15:38 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
People who, say, have a .dmrc that refers to KDE, will get asked wha=
t to do
on the cluster workstations. I think that's fine. People may disag=
ree with
me, however.
debathena / xsession / jdreed 15:38 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
The other option I see is to keep it as is, and leave all the window=
managers
in the login menu, but then I still think we need to do something ab=
out
"Xclient" vs "GNOME", since they're the same thing.
debathena / xsession / wdc 15:40 (rubber_ducky.sysdaemon)
An alternative is to embrace what upstream is doing, but to divert
"run XClient Session" until its name changes, and let what gets inst=
alled
actually affect the menus.
debathena / xsession / jdreed 15:40 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
bill: that's pretty much what I was suggesting for "the other option=
"
debathena / xsession / andersk 15:40 (Anders Kaseorg)
The failsafe options are not session files. That is not under the
scope of this issue.
debathena / xsession / jdreed 15:41 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Right, i realized that after I sent it. Forget the failsafes then
debathena / xsession / andersk 15:41 (Anders Kaseorg)
So that means that, even though TWM is installed on the cluster
machines, a user that has manually customized their session to use
TWM will not be able to use TWM on the cluster machines.
debathena / xsession / wdc 15:41 (rubber_ducky.sysdaemon)
The problem with saying the failsafes are not in scope of what we're=
talking
about is that they're presented as if they were persistent sessions =
in
the UI we have. So we do nead to deal witn them in some way.
debathena / xsession / andersk 15:42 (Anders Kaseorg)
I did not say that we don=E2=80=99t need to deal with the failsafe o=
ptions in
some way. We do. That=C2=A0just isn=E2=80=99t what we=E2=80=99re t=
alking about right now.
debathena / xsession / wdc 15:42 (rubber_ducky.sysdaemon)
ok.
debathena / xsession / jdreed 15:43 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
anders: I don't understand why the TWM user fails in the scenario yo=
u
described
debathena / xsession / andersk 15:44 (Anders Kaseorg)
Because their .dmrc points to the twm session, and under your
proposal, the twm session is not in the path on uncustomized cluster
machines.
debathena / xsession / jdreed 15:45 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Point. OK, then, let's assume we go with the default upstream behav=
ior,
and we stick all the supported window managers in the login session.=
How
can we most non-offensively rename "Xclient script" to "Normal sessi=
on" or
something and have it at the top of the list.
debathena / xsession / wdc 15:45 (rubber_ducky.sysdaemon)
amb: Although it is a surprise to discover that installing a new
window manager adds to the list of session options, do you see how
embracing that approach has value?
debathena / xsession / andersk 15:47 (Anders Kaseorg)
(to address your second question first) It is at the top of the
list, right?
debathena / xsession / wdc 15:47 (rubber_ducky.sysdaemon)
Re: Xclient script:
Options are: divert it into the void until it gets a name we like, =
and
use GNOME.
divert it with a name we like and offer GNOME too.
Is there a chance that upstream will delete it when it's pointed out
that it's the same as GNOME?
debathena / xsession / broder 15:48 (Evan Broder)
It's only the same as GNOME because we default to GNOME, right? If
you were a KDE user, then it would be the same as KDE, would it not?
debathena / xsession / andersk 15:48 (Anders Kaseorg)
We cannot divert it into the void. Then people with the default
session in their .dmrc get broken.
debathena / xsession / jdreed 15:49 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Can we divert it and simply change the display name. I know that's =
not
ideal, but it's also harmless (since I think the name in .dmrc is th=
e
filename, not the display name)
debathena / xsession / andersk 15:50 (Anders Kaseorg)
That is possible. It=E2=80=99s made slightly more difficult because=
the name
is translated into fifty languages.
debathena / xsession / jdreed 15:51 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Wow, and the comment in default.desktop even points out that the nam=
e
sucks
debathena / xsession / andersk 15:51 (Anders Kaseorg)
This should definitely be reported as an upstream bug.
debathena / xsession / wdc 15:51 (rubber_ducky.sysdaemon)
This has taken me far too long to make sense of. I feel really stupi=
d...
So the Default session runs Xclient. We configured Xclient to use GN=
OME
as a default. But if we changed Xclient, we'd be running a default
but one that would be different from GNOME? Have I got it now?
debathena / xsession / andersk 15:52 (Anders Kaseorg)
We did not change Xclient in any way.
debathena / xsession / jdreed 15:52 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I don't think you have to translate it. Even in non-Latin languages=
,
the word "Xclient" is still there. Just call it "Athena" in every l=
anguage.
debathena / xsession / andersk 15:52 (Anders Kaseorg)
In both upstream Ubuntu, and in Debathena now, the Xclient option
defaults to doing the same thing as GNOME.
debathena / xsession / andersk 15:53 (Anders Kaseorg)
It is possible to configure Xclient to point to a different session
(such as KDE) on a system-wide basis. This is what Kubuntu does, fo=
r
example.
debathena / xsession / wdc 15:53 (rubber_ducky.sysdaemon)
Could someone state the "bug" we would report, and the name we would
suggest upstream?
debathena / xsession / andersk 15:54 (Anders Kaseorg)
I think =E2=80=9CRun Xclient script=E2=80=9D should be renamed to =
=E2=80=9CSystem default
session=E2=80=9D.
debathena / xsession / wdc 15:54 (rubber_ducky.sysdaemon)
andersk: You've clarified my sense of what's going on. Maybe I stat=
ed
myself badly, but I think I get it now.
debathena / xsession / andersk 15:54 (Anders Kaseorg)
It should definitely be renamed upstream. The question is whether
it=E2=80=99s worth changing this ourselves for Athena.
debathena / xsession / andersk 15:54 (Anders Kaseorg)
If we do change it for Athena, =E2=80=9CSystem default session=E2=80=
=9D is still the
most accurate name.
debathena / xsession / jdreed 15:55 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I think it's worth changing it for Athena to "System default session=
"
If we care enough about the translations, I bet someone in 21F can
help.
debathena / xsession / andersk 15:55 (Anders Kaseorg)
A name that involves Athena would be inaccurate, because it is not
necessary to pick that session to get the Athena functionality.
debathena / xsession / wdc 15:55 (rubber_ducky.sysdaemon)
What do people think of diverting default.desktop to have the name
"System default session" rather than "Athena"? It's work to translat=
e,
but it's one less thing to maintain going forward.
debathena / xsession / wdc 15:56 (rubber_ducky.sysdaemon)
I think I saw some kind of Fedora (sorry guys) thing that enabled
getting translations from the community WAY fast...
debathena / xsession / jdreed 15:57 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
I suspect going over to 14N and knocking on doors is even faster, bu=
t sure.
debathena / xsession / andersk 15:57 (Anders Kaseorg)
If we=E2=80=99re going to put effort into doing translations, we sho=
uld first
get consensus from upstream that this is the right name to pick, so
that they don=E2=80=99t have to duplicate effort.
debathena / xsession / wdc 15:58 (rubber_ducky.sysdaemon)
andersk: Yes.
We can then collaborate and maybe drive the change forward offering
some translations ourselves.
debathena / xsession / jdreed 15:58 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Agreed, but I don't think Athena 10 should block on an upstream cons=
ensus.
debathena / xsession / andersk 16:03 (Anders Kaseorg)
Okay. I still don=E2=80=99t think that it matters enough to make th=
at change
for Athena 10 before upstream does, but it sounds like the rest of
you do.
debathena / xsession / ghudson 16:05 (Steel and circuits will make me =
whole)
I side with Anders on that point but weakly so, and from a process
perspective I think it's wise to defer to the support person (jdreed=
).
debathena / xsession / andersk 16:05 (Anders Kaseorg)
I will go ahead and revert geofft=E2=80=99s r23269, because it sound=
s like we
have at least reached consensus that we don=E2=80=99t want to change=
the
session path, right?
debathena / xsession / jdreed 16:06 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Correct, though did we reach consensus about the permission checks
changes he made?
debathena / xsession / wdc 16:06 (rubber_ducky.sysdaemon)
I'm gonna play facilitator and re-state the plan going forward:
1. divert /usr/share/gdm/BuiltInSessions/default.desktop to contain
"System Default Session" as the name in english instead of "Run Xcli=
ent Script."
2. Open an upstream bug to get this change in, and to collaborate
in moving it forward.
3. Report that "Secure Remote Connection" is broken and divert it
until it is fixed.
4. Leave in place the existing "Last Session" and session search pat=
h
behavior.
5. Continue with the plan to de-support $WINDOW_MANAGER in dot files
but instead of telling people to write their own .xsession, we tell
them to select the window manager they like from the session list, a=
nd
to agree to make it their default.
debathena / xsession / andersk 16:06 (Anders Kaseorg)
Unclear. I=E2=80=99d rather revert the entire commit rather than pa=
rt of it,
because the history will be less confusing that way. We should
continue to discuss the permission checks.
debathena / xsession / jdreed 16:07 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Fine. But yes, we should come to consensus on the permission checks=
=2E
debathena / xsession / jdreed 16:08 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Bill:
Step 5 is not quite right. It's "Choose one from the list, or write=
your
own .xsession if your preferred WM is not listed."
debathena / xsession / ghudson 16:08 (Steel and circuits will make me =
whole)
I personally thought the zenity dialog was a good solution to the
permissions checks problem.
debathena / xsession / wdc 16:08 (rubber_ducky.sysdaemon)
andersk: implicit in my proposal is that yes, jdreed and I and other=
s
feel strongly that waiting for upstream on this isn't such a good id=
ea.
debathena / xsession / amb 16:10 (xyloid xanthops)
What's the expected lag from "request upstream" to "new package in o=
ur
intrepid repo"?
debathena / xsession / jdreed 16:10 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
ghudson: The zenity dialog is fine.
debathena / xsession / andersk 16:10 (Anders Kaseorg)
amb: Probably high to infinite unless we get very lucky. More
likely, the fix will make its way into Jaunty.
debathena / xsession / wdc 16:10 (rubber_ducky.sysdaemon)
What would the zenity dialog say, specifically?
debathena / xsession / jdreed 16:11 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
wdc: We have a Zenity dialog in place right now.
debathena / xsession / jdreed 16:11 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
It informs the user that they are cruft and that they received an er=
ror
about .dmrc, and that they can fix it by typing chomd 755 $HOME
debathena / xsession / ghudson 16:12 (Steel and circuits will make me =
whole)
I mean, I don't think it's really gdm's job to enforce a permissions
model on .dmrc. But I'm also not sure it's our job to globally
change the gdm behavior to address a few crufty people's user
experience.
debathena / xsession / wdc 16:12 (rubber_ducky.sysdaemon)
"They are cruft"????
debathena / xsession / ghudson 16:13 (Steel and circuits will make me =
whole)
No, it doesn't say that in so many words.
debathena / xsession / broder 16:13 (Evan Broder)
Nice to see we're focusing on the important part of the message
debathena / xsession / jdreed 16:13 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
No, of course it doesn't say that, which is why I didn't use quotati=
on marks
debathena / xsession / ghudson 16:13 (Steel and circuits will make me =
whole)
message "Your home directory is mode $hm, probably because it was cr=
eated" \
"a long time ago. You likely received a spurious error dialog a=
bout" \
".dmrc as a result of the mode bits on your home directory. To fix =
this" \
"condition, you can run: chmod 755 \$HOME"
debathena / xsession / wdc 16:13 (rubber_ducky.sysdaemon)
ghudson: Thank you.
debathena / xsession / wdc 16:14 (rubber_ducky.sysdaemon)
Do we see any other compelling reason to accept geofft's mode change=
s?
debathena / xsession / jdreed 16:15 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
The only advantage of geofft's changes is that without them, users a=
re likely
to see the first message, panic, and call OLC before they get to the=
Zenity
dialog. But I'm not sure how much I care.
We could also just chmod people's homedirs, I suppose. Or send them=
mail.
debathena / xsession / andersk 16:18 (Anders Kaseorg)
It is possible that software other than GDM also has overly strict
permission checking, and therefore a warning is still useful to thos=
e
users.
debathena / xsession / andersk 16:19 (Anders Kaseorg)
Certainly ssh has such checks under some circumstances.
debathena / xsession / jdreed 16:20 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
Then I will support reverting the changes and leaving it as is (ie: =
with
the zenity dialog). I believe Greg counted the users with 777 home=
dirs at
some point, and the number was fairly low.
debathena / xsession / andersk 16:21 (Anders Kaseorg)
Great. I=E2=80=99ll mail a zlog of this conversation to debathena@ =
in reply
to the thread so we don=E2=80=99t lose it, and we can proceed accord=
ingly.
debathena / xsession / jdreed 16:21 (This zephyr does not necessarily =
reflect the views of IS&T, MIT, its)
"10% of accounts", so *shrug*.
If we start seeing a flood of people calling about it, I'll consider
proactively sending email
---1257098496-1419104217-1231536175=:11108--
