Hi Sebastien. I was fearing this answer :P Thing is upstream doesn't seem to be responsive at all, we even joined the #gnome-hackers IRC channel and were told that it's quite unlikely that anyone answers because gconf has no upstream maintainer.
If something important breaks there somebody takes care of it, but it's not like there is somebody taking real care of it. I know this is a corner case, but it bites us. eBox (which we are trying to get into Ubuntu for Hardy) uses gconf as configuration backend. eBox is a web frontend for server configuration. apache2 blocks some signals and if gconfd is spawned from within apache2 it's not possible to terminate it gracefully. I realise that gconf is a quite critical component in Ubuntu, but the change is really small and not intrusive. In any case we have a relatively clean hack to deal with this issue in case gconf can't be patched in time for Hardy. Best regards -- gconfd does not unblock signals properly https://bugs.launchpad.net/bugs/188007 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
