-----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@zarb.org
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
-----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@zarb.org
-----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@zarb.org
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
-----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@zarb.org
-----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@zarb.org
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
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
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
-----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@zarb.org
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
-----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@zarb.org
-----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_everywhere
$ 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@zarb.org
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_everywhere
$ 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
"Anthony" == Anthony Green green@redhat.com 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
java-devel@lists.fedoraproject.org
-
Anthony Green -
David Walluck -
Mark Wielaard -
Tom Tromey