Spec URL: http://lspooky.fedorapeople.org/jogl/1.1.1/4/jogl.spec SRPM URL: http://lspooky.fedorapeople.org/jogl/1.1.1/4/jogl-1.1.1-4.fc12.src.rpm Description: The JOGL project hosts the development version of the Java Binding for the OpenGL API (JSR-231), and is designed to provide hardware-supported 3D graphics to applications written in Java. JOGL provides full access to the APIs in the OpenGL 2.0 specification as well as nearly all vendor extensions, and integrates with the AWT and Swing widget sets. It is part of a suite of open-source technologies initiated by the Game Technology Group at Sun Microsystems. This package depends on the review of gluegen (bug 572512). ----------------------------------------------------------- I'm (re)opening this review, but this package has, already, a lot of history; please, take a look at bug 439630 for details.
*** Bug 439630 has been marked as a duplicate of this bug. ***
Henrique, should not we add a team as C/C of this bug for a review ?
I've already posted requests at devel and packaging lists.
Taking. First off, I have to manually rm -rf ~/rpmbuild/BUILD/gluegen*, or jogl won't build, prompting on unzip. Mildly annoying, fix if you can, probably in gluegen. Not critical. # MUST: rpmlint must be run on every package. The output should be posted in the review.[1] limb@paguroidea SPECS]$ rpmlint -i ../SRPMS/jogl-1.1.1-4.fc12.src.rpm jogl.src: W: invalid-url URL: http://jogl.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. jogl.src: W: no-buildroot-tag The BuildRoot tag isn't used in your spec. It must be used in order to allow building the package as non root on some systems. For some rpm versions (e.g. rpm.org >= 4.6) the BuildRoot tag is not necessary in specfiles and is ignored by rpmbuild; if your package is only going to be built with such rpm versions you can ignore this warning. OK, if you're not doing older branches. jogl.src: W: invalid-url Source0: http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1a/jogl-1.1.1a-src.zip <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. 1 packages and 0 specfiles checked; 0 errors, 3 warnings. [limb@paguroidea SPECS]$ rpmlint -i ../RPMS/*/jogl* jogl.i686: W: invalid-url URL: http://jogl.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. jogl.i686: W: no-documentation The package contains no documentation (README, doc, etc). You have to include documentation files. FIX jogl-debuginfo.i686: W: invalid-url URL: http://jogl.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. jogl-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, see gluegen comment. jogl-javadoc.i686: W: invalid-url URL: http://jogl.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. jogl-manual.i686: W: invalid-url URL: http://jogl.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. 4 packages and 0 specfiles checked; 1 errors, 5 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 . TODO. # MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . BSD: OK NVIDIA Personal non-exclusive license??!?!? make/stub_includes/cg/CG/* Are these bit redistributable? SGI Free Software B License: OK # MUST: The License field in the package spec file must match the actual license. [3] See above. Should be BSD and MIT at this point. # 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] FIX. # 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. # 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. TODO, mock build once gluegen is in rawhide. # 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 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] OK. # 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] FIX, does not appear to own %{_libdir}/%{name}. Also, should this package possibly Require javadoc? # 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] OK. # 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] I'm actaully not sure that -manual should be a separate subpackage. It's 26k. I mean, -javadoc, OK, it's 1.1MB, but not -manual. You can, but if it were me, I wouldn't. # 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] NA. # 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, I can't finish this until gluegen is in rawhide, but you can start with this.
spec: http://lspooky.fedorapeople.org/jogl/1.1.1/5/jogl.spec srpm: http://lspooky.fedorapeople.org/jogl/1.1.1/5/jogl-1.1.1-5.fc12.src.rpm Here we go. Now JOGL is "cp"ing gluegen-source instead of building directly from %{datadir}. rpmlint is clean complaining only about this no-buildroot-tag thing that we can ignore. ----- [lonely@localhost SPECS]$ rpmlint -i ../RPMS/i686/jogl-* 4 packages and 0 specfiles checked; 0 errors, 0 warnings. [lonely@localhost SPECS]$ rpmlint -i ../SRPMS/jogl-1.1.1-5.fc12.src.rpm jogl.src: W: no-buildroot-tag 1 packages and 0 specfiles checked; 0 errors, 1 warnings.
Sorry, I have forgotten about the %post and %postun sections. spec: http://lspooky.fedorapeople.org/jogl/1.1.1/6/jogl.spec srpm: http://lspooky.fedorapeople.org/jogl/1.1.1/6/jogl-1.1.1-6.fc12.src.rpm
Ping ?
Still waiting on gluegen. . .
Gluegen is now in rawhide. I'll look at the rest after a rawhide mock build succeeds, which it currently does not. Attaching build.log.
Created attachment 411408 [details] Mock build log, 5/4/10
Can this be a temporary error in rawhide?
1.Jni files don't need %post -p /sbin/ldconfig and %postun -p /sbin/ldconfig 2.Version should be 1.1.1a instead of 1.1.1 3.%defattr(644,root,root,755) should always be %defattr(-,root,root,-) 4.I cannot see anything related to %{?_with_Cg:BuildRequires: Cg} 5.%package manual Group: Development/Libraries ->%package manual Group: Documentation 6.http://cvs.fedoraproject.org/viewvc/devel/jogl/jogl.spec?hideattic=0&view=markup is a good example for you except some obsolete items.
Henrique can no longer contribute to Fedora, so he's orphaned gluegen and will need someone to take over this review. If no one does in the next few weeks, I'll close this.
I'm very interested in this package as I teach this stuff. However, I'm not an approved packager. I'll happily take over if someone was to sponsor me joining the Packager group on FAS (username balor).
I can do that. I like to see 3 or 4 practice package reviews first. If you post links here, I can have a look, and if things look good, I'll sponsor you and we can move this along.
Removing spurious FE-DEADREVIEW blocker bug, I assume that this review hasn't stalled as per: https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
Aidan, ping?
A spec file that addresses Chen Lei's points from comment #12 is available at http://culturalinformatics.org.uk/~ajd9/jogl.spec rpmlint shows only the expected warning for no-build-root I think I need to fix some stuff in gluegen as it installs the jars to /usr/lib/gluegen, when I'd expect them in /usr/share/java/
(In reply to comment #18) > A spec file that addresses Chen Lei's points from comment #12 is available at > http://culturalinformatics.org.uk/~ajd9/jogl.spec > rpmlint shows only the expected warning for no-build-root > I think I need to fix some stuff in gluegen as it installs the jars to > /usr/lib/gluegen, when I'd expect them in /usr/share/java/ %{_libdir}/%{name} is the right place for JAR files that use JNI. See http://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI
Chen is correct, you'll need to patch jogl to use the jars where gluegen has them.
Here is the debian patch to do so: http://svn.debian.org/viewsvn/pkg-java/trunk/libjogl-java/debian/patches/defaultDebianPath.diff?revision=8664&view=markup
I've taken that Debian patch and made it Fedora specific. It's all in http://culturalinformatics.org.uk/~ajd9/jogl-1.1.1a-2.fc15.src.rpm. However, the this doesn't work well. On Debian jni libraries are installed to /usr/lib/jni and this is added to LD_LIBRARY_PATH. On Fedora we install jni related libs to /usr/lib/gluegen/libgluegen.so (in this case). So we need to add the java.library.path modifications earlier than the Debian peeps. Therefore, I put it in a static initialiser block. However, where I've added it is too late. So question. Do I find an early entry point into jogl in which to modify java.library.path or do we require users to specify -Djava.library.path=... as a parameter to java? I'm happy with the latter as identifying an early entry point into jogl assumes too much about how users are going to consume it.
@aiden: I don't see the problem ? To me, java.library.path must be set in the Java code. It is jogl business.
I am working on this. There are two issues, one is patching NativeLibraryLoader in JoGL (done) the other is patching the same file in gluegen. I've now got an x86_64 box, so I should have a fix soon.
Where are we on this?
JoGL, as far as I know, works. The java.library.path issue is solved in JoGL. There is an issue in Gluegen with respect to java.library.path. I'll fix this over the next week. Though, as gluegen is already in F14, I should probably open another bug for it. Consider me bumped....I'll get it done.
Excellent. Thanks!
This is messing with my head. The jogl package works if used as the following. [aidan@SillyFace source]$ export CLASSPATH=/usr/lib64/jogl/jogl.jar:/usr/lib64/gluegen/gluegen-1.jar:. [aidan@SillyFace source]$ java -cp $CLASSPATH -Djava.library.path=/usr/lib64/gluegen/:/usr/lib64/jogl/ SimpleJOGL Which is how you might expect to use it. I'm still arguing with NativeLibLoader.java in gluegen and in jogl. This'll remove the need for passing the -Djava.library.path. However, I think it's usable without the modification to NativeLibLoader.java in gluegen.
Great. Does this mean it is ready for an upload in Fedora ?
@Sylvestre #29 I'm happy to commit to maintaining it and improving it over time. I've been looking at JoGL 2.0 development and as soon as you guys need it, I'm happy to package and push it. One of the courses I teach uses JoGL, so I have a long-term need to support it anyway. However, I don't have the authority to upload it to Fedora at the moment.
Aidan: AFAIK, JoGL 2.0 is not compatible with the version 1... :/ This will require massive changes from upstream. I think both 2.0 alpha/beta and 1.X should be available at the same time.
Yeah. Just a massive forward pointer to what's down the line. JoGL 1.X will be around for ages.
Hey, to anyone who knows Java more than I do: gluegen is now FTBFS in rawhide. I fixed a packaging issue which then revealed a Java/antlr issue: http://koji.fedoraproject.org/koji/getfile?taskID=2647172&name=build.log
"Reference antlr.classpath not found." That means that antlr cannot be found from ant. I guess the dependency is explicit, it is probably that the ant declaration of usage of antlr is wrong.
This is interesting. There's already an orphaned jogl. https://admin.fedoraproject.org/pkgdb/acls/name/jogl?_csrf_token=3c4d0fa7f43d2fd5da17647f10b89c4ebf55282d
Jon, thanks for that. However, as the orphan is over 3 months old we need to revalidate the package review. Furthermore, the package was removed for legal reasons. There seems to be a legal issue with jogl. The SGI Free B 1.1 licence can be "upgraded" to the MIT-like SGI Free B 2.0 licence. However, we're unsure if the Sun derivative of the SGH Free B 1.1 licence can be "upgraded" to the open-source Free B 2.0. This is going to fedora-legal for legal eagles to argue over.
Cool, blocking FE-LEGAL.
And spot says this is OK: http://lists.fedoraproject.org/pipermail/legal/2010-December/001476.html ----- The removed sections are the patent grant and the indemnity sections. Section 8 is still intact, and the relicensing permission is reasonably clear that anything not waived in the relicensing is still applicable from SGI, so IMHO, it is safe to migrate this code to FreeB 2.0 (MIT). I would strongly encourage jogl's upstream to make this change so that this horrible horrible license can die. ~tom ----- So feel free to move forward. Unblocking FE-Legal.
I should add that adding at least that mailing list link in a comment near the License: tag (along with the regular explanation of what's what in case your license tag ends up being complicated) would be appreciated in case someone comes across this weirdness in the future.
Do we know if upstream is aware of the license issue ?
Ping
Created attachment 479996 [details] Updated licence I've updated the licence to the SGI Free B 2.0. I still have to test this with a scilab build.
Created attachment 479999 [details] Updated name The same spec with a mistake in my family name.
How can we(Java SIG) help with getting this review finished?
Alexander, IMHO, the best way would be for you to assign to yourself this bug ;)
Also, check out the gluegen FTBFS.
The bug is assigned to Jon Ciesla so I consider it a bit rude to take the bug while he is still responding on this bug. Jon, what are the current issues with this package? P.S. I'll take a look at gluegen FTBFS now.
jon, do you have the log of the FTBFS of gluegen ?
Alexander: By all means, take it, and you can have ownership of gluegen if you like. My Java-fu is weak. I think the only issue with this was licensing, but you should re-review completely anyway, given the time it's been open. Sylvestre: https://bugzilla.redhat.com/show_bug.cgi?id=660850
Gluegen fixed. It looks like the jogl maintainer should take gluegen if you don't want it anymore. I'm interested in only helping with reviews :)
Thanks! That would be the submitter of this bug, see comment #13.
Sylvestre, please open a new review request with the latest srpm and spec file so I can be sure that I'm reviewing the latest one and close this one as duplicate. I don't feel good reviewing bug open by one and touched by few others.
Excellent. Thanks! I was only involved with these packages because I reviewed them and offered to watch them for Henrique until someone more interested could take over.
Well, it is the same for me. I am here as Scilab upstream developer who is helping on getting JOGL and all Scilab's reverses dependencies. I am also packager of Scilab under Debian and most of its dependencies. It is why I am helping here. I am however not a Fedora/Redhat user nor contributor... Sorry By the way, JOGL and Gluegen are not time consuming packages to maintain. They are pretty stable. I packaged recently the version 2.0 rcX into Debian without too much issues. (and I can provide help in the future)
Ok, thanks! Given that, Alexander, shall I post a new request, or just post new links?
(In reply to comment #55) > Ok, thanks! Given that, Alexander, shall I post a new request, or just post > new links? Given that you're the one that this bug is assigned to it would be pretty strange to suddenly become the submitter. Please open a new review request.
See https://bugzilla.redhat.com/show_bug.cgi?id=690282
*** This bug has been marked as a duplicate of bug 690282 ***
It looks like, there is a OpenGL2 related bug in Fedoras 30/31 (x86_64) jogl: $ wget http://wdune.ourproject.org/examples/Triangle.java ... $ javac -cp /usr/lib/java/gluegen2-rt.jar:/usr/lib/java/jogl2.jar Triangle.java $ java -Djava.library.path=/usr/lib64/jogl2/ -cp .:/usr/lib/java/gluegen2-rt.jar:/usr/lib/java/jogl2.jar TriangleException in thread "main" com.jogamp.opengl.GLException: Profile GL2 is not available on null, but: [GLProfile[GLES1/GLES1.hw], GLProfile[GLES2/GLES3.hw], GLProfile[GL2ES1/GLES1.hw], GLProfile[GL4ES3/GL4.hw], GLProfile[GL2ES2/GL4.hw], GLProfile[GL4/GL4.hw], GLProfile[GLES3/GLES3.hw], GLProfile[GL4/GL4.hw], GLProfile[GL3/GL4.hw], GLProfile[GL2GL3/GL4.hw]] at com.jogamp.opengl.GLProfile.get(GLProfile.java:991) at com.jogamp.opengl.GLProfile.get(GLProfile.java:1004) at Triangle.main(Triangle.java:55) The same runs without problems under Ubuntu 18.04 (x86_64)