Just another version bump to 2.5.30. 2.5.29 had a serious file corruption bug that was fixed in 2.5.30. A lot of fixes and improvements. Reproducible: Always Steps to Reproduce:
Created attachment 52660 [details] Ebuild for newest mldonkey
Created attachment 52661 [details] Wrong ebuild upload. Fixed this now
Please attach an unified diff(diff -u old.ebuild new.ebuild) when you make changes to an ebuild.
Created attachment 52664 [details] Diff file between mldonkey-2.5.28-r4 and mldonkey-2.5.30
I think it is best to keep the old version of the ebuild as the patch "Patchpack30a" has just been released. Builds fine here when I use the USE flags "gtk gtk2". When I use "-gtk -gtk2" to build mldonkey 2.5.30a I get an error message that the 2.5.30-config.patch couldn't be applied. I think this patch doesn't apply anymore to version 2.5.30. Here is the diff I used: --- mldonkey-2.5.28-r4.ebuild 2005-03-13 01:00:44.398872136 +0100 +++ mldonkey-2.5.30.ebuild 2005-03-12 21:49:29.836270800 +0100 @@ -6,7 +6,7 @@ IUSE="gtk gtk2" -PATCHPACK="patch_pack28h.gz" +PATCHPACK="patch_pack30a.gz" DESCRIPTION="mldonkey is a new client to access the eDonkey network. It is written in Objective-Caml, and comes with its own GTK GUI, an HTTP interface and a telnet interface." HOMEPAGE="http://www.nongnu.org/mldonkey/"
Created attachment 53903 [details, diff] mldonkey-2.5.30.diff mldonkey-2.5.30 with patchpack 30c diff
*** Bug 85962 has been marked as a duplicate of this bug. ***
Please note that this build depends on ocaml-3.08.2, so the dependencies in the ebuild should be changed.
Out of spiralvoice's info: To build GTK1 newgui: ./configure To build GTK1 oldgui: ./configure --disable-newgui To build GTK2 GUI: ./configure --enable-gtk2 Currently, the oldgui isn't supported by ebuild. Perhaps this could be changed.
Created attachment 54117 [details] ebuild for mldonkey-2.5.30-1 (coming after 30c) This version now requieres dev-lang/ocaml-3.08.3 and the naming system is a problem with portage and the ebuild thingy so i named the ebuild mldonkey-2.5.30-r1 and modified the path for source and workdir. Wanted to make it a new bugzilla bug because it is different to 2.5.30c but the branch was killed ;) The version should definitly stay hard masked!
Created attachment 55638 [details] MLDonkey version bump to 2.5.30-4 New version of mldonkey. Comes after 2.5.30-1 and fixes some minor bugs. Change on gui protocol from version 30 to 31
2.5.30.6 was released today, numbering has changed to avoid problems with portage.
2.5.30.8 was released, grab tarball from here: http://savannah.nongnu.org/download/mldonkey/mldonkey-2.5.30.8.tar.bz2
2.5.30.10 is out: http://savannah.nongnu.org/download/mldonkey/mldonkey-2.5.30.10.tar.bz2
2.5.30.14 is out: http://savannah.nongnu.org/download/mldonkey/mldonkey-2.5.30.14.tar.bz2 You can verify the archive integrity with my public PGP key which can be found here: http://savannah.nongnu.org/users/spiralvoice
I've added an ebuild for mldonkey-2.5.30.14 when I've added the "gd" use-flag because the new mlnet version can produce some bandwidth graph (in the statistic section of web-based interface) using gd library. The gd useflag imply dependency on media-libs/gd and media-libs/freetype packages
Created attachment 57668 [details] mldonkey-2.5.30.14.ebuild
Created attachment 58260 [details] mldonkey-2.5.30.14.ebuild fixed ocaml-3.08.3 dependency
2.5.30.15 was released...
I don
I don´t know if this is the right place for discussing this, if not please tell me where a better place would be. I wrote a patch enabling MLDonkey daemon to create a pid file: http://savannah.nongnu.org/patch/?func=detailitem&item_id=3985 However in the patch there is a discussion about the naming of the pid file, it would be nice if package admins would comment on that.
*** Bug 92811 has been marked as a duplicate of this bug. ***
*** Bug 94889 has been marked as a duplicate of this bug. ***
2.5.30.16 has been released. http://bugs.gentoo.org/show_bug.cgi?id=89220 carries a new ebuild which respects the GTK2 build flag.
Current stable version in portage is 2.5.16-r9. It's 1 year and 3 months old... and current version is 2.5.30.16. I've found comment in package.mask: # <squinky86@gentoo.org> (17 Aug 2004) # Masked by request of upstream developers. >=net-p2p/mldonkey-2.5.17 I'm new for mldonkey and just wondering: what's the best version now to install and try mldonkey for the first time? If it still 2.5.16, then is there any need to fetch newer .ini-files from somethere?
There is no need to refrain from 2.5.30.16 nowadays, especially if you want to use BT.
When will a new version be placed in portage?
2.5.30.17 was released today
I made a bunch of GTK-disabled ebuilds for putting in /usr/local/portage/net-p2p/mldonkey/ its still masked by ~* and package.mask, though. You can find them at http://dabserver.dyndns.org/dabljuh/mldonkey/
2.6.0 was just released with really important changes (overnet/kad memleak solved) see http://savannah.nongnu.org/cgi-bin/viewcvs/mldonkey/mldonkey/distrib/ChangeLog?rev=release-2-6-0&content-type=text/vnd.viewcvs-markup
Created attachment 63842 [details] The ebuild for mldonkey-2.6.0 I just finished testing this new mldonkey-2.6.0 ebuild. It contains some fun new use flags for your pleasure. Read the ebuild for more info. Also, with 2.6.0 being a stable release, I recommend it to be put into the regular portage tree soon, as well as removing the package.mask lines that keep mldonkey at the soon ancient level of 2.5.16
Hi! (In reply to comment #30) > Also, with 2.6.0 being a stable release, I recommend it to be put into the > regular portage tree soon, as well as removing the package.mask lines that keep > mldonkey at the soon ancient level of 2.5.16 I don't agree: All the ebuilds for versions *between* 2.5.16 and 2.5.30 should be removed from portage tree because they're not developed anymore and are buggy as hell. 2.5.16 is still developed and will be soon be released unser the name "mulus" and it's ebuild shall remain in portage until a mulus ebuild is marked stable. Until then, my ebuild for 2.5.16-w1 from bug #93894 should be added to portage because it fixes important bugs which harmed the network and the other 2.5.16 versions should be removed. Best regards Christian
Or that. Anyway, the current situation of mldonkey in portage is quite desolate as no ebuild ever seems to be moved into the rsync tree.
Created attachment 63957 [details] mldonkey-2.6.0-r1 Alright. This is the new and improved ebuild, it features - Much improved USE flags. - More & better dependencies - Disabled gtk2 support because I couldn't get that to compile anywhere, despite trying for 3 hours together with spiralvoice (it works no problem with his self-compiled libraries) And: Who the smeg do you need to shag here to get some attention from net-p2p@gentoo?
Created attachment 63958 [details] updated mldonkey-2.6.0 with gtk2 support Alright, if anyone wants to test the gtk2 support in the same context, try this updated ebuild. It is identical to the -r1 except for allowing you to use gtk2 support. Please give it a shot (USE="X gtk2" and report back)
Created attachment 64049 [details] net-p2p/mldonkey-2.6.0.ebuild (ONLY CVS, read comment) WARNING: this ebuild works well only with new CVS version of mldonkey!!! * I think ocaml isn't enough intuitive I've changed in batch (it can be probably use with lablgtk too) * New use flag: -- guionly (http://bugs.gentoo.org/show_bug.cgi?id=89220), it builds only the GUI -- doc * added gtk2, gtk, oldgtk mutual exclusion * changed gui configure option (mldonkey patch #4195) -- committed by spiralvoice on 2005/07/21 * respecting official mldonkey docs, ebuild only install mlnet and mlgui bins
mldonkey-2.6.0-r1 does not install /etc/conf.d/mldonkey and /etc/init.d/mldonkey.
Added mldonkey-2.6.0 to portage, thanks for help.
shouldn't the pid file be under /var/run/ ?
(In reply to comment #38) > shouldn't the pid file be under /var/run/ ? Normally yes, but MLDonkey is used in different environments, like Windows, chroot and so on and it is not guaranteed that /var/run exists everywhere or is writable for the MLDonkey core. So I hardcoded the file position to the working directory. The only thing I can think of is an environment variable like MLDONKEY_PIDDIR, what do you think about it?
(In reply to comment #39) > The only thing I can think of is an environment variable like MLDONKEY_PIDDIR, > what do you think about it? How about option for starting mldonkey... s/t like mldonkey --with-piddir=/path/to/dir this would be even simplier to use with different environments? only my 2 cents :) Regards, Przemek
It is quite common to take the approach proposed in comment 40. Thats how many other daemons handle it, i.e. take it from the command line. I also noticed that when mldonkey fails to startup, the rc-status is still 'started' whereas it should be `off'. However this shall go as a seperate bug report I think....
