FrostWire is a fork of the very popular LimeWire Gnutella client. The purpose of FrostWire is to keep and maintain the freedoms that LimeWire LLC may be forced to withdraw. It should be easy to make an ebuild from the LimeWire one altough I'm not an ebuild expert ;-).
I took a look at it, and it is a java application, just like limewire. It packages up a lot of jars, not sure which ones we can separate into different ebuilds. From what I understand about the new Java implemenation if the package includes any common .jar's then you want to use the common installation of them, not the one packages with the main package, this way you get the security updates with that package. Here is a list of all the jars it uses. FrostWire.jar commons-net.jar jl011.jar tritonus.jar MessagesBundles.jar daap.jar jmdns.jar vorbis.jar ProgressTabs.jar i18n.jar log4j.jar xerces.jar bsh-2.0b4.jar icu4j.jar logicrypto.jar xml-apis.jar clink.jar id3v2.jar looks.jar commons-httpclient.jar jcraft.jar mp3sp14.jar commons-logging.jar jdic.jar themes.jar the main one is FrostWire.jar, and you can cd to this directory straight out of the tarball and run java -jar FrostWire.jar and it seems to work, though I couldn't get it to download anything, I was getting java thread errors on my console.
Second the motion to add frostwire to portage
Created attachment 94498 [details] (Somewhat crude) ebuild for emerging frostwire 4.10.9 This is my first ebuild, so I hope someone with more experiance can fix it up a bit. It does not take into account Ryan's suggestion of splitting up the ebuild, which may be a good idea.
While that works, it isn't done the correct way. Take a look at this for the new way to do java implementations. http://www.gentoo.org/proj/en/java/java-devel.xml I think an even better way to do this, until someone with more ebuild experience can take a look at it, is to put it in the /opt/ folder, and then create a small shell script in /usr/bin/ that executes the .jar. I haven't ready through the document completely but I think the new location for java packages is in /usr/share
Hmm, okay, you don't need quotes around varibles: SRC_URI="http://mirror1.peercommons.net/frostwire/"${PV}"/FrostWire-"${PV}"-2.tar.gz" should be SRC_URI="http://mirror1.peercommons.net/frostwire/${PV}/FrostWire-${PV}-2.tar.gz" You probably want something like: MY_P="FrostWire" Which will allow you to keep consistent throught the build For "cp -R" you want to use "doins -R" I'm not sure why there is an empty pkg_postinst. @ Comment #4 There's a command: make_wrapper name_of_wrapper command run_in_folder just for that. I'm not a Gentoo developer nor am I familiar with the way the java team wants people to do things, but I'll see if I can write a ebuild when I get time.
> For "cp -R" you want to use "doins -R" results in an install: invalid option -- R > I'm not sure why there is an empty pkg_postinst. No particular reason, it can be removed
Created attachment 94559 [details] modified to reflect changes suggested by David Li Still not done 'correctly', but changed to reflect suggestions by David Li. There is still the complaint about modifiers on {$D}, which likely has to do with the chmod +x line. The .zip archive on the same site (www.frostwire.com) is not already set up in a directory structure and may be a better choice if that all has to be changed to better reflect the way java is setup on gentoo. There is also the source in subversion.
The build works but it also creates a directory "/image" on my root system. I don't thinks that's normal.
(In reply to comment #8) > The build works but it also creates a directory "/image" on my root system. I > don't thinks that's normal. > I looked in the ebuild and it appears that is cause by line 21 being doins -r $S/"$MY_P"-"$PV"/usr "$D"/ it should be just doins -r $S/$MY_P-$PV/usr Justin
*** Bug 157646 has been marked as a duplicate of this bug. ***
Created attachment 103719 [details] Frostwire 4.13.1 Ebuild I have created an ebuild based on limewire 4.9.x which is already in portage. This ebuild works, iv tested as well as some other people. It is the newest version of Froswire and seems to work great. Many people have requested this for gentoo, so I think its great if we try to get this in portage.
Created attachment 103720 [details] Icon that goes along with the ebuild
The latest version is 4.13.1.4, which still works with this ebuild.
(In reply to comment #11) > Created an attachment (id=103719) [edit] > Frostwire 4.13.1 Ebuild > Comments on the ebuild to improve your ebuild writing skills: SRC_URI="http://www.peercommons.com/frostwire/${PV}/frostwire-${PV}.noarch.tar.gz" should use ${PN} to replace frostwire and ${P} to replace ${PN}-${PV} DEPEND="app-arch/unzip Where is the unzip needed as the file is tar.gz? src_compile() { ( echo \#!/bin/sh echo cd ${PREFIX} echo export J2SE_PREEMPTCLOSE=1 echo java -cp .:jl011.jar:MessagesBundles.jar:themes.jar:FrostWire.jar com.limegroup.gnutella.gui.Main ) >frostwire.gentoo You should inherit java-pkg-2 eclass and use java-pkg_dojar function to install jar files and then you can make the launcher automatically using java-pkg_dolauncher. DEPEND="app-arch/unzip gtk? ( >=x11-libs/gtk+-2.4 )" RDEPEND="virtual/jre virtual/jdk" Why do we need gtk to build but not to run? Why do we need a java compiler to run frostwire? S="${WORKDIR}/frostwire-4.13.1.noarch" Should use ${P} echo PATH=${PREFIX} > frostwire.envd These kind of tricks with path for one app are not needed when using dolauncher. insinto /usr/share/icons/hicolor/32x32/apps newins "${FILESDIR}"/main-icon.png frostwire.png use newicon from eutils.eclass pkg_postinst() { use gtk || ewarn "You will probably not be able to use the gtk frontend." einfo " Finished installing Frostwire into ${PREFIX}" } If the user disables the gtk use flag it should be obvious that he is not able to. pena frostwire # ebuild frostwire-4.13.1.4.ebuild compile * frostwire-4.13.1.4.noarch.tar.gz MD5 ;-) ... [ ok ] * frostwire-4.13.1.4.noarch.tar.gz RMD160 ;-) ... [ ok ] * frostwire-4.13.1.4.noarch.tar.gz SHA1 ;-) ... [ ok ] * frostwire-4.13.1.4.noarch.tar.gz SHA256 ;-) ... [ ok ] * frostwire-4.13.1.4.noarch.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking frostwire-4.13.1.4.noarch.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking frostwire-4.13.1.4.noarch.tar.gz to /var/tmp/portage/net-p2p/frostwire-4.13.1.4/work >>> Source unpacked. >>> Compiling source in /var/tmp/portage/net-p2p/frostwire-4.13.1.4/work/frostwire-4.13.1.noarch ... >>> Source compiled. We will not be adding new binary packages. For this to be committed to the main tree it must be compiled from source. betelgeuse@pena /var/tmp/portage/net-p2p/frostwire-4.13.1.4 $ find -name "*.jar" ./work/frostwire-4.13.1.noarch/ProgressTabs.jar ./work/frostwire-4.13.1.noarch/jcraft.jar ./work/frostwire-4.13.1.noarch/vorbis.jar ./work/frostwire-4.13.1.noarch/tritonus.jar ./work/frostwire-4.13.1.noarch/commons-pool.jar ./work/frostwire-4.13.1.noarch/MessagesBundles.jar ./work/frostwire-4.13.1.noarch/FrostWire.jar ./work/frostwire-4.13.1.noarch/i18n.jar ./work/frostwire-4.13.1.noarch/themes.jar ./work/frostwire-4.13.1.noarch/commons-net.jar ./work/frostwire-4.13.1.noarch/looks.jar ./work/frostwire-4.13.1.noarch/jl011.jar ./work/frostwire-4.13.1.noarch/id3v2.jar ./work/frostwire-4.13.1.noarch/mp3sp14.jar ./work/frostwire-4.13.1.noarch/commons-httpclient.jar ./work/frostwire-4.13.1.noarch/commons-logging.jar ./work/frostwire-4.13.1.noarch/log4j.jar ./work/frostwire-4.13.1.noarch/jmdns.jar ./work/frostwire-4.13.1.noarch/xml-apis.jar ./work/frostwire-4.13.1.noarch/clink.jar ./work/frostwire-4.13.1.noarch/icu4j.jar ./work/frostwire-4.13.1.noarch/daap.jar ./work/frostwire-4.13.1.noarch/jdic_stub.jar ./work/frostwire-4.13.1.noarch/irc.jar ./work/frostwire-4.13.1.noarch/jdic.jar Uses packed jars. Like KDE applications don't all bundle kdelibs with them, we don't use packed jars. All *.jar files should be rm -v :ed in src_unpack and the eclass functions should be used to introduce system installed copies to the build system.
Created attachment 107142 [details] Cleaned-up frostwire-4.13.1.4.ebuild It works well for me, although I always get three bug pop-ups when starting it. (They're errors about failing to start some HTTP client or something. Don't know much Java, so I'm not 100% sure.)
(In reply to comment #14) > We will not be adding new binary packages. For this to be committed to the main > tree it must be compiled from source. Unfortunately, the only source code for FrostWire I could find was the trunk source on their subversion repository. It seems all their version releases are all pre-packaged.
(In reply to comment #16) > (In reply to comment #14) > > We will not be adding new binary packages. For this to be committed to the main > > tree it must be compiled from source. > > Unfortunately, the only source code for FrostWire I could find was the trunk > source on their subversion repository. It seems all their version releases are > all pre-packaged. > Well, what you'll need to do is to get the tagged subversion source for each released version. Every release they do is tagged in subversion, and it's a bit nicer and cleaner to just checkout a tag then have them post a tarball for each release. (As an FYI, you can browse all the tags here: http://frostwire.svn.sourceforge.net/viewvc/frostwire/tags/ ) So, how difficult would it be to write the ebuild so it downloads the code from subversion?
> So, how difficult would it be to write the ebuild so it downloads the code from > subversion? > While it's not difficult, it is pretty typically frowned uponed to have ebuilds that depend on a svn checkout (or insert your vcs of choice here). Instead, if they are doing real releases, we could build a tarball of a particular tag, put it up on our mirrors, and go from there. Of course, it's preferred that upstream does releases based on their tags, instead of relying on us to make our own.
> While it's not difficult, it is pretty typically frowned uponed to have ebuilds > that depend on a svn checkout (or insert your vcs of choice here). Instead, if > they are doing real releases, we could build a tarball of a particular tag, put > it up on our mirrors, and go from there. > > Of course, it's preferred that upstream does releases based on their tags, > instead of relying on us to make our own. > I wrote to them about it and they seem to be concerned about bandwidth. You can read or comment on the forum thread here: http://www.frostwire.com/forum/viewtopic.php?p=6392#6392
from my testing today direct/full length url fetch, is no longer valid as, this results in ending up at frostwire front page. thus a direct/full length fetch results in a html file or a ${PN}-${PV}.noarch.tar.gz that is 8KB in size
Upstreams comments about bandwidth restrictions is some what understandable. BUT once they provide sources, and an ebuild makes it into tree. We MIRROR their sources so there is hardly any load placed on them. So actually by doing things as they are now, they are potentially wasting more bandwidth. While also making it difficult for it to be packaged from source. I have made some initial efforts to build Limewire from source. Although not sure about working with upstream there. I have no problems looking to package Frostwire instead. Providing we find a more cooperative upstream. If not then I will lean toward Limewire. Looking for the path of least resistance. Also wrt to bundled deps, I bet limewire and frostwires deps are similar. Likely can do similar things in ebuild. Limewire from source is in java-experimental overlay. Not visible via layman. Must do a direct svn co, and expect bleeding to occur. While not all deps are unbundled, limewire does compile and run. But not usable since it throws constance exceptions when run.
Created attachment 138773 [details] Renamed and location change to have latest version
Been in contact with upstream. Will see if I can convince them to make a source package/release. That I can then make a from source ebuild for Frostwire and commit to tree :) Pretty much giving up on Limewire at this point. So will be looking to package Frostwire as soon as sources are available.
Still waiting on sources from upstream. In the mean time went ahead and ported my work on limewire from source over to frostwire from source. It's a live svn snapshot, based on their frostwire_4.13.4_dec-19-2007 tag. Initial from source version of frostwire. Live ebuild atm due to no packaged sources being available. Compiles, installs, and runs, but throws exceptions while running. Usable? Likely needs some refinements still. Committed to java-experimental overlay, that I don't believe is available via layman. Might be hidden, but pretty sure you have to do a svn co to get overlay. Will work on it some more as time permits. Hopefully upstream will come up with packaged sources, and I can commit to tree :)
Have you tried writing upstream yet (team@frostwire.com) They mentioned in the forum that they maybe able to provide the source to specific projects if we email them.
(In reply to comment #25) > Have you tried writing upstream yet (team@frostwire.com) Yes per comment 23, but just to clarify further. I have been in touch with their lead dev. Exchanged a few emails, but have no ETA or etc as to when packaged sources will be available. Thus since I had been in contact, I wanted to show effort on my side by creating the ebuild. Hopefully it will be matched on the other end with packaged sources being made available sometime soon.
Ok finally got upstream to package a source release. I updated the live ebuild fixed to a particular tag in java-experimental overlay to use the new sources. I just committed that work to tree. So Frostwire is now in portage. Be forewarned it's buggy as hell. I have unbundled some of the deps that limewire ships with. Lots more to go, many of which aren't in tree, and sources are ? Who knows. Expect problems, and be willing to address yourself. I will do what I can to address bugs, and provide patches upstream etc. But will be relying on the community allot to improve this package on Gentoo. Patches to the ebuild, or Frostwire itself are greatly appreciated. Please no whole ebuilds, just patch submissions against the one in tree. Otherwise enjoy it, if you can use it :) Let the bug filing, fixing, and fun begin!
