Bug 468362

sure, i am working on this.

Vuze 4.0.0.4 has been released.

Vuze 4.1 is out as of 2009-01-27   :)
http://sourceforge.net/forum/forum.php?forum_id=911840

Sorry but.. can we have an azureus update to the latest version please? F10 and F9 users are stuck to version 3.0.4.2, that dates back to December 2007! Since then plenty of improvements and bugfixes (including security ones) have been made, and the GUI now basically screams UPDATE ME! everywhere...

I can help out with packaging, if time bandwidth is holding this back.

Package should also be renamed to Vuze.

4.2 is released!

4.0.0.4 in rawhide - http://koji.fedoraproject.org/koji/buildinfo?buildID=94732

Yeah, with significant hackage needed to make it work at all -- if you're interested in helping with transitioning to 4.2 I welcome checking out the cvs head and submitting patches (against the codebase) and/or against the spec file. (I'm now the maintainer of Vuze/azureus but I have little to no interest in the package.)

Can you (or anyone) tell:
- where and what to download
- how to compile (or try to compile)
- how and where to send the patches?

PS: If someone's interested, the azureus2 core V4.2.0.1 CVS (the "old interface" only) compiles ans runs with Eclipse.

To checkout the packaging stuff from CVS:

  CVSROOT=:pserver:anonymous.org:/cvs/pkgs
  cvs co azureus

To try and compile the new version, you'll need to install rpm-build and rpmdevtools, run `rpmdev-setuptree` in your home directory if you don't already have a $HOME/rpmbuild tree, copy the .spec from the CVS checkout above into ~/rpmbuild/SPECS, copy all the .diffs and .patches from CVS into ~/rpmbuild/SOURCES, download the latest zip/tarball of Vuze, put it in ~/rpmbuild/SOURCES, update the .spec in ~/rpmbuild/SPECS to contain the correct version, source zip/tarball, etc.

Then rpmbuild -ba azureus.spec to see if it compiles *with no changes*. It probably won't.

Thanks, I think I now know what it's about. But where did you get a build.xml?

(Some of the patches get rejected but that's the smaller problem. First we need the xml to even start building.)

I'm not entirely sure the .xml is used anymore, some of those patches and stuff I just didn't clean up when I worked on getting 4.0.0.4 building. Does the %build section of the .spec specifically mention a build.xml?

There is a patch related to build.xml, but it's especially the "ant jar" command in the .spec that wants the build.xml and won't do anything without it. The official source zip doesn't contain a build.xml, and it's not needed IF you use Eclipse. But I think we need one for building the rpm. For now I'm trying the way I found on their wiki (looks old though):

  find -iname \*.java > sources.lst
  if ! ${JAVADIR}javac -verbose -classpath $CLASSPATH @sources.lst ; then
    echo "ERROR: Compile failed!"
    exit 1
  fi

But that complains about lots of Chinese chars everywhere, and I also need to tell it somehow where the SWT libs are.

But first, we need to find a reasonable "build everything" command.

Probably would be easier to fix the build.xml, as that worked for 4.0.0.4.

Fix? But I didn't even find one, neither in the zip, nor in your cvs tree. That's why I'm surprised that it contains a patch for the build.xml. Am I missing something?

Ah, the 4.0.0.4 zip had a build.xml. So 4.2 doesn't anymore? Sounds like they really don't want to be packaged... I guess in that case we should try what you suggested in comment 14.

Created attachment 337162 [details]
Build environment

I think I did it. At least I have an RPM and it starts from the desktop after install.
Please somebody give it some testing.

Known issue: Flash animations doesn't work in the Vuze HD Network. We should tell it where the plugin is.

Hrm, ok. Some pointers:

- for java packaging in Fedora, we already have a build-classpath command that will create a working classpath for whichever jars are needed by an app. So some of the code can go away.

- the build script can probably be simplified a little but if it works that's great

- are we entirely sure the Azureus2.jar that's being built contains no other libraries? It looks ok, just making sure.

And: any chance you're already a Fedora packager? If so I'd gladly take a co-maintainer, you seem to be doing a great job. If not, consider it :).

Also: It looks like there are no added patches (I'm just making sure here), is that correct?

:)

I'm not a Fedora packager (yet), moreover it was the first time I've ever seen rpmbuild. Therefore, my only goal was to make it compile. Now comes the optimization/cleanup part.

- build-classpath: it'll be your job if you want it.
- the build script is a selection from the script provided at their wiki, with the proper adjustments applied.
- I don't know what libraries Azureus2.jar contains, but it's bigger than what their binary build has. Since I put almost everything into the REQUIRED section that was mentioned in the orignal script (even osx jars), it's possible we can strip some things from it.
- patches: no additional patches, I simply took all of your patches and removed those that caused merge conflicts. But some minor adjustments (like removing a .java) have been made in the spec file.

I'd be glad to help with packaging, but I'll definitely need some help (see above).

PS. what the ... can we do about flash? the "real" x64 plugin is in alpha state and is definitely not GPL licensed. And I don't know where to put that plugin either.

(In reply to comment #20)
> I'm not a Fedora packager (yet), moreover it was the first time I've ever seen
> rpmbuild. Therefore, my only goal was to make it compile. Now comes the
> optimization/cleanup part.

Well, you did a pretty good job for not having seen a .spec before. Fedora could always use more packagers.

> - build-classpath: it'll be your job if you want it.

Right, I'll do this, it's easy.

> - the build script is a selection from the script provided at their wiki, with
> the proper adjustments applied.

Maybe it's long enough to separate out as a Source1. We'll see.

> - I don't know what libraries Azureus2.jar contains, but it's bigger than what
> their binary build has. Since I put almost everything into the REQUIRED section
> that was mentioned in the orignal script (even osx jars), it's possible we can
> strip some things from it.

No need to strip OSX parts, so long as it doesn't contain the libraries it uses and instead uses the system ones.

> - patches: no additional patches, I simply took all of your patches and removed
> those that caused merge conflicts. But some minor adjustments (like removing a
> .java) have been made in the spec file.

Right, that was my guess, just making sure (patches I'd have to add in CVS).

> I'd be glad to help with packaging, but I'll definitely need some help (see
> above).

Well, you'd need to be sponsored into Fedora first, and I am no sponsor.

> PS. what the ... can we do about flash? the "real" x64 plugin is in alpha state
> and is definitely not GPL licensed. And I don't know where to put that plugin
> either.  

We can't do much about that. There are free software replacement flash plugins (Gnash, swfdec) but AFAIK they don't work on 100% of flash things.

I'm orphaning this package out of lack of interest and lack of time. If someone wants the latest version of Azureus (now Vuze) in Fedora (or any version for that matter), they should probably go through a new review request. So I'm closing this as WONTFIX.

Just a question: why do we have this thing in a package at all? As long as there is a binary version on their site, everyone can simply install it. Additionally, I'm questioning how long the project will remain open source.

The main problem is that it ships with a 32bit x86 only swt.jar, so trying to run the original package on any arch but i386 will end up in an error message. The Fedora rpm uses the system swt.jar instead.

About how long it will stay open source: no idea. Any hint on why this should change?

> The main problem is that it ships with a 32bit x86 only swt.jar

Well that's a real problem, but I think it's them who should fix it. I don't want all the developers to become more and more lazy and leave all bugs unfixed while thinking that "oh, I don't have to fix it because the community will hack it around". We're doing the work that they should've already done.

> Any hint on why this should change?

The "please donate to keep this project free and open source" message starting to appear everywhere and that one of the two HD networks it supports (namely Studio HD) is already a commercial platform, with only a few free ("promo") videos.

There is an easy fix to get the latest Vuze 4.2.0.4 running on an x86 machine. 
First, install the eclipse-swt (eclipse-swt-3.4.2-13.fc11.x86_64).  

Then, download the latest Vuze_Installer.tar.bz2 file from their website.  Unpack this file and navigate to its contents.  Delete the swt.jar file.  Create a symbolic link to the 64 bit version of swt.jar found in /usr/lib64/eclipse/

Then start Vuze (azureus).  With the exception of a nonworking flash plugin, everything will be updated to the latest version!