Here's some info from the user who reported the bug to us:

OS: openSUSE Linux 11.4 (version: Final, architecture: x86_64)

Software packages (among others, of course):
xorg-x11-driver-video 7.6-53.58.1 ("intel" driver in service)
Mesa 7.10.2-7.3.1
DirectFB-Mesa 1.4.5-14.2

Hardware devices (among others, of course):
Motherboard: Intel/Fujitsu Scenic W620 (handling display, network, PCI)
Framebuffer Device: Intel(r)915G/915GV/910GL Graphics Controller

...and, in case you wonder what LOCAL_GL_FRAMEBUFFER_BINDING is, it's just the same as GL_FRAMEBUFFER_BINDING, i forgot to edit that part. It's defined as 0x8CA6 which is the correct value.

(In reply to comment #0)
> This comes from https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c64
> 
> This seems to be a swrast bug, but I didn't find the bugzilla component for it.
> 
> I have code like this:
> 
> glBindFramebuffer(...some arguments...);
> glFramebufferRenderbuffer(...some arguments...);
> GLenum error = glGetError();
> if (error != GL_NO_ERROR)
>   exit(1);
> // no GL error at this point
> GLint framebuffer;
> glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &framebuffer);
> if (!framebuffer)
>   printf("WTF???\n");
> 
> The bug is that the WTF line is reached. Since glBindFramebuffer and
> glFramebufferRenderbuffer succeeded, for sure we have a FBO bound. So it's a
> bug that glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &result) returns 0.

Questions:

1. In the 'if (!framebuffer)' case, is there a GL error?

2. If you initialize framebuffer to, say, 0xDEADBEEF before calling glGetIntegerv, is it still 0 after?

3. Does this still happen with more recent bits?  Mesa 7.10.3 was released yesterday.

> Questions:

I don't know the answers to these questions. I'll check if the user who reported this is interested in further debugging this and I'll make him a build.

From your perspective, how important are swrast bugs? I've been told that swrast is getting replaced by other software renderers, "llvmpipe" and "softpipe".

Also, I forgot something in my pseudocode: we call glCheckFramebufferStatus right before the glGetIntegerv call. This shouldn't make any difference, but it could hit a bug whereby glCheckFramebufferStatus resets the framebuffer binding.

(In reply to comment #4)
> > Questions:
> 
> I don't know the answers to these questions. I'll check if the user who
> reported this is interested in further debugging this and I'll make him a
> build.
> 
> From your perspective, how important are swrast bugs? I've been told that
> swrast is getting replaced by other software renderers, "llvmpipe" and
> "softpipe".

Most of this code is used by all Mesa drivers.  From one of the posts (https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c65) in the Mozilla bug, it looked like it should use the i915 driver instead of swrast anyway.  An earlier post (https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c56) even suggests r600.  It's a little confusing.

I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could capture a trace for Mesa developers to replay...

Yes, sorry, there are probably a few confounding issues in the one bug report.

Refer to https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c3 for glxinfo in the configuration involved here.

(In reply to comment #4)
> > Questions:
> 
> I don't know the answers to these questions. I'll check if the user who
> reported this is interested in further debugging this and I'll make him a
> build.
[...]

Yes I am, even if my "usual" browser doesn't crash at closedown anymore: a crash is a crash, and if t isn't fixed it will happen again.

I just uploaded a new log, see https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c74

(In reply to comment #3)
[...]
> 3. Does this still happen with more recent bits?  Mesa 7.10.3 was released
> yesterday.

I don't know, I'm at the mercy of openSUSE Linux for all my software except Firefox and SeaMonkey (which I get from Mozilla), their extensions (which I get mostly from addons.mozilla.org) and Vim (which I compile from Bram Moolenaar's latest sources).

(In reply to comment #3)
> Questions:
> 
> 1. In the 'if (!framebuffer)' case, is there a GL error?
> 
> 2. If you initialize framebuffer to, say, 0xDEADBEEF before calling
> glGetIntegerv, is it still 0 after?

I made a build initializing as you suggest and logging the GetIntegerv call. Resulting log:
https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c74

Relevant part:

framebuffer info:
[gl:0x197d3f0] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000]
  default framebuffer. No FBO is currently bound.

That means that GetIntegerv did not generate any error (the [0x0000]) and really did set the result to 0 (did not just leave it uninitialized).

(In reply to comment #6)
> I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could
> capture a trace for Mesa developers to replay...

I heard about it but how easy is that for me to deploy in a custom debugging build for a user to run? Meanwhile, I have logs with a verbose GL debug mode that we have. While (as I mention above) it doesn't have some GL calls made from the debugging layer itself, the bug is known to exist already without the debugging layer, so that shouldn't matter. Relevant part of the log below. the gl:0x197d3f0 part is the pointer to the GLContext object, it means all these calls are on the same GL context (this is really checked). The > is before the GL call, the < is after. The [0x0000] is the GL error code, so that means GL_NO_ERROR. For some GL functions, the parameters values are printed. It's enough to reconstruct what we've been doing here: I've added comments.

/* Create and bind a texture, name=1 */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fGenTextures(GLsizei, GLuint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGenTextures(GLsizei, GLuint*) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fBindTexture(GLenum, GLuint)
parameters:
  target = 0x0de1
  texture = 1
[gl:0x197d3f0] < void mozilla::gl::GLContext::fBindTexture(GLenum, GLuint) [0x0000]

/* Set some texparameters */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fTexParameteri(GLenum, GLenum, GLint)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fTexParameteri(GLenum, GLenum, GLint) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fTexParameteri(GLenum, GLenum, GLint)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fTexParameteri(GLenum, GLenum, GLint) [0x0000]

/* Create and bind a framebuffer. Note that FramebufferTexture2D call below succeeds, meaning that we really have a non-default framebuffer bound. */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fGenFramebuffers(GLsizei, GLuint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGenFramebuffers(GLsizei, GLuint*) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fBindFramebuffer(GLenum, GLuint)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fBindFramebuffer(GLenum, GLuint) [0x0000]

/* Create a renderbuffer */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fGenRenderbuffers(GLsizei, GLuint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGenRenderbuffers(GLsizei, GLuint*) [0x0000]

/* Upload an image to our texture. If you're wondering about the 16x16 size, that's because this is a dummy GL context only used to get driver info to print in the about:support page */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fTexImage2D(GLenum, GLint, GLint, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*)
parameters:
  target = 0x0de1
  level = 0
  width = 16
 height = 16
  format = 0x1908
, type = 0x1401
[gl:0x197d3f0] < void mozilla::gl::GLContext::fTexImage2D(GLenum, GLint, GLint, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*) [0x0000]

/* Bind our renderbuffer and allocate it as a depth buffer
 * GL_DEPTH_COMPONENT24 == 0x81A6
 */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fBindRenderbuffer(GLenum, GLuint)
parameters:
  target = 0x8d41
  renderbuffer = 1
[gl:0x197d3f0] < void mozilla::gl::GLContext::fBindRenderbuffer(GLenum, GLuint) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fRenderbufferStorage(GLenum, GLenum, GLsizei, GLsizei)
parameters:
  target = 0x8d41
  internalFormat = 0x81a6
  width = 16
  height = 16
[gl:0x197d3f0] < void mozilla::gl::GLContext::fRenderbufferStorage(GLenum, GLenum, GLsizei, GLsizei) [0x0000]

/* Attach our texture to the color attachment point, and our renderbuffer to
 * the depth attachment point
 * GL_COLOR_ATTACHMENT0 == 0x8CE0
 * GL_DEPTH_ATTACHMENT == 0x8D00
 */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fFramebufferTexture2D(GLenum, GLenum, GLenum, GLuint, GLint)
parameters:
  attachmentPoint = 0x8ce0
  texture = 1
  level = 0
[gl:0x197d3f0] < void mozilla::gl::GLContext::fFramebufferTexture2D(GLenum, GLenum, GLenum, GLuint, GLint) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fFramebufferRenderbuffer(GLenum, GLenum, GLenum, GLuint)
parameters:
  attachmentPoint = 0x8d00
  renderbuffer = 1
[gl:0x197d3f0] < void mozilla::gl::GLContext::fFramebufferRenderbuffer(GLenum, GLenum, GLenum, GLuint) [0x0000]

/* Check FB status and FB binding */

[gl:0x197d3f0] > GLenum mozilla::gl::GLContext::fCheckFramebufferStatus(GLenum)
[gl:0x197d3f0] < GLenum mozilla::gl::GLContext::fCheckFramebufferStatus(GLenum) [0x0000]
framebuffer info:
[gl:0x197d3f0] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000]

/* Boom: getIntegerv(GL_FRAMEBUFFER_BINDING, &result) explicitly set the
 * result to 0, despite above FramebufferRenderbuffer call succeeding
 */

  default framebuffer. No FBO is currently bound.
WARNING: Error resizing offscreen framebuffer -- framebuffer not complete: file /builds/slave/try-lnx64-dbg/build/gfx/thebes/GLContext.cpp, line 877

How easy would it be for me to try swrast? I'm using Debian Testing, but with the NVIDIA driver.

(In reply to comment #10)
> (In reply to comment #6)
> > I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could
> > capture a trace for Mesa developers to replay...
> 
> I heard about it but how easy is that for me to deploy in a custom debugging
> build for a user to run?

It should only take 10 minutes to grab apitrace, compile it and try capturing a trace.  It would be super helpful to us.  And in the future, it would be the best way to report bugs.  The only problem at this point might be multi-context handling.

http://code.google.com/p/jrfonseca/downloads/detail?name=apitrace-20101109.zip

(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #6)
> > > I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could
> > > capture a trace for Mesa developers to replay...
> > 
> > I heard about it but how easy is that for me to deploy in a custom debugging
> > build for a user to run?
> 
> It should only take 10 minutes to grab apitrace, compile it and try capturing a
> trace.  It would be super helpful to us.  And in the future, it would be the
> best way to report bugs.  The only problem at this point might be multi-context
> handling.
> 
> http://code.google.com/p/jrfonseca/downloads/detail?name=apitrace-20101109.zip

This zip file contains old windows binaries.

But tracing is really simple. Just do:

  git clone https://github.com/apitrace/apitrace.git
  cmake .
  make
  LD_PRELOAD=$PWD/glxtrace.so /path/to/firefox

and firefox*.trace will be generated.

Between the call to glBindFramebuffer() and glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?  That would change the context's framebuffer binding.  We might have that wrong, actually...

(In reply to comment #14)
> Between the call to glBindFramebuffer() and
> glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?

As far as I can see, no, we don't call glXMakeCurrent between these two points.

> That
> would change the context's framebuffer binding.  We might have that wrong,
> actually...

Why would glXMakeCurrent change GL state?

Tony, if you have time, could you please try running firefox with apitrace as explained in comment 13?

Note: you'll need to install cmake and you'll need to cd to the apitrace directory you just cloned before running cmake.

Please use a debug build of Firefox for that, for example the latest build I made for you, as we need to see where that "WARNING: Error resizing offscreen framebuffer -- framebuffer not complete" was printed and it's only printed in debug builds. Please keep MOZ_X_SYNC=1 but no need for MOZ_GL_DEBUG_VERBOSE=1 as apitrace replaces that.

(In reply to comment #15)
> (In reply to comment #14)
> > Between the call to glBindFramebuffer() and
> > glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?
> 
> As far as I can see, no, we don't call glXMakeCurrent between these two points.

OK.


> > That
> > would change the context's framebuffer binding.  We might have that wrong,
> > actually...
> 
> Why would glXMakeCurrent change GL state?

glXMakeCurrent creates a binding between a rendering context and a surface for drawing.  The surface (an X Window or GLXPixmaps) is internally represented by an FBO.  Window system FBOs like that and user-created FBOs are pretty much the same with only minor differences in how they're handled.  In any case, the context has "current FBO" pointers that are set in glXMakeCurrent().  That's a potential state change.

The GL_ARB/EXT_framebuffer_object extensions say that calling glXMakeCurrent() should not change the current read/draw FBO bindings if the context is currently pointing at user-created FBOs.  I needed to check Mesa to be sure that we weren't inadvertently binding the X window FBO at in this situation.  It looks like we're doing the right thing.  I just wrote a new piglit test to verify this fact.

Anyway, I don't think this is the issue.  Perhaps you could sprinkle more glGetIntegerv(GL_FRAMEBUFFER_BINDING, &x) calls between the glBindFramebuffer() call and the failure point.

Created attachment 48001 [details]
firefox.bin.trace

Created attachment 48002 [details]
firefox-bin.1.trace

Created attachment 48003 [details]
minefield.log

It looks like firefox is trying to destroy the currently bound context:

$ tracedump firefox-bin.1.trace  | grep ctx
17 glXMakeCurrent(dpy = 0x62ea00, drawable = 125830043, ctx = 0x29b15e0) = True
173 glXMakeCurrent(dpy = 0x62ea00, drawable = 125830041, ctx = 0x29b4f20) = True
351 glXDestroyContext(dpy = 0x62ea00, ctx = 0x29b4f20)
warning: incomplete call glXMakeCurrent
354 glXMakeCurrent(dpy = 0x62ea00, drawable = 125830043, ctx = 0x29b15e0)

According to glXDestroyContext's documentation, the context destruction should be deferred until it's no longer current to any thread.

(In reply to comment #16)
> Tony, if you have time, could you please try running firefox with apitrace as
> explained in comment 13?
> 
> Note: you'll need to install cmake and you'll need to cd to the apitrace
> directory you just cloned before running cmake.
> 
> Please use a debug build of Firefox for that, for example the latest build I
> made for you, as we need to see where that "WARNING: Error resizing offscreen
> framebuffer -- framebuffer not complete" was printed and it's only printed in
> debug builds. Please keep MOZ_X_SYNC=1 but no need for MOZ_GL_DEBUG_VERBOSE=1
> as apitrace replaces that.

(In reply to comment #13)
[...]
>   git clone https://github.com/apitrace/apitrace.git
>   cmake .
>   make
>   LD_PRELOAD=$PWD/glxtrace.so /path/to/firefox
> 
> and firefox*.trace will be generated.

cmake 2.8.3-5.2 is already installed
git clone... cmake... make... done
LD_PRELOAD=$PWD/glxtrace.so MOZ_X_SYNC=1 ~/Minefield/firefox/firefox --sync -P virgin -no-remote 2>&1|tee ~/Minefield/minefield.log
...firefox opens
...look at a few tabs, they seem normal
...Ctrl+Q
...Breakpad comes up, a little comment, [ Quit Firefox ]
ls -l *.trace
-rw-r--r-- 1 root root 11131 Jun 15 16:53 firefox-bin.1.trace
-rw-r--r-- 1 root root  1179 Jun 15 16:50 firefox-bin.trace
ls -l ~/Minefield/minefield.log
-rw-r--r-- 1 root root 30450 Jun 15 16:53 minefield.log
ls -l ~/.mozilla/firefox/Crash\ Reports/submitted
...the oldest one is:
-rw-r--r-- 1 root root  50 Jun 15 16:53 bp-47314ac3-428f-4bab-af98-b88c12110615.txt
meaning that more info about the crash will be found at https://crash-stats.mozilla.com/report/index/47314ac3-428f-4bab-af98-b88c12110615

(In reply to comment #21)
> According to glXDestroyContext's documentation, the context destruction should
> be deferred until it's no longer current to any thread.

Oh, I didn't know that. Indeed we are calling glXDestroyContext with the GL context current on main thread. Build coming with this fixed.

(In reply to comment #17)
> Anyway, I don't think this is the issue.  Perhaps you could sprinkle more
> glGetIntegerv(GL_FRAMEBUFFER_BINDING, &x) calls between the glBindFramebuffer()
> call and the failure point.

Build coming with a glGetIntegerv(GL_FRAMEBUFFER_BINDING, &x) logged before and after every GL call.

(In reply to comment #23)
> (In reply to comment #21)
> > According to glXDestroyContext's documentation, the context destruction should
> > be deferred until it's no longer current to any thread.
> 
> Oh, I didn't know that. Indeed we are calling glXDestroyContext with the GL
> context current on main thread. Build coming with this fixed.

Sorry, I was ambiguous. It's the GL driver's responsibility to defer the destruction internally. See:

  http://www.opengl.org/sdk/docs/man/xhtml/glXDestroyContext.xml

I couldn't find a piglit test for this yet.

That said, it's probably easy to work around this on firefox, until Mesa handles this correctly.  Assuming this is indeed the problem.

New tryserver build: http://tbpl.mozilla.org/?tree=Try&rev=2a3c576f5adf
When the builds are done they will be available at:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-2a3c576f5adf

This build has the changes mentioned in comment 23: it releases the GL context before destroying it, it logs MakeCurrent call and it constantly logs the FBO binding. Please run like this:

MOZ_GL_DEBUG_VERBOSE=1 MOZ_X_SYNC=1 ./firefox -P -no-remote 2>&1 | tee logfile.txt

You can add -P -no-remote if you already have a Firefox session open. Please attach the logfile and report on whether this build still crashes on closedown.

(In reply to comment #24)
> Sorry, I was ambiguous. It's the GL driver's responsibility to defer the
> destruction internally. See:
> 
>   http://www.opengl.org/sdk/docs/man/xhtml/glXDestroyContext.xml
> 
> I couldn't find a piglit test for this yet.
> 
> That said, it's probably easy to work around this on firefox, until Mesa
> handles this correctly.  Assuming this is indeed the problem.

Oh, that's even more interesting to me. Our code was:

        glXDestroyContext(mDisplay, mContext);
        glXDestroyPixmap(mDisplay, mDrawable);

We had X errors from MakeCurrent() on closedown suggesting that the X drawable had been destroyed too early. Now it seems that it could just be that since the context was still current, its destruction was postponed, so by the time it actually happened, the drawable has already been destroyed. If that's the case, my latest build should not crash on closedown.

Created attachment 48014 [details]
minefield.log.bz2 (no crash at the end)

(In reply to comment #25)
> New tryserver build: http://tbpl.mozilla.org/?tree=Try&rev=2a3c576f5adf
> When the builds are done they will be available at:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-2a3c576f5adf
> 
> This build has the changes mentioned in comment 23: it releases the GL context
> before destroying it, it logs MakeCurrent call and it constantly logs the FBO
> binding. Please run like this:
> 
> MOZ_GL_DEBUG_VERBOSE=1 MOZ_X_SYNC=1 ./firefox -P -no-remote 2>&1 | tee
> logfile.txt

I used --sync -P virgin -no-remote because it was easier for me to get the command-line from bash history in a konsole tab dedicated to the present tests and (once a day) fetching the next round of nightlies.

> 
> You can add -P -no-remote if you already have a Firefox session open. Please
> attach the logfile and report on whether this build still crashes on closedown.

No crash on closedown.

(In reply to comment #27)
> Created an attachment (id=48014) [details]
> minefield.log.bz2 (no crash at the end)

Thanks a lot!

The log shows that glGetIntegerv(FRAMEBUFFER_BINDING, &result) always returns 0. Even right after glBindFramebuffer called with a value just returned by glGenFramebuffers. Even when a glFramebufferRenderbuffer call succeeds, which is incompatible with the FB binding being 0.

> No crash on closedown.

\o/ !!!

Also the log shows that glXMakeCurrent is not called between the two points in question.

Note that with the NVIDIA driver, nonzero FB bindings are correctly reported by this build.

(In reply to comment #28)
> (In reply to comment #27)
> > Created an attachment (id=48014) [details] [details]
> > minefield.log.bz2 (no crash at the end)
> 
> Thanks a lot!
> 
> The log shows that glGetIntegerv(FRAMEBUFFER_BINDING, &result) always returns
> 0. Even right after glBindFramebuffer called with a value just returned by
> glGenFramebuffers. Even when a glFramebufferRenderbuffer call succeeds, which
> is incompatible with the FB binding being 0.

I just hacked a piglit fbo test to query GL_FRAMEBUFFER_BINDING after glBindFramebuffer() and assert that the value returned matches the bind call.  It works fine here.  I don't know what's going on in your test.  Which version of Mesa are you using?

(In reply to comment #31)
> I just hacked a piglit fbo test to query GL_FRAMEBUFFER_BINDING after
> glBindFramebuffer() and assert that the value returned matches the bind call. 
> It works fine here.  I don't know what's going on in your test.  Which version
> of Mesa are you using?

See comment 1, Tony is using Mesa 7.10.2.

Anyway, since the crash is fixed, we don't have anymore a reason to blacklist. Firefox just recognizes at runtime when the bug occurs and fails the WebGL context creation.

(In reply to comment #32)
> (In reply to comment #31)
> > I just hacked a piglit fbo test to query GL_FRAMEBUFFER_BINDING after
> > glBindFramebuffer() and assert that the value returned matches the bind call. 
> > It works fine here.  I don't know what's going on in your test.  Which version
> > of Mesa are you using?
> 
> See comment 1, Tony is using Mesa 7.10.2.

and (see comment #8 /in fine/) it's the newest version I can use until or unless openSUSE decides to distribute an upgraded version. If necessary, a bug can be opened at bugzilla.novell.com if the Mesa 7.10.3 is found to fix a possible crash (let's say in firefox-aurora). IIUC the liaison officer between Mozilla and SuSE is Wolfgang Rosenauer. I don't know if he's registered at bugs.freedesktop.org.

FWIW, the Mozilla bug mentioned in comment #1 was VERIFIED FIXED 2011-06-17 in https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c88 (Firefox 7, then ported to Firefox 6). Some water has passed under the bridge since then. :-)

FWIW again, my current Mesa version is described as shown below. It's been years since I last experienced the bug.

linux-2iyu:~ # rpm -qi Mesa
Name        : Mesa
Version     : 17.0.5
Release     : 176.1
Architecture: x86_64
Install Date: Sun 10 Sep 2017 16:41:26 CEST
Group       : System/Libraries
Size        : 17362987
License     : MIT
Signature   : RSA/SHA256, Wed 06 Sep 2017 14:26:43 CEST, Key ID b88b2fd43dbdc284
Source RPM  : Mesa-17.0.5-176.1.src.rpm
Build Date  : Wed 06 Sep 2017 14:18:59 CEST
Build Host  : cloud126
Relocations : (not relocatable)
Packager    : http://bugs.opensuse.org
Vendor      : openSUSE
URL         : http://www.mesa3d.org
Summary     : System for rendering interactive 3-D graphics
Description :
Mesa is a 3-D graphics library with an API which is very similar to
that of OpenGL.* To the extent that Mesa utilizes the OpenGL command
syntax or state machine, it is being used with authorization from
Silicon Graphics, Inc.(SGI). However, the author does not possess an
OpenGL license from SGI, and makes no claim that Mesa is in any way a
compatible replacement for OpenGL or associated with SGI. Those who
want a licensed implementation of OpenGL should contact a licensed
vendor.

Please do not refer to the library as MesaGL (for legal reasons). It's
just Mesa or The Mesa 3-D graphics library.

* OpenGL is a trademark of Silicon Graphics Incorporated.
Distribution: openSUSE Leap 42.3

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/307.