Qingy-0.9.2 doesn't compile with crypto_openssl use flag enabled. It does however compile if that option is disabled. Here's the error it spits out: (...) i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../ -DSETTINGS_ DIR=\"/etc/qingy\" -DSBINDIR=\"/sbin/\" -pipe -W -Wall -O3 -mtune=pentium4 -fomi t-frame-pointer -pipe -MT crypto_openssl.lo -MD -MP -MF .deps/crypto_openssl.Tpo -c crypto_openssl.c -fPIC -DPIC -o .libs/crypto_openssl.o crypto_openssl.c: In function 'encrypt_item': crypto_openssl.c:55: warning: pointer targets in passing argument 2 of 'RSA_publ ic_encrypt' differ in signedness crypto_openssl.c:55: warning: pointer targets in passing argument 3 of 'RSA_publ ic_encrypt' differ in signedness crypto_openssl.c:59: error: 'QINGY_FAILURE' undeclared (first use in this functi on) crypto_openssl.c:59: error: (Each undeclared identifier is reported only once crypto_openssl.c:59: error: for each function it appears in.) crypto_openssl.c: In function 'decrypt_item': crypto_openssl.c:80: warning: pointer targets in passing argument 2 of 'RSA_priv ate_decrypt' differ in signedness crypto_openssl.c:80: warning: pointer targets in passing argument 3 of 'RSA_priv ate_decrypt' differ in signedness crypto_openssl.c: In function 'restore_public_key': crypto_openssl.c:138: error: 'QINGY_FAILURE' undeclared (first use in this funct ion) i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../ -DSETTINGS_ DIR=\"/etc/qingy\" -DSBINDIR=\"/sbin/\" -pipe -W -Wall -O3 -mtune=pentium4 -fomi t-frame-pointer -pipe -MT vt.lo -MD -MP -MF .deps/vt.Tpo -c vt.c -fPIC -DPIC -o .libs/vt.o make[4]: *** [crypto_openssl.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... (...) So it seems to be a problem upstream.. I'll check it out. My "emerge --info": Portage 2.1.2_rc1 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz Gentoo Base System version 1.12.5 Last Sync: Sat, 28 Oct 2006 12:30:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.2.3-r6, 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -mtune=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O3 -mtune=pentium4 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="pt_PT@euro" LINGUAS="pt" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac acpi aiglx alsa apache2 apm berkdb bitmap-fonts bzip2 cairo cdparanoia cdr cli cracklib crypt crypto_openssl cups directfb divx4linux dlloader dri dvd dvdr dvdread elibc_glibc encode fbcon font-server fortran gcj gdbm gecko-sdk gif glibc-compat20 glut gpm gstreamer gtk gtk2 hal iconv input_devices_keyboard input_devices_mouse isdnlog jack java jpeg kernel_linux libg++ linguas_pt lirc lirc_devices_pctv live mad matroska mmx mmxext mozsvg mp3 mpeg mppe-mppc ncurses network nls nptl nptlonly nvidia offensive ogg opengl pam pcre pdf perl png ppds pppd python qt3 qt4 quicktime readline reflection samba sdl session sndfile sox spell spl sse sse2 ssl svg tcpd threads tiff tls truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l v4l2 video_cards_nv video_cards_nvidia video_cards_v4l video_cards_vesa videos vorbis win32codecs x264 xml xml2 xorg xpm xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Ok, the problem is definitely upstream. I've sent an email to the creator hoping it gets corrected soon. It was a simple bug, so I'll create a patch for it for now.
While you're at it, please unify the use flags. Use the global crypto flag for libgcrypt and change crypto_openssl to opensslcrypt, which matches with what the proftpd ebuild is using locally.
(In reply to comment #2) > While you're at it, please unify the use flags. Use the global crypto flag for > libgcrypt and change crypto_openssl to opensslcrypt, which matches with what > the proftpd ebuild is using locally. > I didn't quite understand the libgcrypt part. What should be the use flag? BTW is there any documentation on the "official" use flags? I ask this because I usually end up searching for that stuff here in bugzilla and in the forums, and you can see it isn't the easyest thing to search..
Created attachment 100711 [details, diff] The patch to make openssl compile This patch corrects the compilation problem. As soon as I understand the USE flags change I'll review the ebuild.
(In reply to comment #3) > BTW is there any documentation on the "official" use flags? There are no strict rules for use flag naming. It's all about common sense and adjusting, when appropriate. We differ between (ebuild) local and global use flags. When a local use flag gets used by a handful of packages, it becomes global sooner or later. >> /usr/portage/profiles/use.*
(In reply to comment #2) > While you're at it, please unify the use flags. Use the global crypto flag for > libgcrypt and change crypto_openssl to opensslcrypt, which matches with what > the proftpd ebuild is using locally. Uhm, opensslcrypt as a USE flag sounds good, but libgcryptcrypt (libgcrypt is the other crypto package supported by qingy) definitely does not, libgcrypt is incorrect syntax-wise, and I'm against changing crypto_openssl but maintaining crypto_libgcrypt... what do you think?
(In reply to comment #4) > This patch corrects the compilation problem. > As soon as I understand the USE flags change I'll review the ebuild. Have you tried whether the patched (it should be EXIT_FAILURE, not GUI_FAILURE, btw) version actually works? On my own system it does not, failing in a subtle way when compiled non-statically. This is the reason I haven't fixed this one, yet. If I don't find a solution quickly, I think I'll just remove crypto_openssl from this version USE flags...
(In reply to comment #6) > Uhm, opensslcrypt as a USE flag sounds good, but libgcryptcrypt (libgcrypt is > the other crypto package supported by qingy) definitely does not, libgcrypt is > incorrect syntax-wise, and I'm against changing crypto_openssl but maintaining > crypto_libgcrypt... what do you think? What do you mean with "incorrect syntax-wise"? The "crypt" use flag isn't specific to any library and is absolutely fine to use.
(In reply to comment #8) > What do you mean with "incorrect syntax-wise"? The "crypt" use flag isn't > specific to any library and is absolutely fine to use. Uh, now I understood your message fully... forget what I wrote earlier! Well, I can't say I like crypt for libgcrypt and opensslcrypt for openssl, as there is no indication in crypt that it will bring in libgcrypt... I prefer self-explicative names whenever possible. Moreover, afaik crypt should be used to select whether or not encryption should be enabled, not to prefer one package over another (with the exceptions of mcrypt and gpg, but that is arguable, too). Anyway, if you still think this this is the best route to follow, I can make the necessary adjustments...
Fixed (openssl compilation as well as USE flags). Thank you for the time, comments, and efforts...
