Bug 439630 - Review Request: jogl - Java bindings for OpenGL
Review Request: jogl - Java bindings for OpenGL
Status: CLOSED DUPLICATE of bug 690282
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On: 439627 572512
Blocks: FE-DEADREVIEW RussianFedoraRemix 472639
  Show dependency treegraph
 
Reported: 2008-03-29 16:33 EDT by Colin Walters
Modified: 2011-05-23 13:48 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-13 18:47:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tcallawa: fedora‑review-


Attachments (Terms of Use)
Fix dirs for install target (857 bytes, patch)
2008-11-21 23:22 EST, D Haley
no flags Details | Diff
With jogl/gluegen 2.0, a first patch to remove some hardcoded path to gluegen path (7.17 KB, patch)
2009-12-08 17:59 EST, Sylvestre Ledru
no flags Details | Diff
gentoo' patch (1.49 KB, text/plain)
2010-02-28 21:19 EST, Chen Lei
no flags Details
patch to correctly point build.xml (3.26 KB, patch)
2010-03-09 11:23 EST, Henrique "LonelySpooky" Junior
no flags Details | Diff

  None (edit)
Description Colin Walters 2008-03-29 16:33:06 EDT
Spec URL: http://cdn.verbum.org/jogl.spec
SRPM URL: http://cdn.verbum.org/jogl-1.1.0-1.fc9.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 439627).
Comment 1 Ville Skyttä 2008-03-29 17:21:15 EDT
jogl was in Fedora, but was dropped:
http://cvs.fedoraproject.org/viewcvs/devel/jogl/dead.package?rev=1.1&view=auto

Is this still a problem with 1.1.0?

If not, you may want to verify that your package upgrades the old Fedora one
cleanly; in particular, the old one had Epoch set to 1 so this package should
inherit it.
Comment 2 Colin Walters 2008-03-31 09:53:33 EDT
Ohhh, crap =/  Thanks for taking a look, I'll ping upstream, maybe they have
some plans on this.  We really need a search on the packagedb...


Comment 3 Colin Walters 2008-03-31 10:21:50 EDT
Anthony, can you elaborate a bit on the status of this?  Is/was there any
attempt to get upstream to relicense?  I think JOGL development has been done
under the SCA, so Sun should own copyright and be able to relicense.

We had the same problem with Mesa I believe - how was that resolved?

This library blocks the inclusion into Fedora of a lot of interesting software.
Comment 4 Colin Walters 2008-04-02 20:39:44 EDT
Tom, I'm wondering if you know anything about this.  

I just noticed too the LICENSE.txt in the jogl source has this note:

   NOTE:  The Original Code (as defined below) has been licensed to Sun 
   Microsystems, Inc. ("Sun") under the SGI Free Software License B 
   (Version 1.1), shown above ("SGI License").   Pursuant to Section  
   3.2(3) of the SGI License, Sun is distributing the Covered Code to 
   you under an alternative license ("Alternative License").  This 
   Alternative License includes all of the provisions of the SGI License 
   except that Section 2.2 and 11 are omitted.  Any differences between 
   the Alternative License and the SGI License are offered solely by Sun 
   and not by SGI.

Were the 2.2 and 11 the problematic sections?  From looking at the FSF's web
site on this, 2.2 and 11 look like the objectionable parts.
Comment 5 Tom "spot" Callaway 2008-04-03 09:37:48 EDT
No, the whole darned license is problematic. Nothing under anything FreeB
derived is ok for Fedora.
Comment 6 Peter Lemenkov 2008-04-06 12:36:06 EDT
So we must push in to Livna/RPMFusion
Comment 7 Nicolas Chauvet (kwizart) 2008-04-14 21:33:27 EDT
(In reply to comment #3)
>
> This library blocks the inclusion into Fedora of a lot of interesting software.
> 

Indeed! Scilab 5 which will be relicensed as CeCill won't be available 
(As I'm trying to package it).

For now, gluegen doesn't seems affected by the FE-Legal issue. Someone
interested in the review ?

For the jogl case, there is a possibility to work on  livna/RPM Fusion until an
alternative solution is available. But I wonder if we can provide the jogl
package twice: once of RPMFusion freeworld and the other with RPMFusion nonfree
(for Cg support).



Comment 8 Colin Walters 2008-04-15 10:08:43 EDT
Feel free to take the spec for use elsewhere, of course.  

I think it is worth trying again to open up a conversation with SGI about this
issue too.
Comment 9 Tom "spot" Callaway 2008-05-12 15:30:06 EDT
Closing as CANTFIX. Sorry guys.
Comment 10 Colin Walters 2008-05-12 16:03:28 EDT
As a possible alternative, someone should investigate:
http://lwjgl.org/

Comment 11 Tom "spot" Callaway 2008-05-12 16:11:47 EDT
lwjgl is no-good for Fedora, native/common/extgl.h is SGI Free B.
Comment 12 Mamoru TASAKA 2008-09-23 12:25:10 EDT
Hi, all:

I think this package is now okay, because SGI License B is now under MIT:
https://www.redhat.com/archives/fedora-legal-list/2008-September/msg00035.html
Comment 13 Tom "spot" Callaway 2008-09-23 12:32:30 EDT
Indeed. If someone wanted to reopen this and pursue review, I would lift the FE-Legal block.
Comment 14 Anthony Green 2008-09-23 12:53:09 EDT
We don't need to re-review this package do we?  jogl was already in FC5 and FC6.  I pulled it prior to 7 because of the licensing problem.  It's currently in cvs as a dead.package.   Let's just revive that package instead.  Does somebody want to co-maintain this with me?
Comment 15 Nicolas Chauvet (kwizart) 2008-09-23 13:18:43 EDT
(In reply to comment #14)
> We don't need to re-review this package do we?  jogl was already in FC5 and
> FC6.  I pulled it prior to 7 because of the licensing problem.  It's currently
> in cvs as a dead.package.   Let's just revive that package instead.  Does
> somebody want to co-maintain this with me?

I can help with co-maintaining this package(along with gluegen)
But despite the cvs creation side (If already done, no needs to re-do it); 
I would prefer to formally review this package: either I submit the review request  or you (like it was originally done)
Comment 16 Mamoru TASAKA 2008-09-23 13:25:19 EDT
I think re-review of this package is needed.
- Current Fedora guidelines says that more than "3 months" old spec file needs
  re-review.
  https://fedoraproject.org/wiki/Extras/OrphanedPackages#Claiming_Ownership_of_an_Orphaned_Package_Procedure
- Also Java guideline is established after F-8 (?) so FC6 based Java spec file
  needs update anyway IMO
Comment 17 Anthony Green 2008-09-23 13:52:02 EDT
Ok.  I am not going to resubmit, but I'd be happy to review.

BTW, upstream (Sun) is asking me:
"Question: in the short term, do we need to explicitly re-release the sources for JOGL 1.1.1 (*) with the old FreeB headers replaced with the new license? Or can Linux distributions use the existing sources? We have already transitioned our development to JOGL 2.0 and would prefer to make the license changes only in that branch. "

spot - we're OK with no upstream change, right?

AG
Comment 18 Tom "spot" Callaway 2008-09-23 14:00:34 EDT
Yes, because of how FreeB is written, we're fine with no upstream header change.
Comment 19 Nicolas Chauvet (kwizart) 2008-10-20 20:34:32 EDT
@Antony
I cannot have both gluegen and jogl to build separately, even if they use the same snapshot.
Here are the current attempts:
http://kwizart.fedorapeople.org/SRPMS/jogl-1.1.1-1.fc8.kwizart.src.rpm
http://kwizart.fedorapeople.org/SPECS/jogl.spec

http://kwizart.fedorapeople.org/SRPMS/gluegen-1.1.1-1.fc8.kwizart.src.rpm
http://kwizart.fedorapeople.org/SPECS/gluegen.spec
Do you have any advices ?
Comment 20 Nicolas Chauvet (kwizart) 2008-10-20 20:37:20 EDT
reopened
Comment 21 Tom "spot" Callaway 2008-10-22 16:52:38 EDT
Lifting FE-Legal.
Comment 22 D Haley 2008-11-21 23:22:06 EST
Created attachment 324396 [details]
Fix dirs for install target
Comment 23 D Haley 2008-11-21 23:23:19 EST
If I remove your patch0, then all is well with the build, however as you point out that is only because I have gluegen in my build dir.

Could one possibly, as part of the gluegen package, simply install the glugegen source into /usr/share/gluegen/, and then with patch0, instead of commenting out the gluegen location, remap it to /usr/share/glugen?


Also, as per the previous patch, some of the %install target locations were not quite right
Comment 24 Chitlesh GOORAH 2008-12-01 13:45:22 EST
BUILD FAILED
Target "gluegen.cpptasks.detect.os" does not exist in the project "JOGL". It is used from target "base.init".

with gluegen rpms built from gluegen-1.1.1-1.fc8.kwizart.src.rpm.
Comment 25 Levente Farkas 2008-12-15 11:04:53 EST
does it means lwjgl also good for fedora?
Comment 26 D Haley 2008-12-20 00:28:02 EST
https://jogl.dev.java.net/issues/show_bug.cgi?id=300 may be of use. A gentoo maintainer has patched their build process. Its quite old, though.
Comment 27 Jason Tibbitts 2009-01-13 18:47:43 EST
Since this depends on gluegen, which was closed because the submitter neglected to comment after several months, this is left in an unreviewable state.  I'm going to go ahead and close it, although if someone wants to re-submit gluegen (and respond to review commentary) then I guess this can be re-re-reopened and made to depend on the new gluegen review ticket.
Comment 28 Sylvestre Ledru 2009-12-08 17:59:55 EST
Created attachment 377049 [details]
With jogl/gluegen 2.0, a first patch to remove some hardcoded path to gluegen path
Comment 29 Henrique "LonelySpooky" Junior 2009-12-08 20:21:32 EST
(In reply to comment #28)
> Created an attachment (id=377049) [details]
> With jogl/gluegen 2.0, a first patch to remove some hardcoded path to gluegen
> path  

Thank you! I'll give it a try.
Comment 30 Henrique "LonelySpooky" Junior 2009-12-08 21:17:21 EST
(In reply to comment #28)
> Created an attachment (id=377049) [details]
> With jogl/gluegen 2.0, a first patch to remove some hardcoded path to gluegen
> path  

I'm getting my source code from here http://kenai.com/projects/jogl/sources/jogl-git/show Is that the same place you are getting yours, Sylvestre?
Comment 31 Sylvestre Ledru 2009-12-21 08:29:29 EST
(In reply to comment #30)
Sorry, I missed your question. Yes, I confirm that my patch applies against this version.
You still have to edit:
/home/sylvestre/dev/jogl2.git/make/build.xml
/home/sylvestre/dev/jogl2.git/make/build-nativewindow.xml
/home/sylvestre/dev/jogl2.git/make/build-jogl.xml
to set the correct paths to gluegen. 
I will probably update this too and try to make it applied to upstream.
Comment 32 Sylvestre Ledru 2010-01-15 04:23:23 EST
Could we upload JOGL 1.1 into Fedora/Redhat this way ? 
And plan to do the gluegen/jogl separation when JOGL 2.0 is released (which will be trivial since it will be done upstream).

Thanks
PS: can someone reopen this bug ?
Comment 33 Chen Lei 2010-01-28 01:56:54 EST
(In reply to comment #32)
> Could we upload JOGL 1.1 into Fedora/Redhat this way ? 
> And plan to do the gluegen/jogl separation when JOGL 2.0 is released (which
> will be trivial since it will be done upstream).
> Thanks
> PS: can someone reopen this bug ?    

Hi, Sylvestre. I think you'd better open a new bugzilla report and mark this bugzilla report as a duplicate.
PS: 
Which packages are not in fedora right now for packaging scilab 5.20?
Comment 34 Sylvestre Ledru 2010-01-28 10:59:35 EST
jogl, jgraphx, jhdf (see: http://fedoraproject.org/wiki/SIGs/SciTech/Scilab but note that net-cdf-java & fits dependencies are far from mandatory) and jlatexmath (http://forge.scilab.org/index.php/p/jlatexmath/)

Note only jogl is necessary for Scilab 5.1.1.

Anyway, I followed your comment and wrote bug #559623
Comment 35 Chen Lei 2010-01-28 12:25:35 EST
(In reply to comment #34)
> jogl, jgraphx, jhdf (see: http://fedoraproject.org/wiki/SIGs/SciTech/Scilab but
> note that net-cdf-java & fits dependencies are far from mandatory) and
> jlatexmath (http://forge.scilab.org/index.php/p/jlatexmath/)
> Note only jogl is necessary for Scilab 5.1.1.
> Anyway, I followed your comment and wrote bug #559623    
Hi!

Because Fedora is a "Breeding Edge" distrowatch, I think we should skip scilab 5.1.1 and begin to build scilab 5.2.0.

I realized from the changelog of jogl that the GlueGen runtime classes have been removed from jogl.jar. I think we can pull the source directly from upstream's vcs and package jogl and GlueGen separately.

Should all files in the prerequirements-scilab-5.2.0-src.tar.gz(such as jing.jar, jimi.jar, etc.) to be packaged before packaging scilab?
Comment 36 Sylvestre Ledru 2010-01-28 12:39:14 EST
Well, I don't know which changelog you are talking about but the version jogl 1.1 tarball has both gluegen and jogl together. 
You can create separate packages of them without any problems.

If you are talking about jogl 2.0, it is still a dev version and there are several problems with it:
* a lot of changes occurred in the API
* the last modifications on jogl git are three months old.
* there is not ETA on the release of a stable version (I tried a few time to contact upstream about that and about contributing to jogl but I never received any answer)

For all these reasons, jogl 1.1 should be packaged first.

About the prerequirements, I don't know any dependencies of Scilab using jing.jar or jimi.jar ?!
Comment 37 Chen Lei 2010-01-28 13:14:42 EST
(In reply to comment #36)
> Well, I don't know which changelog you are talking about but the version jogl
> 1.1 tarball has both gluegen and jogl together. 
> You can create separate packages of them without any problems.
> If you are talking about jogl 2.0, it is still a dev version and there are
> several problems with it:
> * a lot of changes occurred in the API
> * the last modifications on jogl git are three months old.
> * there is not ETA on the release of a stable version (I tried a few time to
> contact upstream about that and about contributing to jogl but I never received
> any answer)
> For all these reasons, jogl 1.1 should be packaged first.

If so, I think we can create a jogl1 package instead of jogl to push jogl 1.1 to the fedora repo like qt3 and qt(qt4). What is the version of gluegen that included in jogl 1.1 tarball?

> About the prerequirements, I don't know any dependencies of Scilab using
> jing.jar or jimi.jar ?!    

There is a Prerequirements to compile Scilab 5.2.0 from scilab's site.
See http://www.scilab.org/download/
Comment 38 Sylvestre Ledru 2010-01-28 13:25:18 EST
gluegen (with jogl) has the same version.

About the jing.jar and jimi.jar, I reported a bug upstream:
http://bugzilla.scilab.org/show_bug.cgi?id=6524
Comment 39 Chen Lei 2010-01-28 13:39:34 EST
Do you mean gluegen should ship with jogl?
Is this possible to build gluegen before build jogl using source from http://download.java.net/media/gluegen/builds/archive/ or from certain git revision?
Comment 40 Sylvestre Ledru 2010-01-28 13:46:10 EST
Yes, gentoo is doing it:
http://gpo.zugaina.org/dev-java/jogl/ChangeLog
and
http://gpo.zugaina.org/dev-java/gluegen/ChangeLog

(while Debian is not. Debian uses the one provided in jogl tarballs)
Comment 41 Chen Lei 2010-01-28 14:08:38 EST
(In reply to comment #40)
> Yes, gentoo is doing it:
> http://gpo.zugaina.org/dev-java/jogl/ChangeLog
> and
> http://gpo.zugaina.org/dev-java/gluegen/ChangeLog
> (while Debian is not. Debian uses the one provided in jogl tarballs)    

Since the original "Review Request" for gluegen and jogl aren closed, you or someone should create new "Review Request" for those two.

See http://fedoraproject.org/wiki/PackageMaintainers/Join


The closed "Review Request" can't be seen by fedora package sponsor.
Comment 42 Sylvestre Ledru 2010-01-28 14:30:13 EST
What about ?
https://bugzilla.redhat.com/show_bug.cgi?id=559623
Comment 43 Chen Lei 2010-01-28 14:43:00 EST
You can follow the instruction below. http://fedoraproject.org/wiki/PackageMaintainers/Join#Create_Your_Review_Request

You need to edit the Review Summary and upload the srpm. The "Review Request" for jogl and gluegen should be two separate bugzilla reports.
Comment 44 Sylvestre Ledru 2010-01-28 15:39:08 EST
Well, I am not a Fedora contributor neither a user...
Do you think someone can handle this for me ?
Comment 45 Chen Lei 2010-01-29 00:39:36 EST
Sylvestre, I think Henrique may be helpful to package gluegen and jogl. Try to contact him and let him known what gentoo is doing. 

http://gpo.zugaina.org/dev-java/jogl/ChangeLog
and
http://gpo.zugaina.org/dev-java/gluegen/ChangeLog

(while Debian is not. Debian uses the one provided in jogl tarballs)
Comment 46 Sylvestre Ledru 2010-01-29 03:13:52 EST
OK, thanks. I just sent an email to Henrique about that.
Comment 47 Henrique "LonelySpooky" Junior 2010-01-31 10:10:45 EST
Hello,
I will, then, continue to try to package JOGL/gluegen to make scilab possible in Fedora.
Although not much experienced, I believe that with some help it will be possible. I travel now, in February 3 and return on February 9, but I'll try to leave at least an early draft.
Comment 48 James Heather 2010-02-01 11:17:03 EST
I am very glad to hear about this! I use JOGL/gluegen a lot for my OpenGL teaching, and it would be fantastic to have it in Fedora.

When it turns up, could we please have an F12 build of the JOGL stuff as well as rawhide?

Looking forward to it.

James
Comment 49 Henrique "LonelySpooky" Junior 2010-02-21 18:21:51 EST
Hi, after a little work this weekend I've made some progress with this package, but, to be honest, I'm a little confused about this "gentoo way" to uncouple JOGL/gluegen.
This patch do not make much sense to me[1] and looking after the ebuild code[2] I have a impression that the gentoo guys are doing almost the same that we are doing.
What I have in mind is to build a separated gluegen package, but continue to use this gluegen that cames with JOGL source to build it, then, after JOGL is done, we can simply rm this gluegen codes. Since both, JOGL and his gluegen are compiled from source, this can be one easy way to get the package ready.

[1] - http://gentoo-overlays.zugaina.org/java-overlay/portage/dev-java/jogl/files/1.1.0/uncouple-gluegen.patch
[2] - http://gentoo-overlays.zugaina.org/java-overlay/portage/dev-java/jogl/jogl-1.1.1.ebuild
Comment 50 Chen Lei 2010-02-22 02:05:01 EST
Normally we should build jogl against the system-wide copy of gluegen, that is to say we must del the code of gluegen in %prep section.

%prep
%setup -q
%patch0 -p1
%patch1 -p1
#remove bundled gluegen
rm -rf (bundled gluegen)


Regards,
Comment 51 James Heather 2010-02-22 02:35:17 EST
> Normally we should build jogl against the system-wide copy of gluegen

In other words, against the one we've just built?

So package gluegen:

  Requires: jogl

and package jogl:

  Requires: gluegen
  BuildRequires: jogl

Are you going to have a separate jogl-javadoc package, by the way, or will that come as part of the jogl package?

Really glad to see progress on this!

James
Comment 52 Henrique "LonelySpooky" Junior 2010-02-22 07:03:42 EST
(In reply to comment #51)

> Are you going to have a separate jogl-javadoc package, by the way, or will that
> come as part of the jogl package?
I'm going to build a separated javadock package.
We already have this functional gluegen package: https://bugzilla.redhat.com/show_bug.cgi?id=439627#c35 but the main problem with JOGL is that it needs a side by side copy of gluegen to build his build.xml. The doubt here is if we can use this bundled gluegen in this initial step and discard it.
This bundled gluegen and our packaged gluegen will be the same. Use the bundled gluegen only means that the package can be done without major hacking in JOGL (which, incidentally, are out of my ability).
Maybe it becames clearer if I post here one draft. I'm working on it. =)
Comment 53 Chen Lei 2010-02-23 23:05:00 EST
(In reply to comment #51)
> > Normally we should build jogl against the system-wide copy of gluegen
> 
> In other words, against the one we've just built?
> 
> So package gluegen:
> 
>   Requires: jogl
> 
> and package jogl:
> 
>   Requires: gluegen
>   BuildRequires: jogl
> 
> Are you going to have a separate jogl-javadoc package, by the way, or will that
> come as part of the jogl package?
> 
> Really glad to see progress on this!
> 
> James    

gluegen not depends on jogl, we need to build a gluegen which can works fine with jogl 1.1.1a. We need find a svn or git version gluegen source which has the same codes compared to the bundled gluegen in jogl or find a version which is compatible with jogl 1.1.1a.
Comment 54 Chen Lei 2010-02-23 23:08:44 EST
(In reply to comment #52)
> (In reply to comment #51)
> 
> > Are you going to have a separate jogl-javadoc package, by the way, or will that
> > come as part of the jogl package?
> I'm going to build a separated javadock package.
> We already have this functional gluegen package:
> https://bugzilla.redhat.com/show_bug.cgi?id=439627#c35 but the main problem
> with JOGL is that it needs a side by side copy of gluegen to build his
> build.xml. The doubt here is if we can use this bundled gluegen in this initial
> step and discard it.
It's definitely not.
You must using a git or svn version of gluegen.
Maybe you need wrote some patches for gluegen to let jogl 1.1.1a build success with it.
Comment 55 Henrique "LonelySpooky" Junior 2010-02-25 13:34:06 EST
Found it: svn checkout https://gluegen.dev.java.net/svn/gluegen/tags/1.0b06a  gluegen --username user
Just a few more fixes and I post here a draft.
Comment 56 Henrique "LonelySpooky" Junior 2010-02-25 19:09:05 EST
Have just updated gluegen https://bugzilla.redhat.com/show_bug.cgi?id=439627
If gluegen is OK we're almost there. =)
Comment 57 Henrique "LonelySpooky" Junior 2010-02-25 21:59:41 EST
Here is my first build.
I do not want to go to bed without posting it. Please, keep in mind that it is a draft.
SPEC: http://lspooky.fedorapeople.org/jogl/1.1.1/1/jogl.spec
SRPM: http://lspooky.fedorapeople.org/jogl/1.1.1/1/jogl-1.1.1-1.fc12.src.rpm

rpmlint:
[lonely@localhost SPECS]$ rpmlint ../SRPMS/jogl-1.1.1-1.fc12.src.rpm 
jogl.src: W: spelling-error %description -l en_US Microsystems -> Micro systems, Micro-systems, Ecosystems
jogl.src:75: W: rpm-buildroot-usage %build rm -rf %{buildroot}
jogl.src:78: W: rpm-buildroot-usage %build mkdir -p %{buildroot}%{_javadir}
jogl.src:80: W: rpm-buildroot-usage %build %{buildroot}%{_javadir}/%{name}-%{version}.jar
jogl.src:81: W: rpm-buildroot-usage %build pushd %{buildroot}%{_javadir}
jogl.src:88: W: rpm-buildroot-usage %build install -dm 755 %{buildroot}%{_libdir}
jogl.src:90: W: rpm-buildroot-usage %build %{buildroot}%{_libdir}
jogl.src:93: W: rpm-buildroot-usage %build install -dm 755 %{buildroot}%{_javadocdir}/%{name}-%{version}
jogl.src:95: W: rpm-buildroot-usage %build %{buildroot}%{_javadocdir}/%{name}-%{version}
jogl.src:96: W: rpm-buildroot-usage %build ln -s %{name}-%{version} %{buildroot}%{_javadocdir}/%{name} # ghost symlink
jogl.src: W: no-cleaning-of-buildroot %install
jogl.src: W: no-%install-section
jogl.src: W: invalid-url Source2: gluegen-1.0.20102502svn.tar.gz
1 packages and 0 specfiles checked; 0 errors, 13 warnings.

[lonely@localhost SPECS]$ rpmlint ../RPMS/i686/jogl*
jogl.i686: W: spelling-error %description -l en_US Microsystems -> Micro systems, Micro-systems, Ecosystems
jogl.i686: W: unstripped-binary-or-object /usr/lib/libjogl_awt.so
jogl.i686: W: no-soname /usr/lib/libjogl_awt.so
jogl.i686: W: unstripped-binary-or-object /usr/lib/libjogl.so
jogl.i686: W: no-soname /usr/lib/libjogl.so
jogl.i686: W: no-documentation
jogl-javadoc.i686: W: non-standard-group Development/Java
jogl-javadoc.i686: W: dangerous-command-in-%post rm
jogl-manual.i686: W: spelling-error Summary(en_US) documetation -> documentation, documentary, documented
jogl-manual.i686: W: spelling-error %description -l en_US Usermanual -> User manual, User-manual, Wassermann
jogl-manual.i686: W: non-standard-group Development/Java
3 packages and 0 specfiles checked; 0 errors, 11 warnings.
Comment 58 Sylvestre Ledru 2010-02-26 03:50:10 EST
Well done!

I think you already know but when I tried 'rpmbuild -bb jogl.spec', I get:
+ /usr/bin/unzip -qq /home/Sylvestre/rpmbuild/SOURCES/jogl-1.1.1a-src.zip
replace gluegen/doc/manual/index.html? [y]es, [n]o, [A]ll, [N]one, [r]ename: 

It is normal ?
Comment 59 Henrique "LonelySpooky" Junior 2010-02-26 05:12:49 EST
Yes, it is normal when you try to build in a dirt /home/Sylvestre/rpmbuild/BUILD (from previous attempts). When Koji builds the packages it uses always a clean directory, but I can solve this because it is annoying.
Maybe Chen Lei could guide me through this rpmlint issues.
Comment 60 James Heather 2010-02-26 05:25:21 EST
(In reply to comment #59)
> Yes, it is normal when you try to build in a dirt
> /home/Sylvestre/rpmbuild/BUILD (from previous attempts). When Koji builds the
> packages it uses always a clean directory, but I can solve this because it is
> annoying.

I suspect this is related to the rpmlint warning:

jogl.src: W: no-cleaning-of-buildroot %install

Is this something to with not having an %install section? I am not quite sure what's going on there. I expected to see an %install but there isn't one.

Maybe the %clean isn't being fired for some reason. That ought to be getting rid of the previous build attempts.
Comment 61 James Heather 2010-02-26 05:28:01 EST
In fact, I think it's normal to start the %install section with

%install
rm -rf %{buildroot}

That would make rpmlint happier, and also solve your problem. At the moment, you'll hit this issue if the previous build failed, because %clean won't get executed, and the next build will get confused because of the existing files.
Comment 62 Henrique "LonelySpooky" Junior 2010-02-26 05:34:55 EST
Thanks, James. Soon I post an update here.
Comment 63 Henrique "LonelySpooky" Junior 2010-02-26 07:29:33 EST
SPEC: http://lonelyspooky.com/uploads/SRPMs/jogj/1.1.1-2/jogl.spec
SRPM: http://lonelyspooky.com/uploads/SRPMs/jogj/1.1.1-2/jogl-1.1.1-2.fc11.src.rpm

rpmlint is a bit more happy now:

[virtual@localhost SPECS]$ rpmlint ../RPMS/i586/jogl*
jogl.i586: W: unstripped-binary-or-object /usr/lib/libjogl_awt.so
jogl.i586: W: no-soname /usr/lib/libjogl_awt.so
jogl.i586: W: unstripped-binary-or-object /usr/lib/libjogl.so
jogl.i586: W: no-soname /usr/lib/libjogl.so
jogl.i586: W: no-documentation
jogl-debuginfo.i586: E: empty-debuginfo-package
jogl-javadoc.i586: W: dangerous-command-in-%post rm
4 packages and 0 specfiles checked; 1 errors, 6 warnings.

[virtual@localhost SPECS]$ rpmlint ../SRPMS/jogl-1.1.1-2.fc11.src.rpm 
jogl.src:75: W: rpm-buildroot-usage %build rm -rf %{buildroot}
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
Comment 64 Chen Lei 2010-02-26 07:38:37 EST
I wonder that "Source2:	gluegen-1.0.20102502svn.tar.gz" is not needed.
Comment 65 James Heather 2010-02-26 08:19:12 EST
Do you really need the %post section? It seems odd. It looks as though the "ln -s" in the %install, and the %ghost line in %files, should be enough to create the symlink without needing to rm and ln -s in %post.

Do you need to use restorecon to set the selinux contexts, by the way? I've noticed that in some spec files before. But maybe it all happens automatically.

Might be worth installing the rpm, and then trying

  restorecon -v $(rpm -ql jogl jogl-javadoc jogl-manual)

If it tells you it's changing anything, that probably means you need to use restorecon in %post.

James
Comment 66 Henrique "LonelySpooky" Junior 2010-02-26 15:42:13 EST
(In reply to comment #64)
> I wonder that "Source2: gluegen-1.0.20102502svn.tar.gz" is not needed.    
As described here[1] JOGL relies on gluegen's source tree: "Check out the GlueGen source tree:
JOGL relies on the GlueGen project to autogenerate most of the Java and JNI code for the OpenGL interface. The jogl/ and gluegen/ workspaces must be side-by-side in order for JOGL to build properly."
So, it is not enough to have gluegen packaged in order to build JOGL, we'll need gluegen's source in the first stage.
Here goes the error message:
[lonely@localhost make]$ ant
Buildfile: build.xml

BUILD FAILED
/home/lonely/jogl/jogl/make/build.xml:62: Cannot find ../../gluegen/make/gluegen-cpptasks.xml imported from /home/lonely/jogl/jogl/make/build.xml

(In reply to comment #65)
> Do you really need the %post section? It seems odd. It looks as though the "ln
> -s" in the %install, and the %ghost line in %files, should be enough to create
> the symlink without needing to rm and ln -s in %post.
You are completely right, I didn't noticed it.

>   restorecon -v $(rpm -ql jogl jogl-javadoc jogl-manual)
restorecon returns nothing:
restorecon -v $(rpm -ql jogl jogl-javadoc jogl-manual)
[lonely@localhost ~]$ restorecon -v $(rpm -ql jogl jogl-javadoc jogl-manual)
[lonely@localhost ~]$
Comment 67 Chen Lei 2010-02-26 21:47:00 EST
(In reply to comment #66)
> (In reply to comment #64)
> > I wonder that "Source2: gluegen-1.0.20102502svn.tar.gz" is not needed.    
> As described here[1] JOGL relies on gluegen's source tree: "Check out the
> GlueGen source tree:
> JOGL relies on the GlueGen project to autogenerate most of the Java and JNI
> code for the OpenGL interface. The jogl/ and gluegen/ workspaces must be
> side-by-side in order for JOGL to build properly."
> So, it is not enough to have gluegen packaged in order to build JOGL, we'll
> need gluegen's source in the first stage.
> Here goes the error message:
> [lonely@localhost make]$ ant
> Buildfile: build.xml
> 
> BUILD FAILED
> /home/lonely/jogl/jogl/make/build.xml:62: Cannot find
> ../../gluegen/make/gluegen-cpptasks.xml imported from
> /home/lonely/jogl/jogl/make/build.xml
> 
You need patch build.xml, it's easy to do say.
Comment 68 Henrique "LonelySpooky" Junior 2010-02-26 22:24:18 EST
(In reply to comment #67)
> You need patch build.xml, it's easy to do say.
I know that the ideal is to build JOGL without using this gluegen source, but, as I can see, even the gentoo guys didn't make it.
I'm not an experienced programmer and, maybe, this is just one thing that is beyond my skills. Use this source looks mandatory because to build JOGL without it may need to rewrite great amounts of code.
Comment 69 James Heather 2010-02-27 12:16:48 EST
Does that not suggest that it would be better off as a single spec file that builds both gluegen and jogl? I am not sure what the motivation is for splitting into two packages if the gluegen source is needed to build both of them.

James
Comment 70 Henrique "LonelySpooky" Junior 2010-02-27 19:46:46 EST
I'll probably need some help with this no-soname issue. Ideas, guys?


(In reply to comment #69)
> Does that not suggest that it would be better off as a single spec file that
> builds both gluegen and jogl? I am not sure what the motivation is for
> splitting into two packages if the gluegen source is needed to build both of
> them.
> 
> James    

Build both from the same source was my first idea, but since they are different projects, maybe, provide a separated gluegen is the best practice.
Comment 71 Chen Lei 2010-02-28 04:25:06 EST
(In reply to comment #68)
> (In reply to comment #67)
> > You need patch build.xml, it's easy to do say.
> I know that the ideal is to build JOGL without using this gluegen source, but,
> as I can see, even the gentoo guys didn't make it.
> I'm not an experienced programmer and, maybe, this is just one thing that is
> beyond my skills. Use this source looks mandatory because to build JOGL without
> it may need to rewrite great amounts of code.    

I think this will let package unproved. You may need someone for help.
Comment 72 Henrique "LonelySpooky" Junior 2010-02-28 08:33:02 EST
It will be a great loss to Fedora if Scilab remains outside of our repos (since JOGL is a dependency of it) because this is probably the best software available for simulation and modeling.
Particularly I would not see a great problem in bringing the source code of gluegen with JOGL because the gluegen's code follows the requirements of not using precompiled jars and is deleted immediately after the stage where JOGL finish to get the information it needs.
I'm not familiar with the procedures of RPMFusion, but I think it might be a good alternative if this package could move to there if it is not acceptable in our official repos. If this is our only alternative, Sclab will need to be moved as well.
Comment 73 Chen Lei 2010-02-28 10:48:34 EST
Haven't you tried using uncouple-gluegen.patch from gentoo?
Comment 74 Chen Lei 2010-02-28 10:50:01 EST
Also 


%{_javadir}/*.jar
%attr(755,root,root) %{_libdir}/libjogl.so
%attr(755,root,root) %{_libdir}/libjogl_awt.so

must changed to %{_libdir}/%{name}/*.jar
%{_libdir}/%{name}/*.so
Comment 75 Henrique "LonelySpooky" Junior 2010-02-28 11:29:44 EST
(In reply to comment #73)
> Haven't you tried using uncouple-gluegen.patch from gentoo?
Could you, please, take a look at the patch?
As I can see it is doing nothing.
Comment 76 James Heather 2010-02-28 17:27:45 EST
I'm not really following this. If gluegen and jogl are separate projects but jogl needs the gluegen project to compile, does that not mean it makes sense to do this as a single spec file? I don't understand the motivation for splitting into two, if one needs the source of the other to compile. That to me sounds like effectively a single project, regardless of whether it's split into two projects upstream.

Am I missing something?

James
Comment 77 James Heather 2010-02-28 17:35:50 EST
BTW this is good and important work--it will be really good to get JOGL into Fedora. That's true especially if it means Scilab too, but JOGL is also important in its own right, for Java development.

I presume you've seen the SUSE JOGL stuff at

http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/jogl

?

The OpenSUSE RPMs install just fine on F12, so they're obviously doing something right... the source RPMs won't compile on Fedora, though. But there might be some good clues in there. They seem to be building jogl and gluegen in the same spec file.

James
Comment 78 Henrique "LonelySpooky" Junior 2010-02-28 17:52:08 EST
Yes, I've seen opensuse's mandriva's and gentoo's way. This question seems to be more philosophical than technical. So I decided to send the e-mail asking for guidance to the lists.
It seems to me that the work will be stuck until they decide on the better way, so I think I'll do ALL the ways and wait the decision. =)
Comment 79 Chen Lei 2010-02-28 21:19:37 EST
Created attachment 396941 [details]
gentoo' patch
Comment 80 Henrique "LonelySpooky" Junior 2010-02-28 21:53:26 EST
Thank you. This is quite different from the patch that found previously.
I'll give it a try.
Comment 81 Henrique "LonelySpooky" Junior 2010-03-01 10:18:30 EST
[lonely@localhost jogl-1.1.1a-src]$ patch -p0 < uncouple-gluegen.patch 
patching file jogl/make/build.xml
Hunk #1 succeeded at 131 (offset 4 lines).

[lonely@localhost make]$ ant
Buildfile: build.xml

BUILD FAILED
/home/lonely/rpmbuild/SOURCES/jogl-1.1.1a-src/jogl/make/build.xml:62: Cannot find ../../gluegen/make/gluegen-cpptasks.xml imported from /home/lonely/rpmbuild/SOURCES/jogl-1.1.1a-src/jogl/make/build.xml

Total time: 0 seconds

I was looking at the source and skip this "searching gluegen's code" may be too much work, but if we provide the gluegen-source as Hans have suggested it it relatively easy to declare another gluegen root.

  <property name="gluegen.root" value="../../gluegen" />
Comment 82 Sylvestre Ledru 2010-03-01 16:01:53 EST
FYI, in Debian/Ubuntu, for the past 2 or 3 years, I am packaging JOGL and Gluegen as a single package.
There is not much libraries using Gluegen and, for now, nobody complained about the fact that JOGL and Gluegen are provided into the same package.
Comment 83 Henrique "LonelySpooky" Junior 2010-03-01 21:26:49 EST
I guess we have some precedent cases. The discussion can be found here: http://lists.fedoraproject.org/pipermail/devel/2010-February/131665.html

So, I'll continue this package with BuildRequires: gluegen-source.
Comment 84 Henrique "LonelySpooky" Junior 2010-03-09 11:14:01 EST
Hi, sorry for the delay, but I'm a little sick this days.
As you can see, I've updated gluegen to build a package named gluegen-source. By doing this, I'm, now, able to build jogl without gluegen side by side and my spec now BuildRequires: gluegen-source. I've made a patch to point my build.xml to the correc (and new) location of gluegen.
Despite the fact that my local copy of jogl builds ok, I'm having problems with my rpmbuild version:

BUILD FAILED
/home/lonely/rpmbuild/BUILD/jogl/make/build.xml:1562: The following error occurred while executing this line:
/home/lonely/rpmbuild/BUILD/jogl/make/build.xml:487: The following error occurred while executing this line:
/usr/share/gluegen-source/gluegen/make/build.xml:458: The following error occurred while executing this line:
/usr/share/gluegen-source/gluegen/make/build.xml:378: The following error occurred while executing this line:
/usr/share/gluegen-source/gluegen/make/gluegen-cpptasks.xml:394: Problem: failed to create task or type compiler
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken place.


Total time: 4 seconds
erro: Status de saída de /var/tmp/rpm-tmp.lV0Zq0 inválido (%build)

That is weird... one version builds and another not.


spec: http://lspooky.fedorapeople.org/jogl/1.1.1/2/jogl.spec
srpm: http://lspooky.fedorapeople.org/jogl/1.1.1/2/fix-buildxml.patch
Comment 85 Henrique "LonelySpooky" Junior 2010-03-09 11:23:42 EST
Created attachment 398837 [details]
patch to correctly point build.xml

This is a patch to correctly point build.xml
Comment 86 Henrique "LonelySpooky" Junior 2010-03-09 12:52:01 EST
Solved. I'm able to build now:
spec: http://lspooky.fedorapeople.org/jogl/1.1.1/3/jogl.spec
srpm: http://lspooky.fedorapeople.org/jogl/1.1.1/3/jogl-1.1.1-3.fc12.src.rpm

rpmlint has 5 complains:
[lonely@localhost SPECS]$ rpmlint ../RPMS/i686/jogl-*
jogl.i686: W: spelling-error %description -l en_US Microsystems -> Micro systems, Micro-systems, Ecosystems
jogl.i686: W: no-soname /usr/lib/libjogl_awt.so
jogl.i686: W: no-soname /usr/lib/libjogl.so
jogl.i686: W: no-documentation
jogl-debuginfo.i686: E: debuginfo-without-sources
4 packages and 0 specfiles checked; 1 errors, 4 warnings.

I guess we should ignore this "jogl.i686: W: spelling-error %description -l en_US Microsystems -> Micro systems, Micro-systems, Ecosystems" end this "jogl.i686: W: no-documentation", but I don't know hot to fix the others.
Comment 87 Sylvestre Ledru 2010-03-09 13:24:11 EST
I don't think the soname missing is really an issue since .so should never be called directly. Only called through Java.
About the debuginfo without sources, I am not familiar with fedora but I am pretty sure you should copy the native source (C) into a dedicated package into a directory where gdb can find them.
Comment 88 James Heather 2010-03-09 13:42:01 EST
(In reply to comment #86)
> jogl.i686: W: no-soname /usr/lib/libjogl_awt.so
> jogl.i686: W: no-soname /usr/lib/libjogl.so

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

Looks like the .so files need to go into %{_libdir}/%{name}. I suspect that will get rid of the warning; but it needs doing either way.

Good work--this looks like it's coming along nicely.

James
Comment 89 Stephen R. Saucier 2010-03-09 16:23:35 EST
Henrique "LonelySpooky" Junior:

rpm -q --filesbypkg jogl
jogl                      /usr/lib64jogl/libjogl.so
jogl                      /usr/lib64jogl/libjogl_awt.so
jogl                      /usr/share/java/jogl-1.1.1.jar
jogl                      /usr/share/java/jogl.jar

Granted, I have no idea what I am talking about, however: that /usr/lib64jogl/ seems suspect to me, shouldn't that be /usr/lib64/java?
Comment 90 Henrique "LonelySpooky" Junior 2010-03-09 16:32:47 EST
Absolutely right. It should be /usr/lib64/jogl (my fault).
I'm uploading a fix right now.
Comment 91 Henrique "LonelySpooky" Junior 2010-03-09 16:41:42 EST
Here is an update:
spec: http://lspooky.fedorapeople.org/jogl/1.1.1/4/jogl.spec
srpm: http://lspooky.fedorapeople.org/jogl/1.1.1/4/jogl-1.1.1-4.fc12.src.rpm

rpmlint is a bit more happy:
[lonely@localhost SPECS]$ rpmlint ../RPMS/i686/jogl-*
jogl.i686: W: spelling-error %description -l en_US Microsystems -> Micro systems, Micro-systems, Ecosystems
jogl.i686: W: no-documentation
jogl-debuginfo.i686: E: debuginfo-without-sources
4 packages and 0 specfiles checked; 1 errors, 2 warnings.

(In reply to comment #87)
> About the debuginfo without sources, I am not familiar with fedora but I am
> pretty sure you should copy the native source (C) into a dedicated package into
> a directory where gdb can find them.    
It is a mystery to me too, Sylvestre
Comment 92 Levente Farkas 2010-03-09 17:12:58 EST
not required:
cd ..
rm -rf %{buildroot}  (in install)

don't use -p in install param

if you use
mkdir -p %{buildroot}%{_javadir}
why use a few lines later
install -dm 755 %{buildroot}%{_libdir}/%{name}
some place use install some place use cp...
try to be consequent.

don't use "\" line break so much. a 80 chars long lines is not too long, so most lines shouldn't have to break.
Comment 93 James Heather 2010-03-09 17:26:43 EST
Is the no-documentation problematic? Obviously the javadoc is in a separate package, but maybe you are supposed to put in a README? Not sure.

I have run

  rpmlint -a | grep no-doc

and it did seem that there were quite a lot of installed packages on my machine that have that warning, so you're in good company.

You'd think that an error would be a fatal problem, wouldn't you? Well,

  rpmlint -a | grep " E: "

returns plenty of stuff.

But

  rpmlint -a | grep "debuginfo-without-sources"

returns nothing (and I do have quite a number of debuginfo packages installed), so I suspect that one is a problem.

James
Comment 94 Henrique "LonelySpooky" Junior 2010-03-09 18:06:26 EST
(In reply to comment #92)
> rm -rf %{buildroot}  (in install)
I put this because of a rpmlint error: jogl.src: W: no-cleaning-of-buildroot %install
 
> don't use -p in install param
> 
> if you use
> mkdir -p %{buildroot}%{_javadir}
> why use a few lines later
> install -dm 755 %{buildroot}%{_libdir}/%{name}
> some place use install some place use cp...
> try to be consequent.
I have some recycled code here.
 
> don't use "\" line break so much. a 80 chars long lines is not too long, so
> most lines shouldn't have to break.    
Just for aesthetic reasons, or is there any consequences for rpm's generation?


(In reply to comment #93)
>   rpmlint -a | grep "debuginfo-without-sources"
> 
> returns nothing (and I do have quite a number of debuginfo packages installed),
> so I suspect that one is a problem.
Thank you so much, James, I guess that is time to some googleing and ask for help in the lists.
Comment 95 Henrique "LonelySpooky" Junior 2010-03-09 18:17:09 EST
(In reply to comment #93)
>   rpmlint -a | grep "debuginfo-without-sources"
> 
> returns nothing (and I do have quite a number of debuginfo packages installed),
> so I suspect that one is a problem.
Should it be the same case? https://bugzilla.redhat.com/show_bug.cgi?id=545039#c9
Comment 96 Henrique "LonelySpooky" Junior 2010-03-09 18:23:42 EST
(In reply to comment #91)
> jogl.i686: W: no-documentation
> jogl-debuginfo.i686: E: debuginfo-without-sources
It seems that this error can be ignored https://bugzilla.redhat.com/show_bug.cgi?id=563001
Comment 97 Henrique "LonelySpooky" Junior 2010-03-10 16:06:40 EST
I guess is time to reopen this review (and for gluegen too). Should I create a new one?
Comment 98 Henrique "LonelySpooky" Junior 2010-03-11 07:41:46 EST

*** This bug has been marked as a duplicate of bug 572515 ***
Comment 99 Jason Tibbitts 2011-05-23 13:48:04 EDT

*** This bug has been marked as a duplicate of bug 690282 ***

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