From gbenson at redhat.com Thu Sep 1 09:23:55 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 1 Sep 2005 10:23:55 +0100 Subject: [fedora-java] java-gcjHEAD-compat fixes In-Reply-To: <1125441076.15771.47.camel@tortoise.toronto.redhat.com> References: <1125441076.15771.47.camel@tortoise.toronto.redhat.com> Message-ID: <20050901092353.GC4727@redhat.com> Thomas Fitzsimmons wrote: > I fixed some things in java-gcjHEAD-compat: > > - removed the file conflicts with java-gcj-compat, so > java-gcjHEAD-compat will install cleanly beside other java-gcj-compat > installations > > - added "javac" to the installed tools, using Gary's bootstrap ecj jar > > Here are Andrew's instructions for creating a JPackage alternative for > GCJ HEAD: > > https://www.redhat.com/archives/fedora-devel-java-list/2005-May/msg00046.html > > The installation of these packages runs smoothly now. Funky! From green at redhat.com Thu Sep 1 14:57:41 2005 From: green at redhat.com (Anthony Green) Date: Thu, 01 Sep 2005 07:57:41 -0700 Subject: [fedora-java] java-gcjHEAD-compat fixes In-Reply-To: <1125513896.29329.3.camel@tortoise.toronto.redhat.com> References: <1125441076.15771.47.camel@tortoise.toronto.redhat.com> <1125509965.3723.47.camel@localhost.localdomain> <1125513896.29329.3.camel@tortoise.toronto.redhat.com> Message-ID: <1125586661.3154.4.camel@localhost.localdomain> On Wed, 2005-08-31 at 14:44 -0400, Thomas Fitzsimmons wrote: > I updated the instructions and put them on the Wiki: > > http://www.fedoraproject.org/wiki/java-gcjHEAD-compat I had problems with these instructions. "make test-srpm" didn't do anything. I had to "make sources" and copy the sources into my SOURCES directory and build from the spec file. I also get the following error when I try to install. $ rpm -hiv /usr/src/redhat/RPMS/i386/java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh.i386.rpm Preparing... ########################################### [100%] file /etc/java/security/security.d/1000-gnu.java.security.provider.Gnu from install of java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh conflicts with file from package java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1 Thanks, AG From fitzsim at redhat.com Thu Sep 1 15:22:54 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 01 Sep 2005 11:22:54 -0400 Subject: [fedora-java] java-gcjHEAD-compat fixes In-Reply-To: <1125586661.3154.4.camel@localhost.localdomain> References: <1125441076.15771.47.camel@tortoise.toronto.redhat.com> <1125509965.3723.47.camel@localhost.localdomain> <1125513896.29329.3.camel@tortoise.toronto.redhat.com> <1125586661.3154.4.camel@localhost.localdomain> Message-ID: <1125588174.29329.35.camel@tortoise.toronto.redhat.com> On Thu, 2005-09-01 at 07:57 -0700, Anthony Green wrote: > On Wed, 2005-08-31 at 14:44 -0400, Thomas Fitzsimmons wrote: > > I updated the instructions and put them on the Wiki: > > > > http://www.fedoraproject.org/wiki/java-gcjHEAD-compat > > I had problems with these instructions. > > "make test-srpm" didn't do anything. I had to "make sources" and copy > the sources into my SOURCES directory and build from the spec file. Did you do "make test-srpm" in java-1.4.2-gcj-compat/devel? That's supposed to generate an SRPM in java-1.4.2-gcj-compat/devel (not in ~/rpmbuild/SRPMS). It works for me here. > > I also get the following error when I try to install. > > $ rpm -hiv /usr/src/redhat/RPMS/i386/java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh.i386.rpm > Preparing... ########################################### [100%] > file /etc/java/security/security.d/1000-gnu.java.security.provider.Gnu from install of java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh conflicts with file from package java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1 You'll have to update the installed java-1.4.2-gcj-compat before installing java-gcjHEAD-compat. Tom From green at redhat.com Thu Sep 1 15:33:24 2005 From: green at redhat.com (Anthony Green) Date: Thu, 01 Sep 2005 08:33:24 -0700 Subject: [fedora-java] java-gcjHEAD-compat fixes In-Reply-To: <1125588174.29329.35.camel@tortoise.toronto.redhat.com> References: <1125441076.15771.47.camel@tortoise.toronto.redhat.com> <1125509965.3723.47.camel@localhost.localdomain> <1125513896.29329.3.camel@tortoise.toronto.redhat.com> <1125586661.3154.4.camel@localhost.localdomain> <1125588174.29329.35.camel@tortoise.toronto.redhat.com> Message-ID: <1125588805.3154.6.camel@localhost.localdomain> On Thu, 2005-09-01 at 11:22 -0400, Thomas Fitzsimmons wrote: > > "make test-srpm" didn't do anything. I had to "make sources" and copy > > the sources into my SOURCES directory and build from the spec file. > > Did you do "make test-srpm" in java-1.4.2-gcj-compat/devel? That's > supposed to generate an SRPM in java-1.4.2-gcj-compat/devel (not in > ~/rpmbuild/SRPMS). It works for me here. Yes, that's what I did. It's not doing anything here. > > I also get the following error when I try to install. > > > > $ rpm -hiv /usr/src/redhat/RPMS/i386/java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh.i386.rpm > > Preparing... ########################################### [100%] > > file /etc/java/security/security.d/1000-gnu.java.security.provider.Gnu from install of java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh conflicts with file from package java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1 > > You'll have to update the installed java-1.4.2-gcj-compat before > installing java-gcjHEAD-compat. I think I'm using the very latest java-1.4.2-gcj-compat for FC4. Are you saying I need to install the rawhide version? I was hoping to keep my system purely FC4 with the exception of this new java-1.4.2-gcjHEAD-compat package. AG From fitzsim at redhat.com Thu Sep 1 15:40:09 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 01 Sep 2005 11:40:09 -0400 Subject: [fedora-java] java-gcjHEAD-compat fixes In-Reply-To: <1125588805.3154.6.camel@localhost.localdomain> References: <1125441076.15771.47.camel@tortoise.toronto.redhat.com> <1125509965.3723.47.camel@localhost.localdomain> <1125513896.29329.3.camel@tortoise.toronto.redhat.com> <1125586661.3154.4.camel@localhost.localdomain> <1125588174.29329.35.camel@tortoise.toronto.redhat.com> <1125588805.3154.6.camel@localhost.localdomain> Message-ID: <1125589209.29329.39.camel@tortoise.toronto.redhat.com> On Thu, 2005-09-01 at 08:33 -0700, Anthony Green wrote: > On Thu, 2005-09-01 at 11:22 -0400, Thomas Fitzsimmons wrote: > > > "make test-srpm" didn't do anything. I had to "make sources" and copy > > > the sources into my SOURCES directory and build from the spec file. > > > > Did you do "make test-srpm" in java-1.4.2-gcj-compat/devel? That's > > supposed to generate an SRPM in java-1.4.2-gcj-compat/devel (not in > > ~/rpmbuild/SRPMS). It works for me here. > > Yes, that's what I did. It's not doing anything here. Strange; do you have java-1.4.2-gcj-compat/common checked out as well? > > > > I also get the following error when I try to install. > > > > > > $ rpm -hiv /usr/src/redhat/RPMS/i386/java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh.i386.rpm > > > Preparing... ########################################### [100%] > > > file /etc/java/security/security.d/1000-gnu.java.security.provider.Gnu from install of java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh conflicts with file from package java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1 > > > > You'll have to update the installed java-1.4.2-gcj-compat before > > installing java-gcjHEAD-compat. > > I think I'm using the very latest java-1.4.2-gcj-compat for FC4. Are > you saying I need to install the rawhide version? I was hoping to keep > my system purely FC4 with the exception of this new > java-1.4.2-gcjHEAD-compat package. You can do that, but you'll have to use the --force option when installing java-1.4.2-gcjHEAD-compat. Only java-1.4.2-gcj-compat versions > 0:1.4.2.0-40jpp_44rh (i.e. Rawhide) allow clean parallel installation of java-1.4.2-gcjHEAD-compat. Tom From aph at redhat.com Mon Sep 5 10:47:10 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Sep 2005 11:47:10 +0100 Subject: [fedora-java] GNU Classpath distro DevJam In-Reply-To: <1124716114.22203.78.camel@localhost.localdomain> References: <20050817162306.51529.qmail@web80906.mail.scd.yahoo.com> <1124716114.22203.78.camel@localhost.localdomain> Message-ID: <17180.8750.282860.920086@zapata.pink> Mark Wielaard writes: > > > Are there going to be any Redhat/Fedora Java devs > > attending? > > Although various fedora hackers/packagers said they thought it was > really interesting nobody added their name to the list of interested > people on http://java.debian.net/index.php/DevJam > Please add your name if you are maintaining a package for fedora (or > jpackage, or some other distro) and are interested in attending. Even if > you cannot attend because of the time and place. I guess I'm quite keen to go, but the last time I went to a conference in Germany was LinuxTag where everyone was speaking German, so apart from my own talk it was not very productive for me. Andrew. From justin.conover at gmail.com Tue Sep 6 14:51:05 2005 From: justin.conover at gmail.com (Justin Conover) Date: Tue, 6 Sep 2005 09:51:05 -0500 Subject: [fedora-java] new version of gcjwebplugin Message-ID: https://savannah.nongnu.org/projects/gcjwebplugin/ https://savannah.nongnu.org/forum/forum.php?forum_id=3991 Does anyone know if there are still security concerns with this version? >From the Main page that shows the warning, but not the new version http://www.nongnu.org/gcjwebplugin/news.html WARNING: The current version does not provide a security manager capable of handling Java (tm) applets. Applets have UNRESTRICTED access to your computer. This means they can do anything you can do, like deleting all your important data. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tromey at redhat.com Tue Sep 6 14:48:27 2005 From: tromey at redhat.com (Tom Tromey) Date: 06 Sep 2005 08:48:27 -0600 Subject: [fedora-java] new version of gcjwebplugin In-Reply-To: References: Message-ID: >>>>> "Justin" == Justin Conover writes: Justin> https://savannah.nongnu.org/projects/gcjwebplugin/ Justin> Does anyone know if there are still security concerns with Justin> this version? Yes, there are. The problem isn't so much gcjwebplugin as that we haven't completed the security infrastructure in libgcj. Tom From fitzsim at redhat.com Tue Sep 6 18:20:52 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 06 Sep 2005 14:20:52 -0400 Subject: [fedora-java] java-gcjHEAD-compat fixes In-Reply-To: <1125588805.3154.6.camel@localhost.localdomain> References: <1125441076.15771.47.camel@tortoise.toronto.redhat.com> <1125509965.3723.47.camel@localhost.localdomain> <1125513896.29329.3.camel@tortoise.toronto.redhat.com> <1125586661.3154.4.camel@localhost.localdomain> <1125588174.29329.35.camel@tortoise.toronto.redhat.com> <1125588805.3154.6.camel@localhost.localdomain> Message-ID: <1126030852.29329.81.camel@tortoise.toronto.redhat.com> On Thu, 2005-09-01 at 08:33 -0700, Anthony Green wrote: > On Thu, 2005-09-01 at 11:22 -0400, Thomas Fitzsimmons wrote: > > > "make test-srpm" didn't do anything. I had to "make sources" and copy > > > the sources into my SOURCES directory and build from the spec file. > > > > Did you do "make test-srpm" in java-1.4.2-gcj-compat/devel? That's > > supposed to generate an SRPM in java-1.4.2-gcj-compat/devel (not in > > ~/rpmbuild/SRPMS). It works for me here. > > Yes, that's what I did. It's not doing anything here. You're right; in the public repository the command is "make srpm". The command is "make test-srpm" in the internal repository. > > > > I also get the following error when I try to install. > > > > > > $ rpm -hiv /usr/src/redhat/RPMS/i386/java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh.i386.rpm > > > Preparing... ########################################### [100%] > > > file /etc/java/security/security.d/1000-gnu.java.security.provider.Gnu from install of java-1.4.2-gcjHEAD-compat-1.4.2.0-40jpp_47rh conflicts with file from package java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1 > > > > You'll have to update the installed java-1.4.2-gcj-compat before > > installing java-gcjHEAD-compat. > > I think I'm using the very latest java-1.4.2-gcj-compat for FC4. Are > you saying I need to install the rawhide version? I was hoping to keep > my system purely FC4 with the exception of this new > java-1.4.2-gcjHEAD-compat package. This was a problem with the SPEC file. I've committed a fix so that java-gcjHEAD-compat will work with the latest java-1.4.2-gcj-compat for FC4. No need for Rawhide java-1.4.2-gcj-compat. Tom From mark at klomp.org Wed Sep 7 20:16:39 2005 From: mark at klomp.org (Mark Wielaard) Date: Wed, 07 Sep 2005 22:16:39 +0200 Subject: [fedora-java] GNU Classpath distro DevJam In-Reply-To: <17180.8750.282860.920086@zapata.pink> References: <20050817162306.51529.qmail@web80906.mail.scd.yahoo.com> <1124716114.22203.78.camel@localhost.localdomain> <17180.8750.282860.920086@zapata.pink> Message-ID: <1126124199.6524.96.camel@localhost.localdomain> Hi Andrew, On Mon, 2005-09-05 at 11:47 +0100, Andrew Haley wrote: > > http://java.debian.net/index.php/DevJam > > Please add your name if you are maintaining a package for fedora (or > > jpackage, or some other distro) and are interested in attending. Even if > > you cannot attend because of the time and place. > > I guess I'm quite keen to go, but the last time I went to a conference > in Germany was LinuxTag where everyone was speaking German, so apart > from my own talk it was not very productive for me. I promise you that I won't talk German! The meeting is really meant as a hackers for hackers meeting centered around practical, technical discussions in smaller groups. There will be no long German monologues :) More and more information is added to the wiki so please read it again and possibly add some things you find important. Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From green at redhat.com Sun Sep 11 17:26:02 2005 From: green at redhat.com (Anthony Green) Date: Sun, 11 Sep 2005 10:26:02 -0700 Subject: [fedora-java] Improving Fedora javadoc Message-ID: <1126459563.3035.31.camel@localhost.localdomain> There are a couple of big problems with our javadoc situation right now: - We don't install javadoc for the core classes. - There are no links between javadoc packages. If would be nice to fix this for FC5. Here are my suggested actions: 1. If we aren't going to modify the gcc spec file to generate libgcj javadoc, then we should use something like this package, which builds core javadoc from the libgcj-src RPM... http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm 2. Modify all our spec files to include links between packages. 3. All the javadoc gets installed in directories under /usr/share/javadoc. It would be nice if there were a top level index.html to tie them all together. We could add a %post(un) script to maintain this file. 4. The Eclipse help system should refer to this top level index.html, so it shows up along with the other Eclipse docs. Maybe it could also go on the main Gnome menu under Applications/Programming. Any other ideas? It all starts with [1], which we've discussed before but I'm afraid we're kind of stalled on. AG From qwejustin at yahoo.com Sun Sep 11 17:55:00 2005 From: qwejustin at yahoo.com (qwejustin) Date: Sun, 11 Sep 2005 12:55:00 -0500 Subject: [fedora-java] Eclipse Message-ID: Does anyone know when eclipse will be updated next? My understanding is that there have not been a update since 3.1.0_fc-0.M6.22 thanks From overholt at redhat.com Sun Sep 11 19:16:38 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 11 Sep 2005 15:16:38 -0400 Subject: [fedora-java] Eclipse In-Reply-To: References: Message-ID: <20050911191638.GA19412@redhat.com> * qwejustin [2005-09-11 14:22]: > Does anyone know when eclipse will be updated next? My understanding is > that there have not been a update since 3.1.0_fc-0.M6.22 I plan to update to 3.1 final (in FC4) when I sort out: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161483 See this tracker bug for details about the update to 3.1 final: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162443 Andrew From green at redhat.com Tue Sep 13 18:15:26 2005 From: green at redhat.com (Anthony Green) Date: Tue, 13 Sep 2005 11:15:26 -0700 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <1126459563.3035.31.camel@localhost.localdomain> References: <1126459563.3035.31.camel@localhost.localdomain> Message-ID: <1126635326.3035.186.camel@localhost.localdomain> On Sun, 2005-09-11 at 10:26 -0700, Anthony Green wrote: > 1. If we aren't going to modify the gcc spec file to generate libgcj > javadoc, then we should use something like this package, which builds > core javadoc from the libgcj-src RPM... > http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm I've updated this srpm. http://spindazzle.org/FC/devel It would be much better to generate the javadoc from within the gcc spec file, but my understanding is that this can't happen until gjdoc is imported into GCC. > 2. Modify all our spec files to include links between packages. It looks like gjdoc's link facility is broken (or unimplemented). I'll file a bug report. AG From lechique at poczta.onet.pl Tue Sep 13 18:41:30 2005 From: lechique at poczta.onet.pl (Dominik =?iso-8859-2?Q?=A3eszyk?=) Date: Tue, 13 Sep 2005 20:41:30 +0200 Subject: [fedora-java] Native Eclipse 3.1 doesn't start Message-ID: <1126636890.3160.36.camel@localhost.localdomain> Hello, I'm really fresh to java-fedora stuff so maybe it's the reason for my problem: after compiling Eclipse 3.1 using the script from 'GNU Classpath Wiki' [1] I can't start it. There is an error log: !SESSION Tue Sep 13 13:36:30 GMT+02:00 2005 ------------------------------------ !ENTRY org.eclipse.core.launcher 4 0 2005-09-13 13:36:30.114 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter not found in org.eclipse.core.launcher.MainStartupClassLoader{urls= [file:/home/lechique/eclipse_test/./plugins/org.eclipse.osgi_3.1.0.jar.so], parent=null} at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at org.eclipse.core.launcher.Main.invokeFramework(java.lang.String[], java.net.URL[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.basicRun(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.run(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.main(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) The compilation process went pretty smoothly (without any errors) and path for db file (gnu.gcj.precompiled.db.path) was set correctly. I don't understand but it seems that classloader doesn't see original jar libraries. Am I correct? What should I do? [1] http://developer.classpath.org/mediation/ClasspathShowcase Best Regards, Lechique Pozdrawia, Lechique -- "Mistakes are the portals of discovery" James Joyce From Tommy.Reynolds at MegaCoder.com Tue Sep 13 20:42:54 2005 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Tue, 13 Sep 2005 15:42:54 -0500 Subject: [fedora-java] Java developer needed to help with Fedora Docs Project infrastructure Message-ID: <20050913154254.31e9aac4.Tommy.Reynolds@MegaCoder.com> Hi, All! Over at the Fedora Docs Project, we have a problem that we think you can help with. Our developers use XML DocBook so that we can generate both HTML and PDF forms of the document from the same originals. The HTML generation works great, but the PDF generation is broken. Our current tool "xmlto" uses TeX to render to PDF, but that hasn't been maintained for a long time. We can use Apache FOP for the rendering but don't want to use the JVM version because it doesn't have an open license. So, here is how you could help. We'd first like to get Apache FOP native compiled using gcj and then maybe add in some open-source PNG or JPG rendering libraries. If you would like to help, you can reply on this list or contact me privately at: Tommy.Reynolds at MegaCoder.com I look forward to hearing from you! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From green at redhat.com Tue Sep 13 21:58:41 2005 From: green at redhat.com (Anthony Green) Date: Tue, 13 Sep 2005 14:58:41 -0700 Subject: [fedora-java] Java developer needed to help with Fedora Docs Project infrastructure In-Reply-To: <20050913154254.31e9aac4.Tommy.Reynolds@MegaCoder.com> References: <20050913154254.31e9aac4.Tommy.Reynolds@MegaCoder.com> Message-ID: <1126648721.3035.216.camel@localhost.localdomain> On Tue, 2005-09-13 at 15:42 -0500, Tommy Reynolds wrote: > So, here is how you could help. We'd first like to get Apache FOP > native compiled using gcj and then maybe add in some open-source PNG > or JPG rendering libraries. The jpackage project provides a FOP SRPM. Unfortunately it depends on batik, which currently uses proprietary APIs. There's some details on the problem here: https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg00177.html As far as I know, nobody is currently working on this problem. I guess this would be a good first step towards FOP support. AG From gbenson at redhat.com Wed Sep 14 09:07:39 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 14 Sep 2005 10:07:39 +0100 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <1126635326.3035.186.camel@localhost.localdomain> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> Message-ID: <20050914090737.GA5130@redhat.com> Anthony Green wrote: > On Sun, 2005-09-11 at 10:26 -0700, Anthony Green wrote: > > 1. If we aren't going to modify the gcc spec file to generate > > libgcj javadoc, then we should use something like this package, > > which builds core javadoc from the libgcj-src RPM... > > http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm > > I've updated this srpm. http://spindazzle.org/FC/devel > > It would be much better to generate the javadoc from within the > gcc spec file, but my understanding is that this can't happen > until gjdoc is imported into GCC. Why not? From gbenson at redhat.com Wed Sep 14 09:36:44 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 14 Sep 2005 10:36:44 +0100 Subject: [fedora-java] Java developer needed to help with Fedora Docs Project infrastructure In-Reply-To: <20050913154254.31e9aac4.Tommy.Reynolds@MegaCoder.com> References: <20050913154254.31e9aac4.Tommy.Reynolds@MegaCoder.com> Message-ID: <20050914093642.GB5130@redhat.com> Tommy Reynolds wrote: > So, here is how you could help. We'd first like to get Apache FOP > native compiled using gcj and then maybe add in some open-source PNG > or JPG rendering libraries. Well, the first step would be to download the binary rpms from JPackage and see if they work with libgcj interpreted. I had to install fop, batik, rhino and xmlbeans, but it seemed to work for the few basic examples I tried. Next I suppose you would have to get them building with Fedora's Java. Anthony pointed out some problems with this and how to fix them. Once you have it building you can make it native as described in http://fedoraproject.org/wiki/NativeJava In terms of getting it into Core or Extras, the main thing will be that xmlbeans requires maven to build, and maven requires 60-70 non-Fedoraized packages just to install, let alone build. So, it's not going to happen anytime soon :-/ Cheers, Gary From fitzsim at redhat.com Wed Sep 14 21:38:51 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 14 Sep 2005 17:38:51 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050914090737.GA5130@redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> Message-ID: <1126733931.9822.7.camel@tortoise.toronto.redhat.com> On Wed, 2005-09-14 at 10:07 +0100, Gary Benson wrote: > Anthony Green wrote: > > On Sun, 2005-09-11 at 10:26 -0700, Anthony Green wrote: > > > 1. If we aren't going to modify the gcc spec file to generate > > > libgcj javadoc, then we should use something like this package, > > > which builds core javadoc from the libgcj-src RPM... > > > http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm > > > > I've updated this srpm. http://spindazzle.org/FC/devel > > > > It would be much better to generate the javadoc from within the > > gcc spec file, but my understanding is that this can't happen > > until gjdoc is imported into GCC. > > Why not? Because we don't want to introduce another bootstrapping problem; gjdoc BuildRequires gcj, gcj would BuildRequires gjdoc. Tom > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From fitzsim at redhat.com Wed Sep 14 23:08:01 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 14 Sep 2005 19:08:01 -0400 Subject: [fedora-java] Fedora Core 5 Wishlist Message-ID: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> Hi, I tried to send this yesterday but there was a problem with the Fedora list servers. Tom -------- Forwarded Message -------- > From: Thomas Fitzsimmons > To: fedora-devel-java-list at redhat.com > Subject: Fedora Core 5 Wishlist > Date: Tue, 13 Sep 2005 21:16:31 -0400 > > Hi, > > I've been thinking about my GCJ-related goals for Fedora Core 5, due out > February 2006. Here's a categorized list: > > java-gcj-compat > =============== > > - GNU Crypto fix for Eclipse extssh support: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782 > > Casey Marshall has already committed a Diffie-Hellman JCE provider to > GNU Classpath so this is just a matter of testing. > > - import all JAWT fixes: > > All the necessary patches are already in GNU Classpath and libgcj so > this is just a matter of testing that JOGL works properly on our > java-1.4.2-gcj-compat RPM. > > - Jessie merged into GNU Classpath > > - GNU Crypto core algorithms merged into GNU Classpath > > - gjdoc merged into GNU Classpath and thus ... > > - an --enable-javadocs option to libgcj > > - gcjx becomes java-gcj-compat's javac and javah commands: > > Not sure if this one is doable in time; I don't mean full gcjx, just > the bytecode-compiler portion of it split off into a standalone javac > executable. > > - include Tritonus or some sound implementation > > AWT > === > > - ImageMagick backend for ImageIO > > - Graphics/Imaging refactoring for GTK 2.8 and Cairo > > - MegaMek packages in Fedora Extras: > > http://megamek.sourceforge.net/ > > This just involves a few AWT bug fixes now. > > - fix all 1.5 japi issues in the java.awt.* packages > > - fix all 1.5 japi issues in the javax.imageio.* packages > > Swing > ===== > > - RHDB tools in Fedora Extras: > > http://sources.redhat.com/rhdb/administrator.html > > http://sources.redhat.com/rhdb/visualexplain.html > > http://sources.redhat.com/rhdb/controlcenter.html > > This will also require updating these tools to support PostgreSQL 8.0. > > - Limewire in Fedora Extras: > > http://www.limewire.org/ > > It would be absolutely awesome to have this Swing app working on the > free stack but I'm not sure it's doable in the FC5 time frame. Would > anyone like to undertake it? ;-) > > SWT > === > > - Azureus in Fedora Extras: > > http://azureus.sourceforge.net/ > > Again, not sure if this is doable before FC5 but this would be awesome > to have. > > gcjwebplugin > ============ > > - implement and test security features in GNU Classpath to allow running > untrusted bytecode > > It's very unlikely that this one will be finished before FC5 but I'd > like to at least have started the implementation by then. > > I'm hoping this list will inspire some volunteers, especially for the > big apps and GNU Classpath's security framework. Most of these items > are very doable and will greatly improve the free JPackage stack on > Fedora. > > Tom > From carwyn at carwyn.com Thu Sep 15 04:20:06 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Thu, 15 Sep 2005 05:20:06 +0100 Subject: [fedora-java] jpackage-utils on FC4 (x86_64 issue mainly) Message-ID: <4328F676.6000507@carwyn.com> Why does macros.jpackage in jpackage-utils-1.6.3 on FC4 still use %{_prefix}/lib/jvm references while jpackage.org macros.jpackage in jpackage-utils-1.6.4 (1.6.3 too allegedly) uses %{_libdir}/jvm? The really confusing part is that FC4 seems to have picked up jpackage-utils up _after_ the change was made in the jpackage.org version!? (around 1.6.3 when the chagelog lists the change at 1.6.2). The end result is that the FC4 x86_64 gcj-compat package is in /usr/lib/jvm rather than /usr/lib64/jvm. The unfortunate thing though is that the link part of the alternative slaves also end up pointing at /usr/lib/jvm. I hit this while trying to finish off the Jpackage jdk cleanups I started a while back. Updating to jpackage-utils 1.6.4 from jpackage.org then trying to install a x86_64 Jdk built against it fails if the gcj-compat package is installed as the alternatives link names are different: 1:java-1.5.0-sun ########################################### [ 14%] link /usr/lib/jvm-exports/jre incorrect for slave jre_exports (/usr/lib64/jvm-exports/jre jre_exports) The culprit being: --slave /usr/lib64/jvm-exports/jre jre_exports /usr/lib64/jvm-exports/jre-1.5.0-sun .. which of course conflicts with the link name already installed against "jre_exports" for gcj-compat which lists jre_exports as being a link from /usr/lib/jvm-exports/jre. The workaround is to stick with the jpackage-utils in FC4 I guess. Still it's a good example of how mixing JPackage and FC4 can cause problems. Carwyn From gbenson at redhat.com Thu Sep 15 08:42:44 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Sep 2005 09:42:44 +0100 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <1126733931.9822.7.camel@tortoise.toronto.redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> Message-ID: <20050915084241.GB5316@redhat.com> Thomas Fitzsimmons wrote: > On Wed, 2005-09-14 at 10:07 +0100, Gary Benson wrote: > > Anthony Green wrote: > > > It would be much better to generate the javadoc from within the > > > gcc spec file, but my understanding is that this can't happen > > > until gjdoc is imported into GCC. > > > > Why not? > > Because we don't want to introduce another bootstrapping problem; > gjdoc BuildRequires gcj, gcj would BuildRequires gjdoc. Why is that a problem? Everything that gcc BuildRequires also BuildRequires gcc. Cheers, Gary From david at zarb.org Thu Sep 15 09:44:42 2005 From: david at zarb.org (David Walluck) Date: Thu, 15 Sep 2005 05:44:42 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050915084241.GB5316@redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> Message-ID: <4329428A.1030006@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > Why is that a problem? Everything that gcc BuildRequires also > BuildRequires gcc. Personally, I would create two packages in this scenario: %{name} (with javadocs enabled) and %{name}-bootstrap (without javadocs). The idea is to not have cyclic dependencies. These are a nightmare when building packages from scratch. A lot of times I see in your packages ``bootstrapped into fedora''. Well, this is nice for most people I guess, but I don't consider it very free since you likely bootstrapped off of a package built with Sun javac and now no one else can reproduce it without much work. Granted, not many people would want to reproduce it except me anyway, but in principle it's not very workable. Finally, this isn't as bad as having prebuilt binary jar dependencies, and your example about gcc is valid though I am not sure how it is avoidable. As a related side-note: jonas is sitting in FC4 now, yet *many* packages it requires are not even built for fedora---just Sun built and dropped into the source tarball. At least here I would hope the non-existent packages are filed in buzilla or someone's TODO list. As another side note, I have made a package of jss which is a binary jar currently used by ldapjdk, and I hope to push this out eventually. I believe xalan-j2 also has prebuilt jars in the build (I wish there was a list of these packages somewhere). - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKUKKarJDwJ6gwowRAl1jAJ9tRaLI4tIw06Vev2GwSUaBbPIhRgCglsNO FqWUJg/XAtzZLlhA5aSn0k8= =cZXT -----END PGP SIGNATURE----- From dfarning at sbcglobal.net Thu Sep 15 12:04:50 2005 From: dfarning at sbcglobal.net (David Farning) Date: Thu, 15 Sep 2005 07:04:50 -0500 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat Message-ID: <1126785890.6381.12.camel@localhost.localdomain> I just got around to installing native eclipse on the devel branch and have found what appears to be a dependency issues with java-1.4.2-gcj-compat. When running yum install eclips* I got all sorts of /usr/bin/rebuild-gcj-db: No such file or directory errors until I manually installed java-1.4.2* (I didn't keep a log cause I wasn't sure what was happening yet) When attempting to yum remove eclipse* I get the following .... Removing : xerces-j2 ####################### [ 1/65] Removing : eclipse-jdt-devel ####################### [ 2/65] Removing : ant-nodeps ####################### [ 3/65] Removing : eclipse-pydev ####################### [ 4/65] Removing : ant-apache-bcel ####################### [ 5/65] Removing : ldapjdk ####################### [ 6/65] Removing : jakarta-commons-httpclient ####################### [ 7/65] Removing : ant-jsch ####################### [ 8/65] Removing : ant-apache-resolver ####################### [ 9/65] Removing : ant-trax ####################### [10/65] Removing : geronimo-specs-compat ####################### [11/65] Removing : xalan-j2 ####################### [12/65] Removing : mx4j ####################### [13/65] Removing : eclipse-platform-devel ####################### [14/65] Removing : ant-jdepend ####################### [15/65] Removing : jakarta-commons-collections ####################### [16/65] Removing : jakarta-commons-fileupload ####################### [17/65] Removing : java-1.4.2-gcj-compat ####################### [18/65] Removing : jakarta-commons-logging ####################### [19/65] /var/tmp/rpm-tmp.61501: line 1: /usr/bin/rebuild-gcj-db: No such file or directory error: %postun(jakarta-commons-logging-1.0.4-2jpp_6fc.i386) scriptlet failed, exit status 127 Removing : eclipse-rcp-devel ####################### [20/65] Removing : jakarta-commons-dbcp ####################### [21/65] Removing : ant-javamail ####################### [22/65] ... The /usr/bin/rebuild-gcj-db: No such file or directory error shows up just after java-1.4.2-gcj-compat has been removed. If I manually reinstall java-1.4.2-gcj-compat I can successfully remove jakarta-commons-logging. Should I look into this deeper and file a bug report? -dtf From gbenson at redhat.com Thu Sep 15 12:37:38 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Sep 2005 13:37:38 +0100 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <4329428A.1030006@zarb.org> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> Message-ID: <20050915123735.GC5316@redhat.com> David Walluck wrote: > Gary Benson wrote: > > Why is that a problem? Everything that gcc BuildRequires also > > BuildRequires gcc. > > Personally, I would create two packages in this scenario: %{name} > (with javadocs enabled) and %{name}-bootstrap (without javadocs). > > The idea is to not have cyclic dependencies. These are a nightmare > when building packages from scratch. A lot of times I see in your > packages ``bootstrapped into fedora''. Well, this is nice for most > people I guess, but I don't consider it very free since you likely > bootstrapped off of a package built with Sun javac and now no one > else can reproduce it without much work. Granted, not many people > would want to reproduce it except me anyway, but in principle it's > not very workable. Finally, this isn't as bad as having prebuilt > binary jar dependencies, and your example about gcc is valid though > I am not sure how it is avoidable. Circular dependencies cannot be avoided for Fedora as a whole because there are packages which depend upon themselves -- the kernel, gcc, rpm, etc. This doesn't make any of those packages not free. Fedora's build system can of course cope with such dependency loops so when they're non-trivial to remove I've always been happy for them to remain. Besides, the full set of gcc rpms is 100-120Mb _per_arch_, with another 30Mb of sources. It's inconceivable that releng would allow what is essentially a duplicate of something that large whatever I or anyone else in the Java group decide. > As a related side-note: jonas is sitting in FC4 now, yet *many* > packages it requires are not even built for fedora---just Sun built > and dropped into the source tarball. At least here I would hope the > non-existent packages are filed in buzilla or someone's TODO > list. There's only a couple left in the Fedora JOnAS, but these require Maven and its 60-70 dependencies that are not yet in Fedora. I'm swamped with the 80-90 packages I already maintain! I should be getting help Real Soon Now, but until that happens we'll be stuck with the binary dependencies (and old package versions, and the other stuff I don't have time to fix). > As another side note, I have made a package of jss which is a > binary jar currently used by ldapjdk, and I hope to push this > out eventually. Cool. > I believe xalan-j2 also has prebuilt jars in the build It does. > (I wish there was a list of these packages somewhere). Any Fedora package whose source rpm contains a file that matches '*RHsemiCLEAN*' is one. Cheers, Gary From gbenson at redhat.com Thu Sep 15 12:42:55 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Sep 2005 13:42:55 +0100 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <1126785890.6381.12.camel@localhost.localdomain> References: <1126785890.6381.12.camel@localhost.localdomain> Message-ID: <20050915124253.GD5316@redhat.com> David Farning wrote: > When running yum install eclips* I got all sorts > of /usr/bin/rebuild-gcj-db: No such file or directory errors until I > manually installed java-1.4.2* It sounds like rpm is _still_ not ordering dependencies correctly. There should be a bug open against rpm for this, but if not please file one. > When attempting to yum remove eclipse* I get the following [snip] This is a separate issue, namely that rpm does not implement erase time dependency ordering. Again, there should be a bug open against rpm for this. Cheers, Gary From i.pilcher at comcast.net Thu Sep 15 13:38:18 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 15 Sep 2005 08:38:18 -0500 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> Message-ID: Something I think is missing.... I believe that there needs to be a clear strategy for the co-existence of Fedora gcj packages and JPackage "pure Java" packages. The current situation is a mess: * If the JPackage repos are added to a FC4 yum configuration, yum will try to overwrite gcj packages with native packages, and vice versa. * There's no way for a user to know what the effects of this, beyond performance will be. etc... -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From i.pilcher at comcast.net Thu Sep 15 13:39:35 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 15 Sep 2005 08:39:35 -0500 Subject: [fedora-java] Re: dependency issues with java-1.4.2-gcj-compat In-Reply-To: <20050915124253.GD5316@redhat.com> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> Message-ID: Gary Benson wrote: > It sounds like rpm is _still_ not ordering dependencies correctly. > There should be a bug open against rpm for this, but if not please > file one. The problem may be that the dependencies are not specified at all. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From gbenson at redhat.com Thu Sep 15 13:56:44 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Sep 2005 14:56:44 +0100 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> Message-ID: <20050915135642.GG5316@redhat.com> Ian Pilcher wrote: > Something I think is missing.... > > I believe that there needs to be a clear strategy for the co-existence > of Fedora gcj packages and JPackage "pure Java" packages. The current > situation is a mess: > > * If the JPackage repos are added to a FC4 yum configuration, yum will > try to overwrite gcj packages with native packages, and vice versa. > > * There's no way for a user to know what the effects of this, beyond > performance will be. > > etc... Suggestions welcome :) From gbenson at redhat.com Thu Sep 15 14:12:53 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Sep 2005 15:12:53 +0100 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <1126792389.6381.20.camel@localhost.localdomain> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> <1126792389.6381.20.camel@localhost.localdomain> Message-ID: <20050915141251.GH5316@redhat.com> David Farning wrote: > On Thu, 2005-09-15 at 13:42 +0100, Gary Benson wrote: > > David Farning wrote: > > > When running yum install eclips* I got all sorts of > > > /usr/bin/rebuild-gcj-db: No such file or directory > > > errors until I manually installed java-1.4.2* > > > > It sounds like rpm is _still_ not ordering dependencies correctly. > > There should be a bug open against rpm for this, but if not please > > file one. > > I did a bit of searching on this it would seem to be the > %if %{gcj_support} > .... > Requires(post): java-gcj-compat >= 1.0.31 > Requires(postun): java-gcj-compat >= 1.0.31 > .... > > are causing problem because they don't...wait for it...work! That's the one. > Would there be a problem with > > %if %{gcj_support} > .... > Requires: java-gcj-compat >= 1.0.31 > .... > > ie. would it hurt it -compat were present all the time not just > during post and unpost? The Short answer is no, since Requires(*) implies Requires. The long answer is that Requires on its own is not in force during rpm transactions. Augmented Requires(*) dependencies specify that it must be present at certain points within the transaction _in_addition_to_ inbetween transactions. Cheers, Gary own, Requires on its own. From gbenson at redhat.com Thu Sep 15 14:13:40 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Sep 2005 15:13:40 +0100 Subject: [fedora-java] Re: dependency issues with java-1.4.2-gcj-compat In-Reply-To: References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> Message-ID: <20050915141340.GI5316@redhat.com> Ian Pilcher wrote: > Gary Benson wrote: > > It sounds like rpm is _still_ not ordering dependencies correctly. > > There should be a bug open against rpm for this, but if not please > > file one. > > The problem may be that the dependencies are not specified at all. If you find a package without them then please let me know. Cheers, Gary From dfarning at sbcglobal.net Thu Sep 15 14:51:49 2005 From: dfarning at sbcglobal.net (David Farning) Date: Thu, 15 Sep 2005 09:51:49 -0500 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <20050915141251.GH5316@redhat.com> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> <1126792389.6381.20.camel@localhost.localdomain> <20050915141251.GH5316@redhat.com> Message-ID: <1126795910.6381.42.camel@localhost.localdomain> On Thu, 2005-09-15 at 15:12 +0100, Gary Benson wrote: > David Farning wrote: > > On Thu, 2005-09-15 at 13:42 +0100, Gary Benson wrote: > > > David Farning wrote: > > > > When running yum install eclips* I got all sorts of > > > > /usr/bin/rebuild-gcj-db: No such file or directory > > > > errors until I manually installed java-1.4.2* > > > > > > It sounds like rpm is _still_ not ordering dependencies correctly. > > > There should be a bug open against rpm for this, but if not please > > > file one. > > > > I did a bit of searching on this it would seem to be the > > %if %{gcj_support} > > .... > > Requires(post): java-gcj-compat >= 1.0.31 > > Requires(postun): java-gcj-compat >= 1.0.31 > > .... > > > > are causing problem because they don't...wait for it...work! > > That's the one. > > > Would there be a problem with > > > > %if %{gcj_support} > > .... > > Requires: java-gcj-compat >= 1.0.31 > > .... > > > > ie. would it hurt it -compat were present all the time not just > > during post and unpost? > > The Short answer is no, since Requires(*) implies Requires. > > The long answer is that Requires on its own is not in force during rpm > transactions. Augmented Requires(*) dependencies specify that it must > be present at certain points within the transaction _in_addition_to_ > inbetween transactions. > > Cheers, > Gary > > I have not had any problems with straight Requires. Yum seems to always handle straight requires correctly properly by, first it installs any required packages then it installs the package it's self. if in [core] / devel / gnu-crypto / gnu-crypto.spec > BuildRequires: ant, java-devel >= 0:1.4 > %if !%{gcj_support} > Requires: java >= 0:1.4 > Requires(post): jpackage-utils >= 0:1.6.3-1jpp_1rh > Requires(postun): jpackage-utils >= 0:1.6.3-1jpp_1rh > %else > Requires: jce > Requires: jpackage-utils >= 0:1.6.2-1jpp_5rh > %endif > Requires: java-sasl > %if %{gcj_support} > # libgcj aot-compiled native libraries > BuildRequires: java-gcj-compat-devel >= 1.0.31 > Requires(post): java-gcj-compat >= 1.0.31 > Requires(postun): java-gcj-compat >= 1.0.31 > %else > BuildArch: noarch > %endif > why not replace the Requires(post): java-gcj-compat >= 1.0.31 Requires(postun): java-gcj-compat >= 1.0.31 with Requires: java-gcj-compat >= 1.0.31. The post and postun problems I am having seem to be because /usr/bin/rebuild-gcj-db can not be found during post and postun. If Requires: java-gcj-compat >= 1.0.31 is used, whenever the post or postun is taking place, rebuild-gcj-db will be present. Dave From i.pilcher at comcast.net Thu Sep 15 15:27:02 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 15 Sep 2005 10:27:02 -0500 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <20050915135642.GG5316@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> Message-ID: Gary Benson wrote: > Suggestions welcome :) I'm not sure what the best solution is, but here are some alternatives to consider: 1. Change the names of gcj packages, so that they don't match the JPackage versions. For example, gcj-tomcat5 could "provide" tomcat5. It should be pretty easy to conditionalize this in the SPEC files. 2. Move the Fedora gcj packages into a separate repository from the rest of the distribution. This would at least allow people to create a "pure" JPackage system by simply disabling this repo. That's all I can think of for now. Perhaps others have ideas. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From aph at redhat.com Thu Sep 15 15:45:15 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Sep 2005 16:45:15 +0100 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> Message-ID: <17193.38667.983439.366727@zapata.pink> Ian Pilcher writes: > Gary Benson wrote: > > Suggestions welcome :) > > I'm not sure what the best solution is, but here are some alternatives > to consider: > > 1. Change the names of gcj packages, so that they don't match the > JPackage versions. For example, gcj-tomcat5 could "provide" > tomcat5. It should be pretty easy to conditionalize this in the > SPEC files. > > 2. Move the Fedora gcj packages into a separate repository from the > rest of the distribution. This would at least allow people to > create a "pure" JPackage system by simply disabling this repo. This seems like a really bad idea because it doesn't allow gcj packages to provide dependencies for JPackages. > That's all I can think of for now. Perhaps others have ideas. Andrew. From gbenson at redhat.com Thu Sep 15 16:00:55 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Sep 2005 17:00:55 +0100 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> Message-ID: <20050915160052.GK5316@redhat.com> Ian Pilcher wrote: > Gary Benson wrote: > > Suggestions welcome :) > > I'm not sure what the best solution is, but here are some > alternatives to consider: > > 1. Change the names of gcj packages, so that they don't match the > JPackage versions. For example, gcj-tomcat5 could "provide" > tomcat5. It should be pretty easy to conditionalize this in > the SPEC files. You wouldn't believe how awful this is. I've done it before, for Stronghold. It seems trivial, but it's actually a nightmare, and the total package count in Stronghold was a tenth of what we're dealing with now. > 2. Move the Fedora gcj packages into a separate repository from the > rest of the distribution. This would at least allow people to > create a "pure" JPackage system by simply disabling this repo. > > That's all I can think of for now. Perhaps others have ideas. > > -- > ======================================================================== > Ian Pilcher i.pilcher at comcast.net > ======================================================================== > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From chris at hubick.com Thu Sep 15 16:24:22 2005 From: chris at hubick.com (Chris Hubick) Date: Thu, 15 Sep 2005 10:24:22 -0600 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <20050915135642.GG5316@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> Message-ID: <1126801462.22473.21.camel@FC4a.CHD.hubick.com> On Thu, 2005-09-15 at 14:56 +0100, Gary Benson wrote: > Ian Pilcher wrote: > > I believe that there needs to be a clear strategy for the co-existence > > of Fedora gcj packages and JPackage "pure Java" packages. The current > > situation is a mess: > > Suggestions welcome :) Distribute JPackage packages "as is". For each JPP package shipped in Fedora, create a corresponding "-bin" package containing the compiled library code. RPM will know about the "-bin" dependencies, and those can depend on each other if needed. One would hope that the binary packages don't need any specific patches, but if they do, feed them up to JPackage. Maybe split JPP into not just "Free" and "Non-Free", but also "Free and works on Free compilers/runtimes". Work to get upstream projects like Apache to abstract code with Non-Free dependencies into separate Ant targets, facilitating the creation of sub-packages for RPM's also abstracting away Non-Free code. Eventually work towards automating the binary builds from JPP SRPM's, with the ultimate goal of having a Yum repository which parallels the JPackage one, or is even included as part of JPP, containing "-bin" RPM's for all packages. Or you could create a whole Fedora specific Java repository to replace using JPP, and it could suck in the JPP srpm's, compile, and provide both noarch and arch results. -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From gbenson at redhat.com Thu Sep 15 16:52:52 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Sep 2005 17:52:52 +0100 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <1126801462.22473.21.camel@FC4a.CHD.hubick.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> <1126801462.22473.21.camel@FC4a.CHD.hubick.com> Message-ID: <20050915165250.GM5316@redhat.com> Chris Hubick wrote: > On Thu, 2005-09-15 at 14:56 +0100, Gary Benson wrote: > > Ian Pilcher wrote: > > > I believe that there needs to be a clear strategy for the > > > co-existence of Fedora gcj packages and JPackage "pure Java" > > > packages. The current situation is a mess: > > > > Suggestions welcome :) > > Distribute JPackage packages "as is". There's no way we can commit to shipping JPackage packages unmodified. But, even if we could... > For each JPP package shipped in Fedora, create a corresponding > "-bin" package containing the compiled library code. There are several reasons not to do this but the showstopper is that if someone does 'yum install jonas-examples' on an empty system they will not get the native code. Cheers, Gary From fitzsim at redhat.com Thu Sep 15 17:27:21 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 15 Sep 2005 13:27:21 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <20050915135642.GG5316@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> Message-ID: <1126805241.7740.15.camel@tortoise.toronto.redhat.com> On Thu, 2005-09-15 at 14:56 +0100, Gary Benson wrote: > Ian Pilcher wrote: > > Something I think is missing.... > > > > I believe that there needs to be a clear strategy for the co-existence > > of Fedora gcj packages and JPackage "pure Java" packages. The current > > situation is a mess: > > > > * If the JPackage repos are added to a FC4 yum configuration, yum will > > try to overwrite gcj packages with native packages, and vice versa. > > > > * There's no way for a user to know what the effects of this, beyond > > performance will be. > > > > etc... > > Suggestions welcome :) All we need to do to make this work properly is make sure that the FC4 packages always have versions >= the corresponding JPackage versions. Then packages that are in JPackage but not in Fedora will be provided by JPackage and all other packages will come from Fedora. Our repackaging of JPackages is meant to be 100% compatible with the source JPackages. If a given package is not compatible then that's a bug in that package. Otherwise Fedora users should always want the Fedora versions of the packages. In other words, if our Fedora package versions always match or exceed their JPackage equivalents then there is no problem with JPackage and Fedora packages co-existing without a clear boundary between the two repositories. I just don't see this as a problem at all. Tom From fitzsim at redhat.com Thu Sep 15 17:29:25 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 15 Sep 2005 13:29:25 -0400 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <1126795910.6381.42.camel@localhost.localdomain> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> <1126792389.6381.20.camel@localhost.localdomain> <20050915141251.GH5316@redhat.com> <1126795910.6381.42.camel@localhost.localdomain> Message-ID: <1126805365.7740.17.camel@tortoise.toronto.redhat.com> On Thu, 2005-09-15 at 09:51 -0500, David Farning wrote: > On Thu, 2005-09-15 at 15:12 +0100, Gary Benson wrote: > > David Farning wrote: > > > On Thu, 2005-09-15 at 13:42 +0100, Gary Benson wrote: > > > > David Farning wrote: > > > > > When running yum install eclips* I got all sorts of > > > > > /usr/bin/rebuild-gcj-db: No such file or directory > > > > > errors until I manually installed java-1.4.2* > > > > > > > > It sounds like rpm is _still_ not ordering dependencies correctly. > > > > There should be a bug open against rpm for this, but if not please > > > > file one. > > > > > > I did a bit of searching on this it would seem to be the > > > %if %{gcj_support} > > > .... > > > Requires(post): java-gcj-compat >= 1.0.31 > > > Requires(postun): java-gcj-compat >= 1.0.31 > > > .... > > > > > > are causing problem because they don't...wait for it...work! > > > > That's the one. > > > > > Would there be a problem with > > > > > > %if %{gcj_support} > > > .... > > > Requires: java-gcj-compat >= 1.0.31 > > > .... > > > > > > ie. would it hurt it -compat were present all the time not just > > > during post and unpost? > > > > The Short answer is no, since Requires(*) implies Requires. > > > > The long answer is that Requires on its own is not in force during rpm > > transactions. Augmented Requires(*) dependencies specify that it must > > be present at certain points within the transaction _in_addition_to_ > > inbetween transactions. > > > > Cheers, > > Gary > > > > > I have not had any problems with straight Requires. Yum seems to always > handle straight requires correctly properly by, > first it installs any required packages > then it installs the package it's self. > > if in [core] / devel / gnu-crypto / gnu-crypto.spec > > > BuildRequires: ant, java-devel >= 0:1.4 > > %if !%{gcj_support} > > Requires: java >= 0:1.4 > > Requires(post): jpackage-utils >= 0:1.6.3-1jpp_1rh > > Requires(postun): jpackage-utils >= 0:1.6.3-1jpp_1rh > > %else > > Requires: jce > > Requires: jpackage-utils >= 0:1.6.2-1jpp_5rh > > %endif > > Requires: java-sasl > > %if %{gcj_support} > > # libgcj aot-compiled native libraries > > BuildRequires: java-gcj-compat-devel >= 1.0.31 > > Requires(post): java-gcj-compat >= 1.0.31 > > Requires(postun): java-gcj-compat >= 1.0.31 > > %else > > BuildArch: noarch > > %endif > > > > why not replace the > > Requires(post): java-gcj-compat >= 1.0.31 > Requires(postun): java-gcj-compat >= 1.0.31 > > with > > Requires: java-gcj-compat >= 1.0.31. > > The post and postun problems I am having seem to be because > /usr/bin/rebuild-gcj-db can not be found during post and postun. If > Requires: java-gcj-compat >= 1.0.31 is used, whenever > the post or postun is taking place, rebuild-gcj-db will be present. I just changed rebuild-gcj-db to be an alternative symlink. Therefore RPM wouldn't know about it. Might that be the problem? Tom > > Dave > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From fitzsim at redhat.com Thu Sep 15 17:35:09 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 15 Sep 2005 13:35:09 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050915084241.GB5316@redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> Message-ID: <1126805709.7740.21.camel@tortoise.toronto.redhat.com> On Thu, 2005-09-15 at 09:42 +0100, Gary Benson wrote: > Thomas Fitzsimmons wrote: > > On Wed, 2005-09-14 at 10:07 +0100, Gary Benson wrote: > > > Anthony Green wrote: > > > > It would be much better to generate the javadoc from within the > > > > gcc spec file, but my understanding is that this can't happen > > > > until gjdoc is imported into GCC. > > > > > > Why not? > > > > Because we don't want to introduce another bootstrapping problem; > > gjdoc BuildRequires gcj, gcj would BuildRequires gjdoc. > > Why is that a problem? Everything that gcc BuildRequires also > BuildRequires gcc. Yeah, I guess you're right. So someone should submit a spec file patch to Jakub, I guess. Anthony? Tom From vadimn at redhat.com Thu Sep 15 17:50:43 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Thu, 15 Sep 2005 13:50:43 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <20050915165250.GM5316@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <1126801462.22473.21.camel@FC4a.CHD.hubick.com> <20050915165250.GM5316@redhat.com> Message-ID: <200509151350.43262.vadimn@redhat.com> On Thursday 15 September 2005 12:52, Gary Benson wrote: > There are several reasons not to do this but the showstopper is that > if someone does 'yum install jonas-examples' on an empty system they > will not get the native code. You may extend the RPM spec file with an optional header like the following: Name: jonas-examples ... yadda yadda yadda ... CanBeMassivelySpedUpBy: jonas-examples-compiled-by-gcj With this in place, yum can now fetch jonas-examples-compiled-by-gcj if is available. This requires changes to both rpm and yum. I have no idea how feasible this would be, but I don't remember this option having been discussed yet. From vadimn at redhat.com Thu Sep 15 17:53:25 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Thu, 15 Sep 2005 13:53:25 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <1126805241.7740.15.camel@tortoise.toronto.redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> <1126805241.7740.15.camel@tortoise.toronto.redhat.com> Message-ID: <200509151353.25514.vadimn@redhat.com> On Thursday 15 September 2005 13:27, Thomas Fitzsimmons wrote: > In other words, if our Fedora package versions always match or > exceed their JPackage equivalents That's a pretty big "if", is it not? From green at redhat.com Thu Sep 15 17:57:58 2005 From: green at redhat.com (Anthony Green) Date: Thu, 15 Sep 2005 10:57:58 -0700 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <1126805709.7740.21.camel@tortoise.toronto.redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <1126805709.7740.21.camel@tortoise.toronto.redhat.com> Message-ID: <1126807078.2944.4.camel@dhcp-172-16-25-146.sfbay.redhat.com> On Thu, 2005-09-15 at 13:35 -0400, Thomas Fitzsimmons wrote: > Yeah, I guess you're right. So someone should submit a spec file patch > to Jakub, I guess. Anthony? Ok, I'll do that soon. AG From rdieter at math.unl.edu Thu Sep 15 17:43:56 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Sep 2005 12:43:56 -0500 Subject: [fedora-java] Re: dependency issues with java-1.4.2-gcj-compat In-Reply-To: <1126805365.7740.17.camel@tortoise.toronto.redhat.com> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> <1126792389.6381.20.camel@localhost.localdomain> <20050915141251.GH5316@redhat.com> <1126795910.6381.42.camel@localhost.localdomain> <1126805365.7740.17.camel@tortoise.toronto.redhat.com> Message-ID: Thomas Fitzsimmons wrote: > I just changed rebuild-gcj-db to be an alternative symlink. Therefore > RPM wouldn't know about it. Might that be the problem? IMO, I would argue that in itself is a bug in your packaging. Any rpm that creates alternatives/symlinks should *own* the alternative/symlink it is creating. Simply touch the target, and add a %ghost entry to the %files section. -- Rex From vadimn at redhat.com Thu Sep 15 18:15:09 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Thu, 15 Sep 2005 14:15:09 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <1126801462.22473.21.camel@FC4a.CHD.hubick.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> <1126801462.22473.21.camel@FC4a.CHD.hubick.com> Message-ID: <200509151415.09657.vadimn@redhat.com> On Thursday 15 September 2005 12:24, Chris Hubick wrote: > Maybe split JPP into not just "Free" and "Non-Free", but also "Free > and works on Free compilers/runtimes". Although this would probably take more effort than anyone's is willing to invest at this point, I do like the general sound of this idea. From chris at hubick.com Thu Sep 15 19:32:49 2005 From: chris at hubick.com (Chris Hubick) Date: Thu, 15 Sep 2005 13:32:49 -0600 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <200509151350.43262.vadimn@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <1126801462.22473.21.camel@FC4a.CHD.hubick.com> <20050915165250.GM5316@redhat.com> <200509151350.43262.vadimn@redhat.com> Message-ID: <1126812769.22473.58.camel@FC4a.CHD.hubick.com> On Thu, 2005-09-15 at 13:50 -0400, Vadim Nasardinov wrote: > On Thursday 15 September 2005 12:52, Gary Benson wrote: > > There are several reasons not to do this but the showstopper is that > > if someone does 'yum install jonas-examples' on an empty system they > > will not get the native code. > > You may extend the RPM spec file with an optional header like the > following: > > > Name: jonas-examples > > ... yadda yadda yadda ... > > CanBeMassivelySpedUpBy: jonas-examples-compiled-by-gcj > > With this in place, yum can now fetch jonas-examples-compiled-by-gcj > if is available. Or maybe some way to have one package state that it "masks" another package? Name: jonas-examples-compiled-by-gcj # Anyone tries to install 'jonas-examples', they get this # package instead. Masks: jonas-examples # we need the real jonas-examples, because we are *adding* # to it (binaries), without this line, this package would # just *replace* the masked one. Requires: jonas-examples %install install our additional binary stuff here -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From david at zarb.org Thu Sep 15 23:32:29 2005 From: david at zarb.org (David Walluck) Date: Thu, 15 Sep 2005 19:32:29 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050915123735.GC5316@redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> Message-ID: <432A048D.5000608@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > Circular dependencies cannot be avoided for Fedora as a whole because > there are packages which depend upon themselves -- the kernel, gcc, > rpm, etc. This doesn't make any of those packages not free. I agree with everything here. While gcc, the kernel, etc. may be special cases, we may try to avoid circular dependencies with java packages at least. It is not that hard. Most bootstrap packages exist in jpackage already (and hopefully they don't use binary jars). Then a few packages like java-gcj-compat and ant will need to be bootstraped. The biggest problem is the lack of javadoc creation. If javadoc could be part of the core, then a lot of bootstrap issues would go away. Finally, by non-free I am referring to pre-built binary jars, tecnhnically, only ones built with the Sun jdk (though this is only a philosophical issue). Assuming they were built with ecj + libgcj, all the practical issues would still apply. > There's only a couple left in the Fedora JOnAS, but these require > Maven and its 60-70 dependencies that are not yet in Fedora. I'm > swamped with the 80-90 packages I already maintain! I should be > getting help Real Soon Now, but until that happens we'll be stuck > with the binary dependencies (and old package versions, and the > other stuff I don't have time to fix). All, the more reason for jpackage and FC not to diverge. As we know, someone from Red Hat has been working on a free maven, so maybe the update to jonas can eventually happen. >>I believe xalan-j2 also has prebuilt jars in the build > > > It does. I don't believe they are required to build if you just avoid building the docs (which requrie stylebook, I think). Actually, last time I tried to build xalan at all on a free stack it failed, so I will have to look at this again. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKgSNarJDwJ6gwowRAhdDAKCc1hXsOu9Bel8WXqp7v8u2MVmkZwCdF0xr 2ivK6YY8+6pZrAOLoUFcWzw= =QHK1 -----END PGP SIGNATURE----- From david at zarb.org Thu Sep 15 23:38:24 2005 From: david at zarb.org (David Walluck) Date: Thu, 15 Sep 2005 19:38:24 -0400 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <20050915124253.GD5316@redhat.com> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> Message-ID: <432A05F0.7020907@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > David Farning wrote: > >>When running yum install eclips* I got all sorts >>of /usr/bin/rebuild-gcj-db: No such file or directory errors until I >>manually installed java-1.4.2* On Mandriva at least there seems to be a problem with update-alternatives. No matter what I do I cannot get the creation of the /usr/bin/rebuild-gcj-db symlink to happen, even though it is listed as a slave. But I am not sure where the version of update-alternatives comes from if it's not part of rpm. But I guess it is not the same as debian update-alternatives 1.13.11 on Debian looking at the scripts. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKgXvarJDwJ6gwowRAngYAKCTfIclDSO/1BkXyIKaGnaNLX9rkgCgnBmd p0FsQDIuNPfO/i7riialL2U= =hERu -----END PGP SIGNATURE----- From david at zarb.org Thu Sep 15 23:43:10 2005 From: david at zarb.org (David Walluck) Date: Thu, 15 Sep 2005 19:43:10 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <200509151350.43262.vadimn@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <1126801462.22473.21.camel@FC4a.CHD.hubick.com> <20050915165250.GM5316@redhat.com> <200509151350.43262.vadimn@redhat.com> Message-ID: <432A070E.1000306@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vadim Nasardinov wrote: > You may extend the RPM spec file with an optional header like the > following: I thought rpm has something like `Suggests' now, but this won't force a package. Anyway, I think having the only reason for binary java packages be that new users can't figure out how to install them is a pretty bad reason, since you could always force the install somehow (without modifying rpm) by inserting code into yum that matches *jpp* and checks for a native package to install on top of it. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKgcNarJDwJ6gwowRAtPXAJ4twT3SaQVTrjXVceKX0NQHRYF3FACfZpWV 1huAOThmFsTzMy9jg5kBb2A= =X5Uu -----END PGP SIGNATURE----- From vadimn at redhat.com Fri Sep 16 01:55:03 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Thu, 15 Sep 2005 21:55:03 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <432A070E.1000306@zarb.org> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509151350.43262.vadimn@redhat.com> <432A070E.1000306@zarb.org> Message-ID: <200509152155.03933.vadimn@redhat.com> On Thursday 15 September 2005 19:43, David Walluck wrote: > Vadim Nasardinov wrote: > > You may extend the RPM spec file with an optional header ... > you could always force the install somehow (without modifying rpm) > by inserting code into yum that matches *jpp* and checks for a native > package to install on top of it. Even better. From gbenson at redhat.com Fri Sep 16 09:02:55 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 16 Sep 2005 10:02:55 +0100 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <1126805241.7740.15.camel@tortoise.toronto.redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> <1126805241.7740.15.camel@tortoise.toronto.redhat.com> Message-ID: <20050916090253.GB6223@redhat.com> Thomas Fitzsimmons wrote: > Ian Pilcher wrote: > > I believe that there needs to be a clear strategy for the > > co-existence of Fedora gcj packages and JPackage "pure Java" > > packages. The current situation is a mess: > > All we need to do to make this work properly is make sure that the > FC4 packages always have versions >= the corresponding JPackage > versions. Then packages that are in JPackage but not in Fedora will > be provided by JPackage and all other packages will come from > Fedora. > > Our repackaging of JPackages is meant to be 100% compatible with the > source JPackages. If a given package is not compatible then that's > a bug in that package. Otherwise Fedora users should always want > the Fedora versions of the packages. > > In other words, if our Fedora package versions always match or > exceed their JPackage equivalents then there is no problem with > JPackage and Fedora packages co-existing without a clear boundary > between the two repositories. I just don't see this as a problem > at all. Couldn't have said it better myself. The only reason people are starting to get strange mixes of packages is that Fedora has lagged JPackage because there's not presently the manpower to keep them level. Cheers, Gary From gbenson at redhat.com Fri Sep 16 09:20:28 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 16 Sep 2005 10:20:28 +0100 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <432A048D.5000608@zarb.org> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> Message-ID: <20050916092025.GC6223@redhat.com> David Walluck wrote: > Gary Benson wrote: > > Circular dependencies cannot be avoided for Fedora as a whole > > because there are packages which depend upon themselves -- the > > kernel, gcc, rpm, etc. This doesn't make any of those packages > > not free. > > I agree with everything here. While gcc, the kernel, etc. may be > special cases, we may try to avoid circular dependencies with java > packages at least. It is not that hard. Most bootstrap packages > exist in jpackage already (and hopefully they don't use binary > jars). I agree it's not that hard, but it is also not without price. Fedora's bootstrapping was a one-off, and can be forgotten about now it's done. Bootstrap packages, on the other hand, must maintained. This means they must be updated and tested for every new release. They must be shipped, over the network and on CDs. Finally they must be monitored for security vulnerabilities for as long as they exist in a Red Hat supported product. Any package (bootstrap or otherwise) I introduce into Fedora that ends up in the next version of RHEL will have to be monitored until 2013! If you want to bootstrap Fedora yourself can you not simply use the JPackage ant-bootstrap to get it all going? > > There's only a couple left in the Fedora JOnAS, but these require > > Maven and its 60-70 dependencies that are not yet in Fedora. I'm > > swamped with the 80-90 packages I already maintain! I should be > > getting help Real Soon Now, but until that happens we'll be stuck > > with the binary dependencies (and old package versions, and the > > other stuff I don't have time to fix). > > All, the more reason for jpackage and FC not to diverge. As we know, > someone from Red Hat has been working on a free maven, so maybe the > update to jonas can eventually happen. It _will_ happen, don't worry about that :) > > > I believe xalan-j2 also has prebuilt jars in the build > > > > It does. > > I don't believe they are required to build if you just avoid > building the docs (which requrie stylebook, I think). Actually, > last time I tried to build xalan at all on a free stack it failed, > so I will have to look at this again. xalan-j2 was unbuildable in Fedora for a very long time but it should be fixed now. Cheers, Gary From david at zarb.org Fri Sep 16 09:25:59 2005 From: david at zarb.org (David Walluck) Date: Fri, 16 Sep 2005 05:25:59 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <20050916090253.GB6223@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> <1126805241.7740.15.camel@tortoise.toronto.redhat.com> <20050916090253.GB6223@redhat.com> Message-ID: <432A8FA7.8040306@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > Couldn't have said it better myself. The only reason people are > starting to get strange mixes of packages is that Fedora has lagged > JPackage because there's not presently the manpower to keep them > level. There's no guarantee of this and, in fact, it is quite likely that jpackage versions will supercede FC4 versions (except there isn't much jpackage manpower right now, either). That is, unless you were to bump the epoch on every FC4 package as was done with eclipse (why the special case here I am not sure). On the other hand, people want more compatibility. And I want less (ideally no) duplication. So I would again ask for some policy that separates native libs from the jars. Or at least maybe someone is willing to put some real thought into it rather than dismissing it outright. By the way, I say this having fallen victim to the exact same practices myself, where I have made patches and even full version updates to several packages and just have had no time to push these changes back to jpackage.org. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKo+narJDwJ6gwowRAm/AAKCjz+hCPu04qQW1p9n/sajHOpnIKQCfSTCi sZyoWmiY0ga10MxKOSEI3l8= =LqHO -----END PGP SIGNATURE----- From david at zarb.org Fri Sep 16 09:29:11 2005 From: david at zarb.org (David Walluck) Date: Fri, 16 Sep 2005 05:29:11 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050916092025.GC6223@redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> Message-ID: <432A9067.3000006@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > xalan-j2 was unbuildable in Fedora for a very long time but it should > be fixed now. Do you have more specifics on what the bugs were and where they were fixed? I am using a custom setup here (say, a different version of gcc, or whatever) so I can't be guaranteed to have the fixes, nor do I know where or how to track these fixes when they occurred. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKpBnarJDwJ6gwowRAoQpAJ4u85L0rBKYKhW1a5OTXVt0Lb0pcgCePybm kxyLaWyM5M3Tyu8ljBVFBkg= =6AxP -----END PGP SIGNATURE----- From gbenson at redhat.com Fri Sep 16 09:40:14 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 16 Sep 2005 10:40:14 +0100 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <432A9067.3000006@zarb.org> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> Message-ID: <20050916094011.GE6223@redhat.com> David Walluck wrote: > Gary Benson wrote: > > xalan-j2 was unbuildable in Fedora for a very long time but it > > should be fixed now. > > Do you have more specifics on what the bugs were and where they were > fixed? I am using a custom setup here (say, a different version of > gcc, or whatever) so I can't be guaranteed to have the fixes, nor do > I know where or how to track these fixes when they occurred. The visible face of the problem is that it uses libgcj's xml classes rather than those in xml-commons-apis. libgcj's are newer and contain more interface definitions, so I needed to add stubs in xalan-j2. These are in xalan-j2-bz152255.patch in Fedora xalan-j2. The core of the problem is that there is a bunch of packages which builds using xml-commons-apis, but when you use libgcj only a small minority actually see xml-commons-apis whereas the rest see libgcj's XML classes. I have no idea why. Cheers, Gary From david at zarb.org Fri Sep 16 09:45:12 2005 From: david at zarb.org (David Walluck) Date: Fri, 16 Sep 2005 05:45:12 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050916094011.GE6223@redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> <20050916094011.GE6223@redhat.com> Message-ID: <432A9428.1010909@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > The core of the problem is that there is a bunch of packages which > builds using xml-commons-apis, but when you use libgcj only a small > minority actually see xml-commons-apis whereas the rest see libgcj's > XML classes. I have no idea why. The only thing I can think of is classpath ordering (depends on how the classpath is defined in build.xml). To override internal classes I thought (for Sun at least) you needed to use -bootclasspath, but this doesn't seem always to be the case either. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKpQoarJDwJ6gwowRAtgVAJ9xlbO3U/QkahgFXzzvZ0NPXPet3QCgpvrx rl5+eBay3TQEz79FB4gq8BQ= =ii8d -----END PGP SIGNATURE----- From gbenson at redhat.com Fri Sep 16 09:57:26 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 16 Sep 2005 10:57:26 +0100 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <432A8FA7.8040306@zarb.org> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <1126805241.7740.15.camel@tortoise.toronto.redhat.com> <20050916090253.GB6223@redhat.com> <432A8FA7.8040306@zarb.org> Message-ID: <20050916095723.GF6223@redhat.com> David Walluck wrote: > On the other hand, people want more compatibility. And I want less > (ideally no) duplication. So I would again ask for some policy that > separates native libs from the jars. Or at least maybe someone is > willing to put some real thought into it rather than dismissing it > outright. Before fedora-devel-java-list was set up we had precisely this discussion internally, several times as it happens ;) If I answer you quickly it's not because I'm dismissing it but rather that I've already thought long and hard about it beforehand. I've been trying to dig out the discussion all morning, but I keep getting sidetracked with email. So, if you'll bear with me a few moments longer... Cheers, Gary From aph at redhat.com Fri Sep 16 10:05:34 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 16 Sep 2005 11:05:34 +0100 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <432A8FA7.8040306@zarb.org> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> <1126805241.7740.15.camel@tortoise.toronto.redhat.com> <20050916090253.GB6223@redhat.com> <432A8FA7.8040306@zarb.org> Message-ID: <17194.39150.523644.323610@zapata.pink> David Walluck writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gary Benson wrote: > > Couldn't have said it better myself. The only reason people are > > starting to get strange mixes of packages is that Fedora has lagged > > JPackage because there's not presently the manpower to keep them > > level. > > There's no guarantee of this and, in fact, it is quite likely that > jpackage versions will supercede FC4 versions (except there isn't > much jpackage manpower right now, either). That is, unless you were > to bump the epoch on every FC4 package as was done with eclipse > (why the special case here I am not sure). > > On the other hand, people want more compatibility. And I want less > (ideally no) duplication. So I would again ask for some policy that > separates native libs from the jars. Or at least maybe someone is > willing to put some real thought into it rather than dismissing it > outright. No-one is doing that. A great deal of real thought has been put into this issue, and will continue to be. Andrew. From gbenson at redhat.com Fri Sep 16 11:24:54 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 16 Sep 2005 12:24:54 +0100 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <20050916095723.GF6223@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <1126805241.7740.15.camel@tortoise.toronto.redhat.com> <20050916090253.GB6223@redhat.com> <432A8FA7.8040306@zarb.org> <20050916095723.GF6223@redhat.com> Message-ID: <20050916112452.GA6684@redhat.com> Gary Benson wrote: > David Walluck wrote: > > On the other hand, people want more compatibility. And I want less > > (ideally no) duplication. So I would again ask for some policy that > > separates native libs from the jars. Or at least maybe someone is > > willing to put some real thought into it rather than dismissing it > > outright. > > Before fedora-devel-java-list was set up we had precisely this > discussion internally, several times as it happens ;) If I answer > you quickly it's not because I'm dismissing it but rather that I've > already thought long and hard about it beforehand. > > I've been trying to dig out the discussion all morning, but I keep > getting sidetracked with email. So, if you'll bear with me a few > moments longer... Well, I'd forgotton just how much was said about it, but a brief summary is that there were three methods proposed: 1. Native code in the same rpms as the bytecode. 2. Native code in separate rpms to the bytecode. 3. Native code generated on user's machine. Method 3, which hasn't been mentioned on this list, involved either %post scriptlets or some kind of background job like slocate has. It's main drawbacks were that native compilation is a hugely computationally intensive process, particularly with aggressive inter-class optimizations. Many target machines simply wouldn't have the RAM to do the job. Even were this not the case, it can frequently take hours, too long for a %post scriptlet, and using a background job would mean that there'd be periods when your native code was not in sync and your Java apps would run slowly. Method 2, which is what you're proposing, has the following drawbacks over Method 1: - There is no way at present to make rpm (yum, up2date, anaconda...) associate the native packages with the bytecode ones. Users would have to manually install them in the first instance. - Installed native packages must Require their bytecode equivalents. Users could not upgrade a Fedora package with a JPackage one without manually uninstalling the native package first. - The native package would not have access to the sources, and would not be able to generate a useful debuginfo package. This would render the packages undebuggable with gdb. - There's no obvious way to automate the generation of the native packages. This causes the packagecount to more than double, and the non-atomic nature of it allows things to get out of sync and, for example, break rawhide. But all this is somewhat tangential to the original point, which was that "[if] the JPackage repos are added to a FC4 yum configuration, yum will try to overwrite [Fedora] packages with [JPackage] packages..." Allowing the Fedora stack to be extended with JPackage packages was and is a key requirement. There's only one way I can see that would prevent the former while still allowing the latter, and that's for Fedora's packages to have the same EVR as the JPackage packages. Since that is something we cannot commit to, the problem will remain regardless of where the native code is packaged. Gary From overholt at redhat.com Fri Sep 16 14:04:08 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 16 Sep 2005 10:04:08 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <432A8FA7.8040306@zarb.org> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050915135642.GG5316@redhat.com> <1126805241.7740.15.camel@tortoise.toronto.redhat.com> <20050916090253.GB6223@redhat.com> <432A8FA7.8040306@zarb.org> Message-ID: <20050916140408.GA13231@redhat.com> * David Walluck [2005-09-16 05:26]: > That is, unless you were to bump the epoch on every FC4 package as was > done with eclipse (why the special case here I am not sure). This was totally unrelated and was because we had decided to ship 3.0.2 in FC4 at one point after having 3.1Mx in rawhide. We had to bump the epoch to go back. Then we decided to go with 3.1 in the end. Stupid? Yes. Andrew From green at redhat.com Fri Sep 16 14:19:27 2005 From: green at redhat.com (Anthony Green) Date: Fri, 16 Sep 2005 07:19:27 -0700 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050916094011.GE6223@redhat.com> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> <20050916094011.GE6223@redhat.com> Message-ID: <1126880368.3075.23.camel@localhost.localdomain> On Fri, 2005-09-16 at 10:40 +0100, Gary Benson wrote: > The core of the problem is that there is a bunch of packages which > builds using xml-commons-apis, but when you use libgcj only a small > minority actually see xml-commons-apis whereas the rest see libgcj's > XML classes. I have no idea why. I think it's a bug in the Eclipse compiler. https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg00172.html https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617 AG From gbenson at redhat.com Fri Sep 16 14:28:55 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 16 Sep 2005 15:28:55 +0100 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <1126880368.3075.23.camel@localhost.localdomain> References: <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> <20050916094011.GE6223@redhat.com> <1126880368.3075.23.camel@localhost.localdomain> Message-ID: <20050916142852.GB6684@redhat.com> Anthony Green wrote: > On Fri, 2005-09-16 at 10:40 +0100, Gary Benson wrote: > > The core of the problem is that there is a bunch of packages which > > builds using xml-commons-apis, but when you use libgcj only a > > small minority actually see xml-commons-apis whereas the rest see > > libgcj's XML classes. I have no idea why. > > I think it's a bug in the Eclipse compiler. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617 Oh, cool. I copied myself on that, and I'll see if if fixes it when it's fixed. Cheers, Gary From green at redhat.com Fri Sep 16 14:37:14 2005 From: green at redhat.com (Anthony Green) Date: Fri, 16 Sep 2005 07:37:14 -0700 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050916142852.GB6684@redhat.com> References: <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> <20050916094011.GE6223@redhat.com> <1126880368.3075.23.camel@localhost.localdomain> <20050916142852.GB6684@redhat.com> Message-ID: <1126881434.3075.29.camel@localhost.localdomain> On Fri, 2005-09-16 at 15:28 +0100, Gary Benson wrote: > Oh, cool. I copied myself on that, and I'll see if if fixes it when > it's fixed. That patch in my email definitely fixes the problem. But I think there are other hidden problems in Eclipse's classpath ordering that fitzsim wanted to fix. I forget what the current status of this bug is. AG From fitzsim at redhat.com Fri Sep 16 14:41:31 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 16 Sep 2005 10:41:31 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <1126880368.3075.23.camel@localhost.localdomain> References: <1126459563.3035.31.camel@localhost.localdomain> <1126635326.3035.186.camel@localhost.localdomain> <20050914090737.GA5130@redhat.com> <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> <20050916094011.GE6223@redhat.com> <1126880368.3075.23.camel@localhost.localdomain> Message-ID: <1126881691.12502.10.camel@rh-ibm-t41> (CCing overholt) On Fri, 2005-09-16 at 07:19 -0700, Anthony Green wrote: > On Fri, 2005-09-16 at 10:40 +0100, Gary Benson wrote: > > The core of the problem is that there is a bunch of packages which > > builds using xml-commons-apis, but when you use libgcj only a small > > minority actually see xml-commons-apis whereas the rest see libgcj's > > XML classes. I have no idea why. > > I think it's a bug in the Eclipse compiler. > > https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg00172.html > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617 Andrew, can you add this patch to the next eclipse-ecj build? Thanks, Tom From overholt at redhat.com Fri Sep 16 14:48:56 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 16 Sep 2005 10:48:56 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <1126881691.12502.10.camel@rh-ibm-t41> References: <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> <20050916094011.GE6223@redhat.com> <1126880368.3075.23.camel@localhost.localdomain> <1126881691.12502.10.camel@rh-ibm-t41> Message-ID: <20050916144856.GE13231@redhat.com> * Thomas Fitzsimmons [2005-09-16 10:45]: > > > > I think it's a bug in the Eclipse compiler. > > > > https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg00172.html > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617 > > Andrew, can you add this patch to the next eclipse-ecj build? Of course. I can't build eclipse ATM, though, until Bryce's patch for gcc #23891 gets into a rawhide gcc. We should also discuss this with the JDT core guys. Andrew From fitzsim at redhat.com Fri Sep 16 14:54:37 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 16 Sep 2005 10:54:37 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050916144856.GE13231@redhat.com> References: <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> <20050916094011.GE6223@redhat.com> <1126880368.3075.23.camel@localhost.localdomain> <1126881691.12502.10.camel@rh-ibm-t41> <20050916144856.GE13231@redhat.com> Message-ID: <1126882477.12502.14.camel@rh-ibm-t41> On Fri, 2005-09-16 at 10:48 -0400, Andrew Overholt wrote: > * Thomas Fitzsimmons [2005-09-16 10:45]: > > > > > > I think it's a bug in the Eclipse compiler. > > > > > > https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg00172.html > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617 > > > > Andrew, can you add this patch to the next eclipse-ecj build? > > Of course. I can't build eclipse ATM, though, until Bryce's patch for > gcc #23891 gets into a rawhide gcc. We should also discuss this with the > JDT core guys. Not yet; we're not sure how it's supposed to work yet. After I formalize my tests we can start talking about this upstream. Tom From fitzsim at redhat.com Fri Sep 16 15:20:34 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 16 Sep 2005 11:20:34 -0400 Subject: [fedora-java] Re: Fedora Core 5 Wishlist In-Reply-To: <20050916112452.GA6684@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <1126805241.7740.15.camel@tortoise.toronto.redhat.com> <20050916090253.GB6223@redhat.com> <432A8FA7.8040306@zarb.org> <20050916095723.GF6223@redhat.com> <20050916112452.GA6684@redhat.com> Message-ID: <1126884034.12502.31.camel@rh-ibm-t41> On Fri, 2005-09-16 at 12:24 +0100, Gary Benson wrote: > Gary Benson wrote: > But all this is somewhat tangential to the original point, which was > that "[if] the JPackage repos are added to a FC4 yum configuration, > yum will try to overwrite [Fedora] packages with [JPackage] > packages..." Allowing the Fedora stack to be extended with JPackage > packages was and is a key requirement. There's only one way I can see > that would prevent the former while still allowing the latter, and > that's for Fedora's packages to have the same EVR as the JPackage > packages. Since that is something we cannot commit to, the problem > will remain regardless of where the native code is packaged. I'm starting to think we shouldn't support Fedora Core/JPackage pull arrangements, only Rawhide/JPackage arrangements. Fedora Core and JPackage are on different release cycles; FC tends to have "releases" whereas JPackages are continually updated individually. I think each project's release strategy makes sense for it but the two strategies are incompatible. Without FC/JPackage setups where will people get packages that are in JPackage but not in FC? I'm wondering if a JPackage -> Fedora Extras bridge is in order. Right before a Fedora release we'd do a drop from JPackage to Extras of all packages not in Core. That way FE would be a snapshot of JPackage at FC release time. That would insulate FC users from JPackage churn, while Rawhide users could continue using JPackage directly. Tom From vadimn at redhat.com Fri Sep 16 16:48:02 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 16 Sep 2005 12:48:02 -0400 Subject: raising Yum's IQ (was: Re: [fedora-java] Re: Fedora Core 5 Wishlist) In-Reply-To: <20050916112452.GA6684@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050916095723.GF6223@redhat.com> <20050916112452.GA6684@redhat.com> Message-ID: <200509161248.02384.vadimn@redhat.com> On Friday 16 September 2005 07:24, Gary Benson wrote: > a brief summary is that there were three methods proposed: > > 1. Native code in the same rpms as the bytecode. > 2. Native code in separate rpms to the bytecode. > 3. Native code generated on user's machine. > > Method 2, which is what you're proposing, has the following > drawbacks over Method 1: > > - There is no way at present to make rpm (yum, up2date, > anaconda...) associate the native packages with the bytecode > ones. Users would have to manually install them in the first > instance. Yum can be changed to have a way to associate the native packages with the bytecode ones. > - Installed native packages must Require their bytecode > equivalents. Users could not upgrade a Fedora package with a > JPackage one without manually uninstalling the native package > first. Yum can be changed to handle this. > - The native package would not have access to the sources, and > would not be able to generate a useful debuginfo package. This > would render the packages undebuggable with gdb. Can you elaborate? I thought native compilation worked by taking .class files as input. Where do the sources come in? Secondly, why can't you build native packages from the same SRPM that the binary non-native RPMs were built from? I don't believe this has been discussed on this list in sufficient detail. > - There's no obvious way to automate the generation of the native > packages. This causes the packagecount to more than double, and > the non-atomic nature of it allows things to get out of sync and, > for example, break rawhide. IIRC, David suggested repeatedly that JPackage would be more than happy to accept .spec files where native compilation logic was present conditionally and was off by default. I seem to recall vaguely this suggestion getting dismissed as impractical but don't remember any detailed explanation of why this may not be feasible. The bottom line is, although the current situation is the best solution we could think of, it is not a good solution. The fact of the matter remains that Fedora and JPackage repositories don't mesh very well at this time. In view of this, why don't we explore the option of adding explicit knowledge of the Java packaging situation to Yum? If this turns out to be a dead-end, fine. At the very least, we will have explained, in a public forum, why smarter Yum is not the answer. From aph at redhat.com Fri Sep 16 16:52:40 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 16 Sep 2005 17:52:40 +0100 Subject: raising Yum's IQ (was: Re: [fedora-java] Re: Fedora Core 5 Wishlist) In-Reply-To: <200509161248.02384.vadimn@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050916095723.GF6223@redhat.com> <20050916112452.GA6684@redhat.com> <200509161248.02384.vadimn@redhat.com> Message-ID: <17194.63576.872323.690549@zapata.pink> Vadim Nasardinov writes: > > > - The native package would not have access to the sources, and > > would not be able to generate a useful debuginfo package. This > > would render the packages undebuggable with gdb. > > Can you elaborate? I thought native compilation worked by taking > .class files as input. Where do the sources come in? You don't debug bytecode: you debug source. Debuginfo contains source. Andrew. From vadimn at redhat.com Fri Sep 16 17:07:53 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 16 Sep 2005 13:07:53 -0400 Subject: raising Yum's IQ (was: Re: [fedora-java] Re: Fedora Core 5 Wishlist) In-Reply-To: <17194.63576.872323.690549@zapata.pink> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509161248.02384.vadimn@redhat.com> <17194.63576.872323.690549@zapata.pink> Message-ID: <200509161307.53973.vadimn@redhat.com> On Friday 16 September 2005 12:52, Andrew Haley wrote: > Vadim Nasardinov writes: > > On Friday 16 September 2005 07:24, Gary Benson wrote: > > > a brief summary: > > > > > > 1. Native code in the same rpms as the bytecode. > > > 2. Native code in separate rpms to the bytecode. > > ... > > > Method 2, which is what you're proposing, has the following > > > drawbacks over Method 1: > > ... > > > - The native package would not have access to the sources, and > > > would not be able to generate a useful debuginfo package. > > > This would render the packages undebuggable with gdb. > > > > Can you elaborate? I thought native compilation worked by taking > > .class files as input. Where do the sources come in? > > You don't debug bytecode: you debug source. Debuginfo contains > source. The part I didn't understand was how specifically Method 2 would prevent you from generating appropriate debuginfo packages. I think the source of my confusion was that I misintepreted Gary's definition of "Method 2". I was thinking along the lines of David Walluck's long-standing proposal (I hope I'm not putting words in his mouth) to share exact same .spec files between Fedora and JPackage but have native-compilation-related spec logic conditionalized. I am a little fuzzy on why sharing exact same .spec files (modulo minor distro-specific patches) is infeasible. Even with Gary's definition of Method 2 (call it M2), it's not clear to me why debuginfo packages are impossible to generate. (I think M2 amounts effectively to having two SRPMs for the same application). From overholt at redhat.com Fri Sep 16 17:56:33 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 16 Sep 2005 13:56:33 -0400 Subject: raising Yum's IQ (was: Re: [fedora-java] Re: Fedora Core 5 Wishlist) In-Reply-To: <200509161307.53973.vadimn@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509161248.02384.vadimn@redhat.com> <17194.63576.872323.690549@zapata.pink> <200509161307.53973.vadimn@redhat.com> Message-ID: <20050916175633.GH13231@redhat.com> * Vadim Nasardinov [2005-09-16 13:07]: > I am a little fuzzy on why sharing exact same .spec files (modulo > minor distro-specific patches) is infeasible. I have been out of the loop WRT Eclipse 3.1 packaging for a bit, but I fully plan on sharing everything we possibly can between JPackage and FC Eclipse .spec files. I don't know how well this will work for other packages, but I've already conditionalized most (if not all) of the gcj-specific stuff in the Eclipse .spec file. I never got the chance to work with David and/or others to get our work into the JPackage .spec, but I think David managed to extract most of the stuff that he could/wanted to. Andrew "speaking only for myself" Overholt From david at zarb.org Fri Sep 16 18:52:38 2005 From: david at zarb.org (David Walluck) Date: Fri, 16 Sep 2005 14:52:38 -0400 Subject: [fedora-java] Improving Fedora javadoc In-Reply-To: <20050916144856.GE13231@redhat.com> References: <1126733931.9822.7.camel@tortoise.toronto.redhat.com> <20050915084241.GB5316@redhat.com> <4329428A.1030006@zarb.org> <20050915123735.GC5316@redhat.com> <432A048D.5000608@zarb.org> <20050916092025.GC6223@redhat.com> <432A9067.3000006@zarb.org> <20050916094011.GE6223@redhat.com> <1126880368.3075.23.camel@localhost.localdomain> <1126881691.12502.10.camel@rh-ibm-t41> <20050916144856.GE13231@redhat.com> Message-ID: <432B1476.6020600@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Overholt wrote: > Of course. I can't build eclipse ATM, though, until Bryce's patch for > gcc #23891 gets into a rawhide gcc. We should also discuss this with the > JDT core guys. I fell victim to this bug too. There are two workarounds right now that I found. The first is that ecj.jar doesn't really need to be built in eclipse since the same exact version is already built in the standalone ecj rpm (of course this required gcc at one point). One might wonder why compilation is being done a second time instead of using BuildRequires: eclipse-ecj (not circular if ecj provides eclipse-ecj also). The second is to use the standalone ecj compiler (instead of gcj) to build ecj.jar. The jikes compiler could also be used successfully here. Right now jikes is only in FE, not core, though. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKxR2arJDwJ6gwowRAmjxAKCJxAj/484vTJWA51VHCuRNvAxgDgCgqXQN qep/vLcJ+EM31EhrkAtfUTA= =vEKJ -----END PGP SIGNATURE----- From david at zarb.org Fri Sep 16 19:19:50 2005 From: david at zarb.org (David Walluck) Date: Fri, 16 Sep 2005 15:19:50 -0400 Subject: [fedora-java] Re: raising Yum's IQ In-Reply-To: <200509161307.53973.vadimn@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509161248.02384.vadimn@redhat.com> <17194.63576.872323.690549@zapata.pink> <200509161307.53973.vadimn@redhat.com> Message-ID: <432B1AD6.5030406@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vadim Nasardinov wrote: > I am a little fuzzy on why sharing exact same .spec files (modulo > minor distro-specific patches) is infeasible. I think it was at my behest that gcj_support was added to some spec files. Anyway, the good news is that I have actually gone and taken a lot (if not all!) FC spec files and added `%if %{gcj_support}' in the appropriate places. I just have been strapped for time so I haven't done much of anything with these packages. Similarly, I really have very few additions I would like to add to eclipse (wrt jpackage), I just haven't had time to do it. So I don't blame Fedora here at all, but myself, since I've actually already done this work and just can't seem to find the time to do the last step. Also, I obviously am not here to dictate Fedora policy, and we know that without Fedora, the eclipse 3.1 work may never have gotten done. The only thing I am in favor of, though, is a policy that might integrate better cross-distro and/or avoids duplication of work (since I am sure we all don't have the extra time). In the end, I would prefer two separate spec files for each. It is actually possible to do something with the rpm build scripts to perhaps generate such a package 100% automatically (just as debuginfo packages can be automatically generated now). The inability of rpm to have a noarch subpackage of an arch package prevents what I'd call a near-ideal solution. Already we have aot-compile-rpm in the rpm build scripts but it's not being used. But I think this is a step in the right direction. Perhaps a second rpmbuild process could be launched on the automatically generated native spec file from the non-native build. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKxrVarJDwJ6gwowRAiKYAJwNAtjiMeg4NHLRthx0aLvBSAxN5gCgnvZi 7ZrTPKKAjQIZSP8JkNm4yHI= =sxNz -----END PGP SIGNATURE----- From chris at hubick.com Fri Sep 16 20:27:53 2005 From: chris at hubick.com (Chris Hubick) Date: Fri, 16 Sep 2005 14:27:53 -0600 Subject: [fedora-java] Re: raising Yum's IQ In-Reply-To: <432B1AD6.5030406@zarb.org> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509161248.02384.vadimn@redhat.com> <17194.63576.872323.690549@zapata.pink> <200509161307.53973.vadimn@redhat.com> <432B1AD6.5030406@zarb.org> Message-ID: <1126902473.3606.18.camel@FC4a.CHD.hubick.com> On Fri, 2005-09-16 at 15:19 -0400, David Walluck wrote: > Vadim Nasardinov wrote: > > I am a little fuzzy on why sharing exact same .spec files (modulo > > minor distro-specific patches) is infeasible. > > Anyway, the good news is that I have actually gone and taken a > lot (if not all!) FC spec files and added `%if %{gcj_support}' in the > appropriate places. When I read that, my first thought is: It would be nice if the macro's used in JPP packages were generic/abstract enough that they didn't need to mention GCJ at all, and that the definitions of the 'compilation' macro could be modified to include doing .so builds in addition to the class files on platforms with GCJ... Then I start to realize that it would probably need to be wedged into the Ant build file called by the macro. Then I start to think it would be nice if the Ant targets were generic enough to be able to do this abstraction... Then I realize to make this really work in an abstracted platform independent fashion, we should all just use Maven for our projects, and let the target platform sort out how to get that stuff distributed and installed. -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From david at zarb.org Fri Sep 16 21:04:29 2005 From: david at zarb.org (David Walluck) Date: Fri, 16 Sep 2005 17:04:29 -0400 Subject: [fedora-java] Re: raising Yum's IQ In-Reply-To: <1126902473.3606.18.camel@FC4a.CHD.hubick.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509161248.02384.vadimn@redhat.com> <17194.63576.872323.690549@zapata.pink> <200509161307.53973.vadimn@redhat.com> <432B1AD6.5030406@zarb.org> <1126902473.3606.18.camel@FC4a.CHD.hubick.com> Message-ID: <432B335D.3060007@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Hubick wrote: > When I read that, my first thought is: It would be nice if the macro's > used in JPP packages were generic/abstract enough that they didn't need > to mention GCJ at all, and that the definitions of the 'compilation' > macro could be modified to include doing .so builds in addition to the > class files on platforms with GCJ... It mentions gcj because it's for gcj only. And gcj could be autodetected by a macro too %(test -x %{_bindir}/gcj...). Remember that any jpackage.org build server is also a platform with native binaries, and probably has gcj installed. The existence of the gcj binary doesn't imply someone necessarily wants native packages. > Then I start to realize that it would probably need to be wedged into > the Ant build file called by the macro. Then I start to think it would > be nice if the Ant targets were generic enough to be able to do this > abstraction... Anthony Green has written gcjlib, but it is cumbersome to have to patch every single build.xml, which is why a script that does the same thing is generally preferred. But for upstream projects, it might make sense for them to adopt gcjlib. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDKzNdarJDwJ6gwowRAs1TAJwLfSy85/D677AE5H1CUdLxHBeWugCffKBa acnPAK10RTTboaIjOXzwPKY= =EZp6 -----END PGP SIGNATURE----- From chris at hubick.com Fri Sep 16 21:48:23 2005 From: chris at hubick.com (Chris Hubick) Date: Fri, 16 Sep 2005 15:48:23 -0600 Subject: [fedora-java] Maven (was Re: raising Yum's IQ) In-Reply-To: <432B335D.3060007@zarb.org> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509161248.02384.vadimn@redhat.com> <17194.63576.872323.690549@zapata.pink> <200509161307.53973.vadimn@redhat.com> <432B1AD6.5030406@zarb.org> <1126902473.3606.18.camel@FC4a.CHD.hubick.com> <432B335D.3060007@zarb.org> Message-ID: <1126907303.3606.56.camel@FC4a.CHD.hubick.com> On Fri, 2005-09-16 at 17:04 -0400, David Walluck wrote: > Anthony Green has written gcjlib, but it is cumbersome to have to patch > every single build.xml, which is why a script that does the same thing > is generally preferred. But for upstream projects, it might make sense > for them to adopt gcjlib. It's cumbersome to have to patch build.xml files. It's cumbersome to write and maintain spec files for hundreds of applications, especially if there ended up having to be one 'generic' JPP one, and one FC specific one. Upstream Java developers shouldn't have to worry about RPM spec files, deb files, GCJ libs, Windows installers, BeOS thingamajigs, etc. When I moved my Java project from Windows using Sun's tools, to Fedora and GCJ, my Ant build.xml file Just Worked. That layer of insulation meant I didnt' have to learn about GCJ command line options to compile my code. This type of abstraction needs to be taken to the next level. Ideally, everyone just writes platform independent Java code, and fills out some platform agnostic thing to describe their application, it's version, dependencies, etc - all in a declarative fashion. Everything else from that point on through to end user deployment should be fully automated by a mix of generic and platform specific tools. I think Maven's project.xml is a good start to supply exactly that. There should be tools/plugins/whatever, to turn a project.xml file into an RPM suitable for Fedora, or a .deb for Debian, etc. And if project.xml doesn't supply all the information needed to make this work, maybe we should help fix that. Instead of JPP creating spec files, they could write a project.xml file for everything. Then as the mechanisms get worked out, you just upgrade and maintain the tool chain. Constantly futzing around tweaking code in hundreds of hand written spec files seems silly to me. -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From david at zarb.org Sat Sep 17 20:04:22 2005 From: david at zarb.org (David Walluck) Date: Sat, 17 Sep 2005 16:04:22 -0400 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <1126805365.7740.17.camel@tortoise.toronto.redhat.com> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> <1126792389.6381.20.camel@localhost.localdomain> <20050915141251.GH5316@redhat.com> <1126795910.6381.42.camel@localhost.localdomain> <1126805365.7740.17.camel@tortoise.toronto.redhat.com> Message-ID: <432C76C6.2080009@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: >>The post and postun problems I am having seem to be because >> /usr/bin/rebuild-gcj-db can not be found during post and postun. If >>Requires: java-gcj-compat >= 1.0.31 is used, whenever >> the post or postun is taking place, rebuild-gcj-db will be present. > > > I just changed rebuild-gcj-db to be an alternative symlink. Therefore > RPM wouldn't know about it. Might that be the problem? Is it even correct to have rebuild-gcj-db as an alternative? This file must exist always (even when not running gcj). Since the link is a slave to java, if the java alternative is changed (say, to a Sun 1.5.0 jvm), then I assume that this link will get lost? Or is that not true since gcj is the only one providing it? In any case, I have a similar problem of this link not being set up. And maybe since the Requires(post) is on the java-gcj-compat package and not %{_bindir}/rebuild-gcj-db itself, maybe rpm is not catching it. Also, I think there's a packaging problem with java-gcj-compat not owning a lot of symlinks it creates. As I understand it, we can't own alternatives symlinks since this can cause conflicts between packages (yet why does rpm allow multiple owners of directories?). But there are other links created in post that probably could be %ghost'ed (the internal ones which link to libgcj.jar). - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDLHbGarJDwJ6gwowRAvyFAJ9M0hMCeZhpJctZg0akH41l1DSYWACgjia4 cFZLy/c/1Om2Vf2CQf4J8gE= =oVme -----END PGP SIGNATURE----- From fitzsim at redhat.com Mon Sep 19 01:49:25 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 18 Sep 2005 21:49:25 -0400 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <432C76C6.2080009@zarb.org> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> <1126792389.6381.20.camel@localhost.localdomain> <20050915141251.GH5316@redhat.com> <1126795910.6381.42.camel@localhost.localdomain> <1126805365.7740.17.camel@tortoise.toronto.redhat.com> <432C76C6.2080009@zarb.org> Message-ID: <1127094565.27818.11.camel@rh-ibm-t41> On Sat, 2005-09-17 at 16:04 -0400, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thomas Fitzsimmons wrote: > > >>The post and postun problems I am having seem to be because > >> /usr/bin/rebuild-gcj-db can not be found during post and postun. If > >>Requires: java-gcj-compat >= 1.0.31 is used, whenever > >> the post or postun is taking place, rebuild-gcj-db will be present. > > > > > > I just changed rebuild-gcj-db to be an alternative symlink. Therefore > > RPM wouldn't know about it. Might that be the problem? > > Is it even correct to have rebuild-gcj-db as an alternative? This file > must exist always (even when not running gcj). Since the link is a slave > to java, if the java alternative is changed (say, to a Sun 1.5.0 jvm), > then I assume that this link will get lost? Or is that not true since > gcj is the only one providing it? > > In any case, I have a similar problem of this link not being set up. And > maybe since the Requires(post) is on the java-gcj-compat package and not > %{_bindir}/rebuild-gcj-db itself, maybe rpm is not catching it. I made rebuild-gcj-db an alternative for two reasons. One, so that two java-gcj-compats could be installed in parallel and two because rebuild- gcj-db references gcj-dbtool which is different for different gcj installations (gcj-dbtool, gcj-dbtool4). The same arguments apply to aot-compile-rpm. You raise good points for why this isn't workable. One potential solution is to only include these scripts in the "system default" java- gcj-compat, since there will presumably only be one system-wide gcj database on which aot-compile-rpm and rebuild-gcj-db should operate. I'll fix this soon. > > Also, I think there's a packaging problem with java-gcj-compat not > owning a lot of symlinks it creates. As I understand it, we can't own > alternatives symlinks since this can cause conflicts between packages > (yet why does rpm allow multiple owners of directories?). But there are > other links created in post that probably could be %ghost'ed (the > internal ones which link to libgcj.jar). Yes, also a good point; I'll fix this too. Thanks for the feedback, Tom From david at zarb.org Mon Sep 19 02:23:45 2005 From: david at zarb.org (David Walluck) Date: Sun, 18 Sep 2005 22:23:45 -0400 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <1127094565.27818.11.camel@rh-ibm-t41> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> <1126792389.6381.20.camel@localhost.localdomain> <20050915141251.GH5316@redhat.com> <1126795910.6381.42.camel@localhost.localdomain> <1126805365.7740.17.camel@tortoise.toronto.redhat.com> <432C76C6.2080009@zarb.org> <1127094565.27818.11.camel@rh-ibm-t41> Message-ID: <432E2131.6040905@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > You raise good points for why this isn't workable. One potential > solution is to only include these scripts in the "system default" java- > gcj-compat, since there will presumably only be one system-wide gcj > database on which aot-compile-rpm and rebuild-gcj-db should operate. > I'll fix this soon. Right. You could leave the files out when %custom is defined (or whatever the define is for gcjHEAD). But then gcjHEAD-compat will require gcj-compat (not a big deal, but then you could also relegate the common (shared) scripts to a common subpackage). If it turns out that two separate scripts are required, these common scripts will be able to handle callling them as well. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDLiEwarJDwJ6gwowRAuwEAJ44xKNgXyBXA86kyz+XeUwZok+LgACcCqg8 S/9n9ALrAOtnzoz3NTXgXFA= =jhJ2 -----END PGP SIGNATURE----- From gbenson at redhat.com Mon Sep 19 09:14:07 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 19 Sep 2005 10:14:07 +0100 Subject: raising Yum's IQ (was: Re: [fedora-java] Re: Fedora Core 5 Wishlist) In-Reply-To: <200509161248.02384.vadimn@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050916095723.GF6223@redhat.com> <20050916112452.GA6684@redhat.com> <200509161248.02384.vadimn@redhat.com> Message-ID: <20050919091403.GA12591@redhat.com> Vadim Nasardinov wrote: > The bottom line is, although the current situation is the best > solution we could think of, it is not a good solution. The fact > of the matter remains that Fedora and JPackage repositories don't > mesh very well at this time. Placing the native code in separate rpms will not solve this because the problem is not that Fedora rpms contain native code and JPackage ones do not. The problem is that Fedora and JPackage rpms share the same namespace. Ximian had problems with this five years ago, before they were even called Ximian. What is really needed is for some way to tell yum to ignore packages in jpackage.repo that exist already in fedora.repo. I doubt it's that simple though. Cheers, Gary From david at zarb.org Mon Sep 19 10:22:31 2005 From: david at zarb.org (David Walluck) Date: Mon, 19 Sep 2005 06:22:31 -0400 Subject: [fedora-java] Re: raising Yum's IQ In-Reply-To: <20050919091403.GA12591@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050916095723.GF6223@redhat.com> <20050916112452.GA6684@redhat.com> <200509161248.02384.vadimn@redhat.com> <20050919091403.GA12591@redhat.com> Message-ID: <432E9167.8090109@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > ones do not. The problem is that Fedora and JPackage rpms share the > same namespace. Ximian had problems with this five years ago, before > they were even called Ximian. What is really needed is for some way > to tell yum to ignore packages in jpackage.repo that exist already in > fedora.repo. I doubt it's that simple though. But FC4 was said to be ``100% JPackage compatible''. Why couldn't updates be provided through JPackage (I guess as a support issue it's another story)? Also, if a particular package that *is not* in Fedora requires an updated package (an older version of which *is* in Fedora), then one loses the ability to upgrade this package from JPackage as well. It would be nice to have one repository trump the other (in the general case, but maybe not here). You'd have to specify either by name alone, or by version. Also, you would have to be able to tell it to avoid upgrades if it has to uninstall certain dependencies in order for the upgrade to happen. As an example: : [<'uninstall'|'keep'>] 'prefer' ['for' <'name'|'version'>]. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDLpFmarJDwJ6gwowRAmvsAKCgFoGUtHzVcqTXmyVRUu3cR4zFNQCgnEMm m9epODf8dX3jwrgX7KdunpE= =CUOJ -----END PGP SIGNATURE----- From gbenson at redhat.com Mon Sep 19 11:04:31 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 19 Sep 2005 12:04:31 +0100 Subject: [fedora-java] Re: raising Yum's IQ In-Reply-To: <432E9167.8090109@zarb.org> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <20050916095723.GF6223@redhat.com> <20050916112452.GA6684@redhat.com> <200509161248.02384.vadimn@redhat.com> <20050919091403.GA12591@redhat.com> <432E9167.8090109@zarb.org> Message-ID: <20050919110428.GB12591@redhat.com> David Walluck wrote: > Gary Benson wrote: > > ones do not. The problem is that Fedora and JPackage rpms share > > the same namespace. Ximian had problems with this five years ago, > > before they were even called Ximian. What is really needed is for > > some way to tell yum to ignore packages in jpackage.repo that > > exist already in fedora.repo. I doubt it's that simple though. > > But FC4 was said to be ``100% JPackage compatible''. Why couldn't > updates be provided through JPackage? Some issues take time to fix properly. The correct fix may not be immediately obvious, or there may be several options that require discussion in some upstream community. Wherever possible I will work around the issue locally so people aren't held up. There's probably 15-20 such issues in rawhide at the moment. Replacing Fedora packages with JPackage ones will lose patches like that. > Also, if a particular package that *is not* in Fedora requires an > updated package (an older version of which *is* in Fedora), then one > loses the ability to upgrade this package from JPackage as well. Avoiding breakages without inhibiting things like this is difficult. Cheers, Gary From vadimn at redhat.com Mon Sep 19 15:24:36 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Mon, 19 Sep 2005 11:24:36 -0400 Subject: [fedora-java] Re: raising Yum's IQ In-Reply-To: <20050919091403.GA12591@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509161248.02384.vadimn@redhat.com> <20050919091403.GA12591@redhat.com> Message-ID: <200509191124.36551.vadimn@redhat.com> On Monday 19 September 2005 05:14, Gary Benson wrote: > Placing the native code in separate rpms will not solve this because > the problem is not that Fedora rpms contain native code and JPackage > ones do not. Everyone agrees at this point that the problem is not solvable at the RPM level. The only hope is to move one level up and start looking at what can be done at the Yum level. > What is really needed is for some way to tell yum to ignore packages > in jpackage.repo that exist already in fedora.repo. I doubt it's > that simple though. Some of the possible choices are: (a) fedora.repo always trumps jpackage.repo; (b) jpackage.repo always trumps fedora.repo; (c) the user has a choice of specifying either (a) or (b) as their default policy. People who use java stuff in FC exclusively with GCJ won't want to lose the native bits due to updates coming from jpackage.repo. People who use java packages primarily under a proprietary JVM will be happy to pull upgrades from jpackage.repo even if it means losing the .so bits; (d) go wild and make the choice of repos configurable on a per-package basis. Although I don't know how simple or difficult this is going to be, I doubt it will be much worse than the current situation. My initial conservative preference would be (c) with fedora.repo trumping jpackage.repo by default. From gbenson at redhat.com Mon Sep 19 15:49:04 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 19 Sep 2005 16:49:04 +0100 Subject: [fedora-java] Re: raising Yum's IQ In-Reply-To: <200509191124.36551.vadimn@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509161248.02384.vadimn@redhat.com> <20050919091403.GA12591@redhat.com> <200509191124.36551.vadimn@redhat.com> Message-ID: <20050919154901.GD12591@redhat.com> Vadim Nasardinov wrote: > On Monday 19 September 2005 05:14, Gary Benson wrote: > > What is really needed is for some way to tell yum to ignore > > packages in jpackage.repo that exist already in fedora.repo. > > I doubt it's that simple though. > > Some of the possible choices are: > > (a) fedora.repo always trumps jpackage.repo; > > (b) jpackage.repo always trumps fedora.repo; > > (c) the user has a choice of specifying either (a) or (b) as their > default policy. > > People who use java stuff in FC exclusively with GCJ won't want > to lose the native bits due to updates coming from jpackage.repo. > People who use java packages primarily under a proprietary JVM > will be happy to pull upgrades from jpackage.repo even if it > means losing the .so bits; > > (d) go wild and make the choice of repos configurable on a > per-package basis. > > Although I don't know how simple or difficult this is going to be, I > doubt it will be much worse than the current situation. My initial > conservative preference would be (c) with fedora.repo trumping > jpackage.repo by default. I like the sound of (c), though it's not just yum that needs to deal with this: anaconda and possibly up2date need to handle it too. Cheers, Gary From vadimn at redhat.com Mon Sep 19 15:54:17 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Mon, 19 Sep 2005 11:54:17 -0400 Subject: [fedora-java] Re: raising Yum's IQ In-Reply-To: <20050919154901.GD12591@redhat.com> References: <1126739281.8871.1.camel@tortoise.toronto.redhat.com> <200509191124.36551.vadimn@redhat.com> <20050919154901.GD12591@redhat.com> Message-ID: <200509191154.17265.vadimn@redhat.com> On Monday 19 September 2005 11:49, Gary Benson wrote: > I like the sound of (c), though it's not just yum that needs to deal > with this: anaconda and possibly up2date need to handle it too. I was hoping to keep my head in the sand about the anaconda/up2date part of the story, until we get the yum situation straightened out first. From fitzsim at redhat.com Mon Sep 19 16:31:26 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 19 Sep 2005 12:31:26 -0400 Subject: [fedora-java] dependency issues with java-1.4.2-gcj-compat In-Reply-To: <432E2131.6040905@zarb.org> References: <1126785890.6381.12.camel@localhost.localdomain> <20050915124253.GD5316@redhat.com> <1126792389.6381.20.camel@localhost.localdomain> <20050915141251.GH5316@redhat.com> <1126795910.6381.42.camel@localhost.localdomain> <1126805365.7740.17.camel@tortoise.toronto.redhat.com> <432C76C6.2080009@zarb.org> <1127094565.27818.11.camel@rh-ibm-t41> <432E2131.6040905@zarb.org> Message-ID: <1127147486.28291.10.camel@rh-ibm-t41> On Sun, 2005-09-18 at 22:23 -0400, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thomas Fitzsimmons wrote: > > You raise good points for why this isn't workable. One potential > > solution is to only include these scripts in the "system default" java- > > gcj-compat, since there will presumably only be one system-wide gcj > > database on which aot-compile-rpm and rebuild-gcj-db should operate. > > I'll fix this soon. > > Right. You could leave the files out when %custom is defined (or > whatever the define is for gcjHEAD). But then gcjHEAD-compat will > require gcj-compat (not a big deal, but then you could also relegate the > common (shared) scripts to a common subpackage). If it turns out that > two separate scripts are required, these common scripts will be able to > handle callling them as well. Actually, I think a java-gcj-compat-scripts package is exactly what we need. It could include rebuild-gcj-db, aot-compile-rpm, rebuild- security-providers along with the /etc files that it manipulates, and any other scripts that deal with system-wide defaults. Thanks for the suggestion. Tom From overholt at redhat.com Tue Sep 20 02:20:36 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 19 Sep 2005 22:20:36 -0400 Subject: [fedora-java] AbiWord gcj help request Message-ID: <20050920022036.GA3667@redhat.com> http://www.advogato.org/person/msevior/diary.html?start=56 Andrew From fitzsim at redhat.com Tue Sep 20 02:38:57 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 19 Sep 2005 22:38:57 -0400 Subject: [fedora-java] AbiWord gcj help request In-Reply-To: <20050920022036.GA3667@redhat.com> References: <20050920022036.GA3667@redhat.com> Message-ID: <1127183937.29040.3.camel@rh-ibm-t41> On Mon, 2005-09-19 at 22:20 -0400, Andrew Overholt wrote: > http://www.advogato.org/person/msevior/diary.html?start=56 Unfortunately this code fails on problems in our regexp implementation: java.util.regex.PatternSyntaxException: At position 1 in regular expression pattern: quantifier (?*+{}) without preceding token (?s) ^ at java.util.regex.Pattern. (Pattern.java:106) at java.util.regex.Pattern.compile (Pattern.java:143) at java.util.regex.Pattern.compile (Pattern.java:125) at java.lang.String.replaceAll (String.java:1254) at de.danielnaber.languagetool.Main.filterXML (Unknown Source) at de.danielnaber.languagetool.Main.getFilteredText (Unknown Source) at de.danielnaber.languagetool.Main.main (Unknown Source) I didn't try with jregexp yet. There are also problems with the included Swing GUI. Tom From i.pilcher at comcast.net Tue Sep 20 14:11:07 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 20 Sep 2005 09:11:07 -0500 Subject: [fedora-java] Should non-native Eclipse be noarch? Message-ID: I am trying to use the Rawhide SRPM to build non-native Eclipse 3.1 packages for FC4. (I am using the Java 1.5.0 RPMS from JPackage.) When building with gcj is disabled, this SPEC file sets the BuildArch to noarch. This causes the build to fail, because eclipse_arch gets set to i386 instead of ix86. I'm not sure what the correct fix is. Should a non-native Eclipse build *really* be noarch? There sure seems to be a lot of platform-specific stuff in there, and I note that JPackage's Eclipse 3.0.x packages are i586. So, I can either: * Set the BuildArch to i586 for non-native builds, or * Rework the SPEC file to set eclipse_arch to ix86 for non-native builds. Suggestions welcome. Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From overholt at redhat.com Tue Sep 20 14:51:43 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 20 Sep 2005 10:51:43 -0400 Subject: [fedora-java] Should non-native Eclipse be noarch? In-Reply-To: References: Message-ID: <20050920145143.GF14015@redhat.com> * Ian Pilcher [2005-09-20 10:14]: > When building with gcj is disabled, this SPEC file sets the BuildArch to > noarch. This causes the build to fail, because eclipse_arch gets set to > i386 instead of ix86. > > I'm not sure what the correct fix is. Should a non-native Eclipse build > *really* be noarch? There sure seems to be a lot of platform-specific > stuff in there, and I note that JPackage's Eclipse 3.0.x packages are > i586. I should fix this. It shouldn't be noarch. The reason we have the gcj-specific stuff in there for arches is because we (well, not anymore but the last time I tried) could only build on i386, ppc, and x86_64. So yeah: Eclipse packages should be arch-specific. Sorry, Andrew From i.pilcher at comcast.net Tue Sep 20 14:57:30 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 20 Sep 2005 09:57:30 -0500 Subject: [fedora-java] Re: Should non-native Eclipse be noarch? In-Reply-To: <20050920145143.GF14015@redhat.com> References: <20050920145143.GF14015@redhat.com> Message-ID: Andrew Overholt wrote: > So yeah: Eclipse packages should be arch-specific. Let me take a crack at this. It looks like non-native Eclipse should be limited to ia64, ppc, ppc64, x86_64, and i?86. Seems relatively strait- forward, except for the last one. What do you think is most appropriate i386 (would it actually run?), i586 (to match Sun's JVM), something else? TIA -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From overholt at redhat.com Tue Sep 20 15:31:25 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 20 Sep 2005 11:31:25 -0400 Subject: [fedora-java] Re: Should non-native Eclipse be noarch? In-Reply-To: References: <20050920145143.GF14015@redhat.com> Message-ID: <20050920153124.GA19377@redhat.com> * Ian Pilcher [2005-09-20 11:01]: > What do you think is most appropriate i386 (would it actually run?), > i586 (to match Sun's JVM), something else? Eclipse upstream just calls it x86. That's why we have that stuff at the top of the specfile saying "all arches line up except ...". Does it matter that much what the BuildArch is? I don't know much about .sos that are generated from JNI and their arch, etc. Anyone else? Andrew From gbenson at redhat.com Tue Sep 20 15:57:19 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 20 Sep 2005 16:57:19 +0100 Subject: [fedora-java] Re: Should non-native Eclipse be noarch? In-Reply-To: <20050920153124.GA19377@redhat.com> References: <20050920145143.GF14015@redhat.com> <20050920153124.GA19377@redhat.com> Message-ID: <20050920155716.GA5223@redhat.com> Andrew Overholt wrote: > * Ian Pilcher [2005-09-20 11:01]: > > What do you think is most appropriate i386 (would it actually > > run?), i586 (to match Sun's JVM), something else? > > Eclipse upstream just calls it x86. That's why we have that stuff > at the top of the specfile saying "all arches line up except ...". > Does it matter that much what the BuildArch is? I don't know much > about .sos that are generated from JNI and their arch, etc. Anyone > else? Use i386. Cheers, Gary From gbenson at redhat.com Wed Sep 21 14:50:51 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 21 Sep 2005 15:50:51 +0100 Subject: [fedora-java] aot-compile-rpm improvements Message-ID: <20050921145049.GA20244@redhat.com> I made some changes to aot-compile-rpm this past few days, with the result that it can now cope with jars within jars (required for ears, rars and some wars), incorrectly named classes (the other wars) and classes not in jarfiles at all. If your package contains such things you will find extra solibs and databases being built. This affects tomcat5 and jonas which I'm now rebuilding. When that's done they will have natively compiled applications. Cheers, Gary From vadimn at redhat.com Wed Sep 21 15:17:59 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Wed, 21 Sep 2005 11:17:59 -0400 Subject: [fedora-java] aot-compile-rpm improvements In-Reply-To: <20050921145049.GA20244@redhat.com> References: <20050921145049.GA20244@redhat.com> Message-ID: <200509211117.59635.vadimn@redhat.com> On Wednesday 21 September 2005 10:50, Gary Benson wrote: > incorrectly named classes (the other wars) What's an incorrectly named class? From gbenson at redhat.com Wed Sep 21 15:39:44 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 21 Sep 2005 16:39:44 +0100 Subject: [fedora-java] aot-compile-rpm improvements In-Reply-To: <200509211117.59635.vadimn@redhat.com> References: <20050921145049.GA20244@redhat.com> <200509211117.59635.vadimn@redhat.com> Message-ID: <20050921153943.GB20244@redhat.com> Vadim Nasardinov wrote: > On Wednesday 21 September 2005 10:50, Gary Benson wrote: > > incorrectly named classes (the other wars) > > What's an incorrectly named class? One that's not in the correct directory. In wars, classes that aren't in jarfiles live under WEB-INF/classes; you couldn't, for instance, put a war in your classpath and fetch classes from it like you could with a jar. Cheers, Gary From i.pilcher at comcast.net Thu Sep 22 16:58:11 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 22 Sep 2005 11:58:11 -0500 Subject: [fedora-java] Non-native Eclipse 3.1 builds - now what? Message-ID: Starting with the Eclipse 3.1 SRPM in Rawhide, I've managed to build "non-native" packages on Fedora Core 4. I had to work around the following issues: * nspr-devel vs. mozilla-nspr-devel: Since nspr-devel (in Rawhide) provides mozilla-nspr-devel, I changed the BuildRequires to mozilla-nspr-devel. The location of the header files also changes, so I modified eclipse-libswt-mozilla.patch to look in both /usr/include/nspr4 and /usr/include/mozilla-1.7.10/nspr. * Location of libjawt.so: The SWT build script seems to have the IBM JDK file layout hardcoded in its build scripts. I've bugzilla'ed this at https://bugs.eclipse.org/bugs/show_bug.cgi?id=110199. For now, I'm inclined to simply BuildRequire an IBM JDK for non-native builds. Any thoughts on exactly what I should require and how I should set JAVA_HOME would be appreciated. * Non-native builds are not noarch. I set the ExclusiveArch's for non-native builds to %{ix86} x86_64 ppc ppc64 ia64, which are the architectures supported by Eclipse itself. The real question is what next? It would be nice if the resulting SPEC file could be used for both Fedora Core (4 and devel) and JPackage. How should I go about "conditionalizing" things? Note BTW, that changing the package VERSION to 3.1.0_fc is pretty nasty. Can this be moved to the RELEASE? Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From sagi.ye at gmail.com Sat Sep 24 02:42:48 2005 From: sagi.ye at gmail.com (Sagi Ye) Date: Sat, 24 Sep 2005 10:42:48 +0800 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work Message-ID: <1127529768.3311.10.camel@localhost.localdomain> hello, Fedora core 4 installed and updated ( by yum ) to the most lated version. Apache & Tomcat is installed. http://localhost:8080 check is OK. The eclipse web tool (wtp 0.7) installed via eclipse's "software updates" feature. Now I failed to add the Tomcat server to eclipse's reach. In the "New Server Runtime" dialog, eclipse refused to accept "/usr/share/tomcat5" as the "Tomcat installation directory" where I checked do tomcat resides. I just wondered what are eclipse looking for and how it check for a valid server runtime. Or could it be cause that the installation of Tomcat differs in FC4 to other platforms? -- Sagi Ye From aluchko at redhat.com Fri Sep 23 21:40:14 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Fri, 23 Sep 2005 21:40:14 +0000 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127529768.3311.10.camel@localhost.localdomain> References: <1127529768.3311.10.camel@localhost.localdomain> Message-ID: <1127511614.26433.11.camel@jekyll> On Sat, 2005-09-24 at 10:42 +0800, Sagi Ye wrote: > hello, > > Fedora core 4 installed and updated ( by yum ) > to the most lated version. > Apache & Tomcat is installed. http://localhost:8080 check is OK. > > The eclipse web tool (wtp 0.7) installed via eclipse's > "software updates" feature. > > Now I failed to add the Tomcat server to eclipse's reach. > In the "New Server Runtime" dialog, eclipse refused to accept > "/usr/share/tomcat5" as the "Tomcat installation directory" where > I checked do tomcat resides. > > I just wondered what are eclipse looking for and how it check for > a valid server runtime. Or could it be cause that the installation > of Tomcat differs in FC4 to other platforms? I played around with wtp project (upstream eclipse and tomcat) a while back and had some trouble myself getting tomcat to be accepted. The issue seemed to be more with wtp not accepting the tomcat installation directory when creating certain types of projects for some reason. One project type I do recall working is Dynamic Web Project (though it wasn't rpm installed). Are you able to use /usr/share/tomcat5 using a Dynamic Web Project? thanks, Aaron From sagi.ye at gmail.com Sat Sep 24 05:45:37 2005 From: sagi.ye at gmail.com (Sagi Ye) Date: Sat, 24 Sep 2005 13:45:37 +0800 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127511614.26433.11.camel@jekyll> References: <1127529768.3311.10.camel@localhost.localdomain> <1127511614.26433.11.camel@jekyll> Message-ID: <1127540737.3311.16.camel@localhost.localdomain> Without the success of ADD a NEW SERVER RUNTIME to eclipse. There will be no available Target Server to be selected while creating a new project of "Dynamic Web Project". I think what i need to do is try to add the server in first. On Fri, 2005-09-23 at 21:40 +0000, Aaron Luchko wrote: > On Sat, 2005-09-24 at 10:42 +0800, Sagi Ye wrote: > > hello, > > > > Fedora core 4 installed and updated ( by yum ) > > to the most lated version. > > Apache & Tomcat is installed. http://localhost:8080 check is OK. > > > > The eclipse web tool (wtp 0.7) installed via eclipse's > > "software updates" feature. > > > > Now I failed to add the Tomcat server to eclipse's reach. > > In the "New Server Runtime" dialog, eclipse refused to accept > > "/usr/share/tomcat5" as the "Tomcat installation directory" where > > I checked do tomcat resides. > > > > I just wondered what are eclipse looking for and how it check for > > a valid server runtime. Or could it be cause that the installation > > of Tomcat differs in FC4 to other platforms? > > I played around with wtp project (upstream eclipse and tomcat) a while > back and had some trouble myself getting tomcat to be accepted. > > The issue seemed to be more with wtp not accepting the tomcat > installation directory when creating certain types of projects for some > reason. One project type I do recall working is Dynamic Web Project > (though it wasn't rpm installed). > > Are you able to use /usr/share/tomcat5 using a Dynamic Web Project? > > thanks, > Aaron > From aluchko at redhat.com Sat Sep 24 00:07:46 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Sat, 24 Sep 2005 00:07:46 +0000 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127540737.3311.16.camel@localhost.localdomain> References: <1127529768.3311.10.camel@localhost.localdomain> <1127511614.26433.11.camel@jekyll> <1127540737.3311.16.camel@localhost.localdomain> Message-ID: <1127520466.26433.14.camel@jekyll> On Sat, 2005-09-24 at 13:45 +0800, Sagi Ye wrote: > Without the success of ADD a NEW SERVER RUNTIME to eclipse. > There will be no available Target Server to be selected while > creating a new project of "Dynamic Web Project". > > I think what i need to do is try to add the server in first. Are you able to add the server using upstream tomcat? Aaron From sagi.ye at gmail.com Sat Sep 24 06:54:33 2005 From: sagi.ye at gmail.com (Sagi Ye) Date: Sat, 24 Sep 2005 14:54:33 +0800 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127520466.26433.14.camel@jekyll> References: <1127529768.3311.10.camel@localhost.localdomain> <1127511614.26433.11.camel@jekyll> <1127540737.3311.16.camel@localhost.localdomain> <1127520466.26433.14.camel@jekyll> Message-ID: <1127544873.29281.7.camel@localhost.localdomain> I don't know what u mean by "upstream". The version of tomcat i use is 5.0.30-5jpp_6fc. Isn't this the newest version in the fedora's official yum repo.? I can't add it! BTW, my eclipse is "Native Eclipse 3.1M6". I just found there is no "startup.sh, shutdown.sh, tomcat.sh" in "/usr/share/tomcat5/bin/", but only a "bootstrap.jar". And there do has a "/usr/bin/tomcat5" script which can be used to start/stop tomcat. Could this be the problem? On Sat, 2005-09-24 at 00:07 +0000, Aaron Luchko wrote: > On Sat, 2005-09-24 at 13:45 +0800, Sagi Ye wrote: > > Without the success of ADD a NEW SERVER RUNTIME to eclipse. > > There will be no available Target Server to be selected while > > creating a new project of "Dynamic Web Project". > > > > I think what i need to do is try to add the server in first. > > Are you able to add the server using upstream tomcat? > > Aaron > From tadej.janez at tadej.hicsalta.si Sat Sep 24 10:20:06 2005 From: tadej.janez at tadej.hicsalta.si (Tadej =?iso-8859-2?Q?Jane=BE?=) Date: Sat, 24 Sep 2005 12:20:06 +0200 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127529768.3311.10.camel@localhost.localdomain> References: <1127529768.3311.10.camel@localhost.localdomain> Message-ID: <1127557206.3018.7.camel@localhost.localdomain> On Sat, 2005-09-24 at 10:42 +0800, Sagi Ye wrote: > hello, > > Fedora core 4 installed and updated ( by yum ) > to the most lated version. > Apache & Tomcat is installed. http://localhost:8080 check is OK. > > The eclipse web tool (wtp 0.7) installed via eclipse's > "software updates" feature. > > Now I failed to add the Tomcat server to eclipse's reach. > In the "New Server Runtime" dialog, eclipse refused to accept > "/usr/share/tomcat5" as the "Tomcat installation directory" where > I checked do tomcat resides. Your problem could be connected to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159881 snip "...Eclipse embeds its own version of tomcat. We would like to symlink out to the tomcat that we ship, but it is tomcat5 and Eclipse uses tomcat4 (currently). I'm working on patching Eclipse to use tomcat 5.0.30." This will be fixed when Eclipse in FC4 gets an update to 3.1 final. Hope to help, Tadej -- Tadej Jane? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From overholt at redhat.com Sat Sep 24 14:21:12 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 24 Sep 2005 10:21:12 -0400 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127557206.3018.7.camel@localhost.localdomain> References: <1127529768.3311.10.camel@localhost.localdomain> <1127557206.3018.7.camel@localhost.localdomain> Message-ID: <20050924142112.GA23807@redhat.com> * Tadej Jane? [2005-09-24 06:20]: > On Sat, 2005-09-24 at 10:42 +0800, Sagi Ye wrote: > > hello, > > > > Fedora core 4 installed and updated ( by yum ) > > to the most lated version. > > Apache & Tomcat is installed. http://localhost:8080 check is OK. > > > > The eclipse web tool (wtp 0.7) installed via eclipse's > > "software updates" feature. > > > > Now I failed to add the Tomcat server to eclipse's reach. > > In the "New Server Runtime" dialog, eclipse refused to accept > > "/usr/share/tomcat5" as the "Tomcat installation directory" where > > I checked do tomcat resides. > > Your problem could be connected to > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159881 No, I don't think so. This has nothing to do with the system tomcat that he's trying to use with WTP. Andrew From aluchko at redhat.com Sat Sep 24 14:55:33 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Sat, 24 Sep 2005 14:55:33 +0000 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127544873.29281.7.camel@localhost.localdomain> References: <1127529768.3311.10.camel@localhost.localdomain> <1127511614.26433.11.camel@jekyll> <1127540737.3311.16.camel@localhost.localdomain> <1127520466.26433.14.camel@jekyll> <1127544873.29281.7.camel@localhost.localdomain> Message-ID: <1127573734.26433.24.camel@jekyll> On Sat, 2005-09-24 at 14:54 +0800, Sagi Ye wrote: > I don't know what u mean by "upstream". > The version of tomcat i use is 5.0.30-5jpp_6fc. > Isn't this the newest version in the fedora's official yum repo.? Sorry, upstream means the original source of the software, in this case http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi download http://apache.sunsite.ualberta.ca/jakarta/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.tar.gz than 'tar -zxf jakarta-tomcat-5.0.30.tar.gz' to expand it now you'll have a directory jakarta-tomcat/ try adding this as your server in the same way you did with /usr/share/tomcat5 > BTW, my eclipse is "Native Eclipse 3.1M6". The old version of eclipse in FC4 might cause trouble but I suspect not since they'd already done the API freeze for M6 so plugins shouldn't have trouble. > I just found there is no "startup.sh, shutdown.sh, tomcat.sh" in > "/usr/share/tomcat5/bin/", but only a "bootstrap.jar". And there > do has a "/usr/bin/tomcat5" script which can be used to start/stop > tomcat. Could this be the problem? Unfortunately I don't know that much about tomcat or how it's packaged for FC4. If the upstream tomcat works with wtp my suspicion would be culprit is the way it's packaged and the location of files, if this is the case someone more familiar with tomcat may be able to shed light on the issue and find a way to trick wtp into using the rpm installed tomcat. Aaron From sagi.ye at gmail.com Sun Sep 25 02:50:23 2005 From: sagi.ye at gmail.com (Sagi Ye) Date: Sun, 25 Sep 2005 10:50:23 +0800 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127573734.26433.24.camel@jekyll> References: <1127529768.3311.10.camel@localhost.localdomain> <1127511614.26433.11.camel@jekyll> <1127540737.3311.16.camel@localhost.localdomain> <1127520466.26433.14.camel@jekyll> <1127544873.29281.7.camel@localhost.localdomain> <1127573734.26433.24.camel@jekyll> Message-ID: <1127616624.2671.5.camel@localhost.localdomain> OK, I downloaded tomcat-5.5.9, and installed it. Now it can be added as a server. But while I tried to create a Dynamic Web Project. It still wasn't in the available server list. BTW, I tried also to download the eclipse 3.1 from www.eclipse.org. This can almost work with tomcat-5.5.9. ( Though still has some problems. ) On Sat, 2005-09-24 at 14:55 +0000, Aaron Luchko wrote: > On Sat, 2005-09-24 at 14:54 +0800, Sagi Ye wrote: > > I don't know what u mean by "upstream". > > The version of tomcat i use is 5.0.30-5jpp_6fc. > > Isn't this the newest version in the fedora's official yum repo.? > > Sorry, upstream means the original source of the software, in this case > http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi > download > http://apache.sunsite.ualberta.ca/jakarta/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.tar.gz > than 'tar -zxf jakarta-tomcat-5.0.30.tar.gz' to expand it > now you'll have a directory jakarta-tomcat/ try adding this as your > server in the same way you did with /usr/share/tomcat5 > > > BTW, my eclipse is "Native Eclipse 3.1M6". > > The old version of eclipse in FC4 might cause trouble but I suspect not > since they'd already done the API freeze for M6 so plugins shouldn't > have trouble. > > > I just found there is no "startup.sh, shutdown.sh, tomcat.sh" in > > "/usr/share/tomcat5/bin/", but only a "bootstrap.jar". And there > > do has a "/usr/bin/tomcat5" script which can be used to start/stop > > tomcat. Could this be the problem? > > Unfortunately I don't know that much about tomcat or how it's packaged > for FC4. If the upstream tomcat works with wtp my suspicion would be > culprit is the way it's packaged and the location of files, if this is > the case someone more familiar with tomcat may be able to shed light on > the issue and find a way to trick wtp into using the rpm installed > tomcat. > > Aaron > From aluchko at redhat.com Sun Sep 25 19:49:04 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Sun, 25 Sep 2005 19:49:04 +0000 Subject: [fedora-java] eclipse wtp + tomcat5 couldn't work In-Reply-To: <1127616624.2671.5.camel@localhost.localdomain> References: <1127529768.3311.10.camel@localhost.localdomain> <1127511614.26433.11.camel@jekyll> <1127540737.3311.16.camel@localhost.localdomain> <1127520466.26433.14.camel@jekyll> <1127544873.29281.7.camel@localhost.localdomain> <1127573734.26433.24.camel@jekyll> <1127616624.2671.5.camel@localhost.localdomain> Message-ID: <1127677744.26433.46.camel@jekyll> On Sun, 2005-09-25 at 10:50 +0800, Sagi Ye wrote: > OK, I downloaded tomcat-5.5.9, and installed it. > Now it can be added as a server. > But while I tried to create a Dynamic Web Project. > It still wasn't in the available server list. > > BTW, I tried also to download the eclipse 3.1 from www.eclipse.org. > This can almost work with tomcat-5.5.9. ( Though still has some > problems. ) Ok I've tried with upstream eclipse with upstream tomcat along with /var/lib/tomcat5 and /usr/share/tomcat5 Upstream was accepted but neither of the two rpm installed directories worked. Does anyone more tomcat-wise know what wtp might be looking for and not finding that it doesn't accept either of these directories? thanks, Aaron From brion at pobox.com Thu Sep 29 06:27:49 2005 From: brion at pobox.com (Brion Vibber) Date: Wed, 28 Sep 2005 23:27:49 -0700 Subject: [fedora-java] batik [Fwd: Re: com.sun.image.*] Message-ID: <433B8965.5040802@pobox.com> Anthony Green wrote: > If anybody is interested in running batik on our free stack, here's some > info on what needs doing... Has anybody been working on this? We'd be interested in using Batik to rasterize SVG content for Wikipedia, and as we have a bit of a free software fetish it would be nice to make sure it can run under GCJ. (Currently we're using librsvg, which is not totally satisfactory as there are some things it doesn't render too well.) If nobody's working on it, I might pick it up sometime in the next while depending on how hard it looks. :) -- brion vibber (brion @ pobox.com / brion @ wikimedia.org) > --- Begin Message --- > From: Thomas DeWeese > To: batik-dev xmlgraphics apache org > Subject: Re: com.sun.image.* > Date: Wed, 24 Aug 2005 20:05:34 -0400 > Hi Anthony, > > Anthony Green wrote: > > > batik 1.6 (as packaged by jpackage.org) builds nicely on the Fedora > > Core 4 Linux distribution with a fully Free and Open Source java stack > > (gcj, the Eclipse compiler, etc), with the exception of a few classes > > using com.sun.image.codec.jpeg.*. > > > > The com.sun.image.code.jpeg.* classes aren't part of the standard java > > platform, and there are no Free or Open Source implementations of the > > classes available for us to use. Can similar functionality be achieved > > through the use of core classes, like ImageIO? > > I would imagine so. There are some potential issues with the > handling of colorspaces but my understanding is that imageio > tends to be more complete in general. > > > If so, are there any plans for such a migration? > > The basic problem is that javax.imageio is only available in > JDK 1.4 and higher. Currently Batik target's 1.3 and higher. > However we recently created a source tree for JDK 1.4 specific > classes (only compiled for JDK 1.4 of course). So it might be > possible to add to the current support with this. > > > Getting batik to build with free software solutions opens the door to > > including it, and applications that depend on it, in fully free Linux > > distributions, like Fedora and Debian. > > Any help from the these communities would be very welcome! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: From green at redhat.com Thu Sep 29 06:37:49 2005 From: green at redhat.com (Anthony Green) Date: Wed, 28 Sep 2005 23:37:49 -0700 Subject: [fedora-java] batik [Fwd: Re: com.sun.image.*] In-Reply-To: <433B8965.5040802@pobox.com> References: <433B8965.5040802@pobox.com> Message-ID: <1127975869.3583.5.camel@localhost.localdomain> On Wed, 2005-09-28 at 23:27 -0700, Brion Vibber wrote: > If nobody's working on it, I might pick it up sometime in the next while > depending on how hard it looks. :) As far as I know nobody is working on this, so... go for it! And then look for your name when I edit http://en.wikipedia.org/wiki/Hero :-) AG From caolanm at redhat.com Thu Sep 29 10:37:56 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 29 Sep 2005 11:37:56 +0100 Subject: [fedora-java] gnome java-access-bridge, gcj and idlj Message-ID: <1127990276.9762.2.camel@localhost.localdomain> openoffice's accessibility solution for gnome is apparently to use the gnome java-access-bridge, is this possible to build with gcj ? ftp://ftp.gnome.org/pub/gnome/sources/java-access-bridge/1.4/ I gave a casual check and it requires "idlj" during it's build which doesn't seem to have a gcj eqivalent, or does it ? C. From tromey at redhat.com Thu Sep 29 15:36:54 2005 From: tromey at redhat.com (Tom Tromey) Date: 29 Sep 2005 09:36:54 -0600 Subject: [fedora-java] gnome java-access-bridge, gcj and idlj In-Reply-To: <1127990276.9762.2.camel@localhost.localdomain> References: <1127990276.9762.2.camel@localhost.localdomain> Message-ID: >>>>> "Caolan" == Caolan McNamara writes: Caolan> openoffice's accessibility solution for gnome is apparently to use the Caolan> gnome java-access-bridge, is this possible to build with gcj ? Caolan> ftp://ftp.gnome.org/pub/gnome/sources/java-access-bridge/1.4/ Caolan> I gave a casual check and it requires "idlj" during it's build which Caolan> doesn't seem to have a gcj eqivalent, or does it ? Not yet. However, I think there is one in jacorb, which we package for jonas. Tom