Bugzilla Bug 175599

This is an ebuild i wrote for RetroShare, an InstantMessenger and P2P programm
with buildin SSL encryption and Web of Trust. It uses a patched version of
openssl and uses KadC library, both are build within the ebuild.
Project homepage is http://retroshare.sf.net/. The project seems to be under
constant development and is in alpha state atm, but was linked on heise.de, so
i think there is enough interest on it to write an ebuild.

Reproducible: Always

Steps to Reproduce:




Emerges fine here. The openssl component in the ebuild is the only component
with some autoconfig features. The patching of the openssl configure file only
takes care of machines which are identified as "linux-elf", i did not have a
pentium so i did not take care of that. Kadc and the RetroShare core have
nonautomated build functions, so patching should work fine there. The QT Gui
uses qmake to generate a makefile, this makefile is then patched to adapt to
make.conf settings.
Please tell me how it works for you.

Created an attachment (id=117009) [details]
The ebuild for version 0.3.0_pre8

there is now a rc1 available. could you adapt your ebuild?

retroshare is gaining momentum, i vote for inclusion in gentoo as well.

I found some time to update the ebuild for the latest version of RetroShare.
You need the ebuild and the retroshare script in the /files dir of your portage
overlay.

Please report any bugs here or join #retroshare on freenode.
Is mysql a build dependency? I think so...

To the people in charge: I like to be maintainer for this package.

Created an attachment (id=139794) [details]
the updated ebuild

Created an attachment (id=139796) [details]
wrapper script to distribute the kadc.ini to the users ~/.pqiPGPrc

this script distributes a file to the users ~ and starts the gui afterwards

ebuild works here

Created an attachment (id=160182) [details]
updated ebuild for the recent version

wrapperscript no longer needed

Created an attachment (id=160183) [details]
most recent stable version

fixed a minor bug/typo and changed 2 makes to emakes

please contact me for connection tests, thanks

Created an attachment (id=161707) [details]
Ebuild for the latest stable linux source

New source package was released today.
Builds and works fine on 32bit x86. Needs 64bit testing.

I do like to maintain this ebuild, I am an official packager for the Retroshare
project and I maintain the ebuild and another (generic) install script.

I tried to add the ebuild to the sunrise tree today, but there are too many
issues with it. 
 - The tar referenced contains sources to non-retroshare libraries (openssl,
smplayer etc.)
- the SRC_URI should use ${PN}
- the dependency to >=qt-4.4 is not clear

Maybe the maintainer could submit his package to sunrise himself...

Thanks for your effort, Per!

" - The tar referenced contains sources to non-retroshare libraries (openssl,
smplayer etc.)"
The Openssl version in the source is a patched one and incompatible to system
ssl. (Or better to say: systems ssl wont work for retroshare). So this one is
needed as provided.

There are no ebuilds for miniupnpc and qcheckers, I could write them, but i was
too lazy and used the build mechanism as intended by the RS developers.

Smplayer is in portage, so I could somehow get the libsmplayer.a which RS
needs.
But here again I was lazy, because I first wanted to see if anybody is willing
to use/test RS.

How strict is the gentoo policy on such tar packages? Are they strictly
forbidden or only have to be avoided? Iirc, audacity does include something
like this aswell.

"- the SRC_URI should use ${PN}"
Why? What is the problem with ${PV}?

"- the dependency to >=qt-4.4 is not clear"
I don't understand what you mean. >=x11-libs/qt-4.2.2 is needed.

I have no idea how to add an ebuild to sunrise. Maybe you can contact me via
email or on freenode (same nick as here) and we can discuss the issues there?

I tried it on amd64 and it will not compile with the following error :

udpsorter.cc: In member function ‘int UdpSorter::doStun(sockaddr_in)’:
udpsorter.cc:331: warning: unused variable ‘sentlen’
udpsorter.cc: In member function ‘bool UdpSorter::checkStunKeepAlive()’:
udpsorter.cc:625: warning: comparison between signed and unsigned integer
expressions
g++ -march=athlon64 -O2 -msse3 -pipe -fomit-frame-pointer -ftree-vectorize
-ftree-loop-linear -Wall -I ..  -I
../../../../../src/openssl-0.9.7g-xpgp-0.1c/include   -DPQI_USE_XPGP -c
udptestfn.cc
g++ -march=athlon64 -O2 -msse3 -pipe -fomit-frame-pointer -ftree-vectorize
-ftree-loop-linear -Wall -I ..  -I
../../../../../src/openssl-0.9.7g-xpgp-0.1c/include   -DPQI_USE_XPGP -c
tcppacket.cc
g++ -march=athlon64 -O2 -msse3 -pipe -fomit-frame-pointer -ftree-vectorize
-ftree-loop-linear -Wall -I ..  -I
../../../../../src/openssl-0.9.7g-xpgp-0.1c/include   -DPQI_USE_XPGP -c
tcpstream.cc
tcpstream.cc: In member function ‘int TcpStream::send()’:
tcpstream.cc:2113: error: ‘UINT_MAX’ was not declared in this scope
tcpstream.cc: In member function ‘bool TcpStream::isOldSequence(uint32,
uint32)’:
tcpstream.cc:2292: error: ‘UINT_MAX’ was not declared in this scope
tcpstream.cc:2300: error: ‘UINT_MAX’ was not declared in this scope
make[1]: *** [tcpstream.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/net-misc/retroshare-0.4.09b/work/retroshare-package-v0.4.09b/src/retroshare-v0.4.09b/libretroshare/src/tcponudp'
make: *** [librs] Error 2
 *
 * ERROR: net-misc/retroshare-0.4.09b failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 2127:  Called die
 * The specific snippet of code:
 *       emake -j1 || die "emake of retroshare failed";
 *  The die message:
 *   emake of retroshare failed
 *
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/tmp/portage/net-misc/retroshare-0.4.09b/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/net-misc/retroshare-0.4.09b/temp/environment'.
 * This ebuild is from an overlay: '/usr/local/portage/'

Compiles fine here (x86).
But won't run:
retroshare-nogui: error while loading shared libraries: libminiupnpc.so.2:
cannot open shared object file: No such file or directory

Don't know where to get that lib...

(In reply to comment #14)
> Compiles fine here (x86).
> But won't run:
> retroshare-nogui: error while loading shared libraries: libminiupnpc.so.2:
> cannot open shared object file: No such file or directory
> 
> Don't know where to get that lib...
> 

works when compiling manually... -_-

(In reply to comment #14)
> Compiles fine here (x86).
> But won't run:
> retroshare-nogui: error while loading shared libraries: libminiupnpc.so.2:
> cannot open shared object file: No such file or directory
> 
> Don't know where to get that lib...
> 

http://83.234.250.1/ports/net/miniupnpc/pkg-plist

I tried om my amd64 manually and the ebuild, the error i s the same!

Created an attachment (id=184174) [details]
GCC 4.3 compatibility

Works for me under amd64 + gcc 4.3.3
but also hitting the problem with libminiupnpc.so.2 (looking forward for
placing right dependencies in ebuild)

(In reply to comment #14)
> Compiles fine here (x86).
> But won't run:
> retroshare-nogui: error while loading shared libraries: libminiupnpc.so.2:
> cannot open shared object file: No such file or directory
> 
> Don't know where to get that lib...
> 
Looks like this retroshare-nogui is valid only if USE=dedicated present
I have RetroShare binary which does all as expect

(In reply to comment #18)
> (In reply to comment #14)
> > Compiles fine here (x86).
> > But won't run:
> > retroshare-nogui: error while loading shared libraries: libminiupnpc.so.2:
> > cannot open shared object file: No such file or directory
> > 
> > Don't know where to get that lib...
> > 
> Looks like this retroshare-nogui is valid only if USE=dedicated present
> I have RetroShare binary which does all as expect
> 

retroshare-nogui is only used on headless systems.

the RetroShare binary is what you use on desktops.
I'll look into the ebuild later, but i think we need a svn ebuild, cause
version 4.09b is quite out of date.

Thanks for testing and reporting!