FC5 has been kind of frustrating from a libgcj perspective. We've had to
wait extra-long for new gcc RPMS in order to get critical libgcj fixes
out (for instance 4 or 5 weeks to get gc deadlock update out). I know
people have talked about separating libgcj from gcc in the past. I
don't know those conversations ever ended, but it would be really nice
if we could do something for FC6.
I think the simplest approach would be for jakub to continue building
gcc RPMS as is (including building libgcj and running gcj testsuite),
but then delete libgcj after install and don't build the libgcj
sub-packages. The gcc/libjava directory would still be part of the gcc
SRPM and would get tested as before.
Then we could simply maintain a separate SRPM for libgcj, and not be
shackled to the gcc update schedule. The SRPM would only have to
contain the appropriate target directories, and we could incorporate
mauve testing into the release process.
I think this will be particularly important if we manage to get
something like gcjwebplugin with the new whitelist feature into FC6.
We may want to push out GUI and security updates on a much more frequent
basis than is reasonable for gcc.
Thanks to langel and fitzsim's help, I've created a gcjwebplugin-test
package for x86 FC5. It's built from GNU Classpath and jamvm cvs HEAD
sources. The source RPM just contains a script for checking out the
sources and building them. The binary RPM includes all the sources
(installed under /usr/share/gcjwebplugin-test).
To try it out, simple create a file
called /etc/yum.repos.d/gcjwebplugin-test.repo with the following
name=Experimental gcjwebplugin repository
Then "yum install gcjwebplugin-test".
I don't know what this will do if you have Sun's plugin installed as
well (I don't).
Also, this version of the plugin includes Lillian's whitelist trick, so
it will only load applets you specifically say are "OK".
Please report any applet bugs to the GNU Classpath bugzilla repository..
ARUN P SADANANDAN
L B S College of Engineering
Kerala 671 542
I am happy to introduce myself. I am ARUN P SADANANDAN, doing a Master of Computer Applications at L B S College of Engineering, Kasaragod, affiliated to Kannur University. Now I have just completed my fifth semester.
As per the syllabus prescribed by Kannur University each MCA student has to do a six month long project work at their sixth semester as a part of their curriculum .I have to start my project work by July 2006 and have to submit the
report by November last. I am here by attaching a copy of my resume & my syllabus along with this.
I am really interested to do a project in linux platform.I will be thankful to you if anybody could send me the details of any project works available .
Arun P Sadanandan
Images by Graphics Factory.com
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
I'm working on updating the JPackage eclipse package for a pending
JPackage release (1.7). Right now there exists a circular build
problem between the tomcat5 and eclipse packages (eclipse-platform
requires tomcat5, tomcat5 requires eclipse-ecj). Debian, Mandriva,
and Suse have split out eclipse-ecj into a bootstrap package to solve
this dilemma. Another suggestion made was to make eclipse-platform
into its own package so that the rest of the eclipse components can be
noarch since they are all java.
Since one of the goals for JPackage is to make it easier for various
distros to use our work with little to no changes I wanted to find out
from the fedora-java community if they see any problems with at least
splitting out ecj into a separate package (for reference the Mandriva
package is named ecj-bootstrap). I believe this was done in the past?
Right now the updated eclipse packages that I have so far are located at:
It is not an actual repo despite what the URL may imply. Any patches,
information, etc. greatly appreciated.
the version currently in CVS -- I have a previous version that did it --
refuses to build with the following error:
48. ERROR in
(at line 9)
The import org.eclipse.jface.viewers.TreeSelection cannot be resolved
Isn't a new class missing in the CVS?
Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27
OpenCall Business Unit -- OCBU / //_/ Fax:+33 (0)4 76 14 51 62
Media-Processing Engineering / http://www.hp.com/go/opencall
i n v e n t
Now that we have a new libgcj in FC-5, azureus logging seems to be
working. I've been comparing log files between Sun JRE and gcj runs,
and have filed 1 GNU Classpath bug so far.
One thing that is annoying is that I'm not getting line numbers in the
azureus debug output. Azureus' calls to
StackTraceElement.getLineNumber() always result in -1. I have the
azureus debug RPM installed, and just assumed that this would be enough
to get line number info. Maybe I'm misremembering all this. Should
StackTraceElement.getLineNumber() return good info for bc-compiled code?