Bug 468362 - Package update request to Vuze 4.2
Package update request to Vuze 4.2
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: azureus (Show other bugs)
rawhide
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Lillian Angel
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-24 08:02 EDT by Viktor Erdelyi
Modified: 2009-10-02 01:19 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-30 19:36:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Build environment (80.05 KB, application/octet-stream)
2009-03-29 07:26 EDT, Viktor Erdelyi
no flags Details

  None (edit)
Description Viktor Erdelyi 2008-10-24 08:02:30 EDT
Is it possible to update the package to the latest Vuze so that we don't have to install it separately?
Comment 1 Lillian Angel 2008-10-24 10:46:32 EDT
sure, i am working on this.
Comment 2 Naveed Hasan 2008-12-13 14:35:22 EST
Vuze 4.0.0.4 has been released.
Comment 3 Naveed Hasan 2009-02-05 03:05:38 EST
Vuze 4.1 is out as of 2009-01-27   :)
http://sourceforge.net/forum/forum.php?forum_id=911840
Comment 4 Dario Castellarin 2009-03-18 07:20:21 EDT
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...
Comment 5 Naveed Hasan 2009-03-18 13:55:04 EDT
I can help out with packaging, if time bandwidth is holding this back.
Comment 6 Viktor Erdelyi 2009-03-21 08:19:01 EDT
Package should also be renamed to Vuze.
Comment 7 Viktor Erdelyi 2009-03-24 09:53:33 EDT
4.2 is released!
Comment 8 Naveed Hasan 2009-03-25 02:51:24 EDT
4.0.0.4 in rawhide - http://koji.fedoraproject.org/koji/buildinfo?buildID=94732
Comment 9 Conrad Meyer 2009-03-25 02:55:39 EDT
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.)
Comment 10 Viktor Erdelyi 2009-03-25 12:08:39 EDT
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.
Comment 11 Conrad Meyer 2009-03-25 14:40:16 EDT
To checkout the packaging stuff from CVS:

  CVSROOT=:pserver:anonymous@cvs.fedoraproject.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.
Comment 12 Viktor Erdelyi 2009-03-25 16:32:17 EDT
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.)
Comment 13 Conrad Meyer 2009-03-25 16:58:31 EDT
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?
Comment 14 Viktor Erdelyi 2009-03-25 17:24:03 EDT
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.
Comment 15 Conrad Meyer 2009-03-25 17:44:40 EDT
Probably would be easier to fix the build.xml, as that worked for 4.0.0.4.
Comment 16 Viktor Erdelyi 2009-03-25 17:52:23 EDT
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?
Comment 17 Conrad Meyer 2009-03-25 18:18:26 EDT
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.
Comment 18 Viktor Erdelyi 2009-03-29 07:26:59 EDT
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.
Comment 19 Conrad Meyer 2009-03-29 17:57:12 EDT
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?
Comment 20 Viktor Erdelyi 2009-03-29 19:37:12 EDT
:)

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.
Comment 21 Conrad Meyer 2009-03-29 19:49:54 EDT
(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.
Comment 22 Conrad Meyer 2009-04-30 19:36:42 EDT
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.
Comment 23 Viktor Erdelyi 2009-05-02 05:34:31 EDT
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.
Comment 24 Dario Castellarin 2009-05-02 08:12:09 EDT
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?
Comment 25 Viktor Erdelyi 2009-05-02 12:36:26 EDT
> 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.
Comment 26 Wyatt Alverson 2009-08-11 00:51:22 EDT
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!

Note You need to log in before you can comment on or make changes to this bug.