Spec URL: http://peter.fedorapeople.org/mldonkey.spec SRPM URL: http://peter.fedorapeople.org/mldonkey-2.9.5-1.fc9.src.rpm Description: MLDonkey is a door to the 'donkey' network, a decentralized network used to exchange big files on the Internet. It is written in a wonderful language, called Objective-Caml, and present most features of the basic Windows donkey client, plus some more: - It should work on most UNIX-compatible platforms. - You can remotely command your client, either by telnet (port 4000), by a WEB browser (http://localhost:4080), or with a classical client interface (see http://www.nongnu.org/mldonkey) - You can connect to several servers, and each search will query all the connected servers. - You can select mp3s by bitrates in queries (useful ?). - You can select the name of a downloaded file before moving it to your incoming directory. - You can have several queries in the graphical user interface at the same time. - You can remember your old queries results in the command-line interface. - You can search in the history of all files you have seen on the network. It can also access other peer-to-peer networks: - BitTorrent - Fasttrack - FileTP (wget-clone) - DC++ ======================================= Another one attempt to package this app. Previous ones: http://bugzilla.livna.org/show_bug.cgi?id=1487 https://bugzilla.redhat.com/show_bug.cgi?id=433143 Although this package has quite long history of suggestions and fixed issues there are many things to do left.
I guess I'll continue my review from before then. :)
Partial review: http://bugzilla.livna.org/show_bug.cgi?id=1487#c43 is still not addressed fully: Since it doesn't run as root, it's better to move the log to /var/log/mldonkey/mldonkey.log and set ownership of that directory accordingly. --- http://bugzilla.livna.org/show_bug.cgi?id=1487#c39 is still not addressed fully: mldonkey_df_monitor.sh: email=`grep "^ mail =" /var/lib/mldonkey/downloads.ini | sed 's/ mail = //g'` This is far from foolproof. It'll fail there are whitespace changes in that line. --- I see that the install section has improved a bit (uses make install now), but it's still far from ideal. Though I guess there's nothing wrong with it packaging-wise. BuildRequires: dos2unix Redundant BR, trivial to avoid using perl or tr. Not a blocker though. It doesn't build on F-8, though: error: Failed build dependencies: ocaml-lablgtk-devel >= 2.10.0 is needed by mldonkey-2.9.5-1.fc8 If I relax that BR to >= 2.6.0, it fails at compilation: ocamlopt.opt -inline 10 -I src/utils/cdk -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/gui -I src/gtk2/gui/x11 -I src/gtk2/gui/win32 -I icons/rsvg -I +lablgtk2 -I src/networks/direct_connect -I src/networks/fasttrack -I src/networks/fileTP -I src/networks/bittorrent -I src/networks/donkey -c src/utils/net/ip_set.ml /usr/bin/ocamlc.opt -I src/utils/cdk -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/gui -I src/gtk2/gui/x11 -I src/gtk2/gui/win32 -I icons/rsvg -I +lablgtk2 -I src/networks/direct_connect -I src/networks/fasttrack -I src/networks/fileTP -I src/networks/bittorrent -I src/networks/donkey -c src/utils/net/ip_set.ml /usr/bin/ocamlc.opt -I src/utils/cdk -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/gui -I src/gtk2/gui/x11 -I src/gtk2/gui/win32 -I icons/rsvg -I +lablgtk2 -I src/networks/direct_connect -I src/networks/fasttrack -I src/networks/fileTP -I src/networks/bittorrent -I src/networks/donkey -c src/utils/net/http_server.mli ocamlopt.opt -inline 10 -I src/utils/cdk -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/gui -I src/gtk2/gui/x11 -I src/gtk2/gui/win32 -I icons/rsvg -I +lablgtk2 -I src/networks/direct_connect -I src/networks/fasttrack -I src/networks/fileTP -I src/networks/bittorrent -I src/networks/donkey -c src/utils/net/http_server.ml ocamlopt.opt -inline 10 -I src/utils/cdk -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/gui -I src/gtk2/gui/x11 -I src/gtk2/gui/win32 -I icons/rsvg -I +lablgtk2 -I src/networks/direct_connect -I src/networks/fasttrack -I src/networks/fileTP -I src/networks/bittorrent -I src/networks/donkey -c src/daemon/common/commonOptions.ml Fatal error: out of memory. make: *** [src/daemon/common/commonOptions.cmx] Error 2 error: Bad exit status from /home/rathann/build/tmp/rpm-tmp.20151 (%build) Note that I have 2GB RAM, which I think should be enough. Or is that a problem with lablgtk? Builds fine in mock/devel/i386.
Still here. I'll try to patch build system to be more robust. After that I'll try to apply another suggestions.
Current srpm builds on F9, but the init script searches for the server in the wrong location (/usr/libexec/mldonkey/mlnet instead of /usr/bin/mlnet). Apart from this small glitch, the server seems to work fine.
Update: * Ver. 2.9.6 (latest) * Some cleanups * Fixed issue with sending messages (since now user should change email in mldonkey_df_monitor from "root@localhost" to actual one) * Log-file moved to %{_localstatedir}/log/mldonkey/mldonkey.log http://peter.fedorapeople.org/mldonkey.spec http://peter.fedorapeople.org/mldonkey-2.9.6-1.fc9.src.rpm
Shouldn't that be 2.9.6-2 to distinguish the changes from 2.6.9-1?
(In reply to comment #6) > Shouldn't that be 2.9.6-2 to distinguish the changes from 2.6.9-1? http://mldonkey.sourceforge.net/News Release 2.9.5 had SRPM mldonkey-2.9.5-1.fc9.src.rpm Release 2.9.6 has SRPM mldonkey-2.9.6-1.fc9.src.rpm
2(In reply to comment #7) > (In reply to comment #6) > > Shouldn't that be 2.9.6-2 to distinguish the changes from 2.6.9-1? > > http://mldonkey.sourceforge.net/News > > Release 2.9.5 had SRPM mldonkey-2.9.5-1.fc9.src.rpm > Release 2.9.6 has SRPM mldonkey-2.9.6-1.fc9.src.rpm then why kernel do not clean suffix? http://koji.fedoraproject.org/koji/packageinfo?packageID=8
(In reply to comment #8) > then why kernel do not clean suffix? > > http://koji.fedoraproject.org/koji/packageinfo?packageID=8 They do. Look on the second page of results and you'll see kernel-2.6.27-1.fc10, for example. The changes and builds for that package are much more frequent, sometimes multiple times a day.
That is't true for kernel, i check about 5 pages and can't find any drops for suffix. As you can see before kernel-2.6.27-1.fc10 (-1) here (-0) suffix, look: kernel-2.6.27-0.408.rc9.git1.fc10
http://fedoraproject.org/wiki/Packaging/NamingGuidelines has all of the details for package naming, specifically http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Package_Release with respect to the release number.
Please move your discussion of the Release tag to fedora-packaging mailing list. Peter's usage is correct.
Created attachment 325313 [details] licensecheck.pl report There are some licencing issues with the sources detected by licensecheck.pl script (from Debian). Please notify upstream about them. I've looked at the problematic files (with UNKNOWN licences) and found two notable issues: /src/utils/lib/md5.{c,h} are under Zlib licence, so you need to add "Zlib" to the License: tag. ./src/utils/lib/md4.h is under a licence I wasn't able to identify which doesn't explicitly give permission to distribute modified versions which seems to make it non-free. I'm blocking FE-Legal pending legal review.
Some further comments. $ rpmlint /var/lib/mock//fedora-rawhide-i386/result mldonkey-server.i386: E: executable-marked-as-config-file /etc/sysconfig/mldonkey Please fix: install -D -p -m 755 packages/rpm/mldonkey.sysconfig $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig/mldonkey Change 755 to 644. mldonkey-server.i386: E: script-without-shebang /etc/sysconfig/mldonkey mldonkey-server.i386: W: non-standard-uid /var/lib/mldonkey mldonkey mldonkey-server.i386: W: non-standard-gid /var/lib/mldonkey mldonkey mldonkey-server.i386: E: non-standard-dir-perm /var/lib/mldonkey 0750 mldonkey-server.i386: W: non-standard-uid /var/lib/mldonkey/incoming mldonkey mldonkey-server.i386: W: non-standard-gid /var/lib/mldonkey/incoming mldonkey mldonkey-server.i386: E: non-standard-dir-perm /var/lib/mldonkey/incoming 0770 mldonkey-server.i386: W: non-standard-uid /var/cache/mldonkey mldonkey mldonkey-server.i386: W: non-standard-gid /var/cache/mldonkey mldonkey mldonkey-server.i386: E: non-standard-dir-perm /var/cache/mldonkey 0750 mldonkey-server.i386: E: incoherent-logrotate-file /etc/logrotate.d/mldonkey mldonkey-server.i386: W: non-standard-uid /var/log/mldonkey mldonkey mldonkey-server.i386: W: non-standard-gid /var/log/mldonkey mldonkey mldonkey-server.i386: E: non-standard-dir-perm /var/log/mldonkey 0750 mldonkey-server.i386: W: incoherent-init-script-name mldonkey mldonkey.src: W: mixed-use-of-spaces-and-tabs (spaces: line 41, tab: line 1) 7 packages and 0 specfiles checked; 7 errors, 10 warnings. The rest can be ignored. mldonkey.spec: BuildRequires: m4 BuildRequires: autoconf Why does it need these two? Shouldn't the -gui subpackage require the main package? Or can it function independently? sed -i 's|\r||g' distrib/ed2k_submit/README.MLdonkeySubmit sed -i 's|\r||g' docs/slavanap.txt iconv -f iso8859-1 -t UTF-8 docs/gnutella.txt > docs/gnutella.utf8 && mv docs/gnutella.{utf8,txt} iconv -f iso8859-1 -t UTF-8 distrib/Authors.txt > distrib/Authors.utf8 && mv distrib/Authors.{utf8,txt} This doesn't preserve original file timestamps. Please use touch -r to do that. [...] # menu and pixmaps install packages/rpm/mldonkey-icon-16.png -D -m 644 $RPM_BUILD_ROOT%{_datadir}/icons/hicolor/16x16/apps/mldonkey.png install packages/rpm/mldonkey-icon-32.png -D -m 644 $RPM_BUILD_ROOT%{_datadir}/icons/hicolor/32x32/apps/mldonkey.png install packages/rpm/mldonkey-icon-48.png -D -m 644 $RPM_BUILD_ROOT%{_datadir}/icons/hicolor/48x48/apps/mldonkey.png I suggest a loop: for sz in 16 32 48 ; do install packages/rpm/mldonkey-icon-${sz}.png -D -m 644 $RPM_BUILD_ROOT%{_datadir}/icons/hicolor/${sz}x${sz}/apps/mldonkey.png done %files ... %{_bindir}/copysources %{_bindir}/get_range %{_bindir}/make_torrent ... %{_bindir}/subconv %{_bindir}/svg_converter These filenames seem a little too generic. Are they supposed to be run by the user? Could you add a "ml" prefix to them?
(In reply to comment #14) > Some further comments. > Please fix: > install -D -p -m 755 packages/rpm/mldonkey.sysconfig > $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig/mldonkey > Change 755 to 644. Done. > BuildRequires: m4 > BuildRequires: autoconf > > Why does it need these two? Removed. Another one leftover. > Shouldn't the -gui subpackage require the main package? Or can it function > independently? Will investigate later. I, personally, don't use gui. > sed -i 's|\r||g' distrib/ed2k_submit/README.MLdonkeySubmit > sed -i 's|\r||g' docs/slavanap.txt > > iconv -f iso8859-1 -t UTF-8 docs/gnutella.txt > docs/gnutella.utf8 && mv > docs/gnutella.{utf8,txt} > iconv -f iso8859-1 -t UTF-8 distrib/Authors.txt > distrib/Authors.utf8 && mv > distrib/Authors.{utf8,txt} > > This doesn't preserve original file timestamps. Please use touch -r to do that. There are a lot of similar issues in this spec-file. Actually, I don't think that we need to preserve timestamps in that case, because we do change file contents. > # menu and pixmaps > install packages/rpm/mldonkey-icon-16.png -D -m 644 > $RPM_BUILD_ROOT%{_datadir}/icons/hicolor/16x16/apps/mldonkey.png > install packages/rpm/mldonkey-icon-32.png -D -m 644 > $RPM_BUILD_ROOT%{_datadir}/icons/hicolor/32x32/apps/mldonkey.png > install packages/rpm/mldonkey-icon-48.png -D -m 644 > $RPM_BUILD_ROOT%{_datadir}/icons/hicolor/48x48/apps/mldonkey.png > > I suggest a loop: > for sz in 16 32 48 ; do > install packages/rpm/mldonkey-icon-${sz}.png -D -m 644 > $RPM_BUILD_ROOT%{_datadir}/icons/hicolor/${sz}x${sz}/apps/mldonkey.png > done Doesn't save any line (from 3 similar lines to the same 3, but completely different :) > %files > ... > %{_bindir}/copysources > %{_bindir}/get_range > %{_bindir}/make_torrent > ... > %{_bindir}/subconv > %{_bindir}/svg_converter > > These filenames seem a little too generic. Are they supposed to be run by the > user? Could you add a "ml" prefix to them? Yes. Some of them (exept another one leftover - 'copysources' utility) may be used even by user. For example, make_torrent can be used even w/o main mldonkey package. Maybe we should package them in their own sub-packages?
(In reply to comment #15) > (In reply to comment #14) > > Shouldn't the -gui subpackage require the main package? Or can it function > > independently? > > Will investigate later. I, personally, don't use gui. No need to investigate. I use mldonkey-gui separately on my laptop. It doesn't require other mldonkey* packages.
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > Shouldn't the -gui subpackage require the main package? Or can it function > > > independently? > > > > Will investigate later. I, personally, don't use gui. > > No need to investigate. I use mldonkey-gui separately on my laptop. It doesn't > require other mldonkey* packages. Thanks for info!
Ver. 2.9.6-2 http://peter.fedorapeople.org/mldonkey.spec http://peter.fedorapeople.org/mldonkey-2.9.6-2.fc10.src.rpm
For the record, I've built this on a F9 box and it works fine.
Dominik, I think we're waiting for you to bless this new version of the spec.
(In reply to comment #15) > (In reply to comment #14) > > Some further comments. [...] > > sed -i 's|\r||g' distrib/ed2k_submit/README.MLdonkeySubmit > > sed -i 's|\r||g' docs/slavanap.txt > > > > iconv -f iso8859-1 -t UTF-8 docs/gnutella.txt > docs/gnutella.utf8 && mv > > docs/gnutella.{utf8,txt} > > iconv -f iso8859-1 -t UTF-8 distrib/Authors.txt > distrib/Authors.utf8 && mv > > distrib/Authors.{utf8,txt} > > > > This doesn't preserve original file timestamps. Please use touch -r to do that. > > There are a lot of similar issues in this spec-file. Actually, I don't think > that we need to preserve timestamps in that case, because we do change file > contents. I still think we should keep the timestamps, but I won't block on this. > > %files > > ... > > %{_bindir}/copysources > > %{_bindir}/get_range > > %{_bindir}/make_torrent > > ... > > %{_bindir}/subconv > > %{_bindir}/svg_converter > > > > These filenames seem a little too generic. Are they supposed to be run by the > > user? Could you add a "ml" prefix to them? > > Yes. Some of them (exept another one leftover - 'copysources' utility) You said copysources was a leftover, yet I still see it in the current spec. Others that could be problematic in the future are: %{_bindir}/get_range %{_bindir}/make_torrent %{_bindir}/subconv %{_bindir}/svg_converter I assume you will handle any file conflicts with other packages that may occur in the future. > may be > used even by user. For example, make_torrent can be used even w/o main mldonkey > package. Maybe we should package them in their own sub-packages? mldonkey-tools/utils? Why not. If they're useful independent of mldonkey then it's possible. Not really important though. Alright. There are no major issues left, so this package is APPROVED. Thank you for the enormous effort to bring this package in line with Fedora Packaging Guidelines. Great job.
Well, APPROVED, pending the resolution of the issue raised in Comment #13.
(In reply to comment #22) > Well, APPROVED, pending the resolution of the issue raised in Comment #13. Sent message upstream.
(In reply to comment #23) > (In reply to comment #22) > > Well, APPROVED, pending the resolution of the issue raised in Comment #13. > > Sent message upstream. One more small detail I forgot (not a blocker): you are passing --disable-gd to ./configure. Is there any reason why it's disabled? A user on rpmfusion-users list mentioned that they'd like it enabled.
Dependency on gd adds libX11 as a dependency too. I, personally, don't think that these fancy graphs worths it, but if people will insist, then I'll add support for gd.
As an aside, if you want me to co-maintain, then feel free to add my nick (rjones) to the CVS request.
(In reply to comment #25) > Dependency on gd adds libX11 as a dependency too. I, personally, don't think > that these fancy graphs worths it, but if people will insist, then I'll add > support for gd. I agree with you, let's drop the gd dependency.
I guess I shouldn't have set review flag to + before the legal issues are resolved.
(In reply to comment #27) > (In reply to comment #25) > > Dependency on gd adds libX11 as a dependency too. I, personally, don't think > > that these fancy graphs worths it, but if people will insist, then I'll add > > support for gd. > > I agree with you, let's drop the gd dependency. What about making (yet another) subpackage?
First it has to be posible to make the GD support modular (as a shared object). I'm not sure if that is posible.
(In reply to comment #28) > I guess I shouldn't have set review flag to + before the legal issues are > resolved. According to https://fedoraproject.org/wiki/Licensing/FAQ#What_about_the_RSA_license_on_their_MD5_implementation.3F_Isn.27t_that_GPL-incompatible.3F (thanks tibbs!) there's no issue, but upstream should be asked to remove RSA's licence and keep the copyright notice only. Lifting FE-Legal, so please go ahead and import this package.
Thanks! New Package CVS Request ======================= Package Name: mldonkey Short Description: Client for several P2P networks Owners: peter Branches: El-4 EL-5 F-9 F-10
(In reply to comment #32) > Thanks! > > New Package CVS Request > ======================= > Package Name: mldonkey > Short Description: Client for several P2P networks > Owners: peter > Branches: El-4 EL-5 F-9 F-10 Couple of questions: (a) do you want me to co-maintain, and (b) EL-4 is a bit adventurous isn't it?? Do we have all the deps in EL-4 for mldonkey?
Can you guys figure out what branches you need and re-set the fedora-cvs flag to ? when you are ready?
Sorry about that Kevin - I should have set the flag back. Peter?
Sorry for the delay. > (a) do you want me to co-maintain Yes! I'll add rjones as co-maintainer. > Do we have all the deps in EL-4 for mldonkey? According to the cocan's page, we have met almost all requirements except one about version of ocaml itself (3.09 in EPEL). However I plan to build mldonkey for EPEL anyway, at least for EL-5 (Probably, it will take some additional time). OK, here is my another one request :) New Package CVS Request ======================= Package Name: mldonkey Short Description: Client for several P2P networks Owners: peter rjones Branches: El-4 EL-5 F-9 F-10
Oops, typo in branch name. New Package CVS Request ======================= Package Name: mldonkey Short Description: Client for several P2P networks Owners: peter rjones Branches: EL-4 EL-5 F-9 F-10
cvs done.
mldonkey-2.9.6-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
mldonkey-2.9.6-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
FYI, MLDonkey 2.9.7 was released last week - http://mldonkey.sourceforge.net/forums/viewtopic.php?p=29072 http://sourceforge.net/project/showfiles.php?group_id=156414
Package Change Request ====================== Package Name: mldonkey New Branches: epel7 Owners: cicku