DragonFlyBSD / DPorts

The dedicated application build system for DragonFly BSD
Other
89 stars 44 forks source link

kde4 upowerd core dumps because of polkit assertion #26

Closed jrmarino closed 9 years ago

jrmarino commented 11 years ago

gdb backtrace:

#0  0x281caefb in g_logv (log_domain=0x805d9f1 "UPower", log_level=G_LOG_LEVEL_ERROR, format=0x805ad34 "failed to get pokit authority: %s", 
    args=0xbfbff15c "@\003|( ?\027(\230\071\027(") at gmessages.c:967
#1  0x281caf8a in g_log (log_domain=0x805d9f1 "UPower", log_level=G_LOG_LEVEL_ERROR, format=0x805ad34 "failed to get pokit authority: %s")
    at gmessages.c:1003
#2  0x0804d329 in ?? ()
#3  0x2815ca02 in g_type_create_instance (type=678367672) at gtype.c:1890
#4  0x28145f54 in g_object_constructor (type=678367672, n_construct_properties=0, construct_params=0x0) at gobject.c:1855
#5  0x28145698 in g_object_newv (object_type=678367672, n_parameters=0, parameters=0x0) at gobject.c:1638
#6  0x28145488 in g_object_new (object_type=678367672, first_property_name=0x0) at gobject.c:1548
#7  0x0804d145 in ?? ()
#8  0x08052f0d in ?? ()
#9  0x2815ca02 in g_type_create_instance (type=678367616) at gtype.c:1890
#10 0x28145f54 in g_object_constructor (type=678367616, n_construct_properties=0, construct_params=0x0) at gobject.c:1855
#11 0x28145698 in g_object_newv (object_type=678367616, n_parameters=0, parameters=0x0) at gobject.c:1638
#12 0x28145488 in g_object_new (object_type=678367616, first_property_name=0x0) at gobject.c:1548
#13 0x08052c7c in ?? ()
#14 0x080571fb in ?? ()
#15 0x0804cb4d in ?? ()
#16 0x0804ca18 in ?? ()
#17 0x00000000 in ?? ()
jrmarino commented 11 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.

jrmarino commented 11 years ago

http://xfceonwheezy.blogspot.co.uk/2012/09/etcpolkit-1localauthority50.html

peeterm007 commented 9 years ago

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

rolinh commented 9 years ago

@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.

peeterm007 commented 9 years ago

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).

jrmarino commented 9 years ago

I've added your patch to dports, thanks!