checking for XScreenSaverQueryInfo in -lXss... yes
configure: Support for DirectFB is disabled
checking for CONSOLEKIT... no
configure: error:
*** ConsoleKit is required when --disable-consolekit is not given.

I debugged and found the reason is PKG_CONFIG env-var is empty when executing PKG_CHECK_MODULES macro in ./configure.

after this the new ebuild got installed and new qingy work well, so it's definitely the PKG_CONFIG reason:

Code:

export PKG_CONFIG=pkg-config
emerge qingy

I have only few knowledge with the spec of autotools and portage, and didn't find anything useful on web.
I want to know who is in charge for setting this env-var and when should it be set?

the qingy-1.0.0 ebuild uses PKG_CHECK_MODULES either, to check if DirectFB presents.
Although i didn't test it but i think there's no problem.
So perhaps my autoreconf is wrong?

pkg_postinst()
{
einfo "In order to use qingy you must first edit your /etc/inittab"
einfo "Check the documentation at ${HOMEPAGE}"
einfo "for instructions on how to do that."
echo
einfo "Also, make sure to adjust qingy settings file (/etc/qingy/settings)"
einfo "to your preferences/machine configuration..."

if use crypt; then
echo
einfo "You will have to create a key pair using 'qingy-keygen'"
echo
ewarn "Note that sometimes a generated key-pair may pass the internal tests"
ewarn "but fail to work properly. You will get a 'regenerate your keys'"
ewarn "message. If this is your case, please remove /etc/qingy/public_key"
ewarn "and /etc/qingy/private_key and run qingy-keygen again..."
fi

use emacs && echo && elisp-site-regen
}

pkg_postrm() {
use emacs && elisp-site-regen
}

Last edited by fpemud on Sun Oct 07, 2012 7:21 am; edited 4 times in total

I hope you're able to figure this out. I really need this ebuild, as it looks like I need properly functioning consolekit in order to get multiuser pulseaudio working, and the non-svn qingy doesn't work properly with it. Please post here whatever you come up with, and I'll help you with it.

[edit: I was just looking at the ebuild and noticed that you had called svn_src_unpack, and I couldn't figure out how that function would be available, until I noticed that you had inherited that eclass in an "if" statement. Based on ebuilds I've worked with in the past, I don't believe this is standard procedure. There is no need to conditionally inherit subversion, because *-9999 ebuilds will not (or at least should not) be used as the basis for making non-VCS ebuilds. Instead, just inherit subversion as part of the main "inherit" line, and it will make it easier for people to maintain this ebuild.]

Ok, I got impatient and wrote a new ebuild myself. It's pretty much the same as yours, except it doesn't have any conditional inheritances. I just tried it, and it emerged successfully. Now I suspect that your problem is that you have some sort of misconfiguration in your system that prevents autotools from finding pkg-config. To check this, I recommend you check and see if you are able to compile (not emerge) any program that uses autotools. You have to make sure that the source tree does not contain any autotools generated stuff in it, and for good measure you should make sure there are no object files in there either. If you are able to compile it, I was probably wrong. If you are not, then having a misconfigured setup is most likely. There is also the possibility that you could have a subtle configuration issue that affects some autotools programs and not others (i.e. if qingy's configuration system uses an incorrect method to find pkg-config.). Looking over the old non-9999 qingy ebuild today, that seems quite likely. That older ebuild doesn't inherit autotools, and I see no calls to "auto" anything, so it looks like Michele Noberasco just started using autotools, and may well have made some errors. The notorious difficulty of the autotools build system could also explain why Michele has not come out with a new release in a long time. Everything he has stated online regarding qingy indicates that qingy is not a dead project. Getting enough testing to confirm that the new consolekit compatibility in qingy is implemented correctly could also be a problem holding up a release. In any case, here is the new ebuild. Once I'm able to verify that the binary actually runs, I will submit this to B.G.O. :

pkg_postinst()
{
einfo "In order to use qingy you must first edit your /etc/inittab"
einfo "Check the documentation at ${HOMEPAGE}"
einfo "for instructions on how to do that."
echo
einfo "Also, make sure to adjust qingy settings file (/etc/qingy/settings)"
einfo "to your preferences/machine configuration..."

if use crypt; then
echo
einfo "You will have to create a key pair using 'qingy-keygen'"
echo
ewarn "Note that sometimes a generated key-pair may pass the internal tests"
ewarn "but fail to work properly. You will get a 'regenerate your keys'"
ewarn "message. If this is your case, please remove /etc/qingy/public_key"
ewarn "and /etc/qingy/private_key and run qingy-keygen again..."
fi

If you look here: http://qingy.svn.sourceforge.net/viewvc/qingy/trunk/qingy/ChangeLog?view=log, you can see on the second entry down (revision 434), "still need to work on proper ./configure and stuff". So it definitely looks to me like there is just a little hiccup in the way your pkg-config stuff gets figured out. Probably by any of the proper methods, autotools should be able to find it, but if an improper method is used, as in the case of qingy, it will find something misconfigured, but only on your system or any that have the same issue. I know very little about autotools, in fact I really dislike autotools, but if you really are able to compile other autotools programs then you should be able to get help with another post somewhere on the gentoo forums, or on irc at freenode, #gentoo. Good Luck!