From veillard at redhat.com Tue Jul 1 15:43:58 2008 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 1 Jul 2008 11:43:58 -0400 Subject: [fedora-java] libvirt-java bindings Message-ID: <20080701154358.GC10402@redhat.com> Hi, I have just started to release and package java bindings for libvirt. I have made a request for review for Fedora on the new package: https://bugzilla.redhat.com/show_bug.cgi?id=453119 I found the exercise rather hard, JNI is of course on the edge of the Java land, but it's hard to find good resources to look at for Java bindings in Fedora, the gnome-java stuff seems very specific, and a lot of packages basically rely on gcj for compilation of any JNI stuff. I would like something more flexible, to that end I added some JDK dynamic detection in configure.in for my package, which then allows to guess the jni.h and jni_md.h based on the javah and javac used to generate the bindings (so things should stay consistent). In the spec file I used the following: %define java java and Requires: %{java} >= 1.5.0 BuildRequires: %{java}-devel >= 1.5.0 to easilly allow the user to specify more strictly what java development package to use. I don't know if this is sufficient in general for the previous versions of Fedora, it seems to work with java-1.6.0-openjdk in F-9 or something as old as java-1.5.0-ibm-1.5.0.7 on a RHEL-4 box, but the java class compilations break for example with java-1.5.0-gcj [-devel] on Fedora-8 (didn't tried icedtea yet, though I guess that would work) this looks related to dependancies when compiling a bunch of .java together in one command as /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java 2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14) credType= new VirConnectCredential.VirConnectCredentialType[] { ^^^^^^^^ credType cannot be resolved though VirConnectCredential.java is there and defines the type. Portability tricks and eyeballs for the review would be very welcome ! (as well as patches to improve the package source of course but that would be best conducted on the libvirt list). thanks in advance, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From aph at redhat.com Tue Jul 1 15:54:33 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 01 Jul 2008 16:54:33 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080701154358.GC10402@redhat.com> References: <20080701154358.GC10402@redhat.com> Message-ID: <486A5339.6090703@redhat.com> Daniel Veillard wrote: > the java class compilations break for example with java-1.5.0-gcj [-devel] > on Fedora-8 (didn't tried icedtea yet, though I guess that would work) > this looks related to dependancies when compiling a bunch of .java > together in one command as > > /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java > 2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14) > credType= new VirConnectCredential.VirConnectCredentialType[] { > ^^^^^^^^ > credType cannot be resolved > > though VirConnectCredential.java is there and defines the type. Hmm. I think we need to find out if this is a real bug in ecj, and fix it if so. I can't remember seeing anything like this before. Can you create a stand-alone test case that shows this failure? I can't figure out how to do so. I don't think we should target a particular Java compiler if that can be avoided. Andrew. From ranger at opennms.org Tue Jul 1 16:15:14 2008 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 01 Jul 2008 12:15:14 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080701154358.GC10402@redhat.com> References: <20080701154358.GC10402@redhat.com> Message-ID: <486A5812.8090401@opennms.org> Daniel Veillard wrote: > Portability tricks and eyeballs for the review would be very welcome ! It also still wouldn't work with the official sun RPMs, which I wish we had some kind of simpler solution for, interoperability-wise. At least making it a define of some kind would make it easy to generate the packages twice, once for fedora deps, and once for sun deps. ie, instead of: > %define java java ...you could do something like this instead: %{!?java_requires:%define java_requires java} %{!?java_buildrequires:%define java_buildrequires java-devel} %{!?java_min_version:%define java_min_version 1.5.0} > and > Requires: %{java} >= 1.5.0 > BuildRequires: %{java}-devel >= 1.5.0 ...and then: Requires: %{java_requires} >= %{java_min_version} BuildRequires: %{java_buildrequires} >= %{java_min_version} This lets you do: rpmbuild \ --define "java_requires jre" \ --define "java_buildrequires jdk" \ --define "java-min_version 1.6.0" \ -ba mypackage.spec ...to override the defaults. (I think that's the right syntax...) -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From david at zarb.org Tue Jul 1 16:24:49 2008 From: david at zarb.org (David Walluck) Date: Tue, 01 Jul 2008 12:24:49 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080701154358.GC10402@redhat.com> References: <20080701154358.GC10402@redhat.com> Message-ID: <486A5A51.8030203@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Veillard wrote: | I would like something more flexible, to that end I added some JDK dynamic | detection in configure.in for my package, which then allows to guess the | jni.h and jni_md.h based on the javah and javac used to generate the bindings | (so things should stay consistent). | In the spec file I used the following: There is no need since java and java-devel are virtual Provides provided by every compliant JDK, so the user is already allowed to choose the JDK that they want to build with. Also, there are macros that should be used when refering to the JDK so that you pick up the default JDK used for building and not the current default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}). Unfortunately, there are recent packages passing the Fedora review that directly specify java-1.6.0-openjdk-devel as the JDK and I personally don't like this. I think that this comes from two schools of thought: one group wants to tie the Fedora package even more tightly to Fedora and the other wants to leave the options open. Since Fedora more-or-less has only one JDK (or two counting GCJ which is optional), this benefit is mostly theoretical, but you can see from the current discussion that it can be useful. Similarly, since Fedora can force the default JDK setup at build time through the build system, although the packages are technically not as flexible as they could be, it's never really a problem in practice. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkhqWlAACgkQItObMyg2XCUpNgCghlrnFGtwJPikTBuBxLCCNLLe 3r0AnRs5bIeVxAruG1Ri/bkhQuYwY/63 =6Tqq -----END PGP SIGNATURE----- From foster at in.tum.de Tue Jul 1 16:35:47 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Tue, 1 Jul 2008 17:35:47 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A5A51.8030203@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> Message-ID: 2008/7/1 David Walluck : > Unfortunately, there are recent packages passing the Fedora review that > directly specify java-1.6.0-openjdk-devel as the JDK and I personally > don't like this. I have one recent package that does this (specifies openjdk on F9+ and icedtea on F8) and one that doesn't (just wants java >= 1.5). The first package uses JNI and needs a Sun-like JVM to work (or at least it took more autotools hacking than I cared to try to make it work), and if I just put Requires: java it tended to grab gcj. I guess I could also put java > 1.5, but the issue isn't the 1.5-ness, it's the Sun-style JNI classes. (The packages are pl-jpl and ice-java, respectively, if you're wondering). 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 mefoster at gmail.com Tue Jul 1 16:36:56 2008 From: mefoster at gmail.com (Mary Ellen Foster) Date: Tue, 1 Jul 2008 17:36:56 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A5339.6090703@redhat.com> References: <20080701154358.GC10402@redhat.com> <486A5339.6090703@redhat.com> Message-ID: [ oops, just replied to Andrew the first time ... ] 2008/7/1 Andrew Haley : > Daniel Veillard wrote: >> the java class compilations break for example with java-1.5.0-gcj [-devel] >> on Fedora-8 (didn't tried icedtea yet, though I guess that would work) >> this looks related to dependancies when compiling a bunch of .java >> together in one command as >> >> /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java >> 2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14) >> credType= new VirConnectCredential.VirConnectCredentialType[] { >> ^^^^^^^^ >> credType cannot be resolved >> >> though VirConnectCredential.java is there and defines the type. > > Hmm. I think we need to find out if this is a real bug in ecj, and > fix it if so. I can't remember seeing anything like this before. > > Can you create a stand-alone test case that shows this failure? I can't > figure out how to do so. I think the problem might actually be a lack of "-source 1.5" on the javac line, actually. Without that, it doesn't seem to like the "enum" declarations and doesn't create any of the enum classes, resulting in the above error (and, if you scroll down, errors about the enum declarations too). This is testing with java-1.5.0-gcj-devel-1.5.0.0-17.fc8 on Fedora 8, FWIW. 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 Tue Jul 1 16:39:20 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 01 Jul 2008 17:39:20 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: References: <20080701154358.GC10402@redhat.com> <486A5339.6090703@redhat.com> Message-ID: <486A5DB8.10708@redhat.com> Mary Ellen Foster wrote: > [ oops, just replied to Andrew the first time ... ] > > 2008/7/1 Andrew Haley : >> Daniel Veillard wrote: >>> the java class compilations break for example with java-1.5.0-gcj [-devel] >>> on Fedora-8 (didn't tried icedtea yet, though I guess that would work) >>> this looks related to dependancies when compiling a bunch of .java >>> together in one command as >>> >>> /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java >>> 2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14) >>> credType= new VirConnectCredential.VirConnectCredentialType[] { >>> ^^^^^^^^ >>> credType cannot be resolved >>> >>> though VirConnectCredential.java is there and defines the type. >> Hmm. I think we need to find out if this is a real bug in ecj, and >> fix it if so. I can't remember seeing anything like this before. >> >> Can you create a stand-alone test case that shows this failure? I can't >> figure out how to do so. > > I think the problem might actually be a lack of "-source 1.5" on the > javac line, actually. Without that, it doesn't seem to like the "enum" > declarations and doesn't create any of the enum classes, resulting in > the above error (and, if you scroll down, errors about the enum > declarations too). > > This is testing with java-1.5.0-gcj-devel-1.5.0.0-17.fc8 on Fedora 8, FWIW. Okay, thanks. That should be easy to fix then. Daniel, please try that and report. I could have sworn that we changed the default for ecj to 1.5. We surely should have done. Andrew. From ranger at opennms.org Tue Jul 1 16:42:18 2008 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 01 Jul 2008 12:42:18 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A5A51.8030203@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> Message-ID: <486A5E6A.6080505@opennms.org> David Walluck wrote: > Also, there are macros that should be used when refering to the JDK so > that you pick up the default JDK used for building and not the current > default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}). Aha, I was not aware of these defines. > Unfortunately, there are recent packages passing the Fedora review that > directly specify java-1.6.0-openjdk-devel as the JDK and I personally > don't like this. > > I think that this comes from two schools of thought: one group wants to > tie the Fedora package even more tightly to Fedora and the other wants > to leave the options open. Since Fedora more-or-less has only one JDK > (or two counting GCJ which is optional), this benefit is mostly > theoretical, but you can see from the current discussion that it can be > useful. Similarly, since Fedora can force the default JDK setup at build > time through the build system, although the packages are technically not > as flexible as they could be, it's never really a problem in practice. My main issue is that as a package maintainer, if I want to support Fedora officially *and* other RPM-based distributions (through our own yum repository) I have doubled my workload since I need to make packages that use fedora-style dependencies for fedora, and package that use sun-jdk-style dependencies for everyone else. Right now I depend on "jdk" and everything works peachy everywhere, we make a .noarch.rpm and it runs on every supported RPM platform on the planet. Depending on java-1.6.0-openjdk-devel is the worst of the options, from a 3rd-party-packager point of view. However, now that I know about the fedora %{java_home} macros, perhaps a better option is to provide fallback macros for various compatibility levels. IE, for building my generic everyone-but-fedora packages I would have a "sun-java-macros" set (in ~/.rpmmacros?) that would set %{java_home} to /usr/java/jdk1.6.0_05, %{jdk} to jdk (the sun package name) %{jdk_version} to 2000:1.6.0_05 and so on, and do: Requires: %{jre} >= %{jre_version} BuildRequires: %{jdk} >= %{jdk_version} %build JAVA_HOME=%{java_home} mvn install assembly:directory-inline ...and on fedora, it would fill those macros in to use the openjdk-provided deps, or if someone needs something specific, they can set %{jre} or %{jdk} to a specific package name. It still wouldn't leave me with a universal "opennms.noarch.rpm" which would be best, but it would simplify generating distro-specific rpms. Not that I can't generate spec files to work with fedora with a script or something, it just seems really lame to have to special case "fc9" vs "!fc9" specifically. =) -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From david at zarb.org Tue Jul 1 18:01:33 2008 From: david at zarb.org (David Walluck) Date: Tue, 01 Jul 2008 14:01:33 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A5E6A.6080505@opennms.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A5E6A.6080505@opennms.org> Message-ID: <486A70FD.90605@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benjamin Reed wrote: | David Walluck wrote: | |> Also, there are macros that should be used when refering to the JDK so |> that you pick up the default JDK used for building and not the current |> default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}). | | Aha, I was not aware of these defines. These should be available through the jpackage macros from jpackage-utils (see /etc/rpm/macros.jpackage). | My main issue is that as a package maintainer, if I want to support | Fedora officially *and* other RPM-based distributions (through our own Not at all. If you follow the JPackage conventions you will support any distribution which carries jpackage-utils. These include: ALT, Fedora, Mandriva, PCLOS, Red Hat, Suse, and possibly others. This means using java-devel like I said and not relying on the Sun conventions (this also allows you to support multiple JDK versions and not just multiple Linux distributions with a single JDK version). Also, since Sun supported the DLJ Java packages, at least Mandriva is shipping JPackage-compliant DLJ Sun Java bundles with their OS which would be far superior to any Sun packaging offering due to JPackage compliance. This also means, like I said in a previous email, that I don't think additional macros are needed, but check the macros file first and see if you think anything is missing. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkhqcP0ACgkQItObMyg2XCVXcQCgiVGskRSE2wj8lAR8vwgy0+TF 1kIAoKshQHjcf/AGOhv6EbU0L1RACWk0 =dkhY -----END PGP SIGNATURE----- From david at zarb.org Tue Jul 1 18:08:09 2008 From: david at zarb.org (David Walluck) Date: Tue, 01 Jul 2008 14:08:09 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> Message-ID: <486A7289.2040409@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mary Ellen Foster wrote: | I have one recent package that does this (specifies openjdk on F9+ and | icedtea on F8) and one that doesn't (just wants java >= 1.5). The | first package uses JNI and needs a Sun-like JVM to work (or at least | it took more autotools hacking than I cared to try to make it work), | and if I just put Requires: java it tended to grab gcj. I guess I | could also put java > 1.5, but the issue isn't the 1.5-ness, it's the | Sun-style JNI classes. This is not an issue with the java-devel packages, but rather an issue with either the upstream configure or an issue with the GCJ packaging. If it is lack of JNI support in GCJ, that is one thing. If it is simply that the package is expecting a differnt layout that is another. | (The packages are pl-jpl and ice-java, respectively, if you're wondering). I was not referring specifically to your packages. But I also haven't been able to look and see if there is a simple fix available for GCJ. You should raise the issue on this list though because there are people here who can help with either issue. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkhqcokACgkQItObMyg2XCXywACfTMLzyrvRTVT08cw6zwNZmCum tK0An1nRpk0WuFIlLRJljVaZjTKQSZTO =/Hdt -----END PGP SIGNATURE----- From ranger at opennms.org Tue Jul 1 18:30:55 2008 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 01 Jul 2008 14:30:55 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A70FD.90605@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A5E6A.6080505@opennms.org> <486A70FD.90605@zarb.org> Message-ID: <486A77DF.6090000@opennms.org> David Walluck wrote: > These should be available through the jpackage macros from > jpackage-utils (see /etc/rpm/macros.jpackage). Ah, ok. > | My main issue is that as a package maintainer, if I want to support > | Fedora officially *and* other RPM-based distributions (through our own > > Not at all. If you follow the JPackage conventions you will support any > distribution which carries jpackage-utils. These include: ALT, Fedora, > Mandriva, PCLOS, Red Hat, Suse, and possibly others. OK, I'll give the JPackage stuff another look. My previous foray into jpackage was a mess of hand-building from src.rpms and other craziness just to get around things that were already provided easily from sun or otherwise, and I must admit, I was very turned off by the amount of manual work it took to install something when the whole point is to automate installation. =) If the tools have gotten better, great, I'll give it another shot. > This also means, like I said in a previous email, that I don't think > additional macros are needed, but check the macros file first and see if > you think anything is missing. Yeah, if everything conforms to the java/java-devel stuff, then it should work. Thanks for the response, I'll do more investigation. -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From david at zarb.org Tue Jul 1 18:36:30 2008 From: david at zarb.org (David Walluck) Date: Tue, 01 Jul 2008 14:36:30 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A77DF.6090000@opennms.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A5E6A.6080505@opennms.org> <486A70FD.90605@zarb.org> <486A77DF.6090000@opennms.org> Message-ID: <486A792E.2010208@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benjamin Reed wrote: | My previous foray into jpackage was a mess of hand-building from | src.rpms and other craziness just to get around things that were already | provided easily from sun or otherwise, and I must admit, I was very | turned off by the amount of manual work it took to install something | when the whole point is to automate installation. =) If you are looking for a single monolithic package with no dependencies, then it will not do that (but then generally neither will Fedora or any other RPM-based distribution). Otherwise, raise the specific concerns as you come across them and we will see if it has to be that way or if there is some technical solution. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkhqeS4ACgkQItObMyg2XCXS2gCfc8PaiuCupRfRvSeIjz9uhsWR SZoAn3kEJeY4+VPomR2KT1Df72I3S5B/ =0ETY -----END PGP SIGNATURE----- From lfarkas at lfarkas.org Tue Jul 1 19:40:53 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 01 Jul 2008 21:40:53 +0200 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080701154358.GC10402@redhat.com> References: <20080701154358.GC10402@redhat.com> Message-ID: <486A8845.2080606@lfarkas.org> Daniel Veillard wrote: > Hi, > > I have just started to release and package java bindings for libvirt. > I have made a request for review for Fedora on the new package: > https://bugzilla.redhat.com/show_bug.cgi?id=453119 > > I found the exercise rather hard, JNI is of course on the edge of the Java > land, but it's hard to find good resources to look at for Java bindings > in Fedora, the gnome-java stuff seems very specific, and a lot of packages > basically rely on gcj for compilation of any JNI stuff. you may look into jna. gstreamer-java use it. it's much simpler, easier then jni without the above problems. -- Levente "Si vis pacem para bellum!" From veillard at redhat.com Wed Jul 2 09:02:31 2008 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 2 Jul 2008 05:02:31 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: References: <20080701154358.GC10402@redhat.com> <486A5339.6090703@redhat.com> Message-ID: <20080702090231.GB26257@redhat.com> On Tue, Jul 01, 2008 at 05:36:56PM +0100, Mary Ellen Foster wrote: > [ oops, just replied to Andrew the first time ... ] > > 2008/7/1 Andrew Haley : > > Daniel Veillard wrote: > >> the java class compilations break for example with java-1.5.0-gcj [-devel] > >> on Fedora-8 (didn't tried icedtea yet, though I guess that would work) > >> this looks related to dependancies when compiling a bunch of .java > >> together in one command as > >> > >> /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java > >> 2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14) > >> credType= new VirConnectCredential.VirConnectCredentialType[] { > >> ^^^^^^^^ > >> credType cannot be resolved > >> > >> though VirConnectCredential.java is there and defines the type. > > > > Hmm. I think we need to find out if this is a real bug in ecj, and > > fix it if so. I can't remember seeing anything like this before. > > > > Can you create a stand-alone test case that shows this failure? I can't > > figure out how to do so. > > I think the problem might actually be a lack of "-source 1.5" on the > javac line, actually. Without that, it doesn't seem to like the "enum" > declarations and doesn't create any of the enum classes, resulting in > the above error (and, if you scroll down, errors about the enum > declarations too). Haha, yes ! This fixes it. I still gets 3 warnings but not a blocker :-) > This is testing with java-1.5.0-gcj-devel-1.5.0.0-17.fc8 on Fedora 8, FWIW. Right :-) If I understand correctly enum was added in Java 1.5, if I ask about the version I get laptop:~/libvirt-java/src -> /usr/bin/javac -version Eclipse Java Compiler 0.771, 3.3.0, Copyright IBM Corp 2000, 2007. All rights reserved. Maybe the most portable way to fix this is to force that version flag when javac is the Eclipse compiler. I think I will augment the checkings done in configure.in accordingly thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Wed Jul 2 09:14:44 2008 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 2 Jul 2008 05:14:44 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A5A51.8030203@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> Message-ID: <20080702091444.GC26257@redhat.com> On Tue, Jul 01, 2008 at 12:24:49PM -0400, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel Veillard wrote: > | I would like something more flexible, to that end I added some JDK dynamic > | detection in configure.in for my package, which then allows to guess the > | jni.h and jni_md.h based on the javah and javac used to generate the > bindings > | (so things should stay consistent). > | In the spec file I used the following: > > There is no need since java and java-devel are virtual Provides provided > by every compliant JDK, so the user is already allowed to choose the JDK > that they want to build with. > > Also, there are macros that should be used when refering to the JDK so > that you pick up the default JDK used for building and not the current > default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}). Hum, interesting, butthat's very dependant on the build environment. For example if I rebuild the RPM for RHELv4 those macro define won't exist I don't think I should rely on this for a really generic spec file. > Unfortunately, there are recent packages passing the Fedora review that > directly specify java-1.6.0-openjdk-devel as the JDK and I personally > don't like this. > > I think that this comes from two schools of thought: one group wants to > tie the Fedora package even more tightly to Fedora and the other wants > to leave the options open. Since Fedora more-or-less has only one JDK > (or two counting GCJ which is optional), this benefit is mostly > theoretical, but you can see from the current discussion that it can be > useful. Similarly, since Fedora can force the default JDK setup at build > time through the build system, although the packages are technically not > as flexible as they could be, it's never really a problem in practice. I think the distro build can already define its own policy of what package should be used when there is a java/java-devel BuildRequires just by the way it selects the package used to create the build root. So %{java_home}, %{java}, %{javac}, %{jar} to me are in a sense redundant in that enviroment. And outside of the distro build the macros are not available and that's where the user selection should be done, so this doesn't help much in the case of a manual user rpmbuild, except maybe if one uses them to override the alternative default. I guess I need to think a bit more about it, but i'm firmly in the camp of those who think the package should be distribution agnostic as much as possible. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Wed Jul 2 09:20:08 2008 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 2 Jul 2008 05:20:08 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A8845.2080606@lfarkas.org> References: <20080701154358.GC10402@redhat.com> <486A8845.2080606@lfarkas.org> Message-ID: <20080702092008.GD26257@redhat.com> On Tue, Jul 01, 2008 at 09:40:53PM +0200, Farkas Levente wrote: > Daniel Veillard wrote: > > Hi, > > > >I have just started to release and package java bindings for libvirt. > >I have made a request for review for Fedora on the new package: > > https://bugzilla.redhat.com/show_bug.cgi?id=453119 > > > >I found the exercise rather hard, JNI is of course on the edge of the Java > >land, but it's hard to find good resources to look at for Java bindings > >in Fedora, the gnome-java stuff seems very specific, and a lot of packages > >basically rely on gcj for compilation of any JNI stuff. > > you may look into jna. gstreamer-java use it. it's much simpler, easier > then jni without the above problems. Well back in 97 we tried to avoid JNI in the Kaffe project, the alternative was more elegant, easier, faster. I think everybody outside of java has hoped or tried to develop different bindings mechanism, unfortunately none prevailed, at this point I will stick with JNI, thanks :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From foster at in.tum.de Wed Jul 2 10:11:34 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Wed, 2 Jul 2008 11:11:34 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486A7289.2040409@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> Message-ID: 2008/7/1 David Walluck : > Mary Ellen Foster wrote: > | I have one recent package that does this (specifies openjdk on F9+ and > | icedtea on F8) and one that doesn't (just wants java >= 1.5). The > | first package uses JNI and needs a Sun-like JVM to work (or at least > | it took more autotools hacking than I cared to try to make it work), > | and if I just put Requires: java it tended to grab gcj. I guess I > | could also put java > 1.5, but the issue isn't the 1.5-ness, it's the > | Sun-style JNI classes. > > This is not an issue with the java-devel packages, but rather an issue > with either the upstream configure or an issue with the GCJ packaging. > > If it is lack of JNI support in GCJ, that is one thing. If it is simply > that the package is expecting a differnt layout that is another. I just did a bit of hacking, and it is possible to build the package against gcj instead of openjdk. There were two things to fix: - the "configure" script followed symlinks from javac to find the JNI include dir. Since the symlinks for gcj ground out at /usr/bin/ecj, it ended up looking for /usr/include/jni.h. - It also wanted to hardcode "-ljava -lverify -ljvm" on the gcc line, which isn't right for gcj But I'm not sure if I want to make these modifications to the package. If I build a JNI program against gcj, can the resulting .so be used with Sun-like JVMs? How does this work? Is it documented anywhere? 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 Wed Jul 2 10:30:09 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 02 Jul 2008 11:30:09 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> Message-ID: <486B58B1.9040808@redhat.com> Mary Ellen Foster wrote: > 2008/7/1 David Walluck : >> Mary Ellen Foster wrote: >> | I have one recent package that does this (specifies openjdk on F9+ and >> | icedtea on F8) and one that doesn't (just wants java >= 1.5). The >> | first package uses JNI and needs a Sun-like JVM to work (or at least >> | it took more autotools hacking than I cared to try to make it work), >> | and if I just put Requires: java it tended to grab gcj. I guess I >> | could also put java > 1.5, but the issue isn't the 1.5-ness, it's the >> | Sun-style JNI classes. >> >> This is not an issue with the java-devel packages, but rather an issue >> with either the upstream configure or an issue with the GCJ packaging. >> >> If it is lack of JNI support in GCJ, that is one thing. If it is simply >> that the package is expecting a differnt layout that is another. > > I just did a bit of hacking, and it is possible to build the package > against gcj instead of openjdk. There were two things to fix: > - the "configure" script followed symlinks from javac to find the JNI > include dir. Since the symlinks for gcj ground out at /usr/bin/ecj, it > ended up looking for /usr/include/jni.h. Hmm. This package assumes that the chain of symlinks ends at the installed binary, which must be in the jdk dir. /usr/bin/javac --> /etc/alternatives/javac --> /usr/lib/jvm/java-1.4.2-gcj/bin/javac --> /usr/bin/ecj ? > - It also wanted to hardcode "-ljava -lverify -ljvm" on the gcc line, > which isn't right for gcj No. I'm surprised it's right for Java either; libjvm and libverify I'd expect. > But I'm not sure if I want to make these modifications to the package. > If I build a JNI program against gcj, can the resulting .so be used > with Sun-like JVMs? How does this work? Is it documented anywhere? I think so. Andrew. From foster at in.tum.de Wed Jul 2 10:38:46 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Wed, 2 Jul 2008 11:38:46 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486B58B1.9040808@redhat.com> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> <486B58B1.9040808@redhat.com> Message-ID: 2008/7/2 Andrew Haley : > Mary Ellen Foster wrote: >> - the "configure" script followed symlinks from javac to find the JNI >> include dir. Since the symlinks for gcj ground out at /usr/bin/ecj, it >> ended up looking for /usr/include/jni.h. > > Hmm. This package assumes that the chain of symlinks ends at the installed > binary, which must be in the jdk dir. > > /usr/bin/javac --> > /etc/alternatives/javac --> > /usr/lib/jvm/java-1.4.2-gcj/bin/javac --> > /usr/bin/ecj > > ? Yes. The comment in the configure script says "find the include directory relative to the javac executable", and it loops through links until it finds an actual binary. I hacked it for the moment by adding if [ `basename $_slink` = "ecj" ]; then break; fi (where $_slink is the target of the current link) and it seems to work fine. >> But I'm not sure if I want to make these modifications to the package. >> If I build a JNI program against gcj, can the resulting .so be used >> with Sun-like JVMs? How does this work? Is it documented anywhere? > > I think so. Hmm. Maybe I'll give that a try this afternoon then. 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 Dalibor.Topic at Sun.COM Wed Jul 2 11:04:28 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Wed, 02 Jul 2008 13:04:28 +0200 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080702092008.GD26257@redhat.com> References: <20080701154358.GC10402@redhat.com> <486A8845.2080606@lfarkas.org> <20080702092008.GD26257@redhat.com> Message-ID: <486B60BC.2080508@Sun.COM> Daniel Veillard wrote: > On Tue, Jul 01, 2008 at 09:40:53PM +0200, Farkas Levente wrote: > >> Daniel Veillard wrote: >> >>> Hi, >>> >>> I have just started to release and package java bindings for libvirt. >>> I have made a request for review for Fedora on the new package: >>> https://bugzilla.redhat.com/show_bug.cgi?id=453119 >>> >>> I found the exercise rather hard, JNI is of course on the edge of the Java >>> land, but it's hard to find good resources to look at for Java bindings >>> in Fedora, the gnome-java stuff seems very specific, and a lot of packages >>> basically rely on gcj for compilation of any JNI stuff. >>> >> you may look into jna. gstreamer-java use it. it's much simpler, easier >> then jni without the above problems. >> > > Well back in 97 we tried to avoid JNI in the Kaffe project, the > alternative was more elegant, easier, faster. I think everybody outside > of java has hoped or tried to develop different bindings mechanism, > unfortunately none prevailed, at this point I will stick with JNI, I'll sing the praise for JNA, as it is VM-independent, so doesn't suffer from the problem most other (usually vm-specific) JNI-replacements do. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From veillard at redhat.com Wed Jul 2 12:59:05 2008 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 2 Jul 2008 08:59:05 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486B60BC.2080508@Sun.COM> References: <20080701154358.GC10402@redhat.com> <486A8845.2080606@lfarkas.org> <20080702092008.GD26257@redhat.com> <486B60BC.2080508@Sun.COM> Message-ID: <20080702125905.GC2734@redhat.com> On Wed, Jul 02, 2008 at 01:04:28PM +0200, Dalibor Topic wrote: > Daniel Veillard wrote: > >On Tue, Jul 01, 2008 at 09:40:53PM +0200, Farkas Levente wrote: > > > >>Daniel Veillard wrote: > >> > >>> Hi, > >>> > >>>I have just started to release and package java bindings for libvirt. > >>>I have made a request for review for Fedora on the new package: > >>> https://bugzilla.redhat.com/show_bug.cgi?id=453119 > >>> > >>>I found the exercise rather hard, JNI is of course on the edge of the > >>>Java > >>>land, but it's hard to find good resources to look at for Java bindings > >>>in Fedora, the gnome-java stuff seems very specific, and a lot of > >>>packages > >>>basically rely on gcj for compilation of any JNI stuff. > >>> > >>you may look into jna. gstreamer-java use it. it's much simpler, easier > >>then jni without the above problems. > >> > > > > Well back in 97 we tried to avoid JNI in the Kaffe project, the > >alternative was more elegant, easier, faster. I think everybody outside > >of java has hoped or tried to develop different bindings mechanism, > >unfortunately none prevailed, at this point I will stick with JNI, > I'll sing the praise for JNA, as it is VM-independent, so doesn't suffer > from the > problem most other (usually vm-specific) JNI-replacements do. haha, well you're obviously in a good position to sing that song now :) Looking at the example, yes this looks way nicer, but having that JNI code now I'm not sure I want to rewrite the thing. One interesting thing in my case is that JNA is compatible up to 1.4 while our bindings are restricted to 1.5+ since they use enums (currently this just mean I can't compile with gcj in the RHEL releases, but that's a point in JNA favour) cheers, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Wed Jul 2 13:37:36 2008 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 2 Jul 2008 09:37:36 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486B58B1.9040808@redhat.com> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> <486B58B1.9040808@redhat.com> Message-ID: <20080702133736.GD2734@redhat.com> On Wed, Jul 02, 2008 at 11:30:09AM +0100, Andrew Haley wrote: > Mary Ellen Foster wrote: > > 2008/7/1 David Walluck : > >> Mary Ellen Foster wrote: > >> | I have one recent package that does this (specifies openjdk on F9+ and > >> | icedtea on F8) and one that doesn't (just wants java >= 1.5). The > >> | first package uses JNI and needs a Sun-like JVM to work (or at least > >> | it took more autotools hacking than I cared to try to make it work), > >> | and if I just put Requires: java it tended to grab gcj. I guess I > >> | could also put java > 1.5, but the issue isn't the 1.5-ness, it's the > >> | Sun-style JNI classes. > >> > >> This is not an issue with the java-devel packages, but rather an issue > >> with either the upstream configure or an issue with the GCJ packaging. > >> > >> If it is lack of JNI support in GCJ, that is one thing. If it is simply > >> that the package is expecting a differnt layout that is another. > > > > I just did a bit of hacking, and it is possible to build the package > > against gcj instead of openjdk. There were two things to fix: > > - the "configure" script followed symlinks from javac to find the JNI > > include dir. Since the symlinks for gcj ground out at /usr/bin/ecj, it > > ended up looking for /usr/include/jni.h. > > Hmm. This package assumes that the chain of symlinks ends at the installed > binary, which must be in the jdk dir. > > /usr/bin/javac --> > /etc/alternatives/javac --> > /usr/lib/jvm/java-1.4.2-gcj/bin/javac --> > /usr/bin/ecj I changed libvirt-java configure.in to walk the chain of symlinks starting from javah/javac to find the JDK location and its includes. That seems to work pretty well in practice, and with that in place and the -source 1.5 cleanup for ecj the package build and generates rpms without problems on a variety of platforms: RHEL-4: works with IBM 1.5.0 RHEL-5: works with IBM/SUN/BEA 1.5.0 fails with gcj because it's 1.4 and the bindings use enums Fedora8: works with IcedTea-1.7 and java-1.5.0-gcj-devel Fedora9: works with OpenJDK-1.6.0 and java-1.5.0-gcj-devel thanks for the feedback ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From foster at in.tum.de Wed Jul 2 14:42:59 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Wed, 2 Jul 2008 15:42:59 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> <486B58B1.9040808@redhat.com> Message-ID: 2008/7/2 Mary Ellen Foster : > 2008/7/2 Andrew Haley : >>> But I'm not sure if I want to make these modifications to the package. >>> If I build a JNI program against gcj, can the resulting .so be used >>> with Sun-like JVMs? How does this work? Is it documented anywhere? >> >> I think so. > > Hmm. Maybe I'll give that a try this afternoon then. Well, would you look at that -- JNI shared objects built against GCJ do indeed seem to work just fine when I run them with IcedTea or OpenJDK. That's cool! So my Java sub-package can now be enabled on F8 ppc{64} as well, which is a bonus. 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 Wed Jul 2 14:56:41 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 02 Jul 2008 15:56:41 +0100 Subject: [fedora-java] libvirt-java bindings In-Reply-To: References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> <486B58B1.9040808@redhat.com> Message-ID: <486B9729.4060003@redhat.com> Mary Ellen Foster wrote: > 2008/7/2 Mary Ellen Foster : >> 2008/7/2 Andrew Haley : >>>> But I'm not sure if I want to make these modifications to the package. >>>> If I build a JNI program against gcj, can the resulting .so be used >>>> with Sun-like JVMs? How does this work? Is it documented anywhere? >>> I think so. >> Hmm. Maybe I'll give that a try this afternoon then. > > Well, would you look at that -- JNI shared objects built against GCJ > do indeed seem to work just fine when I run them with IcedTea or > OpenJDK. That's cool! So my Java sub-package can now be enabled on F8 > ppc{64} as well, which is a bonus. Excellent. We aim to please. :-) Andrew. From david at zarb.org Wed Jul 2 16:24:02 2008 From: david at zarb.org (David Walluck) Date: Wed, 02 Jul 2008 12:24:02 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080702091444.GC26257@redhat.com> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <20080702091444.GC26257@redhat.com> Message-ID: <486BABA2.2000908@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Veillard wrote: | And outside of the distro build the macros are not available and that's | where the user selection should be done, so this doesn't help much in the | case of a manual user rpmbuild, except maybe if one uses them to override | the alternative default. To my knowledge they are available. At least allow the user to set JAVA_HOME. This is much cleaner than a hack on following that has been proven not to work ever since IBM JDK 1.4. | I guess I need to think a bit more about it, but i'm firmly in the camp | of those who think the package should be distribution agnostic as much as | possible. It is distribution agnostic. Were the 6+ RPM-based distributions I mentioned in a previous email not agnostic enough? Even Debian/Ubuntu follow the same layout for JVM's. But you were speaking of an RPM build, so that covers ever major RPM distro I know of. And if you allow $JAVA_HOME and --with-java-home= as a configure option, and try /usr/lib/jvm/java first if none is specficed, then you will also support Ubuntu out of the box without resorting to a hack. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkhrq6IACgkQItObMyg2XCXaRwCfSZSBoPkDLORYmSElqeiVpaUP xh8Ani1hNq8Jb55LZ8pOTbhE2gX7R58r =A+P5 -----END PGP SIGNATURE----- From david at zarb.org Wed Jul 2 16:27:51 2008 From: david at zarb.org (David Walluck) Date: Wed, 02 Jul 2008 12:27:51 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080702133736.GD2734@redhat.com> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> <486B58B1.9040808@redhat.com> <20080702133736.GD2734@redhat.com> Message-ID: <486BAC87.4080008@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Veillard wrote: | I changed libvirt-java configure.in to walk the chain of symlinks starting | from javah/javac to find the JDK location and its includes. | That seems to work pretty well in practice, and with that in place and the | -source 1.5 cleanup for ecj the package build and generates rpms without | problems on a variety of platforms: I thought Mary Ellen's email was to demonstrate how this method was bad, but you took this as a reason to adaopt it. Unless you think /usr/bin/ecj is not a valid Java compiler, then it's the method that's broken, not the compiler location. It's your software, so you can do what you want. I am just telling you how Java on Linux has been working for the past five or so years. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkhrrIcACgkQItObMyg2XCVSbACfW9Uya5lHvt+8AktUP01Fdnj5 iFcAn1KYFODD5FwU9ZbWY5OhYhX27Jr+ =rDX4 -----END PGP SIGNATURE----- From veillard at redhat.com Thu Jul 3 07:03:04 2008 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 3 Jul 2008 03:03:04 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486BAC87.4080008@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> <486B58B1.9040808@redhat.com> <20080702133736.GD2734@redhat.com> <486BAC87.4080008@zarb.org> Message-ID: <20080703070304.GA23486@redhat.com> On Wed, Jul 02, 2008 at 12:27:51PM -0400, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel Veillard wrote: > | I changed libvirt-java configure.in to walk the chain of symlinks > starting > | from javah/javac to find the JDK location and its includes. > | That seems to work pretty well in practice, and with that in place > and the > | -source 1.5 cleanup for ecj the package build and generates rpms without > | problems on a variety of platforms: > > I thought Mary Ellen's email was to demonstrate how this method was bad, > but you took this as a reason to adaopt it. Unless you think > /usr/bin/ecj is not a valid Java compiler, then it's the method that's > broken, not the compiler location. Why would I think ecj is not a valid Java compiler ? Stop assuming the only problem with ecj was that it needed the -source 1.5 flags. > It's your software, so you can do what you want. I am just telling you > how Java on Linux has been working for the past five or so years. No, you did not tell me ! Moreover that knowledge you have accumulated for that time is *not* availbale easilly as far as I can tell. You have not provided answers to my problems, you have no right to vent some frustrations if I appear to not have followed your indications (which ones ? where ?). I think what I have done was reasonable, I went to the Fedora Packaging guidelines, read and followed indications provided by /usr/share/doc/jpackage-utils-1.7.5/jpackage-utils-policy But I had 3 concrete real problems I needed a solution for: 1/ I needed a way to give the user the flexibility for the JDK used 2/ I needed the include paths for the JNI headers 3/ I needed a -source 1.5 options when compiling against the Eclipse compiler (thanks a lot Mary for the solution !) Your answer as I understood it was: - that I should ignore 1/ - that there were some RPM macros (undefined, just a list of macro names) - then started to vent about the fact that people don't do the Right Thing Please go reread your answer, that's really what is in your reply to my mail ! Sorry maybe you're the authority on the topic, but based on your answer that was far from obvious ! My approach has been to read the (apparently) appropriate Fedora packaging page in the Wiki http://fedoraproject.org/wiki/Packaging/Java then read and follow the JPackage policy /usr/share/doc/jpackage-utils-1.7.5/jpackage-utils-policy and since I still didn't found answers to 1/ 2/ /3 I asked on IRC, which is why I ended up subscribing to that list and asked. Now please stop assuming people know what you know (otherwise we would not be there asking), save one hour of your time to write down what you know people should do when packaging JNI related sources (including answers to at least 1/ and 2/) both for configure.in and for the spec file, with examples and explanations of what the various macro do. You will save a lot of time of people who just try to do the Right Thing (based on your viewpoint I just wasted a day designing a solution which seems to work but doesn't and testing it on a variety of setups) and save the frustration you seems to have with the newbies. In a nutshell, cool down and do a brain dump as some proper documentation on the Fedora Java Packaging page (or linked to it) It will make you and everyone else happier ! Thanks in advance ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Thu Jul 3 07:37:46 2008 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 3 Jul 2008 03:37:46 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486BABA2.2000908@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <20080702091444.GC26257@redhat.com> <486BABA2.2000908@zarb.org> Message-ID: <20080703073746.GB23486@redhat.com> On Wed, Jul 02, 2008 at 12:24:02PM -0400, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel Veillard wrote: > | And outside of the distro build the macros are not available and that's > | where the user selection should be done, so this doesn't help much in the > | case of a manual user rpmbuild, except maybe if one uses them to override > | the alternative default. > > To my knowledge they are available. At least allow the user to set > JAVA_HOME. This is much cleaner than a hack on following that has been > proven not to work ever since IBM JDK 1.4. > > | I guess I need to think a bit more about it, but i'm firmly in the camp > | of those who think the package should be distribution agnostic as much as > | possible. > > It is distribution agnostic. Were the 6+ RPM-based distributions I > mentioned in a previous email not agnostic enough? Even Debian/Ubuntu > follow the same layout for JVM's. > > But you were speaking of an RPM build, so that covers ever major RPM > distro I know of. > > And if you allow $JAVA_HOME and --with-java-home= as a configure option, > and try /usr/lib/jvm/java first if none is specficed, then you will also > support Ubuntu out of the box without resorting to a hack. Ah, finally some informations which may help save the problem in a generic fashion. So is the following looks the Right Way to package JNI code for you ? in configure.in/ac: - use the $JAVA_HOME as the user provided environment variable to point to the top of the JDK tree - in configure.in provide an option --with-java-home allowing to override it - if still not defined try with /usr/lib/jvm/java - then check that $JAVA_HOME/bin contains the binaries for javah/javac/javah/javadoc/jar to be used when building the binaries - then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for the JNI includes in the spec file: this is still unclear but I guess - we should look for the %{java_home} macro - if found it should be passed as the --with-java-home value when running configure - keep Requires: java [ >= 1.5 ] Requires: jpackage-utils and BuildRequires: java-devel [ >= 1.5 ] BuildRequires: jpackage-utils as the Java RPM dependancies - Indicates that when rebuilding manually, overriding %{java_home} on the rpmbuild command line allows to pick a different JDK Can you confirm those instructions ? If yes can this be written directly somewhere in http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template in a "configure" section along ant/maven thanks, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From david at zarb.org Thu Jul 3 08:48:43 2008 From: david at zarb.org (David Walluck) Date: Thu, 03 Jul 2008 04:48:43 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080703070304.GA23486@redhat.com> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> <486B58B1.9040808@redhat.com> <20080702133736.GD2734@redhat.com> <486BAC87.4080008@zarb.org> <20080703070304.GA23486@redhat.com> Message-ID: <486C926B.5060705@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Veillard wrote: | On Wed, Jul 02, 2008 at 12:27:51PM -0400, David Walluck wrote: |> I thought Mary Ellen's email was to demonstrate how this method was bad, |> but you took this as a reason to adaopt it. Unless you think |> /usr/bin/ecj is not a valid Java compiler, then it's the method that's |> broken, not the compiler location. | | Why would I think ecj is not a valid Java compiler ? Stop assuming | the only problem with ecj was that it needed the -source 1.5 flags. My answer was not meant to be in response to the compilation problem, but the idea of assuming that following symlinks will eventually lead you to a valid JAVA_HOME directory. While this may be fixed to work in Fedora, I had doubt that this could work in general (or at least that it is the best/easiest solution). So, this is partly where the communication was lost: I was talking (ranting---or whatever you choose to see it as) about the packaging/configure issues and not the problems with the compilation. But if `-source 1.5' needs to be passed for ecj (since it defaults to 1.6), then I think it makes sense to pass it as JAVACFLAGS (or whatever you want to call them) to every compiler, but I don't even remember now what the exact issue was. | 1/ I needed a way to give the user the flexibility for the JDK used I think you could do the following. You have BuildRequires: jpackage-utils BuildRequires: java-devel >= 1.5.0 this means %{java_home} is defined, so in the spec you may just do %{configure} --with-java-home=%{java_home} Then a user would be expected to override the default value by setting JAVA_HOME. Alternatively, you could just look for $JAVA_HOME being set, then in the spec you could do: JAVA_HOME=%{java_home} %{configure} Note that the %{java_home} macro as it's defined should honor the $JAVA_HOME setting in the shell. | 2/ I needed the include paths for the JNI headers You can use ${JAVA_HOME}/include or %{java_home}/include by default. | 3/ I needed a -source 1.5 options when compiling against the Eclipse compiler | (thanks a lot Mary for the solution !) Depending on the issue you may want this in general. If you do a specific check for ecj, then you can't really assume the JAVA_HOME layout which is saving you the work of writing some custom scripts for each compiler | Your answer as I understood it was: | - that I should ignore 1/ No, just that the issue was already solved. | - that there were some RPM macros (undefined, just a list of macro names) I thought the macros were self-exaplanatory, but the basic point of their usage would be if you want to do something like %{configure} --with-java=%{java} vs. %{configure} --with-java=%{java_home}/bin/java | people should do when packaging JNI related sources (including answers to | at least 1/ and 2/) both for configure.in and for the spec file, with | examples and explanations of what the various macro do. You will save a lot I think that currently the Fedora Java Packaging Guidelines do not discuss issues related to Java and C much if at all. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkhskmsACgkQItObMyg2XCU42gCfXIpD+QHo/PYlYP1ACiIf71kK aygAoKco5eNP02f7hiLsvqhbQFvUXEca =gvhG -----END PGP SIGNATURE----- From david at zarb.org Thu Jul 3 09:05:52 2008 From: david at zarb.org (David Walluck) Date: Thu, 03 Jul 2008 05:05:52 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <20080703073746.GB23486@redhat.com> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <20080702091444.GC26257@redhat.com> <486BABA2.2000908@zarb.org> <20080703073746.GB23486@redhat.com> Message-ID: <486C9670.8050809@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Veillard wrote: | - use the $JAVA_HOME as the user provided environment variable to point to | the top of the JDK tree | - in configure.in provide an option --with-java-home allowing to override it | - if still not defined try with /usr/lib/jvm/java Sounds good so far. You may also want to try other values for JAVA_HOME. I don't have an exhaustive list of these, but /usr/lib/jvm/java should be fine for any Linux distro that has jpackage-utils, so I think that should be sufficient. | - then check that $JAVA_HOME/bin contains the binaries for | javah/javac/javah/javadoc/jar to be used when building the binaries | - then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for | the JNI includes I think you want something like CPPFLAGS="-I$JAVA_HOME/include -I$JAVA_HOME/include/linux". But if it's not linux, I don't know how standard the existence of $system is. | - we should look for the %{java_home} macro This is only good for the RPM build. If you depend on jpackage-utils you may assume it is defined. | - if found it should be passed as the --with-java-home value when running | configure In the RPM-build case, you can pass explicitly the default (or desired) Java home directory . You have already laid out the three basic steps for configure above: 1.) Use --with-java-home if set. 2.) If this isn't set, then you would read $JAVA_HOME from the environment. 3.) If that isn't set then you would check some pre-defined list of directories. At the very least /usr/lib/jvm/java. | - keep | Requires: java [ >= 1.5 ] | Requires: jpackage-utils | and | BuildRequires: java-devel [ >= 1.5 ] | BuildRequires: jpackage-utils | as the Java RPM dependancies Yes, since these are virtual provides specified by several vendors (GCJ, IBM, BEA, Sun) as long as they follow the JPackage standard. | - Indicates that when rebuilding manually, overriding %{java_home} on the | rpmbuild command line allows to pick a different JDK The switch happens for the end-user of the RPM spec file simply by redefining %java_home, e.g. rpmbuild --define 'java_home /usr/lib/jvm/java-gcj' or JAVA_HOME=/usr/lib/jvm/java-gcj rpmbuild | If yes can this be written directly somewhere in | http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template | in a "configure" section along ant/maven it's hard to say how to standardize this process, since no one has written the canonical set of autoconf macros for this. Some macros exist in the autoconf macro archive, but they try to support many layouts (not just the linux standard layout). Sure, we can try to specify what a call to configure would look like and have each author write his own code to do it. A better approach might be to write a set of canonical m4 code that might be used to satisfy those requirements. Minimally all that is required is to read the value of $JAVA_HOME since you can assume a monolithic layout for the rest of the binaries and directories used for building. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkhslm8ACgkQItObMyg2XCUmVgCgjfbVRjxcJbnCJuzD2swSFtDh f+EAoIMKT8U9yvuw7H0Qu2oXDE7Wv42N =2H0n -----END PGP SIGNATURE----- From veillard at redhat.com Thu Jul 3 09:44:50 2008 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 3 Jul 2008 05:44:50 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486C926B.5060705@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <486A7289.2040409@zarb.org> <486B58B1.9040808@redhat.com> <20080702133736.GD2734@redhat.com> <486BAC87.4080008@zarb.org> <20080703070304.GA23486@redhat.com> <486C926B.5060705@zarb.org> Message-ID: <20080703094450.GB25857@redhat.com> On Thu, Jul 03, 2008 at 04:48:43AM -0400, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel Veillard wrote: > | On Wed, Jul 02, 2008 at 12:27:51PM -0400, David Walluck wrote: > |> I thought Mary Ellen's email was to demonstrate how this method was bad, > |> but you took this as a reason to adaopt it. Unless you think > |> /usr/bin/ecj is not a valid Java compiler, then it's the method that's > |> broken, not the compiler location. > | > | Why would I think ecj is not a valid Java compiler ? Stop assuming > | the only problem with ecj was that it needed the -source 1.5 flags. > > My answer was not meant to be in response to the compilation problem, > but the idea of assuming that following symlinks will eventually lead > you to a valid JAVA_HOME directory. While this may be fixed to work in > Fedora, I had doubt that this could work in general (or at least that it > is the best/easiest solution). Okay. For not being the easiest, that's not surprizing ! > So, this is partly where the communication was lost: I was talking > (ranting---or whatever you choose to see it as) about the > packaging/configure issues and not the problems with the compilation. > > But if `-source 1.5' needs to be passed for ecj (since it defaults to > 1.6), then I think it makes sense to pass it as JAVACFLAGS (or whatever > you want to call them) to every compiler, but I don't even remember now > what the exact issue was. The problem was that Mary had to guess `-source 1.5' was the problem (since there was a BuildRequires: java-devel >= 1.5 at least from a packaging POV this should not have happened) and also being sure that adding this flag won't break in other environment. Since it seems to be a generic javac flag maybe that can be passed down every time: http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html#options I had a javac command failing because of wrong args so I need to recheck it wasn't -source > | 1/ I needed a way to give the user the flexibility for the JDK used > > I think you could do the following. You have > > BuildRequires: jpackage-utils > BuildRequires: java-devel >= 1.5.0 > > this means %{java_home} is defined, so in the spec you may just do > > %{configure} --with-java-home=%{java_home} > > Then a user would be expected to override the default value by setting > JAVA_HOME. > > Alternatively, you could just look for $JAVA_HOME being set, then in the > spec you could do: > > JAVA_HOME=%{java_home} %{configure} > > Note that the %{java_home} macro as it's defined should honor the > $JAVA_HOME setting in the shell. okay, so it seems you confirm the information in the previous mail > | 2/ I needed the include paths for the JNI headers > > You can use ${JAVA_HOME}/include or %{java_home}/include by default. well it also need %{java_home}/include/$system, or wherever jni_md.h may be needed and it's often in a subdir (or sometime not available like in java-1.5.0-ibm-devel-1.5.0.7-1jpp.2.el4 > | 3/ I needed a -source 1.5 options when compiling against the Eclipse > compiler > | (thanks a lot Mary for the solution !) > > Depending on the issue you may want this in general. If you do a > specific check for ecj, then you can't really assume the JAVA_HOME > layout which is saving you the work of writing some custom scripts for > each compiler I used the following: JAVAC_FLAGS= javac_version=`$JAVAC -version 2>&1` case "$javac_version" in *Eclipse*) JAVAC_FLAGS="-source 1.5" ;; esac that seems to work fine in practice. > | people should do when packaging JNI related sources (including answers to > | at least 1/ and 2/) both for configure.in and for the spec file, with > | examples and explanations of what the various macro do. You will save > a lot > > I think that currently the Fedora Java Packaging Guidelines do not > discuss issues related to Java and C much if at all. yes and IMHO that's part of the wall between Java and other communities that we need to bring down. JNI makes it especially hard, maybe JNA will lower the barrier, still we need to make things easier to reuse each-other code. thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Thu Jul 3 09:57:53 2008 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 3 Jul 2008 05:57:53 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486C9670.8050809@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <20080702091444.GC26257@redhat.com> <486BABA2.2000908@zarb.org> <20080703073746.GB23486@redhat.com> <486C9670.8050809@zarb.org> Message-ID: <20080703095753.GC25857@redhat.com> On Thu, Jul 03, 2008 at 05:05:52AM -0400, David Walluck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel Veillard wrote: > | - use the $JAVA_HOME as the user provided environment variable to point to > | the top of the JDK tree > | - in configure.in provide an option --with-java-home allowing to > override it > | - if still not defined try with /usr/lib/jvm/java > > Sounds good so far. You may also want to try other values for JAVA_HOME. > I don't have an exhaustive list of these, but /usr/lib/jvm/java should > be fine for any Linux distro that has jpackage-utils, so I think that > should be sufficient. It seems to be here, back up to RHEL4, so from my own set of systems this looks fine. > | - then check that $JAVA_HOME/bin contains the binaries for > | javah/javac/javah/javadoc/jar to be used when building the binaries > | - then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for > | the JNI includes > > I think you want something like > > CPPFLAGS="-I$JAVA_HOME/include -I$JAVA_HOME/include/linux". > > But if it's not linux, I don't know how standard the existence of > $system is. yeah it's a bit painful, but I prefer not hardcode the system, for example libvirt is used in Solaris and can compile on Windows, and examples on the sun documentations seems to imply $system being respectively solaris and windows on those platforms. I used ------------------ case "$build_os" in *linux*) system="linux" ;; *) system="$build_os" ;; esac if test -f $SDK/include/$system/jni_md.h ; then JNI_CFLAGS="$JNI_CFLAGS -I$SDK/include/$system" else if test "`find $SDK -name jni_md.h`" != "" ; then head=`find $SDK -name jni_md.h | tail -1` dir=`dirname $head` JNI_CFLAGS="$JNI_CFLAGS -I$dir" fi fi ------------------ I think if you substitute SDK by JAVA_HOME you should get something in line with the expectations, while being portable (and extensible) > | - we should look for the %{java_home} macro > > This is only good for the RPM build. If you depend on jpackage-utils you > may assume it is defined. okay > | - if found it should be passed as the --with-java-home value when running > | configure > > In the RPM-build case, you can pass explicitly the default (or desired) > Java home directory . > > You have already laid out the three basic steps for configure above: > > 1.) Use --with-java-home if set. > > 2.) If this isn't set, then you would read $JAVA_HOME from the environment. > > 3.) If that isn't set then you would check some pre-defined list of > directories. At the very least /usr/lib/jvm/java. okay > | - keep > | Requires: java [ >= 1.5 ] > | Requires: jpackage-utils > | and > | BuildRequires: java-devel [ >= 1.5 ] > | BuildRequires: jpackage-utils > | as the Java RPM dependancies > > Yes, since these are virtual provides specified by several vendors (GCJ, > IBM, BEA, Sun) as long as they follow the JPackage standard. I found that to be true even on ancient systems, which was my main worry about a jpackage-utils dependancy, so this is fine (and that part is well documented already) > | - Indicates that when rebuilding manually, overriding %{java_home} on the > | rpmbuild command line allows to pick a different JDK > > The switch happens for the end-user of the RPM spec file simply by > redefining %java_home, e.g. > > rpmbuild --define 'java_home /usr/lib/jvm/java-gcj' > > or > > JAVA_HOME=/usr/lib/jvm/java-gcj rpmbuild makes sense. > | If yes can this be written directly somewhere in > | http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template > | in a "configure" section along ant/maven > > it's hard to say how to standardize this process, since no one has > written the canonical set of autoconf macros for this. Some macros exist > in the autoconf macro archive, but they try to support many layouts (not > just the linux standard layout). > > Sure, we can try to specify what a call to configure would look like and > have each author write his own code to do it. A better approach might be > to write a set of canonical m4 code that might be used to satisfy those > requirements. my experiance with auto* is that the first person who write the macros put them in the configure.in, and they get copied/modified over by everybody else because cut'npaste is the simpler solution and doesn't add any dependancy on the version of autoconf/automake being used. It's a bit sad, it's a bit of a mess, but works somehow. > Minimally all that is required is to read the value of $JAVA_HOME since > you can assume a monolithic layout for the rest of the binaries and > directories used for building. Okay I now have a clearer idea, validated with your expertise :-) Now, that's progress, once I have something which seems to work correctly I will resubmit for Fedora review, and try to expose the steps, thanks a lot ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From ranger at opennms.org Thu Jul 3 12:12:08 2008 From: ranger at opennms.org (Benjamin Reed) Date: Thu, 03 Jul 2008 08:12:08 -0400 Subject: [fedora-java] libvirt-java bindings In-Reply-To: <486C9670.8050809@zarb.org> References: <20080701154358.GC10402@redhat.com> <486A5A51.8030203@zarb.org> <20080702091444.GC26257@redhat.com> <486BABA2.2000908@zarb.org> <20080703073746.GB23486@redhat.com> <486C9670.8050809@zarb.org> Message-ID: <486CC218.8050509@opennms.org> David Walluck wrote: > Daniel Veillard wrote: > | - use the $JAVA_HOME as the user provided environment variable to > point to > | the top of the JDK tree > | - in configure.in provide an option --with-java-home allowing to > override it > | - if still not defined try with /usr/lib/jvm/java > > Sounds good so far. You may also want to try other values for JAVA_HOME. > I don't have an exhaustive list of these, but /usr/lib/jvm/java should > be fine for any Linux distro that has jpackage-utils, so I think that > should be sufficient. > > | - then check that $JAVA_HOME/bin contains the binaries for > | javah/javac/javah/javadoc/jar to be used when building the binaries > | - then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for > | the JNI includes > > I think you want something like > > CPPFLAGS="-I$JAVA_HOME/include -I$JAVA_HOME/include/linux". > > But if it's not linux, I don't know how standard the existence of > $system is. > > | - we should look for the %{java_home} macro > > This is only good for the RPM build. If you depend on jpackage-utils you > may assume it is defined. > > | - if found it should be passed as the --with-java-home value when running > | configure > > In the RPM-build case, you can pass explicitly the default (or desired) > Java home directory . > > You have already laid out the three basic steps for configure above: > > 1.) Use --with-java-home if set. > > 2.) If this isn't set, then you would read $JAVA_HOME from the environment. > > 3.) If that isn't set then you would check some pre-defined list of > directories. At the very least /usr/lib/jvm/java. > > | - keep > | Requires: java [ >= 1.5 ] > | Requires: jpackage-utils > | and > | BuildRequires: java-devel [ >= 1.5 ] > | BuildRequires: jpackage-utils > | as the Java RPM dependancies > > Yes, since these are virtual provides specified by several vendors (GCJ, > IBM, BEA, Sun) as long as they follow the JPackage standard. > > | - Indicates that when rebuilding manually, overriding %{java_home} on the > | rpmbuild command line allows to pick a different JDK > > The switch happens for the end-user of the RPM spec file simply by > redefining %java_home, e.g. > > rpmbuild --define 'java_home /usr/lib/jvm/java-gcj' > > or > > JAVA_HOME=/usr/lib/jvm/java-gcj rpmbuild > > | If yes can this be written directly somewhere in > | http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template > | in a "configure" section along ant/maven > > it's hard to say how to standardize this process, since no one has > written the canonical set of autoconf macros for this. Some macros exist > in the autoconf macro archive, but they try to support many layouts (not > just the linux standard layout). We have some autoconf macros that seem to work reasonably well (they've been tested on various linuxes, 32- and 64-bit, as well as solaris and macosx). They could probably use some tweaking, but would be a start: http://opennms.svn.sourceforge.net/svnroot/opennms/autotools/trunk/java.m4 I just noticed we're bad people, and don't have any copyright/license info on it, I'd be happy to make them whatever license makes them easy on everyone. =) To use it, we do: ONMS_CHECK_JDK([1.4]) AC_CHECK_HEADER([jni.h], [], [AC_MSG_ERROR([cannot find jni.h header])]) ...and in the .am: lib_LTLIBRARIES = libjrrd.la libjrrd_la_SOURCES = rrd_jinterface.c libjrrd_la_LDFLAGS = -module -avoid-version $(JAVA_SHREXT_COMMAND) .java.class: -mkdir -p $(classdir) $(JAVAC) $(JAVACFLAGS) -d $(classdir) $< Haven't figured out a nice way to to javah stuff though, still very manual: rrd_jinterface.c: org_opennms_netmgt_rrd_rrdtool_Interface.h org_opennms_netmgt_rrd_rrdtool_Interface.h: org/opennms/netmgt/rrd/rrdtool/Interface.class $(JAVAH) -classpath $(classdir) org.opennms.netmgt.rrd.rrdtool.Interface Does that help? It's still a little opennms-specific right now, I think, but would be a place to start. -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From overholt at redhat.com Fri Jul 4 12:50:11 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 4 Jul 2008 08:50:11 -0400 Subject: [fedora-java] packaging lessons from FUDCon hackfest? In-Reply-To: <1214405673.3207.201.camel@calliope.phig.org> References: <1214405673.3207.201.camel@calliope.phig.org> Message-ID: <20080704125010.GA29418@redhat.com> Hi, * Karsten 'quaid' Wade [2008-06-25 10:54]: > Andrew, Tom -- where there any insights, lessons, ideas, or other > outfalls from that work with Lee? Well, the process we went through was quite simple, actually: list the software they were using (in this case it was find all the JARs), determine where it came from, and see if it was already packaged. Moving applications onto newer version of libraries so that we're only ever shipping one will always be a challenge for ISVs since they're often using some version that they imported into their tree at some point in the past. This is one obvious difference between ISV packaging and distribution packaging. If we get more ISVs actually developing _on_ Fedora and more up-to-date dependencies, we may be able to help bring everyone's dependencies forward. > * ISV-specific lessons, tips, etc. ==> target wiki/SIGs/ISV I really wish we had video-taped Tom and Lee talking. At the beginning of the conversation Lee was unaware of the benefits of being a part of the distribution and was wary of relying on dependencies outside of their direct control; by the end of the conversation, he was fully in agreement of the benefits of being a part of the distribution :) Tom: perhaps you could write up some of the common arguments by ISVs and the Free Software / distribution POV for each of them? Andrew From fitzsim at redhat.com Fri Jul 4 15:37:21 2008 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 04 Jul 2008 11:37:21 -0400 Subject: [fedora-java] packaging lessons from FUDCon hackfest? In-Reply-To: <20080704125010.GA29418@redhat.com> (Andrew Overholt's message of "Fri, 4 Jul 2008 08:50:11 -0400") References: <1214405673.3207.201.camel@calliope.phig.org> <20080704125010.GA29418@redhat.com> Message-ID: Andrew Overholt writes: > Hi, > > * Karsten 'quaid' Wade [2008-06-25 10:54]: >> Andrew, Tom -- where there any insights, lessons, ideas, or other >> outfalls from that work with Lee? > > Well, the process we went through was quite simple, actually: list the > software they were using (in this case it was find all the JARs), determine > where it came from, and see if it was already packaged. Moving applications > onto newer version of libraries so that we're only ever shipping one will > always be a challenge for ISVs since they're often using some version that > they imported into their tree at some point in the past. This is one obvious > difference between ISV packaging and distribution packaging. If we get more > ISVs actually developing _on_ Fedora and more up-to-date dependencies, we may > be able to help bring everyone's dependencies forward. > >> * ISV-specific lessons, tips, etc. ==> target wiki/SIGs/ISV > > I really wish we had video-taped Tom and Lee talking. At the beginning of > the conversation Lee was unaware of the benefits of being a part of the > distribution and was wary of relying on dependencies outside of their direct > control; by the end of the conversation, he was fully in agreement of the > benefits of being a part of the distribution :) Tom: perhaps you could > write up some of the common arguments by ISVs and the Free Software / > distribution POV for each of them? Here's a draft document: https://fedoraproject.org/wiki/FedoraForISVs I linked to it from the ISV SIG page: https://fedoraproject.org/wiki/SIGs/ISV#Resources_for_ISVs Tom From ranger at opennms.org Fri Jul 4 19:29:46 2008 From: ranger at opennms.org (Benjamin Reed) Date: Fri, 04 Jul 2008 15:29:46 -0400 Subject: [fedora-java] packaging lessons from FUDCon hackfest? In-Reply-To: <20080704125010.GA29418@redhat.com> References: <1214405673.3207.201.camel@calliope.phig.org> <20080704125010.GA29418@redhat.com> Message-ID: <486E7A2A.8060807@opennms.org> Andrew Overholt wrote: > difference between ISV packaging and distribution packaging. If we get more > ISVs actually developing _on_ Fedora and more up-to-date dependencies, we may > be able to help bring everyone's dependencies forward. I wasn't at FUDCon, so I don't know if any of this was discussed, but... The biggest issue with that, I think, is that anyone using Maven is already completely outside of the normal "ask the distro for a dependency" way of doing things; doing maven-based development on fedora will still always end up using maven for resolving dependencies. :( Not to mention when you get into all of the OSGI stuff where foo uses bar 1.x and baz uses incompatible-bar 2.9.x and it does classloading to allow them to be available simultaneously. At some level it seems like some kind of fundamental tools need to be designed to tell maven to prefer system versions over specific versioned-dependencies, run unit tests against them, etc., but that's a huge amount of work. -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From overholt at redhat.com Fri Jul 4 20:39:21 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 4 Jul 2008 16:39:21 -0400 Subject: [fedora-java] packaging lessons from FUDCon hackfest? In-Reply-To: <486E7A2A.8060807@opennms.org> References: <1214405673.3207.201.camel@calliope.phig.org> <20080704125010.GA29418@redhat.com> <486E7A2A.8060807@opennms.org> Message-ID: <20080704203921.GB451@redhat.com> * Benjamin Reed [2008-07-04 15:30]: > The biggest issue with that, I think, is that anyone using Maven is > already completely outside of the normal "ask the distro for a > dependency" way of doing things; doing maven-based development on fedora > will still always end up using maven for resolving dependencies. :( Deepak Bhole has done some great work on the maven package in Fedora which one can use to build _only_ from other stuff in the distro and never touch the maven repos. > Not to mention when you get into all of the OSGI stuff where foo uses > bar 1.x and baz uses incompatible-bar 2.9.x and it does classloading to > allow them to be available simultaneously. It's the same root issue, though: either people move to new versions -- the one we ship -- or they maintain compat- packages. The former is obviously preferred :) Andrew From mcepl at redhat.com Fri Jul 4 23:14:57 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 05 Jul 2008 01:14:57 +0200 Subject: [fedora-java] blueMarine and openJDK -- second attempt Message-ID: Hi, I was trying once already to use blueMarine image cataloging program with IcedTea (which was then still too raw; http://thread.gmane.org/gmane.linux.redhat.fedora.java/2311). Now when the OpenJDK was officially certified to be a Java, I tried again, and I wasn't that much successfull either. Could anyboyd who actually understands Java and Fedora, could join a thread on http://bluemarine.tidalwave.it/forum/posts/list/1179.page and something useful there, please? Thanks a lot, Mat?j From aph at redhat.com Sat Jul 5 09:08:30 2008 From: aph at redhat.com (Andrew Haley) Date: Sat, 05 Jul 2008 10:08:30 +0100 Subject: [fedora-java] blueMarine and openJDK -- second attempt In-Reply-To: References: Message-ID: <486F3A0E.2020106@redhat.com> Matej Cepl wrote: > Hi, > > I was trying once already to use blueMarine image cataloging > program with IcedTea (which was then still too raw; > http://thread.gmane.org/gmane.linux.redhat.fedora.java/2311). Now > when the OpenJDK was officially certified to be a Java, I tried > again, and I wasn't that much successfull either. Could anyboyd > who actually understands Java and Fedora, could join a thread on > http://bluemarine.tidalwave.it/forum/posts/list/1179.page and > something useful there, please? Does it work with any implementation of Java 1.6? Andrew. From mcepl at redhat.com Sat Jul 5 14:11:59 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 05 Jul 2008 16:11:59 +0200 Subject: [fedora-java] Re: blueMarine and openJDK -- second attempt References: <486F3A0E.2020106@redhat.com> Message-ID: On 2008-07-05, 09:08 GMT, Andrew Haley wrote: > Does it work with any implementation of Java 1.6? http://tinyurl.com/2u4fmc asks for Java 6 for Widnows and Linux (on Mac it works with Java 5). Mat?j From aph at redhat.com Sun Jul 6 10:56:13 2008 From: aph at redhat.com (Andrew Haley) Date: Sun, 06 Jul 2008 11:56:13 +0100 Subject: [fedora-java] Re: blueMarine and openJDK -- second attempt In-Reply-To: References: <486F3A0E.2020106@redhat.com> Message-ID: <4870A4CD.5010706@redhat.com> Matej Cepl wrote: > On 2008-07-05, 09:08 GMT, Andrew Haley wrote: >> Does it work with any implementation of Java 1.6? > > http://tinyurl.com/2u4fmc asks for Java 6 for Widnows and Linux > (on Mac it works with Java 5). But you have't tried it with Java 6 on Linux, right? We need to know if it's an upstream bug or not. Andrew. From mark at klomp.org Sun Jul 6 12:03:14 2008 From: mark at klomp.org (Mark Wielaard) Date: Sun, 06 Jul 2008 14:03:14 +0200 Subject: [fedora-java] blueMarine and openJDK -- second attempt In-Reply-To: References: Message-ID: <1215345795.3415.4.camel@hermans.wildebeest.org> Hi Matej, On Sat, 2008-07-05 at 01:14 +0200, Matej Cepl wrote: > I was trying once already to use blueMarine image cataloging > program with IcedTea (which was then still too raw; > http://thread.gmane.org/gmane.linux.redhat.fedora.java/2311). Now > when the OpenJDK was officially certified to be a Java, I tried > again, and I wasn't that much successfull either. Could anyboyd > who actually understands Java and Fedora, could join a thread on > http://bluemarine.tidalwave.it/forum/posts/list/1179.page and > something useful there, please? Could you provide us with some more information? Why is the application depending on the Motif Toolkit? You disable that in your workaround to get it working. IcedTea/OpenJDK does indeed not support that toolkit, but it would be good to know why it was explicitly used in the first place. And what are the "some errors during startup" that you are seeing exactly? Thanks, Mark From mcepl at redhat.com Mon Jul 7 08:31:25 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 07 Jul 2008 10:31:25 +0200 Subject: [fedora-java] Re: blueMarine and openJDK -- second attempt References: <486F3A0E.2020106@redhat.com> <4870A4CD.5010706@redhat.com> Message-ID: On 2008-07-06, 10:56 GMT, Andrew Haley wrote: > But you have't tried it with Java 6 on Linux, right? > We need to know if it's an upstream bug or not. Just working on it, but it seems that jpackage repos are somehow screwed up, so I am installing the Sun's RPMs (with fear and trembling -- hopefully my computer won't get screwed up much). Will let you know about the results. Matej From mcepl at redhat.com Mon Jul 7 08:41:32 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 07 Jul 2008 10:41:32 +0200 Subject: [fedora-java] Re: blueMarine and openJDK -- second attempt References: <1215345795.3415.4.camel@hermans.wildebeest.org> Message-ID: On 2008-07-06, 12:03 GMT, Mark Wielaard wrote: > Could you provide us with some more information? Why is the > application depending on the Motif Toolkit? I have no idea, I am not a programmer (and even less Java programmer), just interested in getting quality photo management software which is not dependent on Mono. > You disable that in your workaround to get it working. You or somebody else suggested it when I was trying to make blueMarine work with the early IcedTea. > And what are the "some errors during startup" that you are > seeing exactly? Silly me, I forgot to tell you that those two tar.bz2 tarballs in http://mcepl.fedorapeople.org/tmp/blueMarine/ have subdirectory logs with a lot of backtraces in them. Does it help? Matej From bkearney at redhat.com Mon Jul 7 12:04:39 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 07 Jul 2008 08:04:39 -0400 Subject: [fedora-java] packaging lessons from FUDCon hackfest? In-Reply-To: References: <1214405673.3207.201.camel@calliope.phig.org> <20080704125010.GA29418@redhat.com> Message-ID: <48720657.2030608@redhat.com> Thomas Fitzsimmons wrote: > Andrew Overholt writes: > Here's a draft document: > > https://fedoraproject.org/wiki/FedoraForISVs You could also list download counting/tracking as a "loss". If an ISV provides a tar-based distribution from their website, they can track counts and/or emails. This may be important for their marketing department. One other item, and perhaps this is covered some place else, but are there accepted standards for aggregate packages (e.g. war, ear, rar) files? For Java, this seems like more then just "Unity with Windows release process" -- bk From overholt at redhat.com Mon Jul 7 12:17:58 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 7 Jul 2008 08:17:58 -0400 Subject: [fedora-java] packaging lessons from FUDCon hackfest? In-Reply-To: <48720657.2030608@redhat.com> References: <1214405673.3207.201.camel@calliope.phig.org> <20080704125010.GA29418@redhat.com> <48720657.2030608@redhat.com> Message-ID: <20080707121757.GA29112@redhat.com> * Bryan Kearney [2008-07-07 08:06]: > One other item, and perhaps this is covered some place else, but are > there accepted standards for aggregate packages (e.g. war, ear, rar) > files? For Java, this seems like more then just "Unity with Windows > release process" Last I heard a few people were working on guidelines for web apps including J2EE, etc. apps. Check through PackagingDrafts/ on the wiki. Andrew From overholt at redhat.com Mon Jul 7 12:23:59 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 7 Jul 2008 08:23:59 -0400 Subject: [fedora-java] Re: blueMarine and openJDK -- second attempt In-Reply-To: References: <486F3A0E.2020106@redhat.com> <4870A4CD.5010706@redhat.com> Message-ID: <20080707122358.GC29112@redhat.com> * Matej Cepl [2008-07-07 04:45]: > Just working on it, but it seems that jpackage repos are somehow > screwed up, so I am installing the Sun's RPMs (with fear and > trembling -- hopefully my computer won't get screwed up much). You don't need the RPMs. Just use the tarball. Andrew From fitzsim at redhat.com Mon Jul 7 14:37:14 2008 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 07 Jul 2008 10:37:14 -0400 Subject: [fedora-java] packaging lessons from FUDCon hackfest? In-Reply-To: <48720657.2030608@redhat.com> (Bryan Kearney's message of "Mon, 07 Jul 2008 08:04:39 -0400") References: <1214405673.3207.201.camel@calliope.phig.org> <20080704125010.GA29418@redhat.com> <48720657.2030608@redhat.com> Message-ID: Bryan Kearney writes: > Thomas Fitzsimmons wrote: >> Andrew Overholt writes: >> Here's a draft document: >> >> https://fedoraproject.org/wiki/FedoraForISVs > You could also list download counting/tracking as a "loss". If an ISV > provides a tar-based distribution from their website, they can track > counts and/or emails. This may be important for their marketing > department. Good point. Wiki updated. > One other item, and perhaps this is covered some place else, but are > there accepted standards for aggregate packages (e.g. war, ear, rar) > files? For Java, this seems like more then just "Unity with Windows > release process" https://fedoraproject.org/wiki/PackagingDrafts/JavaWebApps Tom From mcepl at redhat.com Mon Jul 7 14:31:39 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 07 Jul 2008 16:31:39 +0200 Subject: [fedora-java] Re: blueMarine and openJDK -- second attempt References: <486F3A0E.2020106@redhat.com> <4870A4CD.5010706@redhat.com> Message-ID: On 2008-07-07, 08:31 GMT, Matej Cepl wrote: > On 2008-07-06, 10:56 GMT, Andrew Haley wrote: >> But you have't tried it with Java 6 on Linux, right? >> We need to know if it's an upstream bug or not. > > Will let you know about the results. OK, so with jdk-1.6.0_06-fcs.x86_64 and java-1.6.0-sun-compat-1.6.0.06-1jpp.x86_64 blueMarin works like. Except, that I cannot check different values of AWT_TOOLKIT, because blueMarine.sh switches to XToolkit for x86_64. Logs etc. are again in http://mcepl.fedorapeople.org/tmp/blueMarine/Pictures-sun_java.tar.bz2 Any ideas, what's wrong with OpenJDK? Mat?j From overholt at redhat.com Tue Jul 8 13:29:54 2008 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Jul 2008 09:29:54 -0400 Subject: [fedora-java] gcj bits fail to build for Eclipse [Matt_Domsch@dell.com: Fedora i386 rawhide rebuild in mock status 2008-07-03] Message-ID: <20080708132954.GA8340@redhat.com> Specific build log: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/eclipse-3.3.2-12.fc9.src.rpm/result/build.log Reproducer: cvs -d:pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs co eclipse cd eclipse/devel make Andrew From aph at redhat.com Tue Jul 8 21:19:00 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 08 Jul 2008 22:19:00 +0100 Subject: [fedora-java] gcj bits fail to build for Eclipse [Matt_Domsch@dell.com: Fedora i386 rawhide rebuild in mock status 2008-07-03] In-Reply-To: <20080708132954.GA8340@redhat.com> References: <20080708132954.GA8340@redhat.com> Message-ID: <4873D9C4.5010403@redhat.com> Andrew Overholt wrote: > Specific build log: > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/eclipse-3.3.2-12.fc9.src.rpm/result/build.log > > Reproducer: > > cvs -d:pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs co eclipse > cd eclipse/devel > make Is this a new version of Eclipse? Andrew. From overholt at redhat.com Wed Jul 9 01:15:47 2008 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 8 Jul 2008 21:15:47 -0400 Subject: [fedora-java] gcj bits fail to build for Eclipse [Matt_Domsch@dell.com: Fedora i386 rawhide rebuild in mock status 2008-07-03] In-Reply-To: <4873D9C4.5010403@redhat.com> References: <20080708132954.GA8340@redhat.com> <4873D9C4.5010403@redhat.com> Message-ID: <20080709011547.GA15159@redhat.com> * Andrew Haley [2008-07-08 17:19]: > Andrew Overholt wrote: >> Specific build log: >> >> http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/eclipse-3.3.2-12.fc9.src.rpm/result/build.log >> >> Reproducer: >> >> cvs -d:pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs co eclipse >> cd eclipse/devel >> make > > Is this a new version of Eclipse? No, it's 3.3.2 which is the same as in Fedora 9. Andrew From aph at redhat.com Wed Jul 9 13:33:54 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 09 Jul 2008 14:33:54 +0100 Subject: [fedora-java] gcj bits fail to build for Eclipse [Matt_Domsch@dell.com: Fedora i386 rawhide rebuild in mock status 2008-07-03] In-Reply-To: <20080709011547.GA15159@redhat.com> References: <20080708132954.GA8340@redhat.com> <4873D9C4.5010403@redhat.com> <20080709011547.GA15159@redhat.com> Message-ID: <4874BE42.6040803@redhat.com> Andrew Overholt wrote: > * Andrew Haley [2008-07-08 17:19]: >> Andrew Overholt wrote: >>> Specific build log: >>> >>> http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/eclipse-3.3.2-12.fc9.src.rpm/result/build.log >>> >>> Reproducer: >>> >>> cvs -d:pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs co eclipse >>> cd eclipse/devel >>> make >> Is this a new version of Eclipse? > > No, it's 3.3.2 which is the same as in Fedora 9. OK, so is this a different version of gcc? I'm trying to discover what has changed since last time this was built. Andrew. From lfarkas at lfarkas.org Fri Jul 11 10:23:36 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 11 Jul 2008 12:23:36 +0200 Subject: [fedora-java] jna rpm Message-ID: <487734A8.4030705@lfarkas.org> hi, i heard that someone already made a jna rpm for fedora. can anybody point me to any sources? anyway i like to add jna a gstreamer-java packages to fedora which we made if anybody has these packages already made then we merge the spec file together. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Fri Jul 11 10:47:25 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 11 Jul 2008 12:47:25 +0200 Subject: [fedora-java] Re: jna rpm In-Reply-To: <487734A8.4030705@lfarkas.org> References: <487734A8.4030705@lfarkas.org> Message-ID: <48773A3D.8020307@lfarkas.org> Farkas Levente wrote: > hi, > i heard that someone already made a jna rpm for fedora. can anybody > point me to any sources? anyway i like to add jna a gstreamer-java > packages to fedora which we made if anybody has these packages already > made then we merge the spec file together. ok i was stupid i already find it in fedora:-( -- Levente "Si vis pacem para bellum!" From green at redhat.com Mon Jul 14 06:38:15 2008 From: green at redhat.com (Anthony Green) Date: Sun, 13 Jul 2008 23:38:15 -0700 Subject: [fedora-java] jakarta-commons-cli Message-ID: <487AF457.8080902@redhat.com> I'd like to surrender maintainership of jakarta-commons-cli to somebody more directly invovled in the jpackage effort (or somebody interested in getting involved). The first task at hand is to upgrade to 1.1. Any takers? AG From lfarkas at lfarkas.org Sun Jul 20 22:16:50 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Mon, 21 Jul 2008 00:16:50 +0200 Subject: [fedora-java] jna and gstreamer-java on fedora Message-ID: <4883B952.4050308@lfarkas.org> hi, unfortunately it seems we don't really test the rpm package:-( the main problem is the jna. it seems the jna package provided by fedora is not working with our rpm and even with gstreamer-java compiled from source. we always got such problems (like in test): --------------------------------------------- [junit] Testsuite: org.gstreamer.BinTest [junit] # [junit] # An unexpected error has been detected by Java Runtime Environment: [junit] # [junit] # SIGSEGV (0xb) at pc=0xb24b000b, pid=12123, tid=1616784 [junit] # [junit] # Java VM: OpenJDK Server VM (1.6.0-b09 mixed mode linux-x86) [junit] # Problematic frame: [junit] # C 0xb24b000b [junit] # [junit] # An error report file with more information is saved as: [junit] # /tmp/gstreamer-java/hs_err_pid12123.log [junit] # [junit] # If you would like to submit a bug report, please visit: [junit] # http://icedtea.classpath.org/bugzilla [junit] # The crash happened outside the Java Virtual Machine in native code. [junit] # See problematic frame for where to report the bug. [junit] # [junit] Test org.gstreamer.BinTest FAILED (crashed) --------------------------------------------- what can be the reason? the jna.jar packaged with gstreamer-java is working properly, but not the jna in fedora. does anybody use the jna package in fedora? is it working? can we've do something? or should i've to package the jna provided by gstreamer-java or reuild the original jna and not use the fedora one? thanks in advance. yours. -- Levente "Si vis pacem para bellum!" From overholt at redhat.com Mon Jul 21 00:15:04 2008 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 20 Jul 2008 20:15:04 -0400 Subject: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <4883B952.4050308@lfarkas.org> References: <4883B952.4050308@lfarkas.org> Message-ID: <20080721001503.GA4245@redhat.com> * Farkas Levente [2008-07-20 18:17]: > [junit] # An error report file with more information is saved as: > [junit] # /tmp/gstreamer-java/hs_err_pid12123.log What's in this file? The JVM is most likely crashing due to something wrong in the JNI code. > or should i've to package the jna provided by gstreamer-java or > reuild the original jna and not use the fedora one? This would be against the Fedora Packaging Guidelines. Andrew From lfarkas at lfarkas.org Mon Jul 21 15:13:05 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Mon, 21 Jul 2008 17:13:05 +0200 Subject: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <20080721001503.GA4245@redhat.com> References: <4883B952.4050308@lfarkas.org> <20080721001503.GA4245@redhat.com> Message-ID: <4884A781.2040807@lfarkas.org> Andrew Overholt wrote: > * Farkas Levente [2008-07-20 18:17]: >> [junit] # An error report file with more information is saved as: >> [junit] # /tmp/gstreamer-java/hs_err_pid12123.log > > What's in this file? The JVM is most likely crashing due to something > wrong in the JNI code. attached. >> or should i've to package the jna provided by gstreamer-java or >> reuild the original jna and not use the fedora one? > > This would be against the Fedora Packaging Guidelines. ok but currently the situation is: - not working with the jna in fedora, - working with the jna bundled with gstreamer-java, - working with the jna download from jna homepage. so dare i assume there is some problem with the fedora jna package? -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid5644.log URL: From overholt at redhat.com Mon Jul 21 15:16:17 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 21 Jul 2008 11:16:17 -0400 Subject: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <4884A781.2040807@lfarkas.org> References: <4883B952.4050308@lfarkas.org> <20080721001503.GA4245@redhat.com> <4884A781.2040807@lfarkas.org> Message-ID: <20080721151616.GB15184@redhat.com> * Farkas Levente [2008-07-21 11:13]: > Andrew Overholt wrote: >> * Farkas Levente [2008-07-20 18:17]: >>> [junit] # An error report file with more information is saved as: >>> [junit] # /tmp/gstreamer-java/hs_err_pid12123.log >> >> What's in this file? The JVM is most likely crashing due to something >> wrong in the JNI code. > > attached. I don't know what's specifically wrong there, but you should report this to the jna packager. >>> or should i've to package the jna provided by gstreamer-java or >>> reuild the original jna and not use the fedora one? >> >> This would be against the Fedora Packaging Guidelines. > > ok but currently the situation is: > - not working with the jna in fedora, > - working with the jna bundled with gstreamer-java, > - working with the jna download from jna homepage. > so dare i assume there is some problem with the fedora jna package? I would make that assumption and file a bug with the jna package :) By pointing out the don't-ship-prebuild-jars section of the guidelines, I just meant that you won't be able to package gstreamer-java until you can use the JAR provided by the jna package, not that the _current_ jna package must be used. I have no experience with jna, FWIW. Andrew From wmeissner at gmail.com Mon Jul 21 15:47:59 2008 From: wmeissner at gmail.com (Wayne Meissner) Date: Tue, 22 Jul 2008 01:47:59 +1000 Subject: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <4884A781.2040807@lfarkas.org> References: <4883B952.4050308@lfarkas.org> <20080721001503.GA4245@redhat.com> <4884A781.2040807@lfarkas.org> Message-ID: <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> This is a bit of a stab in the dark, but check that the rpm build for libffi has -DFFI_MMAP_EXEC_WRIT in CFLAGS for the build. gst_object_unref() will do a C -> java callback, and if you're on a system that disables the execute bit on normal malloc data (which should be all of them these days), JNA callbacks will cause the jvm to crash if libffi is not built to allocate the closure trampoline in executable memory. 2008/7/22 Farkas Levente : > Andrew Overholt wrote: >> * Farkas Levente [2008-07-20 18:17]: >>> [junit] # An error report file with more information is saved as: >>> [junit] # /tmp/gstreamer-java/hs_err_pid12123.log >> >> What's in this file? The JVM is most likely crashing due to something >> wrong in the JNI code. > > attached. > >>> or should i've to package the jna provided by gstreamer-java or >>> reuild the original jna and not use the fedora one? >> >> This would be against the Fedora Packaging Guidelines. > > ok but currently the situation is: > - not working with the jna in fedora, > - working with the jna bundled with gstreamer-java, > - working with the jna download from jna homepage. > so dare i assume there is some problem with the fedora jna package? > > -- > Levente "Si vis pacem para bellum!" > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups "gstreamer-java" group. > To post to this group, send email to gstreamer-java at googlegroups.com > To unsubscribe from this group, send email to gstreamer-java-unsubscribe at googlegroups.com > For more options, visit this group at http://groups.google.com/group/gstreamer-java?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x6c9b4564, pid=5644, tid=1616784 > # > # Java VM: OpenJDK Client VM (1.6.0-b09 mixed mode linux-x86) > # Problematic frame: > # C 0x6c9b4564 > # > # If you would like to submit a bug report, please visit: > # http://icedtea.classpath.org/bugzilla > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- T H R E A D --------------- > > Current thread (0x09feac00): JavaThread "main" [_thread_in_native, id=5645, stack(0x0013a000,0x0018b000)] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x6c9b4564 > > Registers: > EAX=0x93ccd008, EBX=0x0654b67c, ECX=0x00000001, EDX=0x0a15b880 > ESP=0x00189a60, EBP=0x00189a8c, ESI=0x00000001, EDI=0x05e7a9a8 > EIP=0x6c9b4564, CR2=0x6c9b4564, EFLAGS=0x00010246 > > Top of Stack: (sp=0x00189a60) > 0x00189a60: 06517103 010e790c 0a35f838 00000001 > 0x00189a70: 09feb1c0 09feb1c0 fffffffe 0a35f83c > 0x00189a80: 0689c258 0689c258 0a35f838 00189acc > 0x00189a90: 0680409f 0a35f838 09feb1ac 00000000 > 0x00189aa0: 09feb1c0 00522b4c fffffffe 0000160d > 0x00189ab0: 00000000 00000001 00000058 0071cb9e > 0x00189ac0: 0689c258 0689c258 0a35f838 00189afc > 0x00189ad0: 06805785 0a35f838 0a11b900 00000000 > > Instructions: (pc=0x6c9b4564) > 0x6c9b4554: > [error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb] > > Stack: [0x0013a000,0x0018b000], sp=0x00189a60, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C 0x6c9b4564 > C [libgstreamer-0.10.so+0x1b09f] gst_object_unref+0x8f > C [libgstreamer-0.10.so+0x1c785] gst_object_sink+0x105 > C [libffi.so.5+0x44c7] ffi_call_SYSV+0x17 > C [libffi.so.5+0x4306] ffi_call+0x86 > C [libjnidispatch.so+0x7b5e] > C [libjnidispatch.so+0x874b] Java_com_sun_jna_Function_invokeVoid+0x3b > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::StubRoutines (1) > V [libjvm.so+0x193677] > V [libjvm.so+0x26c459] > V [libjvm.so+0x19294f] > V [libjvm.so+0x19c24a] > V [libjvm.so+0x1a752a] > C [java+0x2ef7] JavaMain+0xe57 > C [libpthread.so.0+0x632f] > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::Interpreter > v ~BufferBlob::StubRoutines (1) > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x0a05d800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=5651, stack(0x02f11000,0x02f62000)] > 0x0a05ac00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=5650, stack(0x09162000,0x091e3000)] > 0x0a059800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=5649, stack(0x08d42000,0x08d93000)] > 0x0a045000 JavaThread "Finalizer" daemon [_thread_blocked, id=5648, stack(0x08625000,0x08676000)] > 0x0a043c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=5647, stack(0x04983000,0x049d4000)] > =>0x09feac00 JavaThread "main" [_thread_in_native, id=5645, stack(0x0013a000,0x0018b000)] > > Other Threads: > 0x0a040800 VMThread [stack: 0x0029b000,0x0031c000] [id=5646] > 0x0a05ec00 WatcherThread [stack: 0x02f62000,0x02fe3000] [id=5652] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap > def new generation total 960K, used 71K [0x940b0000, 0x941b0000, 0x96810000) > eden space 896K, 5% used [0x940b0000, 0x940bbb08, 0x94190000) > from space 64K, 38% used [0x941a0000, 0x941a6378, 0x941b0000) > to space 64K, 0% used [0x94190000, 0x94190000, 0x941a0000) > tenured generation total 4096K, used 350K [0x96810000, 0x96c10000, 0xb40b0000) > the space 4096K, 8% used [0x96810000, 0x96867988, 0x96867a00, 0x96c10000) > compacting perm gen total 12288K, used 4141K [0xb40b0000, 0xb4cb0000, 0xb80b0000) > the space 12288K, 33% used [0xb40b0000, 0xb44bb4e8, 0xb44bb600, 0xb4cb0000) > No shared spaces configured. > > Dynamic libraries: > 00110000-00111000 r-xp 00110000 00:00 0 [vdso] > 00111000-00138000 r-xp 00000000 fd:00 2849487 /lib/libm-2.8.so > 00138000-00139000 r--p 00026000 fd:00 2849487 /lib/libm-2.8.so > 00139000-0013a000 rw-p 00027000 fd:00 2849487 /lib/libm-2.8.so > 0013a000-0013d000 ---p 0013a000 00:00 0 > 0013d000-0018b000 rwxp 0013d000 00:00 0 > 0018b000-00193000 r-xp 00000000 fd:00 2848904 /lib/librt-2.8.so > 00193000-00194000 r--p 00007000 fd:00 2848904 /lib/librt-2.8.so > 00194000-00195000 rw-p 00008000 fd:00 2848904 /lib/librt-2.8.so > 00195000-0019b000 r-xp 00000000 fd:00 987005 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/native_threads/libhpi.so > 0019b000-0019c000 rw-p 00006000 fd:00 987005 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/native_threads/libhpi.so > 0019c000-001b2000 r-xp 00000000 fd:00 2849486 /lib/libnsl-2.8.so > 001b2000-001b3000 r--p 00015000 fd:00 2849486 /lib/libnsl-2.8.so > 001b3000-001b4000 rw-p 00016000 fd:00 2849486 /lib/libnsl-2.8.so > 001b4000-001b6000 rw-p 001b4000 00:00 0 > 001b6000-001c0000 r-xp 00000000 fd:00 2848939 /lib/libnss_files-2.8.so > 001c0000-001c1000 r--p 0000a000 fd:00 2848939 /lib/libnss_files-2.8.so > 001c1000-001c2000 rw-p 0000b000 fd:00 2848939 /lib/libnss_files-2.8.so > 001c2000-001ce000 r-xp 00000000 fd:00 987003 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libverify.so > 001ce000-001cf000 rw-p 0000b000 fd:00 987003 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libverify.so > 001cf000-001f1000 r-xp 00000000 fd:00 982992 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libjava.so > 001f1000-001f3000 rw-p 00022000 fd:00 982992 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libjava.so > 001f3000-001f9000 r-xp 00000000 fd:00 987004 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so > 001f9000-001fa000 rw-p 00006000 fd:00 987004 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so > 001fa000-001fd000 rwxp 001fa000 00:00 0 > 001fd000-0027a000 rwxp 001fd000 00:00 0 > 0027a000-00281000 rwxp 0027a000 00:00 0 > 00281000-0029b000 rwxp 00281000 00:00 0 > 0029b000-0029c000 ---p 0029b000 00:00 0 > 0029c000-0031c000 rwxp 0029c000 00:00 0 > 0031c000-00328000 r-xp 00000000 fd:00 1476757 /usr/lib/jna/libjnidispatch.so > 00328000-00329000 rw-p 0000b000 fd:00 1476757 /usr/lib/jna/libjnidispatch.so > 00329000-0032e000 r-xp 00000000 fd:00 720980 /usr/lib/libffi.so.5.0.2 > 0032e000-0032f000 rw-p 00005000 fd:00 720980 /usr/lib/libffi.so.5.0.2 > 0032f000-00333000 r-xp 00000000 fd:00 2848961 /lib/libgthread-2.0.so.0.1600.4 > 00333000-00334000 rw-p 00003000 fd:00 2848961 /lib/libgthread-2.0.so.0.1600.4 > 00334000-00337000 r-xp 00000000 fd:00 2848967 /lib/libgmodule-2.0.so.0.1600.4 > 00337000-00338000 rw-p 00002000 fd:00 2848967 /lib/libgmodule-2.0.so.0.1600.4 > 00338000-00352000 r-xp 00000000 fd:00 2849357 /lib/libselinux.so.1 > 00352000-00353000 r--p 00019000 fd:00 2849357 /lib/libselinux.so.1 > 00353000-00354000 rw-p 0001a000 fd:00 2849357 /lib/libselinux.so.1 > 00354000-00355000 r-xs 00000000 fd:00 5761566 /tmp/ffioYUUFK (deleted) > 0035d000-00379000 r-xp 00000000 fd:00 2848893 /lib/ld-2.8.so > 00379000-0037a000 r--p 0001c000 fd:00 2848893 /lib/ld-2.8.so > 0037a000-0037b000 rw-p 0001d000 fd:00 2848893 /lib/ld-2.8.so > 0037d000-004e0000 r-xp 00000000 fd:00 2848895 /lib/libc-2.8.so > 004e0000-004e2000 r--p 00163000 fd:00 2848895 /lib/libc-2.8.so > 004e2000-004e3000 rw-p 00165000 fd:00 2848895 /lib/libc-2.8.so > 004e3000-004e6000 rw-p 004e3000 00:00 0 > 004e8000-004eb000 r-xp 00000000 fd:00 991669 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/jli/libjli.so > 004eb000-004ec000 rw-p 00003000 fd:00 991669 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/jli/libjli.so > 00513000-00516000 r-xp 00000000 fd:00 2848966 /lib/libdl-2.8.so > 00516000-00517000 r--p 00002000 fd:00 2848966 /lib/libdl-2.8.so > 00517000-00518000 rw-p 00003000 fd:00 2848966 /lib/libdl-2.8.so > 0051a000-0052f000 r-xp 00000000 fd:00 2848900 /lib/libpthread-2.8.so > 0052f000-00530000 r--p 00014000 fd:00 2848900 /lib/libpthread-2.8.so > 00530000-00531000 rw-p 00015000 fd:00 2848900 /lib/libpthread-2.8.so > 00531000-00533000 rw-p 00531000 00:00 0 > 00535000-00548000 r-xp 00000000 fd:00 2849507 /lib/libz.so.1.2.3 > 00548000-00549000 rw-p 00012000 fd:00 2849507 /lib/libz.so.1.2.3 > 00549000-008c6000 r-xp 00000000 fd:00 986982 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client/libjvm.so > 008c6000-008e5000 rw-p 0037d000 fd:00 986982 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client/libjvm.so > 008e5000-00d03000 rw-p 008e5000 00:00 0 > 00d03000-00dc3000 rwxp 00d03000 00:00 0 > 00dc3000-02d03000 rwxp 00dc3000 00:00 0 > 02d03000-02d04000 rwxp 02d03000 00:00 0 > 02d04000-02d16000 rwxp 02d04000 00:00 0 > 02d16000-02d19000 rwxp 02d16000 00:00 0 > 02d19000-02e03000 rwxp 02d19000 00:00 0 > 02e03000-02e09000 rwxp 02e03000 00:00 0 > 02e09000-02e23000 rwxp 02e09000 00:00 0 > 02e23000-02e27000 rwxp 02e23000 00:00 0 > 02e27000-02f11000 rwxp 02e27000 00:00 0 > 02f11000-02f14000 ---p 02f11000 00:00 0 > 02f14000-02f62000 rwxp 02f14000 00:00 0 > 02f62000-02f63000 ---p 02f62000 00:00 0 > 02f63000-02fe3000 rwxp 02f63000 00:00 0 > 040cf000-04218000 r-xp 00000000 fd:00 372277 /usr/lib/libxml2.so.2.6.32 > 04218000-0421d000 rw-p 00149000 fd:00 372277 /usr/lib/libxml2.so.2.6.32 > 0421d000-0421e000 rw-p 0421d000 00:00 0 > 04983000-04986000 ---p 04983000 00:00 0 > 04986000-049d4000 rwxp 04986000 00:00 0 > 05d99000-05e7a000 r-xp 00000000 fd:00 2848886 /lib/libglib-2.0.so.0.1600.4 > 05e7a000-05e7b000 rw-p 000e1000 fd:00 2848886 /lib/libglib-2.0.so.0.1600.4 > 0650c000-0654b000 r-xp 00000000 fd:00 2848962 /lib/libgobject-2.0.so.0.1600.4 > 0654b000-0654c000 rw-p 0003f000 fd:00 2848962 /lib/libgobject-2.0.so.0.1600.4 > 067e9000-0689a000 r-xp 00000000 fd:00 370777 /usr/lib/libgstreamer-0.10.so.0.16.0 > 0689a000-0689e000 rw-p 000b1000 fd:00 370777 /usr/lib/libgstreamer-0.10.so.0.16.0 > 08048000-08050000 r-xp 00000000 fd:00 987495 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java > 08050000-08052000 rw-p 00007000 fd:00 987495 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java > 08625000-08628000 ---p 08625000 00:00 0 > 08628000-08676000 rwxp 08628000 00:00 0 > 08d42000-08d45000 ---p 08d42000 00:00 0 > 08d45000-08d93000 rwxp 08d45000 00:00 0 > 09162000-09165000 ---p 09162000 00:00 0 > 09165000-091e3000 rwxp 09165000 00:00 0 > 09fe5000-0a3a6000 rw-p 09fe5000 00:00 0 [heap] > 93ccd000-93cce000 rw-s 00000000 fd:00 5761566 /tmp/ffioYUUFK (deleted) > 93cce000-93cd2000 r--s 00079000 fd:00 987022 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/jsse.jar > 93cd2000-93ce1000 r--s 0007a000 fd:00 5769549 /tmp/gstreamer-java/dist/gstreamer-java.jar > 93ce1000-93ce4000 r--s 00017000 fd:00 6580034 /usr/share/java/jna-3.0.2.jar > 93ce4000-93ced000 r--s 00065000 fd:00 986966 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/ext/gnome-java-bridge.jar > 93ced000-93eed000 r--p 00000000 fd:00 391746 /usr/lib/locale/locale-archive > 93eed000-93f20000 rw-p 93eed000 00:00 0 > 93f20000-940b0000 r--s 033ee000 fd:00 987036 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar > 940b0000-941b0000 rwxp 940b0000 00:00 0 > 941b0000-96810000 rwxp 941b0000 00:00 0 > 96810000-96c10000 rwxp 96810000 00:00 0 > 96c10000-b40b0000 rwxp 96c10000 00:00 0 > b40b0000-b4cb0000 rwxp b40b0000 00:00 0 > b4cb0000-b80b0000 rwxp b4cb0000 00:00 0 > b80b4000-b80b6000 rw-p b80b4000 00:00 0 > b80cd000-b80d5000 rw-s 00000000 fd:00 5761562 /tmp/hsperfdata_lfarkas/5644 > b80d5000-b80d6000 rwxp b80d5000 00:00 0 > b80d6000-b80d7000 r--p b80d6000 00:00 0 > b80d7000-b80d8000 rw-p b80d7000 00:00 0 > bffc3000-bffd8000 rwxp bffeb000 00:00 0 [stack] > > VM Arguments: > java_command: org.gstreamer.lowlevel.Main > Launcher Type: SUN_STANDARD > > Environment Variables: > PATH=/home/lfarkas/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin > LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/../lib/i386 > SHELL=/bin/bash > DISPLAY=:0.0 > > Signal Handlers: > SIGSEGV: [libjvm.so+0x327970], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGBUS: [libjvm.so+0x327970], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGFPE: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGPIPE: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGXFSZ: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGILL: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGUSR2: [libjvm.so+0x26e410], sa_mask[0]=0x00000000, sa_flags=0x10000004 > SIGHUP: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGINT: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGTERM: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGQUIT: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > > > --------------- S Y S T E M --------------- > > OS:Fedora release 9 (Sulphur) > > uname:Linux 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul 7 20:46:03 EDT 2008 i686 > libc:glibc 2.8 NPTL 2.8 > rlimit: STACK 10240k, CORE 0k, NPROC 1024, NOFILE 1024, AS infinity > load average:1.63 1.12 0.74 > > CPU:total 1 (1 cores per cpu, 1 threads per core) family 15 model 36 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnow, 3dnowext > > Memory: 4k page, physical 1164780k(25656k free), swap 786424k(786424k free) > > vm_info: OpenJDK Client VM (1.6.0-b09) for linux-x86 JRE (1.6.0-b09), built on Jul 8 2008 11:26:24 by "mockbuild" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) > > time: Mon Jul 21 16:53:44 2008 > elapsed time: 1 seconds > > > From walters at redhat.com Wed Jul 23 14:26:38 2008 From: walters at redhat.com (Colin Walters) Date: Wed, 23 Jul 2008 10:26:38 -0400 Subject: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> References: <4883B952.4050308@lfarkas.org> <20080721001503.GA4245@redhat.com> <4884A781.2040807@lfarkas.org> <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> Message-ID: <1216823198.14497.2.camel@space-ghost.verbum.private> On Tue, 2008-07-22 at 01:47 +1000, Wayne Meissner wrote: > This is a bit of a stab in the dark, but check that the rpm build for > libffi has -DFFI_MMAP_EXEC_WRIT in CFLAGS for the build. I don't see any such flag in http://kojipkgs.fedoraproject.org/packages/libffi/3.0.1/1.fc9/data/logs/x86_64/build.log CC'ing libffi maintainer (Anthony, the context here is: https://www.redhat.com/archives/fedora-devel-java-list/2008-July/msg00056.html) > gst_object_unref() will do a C -> java callback, and if you're on a > system that disables the execute bit on normal malloc data (which > should be all of them these days), JNA callbacks will cause the jvm to > crash if libffi is not built to allocate the closure trampoline in > executable memory. From walters at redhat.com Wed Jul 23 16:09:50 2008 From: walters at redhat.com (Colin Walters) Date: Wed, 23 Jul 2008 12:09:50 -0400 Subject: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <1216823198.14497.2.camel@space-ghost.verbum.private> References: <4883B952.4050308@lfarkas.org> <20080721001503.GA4245@redhat.com> <4884A781.2040807@lfarkas.org> <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> <1216823198.14497.2.camel@space-ghost.verbum.private> Message-ID: <1216829390.14497.12.camel@space-ghost.verbum.private> And somehow I failed to CC Anthony; trying again: On Wed, 2008-07-23 at 10:26 -0400, Colin Walters wrote: > On Tue, 2008-07-22 at 01:47 +1000, Wayne Meissner wrote: > > This is a bit of a stab in the dark, but check that the rpm build for > > libffi has -DFFI_MMAP_EXEC_WRIT in CFLAGS for the build. > > I don't see any such flag in > http://kojipkgs.fedoraproject.org/packages/libffi/3.0.1/1.fc9/data/logs/x86_64/build.log > > CC'ing libffi maintainer (Anthony, the context here is: > https://www.redhat.com/archives/fedora-devel-java-list/2008-July/msg00056.html) > > > gst_object_unref() will do a C -> java callback, and if you're on a > > system that disables the execute bit on normal malloc data (which > > should be all of them these days), JNA callbacks will cause the jvm to > > crash if libffi is not built to allocate the closure trampoline in > > executable memory. > > > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From green at redhat.com Thu Jul 24 20:35:09 2008 From: green at redhat.com (Anthony Green) Date: Thu, 24 Jul 2008 13:35:09 -0700 Subject: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> References: <4883B952.4050308@lfarkas.org> <20080721001503.GA4245@redhat.com> <4884A781.2040807@lfarkas.org> <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> Message-ID: <4888E77D.8030309@redhat.com> Wayne Meissner wrote: > This is a bit of a stab in the dark, but check that the rpm build for > libffi has -DFFI_MMAP_EXEC_WRIT in CFLAGS for the build. > We don't define this on the command line. FFI_MMAP_EXEC_WRIT is defined automatically in libffi's closures.c on Linux systems like so: #ifndef FFI_MMAP_EXEC_WRIT # if __gnu_linux__ /* This macro indicates it may be forbidden to map anonymous memory with both write and execute permission. Code compiled when this option is defined will attempt to map such pages once, but if it fails, it falls back to creating a temporary file in a writable and executable filesystem and mapping pages from it into separate locations in the virtual memory space, one location writable and another executable. */ # define FFI_MMAP_EXEC_WRIT 1 # endif #endif The F9 GCC defines __gnu_linux__, but - now that I think about it - I haven't confirmed that the F8 compiler defines this. Could somebody with an F8 system please check? Thanks, AG > gst_object_unref() will do a C -> java callback, and if you're on a > system that disables the execute bit on normal malloc data (which > should be all of them these days), JNA callbacks will cause the jvm to > crash if libffi is not built to allocate the closure trampoline in > executable memory. > > 2008/7/22 Farkas Levente : > >> Andrew Overholt wrote: >> >>> * Farkas Levente [2008-07-20 18:17]: >>> >>>> [junit] # An error report file with more information is saved as: >>>> [junit] # /tmp/gstreamer-java/hs_err_pid12123.log >>>> >>> What's in this file? The JVM is most likely crashing due to something >>> wrong in the JNI code. >>> >> attached. >> >> >>>> or should i've to package the jna provided by gstreamer-java or >>>> reuild the original jna and not use the fedora one? >>>> >>> This would be against the Fedora Packaging Guidelines. >>> >> ok but currently the situation is: >> - not working with the jna in fedora, >> - working with the jna bundled with gstreamer-java, >> - working with the jna download from jna homepage. >> so dare i assume there is some problem with the fedora jna package? >> >> -- >> Levente "Si vis pacem para bellum!" >> >> --~--~---------~--~----~------------~-------~--~----~ >> You received this message because you are subscribed to the Google Groups "gstreamer-java" group. >> To post to this group, send email to gstreamer-java at googlegroups.com >> To unsubscribe from this group, send email to gstreamer-java-unsubscribe at googlegroups.com >> For more options, visit this group at http://groups.google.com/group/gstreamer-java?hl=en >> -~----------~----~----~----~------~----~------~--~--- >> >> >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x6c9b4564, pid=5644, tid=1616784 >> # >> # Java VM: OpenJDK Client VM (1.6.0-b09 mixed mode linux-x86) >> # Problematic frame: >> # C 0x6c9b4564 >> # >> # If you would like to submit a bug report, please visit: >> # http://icedtea.classpath.org/bugzilla >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x09feac00): JavaThread "main" [_thread_in_native, id=5645, stack(0x0013a000,0x0018b000)] >> >> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x6c9b4564 >> >> Registers: >> EAX=0x93ccd008, EBX=0x0654b67c, ECX=0x00000001, EDX=0x0a15b880 >> ESP=0x00189a60, EBP=0x00189a8c, ESI=0x00000001, EDI=0x05e7a9a8 >> EIP=0x6c9b4564, CR2=0x6c9b4564, EFLAGS=0x00010246 >> >> Top of Stack: (sp=0x00189a60) >> 0x00189a60: 06517103 010e790c 0a35f838 00000001 >> 0x00189a70: 09feb1c0 09feb1c0 fffffffe 0a35f83c >> 0x00189a80: 0689c258 0689c258 0a35f838 00189acc >> 0x00189a90: 0680409f 0a35f838 09feb1ac 00000000 >> 0x00189aa0: 09feb1c0 00522b4c fffffffe 0000160d >> 0x00189ab0: 00000000 00000001 00000058 0071cb9e >> 0x00189ac0: 0689c258 0689c258 0a35f838 00189afc >> 0x00189ad0: 06805785 0a35f838 0a11b900 00000000 >> >> Instructions: (pc=0x6c9b4564) >> 0x6c9b4554: >> [error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb] >> >> Stack: [0x0013a000,0x0018b000], sp=0x00189a60, free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> C 0x6c9b4564 >> C [libgstreamer-0.10.so+0x1b09f] gst_object_unref+0x8f >> C [libgstreamer-0.10.so+0x1c785] gst_object_sink+0x105 >> C [libffi.so.5+0x44c7] ffi_call_SYSV+0x17 >> C [libffi.so.5+0x4306] ffi_call+0x86 >> C [libjnidispatch.so+0x7b5e] >> C [libjnidispatch.so+0x874b] Java_com_sun_jna_Function_invokeVoid+0x3b >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::StubRoutines (1) >> V [libjvm.so+0x193677] >> V [libjvm.so+0x26c459] >> V [libjvm.so+0x19294f] >> V [libjvm.so+0x19c24a] >> V [libjvm.so+0x1a752a] >> C [java+0x2ef7] JavaMain+0xe57 >> C [libpthread.so.0+0x632f] >> >> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::StubRoutines (1) >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x0a05d800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=5651, stack(0x02f11000,0x02f62000)] >> 0x0a05ac00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=5650, stack(0x09162000,0x091e3000)] >> 0x0a059800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=5649, stack(0x08d42000,0x08d93000)] >> 0x0a045000 JavaThread "Finalizer" daemon [_thread_blocked, id=5648, stack(0x08625000,0x08676000)] >> 0x0a043c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=5647, stack(0x04983000,0x049d4000)] >> =>0x09feac00 JavaThread "main" [_thread_in_native, id=5645, stack(0x0013a000,0x0018b000)] >> >> Other Threads: >> 0x0a040800 VMThread [stack: 0x0029b000,0x0031c000] [id=5646] >> 0x0a05ec00 WatcherThread [stack: 0x02f62000,0x02fe3000] [id=5652] >> >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: None >> >> Heap >> def new generation total 960K, used 71K [0x940b0000, 0x941b0000, 0x96810000) >> eden space 896K, 5% used [0x940b0000, 0x940bbb08, 0x94190000) >> from space 64K, 38% used [0x941a0000, 0x941a6378, 0x941b0000) >> to space 64K, 0% used [0x94190000, 0x94190000, 0x941a0000) >> tenured generation total 4096K, used 350K [0x96810000, 0x96c10000, 0xb40b0000) >> the space 4096K, 8% used [0x96810000, 0x96867988, 0x96867a00, 0x96c10000) >> compacting perm gen total 12288K, used 4141K [0xb40b0000, 0xb4cb0000, 0xb80b0000) >> the space 12288K, 33% used [0xb40b0000, 0xb44bb4e8, 0xb44bb600, 0xb4cb0000) >> No shared spaces configured. >> >> Dynamic libraries: >> 00110000-00111000 r-xp 00110000 00:00 0 [vdso] >> 00111000-00138000 r-xp 00000000 fd:00 2849487 /lib/libm-2.8.so >> 00138000-00139000 r--p 00026000 fd:00 2849487 /lib/libm-2.8.so >> 00139000-0013a000 rw-p 00027000 fd:00 2849487 /lib/libm-2.8.so >> 0013a000-0013d000 ---p 0013a000 00:00 0 >> 0013d000-0018b000 rwxp 0013d000 00:00 0 >> 0018b000-00193000 r-xp 00000000 fd:00 2848904 /lib/librt-2.8.so >> 00193000-00194000 r--p 00007000 fd:00 2848904 /lib/librt-2.8.so >> 00194000-00195000 rw-p 00008000 fd:00 2848904 /lib/librt-2.8.so >> 00195000-0019b000 r-xp 00000000 fd:00 987005 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/native_threads/libhpi.so >> 0019b000-0019c000 rw-p 00006000 fd:00 987005 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/native_threads/libhpi.so >> 0019c000-001b2000 r-xp 00000000 fd:00 2849486 /lib/libnsl-2.8.so >> 001b2000-001b3000 r--p 00015000 fd:00 2849486 /lib/libnsl-2.8.so >> 001b3000-001b4000 rw-p 00016000 fd:00 2849486 /lib/libnsl-2.8.so >> 001b4000-001b6000 rw-p 001b4000 00:00 0 >> 001b6000-001c0000 r-xp 00000000 fd:00 2848939 /lib/libnss_files-2.8.so >> 001c0000-001c1000 r--p 0000a000 fd:00 2848939 /lib/libnss_files-2.8.so >> 001c1000-001c2000 rw-p 0000b000 fd:00 2848939 /lib/libnss_files-2.8.so >> 001c2000-001ce000 r-xp 00000000 fd:00 987003 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libverify.so >> 001ce000-001cf000 rw-p 0000b000 fd:00 987003 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libverify.so >> 001cf000-001f1000 r-xp 00000000 fd:00 982992 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libjava.so >> 001f1000-001f3000 rw-p 00022000 fd:00 982992 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libjava.so >> 001f3000-001f9000 r-xp 00000000 fd:00 987004 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so >> 001f9000-001fa000 rw-p 00006000 fd:00 987004 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so >> 001fa000-001fd000 rwxp 001fa000 00:00 0 >> 001fd000-0027a000 rwxp 001fd000 00:00 0 >> 0027a000-00281000 rwxp 0027a000 00:00 0 >> 00281000-0029b000 rwxp 00281000 00:00 0 >> 0029b000-0029c000 ---p 0029b000 00:00 0 >> 0029c000-0031c000 rwxp 0029c000 00:00 0 >> 0031c000-00328000 r-xp 00000000 fd:00 1476757 /usr/lib/jna/libjnidispatch.so >> 00328000-00329000 rw-p 0000b000 fd:00 1476757 /usr/lib/jna/libjnidispatch.so >> 00329000-0032e000 r-xp 00000000 fd:00 720980 /usr/lib/libffi.so.5.0.2 >> 0032e000-0032f000 rw-p 00005000 fd:00 720980 /usr/lib/libffi.so.5.0.2 >> 0032f000-00333000 r-xp 00000000 fd:00 2848961 /lib/libgthread-2.0.so.0.1600.4 >> 00333000-00334000 rw-p 00003000 fd:00 2848961 /lib/libgthread-2.0.so.0.1600.4 >> 00334000-00337000 r-xp 00000000 fd:00 2848967 /lib/libgmodule-2.0.so.0.1600.4 >> 00337000-00338000 rw-p 00002000 fd:00 2848967 /lib/libgmodule-2.0.so.0.1600.4 >> 00338000-00352000 r-xp 00000000 fd:00 2849357 /lib/libselinux.so.1 >> 00352000-00353000 r--p 00019000 fd:00 2849357 /lib/libselinux.so.1 >> 00353000-00354000 rw-p 0001a000 fd:00 2849357 /lib/libselinux.so.1 >> 00354000-00355000 r-xs 00000000 fd:00 5761566 /tmp/ffioYUUFK (deleted) >> 0035d000-00379000 r-xp 00000000 fd:00 2848893 /lib/ld-2.8.so >> 00379000-0037a000 r--p 0001c000 fd:00 2848893 /lib/ld-2.8.so >> 0037a000-0037b000 rw-p 0001d000 fd:00 2848893 /lib/ld-2.8.so >> 0037d000-004e0000 r-xp 00000000 fd:00 2848895 /lib/libc-2.8.so >> 004e0000-004e2000 r--p 00163000 fd:00 2848895 /lib/libc-2.8.so >> 004e2000-004e3000 rw-p 00165000 fd:00 2848895 /lib/libc-2.8.so >> 004e3000-004e6000 rw-p 004e3000 00:00 0 >> 004e8000-004eb000 r-xp 00000000 fd:00 991669 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/jli/libjli.so >> 004eb000-004ec000 rw-p 00003000 fd:00 991669 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/jli/libjli.so >> 00513000-00516000 r-xp 00000000 fd:00 2848966 /lib/libdl-2.8.so >> 00516000-00517000 r--p 00002000 fd:00 2848966 /lib/libdl-2.8.so >> 00517000-00518000 rw-p 00003000 fd:00 2848966 /lib/libdl-2.8.so >> 0051a000-0052f000 r-xp 00000000 fd:00 2848900 /lib/libpthread-2.8.so >> 0052f000-00530000 r--p 00014000 fd:00 2848900 /lib/libpthread-2.8.so >> 00530000-00531000 rw-p 00015000 fd:00 2848900 /lib/libpthread-2.8.so >> 00531000-00533000 rw-p 00531000 00:00 0 >> 00535000-00548000 r-xp 00000000 fd:00 2849507 /lib/libz.so.1.2.3 >> 00548000-00549000 rw-p 00012000 fd:00 2849507 /lib/libz.so.1.2.3 >> 00549000-008c6000 r-xp 00000000 fd:00 986982 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client/libjvm.so >> 008c6000-008e5000 rw-p 0037d000 fd:00 986982 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client/libjvm.so >> 008e5000-00d03000 rw-p 008e5000 00:00 0 >> 00d03000-00dc3000 rwxp 00d03000 00:00 0 >> 00dc3000-02d03000 rwxp 00dc3000 00:00 0 >> 02d03000-02d04000 rwxp 02d03000 00:00 0 >> 02d04000-02d16000 rwxp 02d04000 00:00 0 >> 02d16000-02d19000 rwxp 02d16000 00:00 0 >> 02d19000-02e03000 rwxp 02d19000 00:00 0 >> 02e03000-02e09000 rwxp 02e03000 00:00 0 >> 02e09000-02e23000 rwxp 02e09000 00:00 0 >> 02e23000-02e27000 rwxp 02e23000 00:00 0 >> 02e27000-02f11000 rwxp 02e27000 00:00 0 >> 02f11000-02f14000 ---p 02f11000 00:00 0 >> 02f14000-02f62000 rwxp 02f14000 00:00 0 >> 02f62000-02f63000 ---p 02f62000 00:00 0 >> 02f63000-02fe3000 rwxp 02f63000 00:00 0 >> 040cf000-04218000 r-xp 00000000 fd:00 372277 /usr/lib/libxml2.so.2.6.32 >> 04218000-0421d000 rw-p 00149000 fd:00 372277 /usr/lib/libxml2.so.2.6.32 >> 0421d000-0421e000 rw-p 0421d000 00:00 0 >> 04983000-04986000 ---p 04983000 00:00 0 >> 04986000-049d4000 rwxp 04986000 00:00 0 >> 05d99000-05e7a000 r-xp 00000000 fd:00 2848886 /lib/libglib-2.0.so.0.1600.4 >> 05e7a000-05e7b000 rw-p 000e1000 fd:00 2848886 /lib/libglib-2.0.so.0.1600.4 >> 0650c000-0654b000 r-xp 00000000 fd:00 2848962 /lib/libgobject-2.0.so.0.1600.4 >> 0654b000-0654c000 rw-p 0003f000 fd:00 2848962 /lib/libgobject-2.0.so.0.1600.4 >> 067e9000-0689a000 r-xp 00000000 fd:00 370777 /usr/lib/libgstreamer-0.10.so.0.16.0 >> 0689a000-0689e000 rw-p 000b1000 fd:00 370777 /usr/lib/libgstreamer-0.10.so.0.16.0 >> 08048000-08050000 r-xp 00000000 fd:00 987495 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java >> 08050000-08052000 rw-p 00007000 fd:00 987495 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java >> 08625000-08628000 ---p 08625000 00:00 0 >> 08628000-08676000 rwxp 08628000 00:00 0 >> 08d42000-08d45000 ---p 08d42000 00:00 0 >> 08d45000-08d93000 rwxp 08d45000 00:00 0 >> 09162000-09165000 ---p 09162000 00:00 0 >> 09165000-091e3000 rwxp 09165000 00:00 0 >> 09fe5000-0a3a6000 rw-p 09fe5000 00:00 0 [heap] >> 93ccd000-93cce000 rw-s 00000000 fd:00 5761566 /tmp/ffioYUUFK (deleted) >> 93cce000-93cd2000 r--s 00079000 fd:00 987022 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/jsse.jar >> 93cd2000-93ce1000 r--s 0007a000 fd:00 5769549 /tmp/gstreamer-java/dist/gstreamer-java.jar >> 93ce1000-93ce4000 r--s 00017000 fd:00 6580034 /usr/share/java/jna-3.0.2.jar >> 93ce4000-93ced000 r--s 00065000 fd:00 986966 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/ext/gnome-java-bridge.jar >> 93ced000-93eed000 r--p 00000000 fd:00 391746 /usr/lib/locale/locale-archive >> 93eed000-93f20000 rw-p 93eed000 00:00 0 >> 93f20000-940b0000 r--s 033ee000 fd:00 987036 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >> 940b0000-941b0000 rwxp 940b0000 00:00 0 >> 941b0000-96810000 rwxp 941b0000 00:00 0 >> 96810000-96c10000 rwxp 96810000 00:00 0 >> 96c10000-b40b0000 rwxp 96c10000 00:00 0 >> b40b0000-b4cb0000 rwxp b40b0000 00:00 0 >> b4cb0000-b80b0000 rwxp b4cb0000 00:00 0 >> b80b4000-b80b6000 rw-p b80b4000 00:00 0 >> b80cd000-b80d5000 rw-s 00000000 fd:00 5761562 /tmp/hsperfdata_lfarkas/5644 >> b80d5000-b80d6000 rwxp b80d5000 00:00 0 >> b80d6000-b80d7000 r--p b80d6000 00:00 0 >> b80d7000-b80d8000 rw-p b80d7000 00:00 0 >> bffc3000-bffd8000 rwxp bffeb000 00:00 0 [stack] >> >> VM Arguments: >> java_command: org.gstreamer.lowlevel.Main >> Launcher Type: SUN_STANDARD >> >> Environment Variables: >> PATH=/home/lfarkas/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin >> LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/../lib/i386 >> SHELL=/bin/bash >> DISPLAY=:0.0 >> >> Signal Handlers: >> SIGSEGV: [libjvm.so+0x327970], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGBUS: [libjvm.so+0x327970], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGFPE: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGPIPE: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGXFSZ: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGILL: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 >> SIGUSR2: [libjvm.so+0x26e410], sa_mask[0]=0x00000000, sa_flags=0x10000004 >> SIGHUP: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGINT: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGTERM: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGQUIT: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> >> >> --------------- S Y S T E M --------------- >> >> OS:Fedora release 9 (Sulphur) >> >> uname:Linux 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul 7 20:46:03 EDT 2008 i686 >> libc:glibc 2.8 NPTL 2.8 >> rlimit: STACK 10240k, CORE 0k, NPROC 1024, NOFILE 1024, AS infinity >> load average:1.63 1.12 0.74 >> >> CPU:total 1 (1 cores per cpu, 1 threads per core) family 15 model 36 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnow, 3dnowext >> >> Memory: 4k page, physical 1164780k(25656k free), swap 786424k(786424k free) >> >> vm_info: OpenJDK Client VM (1.6.0-b09) for linux-x86 JRE (1.6.0-b09), built on Jul 8 2008 11:26:24 by "mockbuild" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) >> >> time: Mon Jul 21 16:53:44 2008 >> elapsed time: 1 seconds >> >> >> >> > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > From tromey at redhat.com Fri Jul 25 14:23:34 2008 From: tromey at redhat.com (Tom Tromey) Date: Fri, 25 Jul 2008 08:23:34 -0600 Subject: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <4888E77D.8030309@redhat.com> (Anthony Green's message of "Thu\, 24 Jul 2008 13\:35\:09 -0700") References: <4883B952.4050308@lfarkas.org> <20080721001503.GA4245@redhat.com> <4884A781.2040807@lfarkas.org> <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> <4888E77D.8030309@redhat.com> Message-ID: >>>>> "Anthony" == Anthony Green writes: Anthony> The F9 GCC defines __gnu_linux__, but - now that I think about it - I Anthony> haven't confirmed that the F8 compiler defines this. Could somebody Anthony> with an F8 system please check? It does. Tom From lfarkas at lfarkas.org Wed Jul 30 14:27:47 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 30 Jul 2008 16:27:47 +0200 Subject: FYI: Re: [fedora-java] jna and gstreamer-java on fedora In-Reply-To: <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> References: <4883B952.4050308@lfarkas.org> <20080721001503.GA4245@redhat.com> <4884A781.2040807@lfarkas.org> <4ccee320807210847l31f36a03x60c8ce5ef20f1cf5@mail.gmail.com> Message-ID: <48907A63.9040104@lfarkas.org> today i try to find the reason for this problem and it seems the problem totally vanish:-) which is a good news since we can use it, but a bad news since nether gstreamer-java nor jna packages change since the problem occurred (may be other packages). Wayne Meissner wrote: > This is a bit of a stab in the dark, but check that the rpm build for > libffi has -DFFI_MMAP_EXEC_WRIT in CFLAGS for the build. > > gst_object_unref() will do a C -> java callback, and if you're on a > system that disables the execute bit on normal malloc data (which > should be all of them these days), JNA callbacks will cause the jvm to > crash if libffi is not built to allocate the closure trampoline in > executable memory. > > 2008/7/22 Farkas Levente : >> Andrew Overholt wrote: >>> * Farkas Levente [2008-07-20 18:17]: >>>> [junit] # An error report file with more information is saved as: >>>> [junit] # /tmp/gstreamer-java/hs_err_pid12123.log >>> What's in this file? The JVM is most likely crashing due to something >>> wrong in the JNI code. >> attached. >> >>>> or should i've to package the jna provided by gstreamer-java or >>>> reuild the original jna and not use the fedora one? >>> This would be against the Fedora Packaging Guidelines. >> ok but currently the situation is: >> - not working with the jna in fedora, >> - working with the jna bundled with gstreamer-java, >> - working with the jna download from jna homepage. >> so dare i assume there is some problem with the fedora jna package? >> >> -- >> Levente "Si vis pacem para bellum!" >> >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x6c9b4564, pid=5644, tid=1616784 >> # >> # Java VM: OpenJDK Client VM (1.6.0-b09 mixed mode linux-x86) >> # Problematic frame: >> # C 0x6c9b4564 >> # >> # If you would like to submit a bug report, please visit: >> # http://icedtea.classpath.org/bugzilla >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x09feac00): JavaThread "main" [_thread_in_native, id=5645, stack(0x0013a000,0x0018b000)] >> >> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x6c9b4564 >> >> Registers: >> EAX=0x93ccd008, EBX=0x0654b67c, ECX=0x00000001, EDX=0x0a15b880 >> ESP=0x00189a60, EBP=0x00189a8c, ESI=0x00000001, EDI=0x05e7a9a8 >> EIP=0x6c9b4564, CR2=0x6c9b4564, EFLAGS=0x00010246 >> >> Top of Stack: (sp=0x00189a60) >> 0x00189a60: 06517103 010e790c 0a35f838 00000001 >> 0x00189a70: 09feb1c0 09feb1c0 fffffffe 0a35f83c >> 0x00189a80: 0689c258 0689c258 0a35f838 00189acc >> 0x00189a90: 0680409f 0a35f838 09feb1ac 00000000 >> 0x00189aa0: 09feb1c0 00522b4c fffffffe 0000160d >> 0x00189ab0: 00000000 00000001 00000058 0071cb9e >> 0x00189ac0: 0689c258 0689c258 0a35f838 00189afc >> 0x00189ad0: 06805785 0a35f838 0a11b900 00000000 >> >> Instructions: (pc=0x6c9b4564) >> 0x6c9b4554: >> [error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb] >> >> Stack: [0x0013a000,0x0018b000], sp=0x00189a60, free space=318k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> C 0x6c9b4564 >> C [libgstreamer-0.10.so+0x1b09f] gst_object_unref+0x8f >> C [libgstreamer-0.10.so+0x1c785] gst_object_sink+0x105 >> C [libffi.so.5+0x44c7] ffi_call_SYSV+0x17 >> C [libffi.so.5+0x4306] ffi_call+0x86 >> C [libjnidispatch.so+0x7b5e] >> C [libjnidispatch.so+0x874b] Java_com_sun_jna_Function_invokeVoid+0x3b >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::StubRoutines (1) >> V [libjvm.so+0x193677] >> V [libjvm.so+0x26c459] >> V [libjvm.so+0x19294f] >> V [libjvm.so+0x19c24a] >> V [libjvm.so+0x1a752a] >> C [java+0x2ef7] JavaMain+0xe57 >> C [libpthread.so.0+0x632f] >> >> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::Interpreter >> v ~BufferBlob::StubRoutines (1) >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x0a05d800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=5651, stack(0x02f11000,0x02f62000)] >> 0x0a05ac00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=5650, stack(0x09162000,0x091e3000)] >> 0x0a059800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=5649, stack(0x08d42000,0x08d93000)] >> 0x0a045000 JavaThread "Finalizer" daemon [_thread_blocked, id=5648, stack(0x08625000,0x08676000)] >> 0x0a043c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=5647, stack(0x04983000,0x049d4000)] >> =>0x09feac00 JavaThread "main" [_thread_in_native, id=5645, stack(0x0013a000,0x0018b000)] >> >> Other Threads: >> 0x0a040800 VMThread [stack: 0x0029b000,0x0031c000] [id=5646] >> 0x0a05ec00 WatcherThread [stack: 0x02f62000,0x02fe3000] [id=5652] >> >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: None >> >> Heap >> def new generation total 960K, used 71K [0x940b0000, 0x941b0000, 0x96810000) >> eden space 896K, 5% used [0x940b0000, 0x940bbb08, 0x94190000) >> from space 64K, 38% used [0x941a0000, 0x941a6378, 0x941b0000) >> to space 64K, 0% used [0x94190000, 0x94190000, 0x941a0000) >> tenured generation total 4096K, used 350K [0x96810000, 0x96c10000, 0xb40b0000) >> the space 4096K, 8% used [0x96810000, 0x96867988, 0x96867a00, 0x96c10000) >> compacting perm gen total 12288K, used 4141K [0xb40b0000, 0xb4cb0000, 0xb80b0000) >> the space 12288K, 33% used [0xb40b0000, 0xb44bb4e8, 0xb44bb600, 0xb4cb0000) >> No shared spaces configured. >> >> Dynamic libraries: >> 00110000-00111000 r-xp 00110000 00:00 0 [vdso] >> 00111000-00138000 r-xp 00000000 fd:00 2849487 /lib/libm-2.8.so >> 00138000-00139000 r--p 00026000 fd:00 2849487 /lib/libm-2.8.so >> 00139000-0013a000 rw-p 00027000 fd:00 2849487 /lib/libm-2.8.so >> 0013a000-0013d000 ---p 0013a000 00:00 0 >> 0013d000-0018b000 rwxp 0013d000 00:00 0 >> 0018b000-00193000 r-xp 00000000 fd:00 2848904 /lib/librt-2.8.so >> 00193000-00194000 r--p 00007000 fd:00 2848904 /lib/librt-2.8.so >> 00194000-00195000 rw-p 00008000 fd:00 2848904 /lib/librt-2.8.so >> 00195000-0019b000 r-xp 00000000 fd:00 987005 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/native_threads/libhpi.so >> 0019b000-0019c000 rw-p 00006000 fd:00 987005 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/native_threads/libhpi.so >> 0019c000-001b2000 r-xp 00000000 fd:00 2849486 /lib/libnsl-2.8.so >> 001b2000-001b3000 r--p 00015000 fd:00 2849486 /lib/libnsl-2.8.so >> 001b3000-001b4000 rw-p 00016000 fd:00 2849486 /lib/libnsl-2.8.so >> 001b4000-001b6000 rw-p 001b4000 00:00 0 >> 001b6000-001c0000 r-xp 00000000 fd:00 2848939 /lib/libnss_files-2.8.so >> 001c0000-001c1000 r--p 0000a000 fd:00 2848939 /lib/libnss_files-2.8.so >> 001c1000-001c2000 rw-p 0000b000 fd:00 2848939 /lib/libnss_files-2.8.so >> 001c2000-001ce000 r-xp 00000000 fd:00 987003 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libverify.so >> 001ce000-001cf000 rw-p 0000b000 fd:00 987003 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libverify.so >> 001cf000-001f1000 r-xp 00000000 fd:00 982992 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libjava.so >> 001f1000-001f3000 rw-p 00022000 fd:00 982992 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libjava.so >> 001f3000-001f9000 r-xp 00000000 fd:00 987004 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so >> 001f9000-001fa000 rw-p 00006000 fd:00 987004 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so >> 001fa000-001fd000 rwxp 001fa000 00:00 0 >> 001fd000-0027a000 rwxp 001fd000 00:00 0 >> 0027a000-00281000 rwxp 0027a000 00:00 0 >> 00281000-0029b000 rwxp 00281000 00:00 0 >> 0029b000-0029c000 ---p 0029b000 00:00 0 >> 0029c000-0031c000 rwxp 0029c000 00:00 0 >> 0031c000-00328000 r-xp 00000000 fd:00 1476757 /usr/lib/jna/libjnidispatch.so >> 00328000-00329000 rw-p 0000b000 fd:00 1476757 /usr/lib/jna/libjnidispatch.so >> 00329000-0032e000 r-xp 00000000 fd:00 720980 /usr/lib/libffi.so.5.0.2 >> 0032e000-0032f000 rw-p 00005000 fd:00 720980 /usr/lib/libffi.so.5.0.2 >> 0032f000-00333000 r-xp 00000000 fd:00 2848961 /lib/libgthread-2.0.so.0.1600.4 >> 00333000-00334000 rw-p 00003000 fd:00 2848961 /lib/libgthread-2.0.so.0.1600.4 >> 00334000-00337000 r-xp 00000000 fd:00 2848967 /lib/libgmodule-2.0.so.0.1600.4 >> 00337000-00338000 rw-p 00002000 fd:00 2848967 /lib/libgmodule-2.0.so.0.1600.4 >> 00338000-00352000 r-xp 00000000 fd:00 2849357 /lib/libselinux.so.1 >> 00352000-00353000 r--p 00019000 fd:00 2849357 /lib/libselinux.so.1 >> 00353000-00354000 rw-p 0001a000 fd:00 2849357 /lib/libselinux.so.1 >> 00354000-00355000 r-xs 00000000 fd:00 5761566 /tmp/ffioYUUFK (deleted) >> 0035d000-00379000 r-xp 00000000 fd:00 2848893 /lib/ld-2.8.so >> 00379000-0037a000 r--p 0001c000 fd:00 2848893 /lib/ld-2.8.so >> 0037a000-0037b000 rw-p 0001d000 fd:00 2848893 /lib/ld-2.8.so >> 0037d000-004e0000 r-xp 00000000 fd:00 2848895 /lib/libc-2.8.so >> 004e0000-004e2000 r--p 00163000 fd:00 2848895 /lib/libc-2.8.so >> 004e2000-004e3000 rw-p 00165000 fd:00 2848895 /lib/libc-2.8.so >> 004e3000-004e6000 rw-p 004e3000 00:00 0 >> 004e8000-004eb000 r-xp 00000000 fd:00 991669 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/jli/libjli.so >> 004eb000-004ec000 rw-p 00003000 fd:00 991669 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/jli/libjli.so >> 00513000-00516000 r-xp 00000000 fd:00 2848966 /lib/libdl-2.8.so >> 00516000-00517000 r--p 00002000 fd:00 2848966 /lib/libdl-2.8.so >> 00517000-00518000 rw-p 00003000 fd:00 2848966 /lib/libdl-2.8.so >> 0051a000-0052f000 r-xp 00000000 fd:00 2848900 /lib/libpthread-2.8.so >> 0052f000-00530000 r--p 00014000 fd:00 2848900 /lib/libpthread-2.8.so >> 00530000-00531000 rw-p 00015000 fd:00 2848900 /lib/libpthread-2.8.so >> 00531000-00533000 rw-p 00531000 00:00 0 >> 00535000-00548000 r-xp 00000000 fd:00 2849507 /lib/libz.so.1.2.3 >> 00548000-00549000 rw-p 00012000 fd:00 2849507 /lib/libz.so.1.2.3 >> 00549000-008c6000 r-xp 00000000 fd:00 986982 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client/libjvm.so >> 008c6000-008e5000 rw-p 0037d000 fd:00 986982 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client/libjvm.so >> 008e5000-00d03000 rw-p 008e5000 00:00 0 >> 00d03000-00dc3000 rwxp 00d03000 00:00 0 >> 00dc3000-02d03000 rwxp 00dc3000 00:00 0 >> 02d03000-02d04000 rwxp 02d03000 00:00 0 >> 02d04000-02d16000 rwxp 02d04000 00:00 0 >> 02d16000-02d19000 rwxp 02d16000 00:00 0 >> 02d19000-02e03000 rwxp 02d19000 00:00 0 >> 02e03000-02e09000 rwxp 02e03000 00:00 0 >> 02e09000-02e23000 rwxp 02e09000 00:00 0 >> 02e23000-02e27000 rwxp 02e23000 00:00 0 >> 02e27000-02f11000 rwxp 02e27000 00:00 0 >> 02f11000-02f14000 ---p 02f11000 00:00 0 >> 02f14000-02f62000 rwxp 02f14000 00:00 0 >> 02f62000-02f63000 ---p 02f62000 00:00 0 >> 02f63000-02fe3000 rwxp 02f63000 00:00 0 >> 040cf000-04218000 r-xp 00000000 fd:00 372277 /usr/lib/libxml2.so.2.6.32 >> 04218000-0421d000 rw-p 00149000 fd:00 372277 /usr/lib/libxml2.so.2.6.32 >> 0421d000-0421e000 rw-p 0421d000 00:00 0 >> 04983000-04986000 ---p 04983000 00:00 0 >> 04986000-049d4000 rwxp 04986000 00:00 0 >> 05d99000-05e7a000 r-xp 00000000 fd:00 2848886 /lib/libglib-2.0.so.0.1600.4 >> 05e7a000-05e7b000 rw-p 000e1000 fd:00 2848886 /lib/libglib-2.0.so.0.1600.4 >> 0650c000-0654b000 r-xp 00000000 fd:00 2848962 /lib/libgobject-2.0.so.0.1600.4 >> 0654b000-0654c000 rw-p 0003f000 fd:00 2848962 /lib/libgobject-2.0.so.0.1600.4 >> 067e9000-0689a000 r-xp 00000000 fd:00 370777 /usr/lib/libgstreamer-0.10.so.0.16.0 >> 0689a000-0689e000 rw-p 000b1000 fd:00 370777 /usr/lib/libgstreamer-0.10.so.0.16.0 >> 08048000-08050000 r-xp 00000000 fd:00 987495 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java >> 08050000-08052000 rw-p 00007000 fd:00 987495 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java >> 08625000-08628000 ---p 08625000 00:00 0 >> 08628000-08676000 rwxp 08628000 00:00 0 >> 08d42000-08d45000 ---p 08d42000 00:00 0 >> 08d45000-08d93000 rwxp 08d45000 00:00 0 >> 09162000-09165000 ---p 09162000 00:00 0 >> 09165000-091e3000 rwxp 09165000 00:00 0 >> 09fe5000-0a3a6000 rw-p 09fe5000 00:00 0 [heap] >> 93ccd000-93cce000 rw-s 00000000 fd:00 5761566 /tmp/ffioYUUFK (deleted) >> 93cce000-93cd2000 r--s 00079000 fd:00 987022 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/jsse.jar >> 93cd2000-93ce1000 r--s 0007a000 fd:00 5769549 /tmp/gstreamer-java/dist/gstreamer-java.jar >> 93ce1000-93ce4000 r--s 00017000 fd:00 6580034 /usr/share/java/jna-3.0.2.jar >> 93ce4000-93ced000 r--s 00065000 fd:00 986966 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/ext/gnome-java-bridge.jar >> 93ced000-93eed000 r--p 00000000 fd:00 391746 /usr/lib/locale/locale-archive >> 93eed000-93f20000 rw-p 93eed000 00:00 0 >> 93f20000-940b0000 r--s 033ee000 fd:00 987036 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >> 940b0000-941b0000 rwxp 940b0000 00:00 0 >> 941b0000-96810000 rwxp 941b0000 00:00 0 >> 96810000-96c10000 rwxp 96810000 00:00 0 >> 96c10000-b40b0000 rwxp 96c10000 00:00 0 >> b40b0000-b4cb0000 rwxp b40b0000 00:00 0 >> b4cb0000-b80b0000 rwxp b4cb0000 00:00 0 >> b80b4000-b80b6000 rw-p b80b4000 00:00 0 >> b80cd000-b80d5000 rw-s 00000000 fd:00 5761562 /tmp/hsperfdata_lfarkas/5644 >> b80d5000-b80d6000 rwxp b80d5000 00:00 0 >> b80d6000-b80d7000 r--p b80d6000 00:00 0 >> b80d7000-b80d8000 rw-p b80d7000 00:00 0 >> bffc3000-bffd8000 rwxp bffeb000 00:00 0 [stack] >> >> VM Arguments: >> java_command: org.gstreamer.lowlevel.Main >> Launcher Type: SUN_STANDARD >> >> Environment Variables: >> PATH=/home/lfarkas/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin >> LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/../lib/i386 >> SHELL=/bin/bash >> DISPLAY=:0.0 >> >> Signal Handlers: >> SIGSEGV: [libjvm.so+0x327970], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGBUS: [libjvm.so+0x327970], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGFPE: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGPIPE: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGXFSZ: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGILL: [libjvm.so+0x26ea60], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 >> SIGUSR2: [libjvm.so+0x26e410], sa_mask[0]=0x00000000, sa_flags=0x10000004 >> SIGHUP: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGINT: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGTERM: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> SIGQUIT: [libjvm.so+0x2705d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 >> >> >> --------------- S Y S T E M --------------- >> >> OS:Fedora release 9 (Sulphur) >> >> uname:Linux 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul 7 20:46:03 EDT 2008 i686 >> libc:glibc 2.8 NPTL 2.8 >> rlimit: STACK 10240k, CORE 0k, NPROC 1024, NOFILE 1024, AS infinity >> load average:1.63 1.12 0.74 >> >> CPU:total 1 (1 cores per cpu, 1 threads per core) family 15 model 36 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnow, 3dnowext >> >> Memory: 4k page, physical 1164780k(25656k free), swap 786424k(786424k free) >> >> vm_info: OpenJDK Client VM (1.6.0-b09) for linux-x86 JRE (1.6.0-b09), built on Jul 8 2008 11:26:24 by "mockbuild" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) >> >> time: Mon Jul 21 16:53:44 2008 >> elapsed time: 1 seconds -- Levente "Si vis pacem para bellum!" From Alexei.Mokeev at Sun.COM Thu Jul 31 05:43:37 2008 From: Alexei.Mokeev at Sun.COM (Alexei Mokeev) Date: Thu, 31 Jul 2008 09:43:37 +0400 Subject: [fedora-java] NetBeans 6.1 Message-ID: <48915109.3020701@sun.com> Hi, I'd like to consult with you about reviewing packages for Netbeans (http://www.netbeans.org) ?. The packages are ready and review requests are in BugZilla. (https://bugzilla.redhat.com/showdependencytree.cgi?id=456337). According to rpmlint they are not in a bad shape :) since it shows no errors. These packages are also in 'active' support, so if it's necessary to change something we are ready to do so quickly. Thanks, -Alexei. From Fabrizio.Giudici at tidalwave.it Thu Jul 31 06:51:49 2008 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 31 Jul 2008 06:51:49 +0000 (UTC) Subject: [fedora-java] Re: blueMarine and openJDK -- second attempt References: <1215345795.3415.4.camel@hermans.wildebeest.org> Message-ID: Hello, I'm the author of blueMarine and Matej pointed me to this thread. My points: 1. I've found some bugs of blueMarine that don't trigger with Sun's JDK 6, but do with OpenJDK (see http://bluemarine.tidalwave.it/issues/browse/BM-670). I'm working to fix them, as I'd like to make OpenJDK the reference Java implementation for distributing blueMarine on Linux. 2. The Motif Toolkit thing is due to a workaround to another bug with Java and Compiz: it looks like on many systems with Compiz installed, all the Java applications come out as an empty frame. See for instance http://ubuntuforums.org/archive/index.php/t-504983.html - This is driving me mad for a number of reasons: first, because I can't test it, as it seems very sensible to local configurations; second, because it even triggers core dumps with JDK 6 and 64 bits Linuxes; third, because it is supposed to be fixed on the latest Sun JDKs, but I've been reported it all the same. Can you tell me if this problem holds with OpenJDK? If not, it would be good news, as I could remove it completely. Thanks. From overholt at redhat.com Thu Jul 31 19:07:30 2008 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 31 Jul 2008 15:07:30 -0400 Subject: [fedora-java] Eclipse 3.4 Message-ID: <20080731190729.GB14841@redhat.com> Hi, I've finally got version 3.4 of the Eclipse SDK ready to go, targetting Fedora 10: http://koji.fedoraproject.org/koji/buildinfo?buildID=58121 (See [1] for an in-progress build with some minor fixes.) Action item for plugin package maintainers: ------------------------------------------- Please look at the relevant attached patches and apply them or something like them in the devel directory of your plugin(s). Feel free to commit and tag but note that you won't be able to build until I tag the build for rawhide. Email me personally if you have questions. Please also let me know when you're finished and I can do koji builds of everything in the right order (chain-build or otherwise). I'd like to do this very soon so please take a few minutes to apply the changes. Testing of the above build is greatly appreciated. ------------------------------------------- There are a few minor changes for packagers of plugins/features: - Bits are now installed to %{_libdir}/eclipse instead of %{_datadir}/eclipse. This brings us in line with upstream's file layout and avoids the crazy split-install osgi.sharedConfiguration.area hack. It's also what Debian does, FWIW. - p2 is the new provisioning platform in 3.4. Essentially it replaces the old update manager but does other things as well. It requires Eclipse-based apps to use profiles -- like Mozilla profiles -- and manage them using its "director". In order to avoid fragile %post scriptlets, we're going to use the "dropins mechanism" for plugin installation. This means that all non-Eclipse platform plugins will be installed into their own directory under %{_libdir}/eclipse/dropins. There are a variety of layouts that are acceptable to p2, but we'll largely be going with dropins/eclipse//{plugins,features}. This has the nice side benefit of simplifying %files sections :) . See [2] for more information here. - I added a flag to the pdebuild script to allow for Orbit-style dependencies. If you don't know what this means, that's okay, but if a plugin you want to package uses Orbit dependencies, you'll want to use the -o flag to pdebuild. Plugins that use non-Eclipse JARs but don't have a lib directory with JARs are probably using Orbit-style dependencies. They'll have Require-Bundle or Import-Package entries in their plugin MANIFEST.MFs. See eclipse-mylyn for an example of how to use pdebuild in this case. - I've renamed (and Obsoleted/Provided) libswt3-gtk2 to eclipse-swt. I can't count the number of times people have been confused by this naming and since we're not going to ship swt2 or swt.motif any time soon, the naming is silly. I also folded pde-runtime into pde since PHPEclipse no longer needs the separate pde-runtime package. Outside of the CDT and the SELinux tools (both maintainers are working on the necessary changes themselves), I've got patches for all of the plugins we have as packages in Fedora. I've attached these patches and CC'd all of the maintainers. I will update the packaging guidelines very soon with the above information. Thanks, Andrew [1] Build with branding fixed and removing some unnecessary Requires(post) and the pde-runtime package which is now folded into pde: http://koji.fedoraproject.org/koji/taskinfo?taskID=750696 [2] There are some performance considerations here. Since it's generating the associated metadata and "provisioning" the bits on the fly based on files dropped into a directory, users may notice a slightly longer startup the first time they start the Eclipse IDE after installing a new plugin package. Subsequent startups won't be impacted. There is a lot of performance improvement work going on upstream and much of it will land in 3.4.1. If 3.4.1 is released early enough, we'll ship it in Fedora 10. If not, we can ship it as an update. Should testing between now and Fedora 10 show unacceptably poor performance (I haven't noticed this in my own testing), we can look at back-porting some of the performance work. The other main way of speeding up dropins-installed plugins is by shipping pre-generated p2 metadata (like yum metadata). I've experimented with this and think I can make it so that we transparently generate it via pdebuild meaning it would only require a rebuild of Fedora plugin packages. Things will work without these generated content.xml files so in the interest of getting testing sooner rather than later, I'm going to push ahead without the metadata for dropins. -------------- next part -------------- ? .build-1.2.4-10.fc10.log ? eclipse-subclipse-1.2.4-10.fc10.src.rpm ? noarch ? subclipse-1.2.4 Index: eclipse-subclipse.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-subclipse/devel/eclipse-subclipse.spec,v retrieving revision 1.20 diff -u -r1.20 eclipse-subclipse.spec --- eclipse-subclipse.spec 7 Apr 2008 13:50:59 -0000 1.20 +++ eclipse-subclipse.spec 30 Jul 2008 23:02:20 -0000 @@ -1,9 +1,15 @@ %define gcj_support 1 %define eclipse_name eclipse +%if 0%{?rhel} == 5 %define eclipse_base %{_datadir}/%{eclipse_name} %define core_plugin_jar %{eclipse_base}/plugins/org.tigris.subversion.subclipse.core_%{version}.jar %define core_plugin_dir %{eclipse_base}/plugins/org.tigris.subversion.subclipse.core_%{version} +%else +%define eclipse_base %{_libdir}/%{eclipse_name} +%define core_plugin_jar %{eclipse_base}/dropins/subclipse/eclipse/plugins/org.tigris.subversion.subclipse.core_%{version}.jar +%define core_plugin_dir %{eclipse_base}/dropins/subclipse/eclipse/plugins/org.tigris.subversion.subclipse.core_%{version} +%endif %define disable_javahl 0 %if 0%{?fedora} == 6 @@ -20,7 +26,7 @@ Name: eclipse-subclipse Version: 1.2.4 -Release: 9%{?dist} +Release: 10%{?dist} Summary: Subversion Eclipse plugin Group: Text Editors/Integrated Development Environments (IDE) @@ -116,13 +122,10 @@ # --------------------------------- # building subclipse pushd subclipse +%if 0%{?rhel} == 5 # See comments in the script to understand this. # RHEL eclipse has a different instalation root -%if 0%{?rhel} == 5 /bin/sh -x %{_libdir}/%{eclipse_name}/buildscripts/copy-platform SDK %{eclipse_base} -%else -/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} -%endif SDK=$(cd SDK > /dev/null && pwd) # Eclipse may try to write to the home directory. @@ -171,6 +174,10 @@ # -Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \ # -f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml +%else +%{eclipse_base}/buildscripts/pdebuild -f org.tigris.subversion.subclipse +%{eclipse_base}/buildscripts/pdebuild -f org.tigris.subversion.book +%endif # returning to base build directory popd @@ -185,12 +192,23 @@ %install rm -rf $RPM_BUILD_ROOT +%if 0%{?rhel} == 5 install -d -m 755 $RPM_BUILD_ROOT%{eclipse_base} - pushd subclipse unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. build/rpmBuild/org.tigris.subversion.subclipse.zip unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. build/rpmBuild/org.tigris.subversion.book.zip +popd +%else +installDir=$RPM_BUILD_ROOT%{eclipse_base}/dropins/subclipse +install -d -m 755 $installDir +install -d -m 755 ${installDir}-book +pushd subclipse +unzip -q -d $installDir build/rpmBuild/org.tigris.subversion.subclipse.zip +unzip -q -d ${installDir}-book build/rpmBuild/org.tigris.subversion.book.zip +popd +%endif +pushd subclipse # repacking core plugin as a directory based plugin, needed in order to replace some jars with symlinks mkdir $RPM_BUILD_ROOT%{core_plugin_dir} unzip -q -d $RPM_BUILD_ROOT%{core_plugin_dir} $RPM_BUILD_ROOT%{core_plugin_jar} @@ -198,22 +216,23 @@ # packaging .class files as a jar file jar -cf $RPM_BUILD_ROOT%{core_plugin_dir}/lib/subclipse-core.jar -C $RPM_BUILD_ROOT%{core_plugin_dir} org rm -rf $RPM_BUILD_ROOT%{core_plugin_dir}/org +popd # removing core plugin internal jars rm -f $RPM_BUILD_ROOT%{core_plugin_dir}/lib/svnjavahl.jar rm -f $RPM_BUILD_ROOT%{core_plugin_dir}/lib/svnkit.jar rm -f $RPM_BUILD_ROOT%{core_plugin_dir}/lib/ganymed.jar -%if %{gcj_support} - aot-compile-rpm -%endif - # We need to setup the symlink because the ant copy task doesn't preserve symlinks # TODO file a bug about this ln -s %{javahl_dir}/svn-javahl.jar $RPM_BUILD_ROOT%{core_plugin_dir}/lib/svnjavahl.jar ln -s %{_javadir}/svnkit.jar $RPM_BUILD_ROOT%{core_plugin_dir}/lib/svnkit.jar ln -s %{_javadir}/ganymed-ssh2.jar $RPM_BUILD_ROOT%{core_plugin_dir}/lib/ganymed.jar +%if %{gcj_support} + aot-compile-rpm +%endif + %clean rm -rf $RPM_BUILD_ROOT @@ -225,10 +244,14 @@ %files %defattr(-,root,root) +%if 0%{?rhel} == 5 %{eclipse_base}/features/org.tigris.subversion.subclipse_* %{eclipse_base}/plugins/org.tigris.subversion.subclipse.core_* %{eclipse_base}/plugins/org.tigris.subversion.subclipse.ui_* %{eclipse_base}/plugins/org.tigris.subversion.subclipse.doc_* +%else +%{eclipse_base}/dropins/subclipse +%endif %doc svnClientAdapter/readme.txt svnClientAdapter/changelog.txt svnClientAdapter/license.txt %if %{gcj_support} @@ -237,10 +260,17 @@ %files book %defattr(-,root,root) +%if 0%{?rhel} == 5 %{eclipse_base}/features/org.tigris.subversion.book_* %{eclipse_base}/plugins/org.tigris.subversion.book_* +%else +%{eclipse_base}/dropins/subclipse-book +%endif %changelog +* Wed Jul 30 2008 Andrew Overholt 1.2.4-10 +- Update for Eclipse SDK 3.4 + * Fri Apr 04 2008 Robert Marcano 1.2.4-9 - Fix Bug 440818: changed links to svn-javahl.jar -------------- next part -------------- ? .build-0.4.0-2.fc10.log ? specfile-editor-fetched-src-18653 Index: eclipse-rpm-editor.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-rpm-editor/devel/eclipse-rpm-editor.spec,v retrieving revision 1.17 diff -u -r1.17 eclipse-rpm-editor.spec --- eclipse-rpm-editor.spec 29 Jun 2008 14:12:39 -0000 1.17 +++ eclipse-rpm-editor.spec 30 Jul 2008 22:59:17 -0000 @@ -1,10 +1,10 @@ %define gcj_support 1 -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define svn_rev 18653 Name: eclipse-rpm-editor Version: 0.4.0 -Release: 1%{?dist} +Release: 2%{?dist} Summary: RPM Specfile editor for Eclipse Group: Development/Tools License: EPL @@ -23,9 +23,6 @@ %else BuildRequires: java-devel >= 1.5.0 %endif -%if ! %{gcj_support} -BuildArch: noarch -%endif BuildRequires: eclipse-pde >= 1:3.3.0 BuildRequires: eclipse-changelog >= 2.5.1 Requires: eclipse-platform >= 3.3.1 @@ -57,8 +54,9 @@ %install rm -rf %{buildroot} -install -d -m 755 %{buildroot}%{eclipse_base} -unzip -q -d %{buildroot}%{eclipse_base}/.. \ +installDir=%{buildroot}%{eclipse_base}/dropins/rpm-editor +install -d -m 755 $installDir +unzip -q -d $installDir \ build/rpmBuild/org.eclipse.linuxtools.rpm.ui.editor.zip %if %{gcj_support} @@ -84,18 +82,19 @@ %files %defattr(-,root,root,-) -%{eclipse_base}/plugins/org.eclipse.linuxtools.rpm.ui.editor_*.jar -%{eclipse_base}/plugins/org.eclipse.linuxtools.rpm.rpmlint_*.jar -%dir %{eclipse_base}/features/org.eclipse.linuxtools.rpm.ui.editor_*/ -%doc %{eclipse_base}/features/org.eclipse.linuxtools.rpm.ui.editor_*/*.html -%{eclipse_base}/features/org.eclipse.linuxtools.rpm.ui.editor_*/*.xml -%{eclipse_base}/features/org.eclipse.linuxtools.rpm.ui.editor_*/*.properties +%doc org.eclipse.linuxtools.rpm.ui.editor-feature/*.html +%{eclipse_base}/dropins/rpm-editor %if %{gcj_support} %dir %{_libdir}/gcj/%{name} %{_libdir}/gcj/%{name}/org.eclipse.linuxtools.rpm.* %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 0.4.0-2 +- Update for Eclipse SDK 3.4 +- Remove noarch potential since CDT is arch-specific and we + ExclusiveArch + * Wed Jun 29 2008 Alphonse Van Assche 0.4.0-1 - bump to 0.4.0 -------------- next part -------------- ? .build-1.2.0-0.3.svn1573.fc10.log ? eclipse-phpeclipse-1.2.0-0.3.svn1573.fc10.src.rpm ? noarch ? phpeclipse-1.2.0 Index: eclipse-phpeclipse.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-phpeclipse/devel/eclipse-phpeclipse.spec,v retrieving revision 1.6 diff -u -r1.6 eclipse-phpeclipse.spec --- eclipse-phpeclipse.spec 29 Jun 2008 18:30:45 -0000 1.6 +++ eclipse-phpeclipse.spec 30 Jul 2008 22:58:50 -0000 @@ -1,9 +1,9 @@ -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define gcj_support 1 Name: eclipse-phpeclipse Version: 1.2.0 -Release: 0.2.svn1573%{?dist} +Release: 0.3.svn1573%{?dist} Summary: PHP Eclipse plugin Group: Development/Tools License: CPL @@ -96,14 +96,15 @@ %install rm -rf %{buildroot} -install -d -m 755 %{buildroot}%{eclipse_base} -unzip -q -d %{buildroot}%{eclipse_base}/.. build/rpmBuild/net.sourceforge.phpeclipse.feature.zip -unzip -q -d %{buildroot}%{eclipse_base}/.. build/rpmBuild/net.sourceforge.phpeclipse.debug.feature.zip -unzip -q -d %{buildroot}%{eclipse_base}/.. build/rpmBuild/net.sourceforge.phpeclipse.xdebug.feature.zip +installDir=%{buildroot}%{eclipse_base}/dropins/phpeclipse +install -d -m 755 $installDir +unzip -q -d $installDir build/rpmBuild/net.sourceforge.phpeclipse.feature.zip +unzip -q -d $installDir build/rpmBuild/net.sourceforge.phpeclipse.debug.feature.zip +unzip -q -d $installDir build/rpmBuild/net.sourceforge.phpeclipse.xdebug.feature.zip # need to recreate the symlinks to libraries that were setup in "prep" # because for some reason the ant copy task doesn't preserve them -pushd %{buildroot}%{eclipse_base}/plugins/net.sourceforge.phpeclipse.phpmanual.htmlparser_* +pushd $installDir/eclipse/plugins/net.sourceforge.phpeclipse.phpmanual.htmlparser_* rm *.jar build-jar-repository -s -p . xml-commons-apis popd @@ -122,37 +123,16 @@ %files %defattr(-,root,root,-) -%doc %{eclipse_base}/features/net.sourceforge.phpeclipse.feature_*/cpl-v10.html - -# main feature -%{eclipse_base}/features/net.sourceforge.phpeclipse.feature_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.core_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.externaltools_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.help_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.phphelp_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.phpmanual_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.phpmanual.htmlparser_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.smarty.ui_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.ui_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.webbrowser_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.xml.core_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.xml.ui_* - -# debug features -%{eclipse_base}/features/net.sourceforge.phpeclipse.debug.feature_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.debug.core_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.debug.ui_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.launching_* -%{eclipse_base}/features/net.sourceforge.phpeclipse.xdebug.feature_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.xdebug.core_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.xdebug.ui_* - +%doc net.sourceforge.phpeclipse.feature/cpl-v10.html +%{eclipse_base}/dropins/phpeclipse %if %{gcj_support} %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 1.2.0-0.3.svn1573 +- Update for building against Eclipse SDK 3.4. + * Sun Jun 29 2008 Mat Booth 1.2.0-0.2.svn1573 - Add patch for Show External Preview functionality. - Add patch for Use External PHP Parser functionality. -------------- next part -------------- ? .build-0.6.24-3.fc10.log ? eclipse-epic-0.6.24-3.fc10.src.rpm ? epic-0.6.24 ? noarch ? x86_64 Index: eclipse-epic.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-epic/devel/eclipse-epic.spec,v retrieving revision 1.4 diff -u -r1.4 eclipse-epic.spec --- eclipse-epic.spec 14 Jun 2008 12:37:41 -0000 1.4 +++ eclipse-epic.spec 30 Jul 2008 22:56:48 -0000 @@ -1,9 +1,9 @@ -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define gcj_support 1 Name: eclipse-epic Version: 0.6.24 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Perl Eclipse plugin Group: Development/Tools License: CPL @@ -99,18 +99,19 @@ %install rm -rf %{buildroot} -install -d -m 755 %{buildroot}%{eclipse_base} -unzip -q -d %{buildroot}%{eclipse_base}/.. build/rpmBuild/org.epic.feature.main.zip +installDir=%{buildroot}%{eclipse_base}/dropins/epic +install -d -m 755 $installDir +unzip -q -d $installDir build/rpmBuild/org.epic.feature.main.zip # need to recreate the symlinks to libraries that were setup in "prep" # because for some reason the ant copy task doesn't preserve them -pushd %{buildroot}%{eclipse_base}/plugins/org.epic.lib_*/lib +pushd $installDir/eclipse/plugins/org.epic.lib_*/lib rm *.jar build-jar-repository -s -p . jdom antlr gnu-regexp brazil popd # ensure source packages are correctly verisoned -pushd %{buildroot}%{eclipse_base}/plugins +pushd $installDir/eclipse/plugins for p in org.epic.perleditor \ org.epic.regexp \ org.epic.debug; do @@ -133,19 +134,16 @@ %files %defattr(-,root,root,-) -%doc %{eclipse_base}/features/org.epic.feature.main_%{version}/license.html -%{eclipse_base}/features/org.epic.feature.main_* -%{eclipse_base}/plugins/org.epic.debug_* -%{eclipse_base}/plugins/org.epic.doc_* -%{eclipse_base}/plugins/org.epic.lib_* -%{eclipse_base}/plugins/org.epic.perleditor_* -%{eclipse_base}/plugins/org.epic.regexp_* -%{eclipse_base}/plugins/org.epic.source_* +%doc org.epic.feature.main/license.html +%{eclipse_base}/dropins/epic %if %{gcj_support} %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 0.6.24-3 +- Update for building with Eclipse SDK 3.4 + * Sat Jun 14 2008 Mat Booth 0.6.24-2 - Fixed package ownership of feature directory. -------------- next part -------------- ? .build-4.0.1-11.fc10.log ? eclipse-checkstyle-4.0.1 ? eclipse-checkstyle-4.0.1-11.fc10.src.rpm ? noarch Index: eclipse-checkstyle.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-checkstyle/devel/eclipse-checkstyle.spec,v retrieving revision 1.5 diff -u -r1.5 eclipse-checkstyle.spec --- eclipse-checkstyle.spec 19 Feb 2008 21:48:47 -0000 1.5 +++ eclipse-checkstyle.spec 30 Jul 2008 22:52:53 -0000 @@ -1,12 +1,12 @@ -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define cs_ver 4.1 -%define eclipse_ver 3.3 +%define eclipse_ver 3.4 %define gcj_support 1 Summary: Checkstyle plugin for Eclipse Name: eclipse-checkstyle Version: 4.0.1 -Release: 10%{?dist} +Release: 11%{?dist} License: LGPLv2+ Group: Development/Tools URL: http://eclipse-cs.sourceforge.net @@ -73,14 +73,14 @@ %{eclipse_base}/plugins/org.eclipse.core.filebuffers_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.core.resources_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.core.runtime_%{eclipse_ver}.*.jar \ -%{eclipse_base}/plugins/org.eclipse.jdt.core_%{eclipse_ver}.*.jar \ -%{eclipse_base}/plugins/org.eclipse.jdt.ui_%{eclipse_ver}.*.jar \ +%{eclipse_base}/dropins/jdt/plugins/org.eclipse.jdt.core_%{eclipse_ver}.*.jar \ +%{eclipse_base}/dropins/jdt/plugins/org.eclipse.jdt.ui_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.jface_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.jface.text_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.osgi_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.swt_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.team.core_%{eclipse_ver}.*.jar \ -%{eclipse_base}/plugins/org.eclipse.team.cvs.core_%{eclipse_ver}.*.jar \ +%{eclipse_base}/plugins/org.eclipse.team.cvs.core_*.jar \ %{eclipse_base}/plugins/org.eclipse.text_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.ui_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.ui.editors_%{eclipse_ver}.*.jar \ @@ -108,20 +108,21 @@ %install rm -rf %{buildroot} -install -d -m755 %{buildroot}/%{eclipse_base}/features/com.atlassw.tools.eclipse.checkstyle_%{version} +installDir=%{buildroot}/%{eclipse_base}/dropins/checkstyle +install -d -m755 $installDir/features/com.atlassw.tools.eclipse.checkstyle_%{version} BUILD_DIR=`pwd`/CheckstylePlugin # install feature -pushd %{buildroot}/%{eclipse_base}/features/com.atlassw.tools.eclipse.checkstyle_%{version} +pushd $installDir/features/com.atlassw.tools.eclipse.checkstyle_%{version} jar xvf ${BUILD_DIR}/dist/com.atlassw.tools.eclipse.checkstyle_%{version}-feature.jar popd # install plugin -pushd %{buildroot}/%{eclipse_base} +pushd $installDir jar xvf ${BUILD_DIR}/dist/com.atlassw.tools.eclipse.checkstyle_%{version}-bin.zip find . -type f -name '*src.zip' -print | xargs -t rm -f build-jar-repository \ - %{buildroot}/%{eclipse_base}/plugins/com.atlassw.tools.eclipse.checkstyle_%{version} \ + $installDir/plugins/com.atlassw.tools.eclipse.checkstyle_%{version} \ checkstyle-%{cs_ver} \ checkstyle-optional-%{cs_ver} \ commons-beanutils-core \ @@ -151,14 +152,16 @@ %files %defattr(-,root,root) %doc CheckstylePlugin/license/LICENSE.* -%{eclipse_base}/features/* -%{eclipse_base}/plugins/* +%{eclipse_base}/dropins/checkstyle %if %{gcj_support} %attr(-,root,root) %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 4.0.1-11 +- Update for Eclipse SDK 3.4 + * Tue Feb 19 2008 Fedora Release Engineering - 4.0.1-10 - Autorebuild for GCC 4.3 -------------- next part -------------- ? eclipse-changelog-2.6.2 Index: eclipse-changelog.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-changelog/devel/eclipse-changelog.spec,v retrieving revision 1.67 diff -u -r1.67 eclipse-changelog.spec --- eclipse-changelog.spec 24 Jul 2008 21:07:31 -0000 1.67 +++ eclipse-changelog.spec 30 Jul 2008 21:42:01 -0000 @@ -1,11 +1,11 @@ Epoch: 1 %define gcj_support 1 -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse Name: eclipse-changelog Version: 2.6.2 -Release: 1%{?dist} +Release: 2%{?dist} Summary: Eclipse ChangeLog plug-in Group: Development/Tools @@ -69,32 +69,13 @@ %setup -q -c -n eclipse-changelog-%{version} %build -# See comments in the script to understand this. -/bin/sh -x %{_datadir}/eclipse/buildscripts/copy-platform SDK %{eclipse_base} cdt -SDK=$(cd SDK > /dev/null && pwd) - -# Eclipse may try to write to the home directory. -mkdir home -homedir=$(cd home > /dev/null && pwd) - -# build the main ChangeLog feature -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Duser.home=$homedir \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.eclipse.linuxtools.changelog \ - -DsourceDirectory=$(pwd) \ - -DbaseLocation=$SDK \ - -Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml +%{eclipse_base}/buildscripts/pdebuild %install rm -rf $RPM_BUILD_ROOT -install -d -m 755 $RPM_BUILD_ROOT%{eclipse_base} -unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. \ +installDir=%{eclipse_base}/dropins/changelog +install -d -m 755 $installDir +unzip -q -d $installDir \ build/rpmBuild/org.eclipse.linuxtools.changelog.zip %if %{gcj_support} @@ -111,12 +92,8 @@ %files %defattr(-,root,root) -%{eclipse_base}/features/org.eclipse.linuxtools.changelog_* -%{eclipse_base}/plugins/org.eclipse.linuxtools.changelog.core_* -%{eclipse_base}/plugins/org.eclipse.linuxtools.changelog.cparser_* -%{eclipse_base}/plugins/org.eclipse.linuxtools.changelog.parsers.java_* -%{eclipse_base}/plugins/org.eclipse.linuxtools.changelog.doc_* -%doc %{eclipse_base}/features/org.eclipse.linuxtools.changelog_*/epl-v10.html +%doc org.eclipse.linuxtools.changelog-feature/epl-v10.html +%{eclipse_base}/dropins/changelog %if %{gcj_support} %dir %{_libdir}/gcj/%{name} %{_libdir}/gcj/%{name}/org.eclipse.linuxtools.changelog.core_* @@ -125,6 +102,9 @@ %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 1:2.6.2-2 +- Update for Eclipse SDK 3.4 + * Thu Jun 26 2008 Jeff Johnston 1:2.6.2-1 - Rebase to 2.6.2 - Resolves Bugzilla #452574 -------------- next part -------------- ? .build-3.5.0-8.fc10.log ? eclipse-quickrex-3.5.0-8.fc10.src.rpm ? noarch ? quickrex-fetched-src-QuickREx_3_5_0 Index: eclipse-quickrex.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-quickrex/devel/eclipse-quickrex.spec,v retrieving revision 1.6 diff -u -r1.6 eclipse-quickrex.spec --- eclipse-quickrex.spec 18 Feb 2008 19:08:46 -0000 1.6 +++ eclipse-quickrex.spec 30 Jul 2008 21:21:53 -0000 @@ -1,5 +1,5 @@ %define gcj_support 1 -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define upstream_name QuickREx %define cvs_tag QuickREx_3_5_0 %define oro_jar jakarta-oro-2.0.8.jar @@ -7,7 +7,7 @@ Name: eclipse-quickrex Version: 3.5.0 -Release: 7%{?dist} +Release: 8%{?dist} Summary: %{upstream_name} is a regular-expression test Eclipse Plug-In Group: Development/Tools @@ -69,37 +69,18 @@ popd popd -# See comments in the script to understand this. -/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} -mkdir home - %build -SDK=$(cd SDK > /dev/null && pwd) - -# Eclipse may try to write to the home directory. -homedir=$(cd home > /dev/null && pwd) - -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=de.babe.eclipse.plugins.QuickREx \ - -DbaseLocation=$SDK \ - -DsourceDirectory=$(pwd) \ - -DbuildDirectory=$(pwd)/build \ - -Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml \ - -vmargs -Duser.home=$homedir +%{eclipse_base}/buildscripts/pdebuild %install rm -rf %{buildroot} -install -d -m 755 %{buildroot}%{eclipse_base} -unzip -q -d %{buildroot}%{eclipse_base}/.. \ +installDir=%{buildroot}%{eclipse_base}/dropins/quickrex +install -d -m 755 $installDir +unzip -q -d $installDir \ build/rpmBuild/de.babe.eclipse.plugins.QuickREx.zip # Re-symlink -pushd %{buildroot}/%{eclipse_base}/plugins/de.babe.eclipse.plugins.QuickREx_%{version}/lib +pushd $installDir/eclipse/plugins/de.babe.eclipse.plugins.QuickREx_%{version}/lib rm %{oro_jar} rm %{regexp_jar} ln -s %{_javadir}/%{oro_jar} @@ -129,16 +110,17 @@ %files %defattr(-,root,root,-) -%dir %{eclipse_base}/plugins/de.babe.eclipse.plugins.QuickREx_%{version} -%doc %{eclipse_base}/plugins/de.babe.eclipse.plugins.QuickREx_%{version}/html -%{eclipse_base}/features/de.babe.eclipse.plugins.QuickREx_%{version} -%{eclipse_base}/plugins/de.babe.eclipse.plugins.QuickREx_%{version}/* +%doc Plug-In/html +%{eclipse_base}/dropins/quickrex %if %{gcj_support} %dir %{_libdir}/gcj/%{name} %{_libdir}/gcj/%{name}/%{upstream_name}.* %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 3.5.0-8 +- Update to build against Eclipse SDK 3.4 + * Mon Feb 18 2008 Fedora Release Engineering - 3.5.0-7 - Autorebuild for GCC 4.3 -------------- next part -------------- ? .build-1.3.14-3.fc10.log ? .build-1.3.18-1.fc10.log ? META-INF ? about.html ? about_files ? clog ? eclipse-pydev-1.3.14 ? eclipse-pydev-1.3.18 ? eclipse-pydev-1.3.18-1.fc10.src.rpm ? noarch ? org.python.pydev.feature-src-1_3_18.zip ? plugin.properties ? test Index: eclipse-pydev.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-pydev/devel/eclipse-pydev.spec,v retrieving revision 1.10 diff -u -r1.10 eclipse-pydev.spec --- eclipse-pydev.spec 17 Jul 2008 19:05:07 -0000 1.10 +++ eclipse-pydev.spec 30 Jul 2008 21:05:48 -0000 @@ -1,26 +1,24 @@ Epoch: 1 +%define eclipse_base %{_libdir}/eclipse %define gcj_support 1 -# All arches line up except i386 -> x86 -%ifarch %{ix86} -%define eclipse_arch x86 -%else -%define eclipse_arch %{_arch} -%endif - Summary: Eclipse Python development plug-in Name: eclipse-pydev -Version: 1.3.14 -Release: 2%{?dist} +Version: 1.3.18 +Release: 1%{?dist} License: EPL URL: http://pydev.sourceforge.net/ Group: Development/Tools -Source0: http://downloads.sourceforge.net/pydev/org.python.pydev.feature-src-1_3_14.zip +Source0: http://downloads.sourceforge.net/pydev/org.python.pydev.feature-src-1_3_18.zip Source1: org.python.pydev.mylyn.feature-fetched-src-pydev_1_3_7.tar.bz2 Source2: fetch-pydev-mylyn.sh +# Back-port from HEAD +# http://pydev.cvs.sourceforge.net/pydev/org.python.pydev/src/org/python/copiedfromeclipsesrc/CopiedWorkbenchLabelProvider.java?revision=1.3&view=markup +Patch0: %{name}-%{version}-compileerrors.patch + %if %{gcj_support} BuildRequires: gcc-java >= 4.1.2 BuildRequires: java-1.5.0-gcj-devel >= 1.5.0 @@ -59,6 +57,7 @@ %prep %setup -q -c +%patch0 tar jxf %{SOURCE1} @@ -108,66 +107,37 @@ rm -f plugins/org.python.pydev.refactoring/contrib/ch/hsr/ukistler/astgraph/jgraph.jar %build -# Copy the SDK for build -/bin/sh -x %{_datadir}/eclipse/buildscripts/copy-platform SDK %{_datadir}/eclipse mylyn -SDK=$(cd SDK > /dev/null && pwd) - -# Eclipse may try to write to the home directory. -mkdir home -homedir=$(cd home > /dev/null && pwd) - -# build the main pydev feature -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.python.pydev.feature \ - -DbaseLocation=$SDK \ - -DsourceDirectory=$(pwd) \ - -DjavacSource=1.5 -DjavacTarget=1.5 \ - -DbuildDirectory=$(pwd)/build \ - -Dbuilder=%{_datadir}/eclipse/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{_datadir}/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml \ - -vmargs -Duser.home=$homedir +%{eclipse_base}/buildscripts/pdebuild \ + -a "-DjavacSource=1.5 -DjavacTarget=1.5" \ + -f org.python.pydev.feature # no xmlrpc3 -> no mylyn on ppc64 due to: # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239123 %ifnarch ppc64 -# build the pydev mylyn feature -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.python.pydev.mylyn.feature \ - -DbaseLocation=$SDK \ - -DsourceDirectory=$(pwd) \ - -DjavacSource=1.5 -DjavacTarget=1.5 \ - -DbuildDirectory=$(pwd)/build \ - -Dbuilder=%{_datadir}/eclipse/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{_datadir}/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml \ - -vmargs -Duser.home=$homedir +%{eclipse_base}/buildscripts/pdebuild \ + -a "-DjavacSource=1.5 -DjavacTarget=1.5" \ + -d mylyn \ + -f org.python.pydev.mylyn.feature %endif %install rm -rf $RPM_BUILD_ROOT -install -d -m755 ${RPM_BUILD_ROOT}/%{_datadir}/eclipse +installDir=${RPM_BUILD_ROOT}/%{eclipse_base}/dropins/pydev +install -d -m755 $installDir +install -d -m755 ${installDir}-mylyn # pydev main feature -unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/.. \ - build/rpmBuild/org.python.pydev.feature.zip +unzip -q -d $installDir build/rpmBuild/org.python.pydev.feature.zip # no xmlrpc3 -> no mylyn on ppc64 due to: # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239123 %ifnarch ppc64 # pydev mylyn feature -unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/.. \ - build/rpmBuild/org.python.pydev.mylyn.feature.zip +unzip -q -d ${installDir}-mylyn build/rpmBuild/org.python.pydev.mylyn.feature.zip %endif # deal with linked deps -pushd $RPM_BUILD_ROOT%{_datadir}/eclipse/plugins +pushd $installDir/eclipse/plugins rm -rf org.python.pydev.core_%{version}/commons-codec.jar ln -sf %{_datadir}/java/jakarta-commons-codec.jar \ org.python.pydev.core_%{version}/commons-codec.jar @@ -196,20 +166,11 @@ %files %defattr(-,root,root,-) -%{_datadir}/eclipse/features/org.python.pydev* -%{_datadir}/eclipse/plugins/org.python.pydev_* -%{_datadir}/eclipse/plugins/org.python.pydev.ast* -%{_datadir}/eclipse/plugins/org.python.pydev.core* -%{_datadir}/eclipse/plugins/org.python.pydev.debug* -%{_datadir}/eclipse/plugins/org.python.pydev.help* -%{_datadir}/eclipse/plugins/org.python.pydev.parser* -%{_datadir}/eclipse/plugins/org.python.pydev.templates* -%{_datadir}/eclipse/plugins/org.python.pydev.jython* -%{_datadir}/eclipse/plugins/org.python.pydev.refactoring* +%{eclipse_base}/dropins/pydev # no xmlrpc3 -> no mylyn on ppc64 due to: # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239123 %ifnarch ppc64 -%{_datadir}/eclipse/plugins/org.python.pydev.mylyn* +%{eclipse_base}/dropins/pydev-mylyn %endif %if %{gcj_support} @@ -217,6 +178,11 @@ %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 1:1.3.18-1 +- 1.3.18 +- Update for building with Eclipse SDK 3.4 +- Back-port patch from HEAD for building against Eclipse SDK 3.4 + * Thu Jul 17 2008 Tom "spot" Callaway 1:1.3.14-2 - fix license tag -------------- next part -------------- ? .build-4.0-1.b3.fc10.2.log Index: eclipse-photran.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-photran/devel/eclipse-photran.spec,v retrieving revision 1.2 diff -u -r1.2 eclipse-photran.spec --- eclipse-photran.spec 19 Feb 2008 17:02:43 -0000 1.2 +++ eclipse-photran.spec 30 Jul 2008 16:19:18 -0000 @@ -2,20 +2,12 @@ %define major 4 %define minor 0 %define majmin %{major}.%{minor} -%define eclipse_base %{_datadir}/eclipse -%define eclipse_lib_base %{_libdir}/eclipse - -# All arches line up except i386 -> x86 -%ifarch %{ix86} -%define eclipse_arch x86 -%else -%define eclipse_arch %{_arch} -%endif +%define eclipse_base %{_libdir}/eclipse Summary: Eclipse Fortran Development Tools (Photran) plugin Name: eclipse-photran Version: %{majmin} -Release: 1.b3%{?dist}.1 +Release: 1.b3%{?dist}.2 License: EPL Group: Development/Tools URL: http://www.eclipse.org/photran @@ -66,43 +58,15 @@ export JAVA_HOME=%{java_home} export PATH=%{java_bin}:/usr/bin:$PATH -# See comments in the script to understand this. -/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} cdt -SDK=$(cd SDK >/dev/null && pwd) - -# Eclipse may try to write to the home directory. -mkdir home -homedir=$(cd home > /dev/null && pwd) - -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{eclipse_lib_base}/configuration \ - -Duser.home=$homedir \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.eclipse.photran_feature \ - -DsourceDirectory=$(pwd) \ - -DbuildDirectory=$(pwd)/build \ - -DbaseLocation=$SDK \ - -DjavacSource=1.5 \ - -DjavacTarget=1.5 \ - -Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml - +%{eclipse_base}/buildscripts/pdebuild -d cdt \ + -a "-DjavacSource=1.5 -DjavacTarget=1.5" %install rm -rf ${RPM_BUILD_ROOT} -install -d -m755 ${RPM_BUILD_ROOT}/%{eclipse_base} - -unzip -d ${RPM_BUILD_ROOT}/%{_datadir} build/rpmBuild/org.eclipse.photran_feature.zip +install -d -m755 ${RPM_BUILD_ROOT}/%{eclipse_base}/dropins/photran -# We move arch-specific plugins to libdir. -mkdir -p ${RPM_BUILD_ROOT}%{eclipse_lib_base}/plugins -for archplugin in $(find ${RPM_BUILD_ROOT}%{eclipse_base}/plugins -name \*%{eclipse_arch}_%{version}\*); do - mv $archplugin ${RPM_BUILD_ROOT}%{eclipse_lib_base}/plugins - chmod -R 755 ${RPM_BUILD_ROOT}%{eclipse_lib_base}/plugins/$(basename $archplugin) -done +unzip -d ${RPM_BUILD_ROOT}/%{eclipse_base}/dropins/photran build/rpmBuild/org.eclipse.photran_feature.zip %if %{gcj_support} aot-compile-rpm @@ -123,13 +87,17 @@ %files %defattr(-,root,root) %doc org.eclipse.photran-feature/epl-v10.html -%{eclipse_base}/plugins/* +%{eclipse_base}/dropins/photran %if %{gcj_support} %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 4.0-1.b3 +- Update for building against Eclipse SDK 3.4 +- Move everything to %%{_libdir} + * Tue Feb 19 2008 Fedora Release Engineering - 4.0-1.b3.1 - Autorebuild for GCC 4.3 -------------- next part -------------- ? .build-0.3.1-2.fc10.log ? eclipse-egit-0.3.1 ? eclipse-egit-0.3.1-2.fc10.src.rpm ? noarch Index: eclipse-egit.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-egit/devel/eclipse-egit.spec,v retrieving revision 1.13 diff -u -r1.13 eclipse-egit.spec --- eclipse-egit.spec 17 Jul 2008 15:11:03 -0000 1.13 +++ eclipse-egit.spec 30 Jul 2008 16:14:12 -0000 @@ -4,7 +4,7 @@ Summary: Eclipse Git plug-in Name: eclipse-egit Version: 0.3.1 -Release: 1%{?dist} +Release: 2%{?dist} License: EPL and GPLv2 and LGPLv2 URL: http://repo.or.cz/w/egit.git Group: Development/Tools @@ -40,35 +40,16 @@ %setup -q -c %build -# Copy the SDK for build -/bin/sh -x %{_datadir}/eclipse/buildscripts/copy-platform SDK %{_datadir}/eclipse -SDK=$(cd SDK > /dev/null && pwd) - -# Eclipse may try to write to the home directory. -mkdir home -homedir=$(cd home > /dev/null && pwd) - -# build the main egit feature -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.spearce.egit \ - -DbaseLocation=$SDK \ - -DjavacSource=1.5 -DjavacTarget=1.5 \ - -DsourceDirectory=$(pwd) \ - -DbuildDirectory=$(pwd)/build \ - -Dbuilder=%{_datadir}/eclipse/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{_datadir}/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml \ - -vmargs -Duser.home=$homedir +%{_libdir}/eclipse/buildscripts/pdebuild \ + -a "-DjavacSource=1.5 -DjavacTarget=1.5" %install rm -rf $RPM_BUILD_ROOT -install -d -m755 $RPM_BUILD_ROOT/%{_datadir}/eclipse +installDir=$RPM_BUILD_ROOT/%{_libdir}/eclipse/dropins/egit +install -d -m755 $installDir # egit main feature -unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/.. \ +unzip -q -d $installDir/ \ build/rpmBuild/org.spearce.egit.zip %if %{gcj_support} @@ -85,16 +66,16 @@ %files %defattr(-,root,root,-) -%{_datadir}/eclipse/features/org.spearce.egit* -%{_datadir}/eclipse/plugins/org.spearce.egit* -%{_datadir}/eclipse/plugins/org.spearce.egit.core* -%{_datadir}/eclipse/plugins/org.spearce.egit.ui* -%{_datadir}/eclipse/plugins/org.spearce.jgit* +%{_libdir}/eclipse/dropins/egit %if %{gcj_support} %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 0.3.1-2 +- Move files and update build for Eclipse SDK 3.4 +- Use pdebuild + * Thu Jul 17 2008 Tom "spot" Callaway - 0.3.1-1 - fix license tag From robert at marcanoonline.com Thu Jul 31 19:32:19 2008 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 31 Jul 2008 15:02:19 -0430 Subject: [fedora-java] Re: Eclipse 3.4 In-Reply-To: <20080731190729.GB14841@redhat.com> References: <20080731190729.GB14841@redhat.com> Message-ID: <1217532739.4199.9.camel@localhost.localdomain> On Thu, 2008-07-31 at 15:07 -0400, Andrew Overholt wrote: > Hi, > > I've finally got version 3.4 of the Eclipse SDK ready to go, targetting > Fedora 10: > Good news, looks like the Subversive plugin still is not part of the base platform like CVS, I am maintaining the subclipse package but it had not much activity recently. ummmm maybe I should try it. is someone working on packaging another Ganymede subprojects? just yesterday I had to install as a requirement for m2eclipse (Maven integration plugins needed to work with JBoss EJB3 sources from eclipse), and I do not like any non OS updater :-). I remember that EMF was previously packaged > http://koji.fedoraproject.org/koji/buildinfo?buildID=58121 > > (See [1] for an in-progress build with some minor fixes.) > > Action item for plugin package maintainers: > ------------------------------------------- > Please look at the relevant attached patches and apply them or something > like them in the devel directory of your plugin(s). Feel free to commit > and tag but note that you won't be able to build until I tag the build > for rawhide. > > Email me personally if you have questions. Please also let me know when > you're finished and I can do koji builds of everything in the right > order (chain-build or otherwise). I'd like to do this very soon so > please take a few minutes to apply the changes. > > Testing of the above build is greatly appreciated. > ------------------------------------------- > > There are a few minor changes for packagers of plugins/features: > > - Bits are now installed to %{_libdir}/eclipse instead of > %{_datadir}/eclipse. This brings us in line with upstream's file layout > and avoids the crazy split-install osgi.sharedConfiguration.area hack. > It's also what Debian does, FWIW. > > - p2 is the new provisioning platform in 3.4. Essentially it replaces the > old update manager but does other things as well. It requires > Eclipse-based apps to use profiles -- like Mozilla profiles -- and manage > them using its "director". In order to avoid fragile %post scriptlets, > we're going to use the "dropins mechanism" for plugin installation. This > means that all non-Eclipse platform plugins will be installed into their > own directory under %{_libdir}/eclipse/dropins. There are a variety of > layouts that are acceptable to p2, but we'll largely be going with > dropins/eclipse//{plugins,features}. This has the nice side > benefit of simplifying %files sections :) . See [2] for more > information here. > > - I added a flag to the pdebuild script to allow for Orbit-style > dependencies. If you don't know what this means, that's okay, but if > a plugin you want to package uses Orbit dependencies, you'll want to > use the -o flag to pdebuild. Plugins that use non-Eclipse JARs but > don't have a lib directory with JARs are probably using Orbit-style > dependencies. They'll have Require-Bundle or Import-Package entries > in their plugin MANIFEST.MFs. See eclipse-mylyn for an example of how > to use pdebuild in this case. > > - I've renamed (and Obsoleted/Provided) libswt3-gtk2 to eclipse-swt. I > can't count the number of times people have been confused by this > naming and since we're not going to ship swt2 or swt.motif any time > soon, the naming is silly. I also folded pde-runtime into pde since > PHPEclipse no longer needs the separate pde-runtime package. > > Outside of the CDT and the SELinux tools (both maintainers are working on > the necessary changes themselves), I've got patches for all of the plugins > we have as packages in Fedora. I've attached these patches and CC'd all of > the maintainers. > > I will update the packaging guidelines very soon with the above > information. > > Thanks, > > Andrew > > [1] > Build with branding fixed and removing some unnecessary Requires(post) > and the pde-runtime package which is now folded into pde: > http://koji.fedoraproject.org/koji/taskinfo?taskID=750696 > > [2] > There are some performance considerations here. Since it's generating > the associated metadata and "provisioning" the bits on the fly based on > files dropped into a directory, users may notice a slightly longer > startup the first time they start the Eclipse IDE after installing a new > plugin package. Subsequent startups won't be impacted. There is a lot > of performance improvement work going on upstream and much of it will > land in 3.4.1. If 3.4.1 is released early enough, we'll ship it in > Fedora 10. If not, we can ship it as an update. Should testing between > now and Fedora 10 show unacceptably poor performance (I haven't noticed > this in my own testing), we can look at back-porting some of the > performance work. The other main way of speeding up dropins-installed > plugins is by shipping pre-generated p2 metadata (like yum metadata). > I've experimented with this and think I can make it so that we > transparently generate it via pdebuild meaning it would only require a > rebuild of Fedora plugin packages. Things will work without these > generated content.xml files so in the interest of getting testing sooner > rather than later, I'm going to push ahead without the metadata for > dropins. From robert at marcanoonline.com Thu Jul 31 19:45:18 2008 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 31 Jul 2008 15:15:18 -0430 Subject: [fedora-java] Re: Eclipse 3.4 In-Reply-To: <1217532739.4199.9.camel@localhost.localdomain> References: <20080731190729.GB14841@redhat.com> <1217532739.4199.9.camel@localhost.localdomain> Message-ID: <1217533518.4199.13.camel@localhost.localdomain> On Thu, 2008-07-31 at 15:02 -0430, Robert Marcano wrote: > On Thu, 2008-07-31 at 15:07 -0400, Andrew Overholt wrote: > > Hi, > > > > I've finally got version 3.4 of the Eclipse SDK ready to go, targetting > > Fedora 10: > > > > Good news, looks like the Subversive plugin still is not part of the > base platform like CVS, I am maintaining the subclipse package but it > had not much activity recently. ummmm maybe I should try it. ooop my mistake , subclipse is at 1.4.3 and I have packaged 1.2.4, the last time I checked it was at 1.4.2, (and 1.2.4 != 1.4.2 I need glasses) > > is someone working on packaging another Ganymede subprojects? just > yesterday I had to install as a requirement for m2eclipse (Maven > integration plugins needed to work with JBoss EJB3 sources from > eclipse), and I do not like any non OS updater :-). I remember that EMF > was previously packaged > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=58121 > > > > (See [1] for an in-progress build with some minor fixes.) > > > > Action item for plugin package maintainers: > > ------------------------------------------- > > Please look at the relevant attached patches and apply them or something > > like them in the devel directory of your plugin(s). Feel free to commit > > and tag but note that you won't be able to build until I tag the build > > for rawhide. > > > > Email me personally if you have questions. Please also let me know when > > you're finished and I can do koji builds of everything in the right > > order (chain-build or otherwise). I'd like to do this very soon so > > please take a few minutes to apply the changes. > > > > Testing of the above build is greatly appreciated. > > ------------------------------------------- > > > > There are a few minor changes for packagers of plugins/features: > > > > - Bits are now installed to %{_libdir}/eclipse instead of > > %{_datadir}/eclipse. This brings us in line with upstream's file layout > > and avoids the crazy split-install osgi.sharedConfiguration.area hack. > > It's also what Debian does, FWIW. > > > > - p2 is the new provisioning platform in 3.4. Essentially it replaces the > > old update manager but does other things as well. It requires > > Eclipse-based apps to use profiles -- like Mozilla profiles -- and manage > > them using its "director". In order to avoid fragile %post scriptlets, > > we're going to use the "dropins mechanism" for plugin installation. This > > means that all non-Eclipse platform plugins will be installed into their > > own directory under %{_libdir}/eclipse/dropins. There are a variety of > > layouts that are acceptable to p2, but we'll largely be going with > > dropins/eclipse//{plugins,features}. This has the nice side > > benefit of simplifying %files sections :) . See [2] for more > > information here. > > > > - I added a flag to the pdebuild script to allow for Orbit-style > > dependencies. If you don't know what this means, that's okay, but if > > a plugin you want to package uses Orbit dependencies, you'll want to > > use the -o flag to pdebuild. Plugins that use non-Eclipse JARs but > > don't have a lib directory with JARs are probably using Orbit-style > > dependencies. They'll have Require-Bundle or Import-Package entries > > in their plugin MANIFEST.MFs. See eclipse-mylyn for an example of how > > to use pdebuild in this case. > > > > - I've renamed (and Obsoleted/Provided) libswt3-gtk2 to eclipse-swt. I > > can't count the number of times people have been confused by this > > naming and since we're not going to ship swt2 or swt.motif any time > > soon, the naming is silly. I also folded pde-runtime into pde since > > PHPEclipse no longer needs the separate pde-runtime package. > > > > Outside of the CDT and the SELinux tools (both maintainers are working on > > the necessary changes themselves), I've got patches for all of the plugins > > we have as packages in Fedora. I've attached these patches and CC'd all of > > the maintainers. > > > > I will update the packaging guidelines very soon with the above > > information. > > > > Thanks, > > > > Andrew > > > > [1] > > Build with branding fixed and removing some unnecessary Requires(post) > > and the pde-runtime package which is now folded into pde: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=750696 > > > > [2] > > There are some performance considerations here. Since it's generating > > the associated metadata and "provisioning" the bits on the fly based on > > files dropped into a directory, users may notice a slightly longer > > startup the first time they start the Eclipse IDE after installing a new > > plugin package. Subsequent startups won't be impacted. There is a lot > > of performance improvement work going on upstream and much of it will > > land in 3.4.1. If 3.4.1 is released early enough, we'll ship it in > > Fedora 10. If not, we can ship it as an update. Should testing between > > now and Fedora 10 show unacceptably poor performance (I haven't noticed > > this in my own testing), we can look at back-porting some of the > > performance work. The other main way of speeding up dropins-installed > > plugins is by shipping pre-generated p2 metadata (like yum metadata). > > I've experimented with this and think I can make it so that we > > transparently generate it via pdebuild meaning it would only require a > > rebuild of Fedora plugin packages. Things will work without these > > generated content.xml files so in the interest of getting testing sooner > > rather than later, I'm going to push ahead without the metadata for > > dropins. > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From overholt at redhat.com Thu Jul 31 19:47:26 2008 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 31 Jul 2008 15:47:26 -0400 Subject: [fedora-java] Re: Eclipse 3.4 In-Reply-To: <1217532739.4199.9.camel@localhost.localdomain> References: <20080731190729.GB14841@redhat.com> <1217532739.4199.9.camel@localhost.localdomain> Message-ID: <20080731194726.GA17148@redhat.com> Hi, * Robert Marcano [2008-07-31 15:33]: > On Thu, 2008-07-31 at 15:07 -0400, Andrew Overholt wrote: > > Hi, > > > > I've finally got version 3.4 of the Eclipse SDK ready to go, targetting > > Fedora 10: > > Good news, looks like the Subversive plugin still is not part of the > base platform like CVS, I am maintaining the subclipse package but it > had not much activity recently. ummmm maybe I should try it. I have never had any luck with Subversive due to the lack of easily-installed ssh-agent integration. Your subclipse package has always treated me well :) Thanks for maintaining it! > is someone working on packaging another Ganymede subprojects? I maintain Mylyn and we also have the CDT but I think that may be it among the Ganymede projects. I'd like to think it's not that hard to package plugins these days. Hopefully the 'stubby' project at the Linux distros project (eclipse.org) will help in the future. > I remember that EMF was previously packaged Yeah, I used to do this but didn't have time to do the work required when they re-organized upstream. Andrew From markphip at gmail.com Thu Jul 31 23:37:50 2008 From: markphip at gmail.com (Mark Phippard) Date: Thu, 31 Jul 2008 23:37:50 +0000 (UTC) Subject: [fedora-java] Re: Eclipse 3.4 References: <20080731190729.GB14841@redhat.com> <1217532739.4199.9.camel@localhost.localdomain> <1217533518.4199.13.camel@localhost.localdomain> Message-ID: Robert Marcano writes: > > On Thu, 2008-07-31 at 15:02 -0430, Robert Marcano wrote: > > On Thu, 2008-07-31 at 15:07 -0400, Andrew Overholt wrote: > > > Hi, > > > > > > I've finally got version 3.4 of the Eclipse SDK ready to go, targetting > > > Fedora 10: > > > > > > > Good news, looks like the Subversive plugin still is not part of the > > base platform like CVS, I am maintaining the subclipse package but it > > had not much activity recently. ummmm maybe I should try it. > > ooop my mistake , subclipse is at 1.4.3 and I have packaged 1.2.4, the > last time I checked it was at 1.4.2, (and 1.2.4 != 1.4.2 I need glasses) 1.4.2 is the current "release". 1.4.3 will be out fairly soon though. The architecture has changed quite a bit with 1.4.x. Email us at dev at subclipse.tigris.org if you have troubles packaging it. In theory the changes should give quite a lot of new flexibility. Mark