From overholt at redhat.com Tue Nov 1 01:21:10 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 31 Oct 2005 20:21:10 -0500 Subject: [fedora-java] Re: Fedora Core 4 Test Update: eclipse-3.1.1-1jpp_1fc.FC4.4 In-Reply-To: <200510311718.j9VHIcw5011718@devserv.devel.redhat.com> References: <200510311718.j9VHIcw5011718@devserv.devel.redhat.com> Message-ID: <20051101012109.GA30625@redhat.com> Please test this Eclipse test update for FC4. I'm hoping this latest test release fixes the following bugs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159564 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161518 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161635 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162383 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162443 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163079 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164095 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165204 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165330 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167548 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168040 I would greatly appreciate it if you can test it and comment on any of the following bugs (especially 168040). Test like so: yum --enablerepo=updates-testing update eclipse-pde-devel (or eclipse-pde or eclipse-jdt or whatever you have installed) Thanks, Andrew From aph at redhat.com Tue Nov 1 09:15:04 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 1 Nov 2005 09:15:04 +0000 Subject: [fedora-java] Re: Fedora Core 4 Test Update: eclipse-3.1.1-1jpp_1fc.FC4.4 In-Reply-To: <20051101012109.GA30625@redhat.com> References: <200510311718.j9VHIcw5011718@devserv.devel.redhat.com> <20051101012109.GA30625@redhat.com> Message-ID: <17255.12824.804999.718600@zapata.pink> Andrew Overholt writes: > Please test this Eclipse test update for FC4. I'm hoping this latest test > release fixes the following bugs: That's great. Did you ever look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162169 Andrew. From overholt at redhat.com Tue Nov 1 13:48:07 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 1 Nov 2005 08:48:07 -0500 Subject: [fedora-java] Re: Fedora Core 4 Test Update: eclipse-3.1.1-1jpp_1fc.FC4.4 In-Reply-To: <17255.12824.804999.718600@zapata.pink> References: <200510311718.j9VHIcw5011718@devserv.devel.redhat.com> <20051101012109.GA30625@redhat.com> <17255.12824.804999.718600@zapata.pink> Message-ID: <20051101134805.GA24535@redhat.com> * Andrew Haley [2005-11-01 04:12]: > Andrew Overholt writes: > > Please test this Eclipse test update for FC4. I'm hoping this latest test > > release fixes the following bugs: > > That's great. > > Did you ever look at > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162169 Nope. I spent all my time on the CVS bug only to give up. I'm planning on going back to that (well, mostly just to get people like you a "small" test case ;) but I didn't want to delay on the FC4 update any longer. Once this new Eclipse RPM is released as an update, I can build and release the new CDT (which still doesn't work when natively-compiled :( ... I will be filing bugs, etc. this week about that). Andrew From phil at mkdoc.com Thu Nov 3 12:30:44 2005 From: phil at mkdoc.com (Phil Shaw) Date: Thu, 3 Nov 2005 12:30:44 -0000 Subject: [fedora-java] Announce: MKSearch beta 1, done with GCJ Message-ID: <436A02F4.31366.5E153F6C@localhost> I have mostly been lurking on these lists over the past year and I have learned a lot from the posts, so thanks very much to the free Java contributors for your part in the MKSearch project. A formal announcement follows, but I thought members of these lists (Mark Wielaard especially) may also be interested in some screen shots of our beta search engine running on Fedora Core 4 with Tomcat 5 in Firefox. https://svn.mkdoc.com/mksearch/doc/design/screenshots/ Best regards, Phil Shaw MKSearch beta 1 release announcement MKDoc Ltd. would like to announce the first beta release of MKSearch, under the GNU General Public Licence. Source and pre-compiled binary downloads are available from the project Web site. http://www.mksearch.mkdoc.org/downloads/ MKSearch is a metadata search engine that indexes structured metadata in Web documents, not free text in the document body. The data acquisition system: * Conforms to the Dublin Core metadata in HTML recommendations [1] * Supports other application profiles, such as the UK e-Government Metadata Standard [2] * Indexes native RDF formats, including RSS 1.0 The MKSearch system has five major components: 1. A Web crawler based on JSpider [3] * Multi-threaded processing * Per-site throttle, user agent, depth and linking rules * Respects the robots.txt exclusion policy * Extensible plug-in based content handling 2. An HTML document validator and formatter based on JTidy [4] * Cleans-up and corrects HTML syntax errors * Converts HTML to XHTML 3. A set of custom indexers based on the Simple API for XML (SAX) * Extracts metadata from HTML meta and link elements * Converts metadata to RDF triple statements * Configurable application profiles 4. An RDF storage and query system based on Sesame [5] * XML/RDF file-based storage * Database storage using PostgreSQL or MySQL * Sophisticated Sesame RDF Query Language (SeRQL) queries * Scope for more semantically rich queries with inferencing 5. A public query interface, provided through a standard servlet container * Simple, expandable query builder form * Configurable application profile-based presentation * Wildcard query handling * Phrase searches * Paged HTML results * Standing RSS results The two main elements of the MKSearch system can be used independently. The data acquisition system can be used to gather large quantities of metadata from the Web and store it as RDF. The query system can be used to provide a typical search engine-style interface to existing RDF content. The MKSearch beta 1 distribution includes sample configurations that crawl a Web site and create: * A mirror of the site on the local file system in valid XHTML * An RDF N-Triple record for each page on the local file system * UK e-Government metadata in a Sesame file-based repository (XML/RDF) This distribution also includes a demonstration of the MKSearch query interface, in the form of a Web Application Archive (WAR) that can be deployed directly to an existing servlet container. The sample search content is from an index of the MKSearch project Web site on 2 November 2005. See the site documentation below: http://www.mksearch.mkdoc.org/documentation/tomcat-on-fc4/ http://www.mksearch.mkdoc.org/howto/ http://www.mksearch.mkdoc.org/plans/beta-1-release- tasks/mksearch-beta-1-release-notes/ System requirements and licence ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MKSearch is written in the Java programming language and is designed to run on any platform that supports a Java environment equivalent to the Sun Java 2 language specification. The system has specifically been designed, developed and tested to run on GNU/Linux systems using the GNU Compiler for Java (GCJ) [6] and Apache Tomcat 5 servlet container, as available on Fedora Core 4 [7]. This provision means that MKSearch can be built and run on software systems that are entirely open source and free from proprietary licencing. The system has been tested extensively using the Sun Java SDK 1.5 on Microsoft Windows 2000. JUnit test suites for the MKSearch code base cover 99% of all code branches. If you have any comments or questions about the MKSearch system, please join us on the project mailing list. http://www.email-lists.org/mailman/listinfo/mksearch-dev References ~~~~~~~~~~ [1] http://dublincore.org/documents/2003/11/30/dcq-html/ [2] http://www.govtalk.gov.uk/schemasstandards/metadata_document. asp?docnum=805 [3] http://j-spider.sourceforge.net/ [4] http://jtidy.sourceforge.net/ [5] http://www.openrdf.org/ [6] http://gcc.gnu.org/java/ [7] http://fedora.redhat.com/ -- MKSearch (beta) http://www.mksearch.mkdoc.org/ Free, open source metadata search engine with RDF storage and query. From vadimn at redhat.com Fri Nov 4 19:18:05 2005 From: vadimn at redhat.com (Vadim Nasardinov) Date: Fri, 4 Nov 2005 14:18:05 -0500 Subject: [fedora-java] updating from ant-1.6.5-2fc to ant-1.6.5-0jpp_1fc Message-ID: <200511041418.05457.vadimn@redhat.com> I recently changed the Ant RPM's Release header from 2fc to 0jpp_1fc in rawhide: https://www.redhat.com/archives/fedora-cvs-commits/2005-November/msg00159.html Thus, the Ant RPM went through the following three consecutive versions in rawhide: ant-1.6.2-3jpp_14fc ant-1.6.5-2fc ant-1.6.5-0jpp_1fc If you had already updated your rawhide box from ant-1.6.2-3jpp_14fc to ant-1.6.5-2fc, you won't be able to yum update it to ant-1.6.5-0jpp_1fc, because 0jpp_1fc is less than 2fc as far as rpm is concerned. Functionally, there are currently no differences between these two releases. The reason I had to change the release number was to make it possible to resync Fedora's Ant with the future ant-1.6.5-1jpp RPM from JPackage. To undo my screwup, you may have to run the attached script. I apologize for the inconvience. Vadim -------------- next part -------------- A non-text attachment was scrubbed... Name: update-ant.sh Type: application/x-shellscript Size: 722 bytes Desc: not available URL: From dant at cdkkt.com Wed Nov 9 02:04:55 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 8 Nov 2005 18:04:55 -0800 Subject: [fedora-java] Using Yum Updates with Jpackage.org repos Message-ID: Hi Folks, Got a problem. I stumbled onto this group (jpackage.org) when I wanted to install the JDK 5.0 on FC4 and in order to do that, part of the instructions was to install the jpackage repos for Yum. I was able to install the JDK 5.0 on FC4. Great! But unfortunately, I was not able to use yum update because there is a dependency conflict regarding jms and this prevents me from updating FC4 as well. So I am forced to move the jpackage repos aside until this issue is resolved. Here is the yum update output: --> Running transaction check --> Processing Dependency: jms for package: avalon-logkit --> Finished Dependency Resolution Error: Missing Dependency: jms is needed by package avalon-logkit Can anyone help? Thanks, Dan Thurman -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 11/5/2005 From gbenson at redhat.com Wed Nov 9 09:22:33 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 9 Nov 2005 09:22:33 +0000 Subject: [fedora-java] Using Yum Updates with Jpackage.org repos In-Reply-To: References: Message-ID: <20051109092230.GB5181@redhat.com> Daniel B. Thurman wrote: > Hi Folks, > > Got a problem. I stumbled onto this group (jpackage.org) when I > wanted to install the JDK 5.0 on FC4 and in order to do that, part > of the instructions was to install the jpackage repos for Yum. > > I was able to install the JDK 5.0 on FC4. Great! > > But unfortunately, I was not able to use yum update because there > is a dependency conflict regarding jms and this prevents me from > updating FC4 as well. So I am forced to move the jpackage repos > aside until this issue is resolved. > > Here is the yum update output: > > --> Running transaction check > --> Processing Dependency: jms for package: avalon-logkit > --> Finished Dependency Resolution > Error: Missing Dependency: jms is needed by package avalon-logkit > > Can anyone help? Downloading and installing geronimo-specs and geronimo-specs-compat from rawhide should solve this. Option B would be to build and install the jms package from JPackage. Cheers, Gary From dant at cdkkt.com Wed Nov 9 18:00:12 2005 From: dant at cdkkt.com (Daniel B. Thurman) Date: Wed, 9 Nov 2005 10:00:12 -0800 Subject: [fedora-java] RE: fedora-devel-java-list Digest, Vol 10, Issue 4 Message-ID: >From: fedora-devel-java-list-bounces at redhat.com >[mailto:fedora-devel-java-list-bounces at redhat.com]On Behalf Of >fedora-devel-java-list-request at redhat.com >Sent: Wednesday, November 09, 2005 9:01 AM >To: fedora-devel-java-list at redhat.com >Subject: fedora-devel-java-list Digest, Vol 10, Issue 4 > > >Send fedora-devel-java-list mailing list submissions to > fedora-devel-java-list at redhat.com > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list >or, via email, send a message with subject or body 'help' to > fedora-devel-java-list-request at redhat.com > >You can reach the person managing the list at > fedora-devel-java-list-owner at redhat.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of fedora-devel-java-list digest..." > > >Today's Topics: > > 1. Using Yum Updates with Jpackage.org repos (Daniel B. Thurman) > 2. Re: Using Yum Updates with Jpackage.org repos (Gary Benson) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 8 Nov 2005 18:04:55 -0800 >From: "Daniel B. Thurman" >Subject: [fedora-java] Using Yum Updates with Jpackage.org repos >To: "Fedora Java Development List \(E-mail\)" > >Message-ID: >Content-Type: text/plain; charset="iso-8859-1" > > >Hi Folks, > >Got a problem. I stumbled onto this group (jpackage.org) when >I wanted to install the JDK 5.0 on FC4 and in order to do that, >part of the instructions was to install the jpackage repos for Yum. > >I was able to install the JDK 5.0 on FC4. Great! > >But unfortunately, I was not able to use yum update because there >is a dependency conflict regarding jms and this prevents me from >updating FC4 as well. So I am forced to move the jpackage repos >aside until this issue is resolved. > >Here is the yum update output: > >--> Running transaction check >--> Processing Dependency: jms for package: avalon-logkit >--> Finished Dependency Resolution >Error: Missing Dependency: jms is needed by package avalon-logkit > >Can anyone help? > >Thanks, >Dan Thurman > >-- >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.1.362 / Virus Database: 267.12.8/162 - Release >Date: 11/5/2005 > > > > >------------------------------ > >Message: 2 >Date: Wed, 9 Nov 2005 09:22:33 +0000 >From: Gary Benson >Subject: Re: [fedora-java] Using Yum Updates with Jpackage.org repos >To: "Fedora Java Development List (E-mail)" > >Message-ID: <20051109092230.GB5181 at redhat.com> >Content-Type: text/plain; charset=us-ascii > >Daniel B. Thurman wrote: >> Hi Folks, >> >> Got a problem. I stumbled onto this group (jpackage.org) when I >> wanted to install the JDK 5.0 on FC4 and in order to do that, part >> of the instructions was to install the jpackage repos for Yum. >> >> I was able to install the JDK 5.0 on FC4. Great! >> >> But unfortunately, I was not able to use yum update because there >> is a dependency conflict regarding jms and this prevents me from >> updating FC4 as well. So I am forced to move the jpackage repos >> aside until this issue is resolved. >> >> Here is the yum update output: >> >> --> Running transaction check >> --> Processing Dependency: jms for package: avalon-logkit >> --> Finished Dependency Resolution >> Error: Missing Dependency: jms is needed by package avalon-logkit >> >> Can anyone help? > >Downloading and installing geronimo-specs and geronimo-specs-compat >from rawhide should solve this. Option B would be to build and >install the jms package from JPackage. > >Cheers, >Gary > > Um, forgive me if I am dense, but can you give me some install instructions? I have no idea where "rawhide" is nor where to begin. I tried: yum install geronimo-specs and the jpackage repos are in the yum directory but it was not found. Kind regards, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/163 - Release Date: 11/8/2005 From fitzsim at redhat.com Wed Nov 9 21:15:44 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 09 Nov 2005 16:15:44 -0500 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat Message-ID: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> Hi, Making aot-compile-rpm and rebuild-gcj-db alternatives symlinks was obviously a mistake, but I think putting them in java-gcj-compat at all is also a mistake. I'm currently looking for other places to move them. A comment in aot-compile-rpm raises the possibility of including this script in RPM itself. Gary, do you think this is feasible in the FC5 time frame? I also propose removing rebuild-gcj-db and instead adding a --rebuild argument to gcj-dbtool that implements the current Fedora Core database management policy (which seems to work). Andrew and Tom, thoughts? The last gcj-specific script in our JPackage stack is rebuild-security-providers. I'd also like to get rid of it, but I'd like to know what others think first. I added rebuild-security-providers so that java security provider RPMs could easily make GCJ aware of the new provider. Ideally, JPackage would provide a JVM-neutral mechanism for this, but it seems like it would be a lot of work (i.e. you'd likely need to partition the available providers based on JVM vendor and version -- a global java.security file likely wouldn't work). Do people think it's worth having a gcj-specific script in jpackage-utils to make gcj aware of new security provider RPMs? Do the JPackage people reading this list know of a better, more general solution? (I'm not even sure it's worth worrying about this, since (the few existing) security provider packages could easily manually add/remove themselves to/from whichever java.security file they care about). Anyway, I was considering creating an intermediate java-gcj-compat-scripts package to handle these scripts but looking through them, I think it's better to get rid of them during the push to FC5. Doing so will solve the "missing rebuild-gcj-db" failures. Comments welcome, Tom From mckinlay at redhat.com Wed Nov 9 22:52:26 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Wed, 09 Nov 2005 17:52:26 -0500 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> Message-ID: <43727DAA.8000106@redhat.com> Thomas Fitzsimmons wrote: >I also propose removing rebuild-gcj-db and instead adding a --rebuild >argument to gcj-dbtool that implements the current Fedora Core database >management policy (which seems to work). Andrew and Tom, thoughts? > > I think thats a good idea. I see no reason why this shouldn't be rolled into gcj-dbtool (Andrew?). If needed for compatibility reasons, rebuild-gcj-db could be made to call "gcj-db --rebuild". >Anyway, I was considering creating an intermediate >java-gcj-compat-scripts package to handle these scripts but looking >through them, I think it's better to get rid of them during the push to >FC5. Doing so will solve the "missing rebuild-gcj-db" failures. > > I agree. The less packages the better, IMO. Bryce From david at zarb.org Thu Nov 10 03:41:55 2005 From: david at zarb.org (David Walluck) Date: Wed, 09 Nov 2005 22:41:55 -0500 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> Message-ID: <4372C183.6040908@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > A comment in aot-compile-rpm raises the possibility of including this > script in RPM itself. Gary, do you think this is feasible in the FC5 > time frame? Hi Tom. Gary has already gotten a portion of this process into rpm, only it's not being used by default. If we're going to put it in, we also need the logic to (easily) enable it in the macros file for a particular distribution, or better, from a particular .spec. I am disappointed that no one was interested in a discussion of moving the natifying outside of the specific rpm, but I have just given up on this idea. I certainly don't have the time or desire to implement it myself. But the issue here is that (1) any distro will be picking up the gcj policy so the script needs to be in rpm and usable (2) newer JPackage versions will trump (kill) the nativified versions. It is because of (2) that I think the FC ``solution'' is a very poor one, but given that I have accepted that, I have no problem with (1) if rpm proper has the support. Also, I thought aot-compile was a good script, but it was done away with. Wouldn't it make sense to bring this back and have a script that didn't rely on rpm, and then have rpm call this script instead? This way, not only other RPM-based distros, but possibly Debian or Ubuntu could even pick it up. > The last gcj-specific script in our JPackage stack is > rebuild-security-providers. I'd also like to get rid of it, but I'd > like to know what others think first. I don't see the harm in keeping it, but such a script might be useful upstream for either classpath or gcj, or both. Apparently, they don't share the same location for the classpath.security file (%{_prefix}/lib vs. %{_libdir}), but it makes sense to see what the people involved upstream think about this. By the way, I did modify the script to ignore certain obvious patterns: *.rpmsave|*.rpmorig|*.rpmnew|*~|*.orig|*.bak) ;; > I added rebuild-security-providers so that java security provider RPMs > could easily make GCJ aware of the new provider. Ideally, JPackage > would provide a JVM-neutral mechanism for this, but it seems like it > would be a lot of work (i.e. you'd likely need to partition the > available providers based on JVM vendor and version -- a global > java.security file likely wouldn't work). You have the right idea. This is the kind of thing we'd want in an ideal world. Really, there is no problem is not having a global java.security file, as it would be possible to rebuild these even on the fly provided java was always ``properly'' invoked through JPackage utils. But given that `java' is a binary, not a script, this can't work from the command-line. Finally, since providers need to be signed, JPackage can't even provide their own versions of providers for commercial Java environments. Let's turn away from our ideal world to the practical world. How many providers do we have anyway? The default gcj one would essentially always be there. We also have bouncycastle (I have package a pre-1.31 version, if anyone is interested). So what are the chances of the gcj provider database needing to be updated? What if the file were static? Can't a missing class be (silently) ignored? Then we could even have a static list. Just for reference, mine currently looks like: security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider security.provider.2=gnu.java.security.provider.Gnu security.provider.3=org.metastatic.jessie.provider.Jessie security.provider.4=gnu.crypto.jce.GnuCrypto Do we really foresee anymore? If there are, just update the classpath.security file once (the problem is which package should own it). Ordering is up to a distro I suppose. Bouncycastle is clearly the most complete. > Anyway, I was considering creating an intermediate > java-gcj-compat-scripts package to handle these scripts but looking > through them, I think it's better to get rid of them during the push to > FC5. Doing so will solve the "missing rebuild-gcj-db" failures. The key is that before we can do away with the scripts package, the aot-compile script must be in rpm proper, as more than just FC relies on them. The same goes for the gcc option, and a gcc release isn't happening right away. In short, we need the scripts package for the time being. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDcsGCarJDwJ6gwowRAj3QAJ42Q4Ovjmaj+1HPsxNzZhpVpBEvAACeOgCn GPS79FIDvT4kikugfV4ciNg= =f0SP -----END PGP SIGNATURE----- From i.pilcher at comcast.net Thu Nov 10 07:31:55 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 10 Nov 2005 01:31:55 -0600 Subject: [fedora-java] Thoughts on JPackage, Fedora Core, gcj, etc. Message-ID: Something that's been bouncing around in my head for awhile now... What do folks think of adding an additional "provides" to packages that provide gcj libraries. The Fedora Core version of tomcat5, for example, could provide "tomcat5(gcj)" or "gcj(tomcat5)", presumably versioned. This wouldn't do anything by itself, but it would give higher level tools, such as yum, the information needed to apply the policies set by system administrators -- prefering the latest version, prefering gcj versions, etc. Thoughts? -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From gbenson at redhat.com Thu Nov 10 09:57:14 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 10 Nov 2005 09:57:14 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <43727DAA.8000106@redhat.com> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <43727DAA.8000106@redhat.com> Message-ID: <20051110095710.GC4724@redhat.com> Bryce McKinlay wrote: > Thomas Fitzsimmons wrote: > > I also propose removing rebuild-gcj-db and instead adding a > > --rebuild argument to gcj-dbtool that implements the current > > Fedora Core database management policy (which seems to work). > > Andrew and Tom, thoughts? > > I think thats a good idea. I see no reason why this shouldn't be > rolled into gcj-dbtool (Andrew?). If needed for compatibility > reasons, rebuild-gcj-db could be made to call "gcj-db --rebuild". There would have to be a %{_bindir}/rebuild-gcj-db in whatever provides gcj-db as without it none of the existing rpms could be uninstalled or upgraded. Cheers, Gary From aph at redhat.com Thu Nov 10 10:59:37 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Nov 2005 10:59:37 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <4372C183.6040908@zarb.org> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> Message-ID: <17267.10265.472198.837403@zapata.pink> David Walluck writes: > Also, I thought aot-compile was a good script, but it was done away > with. Wouldn't it make sense to bring this back and have a script that > didn't rely on rpm, and then have rpm call this script instead? This > way, not only other RPM-based distros, but possibly Debian or Ubuntu > could even pick it up. aot-compile-rpm doesn't rely on RPM at all -- it's just REALLY badly named! :-) Andrew. From gbenson at redhat.com Thu Nov 10 11:26:44 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 10 Nov 2005 11:26:44 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <17267.10265.472198.837403@zapata.pink> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> <17267.10265.472198.837403@zapata.pink> Message-ID: <20051110112641.GE4724@redhat.com> Andrew Haley wrote: > David Walluck writes: > > Also, I thought aot-compile was a good script, but it was done > > away with. Wouldn't it make sense to bring this back and have a > > script that didn't rely on rpm, and then have rpm call this script > > instead? This way, not only other RPM-based distros, but possibly > > Debian or Ubuntu could even pick it up. > > aot-compile-rpm doesn't rely on RPM at all -- it's just REALLY badly > named! :-) Not strictly true. It does have RPM-specific bits, but they're very very small: 10 lines out of 436. I spoke to some of the Debian and Ubuntu guys at DevJam about abstracting it but that's difficult to do whilst it's alternatives-managed. Of course, doing this would make rpm a particularly bad home for it. The obvious place is in gcc itself (and aot-compile-rpm itself could either go there or in rpm) but that would mean being tied to gcc's necessarily slow release cycle. Maybe the solution is having aot-compile-* in its own package. It seems overkill though... Cheers, Gary From aph at redhat.com Thu Nov 10 11:38:45 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Nov 2005 11:38:45 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <20051110112641.GE4724@redhat.com> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> <17267.10265.472198.837403@zapata.pink> <20051110112641.GE4724@redhat.com> Message-ID: <17267.12613.677648.15041@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > David Walluck writes: > > > Also, I thought aot-compile was a good script, but it was done > > > away with. Wouldn't it make sense to bring this back and have a > > > script that didn't rely on rpm, and then have rpm call this script > > > instead? This way, not only other RPM-based distros, but possibly > > > Debian or Ubuntu could even pick it up. > > > > aot-compile-rpm doesn't rely on RPM at all -- it's just REALLY badly > > named! :-) > > Not strictly true. It does have RPM-specific bits, but they're very > very small: 10 lines out of 436. I spoke to some of the Debian and > Ubuntu guys at DevJam about abstracting it but that's difficult to do > whilst it's alternatives-managed. > > Of course, doing this would make rpm a particularly bad home for it. > The obvious place is in gcc itself (and aot-compile-rpm itself could > either go there or in rpm) but that would mean being tied to gcc's > necessarily slow release cycle. gcc doesn't seem to be having a very slow release cycle at the moment: we've seen GCC 4.0.2 in September, GCC 4.0.1 in July and GCC 4.0.0 in April. I can't see any good reason not to move aot-compile-* to gcc, with a view eventially to make it unnecessary by folding all its functions into gcj itself. Andrew. From green at redhat.com Thu Nov 10 11:37:09 2005 From: green at redhat.com (Anthony Green) Date: Thu, 10 Nov 2005 03:37:09 -0800 Subject: [fedora-java] Thoughts on JPackage, Fedora Core, gcj, etc. In-Reply-To: References: Message-ID: <1131622630.3321.8.camel@localhost.localdomain> On Thu, 2005-11-10 at 01:31 -0600, Ian Pilcher wrote: > What do folks think of adding an additional "provides" to packages that > provide gcj libraries. The Fedora Core version of tomcat5, for example, > could provide "tomcat5(gcj)" or "gcj(tomcat5)", presumably versioned. > > This wouldn't do anything by itself, but it would give higher level > tools, such as yum, the information needed to apply the policies set by > system administrators -- prefering the latest version, prefering gcj > versions, etc. I'm kind of clueless in this area. Can you give an example of how these tags would be used? AG From david at zarb.org Thu Nov 10 11:37:02 2005 From: david at zarb.org (David Walluck) Date: Thu, 10 Nov 2005 06:37:02 -0500 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <20051110112641.GE4724@redhat.com> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> <17267.10265.472198.837403@zapata.pink> <20051110112641.GE4724@redhat.com> Message-ID: <437330DE.1040205@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > Maybe the solution is having aot-compile-* in its own package. It > seems overkill though... I would say that they could be part of jpackage-utils if there is no other home for them. Sure, they do happen to be gcc-specifc, but at least they should be arch-agnostic. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDczDearJDwJ6gwowRAuX2AJ418eL2JKW1KDigJcYkERpoSeiH2gCeJNst SAqh2SkOqr4blyX9bMo2uRU= =92r0 -----END PGP SIGNATURE----- From gbenson at redhat.com Thu Nov 10 11:40:06 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 10 Nov 2005 11:40:06 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <4372C183.6040908@zarb.org> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> Message-ID: <20051110114002.GF4724@redhat.com> David Walluck wrote: > Thomas Fitzsimmons wrote: > > A comment in aot-compile-rpm raises the possibility of including > > this script in RPM itself. Gary, do you think this is feasible in > > the FC5 time frame? > > Gary has already gotten a portion of this process into rpm, only > it's not being used by default. If we're going to put it in, we also > need the logic to (easily) enable it in the macros file for a > particular distribution, or better, from a particular .spec. > > I am disappointed that no one was interested in a discussion of > moving the natifying outside of the specific rpm, but I have just > given up on this idea. I certainly don't have the time or desire to > implement it myself. Having natifying outside of specific rpms was my original intention: https://lists.dulug.duke.edu/pipermail/rpm-devel/2005-July/000507.html Indeed, aot-compile-rpm was specifically designed to be used in the same way as brp-python-bytecompile, though the --exclude option that everyone loves except me has broken this somewhat. The problem with this is as I outlined in the above email, in that there are five things that need to happen for transparent native compilation, of which aot-compile-rpm is just one step (and the simplest at that). The two most tricky steps (adding %post/%postun scripts, and adding dependencies for same) were the ones I really wanted to automate, but Jeff Johnson's solutions were basically "do it manually". Cheers, Gary From gbenson at redhat.com Thu Nov 10 11:49:34 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 10 Nov 2005 11:49:34 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <17267.12613.677648.15041@zapata.pink> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> <17267.10265.472198.837403@zapata.pink> <20051110112641.GE4724@redhat.com> <17267.12613.677648.15041@zapata.pink> Message-ID: <20051110114931.GG4724@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > The obvious place is in gcc itself (and aot-compile-rpm itself > > could either go there or in rpm) but that would mean being tied > > to gcc's necessarily slow release cycle. > > gcc doesn't seem to be having a very slow release cycle at the > moment: we've seen GCC 4.0.2 in September, GCC 4.0.1 in July and > GCC 4.0.0 in April. I meant the rpm. At the moment I can change a-c-r and push the packages out myself: I can't do that for gcc, and I'd have to wait the two weeks to a month until the next gcc rpm was built. Cheers, Gary From gbenson at redhat.com Thu Nov 10 11:51:31 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 10 Nov 2005 11:51:31 +0000 Subject: [fedora-java] Thoughts on JPackage, Fedora Core, gcj, etc. In-Reply-To: References: Message-ID: <20051110115128.GH4724@redhat.com> Ian Pilcher wrote: > What do folks think of adding an additional "provides" to packages > that provide gcj libraries. The Fedora Core version of tomcat5, for > example, could provide "tomcat5(gcj)" or "gcj(tomcat5)", presumably > versioned. If aot-compile-rpm did end up integrated in rpm then these dependencies could be added automatically. The alternative (adding them manually) is too painful to think about. Cheers, Gary From gbenson at redhat.com Thu Nov 10 11:53:44 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 10 Nov 2005 11:53:44 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <437330DE.1040205@zarb.org> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> <17267.10265.472198.837403@zapata.pink> <20051110112641.GE4724@redhat.com> <437330DE.1040205@zarb.org> Message-ID: <20051110115342.GI4724@redhat.com> David Walluck wrote: > Gary Benson wrote: > > Maybe the solution is having aot-compile-* in its own package. It > > seems overkill though... > > I would say that they could be part of jpackage-utils if there is no > other home for them. Sure, they do happen to be gcc-specifc, but at > least they should be arch-agnostic. Now there's an idea. It'd introduce a dependency on Python, though. I know it's nigh-on impossible to install a Fedora system without Python, so it's no big deal for us, but does the same apply for SuSE and Mandrake? Cheers, Gary From i.pilcher at comcast.net Thu Nov 10 15:46:02 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 10 Nov 2005 09:46:02 -0600 Subject: [fedora-java] Re: Thoughts on JPackage, Fedora Core, gcj, etc. In-Reply-To: <1131622630.3321.8.camel@localhost.localdomain> References: <1131622630.3321.8.camel@localhost.localdomain> Message-ID: Anthony Green wrote: > > I'm kind of clueless in this area. Can you give an example of how these > tags would be used? > The idea is to enable system administrators to define policies for JPackage/Fedora Core co-existence. For example, one administrator may prefer to always have the latest version of the underlying package; another may prefer to always have the gcj version, if available. There's currently no way for yum, or similar tools, to distinguish gcj packages from non-gcj packages. This would only be a first step, but I think it's a necessary step. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From fitzsim at redhat.com Thu Nov 10 16:08:32 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Nov 2005 11:08:32 -0500 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <20051110112641.GE4724@redhat.com> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> <17267.10265.472198.837403@zapata.pink> <20051110112641.GE4724@redhat.com> Message-ID: <1131638912.5716.1.camel@rh-ibm-t41> On Thu, 2005-11-10 at 11:26 +0000, Gary Benson wrote: > Andrew Haley wrote: > > David Walluck writes: > > > Also, I thought aot-compile was a good script, but it was done > > > away with. Wouldn't it make sense to bring this back and have a > > > script that didn't rely on rpm, and then have rpm call this script > > > instead? This way, not only other RPM-based distros, but possibly > > > Debian or Ubuntu could even pick it up. > > > > aot-compile-rpm doesn't rely on RPM at all -- it's just REALLY badly > > named! :-) > > Not strictly true. It does have RPM-specific bits, but they're very > very small: 10 lines out of 436. I spoke to some of the Debian and > Ubuntu guys at DevJam about abstracting it but that's difficult to do > whilst it's alternatives-managed. Making aot-compile-rpm alternatives-managed was a mistake on my part, and one of the reasons I started this discussion. Tom From gbenson at redhat.com Thu Nov 10 16:07:26 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 10 Nov 2005 16:07:26 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <1131638912.5716.1.camel@rh-ibm-t41> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> <17267.10265.472198.837403@zapata.pink> <20051110112641.GE4724@redhat.com> <1131638912.5716.1.camel@rh-ibm-t41> Message-ID: <20051110160723.GM4724@redhat.com> Thomas Fitzsimmons wrote: > On Thu, 2005-11-10 at 11:26 +0000, Gary Benson wrote: > > I spoke to some of the Debian and Ubuntu guys at DevJam about > > abstracting it but that's difficult to do whilst it's > > alternatives-managed. > > Making aot-compile-rpm alternatives-managed was a mistake on my > part, and one of the reasons I started this discussion. Yeah. I wasn't having a dig or anything (sorry if it sounded like it). I understand why you did it and stuff. Cheers, Gary From fitzsim at redhat.com Thu Nov 10 16:35:35 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Nov 2005 11:35:35 -0500 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <20051110160723.GM4724@redhat.com> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <4372C183.6040908@zarb.org> <17267.10265.472198.837403@zapata.pink> <20051110112641.GE4724@redhat.com> <1131638912.5716.1.camel@rh-ibm-t41> <20051110160723.GM4724@redhat.com> Message-ID: <1131640535.5716.5.camel@rh-ibm-t41> On Thu, 2005-11-10 at 16:07 +0000, Gary Benson wrote: > Thomas Fitzsimmons wrote: > > On Thu, 2005-11-10 at 11:26 +0000, Gary Benson wrote: > > > I spoke to some of the Debian and Ubuntu guys at DevJam about > > > abstracting it but that's difficult to do whilst it's > > > alternatives-managed. > > > > Making aot-compile-rpm alternatives-managed was a mistake on my > > part, and one of the reasons I started this discussion. > > Yeah. I wasn't having a dig or anything (sorry if it sounded like > it). Nah, I was just making sure you knew this wasn't still a design constraint. Tom From fitzsim at redhat.com Thu Nov 10 17:36:04 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Nov 2005 12:36:04 -0500 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <20051110095710.GC4724@redhat.com> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <43727DAA.8000106@redhat.com> <20051110095710.GC4724@redhat.com> Message-ID: <1131644164.5716.19.camel@rh-ibm-t41> On Thu, 2005-11-10 at 09:57 +0000, Gary Benson wrote: > Bryce McKinlay wrote: > > Thomas Fitzsimmons wrote: > > > I also propose removing rebuild-gcj-db and instead adding a > > > --rebuild argument to gcj-dbtool that implements the current > > > Fedora Core database management policy (which seems to work). > > > Andrew and Tom, thoughts? > > > > I think thats a good idea. I see no reason why this shouldn't be > > rolled into gcj-dbtool (Andrew?). If needed for compatibility > > reasons, rebuild-gcj-db could be made to call "gcj-db --rebuild". > > There would have to be a %{_bindir}/rebuild-gcj-db in whatever > provides gcj-db as without it none of the existing rpms could be > uninstalled or upgraded. With rebuild-gcj-db as an alternative I'm not sure this is even possible now (especially if gcj is not the currently-selected alternative). I think we can get away with "breaking backwards compatibility" here in the interest of not maintaining a "rebuild-gcj-db" script indefinitely. Tom From fitzsim at redhat.com Thu Nov 10 18:06:51 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Nov 2005 13:06:51 -0500 Subject: [fedora-java] Followup: aot-compile-rpm, rebuild-gcj-db and rebuild-security-providers Message-ID: <1131646012.5716.47.camel@rh-ibm-t41> Hi, Based on the discussions on this list as well as a phone discussion we just had, here are the plans for these scripts: aot-compile-rpm --------------- We're going to put the logic from this script upstream in the GCC repository. Gary is going to split it into a package-format agnostic "aot-compile" script and an RPM-specific fragment for gleaning settings from an RPM build environment. This location for the "natively compile a set of jars" logic has two advantages: aot-compile can be conveniently reused by other packaging systems (e.g. Debian, Gentoo) and the logic can be conveniently merged bit-by-bit into the gcj front-end itself where it belongs. One downside is the longer release cycle for the GCC RPM but this script is now in bug-fix mode so release frequency isn't as important. rebuild-gcj-db -------------- This script's logic will be moved into a gcj-dbtool --rebuild option. I'm going to suggest we break compatibility (technically) by not providing a replacement rebuild-gcj-db script for use by old RPMS, just in the interest of not maintaining an extra script indefinitely. We haven't decided yet who will do this work; Andrew Haley? rebuild-security-providers -------------------------- I'm going to remove this script from jpackage-utils. I agree with David Walluck's argument that there aren't enough security provider RPMs available to warrant an extra script (and divergence from upstream jpackage-utils). Until Jesse and GNU Crypto are merged into GNU Classpath I'll simply in- line the logic in rebuild-security-providers in those packages. I'm hoping to have them merged before Fedora Core 5 anyway. Tom From fnasser at redhat.com Thu Nov 10 22:01:21 2005 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 10 Nov 2005 17:01:21 -0500 Subject: [fedora-java] Enhanced aot-compile script Message-ID: <4373C331.4030501@redhat.com> Hi, I was thinking of having a 'aot-compile' command that would perform all tasks related to aot compilation. For instance: aot-compile by itself would perform the additional compilation steps necessary to generate the .so files etc., as currently done. aot-compile --rebuilddb would do the rebuild-gcj-db thing aot-compile --install would allow a conditional installation step and so forth. In addition to that, 'aot-compile' would either work or be a no-op, depending on certain conditions, like the presence of GCJ in the system, and/or some system-wide or local override configuration mechanism. This way, aot-compile statements can be added to an RPM spec file and that same spec file can be used to build bytecode or pre-compiled RPMs, depending on the settings. Adding just this script to jpackage-utils would allow us to eliminate differences between the spec files upstream and in other distros, except for having to remove the "BuildArch: noarch" line. It seems that there are a few cases to consider: 1) gcj is not installed ==> automatic ==> do not precompile 2) gcj is installed, but we don't want to pre-compile ==> override with either system or local config (we could test for "BuildArch: noarch"...) ==> do not precompile 3) gcj is installed, and we want to pre-compile ==> automatic ==> precompile There are perhaps some other conditions, like you want to build the bytecode with another Java and then use gcj to pre-compile... IMPORTANT: please note that aot-compile should not be tied to GCJ, but instead be a characteristic of any Java that is capable of pre-compilation. QUESTION: how to accommodate the differences in pre-compilation mechanisms? In any case, we should try and keep the command names generic so if necessary one day the JVMs that are AOT-capable can provide alternatives for those. Regards to all, Fernando From fitzsim at redhat.com Thu Nov 10 22:37:54 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Nov 2005 17:37:54 -0500 Subject: [fedora-java] external references to JPackage Bugzilla Message-ID: <1131662274.23505.16.camel@tortoise.toronto.redhat.com> Hi, I had Dave Lawrence add jpackage.org/bugzilla to our "External Bugzillas" list. Here's an example of its use: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160327 Tom From fitzsim at redhat.com Thu Nov 10 22:49:57 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 10 Nov 2005 17:49:57 -0500 Subject: [fedora-java] gcj-dbtool --rebuild Message-ID: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> Hi, Here's what "gcj-dbtool --rebuild" needs to do: Merge all db files in "$prefix/lib/gcj-$gcc_version/classmap.db.d/" into "$prefix/lib/gcj-$gcc_version/classmap.db". Even better for FC5 would be eliminating the need for individual .db files altogether. We could have "gcj-dbtool --rebuild" compare the .sos in /usr/lib with the database contents and add/remove any new/missing entries to/from classmap.db. Shipping a .db file per package is one divergence from JPackage spec files that Fernando's proposal doesn't address but that an improved gcj-dbtool would. Tom From david at zarb.org Fri Nov 11 01:20:42 2005 From: david at zarb.org (David Walluck) Date: Thu, 10 Nov 2005 20:20:42 -0500 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <1131644164.5716.19.camel@rh-ibm-t41> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <43727DAA.8000106@redhat.com> <20051110095710.GC4724@redhat.com> <1131644164.5716.19.camel@rh-ibm-t41> Message-ID: <4373F1EA.6010206@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > With rebuild-gcj-db as an alternative I'm not sure this is even possible > now (especially if gcj is not the currently-selected alternative). I > think we can get away with "breaking backwards compatibility" here in > the interest of not maintaining a "rebuild-gcj-db" script indefinitely. It could have been fixed if it wasn't called unconditionally: %post if [ -x %{_bindir}/rebuild-gcj-db ]; then %{_bindir}/rebuild-gcj-db fi Unfortunately, now that the damage has been done, some manual intervention is likely necessary, since you can't uninstall, so the upgrade will fail. Or, you could install with `rpm --noscripts' (unless this only applied to the current package). - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDc/HqarJDwJ6gwowRAk1IAJ9ZHE0PsgetfuifFv+2It+Cms4whQCffv0u aqzJNQkzYmkq8p3Gn5S8qHo= =eicG -----END PGP SIGNATURE----- From david at zarb.org Fri Nov 11 01:38:56 2005 From: david at zarb.org (David Walluck) Date: Thu, 10 Nov 2005 20:38:56 -0500 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <4373C331.4030501@redhat.com> References: <4373C331.4030501@redhat.com> Message-ID: <4373F630.8030304@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Nasser wrote: > IMPORTANT: please note that aot-compile should not be tied to GCJ, but > instead be a characteristic of any Java that is capable of > pre-compilation. QUESTION: how to accommodate the differences in > pre-compilation mechanisms? In any case, we should try and keep the > command names generic so if necessary one day the JVMs that are > AOT-capable can provide alternatives for those. I am glad you realized this. I was going to mention to the FC guys that, for example, kaffe has talked about supporting aot. If you have kaffe, you don't necessary need/want to use gcj. With the integration into rpm, would it be possible to produce the gcj support as a separate package such that upgrades from JPackage to not trump it. All we need for this to work is to make sure we don't have any %{version}-%{release} requirements in JPackage and instead stick to %{version}. At least using this method release updates could be accomplished. I don't know enough about the situation of differing versions at this time. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDc/YwarJDwJ6gwowRAjYfAJ0UItAT3e/mG2LfFPQqN+UpS9Mb3gCgmk08 CRHk/fMoWmQPdsPbeTm1vlw= =1dIi -----END PGP SIGNATURE----- From gbenson at redhat.com Fri Nov 11 08:38:43 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 08:38:43 +0000 Subject: [fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat In-Reply-To: <1131644164.5716.19.camel@rh-ibm-t41> References: <1131570944.12772.135.camel@tortoise.toronto.redhat.com> <43727DAA.8000106@redhat.com> <20051110095710.GC4724@redhat.com> <1131644164.5716.19.camel@rh-ibm-t41> Message-ID: <20051111083840.GA4972@redhat.com> Thomas Fitzsimmons wrote: > On Thu, 2005-11-10 at 09:57 +0000, Gary Benson wrote: > > Bryce McKinlay wrote: > > > If needed for compatibility reasons, rebuild-gcj-db could be > > > made to call "gcj-db --rebuild". > > > > There would have to be a %{_bindir}/rebuild-gcj-db in whatever > > provides gcj-db as without it none of the existing rpms could be > > uninstalled or upgraded. > > With rebuild-gcj-db as an alternative I'm not sure this is even > possible now (especially if gcj is not the currently-selected > alternative). I think we can get away with "breaking backwards > compatibility" here in the interest of not maintaining a > "rebuild-gcj-db" script indefinitely. It doesn't have to be indefinite, but it will have to be there for FC5 and probably FC6 at least: without it upgrades from FC4 will fail and releng will kick our ass. Gary From gbenson at redhat.com Fri Nov 11 08:48:12 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 08:48:12 +0000 Subject: [fedora-java] Followup: aot-compile-rpm, rebuild-gcj-db and rebuild-security-providers In-Reply-To: <1131646012.5716.47.camel@rh-ibm-t41> References: <1131646012.5716.47.camel@rh-ibm-t41> Message-ID: <20051111084809.GB4972@redhat.com> Thomas Fitzsimmons wrote: > rebuild-gcj-db > -------------- > > This script's logic will be moved into a gcj-dbtool --rebuild option. While we're changing things here I'd like to propose that the global database be moved from /usr/lib/gcj-x.y.z/classmap.db to somewhere like /var/lib/gcj/classmap.db. Unlike the per-package files the the global database is machine-specific, so putting it in /var makes us more LSB-compliant. One practical advantage of this is that it would allow our rpms to be used on systems with readonly /usr partitions. Cheers, Gary From aph at redhat.com Fri Nov 11 11:05:23 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Nov 2005 11:05:23 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <4373C331.4030501@redhat.com> References: <4373C331.4030501@redhat.com> Message-ID: <17268.31475.320375.369173@zapata.pink> The way this traditionally works in UNIX is by using `make'. For example, to rebuild the mail database you simply go to /etc/mail and type make which does whatever is necessary. Why not do it this way with gcj's dependencies? Just go into /var/lib/gcj and run make? The makefile can then do everything that is necessary, using make's dependency analysis. Andrew. From gbenson at redhat.com Fri Nov 11 11:33:36 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 11:33:36 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17268.31475.320375.369173@zapata.pink> References: <4373C331.4030501@redhat.com> <17268.31475.320375.369173@zapata.pink> Message-ID: <20051111113335.GF4972@redhat.com> Andrew Haley wrote: > The way this traditionally works in UNIX is by using `make'. > > For example, to rebuild the mail database you simply go to /etc/mail > and type > > make > > which does whatever is necessary. > > Why not do it this way with gcj's dependencies? Just go into > /var/lib/gcj and run make? The makefile can then do > everything that is necessary, using make's dependency analysis. That's fine for sendmail, where everything in /etc/mail is owned by sendmail. GCJ can't know in advance what will be in /usr/lib/gcj, so such a makefile would need to be edited or generated by something. Instead of having a script to build a database, we'd end up with a script to build a makefile that'd build a database. Cheers, Gary From aph at redhat.com Fri Nov 11 11:38:36 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Nov 2005 11:38:36 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051111113335.GF4972@redhat.com> References: <4373C331.4030501@redhat.com> <17268.31475.320375.369173@zapata.pink> <20051111113335.GF4972@redhat.com> Message-ID: <17268.33468.213354.515878@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > The way this traditionally works in UNIX is by using `make'. > > > > For example, to rebuild the mail database you simply go to /etc/mail > > and type > > > > make > > > > which does whatever is necessary. > > > > Why not do it this way with gcj's dependencies? Just go into > > /var/lib/gcj and run make? The makefile can then do > > everything that is necessary, using make's dependency analysis. > > That's fine for sendmail, where everything in /etc/mail is owned by > sendmail. GCJ can't know in advance what will be in /usr/lib/gcj, so > such a makefile would need to be edited or generated by something. I don't think so. All the makefile has to know is that the master db depends on *.db and *.so in some directory. Andrew. From gbenson at redhat.com Fri Nov 11 11:52:41 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 11:52:41 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17268.33468.213354.515878@zapata.pink> References: <4373C331.4030501@redhat.com> <17268.31475.320375.369173@zapata.pink> <20051111113335.GF4972@redhat.com> <17268.33468.213354.515878@zapata.pink> Message-ID: <20051111115238.GG4972@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > The way this traditionally works in UNIX is by using `make'. > > > > > > For example, to rebuild the mail database you simply go to > > > /etc/mail and type > > > > > > make > > > > > > which does whatever is necessary. > > > > > > Why not do it this way with gcj's dependencies? Just go into > > > /var/lib/gcj and run make? The makefile can then do > > > everything that is necessary, using make's dependency analysis. > > > > That's fine for sendmail, where everything in /etc/mail is owned by > > sendmail. GCJ can't know in advance what will be in /usr/lib/gcj, so > > such a makefile would need to be edited or generated by something. > > I don't think so. All the makefile has to know is that the master > db depends on *.db and *.so in some directory. How would it cope with file deletions? If we uninstall a rpm then its entries should be removed from the master database. Cheers, Gary From aph at redhat.com Fri Nov 11 12:03:04 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Nov 2005 12:03:04 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051111115238.GG4972@redhat.com> References: <4373C331.4030501@redhat.com> <17268.31475.320375.369173@zapata.pink> <20051111113335.GF4972@redhat.com> <17268.33468.213354.515878@zapata.pink> <20051111115238.GG4972@redhat.com> Message-ID: <17268.34936.249561.46733@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Andrew Haley wrote: > > > > The way this traditionally works in UNIX is by using `make'. > > > > > > > > For example, to rebuild the mail database you simply go to > > > > /etc/mail and type > > > > > > > > make > > > > > > > > which does whatever is necessary. > > > > > > > > Why not do it this way with gcj's dependencies? Just go into > > > > /var/lib/gcj and run make? The makefile can then do > > > > everything that is necessary, using make's dependency analysis. > > > > > > That's fine for sendmail, where everything in /etc/mail is owned by > > > sendmail. GCJ can't know in advance what will be in /usr/lib/gcj, so > > > such a makefile would need to be edited or generated by something. > > > > I don't think so. All the makefile has to know is that the master > > db depends on *.db and *.so in some directory. > > How would it cope with file deletions? Use the directory as a dependency. Any deletions will cause the directory to be touched. ------------------------------------------------------------------------ bar: foo echo "update" touch bar ------------------------------------------------------------------------ $ mkdir foo $ touch foo/baz $ make echo "update" update touch bar $ make make: `bar' is up to date. $ rm foo/baz $ make echo "update" update touch bar Andrew. From gbenson at redhat.com Fri Nov 11 13:00:24 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 13:00:24 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <4373C331.4030501@redhat.com> References: <4373C331.4030501@redhat.com> Message-ID: <20051111130021.GH4972@redhat.com> Fernando Nasser wrote: > I was thinking of having a 'aot-compile' command that would perform > all tasks related to aot compilation. > > For instance: > > aot-compile > > by itself would perform the additional compilation steps necessary to > generate the .so files etc., as currently done. [snip] > > aot-compile --install > > would allow a conditional installation step > > and so forth. Firstly, a minor point. I guess you want this so that the former can go in %build and the latter can go in %install? I wanted to do this anyway, but separating the process turns out to be a nightmare because what's in the build tree after %build is almost never anything like what's in the install tree after %install. Not everything is copied over, and what is is almost always renamed. FWIW katana _was_ split in this way: packages frequently required tens of options just to tell it what was going to be installed where. It was awful... > In addition to that, 'aot-compile' would either work or be a no-op, > depending on certain conditions, like the presence of GCJ in the > system, and/or some system-wide or local override configuration > mechanism. The fact that aot-compiled rpms have more files than their uncompiled equivalents will make this far less neat than you perhaps think. Each package will need a conditional block in its %files list. It's not something that can be done simply with globs. That aside, having the database rebuilding as an alternative (so possibly a no-op) would also cause problems. Imagine this: 1. User has GCJ as their JVM. 2. a) User installs some Fedora packages. b) GCJ database is rebuilt into a consistent state. 3. User switches to some other JVM. 4. a) User installs some more Fedora packages. b) GCJ database is not rebuilt. 5. User switches to GCJ as their JVM. The user has ended up with a broken database. His applications will be slower, and in some (admittedly broken) cases will suddenly start to fail. Rather than being an alternative, the rebuild command would need to rebuild all databases that could be installed on the system. This could be done by for example having all JVMs drop scripts in some database, and having 'aot-compile --rebuild' or whatever call them all in turn. > It seems that there are a few cases to consider: > > 1) gcj is not installed ==> automatic ==> do not precompile > > 2) gcj is installed, but we don't want to pre-compile ==> override > with either system or local config (we could test for "BuildArch: > noarch"...) ==> do not precompile That's certainly possible: aot-compile-rpm already checks your BuildArch. > IMPORTANT: please note that aot-compile should not be tied to GCJ, > but instead be a characteristic of any Java that is capable of > pre-compilation. Sure. This doesn't preclude us from putting the present, GCJ-specific aot-compile-rpm into the gcc-java rpm, and I still think we should proceed with this. > In any case, we should try and keep the command names generic so if > necessary one day the JVMs that are AOT-capable can provide > alternatives for those. How about making them even more generic and mandating that all JPackage rpms call certain scripts at certain points. At the end of %install, for example, you could require that all packages invoke jpackage-install, and similarly %post would have jpackage-post and %postun would have jpackage-postun. Each script could do both generic JPackage stuff and call specific JVM stuff. Under your system jpackage-install would call aot-compile-rpm if GCJ was selected as your JVM, and jpackage-post and -postun would do the database rebuilding. The scripts could do allsorts: the %prep script jpackage-prep could check for bundled jars and classes for example. Cheers, Gary From aph at redhat.com Fri Nov 11 13:08:25 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Nov 2005 13:08:25 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051111130021.GH4972@redhat.com> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> Message-ID: <17268.38857.369578.811397@zapata.pink> Gary Benson writes: > That aside, having the database rebuilding as an alternative (so > possibly a no-op) would also cause problems. Imagine this: > > 1. User has GCJ as their JVM. > 2. a) User installs some Fedora packages. > b) GCJ database is rebuilt into a consistent state. > 3. User switches to some other JVM. > 4. a) User installs some more Fedora packages. > b) GCJ database is not rebuilt. > 5. User switches to GCJ as their JVM. > > The user has ended up with a broken database. His applications will > be slower, and in some (admittedly broken) cases will suddenly start > to fail. > > Rather than being an alternative, the rebuild command would need to > rebuild all databases that could be installed on the system. This > could be done by for example having all JVMs drop scripts in some > database, and having 'aot-compile --rebuild' or whatever call them all > in turn. Use make. If any .db files are added or altered, the .db gets rebuilt. If they aren't, it isn't. The makefile contains the commands that do the right thing. make is designed to solve this kind of problem. Andrew. From gbenson at redhat.com Fri Nov 11 13:39:22 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 13:39:22 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17268.38857.369578.811397@zapata.pink> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> Message-ID: <20051111133918.GI4972@redhat.com> Andrew Haley wrote: > Use make. If any .db files are added or altered, the .db gets > rebuilt. If they aren't, it isn't. The makefile contains the > commands that do the right thing. > > make is designed to solve this kind of problem. Can you write a makefile to do this? I've never been able to figure out how to do multiple directory stuff :-/ Cheers, Gary From gbenson at redhat.com Fri Nov 11 13:44:20 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 13:44:20 +0000 Subject: [fedora-java] gcj-dbtool --rebuild In-Reply-To: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> References: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> Message-ID: <20051111134417.GJ4972@redhat.com> Thomas Fitzsimmons wrote: > Here's what "gcj-dbtool --rebuild" needs to do: > > Merge all db files in "$prefix/lib/gcj-$gcc_version/classmap.db.d/" into > "$prefix/lib/gcj-$gcc_version/classmap.db". > > Even better for FC5 would be eliminating the need for individual .db > files altogether. This would require the hashes to be stored in the .so, which I don't think they are at present. Is this something which is possible? Also, the per-package databases are in $prefix/lib/gcj/$name these days. Cheers, Gary From gbenson at redhat.com Fri Nov 11 13:47:45 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 13:47:45 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <4373F630.8030304@zarb.org> References: <4373C331.4030501@redhat.com> <4373F630.8030304@zarb.org> Message-ID: <20051111134743.GK4972@redhat.com> David Walluck wrote: > Fernando Nasser wrote: > > IMPORTANT: please note that aot-compile should not be tied to GCJ, > > but instead be a characteristic of any Java that is capable of > > pre-compilation. > > I am glad you realized this. I was going to mention to the FC guys > that, for example, kaffe has talked about supporting aot. If you > have kaffe, you don't necessary need/want to use gcj. Well, if anything the aot supported by Kaffe will be GCJ's, so you'll need GCJ for compilation at any rate. > With the integration into rpm, would it be possible to... Sadly, close integration with rpm can not happen without a serious change of heart on behalf of the rpm maintainers. Cheers, Gary From aph at redhat.com Fri Nov 11 15:00:44 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Nov 2005 15:00:44 +0000 Subject: [fedora-java] gcj-dbtool --rebuild In-Reply-To: <20051111134417.GJ4972@redhat.com> References: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> <20051111134417.GJ4972@redhat.com> Message-ID: <17268.45596.68211.922825@zapata.pink> Gary Benson writes: > Thomas Fitzsimmons wrote: > > Here's what "gcj-dbtool --rebuild" needs to do: > > > > Merge all db files in "$prefix/lib/gcj-$gcc_version/classmap.db.d/" into > > "$prefix/lib/gcj-$gcc_version/classmap.db". > > > > Even better for FC5 would be eliminating the need for individual .db > > files altogether. > > This would require the hashes to be stored in the .so, which I don't > think they are at present. Is this something which is possible? Yes. It is part of the Grand Plan. But reading the hashes out of a .so is going to be far slower than out of a .db. It wouldn't be practical if you had thousands of them. Andrew. From aph at redhat.com Fri Nov 11 15:16:55 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Nov 2005 15:16:55 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051111133918.GI4972@redhat.com> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> Message-ID: <17268.46567.468637.320940@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Use make. If any .db files are added or altered, the .db gets > > rebuilt. If they aren't, it isn't. The makefile contains the > > commands that do the right thing. > > > > make is designed to solve this kind of problem. > > Can you write a makefile to do this? I've never been able to figure > out how to do multiple directory stuff :-/ Yes, but I'm not about to do it right now until we've agreed precisely what it is supposed to do. Besides, make runes are tromey's department. :-) Andrew. From fitzsim at redhat.com Fri Nov 11 15:50:35 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 11 Nov 2005 10:50:35 -0500 Subject: [fedora-java] Followup: aot-compile-rpm, rebuild-gcj-db and rebuild-security-providers In-Reply-To: <20051111084809.GB4972@redhat.com> References: <1131646012.5716.47.camel@rh-ibm-t41> <20051111084809.GB4972@redhat.com> Message-ID: <1131724236.5716.81.camel@rh-ibm-t41> On Fri, 2005-11-11 at 08:48 +0000, Gary Benson wrote: > Thomas Fitzsimmons wrote: > > rebuild-gcj-db > > -------------- > > > > This script's logic will be moved into a gcj-dbtool --rebuild option. > > While we're changing things here I'd like to propose that the global > database be moved from /usr/lib/gcj-x.y.z/classmap.db to somewhere > like /var/lib/gcj/classmap.db. Unlike the per-package files the the > global database is machine-specific, so putting it in /var makes us > more LSB-compliant. One practical advantage of this is that it would > allow our rpms to be used on systems with readonly /usr partitions. Good point. I filed two bugs for this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24798 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172950 Tom From fitzsim at redhat.com Fri Nov 11 16:02:16 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 11 Nov 2005 11:02:16 -0500 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051111130021.GH4972@redhat.com> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> Message-ID: <1131724936.5716.94.camel@rh-ibm-t41> Hi, On Fri, 2005-11-11 at 13:00 +0000, Gary Benson wrote: [...] > That aside, having the database rebuilding as an alternative (so > possibly a no-op) would also cause problems. Imagine this: > > 1. User has GCJ as their JVM. > 2. a) User installs some Fedora packages. > b) GCJ database is rebuilt into a consistent state. > 3. User switches to some other JVM. > 4. a) User installs some more Fedora packages. > b) GCJ database is not rebuilt. > 5. User switches to GCJ as their JVM. > > The user has ended up with a broken database. His applications will > be slower, and in some (admittedly broken) cases will suddenly start > to fail. Right, aot-compile should definitely not be an alternative. The idea is that "aot-compile --rebuilddb" decides what to do based on three criteria: 1) a config file, maybe /etc/java/java.conf, specifies the default behaviour -- to run gcj-dbtool or to be a no-op 2) an environment variable can override this default on a per-run basis 3) if gcj-dbtool is not installed, "aot-compile --rebuilddb" is automatically a no-op [...] > > IMPORTANT: please note that aot-compile should not be tied to GCJ, > > but instead be a characteristic of any Java that is capable of > > pre-compilation. > > Sure. This doesn't preclude us from putting the present, GCJ-specific > aot-compile-rpm into the gcc-java rpm, and I still think we should > proceed with this. Agreed -- aot-compile-rpm is still needed here (and in fact, "aot- compile" is a confusing name to use in this proposal for a new jpackage- neutral script). > > > In any case, we should try and keep the command names generic so if > > necessary one day the JVMs that are AOT-capable can provide > > alternatives for those. > > How about making them even more generic and mandating that all > JPackage rpms call certain scripts at certain points. At the end of > %install, for example, you could require that all packages invoke > jpackage-install, and similarly %post would have jpackage-post and > %postun would have jpackage-postun. > > Each script could do both generic JPackage stuff and call specific JVM > stuff. Under your system jpackage-install would call aot-compile-rpm > if GCJ was selected as your JVM, and jpackage-post and -postun would > do the database rebuilding. The scripts could do allsorts: the %prep > script jpackage-prep could check for bundled jars and classes for > example. This sounds excellent. Perhaps we should post a proposal to the jpackage list, along with an example of a converted package. Tom From aph at redhat.com Fri Nov 11 17:46:11 2005 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Nov 2005 17:46:11 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051111133918.GI4972@redhat.com> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> Message-ID: <17268.55523.191323.476222@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Use make. If any .db files are added or altered, the .db gets > > rebuilt. If they aren't, it isn't. The makefile contains the > > commands that do the right thing. > > > > make is designed to solve this kind of problem. > > Can you write a makefile to do this? I've never been able to figure > out how to do multiple directory stuff :-/ OK, I just checked with tromey, and we think we can write a makefile that allows you to install a stanadrd jpackage and then do a "make". For example, this rule does the building, where needed: %.so: %.jar gcj -o $@ blah blah $< %.db: %.so gcj-dbtool -o $@ db/$(basename $<).jar $< ... etc. Andrew. From gbenson at redhat.com Fri Nov 11 17:51:39 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 11 Nov 2005 17:51:39 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17268.55523.191323.476222@zapata.pink> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> Message-ID: <20051111175135.GQ4972@redhat.com> Andrew Haley wrote: > OK, I just checked with tromey, and we think we can write a makefile > that allows you to install a stanadrd jpackage and then do a "make". > > For example, this rule does the building, where needed: > > %.so: %.jar > gcj -o $@ blah blah $< > > %.db: %.so > gcj-dbtool -o $@ db/$(basename $<).jar $< > > ... etc. Building .so files and per-package .db files is not the issue. What is needed is the merging of /usr/lib/gcj/*/*.db into /var/lib/gcj/classmap.db. Cheers, Gary From david at zarb.org Fri Nov 11 21:39:50 2005 From: david at zarb.org (David Walluck) Date: Fri, 11 Nov 2005 16:39:50 -0500 Subject: [fedora-java] gcj-dbtool --rebuild In-Reply-To: <20051111134417.GJ4972@redhat.com> References: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> <20051111134417.GJ4972@redhat.com> Message-ID: <43750FA6.8060308@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > Also, the per-package databases are in $prefix/lib/gcj/$name these > days. Someone mentioned that files in /usr/lib are not necessarily writable, so that could break both the rebuild-gcj-db and rebuild-security providers. But these scripts are only (normally) called by rpm when it installs or uninstalls packages and /usr/lib must be writable at this point. I don't know how I feel about the Makefile idea. In any case, it should never require user intervention. What besides sendmail is using this method anyhow? IMO, `make' should be touched by packagers only, certainly not by end users, and not even by system admins. Their work is supposed to be done by rpm out of the box must of the time. One of the good points about the existing scripts is that they are (a) completely managed by rpm (b) transparent to the user *unless they fail of course). - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdQ+marJDwJ6gwowRAsc0AJ9xjjoy2jp3scuswhbFRvQKps4/KQCff3gT rxDvijQ5ue2V5g2VlMTRMKY= =w3hT -----END PGP SIGNATURE----- From david at zarb.org Fri Nov 11 21:51:01 2005 From: david at zarb.org (David Walluck) Date: Fri, 11 Nov 2005 16:51:01 -0500 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051111134743.GK4972@redhat.com> References: <4373C331.4030501@redhat.com> <4373F630.8030304@zarb.org> <20051111134743.GK4972@redhat.com> Message-ID: <43751245.6010108@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Benson wrote: > Well, if anything the aot supported by Kaffe will be GCJ's, so you'll > need GCJ for compilation at any rate. At install time on the packagers machines, yes. At runtime on the user's machine, I don't think so. I just wanted to be sure that a user would not be forced to install gcj, which make sense, as gcj-dbtool and gcj are normally in separate rpms. Anyway, there is no argument here except that aot-compile was going to end up one place and perhaps rebuild-gcj-db was going to end up another place (upstream). It could come into play depending on how they were split up. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdRJFarJDwJ6gwowRAtfGAJ9DKg3gnvgFSvbsIu5k+q5Ykc6xeQCgka0x Uha9Icr5JB3AoeTwtjn0Zx4= =ltL8 -----END PGP SIGNATURE----- From aph at redhat.com Sat Nov 12 08:00:27 2005 From: aph at redhat.com (Andrew Haley) Date: Sat, 12 Nov 2005 08:00:27 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051111175135.GQ4972@redhat.com> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> Message-ID: <17269.41243.551175.487652@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > OK, I just checked with tromey, and we think we can write a makefile > > that allows you to install a stanadrd jpackage and then do a "make". > > > > For example, this rule does the building, where needed: > > > > %.so: %.jar > > gcj -o $@ blah blah $< > > > > %.db: %.so > > gcj-dbtool -o $@ db/$(basename $<).jar $< > > > > ... etc. > > Building .so files and per-package .db files is not the issue. It certainly was mentioned in the message I was replying to. > What is needed is the merging of /usr/lib/gcj/*/*.db into > /var/lib/gcj/classmap.db. So all you want is a command that does the merging we do at the moment, but only when necessary? Andrew. From aph at redhat.com Sat Nov 12 08:04:28 2005 From: aph at redhat.com (Andrew Haley) Date: Sat, 12 Nov 2005 08:04:28 +0000 Subject: [fedora-java] gcj-dbtool --rebuild In-Reply-To: <43750FA6.8060308@zarb.org> References: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> <20051111134417.GJ4972@redhat.com> <43750FA6.8060308@zarb.org> Message-ID: <17269.41484.486197.904771@zapata.pink> David Walluck writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gary Benson wrote: > > Also, the per-package databases are in $prefix/lib/gcj/$name these > > days. > > Someone mentioned that files in /usr/lib are not necessarily writable, > so that could break both the rebuild-gcj-db and rebuild-security > providers. But these scripts are only (normally) called by rpm when it > installs or uninstalls packages and /usr/lib must be writable at this point. Ah, but /usr might be *shared* between several computers, and each one needs to have its own master database. So that master database can't be in /usr. > I don't know how I feel about the Makefile idea. In any case, it > should never require user intervention. What besides sendmail is > using this method anyhow? IMO, `make' should be touched by > packagers only, certainly not by end users, and not even by system > admins. They won't need to. The question here is how we fix our existing scripts so that they don't do unnecessary work. If we do that, then they can be called unconditionally. make is the right answer here, because it's a tool that already knows how to do the dependency analysis that's needed. > Their work is supposed to be done by rpm out of the box must of the > time. One of the good points about the existing scripts is that > they are (a) completely managed by rpm (b) transparent to the user > *unless they fail of course). And no-one wants to change that. Andrew. From HAWAT.THUFIR at gmail.com Sat Nov 12 21:18:34 2005 From: HAWAT.THUFIR at gmail.com (HAWAT.THUFIR at gmail.com) Date: Sat, 12 Nov 2005 16:18:34 -0500 Subject: [fedora-java] Thoughts on JPackage, Fedora Core, gcj, etc. In-Reply-To: References: <20051110115128.GH4724@redhat.com> Message-ID: On Thu, 10 Nov 2005, Ian Pilcher wrote: .. > Certainly, adding them automatically should be a goal. Too painful to > think about, however? It looks like there are about 158 "Java" packages > in Fedora Core 4. Adding > > Provides: gcj(%{name}) = %{epoch}:%{version}-%{release} > > to each package hardly seems like a Herculean task. > > How does Jpackage compare to jikes? -Thufir From gbenson at redhat.com Mon Nov 14 10:47:59 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 10:47:59 +0000 Subject: [fedora-java] gcj-dbtool --rebuild In-Reply-To: <17269.41484.486197.904771@zapata.pink> References: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> <20051111134417.GJ4972@redhat.com> <43750FA6.8060308@zarb.org> <17269.41484.486197.904771@zapata.pink> Message-ID: <20051114104755.GB12276@redhat.com> Andrew Haley wrote: > David Walluck writes: > > I don't know how I feel about the Makefile idea. In any case, it > > should never require user intervention. What besides sendmail is > > using this method anyhow? IMO, `make' should be touched by > > packagers only, certainly not by end users, and not even by system > > admins. > > They won't need to. The question here is how we fix our existing > scripts so that they don't do unnecessary work. If we do that, then > they can be called unconditionally. make is the right answer here, > because it's a tool that already knows how to do the dependency > analysis that's needed. All it has to do is read every .db file under /usr/lib/gcj and write what it finds to a .db file in /var/lib/gcj. Where's the dependency analysis in that? Cheers, Gary From gbenson at redhat.com Mon Nov 14 10:57:05 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 10:57:05 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17269.41243.551175.487652@zapata.pink> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> Message-ID: <20051114105701.GC12276@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > What is needed is the merging of /usr/lib/gcj/*/*.db into > > /var/lib/gcj/classmap.db. > > So all you want is a command that does the merging we do at the > moment, but only when necessary? I think all he wanted is the command that does the merging we do at the moment full stop. He just wanted what rebuild-gcj-db does in gcj-dbtool. I'm quite happy to write it if you like. Cheers, Gary From aph at redhat.com Mon Nov 14 10:58:40 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2005 10:58:40 +0000 Subject: [fedora-java] gcj-dbtool --rebuild In-Reply-To: <20051114104755.GB12276@redhat.com> References: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> <20051111134417.GJ4972@redhat.com> <43750FA6.8060308@zarb.org> <17269.41484.486197.904771@zapata.pink> <20051114104755.GB12276@redhat.com> Message-ID: <17272.28128.666306.12307@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > David Walluck writes: > > > I don't know how I feel about the Makefile idea. In any case, it > > > should never require user intervention. What besides sendmail is > > > using this method anyhow? IMO, `make' should be touched by > > > packagers only, certainly not by end users, and not even by system > > > admins. > > > > They won't need to. The question here is how we fix our existing > > scripts so that they don't do unnecessary work. If we do that, then > > they can be called unconditionally. make is the right answer here, > > because it's a tool that already knows how to do the dependency > > analysis that's needed. > > All it has to do is read every .db file under /usr/lib/gcj and write > what it finds to a .db file in /var/lib/gcj. Where's the dependency > analysis in that? We can already do that. My suggestion was a way to only do that when we know we really have to. So, if you install a RPM that doesn't add or remove any .db files, nothing gets rebuilt because make doesn't see any changed dependencies. This completely solves the problem of > That aside, having the database rebuilding as an alternative (so > possibly a no-op) would also cause problems. Imagine this: > > 1. User has GCJ as their JVM. > 2. a) User installs some Fedora packages. > b) GCJ database is rebuilt into a consistent state. > 3. User switches to some other JVM. > 4. a) User installs some more Fedora packages. > b) GCJ database is not rebuilt. > 5. User switches to GCJ as their JVM. > > The user has ended up with a broken database. His applications will > be slower, and in some (admittedly broken) cases will suddenly start > to fail. > > Rather than being an alternative, the rebuild command would need to > rebuild all databases that could be installed on the system. This > could be done by for example having all JVMs drop scripts in some > database, and having 'aot-compile --rebuild' or whatever call them all > in turn. which was clipped from the mail. Don't make database rebuilding an alternative. Use make. Andrew. From aph at redhat.com Mon Nov 14 10:59:38 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2005 10:59:38 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051114105701.GC12276@redhat.com> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> Message-ID: <17272.28186.195196.94720@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > What is needed is the merging of /usr/lib/gcj/*/*.db into > > > /var/lib/gcj/classmap.db. > > > > So all you want is a command that does the merging we do at the > > moment, but only when necessary? > > I think all he wanted is the command that does the merging we do at > the moment full stop. He just wanted what rebuild-gcj-db does in > gcj-dbtool. I'm quite happy to write it if you like. Writing it is easy; I want to make sure it does the right thing. Andrew. From gbenson at redhat.com Mon Nov 14 11:08:07 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 11:08:07 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17272.28186.195196.94720@zapata.pink> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> Message-ID: <20051114110804.GD12276@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > Gary Benson writes: > > > > What is needed is the merging of /usr/lib/gcj/*/*.db into > > > > /var/lib/gcj/classmap.db. > > > > > > So all you want is a command that does the merging we do at the > > > moment, but only when necessary? > > > > I think all he wanted is the command that does the merging we do > > at the moment full stop. He just wanted what rebuild-gcj-db does > > in gcj-dbtool. I'm quite happy to write it if you like. > > Writing it is easy; I want to make sure it does the right thing. Using make worries me because I frequently downgrade versions of things while I'm testing. Downgrading will give the .db files an older timestamp, and the system database will not be rebuilt. There are occasions when beehive will downgrade what's in its buildroot. Fixing broken a database on my machine is easy, fixing it on 20+ beehive machines is not. That aside, rebuilding the databases takes no time at all. Using make seems to me to be adding an additional layer of complexity for no perceptible gain. Cheers, Gary From aph at redhat.com Mon Nov 14 11:12:29 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2005 11:12:29 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051114110804.GD12276@redhat.com> References: <4373C331.4030501@redhat.com> <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> Message-ID: <17272.28957.759281.281219@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Andrew Haley wrote: > > > > Gary Benson writes: > > > > > What is needed is the merging of /usr/lib/gcj/*/*.db into > > > > > /var/lib/gcj/classmap.db. > > > > > > > > So all you want is a command that does the merging we do at the > > > > moment, but only when necessary? > > > > > > I think all he wanted is the command that does the merging we do > > > at the moment full stop. He just wanted what rebuild-gcj-db does > > > in gcj-dbtool. I'm quite happy to write it if you like. > > > > Writing it is easy; I want to make sure it does the right thing. > > Using make worries me because I frequently downgrade versions of > things while I'm testing. Downgrading will give the .db files an > older timestamp, and the system database will not be rebuilt. It'll give the directory a newer timestamp, so the system database will be rebuilt. > There are occasions when beehive will downgrade what's in its > buildroot. Fixing broken a database on my machine is easy, fixing > it on 20+ beehive machines is not. > > That aside, rebuilding the databases takes no time at all. Using > make seems to me to be adding an additional layer of complexity for > no perceptible gain. So why worry about making rebuild an alternative? If it's no big deal, why not always do it? Andrew. From gbenson at redhat.com Mon Nov 14 11:53:07 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 11:53:07 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17272.28957.759281.281219@zapata.pink> References: <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> Message-ID: <20051114115304.GE12276@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Using make worries me because I frequently downgrade versions of > > things while I'm testing. Downgrading will give the .db files an > > older timestamp, and the system database will not be rebuilt. > > It'll give the directory a newer timestamp, so the system database > will be rebuilt. I need to see a makefile which does this. > > That aside, rebuilding the databases takes no time at all. Using > > make seems to me to be adding an additional layer of complexity > > for no perceptible gain. > > So why worry about making rebuild an alternative? If it's no big > deal, why not always do it? There's two issues here which I think you are confusing: 1) Presently, rebuild-gcj-db and aot-compile-rpm _are_ alternatives, though not between JVMs: they're shared between versions of java-1.4.2-gcj*-compat. Tom Fitzsimmons wants them not to be alternatives, but to be in gcc subpackages (libgcj for r-g-d, and gcc-java for a-c-r). Almost incidentally, Tom pointed out that rebuild-gcj-db is so small its functionality could easily be incorporated in gcj-dbtool. 2) On the other hand, Fernando wants the two scripts to remain alternatives, but shared between all JVMs (not just GCJ ones). My opinion is that something like this would be a good idea, but that acquiring the GCJ-specific command names for it is the wrong thing to do (not least because GCJ's database should be rebuilt whenever an rpm with GCJ-precompiled stuff is installed regardless of what JVM alternative is in force). This needs more discussion (on JPackage lists so the relevant people see it) but the result of that discussion should not stop us from making the GCJ-specific changes to the GCJ-specific rpms that we need for future development. Cheers, Gary From aph at redhat.com Mon Nov 14 12:05:48 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2005 12:05:48 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051114115304.GE12276@redhat.com> References: <20051111130021.GH4972@redhat.com> <17268.38857.369578.811397@zapata.pink> <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> Message-ID: <17272.32156.317476.595770@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Using make worries me because I frequently downgrade versions of > > > things while I'm testing. Downgrading will give the .db files an > > > older timestamp, and the system database will not be rebuilt. > > > > It'll give the directory a newer timestamp, so the system database > > will be rebuilt. > > I need to see a makefile which does this. > > > > That aside, rebuilding the databases takes no time at all. Using > > > make seems to me to be adding an additional layer of complexity > > > for no perceptible gain. > > > > So why worry about making rebuild an alternative? If it's no big > > deal, why not always do it? > > There's two issues here which I think you are confusing: I don't think so! > 1) Presently, rebuild-gcj-db and aot-compile-rpm _are_ alternatives, > though not between JVMs: they're shared between versions of > java-1.4.2-gcj*-compat. Tom Fitzsimmons wants them not to be > alternatives, but to be in gcc subpackages (libgcj for r-g-d, and > gcc-java for a-c-r). Almost incidentally, Tom pointed out that > rebuild-gcj-db is so small its functionality could easily be > incorporated in gcj-dbtool. Right. No argument there. I have no disagreement with any of this. Making gcj-dbtool do the right thing is easy, and I'll do it. > 2) On the other hand, Fernando wants the two scripts to remain > alternatives, but shared between all JVMs (not just GCJ ones). > My opinion is that something like this would be a good idea, > but that acquiring the GCJ-specific command names for it is the > wrong thing to do (not least because GCJ's database should be > rebuilt whenever an rpm with GCJ-precompiled stuff is installed > regardless of what JVM alternative is in force). This is the issue that I am addressing. My suggestion solves this problem: > GCJ's database should be rebuilt whenever an rpm with > GCJ-precompiled stuff is installed regardless of what JVM > alternative is in force ... without penalizing users who aren't installing gcj packages. It also abstracts away from the RPM specfiles the nitpicky gcj details. This is better than having "gcj-dbtool --rebuild" or its equivalent in each specfile. > This needs more discussion (on JPackage lists so the relevant > people see it) but the result of that discussion should not > stop us from making the GCJ-specific changes to the > GCJ-specific rpms that we need for future development. Andrew. From gbenson at redhat.com Mon Nov 14 13:32:45 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 13:32:45 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17272.32156.317476.595770@zapata.pink> References: <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> Message-ID: <20051114133243.GH12276@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > 1) Presently, rebuild-gcj-db and aot-compile-rpm _are_ > > alternatives, though not between JVMs: they're shared between > > versions of java-1.4.2-gcj*-compat. Tom Fitzsimmons wants > > them not to be alternatives, but to be in gcc subpackages > > (libgcj for r-g-d, and gcc-java for a-c-r). Almost > > incidentally, Tom pointed out that rebuild-gcj-db is so small > > its functionality could easily be incorporated in gcj-dbtool. > > Right. No argument there. I have no disagreement with any of this. > Making gcj-dbtool do the right thing is easy, and I'll do it. Oh, ok, cool. In that case, you should know that you only need to scan /usr/lib/gcj. rebuild-gcj-db also scans $dblocation (aka /usr/lib/gcj-x.y.z/classmap.db.d) but that was just a workaround for FC4 and can be removed. > > 2) On the other hand, Fernando wants the two scripts to remain > > alternatives, but shared between all JVMs (not just GCJ ones). > > My opinion is that something like this would be a good idea, > > but that acquiring the GCJ-specific command names for it is > > the wrong thing to do (not least because GCJ's database should > > be rebuilt whenever an rpm with GCJ-precompiled stuff is > > installed regardless of what JVM alternative is in force). > > This is the issue that I am addressing. > > My suggestion solves this problem: > > > GCJ's database should be rebuilt whenever an rpm with > > GCJ-precompiled stuff is installed regardless of what JVM > > alternative is in force > > ... without penalizing users who aren't installing gcj packages. It > also abstracts away from the RPM specfiles the nitpicky gcj details. > This is better than having "gcj-dbtool --rebuild" or its equivalent > in each specfile. When will it be invoked if not in every specfile? Cheers, Gary From aph at redhat.com Mon Nov 14 13:49:17 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2005 13:49:17 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051114133243.GH12276@redhat.com> References: <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> Message-ID: <17272.38365.857530.492285@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > 1) Presently, rebuild-gcj-db and aot-compile-rpm _are_ > > > alternatives, though not between JVMs: they're shared between > > > versions of java-1.4.2-gcj*-compat. Tom Fitzsimmons wants > > > them not to be alternatives, but to be in gcc subpackages > > > (libgcj for r-g-d, and gcc-java for a-c-r). Almost > > > incidentally, Tom pointed out that rebuild-gcj-db is so small > > > its functionality could easily be incorporated in gcj-dbtool. > > > > Right. No argument there. I have no disagreement with any of this. > > Making gcj-dbtool do the right thing is easy, and I'll do it. > > Oh, ok, cool. In that case, you should know that you only need to > scan /usr/lib/gcj. rebuild-gcj-db also scans $dblocation (aka > /usr/lib/gcj-x.y.z/classmap.db.d) but that was just a workaround for > FC4 and can be removed. OK. > > > 2) On the other hand, Fernando wants the two scripts to remain > > > alternatives, but shared between all JVMs (not just GCJ ones). > > > My opinion is that something like this would be a good idea, > > > but that acquiring the GCJ-specific command names for it is > > > the wrong thing to do (not least because GCJ's database should > > > be rebuilt whenever an rpm with GCJ-precompiled stuff is > > > installed regardless of what JVM alternative is in force). > > > > This is the issue that I am addressing. > > > > My suggestion solves this problem: > > > > > GCJ's database should be rebuilt whenever an rpm with > > > GCJ-precompiled stuff is installed regardless of what JVM > > > alternative is in force > > > > ... without penalizing users who aren't installing gcj packages. It > > also abstracts away from the RPM specfiles the nitpicky gcj details. > > This is better than having "gcj-dbtool --rebuild" or its equivalent > > in each specfile. > > When will it be invoked if not in every specfile? It will be invoked from the specfile, but by either a. Going to some java dir and running make, or b. Running some VM-agnostic script that does a. That way, should there ever be some other VM that does precompilation, we need only to add a make rule for whatever it needs. Andrew. From gbenson at redhat.com Mon Nov 14 14:08:02 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 14:08:02 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17272.38365.857530.492285@zapata.pink> References: <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> Message-ID: <20051114140802.GI12276@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > Gary Benson writes: > > > > 2) On the other hand, Fernando wants the two scripts to remain > > > > alternatives, but shared between all JVMs (not just GCJ > > > > ones). My opinion is that something like this would be a > > > > good idea, but that acquiring the GCJ-specific command > > > > names for it is the wrong thing to do (not least because > > > > GCJ's database should be rebuilt whenever an rpm with > > > > GCJ-precompiled stuff is installed regardless of what JVM > > > > alternative is in force). > > > > > > This is the issue that I am addressing. > > > > > > My suggestion solves this problem: > > > > > > > GCJ's database should be rebuilt whenever an rpm with > > > > GCJ-precompiled stuff is installed regardless of what JVM > > > > alternative is in force > > > > > > ... without penalizing users who aren't installing gcj packages. > > > It also abstracts away from the RPM specfiles the nitpicky gcj > > > details. This is better than having "gcj-dbtool --rebuild" or > > > its equivalent in each specfile. > > > > When will it be invoked if not in every specfile? > > It will be invoked from the specfile, but by either > > a. Going to some java dir and running make, or > b. Running some VM-agnostic script that does a. > > That way, should there ever be some other VM that does > precompilation, we need only to add a make rule for whatever it > needs. Ok. FWIW I perfer B, but it's really something for JPackage not Fedora to decide. As long as Fedora rpms can continue to call 'rebuild-gcj-db' or 'gcj-dbtool --rebuild' until JPackage figure out what they're doing then that's fine. Cheers, Gary From aph at redhat.com Mon Nov 14 14:14:13 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2005 14:14:13 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051114140802.GI12276@redhat.com> References: <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> <20051114140802.GI12276@redhat.com> Message-ID: <17272.39861.579490.115562@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Andrew Haley wrote: > > > > Gary Benson writes: > > > > > 2) On the other hand, Fernando wants the two scripts to remain > > > > > alternatives, but shared between all JVMs (not just GCJ > > > > > ones). My opinion is that something like this would be a > > > > > good idea, but that acquiring the GCJ-specific command > > > > > names for it is the wrong thing to do (not least because > > > > > GCJ's database should be rebuilt whenever an rpm with > > > > > GCJ-precompiled stuff is installed regardless of what JVM > > > > > alternative is in force). > > > > > > > > This is the issue that I am addressing. > > > > > > > > My suggestion solves this problem: > > > > > > > > > GCJ's database should be rebuilt whenever an rpm with > > > > > GCJ-precompiled stuff is installed regardless of what JVM > > > > > alternative is in force > > > > > > > > ... without penalizing users who aren't installing gcj packages. > > > > It also abstracts away from the RPM specfiles the nitpicky gcj > > > > details. This is better than having "gcj-dbtool --rebuild" or > > > > its equivalent in each specfile. > > > > > > When will it be invoked if not in every specfile? > > > > It will be invoked from the specfile, but by either > > > > a. Going to some java dir and running make, or > > b. Running some VM-agnostic script that does a. > > > > That way, should there ever be some other VM that does > > precompilation, we need only to add a make rule for whatever it > > needs. > > Ok. FWIW I perfer B, but it's really something for JPackage not > Fedora to decide. As long as Fedora rpms can continue to call > 'rebuild-gcj-db' or 'gcj-dbtool --rebuild' until JPackage figure > out what they're doing then that's fine. Well, OK: I don't mind. Going through every RPM changing "rebuild-gcj-db" to "gcj-dbtool --rebuild" and then changing it again some time in the future sounds like a PITA to me ... but then I won't be doing it! Andrew. From gbenson at redhat.com Mon Nov 14 14:14:54 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 14:14:54 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17272.38365.857530.492285@zapata.pink> References: <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> Message-ID: <20051114141452.GJ12276@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > Gary Benson writes: > > > > 1) Presently, rebuild-gcj-db and aot-compile-rpm _are_ > > > > alternatives, though not between JVMs: they're shared > > > > between versions of java-1.4.2-gcj*-compat. Tom > > > > Fitzsimmons wants them not to be alternatives, but to be > > > > in gcc subpackages (libgcj for r-g-d, and gcc-java for > > > > a-c-r). Almost incidentally, Tom pointed out that > > > > rebuild-gcj-db is so small its functionality could easily > > > > be incorporated in gcj-dbtool. > > > > > > Right. No argument there. I have no disagreement with any of > > > this. Making gcj-dbtool do the right thing is easy, and I'll do > > > it. > > > > Oh, ok, cool. In that case, you should know that you only need to > > scan /usr/lib/gcj. rebuild-gcj-db also scans $dblocation (aka > > /usr/lib/gcj-x.y.z/classmap.db.d) but that was just a workaround > > for FC4 and can be removed. > > OK. Oh, and something else. Even if we switch new rpms over to do something like 'gcj-dbtool --rebuild' we must retain something at /usr/bin/rebuild-gcj-db or it will become impossible to upgrade or uninstall the FC4 packages. My preference would be to have /usr/bin/rebuild-gcj-db a symbolic link to gcj-dbtool and have gcj-dbtool check its argv[0] (if that's possible under Java). Also note that while FC5 and the newest FC4 packages call rebuild-gcj-db with no arguments, the majority of FC4 packages will call 'rebuild-gcj-db /usr/lib' or 'rebuild-gcj-db /usr/lib64'. Any replacement must not choke on this. Cheers, Gary From gbenson at redhat.com Mon Nov 14 14:17:32 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 14:17:32 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17272.39861.579490.115562@zapata.pink> References: <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> <20051114140802.GI12276@redhat.com> <17272.39861.579490.115562@zapata.pink> Message-ID: <20051114141732.GK12276@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > It will be invoked from the specfile, but by either > > > > > > a. Going to some java dir and running make, or > > > b. Running some VM-agnostic script that does a. > > > > > > That way, should there ever be some other VM that does > > > precompilation, we need only to add a make rule for whatever it > > > needs. > > > > Ok. FWIW I perfer B, but it's really something for JPackage not > > Fedora to decide. As long as Fedora rpms can continue to call > > 'rebuild-gcj-db' or 'gcj-dbtool --rebuild' until JPackage figure > > out what they're doing then that's fine. > > Well, OK: I don't mind. Going through every RPM changing > "rebuild-gcj-db" to "gcj-dbtool --rebuild" and then changing it > again some time in the future sounds like a PITA to me ... but > then I won't be doing it! It'd probably be best to leave them calling "rebuild-gcj-db" for now, since we won't be able to get rid of /usr/bin/rebuild-gcj-db until we stop caring about people upgrading from FC4. Cheers, Gary From aph at redhat.com Mon Nov 14 14:20:01 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2005 14:20:01 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051114141452.GJ12276@redhat.com> References: <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> <20051114141452.GJ12276@redhat.com> Message-ID: <17272.40209.320611.129892@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Andrew Haley wrote: > > > > Gary Benson writes: > > > > > 1) Presently, rebuild-gcj-db and aot-compile-rpm _are_ > > > > > alternatives, though not between JVMs: they're shared > > > > > between versions of java-1.4.2-gcj*-compat. Tom > > > > > Fitzsimmons wants them not to be alternatives, but to be > > > > > in gcc subpackages (libgcj for r-g-d, and gcc-java for > > > > > a-c-r). Almost incidentally, Tom pointed out that > > > > > rebuild-gcj-db is so small its functionality could easily > > > > > be incorporated in gcj-dbtool. > > > > > > > > Right. No argument there. I have no disagreement with any of > > > > this. Making gcj-dbtool do the right thing is easy, and I'll do > > > > it. > > > > > > Oh, ok, cool. In that case, you should know that you only need to > > > scan /usr/lib/gcj. rebuild-gcj-db also scans $dblocation (aka > > > /usr/lib/gcj-x.y.z/classmap.db.d) but that was just a workaround > > > for FC4 and can be removed. > > > > OK. > > Oh, and something else. Even if we switch new rpms over to do > something like 'gcj-dbtool --rebuild' we must retain something > at /usr/bin/rebuild-gcj-db or it will become impossible to > upgrade or uninstall the FC4 packages. > > My preference would be to have /usr/bin/rebuild-gcj-db a symbolic > link to gcj-dbtool and have gcj-dbtool check its argv[0] (if > that's possible under Java). OK. That seems to me like a good idea. > Also note that while FC5 and the newest FC4 packages call > rebuild-gcj-db with no arguments, the majority of FC4 packages > will call 'rebuild-gcj-db /usr/lib' or 'rebuild-gcj-db /usr/lib64'. > Any replacement must not choke on this. OK. Is there somewhere an exact description of what arguemnts rebuild-gcj-db will take? Andrew. From gbenson at redhat.com Mon Nov 14 14:32:30 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 Nov 2005 14:32:30 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17272.40209.320611.129892@zapata.pink> References: <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> <20051114141452.GJ12276@redhat.com> <17272.40209.320611.129892@zapata.pink> Message-ID: <20051114143229.GL12276@redhat.com> Andrew Haley wrote: > Gary Benson wrote: > > Also note that while FC5 and the newest FC4 packages call > > rebuild-gcj-db with no arguments, the majority of FC4 packages > > will call 'rebuild-gcj-db /usr/lib' or 'rebuild-gcj-db > > /usr/lib64'. Any replacement must not choke on this. > > OK. Is there somewhere an exact description of what arguemnts > rebuild-gcj-db will take? The top of rebuild-gcj-db.in says: if [ $# != 0 ]; then if [ $# != 1 -o $1 != @LIBDIR@ ]; then # emit usage message and die fi fi @LIBDIR@ is either /usr/lib or /usr/lib64, depending. Cheers, Gary From mark at klomp.org Mon Nov 14 16:37:15 2005 From: mark at klomp.org (Mark Wielaard) Date: Mon, 14 Nov 2005 17:37:15 +0100 Subject: [fedora-java] GNU Classpath hacker room at FOSDEM 2006 Message-ID: <1131986235.29591.67.camel@localhost.localdomain> Hi all, Like the last couple of years we want to come together with all the projects around GNU Classpath and the various free runtimes, compiler and tool projects to discuss what has happened in the last year in the Free Software community and what the next year will bring us during FOSDEM. The 6th edition of FOSDEM (Free and Opensource Software Developers' European Meeting) will take place on February 25+26 2006 in Brussels (Belgium), at the Solbosch Campus of the ULB (Free University of Brussels). FOSDEM is a free and non-commercial event for the community and organized by the community. See http://www.fosdem.org/ We were thinking of the following setup: - Saturday from 13:00 to 17:30 - "End-User talks" presentations to promote what we all build together to a wider audience that might have heard of what we do, but haven't actually seen it in action/put together. We might also want to have a "lightning" hour with lots of quick Demos of applications running on a completely free stack (5 - 10 minutes per demo). - Sunday from 09:00 to 12:30 - "Developer talks" presentations of things that are in progress and that people want to explain in more depth to get developers of the other projects to join in a share the fun. - Sunday from 13:00 to 17:30 - "The Future" hard core interactive technical hacker discussions on how to integrate the projects more and move forward in the next year. Arnaud Vandyck, Dalibor Topic, Mark Wielaard, Michael Koch and and Tom Tromey will be our "program committee" this year. If you would like to present something, have an idea for a demo or discussion topic please let us know at fosdem-at-developer.classpath.org Please mention the title, a little abstract, which track and whether you want to do a quick demo, a short 30 min talk or full hour talk (we prefer 30 minute talks to give everybody a chance to present something). Deadline for proposals is December 18, so you have a month to think of something cool. Then we make sure to have some kind of "formal program" at the start of January. Examples of presentations and reports from previous years: http://www.gnu.org/software/classpath/events/escape_fosdem05.html http://www.gnu.org/software/classpath/events/fosdem04.html Some ideas for interesting topics: - Free Swing - The Demo! - Your GNU/Linux distro and the free runtimes - package overview. - From 0 to 100 in 15 Minutes: Getting started with GNU Classpath development using Eclipse, JamVM, Mauve, and the ChangeLog plugin! - Integrating with Objectweb through native-(gcj)-JOnAS - Writing OpenOffice.org plugins using a free software stack. - Using GNU Classpath/gcj/kaffe for games - Using free runtimes on Wine and other win32 environments - Embedding GNU Classpath in web browsers and support for JNLP - Security Auditing! - 1.5 language support in GNU Classpath, gcjx and the free runtimes - GNU Classpath/OSGi/J2ME/Library splitting and trimming - Harmony through interfacing. - Beyond JAPI: what is needed to "really finish" GNU Classpath Or, "Beyond Java" -- what we can do when we finish 1.5. Or more generally some kind of presentation about development metrics: bug rates, rates of change in japi/lines of code/tests, email volume, stuff like that. - Debugging, JDWP development efforts. - etc. Hope to see you in Brussels on February 25 and 26 2006, Arnaud, Dalibor, Mark, Michael and Tom -- 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 overholt at redhat.com Mon Nov 14 17:16:36 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 14 Nov 2005 12:16:36 -0500 Subject: [fedora-java] gij and Eclipse CVS checkout finalization Message-ID: <20051114171636.GB25805@redhat.com> Hi Andrew and others, I spent a lot of time a few months ago working on $subj. After many dead ends, I decided it was more prudent to spend my time working on other issues. I have now returned to this issue and would like to pass it off to those who will have more luck than I did figuring out what is going wrong. Background information: ~~~~~~~~~~~~~~~~~~~~~~ RH Bug #161483 [1] CVS checkouts in Eclipse take an extremely long time to finish when run under gij. The issue occurs both when the relevant jars are natively-compiled and when they are not (although the problem is exacerbated when run with only bytecode). I have found a few modules that replicate the issue but the one I have used the most is GNU Classpath. The problem is independent of network issues as checkouts from a local CVS server exhibit the same behaviour. Things to note: ~~~~~~~~~~~~~~ The problem appears to be related to some sort of thread contention. I wrote a headless Eclipse CVS client (using the same code as the GUI CVS client) that does not reproduce the problem. Following the actual checkout of the files from CVS, Eclipse creates synchronization information for the files it has just checked out. Since this is an initial checkout, all folders are considered dirty so it descends into each folder. One of my original theories was that we were incorrectly computing dirty resources (or getting into some sort of recursive loop) but this is not the case. Much println'ing has told me that both gcj and the Sun JVM come up with the same list of dirty folders. Timing information that I have accumulated has shown that we are not spending an inordinate amount of time generating or writing the synchronization information but are instead spending too much time holding locks on the resources. On average we are holding the locks about 100 - 1000 times longer than the Sun JVM. This can be verified by a sysprof [2] sample [3] taken which shows a lot of time in Semaphore.acquire(). OProfile results corroborate this evidence. gnuplot was used at one point to see if the time spent was proportional to the number of files in the directory or to the disk space of said files. No correlation was observed. Note: at one point, I thought the problem was due to missing .sos for some jars because I could not duplicate the problem on my laptop. It turns out that if I changed the CVS compression level [4], I could somehow affect the timing such that it would indeed occur. Hyperthreaded machines seems impervious to this. There appears to be no way to reduce this to a test case so we are unfortunately left with duplicating the symptoms using Eclipse itself. How to duplicate: ~~~~~~~~~~~~~~~~ I have created a version of Anthony's excellent redhat-eclipse-demo RPM that contains a snapshot of GNU Classpath (from a while ago). This RPM will create a local pserver CVS server running on port 2402. It will also create the user anoncvs and put an exploded GNU Classpath checkout (owned by this user) in /var/lib/eclipse-demo-cvsroot. You can retrieve a copy of this RPM here: http://overholt.ca/redhat-eclipse-demo-2.0-1.noarch.rpm http://overholt.ca/redhat-eclipse-demo-2.0-1.src.rpm 1. Install Eclipse from either FC4 or rawhide. gcc versions do not seem to affect this problem and I've done most of my testing with 4.0.2-3 which was current in rawhide until recently. 2. Fire up Eclipse with a new workspace ... something like: eclipse -data ~/testcvsissueworkspace 3. Checkout classpath from your local CVS server: File->Import->Checkout Projects from CVS Next localhost, /var/lib/eclipse-demo-cvsroot anoncvs, anoncvs pserver, 2402, check 'Save password' Next classpath Finish 4. Observe that checkout hangs at final synchronization I am at a bit of a loss as to how to proceed. Any and all help is greatly appreciated. I will provide whatever information is necessary. (I wrote this email while on a plane and lost a bit of revision I had done just before my battery died. If anything's amiss, I blame that ;) Thank you, Andrew [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161483 [2] http://www.daimi.au.dk/~sandmann/sysprof/ [3] http://overholt.ca/eclipse/checkout.sysprof [4] Window->Preferences->Team->CVS->Connection->Compression From aph at redhat.com Mon Nov 14 17:49:57 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2005 17:49:57 +0000 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: <20051114171636.GB25805@redhat.com> References: <20051114171636.GB25805@redhat.com> Message-ID: <17272.52805.626329.288622@zapata.pink> Andrew Overholt writes: > Hi Andrew and others, > > I spent a lot of time a few months ago working on $subj. After many dead > ends, I decided it was more prudent to spend my time working on other > issues. I have now returned to this issue and would like to pass it off to > those who will have more luck than I did figuring out what is going wrong. > > Background information: > ~~~~~~~~~~~~~~~~~~~~~~ > > RH Bug #161483 [1] > > CVS checkouts in Eclipse take an extremely long time to finish when run > under gij. FYI, I have been unable to dup this problem. It works fine for me. This suggests hat it might well be some sort of race. Andrew. From orion at cora.nwra.com Mon Nov 14 17:58:34 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 14 Nov 2005 10:58:34 -0700 Subject: [fedora-java] Many dependencies for eclipse-cdt Message-ID: <4378D04A.40404@cora.nwra.com> Are all of these really necessary? Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: eclipse-cdt i386 1:3.0.0_fc-1.FC4 CoRA 12 M Installing for dependencies: ant-javamail i386 1.6.2-3jpp_8fc CoRA 21 k cryptix noarch 3.2.0-4jpp_1fc CoRA 395 k cryptix-asn1 noarch 20011119-4jpp_1fc CoRA 180 k eclipse-platform i386 1:3.1.1-1jpp_1fc.FC4.4 CoRA 38 M eclipse-rcp i386 1:3.1.1-1jpp_1fc.FC4.4 CoRA 41 k jakarta-commons-dbcp noarch 1.2.1-3jpp_1fc CoRA 108 k jakarta-commons-el i386 1.0-2jpp_3fc CoRA 319 k jakarta-commons-fileupload noarch 1:1.0-3jpp_1fc CoRA 24 k jakarta-commons-launcher noarch 0.9-3jpp_1fc CoRA 42 k jakarta-commons-pool noarch 1.2-2jpp_1fc CoRA 46 k lucene i386 1.4.3-1jpp_3fc CoRA 795 k lucene-demo i386 1.4.3-1jpp_3fc CoRA 130 k puretls noarch 0.9-0.b4.1jpp_2fc CoRA 140 k tomcat5 i386 5.0.30-5jpp_6fc CoRA 3.5 M tomcat5-jasper i386 5.0.30-5jpp_6fc CoRA 970 k tomcat5-servlet-2.4-api i386 5.0.30-5jpp_6fc CoRA 353 k xerces-j2 i386 2.6.2-4jpp_5fc CoRA 2.2 M -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From overholt at redhat.com Mon Nov 14 18:58:50 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 14 Nov 2005 13:58:50 -0500 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: <17272.52805.626329.288622@zapata.pink> References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> Message-ID: <20051114185850.GC25805@redhat.com> * Andrew Haley [2005-11-14 12:50]: > Andrew Overholt writes: > > RH Bug #161483 [1] > > > > CVS checkouts in Eclipse take an extremely long time to finish when run > > under gij. > > FYI, I have been unable to dup this problem. It works fine for me. > This suggests hat it might well be some sort of race. Gah. I guess I can't get your help, then :( Andrew From overholt at redhat.com Mon Nov 14 19:01:46 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 14 Nov 2005 14:01:46 -0500 Subject: [fedora-java] Many dependencies for eclipse-cdt In-Reply-To: <4378D04A.40404@cora.nwra.com> References: <4378D04A.40404@cora.nwra.com> Message-ID: <20051114190145.GD25805@redhat.com> * Orion Poplawski [2005-11-14 12:59]: > Are all of these really necessary? Yes. The dependencies aren't really CDT deps but rather those of the Eclipse SDK. They're dependencies because we don't just ship pre-built jars like upstream does (which limits their dependencies). Is it a problem? Andrew From david at zarb.org Mon Nov 14 22:58:34 2005 From: david at zarb.org (David Walluck) Date: Mon, 14 Nov 2005 17:58:34 -0500 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17272.38365.857530.492285@zapata.pink> References: <20051111133918.GI4972@redhat.com> <17268.55523.191323.476222@zapata.pink> <20051111175135.GQ4972@redhat.com> <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> Message-ID: <4379169A.6090706@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Haley wrote: > > It will be invoked from the specfile, but by either > > a. Going to some java dir and running make, or > b. Running some VM-agnostic script that does a. It happens so quick. Why not have `java' be a script that invokes gij, and then just run it from there? I am not clear why this should be a script that every JVM runs, since only gij (right now) makes use of it. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDeRaaarJDwJ6gwowRAnnHAKChSicEwkC7GEoaF1gJWg3Q/dVpjACfbGkf Q4N6ERBnxn8zgV61W1864h0= =R3En -----END PGP SIGNATURE----- From gbenson at redhat.com Tue Nov 15 11:33:07 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 15 Nov 2005 11:33:07 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <4379169A.6090706@zarb.org> References: <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> <4379169A.6090706@zarb.org> Message-ID: <20051115113303.GB5116@redhat.com> David Walluck wrote: > Andrew Haley wrote: > > It will be invoked from the specfile, but by either > > > > a. Going to some java dir and running make, or > > b. Running some VM-agnostic script that does a. > > It happens so quick. Why not have `java' be a script that invokes > gij, and then just run it from there? It needs to happen as root. Though, I wonder if per-session databases might not be a better idea. Andrew? > I am not clear why this should be a script that every JVM runs, > since only gij (right now) makes use of it. Fernando wants it to be generalised, in case some other JVM acquires the ability to precompile. Cheers, Gary From aph at redhat.com Tue Nov 15 11:47:57 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Nov 2005 11:47:57 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051115113303.GB5116@redhat.com> References: <17269.41243.551175.487652@zapata.pink> <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> <4379169A.6090706@zarb.org> <20051115113303.GB5116@redhat.com> Message-ID: <17273.51949.832543.911505@zapata.pink> Gary Benson writes: > David Walluck wrote: > > Andrew Haley wrote: > > > It will be invoked from the specfile, but by either > > > > > > a. Going to some java dir and running make, or > > > b. Running some VM-agnostic script that does a. > > > > It happens so quick. Why not have `java' be a script that invokes > > gij, and then just run it from there? Rebuild every time? It's fast, but it's not _that_ fast. The speed of rebuilding depends how many libraries you have installed, and scalability was my first design goal. (The time taken to do the rebuild is O(N) in theory, but likely slightly worse in practice because of the page cache.) > It needs to happen as root. > > Though, I wonder if per-session databases might not be a better idea. > Andrew? It's a bad idea IMO. The libraries that are installed are global on the system, and the database should be too. The database is in memory that's shared between all processes, and for that to be secure only root has write access to it. There's no reason not to have per-session databases in some special applications, but it is *not* a good choice for a default policy. Andrew. From gbenson at redhat.com Tue Nov 15 12:39:22 2005 From: gbenson at redhat.com (Gary Benson) Date: Tue, 15 Nov 2005 12:39:22 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <17273.51949.832543.911505@zapata.pink> References: <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> <4379169A.6090706@zarb.org> <20051115113303.GB5116@redhat.com> <17273.51949.832543.911505@zapata.pink> Message-ID: <20051115123918.GC5116@redhat.com> Andrew Haley wrote: > Gary Benson writes: > > David Walluck wrote: > > > Andrew Haley wrote: > > > > It will be invoked from the specfile, but by either > > > > > > > > a. Going to some java dir and running make, or > > > > b. Running some VM-agnostic script that does a. > > > > > > It happens so quick. Why not have `java' be a script that > > > invokes gij, and then just run it from there? > > Rebuild every time? It's fast, but it's not _that_ fast. The speed > of rebuilding depends how many libraries you have installed, and > scalability was my first design goal. (The time taken to do the > rebuild is O(N) in theory, but likely slightly worse in practice > because of the page cache.) > > > It needs to happen as root. > > > > Though, I wonder if per-session databases might not be a better > > idea. Andrew? > > It's a bad idea IMO. The libraries that are installed are global on > the system, and the database should be too. > > The database is in memory that's shared between all processes, and > for that to be secure only root has write access to it. There's no > reason not to have per-session databases in some special > applications, but it is *not* a good choice for a default policy. Fair enough. Cheers, Gary From aph at redhat.com Tue Nov 15 18:31:03 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Nov 2005 18:31:03 +0000 Subject: [fedora-java] Enhanced aot-compile script In-Reply-To: <20051114143229.GL12276@redhat.com> References: <20051114105701.GC12276@redhat.com> <17272.28186.195196.94720@zapata.pink> <20051114110804.GD12276@redhat.com> <17272.28957.759281.281219@zapata.pink> <20051114115304.GE12276@redhat.com> <17272.32156.317476.595770@zapata.pink> <20051114133243.GH12276@redhat.com> <17272.38365.857530.492285@zapata.pink> <20051114141452.GJ12276@redhat.com> <17272.40209.320611.129892@zapata.pink> <20051114143229.GL12276@redhat.com> Message-ID: <17274.10599.109209.722257@zapata.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson wrote: > > > Also note that while FC5 and the newest FC4 packages call > > > rebuild-gcj-db with no arguments, the majority of FC4 packages > > > will call 'rebuild-gcj-db /usr/lib' or 'rebuild-gcj-db > > > /usr/lib64'. Any replacement must not choke on this. > > > > OK. Is there somewhere an exact description of what arguemnts > > rebuild-gcj-db will take? > > The top of rebuild-gcj-db.in says: > > if [ $# != 0 ]; then > if [ $# != 1 -o $1 != @LIBDIR@ ]; then > # emit usage message and die > fi > fi > > @LIBDIR@ is either /usr/lib or /usr/lib64, depending. I just came across a nasty problem with all this. If you build a copy of gcj from CVS it won't pick up the system-wide database, because that is in /usr/lib/gcj-4.1.0/, not wherever gcj has been installed. We need a way to rebuild the database into the right place for the installed gcj. Having gcj-dbtool --rebuild in gcj itself will solve this very nicely because it will rebuild the installed copy, wherever that happens to be. Andrew. From mckinlay at redhat.com Tue Nov 15 18:55:25 2005 From: mckinlay at redhat.com (Bryce McKinlay) Date: Tue, 15 Nov 2005 13:55:25 -0500 Subject: [fedora-java] gcj-dbtool --rebuild In-Reply-To: <17268.45596.68211.922825@zapata.pink> References: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> <20051111134417.GJ4972@redhat.com> <17268.45596.68211.922825@zapata.pink> Message-ID: <437A2F1D.6090309@redhat.com> Andrew Haley wrote: >Gary Benson writes: > > Thomas Fitzsimmons wrote: > > > Here's what "gcj-dbtool --rebuild" needs to do: > > > > > > Merge all db files in "$prefix/lib/gcj-$gcc_version/classmap.db.d/" into > > > "$prefix/lib/gcj-$gcc_version/classmap.db". > > > > > > Even better for FC5 would be eliminating the need for individual .db > > > files altogether. > > > > This would require the hashes to be stored in the .so, which I don't > > think they are at present. Is this something which is possible? > >Yes. It is part of the Grand Plan. But reading the hashes out of a >.so is going to be far slower than out of a .db. It wouldn't be >practical if you had thousands of them. > > With hashes stored in the .so's, we'd still want to keep the .db as a sort of cache. The advantage would be that updating/rebuilding the db becomes much faster, as dbtool just needs to compare the hashes in each .so with what is in the database rather than reading all the bytecode and recomputing the hashes. It would be too slow for the general case to have libgcj reading hashes from all the shared libraries at runtime, but it would allow things to work better in the case where the classes in a particular .so at runtime don't match the contents of the db - something that could happen during development or in case someone forgets to run dbtool. Currently we just quietly fall back to the interpreter in that case, resulting in (seemingly) mysterious performance problems. Bryce From tromey at redhat.com Tue Nov 15 19:56:34 2005 From: tromey at redhat.com (Tom Tromey) Date: 15 Nov 2005 12:56:34 -0700 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: <20051114185850.GC25805@redhat.com> References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> <20051114185850.GC25805@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: >> FYI, I have been unable to dup this problem. It works fine for me. >> This suggests hat it might well be some sort of race. Andrew> Gah. I guess I can't get your help, then :( I saw this problem last night when checking out cacao. I was using 3.1.1-1jpp_2fc. FWIW I looked and noticed that the cvs .so was not being used, so it was running interpreted. This may be due to running rawhide versions; I've noticed that the compiler bump to 4.0.1 to 4.0.2 invalidated the .so cache -- we probably should have stripped that final digit from the cache directory name. Tom From aph at redhat.com Tue Nov 15 19:06:28 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Nov 2005 19:06:28 +0000 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> <20051114185850.GC25805@redhat.com> Message-ID: <17274.12724.590956.598538@zapata.pink> Tom Tromey writes: > >>>>> "Andrew" == Andrew Overholt writes: > > >> FYI, I have been unable to dup this problem. It works fine for me. > >> This suggests hat it might well be some sort of race. > > Andrew> Gah. I guess I can't get your help, then :( > > I saw this problem last night when checking out cacao. > I was using 3.1.1-1jpp_2fc. > > FWIW I looked and noticed that the cvs .so was not being used, so it > was running interpreted. This may be due to running rawhide versions; > I've noticed that the compiler bump to 4.0.1 to 4.0.2 invalidated the > .so cache -- we probably should have stripped that final digit from > the cache directory name. I think Gary already fixed this. We now install all the target libs under /usr/lib/gcj. We used to install them under gcj-4.0.*, and this was wrong. Andrew. From overholt at redhat.com Tue Nov 15 19:09:35 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Nov 2005 14:09:35 -0500 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> <20051114185850.GC25805@redhat.com> Message-ID: <20051115190935.GI10366@redhat.com> * Tom Tromey [2005-11-15 14:02]: > >>>>> "Andrew" == Andrew Overholt writes: > > >> FYI, I have been unable to dup this problem. It works fine for me. > >> This suggests hat it might well be some sort of race. > > Andrew> Gah. I guess I can't get your help, then :( > > I saw this problem last night when checking out cacao. > I was using 3.1.1-1jpp_2fc. > > FWIW I looked and noticed that the cvs .so was not being used, so it > was running interpreted. This may be due to running rawhide versions; > I've noticed that the compiler bump to 4.0.1 to 4.0.2 invalidated the > .so cache -- we probably should have stripped that final digit from > the cache directory name. I can't see how that happened. I've verified more than once that now that we've got -fjni in aot-compile-rpm in both FC4 and rawhide, all the jars that we have compiled (which is all of them in rawhide) should be loaded from .so and not bytecode. Andrew From aph at redhat.com Tue Nov 15 19:14:47 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Nov 2005 19:14:47 +0000 Subject: [fedora-java] gcj-dbtool --rebuild In-Reply-To: <437A2F1D.6090309@redhat.com> References: <1131662998.23505.30.camel@tortoise.toronto.redhat.com> <20051111134417.GJ4972@redhat.com> <17268.45596.68211.922825@zapata.pink> <437A2F1D.6090309@redhat.com> Message-ID: <17274.13223.664383.193146@zapata.pink> Bryce McKinlay writes: > Andrew Haley wrote: > > >Gary Benson writes: > > > Thomas Fitzsimmons wrote: > > > > Here's what "gcj-dbtool --rebuild" needs to do: > > > > > > > > Merge all db files in "$prefix/lib/gcj-$gcc_version/classmap.db.d/" into > > > > "$prefix/lib/gcj-$gcc_version/classmap.db". > > > > > > > > Even better for FC5 would be eliminating the need for individual .db > > > > files altogether. > > > > > > This would require the hashes to be stored in the .so, which I don't > > > think they are at present. Is this something which is possible? > > > >Yes. It is part of the Grand Plan. But reading the hashes out of a > >.so is going to be far slower than out of a .db. It wouldn't be > >practical if you had thousands of them. > > With hashes stored in the .so's, we'd still want to keep the .db as a > sort of cache. The advantage would be that updating/rebuilding the db > becomes much faster, as dbtool just needs to compare the hashes in each > .so with what is in the database rather than reading all the bytecode > and recomputing the hashes. Well, we only compute the hashes at package build time, so this won't affect installation time. > It would be too slow for the general case to have libgcj reading > hashes from all the shared libraries at runtime, but it would allow > things to work better in the case where the classes in a particular > .so at runtime don't match the contents of the db - something that > could happen during development or in case someone forgets to run > dbtool. Currently we just quietly fall back to the interpreter in > that case, resulting in (seemingly) mysterious performance > problems. Right. This is effectively "closing the loop", and it's one reason for putting the hashes into the DSOs. It's just one less weird thing that can go wrong. Andrew. From aph at redhat.com Tue Nov 15 19:44:20 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Nov 2005 19:44:20 +0000 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: <20051114185850.GC25805@redhat.com> References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> <20051114185850.GC25805@redhat.com> Message-ID: <17274.14996.715948.740716@zapata.pink> Andrew Overholt writes: > * Andrew Haley [2005-11-14 12:50]: > > Andrew Overholt writes: > > > RH Bug #161483 [1] > > > > > > CVS checkouts in Eclipse take an extremely long time to finish when run > > > under gij. > > > > FYI, I have been unable to dup this problem. It works fine for me. > > This suggests hat it might well be some sort of race. > > Gah. I guess I can't get your help, then :( I wouldn't say that. It will make it harder, though. Andrew. From tromey at redhat.com Tue Nov 15 22:29:37 2005 From: tromey at redhat.com (Tom Tromey) Date: 15 Nov 2005 15:29:37 -0700 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: <20051115190935.GI10366@redhat.com> References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> <20051114185850.GC25805@redhat.com> <20051115190935.GI10366@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> I can't see how that happened. I've verified more than once Andrew> that now that we've got -fjni in aot-compile-rpm in both FC4 Andrew> and rawhide, all the jars that we have compiled (which is all Andrew> of them in rawhide) should be loaded from .so and not Andrew> bytecode. I just updated eclipse on that machine and I got a bunch of errors about '/usr/bin/rebuild-gcj-db: No such file or directory'. I suppose this is more to blame than the minor version increment. Tom From overholt at redhat.com Tue Nov 15 21:36:41 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 15 Nov 2005 16:36:41 -0500 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> <20051114185850.GC25805@redhat.com> <20051115190935.GI10366@redhat.com> Message-ID: <20051115213641.GK10366@redhat.com> * Tom Tromey [2005-11-15 16:35]: > >>>>> "Andrew" == Andrew Overholt writes: > > Andrew> I can't see how that happened. I've verified more than once > Andrew> that now that we've got -fjni in aot-compile-rpm in both FC4 > Andrew> and rawhide, all the jars that we have compiled (which is all > Andrew> of them in rawhide) should be loaded from .so and not > Andrew> bytecode. > > I just updated eclipse on that machine and I got a bunch of errors > about '/usr/bin/rebuild-gcj-db: No such file or directory'. > I suppose this is more to blame than the minor version increment. This is due to the changes in java-1.4.2-gcj-compat{,-devel}. fitzsim can probably shed some light. Perhaps in a new thread, fitzsim? Andrew From fitzsim at redhat.com Tue Nov 15 21:42:17 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 15 Nov 2005 16:42:17 -0500 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: <20051115213641.GK10366@redhat.com> References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> <20051114185850.GC25805@redhat.com> <20051115190935.GI10366@redhat.com> <20051115213641.GK10366@redhat.com> Message-ID: <1132090938.23505.80.camel@tortoise.toronto.redhat.com> On Tue, 2005-11-15 at 16:36 -0500, Andrew Overholt wrote: > * Tom Tromey [2005-11-15 16:35]: > > >>>>> "Andrew" == Andrew Overholt writes: > > > > Andrew> I can't see how that happened. I've verified more than once > > Andrew> that now that we've got -fjni in aot-compile-rpm in both FC4 > > Andrew> and rawhide, all the jars that we have compiled (which is all > > Andrew> of them in rawhide) should be loaded from .so and not > > Andrew> bytecode. > > > > I just updated eclipse on that machine and I got a bunch of errors > > about '/usr/bin/rebuild-gcj-db: No such file or directory'. > > I suppose this is more to blame than the minor version increment. > > This is due to the changes in java-1.4.2-gcj-compat{,-devel}. fitzsim can > probably shed some light. Perhaps in a new thread, fitzsim? Update to Rawhide java-1.4.2-gcj-compat-devel. Tom From david at zarb.org Tue Nov 15 22:22:14 2005 From: david at zarb.org (David Walluck) Date: Tue, 15 Nov 2005 17:22:14 -0500 Subject: [fedora-java] Re: gij and Eclipse CVS checkout finalization In-Reply-To: References: <20051114171636.GB25805@redhat.com> <17272.52805.626329.288622@zapata.pink> <20051114185850.GC25805@redhat.com> Message-ID: <437A5F96.2050001@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Tromey wrote: > I saw this problem last night when checking out cacao. > I was using 3.1.1-1jpp_2fc. Hey, let's get some jpackage rpms of cacao ;) I built both kaffe and jamvm and neither can seem to run eclipse on x86_64. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDel+WarJDwJ6gwowRAhUaAJ9YufE3YaWkKmsGLINGsk0ncxwKvQCfQ3eq JlNKygcDiNMYiCARF37Q1b4= =ySV7 -----END PGP SIGNATURE----- From overholt at redhat.com Wed Nov 16 21:41:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 16 Nov 2005 16:41:14 -0500 Subject: [fedora-java] Native Eclipse 3.1 doesn't start In-Reply-To: <1126636890.3160.36.camel@localhost.localdomain> References: <1126636890.3160.36.camel@localhost.localdomain> Message-ID: <20051116214114.GD18320@redhat.com> Hi, * Dominik ?eszyk [2005-09-13 15:57]: > I'm really fresh to java-fedora stuff so maybe it's the reason for my > problem: Sorry no one got back to you. Are you still having problems? > after compiling Eclipse 3.1 using the script from 'GNU > Classpath Wiki' [1] I can't start it. There is an error log: > > [...] > > 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? Hmm. Why were you trying to build it yourself (just curious)? I'm not sure that the instructions on the Classpath Wiki are up-to-date. Perhaps take a look at our specfile and see if you notice any differences. Andrew From kremvax at gmail.com Wed Nov 16 22:01:42 2005 From: kremvax at gmail.com (Mark Wilkinson) Date: Wed, 16 Nov 2005 22:01:42 +0000 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: <28137cef0511161401q20fda4aewe9bde883398db47f@mail.gmail.com> Resurrecting an old thread as I'm catching up... On 9/19/05, Vadim Nasardinov 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. > > (d) go wild and make the choice of repos configurable on a > per-package basis. My simple solution to this problem has been to add an exclude= line to my jpackage.repo file listing the names of all the Java packages that shipped with FC4: [jpackage-generic] name=JPackage (free), generic mirrorlist=http://www.jpackage.org/jpackage_generic.txt failovermethod=priority gpgcheck=1 gpgkey=http://www.jpackage.org/jpackage.asc enabled=1 exclude=ant, ant-antlr, ant-apache-bcel, ant-apache-log4j, ant-apache-oro, ant-apache-regexp, ant-apache-resolver, ant-commons-logging, ... and so on. The list of packages was built by grepping for [0-9]*jpp_[0-9]*fc from the list of the packages that shipped with FC4, then stripping off the version numbers. When I first saw the problem mentioned on this list I was surprised that the jpackage.org site didn't suggest something like this to prevent JPackage packages from replacing the Fedora ones. -Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fitzsim at redhat.com Fri Nov 18 22:21:37 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 18 Nov 2005 17:21:37 -0500 Subject: [fedora-java] missing rebuild-gcj-db and aot-compile-rpm scripts Message-ID: <1132352498.23505.195.camel@tortoise.toronto.redhat.com> Hi, People using Rawhide java-1.4.2-gcj-compat will have noticed that rebuild-gcj-db and aot-compile-rpm get deleted when upgrading from <= 1.4.2.0-40jpp_51rh to >= 1.4.2.0-40jpp_52rh. This was caused by a bug in "update-alternatives --install" where it would remove filenames that no longer appeared in the alternatives database: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173685 Bill Nottingham has built into Rawhide chkconfig-1.3.24-1, which I confirmed fixes the bug. In the meantime you can work around the problem by --force reinstalling java-1.4.2-gcj-compat >= 1.4.2.0-40jpp_52rh and java-1.4.2-gcj-compat-devel >= 1.4.2.0-40jpp_52rh from your yum cache. Tom From orion at cora.nwra.com Mon Nov 21 23:57:15 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 21 Nov 2005 16:57:15 -0700 Subject: [fedora-java] Many dependencies for eclipse-cdt In-Reply-To: <20051114190145.GD25805@redhat.com> References: <4378D04A.40404@cora.nwra.com> <20051114190145.GD25805@redhat.com> Message-ID: <43825EDB.70600@cora.nwra.com> Andrew Overholt wrote: > * Orion Poplawski [2005-11-14 12:59]: > >>Are all of these really necessary? > > > Yes. The dependencies aren't really CDT deps but rather those of the > Eclipse SDK. They're dependencies because we don't just ship pre-built > jars like upstream does (which limits their dependencies). Is it a > problem? > > Andrew Probably not a real problem, but all I want is a basic C IDE setup and lots of other things come along. Just seems excessive, but as they say, disk is cheap! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From aph at redhat.com Mon Nov 28 12:44:25 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Nov 2005 12:44:25 +0000 Subject: [fedora-java] Release Notes In-Reply-To: <1130022905.2985.48.camel@localhost.localdomain> References: <1130022905.2985.48.camel@localhost.localdomain> Message-ID: <17290.64425.317892.748685@zapata.pink> Anthony Green writes: > The current "Java" content for the release notes (from FC4) are pretty > slim. I'll quote them below with my comments and questions... > > > Fedora Core 4 users are advised not to use the Java RPM provided by > > Sun. It contains Provides that conflict with names used in packages > > provided as part of Fedora Core 4. Because of this, Sun Java might > > disappear from an installed system during package upgrade operations. > > I assume this is still true. Does anybody have a pointer to the > details? > > > Fedora Core 4 users should use either the RPM available from > > http://www.jpackage.org/, or manually install the Sun Java tarball > > into `/opt/`. > > I think we should discourage the /opt solution, since it doesn't > integrate with out alternatives-based solution. Absolutely. Something more like "You may manually install the Sun Java tarball into `/opt/`, but this is not a recommended configuration because it doesn't integrate with our alternatives-based solution." > Also, I thought there were problems with using the binary RPM from > JPackage, and users _have_ to rebuild from the SRPM. Does anybody > know about this? > > > Sun Java 1.5+ is recommended for stability purposes. > > Is this really true? What about IBM or BEA? Should we even be > making specific recommendations here? Perhaps this is best > avoided. I think it is, yes. Can we get these release notes fixed in FC4, rather than waiting for FC5? Andrew. From gbenson at redhat.com Mon Nov 28 13:35:46 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 28 Nov 2005 13:35:46 +0000 Subject: [fedora-java] Release Notes In-Reply-To: <17290.64425.317892.748685@zapata.pink> References: <1130022905.2985.48.camel@localhost.localdomain> <17290.64425.317892.748685@zapata.pink> Message-ID: <20051128133542.GD12549@redhat.com> Andrew Haley wrote: > Anthony Green writes: > > The current "Java" content for the release notes (from FC4) are pretty > > slim. I'll quote them below with my comments and questions... > > > > > Fedora Core 4 users are advised not to use the Java RPM provided by > > > Sun. It contains Provides that conflict with names used in packages > > > provided as part of Fedora Core 4. Because of this, Sun Java might > > > disappear from an installed system during package upgrade operations. > > > > I assume this is still true. Does anybody have a pointer to the > > details? > > > > > Fedora Core 4 users should use either the RPM available from > > > http://www.jpackage.org/, or manually install the Sun Java tarball > > > into `/opt/`. > > > > I think we should discourage the /opt solution, since it doesn't > > integrate with out alternatives-based solution. > > Absolutely. Something more like "You may manually install the Sun > Java tarball into `/opt/`, but this is not a recommended configuration > because it doesn't integrate with our alternatives-based solution." > > > Also, I thought there were problems with using the binary RPM from > > JPackage, and users _have_ to rebuild from the SRPM. Does anybody > > know about this? > > > > > Sun Java 1.5+ is recommended for stability purposes. > > > > Is this really true? What about IBM or BEA? Should we even be > > making specific recommendations here? Perhaps this is best > > avoided. > > I think it is, yes. See also http://www.fedoraproject.org/wiki/JavaFAQ Cheers, Gary From karltk at gentoo.org Tue Nov 29 02:37:24 2005 From: karltk at gentoo.org (Karl Trygve Kalleberg) Date: Tue, 29 Nov 2005 03:37:24 +0100 Subject: [fedora-java] Release Notes In-Reply-To: <17290.64425.317892.748685@zapata.pink> References: <1130022905.2985.48.camel@localhost.localdomain> <17290.64425.317892.748685@zapata.pink> Message-ID: <438BBEE4.6000602@gentoo.org> Andrew Haley wrote: > > > Sun Java 1.5+ is recommended for stability purposes. > > > > Is this really true? What about IBM or BEA? Should we even be > > making specific recommendations here? Perhaps this is best > > avoided. The performance and stability characteristics of the BEA, Sun and IBM offerings are different, and in my experience it is difficult to hail one of them as a clear winner. If you _are_ going to mention vendor-specific offerings, it may be idea to mention all three, since they are all pretty decent and available on x86 and x86_64 (IBM has a beta of 1.5 for PPC; BEA works on IA64). Cheers, -- Karl T