Spec URL: http://cdn.verbum.org/gluegen.spec SRPM URL: http://cdn.verbum.org/gluegen-1.0-0.1.20080329cvs.fc9.src.rpm %description GlueGen is a tool which automatically generates the Java and JNI code necessary to call C libraries. It reads as input ANSI C header files and separate configuration files which provide control over many aspects of the glue code generation. GlueGen uses a complete ANSI C parser and an internal representation (IR) capable of representing all C types to represent the APIs for which it generates interfaces.
Some preliminary notes: I cannot install F-9 for now so I won't be able to test with F-9 openJDK-1.6 Testing with java >= 1.6 for now on x86_64. Ok the main problem with this package is about the content of make/lib/. According to the new packaging guidelines, we have to remove the bundled .jar and .class files. If removed, the current package doesn't build anymore (even if using your patch or defining ant -v -Dantlr.jar=$(build-classpath antlr) at build time. Suggested BR and Requires: BuildRequires: java-devel >= 1.6 BuildRequires: jpackage-utils >= 1.6 BuildRequires: ant, ant-contrib, ant-antlr (not sure for each of them). Requires: jpackage-utils >= 1.6 Requires: java >= 1.6 I wonder if ant-antlr will be Requested at runtime; maybe others will be needed. Suggested Group: Group: Development/Libraries Can you use %{_javadir} when appropriate (instead of %{_datadir}/java ). This make me think that gluegen uses a patched version of cpptasks, and i don't know how to force it to use the system one (if possible and relevant). Found some patches here to support ppc build: http://patches.ubuntu.com/by-release/extracted/debian/libj/libjogl-java/1.1.1~rc8-3/ I wonder if we need to add our $RPM_OPT_FLAGS in java packages: gcc -c -fno-rtti -fPIC -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include/linux /builddir/build/BUILD/gluegen/src/native/unix/UnixDynamicLinkerImpl_JNI.c [cc] cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C Since you have created a snapshot, it would be nicer if you can create a script to make this snapshot, remove the included .jar files, and fix (executable) permissions for most files. LICENSE.txt will need to be bundled. manual seems to be missing.
Since this depends on jogl, which is blocked by FE-Legal, I'm closing this CANTFIX. You may want to take both of them over to Livna/RPMFusion non-free.
I believe it's the other way around - jogl depends on gluegen. So this package should potentially be able to go in.
Ahh, okay.
@Colin Any thought on #1 ? I could formally Review the package once I get an answer...
@Colin. Gluegen could probably be extracted to the jogl release 1.1.1. Maybe we can have the jogl problematic license replaced (like what was done for glew if i remember). If not possible, i'm thinking of having jogl submitted in a third part repository.
Any updates here? Things seem to have been waiting on a response from Colin for a few months now. Setting needinfo; I guess I'll close this if there's no response soon.
Over two months later, I'm just going to close this.
why? it seems FE-Legal block was released. wouldn't like to reopen?
I'll try to work on this package. If all works fine is ok to reopen this review process?
This is my first draft of the RPM for gluegen. As I've commented in the Scilab's review, I'm not an experienced packager (in fact, I am still learning) but I like to contribute in any way to take Scilab officially in Fedora as soon as possible, since it is a very important software for various tipes of engineering. I was able to generate the RPM of gluegen and the documentation, but rpmlint still has some errors (which I do not know how to solve). I have some time to devote to the package in this weekend and in the next week, so if you have some patience to guide me, I'll be very happy to help. =) By the way, this spec is based on Mandriva's and Colin Walters's specs. SPEC: http://lspooky.fedorapeople.org/gluegen/1.0-1/gluegen.spec SRPM: http://lspooky.fedorapeople.org/gluegen/1.0-1/gluegen-1.0-1.20090305cvs.fc10.src.rpm rpmlint errors: [lonely@localhost i386]$ rpmlint gluegen-1.0-1.20090305cvs.fc10.i386.rpm gluegen.i386: W: no-documentation gluegen.i386: W: non-standard-group Libraries gluegen.i386: W: unstripped-binary-or-object /usr/lib/libgluegen-rt.so gluegen.i386: W: no-soname /usr/lib/libgluegen-rt.so gluegen.i386: W: class-path-in-manifest /usr/share/java/gluegen-1.0.jar 1 packages and 0 specfiles checked; 0 errors, 5 warnings. [lonely@localhost i386]$ rpmlint gluegen-manual-1.0-1.20090305cvs.fc10.i386.rpm gluegen-manual.i386: W: spurious-executable-perm /usr/share/doc/gluegen-manual-1.0/manual/index.html gluegen-manual.i386: W: non-standard-group Libraries 1 packages and 0 specfiles checked; 0 errors, 2 warnings. [lonely@localhost SRPMS]$ rpmlint gluegen-1.0-1.20090305cvs.fc10.src.rpm gluegen.src: W: non-standard-group Libraries 1 packages and 0 specfiles checked; 0 errors, 1 warnings.
A few off-the-cuff comments: I think: ># vs -d :pserver:username.java.net:/cvs checkout gluegen Should be: # cvs -d :pserver:username.java.net:/cvs checkout gluegen The error: >gluegen.i386: W: no-documentation Means that you should have the doc macro. Normally you would include things such as a changelog, licence files and readme stuff, or other such things: Its easy fixed just use something like: %doc LICENSE.txt README CHANGELOG or similar in your %files section. >gluegen.i386: W: non-standard-group Libraries Change: Group: Libraries To: Group: Development/Libraries For each instance >gluegen.i386: W: class-path-in-manifest /usr/share/java/gluegen-1.0.jar Looks like your jar file has a MANIFEST in it. You need to sort this out, not sure exactly what is the best way. >gluegen.i386: W: no-soname /usr/lib/libgluegen-rt.so You may need to tell GCC what soname to use. See bug 464781 comment 27 >gluegen-manual.i386: W: spurious-executable-perm Sounds like "/usr/share/doc/gluegen-manual-1.0/manual/index.html" in your rpm has bad permissions. You may need to chmod it. >gluegen.i386: W: unstripped-binary-or-object /usr/lib/libgluegen-rt.so .so files need to be executable for rpmbuild to strip them (I fell into this trap). Can this be re-opened?
A few more, that I missed earlier: Summary: User documetation for %{name} Typo "documentation" Can you throw in the no-bad jar check, for those of us too lazy to grab the SRPM? Its in https://fedoraproject.org/wiki/Packaging:Java#Pre-built_JAR_files_.2F_Other_bundled_software Also this page has the MANIFEST problem (with solution) outlined. Finally, if possible a scratch build would be great http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Scratch_Builds
>You may need to tell GCC what soname to use. See bug 464781 comment 27 Apologies for more noise, that link is for the so executable problem. The link for the soname issue is : bug 474787 comment 6 .
Hi, only to keep you updated, I'm - still - working in this package: rpmling has 3 complains to solve (the worse ones, I think): [lonely@localhost i386]$ rpmlint . gluegen.i386: W: unstripped-binary-or-object /usr/lib/libgluegen-rt.so gluegen.i386: W: no-soname /usr/lib/libgluegen-rt.so gluegen.i386: W: class-path-in-manifest /usr/share/java/gluegen-1.0.jar 2 packages and 0 specfiles checked; 0 errors, 3 warnings. And following D Haley's hints I know that I must not use the .jar files provided in the sources: These JAR files should be deleted and symlinked to system JAR files: ./make/lib/cdc_fp.jar ./make/lib/cpptasks.jar ./make/lib/JOGLDocLinksGeneratorAndLibs.jar I'm sorry to say, but I'm completely blind in java and I do not know how to provide this libraries and this will take some more time.
You may wish too work out what bug 167525 is all about.
> gluegen.i386: W: no-soname /usr/lib/libgluegen-rt.so This may not be right, but when ant builds the so file using the gcc rule in the build.xml, see if the arguments listing has something that looks like the following (pinched from http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html). gcc -shared -Wl,-soname,your_soname \ -o library_name file_list library_list If it doesn't you may need to patch build.xml. Your soname should, I believe, be glugen-rt in this case.
Hi, Haley, As I can see we're in the "the chicken or the egg" paradox... to make gluegen we need cpptasks 167525 and jogl 439630 , but jogl depends on gluegen, so, if we solve this soname problem, gluegen may not be approved since jogl and cpptasks are not in our repos, right?
Sorry for the noise We have some substantial work done right here: https://bugzilla.redhat.com/show_bug.cgi?id=439630#c19 maybe if we mix some solutions we get better results.
To build gluegen you shouldn't need jogl (see comment 3). Jogl needs gluegen, however and it wants it in source form, which is a problem for us, but not a problem that needs to be tackled here. To build gluegen, however, you will need cpptasks. >gluegen may not be approved since jogl and >cpptasks are not in our repos, right? If you get a good SPEC for this, without cpptasks you might not get approval and cpptasks will need to be finished first.
So, I'll take a look at cpptasks at first and see if I'm able to package it
Created attachment 345573 [details] Updated spec file I have updated spec file from that Henrique was generated. With this spec file, I get only one warning: $ rpmlint gluegen-1.0-0.20090527.svn.fc10.x86_64.rpm gluegen.x86_64: W: no-soname /usr/lib64/libgluegen-rt.so 1 packages and 0 specfiles checked; 0 errors, 1 warnings. I'm not familiar with this issue. So I hope someone will help for this issue.
Having gluegen splitted isn't that difficult, what remains harder is to have this version of gluegen used to build jogl. (at least, last time I've tried). (then jogl used by openjdk will be the next step) soname is stand for Shared Object NAME, aka the internal name of the library which is defined at link time. usually readelf -a any_system_library.so.x |grep SONAME will show you the one used to recognize the library. But I don't know how ant do to generate soname nor if that's usefull for a java architecture dependant package. (I guess it is).
Created attachment 345591 [details] Updated spec fie with manual as a separated package We hope jogl will bundled as a Fedora package.
OK, seeing as no-one else has so far proposed a package that everyone can agree on, here's my shot: SPEC URL : http://dhd.selfip.com/427e/gluegen.spec SRPM URL : http://dhd.selfip.com/427e/gluegen-1.0-0.135.svn.fc10.src.rpm koji: No, requires cpptasks (can someone reopen cpptasks?) rpmlint: $ rpmlint gluegen.spec ../SRPMS/gluegen-1.0-0.135.svn.fc10.src.rpm ../RPMS/i386/gluegen-1.0-0.135.svn.fc10.i386.rpm 2 packages and 1 specfiles checked; 0 errors, 0 warnings.
Again what need to be done is to see if this gluegen is capable to build jogl. If not, there is no reason to validate this package because it will fail the usability test of the package review.
I think you might be looking at this from a slightly different perspective. If we want jogl to build, we need to modify the jogl build system to decouple it from gluegen. Jogl itself will work with gluegen *once built* -- its a matter of tricking ant to do what we need. I had a shot at this a while back, and was able to decouple it, but some java errors I introduced caused some problems.
Is there interest in reopening this review bug now that cpptasks is available? If so, who is the submitter?
Hi, any movement here?
So, I did some minor changes, now, using our available cpptasks. [lonely@localhost i686]$ rpmlint gluegen-1.0-1.135.svn.fc12.i686.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. SPEC: http://lonelyspooky.com/uploads/SRPMs/gluegen/1.0-1.135.svn/gluegen.spec SRPM: http://lonelyspooky.com/uploads/SRPMs/gluegen/1.0-1.135.svn/gluegen-1.0-1.135.svn.fc12.src.rpm
With the current development version of gluegen and jogl, it is possible to build them separately. It is not optimal from the packaging point of view (jogl is going to search for gluegen files into ../gluegen/) but I have been able to produce independent packages for Debian. I will try to upload my patches tonight. Next time, try Scilab with jogl 2.0.
Hi, Sylvestre, As you said, I've tried to build jogl from tha latest source and it complains about gluegen: [lonely@localhost make]$ ant Buildfile: build.xml BUILD FAILED /home/lonely/jogl~jogl-git/make/build.xml:8: Cannot find ../../gluegen/make/gluegen-cpptasks.xml imported from /home/lonely/jogl~jogl-git/make/build.xml If we can work around this we can, finally, have scilab in Fedora.
Henrique, I just updated the bug #439630 with a preliminary patch for this.
http://gentoo-overlays.zugaina.org/java-overlay/portage/dev-java/gluegen/ http://gentoo-overlays.zugaina.org/java-overlay/portage/dev-java/jogl/ There's some patch for gluegen and jogl from gentoo overlay, I think it can works OK for fedora.
I'm able to build gluegen from the same tarball of jogl. Please, take a look at: SPEC: http://lspooky.fedorapeople.org/gluegen/1.1.1/1/gluegen.spec SRPM: http://lspooky.fedorapeople.org/gluegen/1.1.1/1/gluegen-1.1.1-1.fc12.src.rpm rpmlint looks (almost) clean, except for this problem with the source URL, since the source was repackaged: [lonely@localhost rpmbuild]$ rpmlint RPMS/i686/gluegen-1.1.1-1.fc12.i686.rpm gluegen.i686: W: class-path-in-manifest /usr/share/java/gluegen-1.1.1.jar 1 packages and 0 specfiles checked; 0 errors, 1 warnings. [lonely@localhost rpmbuild]$ rpmlint SRPMS/gluegen-1.1.1-1.fc12.src.rpm gluegen.src: W: invalid-url Source0: jogl.tar.gz 1 packages and 0 specfiles checked; 0 errors, 1 warnings.
Maybe you can use a different ustream of gluegen like # svn export -r "{2009-05-09}" https://gluegen.dev.java.net/svn/gluegen/trunk # gluegen --username xxx --password xxx See http://gentoo-overlays.zugaina.org/java-overlay/portage/dev-java/gluegen
From what I read (can not remember where), the problem is to maintain compatibility between JOGL and gluegen. It seems that JOGL does not compile with all versions of gluegen and therefore may be better to always use the married versions of the tarball. Since the development of both (JOGL and gluegen) is not very fast, a conservative position should be better.
(In reply to comment #37) > From what I read (can not remember where), the problem is to maintain > compatibility between JOGL and gluegen. It seems that JOGL does not compile > with all versions of gluegen and therefore may be better to always use the > married versions of the tarball. > Since the development of both (JOGL and gluegen) is not very fast, a > conservative position should be better. The following svn version gluegen can works file with jogl. gentoo uses it for scilab 5.2.0. You need register a username in www.dev.java.net. svn export -r "{2009-05-09}" https://gluegen.dev.java.net/svn/gluegen/trunk gluegen --username xxx --password xxx
Ok, I got the SVN version from upstream. It seems to build without problems. The 1.1.1 version of JOGL, in other way, started to complain: /home/lonely/jogl/jogl/make/build.xml:1562: The following error occurred while executing this line: /home/lonely/jogl/jogl/make/build.xml:576: GlueGen returned: 1 I have not tested the SVN version of JOGL (yet), bot as soon as possible I'll give it a try.
I have just updated gluegen to use the (recommended) svn version that upstrean uses with jogl. rpmlint is almost happy, but still complains about the invalid-url [lonely@localhost SPECS]$ rpmlint ../SRPMS/gluegen-1.0.20102502svn-2.fc12.src.rpm gluegen.src: W: invalid-url Source0: gluegen-1.0.20102502svn.tar.gz 1 packages and 0 specfiles checked; 0 errors, 1 warnings. [lonely@localhost SPECS]$ rpmlint ../RPMS/i686/gluegen-1.0.20102502svn-2.fc12.i686.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Ops, sorry: SPEC: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn-2/gluegen.spec SRPM: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn-2/gluegen-1.0.20102502svn-2.fc12.src.rpm
Here we go with a little update. This version makes, also, a package named gluegen-source, used by JOGL. spec: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/3/gluegen.spec srpm: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/3/gluegen-1.0.20102502svn-3.fc12.src.rpm
I guess is time to reopen this review. Should I create a new one?
*** This bug has been marked as a duplicate of bug 572512 ***