Hi Niko,
> > $ dizzy
> > GPU features: [x] GLSL [x] FBOs
> > Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT, used at
> > /usr/share/perl5/Dizzy/TextureGenerator.pm line 101.
> >
> > I tested the same qemu VM with stretch and there it was working.
> > After some tests I found it stopped working when
> > libopengl-perl in version 0.7000+dfsg-1
> > entered testing in 2017-08-12.
> > But I am uncertain if the fault is
> > in package dizzy or libopengl-perl.
>
> I looked at this a bit, and I assume it regressed with
>
>
> https://sourceforge.net/p/pogl/code/ci/ad3508bed030b856a8c36c4900727bbd838212dd/
>
> If I read this correctly, the constants used to be provided
> unconditionally, but are now excluded if things like
> NO_GL_EXT_framebuffer_object are defined.
>
> Now, our Debian packaging has
>
>
> https://sources.debian.org/src/libopengl-perl/0.7000+dfsg-1/debian/patches/add-gl_exclude.h/
>
> which "adds back" these exclusions, apparently for xvfb compatibility and
> making
> the build result independent of the build machine hardware.
>
> My tentative conclusion is that the exclusions we patch in now affect things
> that they didn't earlier, and that we need to fix this on the libopengl-perl
> side somehow. So reassigning.
>
> Copying Florian, who added the patch back in 2012. Any interest in looking
> at this? :)
well thanks for prodding me, I wouldn't have thought I ever touched
anything OpenGL and probably hadn't read your email otherwise.
When I started working on libopengl-perl in 2012, the update to upstream
version 0.66 was unfinished and the build would fail with an error about
a lacking gl_exclude.h; my idea was to just patch in the gl_exclude.h
that used to be part of the upstream tarball, without really
investigating its content, on the assumption that it would keep the
feature set unchanged.
Upstream's idea about gl_exclude.h is to determine the available GPU
features through probing, for which a 'glversion' binary is compiled and
run from Makefile.PL, preferably "under an X11 shell". My understanding
is that this proved impossible to reconcile with the way we build
packages on buildds, as they don't have GPUs and xvfb doesn't emulate
the relevant features either. Hence debian/patches/disable-glversion
disabled the probing, so when upstream stopped shipping gl_exclude.h,
there was nothing that created it.
I notice that the unpatched Makefile.PL has an option
dist=NO_EXCLUSIONS Build with no OpenGL Extension exclusions
which will write a gl_exclude.h containing nothing but comments. This
seems aimed at Windows builds, but if I modify
debian/patches/add-gl_exclude.h so that it results in the same basically
empty header file, I can build a package that will run test.pl and
display the 3D graphics apparently without issues.
Do we need to exclude any OpenGL Extensions, at all?
I'd tend to think that there are so many different machines out there
that we would have heard from our users if gl_exclude.h really needed to
be tailored to the individual machine. Then again why would upstream
bother to exclude anything in the first place?
It's probably a bit late in the release cycle to "just find out" by
uploading a -2 with that modified patch.
Hmmm...
Florian
