Bug#879905: glee: source for GLee.c and GLee.h is missing
On Mon, 6 Nov 2017 02:08:44 +0100 Steve Cotton wrote: > On Fri, Oct 27, 2017 at 07:55:52AM +0200, Steve Cotton wrote: > > On Thu, 19 Oct 2017 22:47:00, Ximin Luo wrote: > > > These files are clearly not source code. But luckily it should > > > be possible to regenerate them from the git repo I mentioned: > > > > > > > [..] https://github.com/kallisti5/glee > > > > It seems that repo is also not the complete source, the build > > steps in CMakeLists.txt download specs for the GL extensions from > > http://www.opengl.org/registry/ > > It doesn't manage to download the specifications any more, which is > probably because the website has changed since 2011. OTOH, anything > that works with Debian's 2009 version of GLee can only be using > extensions that existed in 2009. > > AFAICS, what GLeeGen creates is a mix of: > > 1. An easy wrapper for checking if an extension is supported > 2. The DFSG-free files which are now packaged in khronos-api > 3. The specifications under Khronos' speccopyright (not DFSG-free) > > The speccopyright means that we can't make a DFSG version of GLee, but > it also seems that it might be easier to just fix the rdeps to not use > GLee at all. The wrapper for checking if extensions are supported > could be ported to use the khronos-api, if it's needed at all. > > Looking at the packages that use GLee: > > Fife: only a few extensions, all of them now in khronos-api. Would > need the wrapper function. > > FS-UAE: build-depends on glee-dev, but the changelog includes "use > GLEW instead of GLee", none of the binaries depend on libglee, and the > two #includes in the source are commented out. Bug #880944 logged. > > Out Of Order: transitive dependency via Sludge > > Pink Pony: build-depends on glee-dev, but doesn't #include GLee.h > anywhere. Builds and runs fine without it (bug #880941 logged for > dropping the dependency). > > Sludge: if a compile-time check finds OpenGL ES 2.0, the code assumes > that all of the extensions that it wants are already present, and > doesn't use GLee's wrapper. > > Unknown Horizons: transitive dependency via Fife > > Steve > > I ported sludge to use glew instead of glee, and it was the last rdep. glee can be removed now. Best, Tobias
Bug#879905: glee: source for GLee.c and GLee.h is missing
On Fri, Oct 27, 2017 at 07:55:52AM +0200, Steve Cotton wrote: > On Thu, 19 Oct 2017 22:47:00, Ximin Luo wrote: > > These files are clearly not source code. But luckily it should > > be possible to regenerate them from the git repo I mentioned: > > > > > [..] https://github.com/kallisti5/glee > > It seems that repo is also not the complete source, the build > steps in CMakeLists.txt download specs for the GL extensions from > http://www.opengl.org/registry/ It doesn't manage to download the specifications any more, which is probably because the website has changed since 2011. OTOH, anything that works with Debian's 2009 version of GLee can only be using extensions that existed in 2009. AFAICS, what GLeeGen creates is a mix of: 1. An easy wrapper for checking if an extension is supported 2. The DFSG-free files which are now packaged in khronos-api 3. The specifications under Khronos' speccopyright (not DFSG-free) The speccopyright means that we can't make a DFSG version of GLee, but it also seems that it might be easier to just fix the rdeps to not use GLee at all. The wrapper for checking if extensions are supported could be ported to use the khronos-api, if it's needed at all. Looking at the packages that use GLee: Fife: only a few extensions, all of them now in khronos-api. Would need the wrapper function. FS-UAE: build-depends on glee-dev, but the changelog includes "use GLEW instead of GLee", none of the binaries depend on libglee, and the two #includes in the source are commented out. Bug #880944 logged. Out Of Order: transitive dependency via Sludge Pink Pony: build-depends on glee-dev, but doesn't #include GLee.h anywhere. Builds and runs fine without it (bug #880941 logged for dropping the dependency). Sludge: if a compile-time check finds OpenGL ES 2.0, the code assumes that all of the extensions that it wants are already present, and doesn't use GLee's wrapper. Unknown Horizons: transitive dependency via Fife Steve
Bug#879905: glee: source for GLee.c and GLee.h is missing
Steve Cotton: > Source: glee > Severity: serious > Justification: missing source (GLeeGen), missing source (GL ext specs) > > GLee already has serious bug #879123, and the auto-removal email > for dependencies was sent this morning. Most of the discussion in > #879123 looks as if a .dsfg tarball would just need to remove the > configure file, I'm logging a new bug so that this doesn't get > missed: > > On Thu, 19 Oct 2017 22:47:00, Ximin Luo wrote: >> Unfortunately we have a bigger problem: >> >> -rwxrwxr-x 1,105,245 GLee.c >> -rwxrwxr-x 955,258 GLee.h >> >> * [This file was automatically generated by GLeeGen 7.0 >> >> These files are clearly not source code. But luckily it should >> be possible to regenerate them from the git repo I mentioned: >> >>> [..] https://github.com/kallisti5/glee > > It seems that repo is also not the complete source, the build > steps in CMakeLists.txt download specs for the GL extensions from > http://www.opengl.org/registry/ > > The Readme.txt mentions a graball.bat, which no longer exists, > but seems likely to have grabbed from the same place. > > Steve > Thanks for reporting yes. Looks like the previous discussion went on for almost the length of another ./configure file, without CCing me in the process, and ignored this much more serious issue. I'd also like to reiterate my earlier point: > To re-iterate my first point though, if in the future this issue crops up > again, you need to supply evidence that ./configure is "preferred source of > modification" because that contradicts all other experience of autotools > files. > A git history log of the author hand-editing the file *more times* than > regenerating the file from configure.ac would suffice. And likewise for other generated text code like this C source code here. I see some pedantry in the other bug report about "can modify". Obviously you "can modify" any file that exists on your computer, you can also modify ELF binaries in dirty binary hacks and "I've done this before" as well. (See /home/groups/reproducible/htdocs/patched-libs/libapt-inst.so.1.5.0.patched-xz on alioth). Source code is "*preferred*-form-of-modification", not "form-of-modification". If one says something like this: > I have worked with even more configure scripts and I also prefer modifying > something else. one already acknowledges that the "something else" is the source code, not the configure script. Agreed that bug reports should be filed to other packages if they have similar problems. The packages I am responsible for, do not have this issue. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#879905: glee: source for GLee.c and GLee.h is missing
Source: glee Severity: serious Justification: missing source (GLeeGen), missing source (GL ext specs) GLee already has serious bug #879123, and the auto-removal email for dependencies was sent this morning. Most of the discussion in #879123 looks as if a .dsfg tarball would just need to remove the configure file, I'm logging a new bug so that this doesn't get missed: On Thu, 19 Oct 2017 22:47:00, Ximin Luo wrote: > Unfortunately we have a bigger problem: > > - rwxrwxr-x 1,105,245 GLee.c > - rwxrwxr-x 955,258 GLee.h > > * [This file was automatically generated by GLeeGen 7.0 > > These files are clearly not source code. But luckily it should > be possible to regenerate them from the git repo I mentioned: > > > [..] https://github.com/kallisti5/glee It seems that repo is also not the complete source, the build steps in CMakeLists.txt download specs for the GL extensions from http://www.opengl.org/registry/ The Readme.txt mentions a graball.bat, which no longer exists, but seems likely to have grabbed from the same place. Steve
