From aph at redhat.com Thu Jun 7 10:51:31 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jun 2007 18:51:31 +0100 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <18021.41279.681053.215267@zebedee.pink> References: <18021.41279.681053.215267@zebedee.pink> Message-ID: <18024.17827.200817.449754@zebedee.pink> At the present time it's not possible to build a fully Free Software version of OpenJDK, because of the presence of some "binary plugs". Quoting http://openjdk.java.net/: "Not all of the source code that makes up the JDK is available under an open-source license. In order to build an OpenJDK binary from source code, you must first download and install one or more of the following files from which the build process will copy over 'binary plugs' for these encumbered components." In addition to this, it's necessary to download an unfree JDK to build OpenJDK. We have been working within Red Hat to replace these binary plugs with free software based on GNU Classpath and to remove the need for bootstrapping with unfree software. This is important for a number of reasons, the most pressing being that only free software may be used to build operating systems like Fedora. We intend this build repository, based on OpenJDK, to provide a basis on which to experiment. It's not a fork from OpenJDK, and doesn't contain the OpenJDK source code. We have used the name IcedTea because JDK and OpenJDK are trademarks and we wish to make it perfectly clear that, while this project uses source code from the OpenJDK project, it is not OpenJDK. I'm sure some people will wonder why we've set up this repository rather than submitting our replacements for the binary plugs to openjdk.java.net. Sun hasn't set up a Mercurial repository yet, and we need a public version control system system to work in. Also, this is not mature tested code, it's an experiment. We've been doing this experiment inside Red Hat, and we know from experience that working in the open is better than working behind closed doors. The next question that arises is "will you be submitting these changes to the OpenJDK process?" The answer is yes, we will, once the legal and technical issues are resolved. These "binary plugs" are not complete: they do not replicate all the functionality of the binary plugs used in the OpenJDK. If you need a fully-functional OpenJDK, follow the instructions on http://openjdk.java.net/. However, these "binary plugs" are sufficient to allow IcedTea to build itself without any software that is not free. It's important to show that we can do this, if only as a proof of concept. We'd like to thank the GNU Classpath hackers (and Jim Pick in particular) for sharing the infrastructure at classpath.org that makes this possible. And, of course, for writing the code in GNU Classpath. Andrew. To get started on a Fedora 7 GNU/Linux system with yum: $ sudo yum install /usr/bin/ecj mercurial cups-devel lesstif-devel libXp-devel xalan-j2 xerces-j2 libXt-devel libgcj Then: $ hg clone http://icedtea.classpath.org/hg/icedtea $ cd icedtea Full build instructions are in INSTALL, but this works for me: $ ./configure $ make When this completes you'll have a usable IcedTea in openjdk/control/build/linux-i586 or openjdk/control/build/linux-amd64. Alternatively, you can bootstrap by building IcedTea twice, once with ecj/gcj and then with IcedTea: $ make bootstrap -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Tom.Marble at Sun.COM Thu Jun 7 11:25:49 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Thu, 07 Jun 2007 13:25:49 -0500 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <18024.17827.200817.449754@zebedee.pink> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> Message-ID: <46684DAD.7070701@sun.com> Andrew Haley wrote: > We have been working within Red Hat to replace these binary plugs with > free software based on GNU Classpath and to remove the need for > bootstrapping with unfree software. This is important for a number of > reasons, the most pressing being that only free software may be used > to build operating systems like Fedora. Indeed and we understand the importance of getting OpenJDK into Free Software distributions. The milestone today of making a buildable IcedTea is a huge step in this direction. Now the OpenJDK team needs to take a look at this experiment and evaluate the approach to closing these encumbrances. http://icedtea.classpath.org > We have used the name IcedTea because JDK and OpenJDK are trademarks > and we wish to make it perfectly clear that, while this project uses > source code from the OpenJDK project, it is not OpenJDK. I hope that in time the use of the OpenJDK trademark can be liberalized such that builds which are substantially from the OpenJDK code base can be called OpenJDK. > I'm sure some people will wonder why we've set up this repository > rather than submitting our replacements for the binary plugs to > openjdk.java.net. Sun hasn't set up a Mercurial repository yet, and > we need a public version control system system to work in. Also, this > is not mature tested code, it's an experiment. We've been doing this > experiment inside Red Hat, and we know from experience that working in > the open is better than working behind closed doors. And we hope to learn from your experience... thank you for collaborating with us so quickly on OpenJDK. > The next question that arises is "will you be submitting these changes > to the OpenJDK process?" The answer is yes, we will, once the legal > and technical issues are resolved. The eyes will now be on the technical teams to understand and evaluate the Free Software alternatives that you have proposed. I would like to thank Mark Wielaard for taking the initiative to start a dialog with the Free Software Foundation and the Software Freedom Law Center about how Classpath code could be contributed back to OpenJDK under the Sun Contributor Agreement. > These "binary plugs" are not complete: they do not replicate all the > functionality of the binary plugs used in the OpenJDK. If you need a > fully-functional OpenJDK, follow the instructions on > http://openjdk.java.net/. However, these "binary plugs" are > sufficient to allow IcedTea to build itself without any software that > is not free. It's important to show that we can do this, if only as a > proof of concept. And this highlights the need for us, as a community, to continue to develop and/or liberate testing tools that help us understand exactly the functional, quality and performance aspects of runtimes. > We'd like to thank the GNU Classpath hackers (and Jim Pick in > particular) for sharing the infrastructure at classpath.org that makes > this possible. And, of course, for writing the code in GNU Classpath. I'd like to thank you Andrew as well as Tom Fitzsimmons and the rest of the Classpath & Friends crew who pulled IcedTea together. (Would someone please roll the credits???) > $ hg clone http://icedtea.classpath.org/hg/icedtea > $ cd icedtea Thank you for using Mercurial!!! > Full build instructions are in INSTALL, but this works for me: > > $ ./configure > $ make Thank you for the autoconfiscation!!! http://en.wikipedia.org/wiki/Autoconfiscation > When this completes you'll have a usable IcedTea in > openjdk/control/build/linux-i586 or openjdk/control/build/linux-amd64. > > Alternatively, you can bootstrap by building IcedTea twice, once with > ecj/gcj and then with IcedTea: > > $ make bootstrap Sweet Software Freedom!!! And thank you for using the OpenJDK mailing list disto-pkg-dev!!! Those interested should sign up here: http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev Or follow along on Gmane: http://news.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel Truly and Freely yours, --Tom From David.Herron at Sun.COM Thu Jun 7 12:03:31 2007 From: David.Herron at Sun.COM (David Herron) Date: Thu, 07 Jun 2007 12:03:31 -0700 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <18024.17827.200817.449754@zebedee.pink> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> Message-ID: <46685683.1070506@sun.com> Interesting... I tried replicating this on Ubuntu 7.04 and ran into a couple issues. First, the .jar files for Xerces and Xalan seem to be constructed on Ubuntu differently than the configure script assumes. So I did this: root at dherron:/usr/share/java# ln -s libgcj-4.1.jar libgcj-4.1.2.jar root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2.jar root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2-serializer.jar root at dherron:/usr/share/java# ln -s xercesImpl.jar xerces-j2.jar I looked and xalan2.jar has a package providing classes named Serializer* so I assume that's what you meant to use. Next thing is when I ran "make" it downloaded the b12 source bundle. We're already on b13, b14 should occur "soon", etc. I noticed there's an option to configure to specify an openjdk source tree, so will this icedtea thing work against an arbitrary openjdk source tree? Finally, after letting it go ahead and download and unpack b12, the "make" got to this error, and died: mkdir -p bootstrap/jdk1.7.0/jre/lib/ext /usr/bin/jar cf bootstrap/jdk1.7.0/jre/lib/ext/sunjce_provider.jar *'c' flag requires manifest or input files to be specified!* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070607/63b8f5ee/attachment.html From aph at redhat.com Thu Jun 7 12:11:35 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jun 2007 20:11:35 +0100 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <46685683.1070506@sun.com> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> <46685683.1070506@sun.com> Message-ID: <18024.22631.463825.391254@zebedee.pink> David Herron writes: > > Interesting... > > I tried replicating this on Ubuntu 7.04 and ran into a couple issues. > > First, the .jar files for Xerces and Xalan seem to be constructed on > Ubuntu differently than the configure script assumes. So I did this: > > root at dherron:/usr/share/java# ln -s libgcj-4.1.jar libgcj-4.1.2.jar > root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2.jar > root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2-serializer.jar > root at dherron:/usr/share/java# ln -s xercesImpl.jar xerces-j2.jar > > I looked and xalan2.jar has a package providing classes named > Serializer* so I assume that's what you meant to use. > > Next thing is when I ran "make" it downloaded the b12 source bundle. > We're already on b13, b14 should occur "soon", etc. I noticed there's > an option to configure to specify an openjdk source tree, so will this > icedtea thing work against an arbitrary openjdk source tree? All that, of course, depends on what you do to the openjdk source tree. Realistically speaking, changes will probably be needed. > Finally, after letting it go ahead and download and unpack b12, the > "make" got to this error, and died: > > mkdir -p bootstrap/jdk1.7.0/jre/lib/ext > /usr/bin/jar cf bootstrap/jdk1.7.0/jre/lib/ext/sunjce_provider.jar > *'c' flag requires manifest or input files to be specified!* Ouch. Looks like the jar program you have is rather fussy. These are just dummy files. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From aph at redhat.com Thu Jun 7 12:17:22 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jun 2007 20:17:22 +0100 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <46684DAD.7070701@sun.com> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> <46684DAD.7070701@sun.com> Message-ID: <18024.22978.371474.808361@zebedee.pink> Tom Marble writes: > Andrew Haley wrote: > > > We'd like to thank the GNU Classpath hackers (and Jim Pick in > > particular) for sharing the infrastructure at classpath.org that makes > > this possible. And, of course, for writing the code in GNU Classpath. > I'd like to thank you Andrew as well as Tom Fitzsimmons and the rest of the > Classpath & Friends crew who pulled IcedTea together. (Would someone > please roll the credits???) I was a little reluctant to name anyone in particular, since this has been a team effort. It's always a great risk to make names because you sometimes forget some staff member who has make heroic efforts. But yeah, we should probably do that. > Thank you for the autoconfiscation!!! http://en.wikipedia.org/wiki/Autoconfiscation Ah, we only autoconfiscated our little part. :-) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Tom.Marble at Sun.COM Thu Jun 7 12:25:25 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Thu, 07 Jun 2007 14:25:25 -0500 Subject: Building OpenJDK on Ubuntu Message-ID: <46685BA5.2090606@sun.com> All: I have been building OpenJDK on Ubuntu. Has anyone else been building on Debian or Ubuntu? Thanks, --Tom From aph at redhat.com Thu Jun 7 12:34:31 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jun 2007 20:34:31 +0100 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <46685683.1070506@sun.com> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> <46685683.1070506@sun.com> Message-ID: <18024.24008.23.605682@zebedee.pink> David Herron writes: > > Interesting... > > I tried replicating this on Ubuntu 7.04 and ran into a couple issues. > > First, the .jar files for Xerces and Xalan seem to be constructed on > Ubuntu differently than the configure script assumes. So I did this: > > root at dherron:/usr/share/java# ln -s libgcj-4.1.jar libgcj-4.1.2.jar > root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2.jar > root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2-serializer.jar > root at dherron:/usr/share/java# ln -s xercesImpl.jar xerces-j2.jar > > I looked and xalan2.jar has a package providing classes named > Serializer* so I assume that's what you meant to use. I'll warn you now that you'll need a recent version of gcj for this to work. Only the gcj that's on Fedora 7, which has only been out a couple of weeks, will work. I don't know what's on your Ubuntu system. It will probably be useful for us to try building icedtea with gcj built from downloaded source for the benefit of people whose operating systems don't have the latest version installed. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From thunderaxiom at gmail.com Thu Jun 7 14:12:36 2007 From: thunderaxiom at gmail.com (=?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?=) Date: Thu, 07 Jun 2007 23:12:36 +0200 Subject: Building OpenJDK on Ubuntu In-Reply-To: <46685BA5.2090606@sun.com> References: <46685BA5.2090606@sun.com> Message-ID: <466874C4.3010205@gmail.com> Tom Marble skrev den 07-06-2007 21:25: > All: > > I have been building OpenJDK on Ubuntu. > Has anyone else been building on Debian or Ubuntu? > I did it last week on Ubuntu 7.04 too. Took a while to get dependencies right, but then it just took a while. Would it be possible to have a small apt-get repository at java.net to make it easier for Ubuntu folks? -- Thorbj?rn From Tom.Marble at Sun.COM Thu Jun 7 15:13:05 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Thu, 07 Jun 2007 17:13:05 -0500 Subject: Building OpenJDK on Ubuntu In-Reply-To: <466874C4.3010205@gmail.com> References: <46685BA5.2090606@sun.com> <466874C4.3010205@gmail.com> Message-ID: <466882F1.4010707@sun.com> Thorbj?rn Ravn Andersen wrote: > I did it last week on Ubuntu 7.04 too. Took a while to get dependencies > right, but then it just took a while. > > Would it be possible to have a small apt-get repository at java.net to > make it easier for Ubuntu folks? I think it would be great to do that for Ubuntu (feisty and gutsy) and for Debian (etch, lenny, unstable). Separately I just started building IcedTea and my version of gcj on feisty is not sufficiently up to date. Michael has done some work (already) on defining build dependencies for IcedTea on Debian. I'd be glad to host such repositories (meta packages for build dependencies for OpenJDK and IcedTea) on java.net. Regards, --Tom p.s. one of the patches we'll have to add to IcedTea has to do with jar naming (see David Herron's mail) From fkung at redhat.com Thu Jun 7 16:23:33 2007 From: fkung at redhat.com (Francis Kung) Date: Thu, 07 Jun 2007 19:23:33 -0400 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <46685683.1070506@sun.com> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> <46685683.1070506@sun.com> Message-ID: <46689375.1060208@redhat.com> > First, the .jar files for Xerces and Xalan seem to be constructed on > Ubuntu differently than the configure script assumes. So I did this: > > root at dherron:/usr/share/java# ln -s libgcj-4.1.jar libgcj-4.1.2.jar > root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2.jar > root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2-serializer.jar > root at dherron:/usr/share/java# ln -s xercesImpl.jar xerces-j2.jar > > I looked and xalan2.jar has a package providing classes named > Serializer* so I assume that's what you meant to use. Thanks for noting those. I've added those to the IcedTea build system as additional locations to check. > Next thing is when I ran "make" it downloaded the b12 source bundle. > We're already on b13, b14 should occur "soon", etc. I noticed there's > an option to configure to specify an openjdk source tree, so will this > icedtea thing work against an arbitrary openjdk source tree? I didn't realise we were on b13 (was there any public announcement? announce at openjdk.java.net would be a natural place). I've just downloaded the b13 and tried a build; unfortunately it fails, so it looks like b12 is required for now. > Finally, after letting it go ahead and download and unpack b12, the > "make" got to this error, and died: > > mkdir -p bootstrap/jdk1.7.0/jre/lib/ext > /usr/bin/jar cf bootstrap/jdk1.7.0/jre/lib/ext/sunjce_provider.jar > *'c' flag requires manifest or input files to be specified!* The version of jar we are using allows us to omit input files to create an empty jar, but it looks like this version doesn't. As a work-around, I've added a dummy input file to the jar command. These changes (xalan/xerces locations and empty jars) have been checked into the IcedTea mercurial repository. Cheers, Francis From acidbriggs at gmail.com Thu Jun 7 18:44:03 2007 From: acidbriggs at gmail.com (Briggs) Date: Thu, 7 Jun 2007 21:44:03 -0400 Subject: IcedTea and OS X Message-ID: <1c0e93080706071844m2dbd68d9r433df2b107ba93c6@mail.gmail.com> So, I'll ask the silly question... Does iced tea make it possible to build the OpenJDK on OS X yet? -- "Conscious decisions by conscious minds are what make reality real" From Tom.Marble at Sun.COM Thu Jun 7 19:15:19 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Thu, 07 Jun 2007 21:15:19 -0500 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <46689375.1060208@redhat.com> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> <46685683.1070506@sun.com> <46689375.1060208@redhat.com> Message-ID: <4668BBB7.6040200@sun.com> Francis Kung wrote: > The version of jar we are using allows us to omit input files to create > an empty jar, but it looks like this version doesn't. As a work-around, > I've added a dummy input file to the jar command. > > These changes (xalan/xerces locations and empty jars) have been checked > into the IcedTea mercurial repository. For fun I have been trying to use OpenJDK (b13) as the bootstrap for IcedTea. To workaround the above problem I did this: tmarble at ontologie:~/IcedTea/icedtea$ export PATH=$PATH:/usr/lib/classpath tmarble at ontologie:~/IcedTea/icedtea$ which gjar /usr/lib/classpath/gjar I also had to make sure I had jamvm installed... cd lib/rt ; \ /usr/lib/classpath/gjar cf rt.jar com gnu java javax sun exec: 47: /usr/bin/jamvm: not found make: *** [lib/rt/rt.jar] Error 2 (So all the Classpath & Friends are involved :) tmarble at ontologie:~/IcedTea/icedtea$ ./configure --with-java=/home/tmarble/OpenJDK/openjdk/control/build/linux-i586/bin/java I let it (like robogeek) download b12, but then got hung up on an XML issue... I think this is because my gcj version is tool old??? /home/tmarble/IcedTea/icedtea/bootstrap/jdk1.6.0/bin/java -Djava.endorsed.dirs=/home/tmarble/IcedTea/icedtea/bootstrap/jdk1.6.0/lib/endorsed -classpath /home/tmarble/IcedTea/icedtea/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/jvmtifiles jvmtiGen -IN /home/tmarble/IcedTea/icedtea/openjdk/hotspot/src/share/vm/prims/jvmti.xml -XSL /home/tmarble/IcedTea/icedtea/openjdk/hotspot/src/share/vm/prims/jvmtiHpp.xsl -OUT /home/tmarble/IcedTea/icedtea/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/jvmtifiles/jvmtiEnv.hpp Info: jvmtiGen using javax.xml.transform.TransformerFactory = org.apache.xalan.processor.TransformerFactoryImpl Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/xml/serializer/SerializerTrace at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2445) at java.lang.Class.getMethod0(Class.java:2688) at java.lang.Class.getMethod(Class.java:1621) In any case thanks for your help with IcedTea!!! --Tom From Tom.Marble at Sun.COM Thu Jun 7 19:18:36 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Thu, 07 Jun 2007 21:18:36 -0500 Subject: IcedTea and OS X In-Reply-To: <1c0e93080706071844m2dbd68d9r433df2b107ba93c6@mail.gmail.com> References: <1c0e93080706071844m2dbd68d9r433df2b107ba93c6@mail.gmail.com> Message-ID: <4668BC7C.4020600@sun.com> Briggs wrote: > So, I'll ask the silly question... Does iced tea make it possible to > build the OpenJDK on OS X yet? This is a very interesting question. Did you realize that Mac OS X is, itself, built with the GNU toolchain? In theory this shouldn't be too hard, but the trick is that OpenJDK is missing the operating specific directory (os/macosx) and the architecture specific directories (os_cpu/macosx_*). Do you think there are many OpenJDK *platform* developers who work on Mac OS X? Regards, --Tom From David.Herron at Sun.COM Thu Jun 7 19:50:11 2007 From: David.Herron at Sun.COM (David Herron) Date: Thu, 07 Jun 2007 19:50:11 -0700 Subject: IcedTea and OS X In-Reply-To: <4668BC7C.4020600@sun.com> References: <1c0e93080706071844m2dbd68d9r433df2b107ba93c6@mail.gmail.com> <4668BC7C.4020600@sun.com> Message-ID: <4668C3E3.70204@sun.com> So, Tom, isn't this statement a bit like that Dilbert cartoon from 1995 where HR is suggesting that for the job description they're trying to fill, that a requirement is 10 years of Java experience. Back in 1995 nobody had 10 years Java experience. And today nobody can do OpenJDK "Platform Development" on Mac OS X.. because of the problems you mentioned. But clearly there are people who want to do OpenJDK platform development while using Mac OS X. - David Tom Marble wrote: > Briggs wrote: > >> So, I'll ask the silly question... Does iced tea make it possible to >> build the OpenJDK on OS X yet? > Do you think there are many OpenJDK *platform* developers > who work on Mac OS X? > > Regards, > > --Tom > From Tom.Marble at Sun.COM Thu Jun 7 19:58:50 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Thu, 07 Jun 2007 21:58:50 -0500 Subject: IcedTea and OS X In-Reply-To: <4668C3E3.70204@sun.com> References: <1c0e93080706071844m2dbd68d9r433df2b107ba93c6@mail.gmail.com> <4668BC7C.4020600@sun.com> <4668C3E3.70204@sun.com> Message-ID: <4668C5EA.9020509@sun.com> David Herron wrote: > But clearly there are people who want to do OpenJDK platform development > while using Mac OS X. > > Tom Marble wrote: >> Do you think there are many OpenJDK *platform* developers >> who work on Mac OS X? It's my twisted sense of humor... it's intended, really, to be a two part question: 1) How many people would like to play with OpenJDK (JDK 7 alpha) on Mac OS X? 2) Of those, how many may have the passion and ability to contribute to OpenJDK to combine the unique "it just works (TM)" Mac OS X experience with the power of open source? I think it's a great idea! How can we reach these people so they can let their voices be heard? Regards, --Tom From mark at klomp.org Fri Jun 8 00:41:18 2007 From: mark at klomp.org (Mark Wielaard) Date: Fri, 08 Jun 2007 09:41:18 +0200 Subject: Mauve test run results Message-ID: <1181288479.4418.28.camel@dijkstra.wildebeest.org> Tom asked on my blog about the mauve test run results http://gnu.wildebeest.org/diary/2007/06/07/icedtea/ And I thought the answer would be appropriate for the list especially in the light of how we are going to make sure icedtea/openjdk derivatives are "good". Mauve is a nice check that icedtea/openjdk conforms to what we expect from a GNU Classpath derived runtime, but you would also want other tests of course to see that it confirms to the quality that people have come expected of the Sun Java releases. Posted the output of a run at http://www.klomp.org/mark/classpath/icedtea-1.0-mauve-run.out Since mauve doesn?t have an easy option not to run any awt/swing related tests this is just done by hand as follows: PATH=~/src/icedtea/openjdk/control/build/linux-i586/bin:$PATH ~/src/icedtea/openjdk/control/build/linux-i586/bin/java Harness -vm ~/src/icedtea/openjdk/control/build/linux-i586/bin/java -timeout 30000 -showpasses java.io java.net java.lang java.math java.security java.text java.util java.nio java.rmi java.sql javax.crypto javax.accessibility javax.activity javax.management javax.net javax.rmi javax.xml javax.transaction javax.sql javax.security javax.naming Note that this is the first time that I have run the Mauve tests on anything not GNU Classpath derived and some tests fail because of different assumptions of what the core classes should do and some fail because they have hard coded GNU dependencies (bad us!) and in the case of the Character failures it seems Unicode has moved on since those were written. So some cleaning up of these tests is in order. From gbenson at redhat.com Fri Jun 8 01:09:01 2007 From: gbenson at redhat.com (Gary Benson) Date: Fri, 8 Jun 2007 09:09:01 +0100 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <46685683.1070506@sun.com> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> <46685683.1070506@sun.com> Message-ID: <20070608080901.GA4114@redhat.com> David Herron wrote: > First, the .jar files for Xerces and Xalan seem to be constructed > on Ubuntu differently than the configure script assumes. So I did > this: > > root at dherron:/usr/share/java# ln -s xalan2.jar xalan-j2-serializer.jar > > I looked and xalan2.jar has a package providing classes named > Serializer* so I assume that's what you meant to use. Older versions of xalan had the serializer classes in the main jar iirc. Cheers, Gary From matthew.flaschen at gatech.edu Fri Jun 8 02:01:13 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Fri, 08 Jun 2007 05:01:13 -0400 Subject: Ubuntu Dapper Build Message-ID: <46691AD9.9010606@gatech.edu> I tried to build on Ubuntu (really gNewSense) Dapper and got the below error: checking for eclipse-ecj.jar... no configure: error: "A ECJ jar was not found." Can anyone suggest where to find this file (preferably packaged in a logical place :) ) Matthew Flaschen From konqueror at gmx.de Fri Jun 8 02:04:58 2007 From: konqueror at gmx.de (Michael Koch) Date: Fri, 8 Jun 2007 11:04:58 +0200 Subject: Ubuntu Dapper Build In-Reply-To: <46691AD9.9010606@gatech.edu> References: <46691AD9.9010606@gatech.edu> Message-ID: <20070608090458.GJ16684@mail.konqueror.de> On Fri, Jun 08, 2007 at 05:01:13AM -0400, Matthew Flaschen wrote: > I tried to build on Ubuntu (really gNewSense) Dapper and got the below > error: > > checking for eclipse-ecj.jar... no > configure: error: "A ECJ jar was not found." > > Can anyone suggest where to find this file (preferably packaged in a > logical place :) ) sudo aptitude install ecj. (or on older Ubuntu/Debian ecj-boostrap instead of ecj) I'm preparing a meta package which depends on all build dependencies and adds some links for Debian and Ubuntu. When ready I will announce it here. Cheers, Michael -- .''`. | Michael Koch : :' : | Free Java Developer `. `' | `- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B From matthew.flaschen at gatech.edu Fri Jun 8 02:15:29 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Fri, 08 Jun 2007 05:15:29 -0400 Subject: Ubuntu Dapper Build In-Reply-To: <20070608090458.GJ16684@mail.konqueror.de> References: <46691AD9.9010606@gatech.edu> <20070608090458.GJ16684@mail.konqueror.de> Message-ID: <46691E31.20409@gatech.edu> Michael Koch wrote: >> Can anyone suggest where to find this file (preferably packaged in a >> logical place :) ) > > sudo aptitude install ecj Thanks for the quick response, but ecj-bootstrap is already installed. > I'm preparing a meta package which depends on all build dependencies and > adds some links for Debian and Ubuntu. When ready I will announce it > here. I appreciate it. I'd still like to build it myself if possible. Matt Flaschen From aph at redhat.com Fri Jun 8 02:27:00 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Jun 2007 10:27:00 +0100 Subject: Ubuntu Dapper Build In-Reply-To: <46691AD9.9010606@gatech.edu> References: <46691AD9.9010606@gatech.edu> Message-ID: <18025.8420.239969.762089@zebedee.pink> Matthew Flaschen writes: > I tried to build on Ubuntu (really gNewSense) Dapper and got the below > error: > > checking for eclipse-ecj.jar... no > configure: error: "A ECJ jar was not found." > > Can anyone suggest where to find this file (preferably packaged in a > logical place :) ) Try this: gij --version and tell us the result. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From aph at redhat.com Fri Jun 8 02:28:28 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Jun 2007 10:28:28 +0100 Subject: Ubuntu Dapper Build In-Reply-To: <20070608090458.GJ16684@mail.konqueror.de> References: <46691AD9.9010606@gatech.edu> <20070608090458.GJ16684@mail.konqueror.de> Message-ID: <18025.8508.231915.345033@zebedee.pink> Michael Koch writes: > On Fri, Jun 08, 2007 at 05:01:13AM -0400, Matthew Flaschen wrote: > > I tried to build on Ubuntu (really gNewSense) Dapper and got the below > > error: > > > > checking for eclipse-ecj.jar... no > > configure: error: "A ECJ jar was not found." > > > > Can anyone suggest where to find this file (preferably packaged in a > > logical place :) ) > > sudo aptitude install ecj. > > (or on older Ubuntu/Debian ecj-boostrap instead of ecj) > > I'm preparing a meta package which depends on all build dependencies and > adds some links for Debian and Ubuntu. When ready I will announce it > here. Ah, thanks. I knew you would come to the rescue. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From matthew.flaschen at gatech.edu Fri Jun 8 02:31:05 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Fri, 08 Jun 2007 05:31:05 -0400 Subject: Ubuntu Dapper Build In-Reply-To: <18025.8420.239969.762089@zebedee.pink> References: <46691AD9.9010606@gatech.edu> <18025.8420.239969.762089@zebedee.pink> Message-ID: <466921D9.1000601@gatech.edu> Andrew Haley wrote: > Matthew Flaschen writes: > > I tried to build on Ubuntu (really gNewSense) Dapper and got the below > > error: > > > > checking for eclipse-ecj.jar... no > > configure: error: "A ECJ jar was not found." > > > > Can anyone suggest where to find this file (preferably packaged in a > > logical place :) ) > > Try this: > > gij --version java version "1.4.2" gij (GNU libgcj) version 4.1.0 (Ubuntu 4.1.0-1ubuntu8) Matt Flaschen From konqueror at gmx.de Fri Jun 8 02:49:34 2007 From: konqueror at gmx.de (Michael Koch) Date: Fri, 8 Jun 2007 11:49:34 +0200 Subject: Ubuntu Dapper Build In-Reply-To: <466921D9.1000601@gatech.edu> References: <46691AD9.9010606@gatech.edu> <18025.8420.239969.762089@zebedee.pink> <466921D9.1000601@gatech.edu> Message-ID: <20070608094934.GK16684@mail.konqueror.de> On Fri, Jun 08, 2007 at 05:31:05AM -0400, Matthew Flaschen wrote: > Andrew Haley wrote: > > Matthew Flaschen writes: > > > I tried to build on Ubuntu (really gNewSense) Dapper and got the below > > > error: > > > > > > checking for eclipse-ecj.jar... no > > > configure: error: "A ECJ jar was not found." > > > > > > Can anyone suggest where to find this file (preferably packaged in a > > > logical place :) ) > > > > Try this: > > > > gij --version > > java version "1.4.2" > gij (GNU libgcj) version 4.1.0 (Ubuntu 4.1.0-1ubuntu8) Oh, this is dapper. Better try Feisty. Cheers, Michael -- .''`. | Michael Koch : :' : | Free Java Developer `. `' | `- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B From matthew.flaschen at gatech.edu Fri Jun 8 03:05:46 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Fri, 08 Jun 2007 06:05:46 -0400 Subject: Ubuntu Dapper Build In-Reply-To: <20070608094934.GK16684@mail.konqueror.de> References: <46691AD9.9010606@gatech.edu> <18025.8420.239969.762089@zebedee.pink> <466921D9.1000601@gatech.edu> <20070608094934.GK16684@mail.konqueror.de> Message-ID: <466929FA.6080300@gatech.edu> Michael Koch wrote: >>> Try this: >>> >>> gij --version >> java version "1.4.2" >> gij (GNU libgcj) version 4.1.0 (Ubuntu 4.1.0-1ubuntu8) > > Oh, this is dapper. Better try Feisty. Yes, it is Dapper (or deltad)... :) I probably will have to switch to Feisty soon; "That is the sound of inevitability...". It's more and more difficult to build anything on Dapper, and Edgy was a packaging explosion. Matt Flaschen From konqueror at gmx.de Fri Jun 8 03:26:11 2007 From: konqueror at gmx.de (Michael Koch) Date: Fri, 8 Jun 2007 12:26:11 +0200 Subject: Ubuntu Dapper Build In-Reply-To: <466929FA.6080300@gatech.edu> References: <46691AD9.9010606@gatech.edu> <18025.8420.239969.762089@zebedee.pink> <466921D9.1000601@gatech.edu> <20070608094934.GK16684@mail.konqueror.de> <466929FA.6080300@gatech.edu> Message-ID: <20070608102611.GL16684@mail.konqueror.de> On Fri, Jun 08, 2007 at 06:05:46AM -0400, Matthew Flaschen wrote: > Michael Koch wrote: > >>> Try this: > >>> > >>> gij --version > >> java version "1.4.2" > >> gij (GNU libgcj) version 4.1.0 (Ubuntu 4.1.0-1ubuntu8) > > > > Oh, this is dapper. Better try Feisty. > > Yes, it is Dapper (or deltad)... :) I probably will have to switch to > Feisty soon; "That is the sound of inevitability...". It's more and > more difficult to build anything on Dapper, and Edgy was a packaging > explosion. Or as alternative install a chroot with feisty of gutsy and keep your otherwise running system. Michael -- .''`. | Michael Koch : :' : | Free Java Developer `. `' | `- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B From gbenson at redhat.com Fri Jun 8 04:51:28 2007 From: gbenson at redhat.com (Gary Benson) Date: Fri, 8 Jun 2007 12:51:28 +0100 Subject: IcedTea and OS X In-Reply-To: <4668BC7C.4020600@sun.com> References: <1c0e93080706071844m2dbd68d9r433df2b107ba93c6@mail.gmail.com> <4668BC7C.4020600@sun.com> Message-ID: <20070608115128.GD4114@redhat.com> Tom Marble wrote: > Briggs wrote: > > So, I'll ask the silly question... Does iced tea make it > > possible to build the OpenJDK on OS X yet? > > This is a very interesting question. Did you realize that > Mac OS X is, itself, built with the GNU toolchain? > > In theory this shouldn't be too hard, but the trick is that > OpenJDK is missing the operating specific directory (os/macosx) > and the architecture specific directories (os_cpu/macosx_*). The processor-specific directory cpu/ppc or cpu/ppc64 too, for non-x86 Macs. The portable interpreter work I'm doing might help that. Cheers, Gary From langel at redhat.com Fri Jun 8 06:34:34 2007 From: langel at redhat.com (Lillian Angel) Date: Fri, 08 Jun 2007 09:34:34 -0400 Subject: Ubuntu Dapper Build In-Reply-To: <466921D9.1000601@gatech.edu> References: <46691AD9.9010606@gatech.edu> <18025.8420.239969.762089@zebedee.pink> <466921D9.1000601@gatech.edu> Message-ID: <1181309674.3231.0.camel@towel.toronto.redhat.com> On Fri, 2007-06-08 at 05:31 -0400, Matthew Flaschen wrote: > Andrew Haley wrote: > > Matthew Flaschen writes: > > > I tried to build on Ubuntu (really gNewSense) Dapper and got the below > > > error: > > > > > > checking for eclipse-ecj.jar... no > > > configure: error: "A ECJ jar was not found." > > > > > > Can anyone suggest where to find this file (preferably packaged in a > > > logical place :) ) > > > > Try this: > > > > gij --version > > java version "1.4.2" > gij (GNU libgcj) version 4.1.0 (Ubuntu 4.1.0-1ubuntu8) You will need 1.5.0 to build IcedTea. Lillian From fitzsim at redhat.com Fri Jun 8 08:51:42 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 08 Jun 2007 11:51:42 -0400 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <46684DAD.7070701@sun.com> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> <46684DAD.7070701@sun.com> Message-ID: <46697B0E.5000808@redhat.com> Hi, Tom Marble wrote: > I'd like to thank you Andrew as well as Tom Fitzsimmons and the rest of the > Classpath & Friends crew who pulled IcedTea together. (Would someone > please roll the credits???) Unfortunately parts of the release process involved blanking the ChangeLog and creating a new Mercurial repository, so the change history is not evident in the public release. Here's a summary of who did what. Those who contributed code to the initial release are listed in the README in icedtea-1.0.tar.gz: Lillian Angel Tania Bento Thomas Fitzsimmons Kyle Galloway Francis Kung Francis and Kyle created the initial "icedtea-plug-replacements" project, doing the autotooling work and integrating the code from GNU Classpath and generated from the OpenJDK sources. Lillian and Tania wrote stubs for the sound, snmp, javascript and sun.dc packages. Lillian created icedtea-ecj-bootstrap.patch which allowed us to create the initial IcedTea build. I worked on Makefile.am and icedtea-ecj-bootstrap.patch to allow IcedTea to bootstrap itself. I also did code review and helped with the administrative setup of icedtea.classpath.org. We all had a hand in writing the release documentation in README, INSTALL and HACKING. Other people helped with other aspects of the release: Andrew Haley did code review, build testing and wrote the release announcement. Jim Pick generously provided the Xen instance and bandwidth for icedtea.classpath.org. Mark Wielaard did build testing and most of the administrative setup of icedtea.classpath.org. Tom From aph at redhat.com Fri Jun 8 10:50:01 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Jun 2007 18:50:01 +0100 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <4668BBB7.6040200@sun.com> References: <18021.41279.681053.215267@zebedee.pink> <18024.17827.200817.449754@zebedee.pink> <46685683.1070506@sun.com> <46689375.1060208@redhat.com> <4668BBB7.6040200@sun.com> Message-ID: <18025.38601.151026.725844@zebedee.pink> Tom Marble writes: > Francis Kung wrote: > > The version of jar we are using allows us to omit input files to create > > an empty jar, but it looks like this version doesn't. As a work-around, > > I've added a dummy input file to the jar command. > > > > These changes (xalan/xerces locations and empty jars) have been checked > > into the IcedTea mercurial repository. > > For fun I have been trying to use OpenJDK (b13) as the bootstrap > for IcedTea. I just bootstrapped OpenJDK (b13) from my IcedTea (b12). It was a simple matter of applying icedtea/icedtea-copy-plugs.patch to openjdk-7-ea-src-b13-24_may_2007 and then building as usual. Like this: cd /local/openjdk-7-ea-src-b13-24_may_2007 patch -p1 < /local/icedtea/icedtea-copy-plugs.patch ln -s /local/icedtea/bootstrap/jdk1.6.0/ . ln -s /local/icedtea/bootstrap/jdk1.7.0 . export ALT_CLOSED_JDK_IMPORT_PATH=/local/openjdk-7-ea-src-b13-24_may_2007/jdk1.7.0/ export ALT_BOOTDIR=/local/openjdk-7-ea-src-b13-24_may_2007/jdk1.6.0/ cd control/make make Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From mr at sun.com Fri Jun 8 10:50:48 2007 From: mr at sun.com (Mark Reinhold) Date: Fri, 08 Jun 2007 10:50:48 -0700 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: fkung@redhat.com; Thu, 07 Jun 2007 19:23:33 EDT; <46689375.1060208@redhat.com> Message-ID: <20070608175048.8DC836431@callebaut.niobe.net> > Date: Thu, 07 Jun 2007 19:23:33 -0400 > From: Francis Kung > ... > > I didn't realise we were on b13 (was there any public announcement? > announce at openjdk.java.net would be a natural place). I'll look into this. Prior to the big launch a month ago our RE team was sending build-promotion notices to the announce list; not sure why that stopped. BTW: Nice work, folks -- impressive progress in just one month! - Mark From konqueror at gmx.de Sat Jun 9 04:30:36 2007 From: konqueror at gmx.de (Michael Koch) Date: Sat, 9 Jun 2007 13:30:36 +0200 Subject: Ubuntu Dapper Build In-Reply-To: <18025.8508.231915.345033@zebedee.pink> References: <46691AD9.9010606@gatech.edu> <20070608090458.GJ16684@mail.konqueror.de> <18025.8508.231915.345033@zebedee.pink> Message-ID: <20070609113036.GR16684@mail.konqueror.de> On Fri, Jun 08, 2007 at 10:28:28AM +0100, Andrew Haley wrote: > Michael Koch writes: > > On Fri, Jun 08, 2007 at 05:01:13AM -0400, Matthew Flaschen wrote: > > > I tried to build on Ubuntu (really gNewSense) Dapper and got the below > > > error: > > > > > > checking for eclipse-ecj.jar... no > > > configure: error: "A ECJ jar was not found." > > > > > > Can anyone suggest where to find this file (preferably packaged in a > > > logical place :) ) > > > > sudo aptitude install ecj. > > > > (or on older Ubuntu/Debian ecj-boostrap instead of ecj) > > > > I'm preparing a meta package which depends on all build dependencies and > > adds some links for Debian and Ubuntu. When ready I will announce it > > here. > > Ah, thanks. I knew you would come to the rescue. I have uploaded a package called icedtea-builddeps to my personal repo on people.debian.org. You can apt-get it via the following source line: deb http://people.debian.org/~mkoch/java/ ./ This installs all the needed build dependencies and some links for jars that are named differently on Fedora. It works on recent enough Debian and Ubuntu systems. I still cant build icedtea with this. I get the following error: make[6]: Entering directory `/home/mkoch/src/icedtea/icedtea/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' Generating /home/mkoch/src/icedtea/icedtea/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/jvmtifiles/jvmtiEnvRecommended.cpp /home/mkoch/src/icedtea/icedtea/bootstrap/jdk1.6.0/bin/java -Djava.endorsed.dirs=/home/mkoch/src/icedtea/icedtea/bootstrap/jdk1.6.0/lib/endorsed -classpath /home/mkoch/src/icedtea/icedtea/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/jvmtifiles jvmtiGen -IN /home/mkoch/src/icedtea/icedtea/openjdk/hotspot/src/share/vm/prims/jvmti.xml -XSL /home/mkoch/src/icedtea/icedtea/openjdk/hotspot/src/share/vm/prims/jvmtiEnv.xsl -OUT /home/mkoch/src/icedtea/icedtea/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/jvmtifiles/jvmtiEnvStub.cpp Info: jvmtiGen using javax.xml.transform.TransformerFactory = org.apache.xalan.processor.TransformerFactoryImpl Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.xalan.templates.ElemValueOf at java.lang.Class.initializeClass(natClass.cc:720) at java.lang.Class.forName(Class.h:751) at java.lang.Class.forName(natClass.cc:124) at org.apache.xalan.processor.XSLTSchema.build(XSLTSchema.java:381) at org.apache.xalan.processor.XSLTSchema.(XSLTSchema.java:70) at org.apache.xalan.processor.StylesheetHandler.(StylesheetHandler.java:1287) at org.apache.xalan.processor.TransformerFactoryImpl.newTemplatesHandler(TransformerFactoryImpl.java:374) at org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:865) at org.apache.xalan.processor.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:774) at jvmtiGen.main(jvmtiGen.java:144) Caused by: java.lang.NullPointerException at java.lang.Class.initializeClass(natClass.cc:714) ...9 more The class org.apache.xalan.templates.ElemValueOf definitely exists in the same jar as org.apache.xalan.processor.XSLTSchema. I dont what can cause this. Any help is appreciated. Cheers, Michael -- .''`. | Michael Koch : :' : | Free Java Developer `. `' | `- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B From aph at redhat.com Sat Jun 9 06:05:59 2007 From: aph at redhat.com (Andrew Haley) Date: Sat, 9 Jun 2007 14:05:59 +0100 Subject: Ubuntu Dapper Build In-Reply-To: <20070609113036.GR16684@mail.konqueror.de> References: <46691AD9.9010606@gatech.edu> <20070608090458.GJ16684@mail.konqueror.de> <18025.8508.231915.345033@zebedee.pink> <20070609113036.GR16684@mail.konqueror.de> Message-ID: <18026.42424.220.521295@zebedee.pink> Michael Koch writes: > Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.xalan.templates.ElemValueOf > at java.lang.Class.initializeClass(natClass.cc:720) > at java.lang.Class.forName(Class.h:751) > at java.lang.Class.forName(natClass.cc:124) > at org.apache.xalan.processor.XSLTSchema.build(XSLTSchema.java:381) XSLTElementDef xslValueOf = new XSLTElementDef(this, Constants.S_XSLNAMESPACEURL, "value-of", null /*alias */, null /* elements */, new XSLTAttributeDef[]{ selectAttrRequired, disableOutputEscapingAttr }, new ProcessorTemplateElem(), ElemValueOf.class /* class object */, 20, true); > at org.apache.xalan.processor.XSLTSchema.(XSLTSchema.java:70) > at org.apache.xalan.processor.StylesheetHandler.(StylesheetHandler.java:1287) > at org.apache.xalan.processor.TransformerFactoryImpl.newTemplatesHandler(TransformerFactoryImpl.java:374) > at org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:865) > at org.apache.xalan.processor.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:774) > at jvmtiGen.main(jvmtiGen.java:144) > Caused by: java.lang.NullPointerException > at java.lang.Class.initializeClass(natClass.cc:714) > ...9 more > > The class org.apache.xalan.templates.ElemValueOf definitely exists in > the same jar as org.apache.xalan.processor.XSLTSchema. I dont what can > cause this. > > Any help is appreciated. The NullPointerException that occurs here is triggered when initializing org.apache.xalan.processor.XSLTSchema. That class tries to load org.apache.xalan.templates.ElemValueOf, and fails while trying to initialize it. So, I think the class org.apache.xalan.templates.ElemValueOf was loaded, but we fail to initialize it. What version of gcj are you trying to use? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From konqueror at gmx.de Sat Jun 9 06:14:46 2007 From: konqueror at gmx.de (Michael Koch) Date: Sat, 9 Jun 2007 15:14:46 +0200 Subject: Ubuntu Dapper Build In-Reply-To: <18026.42424.220.521295@zebedee.pink> References: <46691AD9.9010606@gatech.edu> <20070608090458.GJ16684@mail.konqueror.de> <18025.8508.231915.345033@zebedee.pink> <20070609113036.GR16684@mail.konqueror.de> <18026.42424.220.521295@zebedee.pink> Message-ID: <20070609131446.GS16684@mail.konqueror.de> On Sat, Jun 09, 2007 at 02:05:59PM +0100, Andrew Haley wrote: > Michael Koch writes: > > > Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.xalan.templates.ElemValueOf > > at java.lang.Class.initializeClass(natClass.cc:720) > > at java.lang.Class.forName(Class.h:751) > > at java.lang.Class.forName(natClass.cc:124) > > at org.apache.xalan.processor.XSLTSchema.build(XSLTSchema.java:381) > > XSLTElementDef xslValueOf = new XSLTElementDef(this, > Constants.S_XSLNAMESPACEURL, "value-of", > null /*alias */, null /* elements */, > new XSLTAttributeDef[]{ selectAttrRequired, > disableOutputEscapingAttr }, > new ProcessorTemplateElem(), > ElemValueOf.class /* class object */, 20, true); > > > at org.apache.xalan.processor.XSLTSchema.(XSLTSchema.java:70) > > at org.apache.xalan.processor.StylesheetHandler.(StylesheetHandler.java:1287) > > at org.apache.xalan.processor.TransformerFactoryImpl.newTemplatesHandler(TransformerFactoryImpl.java:374) > > at org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:865) > > at org.apache.xalan.processor.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:774) > > at jvmtiGen.main(jvmtiGen.java:144) > > Caused by: java.lang.NullPointerException > > at java.lang.Class.initializeClass(natClass.cc:714) > > ...9 more > > > > The class org.apache.xalan.templates.ElemValueOf definitely exists in > > the same jar as org.apache.xalan.processor.XSLTSchema. I dont what can > > cause this. > > > > Any help is appreciated. > > The NullPointerException that occurs here is triggered when > initializing org.apache.xalan.processor.XSLTSchema. That class tries > to load org.apache.xalan.templates.ElemValueOf, and fails while trying > to initialize it. So, I think the class > org.apache.xalan.templates.ElemValueOf was loaded, but we fail to > initialize it. > > What version of gcj are you trying to use? (sid)mkoch at oberon:~$ gcj --version gcj (GCC) 4.1.3 20070518 (prerelease) (Debian 4.1.2-8) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (sid)mkoch at oberon:~$ java --version java version "1.5.0" gij (GNU libgcj) version 4.1.3 20070518 (prerelease) (Debian 4.1.2-8) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (sid)mkoch at oberon:~$ This should be the same as in Fedora 7. Cheers, Michael -- .''`. | Michael Koch : :' : | Free Java Developer `. `' | `- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B From mark at klomp.org Sat Jun 9 09:13:39 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 09 Jun 2007 18:13:39 +0200 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: References: <1181239279.4446.19.camel@dijkstra.wildebeest.org> <200706072332.44687.gnu_andrew@member.fsf.org> Message-ID: <1181405619.4419.18.camel@dijkstra.wildebeest.org> Hi Stuart (CC distro-pkg-dev at openjdk.java.net), On Sat, 2007-06-09 at 11:11 -0400, Stuart Ballard wrote: > I thought it'd be interesting to see how > IcedTea fares japiwise. I suppose that becomes less interesting if the > stuff IcedTea is missing isn't reflected in the API itself, but > still... That would be cool! But we currently don't have the build setup (currently investigating how to get it all going on Debian 3.0/Etch, because people have till now only used Fedora 7 to bootstrap, but almost all our classpath infrastructure machines are Debian based) nor do we really have the capacity to do such a massive build, but maybe we can add it to builder.classpath.org later on. So you will have to do with compiling from source yourself for now. Japi-wise it really is more-or-less fully complete with respect to the public api (but since some things aren't fully connected between the openjdk and classpath parts and some small parts are stubbed, only the non-gui parts really work well). Results would of course still be cool because it would capture api-changes between the official 1.6 and icedtea. Hopefully we can keep using your JDK matrix for that for now http://sab39.netreach.com/Software/Japitools/JDK_Results/46/ The JDK 7 Beta part should be more or less identical to what Icedtea would give. At a certain point I suspect an OpenJDK/Icedtea branch that focuses on getting a full JDK6-like GPL build will emerge and then we definitely want to add that to japi of course. Cheers, Mark From stuart.a.ballard at gmail.com Sat Jun 9 09:29:45 2007 From: stuart.a.ballard at gmail.com (Stuart Ballard) Date: Sat, 9 Jun 2007 12:29:45 -0400 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <1181405619.4419.18.camel@dijkstra.wildebeest.org> References: <1181239279.4446.19.camel@dijkstra.wildebeest.org> <200706072332.44687.gnu_andrew@member.fsf.org> <1181405619.4419.18.camel@dijkstra.wildebeest.org> Message-ID: On 6/9/07, Mark Wielaard wrote: > That would be cool! But we currently don't have the build setup > (currently investigating how to get it all going on Debian 3.0/Etch, > because people have till now only used Fedora 7 to bootstrap, but almost > all our classpath infrastructure machines are Debian based) nor do we > really have the capacity to do such a massive build, but maybe we can > add it to builder.classpath.org later on. So you will have to do with > compiling from source yourself for now. My machine is also Debianish (Ubuntu actually) and definitely doesn't have the resources for massive builds (I actually do the runs on my workstation at work; if something goes wrong and they're still running when I get into the office I definitely feel the effects). So I really can't do something like that right now. Let me know if and when such a builder does get set up, though, and I'll definitely add it to the matrix. Thanks, Stuart. -- http://sab39.netreach.com/ From mark at klomp.org Sun Jun 10 15:36:46 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 11 Jun 2007 00:36:46 +0200 Subject: Sun's OpenJDK in Debian? In-Reply-To: <18027.56607.876757.673715@zebedee.pink> References: <20070609201255.GA32507@pluto.sol.de> <20070609205050.GU16684@mail.konqueror.de> <1181430387.4419.62.camel@dijkstra.wildebeest.org> <18027.56607.876757.673715@zebedee.pink> Message-ID: <1181515007.3651.32.camel@dijkstra.wildebeest.org> (CC openjdk distro-pkg-dev to keep them in the loop about the progress) On Sun, 2007-06-10 at 12:14 +0100, Andrew Haley wrote: > Mark Wielaard writes: > > > Only bootstraps on Fedora 7 for now, but we are making (very) slow > > progress to get things to build fully on Debian also. > > Ofergoodnessake, it's been three whole days! :-) Four already! But... IcedTea is served: openjdk/control/build/linux-i586 $ /home/mjw/icedtea/openjdk/control/build/linux-i586/bin/javac HelloWorld.java $ /home/mjw/icedtea/openjdk/control/build/linux-i586/bin/java HelloWorld Hello World! Greetings Earth! vm: OpenJDK Client VM version: 1.7.0-internal-mjw_10_jun_2007_20_29-b00 vendor: Sun Microsystems Inc. This is a bit faked though. It is on a Debian 3.0/Etch install, which definitely doesn't have the latest gcj, so I build myself a gcc from svn trunk. Michael and I found some small issues in his last icedtea-builddeps that partially explain the problems found in: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-June/000035.html There is a serializer.jar which provides the xalan stuff and some parts of the build seem to unconditionally use gawk. Both issues should be solved by Michael's latest icedtea-builddeps package (available as apt sources line at deb http://people.debian.org/~mkoch/java/ ./). Also on this install ecj wasn't always picking up the bootstrap classpath, so I had to fake that by adding the following to the javac script in icedtea and by creating my own wrapper of ecj (and point --with-ecj at it): libgcjjar=/home/mjw/gcc/install/share/java/libgcj-4.3.0.jar case "$*" in *-bootclasspath*) ;; *) bcoption="-bootclasspath $libgcjjar" esac CLASSPATH=/usr/share/java/ecj.jar${CLASSPATH:+:}$CLASSPATH \ /home/mjw/gcc/install/bin/gij \ org.eclipse.jdt.internal.compiler.batch.Main -1.5 -nowarn \ $bcoption $NEW_ARGS Finally since I was using a x86 xen guest on a x86_64 xen host the build guessed the architecture wrong at one point which I just manually corrected. And since this xen guest doesn't have proper tls support I had to fake out libunpack.so and libwaiters.so which (indirectly) seem to use that. And I didn't yet try to make it bootstrap itself. So lots of tricks to play. But theoretically it is possible :) Cheers, Mark From fitzsim at redhat.com Sun Jun 10 18:10:35 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 10 Jun 2007 21:10:35 -0400 Subject: Patch: Update build for b13 Message-ID: <466CA10B.5010804@redhat.com> Hi, I committed this patch to update the build for openjdk-7-ea-src-b13-24_may_2007.zip. Tested with "make bootstrap" on x86. Tom 2007-06-10 Thomas Fitzsimmons * Makefile.am (OPENJDK_URL): Update for b13 bundle. (OPENJDK_SRC_ZIP): Likewise. (OPENJDK_MD5SUM): Likewise. (ICEDTEA_COPY_DIRS): Add rt/com/sun/tools and rt/com/sun/tools/jdi. (ICEDTEA_COPY_SRC): Add com/sun/tools/jdi/LinkedHashMap.java. * Makefile.in: Regenerate. * .hgignore: Add rt/com/sun/tools/jdi/LinkedHashMap.java. -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-b13-update.patch Type: text/x-patch Size: 2848 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070610/8cc9bda8/icedtea-b13-update.patch From konqueror at gmx.de Mon Jun 11 07:16:55 2007 From: konqueror at gmx.de (Michael Koch) Date: Mon, 11 Jun 2007 16:16:55 +0200 Subject: Icedtea for Ubuntu and Debian Message-ID: <20070611141655.GX16684@mail.konqueror.de> Hello list, I have built a package based on icedtea for Ubuntu and Debian. You can apt-get it from deb http://people.debian.org/~mkoch/java/ ./ Its currently very raw. E.g. it builds with GCJ but has wrong build dependencies for it. And its only buildable for i386 currently. Patches are welcome. Please test and report back. Thanks to all that made this possible. Cheers, Michael -- .''`. | Michael Koch : :' : | Free Java Developer `. `' | `- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B From nkwan at redhat.com Mon Jun 11 18:24:21 2007 From: nkwan at redhat.com (Thomas Kwan) Date: Mon, 11 Jun 2007 18:24:21 -0700 Subject: OpenJDK compiled! Message-ID: <466DF5C5.3040009@redhat.com> Downloaded and compiled successfully for IcedTea. Anyone knows how to turn it into a JPackage compatible JDK?? thanks thomas From mark at klomp.org Tue Jun 12 02:04:16 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 12 Jun 2007 11:04:16 +0200 Subject: bug tracking Message-ID: <1181639057.4417.24.camel@dijkstra.wildebeest.org> Hi, What is a good place to track bugs for distro packages based on openjdk like icedtea? We could setup a bugzilla on icedtea.classpath.org to track package specific bugs. There is also the bugs.sun.com site but that seems really meant for Sun products, not derivatives and community based products like icedtea. It has a big drawback that bugs disappear in it and only can come out when someone "on the inside" makes them public again. Anyway, here are the issues that I know of so far: - libfontmanager.so: undefined symbol: setSunFontIDs Although not all AWT support is enabled in icedtea this error seems to be triggered also by non-awt specific code. Even some SWT apps, that work fine otherwise seem to die because of this. Need to find out which classes/methods trigger this. The native code seems available in scalerMethods.c, but is marked: /* This copy of sunFontIDs doesn't really belong here, * and should move once this code is properly refactored */ - Crypto algorithms/provider missing The crypto framework is in place, but there is no default provider and jre/lib/security/java.security doesn't contain any. We should add the rest of GNU Classpath/Crypto provider to get all mandated algorithms. Simple testcase: javax.crypto.Cipher.getInstance("DES"); - Detection of build dependency jars Debian has the icedtea-buildeps package which creates symlinks for various jar needed by the bootstrap environment. It would be nicer to detect the jars even if they are named differently than on Fedora 7. libgcj-4.1.2.jar -> libgcj-4.1.jar xalan-j2-serializer.jar -> serializer.jar xalan-j2.jar -> xalan2.jar xerces-j2.jar -> xercesImpl.jar - Configure should detect missing openjdk src zip. Currently the build just goes out and tries to download a new copy even if the user might already have the (80MB!) zip around, but in the wrong dir. Cheers, Mark From mr at sun.com Tue Jun 12 08:52:56 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 12 Jun 2007 08:52:56 -0700 Subject: bug tracking In-Reply-To: mark@klomp.org; Tue, 12 Jun 2007 11:04:16 +0200; <1181639057.4417.24.camel@dijkstra.wildebeest.org> Message-ID: <20070612155256.B784E6432@callebaut.niobe.net> > Date: Tue, 12 Jun 2007 11:04:16 +0200 > From: Mark Wielaard > What is a good place to track bugs for distro packages based on openjdk > like icedtea? We could setup a bugzilla on icedtea.classpath.org to > track package specific bugs. There is also the bugs.sun.com site but > that seems really meant for Sun products, not derivatives and community > based products like icedtea. It has a big drawback that bugs disappear > in it and only can come out when someone "on the inside" makes them > public again. A bugzilla on icedtea.classpath.org is probably the best thing for now. We're looking in to fixing the myriad problems with bugs.sun.com, but a full solution is going to take a while. - Mark From fkung at redhat.com Tue Jun 12 11:02:08 2007 From: fkung at redhat.com (Francis Kung) Date: Tue, 12 Jun 2007 14:02:08 -0400 Subject: Mauve test run results In-Reply-To: <1181288479.4418.28.camel@dijkstra.wildebeest.org> References: <1181288479.4418.28.camel@dijkstra.wildebeest.org> Message-ID: <466EDFA0.2080700@redhat.com> Hi, > And I thought the answer would be appropriate for the list especially in > the light of how we are going to make sure icedtea/openjdk derivatives > are "good". Mauve is a nice check that icedtea/openjdk conforms to what > we expect from a GNU Classpath derived runtime, but you would also want > other tests of course to see that it confirms to the quality that people > have come expected of the Sun Java releases. I've also run a more targeted test: I excluded all the graphics-related packages (java.awt.* and javax.swing.*) and ran the openjdk-b13 with binary plugs through the Mauve suite. Then, I took only the tests that passed, and ran those through IcedTea. The stub replacement & gcj bootstrapping process introduced only 12 test failures: OpenJDK: TEST RESULTS: 216 of 1022 tests failed. 2796 total calls to harness.check() failed. IcedTea: TEST RESULTS: 12 of 803 tests failed. 1 total calls to harness.check() failed. The failures were: FAIL: java.io.File.jdk11 line 297: lastModified () [1] -- boolean passed to check was false FAIL: java.beans.SimpleBeanInfo.loadImage symbol lookup failure: libfontmanager.so: undefined symbol: setSunFontIDs FAIL: java.lang.management.ClassLoadingMXBeanTest line 67: [1] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.lang.management.OperatingSystemMXBeanTest line 91: [1] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.lang.management.RuntimeMXBeanTest line 190: [1] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.lang.Class.security line 146: setup [2] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.lang.ClassLoader.security line 119: setup [2] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.lang.Integer.getInteger line 108: [19] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.lang.Thread.insecurity line 230: setup [3] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.lang.reflect.AccessibleObject.security line 130: method [3] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.net.DatagramPacket.DatagramPacketTest line 78: Error : test_Basics failed - 6 The getData should return actual bytes to be sent/received [2] -- uncaught exception: java.lang.NoClassDefFoundError: Could not initialize class sun.net.InetAddressCachePolicy FAIL: java.net.DatagramPacket.DatagramPacketTest2 Test timed out. Use -timeout [millis] option to change the timeout value. I have the full logs of both runs, including exceptions & stacktraces, if anyone is interested. Cheers, Francis From Andreas.Sterbenz at Sun.COM Tue Jun 12 11:19:10 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Tue, 12 Jun 2007 11:19:10 -0700 Subject: bug tracking In-Reply-To: <1181639057.4417.24.camel@dijkstra.wildebeest.org> References: <1181639057.4417.24.camel@dijkstra.wildebeest.org> Message-ID: <466EE39E.6000308@sun.com> Mark Wielaard wrote: > > - Crypto algorithms/provider missing > The crypto framework is in place, but there is no default provider and > jre/lib/security/java.security doesn't contain any. We should add the > rest of GNU Classpath/Crypto provider to get all mandated algorithms. > Simple testcase: javax.crypto.Cipher.getInstance("DES"); FYI, we are in the process of making the JCE framework and all the Sun crypto providers available as part of the regular OpenJDK source base. I don't have an ETA, but hopefully this will not take a too long. Andreas. From fitzsim at redhat.com Wed Jun 13 06:44:35 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 13 Jun 2007 09:44:35 -0400 Subject: OpenJDK compiled! In-Reply-To: <466DF5C5.3040009@redhat.com> References: <466DF5C5.3040009@redhat.com> Message-ID: <466FF4C3.3040404@redhat.com> Thomas Kwan wrote: > Downloaded and compiled successfully for IcedTea. > Anyone knows how to turn it into a JPackage compatible > JDK?? Yes, I'll have something ready today. It's going to be a Fedora-tested .nosrc.rpm that includes icedtea-1.0.tar.gz but excludes the OpenJDK source bundle. We still need to get clarification from Sun on some questionable license headers (see the IcedTea README) before we can host the OpenJDK sources, even bundled in a .src.rpm. Once the license headers are fixed/clarified I'll submit java-1.7.0-icedtea to Fedora. Tom From aph at redhat.com Wed Jun 13 07:02:25 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2007 15:02:25 +0100 Subject: OpenJDK compiled! In-Reply-To: <466FF4C3.3040404@redhat.com> References: <466DF5C5.3040009@redhat.com> <466FF4C3.3040404@redhat.com> Message-ID: <18031.63729.372708.860304@zebedee.pink> Thomas Fitzsimmons writes: > Thomas Kwan wrote: > > Downloaded and compiled successfully for IcedTea. > > Anyone knows how to turn it into a JPackage compatible > > JDK?? > > Yes, I'll have something ready today. It's going to be a Fedora-tested > .nosrc.rpm that includes icedtea-1.0.tar.gz but excludes the OpenJDK source > bundle. Excellent. Will this be jpackage-compatible, so we can select it as an alternative? Thanks, Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From fitzsim at redhat.com Wed Jun 13 07:08:51 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 13 Jun 2007 10:08:51 -0400 Subject: OpenJDK compiled! In-Reply-To: <18031.63729.372708.860304@zebedee.pink> References: <466DF5C5.3040009@redhat.com> <466FF4C3.3040404@redhat.com> <18031.63729.372708.860304@zebedee.pink> Message-ID: <466FFA73.6060103@redhat.com> Andrew Haley wrote: > Thomas Fitzsimmons writes: > > Thomas Kwan wrote: > > > Downloaded and compiled successfully for IcedTea. > > > Anyone knows how to turn it into a JPackage compatible > > > JDK?? > > > > Yes, I'll have something ready today. It's going to be a Fedora-tested > > .nosrc.rpm that includes icedtea-1.0.tar.gz but excludes the OpenJDK source > > bundle. > > Excellent. Will this be jpackage-compatible, so we can select it as > an alternative? Yes. Tom From David.Herron at Sun.COM Wed Jun 13 09:07:25 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 13 Jun 2007 09:07:25 -0700 Subject: Icedtea on OS X Message-ID: <4670163D.6030201@sun.com> Marius, also known as de_co_der, posted a comment on my java.net blog saying he's looking at iced tea for OS X. He's keeping a "log" here: http://de-co-de.blogspot.com/ - David Herron From David.Herron at Sun.COM Wed Jun 13 09:21:47 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 13 Jun 2007 09:21:47 -0700 Subject: Mauve test run results In-Reply-To: <466EDFA0.2080700@redhat.com> References: <1181288479.4418.28.camel@dijkstra.wildebeest.org> <466EDFA0.2080700@redhat.com> Message-ID: <4670199B.3050803@sun.com> Francis Kung wrote: > I've also run a more targeted test: I excluded all the > graphics-related packages (java.awt.* and javax.swing.*) and ran the > openjdk-b13 with binary plugs through the Mauve suite. Then, I took > only the tests that passed, and ran those through IcedTea. The stub > replacement & gcj bootstrapping process introduced only 12 test failures: If I read this right ... you skipped over reporting hundreds or maybe thousands of test failures by dropping the graphics related tests, yes? - David Herron From kgallowa at redhat.com Wed Jun 13 09:47:17 2007 From: kgallowa at redhat.com (Kyle Galloway) Date: Wed, 13 Jun 2007 12:47:17 -0400 Subject: IcedTea built on Gentoo Message-ID: <46701F95.9060305@redhat.com> I have now successfully built IcedTea using ecj on Gentoo. Included in this e-mail are instructions on how to do it for all those Gentoo users out there who want to hack on IcedTea. This was done on Gentoo 2007.0 ~x86 1. Required Packages emerge -av xalan xalan-serializer xerces cups lesstif eclipse-ecj Some of those are probably already installed, but -av will tell you and let you confirm whether you want to rebuild any of those. 2. Build a 1.5 compliant libgcj (substitute the stuff in <> with directories of your choice). svn co svn://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_1-branch gcc mkdir gcc-build cd gcc-build ../gcc/configure --prefix= --exec-prefix=/ make && make install 3. Modify icedtea/javac.in. In order to get IcedTea to build with your built libgcj you will need to modify the attached patch to point to your libgcj-4.1.3.jar, then apply it to javac.in. vim javac_in.patch cd icedtea patch -p0 < javac_in.patch 4. Configure and build IcedTea ./configure --with-ecj=/usr/bin/ecj-3.2 --with-ecj-jar=/usr/share/eclipse-ecj-3.2/lib/ecj.jar --with-libgcj-jar=/share/java/libgcj-4.1.3.jar --with-xalan2-jar=/usr/share/xalan/lib/xalan.jar --with-xalan2-serializer-jar=/usr/share/xalan-serializer/lib/serializer.jar --with-xerces2-jar=/usr/share/xerces-2/lib/xercesImpl.jar make And there you have it. Kyle -------------- next part -------------- A non-text attachment was scrubbed... Name: javac_in.patch Type: text/x-patch Size: 620 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070613/dc965a8b/javac_in.patch From fkung at redhat.com Wed Jun 13 10:18:28 2007 From: fkung at redhat.com (Francis Kung) Date: Wed, 13 Jun 2007 13:18:28 -0400 Subject: Mauve test run results In-Reply-To: <4670199B.3050803@sun.com> References: <1181288479.4418.28.camel@dijkstra.wildebeest.org> <466EDFA0.2080700@redhat.com> <4670199B.3050803@sun.com> Message-ID: <467026E4.7060709@redhat.com> >> I've also run a more targeted test: I excluded all the >> graphics-related packages (java.awt.* and javax.swing.*) and ran the >> openjdk-b13 with binary plugs through the Mauve suite. Then, I took >> only the tests that passed, and ran those through IcedTea. The stub >> replacement & gcj bootstrapping process introduced only 12 test failures: > If I read this right ... you skipped over reporting hundreds or maybe > thousands of test failures by dropping the graphics related tests, yes? Yes - graphics are known to not work, and leaving those tests in prevented a full Mauve run (the vm throws an exception saying "too many open files" - not sure if this is an IcedTea bug or Mauve bug). Mauve is by no means a complete testsuite, so numbers from it are only a very rough indication. I was mostly interested in finding OpenJDK->IcedTea regressions in areas that were not stubbed (ie not in crypto/graphics/sound/snmp, as we know none of those work). Cheers, Francis From mark at klomp.org Wed Jun 13 15:59:47 2007 From: mark at klomp.org (Mark Wielaard) Date: Thu, 14 Jun 2007 00:59:47 +0200 Subject: bug tracking In-Reply-To: <20070612155256.B784E6432@callebaut.niobe.net> References: <20070612155256.B784E6432@callebaut.niobe.net> Message-ID: <1181775587.4579.29.camel@dijkstra.wildebeest.org> On Tue, 2007-06-12 at 08:52 -0700, Mark Reinhold wrote: > > What is a good place to track bugs for distro packages based on openjdk > > like icedtea? We could setup a bugzilla on icedtea.classpath.org to > > track package specific bugs. There is also the bugs.sun.com site but > > that seems really meant for Sun products, not derivatives and community > > based products like icedtea. It has a big drawback that bugs disappear > > in it and only can come out when someone "on the inside" makes them > > public again. > > A bugzilla on icedtea.classpath.org is probably the best thing for now. OK, there is http://icedtea.classpath.org/bugzilla now. We will try to keep it just for bugs caused by packaging, the different build setup and replacement classes. And move everything else to the openjdk bug database (or classpath bugzilla if it is caused by a classpath replacement class). > We're looking in to fixing the myriad problems with bugs.sun.com, but a > full solution is going to take a while. The OpenSolaris people pointed me to their DTS requirements http://mail.opensolaris.org/pipermail/tools-discuss/2007-June/004003.html That does indeed seem a pretty big list. But if they can solve that then we can probably just adopt whatever they do. Worked great for the DSCM choice :) Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070614/ce0d40fc/attachment.bin From fitzsim at redhat.com Wed Jun 13 16:03:50 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 13 Jun 2007 19:03:50 -0400 Subject: Fedora IcedTea packages Message-ID: <467077D6.3040007@redhat.com> Hi, I uploaded a .nosrc.rpm that can be used to build IcedTea packages on Fedora 7: http://icedtea.classpath.org/download/fedora/java-1.7.0-icedtea-1.7.0.0-0.2.b12.nosrc.rpm Build instructions: sudo yum -y install alsa-lib-devel cups-devel lesstif-devel libX11-devel libXi-devel libXp-devel libXt-devel libXtst-devel xalan-j2 xerces-j2 xorg-x11-proto-devel java-1.5.0-gcj-devel mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} echo %_topdir ~/rpmbuild > ~/.rpmmacros rpm -Uvh http://icedtea.classpath.org/download/fedora/java-1.7.0-icedtea-1.7.0.0-0.2.b12.nosrc.rpm wget -P ~/rpmbuild/SOURCES http://www.java.net/download/openjdk/40ec4ed263a6dfce13b8cf18fa046058/jdk7/promoted/b12/openjdk-7-ea-src-b12-06_may_2007.zip rpmbuild --target i586 -ba ~/rpmbuild/SPECS/java-1.7.0-icedtea.spec Omit "--target i586" on x86_64: rpmbuild -ba ~/rpmbuild/SPECS/java-1.7.0-icedtea.spec The binary packages are written to ~/rpmbuild/RPMS/i586 or ~/rpmbuild/RPMS/x86_64. To install them: sudo rpm -Uvh ~/rpmbuild/RPMS/i586/java-1.7.0-icedtea{,-debuginfo,-demo,-devel,-src}-1.7.0.0-0.2.b12.fc7.i586.rpm or rpm -Uvh ~/rpmbuild/RPMS/x86_64/java-1.7.0-icedtea{,-debuginfo,-demo,-devel,-src}-1.7.0.0-0.2.b12.fc7.x86_64.rpm I'll be submitting a similar .src.rpm to the Fedora project once our licensing questions are cleared up. Tom From aph at redhat.com Thu Jun 14 01:57:43 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2007 09:57:43 +0100 Subject: bug tracking In-Reply-To: <1181775587.4579.29.camel@dijkstra.wildebeest.org> References: <20070612155256.B784E6432@callebaut.niobe.net> <1181775587.4579.29.camel@dijkstra.wildebeest.org> Message-ID: <18033.775.289090.512301@zebedee.pink> Mark Wielaard writes: > On Tue, 2007-06-12 at 08:52 -0700, Mark Reinhold wrote: > > > What is a good place to track bugs for distro packages based on openjdk > > > like icedtea? We could setup a bugzilla on icedtea.classpath.org to > > > track package specific bugs. There is also the bugs.sun.com site but > > > that seems really meant for Sun products, not derivatives and community > > > based products like icedtea. It has a big drawback that bugs disappear > > > in it and only can come out when someone "on the inside" makes them > > > public again. > > > > A bugzilla on icedtea.classpath.org is probably the best thing for now. > > OK, there is http://icedtea.classpath.org/bugzilla now. > We will try to keep it just for bugs caused by packaging, the different > build setup and replacement classes. And move everything else to the > openjdk bug database (or classpath bugzilla if it is caused by a > classpath replacement class). I'm not convinced of the wisdom of that. Anyone reporting a bug with IcedTea that is not present in OpenJDK should be able to enter it in IcedTea's Bugzilla: after all, how are they to know whether a bug is caused by bad packaging or bad Classpath code? There's no reason not to link IcedTea bugs to Classpath bugs if needs be. Also, from a practical point of view, I'd like to keep all IcedTea bugs together in one place. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From mark at klomp.org Thu Jun 14 04:44:12 2007 From: mark at klomp.org (Mark Wielaard) Date: Thu, 14 Jun 2007 13:44:12 +0200 Subject: bug tracking In-Reply-To: <18033.775.289090.512301@zebedee.pink> References: <20070612155256.B784E6432@callebaut.niobe.net> <1181775587.4579.29.camel@dijkstra.wildebeest.org> <18033.775.289090.512301@zebedee.pink> Message-ID: <1181821453.4474.46.camel@dijkstra.wildebeest.org> On Thu, 2007-06-14 at 09:57 +0100, Andrew Haley wrote: > Mark Wielaard writes: > > On Tue, 2007-06-12 at 08:52 -0700, Mark Reinhold wrote: > > > A bugzilla on icedtea.classpath.org is probably the best thing for now. > > > > OK, there is http://icedtea.classpath.org/bugzilla now. > > We will try to keep it just for bugs caused by packaging, the different > > build setup and replacement classes. And move everything else to the > > openjdk bug database (or classpath bugzilla if it is caused by a > > classpath replacement class). > > I'm not convinced of the wisdom of that. Anyone reporting a bug with > IcedTea that is not present in OpenJDK should be able to enter it in > IcedTea's Bugzilla: after all, how are they to know whether a bug is > caused by bad packaging or bad Classpath code? There's no reason not > to link IcedTea bugs to Classpath bugs if needs be. Also, from a > practical point of view, I'd like to keep all IcedTea bugs together in > one place. Fair points. But it would be bad not to push any bugs towards the openjdk/classpath bug databases, because they obviously also would like to have a full overview of all known issues. I admit that I don't have a good plan for this yet. We are currently running bugzilla 2.22.1-debian2, but it seems bugzilla 3.0 does provide some more support for this through a Bugzilla::Webservice XML-RPC Interface. Maybe we could switch to that in the future to automagically push/pull bugs between projects. For now I am seeing http://icedtea.classpath.org/bugzilla a bit as a "build one to throw one away" project that we can use to see what an ideal bug tracking solution would be for all the projects involved in the long term. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070614/10ebb878/attachment.bin From aph at redhat.com Thu Jun 14 04:56:04 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2007 12:56:04 +0100 Subject: bug tracking In-Reply-To: <1181821453.4474.46.camel@dijkstra.wildebeest.org> References: <20070612155256.B784E6432@callebaut.niobe.net> <1181775587.4579.29.camel@dijkstra.wildebeest.org> <18033.775.289090.512301@zebedee.pink> <1181821453.4474.46.camel@dijkstra.wildebeest.org> Message-ID: <18033.11476.39684.193592@zebedee.pink> Mark Wielaard writes: > On Thu, 2007-06-14 at 09:57 +0100, Andrew Haley wrote: > > Mark Wielaard writes: > > > On Tue, 2007-06-12 at 08:52 -0700, Mark Reinhold wrote: > > > > A bugzilla on icedtea.classpath.org is probably the best thing for now. > > > > > > OK, there is http://icedtea.classpath.org/bugzilla now. > > > We will try to keep it just for bugs caused by packaging, the different > > > build setup and replacement classes. And move everything else to the > > > openjdk bug database (or classpath bugzilla if it is caused by a > > > classpath replacement class). > > > > I'm not convinced of the wisdom of that. Anyone reporting a bug with > > IcedTea that is not present in OpenJDK should be able to enter it in > > IcedTea's Bugzilla: after all, how are they to know whether a bug is > > caused by bad packaging or bad Classpath code? There's no reason not > > to link IcedTea bugs to Classpath bugs if needs be. Also, from a > > practical point of view, I'd like to keep all IcedTea bugs together in > > one place. > > Fair points. But it would be bad not to push any bugs towards the > openjdk/classpath bug databases, because they obviously also would > like to have a full overview of all known issues. I have no problem with that, of course. We can do that in a high-tech way or a low-tech way. The low-tech way is simply to insert a URL that points to the Classpath / OpenJDK bug. That would be OK, wouldn't it? > For now I am seeing http://icedtea.classpath.org/bugzilla a bit as a > "build one to throw one away" project that we can use to see what an > ideal bug tracking solution would be for all the projects involved in > the long term. That makes sense. I hope that we'll be able to use the IcedTea bugzilla as a way to ensure that people working on IcedTea don't waste time on duplicated effort. So, if every IcedTea "to do" item has an associated Bugzilla entry, the person working to fix it claims the bug. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From mark at klomp.org Thu Jun 14 05:06:14 2007 From: mark at klomp.org (Mark Wielaard) Date: Thu, 14 Jun 2007 14:06:14 +0200 Subject: bug tracking In-Reply-To: <18033.11476.39684.193592@zebedee.pink> References: <20070612155256.B784E6432@callebaut.niobe.net> <1181775587.4579.29.camel@dijkstra.wildebeest.org> <18033.775.289090.512301@zebedee.pink> <1181821453.4474.46.camel@dijkstra.wildebeest.org> <18033.11476.39684.193592@zebedee.pink> Message-ID: <1181822774.4474.54.camel@dijkstra.wildebeest.org> On Thu, 2007-06-14 at 12:56 +0100, Andrew Haley wrote: > > Fair points. But it would be bad not to push any bugs towards the > > openjdk/classpath bug databases, because they obviously also would > > like to have a full overview of all known issues. > > I have no problem with that, of course. We can do that in a high-tech > way or a low-tech way. The low-tech way is simply to insert a URL > that points to the Classpath / OpenJDK bug. That would be OK, > wouldn't it? Yes, that would work for a start. Every bug has an URL field now (just above the Summary), which is currently empty for all bugs. > > For now I am seeing http://icedtea.classpath.org/bugzilla a bit as a > > "build one to throw one away" project that we can use to see what an > > ideal bug tracking solution would be for all the projects involved in > > the long term. > > That makes sense. I hope that we'll be able to use the IcedTea > bugzilla as a way to ensure that people working on IcedTea don't waste > time on duplicated effort. So, if every IcedTea "to do" item has an > associated Bugzilla entry, the person working to fix it claims the > bug. Feel free to create an account and claim any bug! Anything assigned to bugzilla-at-icedtea.classpath.org (that is every bug in the database now) is up for grabs! :) Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070614/766bc72a/attachment.bin From matthew.flaschen at gatech.edu Thu Jun 14 08:46:19 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Thu, 14 Jun 2007 11:46:19 -0400 Subject: bug tracking In-Reply-To: <18033.775.289090.512301@zebedee.pink> References: <20070612155256.B784E6432@callebaut.niobe.net> <1181775587.4579.29.camel@dijkstra.wildebeest.org> <18033.775.289090.512301@zebedee.pink> Message-ID: <467162CB.7000404@gatech.edu> Andrew Haley wrote: > I'm not convinced of the wisdom of that. Anyone reporting a bug with > IcedTea that is not present in OpenJDK should be able to enter it in > IcedTea's Bugzilla: after all, how are they to know whether a bug is > caused by bad packaging or bad Classpath code? Same way they know it's not in OpenJDK. Try it in Classpath. > There's no reason not > to link IcedTea bugs to Classpath bugs if needs be. Also, from a > practical point of view, I'd like to keep all IcedTea bugs together in > one place. But if it's a Classpath bug, it's not really an IcedTea bug. Obviously, people won't be perfect at segregating the bugs (hence the URL makes sense), but there's a logical distinction in theory. Just my thoughts. Matt Flaschen From kgallowa at redhat.com Thu Jun 14 12:02:47 2007 From: kgallowa at redhat.com (Kyle Galloway) Date: Thu, 14 Jun 2007 15:02:47 -0400 Subject: REVISED: IcedTea built on Gentoo In-Reply-To: <46701F95.9060305@redhat.com> References: <46701F95.9060305@redhat.com> Message-ID: <467190D7.6050300@redhat.com> I have just committed a change to IcedTea that will simplify this process. Though this procedure was done on a Gentoo system, it can be easily adapted to just about any Linux distro by changing the paths supplied to configure appropriately. I have also got some input from the Gentoo Java team about using the GCJ overlay. I have included it below as an alternative for anyone who wants to use that approach, is running Gentoo, and is comfortable using portage overlays. > This was done on Gentoo 2007.0 ~x86 > > 1. Required Packages > > emerge -av xalan xalan-serializer xerces cups lesstif eclipse-ecj > > Some of those are probably already installed, but -av will tell you and > let you confirm whether you want to rebuild any of those. > > 2. Build a 1.5 compliant libgcj (substitute the stuff in <> with > directories of your choice). > > svn co svn://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_1-branch gcc > mkdir gcc-build > cd gcc-build > ../gcc/configure --prefix= --exec-prefix= dir>/ > make && make install > OR if you are running Gentoo. Use the Gentoo GCJ overlay, see instructions: http://overlays.gentoo.org/proj/java/wiki/GCJ_as_a_JDK Now that javac.in has been patched, it is no longer necessary to use the patch I sent, or modify the source tree in any way. Simply: > 3. Configure and build IcedTea > > ./configure --with-ecj=/usr/bin/ecj-3.2 > --with-ecj-jar=/usr/share/eclipse-ecj-3.2/lib/ecj.jar > --with-libgcj-jar=/share/java/libgcj-4.1.3.jar > --with-xalan2-jar=/usr/share/xalan/lib/xalan.jar > --with-xalan2-serializer-jar=/usr/share/xalan-serializer/lib/serializer.jar > --with-xerces2-jar=/usr/share/xerces-2/lib/xercesImpl.jar > make And there you have it. - Kyle From gnu_andrew at member.fsf.org Fri Jun 15 13:21:29 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 Jun 2007 21:21:29 +0100 Subject: IcePick Message-ID: <200706152121.35386.gnu_andrew@member.fsf.org> Hi everyone, Since the release of the OpenJDK sources, I've been kind of looking at things in a different way to most people (as is my want). Knowing I couldn't build a Free JDK immediately (or even the sources Freely until recently), I tried just building what I thought would be most immediately useful -- the tools. Although we have some from Classpath, we don't always have them API-wise (e.g. executing com.sun.tools.javah.Main rather than a 'javah' binary), some of them aren't in the best position to be replacements at the moment (gjdoc unfortunately) and some are just plain missing (apt is the one I ran into in trying to build JikesRVM). To cut a long story short, I've succeeded in cobbling together a small autoconf build system that will pluck through the OpenJDK sources and build them (just javac, javadoc, javah and apt so far, as a proof of concept -- but more should be easy enough to add now the main work's done). It creates a tools.jar and scripts to run them (just like those in Classpath). I was wondering if it would be worth me cleaning this up a little (adding niceties like a README, etc.) and hosting it with the rest of the IcedTea stuff. Let me know what you think, Cheers, -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070615/faf31723/attachment.bin From yuhongbao_386 at hotmail.com Fri Jun 15 15:44:35 2007 From: yuhongbao_386 at hotmail.com (Yuhong Bao) Date: Fri, 15 Jun 2007 15:44:35 -0700 Subject: Is bootstripping with gcj and classpath really nesserary? Message-ID: Can't you just use a binary of OpenJDK to bootstrip it? Yuhong Bao _________________________________________________________________ Windows Live Hotmail, with safety bar colour coding, helps identify suspicious mail before it takes your daughter out on a date. Upgrade today for a better look. www.newhotmail.ca?icid=WLHMENCA152 From matthew.flaschen at gatech.edu Sat Jun 16 05:09:23 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Sat, 16 Jun 2007 08:09:23 -0400 Subject: Is bootstripping with gcj and classpath really nesserary? In-Reply-To: References: Message-ID: <4673D2F3.1030103@gatech.edu> Yuhong Bao wrote: > Can't you just use a binary of OpenJDK to bootstrip it? It's bootstrapping, and building on OpenJDK would make IcedTea unfree (because OpenJDK has binary plugs), which defeats the point. Matt Flaschen From mark at klomp.org Sat Jun 16 10:46:27 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 16 Jun 2007 19:46:27 +0200 Subject: IcePick In-Reply-To: <200706152121.35386.gnu_andrew@member.fsf.org> References: <200706152121.35386.gnu_andrew@member.fsf.org> Message-ID: <1182015988.4514.9.camel@dijkstra.wildebeest.org> Hi Andrew, On Fri, 2007-06-15 at 21:21 +0100, Andrew John Hughes wrote: > To cut a long story short, I've succeeded in cobbling together a small > autoconf build system that will pluck through the OpenJDK sources and build > them (just javac, javadoc, javah and apt so far, as a proof of concept -- but > more should be easy enough to add now the main work's done). It creates a > tools.jar and scripts to run them (just like those in Classpath). I was > wondering if it would be worth me cleaning this up a little (adding niceties > like a README, etc.) and hosting it with the rest of the IcedTea stuff. Nice. This sounds very useful. How "portable" is the result? Is it completely self-contained or do the tools depend on some of the internal openjdk library implementations (can I use them with gcj for example)? I think it would be a nice addition to the icedtea build system if you can make it easy to integrate. IcedTea is already kind of a build harness for openjdk, if there is an option to easily build just the tools with it that would be helpful imho, if only for those people who just want to hack on and build the tools. Or maybe the openjdk tools-group (is there such a thing?) would be interested. Although I believe Dalibor already had a plan of autoconfiscating javac and the team said they already had enough different build options. Alternatively if nobody want to integrate your patches we can always create a new repo (icepick) for you to make it easy to publish your stuff and have a development repository. Any patches or source available? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070616/8f91fa76/attachment.bin From mark at klomp.org Sat Jun 16 10:58:58 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 16 Jun 2007 19:58:58 +0200 Subject: Is bootstripping with gcj and classpath really nesserary? In-Reply-To: References: Message-ID: <1182016739.4514.22.camel@dijkstra.wildebeest.org> Hi, On Fri, 2007-06-15 at 15:44 -0700, Yuhong Bao wrote: > Can't you just use a binary of OpenJDK to bootstrip it? I don't believe anybody distributes binaries of OpenJDK yet. Although Michael has some preliminary Debian packages for x86 only see http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-June/000042.html You can build one yourself following the build instructions from the build group http://openjdk.java.net/groups/build/ but you will need some binary blobs and an existing proprietary JDK around. Or you can use the IcedTea build harness from http://icedtea.classpath.org/ that bootstraps openjdk using only Free Software. Icedtea lets you do a make bootstrap that will (after creating the initial binary using gcj with free plugs created from GNU Classpath) use openjdk/icedtea itself to build itself. So in theory after you have your initial binary you can then use that to bootstrap itself. And you then don't need the proprietary JDK binary or gcj anymore (although you would still need either the proprietary binary blobs or the free plugs provided by IcedTea/Classpath). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070616/c5d7fafe/attachment.bin From mark at klomp.org Sat Jun 16 11:06:58 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 16 Jun 2007 20:06:58 +0200 Subject: Is bootstripping with gcj and classpath really nesserary? In-Reply-To: <4673D2F3.1030103@gatech.edu> References: <4673D2F3.1030103@gatech.edu> Message-ID: <1182017219.4514.30.camel@dijkstra.wildebeest.org> On Sat, 2007-06-16 at 08:09 -0400, Matthew Flaschen wrote: > Yuhong Bao wrote: > > Can't you just use a binary of OpenJDK to bootstrip it? > > It's bootstrapping, and building on OpenJDK would make IcedTea unfree > (because OpenJDK has binary plugs), which defeats the point. To be a little pedantic there are two things here. The build environment and the plugs. IcedTea provides both. The build environment of the free plugs in IcedTea is a little interwoven with the build harness for building OpenJDK using these free plugs, but doesn't necessary have to be. One could use a proprietary build environment, but using the free plugs from IcedTea and build with that to create a fully free OpenJDK (the result can bootstrap itself). Of course bootstrapping while starting with completely free tools and plugs at the same time makes sure that no proprietary bits can ever (accidentally) leak into the resulting openjdk based toolchain which is a nice benefit for the paranoia (and a nice existence proof that no such "leaking" happens). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070616/684bf132/attachment.bin From matthew.flaschen at gatech.edu Sat Jun 16 14:38:11 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Sat, 16 Jun 2007 17:38:11 -0400 Subject: Is bootstripping with gcj and classpath really nesserary? In-Reply-To: <1182017219.4514.30.camel@dijkstra.wildebeest.org> References: <4673D2F3.1030103@gatech.edu> <1182017219.4514.30.camel@dijkstra.wildebeest.org> Message-ID: <46745843.1060405@gatech.edu> Mark Wielaard wrote: > On Sat, 2007-06-16 at 08:09 -0400, Matthew Flaschen wrote: >> Yuhong Bao wrote: >>> Can't you just use a binary of OpenJDK to bootstrip it? >> It's bootstrapping, and building on OpenJDK would make IcedTea unfree >> (because OpenJDK has binary plugs), which defeats the point. > > To be a little pedantic there are two things here. The build environment > and the plugs. IcedTea provides both. What do you mean, exactly? My understanding is that the IcedTea build environment is a combination of ecj, gcj, and classpath, and that the binary plugs are replaced with Classpath classes or just removed entirely. > One could use a proprietary build environment, but using the free > plugs from IcedTea and build with that to create a fully free OpenJDK > (the result can bootstrap itself). Yes, I think that's right. The main reason for a fully free build environment is so everything can be replicated without using proprietary software. > Of course bootstrapping while starting with completely free tools and > plugs at the same time makes sure that no proprietary bits can ever > (accidentally) leak into the resulting openjdk based toolchain which is > a nice benefit for the paranoia (and a nice existence proof that no such > "leaking" happens). That too. Matt Flaschen From mark at klomp.org Sat Jun 16 15:24:46 2007 From: mark at klomp.org (Mark Wielaard) Date: Sun, 17 Jun 2007 00:24:46 +0200 Subject: Is bootstripping with gcj and classpath really nesserary? In-Reply-To: <46745843.1060405@gatech.edu> References: <4673D2F3.1030103@gatech.edu> <1182017219.4514.30.camel@dijkstra.wildebeest.org> <46745843.1060405@gatech.edu> Message-ID: <1182032687.8032.6.camel@dijkstra.wildebeest.org> On Sat, 2007-06-16 at 17:38 -0400, Matthew Flaschen wrote: > Mark Wielaard wrote: > > On Sat, 2007-06-16 at 08:09 -0400, Matthew Flaschen wrote: > >> Yuhong Bao wrote: > >>> Can't you just use a binary of OpenJDK to bootstrip it? > >> It's bootstrapping, and building on OpenJDK would make IcedTea unfree > >> (because OpenJDK has binary plugs), which defeats the point. > > > > To be a little pedantic there are two things here. The build environment > > and the plugs. IcedTea provides both. > > What do you mean, exactly? My understanding is that the IcedTea build > environment is a combination of ecj, gcj, and classpath, and that the > binary plugs are replaced with Classpath classes or just removed entirely. Yes, that was what I meant. And that theoretically the build is a two staged process. "make plugs", which gives you free replacements (and some stubs) for the binary blobs under "icedtea/bootstrap/jdk1.7.0/" and then "make boot" which provides a free build environment under "icedtea/bootstrap/jdk1.6.0/" (these directory names might be slightly confusing, but were chosen because they match the plugs and build directory setup of plain openjdk). Either step could be replaced with some other environment, but the first step is essential for getting a completely free software solution, the second step could pedantically be replaced with a solution not based on gcj/classpath, but pragmatically it is super useful since almost all GNU/Linux distros are currently based on gcj/classpath and it is a nice point for porting openjdk since gcj is available on so many platforms already. Just to complete the picture. If you do a "make bootstrap" in icedtea then first the above steps are taken resulting in a full free workable icedtea/openjdk/control/build/linux-$(BUILD_ARCH_DIR)/j2sdk-image, and then this image is copied to the build environment under "icedtea/bootstrap/jdk1.6.0/" with which then a new clean build is made (so using the free plug replacements, but using the just build java and javac, and not gcj and ecj for compiling the new image itself). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070617/8178f925/attachment.bin From gnu_andrew at member.fsf.org Sat Jun 16 16:28:00 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 17 Jun 2007 00:28:00 +0100 Subject: IcePick In-Reply-To: <1182015988.4514.9.camel@dijkstra.wildebeest.org> References: <200706152121.35386.gnu_andrew@member.fsf.org> <1182015988.4514.9.camel@dijkstra.wildebeest.org> Message-ID: <200706170028.06795.gnu_andrew@member.fsf.org> On Saturday 16 June 2007 18:46, Mark Wielaard wrote: > Hi Andrew, > > On Fri, 2007-06-15 at 21:21 +0100, Andrew John Hughes wrote: > > To cut a long story short, I've succeeded in cobbling together a small > > autoconf build system that will pluck through the OpenJDK sources and > > build them (just javac, javadoc, javah and apt so far, as a proof of > > concept -- but more should be easy enough to add now the main work's > > done). It creates a tools.jar and scripts to run them (just like those > > in Classpath). I was wondering if it would be worth me cleaning this up > > a little (adding niceties like a README, etc.) and hosting it with the > > rest of the IcedTea stuff. > > Nice. This sounds very useful. How "portable" is the result? Is it > completely self-contained or do the tools depend on some of the internal > openjdk library implementations (can I use them with gcj for example)? > It seems portable. Personally, I run the resulting tools with cacao and GNU Classpath and it has worked fine so far. I've just managed to build most of JikesRVM using the tools.jar (Ant tries to use this by default, which is what inspired me in the first place). I've also succeeded in compiling apt to native from the result, but it failed to run due to my gcj being outdated (it doesn't have the javac hacks we added yet) -- I need to build a new one at some point. > I think it would be a nice addition to the icedtea build system if you > can make it easy to integrate. IcedTea is already kind of a build > harness for openjdk, if there is an option to easily build just the > tools with it that would be helpful imho, if only for those people who > just want to hack on and build the tools. Or maybe the openjdk > tools-group (is there such a thing?) would be interested. Although I > believe Dalibor already had a plan of autoconfiscating javac and the > team said they already had enough different build options. Alternatively > if nobody want to integrate your patches we can always create a new repo > (icepick) for you to make it easy to publish your stuff and have a > development repository. > My initial thought was a separate repository, because I've assumed the goals of the two are fairly different, but united under the banner of interaction between GNU Classpath and IcedTea. My understanding of IcedTea (having not had chance to build it myself yet) is that it patches and then uses OpenJDK's build system, whereas what I have here merely compiles the sources from the OpenJDK tree, putting the result in its own tree and not touching OpenJDK's build system at all (although that was my reference for some of the tricky parts). I could do with talking to Dalibor about his plans at some point (probably when I next catch him on IRC) as it does seem there may be an overlap there. He mentioned sending me some of the work he'd done at some point, but I haven't seen anything yet. > Any patches or source available? > At the moment, I've got away with just an autoconf build system. As I incorporate more tools though, patches may be necessary. > Cheers, > > Mark Cheers, -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070617/a39fe076/attachment.bin From yuhongbao_386 at hotmail.com Sat Jun 16 16:17:26 2007 From: yuhongbao_386 at hotmail.com (Yuhong Bao) Date: Sat, 16 Jun 2007 23:17:26 +0000 (UTC) Subject: Is bootstripping with gcj and classpath really nesserary? References: <4673D2F3.1030103@gatech.edu> Message-ID: > It's bootstrapping, and building on OpenJDK would make IcedTea unfree > (because OpenJDK has binary plugs), which defeats the point. I mean using a binary of IcedTea to bootstrap themselves. From fitzsim at redhat.com Sun Jun 17 12:08:33 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 17 Jun 2007 15:08:33 -0400 Subject: IcePick In-Reply-To: <200706170028.06795.gnu_andrew@member.fsf.org> References: <200706152121.35386.gnu_andrew@member.fsf.org> <1182015988.4514.9.camel@dijkstra.wildebeest.org> <200706170028.06795.gnu_andrew@member.fsf.org> Message-ID: <467586B1.2020802@redhat.com> Andrew John Hughes wrote: > On Saturday 16 June 2007 18:46, Mark Wielaard wrote: >> Hi Andrew, >> >> On Fri, 2007-06-15 at 21:21 +0100, Andrew John Hughes wrote: >>> To cut a long story short, I've succeeded in cobbling together a small >>> autoconf build system that will pluck through the OpenJDK sources and >>> build them (just javac, javadoc, javah and apt so far, as a proof of >>> concept -- but more should be easy enough to add now the main work's >>> done). It creates a tools.jar and scripts to run them (just like those >>> in Classpath). I was wondering if it would be worth me cleaning this up >>> a little (adding niceties like a README, etc.) and hosting it with the >>> rest of the IcedTea stuff. >> Nice. This sounds very useful. How "portable" is the result? Is it >> completely self-contained or do the tools depend on some of the internal >> openjdk library implementations (can I use them with gcj for example)? >> > > It seems portable. Personally, I run the resulting tools with cacao and GNU > Classpath and it has worked fine so far. I've just managed to build most of > JikesRVM using the tools.jar (Ant tries to use this by default, which is what > inspired me in the first place). I've also succeeded in compiling apt to > native from the result, but it failed to run due to my gcj being outdated (it > doesn't have the javac hacks we added yet) -- I need to build a new one at > some point. Have you thought about simply merging the OpenJDK tools sources you need into the GNU Classpath repository, under the tools/external directory? Then all the GNU Classpath-using runtime projects would have convenient access to these tools without any extra merging effort. Tom From mcepl at redhat.com Sun Jun 17 15:51:51 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 18 Jun 2007 00:51:51 +0200 Subject: Fedora IcedTea packages References: <467077D6.3040007@redhat.com> Message-ID: On 2007-06-13, 23:03 GMT, Thomas Fitzsimmons wrote: > I uploaded a .nosrc.rpm that can be used to build IcedTea > packages on Fedora 7: Trying to compile that on Fedora 7 and got one beautiful SELinux AVC denial: Summary SELinux is preventing /home/matej/redhat/BUILD/icedtea-1.0/openjdk/control\ /build/linux-i586/bin/java from loading /home/matej/redhat/BUILD/icedtea-1.0\ /openjdk/control/build/linux-i586/lib/i386/client/libjvm.so which requires text relocation. Raw Audit Messages avc: denied { execmod } for comm="java" dev=dm-4 egid=500 euid=500 exe="/home/matej/redhat/BUILD/icedtea-1.0/openjdk/control/build/linux-i586/bin/java" exit=0 fsgid=500 fsuid=500 gid=500 items=0 name="libjvm.so" path="/home/matej/redhat/BU ILD/icedtea-1.0/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so" pid=10091 scontext=user_u:system_r:unconfined_t:s0 sgid=500 subj=user_u:system_r:unconfined_t:s0 suid=500 tclass=file tcontext=user_u:object_r:user_home_t:s0 tty=pts1 uid=500 Any thoughts on this? Matej Cepl From mark at klomp.org Mon Jun 18 07:23:02 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 18 Jun 2007 16:23:02 +0200 Subject: Experimental Build Repository at icedtea.classpath.org In-Reply-To: <20070608175048.8DC836431@callebaut.niobe.net> References: <20070608175048.8DC836431@callebaut.niobe.net> Message-ID: <1182176582.4534.41.camel@dijkstra.wildebeest.org> On Fri, 2007-06-08 at 10:50 -0700, Mark Reinhold wrote: > > Date: Thu, 07 Jun 2007 19:23:33 -0400 > > From: Francis Kung > > ... > > > > I didn't realise we were on b13 (was there any public announcement? > > announce at openjdk.java.net would be a natural place). > > I'll look into this. Prior to the big launch a month ago our RE team was > sending build-promotion notices to the announce list; not sure why that > stopped. Someone on irc pointed me at http://download.java.net/jdk7/changes/jdk7-b13.html which contains some explanations for some of the svn diff output you might have been puzzling over between b12 and b13. Is there a similar list of issues being worked on for b14+? And any timeline when such b14+ code drops are scheduled to appear? Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070618/c68fbd8a/attachment.bin From aph at redhat.com Mon Jun 18 08:03:21 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2007 16:03:21 +0100 Subject: Is bootstripping with gcj and classpath really nesserary? In-Reply-To: References: <4673D2F3.1030103@gatech.edu> Message-ID: <18038.40633.605271.836323@zebedee.pink> Yuhong Bao writes: > > > It's bootstrapping, and building on OpenJDK would make IcedTea unfree > > (because OpenJDK has binary plugs), which defeats the point. > > I mean using a binary of IcedTea to bootstrap themselves. That works, but you have to start from somewhere. If you are bulding for a free operating system like Fedora or Debian, you have to start with a bunch of source code and some free software and then build a binary package. We can't build IcedTea with unfree software and install that on Fedora, because we then could not prove that IcedTea wasn't derived from unfree software. It might turn out, by accident, that IcedTea contained binary components from the unfree JDK that was used to bootstrap it. That would be a very Bad Thing. In the future it won't be necessary to bootstrap with Classpath and gcj. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From fitzsim at redhat.com Mon Jun 18 08:34:29 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 18 Jun 2007 11:34:29 -0400 Subject: Fedora IcedTea packages In-Reply-To: References: <467077D6.3040007@redhat.com> Message-ID: <4676A605.5080805@redhat.com> Matej Cepl wrote: > On 2007-06-13, 23:03 GMT, Thomas Fitzsimmons wrote: >> I uploaded a .nosrc.rpm that can be used to build IcedTea >> packages on Fedora 7: > > Trying to compile that on Fedora 7 and got one beautiful SELinux > AVC denial: > > Summary > SELinux is preventing > /home/matej/redhat/BUILD/icedtea-1.0/openjdk/control\ > /build/linux-i586/bin/java from loading > /home/matej/redhat/BUILD/icedtea-1.0\ > /openjdk/control/build/linux-i586/lib/i386/client/libjvm.so > which requires text relocation. > > Raw Audit Messages > > avc: denied { execmod } for comm="java" dev=dm-4 egid=500 > euid=500 > exe="/home/matej/redhat/BUILD/icedtea-1.0/openjdk/control/build/linux-i586/bin/java" > exit=0 > fsgid=500 fsuid=500 gid=500 items=0 name="libjvm.so" > path="/home/matej/redhat/BU > ILD/icedtea-1.0/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so" > pid=10091 scontext=user_u:system_r:unconfined_t:s0 sgid=500 > subj=user_u:system_r:unconfined_t:s0 suid=500 tclass=file > tcontext=user_u:object_r:user_home_t:s0 tty=pts1 uid=500 > > Any thoughts on this? Yes, I've attached a patch that fixes this. You can add it to java-1.7.0-icedtea.spec for now, and it will be in the next IcedTea release. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-text-relocations.patch Type: text/x-patch Size: 648 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070618/af98fc70/icedtea-text-relocations.patch From matthew.flaschen at gatech.edu Mon Jun 18 13:44:48 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Mon, 18 Jun 2007 16:44:48 -0400 Subject: Fedora IcedTea packages In-Reply-To: <4676A605.5080805@redhat.com> References: <467077D6.3040007@redhat.com> <4676A605.5080805@redhat.com> Message-ID: <4676EEC0.3010901@gatech.edu> Thomas Fitzsimmons wrote: > Yes, I've attached a patch that fixes this. You can add it to > java-1.7.0-icedtea.spec for now, and it will be in the next IcedTea > release. What's the difference between fPIC and fpic? Matt Flaschen From gbenson at redhat.com Tue Jun 19 00:46:44 2007 From: gbenson at redhat.com (Gary Benson) Date: Tue, 19 Jun 2007 08:46:44 +0100 Subject: Fedora IcedTea packages In-Reply-To: <4676EEC0.3010901@gatech.edu> References: <467077D6.3040007@redhat.com> <4676A605.5080805@redhat.com> <4676EEC0.3010901@gatech.edu> Message-ID: <20070619074644.GA3938@redhat.com> Matthew Flaschen wrote: > Thomas Fitzsimmons wrote: > > Yes, I've attached a patch that fixes this. You can add it > > to java-1.7.0-icedtea.spec for now, and it will be in the next > > IcedTea release. > > What's the difference between fPIC and fpic? -fPIC works around a hardware limit that -fpic can hit on some machines. Cheers, Gary From langel at redhat.com Tue Jun 19 07:31:07 2007 From: langel at redhat.com (Lillian Angel) Date: Tue, 19 Jun 2007 10:31:07 -0400 Subject: Mauve test run results In-Reply-To: <466EDFA0.2080700@redhat.com> References: <1181288479.4418.28.camel@dijkstra.wildebeest.org> <466EDFA0.2080700@redhat.com> Message-ID: <4677E8AB.2080701@redhat.com> Francis Kung wrote: > Hi, > >> And I thought the answer would be appropriate for the list especially in >> the light of how we are going to make sure icedtea/openjdk derivatives >> are "good". Mauve is a nice check that icedtea/openjdk conforms to what >> we expect from a GNU Classpath derived runtime, but you would also want >> other tests of course to see that it confirms to the quality that people >> have come expected of the Sun Java releases. > > I've also run a more targeted test: I excluded all the > graphics-related packages (java.awt.* and javax.swing.*) and ran the > openjdk-b13 with binary plugs through the Mauve suite. Then, I took > only the tests that passed, and ran those through IcedTea. The stub > replacement & gcj bootstrapping process introduced only 12 test failures: There have been some fixes in Mauve recently. There are 0 new failures on IcedTea when rerunning the testsuite. Lillian From langel at redhat.com Tue Jun 19 07:31:52 2007 From: langel at redhat.com (Lillian Angel) Date: Tue, 19 Jun 2007 10:31:52 -0400 Subject: bug tracking In-Reply-To: <1181639057.4417.24.camel@dijkstra.wildebeest.org> References: <1181639057.4417.24.camel@dijkstra.wildebeest.org> Message-ID: <4677E8D8.9060401@redhat.com> Mark Wielaard wrote: > - Configure should detect missing openjdk src zip. > Currently the build just goes out and tries to download a new copy > even if the user might already have the (80MB!) zip around, but in the > wrong dir. Fixed! Lillian From fkung at redhat.com Tue Jun 19 08:48:24 2007 From: fkung at redhat.com (Francis Kung) Date: Tue, 19 Jun 2007 11:48:24 -0400 Subject: Faster IcedTea builds Message-ID: <4677FAC8.5080600@redhat.com> Hi, I've just committed a change into the IcedTea repository providing a fast-build option: if you pass --enable-fast-build to configure, it will build with -O0 (instead of -O3) and will skip building all the javadoc. This speeds up the build by about 30-50% for me, which may be useful to those doing development work. Cheers, Francis From gbenson at redhat.com Wed Jun 20 00:45:12 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 20 Jun 2007 08:45:12 +0100 Subject: Faster IcedTea builds In-Reply-To: <4677FAC8.5080600@redhat.com> References: <4677FAC8.5080600@redhat.com> Message-ID: <20070620074512.GB4096@redhat.com> Francis Kung wrote: > I've just committed a change into the IcedTea repository providing a > fast-build option: if you pass --enable-fast-build to configure, it > will build with -O0 (instead of -O3) and will skip building all the > javadoc. > > This speeds up the build by about 30-50% for me, which may be useful > to those doing development work. Good call. I switched to -O0 locally, but I didn't think to make it available like that. Cheers, Gary From konqueror at gmx.de Wed Jun 20 01:07:38 2007 From: konqueror at gmx.de (Michael Koch) Date: Wed, 20 Jun 2007 10:07:38 +0200 Subject: Faster IcedTea builds In-Reply-To: <4677FAC8.5080600@redhat.com> References: <4677FAC8.5080600@redhat.com> Message-ID: <20070620080738.GZ27920@mail.konqueror.de> On Tue, Jun 19, 2007 at 11:48:24AM -0400, Francis Kung wrote: > Hi, > > I've just committed a change into the IcedTea repository providing a > fast-build option: if you pass --enable-fast-build to configure, it will > build with -O0 (instead of -O3) and will skip building all the javadoc. > > This speeds up the build by about 30-50% for me, which may be useful to > those doing development work. Isn't ccache a better option to make the build faster? Cheers, Michael -- .''`. | Michael Koch : :' : | Free Java Developer `. `' | `- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B From fkung at redhat.com Wed Jun 20 08:02:45 2007 From: fkung at redhat.com (Francis Kung) Date: Wed, 20 Jun 2007 11:02:45 -0400 Subject: Faster IcedTea builds In-Reply-To: <20070620080738.GZ27920@mail.konqueror.de> References: <4677FAC8.5080600@redhat.com> <20070620080738.GZ27920@mail.konqueror.de> Message-ID: <46794195.4000403@redhat.com> >> I've just committed a change into the IcedTea repository providing a >> fast-build option: if you pass --enable-fast-build to configure, it will >> build with -O0 (instead of -O3) and will skip building all the javadoc. >> >> This speeds up the build by about 30-50% for me, which may be useful to >> those doing development work. > > Isn't ccache a better option to make the build faster? I wasn't familiar with ccache, but it does look very promising, yes! This sounds really cool... thanks for mentioning it =) I'll open a ticket in the IcedTea bugzilla for it in case anyone wants to add this. Francis From betelgeuse at gentoo.org Wed Jun 20 09:49:29 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Wed, 20 Jun 2007 19:49:29 +0300 Subject: Faster IcedTea builds In-Reply-To: <46794195.4000403@redhat.com> References: <4677FAC8.5080600@redhat.com> <20070620080738.GZ27920@mail.konqueror.de> <46794195.4000403@redhat.com> Message-ID: <46795A99.400@gentoo.org> Francis Kung kirjoitti: >>> I've just committed a change into the IcedTea repository providing a >>> fast-build option: if you pass --enable-fast-build to configure, it >>> will build with -O0 (instead of -O3) and will skip building all the >>> javadoc. >>> >>> This speeds up the build by about 30-50% for me, which may be useful >>> to those doing development work. >> >> Isn't ccache a better option to make the build faster? > > I wasn't familiar with ccache, but it does look very promising, yes! > This sounds really cool... thanks for mentioning it =) > > I'll open a ticket in the IcedTea bugzilla for it in case anyone wants > to add this. > > Francis > Just make sure configure your way around: http://news.gmane.org/gmane.comp.java.openjdk.build.devel Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070620/e4b559b8/signature.asc From aph at redhat.com Wed Jun 20 10:21:04 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Jun 2007 18:21:04 +0100 Subject: Building OpenJDK with debuginfo Message-ID: <18041.25088.656361.976815@zebedee.pink> I noticed that debugging IcedTea is difficult, and I've found the core problem: ecj defaults to generating minimal debuginfo, basically just line numbers. GNU/Linux distributions usually have a rule that debuginfo is enabled for all packages, and I can't think of any reason not to do that now with IcedTea. Debuginfo is going to be non-negotiable in a real release package anyway. So, I'll fix the Makefiles to use "-g" throughout. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From betelgeuse at gentoo.org Wed Jun 20 10:25:49 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Wed, 20 Jun 2007 20:25:49 +0300 Subject: Faster IcedTea builds In-Reply-To: <46795A99.400@gentoo.org> References: <4677FAC8.5080600@redhat.com> <20070620080738.GZ27920@mail.konqueror.de> <46794195.4000403@redhat.com> <46795A99.400@gentoo.org> Message-ID: <4679631D.1050601@gentoo.org> Petteri R?ty kirjoitti: > Francis Kung kirjoitti: >>>> I've just committed a change into the IcedTea repository providing a >>>> fast-build option: if you pass --enable-fast-build to configure, it >>>> will build with -O0 (instead of -O3) and will skip building all the >>>> javadoc. >>>> >>>> This speeds up the build by about 30-50% for me, which may be useful >>>> to those doing development work. >>> Isn't ccache a better option to make the build faster? >> I wasn't familiar with ccache, but it does look very promising, yes! >> This sounds really cool... thanks for mentioning it =) >> >> I'll open a ticket in the IcedTea bugzilla for it in case anyone wants >> to add this. >> >> Francis >> > > Just make sure configure your way around: > http://news.gmane.org/gmane.comp.java.openjdk.build.devel > > Regards, > Petteri > A direct link http://article.gmane.org/gmane.comp.java.openjdk.build.devel/13 Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070620/824eb6b9/signature.asc From betelgeuse at gentoo.org Wed Jun 20 10:29:34 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Wed, 20 Jun 2007 20:29:34 +0300 Subject: Building OpenJDK with debuginfo In-Reply-To: <18041.25088.656361.976815@zebedee.pink> References: <18041.25088.656361.976815@zebedee.pink> Message-ID: <467963FE.7080704@gentoo.org> Andrew Haley kirjoitti: > I noticed that debugging IcedTea is difficult, and I've found the core > problem: ecj defaults to generating minimal debuginfo, basically just > line numbers. GNU/Linux distributions usually have a rule that > debuginfo is enabled for all packages, and I can't think of any reason > not to do that now with IcedTea. Debuginfo is going to be non-negotiable > in a real release package anyway. > > So, I'll fix the Makefiles to use "-g" throughout. > > Andrew. > Shouldn't -g be something that is picked from CFLAGS. This is what we do in the Gentoo OpenJDK ebuild: 103 # Don't pass these to make, or they'll break stuff. 104 export OTHER_CFLAGS=${CFLAGS} 105 export OTHER_CXXFLAGS=${CXXFLAGS} http://overlays.gentoo.org/proj/java/browser/java-experimental/dev-java/openjdk/openjdk-1.7.0.0_alpha13.ebuild Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070620/9df1eb25/signature.asc From aph at redhat.com Wed Jun 20 10:34:18 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Jun 2007 18:34:18 +0100 Subject: Building OpenJDK with debuginfo In-Reply-To: <467963FE.7080704@gentoo.org> References: <18041.25088.656361.976815@zebedee.pink> <467963FE.7080704@gentoo.org> Message-ID: <18041.25882.304697.464246@zebedee.pink> Petteri R?ty writes: > Andrew Haley kirjoitti: > > I noticed that debugging IcedTea is difficult, and I've found the core > > problem: ecj defaults to generating minimal debuginfo, basically just > > line numbers. GNU/Linux distributions usually have a rule that > > debuginfo is enabled for all packages, and I can't think of any reason > > not to do that now with IcedTea. Debuginfo is going to be non-negotiable > > in a real release package anyway. > > > > So, I'll fix the Makefiles to use "-g" throughout. > > Shouldn't -g be something that is picked from CFLAGS. When building Java code? I hope not. :-) > This is what we do in the Gentoo OpenJDK ebuild: > > 103 # Don't pass these to make, or they'll break stuff. > 104 export OTHER_CFLAGS=${CFLAGS} > 105 export OTHER_CXXFLAGS=${CXXFLAGS} > > http://overlays.gentoo.org/proj/java/browser/java-experimental/dev-java/openjdk/openjdk-1.7.0.0_alpha13.ebuild OK, thanks. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From betelgeuse at gentoo.org Wed Jun 20 10:37:00 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Wed, 20 Jun 2007 20:37:00 +0300 Subject: Building OpenJDK with debuginfo In-Reply-To: <18041.25882.304697.464246@zebedee.pink> References: <18041.25088.656361.976815@zebedee.pink> <467963FE.7080704@gentoo.org> <18041.25882.304697.464246@zebedee.pink> Message-ID: <467965BC.9060608@gentoo.org> Andrew Haley kirjoitti: > Petteri R?ty writes: > > Andrew Haley kirjoitti: > > > I noticed that debugging IcedTea is difficult, and I've found the core > > > problem: ecj defaults to generating minimal debuginfo, basically just > > > line numbers. GNU/Linux distributions usually have a rule that > > > debuginfo is enabled for all packages, and I can't think of any reason > > > not to do that now with IcedTea. Debuginfo is going to be non-negotiable > > > in a real release package anyway. > > > > > > So, I'll fix the Makefiles to use "-g" throughout. > > > > Shouldn't -g be something that is picked from CFLAGS. > > When building Java code? I hope not. :-) > Ah yes missed that part. :) Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070620/fd335ab1/signature.asc From konqueror at gmx.de Wed Jun 20 12:19:49 2007 From: konqueror at gmx.de (Michael Koch) Date: Wed, 20 Jun 2007 21:19:49 +0200 Subject: Faster IcedTea builds In-Reply-To: <46794195.4000403@redhat.com> References: <4677FAC8.5080600@redhat.com> <20070620080738.GZ27920@mail.konqueror.de> <46794195.4000403@redhat.com> Message-ID: <20070620191949.GD27920@mail.konqueror.de> On Wed, Jun 20, 2007 at 11:02:45AM -0400, Francis Kung wrote: > >>I've just committed a change into the IcedTea repository providing a > >>fast-build option: if you pass --enable-fast-build to configure, it will > >>build with -O0 (instead of -O3) and will skip building all the javadoc. > >> > >>This speeds up the build by about 30-50% for me, which may be useful to > >>those doing development work. > > > >Isn't ccache a better option to make the build faster? > > I wasn't familiar with ccache, but it does look very promising, yes! > This sounds really cool... thanks for mentioning it =) > > I'll open a ticket in the IcedTea bugzilla for it in case anyone wants > to add this. You dont need to added support for it explicitely. ccache provides gcc, g++, etc. wrappers. It can be used transparently. I use it for my packaging work a lot. Cheers, Michael -- .''`. | Michael Koch : :' : | Free Java Developer `. `' | `- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B From kgallowa at redhat.com Thu Jun 21 07:50:25 2007 From: kgallowa at redhat.com (Kyle Galloway) Date: Thu, 21 Jun 2007 10:50:25 -0400 Subject: Faster IcedTea builds In-Reply-To: <20070620191949.GD27920@mail.konqueror.de> References: <4677FAC8.5080600@redhat.com> <20070620080738.GZ27920@mail.konqueror.de> <46794195.4000403@redhat.com> <20070620191949.GD27920@mail.konqueror.de> Message-ID: <467A9031.9010901@redhat.com> Michael Koch wrote: > On Wed, Jun 20, 2007 at 11:02:45AM -0400, Francis Kung wrote: > >> I'll open a ticket in the IcedTea bugzilla for it in case anyone wants >> to add this. >> > > You dont need to added support for it explicitely. ccache provides gcc, > g++, etc. wrappers. It can be used transparently. I use it for my > packaging work a lot. > Though that works well for people who want to use ccache all the time, I know I don't have my compilers replaced by ccache wrappers, even though I like the program. ccache support, however, has now been added to the IcedTea build process. It is enabled by default if ccache is found, but can be disabled by passing --disable-ccache to configure. Kyle From yuhongbao_386 at hotmail.com Thu Jun 21 17:06:03 2007 From: yuhongbao_386 at hotmail.com (Yuhong Bao) Date: Fri, 22 Jun 2007 00:06:03 +0000 (UTC) Subject: Is bootstripping with gcj and classpath really nesserary? References: <4673D2F3.1030103@gatech.edu> <18038.40633.605271.836323@zebedee.pink> Message-ID: > by accident, that IcedTea contained binary components from the unfree > JDK that was used to bootstrap it. That would be a very Bad Thing. That is why the result of the unfree build is used to build again, just to ensure this won't happen. From betelgeuse at gentoo.org Thu Jun 21 23:37:12 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Fri, 22 Jun 2007 09:37:12 +0300 Subject: Is bootstripping with gcj and classpath really nesserary? In-Reply-To: References: <4673D2F3.1030103@gatech.edu> <18038.40633.605271.836323@zebedee.pink> Message-ID: <467B6E18.2010702@gentoo.org> Yuhong Bao kirjoitti: >> by accident, that IcedTea contained binary components from the unfree >> JDK that was used to bootstrap it. That would be a very Bad Thing. > > That is why the result of the unfree build is used to build again, > just to ensure this won't happen. > That would accomplish what? The unfree build could still leak those bits. It's not likely of course. Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070622/ca13dbcd/signature.asc From betelgeuse at gentoo.org Fri Jun 22 11:37:29 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Fri, 22 Jun 2007 21:37:29 +0300 Subject: Clearly marking external files in j2se/src/solaris/native/sun/awt as such Message-ID: <467C16E9.3050409@gentoo.org> Attached is the output of grep -E "\\\$(XConsortium|XFree86)" -l * I am in the process of trying to build with these files deleted so let's see how it goes but any way it's a bit awkward that the directory has Sun written stuff and external files mixed together. Maybe the external files should be in their own directory for easy deletion/replacement with system stuff? I cross posted this to distro-pkg-dev and build-dev as it affects both. Regards, Petteri -- Gentoo/Java project lead -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output.txt Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070622/21dc666a/output.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070622/21dc666a/signature.asc From betelgeuse at gentoo.org Fri Jun 22 15:26:30 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Sat, 23 Jun 2007 01:26:30 +0300 Subject: Clearly marking external files in j2se/src/solaris/native/sun/awt as such In-Reply-To: <467C3871.5050402@sun.com> References: <467C16E9.3050409@gentoo.org> <467C3871.5050402@sun.com> Message-ID: <467C4C96.7010107@gentoo.org> Phil Race kirjoitti: > Some of those are .c files, not header files. > You may also want to see how any of these files differ in any significant > way from the ones on your system. I think at least a couple of them are > modified. > > -phil > Yep I never talked about headers exclusively. My point mainly being that keeping forked files should be avoided if at all possible. Any improvements/changes should go upstream etc. Yes diffing them is certainly prudent but let's see if I find the time for that any time soon. Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070623/835f6159/signature.asc From betelgeuse at gentoo.org Fri Jun 22 16:05:35 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Sat, 23 Jun 2007 02:05:35 +0300 Subject: Clearly marking external files in j2se/src/solaris/native/sun/awt as such In-Reply-To: <467C4C96.7010107@gentoo.org> References: <467C16E9.3050409@gentoo.org> <467C3871.5050402@sun.com> <467C4C96.7010107@gentoo.org> Message-ID: <467C55BF.9000001@gentoo.org> Petteri R?ty kirjoitti: > Phil Race kirjoitti: >> Some of those are .c files, not header files. >> You may also want to see how any of these files differ in any significant >> way from the ones on your system. I think at least a couple of them are >> modified. >> >> -phil >> > > Yep I never talked about headers exclusively. My point mainly being that > keeping forked files should be avoided if at all possible. Any > improvements/changes should go upstream etc. Yes diffing them is > certainly prudent but let's see if I find the time for that any time soon. > > Regards, > Petteri > Ok so mapping these files: Xrandr.h x11-libs/libXrandr Xinerama.c x11-libs/libXinerama panoramiXext.h panoramiXproto.h Xinerama.h x11-proto/xineramaproto randr.h x11-proto/randrproto extutil.h x11-proto/xextproto multiVis.c multiVis.h list.c list.h wsutils.h x11-apps/xwd Of these the files in xwd can't be currently linked against as xwd is an application. The other should be fine to use the system files based on the diffs at least on Linux. Take for example the attached panoramiXproto.h diff. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: panorami.diff Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070623/63783e2a/panorami.diff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070623/63783e2a/signature.asc From Phil.Race at Sun.COM Fri Jun 22 14:00:33 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 22 Jun 2007 14:00:33 -0700 Subject: Clearly marking external files in j2se/src/solaris/native/sun/awt as such In-Reply-To: <467C16E9.3050409@gentoo.org> References: <467C16E9.3050409@gentoo.org> Message-ID: <467C3871.5050402@sun.com> Some of those are .c files, not header files. You may also want to see how any of these files differ in any significant way from the ones on your system. I think at least a couple of them are modified. -phil Petteri R?ty wrote: > Attached is the output of grep -E "\\\$(XConsortium|XFree86)" -l * > I am in the process of trying to build with these files deleted so let's > see how it goes but any way it's a bit awkward that the directory has > Sun written stuff and external files mixed together. Maybe the external > files should be in their own directory for easy deletion/replacement > with system stuff? > > I cross posted this to distro-pkg-dev and build-dev as it affects both. > > Regards, > Petteri > -- > Gentoo/Java project lead > > > ------------------------------------------------------------------------ > > extutil.h:/* $XFree86: xc/include/extensions/extutil.h,v 1.5 2001/01/17 17:53:20 dawes Exp $ */ > list.c:/* $XConsortium: list.c /main/4 1996/10/14 15:03:56 swick $ */ > list.h:/* $XConsortium: list.h /main/4 1996/10/14 15:04:04 swick $ */ > multiVis.c:/* $XConsortium: multiVis.c /main/4 1996/10/14 15:04:08 swick $ */ > multiVis.h:/* $XConsortium: multiVis.h /main/4 1996/10/14 15:04:12 swick $ */ > panoramiXext.h:/* $XFree86: xc/include/extensions/panoramiXext.h,v 3.6 2001/01/17 17:53:22 dawes Exp $ */ > panoramiXproto.h:/* $XFree86: xc/include/extensions/panoramiXproto.h,v 3.6 2001/01/17 17:53:22 dawes Exp $ */ > randr.h: * $XFree86: xc/include/extensions/randr.h,v 1.4 2001/11/24 07:24:58 keithp Exp $ > wsutils.h:/* $XConsortium: wsutils.h /main/3 1996/10/14 15:04:17 swick $ */ > Xinerama.c:/* $XFree86: xc/lib/Xinerama/Xinerama.c,v 1.4 2004/04/03 22:38:52 tsi Exp $ */ > Xinerama.h:/* $XFree86: xc/include/extensions/Xinerama.h,v 3.2 2000/03/01 01:04:20 dawes Exp $ */ > Xrandr.h: * $XFree86: xc/lib/Xrandr/Xrandr.h,v 1.9 2002/09/29 23:39:44 keithp Exp $ From matthew.flaschen at gatech.edu Sun Jun 24 02:10:47 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Sun, 24 Jun 2007 05:10:47 -0400 Subject: Building on BLAG/FC 6 Message-ID: <467E3517.3000003@gatech.edu> I'm trying to build on BLAG 60000, which is based on Fedora Core 6. It can't find libgcj-4.1.2.jar , since FC6 seems to have libgcj-4.1.1.jar . If I override this, do you think the rest of the build will work? Matt Flaschen From mark at klomp.org Sun Jun 24 03:36:03 2007 From: mark at klomp.org (Mark Wielaard) Date: Sun, 24 Jun 2007 12:36:03 +0200 Subject: Building on BLAG/FC 6 In-Reply-To: <467E3517.3000003@gatech.edu> References: <467E3517.3000003@gatech.edu> Message-ID: <1182681364.4101.1.camel@hermans.wildebeest.org> Hi Matthew, On Sun, 2007-06-24 at 05:10 -0400, Matthew Flaschen wrote: > I'm trying to build on BLAG 60000, which is based on Fedora Core 6. It > can't find libgcj-4.1.2.jar , since FC6 seems to have libgcj-4.1.1.jar . > If I override this, do you think the rest of the build will work? No, you will need something based of the gcj in Fedora 7 or later (the gcj in Fedora 7 is actually 4.1.2 plus a backport of the new 1.5 and ecj work. Cheers, Mark From mark at klomp.org Sun Jun 24 14:12:36 2007 From: mark at klomp.org (Mark Wielaard) Date: Sun, 24 Jun 2007 23:12:36 +0200 Subject: Read-only mercurial mirror of openjdk subversion Message-ID: <1182719557.5950.32.camel@dijkstra.wildebeest.org> Hi, Since I wanted to look at bit at the history and changes made to OpenJDK over time, but wasn?t going to be online for a while (and the subversion server of openjdk seems a little slow even if I were online) I decided to create a read-only openjdk mercurial mirror so I could carry the whole project history with me on a laptop and do quick diffs. [1] This is pretty nice since it is much faster and much smaller than working with the subversion checkouts themselves. If someone else thinks this is useful then you can get at it through: hg clone http://icedtea.classpath.org/hg/openjdk WARNING, that is 740MB - but that is for the whole repo with all history though, so it is still much smaller than a single subversion checkout, which comes in at 1.2GB (!) It is read-only and just tracks the subversion repository whenever updates are made to it, so you can just hg pull them in. It also makes it a little easier to keep experimental patches up to date since the subversion repo is also read-only, but you can easily clone the mercurial repo locally. Cheers, Mark [1] hgsvn is really great for doing this and makes it really simple: http://cheeseshop.python.org/pypi/hgsvn/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070624/43ea673e/attachment.bin From fkung at redhat.com Mon Jun 25 07:11:00 2007 From: fkung at redhat.com (Francis Kung) Date: Mon, 25 Jun 2007 10:11:00 -0400 Subject: Building on BLAG/FC 6 In-Reply-To: <1182681364.4101.1.camel@hermans.wildebeest.org> References: <467E3517.3000003@gatech.edu> <1182681364.4101.1.camel@hermans.wildebeest.org> Message-ID: <467FCCF4.7000409@redhat.com> Hi, >> I'm trying to build on BLAG 60000, which is based on Fedora Core 6. It >> can't find libgcj-4.1.2.jar , since FC6 seems to have libgcj-4.1.1.jar . >> If I override this, do you think the rest of the build will work? > > No, you will need something based of the gcj in Fedora 7 or later (the > gcj in Fedora 7 is actually 4.1.2 plus a backport of the new 1.5 and ecj > work. Alternately, you can follow the instructions at http://icedtea.classpath.org/wiki/GentooBuildInstructions to build a newer version of gcj without upgrading to a F7-based distro (of course, doing the Fedora/BLAG equivalents of the Gentoo commands provided). Cheers, Francis From aph at redhat.com Tue Jun 26 10:05:29 2007 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jun 2007 18:05:29 +0100 Subject: IcedTea crypto changes, etc. Message-ID: <18049.18265.254754.808797@zebedee.pink> I've committed a bunch of changes, merging GNU crypto to IcedTea. I've also committed a patch that forces debug info to be generated, regradless of the optimization level. Andrew. 2007-06-26 Andrew Haley * Makefile.am (ICEDTEA_PATCHES): Add icedtea-java.security.patch. 2007-06-22 Andrew Haley * Makefile.am (ICEDTEA_PATCHES): Add icedtea-debuginfo.patch. Add -g option to all Java compilations. (ICEDTEA_COPY_SRC): Copy a bunch of files needed to build GNU crypto. * jce/gnu/java/security/hash/BaseHash.java, jce/gnu/java/security/hash/HashFactory.java, jce/gnu/java/security/hash/Haval.java, jce/gnu/java/security/hash/IMessageDigest.java, jce/gnu/java/security/hash/MD2.java, jce/gnu/java/security/hash/MD4.java, jce/gnu/java/security/hash/MD5.java, jce/gnu/java/security/hash/RipeMD128.java, jce/gnu/java/security/hash/RipeMD160.java, jce/gnu/java/security/hash/Sha160.java, jce/gnu/java/security/hash/Sha256.java, jce/gnu/java/security/hash/Sha384.java, jce/gnu/java/security/hash/Sha512.java, jce/gnu/java/security/hash/Tiger.java, jce/gnu/java/security/hash/Whirlpool.java, jce/gnu/java/security/jce/hash/HavalSpi.java, jce/gnu/java/security/jce/hash/MD2Spi.java, jce/gnu/java/security/jce/hash/MD4Spi.java, jce/gnu/java/security/jce/hash/MD5Spi.java, jce/gnu/java/security/jce/hash/MessageDigestAdapter.java, jce/gnu/java/security/jce/hash/RipeMD128Spi.java, jce/gnu/java/security/jce/hash/RipeMD160Spi.java, jce/gnu/java/security/jce/hash/Sha160Spi.java, jce/gnu/java/security/jce/hash/Sha256Spi.java, jce/gnu/java/security/jce/hash/Sha384Spi.java, jce/gnu/java/security/jce/hash/Sha512Spi.java, jce/gnu/java/security/jce/hash/TigerSpi.java, jce/gnu/java/security/jce/hash/WhirlpoolSpi.java, jce/gnu/java/security/jce/prng/HavalRandomSpi.java, jce/gnu/java/security/jce/prng/MD2RandomSpi.java, jce/gnu/java/security/jce/prng/MD4RandomSpi.java, jce/gnu/java/security/jce/prng/MD5RandomSpi.java, jce/gnu/java/security/jce/prng/RipeMD128RandomSpi.java, jce/gnu/java/security/jce/prng/RipeMD160RandomSpi.java, jce/gnu/java/security/jce/prng/SecureRandomAdapter.java, jce/gnu/java/security/jce/prng/Sha160RandomSpi.java, jce/gnu/java/security/jce/prng/Sha256RandomSpi.java, jce/gnu/java/security/jce/prng/Sha384RandomSpi.java, jce/gnu/java/security/jce/prng/Sha512RandomSpi.java, jce/gnu/java/security/jce/prng/TigerRandomSpi.java, jce/gnu/java/security/jce/prng/WhirlpoolRandomSpi.java, jce/gnu/java/security/jce/sig/DSSKeyFactory.java, jce/gnu/java/security/jce/sig/DSSKeyPairGeneratorSpi.java, jce/gnu/java/security/jce/sig/DSSParameters.java, jce/gnu/java/security/jce/sig/DSSParametersGenerator.java, jce/gnu/java/security/jce/sig/DSSRawSignatureSpi.java, jce/gnu/java/security/jce/sig/EncodedKeyFactory.java, jce/gnu/java/security/jce/sig/KeyPairGeneratorAdapter.java, jce/gnu/java/security/jce/sig/MD2withRSA.java, jce/gnu/java/security/jce/sig/MD5withRSA.java, jce/gnu/java/security/jce/sig/RSAKeyFactory.java, jce/gnu/java/security/jce/sig/RSAKeyPairGeneratorSpi.java, jce/gnu/java/security/jce/sig/RSAPSSRawSignatureSpi.java, jce/gnu/java/security/jce/sig/SHA160withDSS.java, jce/gnu/java/security/jce/sig/SHA160withRSA.java, jce/gnu/java/security/jce/sig/SHA256withRSA.java, jce/gnu/java/security/jce/sig/SHA384withRSA.java, jce/gnu/java/security/jce/sig/SHA512withRSA.java, jce/gnu/java/security/jce/sig/SignatureAdapter.java, jce/gnu/java/security/key/IKeyPairCodec.java, jce/gnu/java/security/key/IKeyPairGenerator.java, jce/gnu/java/security/key/KeyPairCodecFactory.java, jce/gnu/java/security/key/KeyPairGeneratorFactory.java, jce/gnu/java/security/key/dss/DSSKey.java, jce/gnu/java/security/key/dss/DSSKeyPairGenerator.java, jce/gnu/java/security/key/dss/DSSKeyPairPKCS8Codec.java, jce/gnu/java/security/key/dss/DSSKeyPairRawCodec.java, jce/gnu/java/security/key/dss/DSSKeyPairX509Codec.java, jce/gnu/java/security/key/dss/DSSPrivateKey.java, jce/gnu/java/security/key/dss/DSSPublicKey.java, jce/gnu/java/security/key/dss/FIPS186.java, jce/gnu/java/security/key/rsa/GnuRSAKey.java, jce/gnu/java/security/key/rsa/GnuRSAPrivateKey.java, jce/gnu/java/security/key/rsa/GnuRSAPublicKey.java, jce/gnu/java/security/key/rsa/RSAKeyPairGenerator.java, jce/gnu/java/security/key/rsa/RSAKeyPairPKCS8Codec.java, jce/gnu/java/security/key/rsa/RSAKeyPairRawCodec.java, jce/gnu/java/security/key/rsa/RSAKeyPairX509Codec.java, jce/gnu/java/security/prng/BasePRNG.java, jce/gnu/java/security/prng/EntropySource.java, jce/gnu/java/security/prng/IRandom.java, jce/gnu/java/security/prng/LimitReachedException.java, jce/gnu/java/security/prng/MDGenerator.java, jce/gnu/java/security/prng/PRNGFactory.java, jce/gnu/java/security/prng/RandomEvent.java, jce/gnu/java/security/prng/RandomEventListener.java, jce/gnu/java/security/provider/CollectionCertStoreImpl.java, jce/gnu/java/security/provider/DefaultPolicy.java, jce/gnu/java/security/provider/Gnu.java, jce/gnu/java/security/provider/PKIXCertPathValidatorImpl.java, jce/gnu/java/security/provider/X509CertificateFactory.java, jce/gnu/java/security/provider/package.html, jce/gnu/java/security/sig/BaseSignature.java, jce/gnu/java/security/sig/ISignature.java, jce/gnu/java/security/sig/ISignatureCodec.java, jce/gnu/java/security/sig/SignatureCodecFactory.java, jce/gnu/java/security/sig/SignatureFactory.java, jce/gnu/java/security/sig/dss/DSSSignature.java, jce/gnu/java/security/sig/dss/DSSSignatureRawCodec.java, jce/gnu/java/security/sig/dss/DSSSignatureX509Codec.java, jce/gnu/java/security/sig/rsa/EME_PKCS1_V1_5.java, jce/gnu/java/security/sig/rsa/EMSA_PKCS1_V1_5.java, jce/gnu/java/security/sig/rsa/EMSA_PSS.java, jce/gnu/java/security/sig/rsa/RSA.java, jce/gnu/java/security/sig/rsa/RSAPKCS1V1_5Signature.java, jce/gnu/java/security/sig/rsa/RSAPKCS1V1_5SignatureRawCodec.java, jce/gnu/java/security/sig/rsa/RSAPKCS1V1_5SignatureX509Codec.java, jce/gnu/java/security/sig/rsa/RSAPSSSignature.java, jce/gnu/java/security/sig/rsa/RSAPSSSignatureRawCodec.java, jce/gnu/java/security/sig/rsa/RSASignatureFactory.java, jce/gnu/java/security/util/ByteArray.java, jce/gnu/java/security/util/ByteBufferOutputStream.java, jce/gnu/java/security/util/DerUtil.java, jce/gnu/java/security/util/ExpirableObject.java, jce/gnu/java/security/util/FormatUtil.java, jce/gnu/java/security/util/IntegerUtil.java, jce/gnu/java/security/util/PRNG.java, jce/gnu/java/security/util/Prime.java, jce/gnu/java/security/util/Sequence.java, jce/gnu/java/security/util/SimpleList.java, jce/gnu/java/security/util/Util.java, jce/gnu/java/security/util/package.html, jce/gnu/java/security/x509/GnuPKIExtension.java, jce/gnu/java/security/x509/PolicyNodeImpl.java, jce/gnu/java/security/x509/X500DistinguishedName.java, jce/gnu/java/security/x509/X509CRL.java, jce/gnu/java/security/x509/X509CRLEntry.java, jce/gnu/java/security/x509/X509CRLSelectorImpl.java, jce/gnu/java/security/x509/X509CertPath.java, jce/gnu/java/security/x509/X509CertSelectorImpl.java, jce/gnu/java/security/x509/X509Certificate.java, jce/gnu/java/security/x509/ext/AuthorityKeyIdentifier.java, jce/gnu/java/security/x509/ext/BasicConstraints.java, jce/gnu/java/security/x509/ext/CRLNumber.java, jce/gnu/java/security/x509/ext/CertificatePolicies.java, jce/gnu/java/security/x509/ext/ExtendedKeyUsage.java, jce/gnu/java/security/x509/ext/Extension.java, jce/gnu/java/security/x509/ext/GeneralName.java, jce/gnu/java/security/x509/ext/GeneralNames.java, jce/gnu/java/security/x509/ext/GeneralSubtree.java, jce/gnu/java/security/x509/ext/IssuerAlternativeNames.java, jce/gnu/java/security/x509/ext/KeyUsage.java, jce/gnu/java/security/x509/ext/NameConstraints.java, jce/gnu/java/security/x509/ext/PolicyConstraint.java, jce/gnu/java/security/x509/ext/PolicyMappings.java, jce/gnu/java/security/x509/ext/PrivateKeyUsagePeriod.java, jce/gnu/java/security/x509/ext/ReasonCode.java, jce/gnu/java/security/x509/ext/SubjectAlternativeNames.java, jce/gnu/java/security/x509/ext/SubjectKeyIdentifier.java, jce/gnu/java/security/x509/ext/package.html, jce/gnu/java/security/x509/package.html, jce/gnu/javax/crypto/RSACipherImpl.java, jce/gnu/javax/crypto/assembly/Assembly.java, jce/gnu/javax/crypto/assembly/Cascade.java, jce/gnu/javax/crypto/assembly/CascadeStage.java, jce/gnu/javax/crypto/assembly/CascadeTransformer.java, jce/gnu/javax/crypto/assembly/DeflateTransformer.java, jce/gnu/javax/crypto/assembly/Direction.java, jce/gnu/javax/crypto/assembly/LoopbackTransformer.java, jce/gnu/javax/crypto/assembly/ModeStage.java, jce/gnu/javax/crypto/assembly/Operation.java, jce/gnu/javax/crypto/assembly/PaddingTransformer.java, jce/gnu/javax/crypto/assembly/Stage.java, jce/gnu/javax/crypto/assembly/Transformer.java, jce/gnu/javax/crypto/assembly/TransformerException.java, jce/gnu/javax/crypto/cipher/Anubis.java, jce/gnu/javax/crypto/cipher/BaseCipher.java, jce/gnu/javax/crypto/cipher/Blowfish.java, jce/gnu/javax/crypto/cipher/Cast5.java, jce/gnu/javax/crypto/cipher/CipherFactory.java, jce/gnu/javax/crypto/cipher/DES.java, jce/gnu/javax/crypto/cipher/IBlockCipher.java, jce/gnu/javax/crypto/cipher/IBlockCipherSpi.java, jce/gnu/javax/crypto/cipher/Khazad.java, jce/gnu/javax/crypto/cipher/NullCipher.java, jce/gnu/javax/crypto/cipher/Rijndael.java, jce/gnu/javax/crypto/cipher/Serpent.java, jce/gnu/javax/crypto/cipher/Square.java, jce/gnu/javax/crypto/cipher/TripleDES.java, jce/gnu/javax/crypto/cipher/Twofish.java, jce/gnu/javax/crypto/cipher/WeakKeyException.java, jce/gnu/javax/crypto/jce/DiffieHellmanImpl.java, jce/gnu/javax/crypto/jce/GnuCrypto.java, jce/gnu/javax/crypto/jce/GnuSasl.java, jce/gnu/javax/crypto/jce/PBKDF2SecretKeyFactory.java, jce/gnu/javax/crypto/jce/cipher/AES128KeyWrapSpi.java, jce/gnu/javax/crypto/jce/cipher/AES192KeyWrapSpi.java, jce/gnu/javax/crypto/jce/cipher/AES256KeyWrapSpi.java, jce/gnu/javax/crypto/jce/cipher/AESKeyWrapSpi.java, jce/gnu/javax/crypto/jce/cipher/AESSpi.java, jce/gnu/javax/crypto/jce/cipher/ARCFourSpi.java, jce/gnu/javax/crypto/jce/cipher/AnubisSpi.java, jce/gnu/javax/crypto/jce/cipher/BlowfishSpi.java, jce/gnu/javax/crypto/jce/cipher/Cast5Spi.java, jce/gnu/javax/crypto/jce/cipher/CipherAdapter.java, jce/gnu/javax/crypto/jce/cipher/DESSpi.java, jce/gnu/javax/crypto/jce/cipher/KeyWrappingAlgorithmAdapter.java, jce/gnu/javax/crypto/jce/cipher/KhazadSpi.java, jce/gnu/javax/crypto/jce/cipher/NullCipherSpi.java, jce/gnu/javax/crypto/jce/cipher/PBES2.java, jce/gnu/javax/crypto/jce/cipher/RijndaelSpi.java, jce/gnu/javax/crypto/jce/cipher/SerpentSpi.java, jce/gnu/javax/crypto/jce/cipher/SquareSpi.java, jce/gnu/javax/crypto/jce/cipher/TripleDESKeyWrapSpi.java, jce/gnu/javax/crypto/jce/cipher/TripleDESSpi.java, jce/gnu/javax/crypto/jce/cipher/TwofishSpi.java, jce/gnu/javax/crypto/jce/key/AnubisKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/AnubisSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/BlowfishKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/BlowfishSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/Cast5KeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/Cast5SecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/DESKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/DESSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/DESedeSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/KhazadKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/KhazadSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/RijndaelKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/RijndaelSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/SecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/SecretKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/SerpentKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/SerpentSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/SquareKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/SquareSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/key/TripleDESKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/TwofishKeyGeneratorImpl.java, jce/gnu/javax/crypto/jce/key/TwofishSecretKeyFactoryImpl.java, jce/gnu/javax/crypto/jce/keyring/GnuKeyring.java, jce/gnu/javax/crypto/jce/mac/HMacHavalSpi.java, jce/gnu/javax/crypto/jce/mac/HMacMD2Spi.java, jce/gnu/javax/crypto/jce/mac/HMacMD4Spi.java, jce/gnu/javax/crypto/jce/mac/HMacMD5Spi.java, jce/gnu/javax/crypto/jce/mac/HMacRipeMD128Spi.java, jce/gnu/javax/crypto/jce/mac/HMacRipeMD160Spi.java, jce/gnu/javax/crypto/jce/mac/HMacSHA160Spi.java, jce/gnu/javax/crypto/jce/mac/HMacSHA256Spi.java, jce/gnu/javax/crypto/jce/mac/HMacSHA384Spi.java, jce/gnu/javax/crypto/jce/mac/HMacSHA512Spi.java, jce/gnu/javax/crypto/jce/mac/HMacTigerSpi.java, jce/gnu/javax/crypto/jce/mac/HMacWhirlpoolSpi.java, jce/gnu/javax/crypto/jce/mac/MacAdapter.java, jce/gnu/javax/crypto/jce/mac/OMacAnubisImpl.java, jce/gnu/javax/crypto/jce/mac/OMacBlowfishImpl.java, jce/gnu/javax/crypto/jce/mac/OMacCast5Impl.java, jce/gnu/javax/crypto/jce/mac/OMacDESImpl.java, jce/gnu/javax/crypto/jce/mac/OMacImpl.java, jce/gnu/javax/crypto/jce/mac/OMacKhazadImpl.java, jce/gnu/javax/crypto/jce/mac/OMacRijndaelImpl.java, jce/gnu/javax/crypto/jce/mac/OMacSerpentImpl.java, jce/gnu/javax/crypto/jce/mac/OMacSquareImpl.java, jce/gnu/javax/crypto/jce/mac/OMacTripleDESImpl.java, jce/gnu/javax/crypto/jce/mac/OMacTwofishImpl.java, jce/gnu/javax/crypto/jce/mac/TMMH16Spi.java, jce/gnu/javax/crypto/jce/mac/UHash32Spi.java, jce/gnu/javax/crypto/jce/mac/UMac32Spi.java, jce/gnu/javax/crypto/jce/params/BlockCipherParameters.java, jce/gnu/javax/crypto/jce/params/DEREncodingException.java, jce/gnu/javax/crypto/jce/params/DERReader.java, jce/gnu/javax/crypto/jce/params/DERWriter.java, jce/gnu/javax/crypto/jce/prng/ARCFourRandomSpi.java, jce/gnu/javax/crypto/jce/prng/CSPRNGSpi.java, jce/gnu/javax/crypto/jce/prng/FortunaImpl.java, jce/gnu/javax/crypto/jce/prng/ICMRandomSpi.java, jce/gnu/javax/crypto/jce/prng/UMacRandomSpi.java, jce/gnu/javax/crypto/jce/sig/DHKeyFactory.java, jce/gnu/javax/crypto/jce/sig/DHKeyPairGeneratorSpi.java, jce/gnu/javax/crypto/jce/sig/DHParameters.java, jce/gnu/javax/crypto/jce/sig/DHParametersGenerator.java, jce/gnu/javax/crypto/jce/spec/BlockCipherParameterSpec.java, jce/gnu/javax/crypto/jce/spec/TMMHParameterSpec.java, jce/gnu/javax/crypto/jce/spec/UMac32ParameterSpec.java, jce/gnu/javax/crypto/key/BaseKeyAgreementParty.java, jce/gnu/javax/crypto/key/GnuPBEKey.java, jce/gnu/javax/crypto/key/GnuSecretKey.java, jce/gnu/javax/crypto/key/IKeyAgreementParty.java, jce/gnu/javax/crypto/key/IncomingMessage.java, jce/gnu/javax/crypto/key/KeyAgreementException.java, jce/gnu/javax/crypto/key/KeyAgreementFactory.java, jce/gnu/javax/crypto/key/OutgoingMessage.java, jce/gnu/javax/crypto/key/dh/DHKeyPairPKCS8Codec.java, jce/gnu/javax/crypto/key/dh/DHKeyPairRawCodec.java, jce/gnu/javax/crypto/key/dh/DHKeyPairX509Codec.java, jce/gnu/javax/crypto/key/dh/DiffieHellmanKeyAgreement.java, jce/gnu/javax/crypto/key/dh/DiffieHellmanReceiver.java, jce/gnu/javax/crypto/key/dh/DiffieHellmanSender.java, jce/gnu/javax/crypto/key/dh/ElGamalKeyAgreement.java, jce/gnu/javax/crypto/key/dh/ElGamalReceiver.java, jce/gnu/javax/crypto/key/dh/ElGamalSender.java, jce/gnu/javax/crypto/key/dh/GnuDHKey.java, jce/gnu/javax/crypto/key/dh/GnuDHKeyPairGenerator.java, jce/gnu/javax/crypto/key/dh/GnuDHPrivateKey.java, jce/gnu/javax/crypto/key/dh/GnuDHPublicKey.java, jce/gnu/javax/crypto/key/dh/RFC2631.java, jce/gnu/javax/crypto/key/srp6/SRP6Host.java, jce/gnu/javax/crypto/key/srp6/SRP6KeyAgreement.java, jce/gnu/javax/crypto/key/srp6/SRP6SaslClient.java, jce/gnu/javax/crypto/key/srp6/SRP6SaslServer.java, jce/gnu/javax/crypto/key/srp6/SRP6TLSClient.java, jce/gnu/javax/crypto/key/srp6/SRP6TLSServer.java, jce/gnu/javax/crypto/key/srp6/SRP6User.java, jce/gnu/javax/crypto/key/srp6/SRPAlgorithm.java, jce/gnu/javax/crypto/key/srp6/SRPKey.java, jce/gnu/javax/crypto/key/srp6/SRPKeyPairGenerator.java, jce/gnu/javax/crypto/key/srp6/SRPKeyPairRawCodec.java, jce/gnu/javax/crypto/key/srp6/SRPPrivateKey.java, jce/gnu/javax/crypto/key/srp6/SRPPublicKey.java, jce/gnu/javax/crypto/keyring/AuthenticatedEntry.java, jce/gnu/javax/crypto/keyring/BaseKeyring.java, jce/gnu/javax/crypto/keyring/BinaryDataEntry.java, jce/gnu/javax/crypto/keyring/CertPathEntry.java, jce/gnu/javax/crypto/keyring/CertificateEntry.java, jce/gnu/javax/crypto/keyring/CompressedEntry.java, jce/gnu/javax/crypto/keyring/EncryptedEntry.java, jce/gnu/javax/crypto/keyring/Entry.java, jce/gnu/javax/crypto/keyring/EnvelopeEntry.java, jce/gnu/javax/crypto/keyring/GnuPrivateKeyring.java, jce/gnu/javax/crypto/keyring/GnuPublicKeyring.java, jce/gnu/javax/crypto/keyring/IKeyring.java, jce/gnu/javax/crypto/keyring/IPrivateKeyring.java, jce/gnu/javax/crypto/keyring/IPublicKeyring.java, jce/gnu/javax/crypto/keyring/MalformedKeyringException.java, jce/gnu/javax/crypto/keyring/MaskableEnvelopeEntry.java, jce/gnu/javax/crypto/keyring/MeteredInputStream.java, jce/gnu/javax/crypto/keyring/PasswordAuthenticatedEntry.java, jce/gnu/javax/crypto/keyring/PasswordEncryptedEntry.java, jce/gnu/javax/crypto/keyring/PasswordProtectedEntry.java, jce/gnu/javax/crypto/keyring/PrimitiveEntry.java, jce/gnu/javax/crypto/keyring/PrivateKeyEntry.java, jce/gnu/javax/crypto/keyring/Properties.java, jce/gnu/javax/crypto/keyring/PublicKeyEntry.java, jce/gnu/javax/crypto/kwa/AESKeyWrap.java, jce/gnu/javax/crypto/kwa/BaseKeyWrappingAlgorithm.java, jce/gnu/javax/crypto/kwa/IKeyWrappingAlgorithm.java, jce/gnu/javax/crypto/kwa/KeyUnwrappingException.java, jce/gnu/javax/crypto/kwa/KeyWrappingAlgorithmFactory.java, jce/gnu/javax/crypto/kwa/TripleDESKeyWrap.java, jce/gnu/javax/crypto/mac/BaseMac.java, jce/gnu/javax/crypto/mac/HMac.java, jce/gnu/javax/crypto/mac/HMacFactory.java, jce/gnu/javax/crypto/mac/IMac.java, jce/gnu/javax/crypto/mac/MacFactory.java, jce/gnu/javax/crypto/mac/MacInputStream.java, jce/gnu/javax/crypto/mac/MacOutputStream.java, jce/gnu/javax/crypto/mac/OMAC.java, jce/gnu/javax/crypto/mac/TMMH16.java, jce/gnu/javax/crypto/mac/UHash32.java, jce/gnu/javax/crypto/mac/UMac32.java, jce/gnu/javax/crypto/mode/BaseMode.java, jce/gnu/javax/crypto/mode/CBC.java, jce/gnu/javax/crypto/mode/CFB.java, jce/gnu/javax/crypto/mode/CTR.java, jce/gnu/javax/crypto/mode/EAX.java, jce/gnu/javax/crypto/mode/ECB.java, jce/gnu/javax/crypto/mode/IAuthenticatedMode.java, jce/gnu/javax/crypto/mode/ICM.java, jce/gnu/javax/crypto/mode/IMode.java, jce/gnu/javax/crypto/mode/ModeFactory.java, jce/gnu/javax/crypto/mode/OFB.java, jce/gnu/javax/crypto/pad/BasePad.java, jce/gnu/javax/crypto/pad/IPad.java, jce/gnu/javax/crypto/pad/ISO10126.java, jce/gnu/javax/crypto/pad/PKCS1_V1_5.java, jce/gnu/javax/crypto/pad/PKCS7.java, jce/gnu/javax/crypto/pad/PadFactory.java, jce/gnu/javax/crypto/pad/SSL3.java, jce/gnu/javax/crypto/pad/TBC.java, jce/gnu/javax/crypto/pad/TLS1.java, jce/gnu/javax/crypto/pad/WrongPaddingException.java, jce/gnu/javax/crypto/prng/ARCFour.java, jce/gnu/javax/crypto/prng/CSPRNG.java, jce/gnu/javax/crypto/prng/Fortuna.java, jce/gnu/javax/crypto/prng/ICMGenerator.java, jce/gnu/javax/crypto/prng/IPBE.java, jce/gnu/javax/crypto/prng/PBKDF2.java, jce/gnu/javax/crypto/prng/PRNGFactory.java, jce/gnu/javax/crypto/prng/UMacGenerator.java, jce/gnu/javax/crypto/sasl/AuthInfo.java, jce/gnu/javax/crypto/sasl/AuthInfoProviderFactory.java, jce/gnu/javax/crypto/sasl/ClientFactory.java, jce/gnu/javax/crypto/sasl/ClientMechanism.java, jce/gnu/javax/crypto/sasl/ConfidentialityException.java, jce/gnu/javax/crypto/sasl/IAuthInfoProvider.java, jce/gnu/javax/crypto/sasl/IAuthInfoProviderFactory.java, jce/gnu/javax/crypto/sasl/IllegalMechanismStateException.java, jce/gnu/javax/crypto/sasl/InputBuffer.java, jce/gnu/javax/crypto/sasl/IntegrityException.java, jce/gnu/javax/crypto/sasl/NoSuchMechanismException.java, jce/gnu/javax/crypto/sasl/NoSuchUserException.java, jce/gnu/javax/crypto/sasl/OutputBuffer.java, jce/gnu/javax/crypto/sasl/SaslEncodingException.java, jce/gnu/javax/crypto/sasl/SaslInputStream.java, jce/gnu/javax/crypto/sasl/SaslOutputStream.java, jce/gnu/javax/crypto/sasl/SaslUtil.java, jce/gnu/javax/crypto/sasl/ServerFactory.java, jce/gnu/javax/crypto/sasl/ServerMechanism.java, jce/gnu/javax/crypto/sasl/UserAlreadyExistsException.java, jce/gnu/javax/crypto/sasl/anonymous/AnonymousClient.java, jce/gnu/javax/crypto/sasl/anonymous/AnonymousServer.java, jce/gnu/javax/crypto/sasl/anonymous/AnonymousUtil.java, jce/gnu/javax/crypto/sasl/crammd5/CramMD5AuthInfoProvider.java, jce/gnu/javax/crypto/sasl/crammd5/CramMD5Client.java, jce/gnu/javax/crypto/sasl/crammd5/CramMD5Registry.java, jce/gnu/javax/crypto/sasl/crammd5/CramMD5Server.java, jce/gnu/javax/crypto/sasl/crammd5/CramMD5Util.java, jce/gnu/javax/crypto/sasl/crammd5/PasswordFile.java, jce/gnu/javax/crypto/sasl/plain/PasswordFile.java, jce/gnu/javax/crypto/sasl/plain/PlainAuthInfoProvider.java, jce/gnu/javax/crypto/sasl/plain/PlainClient.java, jce/gnu/javax/crypto/sasl/plain/PlainRegistry.java, jce/gnu/javax/crypto/sasl/plain/PlainServer.java, jce/gnu/javax/crypto/sasl/srp/CALG.java, jce/gnu/javax/crypto/sasl/srp/ClientStore.java, jce/gnu/javax/crypto/sasl/srp/IALG.java, jce/gnu/javax/crypto/sasl/srp/KDF.java, jce/gnu/javax/crypto/sasl/srp/PasswordFile.java, jce/gnu/javax/crypto/sasl/srp/SRP.java, jce/gnu/javax/crypto/sasl/srp/SRPAuthInfoProvider.java, jce/gnu/javax/crypto/sasl/srp/SRPClient.java, jce/gnu/javax/crypto/sasl/srp/SRPRegistry.java, jce/gnu/javax/crypto/sasl/srp/SRPServer.java, jce/gnu/javax/crypto/sasl/srp/SecurityContext.java, jce/gnu/javax/crypto/sasl/srp/ServerStore.java, jce/gnu/javax/crypto/sasl/srp/StoreEntry.java, jce/gnu/javax/security/auth/Password.java, jce/gnu/javax/security/auth/callback/AbstractCallbackHandler.java, jce/gnu/javax/security/auth/callback/CertificateCallback.java, jce/gnu/javax/security/auth/callback/ConsoleCallbackHandler.java, jce/gnu/javax/security/auth/callback/DefaultCallbackHandler.java, jce/gnu/javax/security/auth/callback/GnuCallbacks.java, jce/gnu/javax/security/auth/login/ConfigFileParser.java, jce/gnu/javax/security/auth/login/ConfigFileTokenizer.java, jce/gnu/javax/security/auth/login/GnuConfiguration.java, lib/rt/gnu/java/security/provider/Gnu.java, rt/gnu/java/io/Base64InputStream.java, rt/gnu/java/security/provider/Gnu.java, rt/java/util/Timer.java, rt/javax/security/auth/callback/ChoiceCallback.java, rt/javax/security/auth/callback/ConfirmationCallback.java, rt/javax/security/auth/callback/LanguageCallback.java, rt/javax/security/auth/callback/NameCallback.java, rt/javax/security/auth/callback/TextInputCallback.java, rt/javax/security/auth/callback/TextOutputCallback.java, rt/javax/security/sasl/AuthenticationException.java, rt/javax/security/sasl/Sasl.java, rt/javax/security/sasl/SaslClient.java, rt/javax/security/sasl/SaslClientFactory.java, rt/javax/security/sasl/SaslException.java, rt/javax/security/sasl/SaslServer.java, rt/javax/security/sasl/SaslServerFactory.java: New files 2007-06-21 Andrew Haley * Makefile (ICEDTEA_PATCHES): Add icedtea-debuginfo.patch. patches/icedtea-debuginfo.patch: New file. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From gbenson at redhat.com Tue Jun 26 15:01:09 2007 From: gbenson at redhat.com (Gary Benson) Date: Tue, 26 Jun 2007 18:01:09 -0400 Subject: IcedTea crypto changes, etc. In-Reply-To: <18049.18265.254754.808797@zebedee.pink> References: <18049.18265.254754.808797@zebedee.pink> Message-ID: <20070626220109.GA31257@devserv.devel.redhat.com> Andrew Haley wrote: > I've also committed a patch that forces debug info to be generated, > regradless of the optimization level. How does this tie in with optimization? Most of Hotspot for example is compiled with -O3. Cheers, Gary From aph at redhat.com Wed Jun 27 03:13:22 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jun 2007 11:13:22 +0100 Subject: IcedTea crypto changes, etc. In-Reply-To: <20070626220109.GA31257@devserv.devel.redhat.com> References: <18049.18265.254754.808797@zebedee.pink> <20070626220109.GA31257@devserv.devel.redhat.com> Message-ID: <18050.14402.544836.614896@zebedee.pink> Gary Benson writes: > Andrew Haley wrote: > > I've also committed a patch that forces debug info to be generated, > > regradless of the optimization level. > > How does this tie in with optimization? Most of Hotspot for example > is compiled with -O3. I guess I don't understand the question. Debug info is still generated at all optimization levels, and always has been. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From gbenson at redhat.com Wed Jun 27 03:55:26 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 27 Jun 2007 06:55:26 -0400 Subject: IcedTea crypto changes, etc. In-Reply-To: <18050.14402.544836.614896@zebedee.pink> References: <18049.18265.254754.808797@zebedee.pink> <20070626220109.GA31257@devserv.devel.redhat.com> <18050.14402.544836.614896@zebedee.pink> Message-ID: <20070627105526.GA1498@devserv.devel.redhat.com> Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > I've also committed a patch that forces debug info to be > > > generated, regradless of the optimization level. > > > > How does this tie in with optimization? Most of Hotspot for > > example is compiled with -O3. > > I guess I don't understand the question. Debug info is still > generated at all optimization levels, and always has been. Does the optimization not make it really hard to debug though? Cheers, Gary From aph at redhat.com Wed Jun 27 04:01:24 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jun 2007 12:01:24 +0100 Subject: IcedTea crypto changes, etc. In-Reply-To: <20070627105526.GA1498@devserv.devel.redhat.com> References: <18049.18265.254754.808797@zebedee.pink> <20070626220109.GA31257@devserv.devel.redhat.com> <18050.14402.544836.614896@zebedee.pink> <20070627105526.GA1498@devserv.devel.redhat.com> Message-ID: <18050.17284.96232.382457@zebedee.pink> Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Andrew Haley wrote: > > > > I've also committed a patch that forces debug info to be > > > > generated, regradless of the optimization level. > > > > > > How does this tie in with optimization? Most of Hotspot for > > > example is compiled with -O3. > > > > I guess I don't understand the question. Debug info is still > > generated at all optimization levels, and always has been. > > Does the optimization not make it really hard to debug though? Yes, of course. We always generate it, though, because without debug info it's even harder. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From theuserbl at hotmail.com Thu Jun 28 03:55:13 2007 From: theuserbl at hotmail.com (theUser BL) Date: Thu, 28 Jun 2007 10:55:13 +0000 Subject: What is IcedTea? Message-ID: Hi! What is IcedTea? There are two possibilites: a) like GNU Classpath extending only the closed-sourced OpenJDK-libraries with GNU Classpath parts. And like GNU Classpath it is then only a sourcecode-project. There are no binaries. And like GNU Classpath this libraries are created for gcj, kaffe, jamvm, cacao, ikvm, etc. b) like Suns Java you also create also binaries of IcedTea, where the VM is Suns HotSpot-VM. And then IcedTea ist mostly like Suns Java. Only the non-OpenSource-parts of OpenJDK with some other graphical parts http://fkung.wordpress.com/2007/06/25/icedtea-graphics/ will be taken from GNU Classpath. But it seems, that a) is right http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions#What_is_IcedTea.3F because it is mostly created for gcj and the developer are RedHat-developer (people behind gcj). So, is it right, that a) is right? Greatings theuserbl _________________________________________________________________ Haben Spinnen Ohren? Finden Sie es heraus ? mit dem MSN Suche Superquiz via http://www.msn-superquiz.de Jetzt mitmachen und gewinnen! From aph at redhat.com Thu Jun 28 04:04:11 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Jun 2007 12:04:11 +0100 Subject: What is IcedTea? In-Reply-To: References: Message-ID: <18051.38315.205217.724102@zebedee.pink> theUser BL writes: > What is IcedTea? You could always try readong the web site. > There are two possibilites: > > a) like GNU Classpath > extending only the closed-sourced OpenJDK-libraries with GNU Classpath > parts. And like GNU Classpath it is then only a sourcecode-project. There > are no binaries. And like GNU Classpath this libraries are created for gcj, > kaffe, jamvm, cacao, ikvm, etc. > > b) like Suns Java > you also create also binaries of IcedTea, where the VM is Suns HotSpot-VM. > And then IcedTea ist mostly like Suns Java. Only the non-OpenSource-parts of > OpenJDK with some other graphical parts > http://fkung.wordpress.com/2007/06/25/icedtea-graphics/ > will be taken from GNU Classpath. The FAQ says: A full binary RPM is not possible at the moment due to some questionable licensing headers in the OpenJDK (likely oversights when preparing for the OpenJDK release; we hope these will be resolved soon). > But it seems, that a) is right > http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions#What_is_IcedTea.3F > because it is mostly created for gcj No, it isn't. From where did you get the idea that IcedTea is created for gcj? > and the developer are RedHat-developer (people behind gcj). Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From casey.s.marshall at gmail.com Sat Jun 30 15:23:22 2007 From: casey.s.marshall at gmail.com (Casey Marshall) Date: Sat, 30 Jun 2007 15:23:22 -0700 Subject: [icedtea] javac is not javap / -1.5 option Message-ID: <25BE1E82-1D5A-4D1A-8AFD-56D812EA0A27@gmail.com> Hi. I can't seem to register with icedtea's bugzilla, so I'm sending this message here, so people involved my see it. I've been trying to get icedtea compiled on Ubuntu Edgy, and noticed so far that the Makefile copies 'javac' to 'bootstrap/jdk1.6.0/bin/ javap', not the 'javap' script that's included. Also, it uses the option -1.5 when compiling the CompileProperties program, which won't work for javac. I *think* "-source 1.5 -target 1.5" will work here instead, right? Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-makefile.patch Type: application/octet-stream Size: 1019 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070630/1b7d9ec2/icedtea-makefile.patch -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070630/1b7d9ec2/smime.p7s From betelgeuse at gentoo.org Sat Jun 30 15:39:48 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Sun, 01 Jul 2007 01:39:48 +0300 Subject: Gentoo OpenJDK patchset Message-ID: <4686DBB4.9050907@gentoo.org> This might interest others so here is the collection of patches I currently apply: lesstif: Makes it possible to compile against both lesstif and openmotif external-zlib: Use system installed copy of zlib external-jpeg-splash: Part of patching OpenJDK to use system libjpeg but haven't had the time to test whether the code work so not activiting the feature yet. external-giflib: Use system installed copy of giflib external-libpng: Use system installed copy of libpng noundef, dymanic-libstdc++: Never link libstdc++ statically gettimeofday-declaration: Silence some gcc warnings j2see-cxxflags, hotspot-cflags: Allow user set CFLAGS/CXXFLAGS to take precedence over defaults cpuid-fomit-frame-pointer: Makes the cpuid code work when compiled with -fomit-frame-pointer icedtea-text-relocations: Hardened kernels for example can turn of support for text-relocations. execstack: Apply proper markings to asm files about GNU stack. external-libXinerama: Use system copy of libXinerama tempname-free: Bug fix from Diego fontconfig-directlink: Make it possible to directly linking to fontconfig instead of dlopening the shard library. b14-gcc4: Make build 14 build with gcc4. All these patches should be found submitted to the various OpenJDK mailing lists. (Well my own ones would need me to motivate myself enough to sign the SCA). Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070701/2b9e6af9/signature.asc From flameeyes at gmail.com Sat Jun 30 15:45:51 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Sun, 1 Jul 2007 00:45:51 +0200 Subject: Gentoo OpenJDK patchset References: <4686DBB4.9050907@gentoo.org> Message-ID: <20070701004551.4fb620c0@enterprise.flameeyes.is-a-geek.org> On Sun, 01 Jul 2007 01:39:48 +0300 Petteri R?ty wrote: > external-jpeg-splash: Part of patching OpenJDK to use system libjpeg but > haven't had the time to test whether the code work so not activiting the > feature yet. As far as I can see this works just as fine as -giflib and -libpng; there's a second part that uses external jpeg for the jni extension, but that will change the behaviour so for now it's unsafe. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070701/741324dd/signature.asc