botan has been releasing 1.9.x, which contains python bindings (so i guess that should depend on USE=python). This, and more, is really intersting, to me at least. Reproducible: Always
In principle there is no problem with this, but I am hesitant about 1.9 being packaged for any distro because the development tree is quite explicitly not stable (especially in terms of API/ABI stability - it is relatively common for there to be major changes along these trees). That said Gentoo has an easier time with this than most distros (1.7 being packaged in Debian was a total mess) thanks to building from source and tools like revdep-rebuild. Definitely I'd be against marking any 1.9 release as non-~ though, regular users (of say monotone which is a dependency (maybe the only one in portage proper atm?)) should not have to deal with this. That said: I'll attach an ebuild to this PR for 1.9.4 when that is released (probably later this month), I don't have the time to work on an ebuild at the moment and if any dev release is going to be packaged in any form I'd prefer it be that one (as it adds a lot of new features like SSL/TLS, the GOST ECC signature scheme, and many new SIMD optimizations). Which you could use in a portage overlay locally, or if Gentoo wants to redistribute then OK.
Oh, do you mean that they follow the scheme 1.x is the stable branch for x even and unstable for x odd ? I had not understood that. I agree with you that this should not bet stable (non-~), and i would already be very happy to have 1.9.4 in some overlay, even hard masked.. Thanks for your work anyway.
Yes 1.1, 1.3, 1.5, 1.7, 1.9 were/are the development branches that are after a time stabilized to an API compatible (and in 1.8/1.10 also ABI compatible) branch that gets only bug fixes. These are the branches intended for general consumption; the dev releases are mostly so people can follow along, assist in development, or if they really want specific new features that are added along the way before they become generally available in a stable release.
http://botan.randombit.net/news/releases/1_9_4.html :-)
Created attachment 222983 [details] 1.9.4 ebuild As promised, here is an ebuild for 1.9.4. It respects the python use flag to build the boost python wrappers, but the whole build setup for the python stuff is really pretty poor. Right now it's hardcoded for building/installing itself for python2.6 only, for one thing. I would not recommend this for inclusion into portage due to this, but feel free to mess around with it. (And patches to improve the Python wrappers in any way would be happily accepted)
Thanks a lot! It works well here (~amd64). I dont know about the build system for python, but i'm not surprised that it is 'rough'.... the python bindings are in a very early stage, though already quite useful (at least for me :-) Anyway, thanks again!
botan 1.9.x are released quite often. We are now at 1.9.7. And each release brings interesting stuff (at least for us). Could we have, say, the next one(1.9.8) in portage ? (masked if needed) Of course i agree it should certainly be at the very least unstable (~amd64,~x86)
renaming the ebuild to 1.9.7 works for me
Created attachment 235263 [details] dev-libs/botan-1.9.8 ebuild Attached a new ebuild for 1.9.8, with some small changes ported in from the 1.8.8-r1 ebuild for OS X. Caveat: dev-vcs/monotone will build with 1.9, but refuses to run "error: This monotone binary does not work with Botan 1.9.x." - checking the source, it just categorically rejects anything over 1.9.0. Think this is due to ABI stability (or lack thereof) in 1.9, not sure though.
i've installed botan-1.9.8.ebuild today, and really few files are installed. Most importantly the main .so seems to be missing.. ? ------------------------------------------------------------------------ # equery files botan * Searching for botan ... * Contents of dev-libs/botan-1.9.8: /usr /usr/lib /usr/lib/debug /usr/lib/debug/usr /usr/lib/debug/usr/lib /usr/lib/debug/usr/lib/python2.6 /usr/lib/debug/usr/lib/python2.6/site-packages /usr/lib/debug/usr/lib/python2.6/site-packages/botan /usr/lib/debug/usr/lib/python2.6/site-packages/botan/_botan.so.debug /usr/lib/python2.6 /usr/lib/python2.6/site-packages /usr/lib/python2.6/site-packages/botan /usr/lib/python2.6/site-packages/botan/__init__.py /usr/lib/python2.6/site-packages/botan/_botan.so # ldd /usr/lib/python2.6/site-packages/botan/_botan.so linux-vdso.so.1 => (0x00007ffff2fff000) libbotan-1.9.8.so => not found libboost_python-1_42.so.1.42.0 => /usr/lib/libboost_python-1_42.so.1.42.0 (0x00007fd07ab4d000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/libstdc++.so.6 (0x00007fd07a83b000) libm.so.6 => /lib/libm.so.6 (0x00007fd07a5ba000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fd07a3a2000) libc.so.6 => /lib/libc.so.6 (0x00007fd07a03c000) libutil.so.1 => /lib/libutil.so.1 (0x00007fd079e39000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fd079c1b000) libdl.so.2 => /lib/libdl.so.2 (0x00007fd079a17000) /lib64/ld-linux-x86-64.so.2 (0x00007fd07b029000) ------------------------------------------------------------------------
if i edit the ebuild with vim, the following line in src_install() is red, which usually means there's an error according to the vim syntax coloring specification file. emake DESTDIR="${ED}usr" install || die "emake install failed" Though i have no idea of what's wrong. That's probably related to missing installed file. The python files are installed later on.
oops, fortunately the former botan-1.9.7.ebuild still works and installs everything! Just so that you know!
Created attachment 251191 [details] dev-libs/botan-1.9.10.ebuild It's an EAPI problem I think. At some point someone updated the version of the ebuild in CVS to EAPI 3 but I continued using EAPI 2 in my local dev branch ebuild. ${ED} is EAPI 3 only, so things broke entirely, and clearly I didn't test that ebuild very carefully before I uploaded it. Attaching a new version for 1.9.10 that seems to fix this.
yeps, confirmed, this one works a lot better, thanks for the very quick answer/fix!
Jack, I can add the -1.9* ebuild to the tree masked if you like. As you're the upstream maintainer, I'm going to differ to your judgment though as to whether or not this makes sense.
Dane, I would definitely lean against including the 1.9 ebuilds, at least until things have reached the stage of being release candidates for 1.10, which probably won't happen before spring. There is also at least one issue with the current 1.9 release and the latest monotone release: http://code.monotone.ca/p/monotone/issues/104/ This should be resolved in the following releases of botan and/or monotone.
if 1.9.* are included in the main tree and hardmasked, the message that the API is not to be relied upon will be clear enough i think. Please add it :)
(In reply to comment #17) > if 1.9.* are included in the main tree and hardmasked, the message that the API > is not to be relied upon will be clear enough i think. Please add it :) > I'm sorry, but I don't follow this. What's wrong with the API in botan-1.8*? On a related note, I am willing to keep 1.9* masked in my overlay if people need it. It should show up soon. Overlay name is c1pher. It will be hardmasked.
There's nothing wrong with API of 1.8.x. Botan 1.9.x (not 1.8) is a development branch, and as such the api is not stable, this is why Jack (author of botan) is worried about inclusion in gentoo. What i'm saying is that hardmasking it makes it clear enough for people not to rely on it. Nothing else.
Created attachment 254629 [details] Updated ebuild
Ok. Some notes: Everyone: I've added the 1.9.10 ebuild to my overlay (c1pher in layman). Feel free to use it. When Jack thinks it's safe to have it in the main tree, I will gladly add it, for now though, that will be it's home. Jack: Couple things. First, I made a couple changes to the ebuild. (See attached). Most notable is the use of PYTHON_DEPEND. Seeing that the build system is dependent on Python (as best as I can tell) it's an unconditional depend on Python-2 >= 2.6 with all of the version 3* pythons masked. (PYTHON_RESTRICT_ABIS). If you haven't seen this before, it's very handy [1]. Also, there are some QA issues that will need to be addressed before this goes to gx86. * QA Notice: Files built without respecting LDFLAGS have been detected * Please include the following list of files in your report: * /usr/lib/python2.6/site-packages/botan/_botan.so If you need me to look into it, feel free to shoot me an e-mail. As I'm not familiar with the build system, I'm going to leave it to you for the moment though. [1] http://www.gentoo.org/proj/en/Python/developersguide.xml
Bumped to 1.9.11 in my overlay. In the meantime, I'm closing this. I will continue to manage botan in my overlay while it remains in testing. Jack, when you feel confident that this should be in the main tree, reopen it (and if it's 1.10.* changes the Summary) and I will move what I have into the main tree. Note: It appears to me that 1.9.11 may have some compile issues. So I would recommend against updating if you're using this. I will remove the keywords from it until Jack and I have it worked out.
i confirm 1.9.11 has compile issues. I've bumped 1.9.10 to 1.9.11 in my (local) overlay and it fails to compile: x86_64-pc-linux-gnu-g++ -Ibuild/include -march=native -O2 -pipe -D_REENTRANT -Wno-long-long -W -Wall -fPIC -fvisibility=hidden -c src/engine/openssl/ossl_bc.cpp -o build/lib/ossl_bc.o src/engine/openssl/ossl_arc4.cpp: In member function ‘virtual Botan::StreamCipher* Botan::<unnamed>::ARC4_OpenSSL::clone() const’: src/engine/openssl/ossl_arc4.cpp:24: error: cannot allocate an object of abstract type ‘Botan::<unnamed>::ARC4_OpenSSL’ src/engine/openssl/ossl_arc4.cpp:20: note: because the following virtual functions are pure within ‘Botan::<unnamed>::ARC4_OpenSSL’: build/include/botan/sym_algo.h:28: note: virtual Botan::Key_Length_Specification Botan::SymmetricAlgorithm::key_spec() const src/engine/openssl/ossl_arc4.cpp: In constructor ‘Botan::<unnamed>::ARC4_OpenSSL::ARC4_OpenSSL(size_t)’: src/engine/openssl/ossl_arc4.cpp:26: error: no matching function for call to ‘Botan::StreamCipher::StreamCipher(int, int)’ build/include/botan/stream_cipher.h:19: note: candidates are: Botan::StreamCipher::StreamCipher() build/include/botan/stream_cipher.h:19: note: Botan::StreamCipher::StreamCipher(const Botan::StreamCipher&) src/engine/openssl/ossl_arc4.cpp: In member function ‘virtual Botan::StreamCipher* Botan::OpenSSL_Engine::find_stream_cipher(const Botan::SCAN_Name&, Botan::Algorithm_Factory&) const’: src/engine/openssl/ossl_arc4.cpp:75: error: cannot allocate an object of abstract type ‘Botan::<unnamed>::ARC4_OpenSSL’ src/engine/openssl/ossl_arc4.cpp:20: note: since type ‘Botan::<unnamed>::ARC4_OpenSSL’ has pure virtual functions src/engine/openssl/ossl_arc4.cpp:77: error: cannot allocate an object of abstract type ‘Botan::<unnamed>::ARC4_OpenSSL’ src/engine/openssl/ossl_arc4.cpp:20: note: since type ‘Botan::<unnamed>::ARC4_OpenSSL’ has pure virtual functions make: *** [build/lib/ossl_arc4.o] Error 1
Yes, the OpenSSL plugin and the Python wrappers had compilation problems in 1.9.11. Both were fixed in 1.9.12.
(In reply to comment #23) > i confirm 1.9.11 has compile issues. I've bumped 1.9.10 to 1.9.11 in my (local) > overlay and it fails to compile: > > x86_64-pc-linux-gnu-g++ -Ibuild/include -march=native -O2 -pipe -D_REENTRANT > -Wno-long-long -W -Wall -fPIC -fvisibility=hidden -c > src/engine/openssl/ossl_bc.cpp -o build/lib/ossl_bc.o > src/engine/openssl/ossl_arc4.cpp: In member function ‘virtual > Botan::StreamCipher* Botan::<unnamed>::ARC4_OpenSSL::clone() const’: > src/engine/openssl/ossl_arc4.cpp:24: error: cannot allocate an object of > abstract type ‘Botan::<unnamed>::ARC4_OpenSSL’ > src/engine/openssl/ossl_arc4.cpp:20: note: because the following virtual > functions are pure within ‘Botan::<unnamed>::ARC4_OpenSSL’: > build/include/botan/sym_algo.h:28: note: virtual > Botan::Key_Length_Specification Botan::SymmetricAlgorithm::key_spec() const > src/engine/openssl/ossl_arc4.cpp: In constructor > ‘Botan::<unnamed>::ARC4_OpenSSL::ARC4_OpenSSL(size_t)’: > src/engine/openssl/ossl_arc4.cpp:26: error: no matching function for call to > ‘Botan::StreamCipher::StreamCipher(int, int)’ > build/include/botan/stream_cipher.h:19: note: candidates are: > Botan::StreamCipher::StreamCipher() > build/include/botan/stream_cipher.h:19: note: > Botan::StreamCipher::StreamCipher(const Botan::StreamCipher&) > src/engine/openssl/ossl_arc4.cpp: In member function ‘virtual > Botan::StreamCipher* Botan::OpenSSL_Engine::find_stream_cipher(const > Botan::SCAN_Name&, Botan::Algorithm_Factory&) const’: > src/engine/openssl/ossl_arc4.cpp:75: error: cannot allocate an object of > abstract type ‘Botan::<unnamed>::ARC4_OpenSSL’ > src/engine/openssl/ossl_arc4.cpp:20: note: since type > ‘Botan::<unnamed>::ARC4_OpenSSL’ has pure virtual functions > src/engine/openssl/ossl_arc4.cpp:77: error: cannot allocate an object of > abstract type ‘Botan::<unnamed>::ARC4_OpenSSL’ > src/engine/openssl/ossl_arc4.cpp:20: note: since type > ‘Botan::<unnamed>::ARC4_OpenSSL’ has pure virtual functions > make: *** [build/lib/ossl_arc4.o] Error 1 > For what it's worth, I keep an up-to-date and semi-tested ebuild in my overlay 'c1pher' Both of those compile issues were spotted and fixed there. My ebuild is also cleaned up to comply with some of the Python ebuild guidelines. If you can, I would suggest using my overlay for this. It's in there masked. Just unmask it and emerge away. If you run into issues, all you need to do is shoot me an e-mail and I will get with Jack and get them resolved. It saves everyone time and effort. Just my 2 cents.
yes, i forgot to say : i've switched to the ebuild in your overlay since then. It installs fine, thanks a lot!
Argh, since i've switched over to python 2.7, all botan stuff is broken. Even if i (or python-updater) reinstall. The reason is that python-2.6 is _hardcoded_ in the ebuild!! Even the one in the c1pher overlay.
