| View previous topic :: View next topic |
| Author |
Message |
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
 Posted: Fri Mar 23, 2012 10:51 am Post subject: Want to get rid of *kits. What should I be careful about? |
 |
|
Update: Check this post for the procedure I followed to remove *kits. My original post follows.
Hi all,
A recent upgrade left me unable to remotely lock my desktop. By "remotely," I mean via acpi scripts. My setup is as follows:
- I use e17 exclusively, with a smattering of applications from kde and gtk, but no gnome applications and no kde desktop.
- I login through e17 using slim and I can verify that udisks command works from the terminal. This latter point implies that consolekit is working.
- Similarly, I use nm-applet/Networkmanager combination to easily change wifi points. All my connections are usually system connections which means that I don't need to start nm-applet in my desktop and Networkmanager auto-connects to the available predefined access point in the background.
- The acpi script calls the screenlock command as
| Code: | | DISPLAY=:0.0 su $my_username -c "a dbus command to enlightenment" |
The same dbus command if called from a terminal when I am logged into enlightenment works just fine
Why do I need this "remote" functionality? Well, I need it because I use it to lock my desktop during suspend/hibernate on closing my laptop lid.
A look through the output of | Code: | | genlop -l -u --date 2 weeks ago |
shows that the package that is possibly responsible for this breakage is dbus, since that is the only relevant package that got upgraded since the time I noticed the breakage. The only reason that could have caused this would be some X permissions issue since I get a dbus message saying that the .service is missing. And the only thing that could mess with X permissions issues is the mess called consolekit and polkit.
So, now I am looking to remove both consolekit and polkit from my system completely. Consolekit is also unmaintained as of now, since upstream has moved to systemd. Here are same salient points that I have come to realize:
- Removing these *kits seems a bit nontrivial task.
- I had to back out of an initial attempt because I couldn't re-emerge world without it pulling in the *kits.
- The USE flags were displayed as (consolekit) (policykit) which means that even though I disabled them in make.conf, they wouldn't be disabled.
Due to lack of time I had to abandon this attempt. Now, on thinking about this a bit more, I believe I should be more cautious and first ask you here (who are running a system free of *kits). My questions are:
- How did you get rid of the *kits?
- Did you encounter any package that will not work without these *kits? What I found is that k3b and kdelibs tend to pull these in. But the k3b ebuild can be modified to leave out the *kit dependency since it is a runtime dependency on ukit.
- Is there some specific thing that could break because of removing these *kits. I know that my udisks-based mounting system will break, but I will deal with that using sudo.
Thanks for your information and help. I hope I can get this monstrosity out of my system.
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/
Last edited by ppurka on Sat Apr 07, 2012 9:48 am; edited 1 time in total |
|
| Back to top |
|
 |
gorkypl
Guru
Joined: 04 Oct 2010
Posts: 444
Location: Kraków, PL
|
| Posted: Fri Mar 23, 2012 12:21 pm Post subject: |
|
|
I have never had any *kits or dbus installed and I am doing well  I use awesome as WM, but I think that e17 should have no problems also.
Don't know anything about problems with uninstalling - I would probably set USE flags in /etc/make.conf to -consolekit -policykit (perhaps something more will be needed), remove them from world file (if they are there) and subsequently do 'equery d consolekit' (and polkit, respectively), to check what still pulls them in.
I have just checked remote screen locking and it works flawlessly - I am using x11-misc/slock to do this:
As a side note - I suggest using net-misc/wicd to manage wifi networks (seems to have less dependencies). For automounter I use sys-apps/uam (for removable devices, that is). |
|
| Back to top |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
| Posted: Fri Mar 23, 2012 4:35 pm Post subject: |
|
|
| gorkypl wrote: | | I have never had any *kits or dbus installed and I am doing well I use awesome as WM, but I think that e17 should have no problems also. |
Indeed e17 can work without dbus. In fact e17 is probably the only program I have encountered that merrily continues running even when the parent dbus session crashes.
| Quote: | | Don't know anything about problems with uninstalling - I would probably set USE flags in /etc/make.conf to -consolekit -policykit (perhaps something more will be needed), remove them from world file (if they are there) and subsequently do 'equery d consolekit' (and polkit, respectively), to check what still pulls them in. |
Yes, what I did was set -consolekit -policykit -udisks -upower and yet it wasn't enough to prevent the *kits from being pulled in, after I unmerged them and tried to emerge world with these new USE flags.
| Quote: | I have just checked remote screen locking and it works flawlessly - I am using x11-misc/slock to do this:
|
Remote screen locking using e17's screen lock will not work if I remove dbus. So, I will keep dbus around and my aim is to remove consolekit and polkit.
| Quote: | | As a side note - I suggest using net-misc/wicd to manage wifi networks (seems to have less dependencies). |
I have tried wicd, wpa_gui, and plain net.wlan0. I must say that nm gives the most painless wireless configuration in linux. wicd works good as long as the networks are not hidden or not something like wpa2 enterprise with roaming. wpa_gui or net.wlan0 are also good if you are not changing wireless access points. But if you need to connect to a new network with the least amount of trouble, then nm is simply the best. This is why I have stuck to using only nm. | Quote: | | For automounter I use sys-apps/uam (for removable devices, that is). |
I have my own scripts for mounting, which hooks up to udev. I do not do automounting; instead I prefer to pop up a dialog and mount only those partitions that I require. This ensures that I don't accidentally change, delete, or modify the files (sometimes those are backup files) in the external drive.
Thanks for you answer though. It seems like it should be possible to get rid of the *kits since you have a system free of them! 
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/ |
|
| Back to top |
|
|
Etal
Veteran
Joined: 15 Jul 2005
Posts: 1931
|
| Posted: Fri Mar 23, 2012 6:45 pm Post subject: |
|
|
I managed to avoid the *Kits by not actually letting anything pull them in
I've even run an almost complete KDE desktop before without any problems (Now I use razorqt with a mixture of KDE and XFCE applications).
The main source of problem are mostly udisks and upower since they need the *Kits, so you'll have to get rid of them and anything that pulls them in (or try if they still work and if so, file some bug reports). A few days ago HPLIP started trying to pull in CK, but it was easily solved by unsetting "acl" flag for it.
| ppurka wrote: | | Quote: | | As a side note - I suggest using net-misc/wicd to manage wifi networks (seems to have less dependencies). |
I have tried wicd, wpa_gui, and plain net.wlan0. [...] wpa_gui or net.wlan0 are also good if you are not changing wireless access points. But if you need to connect to a new network with the least amount of trouble, then nm is simply the best. This is why I have stuck to using only nm. |
How so? If you set in wpa_supplicant.conf:
| Code: | ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
update_config=1 |
It makes using wpa_gui really simple since it allows unprivileged user to add and switch APs, and saves them automatically to the config file. (Although I unfortunately the UI is pretty unappealing.)
Interestingly, there's a network that I use that people with NM can't easily connect to, because the UI is missing some options (on Ubuntu, openSUSE and Fedora, both KDE and GNOME), but with wpa_gui it works with no fuss! 
_________________
“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010 |
|
| Back to top |
|
|
gorkypl
Guru
Joined: 04 Oct 2010
Posts: 444
Location: Kraków, PL
|
| Posted: Fri Mar 23, 2012 10:39 pm Post subject: |
|
|
| ppurka wrote: |
| Quote: | | Don't know anything about problems with uninstalling - I would probably set USE flags in /etc/make.conf to -consolekit -policykit (perhaps something more will be needed), remove them from world file (if they are there) and subsequently do 'equery d consolekit' (and polkit, respectively), to check what still pulls them in. |
Yes, what I did was set -consolekit -policykit -udisks -upower and yet it wasn't enough to prevent the *kits from being pulled in, after I unmerged them and tried to emerge world with these new USE flags.
|
You want to do
| Code: |
equery d consolekit
equery d polkit
|
|
|
| Back to top |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
| Posted: Fri Apr 06, 2012 1:34 pm Post subject: |
|
|
Trying to get rid of the *kits was quite an ordeal. This is what I had to do.
Getting rid of *kits:
- First look at the reverse deps of consolekit, polkit, udisks, upower, and the dependencies of the packages listed there. And make sure that they don't pull these packages in anymore.
Also, disable the relevant USE flags
| Code: | | euse -D consolekit policykit upower udisks |
Next, add the following packages to /etc/portage/profile/package.provided since all the GUI packages that depend on them, depend runtime. This means that they should run fine (maybe with less functionality -- lower instances of elevated privileges) if these packages are not installed. This also means that I don't have to maintain local ebuilds with those packages removed from RDEPEND.
| Quote: | sys-auth/consolekit-0.4.5-r1
sys-auth/polkit-0.104-r1
sys-auth/polkit-kde-agent-0.99.0
kde-misc/polkit-kde-kcmodules-0.98
sys-auth/polkit-qt-0.103.0
sys-fs/udisks-1.0.4-r1 |
Next, unmerge consolekit polkit udisks upower polkit-kde* polkit-qt lxpolkit (these are the related packages installed in my system)
| Code: | | ~> emerge -Cq consolekit polkit polkit-kde-agent polkit-kde-kcmodules polkit-qt lxpolkit udisks upower |
Ran | Code: | | emerge -auD --changed-use world |
to merge the new changes.
Now /var/lib/portage/preserved-libs-* showed that it had preserved several libs belonging to consolekit and polkit. Removed all those libs manually and ran revdep-rebuild. I think emerge @preserved-libs got confused because of package.provided.
revdep failed on 3 packages - slim, modemmanager, gconf. Those were showing the policykit and consolekit USEs as forced.
Changed my profile from desktop/kde to desktop. This fixed the USEs and ran | Code: | | emerge --changed-use -auD world |
in order to make the new USE flags take effect.
Recycled through the init: | Code: | init 1
service udev restart
init 5 |
to get a fresh session with everything intact and working. (except of course udisks related stuff).
After doing all this, my original problem is still not solved. So I am quite peeved. Running | Code: | su <user> -c 'enlightenment_remote -desktop-lock'
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.enlightenment.wm.service was not provided by any .service files
|
still doesn't work when it is run as root. This used to work fine couple of weeks back. Whereas it works if I run the command from a user session with or without su. So, it seems it is dbus that is creating a whole lot of trouble here. Yay, for buggy system level software! Dumb dbus. 
Edit 2: Removed the earlier link. It was unrelated. Still searching for a solution though. 
Edit 3: Update step 1. I forgot to write about adding USEs to make.conf
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/
Last edited by ppurka on Sat Apr 07, 2012 9:44 am; edited 1 time in total |
|
| Back to top |
|
|
Goverp
Veteran
Joined: 07 Mar 2007
Posts: 1992
|
| Posted: Sat Apr 07, 2012 8:15 am Post subject: |
|
|
I have a theory about packages with "kit" in their name. It's an evolution of my theory from Object Oriented Programming (OOP) that classes with "Manager" in their name are automatically broken. That's because the whole principle of OOP is that an object should manage itself. In fact, I found in my career as a developer that anything with "Manager" in it's name was broken, but that's another story...
As to *kit packages, the intention seems to be to bring several complex unrelated bits of security code into one composite so that their bugs can get together and breed in peace.  I always distrust developers that can handle complex code - for example, anything that needs an XML configuration file is suspect.
_________________
Greybeard |
|
| Back to top |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
| Posted: Sat Apr 07, 2012 9:45 am Post subject: |
|
|
Well, this time it turns out it wasn't some *kit that was at fault. It was dbus. And I haven't the slightest clue how to fix this errant behavior.
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/ |
|
| Back to top |
|
|
Etal
Veteran
Joined: 15 Jul 2005
Posts: 1931
|
| Posted: Sat Apr 07, 2012 2:25 pm Post subject: |
|
|
Maybe "su <user> -c 'DISPLAY=:0 enlightenment_remote -desktop-lock' "?
_________________
“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010 |
|
| Back to top |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
| Posted: Sat Apr 07, 2012 4:06 pm Post subject: |
|
|
| Etal wrote: | | Maybe "su <user> -c 'DISPLAY=:0 enlightenment_remote -desktop-lock' "? |
Yeah. I tried both the possible variants. "DISPLAY=:0.0 su <user> -c '...'", and the one you wrote. This has worked for years. I don't even remember when I started using this.
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/ |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Sat Apr 07, 2012 4:52 pm Post subject: Re: Want to get rid of *kits. What should I be careful about |
|
|
| ppurka wrote: | | Consolekit is also unmaintained as of now, since upstream has moved to systemd. |
Nah, the maintainer just changed and 0.4.6 release is out soon.
http://cgit.freedesktop.org/ConsoleKit/ |
|
| Back to top |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
| Posted: Sun Apr 08, 2012 7:50 am Post subject: Re: Want to get rid of *kits. What should I be careful about |
|
|
| ssuominen wrote: | | ppurka wrote: | | Consolekit is also unmaintained as of now, since upstream has moved to systemd. |
Nah, the maintainer just changed and 0.4.6 release is out soon.
http://cgit.freedesktop.org/ConsoleKit/ |
They should update their main website then.
http://www.freedesktop.org/wiki/Software/ConsoleKit
The "git" links there are also dead. As an outsider there is no way for me to know about the correct git source unless I am really in to developing for consolekit
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/ |
|
| Back to top |
|
|
mole
Tux's lil' helper
Joined: 07 Nov 2009
Posts: 81
|
| Posted: Thu May 24, 2012 3:47 pm Post subject: |
|
|
Having similar issues, not found a simple answer and Googled this thread - my workaround was to change the scripts to use SSH rather than sudo or su - ie ssh root@localhost with key authentication, empty passphrase.
Not ideal but worked for me... |
|
| Back to top |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
| Posted: Thu May 24, 2012 4:33 pm Post subject: |
|
|
| mole wrote: | Having similar issues, not found a simple answer and Googled this thread - my workaround was to change the scripts to use SSH rather than sudo or su - ie ssh root@localhost with key authentication, empty passphrase.
Not ideal but worked for me... |
I found one workaround - to figure out the dbus session of the user and export it. One way is to check for the latest dbus file in ~/.dbus/session-bus (ls -1t | head -n 1 works in this case), and hope that that is the correct file. Then you need to extract out DBUS_SESSION_BUS_ADDRESS from the file and export it.
The other method that I use is to have a script run when you login, that echo's the content of that variable into a file, say ~/.config/dbus-address. Then you don't need to parse any other file and can simply do export DBUS_SESSION_BUS_ADDRESS="$(cat ~/.config/dbus-address)".
Let's hope these hacks can work for a year at least, given the pace at which working stuff gets broken.
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/ |
|
| Back to top |
|
|
Hypnos
Advocate
Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent
|
| Posted: Sat Jul 28, 2012 6:17 pm Post subject: |
|
|
| Goverp wrote: | | That's because the whole principle of OOP is that an object should manage itself. In fact, I found in my career as a developer that anything with "Manager" in it's name was broken, but that's another story... |
That's some deep s*** right there -- says a lot about what is broken in software these days.
"To make something simple is a thousand times more difficult than to make something complex." -- Mikhail Kalashnikov
_________________
Personal overlay | Simple backup scheme |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
