Created attachment 385144 [details, diff] tora-9999.ebuild.patch # ebuild /usr/portage/gentoo/dev-db/tora/tora-9999.ebuild prepare … >>> Preparing source in /var/tmp/portage/dev-db/tora-9999/work/tora-9999 ... * Applying tora-9999-ext-loki.patch ... * Failed Patch: tora-9999-ext-loki.patch ! * ( /usr/portage/gentoo/dev-db/tora/files/tora-9999-ext-loki.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/dev-db/tora-9999/temp/tora-9999-ext-loki.patch.out * ERROR: dev-db/tora-9999::gentoo failed (prepare phase): * Failed Patch: tora-9999-ext-loki.patch! * * Call stack: * ebuild.sh, line 93: Called src_prepare * environment, line 2642: Called epatch '/usr/portage/gentoo/dev-db/tora/files/tora-9999-ext-loki.patch' * environment, line 1214: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * * If you need support, post the output of `emerge --info '=dev-db/tora-9999::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-db/tora-9999::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-db/tora-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-db/tora-9999/temp/environment'. * Working directory: '/var/tmp/portage/dev-db/tora-9999/work/tora-9999' * S: '/var/tmp/portage/dev-db/tora-9999/work/tora-9999' Idea of tora-ext-loki.patch (bug #383109) was merged to upstream's source tree for a time ago, that breaked the patch. So, we should use cmake arguments instead of it. Attaching patch to ebuild, making src_prepare() pass successfully. P.S. Probably tora-9999 for now is not buildable, at least yesterday's snapshot failed. P.P.S. Not to open separate bug: tora's homepage in portage (http://tora.sourceforge.net) forwards to http://torasql.com/
BTW, ${FILESDIR} contains outdated and not used patch tora-2.1.2-qt47.patch.
Created attachment 385706 [details] tora-3.0.0_pre20140928.ebuild Previously attached patch isn't enough. Attaching corrected ebuild, compatible with recent tree's state. Should be compatible with -9999 build (just rename).
Created attachment 385728 [details] tora-3.0.0_pre20140928-r1.ebuild Ebuild updated to get values of includedir/libdir via pkg-config. Also, not long ago tora requires also libantlr3c. Is it dev-libs/antlr-c? For now use internal from extlibs. Upstream's notes: Regarding antlr library version, see: https://bugzilla.redhat.com/show_bug.cgi?id=979166 https://sourceforge.net/p/tora/bugs/873/ https://bugzilla.redhat.com/show_bug.cgi?id=1026440 Long story short. Tora contains some sources generated by ANTLR tool (of exact version), these sources depend on runtime lib of the same exact version. This is not Tora specific, it's the nature of the ANTLR tool. https://sourceforge.net/p/tora/bugs/884/#660e
Referenced in tora-3.0.0_pre20140928-r1.ebuild patch was included into upstream's source tree: https://sourceforge.net/p/tora/patches/86/
Sergey, your effort on TOra is much appreciated! Feels like there's some dependency cruft to be sorted out still, but unfortunately I'm short in time ATM. However, I've created an uploaded the tora-3.0.0_pre20140928.tar.xz so you can use this link in the tora-3.0.0_pre20140928.ebuild for now: SRC_URI="http://dev.gentoo.org/~haubi/distfiles/${P}.tar.xz" Ehm, .tar.xz requires newer EAPI, currently recommended is EAPI=5.
(In reply to Michael Haubenwallner from comment #5) > Feels like there's some dependency cruft to be sorted out still For recent versions of TOra (2.1.3 up to recent SVN trunk) we must switch Oracle support from conditional USE-flag managed to mandatory. See https://bugs.gentoo.org/show_bug.cgi?id=490604#c12 for details. But I'm not shure, dev-db/oracle-instantclient-sqlplus is necessary for TOra, dev-db/oracle-instantclient-basic should be enough. > but unfortunately I'm short in time ATM. If so, could you delegate some privileges on your category to users (primarily me) via proxy-maintaining initiative (pinkbyte@gentoo.org and some others)? P.S. After convertion attached ebuild to only-svn (removing SRC_URI) it should be commited in the tree and bug fixed.
Created attachment 385992 [details] tora-3.0.0_pre20140930.ebuild Attaching corrected version of ebuild. It could be commited immediately as tora-9999.ebuild fixing current bug. (In reply to Michael Haubenwallner from comment #5) > However, I've created an uploaded the tora-3.0.0_pre20140928.tar.xz so you > can use this link in the tora-3.0.0_pre20140928.ebuild for now: > SRC_URI="http://dev.gentoo.org/~haubi/distfiles/${P}.tar.xz" Please, update sources archive to trunk-5141 (probably 20140930) snapshot. (In reply to Michael Haubenwallner from comment #5) > Feels like there's some dependency cruft to be sorted out still Requireing dev-db/postgresql-server looks to be much overhead (I use TOra as Oracle client without Oracle server installed locally). dev-db/oracle-instantclient-sqlplus in dependencies also looks to be strange. Client library itself (dev-db/oracle-instantclient-basic) is enough.
(In reply to Sergey S. Starikoff from comment #7) > Please, update sources archive to trunk-5141 (probably 20140930) snapshot. Well, I've updated tora-9999.ebuild now. > (In reply to Michael Haubenwallner from comment #5) > > Feels like there's some dependency cruft to be sorted out still I've meant these antlr things actually... > Requireing dev-db/postgresql-server looks to be much overhead (I use > TOra as Oracle client without Oracle server installed locally). Done. > dev-db/oracle-instantclient-sqlplus in dependencies also looks to be strange. > Client library itself (dev-db/oracle-instantclient-basic) is enough. I don't think unconditionally requiring oracle-instantclient-basic is a good idea, as this (although at no cost) requires to accept the Oracle license as well as an Oracle account to download the instantclient. (In reply to Sergey S. Starikoff from comment #6) > > but unfortunately I'm short in time ATM. > > If so, could you delegate some privileges on your category to users > (primarily me) via proxy-maintaining initiative (pinkbyte@gentoo.org and > some others)? In progress...