From kgallowa at redhat.com Wed Aug 1 06:53:32 2007 From: kgallowa at redhat.com (Kyle Galloway) Date: Wed, 01 Aug 2007 09:53:32 -0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46B049A2.1040706@sun.com> References: <46AA381D.3050703@redhat.com> <46AAFDAC.9090405@sun.com> <46ADEA37.4060201@redhat.com> <46AE09F2.9070605@redhat.com> <46AE497E.9030702@redhat.com> <46AF3F51.2050908@redhat.com> <46B049A2.1040706@sun.com> Message-ID: <46B0905C.9040805@redhat.com> Hi all, I responded to Artem directly, but I'm going to post my response here for those that are interested. I am using Gnome 2.18.3 running on Fedora 7. Metacity is my window manager, and I have tried "metacity --replace" with no effects. I am not running any composite extensions, or even a proprietary video driver (I use VESA and have an ATI video card). The latest binary JDKs do not cause this issue, it is only seen with OpenJDK/IcedTea (although it has been fixed in IcedTea 1.2 released today). I have also enclosed a screenshot of a simple awt app that appears correctly on 32-bit systems, but, as can be seen, is missing window decorations on our x86_64 machines. Hope that helps. Thanks, Kyle Artem Ananiev wrote: > Hi, Francis, all, > > the diffs in XPanelPeer are a part of the fix for 6567564 (Canvas's > graphics config does not change when moved across monitors, Linux). > The fix also includes some changes in XPanelPeer sub/super classes, > and I think it's not a right thing to revert the changes from > XPanelPeer only. > > At the same time, I still can't reproduce the described problem with > window decorations on my desktop. I have already written to Kyle > privately about the required system configuration (32/64 bit, window > manager, window manager version, etc.) but haven't received any reply. > Until this information is available, we can't proceed with the bug. > > Thanks, > > Artem > > Francis Kung wrote: >> Hi everyone, >> >>>>>> Could you tell what window manager you're using when you observe >>>>>> this behavior? Did you try running under Metacity? Is the bug >>>>>> still reproducible then? >>>>> >>>>> This was tested under Metacity and it is still a bug. >>>> Sun accepted this bug this morning as bug 6586752. >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6586752 >>> >>> >>> This problem was narrowed down to a regression between b14 and b15. >>> The patch causing the problem has been uploaded here: >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=37 >>> >>> Though, we are still trying to determine what part of this patch is >>> the cause. >> >> I've found the specific area that causes this regression; it was the >> change in XPanelPeer.java. I've attached the relevant b14->b15 diff; >> if you revert that patch then window decorations appear once again. >> >> Regards, >> Francis >> -------------- next part -------------- A non-text attachment was scrubbed... Name: window_decs.png Type: image/png Size: 22857 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070801/1bb9ecb8/window_decs.png From Artem.Ananiev at Sun.COM Wed Aug 1 01:51:46 2007 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Wed, 01 Aug 2007 12:51:46 +0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46AF3F51.2050908@redhat.com> References: <46AA381D.3050703@redhat.com> <46AAFDAC.9090405@sun.com> <46ADEA37.4060201@redhat.com> <46AE09F2.9070605@redhat.com> <46AE497E.9030702@redhat.com> <46AF3F51.2050908@redhat.com> Message-ID: <46B049A2.1040706@sun.com> Hi, Francis, all, the diffs in XPanelPeer are a part of the fix for 6567564 (Canvas's graphics config does not change when moved across monitors, Linux). The fix also includes some changes in XPanelPeer sub/super classes, and I think it's not a right thing to revert the changes from XPanelPeer only. At the same time, I still can't reproduce the described problem with window decorations on my desktop. I have already written to Kyle privately about the required system configuration (32/64 bit, window manager, window manager version, etc.) but haven't received any reply. Until this information is available, we can't proceed with the bug. Thanks, Artem Francis Kung wrote: > Hi everyone, > >>>>> Could you tell what window manager you're using when you observe >>>>> this behavior? Did you try running under Metacity? Is the bug still >>>>> reproducible then? >>>> >>>> This was tested under Metacity and it is still a bug. >>> Sun accepted this bug this morning as bug 6586752. >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6586752 >> >> >> This problem was narrowed down to a regression between b14 and b15. >> The patch causing the problem has been uploaded here: >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=37 >> >> Though, we are still trying to determine what part of this patch is >> the cause. > > I've found the specific area that causes this regression; it was the > change in XPanelPeer.java. I've attached the relevant b14->b15 diff; if > you revert that patch then window decorations appear once again. > > Regards, > Francis > From fkung at redhat.com Thu Aug 2 11:02:33 2007 From: fkung at redhat.com (Francis Kung) Date: Thu, 02 Aug 2007 14:02:33 -0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46B0905C.9040805@redhat.com> References: <46AA381D.3050703@redhat.com> <46AAFDAC.9090405@sun.com> <46ADEA37.4060201@redhat.com> <46AE09F2.9070605@redhat.com> <46AE497E.9030702@redhat.com> <46AF3F51.2050908@redhat.com> <46B049A2.1040706@sun.com> <46B0905C.9040805@redhat.com> Message-ID: <46B21C39.4030602@redhat.com> Hi, It looks like I was a bit premature in blaming a patch for this bug; it turns out to be a much more subtle problem with the build system (and completely unrelated to XPanelPeer, which had the unfortunate position of being in the wrong place at the wrong time =) ). My extreme apologies for heading in the wrong direction with this. The real problem here is between lesstif and openmotif. The PropMwmHints struct has a different size, and thus lesstif is incompatible with OpenJDK on 64-bit architectures. This also explains why the Sun developers weren't seeing this (I assume they use openmotif), and a stray ALT_MOTIF_DIR setting in my build environment, left-over from a b14 build, led me on a wild goose chase last week. Regards, Francis From thunderaxiom at gmail.com Fri Aug 3 13:31:45 2007 From: thunderaxiom at gmail.com (=?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?=) Date: Fri, 03 Aug 2007 22:31:45 +0200 Subject: Icedtea 1.2, needed yum line Message-ID: <46B390B1.4050408@gmail.com> Hi. I played today with building icedtea on a freshly installed Fedora 7 vmware instance. I needed some additional packages installed than mentioned in the release docs. The yum command that got icedtea to build, was: yum -y install /usr/bin/ecj mercurial cups-devel lesstif-devel libXp-devel libXtst-devel libXi-devel xalan-j2 xerces-j2 libXt-devel libgcj freetype-devel gcc gcc-c++ wget java-1.5.0-gcj-devel alsa-lib-devel Hopefully this helps somebody :) -- Thorbj?rn From fkung at redhat.com Fri Aug 3 14:00:59 2007 From: fkung at redhat.com (Francis Kung) Date: Fri, 03 Aug 2007 17:00:59 -0400 Subject: IcedTea updated to b17 Message-ID: <46B3978B.5040903@redhat.com> IcedTea mercurial tip has now been updated to the OpenJDK b17 release. Regards, Francis From mcepl at redhat.com Fri Aug 3 14:10:09 2007 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 03 Aug 2007 23:10:09 +0200 Subject: build problem Message-ID: Trying to build java-1.7.0-icedtea-1.7.0.0-0.9.b16.nosrc.rpm on Fedora 7 and this is what I get for --target=i586 (x86_64 builts without a problem): IcedTea re-served: openjdk/control/build/linux-amd64 + pushd java-access-bridge-1.18.0 ~/rpm/BUILD/icedtea-1.2/java-access-bridge-1.18.0 ~/rpm/BUILD/icedtea-1.2 ++ pwd + export JAVA_HOME=/home/matej/rpm/BUILD/icedtea-1.2/java-access-bridge-1.18.0/../openjdk/control/build/linux-i586/j2sdk-image + JAVA_HOME=/home/matej/rpm/BUILD/icedtea-1.2/java-access-bridge-1.18.0/../openjdk/control/build/linux-i586/j2sdk-image + export PATH=/home/matej/rpm/BUILD/icedtea-1.2/java-access-bridge-1.18.0/../openjdk/control/build/linux-i586/j2sdk-image/bin:/home/matej/.bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin: + PATH=/home/matej/rpm/BUILD/icedtea-1.2/java-access-bridge-1.18.0/../openjdk/control/build/linux-i586/j2sdk-image/bin:/home/matej/.bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin: + ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for "/home/matej/rpm/BUILD/icedtea-1.2/java-access-bridge-1.18.0/../openjdk/control/build/linux-i586/j2sdk-image/bin/java"... no configure: error: Java 1.4 or later is required to build java-access-bridge error: ?patn? n?vratov? k?d z /var/tmp/rpm-tmp.78074 (%build) chyby sestaven? RPM: ?patn? n?vratov? k?d z /var/tmp/rpm-tmp.78074 (%build) [matej at hubmaier rpm]$ Any ideas what's wrong? Matej From fkung at redhat.com Fri Aug 3 14:19:51 2007 From: fkung at redhat.com (Francis Kung) Date: Fri, 03 Aug 2007 17:19:51 -0400 Subject: IcedTea updated to b17 In-Reply-To: <46B3978B.5040903@redhat.com> References: <46B3978B.5040903@redhat.com> Message-ID: <46B39BF7.8030603@redhat.com> > IcedTea mercurial tip has now been updated to the OpenJDK b17 release. To follow up a bit, there are some font rendering artifacts after this push. I've discarded the font work that Kyle and myself did and switched to the Sun freetype fonts in b17 (the native implementations are very similar). I suspect the artifacts are caused by the icedtea-antialias patch (specifically, the modifications to FontStrikeDesc.java). The intent was to change the text-antialias default to "on", as that looks much better with Freetype, but it seems to be causing problems with the new font stuff. Removing that part of the patch and rebuilding may fix the rendering problems, but I won't have a chance to test it until next week. Cheers, Francis From keiths at redhat.com Wed Aug 8 07:05:09 2007 From: keiths at redhat.com (Keith Seitz) Date: Wed, 08 Aug 2007 07:05:09 -0700 Subject: Using system tzdata Message-ID: <46B9CD95.800@redhat.com> Hi, The JRE contains pre-compiled timezone information files. As an OS vendor, Red Hat would prefer not to respin or repackage the JRE every time tzdata changes somewhere in the world. In order to facilitate this, we're in the process of modifying our tzdata package to include pre-compiled zoneinfo files for use with JREs. I have created a patch to the openjdk JRE that would optionally use these files instead of the pre-packaged ones in the JRE. We would really like to solicit advice/comments about how to get something like this accepted upstream so that other distros can use this. Keith -------------- next part -------------- A non-text attachment was scrubbed... Name: use-system-tzdata.patch Type: text/x-patch Size: 1657 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070808/14a98ce2/use-system-tzdata.patch From aph at redhat.com Wed Aug 8 07:28:30 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Aug 2007 15:28:30 +0100 Subject: Using system tzdata In-Reply-To: <46B9CD95.800@redhat.com> References: <46B9CD95.800@redhat.com> Message-ID: <18105.54030.281185.384087@zebedee.pink> Keith Seitz writes: > The JRE contains pre-compiled timezone information files. As an OS > vendor, Red Hat would prefer not to respin or repackage the JRE > every time tzdata changes somewhere in the world. > > In order to facilitate this, we're in the process of modifying our > tzdata package to include pre-compiled zoneinfo files for use with > JREs. I have created a patch to the openjdk JRE that would > optionally use these files instead of the pre-packaged ones in the > JRE. > > We would really like to solicit advice/comments about how to get > something like this accepted upstream so that other distros can use > this. I'd appreciate it if someone could tell us which of the many lists @java.net would be the best place for this discussion. TVM, Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From David.Herron at Sun.COM Wed Aug 8 07:43:20 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 08 Aug 2007 07:43:20 -0700 Subject: Using system tzdata In-Reply-To: <46B9CD95.800@redhat.com> References: <46B9CD95.800@redhat.com> Message-ID: <46B9D688.50106@sun.com> I believe this mailing list http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev is the appropriate team to bring this to. This project list is focused on packaging It'll help if you can reference a bug (or file a new one if necessary). I did a little bit of looking and didn't find anything, but this appears to be interesting too. There must be an existing bug report on this, as use of system timezone data is clearly desirable. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628 Keith Seitz wrote: > Hi, > > The JRE contains pre-compiled timezone information files. As an OS > vendor, Red Hat would prefer not to respin or repackage the JRE every > time tzdata changes somewhere in the world. > > In order to facilitate this, we're in the process of modifying our > tzdata package to include pre-compiled zoneinfo files for use with > JREs. I have created a patch to the openjdk JRE that would optionally > use these files instead of the pre-packaged ones in the JRE. > > We would really like to solicit advice/comments about how to get > something like this accepted upstream so that other distros can use this. > > Keith > ------------------------------------------------------------------------ > > --- openjdk/hotspot/src/os/linux/vm/os_linux.cpp.keiths 2007-08-01 10:21:19.000000000 -0700 > +++ openjdk/hotspot/src/os/linux/vm/os_linux.cpp 2007-08-01 10:21:36.000000000 -0700 > @@ -376,6 +376,10 @@ > } > } > > + // Use the system zoneinfo files, if present > + SystemProperty* sp = Arguments::system_properties(); > + Arguments::PropertyList_add (&sp, > + "java.zoneinfo.dir", "/usr/share/zoneinfo/java"); > #undef malloc > #undef getenv > #undef EXTENSIONS_DIR > --- openjdk/j2se/src/share/classes/sun/util/calendar/ZoneInfoFile.java.keiths 2007-08-01 12:31:03.000000000 -0700 > +++ openjdk/j2se/src/share/classes/sun/util/calendar/ZoneInfoFile.java 2007-08-01 12:29:44.000000000 -0700 > @@ -1021,10 +1021,18 @@ > byte[] buffer = null; > > try { > - String homeDir = (String) AccessController.doPrivileged( > + String zi_dir = (String) AccessController.doPrivileged( > + new sun.security.action.GetPropertyAction("java.zoneinfo.dir")); > + File dir = null; > + if (zi_dir != null) > + dir = new File(zi_dir); > + if (dir == null || !dir.exists() || !dir.isDirectory()) { > + String homeDir = (String) AccessController.doPrivileged( > new sun.security.action.GetPropertyAction("java.home")); > - final String fname = homeDir + File.separator + "lib" + File.separator > - + "zi" + File.separator + fileName; > + zi_dir = homeDir + File.separator + "lib" + File.separator > + + "zi"; > + } > + final String fname = zi_dir + File.separator + fileName; > buffer = (byte[]) AccessController.doPrivileged(new PrivilegedExceptionAction() { > public Object run() throws IOException { > File file = new File(fname); > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070808/ae3170a3/attachment.html From David.Herron at Sun.COM Wed Aug 8 07:50:56 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 08 Aug 2007 07:50:56 -0700 Subject: Using system tzdata In-Reply-To: <18105.54030.281185.384087@zebedee.pink> References: <46B9CD95.800@redhat.com> <18105.54030.281185.384087@zebedee.pink> Message-ID: <46B9D850.6010708@sun.com> Andrew Haley wrote: > I'd appreciate it if someone could tell us which of the many lists > @java.net would be the best place for this discussion. > > TVM, > Andrew. The lists in question are not @java.net but @openjdk.java.net They are listed here: http://mail.openjdk.java.net/mailman/listinfo I know the descriptions on that page don't give really good guidance, but I think by process of elimination you can rule out many of them. That's the process I followed a minute ago in my other reply, and I ended up with core-libs-dev The other way to discover the appropriate mailing list is a bit circuitous. Each group advertises on the group home page the scope / area covered by that group. The core-libs group lists *TimeZone*.java as being in their scope of responsibility http://openjdk.java.net/groups/core-libs/ Cheers, - David Herron From fkung at redhat.com Wed Aug 8 14:24:33 2007 From: fkung at redhat.com (Francis Kung) Date: Wed, 08 Aug 2007 17:24:33 -0400 Subject: Icedtea 1.2, needed yum line In-Reply-To: <46B390B1.4050408@gmail.com> References: <46B390B1.4050408@gmail.com> Message-ID: <46BA3491.1020009@redhat.com> Hi Thorbj?rn, > I needed some additional packages installed than mentioned in the > release docs. The yum command that got icedtea to build, was: > > yum -y install /usr/bin/ecj mercurial cups-devel lesstif-devel > libXp-devel libXtst-devel libXi-devel xalan-j2 xerces-j2 libXt-devel > libgcj freetype-devel gcc gcc-c++ wget java-1.5.0-gcj-devel alsa-lib-devel > > Hopefully this helps somebody :) Thanks - I've updated the INSTALL file and wiki with this information. Regards, Francis From aph at redhat.com Thu Aug 9 06:03:40 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Aug 2007 14:03:40 +0100 Subject: Fix DiffieHellmanImpl.java Message-ID: <18107.4268.539387.155988@zebedee.pink> I pushed this patch to IcedTea: it fixes SSL failures we discovered when running the JBoss testsuite. Andrew. -------------- next part -------------- An embedded message was scrubbed... From: Andrew Haley Subject: Fix DiffieHellmanImpl.java Date: Fri, 3 Aug 2007 18:19:07 +0100 Size: 4995 Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070809/2055ec91/attachment.nws -------------- next part -------------- -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From plugwash at p10link.net Fri Aug 10 14:02:41 2007 From: plugwash at p10link.net (peter green) Date: Fri, 10 Aug 2007 22:02:41 +0100 Subject: attenpt at building icedtea on debian sid Message-ID: <46BCD271.3040500@p10link.net> I updated the sid chroot in which I tried this before starting I installed the following packages using apt to try and satisfy the build requirements ecj mercurial libcupsys2-dev lesstif2-dev libXp-dev libXtst-dev libXi-dev libxalan2-java libxerces2-java libXt-dev libgcj-bc libfreetype6-dev gcc g++ wget gcj libalsaplayer-dev which I got from the combination of the yum command on the icedtea wiki and a bit of educated guesswork. I checked out the code for mercurial by following the instructions on the front page of the icedtea wiki I ran ./configure , it gave an error about not being able to find unzip so I installed the zip and unzip packages. I ran it again and it said checking for libgcj-4.1.2.jar... no configure: error: "A LIBGCJ jar was not found." A package contents search for that file found nothing but removing the .2 from the name found the package libgcj7-jar. I discovered this was already installed so I added a symlink with ln -s /usr/share/java/libgcj-4.1.jar /usr/share/java/libgcj-4.1.2.jar Once again i reran ./configure and got the error checking for alsa/asoundlib.h... no configure: error: "ALSA headers were not found - try installing alsa-lib-devel." A package contents search revealed the header was in libasound2-dev. I installed this and reran configure. Finally it passed. I then ran make bootstrap, this proceeded to download openjdk and attempted to build it. After some time I got the following error /usr/bin/ecj -nowarn -g -d ../lib/rt -bootclasspath '' -source 1.6 \ -sourcepath /icedtea/openjdk/j2se/src/share/classes:/icedtea/openjdk/j2se/src/solaris/classes:../generated:../jce \ @../rt-classes Annotation processing got disabled, since it requires a 1.6 compliant JVM ---------- 1. ERROR in /icedtea/openjdk/j2se/src/share/classes/java/awt/Component.java (at line 5647) transient EventQueueItem[] eventCache; ^^^^^^^^^^^^^^ EventQueueItem cannot be resolved to a type ---------- 1 problem (1 error)make: *** [rt-compile-classes] Error 255 debian:/icedtea# any Idea what the problem might be? From langel at redhat.com Tue Aug 14 06:32:02 2007 From: langel at redhat.com (Lillian Angel) Date: Tue, 14 Aug 2007 09:32:02 -0400 Subject: IcedTea Fonts In-Reply-To: <469E7EF5.9000707@redhat.com> References: <469E7094.7000602@redhat.com> <1184791673.20107.10.camel@dijkstra.wildebeest.org> <469E7EF5.9000707@redhat.com> Message-ID: <46C1AED2.1050905@redhat.com> Francis Kung wrote: > Hi Mark, > >> I saw you also opened bug >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=45 >> "Graphics will not work after a regular build; a full bootstrap build is >> required." Since that doubles the build time that is somewhat >> unfortunate. What is causing this? > > Unfortunately, some graphics-related files don't get generated properly > when bootstrapping with gij - in fact, gij throws exceptions when trying > to generate those files. Hence we need to do a full bootstrap in order > to get these files generated. Looks like Francis has fixed this in the repo. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=45 Lillian From matthew.flaschen at gatech.edu Tue Aug 14 13:14:14 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Tue, 14 Aug 2007 16:14:14 -0400 Subject: Build fails with "javax.script.Wrapper cannot be resolved" Message-ID: <46C20D16.5020201@gatech.edu> On Fedora 7, the latest checkout fails to build with: ---------- 1. ERROR in /home/matthew/Code/Java/IcedTea/hg/openjdk/j2se/src/share/classes/com/sun/script/javascript/JavaAdapter.java (at line 30) import javax.script.Wrapper; ^^^^^^^^^^^^^^^^^^^^ The import javax.script.Wrapper cannot be resolved ---------- Matt Flaschen From langel at redhat.com Tue Aug 14 13:30:37 2007 From: langel at redhat.com (Lillian Angel) Date: Tue, 14 Aug 2007 16:30:37 -0400 Subject: Build fails with "javax.script.Wrapper cannot be resolved" In-Reply-To: <46C20D16.5020201@gatech.edu> References: <46C20D16.5020201@gatech.edu> Message-ID: <46C210ED.3030304@redhat.com> Matthew Flaschen wrote: > On Fedora 7, the latest checkout fails to build with: > > ---------- > 1. ERROR in > /home/matthew/Code/Java/IcedTea/hg/openjdk/j2se/src/share/classes/com/sun/script/javascript/JavaAdapter.java > (at line 30) > import javax.script.Wrapper; > ^^^^^^^^^^^^^^^^^^^^ > The import javax.script.Wrapper cannot be resolved Do a "make clobber". There was a change to this today, which changes a patch to the OpenJDK sources. You still have that patch applied. Lillian From matthew.flaschen at gatech.edu Tue Aug 14 15:43:32 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Tue, 14 Aug 2007 18:43:32 -0400 Subject: Build fails with "javax.script.Wrapper cannot be resolved" In-Reply-To: <46C210ED.3030304@redhat.com> References: <46C20D16.5020201@gatech.edu> <46C210ED.3030304@redhat.com> Message-ID: <46C23014.1040503@gatech.edu> Lillian Angel wrote: >> 1. ERROR in >> /home/matthew/Code/Java/IcedTea/hg/openjdk/j2se/src/share/classes/com/sun/script/javascript/JavaAdapter.java >> >> (at line 30) >> import javax.script.Wrapper; >> ^^^^^^^^^^^^^^^^^^^^ >> The import javax.script.Wrapper cannot be resolved > > Do a "make clobber". There was a change to this today, which changes a > patch to the OpenJDK sources. You still have that patch applied. Thanks. I removed the openjdk zip files and ran: make clean make clobber make , but still got the same error. Matt Flaschen From langel at redhat.com Wed Aug 15 06:06:06 2007 From: langel at redhat.com (Lillian Angel) Date: Wed, 15 Aug 2007 09:06:06 -0400 Subject: Build fails with "javax.script.Wrapper cannot be resolved" In-Reply-To: <46C23014.1040503@gatech.edu> References: <46C20D16.5020201@gatech.edu> <46C210ED.3030304@redhat.com> <46C23014.1040503@gatech.edu> Message-ID: <46C2FA3E.9010607@redhat.com> Matthew Flaschen wrote: > Lillian Angel wrote: > > >>> 1. ERROR in >>> /home/matthew/Code/Java/IcedTea/hg/openjdk/j2se/src/share/classes/com/sun/script/javascript/JavaAdapter.java >>> >>> (at line 30) >>> import javax.script.Wrapper; >>> ^^^^^^^^^^^^^^^^^^^^ >>> The import javax.script.Wrapper cannot be resolved >>> >> Do a "make clobber". There was a change to this today, which changes a >> patch to the OpenJDK sources. You still have that patch applied. >> > > Thanks. I removed the openjdk zip files and ran: > > make clean > make clobber > make > > , but still got the same error. Ah sorry, yes that JavaAdapter file would still exist with the changes after a make clobber. I meant to say "make distclean"- this removes the openjdk sources completely. Lillian From matthew.flaschen at gatech.edu Wed Aug 15 19:54:11 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Wed, 15 Aug 2007 22:54:11 -0400 Subject: Build fails with "javax.script.Wrapper cannot be resolved" In-Reply-To: <46C2FA3E.9010607@redhat.com> References: <46C20D16.5020201@gatech.edu> <46C210ED.3030304@redhat.com> <46C23014.1040503@gatech.edu> <46C2FA3E.9010607@redhat.com> Message-ID: <46C3BC53.80002@gatech.edu> Lillian Angel wrote: > Ah sorry, yes that JavaAdapter file would still exist with the changes > after a make clobber. I meant to say "make distclean"- this removes the > openjdk sources completely. Thanks. It's currently building. Matt Flaschen From fitzsim at redhat.com Sun Aug 19 18:43:47 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sun, 19 Aug 2007 21:43:47 -0400 Subject: Fix for libpng undefined symbol Message-ID: <46C8F1D3.1070006@redhat.com> Hi, With the update to b18 the build was failing on my x86_64 machine with an undefined symbol, png_mmx_support, in libpng. The problem was exposed by the fix for: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6577886 specifically this line: +LDFLAGS_DEFS_OPTION = -z defs which causes the linker to disallow undefined symbols. The failure will happen on systems that support MMX: $ echo | cpp -dM | grep __MMX__ #define __MMX__ 1 That macro indirectly causes the default png_mmx_support definition to be ifdef'd out. For now I've applied this workaround: --- openjdk.orig/j2se/make/sun/splashscreen/Makefile 2007-08-19 15:04:21.000000000 -0400 +++ openjdk/j2se/make/sun/splashscreen/Makefile 2007-08-19 15:08:45.000000000 -0400 @@ -59,7 +59,7 @@ # C Flags # -CFLAGS += -DSPLASHSCREEN +CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE ifneq ($(PLATFORM), windows) CFLAGS += -DWITH_X11 to disable libpng's MMX-specific functions (optimized C implementations are used instead). A better solution would be to conditionally compile pnggccrd.c, which defines png_mmx_support, when __MMX__ is defined. pnggccrd.c would have to be patched to fix png_squelch_warnings compile errors. Tom From j.w.r.degoede at hhs.nl Mon Aug 20 00:48:51 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Aug 2007 09:48:51 +0200 Subject: Fix for libpng undefined symbol In-Reply-To: <46C8F1D3.1070006@redhat.com> References: <46C8F1D3.1070006@redhat.com> Message-ID: <46C94763.5070109@hhs.nl> Thomas Fitzsimmons wrote: > Hi, > > With the update to b18 the build was failing on my x86_64 machine with > an undefined symbol, png_mmx_support, in libpng. > > The problem was exposed by the fix for: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6577886 > > specifically this line: > > +LDFLAGS_DEFS_OPTION = -z defs > > which causes the linker to disallow undefined symbols. > > The failure will happen on systems that support MMX: > > $ echo | cpp -dM | grep __MMX__ > #define __MMX__ 1 > > That macro indirectly causes the default png_mmx_support definition to > be ifdef'd out. > > For now I've applied this workaround: > > --- openjdk.orig/j2se/make/sun/splashscreen/Makefile 2007-08-19 > 15:04:21.000000000 -0400 > +++ openjdk/j2se/make/sun/splashscreen/Makefile 2007-08-19 > 15:08:45.000000000 -0400 > @@ -59,7 +59,7 @@ > # C Flags > # > > -CFLAGS += -DSPLASHSCREEN > +CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE > > ifneq ($(PLATFORM), windows) > CFLAGS += -DWITH_X11 > > to disable libpng's MMX-specific functions (optimized C implementations > are used instead). > > A better solution would be to conditionally compile pnggccrd.c, which > defines png_mmx_support, when __MMX__ is defined. pnggccrd.c would have > to be patched to fix png_squelch_warnings compile errors. > Hmm, This sounds awefully familiar to a bug in the system libpng, which I fixed quite some time ago. Is IcedTea using its own copy of libpng? IF so why? Regards, Hans From fitzsim at redhat.com Mon Aug 20 15:34:31 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 20 Aug 2007 18:34:31 -0400 Subject: Fix for libpng undefined symbol In-Reply-To: <46C94763.5070109@hhs.nl> References: <46C8F1D3.1070006@redhat.com> <46C94763.5070109@hhs.nl> Message-ID: <46CA16F7.7060702@redhat.com> Hans de Goede wrote: > Thomas Fitzsimmons wrote: >> Hi, >> >> With the update to b18 the build was failing on my x86_64 machine with >> an undefined symbol, png_mmx_support, in libpng. >> >> The problem was exposed by the fix for: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6577886 >> >> specifically this line: >> >> +LDFLAGS_DEFS_OPTION = -z defs >> >> which causes the linker to disallow undefined symbols. >> >> The failure will happen on systems that support MMX: >> >> $ echo | cpp -dM | grep __MMX__ >> #define __MMX__ 1 >> >> That macro indirectly causes the default png_mmx_support definition to >> be ifdef'd out. >> >> For now I've applied this workaround: >> >> --- openjdk.orig/j2se/make/sun/splashscreen/Makefile 2007-08-19 >> 15:04:21.000000000 -0400 >> +++ openjdk/j2se/make/sun/splashscreen/Makefile 2007-08-19 >> 15:08:45.000000000 -0400 >> @@ -59,7 +59,7 @@ >> # C Flags >> # >> >> -CFLAGS += -DSPLASHSCREEN >> +CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE >> >> ifneq ($(PLATFORM), windows) >> CFLAGS += -DWITH_X11 >> >> to disable libpng's MMX-specific functions (optimized C >> implementations are used instead). >> >> A better solution would be to conditionally compile pnggccrd.c, which >> defines png_mmx_support, when __MMX__ is defined. pnggccrd.c would >> have to be patched to fix png_squelch_warnings compile errors. >> > > Hmm, > > This sounds awefully familiar to a bug in the system libpng, which I > fixed quite some time ago. Is IcedTea using its own copy of libpng? IF > so why? OpenJDK bundles its own copy of libpng. There are no significant differences between the bundled copy and Fedora 7's. I assume it's done for portability to systems that don't have libpng, but for Fedora I agree that IcedTea should use the system libpng. Tom From matthew.flaschen at gatech.edu Tue Aug 21 14:07:04 2007 From: matthew.flaschen at gatech.edu (Matthew Flaschen) Date: Tue, 21 Aug 2007 17:07:04 -0400 Subject: Mozilla Build Requirements Message-ID: <46CB53F8.6040107@gatech.edu> The latest IcedTea hg requires Mozilla to build. However, it is not particularly clear about what exactly is checked for and required. The configure output says: "checking for MOZILLA... no checking for MOZILLA... yes" Before it said, "checking for MOZILLA... no checking for MOZILLA... no" and gave an error. I fixed this by installing firefox-devel on Fedora 7, which brought in several dependencies. I'm not sure which of these packages were actually required. The INSTALL file should be updated to list the required Mozilla dependencies. It would also be helpful to give more clear configure output. Matt Flaschen From doko at ubuntu.com Wed Aug 22 13:51:47 2007 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 22 Aug 2007 22:51:47 +0200 Subject: icedtea packages in deb format Message-ID: <46CCA1E3.4080304@ubuntu.com> First deb Packages for amd64 and i386 are available at deb http://people.ubuntu.com/~doko/ubuntu/ gutsy/ deb-src http://people.ubuntu.com/~doko/ubuntu/ gutsy/ Although the packages are built on Ubuntu gutsy, they are installable on Debian sid as well. Please contact Michael Koch or me if you do want to join the packaging and maintainance effort for the deb packages or give some feedback. Matthias From gnu_andrew at member.fsf.org Wed Aug 22 15:00:34 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 22 Aug 2007 23:00:34 +0100 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: <200708222300.44767.gnu_andrew@member.fsf.org> On Sunday 17 June 2007 00:28, 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. > > > 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, Further to this earlier discussion, Dalibor has now completed his work on getting javac building using autoconf. I'm going to look at this over the next few days and see if I can combine it with what I have. Assuming this is successful, can we set up a Mercurial repository on the IcedTea servers for this (or perhaps it may be worth having it as part of IcedTea itself)? Thanks, -- 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/20070822/3564294f/attachment.bin From Tom.Marble at Sun.COM Wed Aug 22 21:54:49 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 22 Aug 2007 23:54:49 -0500 Subject: icedtea packages in deb format In-Reply-To: <46CCA1E3.4080304@ubuntu.com> References: <46CCA1E3.4080304@ubuntu.com> Message-ID: <46CD1319.5090707@sun.com> Matthias Klose wrote: > First deb Packages for amd64 and i386 are available at > > deb http://people.ubuntu.com/~doko/ubuntu/ gutsy/ > deb-src http://people.ubuntu.com/~doko/ubuntu/ gutsy/ > > Although the packages are built on Ubuntu gutsy, they are installable on Debian > sid as well. Thanks doko! I have done some preliminary testing on a 'sid' system. I had a very early version of the 'icedtea' package from man-di which did conflict, but I doubt many will encounter this. The following packages will be REMOVED: icedtea The following NEW packages will be installed: icedtea-java7-bin icedtea-java7-demo icedtea-java7-jdk icedtea-java7-jre icedtea-java7-source Smoketest seems fine: tmarble at ontologie 4% /usr/lib/jvm/java-7-icedtea/bin/java -version java version "1.7.0" OpenJDK Runtime Environment (build 1.7.0-doko_22_aug_2007_17_34-b00) OpenJDK Server VM (build 1.7.0-doko_22_aug_2007_18_42-b00, mixed mode) tmarble at ontologie 5% I will do more testing tomorrow. I notice in the control files you have: Package: icedtea-java7-jdk Depends: icedtea-java7-jre (= 7~b18-1.2+20070822-0ubuntu1), libc6 (>= 2.6-1), libx11-6 Package: icedtea-java7-jre Depends: icedtea-java7-bin (>= 7~b18), java-common Package: icedtea-java7-bin Depends: icedtea-java7-jre (>= 7~b18-1.2+20070822-0ubuntu1), libc6 (>= 2.6-1), libfreetype6 (>= 2.3.5), libgcc1 (>= 1:4.2-20070516), libx11-6, libxext6, libxi6, libxtst6 Do you have any thoughts about splitting icedtea-java7-bin (arch specific part of the JRE) into parts which are (and are not) dependent on libx11-6, libxext6, libxi6, libxtst6? Regards, --Tom From fw at deneb.enyo.de Sun Aug 26 01:49:52 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 26 Aug 2007 10:49:52 +0200 Subject: icedtea packages in deb format In-Reply-To: <46CCA1E3.4080304@ubuntu.com> (Matthias Klose's message of "Wed, 22 Aug 2007 22:51:47 +0200") References: <46CCA1E3.4080304@ubuntu.com> Message-ID: <87k5rismrz.fsf@mid.deneb.enyo.de> * Matthias Klose: > Although the packages are built on Ubuntu gutsy, they are > installable on Debian sid as well. They also build on sid after tweaking the build dependencies. Nice, thanks. Eclipse 3.3 seems to run just fine, but all Swing applications just display a grey window. Is this expected? From mark at klomp.org Sun Aug 26 07:32:32 2007 From: mark at klomp.org (Mark Wielaard) Date: Sun, 26 Aug 2007 16:32:32 +0200 Subject: icedtea packages in deb format In-Reply-To: <87k5rismrz.fsf@mid.deneb.enyo.de> References: <46CCA1E3.4080304@ubuntu.com> <87k5rismrz.fsf@mid.deneb.enyo.de> Message-ID: <1188138753.2895.5.camel@hermans.wildebeest.org> Hi Florian, On Sun, 2007-08-26 at 10:49 +0200, Florian Weimer wrote: > Eclipse 3.3 seems to run just fine, but all Swing applications just > display a grey window. Is this expected? No. I haven't tried the deb packages yet, but compiled icedtea from source (on Fedora 7, x86) and the result can run even the SwingSet2 and 2D demo and jedit (and even netbeans although that doesn't run flawlessly yet). There are some small drawing issues here and there, but nothing major. Cheers, Mark From langel at redhat.com Tue Aug 28 11:05:23 2007 From: langel at redhat.com (Lillian Angel) Date: Tue, 28 Aug 2007 14:05:23 -0400 Subject: IcedTea 1.3 Web Browser Plugin Release Message-ID: <46D463E3.6070804@redhat.com> We are proud to announce the release of IcedTea 1.3. This release represents the inclusion of a web browser plugin! The IcedTea project provides a harness to build the source code from OpenJDK (http://openjdk.java.net) using Free Software build tools and provides replacements libraries for the binary plugs with code from the GNU Classpath project. More information on IcedTea can be found here: http://icedtea.classpath.org What's new? --------------- * Updated to OpenJDK b18 build. * Web browser plugin support using gcjwebplugin. * Now using Fonts included in b18. * Graphics fixes. * SSL/Crypto fixes. * Refactored build process. * Various bug fixes (http://icedtea.classpath.org/bugzilla/). The tarball and nosrc RPM can be downloaded here: http://icedtea.classpath.org/download/ The following people helped with this release: Lillian Angel, Gary Benson, Tania Bento, Thomas Fitzsimmons, Andrew Haley, Francis Kung, Joshua Sumali, Mark Wielaard We would also like to thank the bug reporters and testers! ---------- 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 firefox-devel glib2-devel gtk2-devel Then: $ hg clone http://icedtea.classpath.org/hg/icedtea $ cd icedtea Full build instructions are in INSTALL, but this works: $ ./configure $ make When this completes you'll have a usable IcedTea in openjdk/control/build/linux-i586 or openjdk/control/build/linux-amd64. From theBohemian at gmx.net Wed Aug 29 05:07:02 2007 From: theBohemian at gmx.net (Robert Schuster) Date: Wed, 29 Aug 2007 14:07:02 +0200 Subject: IcedTea 1.3 Web Browser Plugin Release In-Reply-To: <46D463E3.6070804@redhat.com> References: <46D463E3.6070804@redhat.com> Message-ID: <46D56166.3010701@gmx.net> Hi, woah is this -> > $ ./configure > $ make Autotools? > When this completes you'll have a usable IcedTea in > openjdk/control/build/linux-i586 or openjdk/control/build/linux-amd64. @Twisti: Can this be run by cacao? Regards Robert -------------- 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/20070829/d1a96bf6/signature.asc From twisti at complang.tuwien.ac.at Wed Aug 29 05:26:41 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 29 Aug 2007 14:26:41 +0200 Subject: IcedTea 1.3 Web Browser Plugin Release In-Reply-To: <46D56166.3010701@gmx.net> References: <46D463E3.6070804@redhat.com> <46D56166.3010701@gmx.net> Message-ID: <1188390401.3716.17.camel@localhost.localdomain> On Wed, 2007-08-29 at 14:07 +0200, Robert Schuster wrote: > Hi, Hi! I really should subscribe myself to distro-pkg-dev... > woah is this -> > > $ ./configure > > $ make > Autotools? No. > > > When this completes you'll have a usable IcedTea in > > openjdk/control/build/linux-i586 or openjdk/control/build/linux-amd64. > @Twisti: Can this be run by cacao? Eh... yes. In two ways: 1. Either by CACAO it self or 2. copy CACAO's libjvm.so to the appropriate place(s) and run the OpenJDK wrappers. OK, I know, this was a short explanation but it works. - twisti From doko at ubuntu.com Wed Aug 29 07:25:10 2007 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 29 Aug 2007 16:25:10 +0200 Subject: icedtea packages in deb format In-Reply-To: <87k5rismrz.fsf@mid.deneb.enyo.de> References: <46CCA1E3.4080304@ubuntu.com> <87k5rismrz.fsf@mid.deneb.enyo.de> Message-ID: <46D581C6.30904@ubuntu.com> Florian Weimer schrieb: > * Matthias Klose: > >> Although the packages are built on Ubuntu gutsy, they are >> installable on Debian sid as well. > > They also build on sid after tweaking the build dependencies. Nice, > thanks. > > Eclipse 3.3 seems to run just fine, but all Swing applications just > display a grey window. Is this expected? does the installation of liblesstif2 help? From doko at ubuntu.com Wed Aug 29 07:48:26 2007 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 29 Aug 2007 16:48:26 +0200 Subject: finding out about (system) dependencies Message-ID: <46D5873A.6020209@ubuntu.com> A whole bunch of system libraries are tried to load using dlopen, instead of linking against these libraries. Is this a leftover windowism, or expected behaviour? It makes it somewhat difficult to automatically add runtime dependencies for the runtime packages. Scanning the strings output from the library packages, the following libraries seem to be dlopen'ed: LIB: libawt.so: libXm.so.3 LIB: libfontmanager.so: libfreetype.so.6 libjpeg.so LIB: libnet.so libgconf-2.so libgconf-2.so.4 LIB: headless/libmawt.so: libfontconfig.so.1 libfontconfig.so libcups.so.2 libcups.so LIB: xawt/libmawt.so: libsunwjdga.so libXrandr.so.2 libgnomevfs-2.so.0 libgnome-2.so.0 libfontconfig.so.1 libfontconfig.so libGL.so.1 libcups.so.2 libcups.so libgtk-x11-2.0.so.0 running debian's dpkg-shlibdeps only identifies as dependencies: libc6, libfreetype6, libgcc1, libx11-6, libxext6, libxi6, libxtst6 so I assume these dependencies have to be managed manually as long as the libraries are not linked against the system libraries? Matthias From doko at ubuntu.com Wed Aug 29 08:00:55 2007 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 29 Aug 2007 17:00:55 +0200 Subject: minimal / server installation for -jre package needed Message-ID: <46D58A27.7030603@ubuntu.com> In the past, Debian and Ubuntu had some bug reports requesting the possibility to install the runtime on a system without any need to install any X, Motif, and sound dependencies. On the other hand upstream asked for a "complete" installation, if you install "the" runtime package. Using packaging dependencies and splitting up installation files into several binary packages (built from the same package source), you usually can satisfy both needs: Package: foo-jre Depends: foo-bin-core Package: foo-bin: Depends: foo-jre foo-bin-core foo-bin-cups foo-bin-sound \ foo-bin-awtswing foo-plugin Package: foo-jdk Depends: foo-bin, foo-jre Are there any plans by upstream to recommend/suggest how such a split should be done so that distributions don't differ too much, or is this completly up to distributors? Matthias From doko at ubuntu.com Wed Aug 29 08:07:16 2007 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 29 Aug 2007 17:07:16 +0200 Subject: replacing included 3rd party libraries with system libraries Message-ID: <46D58BA4.8000501@ubuntu.com> Currently libraries like jpeg, zlib, lcms, png and maybe others are included in the installed runtime packages. Would it be possible to use the available system libraries instead of the included libraries? At least that would save distributors for security updates of the openjdk/iced package when one of these libraries is only affected. Matthias From fw at deneb.enyo.de Wed Aug 29 08:14:22 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 29 Aug 2007 17:14:22 +0200 Subject: icedtea packages in deb format In-Reply-To: <46D581C6.30904@ubuntu.com> (Matthias Klose's message of "Wed, 29 Aug 2007 16:25:10 +0200") References: <46CCA1E3.4080304@ubuntu.com> <87k5rismrz.fsf@mid.deneb.enyo.de> <46D581C6.30904@ubuntu.com> Message-ID: <87ejhmv0dt.fsf@mid.deneb.enyo.de> * Matthias Klose: > Florian Weimer schrieb: >> Eclipse 3.3 seems to run just fine, but all Swing applications just >> display a grey window. Is this expected? > > does the installation of liblesstif2 help? Both lesstif2 and lesstif2-dev have already been installed. From fkung at redhat.com Wed Aug 29 08:17:58 2007 From: fkung at redhat.com (Francis Kung) Date: Wed, 29 Aug 2007 11:17:58 -0400 Subject: icedtea packages in deb format In-Reply-To: <87ejhmv0dt.fsf@mid.deneb.enyo.de> References: <46CCA1E3.4080304@ubuntu.com> <87k5rismrz.fsf@mid.deneb.enyo.de> <46D581C6.30904@ubuntu.com> <87ejhmv0dt.fsf@mid.deneb.enyo.de> Message-ID: <46D58E26.2080204@redhat.com> >>> Eclipse 3.3 seems to run just fine, but all Swing applications just >>> display a grey window. Is this expected? >> does the installation of liblesstif2 help? > > Both lesstif2 and lesstif2-dev have already been installed. Is this an x86_64 machine? We've seen a bug in 64-bit lesstif that caused window decorations to disappear - perhaps this is another similar problem? Regards, Francis From j.w.r.degoede at hhs.nl Wed Aug 29 08:09:13 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 29 Aug 2007 17:09:13 +0200 Subject: icedtea packages in deb format In-Reply-To: <46D58E26.2080204@redhat.com> References: <46CCA1E3.4080304@ubuntu.com> <87k5rismrz.fsf@mid.deneb.enyo.de> <46D581C6.30904@ubuntu.com> <87ejhmv0dt.fsf@mid.deneb.enyo.de> <46D58E26.2080204@redhat.com> Message-ID: <46D58C19.7030904@hhs.nl> Francis Kung wrote: >>>> Eclipse 3.3 seems to run just fine, but all Swing applications just >>>> display a grey window. Is this expected? >>> does the installation of liblesstif2 help? >> >> Both lesstif2 and lesstif2-dev have already been installed. > > Is this an x86_64 machine? We've seen a bug in 64-bit lesstif that > caused window decorations to disappear - perhaps this is another similar > problem? > Talking about this 64 bit lesstif bug, the so called "fix" has caused many problems for other lesstif applications on 64 bit machines and is almost 100% guaranteed wrong, see: https://bugzilla.redhat.com/show_bug.cgi?id=253456 Regards, Hans From Tom.Marble at Sun.COM Wed Aug 29 08:38:59 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 29 Aug 2007 10:38:59 -0500 Subject: replacing included 3rd party libraries with system libraries In-Reply-To: <46D58BA4.8000501@ubuntu.com> References: <46D58BA4.8000501@ubuntu.com> Message-ID: <46D59313.3030104@sun.com> Matthias Klose wrote: > Currently libraries like jpeg, zlib, lcms, png and maybe others are included in > the installed runtime packages. Would it be possible to use the available system > libraries instead of the included libraries? At least that would save > distributors for security updates of the openjdk/iced package when one of these > libraries is only affected. We have discussed this in the context of the timezone database, font configuration and Xinerama (the dreaded XCB bug). Generally speaking this has been problematic because have wanted to keep coherent cross-platform behavior. It seems, however, there has been a little more willingness to consider the dependence on system libraries. To the extent that IcedTea is a chance to experiment now with this sort of thing perhaps it would be a could place to try out these ideas? If so please keep a list of this class of "system library dependencies" so we can easily find these solutions. Regards, --Tom From Tom.Marble at Sun.COM Wed Aug 29 08:41:15 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 29 Aug 2007 10:41:15 -0500 Subject: finding out about (system) dependencies In-Reply-To: <46D5873A.6020209@ubuntu.com> References: <46D5873A.6020209@ubuntu.com> Message-ID: <46D5939B.2010402@sun.com> Matthias Klose wrote: > A whole bunch of system libraries are tried to load using dlopen, instead of > linking against these libraries. Is this a leftover windowism, or expected > behaviour? [...] I suspect this has been done, among other reasons, to reduce startup time and memory footprint. > so I assume these dependencies have to be managed manually as long as the > libraries are not linked against the system libraries? Probably. And to the extent we can collaborate between the distros (e.g. Debian, Fedora, Gentoo...) system library package names and dependency graphs that would be fantastic. Regards, --Tom From mr at sun.com Wed Aug 29 08:43:29 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 29 Aug 2007 08:43:29 -0700 Subject: finding out about (system) dependencies In-Reply-To: tom.marble@sun.com; Wed, 29 Aug 2007 10:41:15 CDT; <46D5939B.2010402@sun.com> Message-ID: <20070829154329.CA0392608@eggemoggin.niobe.net> > Date: Wed, 29 Aug 2007 10:41:15 -0500 > From: tom.marble at sun.com > Matthias Klose wrote: >> A whole bunch of system libraries are tried to load using dlopen, instead of >> linking against these libraries. Is this a leftover windowism, or expected >> behaviour? [...] > > I suspect this has been done, among other reasons, to reduce > startup time and memory footprint. There are also cases where it's done in order to cope with the potential absence of certain libraries on some systems. >> so I assume these dependencies have to be managed manually as long as the >> libraries are not linked against the system libraries? > > Probably. And to the extent we can collaborate between the distros > (e.g. Debian, Fedora, Gentoo...) system library package names and > dependency graphs that would be fantastic. Agreed. It's also be interesting, however, to do an audit of all the dlopen calls in the code to see how many are actually necessary these days. - Mark From Tom.Marble at Sun.COM Wed Aug 29 08:47:26 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 29 Aug 2007 10:47:26 -0500 Subject: minimal / server installation for -jre package needed In-Reply-To: <46D58A27.7030603@ubuntu.com> References: <46D58A27.7030603@ubuntu.com> Message-ID: <46D5950E.9030106@sun.com> Matthias Klose wrote: > Are there any plans by upstream to recommend/suggest how such a split should be > done so that distributions don't differ too much, or is this completly up to > distributors? There are no such plans as foo-bin-core could not be considered "Compatible". However doing so would be within distributors rights under the GPL. That being said if distros think this would be helpful I hope that we can come up with a cross distro solution for the dependency graph. By that I mean that the significance of the decomposition is shared and analogous: foo-bin-core: server core (i.e. no X, sound) foo-bin: arch specific runtime foo-jre: arch indep runtime foo-jdk: SDK Comments from other distros? HTH, --Tom From fw at deneb.enyo.de Wed Aug 29 09:05:42 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 29 Aug 2007 18:05:42 +0200 Subject: icedtea packages in deb format In-Reply-To: <46D58E26.2080204@redhat.com> (Francis Kung's message of "Wed, 29 Aug 2007 11:17:58 -0400") References: <46CCA1E3.4080304@ubuntu.com> <87k5rismrz.fsf@mid.deneb.enyo.de> <46D581C6.30904@ubuntu.com> <87ejhmv0dt.fsf@mid.deneb.enyo.de> <46D58E26.2080204@redhat.com> Message-ID: <874piiuy09.fsf@mid.deneb.enyo.de> * Francis Kung: >>>> Eclipse 3.3 seems to run just fine, but all Swing applications just >>>> display a grey window. Is this expected? >>> does the installation of liblesstif2 help? >> Both lesstif2 and lesstif2-dev have already been installed. > > Is this an x86_64 machine? Yes, it is. Would it help if I tried compiling or running with OpenMotif? However, it's not just the that WM decorations disappear. The entire window is grey. From mr at sun.com Wed Aug 29 09:45:49 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 29 Aug 2007 09:45:49 -0700 Subject: minimal / server installation for -jre package needed In-Reply-To: tom.marble@sun.com; Wed, 29 Aug 2007 10:47:26 CDT; <46D5950E.9030106@sun.com> Message-ID: <20070829164549.55B3F2608@eggemoggin.niobe.net> > Date: Wed, 29 Aug 2007 10:47:26 -0500 > From: tom.marble at sun.com > Matthias Klose wrote: >> Are there any plans by upstream to recommend/suggest how such a split should be >> done so that distributions don't differ too much, or is this completly up to >> distributors? > > There are no such plans as foo-bin-core could not be considered > "Compatible". ... Well, it depends. The platform specification and the conformance rules do define the concept of a "headless" implementation, which is one that doesn't support interactive interfaces. It's been a while since I last read the conformance rules in detail, but my understanding has been that a "headless" implementation is considered conformant on a "headless" machine (i.e., one without a display). So it may well be that a partial installation, as Matthias suggests, would be fully conformant on headless boxes, which is presumably where it'd most often be used. - Mark From fkung at redhat.com Wed Aug 29 10:11:06 2007 From: fkung at redhat.com (Francis Kung) Date: Wed, 29 Aug 2007 13:11:06 -0400 Subject: icedtea packages in deb format In-Reply-To: <46D58C19.7030904@hhs.nl> References: <46CCA1E3.4080304@ubuntu.com> <87k5rismrz.fsf@mid.deneb.enyo.de> <46D581C6.30904@ubuntu.com> <87ejhmv0dt.fsf@mid.deneb.enyo.de> <46D58E26.2080204@redhat.com> <46D58C19.7030904@hhs.nl> Message-ID: <46D5A8AA.6040501@redhat.com> > Talking about this 64 bit lesstif bug, the so called "fix" has caused > many problems for other lesstif applications on 64 bit machines and is > almost 100% guaranteed wrong, see: > https://bugzilla.redhat.com/show_bug.cgi?id=253456 Thanks, I wasn't aware of that (I helped find the bug but wasn't involved in "fixing" it). I guess we'll wait for a proper patch. >>> Is this an x86_64 machine? >> >> Yes, it is. Would it help if I tried compiling or running with >> OpenMotif? >> >> However, it's not just the that WM decorations disappear. The entire >> window is grey. The symptoms are different, but I don't have any other ideas. Knowing that lesstif on x86_64 has caused problems in the past with AWT/Swing, it would help to at least rule this out... and since we haven't seen this problem on Fedora, I suspect a difference in a system library. Can you try setting the ALT_MOTIF_DIR env variable to point to OpenMotif and recompile, then see if this problem persists? Thanks, Francis From David.Herron at Sun.COM Wed Aug 29 10:38:24 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 29 Aug 2007 10:38:24 -0700 Subject: replacing included 3rd party libraries with system libraries In-Reply-To: <46D58BA4.8000501@ubuntu.com> References: <46D58BA4.8000501@ubuntu.com> Message-ID: <46D5AF10.2020009@sun.com> Matthias Klose wrote: > Currently libraries like jpeg, zlib, lcms, png and maybe others are included in > the installed runtime packages. Would it be possible to use the available system > libraries instead of the included libraries? At least that would save > distributors for security updates of the openjdk/iced package when one of these > libraries is only affected. > > Matthias > > As Tom said, this is being considered for the XCB fix (to dlopen the xinerama library if it's on the system) I remember seeing requests in some of the mailing lists for projects to do some of these: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen http://mail.openjdk.java.net/pipermail/awt-dev/2007-June/000021.html http://mail.openjdk.java.net/pipermail/awt-dev/2007-May/000000.html Using system tzdata http://mail.openjdk.java.net/pipermail/core-libs-dev/2007-August/000066.html http://mail.openjdk.java.net/pipermail/i18n-dev/2007-August/000001.html Generally this kind of change should be proposed in the relevant group mailing list. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070829/02dc103f/attachment.html From mark at klomp.org Wed Aug 29 11:41:58 2007 From: mark at klomp.org (Mark Wielaard) Date: Wed, 29 Aug 2007 20:41:58 +0200 Subject: replacing included 3rd party libraries with system libraries In-Reply-To: <46D5AF10.2020009@sun.com> References: <46D58BA4.8000501@ubuntu.com> <46D5AF10.2020009@sun.com> Message-ID: <1188412918.3823.6.camel@dijkstra.wildebeest.org> Hi David, On Wed, 2007-08-29 at 10:38 -0700, David Herron wrote: > As Tom said, this is being considered for the XCB fix (to dlopen the > xinerama library if it's on the system) Where is this discussed? > I remember seeing requests in some of the mailing lists for projects > to do some of these: > > [PATCHes] Allow using system's copies of libjpeg, libpng and > giflib for splashscreen > http://mail.openjdk.java.net/pipermail/awt-dev/2007-June/000021.html > http://mail.openjdk.java.net/pipermail/awt-dev/2007-May/000000.html > > Using system tzdata > http://mail.openjdk.java.net/pipermail/core-libs-dev/2007-August/000066.html > http://mail.openjdk.java.net/pipermail/i18n-dev/2007-August/000001.html > > Generally this kind of change should be proposed in the relevant group > mailing list. Thanks for the references. It is pretty hard to follow the overall project with so many mailinglist (and imho none of them have enough traffic to warrant being separate lists). Cheers, Mark From doko at ubuntu.com Wed Aug 29 11:47:05 2007 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 29 Aug 2007 20:47:05 +0200 Subject: [icedtea patch] DISTRIBUTION_PATCHES / jni include dir Message-ID: <46D5BF29.2010007@ubuntu.com> actually two patches: - re-add DISTRIBUTION_PATCHES; this might be empty, but is very conveniant to integrate patches before they are integrated in icedtea. - when building with gcc version != gcj version, the jni headers are not found. maybe this should become a new configure flag --with-jni-include= -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: icedtea-make.diff Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070829/27227402/icedtea-make.diff From doko at ubuntu.com Wed Aug 29 11:50:59 2007 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 29 Aug 2007 20:50:59 +0200 Subject: [openjdk / icedtea patch] allow to build with versioned compiler Message-ID: <46D5C013.4000602@ubuntu.com> its somewhat difficult to set the compiler to something different than gcc/g++. Adding another bin dir to PATH doesn't work because the compiler is called with an absolute path (why)? Adding a GCC_VERSION macro (which can be set in the environment), works for me to build using a specific compiler version. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gcc-suffix.diff Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070829/2d3434ff/gcc-suffix.diff From David.Herron at Sun.COM Wed Aug 29 14:10:41 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 29 Aug 2007 14:10:41 -0700 Subject: replacing included 3rd party libraries with system libraries In-Reply-To: <1188412918.3823.6.camel@dijkstra.wildebeest.org> References: <46D58BA4.8000501@ubuntu.com> <46D5AF10.2020009@sun.com> <1188412918.3823.6.camel@dijkstra.wildebeest.org> Message-ID: <46D5E0D1.60206@sun.com> Mark Wielaard wrote: > Hi David, > > On Wed, 2007-08-29 at 10:38 -0700, David Herron wrote: > >> As Tom said, this is being considered for the XCB fix (to dlopen the >> xinerama library if it's on the system) >> > Where is this discussed? > The XCB fix discussion has been on an internal mailing list so far. The bugs.sun.com page is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 I'll send a note to the assigned developer to ask him to post status on the awt-dev mailing list. >> I remember seeing requests in some of the mailing lists for projects >> to do some of these: >> >> [PATCHes] Allow using system's copies of libjpeg, libpng and >> giflib for splashscreen >> http://mail.openjdk.java.net/pipermail/awt-dev/2007-June/000021.html >> http://mail.openjdk.java.net/pipermail/awt-dev/2007-May/000000.html >> >> Using system tzdata >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2007-August/000066.html >> http://mail.openjdk.java.net/pipermail/i18n-dev/2007-August/000001.html >> >> Generally this kind of change should be proposed in the relevant group >> mailing list. >> > Thanks for the references. It is pretty hard to follow the overall > project with so many mailinglist (and imho none of them have enough > traffic to warrant being separate lists). > I agree right now it's a little hard to follow - but what if there was lots of traffic all in one list? At least the way it is now someone who's specifically interested in X will only receive email on X. > Cheers, > > Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070829/78b12511/attachment.html From David.Herron at Sun.COM Wed Aug 29 15:12:40 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 29 Aug 2007 15:12:40 -0700 Subject: minimal / server installation for -jre package needed In-Reply-To: <20070829164549.55B3F2608@eggemoggin.niobe.net> References: <20070829164549.55B3F2608@eggemoggin.niobe.net> Message-ID: <46D5EF58.7070109@sun.com> There is the Headless Toolkit in AWT which is meant to support installing Java on a headless system. I remember one intended scenario was exactly as Matthias suggested, no GUI libraries on the system. But I don't remember if we ever tested that scenario (I handled the initial test development for Headless AWT). I don't know this from the conformance rules standpoint (having never read those). Of course a server install wants to be headless because who needs graphics support on a webserver? I just did a test setup of debian, no X libs or other GUI stuff, and unpacked a tarball JDK and ran a few things. GUI apps of course died with headless exception, but e.g. the nio sample webserver ran and compiles ran. Hardly a conclusive test. Sounds promising. - David Herron Mark Reinhold wrote: >> Date: Wed, 29 Aug 2007 10:47:26 -0500 >> From: tom.marble at sun.com >> > > >> Matthias Klose wrote: >> >>> Are there any plans by upstream to recommend/suggest how such a split should be >>> done so that distributions don't differ too much, or is this completly up to >>> distributors? >>> >> There are no such plans as foo-bin-core could not be considered >> "Compatible". ... >> > > Well, it depends. > > The platform specification and the conformance rules do define the > concept of a "headless" implementation, which is one that doesn't > support interactive interfaces. > > It's been a while since I last read the conformance rules in detail, > but my understanding has been that a "headless" implementation is > considered conformant on a "headless" machine (i.e., one without > a display). > > So it may well be that a partial installation, as Matthias suggests, > would be fully conformant on headless boxes, which is presumably > where it'd most often be used. > > - Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20070829/d20d8eef/attachment.html