Bug 572512

*** Bug 439627 has been marked as a duplicate of this bug. ***

Please follow http://fedoraproject.org/wiki/Packaging/Java.
JAR files that require JNI shared objects MUST be installed in %{_libdir}/%{name}. The JNI shared objects themselves must also be installed in %{_libdir}/%{name}. 

Also, you maybe need to take a look at https://fedoraproject.org/wiki/Packaging/SourceURL

(In reply to comment #2)
> Please follow http://fedoraproject.org/wiki/Packaging/Java.
> JAR files that require JNI shared objects MUST be installed in
> %{_libdir}/%{name}. The JNI shared objects themselves must also be installed in
> %{_libdir}/%{name}. 
> 
> Also, you maybe need to take a look at
> https://fedoraproject.org/wiki/Packaging/SourceURL    

Thank you. I'm fixing it.

spec: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/4/gluegen.spec
srpm: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/4/gluegen-1.0.20102502svn-4.fc12.src.rpm
----------
[lonely@localhost SPECS]$ rpmlint ../SRPMS/gluegen-1.0.20102502svn-4.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-*
gluegen-debuginfo.i686: E: debuginfo-without-sources
2 packages and 0 specfiles checked; 1 errors, 0 warnings.

It seems that this "debuginfo-without-sources" issue can be ignored.
The source package is generating multiple issues in rpmlint, but I think it can be ignored too.

Ok, let's see what I've got so far.



#  MUST: rpmlint must be run on every package. The output should be posted in the review.[1]

[limb@paguroidea SPECS]$ rpmlint -i ../SRPMS/gluegen-1.0.20102502svn-4.fc12.src.rpm 
gluegen.src: W: invalid-url URL: https://gluegen.dev.java.net/ <urlopen error [Errno -3] Temporary failure in name resolution>
The value should be a valid, public HTTP, HTTPS, or FTP URL.

OK, I was offline.

gluegen.src: W: invalid-url Source0: gluegen-1.0.20102502svn.tar.gz
The value should be a valid, public HTTP, HTTPS, or FTP URL.

OK, SVN checkout.

1 packages and 0 specfiles checked; 0 errors, 2 warnings.

On the initail rpmlint run, there were tons of "internal vcs file" warnings.  Add the following to your tarball generation process:

find -name '.svn' | xargs rm -rf

After correcting this and rebuilding:

[limb@paguroidea SPECS]$ rpmlint -i ../RPMS/*/gluegen*
gluegen.i686: W: invalid-url URL: https://gluegen.dev.java.net/ <urlopen error [Errno -3] Temporary failure in name resolution>
The value should be a valid, public HTTP, HTTPS, or FTP URL.

gluegen-debuginfo.i686: W: invalid-url URL: https://gluegen.dev.java.net/ <urlopen error [Errno -3] Temporary failure in name resolution>
The value should be a valid, public HTTP, HTTPS, or FTP URL.

gluegen-debuginfo.i686: E: debuginfo-without-sources
This debuginfo package appears to contain debug symbols but no source files.
This is often a sign of binaries being unexpectedly stripped too early during
the build, or being compiled without compiler debug flags (which again often
is a sign of distro's default compiler flags ignored which might have security
consequences), or other compiler flags which result in rpmbuild's debuginfo
extraction not working as expected.  Verify that the binaries are not
unexpectedly stripped and that the intended compiler flags are used.

FIX  I'm not sure how this should work, as my Java-fu is weak.  If you can't fix this, disable the debuginfo as a last resort.

gluegen-source.noarch: W: invalid-url URL: https://gluegen.dev.java.net/ <urlopen error [Errno -3] Temporary failure in name resolution>
The value should be a valid, public HTTP, HTTPS, or FTP URL.

OK, see above.

gluegen-source.noarch: W: no-documentation
The package contains no documentation (README, doc, etc). You have to include
documentation files.

FIX

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/net/highteq/nativetaglet/NativeTaglet.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/dynlink-unix-CustomJavaCode.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/build.xml
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/BufferFactory.java.javame_cdc_fp
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/StructAccessor.java.javame_cdc_fp
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/UnixDynamicLinkerImpl.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/opengl/GLJavaMethodBindingEmitter.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/procaddress/ProcAddressCMethodBindingEmitter.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/gluegen.properties.antlr-properties.patch
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/validate-properties.xml
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/dynlink-windows-CustomJavaCode.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: W: spurious-executable-perm /usr/share/gluegen-source/gluegen/make/stub_includes/unix/dynamic-linker.h
The file is installed with executable permissions, but was identified as one
that probably should not be executable.  Verify if the executable bits are
desired, and remove if not.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/BufferFactory.java.javase
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/procaddress/ProcAddressConfiguration.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/procaddress/ProcAddressEmitter.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: W: spurious-executable-perm /usr/share/gluegen-source/gluegen/src/native/windows/WindowsDynamicLinkerImpl_JNI.c
The file is installed with executable permissions, but was identified as one
that probably should not be executable.  Verify if the executable bits are
desired, and remove if not.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/DynamicLookupHelper.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/NativeLibLoader.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: W: spurious-executable-perm /usr/share/gluegen-source/gluegen/src/native/unix/UnixDynamicLinkerImpl_JNI.c
The file is installed with executable permissions, but was identified as one
that probably should not be executable.  Verify if the executable bits are
desired, and remove if not.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/DynamicLinker.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/BufferFactoryInternal.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/opengl/GLConfiguration.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/StructAccessor.java.javase
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: W: spurious-executable-perm /usr/share/gluegen-source/gluegen/make/stub_includes/windows/dynamic-linker.h
The file is installed with executable permissions, but was identified as one
that probably should not be executable.  Verify if the executable bits are
desired, and remove if not.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/Manifest
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/dynlink-unix.cfg
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/gluegen.properties
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/dynlink-macosx.cfg
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/gluegen-cpptasks.xml
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/nativesig/NativeSignatureEmitter.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/MacOSXDynamicLinkerImpl.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/nativesig/NativeSignatureJavaMethodBindingEmitter.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/lib/cpptasks-version.txt
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: W: spurious-executable-perm /usr/share/gluegen-source/gluegen/make/stub_includes/macosx/dynamic-linker.h
The file is installed with executable permissions, but was identified as one
that probably should not be executable.  Verify if the executable bits are
desired, and remove if not.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/dynlink-windows.cfg
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/make/gluegen-cpptasks.xml.no-solaris.patch
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/procaddress/ProcAddressJavaMethodBindingEmitter.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: world-writable /usr/share/gluegen-source/gluegen 0777
A file or directory in the package is installed with world writable
permissions, which is most likely a security issue.

gluegen-source.noarch: E: non-standard-dir-perm /usr/share/gluegen-source/gluegen 0777
A standard directory should have permission set to 0755. If you get this
message, it means that you have wrong directory permissions in some dirs
included in your package.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/CPU.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/pcpp/ConcatenatingReader.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/cgram/types/SizeThunk.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: W: spurious-executable-perm /usr/share/gluegen-source/gluegen/src/native/macosx/MacOSXDynamicLinkerImpl_JNI.c
The file is installed with executable permissions, but was identified as one
that probably should not be executable.  Verify if the executable bits are
desired, and remove if not.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/WindowsDynamicLinkerImpl.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

gluegen-source.noarch: E: script-without-shebang /usr/share/gluegen-source/gluegen/src/java/com/sun/gluegen/runtime/NativeLibrary.java
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

FIX You can fix all of the above using find -name '*.java' | xargs chmod -x, rinse and repeat for .c, .xml, etc as needed.

3 packages and 0 specfiles checked; 40 errors, 10 warnings.



# MUST: The package must be named according to the Package Naming Guidelines .

OK

# MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. [2] .

OK

# MUST: The package must meet the Packaging Guidelines .

Looks like it doesn't run afoul of the Java guidelines.

# MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .

BSD: OK

Apple Public Source License: OK

make/stub_includes/unix/dynamic-linker.h
Copyright 1989 AT&T?!?!?!??!
What license is this file?  It says it's extracted from Solaris?


# MUST: The License field in the package spec file must match the actual license. [3]

See above.  At this point, it should be BSD and APSL 2.0

# MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.[4]

OK, pending above.

# MUST: The spec file must be written in American English. [5]

OK

# MUST: The spec file for the package MUST be legible. [6]

OK

# MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.

OK, SVN checkout.

# MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. [7]

OK, builds on i686.

# MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. [8]

OK

# MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.

OK, mock rawhide build was fine.

# MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9]

OK

# MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [10]

FIX  ldconfig is not called.

# MUST: Packages must NOT bundle copies of system libraries.[11]

OK

# MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [12]

NA

# MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [13]

OK

# MUST: A Fedora package must not list a file more than once in the spec file's %files listings. [14]

OK

# MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. [15]

See above.

# MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [16]

OK

# MUST: Each package must consistently use macros. [17]

OK

# MUST: The package must contain code, or permissable content. [18]

OK

# MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [19]

NA

# MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [19]

OK

# MUST: Header files must be in a -devel package. [20]

OK, the few .h are in -source

# MUST: Static libraries must be in a -static package. [21]

NA

# MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [22]

NA

# MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [20]

NA

# MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} [23]

NA

# MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[21]

OK

# MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [24]

NA

# MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [25]

OK

# MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [26]

OK

# MUST: All filenames in rpm packages must be valid UTF-8. [27]

OK



So, it looks like it's the license issue, the svn files, documentation, debuginfo and file permissions.  Unless I missed something.

First of all, thanks for reviewing, Jon.
So, here we go:
spec: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/5/gluegen.spec
srpm: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/5/gluegen-1.0.20102502svn-5.fc12.src.rpm
---
[lonely@localhost SPECS]$ rpmlint ../RPMS/noarch/gluegen-*
gluegen-source.noarch: W: no-documentation
-> Im building, now, a package named gluegen-manual. Maybe I should "requires" it also in the source package?
gluegen-source.noarch: E: world-writable /usr/share/gluegen-source/gluegen 0777
gluegen-source.noarch: E: non-standard-dir-perm /usr/share/gluegen-source/gluegen 0777
-> About this two, unfortunately, the directory must be writable because, when building, jogl needs to create some files on if.

[lonely@localhost SPECS]$ rpmlint ../RPMS/i686/gluegen-*
gluegen-debuginfo.i686: E: debuginfo-without-sources
-> Was looking around and found some cases like this: https://bugzilla.redhat.com/show_bug.cgi?id=563001 that suggests that this error can be ignored.

[lonely@localhost SPECS]$ rpmlint ../SRPMS/gluegen-1.0.20102502svn-5.fc12.src.rpm 
gluegen.src: W: invalid-url Source0: gluegen-1.0.20102502svn.tar.gz
-> I think that this can be ignored too, since I'm building my tarball from svn.

(In reply to comment #6)
> [lonely@localhost SPECS]$ rpmlint ../RPMS/noarch/gluegen-*
> gluegen-source.noarch: W: no-documentation
> -> Im building, now, a package named gluegen-manual. Maybe I should "requires"
> it also in the source package?
> gluegen-source.noarch: E: world-writable /usr/share/gluegen-source/gluegen 0777
> gluegen-source.noarch: E: non-standard-dir-perm
> /usr/share/gluegen-source/gluegen 0777
> -> About this two, unfortunately, the directory must be writable because, when
> building, jogl needs to create some files on if.

  http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
  "The /usr/share hierarchy is for all *read-only* architecture independent data files."
  - Writing files under /usr/share when building jogl is not allowed.
  
> 
> [lonely@localhost SPECS]$ rpmlint ../RPMS/i686/gluegen-*
> gluegen-debuginfo.i686: E: debuginfo-without-sources
> -> Was looking around and found some cases like this:
> https://bugzilla.redhat.com/show_bug.cgi?id=563001 that suggests that this
> error can be ignored.

- The review comment on that bug is about debuginfo issue is just wrong.
  Debuginfo rpm must be created correctly (if it is to be created).
  * I guess the reviewer on bug 563001 did not have redhat-rpm-config
    installed. In fact xfce4-remmina-plugin creates debuginfo rpm
    correctly:
    http://koji.fedoraproject.org/koji/buildinfo?buildID=162053

    One problem on this package is that build.log shows just
-----------------------------------------------------------------
   716  c.build:
   717       [echo] Output lib name = gluegen-rt
   718      [mkdir] Created dir: /builddir/build/BUILD/gluegen/build/obj
   719       [echo] Compiling src/native/unix/*.c
   720       [echo] user.dir=/builddir/build/BUILD/gluegen/make
   721         [cc] 1 total files to be compiled.
   722         [cc] cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C
   723         [cc] Starting link
-----------------------------------------------------------------
    and we cannot guess what command line is used here, especially
    what compilation flags are used (and so we cannot check if
    Fedora specific compilation flags are actually used:
    https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags )

    To create debuginfo rpm correctly, at least
    - "-g" option is correctly passed to gcc (or so)
    - and build process must not strip the rebuilt binary by itself
    https://fedoraproject.org/wiki/Packaging:Debuginfo

(In reply to comment #7)
> - The review comment on that bug is about debuginfo issue is just wrong.
  Actually "The review comment on that bug about debuginfo issue is just
  wrong" (one "is" not needed...)

Hi, Mamoru,
Is there any directory I should use with 777 permission. It is mandatory to build jogl correctly. (gluegen is just a dependency).
About this debuginfo problem, any hint? I have no idea.

(In reply to comment #9)
> Hi, Mamoru,
> Is there any directory I should use with 777 permission. It is mandatory to
> build jogl correctly. (gluegen is just a dependency).

- I don't know how to build gluegen, however just copying whole
  tree of /usr/share/gluegen-source to somewhere else (most likely
  under %_builddir/jogl-XXXXX or so) when building jogl is the simplest idea.

> About this debuginfo problem, any hint? I have no idea.    
- (First of all, I am not familiar with java)
  When "ant -verbose" is used (i.e. at %build, use
--------------------------------------------------------------
ant -verbose \
 -Dantlr.jar=$(build-classpath antlr)
--------------------------------------------------------------
  http://koji.fedoraproject.org/koji/taskinfo?taskID=2091598
  build.log shows:
--------------------------------------------------------------
c.build:
     [echo] Output lib name = gluegen-rt
Override ignored for property "c.compiler.debug"
    [mkdir] Created dir: /builddir/build/BUILD/gluegen/build/obj
     [echo] Compiling src/native/unix/*.c
     [echo] user.dir=/builddir/build/BUILD/gluegen/make
       [cc] 1 total files to be compiled.
       [cc] 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
       [cc] Starting link
       [cc] gcc -shared -o libgluegen-rt.so UnixDynamicLinkerImpl_JNI.o
--------------------------------------------------------------
  Here actually Fedora specific compilation flags are ignored, which
  causes improper debuginfo creation.

  Looking at gluegen/make/build.xml:
--------------------------------------------------------------
   333        <echo message="Compiling ${c.compiler.src.files}" />
   334        <echo message="user.dir=${user.dir}" />
   335  
   336        <cc outtype="shared" 
   337            objdir="../build/obj" 
   338            outfile="../build/obj/${output.lib.name}"
   339            optimize="${c.compiler.optimise}" 
   340            debug="${c.compiler.debug}"
   341            multithreaded="true" 
   342            exceptions="false" 
   343            rtti="false">   
--------------------------------------------------------------
  I guess changing "optimize" "debug" option to honor Fedora specific
  compilation flags will make debuginfor rpm being correctly created.

(In reply to comment #10)
> (In reply to comment #9)
> - I don't know how to build gluegen, however just copying whole
>   tree of /usr/share/gluegen-source to somewhere else (most likely
>   under %_builddir/jogl-XXXXX or so) when building jogl is the simplest idea.
Looks like a good idea to me. Thanks, I'll give it a try.

>   I guess changing "optimize" "debug" option to honor Fedora specific
>   compilation flags will make debuginfor rpm being correctly created.    
I'm not sure on what to do here... I'm not used to java, but I'm working on this packages to satisfy some dependencies. If this kind of chages are beyond my skills, is there a problem if a drop this debuginfo package?

(In reply to comment #11)
> >   I guess changing "optimize" "debug" option to honor Fedora specific
> >   compilation flags will make debuginfor rpm being correctly created.    
> I'm not sure on what to do here... I'm not used to java, but I'm working on
> this packages to satisfy some dependencies. If this kind of chages are beyond
> my skills, is there a problem if a drop this debuginfo package?    

- Rather, honoring Fedora specific compilation flags is mandatory
  (as written in
   https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags )
  With Fedora specific compilation flags correctly honored, debuginfo
  rpm should be correctly generated.
  Note that you can check what "Fedora specific compilation flags"
  are by
  $ rpm --eval %optflags

spec: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/6/gluegen.spec
srpm: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/6/gluegen-1.0.20102502svn-6.fc12.src.rpm

I've created this patch to fix this debuginfo issue. Now gluegen-source is not writeable and rpmlint looks happy - just like me =).
---
[lonely@localhost SPECS]$ rpmlint ../RPMS/noarch/gluegen*
gluegen-source.noarch: W: no-documentation
2 packages and 0 specfiles checked; 0 errors, 1 warnings.

[lonely@localhost SPECS]$ rpmlint ../SRPMS/gluegen-1.0.20102502svn-6.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-
[lonely@localhost SPECS]$ rpmlint ../RPMS/i686/gluegen-*
2 packages and 0 specfiles checked; 0 errors, 0 warnings.

Won't build.  chmod ../gluegen-source/make/build.xml.debug-on.patch': No such file or directory

That is weird, Jon, it is building ok here. Could you, please, clean your BUILD directory?

It builds ok in Koji too: https://koji.fedoraproject.org/koji/taskinfo?taskID=2097277

Ok, that helped.  rpmlint is now clean other than the Source warning about the svn checkout, which is fine.

License issue for the stub include is still outstanding, and the license tag is still only BSD.

SVN files are now gone.

gluegen-source still has no documentation.

debuginfo is now OK, AFAICT.

File permissions are fine.



So, it looks like it's just Licensing and documentation now.

P.S.  Thanks Mamoru!!!

Some comments:
1.20102502svn should not add in the %{version}.

2.This package should review along with jogl, the reviewer must check that if this copy of gluegen can work well with jogl. Reviewer should also check that if using gluegen source to build jogl is necessary.

1. You're right, it should be in the release.

Version:	1.0
Release:	0.20102502svn%{?dist}

2. I thought that the built dep had been established.  I'm not sure how to test functionality, can you instruct?

(In reply to comment #19)
> 1. You're right, it should be in the release.
> Version: 1.0
> Release: 0.20102502svn%{?dist}
> 2. I thought that the built dep had been established.  I'm not sure how to test
> functionality, can you instruct?    

I think this packaging gluegen is a bit difficult, jogl can not work with all versions of gluegen(maybe only a special svn revision of gluegen can work well with jogl 1.11a).

See https://bugzilla.redhat.com/show_bug.cgi?id=439627

Packaging jogl is also difficult, maybe we should add some patches to build jogl without building bundled gluegen.

See https://bugzilla.redhat.com/show_bug.cgi?id=439630

(In reply to comment #20)
> I think this packaging gluegen is a bit difficult, jogl can not work with all
> versions of gluegen(maybe only a special svn revision of gluegen can work well
> with jogl 1.11a).
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=439627
> 
> Packaging jogl is also difficult, maybe we should add some patches to build
> jogl without building bundled gluegen.
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=439630

This version of gluegen works with JOGL. After this time I have figured out that is not possible to make JOGL without gluegen (gluegen was created by the same upstream of JOGL just to to make JOGL more "flexible" in the build process). Patch JOGL to build without gluegem may require rewrite great amount of code.

spec: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/7/gluegen.spec
srpm: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/7/gluegen-1-0.20102502svn7.fc12.src.rpm

(I hope I've named it right)

(In reply to comment #21)
> (In reply to comment #20)
> > I think this packaging gluegen is a bit difficult, jogl can not work with all
> > versions of gluegen(maybe only a special svn revision of gluegen can work well
> > with jogl 1.11a).
> > 
> > See https://bugzilla.redhat.com/show_bug.cgi?id=439627
> > 
> > Packaging jogl is also difficult, maybe we should add some patches to build
> > jogl without building bundled gluegen.
> > 
> > See https://bugzilla.redhat.com/show_bug.cgi?id=439630
> This version of gluegen works with JOGL. After this time I have figured out
> that is not possible to make JOGL without gluegen (gluegen was created by the
> same upstream of JOGL just to to make JOGL more "flexible" in the build
> process). 
>Patch JOGL to build without gluegem may require rewrite great amount of code.    

This is a true obstructer for getting jogl and gluegen approved in fedora
and other linux distributions and also the reason why #439627 and #439630 were dropped.

What about it is obstructing?  Jogl wouldn't be bundling gluegen, it would BuildRequire the source.

(In reply to comment #24)
> What about it is obstructing?  Jogl wouldn't be bundling gluegen, it would
> BuildRequire the source.    

In fact, the idea of build jogl using a source package is from the xorg-x11-server folks. They are in a equal dilema and solved it using a source package.

Probably my English sounds a little funny. Please, excuse me for bad grammar, accent, semantics... I would not want to sound rude in any response.

(In reply to comment #24)
> What about it is obstructing?  Jogl wouldn't be bundling gluegen, it would
> BuildRequire the source.    

You are right, it's a good workaround for packaging jogl using gluegen source, but I think that we can hack build.xml to not generate gluegen.jar and gluegen.so when building jogl package.

Now the only thing I'm afraid is that we may have to modify the source of jogl to make it possible to load gluegen.jar in %{_libdir}/gluegen.

(In reply to comment #27)
> (In reply to comment #24)
> > What about it is obstructing?  Jogl wouldn't be bundling gluegen, it would
> > BuildRequire the source.    
> 
> You are right, it's a good workaround for packaging jogl using gluegen source,
> but I think that we can hack build.xml to not generate gluegen.jar and
> gluegen.so when building jogl package.
> 
> Now the only thing I'm afraid is that we may have to modify the source of jogl
> to make it possible to load gluegen.jar in %{_libdir}/gluegen.    

Maybe we can "rm" it and then "ln" it to our gluegen?

(In reply to comment #28)
> Maybe we can "rm" it and then "ln" it to our gluegen?    

Hmmm JOGL is already pointing to the right place. There is no need to changes.

ping ?

Henrique, Chen, am I correct in assuming that #23 is resolved and I can keep on?

Yes, Jon. This issue is solved. We are using the right version of gluegen and JOGL is working fine. Also, we dont have to hack our jogl verion to work with our gluegen because ours and the bundled version are the same.

Ok, the license tag is better, and the doc in -source is better.  What about the licensing for make/stub_includes/unix/dynamic-linker.h?  If we can't resolve that, can gluegen do without it?

It is building ok without this include file.
To be sure I'll build a new release and test JOGL with it.

Without dynamic-linker.h

spec: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/8/gluegen.spec
srpm: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/8/gluegen-1-0.20102502svn8.fc12.src.rpm

Gluegen is building ok, JOGL too. Anyway, I guess it time to ask if Spot can take a look.

CCing Spot, though I think without that header it's probably fine, so long as you specify in the spec that as part of the tarball generation, you removed that file.

I did some googleing and found nothing useful about this file. This comment suggests that it is more related to solaris:
"/* Portions extracted from Solaris dlfcn.h */"
Anyway, the package seems to be fine without it.

Ok, update with the changes described in #36 and we're good.

Ok.
spec: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/9/gluegen.spec
srpm: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/9/gluegen-1-0.20102502svn9.fc12.src.rpm

Awesome.  APPROVED.

I'll finish jogl once gluegen hits rawhide.

oh oh oh. Excellent news! Well done.

Thank you for your kindness and patience, Jon.

New Package CVS Request
=======================
Package Name: gluegen
Short Description: Tool which automatically generates the Java and JNI
code necessary to call C libraries.
Owners: lspooky
Branches: F-11 F-12 F-13
InitialCC: teseu

CVS done (by process-cvs-requests.py).

(In reply to comment #3)
> (In reply to comment #2)
> > Please follow http://fedoraproject.org/wiki/Packaging/Java.
> > JAR files that require JNI shared objects MUST be installed in
> > %{_libdir}/%{name}. The JNI shared objects themselves must also be installed in
> > %{_libdir}/%{name}. 
> > 
> > Also, you maybe need to take a look at
> > https://fedoraproject.org/wiki/Packaging/SourceURL    
> 
> Thank you. I'm fixing it.    

Still not fixed, they should be installed into %{_libdir}/%{name}.

Sorry, I'll fix it ASAP. I have to fix a problem building for PPC too, but I'm really busy now.

(In reply to comment #45)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Please follow http://fedoraproject.org/wiki/Packaging/Java.
> > > JAR files that require JNI shared objects MUST be installed in
> > > %{_libdir}/%{name}. The JNI shared objects themselves must also be installed in
> > > %{_libdir}/%{name}. 
> > > 
> > > Also, you maybe need to take a look at
> > > https://fedoraproject.org/wiki/Packaging/SourceURL    
> > 
> > Thank you. I'm fixing it.    
> 
> Still not fixed, they should be installed into %{_libdir}/%{name}.    

All fixed now. Building OK in PPC too.
http://koji.fedoraproject.org/koji/taskinfo?taskID=2152451

The JNI shared objects themselves must also be installed in %{_libdir}/%{name}. 

/usr/lib64/java/libgluegen-rt.so->/usr/lib64/gluegen/libgluegen-rt.so

See http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI

(In reply to comment #47)
> (In reply to comment #45)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > Please follow http://fedoraproject.org/wiki/Packaging/Java.
> > > > JAR files that require JNI shared objects MUST be installed in
> > > > %{_libdir}/%{name}. The JNI shared objects themselves must also be installed in
> > > > %{_libdir}/%{name}. 
> > > > 
> > > > Also, you maybe need to take a look at
> > > > https://fedoraproject.org/wiki/Packaging/SourceURL    
> > > 
> > > Thank you. I'm fixing it.    
> > 
> > Still not fixed, they should be installed into %{_libdir}/%{name}.    
> 
> All fixed now. Building OK in PPC too.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2152451    

I have a good news for you, a talented sponsor seems interested in packaging scilab recently, maybe you can help him to finish packaging scilab 5.22.

https://bugzilla.redhat.com/show_bug.cgi?id=587198

(In reply to comment #48)
> The JNI shared objects themselves must also be installed in %{_libdir}/%{name}. 
> 
> /usr/lib64/java/libgluegen-rt.so->/usr/lib64/gluegen/libgluegen-rt.so
> 
> See
> http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI    

Ops! Sorry, I was in a hurry. It is easy to fix. I was really worried with this problem in PPC builds, but it is OK now. Thanks for your help, Chen.

Done: http://koji.fedoraproject.org/koji/taskinfo?taskID=2152609
Maybe a couple of weeks in testing is enough?

Gluegen is, now, in updates-testing for f11, f12, f13 and rawhide. =)

(In reply to comment #51)
> Done: http://koji.fedoraproject.org/koji/taskinfo?taskID=2152609
> Maybe a couple of weeks in testing is enough?    

Let gluegen stay in testing until the whole scilab sets build successful on devel.

(In reply to comment #53)
> Let gluegen stay in testing until the whole scilab sets build successful on
> devel.

Sounds good to me, Chen.

That will prevent me from using gluegen in test mock builds while reviewing jogl.  I can't see any harming in pushing it to stable after a few days.

If the reasoning is wanting to test the whole scilab stack before this goes out, another solution would be to request rel-eng for tagging it into an override tag, so that it can be used in other builds (whether it is build of scilab into fedora, or Jon's scratch builds).

Well, gluegen is a new package, so, it breaks nothing in Fedora if it goes to stable after a while. Packaging was a little difficult, but the package itself is pretty simple and I don't see any evident risks.
Since packaging gluegen/jogl is only a way to have scilab working (and there is no other package depending on it) I'm ok doing what is easyer/faster to help Jon's review in JOGL.

1.
Version:        1
Release:        0.20102502svn11%{?dist}
 
->
Version:        1.0
 
Release:        0.11.20100225svn

to match naming guideline.
 
See http://fedoraproject.org/wiki/PackageNamingGuidelines#Pre-Release_packages

2. No evidence shows that scilab will be available for F11 and F12, pushing jogl/gluegen to F11/F12 seems useless. 
Packaging scilab is a big project, maybe we can add Scilab 5.2.x as a new feature for F14. Normally a new feature won't be backported to old releases.
Maybe you can push those packages to F13.

3.
For mock/koji, one can easily do a devel/rawhide mock build on a F12 or EL-5 box. As I known http://koji.fedoraproject.org/koji/ is based on EL-5.

3. I do my rawhide mock test builds on an F-12 box.  Gluegen's presence in F-14 is enough for me.

3. I do my rawhide mock test builds on an F-12 box.  Gluegen's presence in F-14 is enough for me.

I'll be changing it today and a package with correct naming will be available
soon.
> 2. No evidence shows that scilab will be available for F11 and F12, pushing
> jogl/gluegen to F11/F12 seems useless. 
> Packaging scilab is a big project, maybe we can add Scilab 5.2.x as a new
> feature for F14. Normally a new feature won't be backported to old releases.
> Maybe you can push those packages to F13.
It makes sense, but I really think that if we get scilab ready in the middle of
F13 we don't need to wait F14, unless we want to deliberately keep this
software to add value to F14.

> 2. No evidence shows that scilab will be available for F11 and F12, pushing
> jogl/gluegen to F11/F12 seems useless. 
> Packaging scilab is a big project, maybe we can add Scilab 5.2.x as a new
> feature for F14. Normally a new feature won't be backported to old releases.
> Maybe you can push those packages to F13.
Scilab is easier than Gluegen to package. It has a standard build/installation process. Many patches are available for Debian and Gentoo.
Upstream (ie: me) will be happy to help in the packaging of Scilab in fedora.

(In reply to comment #60)
> 3. I do my rawhide mock test builds on an F-12 box.  Gluegen's presence in F-14
> is enough for me.    

Maybe koji scratch build will be more faster than local mock build.

Jon, it seems that Henrique didn't patch glueten to load jni file in %{_libdir}/%{name}, can gluegen really works in this package.

See https://fedoraproject.org/wiki/Packaging:Java#Rationale

I'm not familiar with both java and ant, so I cannot sure about this. Howerver a java package probably can not work correctly by simply move .jar and .so files to %{_libdir}/%{name}. 

Thank you!

Well, I guess we really need someone used to java. I did some googleing but the tests I've found sounds like greek to me.

I've just invited James Heather (that seems to have some knowledge about this matter) to join us.

OK, well, here I am...

I am familiar with Java, and with JOGL. I use JOGL for my teaching, on F11 and F12. If you'd like to point me to 64-bit F11 and F12 builds of JOGL and Gluegen, I'll gladly try them out. (I haven't tried F13 yet, let alone F14!)

That said, please be aware that I have no experience of packaging things for Fedora. I have put a few basic RPMs together in my time, but they've all been built from precompiled binaries or interpreted code, so they've been utterly trivial. They've been purely for my own consumption, so I haven't made any effort to get them to meet Fedora standards.

Glad to hear there's movement on this!

James

Some fix needed for gluegen:

1. version and release issue
2. Jni load patch
3. optflags issue
export PATH=%{_builddir}/%{name}:$PATH
cat << EOF > gcc 
#!/bin/sh 
%{_bindir}/gcc %{optflags} "\$@" 
EOF 
chmod +x gcc
I think debug-on.patch is not needed, since it pass -g argument to gcc
4. missing symbolic from *-x.y.z.jar to*.jar

pushd ${RPM_BUILD_ROOT}%{_javadir}
	for jar in *-%{version}*; do
		ln -sf ${jar} `echo $jar| sed "s|-%{version}||g"`
	done
popd

(In reply to comment #66)
> OK, well, here I am...
> 
> I am familiar with Java, and with JOGL. I use JOGL for my teaching, on F11 and
> F12. If you'd like to point me to 64-bit F11 and F12 builds of JOGL and
> Gluegen, I'll gladly try them out. (I haven't tried F13 yet, let alone F14!)
> 
> That said, please be aware that I have no experience of packaging things for
> Fedora. I have put a few basic RPMs together in my time, but they've all been
> built from precompiled binaries or interpreted code, so they've been utterly
> trivial. They've been purely for my own consumption, so I haven't made any
> effort to get them to meet Fedora standards.
> 
> Glad to hear there's movement on this!
> 
> James    

You can install this by activating the updates-testing repo:
yum --enablerepo=updates-testin install gluegen
We need someone with experience in java to test if everything is working. My experience with java is almost zero. =)

(In reply to comment #67)
> Some fix needed for gluegen:
> 
> 1. version and release issue
Yes, I have to fix this
> 2. Jni load patch
> 3. optflags issue
> export PATH=%{_builddir}/%{name}:$PATH
> cat << EOF > gcc 
> #!/bin/sh 
> %{_bindir}/gcc %{optflags} "\$@" 
> EOF 
> chmod +x gcc
> I think debug-on.patch is not needed, since it pass -g argument to gcc
I've tried passing -g to gcc and it didn't work
> 4. missing symbolic from *-x.y.z.jar to*.jar
> 
> pushd ${RPM_BUILD_ROOT}%{_javadir}
>  for jar in *-%{version}*; do
>   ln -sf ${jar} `echo $jar| sed "s|-%{version}||g"`
>  done
> popd    
Chen, I'm in a hurry this days due to some exams in my University, so, could you apply this changes to the spec? I still have to do some reading and learn how to apply all fixes.

> You can install this by activating the updates-testing repo:
> yum --enablerepo=updates-testin install gluegen
> We need someone with experience in java to test if everything is working. My
> experience with java is almost zero. =)    

How about jogl itself? (I wouldn't know what to do with gluegen without jogl.)

James

Indeed. Building JOGL against gluegen is the best test we could do.

It seems this review is done.

Could you please use a mailing list or IRC for discussion and bugzilla for
resolving bugs?

Thanks.

Build in rawhide:
http://koji.fedoraproject.org/koji/buildinfo?buildID=170290

Shipping some testing updates:
https://admin.fedoraproject.org/updates/gluegen-1-0.20102502svn11.fc13
https://admin.fedoraproject.org/updates/gluegen-1-0.20102502svn11.fc12
https://admin.fedoraproject.org/updates/gluegen-1-0.20102502svn11.fc11

-> Closed Rawhide, if not 'soon' a update is pushed stable