Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
qca2 (http://delta.affinix.com/download/qca/2.0/) is in beta, and is able to live alongside qca1. Therefore, qca should be slotted.
Hi! (In reply to comment #0) > qca2 (http://delta.affinix.com/download/qca/2.0/) is in beta, and is able to > live alongside qca1. Therefore, qca should be slotted. if you unpack source tarball, take a look on qca.pc file for example there is info on how to link with qca2: -lqca ----> it is just the same as with qca-1. from my point of view, if we want to have both versions in gentoo, we would have to start changing _every_ package that depend on at least on of qca versions (1 or 2). making distribution related packages is hard and quite ineffected. if I am right (and I think I am) this isn't a good idea. anyway - just my 2 cents :) different thing is to make sloted package for testing and making it hardmasked - why not? only those who will knew what they are doing (at least they should ;) ), could install this version. for now, there aren't many packages that could use this version of qca-2, but kde-4 is closer to be released, every day :) hmmm... and last : general update ebuild is a good idea - but without slotting. I'll make one. Regards, Przemek
A forum thread discussing the issues of gentoo and qca: http://forum.psi-im.org/post/27796
well... we may put into all ebuilds configure --with-qca-lib=/bla/bla/lqca2 but it isn't a good thing. gentoo is _meta_ distribution, so we _may_ do something like this. on the other hand - then developer responsible for qca packages would have a really hard live, to test all qca packages, to update all packages, etc. as you can see - imho, we _may_ do it. there are two questions now: - who wants to test all of packages that depends on qca{1,2}? - how many packages depends on qca? if this is only a metter of psi - this can be done very easily. qca2 will be part - right? - of new kde4, so we need it anyway. ok. I'm starting the investigation :) Regards, Przemek
Ok. Finally got some time free :) I searched for ebuilds that depends on qca and here's the list: app-crypt/qca/qca-1.0-r2.ebuild app-crypt/qca-tls/qca-tls-1.0.ebuild app-crypt/qca-tls/qca-tls-1.0-r2.ebuild app-crypt/qca-tls/qca-tls-1.0-r3.ebuild games-fps/quake1-killer/quake1-killer-2.2z.ebuild kde-base/kdenetwork/kdenetwork-3.3.2-r2.ebuild kde-base/kdenetwork/kdenetwork-3.4.1-r1.ebuild kde-base/kdenetwork/kdenetwork-3.4.2.ebuild kde-base/kdenetwork/kdenetwork-3.4.3.ebuild kde-base/kdenetwork/kdenetwork-3.5.2.ebuild kde-base/kopete/kopete-3.4.1-r1.ebuild kde-base/kopete/kopete-3.4.2.ebuild kde-base/kopete/kopete-3.4.3.ebuild kde-base/kopete/kopete-3.5.2.ebuild media-video/gqcam/gqcam-0.9.ebuild net-im/kopete/kopete-0.12_beta2-r1.ebuild net-im/psi/psi-0.10.ebuild net-im/psi/psi-0.9.3-r1.ebuild net-im/psi/psi-0.9.3-r2.ebuild net-im/psi/psi-0.9.3-r3.ebuild net-im/psi/psi-0.9.3-r4.ebuild net-misc/asterisk/asterisk-1.2.7_p1.ebuild net-misc/asterisk/asterisk-1.2.7_p1-r1.ebuild sci-misc/qcad/qcad-2.0.4.0-r1.ebuild sci-misc/qcad/qcad-2.0.4.0-r2.ebuild sci-misc/qcad/qcad-2.0.4.0-r3.ebuild sci-misc/qcad-parts/qcad-parts-2.0.1.2.ebuild sci-misc/qcad-parts/qcad-parts-2.0.1.2-r1.ebuild it's not to big, but still this is 10 apps that depends on qca1. I would do it like this now: - let us put slotted qca2beta2 ebuild into portage - hardmask it with this situation we're giving a way for installing new version of qca, along with previous one. next move would be to contact projects programmers and find out, which of them are migrating to qt4 with qca2 (most of them is, from what I know). Gustavo - what do you think? we could play with psi-0.11 in portage then :) Regards, Przemek
Created an attachment (id=89430) [edit] qca-2.0_beta2.ebuild Ok. I finally finished ebuild for slotted version of qca-2_beta2 I look into /usr/lib/pkgconfig and rename the library from libqca to libqca-2 (simply: I add version number to library filename). Generally - this is _bad_ idea, since qca is not doing it by its own (maybe we could mail qca author about this?). Solution like this is natural for pakcages like pangomm or sigc++. Tommorow I'll play with psi. I believe this should be quick from now, to build test psi version now. If anybody can try qca2 ebuild (espessialy on archs different then x86) or with debug use flag (for this qt has to be build with debug!): plz report about your tests :) Regards, Przemek
Created an attachment (id=89431) [edit] qca-allow_slotting.patch
Created an attachment (id=89432) [edit] qca-2.0_beta2.ebuild very small cleanups :)
Ok... just before I'll sleep on my keyboard. I made ebuilds for all qca-2 plugins, that are available with beta2 version. You can view/download them from http://bugs.gentoo.org/show_bug.cgi?id=137132 Regards, Przemek
Created an attachment (id=89488) [edit] qca-2.0_beta2.ebuild small update: - better debug USE flag handling I just tested ebuild with qt built with debug USE flag - everything looks good :)
Created an attachment (id=89489) [edit] qca-allow_slotting.patch corrected patch - previous version was broken, when compiling with USE="debug". this one was just tested. Regards, Przemek
Created an attachment (id=89490) [edit] qca-2.0_beta2.ebuild sorry - I didn't upload latest ebuild version :/ Regards, Przemek
Just added to sunrise overlay
Hi, i have problem build qca2: g++ -c -pipe -O2 -march=athlon64 -pipe -fomit-frame-pointer -fgcse-after-reload -Wall -W -D_REENTRANT -fPIC -DBOTAN_TYPES_QT -DBOTAN_NO_INIT_H -DBOTAN_NO_CONF_H -DBOTAN_TOOLS_ONLY -DBOTAN_MINIMAL_BIGINT -DBOTAN_MP_WORD_BITS=32 -DBOTAN_VECTOR_OVER_ALLOCATE=4 -DQCA_SYSTEMSTORE_PATH="/etc/ssl/certs/ca-certificates.crt" -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I/home/tmp/portage/app-crypt/qca-2.0_beta2/work/qca-2.0-beta2/src -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4 -I../include/QtCrypto -I. -I/home/tmp/portage/app-crypt/qca-2.0_beta2/work/qca-2.0-beta2/src/botantools/botan -I.moc -I. -o .obj/qca_systemstore_flatfile.o qca_systemstore_flatfile.cpp qca_systemstore_flatfile.cpp: In function ‘bool QCA::qca_have_systemstore()’: qca_systemstore_flatfile.cpp:28: error: expected primary-expression before ‘/’ token qca_systemstore_flatfile.cpp:28: error: ‘etc’ was not declared in this scope qca_systemstore_flatfile.cpp:28: error: ‘ssl’ was not declared in this scope qca_systemstore_flatfile.cpp:28: error: ‘certs’ was not declared in this scope qca_systemstore_flatfile.cpp:28: error: ‘ca’ was not declared in this scope qca_systemstore_flatfile.cpp:28: error: ‘certificates’ was not declared in this scope qca_systemstore_flatfile.cpp: In function ‘QCA::CertificateCollection QCA::qca_get_systemstore(const QString&)’: qca_systemstore_flatfile.cpp:34: error: expected primary-expression before ‘/’ token qca_systemstore_flatfile.cpp:34: error: ‘etc’ was not declared in this scope qca_systemstore_flatfile.cpp:34: error: ‘ssl’ was not declared in this scope qca_systemstore_flatfile.cpp:34: error: ‘certs’ was not declared in this scope qca_systemstore_flatfile.cpp:34: error: ‘ca’ was not declared in this scope qca_systemstore_flatfile.cpp:34: error: ‘certificates’ was not declared in this scope make[1]: *** [.obj/qca_systemstore_flatfile.o] Error 1 ------------ Reason for this is: -DQCA_SYSTEMSTORE_PATH="/etc/ssl/certs/ca-certificates.crt" in compiler parameters, in qca_systemstore_flatfile.cpp: 28/34 is expected string "/etc/ssl/certs/ca-certificates.crt" but quotes are omited ..... with -DQCA_SYSTEMSTORE_PATH='"/etc/ssl/certs/ca-certificates.crt"' works well. ---------------------------- Portage 2.1.2-r1 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.18-gentoo-r3-v0000 x86_64) ================================================================= System uname: 2.6.18-gentoo-r3-v0000 x86_64 AMD Sempron(tm) Processor 3400+ Gentoo Base System version 1.12.9 Timestamp of tree: Sun, 21 Jan 2007 01:50:02 +0000 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 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.19.2-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe -fomit-frame-pointer -fgcse-after-reload -freorder-blocks-and-partition" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /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/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=athlon64 -pipe -fomit-frame-pointer -fgcse-after-reload" DISTDIR="/mnt/storage/gentoo/distfiles" FEATURES="autoconfig buildpkg distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo" LANG="cs_CZ.UTF-8" LC_ALL="cs_CZ.UTF-8" LINGUAS="cs en en_US en_GB" MAKEOPTS="-j1" PKGDIR="/mnt/storage/gentoo/packages-x86_64" 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://ftp.sh.cvut.cz/gentoo-portage" USE="7zip X a52 aac alsa amd64 ao apache2 async audiofile avahi bash-completion bidi bitmap-fonts blas branding browserplugin bzip2 cairo cdda chroot cli cracklib crosscompile crypt cups curl dba dbus dedicated divx dlloader dri dts dv dvb dvd dvdread enca encode exif extras fam ffmpeg firefox flac fontconfig fuse gcc64 gd gdbm gif ginac glib glut gmedia gnome gnutls gphoto2 grammar gs gstreamer gtk hal hdf5 howl hpn httpd iconv idn ieee1394 ilbc imagemagick imlib iproute2 ipv6 isdnlog jack javascript jbig jingle jpeg jpeg2k kde kqemu lcms libg++ live logitech-mouse logrotate lzo mad mailwrapper math matroska mikmod mmap mng mod mp3 mp3rtp mpeg musepack mysql nas ncurses netboot network nfs nls no-old-linux no-suexec nptl nptlonly ntfs objc ogg openal openexr opengl pam pam_chroot pam_console pcre pdf perl php pic plotutils png ppds pppd python qhull qmax qt qt3 rdesktop readline reflection rle rogue rss rtc rtsp samba screen sdl sensord server session shout slang sndfile source speex spell spl ssl stream svg t1lib test theora thesaurus threads tiff tk truetype truetype-fonts type1-fonts udev unicode usb v4l v4l2 vcd vhosts vim-pager vlm vorbis wxwindows x264 xatrix xforms xine xinerama xml xml2 xorg xosd xpm xv xvid zip zlib" ALSA_CARDS="ad1848-lib ad1889 ali5451 als300 als4000 atiixp atiixp-modem au8810 au8820 au8830 azt3328 bt87x ca0106 cmipci cs4281 cs46xx darla20 darla24 dummy echo3g emu10k1 emu10k1x ens1370 ens1371 fm801 gina20 gina24 hda-intel hdsp hdspm ice1712 ice1724 indigo indigodj indigoio intel8x0 intel8x0m korg1212 layla20 layla24 loopback maestro3 mia mixart mona mpu401 mtpav mts64 nm256 pcxhr pdplus portman2x4 riptide rme32 rme96 rme9652 seq-dummy serial-u16550 soc sonicvibes trident usb-audio usb-usx2y via82xx via82xx-modem virmidi vx222 ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" DVB_CARDS="dibusb-usb1 dibusb-usb2 or51132 or51211 ttpci usb-a800 usb-dtt200u usb-umt usb-vp702x usb-vp7045 usb-wt220u nxt200x sp8870 sp887x tda1004x ttusb-dec" ELIBC="glibc" INPUT_DEVICES="acecad aiptek calcomp citron digitaledge dmc dynapro elo2300 elographics evdev fpit hyperpen jamstudio joystick keyboard magellan magictouch microtouch mouse mutouch palmax penmount spaceorb summa synaptics tek4957 ur98 vmmouse void" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="cs en en_US en_GB" USERLAND="GNU" VIDEO_CARDS="apm ark ati chips cirrus cyrix dummy fbdev glint i128 i810 mga neomagic nouveau nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS ---------------------------------
(In reply to comment #13) > Hi, > > i have problem build qca2: <cut> :/ same here. > Reason for this is: > -DQCA_SYSTEMSTORE_PATH="/etc/ssl/certs/ca-certificates.crt" > in compiler parameters, in qca_systemstore_flatfile.cpp: 28/34 is expected > string "/etc/ssl/certs/ca-certificates.crt" but quotes are omited ..... > > with > -DQCA_SYSTEMSTORE_PATH='"/etc/ssl/certs/ca-certificates.crt"' > works well. if you look into conf.pri file, there is: DEFINES += QCA_SYSTEMSTORE_PATH='"/etc/ssl/certs/ca-certificates.crt"' so this should work for qca... I'll try to find a problem here. anyway - qca2 isn't needed for newest psi - I'm using the one, that is in psi sources. new beta for qca2 should be out month ago... :/ Thx for info. I'll check this. Cheers, Przemek
Created an attachment (id=107740) [edit] qca-2.0_beta2-qca_systemstore_path.patch solution taken from psi
Created an attachment (id=107742) [edit] qca-2.0_beta2.ebuild updated ebuild
Created an attachment (id=119929) [edit] qca-2.0.0_beta5.ebuild version bump to beta5
Created an attachment (id=119930) [edit] qca-2.0.0-beta5-allow_slotting.patch patch to allow qca slotting
qca2 is now part of kde4. unfortunately - there's no qca2 in portage for now and I would like to use it for psi-0.11_rc1. I planning to add it into portage in next 24h, unless somebody is against. psi will be now the only app that uses this qca, so even when we add kde4 into portage, it should be simple to change this single package. Best regards, Przemek
Created an attachment (id=119932) [edit] qca-2.0.0_beta5.ebuild minor problem : I forgot to add sed into DEPEND :) Cheers, Przemek
Troll, no objections from me but sys-apps/sed is part of the base system profile and as we only have sed-4* in Portage, the DEPEND on it shouldn't be necessary.
Created an attachment (id=119942) [edit] qca-2.0.0_beta5.ebuild (In reply to comment #21) > Troll, no objections from me but sys-apps/sed is part of the base system > profile and as we only have sed-4* in Portage, the DEPEND on it shouldn't be > necessary. obviously - you're right. changes: - removed sed from DEPEND - fixed download location Cheers, Przemek
qca-2.0.0_beta5 does not compile here (~amd64) with MAKEOPTS="-j1" make[2]: Entering directory `/var/tmp/portage/app-crypt/qca-2.0.0_beta5/work/qca-2.0.0-beta5/tools/mozcerts' g++ -c -pipe -O2 -march=nocona -fomit-frame-pointer -pipe -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I/var/tmp/portage/app-crypt/qca-2.0.0_beta5/work/qca-2.0.0-beta5/tools/mozcerts -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4 -I../../include/QtCrypto -I. -I. -o main.o main.cpp g++ -o mozcerts main.o -L/usr/lib64/qt4 -L../../lib -lqca2 -lQtCore -L/usr/lib64 -L/usr/lib64/qt4 -lz -lm -pthread -lgthread-2.0 -lrt -lglib-2.0 -ldl -lpthread /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lqca2 collect2: ld returned 1 exit status make[2]: *** [mozcerts] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-crypt/qca-2.0.0_beta5/work/qca-2.0.0-beta5/tools/mozcerts' make[1]: *** [sub-mozcerts-make_default] Error 2 make[1]: Leaving directory `/var/tmp/portage/app-crypt/qca-2.0.0_beta5/work/qca-2.0.0-beta5/tools' make: *** [sub-tools-make_default] Error 2 !!! ERROR: app-crypt/qca-2.0.0_beta5 failed. Call stack: ebuild.sh, line 1615: Called dyn_compile ebuild.sh, line 972: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile qca-2.0.0_beta5.ebuild, line 80: Called die !!! make failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/app-crypt/qca-2.0.0_beta5/temp/build.log'. emerge --info Portage 2.1.2.7 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r2, 2.6.21-gentoo-r1-mactel x86_64) ================================================================= System uname: 2.6.21-gentoo-r1-mactel x86_64 Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz Gentoo Base System release 2.0.0_alpha3 Timestamp of tree: Mon, 21 May 2007 14:20:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 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.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /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/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict userfetch" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ ftp://ftp.unina.it/pub/linux/distributions/gentoo" LANG="it_IT" LC_ALL="it_IT" LINGUAS="it" MAKEOPTS="-j3" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/pesa" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X Xaw3d a52 aac acl acpi aim alsa amd64 avahi bash-completion bitmap-fonts blas bluetooth bzip2 cairo caps cddb cdparanoia cdr cli cracklib crypt curl curlwrappers dbus directfb dri dts dv dvd dvdr dvdread emboss encode evo exif expat fam fbcon ffmpeg fftw firefox flac ftp gd gdbm gif glut gnutls gpm graphviz hal iconv icq idn ieee1394 imagemagick imlib ipod ipv6 isdnlog jabber java javascript jbig jpeg jpeg2k kde kdeenablefinal kdexdeltas lapack lcms libg++ libsamplerate lirc lm_sensors lua mad mailwrapper matroska midi mikmod mmap mmx mng mp3 mpeg mplayer msn mudflap musepack musicbrainz ncurses nls nptl nptlonly nsplugin offensive ogg opengl openmp oscar oss pam pcmcia pcre pdf perl plotutils png posix pppd python qt3 qt3support qt4 quicktime readline reflection ruby samba sasl sdl session slang sndfile snmp sockets socks5 speex spell spl sqlite sqlite3 sse sse2 ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts unicode usb v4l vcd vorbis wifi wmf x264 xcomposite xine xinerama xml xorg xpm xv xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="it" LIRC_DEVICES="inputlirc sir" USERLAND="GNU" VIDEO_CARDS="fglrx radeon vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Quick question: Why do you use qmake before make? I tried without this and it seems OK.
Oh... And I think the side-by-side should also handle: /usr/lib/pkgconfig/qca.pc -> /usr/lib/pkgconfig/qca2.pc And what about the include path?
Created an attachment (id=120041) [edit] qca-2.0.0_beta5.ebuild - alternative Hello, Just another alternative for side-by-side and some fixups. 1. Use --qtdir and not QTDIR, the current ebuild QTDIR was not found anyway... You can see this if you add --verbose to configure. 2. I've removed the qmake stange, can someone explain why it is needed, is it in order to add "CONFIG += no_fixpath", if so, what does it do? 3. Side-by-side is as follows: /usr/include/qca2/XXX /usr/lib/qca2/XXX Just like qt, I think it is better, much less modifications and no name change. I've asked upstream to add --includedir option to configure. 4. There is parallel build issue, so I switched into -j1, reported to upstream. 5. Upstream wish to strip the binaries anyway... So maybe we should mask off the QA warning.
(In reply to comment #26) Your alternative ebuild compiles fine here, thanks. But now another issue arises: qca-openssl-0.1_p20070508 ebuild from bug #137132 dies with the following error... >>> Compiling source in /var/tmp/portage/app-crypt/qca-openssl-0.1_p20070508/work/qca-openssl-0.1-20070508 ... Configuring qca-openssl ... Verifying Qt 4 build environment ... ok Checking for QCA 2.0 ... no Error: need QCA 2.0! !!! ERROR: app-crypt/qca-openssl-0.1_p20070508 failed. Call stack: ebuild.sh, line 1615: Called dyn_compile ebuild.sh, line 972: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile qca-openssl-0.1_p20070508.ebuild, line 62: Called die !!! configure failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/app-crypt/qca-openssl-0.1_p20070508/temp/build.log'.
Created an attachment (id=120090) [edit] qca-2.0.0_beta5.ebuild OK. Works now with plugins as well. Feel free to remove any of this... :)
(In reply to comment #28) > Created an attachment (id=120090) [edit] > qca-2.0.0_beta5.ebuild > > OK. > Works now with plugins as well. > Yep, I can confirm that the last ebuild finally builds and works on ~amd64! Compiling psi-0.11_rc1 against it right now... :) Thanks a lot!
Created an attachment (id=120103) [edit] qca-2.0.0_beta5.ebuild pc file fixup.
Can you please use sed -i -e "" to be platform independant. Only GNU allows to omit -e Can you please commit this hard masked - after all it is only for the psi beta which is also hard masked ;)
(In reply to comment #31) > Can you please use sed -i -e "" to be platform independant. Only GNU allows to > omit -e I think that the -i is the none standard one... The -e is optional since before the beginning of time. http://www.opengroup.org/onlinepubs/007908775/xcu/sed.html
(In reply to comment #26) > Created an attachment (id=120041) [edit] > qca-2.0.0_beta5.ebuild - alternative > > 2. I've removed the qmake stange, can someone explain why it is needed, is it > in order to add "CONFIG += no_fixpath", if so, what does it do? one of many bugzilla reasons that I remember: https://bugs.gentoo.org/show_bug.cgi?id=72545 ;) also, while executing qmake you can add C{,XX}FLAGS to Makefiles. > 3. Side-by-side is as follows: > /usr/include/qca2/XXX > /usr/lib/qca2/XXX > > Just like qt, I think it is better, much less modifications and no name change. yes and no :) qt3 is located at /usr/qt/3 and qt4 is located at /usr/lib/qt4 - without -L/usr/some/dir no qt library is selected by default, because none of them is in standard /usr/lib. qca-1 is installed at /usr/lib and (I'm not sure of it) -lqca will gave qca-1 as standard lib. --- Also I found my sed to be broken on amd64, when it is used in src_unpack, but I see you also found that ;) Cheers, Przemek
(In reply to comment #33) > (In reply to comment #26) > > 3. Side-by-side is as follows: > > /usr/include/qca2/XXX > > /usr/lib/qca2/XXX a bit to fast :/ I like the idea of /usr/XXX/qca2 directories. still - I would vote to change it's name. same name for two different libraries always leads to problems... Cheers, Przemek
I've just tested compilation of qca-openssl-0.1(pre...) with qca2 being installed in /usr/lib/qca2 without changing it's name: <cut> Verifying Qt 4 build environment ... ok Checking for QCA 2.0 ...sh: line 1: 3562 Segmentation fault ./atest 2> /dev/null no Error: need QCA 2.0! <cut> --- I'm a bit tired (studies and work are killing sometimes ;) ), but as I see it with or without name changed, we have to patch packages, that depends on qca. Maybe it would be nice to ask upstream, what they think about this? Cheers, Przemek
Already had: http://lists.affinix.com/pipermail/delta-affinix.com/2007-May/000903.html
(In reply to comment #35) > I've just tested compilation of qca-openssl-0.1(pre...) with qca2 being > installed in /usr/lib/qca2 without changing it's name: > > <cut> > Verifying Qt 4 build environment ... ok > Checking for QCA 2.0 ...sh: line 1: 3562 Segmentation fault ./atest 2> > /dev/null > no > > Error: need QCA 2.0! > <cut> > Oh... Maybe we should also patch qca1 in to /usr/lib/qca1/XXX? How is this handled with Qt? I guess someone must set LD_LIBRARY_PATH currectly at build time. Alon.
Please try the new ebuilds of plugins. Thanks!
Thinking about it... It is very strnage... The ./configure uses -L/usr/lib/qca2 -lqca, so it will be linked against qca.so.2.0.0, so it should be able to be loaded correctly. So the last modifications of the plugins should not solve anything... Please add --verbose to configure and attach the log. Thanks!
Latest ebuilds of qca-2.0.0_beta5 and qca-openssl-0.1_p20070508 from bug #137132 (comment #25) build and work fine here (testing with psi-0.11_rc1).
troll: I am waiting for your reply... Upstream will fix side-by-side in beta6, but I need to know what is happening on your side.
(In reply to comment #41) > troll: I am waiting for your reply... Upstream will fix side-by-side in beta6, > but I need to know what is happening on your side. sorry I keep you waiting, just give me an hour and I will post everything. Cheers, Przemek
(...) g++ -o psi .obj/bytestream.o .obj/bsocket.o (...) a lot of .o (...) .obj/moc_opt_shortcuts.o .obj/moc_main.o .obj/qrc_psi.o .obj/qrc_iconsets.o -L/usr/lib -L/usr/lib/qt4 -lXss -laspell -L/usr/lib/qca2 -lqca -lQt3Support -L/usr/lib/mysql -L/usr/lib/qt4 -lQtSql -pthread -pthread -pthread -pthread -pthread -pthread -pthread -pthread -L/usr/lib -pthread -pthread -pthread -pthread -pthread -pthread -pthread -pthread -pthread -pthread -lQtXml -pthread -pthread -lQtGui -lpng -lSM -lICE -pthread -pthread -lXrender -lXrandr -lXfixes -lXcursor -lfreetype -lfontconfig -lXext -lX11 -lQtNetwork -pthread -pthread -lQtCore -lz -lm -pthread -lgthread-2.0 -lrt -lglib-2.0 -lpthread -ldl .obj/httpconnect.o: In function `HttpConnect::sock_connected()': httpconnect.cpp:(.text+0x145c): undefined reference to `QCA::Base64::Base64(QCA::Direction)' httpconnect.cpp:(.text+0x1474): undefined reference to `QCA::TextFilter::encodeString(QString const&)' httpconnect.cpp:(.text+0x1554): undefined reference to `vtable for QCA::Base64' httpconnect.cpp:(.text+0x1560): undefined reference to `QCA::SecureArray::~SecureArray()' httpconnect.cpp:(.text+0x1574): undefined reference to `QCA::Filter::~Filter()' httpconnect.cpp:(.text+0x18b9): undefined reference to `vtable for QCA::Base64' httpconnect.cpp:(.text+0x18c5): undefined reference to `QCA::SecureArray::~SecureArray()' httpconnect.cpp:(.text+0x18d9): undefined reference to `QCA::Filter::~Filter()' .obj/httpconnect.o: In function `QCA::TextFilter::~TextFilter()': httpconnect.cpp:(.text._ZN3QCA10TextFilterD0Ev[QCA::TextFilter::~TextFilter()]+0x12): undefined reference to `QCA::Filter::~Filter()' .obj/httpconnect.o: In function `QCA::TextFilter::~TextFilter()': httpconnect.cpp:(.text._ZN3QCA10TextFilterD1Ev[QCA::TextFilter::~TextFilter()]+0xb): undefined reference to `QCA::Filter::~Filter()' .obj/httpconnect.o:(.rodata._ZTIN3QCA10TextFilterE[typeinfo for QCA::TextFilter]+0x8): undefined reference to `typeinfo for QCA::Filter' .obj/httppoll.o: In function `hpk(int, QString const&)': httppoll.cpp:(.text+0xaf9): undefined reference to `QCA::SecureArray::SecureArray(QByteArray const&)' httppoll.cpp:(.text+0xb3f): undefined reference to `QCA::Hash::Hash(QString const&, QString const&)' httppoll.cpp:(.text+0xb5b): undefined reference to `QCA::Hash::hash(QCA::SecureArray const&)' httppoll.cpp:(.text+0xb6e): undefined reference to `QCA::SecureArray::toByteArray() const' httppoll.cpp:(.text+0xb81): undefined reference to `QCA::SecureArray::SecureArray(QByteArray const&)' httppoll.cpp:(.text+0xb95): undefined reference to `QCA::Base64::Base64(QCA::Direction)' httppoll.cpp:(.text+0xba5): undefined reference to `QCA::TextFilter::arrayToString(QCA::SecureArray const&)' httppoll.cpp:(.text+0xbb0): undefined reference to `vtable for QCA::Base64' (...) etc. illea psi-0.11_rc1 # illea temp # emerge --info Portage 2.1.2.7 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.5-r2, 2.6.21-gentoo-r1 i686) ================================================================= System uname: 2.6.21-gentoo-r1 i686 Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 26 May 2007 14:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64 x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -march=nocona" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /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/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -march=nocona" DISTDIR="/common/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.prz.rzeszow.pl http://src.gentoo.pl" LANG="pl_PL" LC_ALL="pl_PL.UTF-8" LINGUAS="pl" MAKEOPTS="-j5" PKGDIR="/common/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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp/portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/common/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl alsa amr audiofile bitmap-fonts bzip2 caps cli cracklib crypt cups curl dbus dri dts dv dvd dvdr dvdread encode exif fam ffmpeg flac fortran ftp gif gmp gnutls gpm gtk hal iconv idn ieee1394 imagemagick imlib isdnlog jack jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility lcms libg++ mad midi mmx mng mp3 mpeg mudflap musepack ncurses nls nptl nptlonly nsplugin ogg openal openexr opengl openmp oss pam pcre pdf png pppd quicktime readline reflection samba sdl session sndfile speex spl sqlite sse sse2 ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts unicode vcd vidix vorbis win32codecs x264 x86 xcb xml xorg xscreensaver xv xvid xvmc zlib" ALSA_CARDS="emu10k1 hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pl" USERLAND="GNU" VIDEO_CARDS="nv nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS illea temp # ls -la /usr/lib/qca2/ razem 992 drwxr-xr-x 2 root root 1024 maj 26 15:23 . drwxr-xr-x 69 root root 66560 maj 26 17:11 .. -rw-r--r-- 1 root root 350 maj 26 15:23 libqca.prl lrwxrwxrwx 1 root root 15 maj 26 15:23 libqca.so -> libqca.so.2.0.0 lrwxrwxrwx 1 root root 15 maj 26 15:23 libqca.so.2 -> libqca.so.2.0.0 lrwxrwxrwx 1 root root 15 maj 26 15:23 libqca.so.2.0 -> libqca.so.2.0.0 -rwxr-xr-x 1 root root 940304 maj 26 15:23 libqca.so.2.0.0 All that mess because of: (...) -L/usr/lib -L/usr/lib/qt4 -lXss -laspell -L/usr/lib/qca2 -lqca Thus, having qca slotted instead of renamed to qca2 is a brain-damaged idea IMHO. :|
Jakub: Which ebuild did you use to build psi?
@Alon: This one: https://bugs.gentoo.org/attachment.cgi?id=119940 .
(In reply to comment #41) > troll: I am waiting for your reply... Upstream will fix side-by-side in beta6, > but I need to know what is happening on your side. ahhh... sorry, my bad. I made an error in ebuild. I need to test few things... -- I see Jakub found a problem I mentioned earlier. linking with order like: -L/usr/lib -L/usr/lib/qca2 -lqca isn't right and can be a pain for us. Cheers, Przemek
I hate packages with qt3support!!!! No time to build new qt now. But can you please try to remove the qmake stuff from that ebuild and see if something is fixed? It should be quite simple for upstream to modify the order of -L... :)
(In reply to comment #47) > I hate packages with qt3support!!!! > No time to build new qt now. > But can you please try to remove the qmake stuff from that ebuild and see if > something is fixed? It should be quite simple for upstream to modify the order > of -L... :) I can't understand why do you want to do that? depending on libraries order is (simply) bad. that way we can seat and wait for bugs, that _will_ show up on bugzilla. if something can go wrong, it will go wrong. always. on windows qt works as it should - libraries have version number in filenames. on unixes trolltech did that bad. as I see it - we should fixed this. could you tell us (at least me), why you want to it like this? Cheers, Przemek
> why you want to it like this? Not I... Upstream... I asked to rename the libraries... but he like to keep Qt behavior. I don't think patching packages against upstream direction is a good decesion... I think that the solution for this mess is not to install QCA-1 at /lib either... What do you thing?
(In reply to comment #49) > I think that the solution for this mess is not to install QCA-1 at /lib > either... What do you thing? I checked packages in my system, that depends on qca-1 - it's only kopete. If not patching the qca filename, than this would be best. Cheers, Przemek
Created an attachment (id=120901) [edit] qca-1.0-r2.ebuild.diff
Created an attachment (id=120903) [edit] qca-tls-1.0-r3.ebuild.diff
Created an attachment (id=120906) [edit] psi-0.10-r2.ebuild.diff
Created an attachment (id=120907) [edit] mailody-0.4.0.ebuild.diff
*** Bug 137132 has been marked as a duplicate of this bug. ***
Created an attachment (id=124093) [edit] qca-2.0.0_beta7.ebuild
Created an attachment (id=124095) [edit] qca-cyrus-sasl-0.1_p20070706.ebuild
Created an attachment (id=124096) [edit] qca-gnupg-0.1_p20070706.ebuild
Created an attachment (id=124097) [edit] qca-logger-0.1_p20070706.ebuild
Created an attachment (id=124098) [edit] qca-ossl-0.1_p20070706.ebuild
Created an attachment (id=124100) [edit] qca-pkcs11-0.1_p20070706.ebuild
Hello, I am not using any of these applications, so I if anyone can check this... These should continue to work with qca-1.0-r2.ebuild.diff after revdep-rebuild: mail-client/mailody net-im/psi kde-base/kopete (bug#180599) I guess new psi-0.11 rc will be released soon so test of bug#131528 will be possible.
Created an attachment (id=124123) [edit] qca-2.0.0_beta7.ebuild Don't install .debug on release.
Created an attachment (id=124125) [edit] qca-cyrus-sasl-0.1_p20070706.ebuild
Created an attachment (id=124127) [edit] qca-gnupg-0.1_p20070706.ebuild
Created an attachment (id=124128) [edit] qca-logger-0.1_p20070706.ebuild
Created an attachment (id=124130) [edit] qca-ossl-0.1_p20070706.ebuild
Created an attachment (id=124132) [edit] qca-pkcs11-0.1_p20070706.ebuild
hmm, qca seems to bundle (parts of) botan. Maybe that should be changed before committing it to the tree...
As far as I know, this is a modified botan, and as it does not install any libs I think it is safe to keep it this way.
QCA 2.0 Test 1 has been released together with updated snapshots of the OpenSSL, GnuPG, PKCS#11, cyrus-sasl and logger plugins. http://lists.affinix.com/pipermail/delta-affinix.com/2007-August/001005.html
Test2 has been released. I've bumped Alon's ebuilds and modified them a bit to use eqmake4 for Makefiles generation.
Created an attachment (id=129722) [edit] qca-2.0.0_rc2.ebuild
Created an attachment (id=129723) [edit] qca-2.0.0_rc2-defer-plugin-updates.patch Upstream patch for qca-2.0.0_rc2.ebuild that fixes a 100% CPU usage bug.
Created an attachment (id=129725) [edit] qca-cyrus-sasl-0.1_p20070829.ebuild
Created an attachment (id=129727) [edit] qca-gnupg-0.1_p20070829.ebuild
Created an attachment (id=129729) [edit] qca-logger-0.1_p20070829.ebuild
Created an attachment (id=129730) [edit] qca-ossl-0.1_p20070829.ebuild
Created an attachment (id=129732) [edit] qca-pkcs11-0.1_p20070829.ebuild
Created an attachment (id=129733) [edit] configure.patch This patch must be applied to every package. For qca itself, filename should be "qca-2.0.0-configure.patch" For qca plugins, filenames should be "${PN}-configure.patch"
Thanks! A few questions... (In reply to comment #72) > Test2 has been released. I've bumped Alon's ebuilds and modified them a bit to > use eqmake4 for Makefiles generation. Why do you wish to modify the Makefile? Why aren't configure && emake enough? If it is required we should work with upstream so it will be solved. (In reply to comment #80) > Created an attachment (id=129733) [edit] > configure.patch > > This patch must be applied to every package. Why is it required? Does upstream provided this one?
(In reply to comment #81) > Thanks! > > A few questions... > > (In reply to comment #72) > > Test2 has been released. I've bumped Alon's ebuilds and modified them a bit to > > use eqmake4 for Makefiles generation. > > Why do you wish to modify the Makefile? > Why aren't configure && emake enough? > If it is required we should work with upstream so it will be solved. Upstream configure script runs qmake on ${S}/${PN}.pro after configuring the build system. We do not want this because running qmake in such a way doesn't respect C(XX)FLAGS and LDFLAGS declared in user's make.conf. The right thing to do from an ebuild should be using eqmake4 (for qt4-based packages) or eqmake3 (for qt-3 based packages) which are simple wrappers that call qmake setting correctly the relevant variables. You can have a look at the code in qt[34].eclass and see bug #120116. > (In reply to comment #80) > > Created an attachment (id=129733) [edit] > > configure.patch > > > > This patch must be applied to every package. > > Why is it required? > Does upstream provided this one? > No, that patch is mine. It is required to prevent the configure script from running qmake on ${S}/${PN}.pro, but now I realized that it is probably not necessary because we can always run eqmake4 after configure to force re-generation of Makefile...
Maybe you should talk with Justin, so qconf will include whatever needed to *FLAGS? I worked with Justin very hard to make it generic enough so gentoo specific hacks will not be required. I don't fully understand why you wish to override Qt *FLAGS, but if it is required qconf should also support this. BTW: I don't use Qt so I am no expert, but as I understand QCA should be built with the same *FALGS of Qt, so current behavior is currect.
(In reply to comment #83) > BTW: I don't use Qt so I am no expert, but as I understand QCA should be built > with the same *FALGS of Qt, so current behavior is currect. > Sorry, I didn't know that QCA should be built with the same *FLAGS used to build Qt... if this is the case then you may drop the configure patch and remove completely any eqmake usage from the ebuilds. But, for example, on one of my boxes I have qt4 compiled with -ggdb, do you mean that I should compile QCA with -ggdb too? And what about all the other packages that link against qt?
I said I don't know much... :) But it sound logical to me that a core component should be compiled the same as the framework... This is why qmake behaves this way. But maybe someone from kde herd will help us out.
Ok, let's ask them then! BTW, do you know why QCA and its plugins have RESTRICT="strip" in their ebuilds?
The binaries are prestripped as Justin insists to follow Qt protocol, and put symbols at separate files on debug and strip on release. I could not convince him to leave them out or to allow an option at configure.
Created an attachment (id=130194) [edit] qca-2.0.0_rc3.ebuild
Created an attachment (id=130196) [edit] qca-cyrus-sasl-0.1_p20070829.ebuild
Created an attachment (id=130197) [edit] qca-gnupg-0.1_p20070904.ebuild
Created an attachment (id=130199) [edit] qca-logger-0.1_p20070829.ebuild
Created an attachment (id=130200) [edit] qca-ossl-0.1_p20070904.ebuild
Created an attachment (id=130202) [edit] qca-pkcs11-0.1_p20070829.ebuild
Created an attachment (id=130477) [edit] qca-2.0.0_rc4.ebuild Upstream changed the behaviour of configure options: --debug-and-release is only for Mac now, and a new switch (--debug) has been introduced for others platforms. RESTRICT="strip" is no longer necessary if we use --no-separate-debug-info. Note that plugins also have to be changed in a similar way (--debug in place of --debug-and-release), I'm attaching a patch as an example.
Created an attachment (id=130478) [edit] /tmp/qca-plugins.patch
Great! Why: eqmake4 ${PN}.pro Is needed now?
(In reply to comment #96) > Great! > Why: > eqmake4 ${PN}.pro > Is needed now? > To respect C(XX)FLAGS and LDFLAGS that users set in their make.conf... And to use the program returned by tc-getCXX() as the compiler and linker. In general, to do everything more in the Gentoo way ;)
(In reply to comment #97) > To respect C(XX)FLAGS and LDFLAGS that users set in their make.conf... > And to use the program returned by tc-getCXX() as the compiler and linker. > In general, to do everything more in the Gentoo way ;) Qt will put these flags in qmake when it is compiled... right? So why do you need to modify it in every Qt enabled package? The safest way is not to modify something the author did not expect...
qca-2.0 was released. kde: please ack if the qca-1 slot (attachment#120901 [edit]) works with mailody (attachment#120907 [edit]) and psi (attachment#120906 [edit]). This is the prerequisite for the slotting.
Created an attachment (id=132469) [edit] qca-2.0.0.ebuild Ebuild for qca-2.0.0 FINAL. Added 'examples' USE flag. I suppose that this ebuild should be committed with KEYWORDS="" and arches team should be asked for re-keywording since this is basically a rewrite for Qt4. However (if it matters) I've been testing both qca library and qca-{gnupg,ossl} plugins on x86 and amd64 for almost a year now and I can say that they are working very well and AFAIK there are no known bugs.
Created an attachment (id=132473) [edit] qca-cyrus-sasl-0.1_p20070829.ebuild
Created an attachment (id=132474) [edit] qca-gnupg-0.1_p20070904.ebuild
Created an attachment (id=132476) [edit] qca-logger-0.1_p20070829.ebuild
Created an attachment (id=132478) [edit] qca-ossl-0.1_p20070904.ebuild
Created an attachment (id=132479) [edit] qca-pkcs11-0.1_p20070829.ebuild
Just added them to my dev overlay so you can try them
Created an attachment (id=135163) [edit] qca-cyrus-sasl-2.0.0_beta1.ebuild
Created an attachment (id=135164) [edit] qca-gnupg-2.0.0_beta1.ebuild
Created an attachment (id=135166) [edit] qca-logger-2.0.0_beta1.ebuild
Created an attachment (id=135167) [edit] qca-ossl-2.0.0_beta1.ebuild
Created an attachment (id=135168) [edit] qca-pkcs11-2.0.0_beta1.ebuild
kde: Before bump the version, I suggest that current packages should work with modified qca-1 that enable slotting. We have attachment#120906 [edit], attachment#120907 [edit] and bug#180599. I don't use any of these applications, so I cannot test if they are working after the change. After the current packages work, it will be simple to add new psi as it is the only one dependended on qca-2.
(In reply to comment #112) > I don't use any of these applications, so I cannot test if they are working > after the change. Why don't you emerge them and test them, then? I test lots of packages that I normally wouldn't use. What is technically preventing you from trying them out?
Qt should be in on this.
Shouldn't /usr/share/qt4/mkspecs/features/crypto.prf make reference to the non-default libdir?
(In reply to comment #115) > Shouldn't /usr/share/qt4/mkspecs/features/crypto.prf make reference to the > non-default libdir? > It does. $ cat /usr/share/qt4/mkspecs/features/crypto.prf QCA_INCDIR = /usr/include/qca2 QCA_LIBDIR = /usr/lib64/qca2 # prepend this file with QCA_INCDIR/QCA_LIBDIR definitions CONFIG *= qt INCLUDEPATH += $$QCA_INCDIR/QtCrypto LIBS += -L$$QCA_LIBDIR LINKAGE = -lqca CONFIG(debug, debug|release) { windows:LINKAGE = -lqcad mac:LINKAGE = -lqca_debug } LIBS += $$LINKAGE Looks good to me.
Hi! I was around here for some time, but maybe I still can do something good for gentoo (let's hope ;) ). In qca ebuild I see pkg_setup function that is almost the same as qt4_pkg_setup function. What is much better in ebuild' version of function is a direct hint for the user, that is missing from eclass. In eclass setup looks like this: qt4_pkg_setup() { for x in ${QT4_BUILT_WITH_USE_CHECK}; do if ! built_with_use =x11-libs/qt-4* $x; then die "This package requires Qt4 to be built with the '${x}' use flag." fi done } much better (especially for beginer users) it could look like in ebuild: qt4_pkg_setup() { for x in ${QT4_BUILT_WITH_USE_CHECK}; do if ! built_with_use =x11-libs/qt-4* $x; then eerror eerror "You are trying to compile ${PN} package with USE=\"$x\"" eerror "while qt4 is built without this particular flag: it will" eerror "not work." eerror eerror "Possible solutions to this problem are:" eerror "a) install package ${PN} without $x USE flag" eerror "b) re-emerge qt4 with $x USE flag" eerror die "can't emerge ${PN} with $x USE flag" fi done } it gives much cleaner information for users. and of course - we could drop pkg_setup from ebuild then :) what you think of it? is anybody against? Cheers, Przemek
(In reply to comment #117) > much better (especially for beginer users) it could look like in ebuild: > qt4_pkg_setup() { > for x in ${QT4_BUILT_WITH_USE_CHECK}; do > if ! built_with_use =x11-libs/qt-4* $x; then If you want to improve that function the first thing you should do is get rid of the for loop. if ! built_with_use =x11-libs/qt-4* ${QT4_BUILT_WITH_USE_CHECK}; then ... fi will work and be able to show the user all the flags that should be enabled at once. Rather than being told to rebuild qt4 once for every missing use flag...
(In reply to comment #118) <cut> > Rather than being told to rebuild qt4 once for every missing use flag... hell yeah! +1
(In reply to comment #119) > (In reply to comment #118) > <cut> > > Rather than being told to rebuild qt4 once for every missing use flag... > > hell yeah! +1 more propositions for qt4.eclass in separated bug entry: http://bugs.gentoo.org/show_bug.cgi?id=201772 ps. are we ready to add qca-*-2 packages? I need them for psi-0.11 :/ Cheers, Przemek
(In reply to comment #120) > ps. are we ready to add qca-*-2 packages? I need them for psi-0.11 :/ It is your call, as kde maintain all the dependencies.
Well... Any reason we cannot close this?
(In reply to comment #122) > Well... > Any reason we cannot close this? I want to do bigger update this weekend for qca and psi. if you want to do it today - fill free to do so. Cheers, Przemek
What do you mean "bigger"?
Created an attachment (id=140505) [edit] qca-2.0.0.ebuild Further improvements. Added a patch and a multilib fix from kde4-experimental overlay (thanks to Ingmar Vanhassel). Block "<app-crypt/qca-1.0-r3" and use QT4_OPTIONAL_BUILT_WITH_USE_CHECK for debug USE flag.
Created an attachment (id=140506) [edit] qca-2.0.0-debug-same-pkgconfig-file.patch Patch to install the same pkgconfig file both for release and debug builds. Should fix KDE4 being unable to locate qca2 built with USE="debug".
Created an attachment (id=140875) [edit] qca-cyrus-sasl-2.0.0_beta3.ebuild
Created an attachment (id=140876) [edit] qca-gnupg-2.0.0_beta2.ebuild
Created an attachment (id=140878) [edit] qca-logger-2.0.0_beta2.ebuild
Created an attachment (id=140880) [edit] qca-ossl-2.0.0_beta3.ebuild
Created an attachment (id=140882) [edit] qca-pkcs11-2.0.0_beta2.ebuild
I just verified that the multilib and pkg-config fixes are merged in upstream.
All ebuilds are in the tree now.
But what about with the slotting? attachment#120901 [edit], attachment#120903 [edit], attachment#120906 [edit], attachment#120907 [edit] These required in order to allow qca slotting... without breaking user configuration, never acked by kde herd, as all dependencies are of kde.
Oh... And there is bug#180599 comment#3... soon from 2007-09-08...
(In reply to comment #133) > All ebuilds are in the tree now. > EAPI=1 in the recently-committed qca-2.0.0-r2 ebuild is not needed at all. You should use qt4_min_version in DEPEND and QT4_OPTIONAL_BUILT_WITH_USE_CHECK="debug" in place of that check in pkg_setup(). Please have a look at https://bugs.gentoo.org/attachment.cgi?id=140505 Furthermore, if qca belongs to the KDE herd, metadata.xml should be changed accordingly.
What I fear now is that we break users' configurations... If slot 0 is not approved and committed.
(In reply to comment #137) > What I fear now is that we break users' configurations... If slot 0 is not > approved and committed. qca:2 is in p.mask for now. Slot 0 is being worked on while I'm writing this. :-)
(In reply to comment #136) > EAPI=1 in the recently-committed qca-2.0.0-r2 ebuild is not needed at all. > You should use qt4_min_version in DEPEND and Exactly these crappy function calls should be gone one day. Using EAPI and slot dependencies is the right way to go.
I don't understand... Whoever unmask qca now, and had qca before, gets invalid configuration.
Any reason keeping this open?
(In reply to comment #141) > Any reason keeping this open? It depends on bug 180599, which still isn't fixed yet, it still uses the internal qca. (Wulf is working on this one.) And troll still needs to fix Psi.
Thanks! Although I fail to understand how come a dependency is not fixed before... As I guess whoever who had psi or kopete and tried the recently added kde-4 broke his system...
BTW, qca-2* should block "<app-crypt/qca-1.0-r3", otherwise people might get an invalid configuration of their system, where psi (and probably kopete too) fails to build.
What about psi? Should not take this long... I can commit this if no activity... :)
(In reply to comment #145) > What about psi? > Should not take this long... > I can commit this if no activity... :) Please do, thanks :-) (In reply to comment #144) > BTW, qca-2* should block "<app-crypt/qca-1.0-r3", otherwise people might get an > invalid configuration of their system, where psi (and probably kopete too) > fails to build. Will do, thanks.
Finally closing! I don't understand why we should have waiting for kde-4 in order to do this one... Thank for all your help.
