Bug 572512 - Review Request: gluegen - Java/JNI glue code generator to call out to ANSI C
Review Request: gluegen - Java/JNI glue code generator to call out to ANSI C
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jon Ciesla
Fedora Extras Quality Assurance
:
: 439627 (view as bug list)
Depends On: 167525
Blocks: RussianFedoraRemix 439630 572515
  Show dependency treegraph
 
Reported: 2010-03-11 07:26 EST by Henrique "LonelySpooky" Junior
Modified: 2010-05-05 07:22 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-05 07:22:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
limburgher: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Henrique "LonelySpooky" Junior 2010-03-11 07:26:00 EST
Spec URL: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/3/gluegen.spec
SRPM URL: http://lspooky.fedorapeople.org/gluegen/1.0.20102502svn/3/gluegen-1.0.20102502svn-3.fc12.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.

I'm (re)opening this review, but this package has, already, a lot of history; please, take a look at https://bugzilla.redhat.com/show_bug.cgi?id=439627 for details.
Comment 1 Henrique "LonelySpooky" Junior 2010-03-11 07:26:46 EST
*** Bug 439627 has been marked as a duplicate of this bug. ***
Comment 2 Chen Lei 2010-03-18 22:28:12 EDT
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
Comment 3 Henrique "LonelySpooky" Junior 2010-03-18 23:27:04 EDT
(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.
Comment 4 Henrique "LonelySpooky" Junior 2010-03-19 00:12:19 EDT
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.
Comment 5 Jon Ciesla 2010-03-30 10:02:25 EDT
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.
Comment 6 Henrique "LonelySpooky" Junior 2010-04-02 10:56:16 EDT
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.
Comment 7 Mamoru TASAKA 2010-04-02 11:53:14 EDT
(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
Comment 8 Mamoru TASAKA 2010-04-02 11:57:47 EDT
(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...)
Comment 9 Henrique "LonelySpooky" Junior 2010-04-02 12:12:59 EDT
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.
Comment 10 Mamoru TASAKA 2010-04-02 12:53:28 EDT
(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.
Comment 11 Henrique "LonelySpooky" Junior 2010-04-02 13:08:31 EDT
(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?
Comment 12 Mamoru TASAKA 2010-04-02 13:37:30 EDT
(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
Comment 13 Henrique "LonelySpooky" Junior 2010-04-02 15:20:40 EDT
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.
Comment 14 Jon Ciesla 2010-04-06 10:05:59 EDT
Won't build.  chmod ../gluegen-source/make/build.xml.debug-on.patch': No such file or directory
Comment 15 Henrique "LonelySpooky" Junior 2010-04-06 10:24:10 EDT
That is weird, Jon, it is building ok here. Could you, please, clean your BUILD directory?
Comment 16 Henrique "LonelySpooky" Junior 2010-04-06 10:51:34 EDT
It builds ok in Koji too: https://koji.fedoraproject.org/koji/taskinfo?taskID=2097277
Comment 17 Jon Ciesla 2010-04-06 11:18:34 EDT
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!!!
Comment 18 Chen Lei 2010-04-06 11:33:01 EDT
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.
Comment 19 Jon Ciesla 2010-04-06 11:38:15 EDT
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?
Comment 20 Chen Lei 2010-04-06 11:50:28 EDT
(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
Comment 21 Henrique "LonelySpooky" Junior 2010-04-06 12:09:50 EDT
(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.
Comment 23 Chen Lei 2010-04-06 12:23:14 EDT
(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.
Comment 24 Jon Ciesla 2010-04-06 12:32:40 EDT
What about it is obstructing?  Jogl wouldn't be bundling gluegen, it would BuildRequire the source.
Comment 25 Henrique "LonelySpooky" Junior 2010-04-06 12:39:19 EDT
(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.
Comment 26 Henrique "LonelySpooky" Junior 2010-04-06 12:46:08 EDT
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.
Comment 27 Chen Lei 2010-04-06 12:54:41 EDT
(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.
Comment 28 Henrique "LonelySpooky" Junior 2010-04-06 13:12:59 EDT
(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?
Comment 29 Henrique "LonelySpooky" Junior 2010-04-06 13:37:26 EDT
(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.
Comment 30 Sylvestre Ledru 2010-04-18 12:53:03 EDT
ping ?
Comment 31 Jon Ciesla 2010-04-23 15:28:47 EDT
Henrique, Chen, am I correct in assuming that #23 is resolved and I can keep on?
Comment 32 Henrique "LonelySpooky" Junior 2010-04-23 15:48:00 EDT
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.
Comment 33 Jon Ciesla 2010-04-23 15:58:06 EDT
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?
Comment 34 Henrique "LonelySpooky" Junior 2010-04-23 17:00:27 EDT
It is building ok without this include file.
To be sure I'll build a new release and test JOGL with it.
Comment 35 Henrique "LonelySpooky" Junior 2010-04-23 17:28:52 EDT
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.
Comment 36 Jon Ciesla 2010-04-26 14:47:47 EDT
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.
Comment 37 Henrique "LonelySpooky" Junior 2010-04-26 15:21:19 EDT
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.
Comment 38 Jon Ciesla 2010-04-26 15:56:36 EDT
Ok, update with the changes described in #36 and we're good.
Comment 40 Jon Ciesla 2010-04-26 17:19:53 EDT
Awesome.  APPROVED.

I'll finish jogl once gluegen hits rawhide.
Comment 41 Sylvestre Ledru 2010-04-26 17:26:25 EDT
oh oh oh. Excellent news! Well done.
Comment 42 Henrique "LonelySpooky" Junior 2010-04-26 23:06:08 EDT
Thank you for your kindness and patience, Jon.
Comment 43 Henrique "LonelySpooky" Junior 2010-04-26 23:13:39 EDT
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
Comment 44 Jason Tibbitts 2010-04-28 22:09:24 EDT
CVS done (by process-cvs-requests.py).
Comment 45 Chen Lei 2010-04-28 23:21:02 EDT
(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}.
Comment 46 Henrique "LonelySpooky" Junior 2010-04-29 09:36:34 EDT
Sorry, I'll fix it ASAP. I have to fix a problem building for PPC too, but I'm really busy now.
Comment 47 Henrique "LonelySpooky" Junior 2010-04-30 23:16:56 EDT
(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
Comment 48 Chen Lei 2010-04-30 23:22:21 EDT
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
Comment 49 Chen Lei 2010-04-30 23:29:22 EDT
(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
Comment 50 Henrique "LonelySpooky" Junior 2010-04-30 23:36:02 EDT
(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.
Comment 51 Henrique "LonelySpooky" Junior 2010-05-01 00:14:54 EDT
Done: http://koji.fedoraproject.org/koji/taskinfo?taskID=2152609
Maybe a couple of weeks in testing is enough?
Comment 52 Henrique "LonelySpooky" Junior 2010-05-03 14:14:39 EDT
Gluegen is, now, in updates-testing for f11, f12, f13 and rawhide. =)
Comment 53 Chen Lei 2010-05-04 07:37:42 EDT
(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.
Comment 54 Henrique "LonelySpooky" Junior 2010-05-04 10:01:00 EDT
(In reply to comment #53)
> Let gluegen stay in testing until the whole scilab sets build successful on
> devel.

Sounds good to me, Chen.
Comment 55 Jon Ciesla 2010-05-04 12:27:32 EDT
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.
Comment 56 Lubomir Rintel 2010-05-04 12:56:00 EDT
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).
Comment 57 Henrique "LonelySpooky" Junior 2010-05-04 13:25:22 EDT
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.
Comment 58 Chen Lei 2010-05-04 13:43:42 EDT
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.
Comment 59 Jon Ciesla 2010-05-04 14:32:51 EDT
3. I do my rawhide mock test builds on an F-12 box.  Gluegen's presence in F-14 is enough for me.
Comment 60 Jon Ciesla 2010-05-04 14:35:45 EDT
3. I do my rawhide mock test builds on an F-12 box.  Gluegen's presence in F-14 is enough for me.
Comment 61 Henrique "LonelySpooky" Junior 2010-05-04 14:39:56 EDT
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.
Comment 62 Sylvestre Ledru 2010-05-04 14:49:17 EDT
> 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.
Comment 63 Chen Lei 2010-05-04 22:13:26 EDT
(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!
Comment 64 Henrique "LonelySpooky" Junior 2010-05-04 23:21:16 EDT
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.
Comment 65 Henrique "LonelySpooky" Junior 2010-05-04 23:32:54 EDT
I've just invited James Heather (that seems to have some knowledge about this matter) to join us.
Comment 66 James Heather 2010-05-05 03:52:43 EDT
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
Comment 67 Chen Lei 2010-05-05 05:37:44 EDT
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
Comment 68 Henrique "LonelySpooky" Junior 2010-05-05 06:56:09 EDT
(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. =)
Comment 69 Henrique "LonelySpooky" Junior 2010-05-05 07:02:20 EDT
(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.
Comment 70 James Heather 2010-05-05 07:04:03 EDT
> 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
Comment 71 Sylvestre Ledru 2010-05-05 07:19:02 EDT
Indeed. Building JOGL against gluegen is the best test we could do.
Comment 72 Thomas Spura 2010-05-05 07:22:06 EDT
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

Note You need to log in before you can comment on or make changes to this bug.