You will need to download the jre (jre-1_5_0_02-linux-i586.rpm) and create a symbolic link to the plugin from /usr/lib/firefox-1.0.2/plugins/
ln -s /usr/java/jre1.5.0_02/plugin/i386/ns7/libjavaplugin_oji.so libjavaplugin_oji.so
Alan
Alan J. Gagne wrote:
You will need to download the jre (jre-1_5_0_02-linux-i586.rpm) and create a symbolic link to the plugin from /usr/lib/firefox-1.0.2/plugins/
ln -s /usr/java/jre1.5.0_02/plugin/i386/ns7/libjavaplugin_oji.so libjavaplugin_oji.so
Alan
Since there is a kind of Java-Support with GCJ in FC4T1,shouldn't we better use this??? If yes, how to?
Roger
On Sun, 2005-04-03 at 21:29 +0200, Roger Grosswiler wrote:
Since there is a kind of Java-Support with GCJ in FC4T1,shouldn't we better use this??? If yes, how to?
See gcjwebplugin: http://www.nongnu.org/gcjwebplugin/
The big problem with this today is that gcj has known problems with its sandbox security implementation. We need to fix those problems and do a full audit of libgcj before it makes sense to package gcjwebplugin.
I'm not fully aware of SELinux's capabilities yet, but I wonder if it's possible to sandbox our current libgcj for gcjwebplugin by writing strict SELinux policy. Does anybody know?
AG
Anthony Green schrieb:
On Sun, 2005-04-03 at 21:29 +0200, Roger Grosswiler wrote:
Since there is a kind of Java-Support with GCJ in FC4T1,shouldn't we better use this??? If yes, how to?
See gcjwebplugin: http://www.nongnu.org/gcjwebplugin/
The big problem with this today is that gcj has known problems with its sandbox security implementation. We need to fix those problems and do a full audit of libgcj before it makes sense to package gcjwebplugin.
I'm not fully aware of SELinux's capabilities yet, but I wonder if it's possible to sandbox our current libgcj for gcjwebplugin by writing strict SELinux policy. Does anybody know?
AG
Thanks,
I looked the homepage and understand your problem. couldn't this be a feature for FC4T3? I think it's to late for T2 now... ;-) if yes, i would create an entry in bugzilla, as i think, the installation must be quite easy, but SELINUX *hrm*, i really don't know (even not in the actual implementation) done by sopwith (Thanks for easy handling by gui ;-)
Roger
On Mon, 2005-04-04 at 07:23 +0200, Roger Grosswiler wrote:
I looked the homepage and understand your problem. couldn't this be a feature for FC4T3?
No, I think FC5test1 is more realistic.
AG
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
in each case we would have java-support in the browser, nevermind when ;-) if it is not in 10 years..
Roger
On 04/04/2005 12:19:55 AM, Roger Grosswiler wrote:
in each case we would have java-support in the browser, nevermind when ;-) if it is not in 10 years..
In the meantime - http://www.jpackage.org/
Their nosrc.rpm should work in fc4t1 - though I personally haven't tried (in fc3 I had to fix the spec file but that's known problem with fc3 and hopefully fixed now, there's been a bugzilla for awhile)
man, 04.04.2005 kl. 04.54 skrev Anthony Green:
On Sun, 2005-04-03 at 21:29 +0200, Roger Grosswiler wrote:
Since there is a kind of Java-Support with GCJ in FC4T1,shouldn't we better use this??? If yes, how to?
See gcjwebplugin: http://www.nongnu.org/gcjwebplugin/
The big problem with this today is that gcj has known problems with its sandbox security implementation. We need to fix those problems and do a full audit of libgcj before it makes sense to package gcjwebplugin.
I'm not fully aware of SELinux's capabilities yet, but I wonder if it's possible to sandbox our current libgcj for gcjwebplugin by writing strict SELinux policy. Does anybody know?
AG
Another problem might be how complete the gcc java implementation is...
On Mon, 2005-04-04 at 16:41 +0200, Kyrre Ness Sjobak wrote:
Another problem might be how complete the gcc java implementation is...
I think it's already proven to be good enough for many applets, including, for instance, Flumotion's Cortado applet (a media player for Ogg Theora video) and various game applets.
Sure, it's not perfect yet, but my feeling is that we should package it for people to use as soon as we sort out the security problems.
AG
man, 04.04.2005 kl. 23.54 skrev Anthony Green:
On Mon, 2005-04-04 at 16:41 +0200, Kyrre Ness Sjobak wrote:
Another problem might be how complete the gcc java implementation is...
I think it's already proven to be good enough for many applets, including, for instance, Flumotion's Cortado applet (a media player for Ogg Theora video) and various game applets.
Sure, it's not perfect yet, but my feeling is that we should package it for people to use as soon as we sort out the security problems.
AG
OTOH, some rumors are saying that Sun might LGPL their Java 2nd quarter, for the sake of OpenOffice: http://www.sapinfo.net/index.php4?ACTION=noframe&url=http://www.sapinfo.... http://www.libervis.com/modules/weblog/details.php?blog_id=42
That could be interesting... OTOH, i don't know how much theese rumors should be thrusted.
Kyrre Ness Sjøbæk
On Tue, 2005-04-05 at 15:09 +0200, Kyrre Ness Sjobak wrote:
OTOH, some rumors are saying that Sun might LGPL their Java 2nd quarter, for the sake of OpenOffice: http://www.sapinfo.net/index.php4?ACTION=noframe&url=http://www.sapinfo.... http://www.libervis.com/modules/weblog/details.php?blog_id=42
That article is about them freeing up the "Java Enterprise System" which, AFAICT, is not a JRE/JDK. It's a suite of applications including an app server. I think this has more to do with the traction being made by jonas and jboss than openoffice.
AG
On Sun, 2005-04-03 at 19:54 -0700, Anthony Green wrote:
On Sun, 2005-04-03 at 21:29 +0200, Roger Grosswiler wrote:
Since there is a kind of Java-Support with GCJ in FC4T1,shouldn't we better use this??? If yes, how to?
See gcjwebplugin: http://www.nongnu.org/gcjwebplugin/
The big problem with this today is that gcj has known problems with its sandbox security implementation. We need to fix those problems and do a full audit of libgcj before it makes sense to package gcjwebplugin.
I'm not fully aware of SELinux's capabilities yet, but I wonder if it's possible to sandbox our current libgcj for gcjwebplugin by writing strict SELinux policy. Does anybody know?
Depends on the desired granularity of protection and the extent to which the current architecture uses separate processes and exec-based transitions (although the latter is less of a constraint now that SELinux supports dynamic context transitions, I suppose).
Ultimately, you want a SELinux-aware jvm that uses the SELinux API to get policy decisions and apply them to its internal resources for finer- grained control as well as using the SELinux kernel controls to confine the entire process.