From overholt at redhat.com Fri Jan 16 16:01:59 2009 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 16 Jan 2009 11:01:59 -0500 Subject: [fedora-java] Packaging BIRT Message-ID: <20090116160157.GA6944@redhat.com> Hi, I took a brief look at BIRT dependencies using the PDE dependency visualizer [1]. I've attached its PNG output for org.eclipse.birt.chart.device.swt and org.eclipse.birt.chart.examples (what I thought would be a decent high-level bundle). It looks like we should have most of the necessary dependencies in Fedora already (or up for review): batik fop avalon-{framework.logkit} eclipse-emf We'll have to add OSGi metadata matching what's in Orbit to batik, fop, and possibly avalon-*. It looks like we've already got it for commons codec. After that, I'm hoping we'll be able to use RPM Stubby [2] to help us package BIRT :) Help is always more than welcome if anyone's interested. I can elaborate if necessary. The reason we're interested in doing this is so that once they've had a release, we can get the eclipse.org Linux Tools project's Valgrind tools [3] into Fedora. Thanks, Andrew [1] http://www.eclipse.org/pde/incubator/dependency-visualization/index.php The key piece of information I needed to get it to work was that I had to right-click in the view to specify a bundle [2] http://www.eclipse.org/linuxtools/projectPages/rpmstubby [3] http://www.eclipse.org/linuxtools/projectPages/valgrind -------------- next part -------------- A non-text attachment was scrubbed... Name: birtexamples.png Type: image/png Size: 107265 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: birt-swt.png Type: image/png Size: 42871 bytes Desc: not available URL: From overholt at redhat.com Fri Jan 23 19:51:12 2009 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 23 Jan 2009 14:51:12 -0500 Subject: [fedora-java] OpenJDK/IcedTea rt.jar hacking Message-ID: <1232740272.3992.0.camel@vvvvt> I saw this blog entry and thought it would be of interest to people here: http://galder.zamarreno.com/?p=256 Andrew From foster at in.tum.de Mon Jan 26 12:44:04 2009 From: foster at in.tum.de (Mary Ellen Foster) Date: Mon, 26 Jan 2009 13:44:04 +0100 Subject: [fedora-java] Very slow Eclipse on F10 Message-ID: Before I file this in bugzilla, I wanted to check if it's just my problem ... Lately, in Eclipse (3.4.1 on Fedora 10), I've been noticing that it takes several seconds to open a new editor. So if I click on a Java source file (in Java perspective), the new tab appears immediately, but it takes several seconds for the actual editor to finish rendering. In the meantime, the tab just says "Java editor". Similar things happen with the Ant buildfile editor. I have several third-party plugins installed that I don't want to remove unless I have to, which is why I wanted to check first -- is anyone else seeing similar symptoms? Thanks, MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From aph at redhat.com Mon Jan 26 12:48:59 2009 From: aph at redhat.com (Andrew Haley) Date: Mon, 26 Jan 2009 12:48:59 +0000 Subject: [fedora-java] Very slow Eclipse on F10 In-Reply-To: References: Message-ID: <497DB13B.1080103@redhat.com> Mary Ellen Foster wrote: > Before I file this in bugzilla, I wanted to check if it's just my > problem ... Lately, in Eclipse (3.4.1 on Fedora 10), I've been > noticing that it takes several seconds to open a new editor. So if I > click on a Java source file (in Java perspective), the new tab appears > immediately, but it takes several seconds for the actual editor to > finish rendering. In the meantime, the tab just says "Java editor". > Similar things happen with the Ant buildfile editor. > > I have several third-party plugins installed that I don't want to > remove unless I have to, which is why I wanted to check first -- is > anyone else seeing similar symptoms? It depends on which Java you have installed. Try this: $ alternatives --config java There are 2 programs which provide 'java'. Selection Command ----------------------------------------------- *+ 1 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java 2 /usr/lib/jvm/jre-1.5.0-gcj/bin/java If you're on x86, select openjdk. If you don't see openjdk, yum install java-1.6.0-openjdk-devel Andrew. From overholt at redhat.com Mon Jan 26 13:03:26 2009 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 26 Jan 2009 08:03:26 -0500 Subject: [fedora-java] Very slow Eclipse on F10 In-Reply-To: References: Message-ID: <20090126130325.GA3386@redhat.com> * Mary Ellen Foster [2009-01-26 07:44]: > I have several third-party plugins installed that I don't want to > remove unless I have to, which is why I wanted to check first -- is > anyone else seeing similar symptoms? No. This should be fun to track down ;) Andrew From foster at in.tum.de Mon Jan 26 13:34:08 2009 From: foster at in.tum.de (Mary Ellen Foster) Date: Mon, 26 Jan 2009 14:34:08 +0100 Subject: [fedora-java] Very slow Eclipse on F10 In-Reply-To: <20090126130325.GA3386@redhat.com> References: <20090126130325.GA3386@redhat.com> Message-ID: On Mon, Jan 26, 2009 at 2:03 PM, Andrew Overholt wrote: > * Mary Ellen Foster [2009-01-26 07:44]: >> I have several third-party plugins installed that I don't want to >> remove unless I have to, which is why I wanted to check first -- is >> anyone else seeing similar symptoms? > > No. This should be fun to track down ;) I just tried with a fresh ~/.eclipse directory and a fresh workspace -- and with both OpenJDK and GCJ -- and it still takes a very perceptible amount of time to open files. Here's a video: http://www6.informatik.tu-muenchen.de/~foster/eclipse.ogg Using the fresh ~/.eclipse should have got rid of the third-party plugins, but I still have a few Fedora plugins -- CDT, mylyn, and subclipse. Maybe those are an issue ... can't test much more at the moment but I'll fiddle around later. Not much help yet, unfortunately. Maybe I should look upstream and see if anyone's reported similar issues. MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Mon Jan 26 13:59:43 2009 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 26 Jan 2009 08:59:43 -0500 Subject: [fedora-java] Very slow Eclipse on F10 In-Reply-To: References: <20090126130325.GA3386@redhat.com> Message-ID: <20090126135943.GA4569@redhat.com> * Mary Ellen Foster [2009-01-26 08:34]: > On Mon, Jan 26, 2009 at 2:03 PM, Andrew Overholt wrote: > > * Mary Ellen Foster [2009-01-26 07:44]: > >> I have several third-party plugins installed that I don't want to > >> remove unless I have to, which is why I wanted to check first -- is > >> anyone else seeing similar symptoms? > > > > No. This should be fun to track down ;) > > I just tried with a fresh ~/.eclipse directory and a fresh workspace > -- and with both OpenJDK and GCJ -- and it still takes a very > perceptible amount of time to open files. Here's a video: > http://www6.informatik.tu-muenchen.de/~foster/eclipse.ogg Hmm. What about opening a second .java file? Once the JDT UI plugins are (lazily) loaded they should be much faster. > Using the fresh ~/.eclipse should have got rid of the third-party > plugins That's correct. > Not much help yet, unfortunately. Maybe I should look upstream and see > if anyone's reported similar issues. Yeah. It would be nice if we had an easy way to profile this. Other than the TPTP (eclipse.org/tptp) profiler, I can't think of one OTTOMH. It would be an interesting project to see what's the best option out there. Andrew From foster at in.tum.de Mon Jan 26 14:07:28 2009 From: foster at in.tum.de (Mary Ellen Foster) Date: Mon, 26 Jan 2009 15:07:28 +0100 Subject: [fedora-java] Very slow Eclipse on F10 In-Reply-To: <20090126135943.GA4569@redhat.com> References: <20090126130325.GA3386@redhat.com> <20090126135943.GA4569@redhat.com> Message-ID: On Mon, Jan 26, 2009 at 2:59 PM, Andrew Overholt wrote: > * Mary Ellen Foster [2009-01-26 08:34]: >> I just tried with a fresh ~/.eclipse directory and a fresh workspace >> -- and with both OpenJDK and GCJ -- and it still takes a very >> perceptible amount of time to open files. Here's a video: >> http://www6.informatik.tu-muenchen.de/~foster/eclipse.ogg > > Hmm. What about opening a second .java file? Once the JDT UI plugins > are (lazily) loaded they should be much faster. I thought that would be true too, but unfortunately it doesn't get much faster when opening subsequent files. And all editors seem to be equally slow, including the plain-text editor. I'll try this at home tonight on my laptop and see if it happens there too; might be something weird on this computer. MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Wed Jan 28 16:10:49 2009 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 28 Jan 2009 11:10:49 -0500 Subject: [fedora-java] [Fwd: [Bug 471811] RfE: Need CNI sub package to resurrect pdftk] Message-ID: <1233159049.5224.6.camel@vvvvt> Can anyone with CNI experience please help with this bug? I have heard of lots of people using pdftk and it would be nice if it was available in Fedora. Andrew -------- Forwarded Message -------- > https://bugzilla.redhat.com/show_bug.cgi?id=471811 > > > Orcan 'oget' Ogetbil changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |CLOSED > Resolution| |WONTFIX > > > > > --- Comment #9 from Orcan 'oget' Ogetbil 2009-01-24 21:37:32 EDT --- > Well, nobody stepped up to patch neither itext nor pdftk to make pdftk link to > our itext dynamically. This task is rather involved as it will require JNI > knowledge and possibly some java fixes within pdftk which might be incompatible > with the current version of itext and bouncycastle we have. I am no java > programmer. > > But I got several user requests at fedoraforum to package pdftk. We can do this > at rpmfusion. If someone does the necessary work (and keeps doing it for every > itext update), we'll drop pdftk from rpmfusion and put it back here. > > Jochen, would you like to do the packaging at rpmfusion (I will review it > there) or do you want me to do it? > > Closing the bug as WONTFIX. From overholt at redhat.com Wed Jan 28 16:42:56 2009 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 28 Jan 2009 11:42:56 -0500 Subject: [fedora-java] Suggestions to improve the JAVA guidelines In-Reply-To: <827884.78114.qm@web32808.mail.mud.yahoo.com> References: <827884.78114.qm@web32808.mail.mud.yahoo.com> Message-ID: <1233160976.5224.18.camel@vvvvt> Hi, Sorry no one responded earlier. I'm in the process of trying to get all of these questions/comments into the Talk page [1] of the guidelines [2]. On Wed, 2008-11-19 at 00:36 -0800, Orcan Ogetbil wrote: > As I promised overholt on IRC, I wanted to share my views about the > Fedora Java packaging guidelines from a non-Java-coder point of view. Thanks! > - In certain cases, we can build applications GCJ-natively > (producing .so files). But these won't work with any JVM. The .so files will only be used by gij but the corresponding .class files will be the same and will be used by other JVMs. > What should be the packager's primary preference? GCJ-native or > OpenJDK? The first one runs faster, but the second one has larger > coverage. Many people said they want to keep GCJ AOT bits for F11 so I guess that will continue to be the preference. > For instance, tuxguitar (that I packaged) provides GNU Makefiles (that > use GCJ) for this. Are the resulting .so files going to be the same as > the ones built by aot-compile-rpm? (More about AOT later) I don't know what tuxguitar is doing, but this small explanation from a non-GCJ expert may help: - gcj can compile java code in one of two ways: 1) .java source directly to C++-style .so files 2) java bytecode (.class files) to special GCJ-only .so files - in case 2) above, the package will ship *both* the .class files (usually in a .jar) *and* the GCJ .so files. The GCJ .so files will *only* be read by gij -- the GCJ java bytecode interpreter -- and not by other JVMs. Since GCJ is an ahead-of-time (AOT) compiler and has no just-in-time (JIT) compiler like HotSpot, using these pre-compiled .so files is faster than purely interpreting the java bytecode. The presence of the AOT .so files (sometimes referred to as "GCJ AOT bits") is inconsequential to JVMs other than gij/gcj. I hope this helps. Like I said, I'm trying to capture outstanding issues with the guidelines on the talk page in the hopes that we can drive this to some fixes. Andrew [1] https://fedoraproject.org/w/index.php?title=Packaging_talk:Java [2] http://fedoraproject.org/wiki/Packaging/Java From foster at in.tum.de Thu Jan 29 16:39:24 2009 From: foster at in.tum.de (Mary Ellen Foster) Date: Thu, 29 Jan 2009 17:39:24 +0100 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs Message-ID: I'm playing around with a couple of Eclipse plugin packages that are almost ready to go up for review. They both now build cleanly on my (i386) computer in mock, so I decided to try out koji. One of them reproduceably fails to build on x86_64 and ppc64, with errors like this: Building feature = org.vimplugin.feature. Symlinking SDK into /builddir/build/BUILD/eclipse-vimplugin-0.3.4/build/SDK directory. /bin/sh /usr/lib64/eclipse/buildscripts/copy-platform /builddir/build/BUILD/eclipse-vimplugin-0.3.4/build/SDK /usr/lib64/eclipse ln: creating symbolic link `about.html' : File exists ln: creating symbolic link `artifacts.xml': File exists ln: creating symbolic link `configuration' : File exists (lots more errors of this type can be seen in the build.log under https://koji.fedoraproject.org/koji/taskinfo?taskID=1091518 or https://koji.fedoraproject.org/koji/taskinfo?taskID=1091543) This failure (a) doesn't happen with the other plugin I just built in koji (https://koji.fedoraproject.org/koji/taskinfo?taskID=1091481), and (b) doesn't happen on i386 or ppc (https://koji.fedoraproject.org/koji/taskinfo?taskID=1091529). pdebuild is basically a mystery to me ... any idea what's going on? MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Thu Jan 29 17:23:56 2009 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 29 Jan 2009 12:23:56 -0500 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs In-Reply-To: References: Message-ID: <20090129172356.GA4971@redhat.com> Hi, * Mary Ellen Foster [2009-01-29 11:47]: > I'm playing around with a couple of Eclipse plugin packages that are > almost ready to go up for review. They both now build cleanly on my > (i386) computer in mock, so I decided to try out koji. This sounds like a bug in pdebuild (aka Andrew's crap-tacular shell script). Can you send me a pointer to the SRPM? I'm on x86_64 so will hopefully be able to figure out what's going on. Thanks, Andrew From foster at in.tum.de Thu Jan 29 17:58:01 2009 From: foster at in.tum.de (Mary Ellen Foster) Date: Thu, 29 Jan 2009 18:58:01 +0100 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs In-Reply-To: <20090129172356.GA4971@redhat.com> References: <20090129172356.GA4971@redhat.com> Message-ID: On Thu, Jan 29, 2009 at 6:23 PM, Andrew Overholt wrote: > This sounds like a bug in pdebuild (aka Andrew's crap-tacular shell > script). Can you send me a pointer to the SRPM? I'm on x86_64 so will > hopefully be able to figure out what's going on. I'm at home using my netbook now and having a bit of difficulty loading koji, but you should be able to get the SRPMs from this successful (ExcludeArch *64) build: https://koji.fedoraproject.org/koji/taskinfo?taskID=1091529 Don't forget to remove the ExcludeArch in the spec. :) Thanks for any help you can give, MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From foster at in.tum.de Fri Jan 30 10:47:47 2009 From: foster at in.tum.de (Mary Ellen Foster) Date: Fri, 30 Jan 2009 11:47:47 +0100 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs In-Reply-To: References: <20090129172356.GA4971@redhat.com> Message-ID: On Thu, Jan 29, 2009 at 6:58 PM, Mary Ellen Foster wrote: > On Thu, Jan 29, 2009 at 6:23 PM, Andrew Overholt wrote: >> This sounds like a bug in pdebuild (aka Andrew's crap-tacular shell >> script). Can you send me a pointer to the SRPM? I'm on x86_64 so will >> hopefully be able to figure out what's going on. It actually seems to be a very weird problem in copy-platform, and I can't figure out why. On my i386 machine, copy-platform contains a bunch of lines like this: [ ! -e about.html ] && ln -s $eclipse/about.html about.html [ ! -e artifacts.xml ] && ln -s $eclipse/artifacts.xml artifacts.xml And on 64-bit platforms, all of those lines are failing with "File exists" which shouldn't be POSSIBLE, should it?! (But only with this one plugin, and not with others ...) I took a look at the contents of this file from the 64-bit version of eclipse-pde, but it seems to be basically identical so no luck there. Hmph. Back to $DAYJOB now ... MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Fri Jan 30 15:39:56 2009 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 30 Jan 2009 10:39:56 -0500 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs In-Reply-To: References: <20090129172356.GA4971@redhat.com> Message-ID: <20090130153956.GA9835@redhat.com> I think the problem may stem from the fact that there is already a build and build/SDK directory (with symlink contents) in your source tarball. Andrew From foster at in.tum.de Fri Jan 30 16:08:42 2009 From: foster at in.tum.de (Mary Ellen Foster) Date: Fri, 30 Jan 2009 17:08:42 +0100 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs In-Reply-To: <20090130153956.GA9835@redhat.com> References: <20090129172356.GA4971@redhat.com> <20090130153956.GA9835@redhat.com> Message-ID: On Fri, Jan 30, 2009 at 4:39 PM, Andrew Overholt wrote: > I think the problem may stem from the fact that there is already a build > and build/SDK directory (with symlink contents) in your source tarball. Huh. Okay, never noticed that part, I'll just delete it before building. So why does it only fail on 64-bit machines then? MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Fri Jan 30 16:15:54 2009 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 30 Jan 2009 11:15:54 -0500 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs In-Reply-To: References: <20090129172356.GA4971@redhat.com> <20090130153956.GA9835@redhat.com> Message-ID: <20090130161554.GB11193@redhat.com> * Mary Ellen Foster [2009-01-30 11:09]: > On Fri, Jan 30, 2009 at 4:39 PM, Andrew Overholt wrote: > > I think the problem may stem from the fact that there is already a build > > and build/SDK directory (with symlink contents) in your source tarball. > > Huh. Okay, never noticed that part, I'll just delete it before > building. So why does it only fail on 64-bit machines then? I'm not 100% sure but I think it's 'cause the broken symlinks in the source tarball are to /usr/lib/eclipse stuff which doesn't exist on x86_64. Andrew From foster at in.tum.de Fri Jan 30 16:33:32 2009 From: foster at in.tum.de (Mary Ellen Foster) Date: Fri, 30 Jan 2009 17:33:32 +0100 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs In-Reply-To: <20090130161554.GB11193@redhat.com> References: <20090129172356.GA4971@redhat.com> <20090130153956.GA9835@redhat.com> <20090130161554.GB11193@redhat.com> Message-ID: On Fri, Jan 30, 2009 at 5:15 PM, Andrew Overholt wrote: > * Mary Ellen Foster [2009-01-30 11:09]: >> On Fri, Jan 30, 2009 at 4:39 PM, Andrew Overholt wrote: >> > I think the problem may stem from the fact that there is already a build >> > and build/SDK directory (with symlink contents) in your source tarball. >> >> Huh. Okay, never noticed that part, I'll just delete it before >> building. So why does it only fail on 64-bit machines then? > > I'm not 100% sure but I think it's 'cause the broken symlinks in the > source tarball are to /usr/lib/eclipse stuff which doesn't exist on > x86_64. Aha, yes, of course -- "test -e broken-symlink" returns false because it follows the link. That explains it. So if I delete the "build" directory first, things seem to build cleanly on all architectures: https://koji.fedoraproject.org/koji/taskinfo?taskID=1094129 Yay! Expect to see a couple of new Eclipse plugins going up for review in the next few days. :) MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Fri Jan 30 16:39:44 2009 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 30 Jan 2009 11:39:44 -0500 Subject: [fedora-java] Help me understand (and fix!) this pdebuild failure on 64-bit archs In-Reply-To: References: <20090129172356.GA4971@redhat.com> <20090130153956.GA9835@redhat.com> <20090130161554.GB11193@redhat.com> Message-ID: <20090130163944.GB14500@redhat.com> * Mary Ellen Foster [2009-01-30 11:37]: > So if I delete the "build" directory first, things seem to build > cleanly on all architectures: > https://koji.fedoraproject.org/koji/taskinfo?taskID=1094129 > Yay! Cool, I'm glad it builds. > Expect to see a couple of new Eclipse plugins going up for review in > the next few days. :) :) Andrew