Bug 216485

Azureus needs to be rebuilt. Andrew said that he would take care of it.
Re-assigning bug to him.

Yeah, I'm going to rebuild the stuff in Extras but I can't do that until the
update is out as I don't think Extras has an updates-testing equivalent.

Rebuilding azureus currently doesn't work, BTW, since the default install of
java can't find swt-gtk-3.2 when building azureus either, just like running it.

Moving the swt-gtk-3.2.jar file from /usr/share/java/ to /usr/lib[64]/eclipse is
the cause of that problem.  Judging by the locations of jar files for other
packages, the .jar.so and .jar.db files should be in /usr/lib[64], but the plain
swt-gtk-3.2.jar and swt-gtk-3.2.1.jar files should remain in /usr/share/java, or
at least there should be a link to them in /usr/share/java.  (I suppose that the
search path for java could be changed too, but symbolic links seem easier.)

(In reply to comment #3)
> Rebuilding azureus currently doesn't work, BTW, since the default install of
> java can't find swt-gtk-3.2 when building azureus either, just like running it.

The jars are arch-specific and cannot be in /usr/share.  It's a simple matter of
rebuilding and changing azureus.script.  I think I committed this to Extras CVS
but didn't build.  I will do so once the update is released.

> The jars are arch-specific and cannot be in /usr/share.

True, yet for some reason that doesn't seem to stop all the other packages from
putting them there.  But it is more correct, I grant.

> I think I committed this to Extras CVS but didn't build.

Unfortunately, you'll have to change it for bouncycastle 1.34 as well, which was
just updated to 1.34.  Change to /usr/share/java/gcj-endorsed/bcprov-1.34.jar
and all.  (The advantage of /usr/share/java being in the lack of having to
specify the versions to much, even if technically wrong.  Someone should fix it,
I suppose.)

(In reply to comment #5)
> > The jars are arch-specific and cannot be in /usr/share.
> 
> True, yet for some reason that doesn't seem to stop all the other packages from
> putting them there.  But it is more correct, I grant.

I didn't think other packages had arch-specific jars.  What are you thinking of?

> > I think I committed this to Extras CVS but didn't build.
> 
> Unfortunately, you'll have to change it for bouncycastle 1.34 as well, which was
> just updated to 1.34.  Change to /usr/share/java/gcj-endorsed/bcprov-1.34.jar
> and all.  (The advantage of /usr/share/java being in the lack of having to
> specify the versions to much, even if technically wrong.  Someone should fix it,
> I suppose.)

Can you file that last one against azureus, please?  Thanks.

As Andrew mentioned, the swt jar is arch-specific. This is because the java
source in swt is pre-processed to use ints on 32-bit platforms and longs on
64-bit platfroms. Not to mention that the swt jar includes its JNI libs.

That said, I just re-read the FHS and think there may be a small problem with
what we have. 

From
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA:

"/usr/lib : Libraries for programming and packages
Purpose

/usr/lib includes object files, libraries, and internal binaries that are not  
  intended to be executed directly by users or shell scripts. [22]

Applications may use a single subdirectory under /usr/lib. If an application
uses a subdirectory, all architecture-dependent data exclusively used by the
application must be placed within that subdirectory. [23]"

So what we should really do is move the swt symlinks from /usr/lib/eclipse to
/usr/lib because applications shouldn't be digging in /usr/lib/eclipse. Strictly
speaking, we should also remove the JNI symlinks from /usr/lib because those are
private to swt. However if we did this, applications would have to set the
java.library.path vmarg which may not be desirable. Andrew, do you have any
thoughts here?

Adding Tom Tromey to tap into his expertise.

(In reply to comment #7)
> "/usr/lib : Libraries for programming and packages
> Purpose
> 
> /usr/lib includes object files, libraries, and internal binaries that are not  
>   intended to be executed directly by users or shell scripts. [22]
> 
> Applications may use a single subdirectory under /usr/lib. If an application
> uses a subdirectory, all architecture-dependent data exclusively used by the
> application must be placed within that subdirectory. [23]"
> 
> So what we should really do is move the swt symlinks from /usr/lib/eclipse to
> /usr/lib because applications shouldn't be digging in /usr/lib/eclipse.

But nothing should be linking against the JNI libraries.  Those are dlopen'd only.

> Strictly speaking, we should also remove the JNI symlinks from /usr/lib
> because those are private to swt.

Yeah, I guess.

> However if we did this, applications would have to set the
> java.library.path vmarg which may not be desirable. Andrew, do you have any
> thoughts here?

I'm pretty sure proprietary JVMs require the setting of java.library.path even
with the stuff in /usr/lib.  I'm not sure it's undesirable but I really don't
know.  Tom?

I picked up the new eclipse jvms this evening from the standard updates repo. 
This bug is now present in the default repos.

Is there an easy way to get azureus to start again (without reverting to the old
libswt3-gtk2)?

I built an updated azureus.  I tried to synchronize the two updates as best as
possible.  Is the new azureus not available yet?

I asked on fedora-extras-list and the response I got to my question of "When
will the newly-built azureus get pushed out?" was:  "The only delay will be the
delay it takes to mirror the files from an internal server to the public servers."

Got the updates now. However...

azureus-2.5.0.0-9.fc6
eclipse-*-3.2.1-23.fc6
bouncycastle-1.34-1

...just gives this before exiting:

$ azureus
Exception in thread "main" java.lang.NoClassDefFoundError:
org/bouncycastle/jce/spec/ECParameterSpec
        at
com.aelitis.azureus.core.security.impl.CryptoManagerImpl.<init>(CryptoManagerImpl.java:75)
        at
com.aelitis.azureus.core.security.impl.CryptoManagerImpl.getSingleton(CryptoManagerImpl.java:60)
        at
com.aelitis.azureus.core.security.CryptoManagerFactory.getSingleton(CryptoManagerFactory.java:33)
        at
com.aelitis.azureus.core.impl.AzureusCoreImpl.<init>(AzureusCoreImpl.java:155)
        at
com.aelitis.azureus.core.impl.AzureusCoreImpl.create(AzureusCoreImpl.java:92)
        at
com.aelitis.azureus.core.AzureusCoreFactory.create(AzureusCoreFactory.java:46)
        at org.gudy.azureus2.ui.swt.Main.<init>(Main.java:143)
        at org.gudy.azureus2.ui.swt.Main.main(Main.java:162)

(In reply to comment #13)
> Got the updates now. However...
> 
> azureus-2.5.0.0-9.fc6
> eclipse-*-3.2.1-23.fc6
> bouncycastle-1.34-1
> 
> ...just gives this before exiting:
> 
> $ azureus
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/bouncycastle/jce/spec/ECParameterSpec

Hmm.  Can you file a new bug against azureus for that?  CC fitzsim
when you do as he does bouncycastle.  Thanks.

> Hmm.  Can you file a new bug against azureus for that?  CC fitzsim
> when you do as he does bouncycastle.  Thanks.

Done. Please see bug #218794

Andrew, what's going on with this bug?

I can't verify ATM (I've got a new gcc RPM which kills old non-BC-compiled
stuff) but I'm pretty sure Azureus is fine in FC6 now.  I don't know about
rawhide, but I'm pretty sure I filed a bug with Anthony to use the new swt JNI
symlinks you put in.

Anthony?

Is azureus broken for anyone else right now?

Azureus seems to work in FC6 for me.  I didn't try downloading anything, but
startup worked.  Should we close this bug now?

Works for me.

Closing bug as Azureus currently works in FC-6.