Since most hubs (that I know of at least) require that one uses DC++ or a mod of DC++ this could be a good client to have in Gentoo. As stated on the web page (http://linuxdcpp.berlios.de/) "If you didn't get that already, this is a project to port the DC++ direct connect client to Linux. Or, to any POSIX-compliant Unix really, but since the Unix developers have access to is Linux this is the only one supported at the moment." Since no real release has been made yet, this is a CVS ebuild. This client is somewhat stable but is evolving continuisly. P.s. Sorry for my spelling... D.s. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 66091 [details] ebuild My first attempt at an ebuild... hope I got it somewhat right :)
Created attachment 66544 [details] Updated ebuild This ebuild changes some "common" mistakes I thing I found, and it changes the install to use scons install. And it installs the files to /usr/{bin,lib/dcpp,share/doc/dcpp} instead of under /usr/local Two patches are also included (or soon :)) to make this happen (also sent upstream, with a request for a snapshot or a release depending on the authors opinion) /Naga
Created attachment 66545 [details, diff] Patch to enable install to /usr/... (SConstruct)
Created attachment 66546 [details, diff] Patch to enable install to /usr/... (wulformanager.cc)
The SConstruct checks specifically for g++-3.4 and has to be edited for later versions to compile.
(In reply to comment #5) > The SConstruct checks specifically for g++-3.4 and has to be edited for later > versions to compile. No It checks to see if the version of g++ is greater or equal to 3.4. But if the standard g++ isn't >3.4 then it looks for g++-3.4 --- def CheckCXXVersion(context, name, major, minor): context.Message('Checking for %s >= %d.%d...' % (name, major, minor)) ret = commands.getoutput('%s -dumpversion' % name) retval = 0 if ((string.atoi(ret[0]) == major and string.atoi(ret[2]) >= minor) or (string.atoi(ret[0]) > major)): retval = 1 -- cxx = conf.env.Dictionary()['CXX'] if not conf.CheckCXXVersion(cxx, 3, 4): if WhereIs('g++-3.4') != None: print 'Found g++-3.4' cxx = 'g++-3.4' else: print 'Compiler version check failed. g++ 3.4 or later is needed' Exit(1) --- On a side note this ebuild is old. Since my understanding is that it won't be added to the tree until a release has been made I've stopped updating it here until such a release is available. An up to date ebuild can be found here: http://dx.homelinux.org/gentoo/portage-overlay/net-p2p/dcpp/
Interesting package, but it will need some cleanups. 1) Invalid header. Please read the gentoo documentation. We'll add credit to you in the ChangeLog, but we need to keep the headers throughout the ebuilds standard. 2) I don't really like that /lib is hardcoded throughout the package. I'm on amd64, so my libdir is lib64. 3) the DEPEND on sys-libs/glibc should probably be virtual/libc 4) Live CVS ebuilds are generally frowned upon. Any way we could make a cvs snapshot or use a stable version?
"Interesting package, but it will need some cleanups." No problems :) "1) Invalid header. Please read the gentoo documentation. We'll add credit to you in the ChangeLog, but we need to keep the headers throughout the ebuilds standard." The Author has been removed, but if you were referring to the $Header: $ it's because I have it saved in a cvs repo. "2) I don't really like that /lib is hardcoded throughout the package. I'm on amd64, so my libdir is lib64." Well it isn't hardcoded, if one supplies PREFIX and LIBDIR to scons those dirs will be used instead. Vars are described in the top level SConstruct file. The ebuild has been changed to use get_libdir from multi_lib.eclass Or should these files go into another dir (they are some png's and some glade files)? "3) the DEPEND on sys-libs/glibc should probably be virtual/libc" Fixed "4) Live CVS ebuilds are generally frowned upon. Any way we could make a cvs snapshot or use a stable version?" Snapshot should be easy (and done, but the src_uri could probably use a gentoo address if/when the ebuild gets added to the tree), a stable release will be some time but a "beta" might be released within a not too distant future (we hope :) ) Should I attach the new ebuild here or should i leave it in my overlay? (http://dx.homelinux.org/gentoo/portage-overlay/local-overlay/net-p2p/ldcpp/)
Looking much better :). I'm about to go on vacation so won't get around to this for a couple weeks. Could you please go ahead and post the ebuild back in here so we have a permanent record of it (mostly for consistency)? After a bit of testing when I get back, I'll probably add it to portage (provided there is nothing that goes horribly wrong).
Created attachment 87115 [details] Fixed ebuild ebuild with the issues in comment #8 fixed
Created attachment 87116 [details] desktop entry The desktop entry
OK, a couple more issues: 1) it shouldn't install things into /ldcpp >>> /ldcpp/ >>> /ldcpp/glade/ >>> /ldcpp/glade/hub.glade >>> /ldcpp/glade/settingsdialog.glade >>> /ldcpp/glade/sharebrowser.glade >>> /ldcpp/glade/hash.glade >>> /ldcpp/glade/mainwindow.glade >>> /ldcpp/glade/search.glade >>> /ldcpp/glade/finishedtransfers.glade >>> /ldcpp/glade/privatemessage.glade >>> /ldcpp/glade/.sconsign >>> /ldcpp/glade/publichubs.glade >>> /ldcpp/glade/downloadqueue.glade >>> /ldcpp/glade/favoritehubs.glade >>> /ldcpp/pixmaps/ >>> /ldcpp/pixmaps/publichubs.png >>> /ldcpp/pixmaps/dc++.png >>> /ldcpp/pixmaps/normal-fw-op.png >>> /ldcpp/pixmaps/normal-fw.png >>> /ldcpp/pixmaps/normal.png >>> /ldcpp/pixmaps/dc++-fw.png >>> /ldcpp/pixmaps/upload.png >>> /ldcpp/pixmaps/settings.png >>> /ldcpp/pixmaps/normal-op.png >>> /ldcpp/pixmaps/dc++-op.png >>> /ldcpp/pixmaps/FinishedDL.png >>> /ldcpp/pixmaps/search.png >>> /ldcpp/pixmaps/.sconsign >>> /ldcpp/pixmaps/queue.png >>> /ldcpp/pixmaps/favhubs.png >>> /ldcpp/pixmaps/FinishedUL.png >>> /ldcpp/pixmaps/download.png >>> /ldcpp/pixmaps/dc++-fw-op.png 2) I can't find the referenced dc++.svg doicon "${FILESDIR}/dc++.svg"
:) We've done some major updates to ldcpp in the last week. I'll redo the ebuild and resubmit soon.
Created attachment 89448 [details] ebuild for CVS snapshot from 20060618
(I assume it's correct to provide feedback to these ebuilds in this bug rather than start another because it has yet to make it into portage proper. Please let me know if I'm making an ass of myself.) The 20060519 ebuild works fine, but with the 20060606 one, I get: vingilot ldcpp # emerge ldcpp Calculating dependencies... done! >>> Emerging (1 of 1) net-p2p/ldcpp-0.0.1.20060606 to / >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking linuxdcpp-0.0.1.20060606.tar.gz ;-) >>> Unpacking source... >>> Unpacking linuxdcpp-0.0.1.20060606.tar.gz to /var/tmp/portage/ldcpp-0.0.1.20060606/work >>> Source unpacked. >>> Compiling source in /var/tmp/portage/ldcpp-0.0.1.20060606/work ... grep: SConstruct: No such file or directory scons: *** No SConstruct file found. File "/usr/lib/scons/SCons/Script/__init__.py", line 870, in _main !!! ERROR: net-p2p/ldcpp-0.0.1.20060606 failed. Call stack: ebuild.sh, line 1545: Called dyn_compile ebuild.sh, line 940: Called src_compile ldcpp-0.0.1.20060606.ebuild, line 78: Called die !!! scons failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/local/portage' Aaaaaaaaaaaaaand: vingilot ldcpp # emerge --info Portage 2.1.1_pre2-r8 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-gentoo-r9 i686) ================================================================= System Settings ================================================================= System uname: 2.6.16-gentoo-r9 i686 Intel(R) Pentium(R) M processor 1.70GHz Gentoo Base System version 1.6.15 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium-m -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf" CXXFLAGS="-O3 -march=pentium-m -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://mirror.espri.arizona.edu/gentoo/ http://gentoo.mirrors.easynews.com/linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 X aac alsa apache2 apm asf avi bash-completion berkdb bitmap-fonts cddb cdparanoia cli crypt cscope cups divx4linux dlloader dri dvd eds emboss encode flac foomaticdb fortran gdbm gif gstreamer gtk gtk2 i8x0 imlib ipv6 isdnlog jpeg libg++ libwww mad matroska mikmod mmx motif mp3 mpeg ncurses nls nptl nptlonly nsplugin ogg oggvorbis opengl pam pcre pdflib png pppd python qt3 qt4 quicktime readline real reflection rtc samba sdl session spell spl sse sse2 ssl svg tcpd tiff truetype truetype-fonts type1-fonts udev vorbis win32codecs xml xorg xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_synaptics kernel_linux userland_GNU video_cards_radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Either use the ebuild in this bug or use the cvs one, since I'm not maintaining any others.
Created attachment 91718 [details] New ebuild (CVS snapshot 20060714) Much has happened to the source, so I made a new ebuild. Btw, what is the status of this bug? Is it going in soon or?
(In reply to comment #16) > Either use the ebuild in this bug or use the cvs one, since I'm not maintaining > any others. I have only used ebuilds in this bug; the problem I described was caused by the ebuild you attached in reply #14. Note also that the version info has changed for the ebuild for 20060714: it is no longer prefixed by 0.0.1, which is not obvious until the download fails and one goes groveling through your webserver. What I mean is that the attachment needs to be saved as "ldcpp-20060714.ebuild", which differs from the previous pattern (which would have made it "ldcpp-0.0.1.20060714.ebuild"). The 20060714 ebuild appears to not suffer from the same bug as the ebuild from reply #14.
Created attachment 92534 [details] net-p2p/linuxdcpp-9999.ebuild Clean ebuild instead without unnecessary hacks. I'm not bothering to create CVS snapshot ebuild but I know that is preferred in portage and trust if someone is putting this to portage he is capable for changing this to one. :)
BTW, thanks to zeroth404 in #g-dev-help, without him I probably wouldn't even made it.
Created attachment 92535 [details] net-p2p/linuxdcpp-9999.ebuild - Respect CXXFLAGS from /etc/make.conf
Some questions: * Why remove Jon Hood? * Just out of curiosity, what hacks? * And the ebuild you wrote is wrong, it doesn't depend on virtual-x11, or? * Will it compile with sandbox on? * As far as I can see the ebuild you wrote doesn't install the files into the correct places (ldcpp -> bin/ pixmaps/ -> share/ldcpp/ and so).
(In reply to comment #22) > Some questions: > * Why remove Jon Hood? Sorry, forgot to CC him. Other devs might be intrested this too, since it's not in portage yet. Maintainer-wanted is correct 'herd'. > * Just out of curiosity, what hacks? > * Will it compile with sandbox on? Same question. Do exactly that, compile with sandbox. > * And the ebuild you wrote is wrong, it doesn't depend on virtual-x11, or? You are right, I will modularize it. Waiting for buildlog as we speak to add correct dependencies. > * As far as I can see the ebuild you wrote doesn't install the files into the > correct places (ldcpp -> bin/ pixmaps/ -> share/ldcpp/ and so). > Yes, it does. /usr/bin/ldcpp /usr/share/doc/linuxdcpp-9999/Changelog.txt.gz /usr/share/doc/linuxdcpp-9999/Credits.txt.gz /usr/share/doc/linuxdcpp-9999/Readme.txt.gz /usr/share/applications/ldcpp-linuxdcpp.desktop /usr/share/pixmaps/linuxdcpp.png /usr/share/linuxdcpp/glade/hub.glade /usr/share/linuxdcpp/glade/settingsdialog.glade /usr/share/linuxdcpp/glade/sharebrowser.glade /usr/share/linuxdcpp/glade/hash.glade /usr/share/linuxdcpp/glade/mainwindow.glade /usr/share/linuxdcpp/glade/search.glade /usr/share/linuxdcpp/glade/finishedtransfers.glade /usr/share/linuxdcpp/glade/privatemessage.glade /usr/share/linuxdcpp/glade/publichubs.glade /usr/share/linuxdcpp/glade/downloadqueue.glade /usr/share/linuxdcpp/glade/favoritehubs.glade /usr/share/linuxdcpp/ldcpp /usr/share/linuxdcpp/pixmaps/linuxdcpp.png /usr/share/linuxdcpp/pixmaps/publichubs.png /usr/share/linuxdcpp/pixmaps/dc++.png /usr/share/linuxdcpp/pixmaps/linuxdcpp-icon.png /usr/share/linuxdcpp/pixmaps/normal-fw-op.png /usr/share/linuxdcpp/pixmaps/hash.png /usr/share/linuxdcpp/pixmaps/normal-fw.png /usr/share/linuxdcpp/pixmaps/normal.png /usr/share/linuxdcpp/pixmaps/dc++-fw.png /usr/share/linuxdcpp/pixmaps/upload.png /usr/share/linuxdcpp/pixmaps/settings.png /usr/share/linuxdcpp/pixmaps/normal-op.png /usr/share/linuxdcpp/pixmaps/dc++-op.png /usr/share/linuxdcpp/pixmaps/FinishedDL.png /usr/share/linuxdcpp/pixmaps/search.png /usr/share/linuxdcpp/pixmaps/quit.png /usr/share/linuxdcpp/pixmaps/connect.png /usr/share/linuxdcpp/pixmaps/queue.png /usr/share/linuxdcpp/pixmaps/favhubs.png /usr/share/linuxdcpp/pixmaps/FinishedUL.png /usr/share/linuxdcpp/pixmaps/download.png /usr/share/linuxdcpp/pixmaps/dc++-fw-op.png thanks, drac
make_desktop_entry creates.. desktop [Desktop Entry] Encoding=UTF-8 Version=0.9.2 Name=linuxdcpp Type=Application Comment=Direct connect client, looks and works like famous DC++ Exec=ldcpp TryExec=ldcpp Path= Icon=linuxdcpp.png Categories=Application;Network;FileTransfer; It's part of eutils.eclass, take a look at it.
Created attachment 92536 [details] net-p2p/linuxdcpp-9999.ebuild Looks like it doesn't link to any of X11 libraries compiletime but to these.. app-arch/bzip2 dev-libs/atk dev-libs/glib dev-libs/libxml2 gnome-base/libglade sys-libs/glibc sys-libs/zlib x11-libs/cairo x11-libs/gtk+ x11-libs/pango So I've added cairo, atk and pango to RDEPEND. Dependencies of these libraries will take care of modular X depends.
Also there is no need to check for GCC version as GCC 3.4 is stable on x86, and default GCC in ~x86 is 4.1.1. Classic "User error." if one is running outdated system. ;-)
/usr/bin/ldcpp /usr/share/linuxdcpp/glade/favoritehubs.glade /usr/share/linuxdcpp/ldcpp /usr/share/linuxdcpp/pixmaps/linuxdcpp.png isn't /usr/bin/ldcpp just a symlink? And has sandbox changed? When I first wrote an ebuild for ldcpp sandbox complained _alot_ on scons. (Btw it compiles on amd64 too)
> isn't /usr/bin/ldcpp just a symlink? > And has sandbox changed? When I first wrote an ebuild for ldcpp sandbox > complained _alot_ on scons. (Btw it compiles on amd64 too) Because I didn't use use PREFIX, FAKE_ROOT, BINDIR, DATADIR or DOCDIR but instead used method described in Readme.txt Quote: "Using binreloc, which is the default, you can just copy the binary and the pixmaps and glade directories to wherever you like. Then you can add the program to your menu or create a symlink in /bin for easy access. This way I we can install everything using portage functions and avoid sandbox errors more convinient way. And it is why we are using symlink instead of copying binary to somewhere else. TODO: Use $(tc-getCXX) to set *-pc-linux-gnu-g++ instead of just using g++ from toolchain-funcs.eclass, will look at this later today.
Created attachment 92571 [details] linuxdcpp-9999.ebuild Changes: - Make scons respect MAKEOPTS from /etc/make.conf. - Accidentally added depends for cairo, pango and atk. Removing them as GTK+ allready depends on them. And these are all X modularized thus filling necessary X depends for this ebuild also. - Add elog warning about UTF-8 issues described in Readme.txt, and point people to same textfile for information. Still reading? Apologies for bugspam. Blame it on scons!#% :)
LinuxDCPP CVS works fine on amd64, what about adding ~amd64 in the ebuild?
hello, I had an error because scons couldn't use my CCFLAGS from /etc/make.conf and the program didn't compile at all but the ebuild tried to get it merged. if any error has occured during the compilation it shouldn't continue the merge but exit with an adequate error message. Also the name of the program binary has changed in linuxdcpp, see the changelog ........ Checking for g++ >= 3.4...ok Enabling distcc... Checking for pkg-config... ok Checking for gtk+-2.0 >= 2.6... ok Checking for gthread-2.0 >= 2.4... ok Checking for libglade-2.0 >= 2.4... ok Checking for C header file time.h... yes Checking for C header file signal.h... yes Checking for C header file unistd.h... yes Checking for main() in C library pthread... yes Checking for main() in C library z... yes Checking for main() in C library bz2... yes scons: done reading SConscript files. scons: Building targets ... distcc g++ -O2 -pipe -fomit-frame-pointer -march=athlon-xp -I. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 "-O2 -pipe -fomit-frame-pointer -march=athlon-xp" -D_DATADIR='"/usr/local/share"' -c -o build/client/AdcCommand.o client/AdcCommand.cpp distcc[27182] (dcc_get_hostlist) Warning: no hostlist is set; can't distribute work distcc[27182] (dcc_build_somewhere) Warning: failed to distribute, running locally instead cc1plus: error: invalid option argument `-O2 -pipe -fomit-frame-pointer -march=athlon-xp' distcc[27182] ERROR: compile client/AdcCommand.cpp on localhost failed scons: *** [build/client/AdcCommand.o] Error 1 scons: building terminated because of errors. /usr/local/portage/net-p2p/linuxdcpp/linuxdcpp-9999.ebuild: line 35: scons failed.: command not found >>> Source compiled. >>> Test phase [not enabled]: net-p2p/linuxdcpp-9999 >>> Install linuxdcpp-9999 into /tmp/portage/linuxdcpp-9999/image/ category net-p2p install: cannot stat `ldcpp': No such file or directory chmod: cannot access `/tmp/portage/linuxdcpp-9999/image//usr/share/linuxdcpp/ldcpp': No such file or directory >>> Completed installing linuxdcpp-9999 into /tmp/portage/linuxdcpp-9999/image/ man: >>> Merging net-p2p/linuxdcpp-9999 to / --- /usr/ --- /usr/bin/ --- /usr/share/ --- /usr/share/doc/ --- /usr/share/doc/linuxdcpp-9999/ >>> /usr/share/doc/linuxdcpp-9999/Changelog.txt.gz >>> /usr/share/doc/linuxdcpp-9999/Credits.txt.gz >>> /usr/share/doc/linuxdcpp-9999/Readme.txt.gz --- /usr/share/applications/ >>> /usr/share/applications/ldcpp-linuxdcpp.desktop --- /usr/share/pixmaps/ >>> /usr/share/pixmaps/linuxdcpp.png -> /usr/share/linuxdcpp/pixmaps/linuxdcpp.png --- /usr/share/linuxdcpp/ --- /usr/share/linuxdcpp/glade/ >>> /usr/share/linuxdcpp/glade/hub.glade >>> /usr/share/linuxdcpp/glade/settingsdialog.glade >>> /usr/share/linuxdcpp/glade/sharebrowser.glade >>> /usr/share/linuxdcpp/glade/hash.glade >>> /usr/share/linuxdcpp/glade/mainwindow.glade >>> /usr/share/linuxdcpp/glade/search.glade >>> /usr/share/linuxdcpp/glade/finishedtransfers.glade >>> /usr/share/linuxdcpp/glade/privatemessage.glade >>> /usr/share/linuxdcpp/glade/publichubs.glade >>> /usr/share/linuxdcpp/glade/downloadqueue.glade >>> /usr/share/linuxdcpp/glade/favoritehubs.glade --- /usr/share/linuxdcpp/pixmaps/ >>> /usr/share/linuxdcpp/pixmaps/linuxdcpp.png >>> /usr/share/linuxdcpp/pixmaps/publichubs.png >>> /usr/share/linuxdcpp/pixmaps/dc++.png >>> /usr/share/linuxdcpp/pixmaps/linuxdcpp-icon.png >>> /usr/share/linuxdcpp/pixmaps/normal-fw-op.png >>> /usr/share/linuxdcpp/pixmaps/hash.png >>> /usr/share/linuxdcpp/pixmaps/normal-fw.png >>> /usr/share/linuxdcpp/pixmaps/normal.png >>> /usr/share/linuxdcpp/pixmaps/dc++-fw.png >>> /usr/share/linuxdcpp/pixmaps/upload.png >>> /usr/share/linuxdcpp/pixmaps/settings.png >>> /usr/share/linuxdcpp/pixmaps/normal-op.png >>> /usr/share/linuxdcpp/pixmaps/dc++-op.png >>> /usr/share/linuxdcpp/pixmaps/FinishedDL.png ..................
Well as stated before in this bug, the ebuilds here are out of date and probably will be until some developer shows some intrest in the package. For more up to date ebuilds please see: http://dx.homelinux.org/gentoo/portage-overlay/local-overlay/net-p2p/linuxdcpp/ / Naga
compiles and works fine here on x86, have tested on multiple ebuilds provided in the previous post and the latest also works fine. would be great if it could be added to portage. A much cleaner interface than valknut, and refreshing for people who transit :-)
Created attachment 103813 [details] linuxdcpp-9999.ebuild Working version.
In CVS, i'll add the 9999 ebuild later.
Created attachment 107264 [details] A better CVS ebuild. Less ebuild hacks then the -9999 one (no sed calls needed)
All done, CVS ebuild in CVS.
an additional note, it works on sparc as well. And thanks again.
