From aph at redhat.com Wed Sep 3 09:33:52 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Sep 2008 10:33:52 +0100 Subject: [fedora-java] aot-compile-rpm error In-Reply-To: <20080829074306.GA3817@redhat.com> References: <48B70D70.9060003@cora.nwra.com> <20080829074306.GA3817@redhat.com> Message-ID: <48BE5A00.8080600@redhat.com> Gary Benson wrote: > Orion Poplawski wrote: >> Trying to build eclipse-photran: >> >> http://koji.fedoraproject.org/koji/getfile?taskID=791458&name=build.log >> >> + aot-compile-rpm >> /usr/lib64/gcj-4.3.1/classmap.db >> aot-compile-rpm: error: /usr/bin/gcj-dbtool -p: unexpected output >> >> ? > > It looks like gcj-dbtool printed its result on stderr instead of > stdout, so aot-compile-rpm read nothing from it. Did something > change in gcj-dbtool? No. If there's a message on stderr, it's an error message. We need to know what that error message is. I just ptrace'd gcj-dbtool in gcj 4.3.1 and got [pid 23950] write(1, "/usr/lib64/gcj-4.3.1/classmap.db"..., 33/usr/lib64/gcj-4.3.1/classmap.db ) = 33 Andrew. From gbenson at redhat.com Wed Sep 3 10:11:39 2008 From: gbenson at redhat.com (Gary Benson) Date: Wed, 3 Sep 2008 11:11:39 +0100 Subject: [fedora-java] aot-compile-rpm error In-Reply-To: <48BE5A00.8080600@redhat.com> References: <48B70D70.9060003@cora.nwra.com> <20080829074306.GA3817@redhat.com> <48BE5A00.8080600@redhat.com> Message-ID: <20080903101139.GA1329@redhat.com> Andrew Haley wrote: > Gary Benson wrote: > > Orion Poplawski wrote: > > > Trying to build eclipse-photran: > > > > > > http://koji.fedoraproject.org/koji/getfile?taskID=791458&name=build.log > > > > > > + aot-compile-rpm > > > /usr/lib64/gcj-4.3.1/classmap.db > > > aot-compile-rpm: error: /usr/bin/gcj-dbtool -p: unexpected output > > > > > > ? > > > > It looks like gcj-dbtool printed its result on stderr instead of > > stdout, so aot-compile-rpm read nothing from it. Did something > > change in gcj-dbtool? > > No. If there's a message on stderr, it's an error message. We > need to know what that error message is. I just ptrace'd gcj-dbtool > in gcj 4.3.1 and got > > [pid 23950] write(1, "/usr/lib64/gcj-4.3.1/classmap.db"..., 33/usr/lib64/gcj-4.3.1/classmap.db > ) = 33 The only other thing I can think of then is that Python's os.popen() didn't capture stdout properly. There's nothing in aot-compile-rpm itself that would write "/usr/lib64/gcj-4.3.1/classmap.db" to either stdout or stderr. Cheers, Gary -- http://gbenson.net/ From aph at redhat.com Wed Sep 3 11:10:43 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Sep 2008 12:10:43 +0100 Subject: [fedora-java] aot-compile-rpm error In-Reply-To: <20080903101139.GA1329@redhat.com> References: <48B70D70.9060003@cora.nwra.com> <20080829074306.GA3817@redhat.com> <48BE5A00.8080600@redhat.com> <20080903101139.GA1329@redhat.com> Message-ID: <48BE70B3.4030608@redhat.com> Gary Benson wrote: > Andrew Haley wrote: >> Gary Benson wrote: >>> Orion Poplawski wrote: >>>> Trying to build eclipse-photran: >>>> >>>> http://koji.fedoraproject.org/koji/getfile?taskID=791458&name=build.log >>>> >>>> + aot-compile-rpm >>>> /usr/lib64/gcj-4.3.1/classmap.db >>>> aot-compile-rpm: error: /usr/bin/gcj-dbtool -p: unexpected output >>>> >>>> ? >>> It looks like gcj-dbtool printed its result on stderr instead of >>> stdout, so aot-compile-rpm read nothing from it. Did something >>> change in gcj-dbtool? >> No. If there's a message on stderr, it's an error message. We >> need to know what that error message is. I just ptrace'd gcj-dbtool >> in gcj 4.3.1 and got >> >> [pid 23950] write(1, "/usr/lib64/gcj-4.3.1/classmap.db"..., 33/usr/lib64/gcj-4.3.1/classmap.db >> ) = 33 > > The only other thing I can think of then is that Python's os.popen() > didn't capture stdout properly. There's nothing in aot-compile-rpm > itself that would write "/usr/lib64/gcj-4.3.1/classmap.db" to either > stdout or stderr. Yeah. We need to strace aot-compile-rpm at this point to see what it's doing. Orion, is there some way I can logon to this box? Andrew. From overholt at redhat.com Wed Sep 3 14:14:40 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 3 Sep 2008 10:14:40 -0400 Subject: [fedora-java] F9: Eclipse problems found In-Reply-To: <48B89D19.90701@cdkkt.com> References: <48B89D19.90701@cdkkt.com> Message-ID: <20080903141440.GB3285@redhat.com> Hi Dan, > BIRT (missing required components from which I could not find to > resolve), This is a special case IIRC because it requires a specific version of Tomcat bundled up which we don't ship. If you want to use BIRT, it's probably easiest to just use an eclipse.org download. > Mylin, > PyDev There are RPMs of both of these. > + Eclipse C/C++ Development Tools 4.0.3 200804041441 > Plug-in "org.eclipse.cdt.core.linux.x86" version "4.0.0.200804041441" > referenced by this feature is missing. I thought we had talked about this before, but this is a bug in the old Update manager when dealing with fragments. It doesn't affect functionality. > + Graphical Editing Framework SDK 3.3.0 200802201606 > The feature is disabled. > (Replaced by Graphical Editing Framework SDK 3.3.2.v20080129) I don't know where you got GEF but if it's some old Feodra package, remove it. > + SETools 3.3.2.4 > Plug-in "com.tresys.setools.linux.x86" version "3.3.2" referenced by > this feature is missing. This is the same as the CDT fragment issue above. > Plug-in "org.eclipse.equinox.common" version "3.3.0.v20070426" > referenced by this feature is missing. I have no idea about these features. But the important point is that there are known bugs in the old Update manager when dealing with split configurations like we have in Fedora. The dialogue you used that gave you these "errors" is a part of the old Update manager. If you notice actual behavioural problems (the BIRT issue is a unique case), then we have an issue, but these "configuration is broken" messages are harmless and incorrect. In the future, please file bugs for potential issues you find. Thanks. Andrew From orion at cora.nwra.com Wed Sep 3 15:44:29 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 03 Sep 2008 09:44:29 -0600 Subject: [fedora-java] aot-compile-rpm error In-Reply-To: <48BE70B3.4030608@redhat.com> References: <48B70D70.9060003@cora.nwra.com> <20080829074306.GA3817@redhat.com> <48BE5A00.8080600@redhat.com> <20080903101139.GA1329@redhat.com> <48BE70B3.4030608@redhat.com> Message-ID: <48BEB0DD.2000609@cora.nwra.com> Andrew Haley wrote: > Gary Benson wrote: >> The only other thing I can think of then is that Python's os.popen() >> didn't capture stdout properly. There's nothing in aot-compile-rpm >> itself that would write "/usr/lib64/gcj-4.3.1/classmap.db" to either >> stdout or stderr. > > Yeah. We need to strace aot-compile-rpm at this point to see what it's > doing. Orion, is there some way I can logon to this box? This is probably the popen() broken on xen kernels bug. I'll resubmit my build. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Wed Sep 3 16:06:32 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 03 Sep 2008 10:06:32 -0600 Subject: [fedora-java] Eclipse pdebuild trouble Message-ID: <48BEB608.9050803@cora.nwra.com> BUILD FAILED /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/build.xml:24: The following error occurred while executing this line: /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/build.xml:64: The following error occurred while executing this line: /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/templates/package-build/customTargets.xml:17: The following error occurred while executing this line: java.io.FileNotFoundException: /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/${eclipse.pdebuild.scripts}/genericTargets.xml (No such file or directory) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From overholt at redhat.com Wed Sep 3 16:07:11 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 3 Sep 2008 12:07:11 -0400 Subject: [fedora-java] Eclipse pdebuild trouble In-Reply-To: <48BEB608.9050803@cora.nwra.com> References: <48BEB608.9050803@cora.nwra.com> Message-ID: <20080903160711.GA11790@redhat.com> Hi Orion, * Orion Poplawski [2008-09-03 12:06]: > java.io.FileNotFoundException: > /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/${eclipse.pdebuild.scripts}/genericTargets.xml > (No such file or directory) This means something is wrong with your configuration. We need to make pdebuild use a clean user.home (I thought I did but it's obviously not doing it). Move the build user's ~/.eclipse out of the way and see if the problem persists. If it does, you'll need to add -D to the pdebuild line and examine the output for missing bundle lines, etc. Andrew From harshad.rj at gmail.com Wed Sep 3 16:32:23 2008 From: harshad.rj at gmail.com (Harshad) Date: Wed, 03 Sep 2008 22:02:23 +0530 Subject: [fedora-java] Toddler question : Scala package maintainer Message-ID: Hi, I have been a Fedora user since 7 upto 9. I also use Scala (www.scala-lang.org) a lot in my work. After seeing this [1] announcement on the Scala website, I thought I would chip-in for maintaining a Scala package for Fedora, and do my bit for both of these excellent communities. Trouble is that I have never done such a thing before. I have never compiled my own RPM, ever. I am looking at the package maintainers guide [2] right now and I am confident of following the details. But I need some baby-sitting for some top-level questions: * Is this the right list for asking questions about applications based on Java? * The creating-package-howto [3] says that we need to begin with pristine-sources and not use pre-compiled binaries. Is this applicable for Java packages too? Is pre-compiled to byte-code considered pristine enough? ;) Thanks in advance, Harshad [1] http://www.scala-lang.org/node/296 [2] http://fedoraproject.org/wiki/PackageMaintainers/Join [3] http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo From orion at cora.nwra.com Wed Sep 3 17:15:56 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 03 Sep 2008 11:15:56 -0600 Subject: [fedora-java] Rawhide eclipse file conflict Message-ID: <48BEC64C.9070003@cora.nwra.com> Trying to install rawhide: file /usr/lib/eclipse/plugins/com.ibm.icu_3.8.1.v20080530.jar conflicts between attempted installs of eclipse-rcp-1:3.4.0-22.fc10.i386 and icu4j-eclipse-0:3.8.1-3.fc10.i386 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From aph at redhat.com Wed Sep 3 17:17:34 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Sep 2008 18:17:34 +0100 Subject: [fedora-java] aot-compile-rpm error In-Reply-To: <48BEB0DD.2000609@cora.nwra.com> References: <48B70D70.9060003@cora.nwra.com> <20080829074306.GA3817@redhat.com> <48BE5A00.8080600@redhat.com> <20080903101139.GA1329@redhat.com> <48BE70B3.4030608@redhat.com> <48BEB0DD.2000609@cora.nwra.com> Message-ID: <48BEC6AE.6080708@redhat.com> Orion Poplawski wrote: > Andrew Haley wrote: >> Gary Benson wrote: >>> The only other thing I can think of then is that Python's os.popen() >>> didn't capture stdout properly. There's nothing in aot-compile-rpm >>> itself that would write "/usr/lib64/gcj-4.3.1/classmap.db" to either >>> stdout or stderr. >> >> Yeah. We need to strace aot-compile-rpm at this point to see what it's >> doing. Orion, is there some way I can logon to this box? > > This is probably the popen() broken on xen kernels bug. Ah. This seems very likely! :-) Andrew. From overholt at redhat.com Wed Sep 3 17:19:37 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 3 Sep 2008 13:19:37 -0400 Subject: [fedora-java] Toddler question : Scala package maintainer In-Reply-To: References: Message-ID: <20080903171937.GA15083@redhat.com> Hi, * Harshad [2008-09-03 12:40]: > > After seeing this [1] announcement on the Scala website, I thought I would > chip-in for maintaining a Scala package for Fedora, and do my bit for both > of these excellent communities. Cool! > * Is this the right list for asking questions about applications based on > Java? Yup. It's generally about stuff written in Java _in_ or _going into_ Fedora. > * The creating-package-howto [3] says that we need to begin with > pristine-sources and not use pre-compiled binaries. Is this applicable for > Java packages too? Yes. > Is pre-compiled to byte-code considered pristine enough? ;) Haha, no :) Andrew From overholt at redhat.com Wed Sep 3 17:20:06 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 3 Sep 2008 13:20:06 -0400 Subject: [fedora-java] Rawhide eclipse file conflict In-Reply-To: <48BEC64C.9070003@cora.nwra.com> References: <48BEC64C.9070003@cora.nwra.com> Message-ID: <20080903172005.GB15083@redhat.com> > file /usr/lib/eclipse/plugins/com.ibm.icu_3.8.1.v20080530.jar conflicts > between attempted installs of eclipse-rcp-1:3.4.0-22.fc10.i386 and > icu4j-eclipse-0:3.8.1-3.fc10.i386 Yes, I know. I'm fixing this now. Thanks, Andrew From harshad.rj at gmail.com Wed Sep 3 17:30:13 2008 From: harshad.rj at gmail.com (Harshad) Date: Wed, 03 Sep 2008 23:00:13 +0530 Subject: [fedora-java] Re: Toddler question : Scala package maintainer References: <20080903171937.GA15083@redhat.com> Message-ID: Andrew Overholt wrote: >> Is pre-compiled to byte-code considered pristine enough? ;) > > Haha, no :) I thought so :) But, the scala compiler is implemented in the scala language. This would mean cyclic dependencies (?) or perhaps we need to bootstrap it by following the older scala versions which must have started from .java. I guess adding scala is like adding a whole new language. It just so happens that it compiles to JVM as its target platform. So, it is not written in Java (the language), yet is a Java application (running on the JVM) From jjohnstn at redhat.com Wed Sep 3 17:36:46 2008 From: jjohnstn at redhat.com (Jeff Johnston) Date: Wed, 03 Sep 2008 13:36:46 -0400 Subject: [fedora-java] Eclipse pdebuild trouble In-Reply-To: <20080903160711.GA11790@redhat.com> References: <48BEB608.9050803@cora.nwra.com> <20080903160711.GA11790@redhat.com> Message-ID: <48BECB2E.8020209@redhat.com> Andrew Overholt wrote: > Hi Orion, > > * Orion Poplawski [2008-09-03 12:06]: > >> java.io.FileNotFoundException: >> /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/${eclipse.pdebuild.scripts}/genericTargets.xml >> (No such file or directory) >> > > This means something is wrong with your configuration. We need to make > pdebuild use a clean user.home (I thought I did but it's obviously not > doing it). Move the build user's ~/.eclipse out of the way and see if > the problem persists. If it does, you'll need to add -D to the pdebuild > line and examine the output for missing bundle lines, etc. > > Andrew > > -- > I recently ran into this problem. In addition to Andrew's suggestion of moving your ~/.eclipse out of the way, verify that your /usr/lib/eclipse/dropins/jdt and /usr/lib/eclipse/dropins/sdk directories don't have an eclipse subdirectory as well as plugins and features subdirectories. The newer model is no longer have the extra "eclipse" directory in-between. When I recently updated, the uninstall did not properly remove the eclipse subdirectory and there were a couple of straggling plugins found there. It appears that the resolution method doesn't backtrack so once it goes down the eclipse subdirectory and finds plugins, there are missing plugins so things go badly from there-on and the special ant extensions (e.g. eclipse.pdebuild.scripts) don't get resolved. -- Jeff J. From aph at redhat.com Wed Sep 3 17:37:27 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Sep 2008 18:37:27 +0100 Subject: [fedora-java] Re: Toddler question : Scala package maintainer In-Reply-To: References: <20080903171937.GA15083@redhat.com> Message-ID: <48BECB57.1030608@redhat.com> Harshad wrote: > Andrew Overholt wrote: > >>> Is pre-compiled to byte-code considered pristine enough? ;) >> Haha, no :) > > I thought so :) > > But, the scala compiler is implemented in the scala language. This would > mean cyclic dependencies (?) No, there's no need for that. The Scala build will need a Scala compiler; that's no different from gcc, which is written in C. So, the bootstrap Scala package will need pre-compiled bytecode, but we won't release that. Andrew. From harshad.rj at gmail.com Wed Sep 3 17:47:39 2008 From: harshad.rj at gmail.com (Harshad) Date: Wed, 03 Sep 2008 23:17:39 +0530 Subject: [fedora-java] Re: Re: Toddler question : Scala package maintainer References: <20080903171937.GA15083@redhat.com> <48BECB57.1030608@redhat.com> Message-ID: Andrew Haley wrote: > Harshad wrote: > > No, there's no need for that. The Scala build will need a Scala compiler; > that's no different from gcc, which is written in C. So, the bootstrap > Scala package will need pre-compiled bytecode, but we won't release that. Thanks both the Andrews for your quick responses. But some more searching revealed that another guy, Geoff Reedy, is making a similar effort and is much ahead than where I am: https://bugzilla.redhat.com/show_bug.cgi?id=426867 So, I will leave it to him. right ho, Harshad From orion at cora.nwra.com Wed Sep 3 19:04:58 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 03 Sep 2008 13:04:58 -0600 Subject: [fedora-java] Eclipse pdebuild trouble In-Reply-To: <48BECB2E.8020209@redhat.com> References: <48BEB608.9050803@cora.nwra.com> <20080903160711.GA11790@redhat.com> <48BECB2E.8020209@redhat.com> Message-ID: <48BEDFDA.9050800@cora.nwra.com> Jeff Johnston wrote: > Andrew Overholt wrote: >> Hi Orion, >> >> * Orion Poplawski [2008-09-03 12:06]: >> >>> java.io.FileNotFoundException: >>> /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/${eclipse.pdebuild.scripts}/genericTargets.xml >>> (No such file or directory) >>> >> >> This means something is wrong with your configuration. We need to make >> pdebuild use a clean user.home (I thought I did but it's obviously not >> doing it). Move the build user's ~/.eclipse out of the way and see if >> the problem persists. If it does, you'll need to add -D to the pdebuild >> line and examine the output for missing bundle lines, etc. >> >> Andrew >> >> -- >> > I recently ran into this problem. In addition to Andrew's suggestion of > moving your ~/.eclipse out of the way, verify that your > /usr/lib/eclipse/dropins/jdt and /usr/lib/eclipse/dropins/sdk > directories don't have an eclipse subdirectory as well as plugins and > features subdirectories. The newer model is no longer have the extra > "eclipse" directory in-between. When I recently updated, the uninstall > did not properly remove the eclipse subdirectory and there were a couple > of straggling plugins found there. It appears that the resolution > method doesn't backtrack so once it goes down the eclipse subdirectory > and finds plugins, there are missing plugins so things go badly from > there-on and the special ant extensions (e.g. eclipse.pdebuild.scripts) > don't get resolved. > > -- Jeff J. Well, these are mock and koji builds, so no existing ~/.eclipse directories. $ ls ../root/usr/lib/eclipse/dropins/* ../root/usr/lib/eclipse/dropins/cdt: eclipse ../root/usr/lib/eclipse/dropins/jdt: content.xml features plugins ../root/usr/lib/eclipse/dropins/sdk: content.xml features plugins Snippet with -D. Full log at: http://www.cora.nwra.com/~orion/fedora/build.log /usr/lib/eclipse/buildscripts/pdebuild -D -d cdt -f org.eclipse.photran_feature -a '-DjavacSource=1.5 -DjavacTarget=1.5' .... 0 2008-09-03 14:11:39.392 !MESSAGE Missing imported package com.ibm.icu.text_0.0.0. Starting application: 8244 !ENTRY org.eclipse.update.configurator 4 0 2008-09-03 14:11:39.529 !MESSAGE Unable to access file "plugins/com.ibm.icu_3.8.1.v20080530.jar!META-INF/MANIFEST. MF". !ENTRY org.eclipse.equinox.app 0 0 2008-09-03 14:11:39.757 !MESSAGE Product org.fedoraproject.ide.platform.product could not be found. !ENTRY org.eclipse.ant.core 4 2 2008-09-03 14:11:39.762 !MESSAGE Malformed URL. !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313) at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:164) at org.eclipse.ant.core.AntCorePreferences.addLibraries(AntCorePreferences.java:83 6) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries(AntCorePrefere nces.java:442) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHome(AntCorePreferences.ja va:303) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java: 291) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences .java:196) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:162) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:234) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:494) at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193 ) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecl ipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLa uncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) !ENTRY org.eclipse.ant.core 4 2 2008-09-03 14:11:39.764 !MESSAGE Malformed URL. !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313) at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:164) at org.eclipse.ant.core.AntCorePreferences.addLibraries(AntCorePreferences.java:83 6) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries(AntCorePrefere nces.java:442) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHome(AntCorePreferences.ja va:303) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java: 291) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences .java:196) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:162) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:234) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:494) at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193 ) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecl ipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLa uncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) !ENTRY org.eclipse.ant.core 4 2 2008-09-03 14:11:39.765 !MESSAGE Malformed URL. !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313) at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:164) at org.eclipse.ant.core.AntCorePreferences.addLibraries(AntCorePreferences.java:83 6) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries(AntCorePrefere nces.java:442) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHome(AntCorePreferences.ja va:303) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java: 291) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences .java:196) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:162) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:234) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:494) at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193 ) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecl ipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLa uncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) !ENTRY org.eclipse.ant.core 4 2 2008-09-03 14:11:39.766 !MESSAGE Malformed URL. !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313) at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:164) at org.eclipse.ant.core.AntCorePreferences.addLibraries(AntCorePreferences.java:83 6) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries(AntCorePrefere nces.java:442) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHome(AntCorePreferences.ja va:303) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java: 291) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences .java:196) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:162) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:234) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:494) at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193 ) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecl ipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLa uncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) !ENTRY org.eclipse.ant.core 4 2 2008-09-03 14:11:39.766 !MESSAGE Malformed URL. !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313) at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:164) at org.eclipse.ant.core.AntCorePreferences.addLibraries(AntCorePreferences.java:83 6) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries(AntCorePrefere nces.java:442) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHome(AntCorePreferences.ja va:303) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java: 291) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences .java:196) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:162) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:234) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:494) at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193 ) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecl ipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLa uncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) !ENTRY org.eclipse.ant.core 4 2 2008-09-03 14:11:39.793 !MESSAGE Malformed URL. !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313) at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:164) at org.eclipse.ant.core.AntCorePreferences.addLibraries(AntCorePreferences.java:83 6) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries(AntCorePrefere nces.java:442) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHome(AntCorePreferences.ja va:303) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java: 291) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences .java:196) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:162) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:234) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:494) at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193 ) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecl ipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLa uncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) !ENTRY org.eclipse.ant.core 4 2 2008-09-03 14:11:39.794 !MESSAGE Malformed URL. !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313) at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:164) at org.eclipse.ant.core.AntCorePreferences.addLibraries(AntCorePreferences.java:83 6) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries(AntCorePrefere nces.java:442) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHome(AntCorePreferences.ja va:303) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java: 291) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences .java:196) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:162) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:234) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:494) at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193 ) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecl ipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLa uncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) !ENTRY org.eclipse.ant.core 4 2 2008-09-03 14:11:39.794 !MESSAGE Malformed URL. !STACK 0 java.lang.NullPointerException at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313) at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:164) at org.eclipse.ant.core.AntCorePreferences.addLibraries(AntCorePreferences.java:83 6) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries(AntCorePrefere nces.java:442) at org.eclipse.ant.core.AntCorePreferences.getDefaultAntHome(AntCorePreferences.ja va:303) at org.eclipse.ant.core.AntCorePreferences.restoreAntHome(AntCorePreferences.java: 291) at org.eclipse.ant.core.AntCorePreferences.restoreCustomObjects(AntCorePreferences .java:196) at org.eclipse.ant.core.AntCorePreferences.(AntCorePreferences.java:162) at org.eclipse.ant.core.AntCorePlugin.setRunningHeadless(AntCorePlugin.java:234) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:494) at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193 ) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecl ipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLa uncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) at org.eclipse.core.launcher.Main.main(Main.java:30) Apache Ant version 1.7.0 compiled on July 9 2008 Setting ro project property: ant.file -> /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse. pde.build_3.4.0.v20080604/scripts/build.xml Unknown argument: -DorbitDepsDir= (Eclipse Fortran Development Tools) (Eclipse Technology Incubation)" Buildfile: /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scri pts/build.xml +Datatype eclipse.convertPath org.eclipse.core.resources.ant.ConvertPath +Datatype eclipse.incrementalBuild org.eclipse.core.resources.ant.IncrementalBuild +Datatype eclipse.refreshLocal org.eclipse.core.resources.ant.RefreshLocalTask +Datatype p2.director org.eclipse.equinox.p2.director.app.ant.DirectorTask +Datatype p2.generator org.eclipse.equinox.internal.p2.metadata.generator.ant.GeneratorTa sk Adding reference: ant.projectHelper Adding reference: ant.parsing.context Adding reference: ant.targets parsing buildfile /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v200806 04/scripts/build.xml with URI = file:/usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde. build_3.4.0.v20080604/scripts/build.xml Setting ro project property: ant.project.name -> Build All Elements Adding reference: Build All Elements Setting ro project property: ant.file.Build All Elements -> /usr/lib/eclipse/dropins/sdk/p lugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/build.xml Project base dir set to: /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0. v20080604/scripts +Target: +Target: main +Target: preBuild +Target: fetch +Target: generate +Target: process +Target: assemble +Target: package +Target: postBuild +Target: clean [antlib:org.apache.tools.ant] Could not load definitions from resource org/apache/tools/an t/antlib.xml. It could not be found. Override ignored for property "builder" Setting project property: builderDirectory -> /usr/lib/eclipse/dropins/sdk/plugins/org.ecl ipse.pde.build_3.4.0.v20080604/templates/package-build Setting project property: buildProperties -> /usr/lib/eclipse/dropins/sdk/plugins/org.ecli pse.pde.build_3.4.0.v20080604/templates/package-build/build.properties [property] Loading /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v2008 0604/templates/package-build/build.properties Override ignored for property "buildDirectory" Override ignored for property "baseLocation" Setting project property: runPackager -> false Setting project property: javacDebugInfo -> true Setting project property: javacFailOnError -> true Setting project property: collectingFolder -> eclipse Setting project property: zipargs -> -y Setting project property: archivesFormat -> *,*,*-zip Setting project property: archivePrefix -> eclipse Setting project property: archiveName -> org.eclipse.photran_feature.zip Setting project property: skipFetch -> true Setting project property: buildLabel -> rpmBuild [available] Found: /usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080 604/templates/package-build/customTargets.xml Setting project property: customTargets -> /usr/lib/eclipse/dropins/sdk/plugins/org.eclips e.pde.build_3.4.0.v20080604/templates/package-build/customTargets.xml Property "eclipse.pdebuild.templates" has not been set Override ignored for property "customTargets" Property "eclipse.pdebuild.scripts" has not been set Setting project property: genericTargets -> /usr/lib/eclipse/dropins/sdk/plugins/org.eclip se.pde.build_3.4.0.v20080604/scripts/${eclipse.pdebuild.scripts}/genericTargets.xml -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From overholt at redhat.com Wed Sep 3 19:23:31 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 3 Sep 2008 15:23:31 -0400 Subject: [fedora-java] Eclipse pdebuild trouble In-Reply-To: <48BEDFDA.9050800@cora.nwra.com> References: <48BEB608.9050803@cora.nwra.com> <20080903160711.GA11790@redhat.com> <48BECB2E.8020209@redhat.com> <48BEDFDA.9050800@cora.nwra.com> Message-ID: <20080903192331.GA22206@redhat.com> * Orion Poplawski [2008-09-03 15:05]: > Well, these are mock and koji builds, so no existing ~/.eclipse directories. Hmm. I can't duplicate locally. Maybe it's got to do with the icu4j-eclipse file dual ownership issue? I've got a build going of the SDK now (-23) with a fix for that, so maybe try again tomorrow? Sorry I don't have a better answer. Andrew From dant at cdkkt.com Wed Sep 3 22:09:34 2008 From: dant at cdkkt.com (Dan Thurman) Date: Wed, 03 Sep 2008 15:09:34 -0700 Subject: [fedora-java] F9: Eclipse problems found In-Reply-To: <20080903141440.GB3285@redhat.com> References: <48B89D19.90701@cdkkt.com> <20080903141440.GB3285@redhat.com> Message-ID: <48BF0B1E.9060201@cdkkt.com> Andrew Overholt wrote: > > Hi Dan, > > > BIRT (missing required components from which I could not find to > > resolve), > > This is a special case IIRC because it requires a specific version of > Tomcat bundled up which we don't ship. If you want to use BIRT, it's > probably easiest to just use an eclipse.org download. > Can I simply download just about any package from the Eclipse.org site, download it, and simply overlay it on top of the existing eclipse directory depending on if the package is rooted on the 'eclipse' directory? Some packages may have only the features/plugins directory and in that case, is overlayed on top of those directories under the eclipse directory. More below... > > > Mylin, > > PyDev > > There are RPMs of both of these. > Ok. > > > + Eclipse C/C++ Development Tools 4.0.3 200804041441 > > Plug-in "org.eclipse.cdt.core.linux.x86" version "4.0.0.200804041441" > > referenced by this feature is missing. > > I thought we had talked about this before, but this is a bug in the old > Update manager when dealing with fragments. It doesn't affect > functionality. > Ok, so I can simply ignore the messages therein. > > > + Graphical Editing Framework SDK 3.3.0 200802201606 > > The feature is disabled. > > (Replaced by Graphical Editing Framework SDK 3.3.2.v20080129) > > I don't know where you got GEF but if it's some old Feodra package, > remove it. > Ok, I deleted the folders/files containing the specific GEF found in features and plugins directories and the GEF error message no longer appears. > > > + SETools 3.3.2.4 > > Plug-in "com.tresys.setools.linux.x86" version "3.3.2" referenced by > > this feature is missing. > > This is the same as the CDT fragment issue above. > Ok, not an error, but an annoyance. > > > Plug-in "org.eclipse.equinox.common" version "3.3.0.v20070426" > > referenced by this feature is missing. > > I have no idea about these features. But the important point is that > there are known bugs in the old Update manager when dealing with split > configurations like we have in Fedora. The dialogue you used that gave > you these "errors" is a part of the old Update manager. If you notice > actual behavioural problems (the BIRT issue is a unique case), then we > have an issue, but these "configuration is broken" messages are harmless > and incorrect. > You say 'old' update manager - are you referring to the Update Manager found in Fedora's Eclipse (via Help->Software Updates) or what - I am clueless here. AFAIK - I am simply using Fedora-8/9's Eclipse and trying to understand what is going on. > > In the future, please file bugs for potential issues you find. Thanks. > But I was not sure these are 'bugs' per-se but rather clueless which is why I posted here to get a better understanding of what is going on before filing a bug when it is not really a bug, but ignorance on my part. > > Andrew > BTW: I downloaded from Eclipse.org, "Eclipse IDE for Java and Report Developers (188 MB) " (Linux 32bit ) to my Desktop, which created a file called: "eclipse-reporting-ganymede-linux-gtk.tar.gz" which was not seen as an icon on my desktop at all - I had to use the Gnome Terminal Emulator to actually see this file, moved it to another folder, and from there I was able to open this package and found that it was rooted with the 'eclipse' directory. But I was afraid to install this on top of my existing Fedora-9's eclipse for fear of trashing the whole package - worst - that I would be unable to remove anything with yum remove. Is there a Fedora (8-9) link somewhere to get a newbie perspective on how eclipse ought to be installed and in the proper way? Also, perhaps to catch up on what other packages are available that can be install within Fedora's Eclipse. Again, I am clueless although the Windoes version is very clear to me and I have primarily used Eclipse there for developing - just that I am unfamiliar with the nuances on Fedora - and would like to start using Eclipse on Fedora. Thanks for taking the time with me! Dan From gbenson at redhat.com Thu Sep 4 07:33:58 2008 From: gbenson at redhat.com (Gary Benson) Date: Thu, 4 Sep 2008 08:33:58 +0100 Subject: [fedora-java] aot-compile-rpm error In-Reply-To: <48BEC6AE.6080708@redhat.com> References: <48B70D70.9060003@cora.nwra.com> <20080829074306.GA3817@redhat.com> <48BE5A00.8080600@redhat.com> <20080903101139.GA1329@redhat.com> <48BE70B3.4030608@redhat.com> <48BEB0DD.2000609@cora.nwra.com> <48BEC6AE.6080708@redhat.com> Message-ID: <20080904073358.GA3815@redhat.com> Andrew Haley wrote: > Orion Poplawski wrote: > > Andrew Haley wrote: > > > Gary Benson wrote: > > > > The only other thing I can think of then is that Python's > > > > os.popen() didn't capture stdout properly. There's nothing > > > > in aot-compile-rpm itself that would write > > > > "/usr/lib64/gcj-4.3.1/classmap.db" to either stdout or stderr. > > > > > > Yeah. We need to strace aot-compile-rpm at this point to see > > > what it's doing. Orion, is there some way I can logon to this > > > box? > > > > This is probably the popen() broken on xen kernels bug. > > Ah. This seems very likely! :-) Quite :) -- http://gbenson.net/ From overholt at redhat.com Thu Sep 4 13:59:43 2008 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 4 Sep 2008 09:59:43 -0400 Subject: [fedora-java] F9: Eclipse problems found In-Reply-To: <48BF0B1E.9060201@cdkkt.com> References: <48B89D19.90701@cdkkt.com> <20080903141440.GB3285@redhat.com> <48BF0B1E.9060201@cdkkt.com> Message-ID: <20080904135943.GA8511@redhat.com> Hi, * Dan Thurman [2008-09-03 18:09]: > Can I simply download just about any package from the > Eclipse.org site, download it, and simply overlay it on > top of the existing eclipse directory depending on if the Just put it in your home directory. Pick one of the Ganymede bundles that includes the stuff you want to try. > You say 'old' update manager - are you referring to the Update The Update Manager from Eclipse <= 3.3. There's a new one in 3.4 which will be in Fedora 10. It is being actively developed and we're trying to ensure it works for our RPM case. >> In the future, please file bugs for potential issues you find. Thanks. >> > But I was not sure these are 'bugs' per-se but rather clueless which > is why I posted here to get a better understanding of what is going > on before filing a bug when it is not really a bug, but ignorance on > my part. Understood :) > - worst - that I would > be unable to remove anything with yum remove. If you just explode the tarball somewhere in your home directory, it will be self-contained. > Is there a Fedora (8-9) link somewhere to get a newbie perspective on > how eclipse ought to be installed and in the proper way? Eclipse is hard to get right for everyone. Fedora provides RPMs of the SDK and some plugins that are popular/useful/etc. These don't work for everyone, it's impossible to support every plugin out there, etc. Hence me suggesting you try an upstream download to see if it suits your needs better. If you're just using our RPMs, things *should* work and you *should* be able to install plugins seamlessly, etc. Mucking with files in the installation or doing things as root causes issues. If you were able to download and install an eclipse.org offering on Windows, you should be able to do the same on Linux (be it Fedora or whatever). > Thanks for taking the time with me! Any time. Andrew From orion at cora.nwra.com Thu Sep 4 14:42:24 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 04 Sep 2008 08:42:24 -0600 Subject: [fedora-java] Eclipse pdebuild trouble In-Reply-To: <20080903192331.GA22206@redhat.com> References: <48BEB608.9050803@cora.nwra.com> <20080903160711.GA11790@redhat.com> <48BECB2E.8020209@redhat.com> <48BEDFDA.9050800@cora.nwra.com> <20080903192331.GA22206@redhat.com> Message-ID: <48BFF3D0.9090708@cora.nwra.com> Andrew Overholt wrote: > * Orion Poplawski [2008-09-03 15:05]: >> Well, these are mock and koji builds, so no existing ~/.eclipse directories. > > Hmm. I can't duplicate locally. Maybe it's got to do with the > icu4j-eclipse file dual ownership issue? I've got a build going of the > SDK now (-23) with a fix for that, so maybe try again tomorrow? > > Sorry I don't have a better answer. > > Andrew Well, it built today, so it was a perfectly good answer :-). -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Thu Sep 4 14:44:13 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 04 Sep 2008 08:44:13 -0600 Subject: [fedora-java] aot-compile-rpm error In-Reply-To: <48BEB0DD.2000609@cora.nwra.com> References: <48B70D70.9060003@cora.nwra.com> <20080829074306.GA3817@redhat.com> <48BE5A00.8080600@redhat.com> <20080903101139.GA1329@redhat.com> <48BE70B3.4030608@redhat.com> <48BEB0DD.2000609@cora.nwra.com> Message-ID: <48BFF43D.2040808@cora.nwra.com> Orion Poplawski wrote: > Andrew Haley wrote: >> Gary Benson wrote: >>> The only other thing I can think of then is that Python's os.popen() >>> didn't capture stdout properly. There's nothing in aot-compile-rpm >>> itself that would write "/usr/lib64/gcj-4.3.1/classmap.db" to either >>> stdout or stderr. >> >> Yeah. We need to strace aot-compile-rpm at this point to see what it's >> doing. Orion, is there some way I can logon to this box? > > This is probably the popen() broken on xen kernels bug. I'll resubmit > my build. > Build worked today. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From gbenson at redhat.com Thu Sep 4 15:23:49 2008 From: gbenson at redhat.com (Gary Benson) Date: Thu, 4 Sep 2008 16:23:49 +0100 Subject: [fedora-java] aot-compile-rpm error In-Reply-To: <48BFF43D.2040808@cora.nwra.com> References: <48B70D70.9060003@cora.nwra.com> <20080829074306.GA3817@redhat.com> <48BE5A00.8080600@redhat.com> <20080903101139.GA1329@redhat.com> <48BE70B3.4030608@redhat.com> <48BEB0DD.2000609@cora.nwra.com> <48BFF43D.2040808@cora.nwra.com> Message-ID: <20080904152349.GC3815@redhat.com> Orion Poplawski wrote: > Orion Poplawski wrote: > > Andrew Haley wrote: > > > Gary Benson wrote: > > > > The only other thing I can think of then is that Python's > > > > os.popen() didn't capture stdout properly. There's nothing > > > > in aot-compile-rpm itself that would write > > > > "/usr/lib64/gcj-4.3.1/classmap.db" to either stdout or stderr. > > > > > > Yeah. We need to strace aot-compile-rpm at this point to see > > > what it's doing. Orion, is there some way I can logon to this > > > box? > > > > This is probably the popen() broken on xen kernels bug. I'll > > resubmit my build. > > Build worked today. Excellent, thanks. Cheers, Gary -- http://gbenson.net/ From dant at cdkkt.com Fri Sep 5 01:15:37 2008 From: dant at cdkkt.com (Dan Thurman) Date: Thu, 04 Sep 2008 18:15:37 -0700 Subject: [fedora-java] How to get Ruby installed on Eclipse 3.4? Message-ID: <48C08839.7020202@cdkkt.com> I'm a bit perplexed.. How do I install Ruby on Eclipse 3.4? Seems that it wants Equinox - but I don't seem to have this listed in my installed list - Just straight Eclipse so far. Here is the barf I get: Cannot complete the request. See the details. Cannot find a solution where both Match[requiredCapability: org.eclipse.equinox.p2.iu/org.epic.regexp/[0.5.1,0.5.1]] and Match[requiredCapability: org.eclipse.equinox.p2.iu/org.epic.regexp/[0.1.4,0.1.4]] can be satisfied. I am using straight Eclipse 3.4 (Not the Fedora 9 version) I do have EPIC installed also and thought it would work but the difference seems to be that there must also be EPIC under Equinox or so I assume? The RubyPeople claims it is compatable with Eclipse v3.4. Sorry, I am somewhat a n00b in this case. Thanks! Dan From lfarkas at lfarkas.org Fri Sep 5 09:28:20 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 05 Sep 2008 11:28:20 +0200 Subject: [fedora-java] which compiler to use for java packages Message-ID: <48C0FBB4.9010604@lfarkas.org> hi, what is the current preferred compiler to use in java packages in fedora? for me it seems mot of the java package still use gcj while openjdk is incuded in the distro. gcj has has the advantage to be able to use on rhel/epel too, while openjdk can compile 1.6 code. but suppose we've got an 1.5 code what compiler should have to use in rawhide packages? thanks. -- Levente "Si vis pacem para bellum!" From aph at redhat.com Fri Sep 5 09:35:59 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Sep 2008 10:35:59 +0100 Subject: [fedora-java] which compiler to use for java packages In-Reply-To: <48C0FBB4.9010604@lfarkas.org> References: <48C0FBB4.9010604@lfarkas.org> Message-ID: <48C0FD7F.9050401@redhat.com> Farkas Levente wrote: > what is the current preferred compiler to use in java packages in > fedora? for me it seems mot of the java package still use gcj while > openjdk is incuded in the distro. gcj has has the advantage to be able > to use on rhel/epel too, while openjdk can compile 1.6 code. but suppose > we've got an 1.5 code what compiler should have to use in rawhide packages? > thanks. You can normally just depend on java-devel unless your package depends on some special capabilities of one or the other. If you need compatibility with a very particular version of java you can explicitly depend on it, but I'd have to question why. Andrew. From overholt at redhat.com Fri Sep 5 13:15:57 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 5 Sep 2008 09:15:57 -0400 Subject: [fedora-java] How to get Ruby installed on Eclipse 3.4? In-Reply-To: <48C08839.7020202@cdkkt.com> References: <48C08839.7020202@cdkkt.com> Message-ID: <20080905131556.GA3430@redhat.com> Hi Dan, > I'm a bit perplexed.. > > How do I install Ruby on Eclipse 3.4? Seems that it wants > Equinox - but I don't seem to have this listed in my installed > list - Just straight Eclipse so far. This list is more for developers of Java parts of Fedora and not so much end user questions. Those are best asked on fedora-list. But since you're using an upstream download, you're really better off asking on one of the Eclipse newsgroups: http://www.eclipse.org/newsgroups/ > org.eclipse.equinox.p2.iu/org.epic.regexp/[0.5.1,0.5.1]] and > Match[requiredCapability: > org.eclipse.equinox.p2.iu/org.epic.regexp/[0.1.4,0.1.4]] can be > satisfied. > [...] > I do have EPIC installed also How'd you install EPIC? This error indicates that the EPIC installation is broken in some way which is preventing the installation of whatever ruby plugin you're trying. Andrew From orion at cora.nwra.com Fri Sep 5 15:52:09 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 09:52:09 -0600 Subject: [fedora-java] Trying to build tomcat app Message-ID: <48C155A9.5050407@cora.nwra.com> I'm trying to build a tomcat application but getting: + ant -lib /usr/share/java/tomcat6 Buildfile: build.xml BUILD FAILED /builddir/build/BUILD/openmailarchiva-1.7.5e/build.xml:35: taskdef class org.apache.catalina.ant.InstallTask cannot be found I've installed tomcat6-lib and there is /usr/share/java/tomcat6/catalina-ant.jar which is where the InstallTask class is. How do I point the build to it? Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Fri Sep 5 16:28:56 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 10:28:56 -0600 Subject: [fedora-java] Trying to build tomcat app In-Reply-To: <48C155A9.5050407@cora.nwra.com> References: <48C155A9.5050407@cora.nwra.com> Message-ID: <48C15E48.8090106@cora.nwra.com> Orion Poplawski wrote: > I'm trying to build a tomcat application but getting: > > + ant -lib /usr/share/java/tomcat6 > Buildfile: build.xml > BUILD FAILED > /builddir/build/BUILD/openmailarchiva-1.7.5e/build.xml:35: taskdef class > org.apache.catalina.ant.InstallTask cannot be found > > I've installed tomcat6-lib and there is > /usr/share/java/tomcat6/catalina-ant.jar which is where the InstallTask > class is. How do I point the build to it? > > Thanks! > export CLASSPATH=/usr/share/java/tomcat6/catalina-ant.jar seems to have done the trick. If there is a better way, let me know. Next issue - public class ADIdentity extends Identity implements Serializable { ... public boolean loadSettings(String prefix, Settings prop, String suffix) { logger.debug("loading ad identity"); // active directory identity info gives error: [javac] 5. ERROR in /builddir/build/BUILD/openmailarchiva-1.7.5e/src/com/stimulus/arch iva/authentication/ADIdentity.java (at line 102) [javac] logger.debug("loading ad identity"); [javac] ^^^^^^ [javac] Logger cannot be resolved to a type Which I'm not surprised at since logger is not defined anywhere in the source file. Is there some version of java compiler (eclipse? I think this project was developed with it) that would allow this? It is defined in Indentity.java: import org.apache.log4j.Logger; public abstract class Identity implements java.io.Serializable, Props { protected static Logger logger = Logger.getLogger(Identity.class.getName()); but that hasn't been compiled yet at this point. Some other warnings earlier: [taskdef] Could not load definitions from resource axis-tasks.properties. It could not be found. [javac] Annotation processing got disabled, since it requires a 1.6 compliant JVM Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Fri Sep 5 17:34:19 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 11:34:19 -0600 Subject: [fedora-java] Classpath issues In-Reply-To: <48C15E48.8090106@cora.nwra.com> References: <48C155A9.5050407@cora.nwra.com> <48C15E48.8090106@cora.nwra.com> Message-ID: <48C16D9B.8040604@cora.nwra.com> I seem to be stuck adding every single .jar that the application needs to CLASSPATH. There must be a better way. Please help. Build uses ant. Total noob. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Fri Sep 5 18:49:24 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 12:49:24 -0600 Subject: [fedora-java] Strange build error for classpathx-mail Message-ID: <48C17F34.2010207@cora.nwra.com> Starting looking into updating classpathx-mail to version 1.1.2 (anyone know of a reason not to?). Got a really weird internal compiler error on the ppc64 build: [javac] 1. ERROR in /builddir/build/BUILD/mail-1.1.2/inetlib-1.1.1/source/org/jpackage/mail/inet/imap/IMAPConnection.java (at line 0) [javac] /* [javac] ^ [javac] Internal compiler error [javac] java.lang.NullPointerException [javac] at org.eclipse.jdt.internal.compiler.looku [javac] p.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:262) [javac] at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719) [javac] at org.eclipse.jdt.i [javac] nternal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699) [javac] at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:294) [javac] at org.eclipse.jdt.internal.com [javac] piler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:128) [javac] at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:179) [javac] at org.eclipse.jdt.inte [javac] rnal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456) [javac] at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510) [javac] at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:359) [javac] at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(Compi [javac] lationUnitScope.java:435) [javac] at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:736) [javac] at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) [javac] at java.lang.Thread.run(libgcj.so.9) Other arches seemed okay but got cancelled. See: http://koji.fedoraproject.org/koji/taskinfo?taskID=809142 This was on ppc7. Resubmitted and it built okay (or at least got past this point). This time on ppc2 http://koji.fedoraproject.org/koji/taskinfo?taskID=809169 Fully successful build (if anyone wants to take a look at the package): http://koji.fedoraproject.org/koji/taskinfo?taskID=809200 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From aph at redhat.com Fri Sep 5 18:57:35 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Sep 2008 19:57:35 +0100 Subject: [fedora-java] Strange build error for classpathx-mail In-Reply-To: <48C17F34.2010207@cora.nwra.com> References: <48C17F34.2010207@cora.nwra.com> Message-ID: <48C1811F.4090003@redhat.com> Orion Poplawski wrote: > Starting looking into updating classpathx-mail to version 1.1.2 (anyone > know of a reason not to?). > > Got a really weird internal compiler error on the ppc64 build: > > > [javac] 1. ERROR in > /builddir/build/BUILD/mail-1.1.2/inetlib-1.1.1/source/org/jpackage/mail/inet/imap/IMAPConnection.java > (at line 0) > [javac] /* > [javac] ^ > [javac] Internal compiler error > [javac] java.lang.NullPointerException > [javac] at org.eclipse.jdt.internal.compiler.looku > [javac] p.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:262) > [javac] at > org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719) > > [javac] at org.eclipse.jdt.i > [javac] > nternal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699) > > [javac] at > org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:294) > [javac] at org.eclipse.jdt.internal.com > [javac] > piler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:128) > [javac] at > org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:179) > > [javac] at org.eclipse.jdt.inte > [javac] > rnal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456) > > [javac] at > org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510) > > [javac] at > org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:359) > > [javac] at > org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(Compi > > [javac] lationUnitScope.java:435) > [javac] at > org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:736) > [javac] at > org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) > > [javac] at java.lang.Thread.run(libgcj.so.9) > > > Other arches seemed okay but got cancelled. See: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=809142 > > This was on ppc7. > > > Resubmitted and it built okay (or at least got past this point). This > time on ppc2 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=809169 > > > Fully successful build (if anyone wants to take a look at the package): > > http://koji.fedoraproject.org/koji/taskinfo?taskID=809200 This is probably https://bugzilla.redhat.com/show_bug.cgi?id=459129 Jakub has a patch and we're waiting for gcj to be respun into a new RPM. Andrew. From orion at cora.nwra.com Fri Sep 5 20:23:47 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 14:23:47 -0600 Subject: [fedora-java] Strange build error for classpathx-mail In-Reply-To: <48C1811F.4090003@redhat.com> References: <48C17F34.2010207@cora.nwra.com> <48C1811F.4090003@redhat.com> Message-ID: <48C19553.9050401@cora.nwra.com> Andrew Haley wrote: > > This is probably https://bugzilla.redhat.com/show_bug.cgi?id=459129 > > Jakub has a patch and we're waiting for gcj to be respun into a new RPM. > > Andrew. Indeed. Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From simon at w3sp.de Mon Sep 8 14:23:31 2008 From: simon at w3sp.de (Simon Wesp) Date: Mon, 8 Sep 2008 16:23:31 +0200 Subject: [fedora-java] gonkygui and the dependences Message-ID: <20080908162331.767b07e6@schafwiese> Hi all, My wish is to add conkygui to fedora. i'm not really a java-adept. I think these are the missing dependences: conkygui http://conkygui.sourceforge.net (not available) D appframework https://appframework.dev.java.net/ (#461418) DD swing-worker https://swingworker.dev.java.net/ (#459926) D substance https://substance.dev.java.net/ (not available) DD laf-plugin https://laf-plugin.dev.java.net/ (#451407) DD laf-widget https://laf-widget.dev.java.net/ (#461408) DD swingx https://swingx.dev.java.net/ (not available) DDD jhlabs-filters http://www.jhlabs.com/ip/filters/ (#461411) DDD jmock http://www.jmock.org/ (not available) DDDD cglib http://cglib.sourceforge.net/ (not available) DDDD jarjar http://code.google.com/p/jarjar/ (not available) DDDDD aspectwerkz http://aspectwerkz.codehaus.org/ (not available) DDDDDD gnu-trove http://trove4j.sourceforge.net/ (not available) D swing-worker https://swingworker.dev.java.net/ (#459926) D = depends on (from https://fedoraproject.org/wiki/User:Cassmodiah#conkygui) I started to build the packages. But i think i'm not good enough for the whole tree. Would anybody adpot a/several package/s? Is the list of dependences correct? Feel free to correct it on the wiki or write me :-) so long -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp The G in GNU stands for GNU -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From overholt at redhat.com Mon Sep 8 14:54:41 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 8 Sep 2008 10:54:41 -0400 Subject: [fedora-java] gonkygui and the dependences In-Reply-To: <20080908162331.767b07e6@schafwiese> References: <20080908162331.767b07e6@schafwiese> Message-ID: <20080908145440.GA13547@redhat.com> Hi, * Simon Wesp [2008-09-08 10:24]: > conkygui http://conkygui.sourceforge.net (not available) > D appframework https://appframework.dev.java.net/ (#461418) > DD swing-worker https://swingworker.dev.java.net/ (#459926) > D substance https://substance.dev.java.net/ (not available) > DD laf-plugin https://laf-plugin.dev.java.net/ (#451407) > DD laf-widget https://laf-widget.dev.java.net/ (#461408) > DD swingx https://swingx.dev.java.net/ (not available) > DDD jhlabs-filters http://www.jhlabs.com/ip/filters/ (#461411) > DDD jmock http://www.jmock.org/ (not available) > DDDD cglib http://cglib.sourceforge.net/ (not available) > DDDD jarjar http://code.google.com/p/jarjar/ (not available) > DDDDD aspectwerkz http://aspectwerkz.codehaus.org/ (not available) > DDDDDD gnu-trove http://trove4j.sourceforge.net/ (not available) > D swing-worker https://swingworker.dev.java.net/ (#459926) I'm sure some of these dependencies are already in Fedora. Andrew From simon at w3sp.de Mon Sep 8 19:19:01 2008 From: simon at w3sp.de (Simon Wesp) Date: Mon, 8 Sep 2008 21:19:01 +0200 Subject: [fedora-java] gonkygui and the dependences In-Reply-To: <20080908145440.GA13547@redhat.com> References: <20080908162331.767b07e6@schafwiese> <20080908145440.GA13547@redhat.com> Message-ID: <20080908211901.19a0c3e9@schafwiese> Andrew Overholt : > I'm sure some of these dependencies are already in Fedora. I will never say "no" to detailed informations :-) I did not found them in the fedora repository and in the bugzilla-system. Perhaps i surveyed it inadvertently :-( I will check it tomorrow -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp The G in GNU stands for GNU -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From david at zarb.org Mon Sep 8 22:23:33 2008 From: david at zarb.org (David Walluck) Date: Mon, 08 Sep 2008 18:23:33 -0400 Subject: [fedora-java] gonkygui and the dependences In-Reply-To: <20080908162331.767b07e6@schafwiese> References: <20080908162331.767b07e6@schafwiese> Message-ID: <48C5A5E5.6080604@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Wesp wrote: | I started to build the packages. But i think i'm not good enough for the whole tree. | Would anybody adpot a/several package/s? For the ones that you listed as not available, you may also check JPackage for the SRPM: . | Is the list of dependences correct? If you got the list of jars from what is shipped with the sources, and it builds from source, then the list should be correct. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkjFpeQACgkQItObMyg2XCVpdwCeLI+NfONbIT0O4r74R5LGGL2x guUAnRVgQL5tIPNYiX5CimCiuE6rQFkU =zPbE -----END PGP SIGNATURE----- From simon at w3sp.de Wed Sep 10 17:53:15 2008 From: simon at w3sp.de (Simon Wesp) Date: Wed, 10 Sep 2008 19:53:15 +0200 Subject: [fedora-java] gonkygui and the dependences In-Reply-To: <48C5A5E5.6080604@zarb.org> References: <20080908162331.767b07e6@schafwiese> <48C5A5E5.6080604@zarb.org> Message-ID: <20080910195315.6a359a1e@schafwiese> David Walluck : > JPackage for the SRPM: . Old, very old, too old... -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp The G in GNU stands for GNU -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sflaniga at redhat.com Thu Sep 11 02:41:13 2008 From: sflaniga at redhat.com (Sean Flanigan) Date: Thu, 11 Sep 2008 12:41:13 +1000 Subject: [fedora-java] Packaging guidelines - do we need to repack jars for noarch Java packages? Message-ID: <48C88549.9020101@redhat.com> G'day! I've been creating a package for eclipse-nls , and I added this to my spec file: # Disable repacking of jars, since it takes forever for all the little jars, # and we don't need multilib anyway: %define __jar_repack %{nil} I haven't found a good explanation of the reasons behind jar repacking, but I gather it's something to do with multilib. What happens if you don't repack when you should? Jar repacking is incredibly slow when you have lots of little plugins (hello Eclipse!), so avoiding it is nice. I'm pretty sure it's safe to skip repacking in my case, because my package contains nothing except .properties files inside Eclipse plugins which are in jars when I download them, but is it safe to do in more general cases, such as noarch packages? Is there anything useful we could add to the guidelines? Regards Sean. -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From fitzsim at fitzsim.org Mon Sep 15 06:43:09 2008 From: fitzsim at fitzsim.org (Thomas Fitzsimmons) Date: Sun, 14 Sep 2008 23:43:09 -0700 Subject: [fedora-java] Re: Packaging guidelines - do we need to repack jars for noarch Java packages? In-Reply-To: <48C88549.9020101@redhat.com> (Sean Flanigan's message of "Thu\, 11 Sep 2008 12\:41\:13 +1000") References: <48C88549.9020101@redhat.com> Message-ID: Sean Flanigan writes: > G'day! > > I've been creating a package for eclipse-nls > , and I added this > to my spec file: > > # Disable repacking of jars, since it takes forever for all the little > jars, > # and we don't need multilib anyway: > %define __jar_repack %{nil} > > I haven't found a good explanation of the reasons behind jar repacking, > but I gather it's something to do with multilib. What happens if you > don't repack when you should? > > Jar repacking is incredibly slow when you have lots of little plugins > (hello Eclipse!), so avoiding it is nice. > > I'm pretty sure it's safe to skip repacking in my case, because my > package contains nothing except .properties files inside Eclipse plugins > which are in jars when I download them, but is it safe to do in more > general cases, such as noarch packages? > > Is there anything useful we could add to the guidelines? brp-java-repack-jars is meant to eliminate multilib conflicts for arch-dependent packages that include both arch-independent JARs under /usr/share/java and GCJ-compiled .jar.sos under /usr/lib*. JAR encodes a timestamp in archives it produces, so RPM's checksum-based conflict detection algorithm forbids installation of two otherwise identical JARs built at different times. Such conflicts affect Java packages that provide GCJ support. The problem doesn't exist for noarch Java packages. A small number of Java packages must be built arch-specific -- even if they do not provide GCJ support -- because they contain JNI DSOs. Running brp-java-repack-jars would seem to be necessary for these packages, except that the Java guidelines specify that JNI-using JAR files should be installed in %{_libdir}/%{name} [1]. The short answer is: if you follow the Java packaging guidelines, you only need to run brp-java-repack-jars on packages that include arch-independent JAR files under /usr/share and that also include GCJ-compiled .jar.so files. So ideally brp-java-repack-jars should not be run by default, but should instead be rolled into aot-compile-rpm. That would eliminate "%define __jar_repack %{nil}" spec file hacks. Tom 1. http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI From sflaniga at redhat.com Tue Sep 16 03:17:46 2008 From: sflaniga at redhat.com (Sean Flanigan) Date: Tue, 16 Sep 2008 13:17:46 +1000 Subject: [fedora-java] Re: Packaging guidelines - do we need to repack jars for noarch Java packages? In-Reply-To: References: <48C88549.9020101@redhat.com> Message-ID: <48CF255A.2040501@redhat.com> Thomas Fitzsimmons wrote: > brp-java-repack-jars is meant to eliminate multilib conflicts for > arch-dependent packages that include both arch-independent JARs under > /usr/share/java and GCJ-compiled .jar.sos under /usr/lib*. JAR encodes > a timestamp in archives it produces, so RPM's checksum-based conflict > detection algorithm forbids installation of two otherwise identical JARs > built at different times. Such conflicts affect Java packages that > provide GCJ support. The problem doesn't exist for noarch Java > packages. > > A small number of Java packages must be built arch-specific -- even if > they do not provide GCJ support -- because they contain JNI DSOs. > Running brp-java-repack-jars would seem to be necessary for these > packages, except that the Java guidelines specify that JNI-using JAR > files should be installed in %{_libdir}/%{name} [1]. > > The short answer is: if you follow the Java packaging guidelines, you > only need to run brp-java-repack-jars on packages that include > arch-independent JAR files under /usr/share and that also include > GCJ-compiled .jar.so files. So ideally brp-java-repack-jars should not > be run by default, but should instead be rolled into aot-compile-rpm. > That would eliminate "%define __jar_repack %{nil}" spec file hacks. > > Tom > > 1. http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI Thanks for the explanation, Tom. I think I got most of it, with help from an interpreter. So, a jar only needs to be repacked if (a) it is destined for /usr/share/ and (b) it belongs to an arch-specific package. Have I got that right? It sounds like repacking would be totally unnecessary if /usr/share/ jars were required to be in noarch sub-packages. Is that too impractical? (I'm new to packaging. Can you tell?) BTW, next time someone is looking at brb-java-repack-jars, they might want to check the status of this patch against Info-Zip: It's a patch for zipnote which can edit the timestamps inside a zip file. At the moment, it works on jar files (I just checked - the checksums match!), but ordinary zip files tend to have other timestamps which aren't handled yet. And my quick port to Zip 3.0 segfaults, I just discovered. brb-java-repack-jars could use the patched zipnote to edit the timestamps without having to repack the jars, but I suppose there's more benefit in the aot-compile-rpm work mentioned above. Still, once Zip 3.1 becomes available to the Fedora build system, it would be pretty easy to change brb-java-repack-jars. Assuming the patch, or something like it, makes it into Zip 3.1, that is. -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From fitzsim at fitzsim.org Tue Sep 16 11:01:11 2008 From: fitzsim at fitzsim.org (Thomas Fitzsimmons) Date: Tue, 16 Sep 2008 04:01:11 -0700 Subject: [fedora-java] Re: Packaging guidelines - do we need to repack jars for noarch Java packages? In-Reply-To: <48CF255A.2040501@redhat.com> (Sean Flanigan's message of "Tue\, 16 Sep 2008 13\:17\:46 +1000") References: <48C88549.9020101@redhat.com> <48CF255A.2040501@redhat.com> Message-ID: Sean Flanigan writes: > Thomas Fitzsimmons wrote: >> brp-java-repack-jars is meant to eliminate multilib conflicts for >> arch-dependent packages that include both arch-independent JARs under >> /usr/share/java and GCJ-compiled .jar.sos under /usr/lib*. JAR encodes >> a timestamp in archives it produces, so RPM's checksum-based conflict >> detection algorithm forbids installation of two otherwise identical JARs >> built at different times. Such conflicts affect Java packages that >> provide GCJ support. The problem doesn't exist for noarch Java >> packages. >> >> A small number of Java packages must be built arch-specific -- even if >> they do not provide GCJ support -- because they contain JNI DSOs. >> Running brp-java-repack-jars would seem to be necessary for these >> packages, except that the Java guidelines specify that JNI-using JAR >> files should be installed in %{_libdir}/%{name} [1]. >> >> The short answer is: if you follow the Java packaging guidelines, you >> only need to run brp-java-repack-jars on packages that include >> arch-independent JAR files under /usr/share and that also include >> GCJ-compiled .jar.so files. So ideally brp-java-repack-jars should not >> be run by default, but should instead be rolled into aot-compile-rpm. >> That would eliminate "%define __jar_repack %{nil}" spec file hacks. >> >> Tom >> >> 1. http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > > Thanks for the explanation, Tom. I think I got most of it, with help > from an interpreter. > > So, a jar only needs to be repacked if (a) it is destined for > /usr/share/ and (b) it belongs to an arch-specific package. Have I got > that right? Yes. > It sounds like repacking would be totally unnecessary if /usr/share/ > jars were required to be in noarch sub-packages. Is that too > impractical? (I'm new to packaging. Can you tell?) We have discussed solutions like that before. It used to be that rpmbuild didn't allow multiple different BuildArch tags in a single spec file. I suspect that's still the case. > BTW, next time someone is looking at brb-java-repack-jars, they might > want to check the status of this patch against Info-Zip: > > > It's a patch for zipnote which can edit the timestamps inside a zip > file. At the moment, it works on jar files (I just checked - the > checksums match!), but ordinary zip files tend to have other timestamps > which aren't handled yet. And my quick port to Zip 3.0 segfaults, I > just discovered. > > brb-java-repack-jars could use the patched zipnote to edit the > timestamps without having to repack the jars, but I suppose there's more > benefit in the aot-compile-rpm work mentioned above. Still, once Zip > 3.1 becomes available to the Fedora build system, it would be pretty > easy to change brb-java-repack-jars. Assuming the patch, or something > like it, makes it into Zip 3.1, that is. Your zipnote patch sounds promising. aot-compile-rpm should likely make use of it when it's ready. I'm glad to see someone's trying to eliminate this annoyance. Tom From matt.hoosier at gmail.com Mon Sep 29 15:12:14 2008 From: matt.hoosier at gmail.com (Matt Hoosier) Date: Mon, 29 Sep 2008 10:12:14 -0500 Subject: [fedora-java] Cross-compiling under CDT autotools Message-ID: Hi, My company is interested in using Eclipse and CDT for embedded Linux development. In the past, we've used some other IDE's that have built-in knowledge of autoconf/automake, and by adding plugins to modify the shell environment just prior to executing the 'configure' and 'make' steps, been able to fairly easily divert the normal Autotools workflow to instead consult a cross-compiled sysroot directory for libraries and headers. I'm not clear on what the best way to do this is in CDT autotools. The code which spawns 'autoconf', for example, doesn't really consult any extension points to allow outside plug-ins the ability to customize the environment variables (say, CFLAGS, CPPFLAGS, LDFLAGS, ...) or the path at which the autoconf binary will be found. Do you have any ideas on a good way to do this? Regards, Matt Hoosier -------------- next part -------------- An HTML attachment was scrubbed... URL: From overholt at redhat.com Mon Sep 29 16:19:23 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 29 Sep 2008 12:19:23 -0400 Subject: [fedora-java] Cross-compiling under CDT autotools In-Reply-To: References: Message-ID: <20080929161922.GR3770@redhat.com> Hi Matt, * Matt Hoosier [2008-09-29 11:12]: > I'm not clear on what the best way to do this is in CDT autotools. The CDT autotools plugins recently moved into the Linux Distros/Tools project at eclipse.org. It would be best to email linux-distros-dev at eclipse.org with your query. Thanks, Andrew From orcanbahri at yahoo.com Tue Sep 30 05:34:41 2008 From: orcanbahri at yahoo.com (Orcan Ogetbil) Date: Mon, 29 Sep 2008 22:34:41 -0700 (PDT) Subject: [fedora-java] iText status? Message-ID: <346371.20271.qm@web32808.mail.mud.yahoo.com> Hi, I saw that the iText software caused some licensing trouble in the past: https://bugzilla.redhat.com/show_bug.cgi?id=176981 and especially https://bugzilla.redhat.com/show_bug.cgi?id=236309 According to the second link it was removed from F-7 because of the fact that it contained some Sun-licensed files. I downloaded the software from its current website: http://www.lowagie.com/iText/download.html The website claims a dual MPLv1.1 / LGPL license. Inside the package there is a text file (core/com/lowagie/text/misc_licenses.txt), which I will paste to the bottom of this email. What is the current status of iText on Fedora? Was there a discussion? Can we consider releasing it again? -----misc_licenses.txt----- (1) ExceptionConverter: The original version of this class was published in an article by Heinz Kabutz. Read http://www.javaspecialists.co.za/archive/newsletter.do?issue=033&print=yes&locale=en_US "This material from The Java(tm) Specialists' Newsletter by Maximum Solutions (South Africa). Please contact Maximum Solutions for more information. (2) SimpleXMLParser: The original version of this class was published in a JavaWorld article by Steven Brandt: http://www.javaworld.com/javaworld/javatips/jw-javatip128.html Jennifer Orr (JavaWorld) wrote: "You have permission to use the code appearing in Steven Brandt's JavaWorld article, 'Java Tip 128: Create a quick-and-dirty XML parser.' We ask that you reference the author as the creator and JavaWorld as the original publisher of the code." Steven Brandt also agreed with the use of this class. (3) The following files contain material that was copyrighted by SUN: com/lowagie/text/pdf/LZWDecoder.java (first appearance in iText: 2002-02-08) com/lowagie/text/pdf/codec/BmpImage.java (first appearance in iText: 2003-06-20) com/lowagie/text/pdf/codec/PngImage.java (first appearance in iText: 2003-04-25) com/lowagie/text/pdf/codec/TIFFDirectory.java (first appearance in iText: 2003-04-09) com/lowagie/text/pdf/codec/TIFFFaxDecoder.java (first appearance in iText: 2003-04-09) com/lowagie/text/pdf/codec/TIFFField.java (first appearance in iText: 2003-04-09) com/lowagie/text/pdf/codec/TIFFLZWDecoder.java (first appearance in iText: 2003-04-09) The original code was released under the BSD license, and contained the following extra restriction: "You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." In a mail sent to Bruno Lowagie on January 23, 2008, Brian Burkhalter (@sun.com) writes: "This code is under a BSD license and supersedes the older codec packages on which your code is based. It also includes numerous fixes among them being the ability to handle a lot of 'broken' TIFFs." Note that numerous fixes were applied to the code used in iText by Paulo Soares, but apart from the fixes there were no essential changes between the code that was originally adapted and the code that is now available under the following license: Copyright (c) 2005 Sun Microsystems, Inc. All Rights Reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Sun Microsystems, Inc. or the names of contributors may be used to endorse or promote products derived from this software without specific prior written permission. This software is provided "AS IS," without a warranty of any kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN MIDROSYSTEMS, INC. ("SUN") AND ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE THIS SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You acknowledge that this software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. The main difference can be found in the final paragraph: the restriction that the source code is not "licensed" in this particular situation has been removed. FYI: Brian also added: "A bit of history might be in order. The codec classes that you used originally were based on some classes included with JAI but not strictly part of JAI. As of Java SE 1.4 an official Image I/O framework was added in javax.imageio.... This frameork supports these formats: Java 1.4: GIF (read only), JPEG, PNG Java 1.5: Added support for BMP and WBMP Java 1.6: Added support for writing GIF The JAI Image I/O Tools packages (jai-imageio-core) were created to support formats handled by JAI but not included in Java SE as well as some new things like JPEG2000." (4) the file com/lowagie/text/pdf/codec/TIFFConstants and some other TIFF related code is derived from LIBTIFF: Copyright (c) 1988-1997 Sam Leffler Copyright (c) 1991-1997 Silicon Graphics, Inc. Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that (i) the above copyright notices and this permission notice appear in all copies of the software and related documentation, and (ii) the names of Sam Leffler and Silicon Graphics may not be used in any advertising or publicity relating to the software without the specific, prior written permission of Sam Leffler and Silicon Graphics. THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. (5) BidiOrder: As stated in the Javadoc comments, materials from Unicode.org are used in the class com/lowagie/text/pdf/BidiOrder.java The following license applies to these materials: http://www.unicode.org/copyright.html#Exhibit1 EXHIBIT 1 UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE Unicode Data Files include all data files under the directories http://www.unicode.org/Public/, http://www.unicode.org/reports/, and http://www.unicode.org/cldr/data/ . Unicode Software includes any source code published in the Unicode Standard or under the directories http://www.unicode.org/Public/, http://www.unicode.org/reports/, and http://www.unicode.org/cldr/data/. NOTICE TO USER: Carefully read the following legal agreement. BY DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING UNICODE INC.'S DATA FILES ("DATA FILES"), AND/OR SOFTWARE ("SOFTWARE"), YOU UNEQUIVOCALLY ACCEPT, AND AGREE TO BE BOUND BY, ALL OF THE TERMS AND CNDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE, DO NOT DOWNLOAD, INSTALL, COP, DISTRIBUTE OR USE THE DATA FILES OR SOFTWARE. ALL OF THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE, DO NOT DOWNLOAD, INSTALL, COPY, DISTRIBUTE OR USE THE DATA FILES OR SOFTWARE. COPYRIGHT AND PERMISSION NOTICE Copyright (C) 1991-2007 Unicode, Inc. All rights reserved. Distributed under the Terms of Use in http://www.unicode.org/copyright.html. Permission is hereby granted, free of charge, to any person obtaining a copy of the Unicode data files and any associated documentation (the "Data Files") or Unicode software and any associated documentation (the "Software") to deal in the Data Files or Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Data Files or Software, and to permit persons to whom the Data Files or Software are furnished to do so, provided that (a) the above copyright notice(s) and this permission notice appear with all copies of the Data Files or Software, (b) both the above copyright notice(s) and this permission notice appear in associated documentation, and (c) there is clear notice in each modified Data File or in the Software as well as in the documentation associated with the Data File(s) or Software that the data or software has been modified. THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTAILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA FILES OR SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in these Data Files or Software without prior written authorization of the copyright holder. From overholt at redhat.com Tue Sep 30 12:46:32 2008 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 30 Sep 2008 08:46:32 -0400 Subject: [fedora-java] iText status? In-Reply-To: <346371.20271.qm@web32808.mail.mud.yahoo.com> References: <346371.20271.qm@web32808.mail.mud.yahoo.com> Message-ID: <20080930124631.GC3466@redhat.com> Hi Orcan, * Orcan Ogetbil [2008-09-30 01:35]: > What is the current status of iText on Fedora? Was there a discussion? > Can we consider releasing it again? I'm not sure that anyone's looked at it since the original problem. If you'd like to take the lead on figuring out the legalities and working with Fedora Legal, it would be much appreciated. Andrew