Bug 572515 - Review Request: jogl - Java bindings for OpenGL
Summary: Review Request: jogl - Java bindings for OpenGL
Status: CLOSED DUPLICATE of bug 690282
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
Depends On: 572512
Blocks: 472639 RussianFedoraRemix
TreeView+ depends on / blocked
Reported: 2010-03-11 12:39 UTC by Henrique C. S. Junior
Modified: 2019-04-14 04:28 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-03-23 19:27:28 UTC
Type: ---
gwync: fedora-review?

Attachments (Terms of Use)
Mock build log, 5/4/10 (78.53 KB, application/octet-stream)
2010-05-04 20:37 UTC, Gwyn Ciesla
no flags Details
Updated licence (4.34 KB, application/octet-stream)
2011-02-21 21:15 UTC, Aidan Delaney
no flags Details
Updated name (4.33 KB, text/x-rpm-spec)
2011-02-21 21:45 UTC, Sylvestre Ledru
no flags Details

Description Henrique C. S. Junior 2010-03-11 12:39:38 UTC
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
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

Comment 1 Henrique C. S. Junior 2010-03-11 12:41:46 UTC
*** Bug 439630 has been marked as a duplicate of this bug. ***

Comment 2 Sylvestre Ledru 2010-03-23 10:04:00 UTC
Henrique, should not we add a team as C/C of this bug for a review ?

Comment 3 Henrique C. S. Junior 2010-03-23 14:13:17 UTC
I've already posted requests at devel and packaging lists.

Comment 4 Gwyn Ciesla 2010-03-30 14:12:38 UTC

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.


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 .


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


# MUST: The package must meet the Packaging Guidelines .


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


NVIDIA Personal non-exclusive license??!?!?

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]


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


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


# 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.


# 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]


# 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]


# 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]


# 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]


# 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]


# 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]


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


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


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


# 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]


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


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


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


# 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]


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


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


# 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]


# 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]


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


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


So, I can't finish this until gluegen is in rawhide, but you can start with this.

Comment 5 Henrique C. S. Junior 2010-04-03 01:33:41 UTC
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.

Comment 6 Henrique C. S. Junior 2010-04-05 01:32:05 UTC
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

Comment 7 Sylvestre Ledru 2010-04-18 16:53:06 UTC
Ping ?

Comment 8 Gwyn Ciesla 2010-04-23 19:29:01 UTC
Still waiting on gluegen. . .

Comment 9 Gwyn Ciesla 2010-05-04 20:36:44 UTC
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.

Comment 10 Gwyn Ciesla 2010-05-04 20:37:38 UTC
Created attachment 411408 [details]
Mock build log, 5/4/10

Comment 11 Henrique C. S. Junior 2010-05-04 21:52:17 UTC
Can this be a temporary error in rawhide?

Comment 12 Chen Lei 2010-05-05 09:55:18 UTC
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.

Comment 13 Gwyn Ciesla 2010-07-07 13:15:40 UTC
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.

Comment 14 Aidan Delaney 2010-07-07 13:46:09 UTC
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).

Comment 15 Gwyn Ciesla 2010-07-07 16:19:41 UTC
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.

Comment 16 Alex Lancaster 2010-07-12 03:39:40 UTC
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

Comment 17 Gwyn Ciesla 2010-07-28 13:27:29 UTC
Aidan, ping?

Comment 18 Aidan Delaney 2010-07-28 15:33:40 UTC
A spec file that addresses Chen Lei's points from comment #12 is available at

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/

Comment 19 Chen Lei 2010-07-28 16:37:39 UTC
(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

Comment 20 Gwyn Ciesla 2010-07-29 13:12:06 UTC
Chen is correct, you'll need to patch jogl to use the jars where gluegen has them.

Comment 22 Aidan Delaney 2010-08-05 22:20:43 UTC
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.

Comment 23 Sylvestre Ledru 2010-08-15 19:48:47 UTC
@aiden: I don't see the problem ?
To me, java.library.path must be set in the Java code. It is jogl business.

Comment 24 Aidan Delaney 2010-08-30 13:49:17 UTC
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.

Comment 25 Gwyn Ciesla 2010-10-29 14:09:58 UTC
Where are we on this?

Comment 26 Aidan Delaney 2010-11-03 10:25:30 UTC
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.

Comment 27 Gwyn Ciesla 2010-11-08 20:47:16 UTC
Excellent.  Thanks!

Comment 28 Aidan Delaney 2010-11-22 20:35:37 UTC
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.

Comment 29 Sylvestre Ledru 2010-11-23 19:40:31 UTC
Great. Does this mean it is ready for an upload in Fedora ?

Comment 30 Aidan Delaney 2010-11-23 20:00:52 UTC
@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.

Comment 31 Sylvestre Ledru 2010-11-23 21:04:33 UTC
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.

Comment 32 Aidan Delaney 2010-11-23 21:10:40 UTC
Yeah.  Just a massive forward pointer to what's down the line.  JoGL 1.X will be around for ages.

Comment 33 Gwyn Ciesla 2010-12-06 16:06:45 UTC
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:


Comment 34 Sylvestre Ledru 2010-12-06 16:51:18 UTC
"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.

Comment 35 Gwyn Ciesla 2010-12-14 13:49:07 UTC
This is interesting.  There's already an orphaned jogl.


Comment 36 Aidan Delaney 2010-12-14 14:52:58 UTC
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.

Comment 37 Gwyn Ciesla 2010-12-14 15:04:01 UTC
Cool, blocking FE-LEGAL.

Comment 38 Jason Tibbitts 2010-12-14 16:05:12 UTC
And spot says this is OK: 

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.


So feel free to move forward.  Unblocking FE-Legal.

Comment 39 Jason Tibbitts 2010-12-14 16:06:54 UTC
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.

Comment 40 Sylvestre Ledru 2010-12-14 16:18:35 UTC
Do we know if upstream is aware of the license issue ?

Comment 41 Sylvestre Ledru 2011-02-13 16:20:58 UTC

Comment 42 Aidan Delaney 2011-02-21 21:15:25 UTC
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.

Comment 43 Sylvestre Ledru 2011-02-21 21:45:55 UTC
Created attachment 479999 [details]
Updated name

The same spec with a mistake in my family name.

Comment 44 Alexander Kurtakov 2011-03-23 13:43:56 UTC
How can we(Java SIG) help with getting this review finished?

Comment 45 Sylvestre Ledru 2011-03-23 13:50:54 UTC
Alexander, IMHO, the best way would be for you to assign to yourself this bug ;)

Comment 46 Gwyn Ciesla 2011-03-23 14:08:14 UTC
Also, check out the gluegen FTBFS.

Comment 47 Alexander Kurtakov 2011-03-23 14:25:33 UTC
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.
what are the current issues with this package?

P.S. I'll take a look at gluegen FTBFS now.

Comment 48 Sylvestre Ledru 2011-03-23 14:28:00 UTC
jon, do you have the log of the FTBFS of gluegen ?

Comment 49 Gwyn Ciesla 2011-03-23 14:36:08 UTC
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

Comment 50 Alexander Kurtakov 2011-03-23 15:31:48 UTC
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 :)

Comment 51 Gwyn Ciesla 2011-03-23 15:44:05 UTC

That would be the submitter of this bug, see comment #13.

Comment 52 Alexander Kurtakov 2011-03-23 15:47:27 UTC
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.

Comment 53 Gwyn Ciesla 2011-03-23 17:41:14 UTC
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.

Comment 54 Sylvestre Ledru 2011-03-23 18:24:30 UTC
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...


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)

Comment 55 Gwyn Ciesla 2011-03-23 18:36:08 UTC
Ok, thanks!  Given that, Alexander, shall I post a new request, or just post new links?

Comment 56 Alexander Kurtakov 2011-03-23 18:51:49 UTC
(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.

Comment 57 Gwyn Ciesla 2011-03-23 19:27:28 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=690282

Comment 58 Jason Tibbitts 2011-05-23 17:48:16 UTC

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

Comment 59 J. Scheurich 2019-04-14 04:28:05 UTC
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)

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