New mldonkey version.
Created attachment 36466 [details] mldonkey-2.5.22 ebuild Made some changes to the ebuild. 1. Removed the patch as it doesnt work with this version anymore 2. GTK gui build is now build with --enable-gtk2. Changed the script to do that when gtk gui is wanted.
Its not clear if the download bug is fixed. If someone knows please say so.
Created attachment 36467 [details] mldonkey-2.5.22 ebuild Removed some debug infos that were just for testing the new release
Created attachment 36478 [details] mldonkey-2.5.22 ebuild If gtk2 is not in use flag we dont want the gui to be compiled. Configure wanted so gtk lib even if the gui should not be compiled. Problem should be fixed
Download bug is still not fixed.
Created attachment 36493 [details] Patchpack 22a Because my webspace provider has some login problems I will post the first patchpack for CVS 2-5-22 here. Included are these patches: 2974 3053 3064 3146 3157 3160 3183 3235 3242 3245 3246 3249 3250 3251 Descriptions can be found on Savannah: http://savannah.nongnu.org/patch/?group=mldonkey
What download bug do you mean?
Created attachment 36504 [details] mldonkey-2.5.22 including patch New ebuild file to use the patchset provided. Also the gtk issue should besolved. Added new dependencie gtk2. If someone wants the new gui to be compiled against gtk2.
Theres is a download bug, that makes you set your max_download_rate two times the actual rate you want.
According to /usr/portage/profiles/use.local.desc there is a USE flag for MLDonkey: net-p2p/mldonkey:mldonkeypango - enable pango patches for mldonkey Should this flag be used in MLDonkey ebuilds?
Created attachment 36575 [details] mldonkey-2.5.22.ebuild New ebuild now uses the mldonkeypango flag. As some people might not know this new flag I added an info informing people about it.
a few questions: 1) why is http://www.8ung.at/spiralvoice/patches/patch_pack21g in the SRC_URI 2) what is the point of mldonkeypango USE flag- can it be removed? your patch_pack-22a doesn't look all pango-centric at all 3) I'm not sure I understand some of the logic in what all this patch does, and some lines (though I admit I haven't looked at the code as much as I should have), became a bit confusing in the code- I can't tell what all is being updated- could you give me a quick overview?
I removed the src to the patch I simply overlocked it. For the description of the patches go to http://savannah.nongnu.org/patch/?group=mldonkey and look for the patches 2974 3053 3064 3146 3157 3160 3183 3235 3242 3245 3246 3249 3250 3251 As it doesnt look like there are no more pango patches I used the USE variable to patch the core with the supplied patchpack
Created attachment 36657 [details] mldonkey-2.5.22.ebuild including pachtset Removed the link to the old patches from src_uri
Created attachment 36658 [details] mldonkey-2.5.22.ebuild hmm, gtk2 gui fails to compile, though everything else seems to work ok ocamlopt.opt -inline 10 -I src/utils/cdk -I src/daemon/chat -I src/gtk2/chat -I src/utils/lib -I src/utils/ocamlrss -I src/utils/xml-light -I src/utils/net -I tools -I src/daemon/common -I src/daemon/driver -I src/utils/mp3tagui -I src/config/unix -I src/gtk2/newgui -I src/gtk2/configwin -I src/gtk2/okey -I src/gtk2/gpattern -I icons/tux -I +lablgtk2 -I src/gtk2/progress -I src/gtk2/im -I src/gtk2/im/yahoo -I src/gtk2/im/irc -I src/networks/gnutella -I src/networks/gnutella2 -I src/networks/fasttrack -I src/networks/fileTP -I src/networks/bittorrent -I src/networks/donkey -c src/gtk2/newgui/gui_results_base.ml File "src/gtk2/newgui/gui_results_base.ml", line 61, characters 4-16: Unbound value GBroken.tree make: *** [src/gtk2/newgui/gui_results_base.cmx] Error 2
Jon Hood - try: emerge -C lablgtk-2.2.0 (i think) emerge -v =lablgtk-1.2.6 and then try to emerge mldonkey. PS. Both versions of lablgtk may be installed on the system at once, but it's not working with mldonkey.... I do not know why.... Regards, Przemek
*** Bug 59309 has been marked as a duplicate of this bug. ***
Created attachment 36729 [details] net-p2p/mldonkey-2.5.22-r1.ebuild ok, the gtk2 frontend will not build on my gcc-3.4 ~x86 box and fails with the above error every time. Since the regular stuff (not the new gtk2 stuff) builds fine, it is now masked in portage until the gtk2 issue can be resolved. To install, just: # echo "net-p2p/mldonkey" >> /etc/portage/package.unmask and you should be able to upgrade without problem. Note the gtk2-goodness is commented out until it behaves correctly. I'd like to get gtk2 working before we push it even to the testing branches.
I'm sorry for my last post ;-) I read some info about lablgtk and what I wrote is .... big piss of crap. Sorry! Regards, Przemek
The gtk dependency is wrong btw.. The gtk use flag does not mean gtk 1, but gtk (1 || 2), which means if USE="-gtk gtk2" then neither gtk1 nor gtk2 should be supported. This is a backwards compatibility thing irrc. The dependency has to be: gtk? ( !gtk2? ( =dev-ml/lablgtk-1.2.6* ) gtk2? ( =dev-ml/lablgtk-2* ) )
thank you carlo, that is now fixed in the comments of the masked ebuild in portage :). Does anyone have a success story with the gtk2 interface they would like to share?
Ok. I've found a solution for compiling mldonkey with gtk2. The problem is that in portage is quite old version ( ;-) ) of lablgtk-2 : 2.2.0 and on http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html there is newer version - 2.4.0 . With version 2.4.0 gtk2 support for mldonkey is compilling and running with no problems. I think that we need a newer version of lablgtk in portage and - of course: gtk? ( !gtk2? ( =dev-ml/lablgtk-1.2.6* ) gtk2? ( >=dev-ml/lablgtk-2.4 ) ) Ebuild for lablgtk-2.2.0 working fine with 2.4.0 after renaming. PS. Sorry for my english - still learning! ;-) Regards, Przemek
Request for lablgtk version bump: http://bugs.gentoo.org/show_bug.cgi?id=59452 Regards, Przemek
Sorry - a small update... When gtk2 version of mlgui connects to mldonkey server some errors apears.... and app is going down. So - compilling and running works, but not using of it :( Regards, Przemek
MLdonkey 2-5-24 is out, unfortunately for the ebuilds there is no tarball...
Please update your ebuilds, my page has moved to http://ftp.berlios.de/pub/mldonkey/spiralvoice/
MLdonkey 2-5-25 is out with lots of bugfixes, unfortunately for the ebuilds there is no tarball...
The SRC_URI has been updated to reflect your new mirror, spiralvoice :). As for the mldonkey bump, a tarball would be preferred...
New Version again. They seem to work quite a lot at the moment to produce a stable build bevor making a tarball to distribute again.
Another version bump, but still no packed files
I sincerely hope everyone realizes that mldonkey version 2.5-2x is the development tree, and should NOT be included in portage. If it is, it should be in package.mask as is the policy for development branches. All versions greater than 2.5-16 contain completely rewritten ed2k and overnet modules, and performance is very very poor compared with the stable 2.5-16. There are also serious Bittorrent bugs that adversely affect their network. QUOTE from the developer handbook: There is a difference between using package.mask and ~arch for ebuilds. The use of ~arch denotes an ebuild requires testing. The use of package.mask denotes that the application or library itself is deemed unstable. For example, if gimp-1.2.0 is the stable release from Gimp developers, and a new bug fix release is available as 1.2.1, then a developer should mark the ebuild as ~arch for testing in portage because the release is deemed to be stable. In another example, if Gimp decides to release an unstable/development series marked as 1.3.0, then these ebuilds should be put in package.mask because the software itself is of development quality and is not recommended by the developers for distribution. </QUOTE> - http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 Please don't break my Gentoo again.
When I took over net-p2p, the testing branch was already in portage. I got on to an arch dev earlier for marking a >.16 release stable on the arch he maintained, but he did have a good reason for it. Due to coming in to a situation like this, I had to find a mldonkey version that worked (at least for the most part), and put it in ~x86. If you'll look at package.mask, the most recent version of mldonkey in portage is listed because of the reasons you pointed out. If the ~unstable version of mldonkey is broken in any way, please report bugs on it.
The bugs are reported on mldonkey's Savannah bug tracker. http://savannah.nongnu.org/bugs/?group=mldonkey If there's a version unmasked in portage greater than 2.5-16, then thats the bug that I'm reporting here. I've been discussing this with Spiralvoice on the mldonkey mailing list, and he's under the impression that having users using the devel tree is beneficial to the mldonkey developers somehow, thats why he is making announcements here. The job of a distro isn't to provide beta testers though. Masking the latest version does no good, because 2.5-21 and and 2.5-22 perform much worse than 2.5-27. We should stick to 2.5-16 until the project stabilizes. As it stands right now though, 2.5.16-r8 is the best release out there, and its not the latest unmasked version. At least it wasn't after my last rsync.
I have to agree with cumagyar at some point. Maybe place 2.5-2x in package.mask then maybe there mark them as stable? Why this behaivor? In a discussion lately about having evolution 1.5x in portage the conclusion became: If the maintainer of the ebuilds thinks he has the time for it then he can place ebuilds for unstable packages (like the gentoo KDE-team having beta-releases in portage), else he does not have to. Apperently squinky86 thinks he has the time and then he could (and I would like that as I had some problems with 2.5-16 witch I do not have with 2.5-2x) and then maybe they should be placed in packages.mask so anyone does not use it (some noobs easily does use ~arch it seems) but we that likes it and thinks we can handle it may do. And there mark the versions of 2.5-2x that works as stable becouse it apperently does not breake too much.
*** Bug 60187 has been marked as a duplicate of this bug. ***
Kalle: in order to do this, we would need the hppa port to mark one of the .16 ebuilds as stable on their architecture, then we'd be able to keep the development branch in package.mask correctly. If a 2.6_pre or 2.5.2* tarball is stable enough, it should go into ~testing.
Tarball of CVS 2-5-27 is (temporary) online: http://ftp.berlios.de/pub/mldonkey/spiralvoice/cvs/
Experimental Patchpack 2-5-27b is online: http://download.berlios.de/pub/mldonkey/spiralvoice/patchpacks/patch_pack27b.gz There is now a distrib/Changelog_spiralvoice file with infos about the patchpack.
Now masked in portage. I am really enjoying this version and would like to unmask it if no one has any objections? I have had it running for a few hours now.
Created attachment 37385 [details] Experimental CVS ebuild for 2.5.27 w/ spiralvoice patchpack 27b What if we handle the 2.5.2x ebuild like this, and packag.mask it? It fails if X11 forwarding is enabled by default in /etc/ssh/ssh_config though, because it creates ~/.xauth* outside the sandbox. Anyone know how to fix that?
I can maintain these development releases, but in my preference and the preference of most other devs, a tarball is prefered over cvs checkouts. What's wrong with the ebuild now in portage?
I had made this ebuild before the tarball was available, I thought it might be useful. It may be useful if tarballs aren't available for a while again. It extracts the release and patchpack name from $PV, so it should be pretty resilient to version bumps. I just should have included a version number after the _p I guess, because the ebuild howto says not to rely on a trailing letter to bump the version. Or you can comment ECVS_CO_OPTS, and try CVS head any time you want, though the patchpack may or may not apply.
squinky, remember to bump RDEPEND to ocaml-3.08 which 2.5.27 seems to require :)
squinky: can you please make the gtk2 useflag depend on the gtk useflag? It should ONLY look the gtk2 useflag IF the gtk useflag is set, i.e. USE="-gtk" == no gtk at all (no gtk, no gtk2).
thanks Kalle and Gustavo, fixed in portage :)
Its seens like the incoming directry setting is not working in the lateste build 2.5.27. All downloads now go into /home/p2p/.mldonkey/shared/. If you try to set this to another directory with the old ini setting it will just delete the info. Didnt finde out if this is because of the patchset or because of some changes in the version. Does anybody else have this problem.
Believe it or not, thats a feature - not a bug. Its related to this experimental patch in the Spiralvoice patchpack: http://mldonkey.berlios.de/modules.php?name=Forums&file=viewtopic&t=2826 I took a look for the Changelog_spiralvoice in /usr/share/doc/mldonkey*, and couldn't find it. Perhaps its installation needs to be added to ebuild? distrib/Changelog_spiralvoice in the patched source.
Could that patch be the reason my mldonkey does not seems to commit properly? I have "autocommit" and I have two files laying for commitment, one of them have laid in about half a day now. And pressing the commit-button (did it some hours and 1 restart ago) does not help. My system has been restarted two times since the file was completed, and usually my mldonkey have no file for commitment after a restart.
Heh. Found the reason. mldonkey did not have write-permission to the "new" destdir. Anyway I don't think the./incoming should be by this patch removed from the shared-list, but be somehow set to the default download-dir (as it more or less automaticly has the right permission) and then somehow have a message (maybe in the ebuild?) informing the user of the new feature.
I don't know, but this kind of thing is the reason 2.5.2x should be masked. You should expect exactly this kind of changes to occur in a development branch. If you're going to unmask and use it, you better pay attention to the mailing list, and Savannah patch tracker, because things will change on you as a result of minor version number bumps.
I see what you mean there and will not unmask 2.5.27, and I agree 2.5.22* should have been masked, but it was not and then it was marked stable on another architecture. It will be masked as soon as possible. We are working on it. As soon as bug #60390 is resolved, >=2.5.17 will be masked.
Thats fine. No complaints here. I'm satisfied with the solution, and I think you're doing a great job.
