Hi! I am a Tarantool developer and I created ebuilds for our project. Tarantool is an in-memory database designed to store the most volatile and highly accessible web content. Tarantool has been extensively used in production since 2009. Its key features include: * all data is maintained in RAM * data persistence is implemented using Write Ahead Log and snapshots * supports asynchronous replication and hot standby * uses coroutines and asynchronous I/O to implement high-performance lock-free access to data * stored procedures in Lua are supported http://tarantool.org/ I ebuild and all needed files into the overlay: https://github.com/rtsisyk/tarantool-gentoo-overlay There are two ebuilds, an init script, a logrotate script, cron files and a Manifest. Your comments and suggestions are welcome. Thanks!
Do you have interest in becoming a proxied maintainer to maintain this? http://www.gentoo.org/proj/en/qa/proxy-maintainers/
(In reply to Tom Wijsman (TomWij) from comment #1) > Do you have interest in becoming a proxied maintainer to maintain this? > > http://www.gentoo.org/proj/en/qa/proxy-maintainers/ Yes, I can maintain it.
Okay, cool; if nobody is earlier, I will review and add them this weekend... You will then also be sent a short mail explaining proxy maintenance.
ok, thanks. Please feel free to contact me if you will any some questions.
Working on these now; it appears Clang doesn't provide Objective C for me, any idea about that or am I doing something wrong? Did you try it with Clang?
Just try to provide both CC and CXX params: CC=clang CXX=clang++ cmake . -- The C compiler identification is Clang 3.2.0 -- The CXX compiler identification is Clang 3.2.0 -- Check for working C compiler: /usr/bin/clang -- Check for working C compiler: /usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/clang++ -- Check for working CXX compiler: /usr/bin/clang++ -- works ...
Some details about objc in tarantool. Actually there is two ebuilds: * tarantool-1.4.9999 - from "stable" git branch. This version is mostly written on Objective C and uses GNUstep runtime (gnustep-base/libobjc2) which shipped within third_party/ directory. "libobjc-bundled" USE flag can be used to switch between the system and the bundled versions. GNU's libobjc (shipped with gcc) is not supported due to lack an interplay mechanism between Objectvie-C and C++ DWARF exceptions. This branch can be compiled using clang-3.1 - 3.3 (and later) and gcc-4.4 - 4.6. gcc-4.7+ is not work properly with gnustep-base/libobjc2 and libobjc2's maintainer does not want to fix it. USE="objc objc+" should be provided for sys-devel/gcc clang works with any settings of USE flags. * tarantool-9999 (1.5.x) - from "master" git branch. Starting from 1.5.x we rewrote all Objective-C parts using regular C++ and removed libobjc2 from the dependecy list. This version can be compiled using gcc-4.5 - 4.8 (and later) and clang-3.1 - 3.3 (and later).
Hi Tom, how it is going with these ebuilds?
Created attachment 352154 [details] tarantool-1.4.9-clang-build-fail.log
Created attachment 352156 [details] tarantool-1.4.9-gcc-test-fail.log
See attached two build logs, for clang I get a build fail and for gcc a test fail; the same happens with other versions like 1.4.9999, 1.5.0 and 9999. No combination appears to build and test succesfully, therefore I can't add any version to the Portage tree. Do you have any idea about what is going on here?
Thanks for you logs, I see following problems there: 1) "make test" only works if "make all" was run Try to run "make -C test" if USE="test" is enabled, or just run "make all" for all combinations of USE flags. 2) sys-libs/libunwind is needed when building with clang 3) 1.4.9999 (which uses Objective C) should be build with gcc-4.6 or with clang. GCC 4.7+ does not work with gnustep-base/libobcj2. Sad but true. We completely remove remove Objective C in 1.5.x release. I will add an error message about compiler to CMakeLists.txt in the upstream. May be we can add CC=clang CXX=clang++ into 1.4.9 ebuild. 4) Some additional dependencies with doxygen schemas are needed for USE="doc" to fix warnings. On Debian it build with: xsltproc docbook5-xml docbook-xsl-ns w3c-sgml-lib libxml-commons-resolver1.1-java libxml2-utils libxerces2-java libxslthl-java lynx jing I added app-text/jing www-client/lynx app-text/docbook-xml-dtd app-text/docbook-xsl-ns-stylesheets app-text/docbook-xsl-stylesheets on Gentoo, but seems that it is not enough. I am trying to find which files is actually needed for USE="doc". I see that you created a non-live ebuild for 1.4.9. Is it bad practice to have only live ebuilds for package on Gentoo? We usually make up to ten minor fix releases (1.4.x.yyyy) within the cycle of one major (1.4.x) release, e.g. tarantool-1.4.9+20130611 tarantool-1.4.9+20130608 tarantool-1.4.9+20130415 ...
(In reply to Roman Tsisyk from comment #12) > 1) "make test" only works if "make all" was run > Try to run "make -C test" if USE="test" is enabled, or just run "make all" > for all combinations of USE flags. That's an improvement, but still fails a test; will attach new build log next. > 2) sys-libs/libunwind is needed when building with clang Hmm, I'll hear whether I should introduce a clang USE flag for this, otherwise I will just have to make it an unconditional dependency. > 3) 1.4.9999 (which uses Objective C) should be build with gcc-4.6 or with > clang. > GCC 4.7+ does not work with gnustep-base/libobcj2. Sad but true. We > completely remove remove Objective C in 1.5.x release. I will add an error > message about compiler to CMakeLists.txt in the upstream. May be we can add > CC=clang CXX=clang++ into 1.4.9 ebuild. Building went fine for me, though; how exactly would it fail? > 4) Some additional dependencies with doxygen schemas are needed for > USE="doc" to fix warnings. > On Debian it build with: > xsltproc docbook5-xml docbook-xsl-ns w3c-sgml-lib > libxml-commons-resolver1.1-java > libxml2-utils libxerces2-java libxslthl-java lynx jing > > I added app-text/jing www-client/lynx app-text/docbook-xml-dtd > app-text/docbook-xsl-ns-stylesheets app-text/docbook-xsl-stylesheets on > Gentoo, but seems that it is not enough. I am trying to find which files is > actually needed for USE="doc". Okay, feel free to let me know. > I see that you created a non-live ebuild for 1.4.9. Is it bad practice to > have only live ebuilds for package on Gentoo? > We usually make up to ten minor fix releases (1.4.x.yyyy) within the cycle > of one major (1.4.x) release, e.g. > tarantool-1.4.9+20130611 > tarantool-1.4.9+20130608 > tarantool-1.4.9+20130415 Yes, live ebuilds are not and should not be keyworded unless absolutely necessary; having proper release versions would be nice. The reason we have live ebuilds in our tree is mainly to test for packages breaking in advance so we're not surprised with the version bump.
Created attachment 352166 [details] tarantool-1.4.9-gcc-test-fail.log
(In reply to Tom Wijsman (TomWij) from comment #13) > (In reply to Roman Tsisyk from comment #12) > > 1) "make test" only works if "make all" was run > > Try to run "make -C test" if USE="test" is enabled, or just run "make all" > > for all combinations of USE flags. > > That's an improvement, but still fails a test; will attach new build log > next. It is a problem with IPv6 connection in box/socket.test that currently occurs only on Gentoo. I posted the bug, we will try to fix it ASAP. https://bugs.launchpad.net/tarantool/+bug/1192951 > > 2) sys-libs/libunwind is needed when building with clang > > Hmm, I'll hear whether I should introduce a clang USE flag for this, > otherwise I will just have to make it an unconditional dependency. I need to examine dev-lang/luajit ebuild to check how they solved problem with clang. > > 3) 1.4.9999 (which uses Objective C) should be build with gcc-4.6 or with > > clang. > > GCC 4.7+ does not work with gnustep-base/libobcj2. Sad but true. We > > completely remove remove Objective C in 1.5.x release. I will add an error > > message about compiler to CMakeLists.txt in the upstream. May be we can add > > CC=clang CXX=clang++ into 1.4.9 ebuild. > > Building went fine for me, though; how exactly would it fail? It segfaults on box/xlog.test (at least on it): https://bugs.launchpad.net/tarantool/+bug/1157040 I added an error message to CMakeLists.txt about GCC-4.7 for "stable" 1.4.9. branch. I also re-tested this branch under clang and pushed some fixes for it. clang 3.1-3.3 and gcc 4.4-4.6 should work fine for 1.4.9. "master" 1.5.x is free from these Objective-C problems.
Hi Tom, Sorry for my later answer. We decided to release Tarantool 1.5.1 on next week to abandon 1.4.9 branch and to get rid of these Objective C problems. This release does not depend on Objective-C and compiles using gcc-4.5+ and clang-3.1+. box/socket.test does not work properly because you do not have IPv6 on the host (the test will be fixed in release).
Hi, I resolved all found problems: * Add USE=mysql and USE=postgres * Remove USE="luajit-bundled" * Fix FEATURES="test" * Fix libunwind dependecy * Fix docbook generation https://github.com/rtsisyk/tarantool-gentoo-overlay I also added a regular (non-live) ebuild for 1.5.1-26-gbd426b7. Tarantool uses "git describe" for version numbering. This system cannot be directly represent in ebuild names. I decided to kept commit counter and remove git hash: tarantool 1.5.1-26-gbd426b7 -> tarantool-1.5.1-p26.ebuild
This has became the oldest bug in my personal inbox; would like to progress on this, so, I started working a bit on 1.5.3. In 1.5.3 documentation generation fails due to: Error: Could not find or load main class com.icl.saxon.StyleSheet We need to adjust it to work together with the Gentoo Java Packaging; from a quick look, patching the hardcoded locations to the jars with those obtained through java-pkg_getjar could be the way forward. The other option is to not regenerate documentation and reuse bundled or separate documentation. Up to you. https://www.gentoo.org/proj/en/java/java-devel.xml
NB: tarantool layman overlay is now maintained by me (I am tarantool developer).
I think that the bug should be closed, because tarantool overlay is available in layman and mostly in line with recent tarantool releases (it also contains -9999 live package).
