Bugzilla Bug 45855

new program release, still testing but should be stable enough
attached ebuild (project changed homepage and sourceforge mirror are no more updated)

Created an attachment (id=28129) [details]
ebuild for amule 2.0.0 rc1

Created an attachment (id=28130) [details]
ebuild for amule 2.0.0 rc1

sorry, don't know why previous attach didn't work

Hi!
I have created one ebuild that seems to be more complete.
I've used the 1.2.6 ebuild as base, and made the necessary changes...
If you want test it, and post the results... I have my amule runnning built by this ebuild.

Created an attachment (id=28165) [details]
amule 2.0.0rc1 ebuild (more complete)

This eBuild doesn't work at all here, crashes on startup upon cryptkey.dat
creation. The crash accours inside cryptopp library. Few ideas:
* Comments in Crypto++ makefile warn about not optimizing with -O2 because it
can cause problems.
* aMule doesn't like being heavily optimised either (I used -O3 -march=pentium4
-fomit-frame-pointer right now).

Solution:
* Disable user-specified optimizations for both Crypto++ and aMule, because
neither seem to like heavy optimizations.

Another thing: Please do _NOT_ build aMule against wxGTK2! GTK2 support in
wxWidgets is EXPERIMENTAL (see wxGTK './configure --help | grep gtk2'), and
causes heavy memory/cpu leaking even in most trivial apps (minimal wxWidgets
app has ~50 leaked objects already). Moreover, linking against wxGTK2 has never
been supported by aMule developers either.

sorry I forgot one thing:
I'm using this ebuild (http://bugs.gentoo.org/show_bug.cgi?id=45821) for crypo++.

"Please do _NOT_ build aMule against wxGTK2!"
I'm not building amule agains GTK2, the stuff in pkg_setup() is to prevent using wxwindows linked with gtk2.

Enjoy and if you find something that can be improved just do it... because I'm still learning.

i've got working amule with my ebuild and these CFLAGS: "-march=athlon-xp
-m3dnow -msse -mmmx -O2 -pipe -fforce-addr -fomit-frame-pointer"

wxGTK linked to gtk2 and crypto++ problems are not related to this ebuild

check introduced by paulo fidalgo will be useful, i think

Created an attachment (id=28186) [details]
Improved to detect wxgtk2 and patch a crash bug.

Actually, your check only assured it won't get compiled against wxgtk2u, but it
still allows compiling wxgtk2. However, thats strongly not recommended either.
I attached an ebuild with the following modifications:
* Detects wxgtk2 and aborts if found, notifying to emerge wxGTK with USE=-gtk2.
* Removed --disable-amulecmd configure flag. Even as there is no wxBase to link
  against, amulecmd should still be built (it will be linked against wxGTK
then).
* Added patch from official aMule developer that fixes some serious networking-
  related crashes (some new aMule mod popped up and is sending wrong packets).

Created an attachment (id=28187) [details]
From official developer: Fixes networking-related crashes.

Patch from Kry (main aMule developer). Fixes networking-related crashes due to
some new aMule mod sending incorrect packets.

i talked with other gentoo users today
it seems that amule doesn't work if crypto++ isn't compiled with -O2, so crypto++ ebuild should be modified as told in http://bugs.gentoo.org/show_bug.cgi?id=45821

Attachment 28186 [details] depends on >=net-ftp/curl-7.11.0, I did emerge sync 5 minutes
ago and now curl is in net-misc. Yesterday it worked with net-ftp/curl.

Yes net-ftp/curl moved to net-misc/curl, just change that in the ebuild and it
should work.

Created an attachment (id=29422) [details]
Patch to fix a bug in amule-2.0.0_rc2 which would deny uploads to emule 4.2

Official patch from the developers at amule.org

Created an attachment (id=29423) [details]
ebuild for amule-2.0.0_rc2 with emule-4.2 compatimility patch

Modified 2.0.0-rc1 ebuild for amule-2.0.0_rc2 including the emule 4.2 patch

Created an attachment (id=29436) [details]
Updated ebuild with optimization disabled, resulting in higher stability.

Duh. Completely forgot about that. Sorry folks!

Created an attachment (id=30176) [details]
ebuild without patch as it is now already applied in the tarball

The patch has already been applied in the tarball which is currently
downloadable. The patch is no longer tried to be applied in this ebuild.

src_unpack seems kinda unneeded...

Also, could you edit the ebuild to IUSE="debug" and `use_with debug`, instead of just disabling it, or is there a problem with debugging support being enabled?

A new aMule version came out, amule-2.0.0-rc3!
Just change the amule-2.0.0-rc2.ebuild file's name to amule-2.0.0-rc3.ebuild, and it should compile just fine.

Use the latest one, the one posted by Adrian Gygax at 2004-04-27.

Good luck!

Created an attachment (id=30513) [details]
ebuild for aMule 2.0.0 rc3

upgraded ebuild for new rc3 release

optimizations are now disabled for better stability and this ebuild has 3 new
USEs:

debug: enables or disables debug
noamuleremote: optionally disables remote control utilities (webserver, web
client, amulecmd text client); they're still builded by default
noamulestats: optionally disables amule GUI statistics, that require a new
dependency, libgd; still builded by default too

now in portage with some slight alterations (crypto++ isn't yet tested for
amd64 users- file a new bug if you get it to compile correctly on that
architecture)
Thanks!

we'll add it back to ~amd64 as soon as bug #49034 is resolved and someone says
'it works!'