[808] in athena10
Re: Changes to debathena-gdm-config
daemon@ATHENA.MIT.EDU (Tim Abbott)
Fri Jan 9 16:35:01 2009
Date: Fri, 9 Jan 2009 16:34:09 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Anders Kaseorg <andersk@mit.edu>
cc: athena10@mit.edu
In-Reply-To: <alpine.DEB.2.00.0901091621440.11108@vinegar-pot.mit.edu>
Message-ID: <alpine.DEB.2.00.0901091625250.959@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1257098496-2026732622-1231536775=:959"
Content-ID: <alpine.DEB.2.00.0901091632590.959@vinegar-pot.mit.edu>
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-2026732622-1231536775=:959
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.00.0901091632591.959@vinegar-pot.mit.edu>
The important part of this is presumably the action plan:
1. divert /usr/share/gdm/BuiltInSessions/default.desktop to contain=20
"System Default Session" as the name in english instead of "Run Xclient=20
Script."
2. Open an upstream bug to get this change in, and to collaborate in=20
moving it forward.
3. Report that "Secure Remote Connection" is broken and divert it until it=
=20
is fixed.
4. Leave in place the existing "Last Session" and session search path=20
behavior.
5. Continue with the plan to de-support $WINDOW_MANAGER in dot files but=20
instead of telling people to write their own .xsession, we tell them to=20
select the window manager they like from the session list, and to agree to=
=20
make it their default.
I think that the didn't materially change after being first stated in this=
=20
form, but please correct me if this is wrong.
=09-Tim Abbott
On Fri, 9 Jan 2009, Anders Kaseorg wrote:
> 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 =
do
> 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'=
ll
> instruct users to create their own .xsession file to specify sessio=
n,
> and window manager. We are apparently not yet all agreed that a us=
er
> generated .xsession will work, or is the right approach.
> debathena / xsession / geofft 11:20 (Our Slogan : Vulnerability Is Po=
ssible !!!)
> 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 t=
he
> 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 Po=
ssible !!!)
> I'd be okay putting this _just_ in the Athena 10 cluster config, bu=
t
> I suspect this doesn't fully address Anders' concerns about staying
> close to upstream.
> debathena / xsession / geofft 11:36 (Our Slogan : Vulnerability Is Po=
ssible !!!)
> 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 ex=
actly 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 =
sense.
>
> Perhaps to summarize:
>
> There is no indication to someone seeing the list of sessions for t=
he first time
> that choosing one of the Failsave options needs NOT be undone by ch=
oosing
> one of the other options. From that starting point, someone who kn=
ows
> "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 sta=
ndard
> login session not the Athena Standard login session is what they ge=
t.
>
> Yes, changing from "run X Client" session to "Athena" will help.
>
> But it is unclear if the stock Gnome session that happens to be lay=
ing
> around in what's installed is actually useful. The "Secure Remote =
Connection"
> option is also what happens to be laying around. Again, it's non-t=
oxic,
> 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 sto=
ck
> Ubuntu greeter. The cruft is now first-class options in a button ma=
ny
> 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 necessitat=
e
> 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 sessio=
n"
> 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=
=2E
> 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 get=
s populated
> per se, but our greeter design has optimized us into a bad place. =
Can
> 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 craft=
ed,
> can we get rid of ours?
>
> This also begs the question: can we get rid of that useless and dis=
tracting
> "Secure Terminal Session" that is discovered in the default directo=
ry
> 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 me=
nu
> 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. =
We're
> essentially commenting out a few broken session options that don't =
work
> 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 possibl=
e
> 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 r=
un 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 m=
achines.
> I cannot use it to ssh into Athena or OS X, for example. That is b=
roken.
> 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, repor=
t 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 -workstati=
on as
> their primary machine. Because we're the only people who seem to r=
un 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 wi=
th,
> "That's not a bug." "Yes it is." "No it isn't." (see Argument Cli=
nic).
> 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 usin=
g -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 nev=
er
> > really clued into how, "You're just supposed to know to Run Xclie=
nt
> > Script".
>
> This is why I continued to press for clarification about what exact=
ly
> broke.
> debathena / xsession / amb 14:40 (xyloid xanthops)
> I use -workstation on one of my two desktops (cithotr), but it's br=
oken in
> a whole bunch of ways due to random testing and probably wants a re=
install.
> 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, t=
hough.)
> debathena / xsession / tabbott 14:40 (Timothy G Abbott)
> I think -login without -workstation is basically only used on Liner=
va
> and some hall dialups. A lot of people's personal desktops and hal=
l
> workstations are -workstation.
>
> Of course, it may be the case that most people don't click around o=
n
> 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 busi=
ness
> of disabling functionality because it's confusing or incompatible w=
ith 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 t=
he
> 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 independe=
nt
> 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=99=
t 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 becaus=
e
> it hangs the GDM session. I propose dealing by selectively diverti=
ng
> 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 Athe=
na 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 Se=
ssion"
> 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 firs=
t
> 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 havi=
ng
> "Make Default" be the default button on the session selection dialo=
g is
> a usability bug.
> debathena / xsession / andersk 14:54 (Anders Kaseorg)
> The Last Session option can be also somewhat separated from the fir=
st
> issue and discussed independently of the other two redundant option=
s.
> 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. Bu=
t while
> we're reporting the bug about it being broken, it might be worth re=
porting
> 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 bu=
tton 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 differe=
nt
> for SSH and, say, KDE?
> debathena / xsession / wdc 14:58 (rubber_ducky.sysdaemon)
> We could just avail ourselves of the xsesssion config option to sto=
p 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 clueles=
sness
> to assume that any option I selected would become the default when
> I saw that "Last Session" option. Thinking about it some more, I g=
uess
> 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 fr=
om
> the proffered list, and it can't just highlight the last one for yo=
u
> 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 thi=
nk 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 i=
sn'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 t=
o 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 homedi=
r?
> debathena / xsession / wdc 15:06 (rubber_ducky.sysdaemon)
> I'm trying to guess at what the "solution of least surprise" would =
be.
> 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 gree=
ter 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 ex=
ample,
> 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 b=
e
> 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 sear=
ch
> 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 =
Session"
> 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-ext=
ra-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 reposi=
tories
> 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 t=
he
> 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 debathen=
a@
> 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 in=
stall
> something else (KDE), then we should keep it. I can live with that=
=2E
> However, we should do something to avoid having N window managers i=
n the
> session window. Something that could easily be reverted by local s=
ysadmins
> for example. It seems that changing the gdm search path is the ea=
siest, 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 pa=
th 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 pu=
t
> 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. =
So we
> disable it as per geofft, and then create the following stock answe=
r:
>
> Q: How do I get other sessions, like KDE, GNOME, TWM, etc to show u=
p 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 p=
revents
> 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.deba=
thena.
> 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/xses=
sions/:
> /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 unco=
mment
> 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=
=2E
> 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, o=
r does it
> give them the Athena session on a cluster machine? I really don't =
care if
> people can't use KDE on cluster machines, that's not what cluster m=
achines
> 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 eve=
rything
> 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 insta=
lled,
> I get a prompted that says "What do you want to do." One of the bu=
ttons 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 =
or not
> it's ok for new window managers, slated to land in the Cluster conf=
ig,
> 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 Wind=
owMaker,
> 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 adde=
d 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 int=
end 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 install=
ed
> 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/xse=
ssions/:\
> /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 c=
omment
> 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 wh=
at to do
> on the cluster workstations. I think that's fine. People may disa=
gree 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 windo=
w managers
> in the login menu, but then I still think we need to do something a=
bout
> "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 ins=
talled
> 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 optio=
n"
> 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'r=
e 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 =
options in
> some way. We do. That=C2=A0just isn=E2=80=99t what we=E2=80=99re =
talking 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 y=
ou
> 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 cluste=
r
> 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 beha=
vior,
> and we stick all the supported window managers in the login session=
=2E How
> can we most non-offensively rename "Xclient script" to "Normal sess=
ion" 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 ou=
t
> 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 t=
he
> filename, not the display name)
> debathena / xsession / andersk 15:50 (Anders Kaseorg)
> That is possible. It=E2=80=99s made slightly more difficult becaus=
e 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 na=
me
> 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 stup=
id...
>
> So the Default session runs Xclient. We configured Xclient to use G=
NOME
> 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 language=
s,
> the word "Xclient" is still there. Just call it "Athena" in every =
language.
> 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, f=
or
> example.
> debathena / xsession / wdc 15:53 (rubber_ducky.sysdaemon)
> Could someone state the "bug" we would report, and the name we woul=
d
> 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 sta=
ted
> 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 sessio=
n"
> 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 transla=
te,
> 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, b=
ut sure.
> debathena / xsession / andersk 15:57 (Anders Kaseorg)
> If we=E2=80=99re going to put effort into doing translations, we sh=
ould 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 con=
sensus.
> debathena / xsession / andersk 16:03 (Anders Kaseorg)
> Okay. I still don=E2=80=99t think that it matters enough to make t=
hat 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 (jdree=
d).
> debathena / xsession / andersk 16:05 (Anders Kaseorg)
> I will go ahead and revert geofft=E2=80=99s r23269, because it soun=
ds like we
> have at least reached consensus that we don=E2=80=99t want to chang=
e 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 Xcl=
ient 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 pa=
th
> behavior.
> 5. Continue with the plan to de-support $WINDOW_MANAGER in dot file=
s
> but instead of telling people to write their own .xsession, we tell
> them to select the window manager they like from the session list, =
and
> 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 p=
art 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 check=
s.
> 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 writ=
e 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 othe=
rs
> feel strongly that waiting for upstream on this isn't such a good i=
dea.
> debathena / xsession / amb 16:10 (xyloid xanthops)
> What's the expected lag from "request upstream" to "new package in =
our
> 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 e=
rror
> 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 permission=
s
> 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 quotat=
ion marks
> debathena / xsession / ghudson 16:13 (Steel and circuits will make me=
whole)
> message "Your home directory is mode $hm, probably because it was c=
reated" \
> "a long time ago. You likely received a spurious error dialog =
about" \
> ".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 chang=
es?
> 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 =
are likely
> to see the first message, panic, and call OLC before they get to th=
e Zenity
> dialog. But I'm not sure how much I care.
> We could also just chmod people's homedirs, I suppose. Or send the=
m 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 tho=
se
> 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 hom=
edirs 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 accor=
dingly.
> 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 conside=
r
> proactively sending email
---1257098496-2026732622-1231536775=:959--
