to kde module developers: kde itself and all kde applications have broken integration with dbus and policykit

Stefan Wold ratler at lunar-linux.org
Sat Jul 10 20:31:24 CEST 2010


On Sat, 2010-07-10 at 10:32 -0400, Dennis Veatch wrote:
> On Saturday, July 10, 2010 10:06:28 am Zbigniew Luszpinski wrote:
> > Hello,
> > 
> > I have just discovered that kde itself and almost all kde applications have
> > broken dbus/messagebus and policykit integration. This integration break
> > was caused by installing kde in non standard directory: /opt/lunar/kde/4
> > 
> > The result of this broken integration is that:
> > *KAuth is broken: you can not use kde sudo like features to do root duties
> > from casual user account. For example setting the clock:
> > 
> > Discussion on Lunar ML: Re: Hello world - my response:
> > >> I asked about password request in KDE
> > >> config tool because I couldn't set ntp as default service.
> > > 
> > > I reproduced the bug you probably encountered setting ntp:
> > > "Unable to authenticate/execute the action: 7, DBus Backend error: could
> > > not contact the helper. Connection error: Could not get owner of name >
> > > 'org.kde.kcontrol.kcmclock': no such name. Message error: The name
> > > org.kde.kcontrol.kcmclock was not provided by any .service files"
> > > 
> > > Will look at it deeper later - Lunar installs dbus files in wrong place.
> > 
> > I manually copied dbus and policykit kde files to correct locations and
> > this bug is fixed. Another advantage is that when I plug in usb drive the
> > kde file browser auto opens its content. Many other hotplug actions also
> > become active. I still discover other new capabilities which appeared
> > thanks to fixing dbus integration.
> > 
> > How about moving kde to /usr which is right place for it to have full kde
> > features enabled? I understand that in kde3/4 transition time it was right
> > to keep both of them in separate dirs. But now after someone brutally
> > smashed off kde3 from moonbase and knowing that there is no kde5 for a
> > long time why not moving kde4 to /usr?
> > 
> > Adding:
> > -DKDE4_AUTH_POLICY_FILES_INSTALL_DIR:STRING=/usr/share/PolicyKit/policy \
> > -DDBUS_INTERFACES_INSTALL_DIR:PATH=/usr/share/dbus-1/interfaces \
> > -DDBUS_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/services \
> > -DDBUS_SYSTEM_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/system-services \
> > -DSYSCONF_INSTALL_DIR:PATH=/etc \ <--- I'm not sure if it will work
> > 
> > to almost every kde module makes no sense. Not all files will be correctly
> > installed. For example there is no option for installing files in the
> > following right directories:
> > 
> > /usr/share/polkit-1/actions
> > 
> > k3b:
> > /etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf
> > /usr/share/dbus-1/system-services/org.kde.kcontrol.k3bsetup.service
> > 
> > kdebase4-workspace:
> > /etc/dbus-1/system.d/org.kde.fontinst.conf
> > /etc/dbus-1/system.d/org.kde.kcontrol.kcmclock.conf
> > /etc/dbus-1/system.d/org.kde.ksysguard.processlisthelper.conf
> > 
> > kdelibs4:
> > /etc/dbus-1/system.d/org.kde.auth.conf
> > /etc/dbus-1/system.d/org.kde.kcontrol.kcmremotewidgets.conf
> > 
> > Let's talk about pros/cons of moving kde to /usr
> > 
> > have a nice day,
> > Zbigniew Luszpinski
> 
> Yes. I am aware the policy kit stuff needs and has needed some attention. 
> Instead of moving everything to /usr; unless there is a consensus to do so. I 
> think I would rather see the appropriate CMake flags added to their respective 
> modules so some of the things you point out are thrown in the right system 
> directories.
> 


I'm all for moving it to /usr, that is where it should belong in the
first place. Everytime I've tried kde4 I moved the prefix to /usr,
always worked good for me without any conflicts. I don't see any reason
to keep it in /opt anymore.

-- 
Sincerely
Stefan Wold
Lunar Linux developer - PGP public key 6E810F05

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100710/863d6fe9/attachment-0001.bin>


More information about the Lunar-dev mailing list