Scilab does not start after some upgrades on Ubuntu Xenial

[Norbert]

[Impact]

Software that use libjogl2-java (Scilab, Matlab,...) fail to run, because Mesa dropped 'Gallium' from the renderer string.

[Test case]
Steps to reproduce:
1. have installed Scilab on Ubuntu Xenial system
2. install system updates
3. try to launch Scilab from GUI - it does not start
4. try to launch Scilab from terminal - it does not start with the following output in the terminal:

$ scilab
Could not create a Scilab main class. Error:
Exception in thread "main" java.lang.InternalError: XXX0 profile[1]: GL3bc -> profileImpl GL4bc !!! not mapped
 at com.jogamp.opengl.GLProfile.computeProfileMap(GLProfile.java:2071)
 at com.jogamp.opengl.GLProfile.initProfilesForDeviceCritical(GLProfile.java:1954)
 at com.jogamp.opengl.GLProfile.initProfilesForDevice(GLProfile.java:1875)
 at com.jogamp.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1842)
 at com.jogamp.opengl.GLProfile.access$000(GLProfile.java:80)
 at com.jogamp.opengl.GLProfile$1.run(GLProfile.java:230)
 at java.security.AccessController.doPrivileged(Native Method)
 at com.jogamp.opengl.GLProfile.initSingleton(GLProfile.java:216)
 at com.jogamp.opengl.GLProfile.getProfileMap(GLProfile.java:2297)
 at com.jogamp.opengl.GLProfile.get(GLProfile.java:988)
 at com.jogamp.opengl.GLProfile.getDefault(GLProfile.java:722)
 at com.jogamp.opengl.GLProfile.getDefault(GLProfile.java:733)
 at org.scilab.modules.gui.SwingView.<init>(Unknown Source)
 at org.scilab.modules.gui.SwingView.registerSwingView(Unknown Source)
 at org.scilab.modules.core.Scilab.<init>(Unknown Source)

Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).

Expected results:
Scilab works normally on Ubuntu 16.04 LTS system.

Actual results:
see error above.

[Regression potential]
The fix is a simple oneliner that allows libjogl2-java to detect Mesa with both new and original version of Mesa.

[Sergio Callegari (callegar)]

Software rendering with recent mesa (either LLVMPipe, softpipe or swr) breaks matlab.

Seen with MATLAB 2016a on Kubuntu 17.04 with the latest (git) mesa as of today.

Graphic commands (e.g. plot) hang and make it impossible to close Matlab cleanly.

On llvmpipe the 'opengl info' matlab command crashes with

Error using hgopengl
Java exception occurred:
java.lang.RuntimeException: Waited 5000ms for: <38d5ebf2, 64757a04>[count 2 [ add. 0, orig 2], qsz 0, owner
<Startup Class Loader>, add.owner Startup Class Loader-SharedResourceRunner] - <main>
 at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:198)
 at com.jogamp.opengl.GLProfile.initSingleton(GLProfile.java:199)
 at com.jogamp.opengl.GLProfile.getDefaultDevice(GLProfile.java:2003)
 at com.jogamp.opengl.GLCapabilities.<init>(GLCapabilities.java:84)
 at com.mathworks.hg.uij.OpenGLUtils$MyGLListener.getGLInformation(OpenGLUtils.java:320)
 at com.mathworks.hg.uij.OpenGLUtils$MyGLListener.getGLData(OpenGLUtils.java:498)
 at com.mathworks.hg.uij.OpenGLUtils.getGLData(OpenGLUtils.java:78)

Error in hgopengl

On softpipe, the same command hangs.

This is curious because matlab has itself a software rendering mode, that seems to rely on mesa X11. The opengl info for it returns

                          Version: '2.1 Mesa 10.5.2'
                           Vendor: 'Brian Paul'
                         Renderer: 'Mesa X11'
                   MaxTextureSize: 16384
                           Visual: 'Visual 0x72, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardware acceleratio…'
                         Software: 'true'
             HardwareSupportLevel: 'none (known graphics driver issues)'
        SupportsGraphicsSmoothing: 0
    SupportsDepthPeelTransparency: 1
       SupportsAlignVertexCenters: 0
                       Extensions: {151x1 cell}
               MaxFrameBufferSize: 16384

So, it looks like mesa was supporting matlab 2016a just fine at the time of 10.5.2 and that we are now facing a regression.

[Emil-l-velikov (emil-l-velikov)]

Hi Sergio,

I won't be looking at the issue, I'm afraid yet here's a couple of ideas/suggestions that should help:

- try to track down the first Mesa version (ideally a commit) that breaks things
- isolate that the issue is not LLVM related by rebuilding mesa without it
- check that the correct libraries are picked (using strace or LD_DEBUG=libs)
Matlab might be shipping libraries (say libc/libstdc++) that are older than the ones Mesa is build against.
- try to get more verbose information of the issue - not sure if the dev. will have a matlab license to debug themselves

[Sergio Callegari (callegar)]

Hi,

I totally understand the difficulty in looking into an issue related to (expensive) commercial, that - as such - is hard to reproduce.

Thanks for the suggestion, even if - on a machine that is in use - I will not be able to do any bisection.

I'll try to work on the last point aka get more verbose information.

In any case, my intent was mostly to assure that a trace of the problem is present on the bug tracker, in case other users run into the issue and possibly to guide them if they need to get new hardware with the need to run Matlab on it.

Unfortunately the Matlab experience on Linux is sad. Not working with nouveau. Not working with soft rendering, either. Working with its own soft rendering, but with many limitations. Fortunately, it seems OK on intel graphics.

[Brianp-h (brianp-h)]

Sergio, I installed the 30-day trial of Matlab r2017b and typed 'opengl info' in the command window. I did not get a java exception. I got an error message that reads:

"""
MATLAB has experienced a low-level graphics error, and may not have drawn correctly.
Read about what you can do to prevent this issue at Resolving Low-Level Graphics Issues then restart MATLAB.
To share details of this issue with MathWorks technical support,
please include this file with your service request.
"""

I don't see that issue when using NVIDIA's driver.

I used apitrace to create a trace of Matlab's GL calls with llvmpipe and with NVIDIA's linux driver. It looks like Matlab begins by trying to find the highest supported GL version of the core profile. With NVIDIA's driver it finds 4.5. With llvmpipe it finds 3.3.

Then, it also tries to create compatibility profile context. With NVIDIA's driver it again gets a 4.5 context. With llvmpipe, we don't have such profiles and Matlab stops after getting a GL 3.1 context.

Finally, with llvmpipe, Matlab tries to create a 3.3 compatibility profile and fails. It then successfully creates a legacy context with glXCreateNewContext(). It calls glGetIntegerv(GL_MAJOR/MINOR_VERSION) then destroys the context.

As far as I an tell, Matlab simply doesn't accept llvmpipe's context/version offerings. Either that's by design or there's some sort of logic bug in MatLab that gives up on GL support after failing to create a particular kind of context.

You could try installing some older versions of Mesa to see if Matlab 2016a works/fails. But Matlab 2017b seems to act differently.

[Sergio Callegari (callegar)]

@Brian

thanks for testing! Indeed, I think that Matlab 2016 is fine with the NVIDIA proprietary driver. However, I cannot use it because I have a KDE desktop and the nvidia proprietary drivers hang the konsole as per

https://devtalk.nvidia.com/default/topic/879586/linux/kf5-konsole-15-04-and-15-08-consumes-100-cpu-on-close-only-with-proprietary-nvidia-driver/2

https://bugs.kde.org/show_bug.cgi?id=343803

https://bugreports.qt.io/browse/blockquote%3E

Furthermore, I prefer the free drivers when my graphics card copes with them.

The different response to the opengl info may be related to a slightly different mesa/graphics stack combination. Incidentally, it is unclear to me whether you got the "MATLAB has experienced a low-level graphics error" with llvmpipe or the hardware driver.

Matlab seems to use some java library to interact with opengl and I do not know if it is something commercial or something open source that MathWorks has adapted to its needs. In the latter case, testing might be easier.

[Sergio Callegari (callegar)]

... looks like also scilab has issues with the software renderer. With LIBGL_ALWAYS_SOFTWARE=1, scilab cannot plot (shows empty plot windows). May be a totally unrelated issue, but I think that scilab and matlab have in common the use of jogamp for graphics rendering.

[Sergio Callegari (callegar)]

Scilab gives

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Caught GLException: AWT-EventQueue-0: X11GLXContext.createContextImpl ctx !ARB but ARB is used, profile > GL2 requested (OpenGL >= 3.0.1). Requested: GLProfile[GL3bc/GL3bc.sw], current: 3.0 (Compat profile, ES2 compat, FBO, software) - 3.0 Mesa 17.3.0-devel
        at javax.media.opengl.awt.GLJPanel$OffscreenBackend.initialize(GLJPanel.java:1757)
        at javax.media.opengl.awt.GLJPanel.initializeBackendImpl(GLJPanel.java:1339)
        at javax.media.opengl.awt.GLJPanel.paintComponent(GLJPanel.java:550)
        at javax.swing.JComponent.paint(Unknown Source)
        at javax.swing.JComponent.paintChildren(Unknown Source)
        at javax.swing.JComponent.paint(Unknown Source)
        at javax.swing.JComponent.paintChildren(Unknown Source)
        at javax.swing.JComponent.paint(Unknown Source)
        at javax.swing.JLayeredPane.paint(Unknown Source)
        at javax.swing.JComponent.paintChildren(Unknown Source)
        at javax.swing.JComponent.paint(Unknown Source)
        at javax.swing.JViewport.paint(Unknown Source)
        at javax.swing.JComponent.paintChildren(Unknown Source)
        at javax.swing.JComponent.paint(Unknown Source)
        at javax.swing.JComponent.paintToOffscreen(Unknown Source)
        at javax.swing.BufferStrategyPaintManager.paint(Unknown Source)
        at javax.swing.RepaintManager.paint(Unknown Source)
        at javax.swing.JComponent._paintImmediately(Unknown Source)
        at javax.swing.JComponent.paintImmediately(Unknown Source)
        at javax.swing.RepaintManager$3.run(Unknown Source)
        at javax.swing.RepaintManager$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
        at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
        at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
        at javax.swing.RepaintManager.prePaintDirtyRegions(Unknown Source)
        at javax.swing.RepaintManager.access$1000(Unknown Source)
        at javax.swing.RepaintManager$ProcessingRunnable.run(Unknown Source)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$400(Unknown Source)
        at java.awt.EventQueue$2.run(Unknown Source)
        at java.awt.EventQueue$2.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: javax.media.opengl.GLExcept...

[Sergio Callegari (callegar)]

Obviously, at least with scilab, there is an important regression.

Note that the scilab website itself, since the release of scilab 5.X (for the last 2-3 years) has advised to use LIBGL_ALWAYS_SOFTWARE=1 with mesa to work around hw driver issues:

https://wiki.scilab.org/Graphical%20issues%20with%20Scilab%205.X

[Scott-d-phillips (scott-d-phillips)]

scilab breaks starting with:

commit 92b4ca45504e7ffc5f4fa385ada1be48e6123181
Author: Marek Olšák <email address hidden>
Date: Wed Jun 7 22:00:48 2017 +0200

    st/mesa: remove the "Gallium 0.4 on" prefix from GL_RENDERER

    If you want to keep it for your driver, please raise your hand.
    The prefix will probably have to be added into the driver instead of here.

    I cringe when I look at my long renderer string:
      Gallium 0.4 on AMD Radeon R9 Fury Series (DRM 3.17.0 / 4.11.0-staging-01277-gab25a9e, LLVM 5.0.0)

    I'm sincerely sorry for all apps that detect Mesa by expecting "Gallium"
    in the string.

    Reviewed-by: Eric Anholt <email address hidden>

It seems jogl wants to detect mesa and alter its behavior based on that:

https://github.com/sgothel/jogl/blob/45cc13c4d68fb3137b741cbc39ea653c15db2f66/src/jogl/classes/jogamp/opengl/GLContextImpl.java#L2136

[Sroland-vmware (sroland-vmware)]

(In reply to Scott D Phillips from comment #8)
> It seems jogl wants to detect mesa and alter its behavior based on that:
>
> https://github.com/sgothel/jogl/blob/
> 45cc13c4d68fb3137b741cbc39ea653c15db2f66/src/jogl/classes/jogamp/opengl/
> GLContextImpl.java#L2136

At a quick glance, my guess would be the issues are around GLRendererQuirks.GLNonCompliant which would be set with detected mesa driver and requested (compatCtx && (major > 3 || (major == 3 && minor >= 1)).
It would then refuse to use such contexts.
(I would tend to think it is a bug in jogl somewhere with different gl versions being available for core/compat contexts but I have no idea really.)

[Norbert (nrbrtx)]

According to scilab changelog it does not changed since

scilab (5.5.2-2ubuntu3) xenial; urgency=medium

  * Enable debian/patches/fop-2.0.diff again to avoid a FTBFS
    since fop 2.0 is now in Ubuntu.

 -- Graham Inggs <email address hidden> Wed, 06 Apr 2016 18:32:35 +0200

So it is graphics issue. Possible related to bug 1741447.

[Norbert (nrbrtx)]

Installed `vainfo` and `mesa-va-drivers`
`sudo apt-get install mesa-va-drivers vainfo`

Here is my output of `vainfo`:

$ vainfo
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.0)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple : VAEntrypointVLD
      VAProfileMPEG2Main : VAEntrypointVLD
      VAProfileVC1Simple : VAEntrypointVLD
      VAProfileVC1Main : VAEntrypointVLD
      VAProfileVC1Advanced : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main : VAEntrypointVLD
      VAProfileH264Main : VAEntrypointEncSlice
      VAProfileH264High : VAEntrypointVLD
      VAProfileH264High : VAEntrypointEncSlice
      VAProfileNone : VAEntrypointVideoProc

$ lspci -knn | grep -A3 VGA
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993]
    Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:0123]
    Kernel driver in use: radeon
    Kernel modules: radeon

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.4.0-109-generic root=UUID=... ro splash quiet vt.handoff=7

$ glxinfo | grep -i 'direct\|vendor\|opengl'
direct rendering: Yes
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
    Vendor: X.Org (0x1002)
OpenGL vendor string: X.Org
OpenGL renderer string: AMD ARUBA (DRM 2.43.0 / 4.4.0-109-generic, LLVM 5.0.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 17.2.4
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
    GL_ARB_direct_state_access, GL_ARB_draw_buffers,
    GL_ARB_draw_indirect, GL_ARB_draw_instanced,
    GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect,
OpenGL version string: 3.0 Mesa 17.2.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.2.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

[Norbert (nrbrtx)]

Upgrading to HWE does not help.

[Timo Aaltonen (tjaalton)]

does it work on artful?

[Timo Aaltonen (tjaalton)]

also, you could try ppa:canonical-x/x-staging which has 17.2.8

[Timo Aaltonen (tjaalton)]

same bug on Debian, so probably doesn't work in artful either (nor bionic)

[Norbert (nrbrtx)]

Asked question on AskUbuntu (https://askubuntu.com/q/995093/66509).

Fixed by blacklisting `radeon`:

cat <<EOF | sudo tee /etc/modprobe.d/blacklist-radeon.conf
# blacklist radeon module to allow run at least Scilab after Mesa upgrade
blacklist radeon
EOF

sudo update-initramfs -k all -u

[Timo Aaltonen (tjaalton)]

that's a bad workaround if your gfx card is radeon..

[Timo Aaltonen (tjaalton)]

from https://wiki.scilab.org/Graphical%20issues%20with%20Scilab%205.X

try adding LIBGL_ALWAYS_SOFTWARE=1 in front of the scilab command

[Timo Aaltonen (tjaalton)]

this is actually a bug in jogl which seems to be doing stupid string checking to see if the driver is Mesa, and fails now that GL_RENDERER string doesn't have "Gallium" in it (wonder what happens with intel..)

[Timo Aaltonen (tjaalton)]

actually that LIBGL_ALWAYS_SOFTWARE=1 won't work either with current mesa

[Norbert (nrbrtx)]

I saw this jogl bug (https://jogamp.org/bugzilla/show_bug.cgi?id=1357) today.
Potentially other programs are affected too (https://www.google.ru/search?q=GL3bc+->+profileImpl+GL4bc+!!!+not+mapped+com.jogamp.opengl.GLProfile.computeProfileMap(GLProfile.java%3A2071)&oq=GL3bc+->+profileImpl+GL4bc+!!!+not+mapped+com.jogamp.opengl.GLProfile.computeProfileMap(GLProfile.java%3A2071)).

With newest Mesa Scilab works normally on i915 and nvidia_340 drivers.

[Timo Aaltonen (tjaalton)]

yes I had a look at the code, it's just radeon and swrast which are busted because they no longer have "Gallium" in the renderer string

[Norbert (nrbrtx)]

I do not know about Bionic, it maybe affected too.

I'll be watching this bug-report and re-enable `radeon` driver on my machine after fix.

Thank you for quick reaction, Timo!

[Timo Aaltonen (tjaalton)]

Bionic should be affected, but I've pushed a fixed libjogl2-java to Debian now and it'll get synced later. Next will be SRU uploads to artful and xenial.

[Timo Aaltonen (tjaalton)]

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

[Timo Aaltonen (tjaalton)]

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

[Timo Aaltonen (tjaalton)]

this is a bug in jogl, and apparently changing it to detect current Mesa makes it work again:

https://jogamp.org/bugzilla/show_bug.cgi?id=1357

[Sroland-vmware (sroland-vmware)]

(In reply to Timo Aaltonen from comment #12)
> this is a bug in jogl, and apparently changing it to detect current Mesa
> makes it work again:
>
> https://jogamp.org/bugzilla/show_bug.cgi?id=1357

They really should fix whatever it's doing wrong, rather than trying to avoid doing the wrong stuff when detecting a mesa-based driver... (I suspect it might be related to mesa not supporting compat profiles higher than 3.3 and jogl not handling this correctly, but really no idea. Doing hacks such as renderer detection might be ok as quick workarounds, but really the root cause should be fixed wherever it is.)

[Norbert (nrbrtx)]

My VESA solution is bad, I can't plot anything in Scilab even with LIBGL_ALWAYS_SOFTWARE=1.
SRU is really needed.

[Norbert (nrbrtx)]

Downgraded the following packages:

libegl1-mesa_11.2.0-1ubuntu2_amd64.deb
libgbm1_11.2.0-1ubuntu2_amd64.deb
libgl1-mesa-dri_11.2.0-1ubuntu2_amd64.deb
libgl1-mesa-dri_11.2.0-1ubuntu2_i386.deb
libgl1-mesa-glx_11.2.0-1ubuntu2_amd64.deb
libgl1-mesa-glx_11.2.0-1ubuntu2_i386.deb
libglapi-mesa_11.2.0-1ubuntu2_amd64.deb
libglapi-mesa_11.2.0-1ubuntu2_i386.deb
libgles2-mesa_11.2.0-1ubuntu2_amd64.deb
libosmesa6_11.2.0-1ubuntu2_amd64.deb
libosmesa6_11.2.0-1ubuntu2_i386.deb
libwayland-egl1-mesa_11.2.0-1ubuntu2_amd64.deb
mesa-va-drivers_11.2.0-1ubuntu2_amd64.deb
mesa-vdpau-drivers_11.2.0-1ubuntu2_amd64.deb

And pinned them:

cat <<EOF | sudo tee /etc/apt/preferences.d/pin-mesa
Package: libegl1-mesa:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libgbm1:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libgl1-mesa-dri:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libgl1-mesa-dri:i386
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libgl1-mesa-glx:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libgl1-mesa-glx:i386
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libglapi-mesa:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libglapi-mesa:i386
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libgles2-mesa:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libosmesa6:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libosmesa6:i386
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: libwayland-egl1-mesa
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: mesa-va-drivers
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

Package: mesa-vdpau-drivers
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337

EOF

It is a temporarily fix, which works for me.

[Norbert (nrbrtx)]

As we predicted, 17.10 (artful) is affected too - see this AskUbuntu question ( https://askubuntu.com/q/997160/66509 ).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tim Wescott (ww3ib0-tim)]

Any news for the newbie on how soon the fix will be applied?

I see the comment on downgrading and pinning a bunch of MESA packages -- but I don't know exactly how to do the downgrade, nor how to safely undo the pinning once it's no longer necessary. I don't want to muck up my machine.

[Łukasz Zemczak (sil2100)]

Hello Norbert, or anyone else affected,

Accepted libjogl2-java into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libjogl2-java/2.3.2+dfsg-5ubuntu0.17.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Łukasz Zemczak (sil2100)]

Hello Norbert, or anyone else affected,

Accepted libjogl2-java into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libjogl2-java/2.3.2+dfsg-4ubuntu0.16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package libjogl2-java - 2.3.2+dfsg-7

---------------
libjogl2-java (2.3.2+dfsg-7) unstable; urgency=medium

  * Reupload using correct .changes.

 -- Timo Aaltonen <email address hidden> Sat, 13 Jan 2018 09:17:50 +0200

[Johan Marius Wesselink (johanmw)]

I tested the proposed package on Lubuntu 17.10.

I tested some example programs they use either:
GLProfile glp = GLProfile.getDefault();
Or they use the GLCanvas default constructor.

Before this version all these examples emitted the typical error found in the previous version of jogl2. The new package RESOLVED this problem.

I noticed after some experimenting that replacing getDefault with get(GLProfile.GL2);
also solved the problem. Then I found this thread.

I build scilab from source using the git repository. This is the master and future 6.1 version it has the same problem. However, scilab 6 and higher have the jogl2 library prebuild and distributed as a thirdparty library. Removing this library doesn't work. The problem is that the scirender module and the gui modules depend on the old syntax. The Java path in the past was javax.media. In newer version of jogl2 this changed to com.jogamp. This means that besides removing the faulty library from scilab the modules scirender and gui need to be patched. I did just this in the last days. The git master branch version 6.1 build and works with the new jogl2 version. I noticed however one regression bug the cursor selection in the plot window work kind of inverted. This is an old bug which I have seen before.

So, yes this fixes the jogl2 bug. But, no likely not the scilab bug. Depends how you get scilab and which version probably.

[Johan Marius Wesselink (johanmw)]

Tested the scilab 5.5.2 for ubuntu which works great.
However, I did not test it before applying the jogl2 patch :-o.

Had a look at the source and it seems that the Ubuntu version is patched to use the
generic version of jogl2.

I would like to try and get this patch integrated in the Scilab source tree.
Probably a difficult and slow process.

[Timo Aaltonen (tjaalton)]

sounds like artful is verified, same for xenial would be great

[Launchpad Janitor (janitor)]

This bug was fixed in the package libjogl2-java - 2.3.2+dfsg-5ubuntu0.17.10.1

---------------
libjogl2-java (2.3.2+dfsg-5ubuntu0.17.10.1) artful; urgency=medium

  * fix-mesa-detection.diff: Fix detecting Mesa 17.2 ->. (LP: #1742894)

 -- Timo Aaltonen <email address hidden> Fri, 12 Jan 2018 21:23:23 +0200

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for libjogl2-java has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Dima (dima2017)]

Scilab works on xenial with the proposed update (libjogl2-java - 2.3.2+dfsg-4ubuntu0.16.04.1). Thank you

[Launchpad Janitor (janitor)]

This bug was fixed in the package libjogl2-java - 2.3.2+dfsg-4ubuntu0.16.04.1

---------------
libjogl2-java (2.3.2+dfsg-4ubuntu0.16.04.1) xenial; urgency=medium

  * fix-mesa-detection.diff: Fix detecting Mesa 17.2 ->. (LP: #1742894)

 -- Timo Aaltonen <email address hidden> Fri, 12 Jan 2018 21:23:23 +0200

[fabcap77 (fabcap77)]

I observed the same problem also with Scilab under Ubuntu 14.04, with the following version of libjogl2-java:

libjogl2-java/trusty,now 2.1.5-1ubuntu3 all [installed,automatic]
libjogl2-jni/trusty,now 2.1.5-1ubuntu3 amd64 [installed]

Is there a fix available for Ubuntu Trusty?

[Timothy Arceri (t-fridey)]

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

[Baker-dylan-c (baker-dylan-c)]

It sounds like this was actually a jogl bug, thus not our bug. Please re-open if I've misunderstood.