I have created ebuilds to two packages: the JAP mixer software and XERCES-C (which is a dependency of the JAP mixer software). JAP (see: http://anon.inf.tu-dresden.de/index_en.html) is an anonymizer/proxy. The normal program used to utilize it is a slow annoying Java program. However, the JAP home page shows how to use their mixer software as a replacement (see: http://anon.inf.tu-dresden.de/develop/commandline_jap_en.html). The mixer software is written in C++ and can be run like any other native program. XERCES-C (see: http://xml.apache.org/xerces-c) is a dependecy of JAP. It appears to be very similar in purpose to the dev-java/xerces already in the portage tree. However, XERCES-C is written in C++. Since JAP needed it, I wrote an ebuild that made it. The ebuilds I wrote are net-www/jap-mix and dev-lib/xerces-c. I will attach a tar.bz2 to this bug with the necissary files. I realize that since Gentoo is in the release candidate stages of 1.4 that there is probably an ebuild freeze going on right now. However, I've uploaded these 2 ebuilds so that you can deal with them at your convenience. If you have further questions concerning them, I am willing to help. :) Regards, Hezekiah Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 8000 [details] The ebuilds for jap-mix and xerces-c
What we have here is two ebuilds: i) Xerces-C, an XML parser written in C ii) JAP, a C++ port of a Java anonymizer/proxy. Not my bag.
A small correction to the previous comment is needed. The JAP ebuild I wrote is NOT for a C++ port of a Java anonymizer/proxy. The author of the previous comment was apparently confused by the relationship between the JAP client (which is written in Java) and the JAP mixing software (which is written in C++). (However, the author did say it wasn't his "bag", so I don't blame him for being confused.) :) My ebuild was written to install the JAP mixing software. The JAP client connects to a series of mixing relays. This series of relays is what keeps the person connecting with the JAP client anonymous. The relay mixing software is written in C++. The nice thing is that you can use this mixing software as a replacement for the Java client. Thus, the Java client and C++ relay are different, one is not the port of the other, but you can make the mixing software do the same job as the Java client. Since the Java client is slow, annoying, and leaves up a little window you can't close, I wrote up an ebuild that uses the mixing software instead. This is the ebuild which I posted above. I hope this has cleared up the relationship between the JAP client (downloadable from http://anon.inf.tu-dresden.de/index_en.html) and the mixing software (which is what I wrote the ebuild for.) If anyone has questions on this, just ask! :) -- Hezekiah
This are both C && C++ Based, they are not java based. i) Xerces-C, an XML parser written in C ii) JAP, a C++ port of a Java anonymizer/proxy As says comment number 2 (Nothing in Java). So returning to bug-wranglers
The JAP mixer is not a C++ port of the JAP client! They are completely different. The mixer is a server (written in C++), the client is a client (written in Java). Please see my previous comment for further explaination. -- Hezekiah
this is rather interesting. i've read about anonymizing mixers and stuff, never tried one though. do you know if jap works with the new xerces-c-2.2.0 ? to be honest, i haven't had time to try out your ebuilds. but a couple of pointers: 1. you should not need to include make, gcc as dependencies 2. RDEPEND should have only the run time dependencies (which you have) and DEPEND should be extra dependencies for building plus ${RDEPEND}. 3. its best to just use make instead of gmake. its just stylistic thing. 4. never encode the version number in the SRC_URI or WORKDIR. do something like: MY_PV=${PV/./_} S=${WORKDIR}/${PN}-src${MY_PV} I'll leave it up to you to read the bash manpage on what MY_PV means :) 5. for jap-mix, that SRC_URI is a moving target because its only a snapshot. do they have a released version or something stable? because it would be a problem to support something that keeps on moving. if there is a version that is stable, we could put it on gentoo's mirror with a version number. they seem to have weird versioning. anyhow, thats something for you to ponder about, and maybe submitting a new ebuild with those changes.
Thanks for the ebuild writting tips. :) I'll try to remeber them for next time. As for the next xerces-c ebuilds you mentioned, I haven't installed them. I have a somewhat out of date Gentoo installation. I haven't had time to update it in a long time. So, I really don't know if the new xerces-c ebuilds work or not. As for the SRC_URI, I'm afraid that it doesn't look like there is an official stable release of the JAP mixing software yet. Thus, for now the best you can do is either download the nightly tarball, or use their CVS tree. I'm sorry that these ebuild aren't very pretty, but I mostly wrote them for myself and posted them here so if someone was interested they could correct them and implement them into the portage tree. I'm not that surprised that they need some work. :) -- Hezekiah
i got a xerces-c ebuild .. someone wants it? (got some problems with src_install though..)
Created attachment 12417 [details] Ebuild for xerces 2.2.0 c++ version Working ebuild, I believe it's per gentoo specs but not 100% sure. Support for icc.
I went ahead and created/ submitted into Portage the ebuild for 2.3.0. I used all of the fixes mentioned, including the MY_PV fix. What I did not add was the ICC stuff, since I don't have any Intel machines to test it on ;) Feel free to add the ICC stuffs if it works. //zhen
Created attachment 15637 [details] jap-mix-0.01.74.ebuild Hi, I bugged the jap-team to add a stable release on their website and fix the xerces-c 2.3 incompatibility ebuild changes: -removed cxxflags patch, I'm too lazy and it's more secure to stay with the flags the developers chose (I commented these lines out, so either remove them or recreate this patch, please) - >=dev-libs/xerces-c-2.3.0-r5, because I didn't test it was another version. - added rc script & standard conf for local usage (port 6544)
Really weird. I tried emerge xerces-c (2.3.0-r1), which stopped right at the beginning. And then... for some unknown reason I tried MAKEOPTS="-j1" in /etc/make.conf, which resulted in a fully emerged xerces-c. But I don't know if this is a problem with the ebuild or with something in my set-up... :/
try -r5 - it should be marked stable imho (http://bugs.gentoo.org/show_bug.cgi?id=22928#c5)
Check bug 22988 - I have added a line that fixes MAKEOPTS to -j1. Give it some testing loving, then I will mark it stable.
scratch - bug is: http://bugs.gentoo.org/show_bug.cgi?id=22928#c5
I build an ebuild for a the 00.05.022 version of the mix software. There have been some legal issues about the security of the dresden-cascade, but most links i can give are in german. But there is something on their hompeage about that, They have a static link for the nightly snapshot now: http://anon.inf.tu-dresden.de/develop/mix.src.tgz Also, I'd like to maintain this package, if possible. I mailed them and asked about there license, because i found non on their homepage. The only comment about licenses is a hint to their devs, not to include anything with GPL for commercial issues. That doesn't sound nice to me. I will add my ebuild if it is properly checked.
Created attachment 68936 [details] Ebuild for the JAP-mix proxy software This is my version of the ebuild for the jap-mix software. It downloads and installs a tarball of a nightly snapshot. I don't know about their license and will add that later. This release is just to get comments if it works for other people. Works fine here. Xerces is in portage now and is no problem to me with version 2.6.0. The help function ("mix -?")of the binary is broken here.
i had trouble compiling. the problem is in the jap-mix sources. they seem to expect an older version of openssl. i have openssl-0.9.7j installed. CACertificate.cpp: In static member function 'static CACertificate* CACertificate::decode(const UINT8*, UINT32, UINT32, const char*)': CACertificate.cpp:108: error: invalid conversion from 'const UINT8**' to 'unsigned char**' CACertificate.cpp:108: error: initializing argument 2 of 'X509* d2i_X509(X509**, unsigned char**, long int)' CACertificate.cpp:115: error: invalid conversion from 'const UINT8**' to 'unsigned char**' CACertificate.cpp:115: error: initializing argument 2 of 'PKCS12* d2i_PKCS12(PKCS12**, unsigned char**, long int)' CACertificate.cpp:136: error: invalid conversion from 'const UINT8**' to 'unsigned char**' CACertificate.cpp:136: error: initializing argument 2 of 'X509* d2i_X509(X509**, unsigned char**, long int)' make[2]: *** [CACertificate.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/jap-mix-00.04.26/work/proxytest' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/jap-mix-00.04.26/work/proxytest' make: *** [all] Error 2 quick and dirty fix: change in /usr/include/openssl/opensslv.h #define OPENSSL_VERSION_NUMBER 0x009070afL to #define OPENSSL_VERSION_NUMBER 0x0090704fL then it compiles fine. chqange it back afterwards. i guess i clean solution would be to exchange the #ifdef in the sources to the correct version string.
Created attachment 123062 [details] jap-mix-0.05.38.ebuild Hi, i have updated Carlo's ebuild to work with the latest stable version of (jap-)mix-0.05.38. The ebuild installs well on my machine, but the start-stop init-scripts are not working properly, as there is no pidfile generated, so the service will not stop. Therefore you have to manually stop the service. I have tried a few things to get it working , but i failed. Maybe someone can fix this. A few comments to the JAP Anonymization-Tool. It has been renamed to JonDo (http://www.jondos.de) and will be commercial in the next time as public funding ran out. The commercial service will only provide a bandwidth of 64-128 kbit/s. Take a look at the payment methods here (http://www.jondos.de/en/payment). There will remain a free service, but they have shorter mix-cascades and the bandwidth is even lower. So if you need higher bandwidth, it is maybe better to use tor as it probably provides higher bandwidths, although it is maybe not that secure, see http://blogs.law.harvard.edu/anonymous/2007/02/26/the-rumors-of-our-demise/. Regards, Daniel
Created attachment 123074 [details] jap-mix-0.05.38.ebuild I found the problem with the init-script. Now it is working properly. It seems that the pidfile commandline option for japmix has changed from --pid-file to --pidfile. I have also tried the tor-anonymizer and it is not significantly faster than jap, just sometimes up to twice as fast, when i have tested it. Regards, Daniel
dev-libs/xerces-c is in the tree already so removing that from summary
(In reply to comment #20) > Created an attachment (id=123074) [edit] > jap-mix-0.05.38.ebuild > Please attach your files as plain text. The people using ebuilds from bugzilla should know how to create digests. Having them as plain text makes it easier for us to comment on them.
(In reply to comment #22) > Please attach your files as plain text. I normally do so, but i went the way Carlo did as there is also a files dir and i didn't want to add to much attachments! Anyway, i will consider this next time.
Either find a maintainer, or if you want to maintain it yourself, feel free to reopen and join project sunrise, details here: http://www.gentoo.org/proj/en/sunrise Thanks. WONTFIX meanwhile. (On a sidenote, dev-libs/xerces-c is already in the tree, no need for that here).
