Closed jrmarino closed 9 years ago
http://www.mentby.com/Group/freebsd-questions/policykit-confusion.html
You also need a file in
/usr/local/etc/polkit-1/localauthority/50-local.d if you want to
shutdown/restart your machine
[Restart]
Identity=unix-group:username
Action=org.freedesktop.consolekit.system.restart
ResultAny=yes
ResultInactive=yes
ResultActive=yes
[Shutdown]
Identity=unix-group:username
Action=org.freedesktop.consolekit.system.stop
ResultAny=yes
ResultInactive=yes
ResultActive=yes
If this is really needed, a pre-filled one should be installed by the port. Apparently this is mentioned in so message that comes up when the polkit is installed but I didn't see it. It must have scrolled off.
Hello
I do not know if this patch resolves the crash of upowerd since, even without the patch, upowerd under kde4 did not crash. But it definitely did not run either since polkitd was not working at all and as a result kde4 power management failed:
---KDE4---BEFORE glib20 patch--- kded(187211) PowerDevil::BackendLoader::loadBackend: Loading HAL backend... kded(187211) PowerDevil::BackendLoader::loadBackend: Failed! kded(187211): KDE Power Management System init failed!
With the patch applied to glib20, upowerd runs fine (since polkitd runs fine as long as system dbus and hald are running) and kde4 is happy as far as power management and upowerd go:
---KDE4---AFTER glib20 patch--- kded(213382) PowerDevil::BackendLoader::loadBackend: Loading HAL backend... kded(213382) PowerDevil::BackendLoader::loadBackend: Success! kded(213382) KDEDPowerDevil::init: Backend loaded, loading core kded(213382) PowerDevil::Core::loadCore: Core loaded, initializing backend kactivitymanagerd(213392)/nepomuk (library): Could not find virtuoso backend kactivitymanagerd(213392)/nepomuk (library): Could not find virtuoso to connect to. Aborting kded(213382) PowerDevil::Core::onBackendReady: Backend is ready, KDE Power Management system initialized
It's a small patch for glib20 to be placed in devel/glib20/dragonfly/
I thought it a good idea to try and submit the patch to the glib people so there'd be less work for DPorts in the future. However, it will also it may arrive in DPorts only in a few months, depending on the release schedule of glib and FreeBSD ports. Can you tell me what is the best way to approach such cases in the future?
In any case the patch is here
https://github.com/peeterm007/patches/blob/master/patch-gio_gcredentialsprivate.h
Thanks
Peeter
@peeterm007 Best approach? Submit the patch here so that it can be included into dports and submit it upstream as well (assuming the patch is clean). This way, we benefit from the patch in dports and it can then be removed when it is merged upstream, assuming it gets accepted.
Thanks, apparently has been committed in glib now:
https://github.com/GNOME/glib/blob/master/gio/gcredentialsprivate.h
DPorts can then benefit from the one submitted above (it is identical to the one submitted to glib).
I've added your patch to dports, thanks!
gdb backtrace: