Re: [gentoo-user] Consolekit and elogind switch questions

2019-12-19 Thread Dale
Mick wrote:
> On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote:
>> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote:
>>> Thanks much for the info.  Maybe the switch will go well for me too. 
>> If it works for you it will be good news for the rest of us ;-)
> If hald's list of devices has anything to do with it, Dale is bound to nail 
> it 
> on the first (re)boot!  :-)
>
> The consolekit framework is responsible switching between users on a system.  
> As I understand it, when you go to 'Plasma/Leave/Switch User' menu option, 
> console kit daemon is responsible for:
>
> 1. Looking at PAM and any processes you own as a user in a login session.
> 2. Checking which seat (local or remote) you are logged in as and associating 
> the hardware you are using with it (e.g. keyboard, mouse, monitor, etc.).
> 3. Connecting to the d-bus system bus to manage the local login session and 
> pass control of hardware devices to the new user.
> 4. When the new user enters their credentials at the Display Manager, check 
> with PAM what processes the new user is authorised to access/use in their 
> login session.
>
> I should have the above mostly correct.  You may ask if any of this control 
> framework complexity is *necessary* for a single user called Dale, who won't 
> allow anyone else to take his 'seat' at the PC without a fight.  The answer 
> is 
> probably no, and this is why simpler desktop environments like *box, 
> Enlightenment, etc. do not offer the facility to switch users and therefore 
> do 
> not ultimately need consolekit.
>
> There are no screenshots of consolekit/elogind because AFAIK neither offer a 
> GUI application.  However, when you run 'ck-list-sessions' in a terminal 
> you'll see your local session, as well as any other login sessions you may be 
> running at the time, e.g. /dev/tt1, remote logins over ssh and which of these 
> are active at the time.
>
> Since consolekit is no longer under development and systemd appears to have 
> taken over most of the Linux distros, elogind is the current service which 
> can 
> run as stand alone on openrc (just as udev of systemd does).
>
> When elogind is running you can use 'loginctl list-sessions' in a terminal to 
> see who's running a session.  The man page gives more options.
>
> You don't *have* to add elogind as a boot service, because any applications 
> which need it will launch it themselves.  However, don't be surprised if some 
> desktop functions are not working as expected.  For example, the SDDM Display 
> Manager's shutdown/reboot buttons may not be displayed and even if they are 
> displayed they'll do nothing when you click on them after a reboot.  If after 
> a reboot you login/out into your Plasma desktop, then elogind will be running 
> and the SDDM buttons should function again normally.
>
> I have converted a number of systems to elogind.  It should be as easy as 
> setting in your make.conf:
>
> USE="elogind -consolekit"
>
> grep consolekit -r /etc/portage
>
> to find and remove/replace any USE flags still asking for consolekit to be 
> emerged.  Then,
>
> emerge --depclean -v -a consolekit
>
> emerge -uaNDv @world
>
> emerge @preserved-rebuild -v -a
>
> rc-update del consolekit
> rc-update add elogind boot
>
> reboot
>
> >From memory that's all there is to it.


I just switched.  I kept forgetting to do this when the puter was
actually idle.  Anyway, I changed the USE flags and did a emerge -uaDN
world which updated/installed as new several packages and took about 30
minutes on my rig.  Once that was done, I went to the boot runlevel and
used the old checkrestart to see what needed restarting.  Sadly, the
init process, process #1, was in the list.  While everything went well
enough, so it seems anyway, I'm adding the reply to say this.  It seems
one does have to reboot. 

So, if anyone runs up on this thread, be ready for a reboot.  I'm not
sure what it is that made init need a restart but that's what it showed
and I've never seen it listed before. 

Thanks to all, Mick for sure since he posted a general guide, for the help.

Dale

:-)  :-) 



Re: [gentoo-user] Consolekit and elogind switch questions

2019-11-03 Thread Dale
Mick wrote:
> On Sunday, 3 November 2019 06:08:15 GMT Dale wrote:
>> Mick wrote:
>>> On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote:
 On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote:
> Thanks much for the info.  Maybe the switch will go well for me too.
 If it works for you it will be good news for the rest of us ;-)
>>> If hald's list of devices has anything to do with it, Dale is bound to
>>> nail it on the first (re)boot!  :-)
>>>
>>> The consolekit framework is responsible switching between users on a
>>> system. As I understand it, when you go to 'Plasma/Leave/Switch User'
>>> menu option, console kit daemon is responsible for:
>>>
>>> 1. Looking at PAM and any processes you own as a user in a login session.
>>> 2. Checking which seat (local or remote) you are logged in as and
>>> associating the hardware you are using with it (e.g. keyboard, mouse,
>>> monitor, etc.). 3. Connecting to the d-bus system bus to manage the local
>>> login session and pass control of hardware devices to the new user.
>>> 4. When the new user enters their credentials at the Display Manager,
>>> check
>>> with PAM what processes the new user is authorised to access/use in their
>>> login session.
>>>
>>> I should have the above mostly correct.  You may ask if any of this
>>> control
>>> framework complexity is *necessary* for a single user called Dale, who
>>> won't allow anyone else to take his 'seat' at the PC without a fight. 
>>> The answer is probably no, and this is why simpler desktop environments
>>> like *box, Enlightenment, etc. do not offer the facility to switch users
>>> and therefore do not ultimately need consolekit.
>>>
>>> There are no screenshots of consolekit/elogind because AFAIK neither offer
>>> a GUI application.  However, when you run 'ck-list-sessions' in a
>>> terminal you'll see your local session, as well as any other login
>>> sessions you may be running at the time, e.g. /dev/tt1, remote logins
>>> over ssh and which of these are active at the time.
>>>
>>> Since consolekit is no longer under development and systemd appears to
>>> have
>>> taken over most of the Linux distros, elogind is the current service which
>>> can run as stand alone on openrc (just as udev of systemd does).
>>>
>>> When elogind is running you can use 'loginctl list-sessions' in a terminal
>>> to see who's running a session.  The man page gives more options.
>>>
>>> You don't *have* to add elogind as a boot service, because any
>>> applications
>>> which need it will launch it themselves.  However, don't be surprised if
>>> some desktop functions are not working as expected.  For example, the
>>> SDDM Display Manager's shutdown/reboot buttons may not be displayed and
>>> even if they are displayed they'll do nothing when you click on them
>>> after a reboot.  If after a reboot you login/out into your Plasma
>>> desktop, then elogind will be running and the SDDM buttons should
>>> function again normally.
>>>
>>> I have converted a number of systems to elogind.  It should be as easy as
>>> setting in your make.conf:
>>>
>>> USE="elogind -consolekit"
>>>
>>> grep consolekit -r /etc/portage
>>>
>>> to find and remove/replace any USE flags still asking for consolekit to be
>>> emerged.  Then,
>>>
>>> emerge --depclean -v -a consolekit
>>>
>>> emerge -uaNDv @world
>>>
>>> emerge @preserved-rebuild -v -a
>>>
>>> rc-update del consolekit
>>> rc-update add elogind boot
>>>
>>> reboot
>>>
>>> >From memory that's all there is to it.
>> One quick question, is a reboot necessary or would going to single and
>> back be enough?  I hate rebooting because I've had a init thingy fail a
>> couple times in the past.  Makes me nervous and my blood pressure go up
>> as well.  Reminds me a little of hal.  :/
>>
>> I'm thinking about going ahead and doing this but may sync again first,
>> just to be sure the tree is up to date enough.  I did a -p on it and it
>> doesn't look like to much changes, mostly USE flags. 
>>
>> Thanks.
>>
>> Dale
>>
>> :-)  :-)  
> I forgot, you should stop the consolekit service before you remove/delete it 
> and do this *after* you have logged out.
>
> Since consolekit/elogind are services dealing with desktop user access, you 
> should at least log out, stop consolekit, start elogind and then log back 
> into 
> your KDE/Plasma desktop.  Rebooting is not necessary, although I tend to 
> reboot just to check boot services (re)start as they should and there are no 
> errors/clashes.
>

OK, thanks much.  Since it is a service, I thought a reboot may not be
required but wanted to be sure.  The extra information did help me with
what I thought would be required, like stopping consolekit first.  That
hadn't occurred to me. 

Dale

:-)  :-) 



Re: [gentoo-user] Consolekit and elogind switch questions

2019-11-03 Thread Mick
On Sunday, 3 November 2019 06:08:15 GMT Dale wrote:
> Mick wrote:
> > On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote:
> >> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote:
> >>> Thanks much for the info.  Maybe the switch will go well for me too.
> >> 
> >> If it works for you it will be good news for the rest of us ;-)
> > 
> > If hald's list of devices has anything to do with it, Dale is bound to
> > nail it on the first (re)boot!  :-)
> > 
> > The consolekit framework is responsible switching between users on a
> > system. As I understand it, when you go to 'Plasma/Leave/Switch User'
> > menu option, console kit daemon is responsible for:
> > 
> > 1. Looking at PAM and any processes you own as a user in a login session.
> > 2. Checking which seat (local or remote) you are logged in as and
> > associating the hardware you are using with it (e.g. keyboard, mouse,
> > monitor, etc.). 3. Connecting to the d-bus system bus to manage the local
> > login session and pass control of hardware devices to the new user.
> > 4. When the new user enters their credentials at the Display Manager,
> > check
> > with PAM what processes the new user is authorised to access/use in their
> > login session.
> > 
> > I should have the above mostly correct.  You may ask if any of this
> > control
> > framework complexity is *necessary* for a single user called Dale, who
> > won't allow anyone else to take his 'seat' at the PC without a fight. 
> > The answer is probably no, and this is why simpler desktop environments
> > like *box, Enlightenment, etc. do not offer the facility to switch users
> > and therefore do not ultimately need consolekit.
> > 
> > There are no screenshots of consolekit/elogind because AFAIK neither offer
> > a GUI application.  However, when you run 'ck-list-sessions' in a
> > terminal you'll see your local session, as well as any other login
> > sessions you may be running at the time, e.g. /dev/tt1, remote logins
> > over ssh and which of these are active at the time.
> > 
> > Since consolekit is no longer under development and systemd appears to
> > have
> > taken over most of the Linux distros, elogind is the current service which
> > can run as stand alone on openrc (just as udev of systemd does).
> > 
> > When elogind is running you can use 'loginctl list-sessions' in a terminal
> > to see who's running a session.  The man page gives more options.
> > 
> > You don't *have* to add elogind as a boot service, because any
> > applications
> > which need it will launch it themselves.  However, don't be surprised if
> > some desktop functions are not working as expected.  For example, the
> > SDDM Display Manager's shutdown/reboot buttons may not be displayed and
> > even if they are displayed they'll do nothing when you click on them
> > after a reboot.  If after a reboot you login/out into your Plasma
> > desktop, then elogind will be running and the SDDM buttons should
> > function again normally.
> > 
> > I have converted a number of systems to elogind.  It should be as easy as
> > setting in your make.conf:
> > 
> > USE="elogind -consolekit"
> > 
> > grep consolekit -r /etc/portage
> > 
> > to find and remove/replace any USE flags still asking for consolekit to be
> > emerged.  Then,
> > 
> > emerge --depclean -v -a consolekit
> > 
> > emerge -uaNDv @world
> > 
> > emerge @preserved-rebuild -v -a
> > 
> > rc-update del consolekit
> > rc-update add elogind boot
> > 
> > reboot
> > 
> > >From memory that's all there is to it.
> 
> One quick question, is a reboot necessary or would going to single and
> back be enough?  I hate rebooting because I've had a init thingy fail a
> couple times in the past.  Makes me nervous and my blood pressure go up
> as well.  Reminds me a little of hal.  :/
> 
> I'm thinking about going ahead and doing this but may sync again first,
> just to be sure the tree is up to date enough.  I did a -p on it and it
> doesn't look like to much changes, mostly USE flags. 
> 
> Thanks.
> 
> Dale
> 
> :-)  :-)  

I forgot, you should stop the consolekit service before you remove/delete it 
and do this *after* you have logged out.

Since consolekit/elogind are services dealing with desktop user access, you 
should at least log out, stop consolekit, start elogind and then log back into 
your KDE/Plasma desktop.  Rebooting is not necessary, although I tend to 
reboot just to check boot services (re)start as they should and there are no 
errors/clashes.

-- 
Regards,

Mick

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Consolekit and elogind switch questions

2019-11-02 Thread Dale
Mick wrote:
> On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote:
>> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote:
>>> Thanks much for the info.  Maybe the switch will go well for me too. 
>> If it works for you it will be good news for the rest of us ;-)
> If hald's list of devices has anything to do with it, Dale is bound to nail 
> it 
> on the first (re)boot!  :-)
>
> The consolekit framework is responsible switching between users on a system.  
> As I understand it, when you go to 'Plasma/Leave/Switch User' menu option, 
> console kit daemon is responsible for:
>
> 1. Looking at PAM and any processes you own as a user in a login session.
> 2. Checking which seat (local or remote) you are logged in as and associating 
> the hardware you are using with it (e.g. keyboard, mouse, monitor, etc.).
> 3. Connecting to the d-bus system bus to manage the local login session and 
> pass control of hardware devices to the new user.
> 4. When the new user enters their credentials at the Display Manager, check 
> with PAM what processes the new user is authorised to access/use in their 
> login session.
>
> I should have the above mostly correct.  You may ask if any of this control 
> framework complexity is *necessary* for a single user called Dale, who won't 
> allow anyone else to take his 'seat' at the PC without a fight.  The answer 
> is 
> probably no, and this is why simpler desktop environments like *box, 
> Enlightenment, etc. do not offer the facility to switch users and therefore 
> do 
> not ultimately need consolekit.
>
> There are no screenshots of consolekit/elogind because AFAIK neither offer a 
> GUI application.  However, when you run 'ck-list-sessions' in a terminal 
> you'll see your local session, as well as any other login sessions you may be 
> running at the time, e.g. /dev/tt1, remote logins over ssh and which of these 
> are active at the time.
>
> Since consolekit is no longer under development and systemd appears to have 
> taken over most of the Linux distros, elogind is the current service which 
> can 
> run as stand alone on openrc (just as udev of systemd does).
>
> When elogind is running you can use 'loginctl list-sessions' in a terminal to 
> see who's running a session.  The man page gives more options.
>
> You don't *have* to add elogind as a boot service, because any applications 
> which need it will launch it themselves.  However, don't be surprised if some 
> desktop functions are not working as expected.  For example, the SDDM Display 
> Manager's shutdown/reboot buttons may not be displayed and even if they are 
> displayed they'll do nothing when you click on them after a reboot.  If after 
> a reboot you login/out into your Plasma desktop, then elogind will be running 
> and the SDDM buttons should function again normally.
>
> I have converted a number of systems to elogind.  It should be as easy as 
> setting in your make.conf:
>
> USE="elogind -consolekit"
>
> grep consolekit -r /etc/portage
>
> to find and remove/replace any USE flags still asking for consolekit to be 
> emerged.  Then,
>
> emerge --depclean -v -a consolekit
>
> emerge -uaNDv @world
>
> emerge @preserved-rebuild -v -a
>
> rc-update del consolekit
> rc-update add elogind boot
>
> reboot
>
> >From memory that's all there is to it.


One quick question, is a reboot necessary or would going to single and
back be enough?  I hate rebooting because I've had a init thingy fail a
couple times in the past.  Makes me nervous and my blood pressure go up
as well.  Reminds me a little of hal.  :/

I'm thinking about going ahead and doing this but may sync again first,
just to be sure the tree is up to date enough.  I did a -p on it and it
doesn't look like to much changes, mostly USE flags. 

Thanks.

Dale

:-)  :-)  



Re: [gentoo-user] Consolekit and elogind switch questions

2019-10-31 Thread Dale
Mick wrote:
> On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote:
>> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote:
>>> Thanks much for the info.  Maybe the switch will go well for me too. 
>> If it works for you it will be good news for the rest of us ;-)
> If hald's list of devices has anything to do with it, Dale is bound to nail 
> it 
> on the first (re)boot!  :-)
>
> The consolekit framework is responsible switching between users on a system.  
> As I understand it, when you go to 'Plasma/Leave/Switch User' menu option, 
> console kit daemon is responsible for:
>
> 1. Looking at PAM and any processes you own as a user in a login session.
> 2. Checking which seat (local or remote) you are logged in as and associating 
> the hardware you are using with it (e.g. keyboard, mouse, monitor, etc.).
> 3. Connecting to the d-bus system bus to manage the local login session and 
> pass control of hardware devices to the new user.
> 4. When the new user enters their credentials at the Display Manager, check 
> with PAM what processes the new user is authorised to access/use in their 
> login session.
>
> I should have the above mostly correct.  You may ask if any of this control 
> framework complexity is *necessary* for a single user called Dale, who won't 
> allow anyone else to take his 'seat' at the PC without a fight.  The answer 
> is 
> probably no, and this is why simpler desktop environments like *box, 
> Enlightenment, etc. do not offer the facility to switch users and therefore 
> do 
> not ultimately need consolekit.
>
> There are no screenshots of consolekit/elogind because AFAIK neither offer a 
> GUI application.  However, when you run 'ck-list-sessions' in a terminal 
> you'll see your local session, as well as any other login sessions you may be 
> running at the time, e.g. /dev/tt1, remote logins over ssh and which of these 
> are active at the time.
>
> Since consolekit is no longer under development and systemd appears to have 
> taken over most of the Linux distros, elogind is the current service which 
> can 
> run as stand alone on openrc (just as udev of systemd does).
>
> When elogind is running you can use 'loginctl list-sessions' in a terminal to 
> see who's running a session.  The man page gives more options.
>
> You don't *have* to add elogind as a boot service, because any applications 
> which need it will launch it themselves.  However, don't be surprised if some 
> desktop functions are not working as expected.  For example, the SDDM Display 
> Manager's shutdown/reboot buttons may not be displayed and even if they are 
> displayed they'll do nothing when you click on them after a reboot.  If after 
> a reboot you login/out into your Plasma desktop, then elogind will be running 
> and the SDDM buttons should function again normally.
>
> I have converted a number of systems to elogind.  It should be as easy as 
> setting in your make.conf:
>
> USE="elogind -consolekit"
>
> grep consolekit -r /etc/portage
>
> to find and remove/replace any USE flags still asking for consolekit to be 
> emerged.  Then,
>
> emerge --depclean -v -a consolekit
>
> emerge -uaNDv @world
>
> emerge @preserved-rebuild -v -a
>
> rc-update del consolekit
> rc-update add elogind boot
>
> reboot
>
> >From memory that's all there is to it.


Thanks much for the info.  Let's not go down the hal road.  Still gets
my blood pressure up.  lol 

It sounds like I don't need it but most likely KDE will moan and groan
without it so I'll just switch and let the chips fall where they may.  I
guess if nothing else, while it is still in the tree at least, I could
switch back and try to find solutions to whatever I run into.  Once it's
gone tho, not a option, easy one at least. 

Thanks again.

Dale

:-)  :-) 



Re: [gentoo-user] Consolekit and elogind switch questions

2019-10-28 Thread Mick
On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote:
> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote:
> > Thanks much for the info.  Maybe the switch will go well for me too. 
> 
> If it works for you it will be good news for the rest of us ;-)

If hald's list of devices has anything to do with it, Dale is bound to nail it 
on the first (re)boot!  :-)

The consolekit framework is responsible switching between users on a system.  
As I understand it, when you go to 'Plasma/Leave/Switch User' menu option, 
console kit daemon is responsible for:

1. Looking at PAM and any processes you own as a user in a login session.
2. Checking which seat (local or remote) you are logged in as and associating 
the hardware you are using with it (e.g. keyboard, mouse, monitor, etc.).
3. Connecting to the d-bus system bus to manage the local login session and 
pass control of hardware devices to the new user.
4. When the new user enters their credentials at the Display Manager, check 
with PAM what processes the new user is authorised to access/use in their 
login session.

I should have the above mostly correct.  You may ask if any of this control 
framework complexity is *necessary* for a single user called Dale, who won't 
allow anyone else to take his 'seat' at the PC without a fight.  The answer is 
probably no, and this is why simpler desktop environments like *box, 
Enlightenment, etc. do not offer the facility to switch users and therefore do 
not ultimately need consolekit.

There are no screenshots of consolekit/elogind because AFAIK neither offer a 
GUI application.  However, when you run 'ck-list-sessions' in a terminal 
you'll see your local session, as well as any other login sessions you may be 
running at the time, e.g. /dev/tt1, remote logins over ssh and which of these 
are active at the time.

Since consolekit is no longer under development and systemd appears to have 
taken over most of the Linux distros, elogind is the current service which can 
run as stand alone on openrc (just as udev of systemd does).

When elogind is running you can use 'loginctl list-sessions' in a terminal to 
see who's running a session.  The man page gives more options.

You don't *have* to add elogind as a boot service, because any applications 
which need it will launch it themselves.  However, don't be surprised if some 
desktop functions are not working as expected.  For example, the SDDM Display 
Manager's shutdown/reboot buttons may not be displayed and even if they are 
displayed they'll do nothing when you click on them after a reboot.  If after 
a reboot you login/out into your Plasma desktop, then elogind will be running 
and the SDDM buttons should function again normally.

I have converted a number of systems to elogind.  It should be as easy as 
setting in your make.conf:

USE="elogind -consolekit"

grep consolekit -r /etc/portage

to find and remove/replace any USE flags still asking for consolekit to be 
emerged.  Then,

emerge --depclean -v -a consolekit

emerge -uaNDv @world

emerge @preserved-rebuild -v -a

rc-update del consolekit
rc-update add elogind boot

reboot

>From memory that's all there is to it.
-- 
Regards,

Mick

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Consolekit and elogind switch questions

2019-10-28 Thread Bill Kenworthy
On 28/10/19 2:23 pm, Arve Barsnes wrote:
> On Mon, 28 Oct 2019 at 04:38, Dale  wrote:
>> Also, are there any other options to elogind?  Is that the only option
>> when using KDE?
> I think the answer here is yes.
>
> I run openbox, so no requirement to have this at all, but I have
> previously done the migration to elogind, and that went without a
> hitch. With no experience to back me up, I think the thing that might
> break upon migration is the shutdown/reboot scripts, so you might have
> to reboot from the commandline. Otherwise I don't expect much trouble.
>
> Regards,
> Arve
>
It works for me - but its annoying in that its inherited some parts of
the systemd "stuff you - I dont care, I am going to take it over anyway"
attitude.  For me its laptop suspend/hibernate - its never worked as
well as previous scripts and it seems it cant be undone.  Its also quite
chatty in the logs - also annoying.

I know the author is responsive and has done a good job in just being
able to get it to work, but he has started with crapware and it shows.
(sorry, but suspend/hibernate is a sore point for me)

BillK





Re: [gentoo-user] Consolekit and elogind switch questions

2019-10-28 Thread Neil Bothwick
On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote:

> Thanks much for the info.  Maybe the switch will go well for me too. 

If it works for you it will be good news for the rest of us ;-)


-- 
Neil Bothwick

There is absolutely no substitute for a genuine lack of preparation.


pgpzS_8Fl7iLb.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Consolekit and elogind switch questions

2019-10-28 Thread Dale
Arve Barsnes wrote:
> On Mon, 28 Oct 2019 at 04:38, Dale  wrote:
>> Also, are there any other options to elogind?  Is that the only option
>> when using KDE?
> I think the answer here is yes.
>
> I run openbox, so no requirement to have this at all, but I have
> previously done the migration to elogind, and that went without a
> hitch. With no experience to back me up, I think the thing that might
> break upon migration is the shutdown/reboot scripts, so you might have
> to reboot from the commandline. Otherwise I don't expect much trouble.
>
> Regards,
> Arve
>
>


Thanks much for the info.  Maybe the switch will go well for me too. 

Dale

:-)  :-) 



Re: [gentoo-user] Consolekit and elogind switch questions

2019-10-27 Thread Arve Barsnes
On Mon, 28 Oct 2019 at 04:38, Dale  wrote:
> Also, are there any other options to elogind?  Is that the only option
> when using KDE?

I think the answer here is yes.

I run openbox, so no requirement to have this at all, but I have
previously done the migration to elogind, and that went without a
hitch. With no experience to back me up, I think the thing that might
break upon migration is the shutdown/reboot scripts, so you might have
to reboot from the commandline. Otherwise I don't expect much trouble.

Regards,
Arve



[gentoo-user] Consolekit and elogind switch questions

2019-10-27 Thread Dale
Howdy,

I subscribe to -dev and read things to get a heads up mostly.  I noticed
a news item being started concerning consolekit and switching to
elogind.  From my understanding it is similar to the difference of udev
and eudev in that it just pulls the code needed when not using systemd
and friends.  I do have consolekit here and since the news item and the
migration guide mentions removing consolekit, I'm pretty sure the news
item has my name all over it and I'm about to switch.  Given the
outdated nature of consolekit, may be a good thing.

Before I start down this road, I have questions.  What exactly is it? 
Is it the screen that pops up when X starts and asks for my login?  Is
it something inside KDE itself that manages the Desktop itself?  I think
the first one is sddm.  So I'm suspecting it is the later one.  Or is it
something that I won't even notice the change in?  Something that runs
in the background and I don't see?  Just trying to figure out exactly
what it is I'm changing, not that I'm against it because it seems it is
needed. 

Has anyone already switched and if so, was it fairly straight forward
and easy or did it require something outside the norm, like shutting
down X and doing from a console?  I generally update etc from a Konsole
inside KDE.  One of the things mentioned something about a session
becoming corrupted during this is one reason I ask.  This comment: 
"Migration is easy, but if run from within a consolekit session that
session may become broken."  I'm not sure but I think Konsole uses
consolekit.  Heck, console itself may use it too. 

If someone has a screenshot that shows the difference, I'd love to see
it.  Post a link to a pic hosting site, send it off list or whatever
works.  I tried to google for screenshots but most mention Gnome and I
use KDE.  I also poked around Gentoo but it seems to be Gnome as well. 
Add in that I'm not sure what I'm looking for, I may not know it when I
see it anyway.  LOL 

Also, are there any other options to elogind?  Is that the only option
when using KDE? 

Thanks to anyone who can clear up some of this confusion on my part. 

Dale

:-)  :-)