[Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)]

[Anthony Green]

Just FYI...

AG

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  Just FYI...
>  
>  AG 
I have a couple  questions:

Why the exclusive arch? It built on x86_64, but I had problems with int
vs. long in one of the files, and I am not sure why. I guess it won't
run on x86_64 due to the threading issue that isn't fixed yet.

Why the ldconfig in %post/%postun?

I would say to add BuildRequires: java-devel. But it's not really
required since java-gcj-compat-devel already is.

I do notice some packaging differences between the bc 1.31 update I made
and the bc in FC. I guess any updates from 1.27 on didn't make it to
JPackage/FC. Sorry...

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDyxl1arJDwJ6gwowRAtOPAJ9SdcfUBR+sKbBfj0Q5nDAWXIewEwCdHqxX
> YcVbWiLTruPiKmtDTFeL3V8=
> =jc97
> -----END PGP SIGNATURE-----

[Anthony Green]

On Sun, 2006-01-15 at 22:56 -0500, David Walluck wrote:
>  Why the exclusive arch?  
We should be able to build this on x86_64.  I was able to a few weeks
ago, but it required patch for this...

>  It built on x86_64, but I had problems with int
>  vs. long in one of the files, and I am not sure why. 
My x86_x64 system is out of commission right now and I've lost those
patches.  I'll install it again when FC5test2 is out and fix this.

>   I guess it won't
>  run on x86_64 due to the threading issue that isn't fixed yet. 
I don't think that bug will be an issue here.  It mainly shows up in
apps that use the SWT browser widget.  I don't think Azureus does that.

>  Why the ldconfig in %post/%postun? 
No reason - I'll remove them.

>  I do notice some packaging differences between the bc 1.31 update I
> made
>  and the bc in FC. I guess any updates from 1.27 on didn't make it to
>  JPackage/FC. Sorry... 
I just grab packages from the JPackage web site, but I suspect that it's
not pointing to the latest stuff.  Do you have a URL?

Thanks,

AG

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  We should be able to build this on x86_64.  I was able to a few
> weeks
>  ago, but it required patch for this... 
Whatever patch I needed was on both i586 and x86_64. I will build
azureus soon and see what happens wrt all the patches.

>  I just grab packages from the JPackage web site, but I suspect that
> it's
>  not pointing to the latest stuff.  Do you have a URL? 
Due to lack of time, I never uploaded any release since 1.25, but I have
been making releases all along for my own use. I hope today to have
bouncycastle 1.31 ready and I will post it somewhere.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDzBdQarJDwJ6gwowRAjYCAJ0TTtYAsnjx6Rvirm3ETunpuWmFgQCfcope
> +K4IbJ0pvQHF70dIjuOp3a8=
> =W+Se
> -----END PGP SIGNATURE-----

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  My x86_x64 system is out of commission right now and I've lost
> those
>  patches.  I'll install it again when FC5test2 is out and fix this. 
I am sure I applied the socket patch to the latest gcc 4.1 rpm, but I
still get errors connecting/starting transfers with azureus, although it
at least starts up.

Also, there are exceptions being thrown about the GKR keystore not
existing. No equivalent exceptions are thrown about the JKS keystore
when running under the Sun jdk.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDzZ+1arJDwJ6gwowRAp+XAJ9LvaNCJDJ2+jV8J54BkFLPvrS72gCfXuMt
> knnWTfeFjKwbCRQILhZYUWo=
> =22+X
> -----END PGP SIGNATURE-----

[Anthony Green]

On Tue, 2006-01-17 at 20:53 -0500, David Walluck wrote:
>  I am sure I applied the socket patch to the latest gcc 4.1 rpm, but
> I
>  still get errors connecting/starting transfers with azureus, although it
>  at least starts up. 
There also this patch now:
http://gcc.gnu.org/ml/java-patches/2006-q1/msg00048.html

>  Also, there are exceptions being thrown about the GKR keystore not
>  existing. No equivalent exceptions are thrown about the JKS keystore
>  when running under the Sun jdk. 
I don't know what that's about yet.  Theories, advice, patches welcome!

AG

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  On Tue, 2006-01-17 at 20:53 -0500, David Walluck wrote:
> >Also, there are exceptions being thrown about the GKR keystore not
> >existing. No equivalent exceptions are thrown about the JKS keystore
> >when running under the Sun jdk.
>  
>  
>  I don't know what that's about yet.  Theories, advice, patches welcome! 
I don't know yet either, but if the
java.security.KeyStore.getDefaultType() call is fixed in classpath
(libgcj), we don't need to explicitly list "JKS" and "GKR".
Instead, we
could use

KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());

which will automatically change depending on the implementation.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDzccYarJDwJ6gwowRAgMLAJ99ymJx+DSdyFdL2YR8SMnLVbYh/QCgnH+e
> N/W/nKpTo0EQv4o694lLoNg=
> =WCqq
> -----END PGP SIGNATURE-----

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  On Tue, 2006-01-17 at 20:53 -0500, David Walluck wrote:
>  
> >I am sure I applied the socket patch to the latest gcc 4.1 rpm, but I
> >still get errors connecting/starting transfers with azureus, although it
> >at least starts up.
>  
>  
>  There also this patch now:
>  http://gcc.gnu.org/ml/java-patches/2006-q1/msg00048.html 
OK, I applied those 2 patches now. But I still get

java.io.IOException: select registration: channel is closed

There is some strangeness is some of the options. The cache size, for
example, is negative (-33). This might happen on Sun as well, I am not sure.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDzc+iarJDwJ6gwowRAvwBAJ0aNSWUB0MkUmCXxJCYvRr1d0ZDQACePH53
> 3xhpgjFBqAZoc73tYcUo8Ns=
> =lsOr
> -----END PGP SIGNATURE-----

[Anthony Green]

On Wed, 2006-01-18 at 00:18 -0500, David Walluck wrote:
>  OK, I applied those 2 patches now. But I still get
>  
>  java.io.IOException: select registration: channel is closed 
Hmm.. I don't know about this.

>  There is some strangeness is some of the options. The cache size,
> for
>  example, is negative (-33). This might happen on Sun as well, I am not sure. 
This problem is unique to our free JRE.  I see it also and it definitely
needs to be tracked down.

Thanks,

AG

[Anthony Green]

On Wed, 2006-01-18 at 00:18 -0500, David Walluck wrote:
>  There is some strangeness is some of the options. The cache size,
> for
>  example, is negative (-33). This might happen on Sun as well, I am not sure. 
The Azureus developers helped track this down.  Cache size is derived
from Runtime.getRuntime().maxMemory(), for which we return
Long.MAX_VALUE.  Subsequent math on this overflows as we cast to an
integer.  My latest SRPM has a patch.

AG

[Mark Wielaard]

On Wed, 2006-01-18 at 20:51 -0800, Anthony Green wrote:
>  On Wed, 2006-01-18 at 00:18 -0500, David Walluck wrote:
>  > There is some strangeness is some of the options. The cache size, for
>  > example, is negative (-33). This might happen on Sun as well, I am not sure.
>  
>  The Azureus developers helped track this down.  Cache size is derived
>  from Runtime.getRuntime().maxMemory(), for which we return
>  Long.MAX_VALUE.  Subsequent math on this overflows as we cast to an
>  integer.  My latest SRPM has a patch. 
This seems to be a common problem. Eclipse had the same kind of issue
(already fixed), see https://bugs.eclipse.org/bugs/show_bug.cgi?id=11129

We have added it to the page that lists problematic code snippets we
found in common free Java applications that make them dependent upon the
some specific (proprietary) implementation and that shows how to
implement things in a way that standards are respected and compatibility
with GNU Classpath is the result:
http://developer.classpath.org/mediation/ClasspathMigration

Cheers,

Mark

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  The Azureus developers helped track this down.  Cache size is
> derived
>  from Runtime.getRuntime().maxMemory(), for which we return
>  Long.MAX_VALUE.  Subsequent math on this overflows as we cast to an
>  integer.  My latest SRPM has a patch. 
I am not sure if my setting changed, but it is probably stored locally.

I noticed another annoying issue which should be patched. When you
download the update plugin it sticks a `./plugins' directory in the
current directory (the one that you launched azureus from, assuming you
have write access).

It should try to use $HOME/.Azureus/plugins. In fact, I note several
plugins under this directory, so I am not sure right now what the issue
is, whether it is with the update plugin itself or the gcj implementation.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFD1gr0arJDwJ6gwowRAsDEAKCd3q0t0FZNQlvFCbIKYksFmvRNNgCfcVlC
> 412uKVaFagCiq3tYu1YGtug=
> =M5f2
> -----END PGP SIGNATURE-----

[Anthony Green]

On Tue, 2006-01-24 at 06:09 -0500, David Walluck wrote:
>  It should try to use $HOME/.Azureus/plugins. In fact, I note several
>  plugins under this directory, so I am not sure right now what the issue
>  is, whether it is with the update plugin itself or the gcj implementation. 
I know about this issue.  I'll file a bug report.

AG

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  I know about this issue.  I'll file a bug report. 
Here is one more issue, then. On startup, I see the message

changeLocale: no message properties for Locale 'en (US)' (en_US), using
'English (default)'

I think that if you have a locale set other than English, the app may
crash here and even fail to get past the splash screen.

Again, I haven't been able to investigate more beyond this.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFD1poTarJDwJ6gwowRAi6wAKCKHQ5WyOrZtZC5hzJsYvSFsVJWAgCeLwKx
> lb/mTFji8QimuetHzwBMJHU=
> =1Exs
> -----END PGP SIGNATURE-----

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  Just FYI... 
I have been considering compatibility with proprietary jdks and the
current azureus rpm. After all, until FC4 users have gcc 4.1, this seems
like the best option. Also, free-jdk lockin is bad, IMO (not as bad as
proprietary lockin, of course).

1.) About java.beans.XMLEncoder: I thought this implementation had been
committed to classpath? See
<http://www.fsfe.org/en/fellows/robertschuster/weblog/gnu_classpath_everyw...

$ unzip -l /usr/share/classpath/glibj.zip | grep java\.beans\.XMLEncoder
     3227  01-14-06 01:19   java/beans/XMLEncoder.class

$ unzip -l /usr/share/java/libgcj-4.1.0.jar | grep java\.beans\.XMLEncoder

Looks like libgcj is not in sync with this change.

2.) There's some scary stuff removed in azureus-sun.misc.Cleaner.patch
and azureus-sun.misc.Signal.patch. What are the chances that upstream
even cares about this? It is non-critical and can be removed even on
proprietary jdks I think.

3.) It appears that azureus-remove-win32-osx-platforms.patch would not
be necessary if an exception wasn't thrown/logged if the platform was
not macos or windows. There seems to be no harm in actually checking the
platform. Maybe upstream would accept a patch.

4.) Most importantly, the patches azureus-GKR.patch and
azureus-jessie.patch create lockin to gcj. With the classpath.security
file, is jessie.patch even necessary? It might also be possible to try
for both classes and just catch exceptions. About the GKR patch, maybe
the same thing applies: try for JKS also, and handle the error.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDyyrRarJDwJ6gwowRAn2cAJ9iv4ywJtnN9bOFX6V47VxOaYYy2gCfXAbM
> dtSikixgsR1Vz9E/CgiC9q8=
> =V0Jd
> -----END PGP SIGNATURE-----

[Anthony Green]

On Mon, 2006-01-16 at 00:10 -0500, David Walluck wrote:
>  1.) About java.beans.XMLEncoder: I thought this implementation had
> been
>  committed to classpath? See
>  <http://www.fsfe.org/en/fellows/robertschuster/weblog/gnu_classpath_everyw...
>  
>  $ unzip -l /usr/share/classpath/glibj.zip | grep java\.beans\.XMLEncoder
>       3227  01-14-06 01:19   java/beans/XMLEncoder.class
>  
>  $ unzip -l /usr/share/java/libgcj-4.1.0.jar | grep java\.beans\.XMLEncoder
>  
>  Looks like libgcj is not in sync with this change. 
It was only added very recently (after I wrote the patch, in fact).  So,
if we don't add it to 4.1, which doesn't seem to be happening, I was
thinking of simply bundling it with the Azureus SRPM.

>  2.) There's some scary stuff removed in
> azureus-sun.misc.Cleaner.patch
>  and azureus-sun.misc.Signal.patch. What are the chances that upstream
>  even cares about this? It is non-critical and can be removed even on
>  proprietary jdks I think. 
To be honest, I don't even know what those things do.  Let's just put
all our patches and comments together to feed to upstream.

>  3.) It appears that azureus-remove-win32-osx-platforms.patch would
> not
>  be necessary if an exception wasn't thrown/logged if the platform was
>  not macos or windows. There seems to be no harm in actually checking the
>  platform. Maybe upstream would accept a patch. 
I don't compile these because there are some references to platform
specific classes somewhere (like from a vendor's JRE) and it was easiest
just to cut all that code out.  Try removing that patch and doing the
platform test, and you'll see what I mean.

>  4.) Most importantly, the patches azureus-GKR.patch and
>  azureus-jessie.patch create lockin to gcj. With the classpath.security
>  file, is jessie.patch even necessary?  
Maybe not.  I don't think we add Jessie to our security property file by
default.  I have it in mine, but it's possible I added it manually.  I
guess I'll know once I do the clean FC5test2 install.

>  It might also be possible to try
>  for both classes and just catch exceptions. About the GKR patch, maybe
>  the same thing applies: try for JKS also, and handle the error. 
Yes, we can definitely do that.  At the time I wasn't interested in
spending time to create upstream-friendly patches, since I wasn't sure
any of this would work at all.  Now I'm interested, and appreciate the
help!

Thanks,

AG

[Tom Tromey]

> >>>> "Anthony" == Anthony Green
> <green(a)redhat.com&gt; writes: 
> > 1.) About java.beans.XMLEncoder: I thought this implementation
> had been
> > committed to classpath? See 
Anthony> It was only added very recently (after I wrote the patch, in
Anthony> fact).  So, if we don't add it to 4.1, which doesn't seem to
Anthony> be happening, I was thinking of simply bundling it with the
Anthony> Azureus SRPM.

Yeah, I don't think this will go in gcc4.1 / fc5.
At least, I wasn't planning to import it and we've pretty much
stopped making big changes.

Tom