pkg kde talk - Mar 2005 - Re: kdm 3.4.0-0pre2 and zsh : unable to log in

--nextPart2035205.zfZGvvkLli
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On March 24, 2005 13:44, Christopher Martin wrote:
> On March 24, 2005 11:26, Adeodato Sim=F3 wrote:
> > * Christopher Martin [Thu, 24 Mar 2005 11:23:11 -0500]:
> > > The problem seems to be that I re-added the sourcing of shell
config
> > > files in KDE 3.4.
> >
> >   There is [1] too.
> >
> >     [1] http://lists.debian.org/debian-qt-kde/2005/03/msg00149.html
>
> Ah, thanks for reminding me. However, I commented out the new shell
> sourcing lines from Xsession, and the problem remained, so we''ll
have to
> look elsewhere. The sessreg patches calc wrote might be a good start,
> since they may no longer work properly in 3.4, but that''s just a
guess.
And indeed, kdm now contains its own internal sessreg routines, so users=20
were being registered/unregistered twice.

Question is - how to fix? Disable the internal sessreg, and continue using=20
our own? That''s the easiest option, since we just have to change an
option=20
in kdmrc, but if we do it by modifying kdmrc, then users who don''t
update=20
that file will still have the problem. Of course, yanking out our own=20
sessreg patches mean that any user that doesn''t update Xstartup and
Xreset=20
will also still be affected.

I''d rather modify one conffile than two, and the fix is simpler, so
I''ll=20
proceed with my first suggestion unless anyone can think of a good reason=20
to do otherwise :)

Cheers,
Christopher Martin

--nextPart2035205.zfZGvvkLli
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Signed by Christopher Martin <chrsmrtn@freeshell.org>

iD8DBQBCQxYaU+gWW+vtsysRApU5AJwNgQ4GgVeL4UgBtnHt2Mn5aZOGwQCdGwHS
xstdzW27KVr3dkZYaKhIiX4=cn3u
-----END PGP SIGNATURE-----

--nextPart2035205.zfZGvvkLli--

* Christopher Martin [Thu, 24 Mar 2005 14:33:46 -0500]:
> Question is - how to fix? Disable the internal sessreg, and continue using 
> our own? That''s the easiest option, since we just have to change
an option
> in kdmrc, but if we do it by modifying kdmrc, then users who don''t
update
> that file will still have the problem. Of course, yanking out our own 
> sessreg patches mean that any user that doesn''t update Xstartup
and Xreset
> will also still be affected.
> I''d rather modify one conffile than two, and the fix is simpler,
so I''ll
> proceed with my first suggestion unless anyone can think of a good reason 
> to do otherwise :)
  However, Xstartup and Xreset seem to me like two files that almost no
  user will have modified, and that''s certainly not the case for kdmrc.

  The above shoult not be taken as advice to revert the change, only as
  (perhaps) useful information. ;-) You''re much more into the problem
  than I.

  Cheers & going out,

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
    Listening to: Joaquín Sabina - Contigo
 
If you want the holes in your knowledge showing up try teaching someone.
                -- Alan Cox

On March 24, 2005 16:12, Adeodato Sim=F3 wrote:
> * Christopher Martin [Thu, 24 Mar 2005 14:33:46 -0500]:
> > Question is - how to fix? Disable the internal sessreg, and continue
> > using our own? That''s the easiest option, since we just have
to change
> > an option in kdmrc, but if we do it by modifying kdmrc, then users who
> > don''t update that file will still have the problem. Of
course, yanking
> > out our own sessreg patches mean that any user that doesn''t
update
> > Xstartup and Xreset will also still be affected.
> >
> > I''d rather modify one conffile than two, and the fix is
simpler, so
> > I''ll proceed with my first suggestion unless anyone can think
of a good
> > reason to do otherwise :)
>
>   However, Xstartup and Xreset seem to me like two files that almost no
>   user will have modified, and that''s certainly not the case for
kdmrc.
>
>   The above shoult not be taken as advice to revert the change, only as
>   (perhaps) useful information. ;-) You''re much more into the
problem
>   than I.
Reverting the change is easy - it''s there for visibility more than
finality=2E=20
You have a good point, but I figured that since going from 3.3 -> 3.4 a=20
kdmrc update is highly recommended anyway, we might as well concentrate the=20
changes in there. Also, we might wind up with users who updated one of=20
Xstartup and Xreset, but not the other, etc. and that would be messy.

Cheers,
Chris