Since the next stable branch of dbmail may just be around the corner (the 2.4 series) here's a couple of ebuilds for libzdb you'll need libzdb-2.2 for use with dbmail 2.3.4 or above (libdb-2.3 doesn't seem to be compatible with dbmail 2.3.4, however it's the latest version, and the ebuild is just the same
Created attachment 175365 [details] libzdb-2.2.ebuild
Created attachment 175367 [details] libzdb-2.3.ebuild
Created attachment 175369 [details, diff] files/libzdb-mysql-ac.patch
I'll add that after trying it out.
any news on this ?
yeah i was busy with other stuff so devel version is one of the things at the bottom of my list .. sorry for that gotta try to catch up on the bugs on stable first - and a few other things on my bugzie
I'll stick this in my overlay first as i did also remove dbmail 2.3 from main portage tree for now.
Created attachment 313355 [details] libzdb-2.10.3.ebuild Guess what. I ended up using this in a recent project. So, without further ado. Here's an up to date version of the ebuild adapted from a version that used to live here: http://code.google.com/p/slepnoga/ The configure states that args to --with-mysql et al is optional... Well. Its not. Please consider for inclusion (as well as adding me as proxy)
Updating ticket info, the connection to dbmail seems long overdue. Also CC:ing proxy to see if they're interested in co-maintaining this with me. I'm a good boy and keep my packages fresh and clean ^_^
I just wrote an ebuild for this myself as I had lost this bug .. O.o .. they are pretty similar ;) I was wondering though as to why you depend on sqlite-unlock by default. sqlite-unlock is optional, so why depend on it by default? I will upload a slightly modified version to my overlay in a bit
also you have if use postgres; then myconf=" --with-postgresql=${EPREFIX}/usr/bin/pg_config" else myconf=" --without-postgresql" fi and then $(use_with postgres postgresql) \ therefore adding that parameter twice
oh and you always overwrote the contents of myconf ;) and one thing you might want to look at too for future ebuilds: http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency anyway made those + a few other small changes. you can see them in my dev-overlay
I forgot. you can add my dev-overlay with "layman -a lordvan" or look at the "changed ebuild here: http://git.overlays.gentoo.org/gitweb/?p=dev/lordvan.git;a=tree;f=dev-db/libzdb;h=7d9a7a662c2745ce2d4cf01f2c92ca7a280bd6e0;hb=4747cad018329ec47fec634149fb96255c70414b
@Thomas: Thanks for the updates to the ebuild. I'll use your overlay but would very much like to see this in gentoo-x86 at some point :-) Cheers, Johan
I can't seem to get the sqlite backend running with your ebuild (works with mine). Just emailed you about it.
So, I figured it out. It's basically a bug in the upstream auto* rig. If using --with-sqlite, it checks for a static library (which we don't have). That's why it wasn't triggering on my version, but was for yours. Here's a patch that fixes it: --- configure.ac 2012-07-14 07:14:19.000000000 +1000 +++ ../configure.ac 2012-07-23 14:17:38.702411605 +1000 @@ -298,12 +298,11 @@ CPPFLAGS="-I$with_sqlite/include $CPPFLAGS" AC_CHECK_HEADERS([sqlite3.h], [ sqlite="yes" - if test -r "$with_sqlite/lib/libsqlite3.a"; then + AC_CHECK_LIB(sqlite3, main,[ + DBCPPFLAGS="$DBCPPFLAGS -I$with_sqlite/include" DBLDFLAGS="$DBLDFLAGS -L$with_sqlite/lib/ -lsqlite3" - else - sqlite="no" - fi + ],[sqlite="no"]) ], [sqlite="no"]) LDFLAGS=$svd_LDFLAGS CPPFLAGS=$svd_CPPFLAGS I've also sent this upstream.
Fixed upstream: http://code.google.com/p/libzdb/source/detail?r=501
(In reply to comment #9) > CC:ing proxy to see if they're interested in co-maintaining this with me. > I'm a good boy and keep my packages fresh and clean ^_^ Please point me to the latest up-to-date ebuild for this, and I will commit it, with you as maintainer by proxy.
Johan, I just did notice your last comments on here when I wanted to just close the bug after commiting the ebuild to the tree. I added the patch for now. do you know if they plan to release a patched version soon? (2.10.5 seems to have been before this patch according to the release notes
@Johan: I just searched my spam mail folder and there was your mail. sorry for not noticing sooner. Could you test the ebuild in the tree please? (Since I never had the error you had on my box anyway - maybe some old static lib ;)) I would like to commit dbmail 3.0.2 to the tree soon, but I'd prefer if you tested that the patch works for you too (it compiles fine here)
Created attachment 323048 [details] libzdb-2.10.5.ebuild Hey, there's no need for patches. All of them was applied upstream. Attaching ebuild for the latest version. Changes from lordvans overlay: - disable tests since they're broken upstream. I will send a patch shortly - dep on virtual/pkgconfig over a specific one @yngwin: sorry for missing your comment :(
ah ok good to know I will commiit .5 later when I'm at my dev box again. btw about the tests. were they already broken on .3 ? I never had any compile errors myself. Also I'll add you as maintainer/proxy. I forgot last night. (should I forget again don't hesitate to remind me, since I tend to forget about things like metadata stuff ;))
commited 2.10.5 and added you to metadata.xml :) Thanks
