Bug 966983
| Summary: | Unstable, unreleased glfw is packaged instead of a stable release | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin Preisler <mpreisle> | ||||
| Component: | glfw | Assignee: | Martin Preisler <mpreisle> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 22 | CC: | bioinfornatics, kevin, stimits | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1028665 (view as bug list) | Environment: | |||||
| Last Closed: | 2015-09-20 16:21:10 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Martin Preisler
2013-05-24 12:57:20 UTC
I agree glfw3 api change often. I provide glfw3 mainly because derelict need it. We could think a way to provide glfw 2.7 and 3 Please note that I am looking at Fedora 19, actual rpm: glfw-3.0-0.18.20130517git673d5b5.fc19.x86_64. It looks like the existing fedora version glfw3 package differs from the actual version 3 glfw (via glfw.org). Compilation errors imply that the existing header file also differs from the dynamic library, /usr/lib64/libglfw.so.3.0 Specifically, header from the RPM version 3 provides /usr/include/GL/glfw3.h, ...and within this, provides the following declaration: typedef void (* GLFWkeyfun)(GLFWwindow*,int,int); If the actual glfw3 source is downloaded from glfw.org for version 3.0.3: http://www.glfw.org/download.html http://sourceforge.net/projects/glfw/files/glfw/3.0.3/glfw-3.0.3.zip/download ...the glfw.org header glfw-3.0.3/include/GLFW/glfw3.h instead uses this declaration: typedef void (* GLFWkeyfun)(GLFWwindow*,int,int,int,int); This latter definition is supported as correct via the glfw.org documentation under the version 3 API: http://www.glfw.org/docs/latest/group__input.html#ga592dd1919f8a1dc7576b13cdd8b7b695 Note that official source for version 2.7.9 (prior API) has the exact definition of GLFWkeyfun used in the fedora rpm for version 3...part of the glfw3 package in the fedora rpm incorrectly mixes version 2 API. Compiler errors lead me to believe that fedora dynamic library /usr/lib64/libglfw.so.3.0, provided by glfw-3.0-0.18.20130517git673d5b5.fc19.x86_64, fails to match the /usr/include/GL/glfw3.h header (provided by the same RPM). Odds are high that the installed library follows version 3 API, causing mismatched declaration/implementation compile failure (I have not verified this difference for the actual libglfw.so.3.0, symbols are stripped). This software is important, and is replacing GLUT in many OpenGL applications. For myself, I am developing on both nVidia x86 and nVidia Tegra embedded, and the SDK has moved away from GLUT and specifically replaced it with glfw. nVidia comments here: https://developer.nvidia.com/content/introducing-new-opengl-sdk-samples This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This is still a problem in rawhide. Furthermore, the packager stopped updating the git snapshots as of October 2013. We need to get this fixed because glfw is a very popular OpenGL context creation library. Could we please have *ANY* stable release instead of the git snapshot? There is no way people can count on using an API that changes every other month. Dear, For me fedora should to provide glfw 3, two reason: - official glfw website promote version 3 see http://www.glfw.org/ - fedora claim to be first see https://fedoraproject.org/en/about-fedora#first I just push an update of glfw it become more and maore stable now. That is an open talk and i will much appreciating that many packager dicuss about this. *** Bug 1028665 has been marked as a duplicate of this bug. *** I do not consider this bug fixed. Please make sure you are *NOT* using git snapshots unless *ABSOLUTELY* necessary. You are packaging a library, people are relying on the API and ABI not breaking / changing. Upstream makes these promises for *RELEASES*, not for every single git commit. Your fedora-git repo says "Update to 3.1" even though you are (again) using a git snapshot from 10th March 2014. glfw 3.1 does not exist at this point. "becoming more and maore stable now" is wishful thinking. I think the best course of action is to revert to 3.0.4 - the latest stable glfw. Still a problem, are there any news? I am willing to fix this if you grant me access (requested commit access on pkgdb). This is blocking several packages, for example cegui-samples. Furthermore, I believe this is making life difficult for people using glfw-devel for their own OpenGL work on Fedora. http://fedoraproject.org/w/index.php?title=Updates_Policy This page clearly states: (Beta to Pre Release and Stable) Package maintainers MUST: Avoid Major version updates, ABI breakage or API changes if at all possible. This is repeatedly violated with this package. See the f18 branch, commits 51a3000719d68d1c422c97f9220121fd4b729bbb..874bd57d05889256b83ba9391a612213a1d1fcfd Release of F19 happened on 2013-07-02, yet there were numerous ABI breaks after that (without soname bumps!). > - fedora claim to be first see https://fedoraproject.org/en/about-fedora#first Yes but this definitely does not mean breaking API and ABI for everyone with every update. For a more recent example of reckless packaging, see the f20 branch. Fedora 20 was released on 2013-12-17 , yet there was a major API/ABI break on 2014-03-10. See commit 4dbdc018988191f9dc9b5ba05378217b570091d1 See update https://admin.fedoraproject.org/updates/FEDORA-2014-3763/glfw-3.1-0.30.20140310git5c23071.fc20 I know that we can't change the past but I would really like to get somewhere with this problem and start being responsible. In the current state nobody can use the glfw package except the packager. The packager is the only person capable of keeping up with their own breakage. Even as it is this is going to be a big mess to untangle because of upgradepath. In my opinion the best course of action is to bump epoch (yuck!) and package stable 3.0 in rawhide. But I will research this further as I am not sure. No real response from Jonathan, I have created a FESCo ticket related to this bug, see https://fedorahosted.org/fesco/ticket/1328 Created attachment 926750 [details]
Change proposed to the spec file
fesco agreed to give me commit access to glfw, they suggest to push stable upstream release to rawhide, as well as fedora stable branches.
Bumping Epoch is a big deal and can't be reverted. Therefore I am attaching the proposed change, asking any passers-by for informal review. I am leaving one week for comments. If no comments show up by 2014-08-21 I will commit this. The change is best explained by the changelog entry:
* Thu Aug 14 2014 Martin Preisler <mpreisle> - 1:3.0.4-1
- Downgraded to upstream latest stable release - 3.0.4
- Epoch bumped from 0 to 1 to ensure clean upgrade path
- Removed texlive-latex from BuildRequires, it is not used during build
(In reply to Martin Preisler from comment #11) > Created attachment 926750 [details] > Change proposed to the spec file > > fesco agreed to give me commit access to glfw, they suggest to push stable > upstream release to rawhide, as well as fedora stable branches. > > Bumping Epoch is a big deal and can't be reverted. Therefore I am attaching > the proposed change, asking any passers-by for informal review. I am leaving > one week for comments. If no comments show up by 2014-08-21 I will commit > this. The change is best explained by the changelog entry: > > * Thu Aug 14 2014 Martin Preisler <mpreisle> - 1:3.0.4-1 > - Downgraded to upstream latest stable release - 3.0.4 > - Epoch bumped from 0 to 1 to ensure clean upgrade path > - Removed texlive-latex from BuildRequires, it is not used during build glfw 3 is actually stable, and so is glfw 2. I've personally had to rebuild a version 3 non-fedora to get a working version on F19, as version 2 is too outdated, and the version 3 (for F19+) has been broken (improperly mixes API version 2 and 3 headers and libraries due to packaging, not due to API). We badly need glfw3 which works, and glfw2-compat for all maintained versions of Fedora. Martin: So, if we push the 3.0.4 version with Epoch back to 19/20/21... will that require coordination and rebuilding of dependent packages? If so, do we have a list? (In reply to D. Stimits from comment #12) > (In reply to Martin Preisler from comment #11) > glfw 3 is actually stable, and so is glfw 2. I've personally had to rebuild > a version 3 non-fedora to get a working version on F19, as version 2 is too > outdated, and the version 3 (for F19+) has been broken (improperly mixes API > version 2 and 3 headers and libraries due to packaging, not due to API). > > We badly need glfw3 which works, and glfw2-compat for all maintained > versions of Fedora. Yes, that's why I am trying to push glfw 3.0 stable into Fedora. Are you sure you haven't misunderstood the comment? Feel free to submit a package review request of glfw2-compat, I'll be glad to review. I will not attempt to package it myself until I get this mess untangled. (In reply to Kevin Fenzi from comment #13) > Martin: So, if we push the 3.0.4 version with Epoch back to 19/20/21... will > that require coordination and rebuilding of dependent packages? If so, do we > have a list? derelict-glfw depends on glfw. The packager is bioinfornatics and git snapshots are packaged instead of releases again. Upstream has made releases, see https://github.com/DerelictOrg/DerelictGLFW3/releases It also seems to me that the "derelict" package itself is a mash up of multiple upstream releases that don't happen in unison. It should be in separate packages with separate versions IMO. The package review happened in https://bugzilla.redhat.com/show_bug.cgi?id=766083. derelict-GLFW3 doesn't actually seem to depend on glfw (at least not at the rpm level). (In reply to Kevin Fenzi from comment #15) > derelict-GLFW3 doesn't actually seem to depend on glfw (at least not at the > rpm level). $ repoquery --whatrequires glfw derelict-glfw-0:3-20.20130626gite70c293.fc20.i686 derelict-glfw-0:3-20.20130626gite70c293.fc20.x86_64 derelict-glfw-0:3-26.201410303git9570453.fc20.i686 derelict-glfw-0:3-26.201410303git9570453.fc20.x86_64 derelict-glfw-devel-0:3-20.20130626gite70c293.fc20.i686 derelict-glfw-devel-0:3-20.20130626gite70c293.fc20.x86_64 derelict-glfw-devel-0:3-26.201410303git9570453.fc20.i686 derelict-glfw-devel-0:3-26.201410303git9570453.fc20.x86_64 glfw-devel-0:3.0-0.27.20130807git735bc2d.fc20.i686 glfw-devel-0:3.0-0.27.20130807git735bc2d.fc20.x86_64 glfw-devel-0:3.1-0.30.20140310git5c23071.fc20.i686 glfw-devel-0:3.1-0.30.20140310git5c23071.fc20.x86_64 Or is the situation different on rawhide? Yeah. % repoquery --whatrequires glfw glfw-devel-0:3.1-0.31.20140310git5c23071.fc21.i686 glfw-devel-0:3.1-0.31.20140310git5c23071.fc21.x86_64 I have looked into it and derelict-glfw3 should definitely depend on glfw even in rawhide. It looks to me like a packaging mistake. The reason most likely is that the bindings dlopen the shared object instead of linking to it. I have reported the issue in #1130960 derelict-glfw3 upstream is writing bindings for glfw 3.x.y, see https://github.com/DerelictOrg/DerelictGLFW3/blob/master/source/derelict/glfw3/glfw3.d Therefore it's very likely that the bindings will work with latest stable glfw 3.0.4. From what I see not even a rebuild of derelict should be necessary. I don't have much experience with D so I will have to look into it more before I can test it and say that for certain. OK, I have committed this and built it for Rawhide - http://koji.fedoraproject.org/koji/taskinfo?taskID=7442394 From my limited testing it works fine. I will submit an update for Fedora 21 soon (into updates-testing). There are no dependencies *right now* so it shouldn't cause any trouble and I think it's worth it to get a stable glfw into F21. I will push it to stable after Alpha is released. Considering everything I think it's worth to do it even after Alpha freeze. The F21 build - http://koji.fedoraproject.org/koji/taskinfo?taskID=7442417 Note that due to various slipage we have not yet frozen, so the f21 build should go out in the next days compose. ;) Ah, cool! That actually helps me right now :-) This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 |