Bug 966983 - Unstable, unreleased glfw is packaged instead of a stable release
Unstable, unreleased glfw is packaged instead of a stable release
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: glfw (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Preisler
Fedora Extras Quality Assurance
: Reopened
: 1028665 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-24 08:57 EDT by Martin Preisler
Modified: 2015-09-20 12:21 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1028665 (view as bug list)
Environment:
Last Closed: 2015-09-20 12:21:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Change proposed to the spec file (2.87 KB, patch)
2014-08-14 07:52 EDT, Martin Preisler
no flags Details | Diff

  None (edit)
Description Martin Preisler 2013-05-24 08:57:20 EDT
glfw has had no stable upstream release of the 3.x branch, yet glfw 3.0 unstable from git is packaged in Fedora 18. What is the rationale for that? Why are we packaging unstable git release when glfw 2.7.x works just fine?

There are API changes between the 2 major releases, so on top of everything, this questionable decision breaks stable released code of other projects depending on glfw.

If there really is solid rationale for bringing glfw 3 into Fedora, I suggest packaging it separately as glfw3. It is very likely that people will depend on glfw2 for quite a long time.

Installed Packages
Name        : glfw
Arch        : x86_64
Version     : 3.0
Release     : 0.7.20120812gita9ed5b1.fc18
Size        : 122 k
Repo        : installed
From repo   : fedora
Summary     : A cross-platform multimedia library
URL         : http://www.glfw.org/index.html
License     : zlib
Description : GLFW is a free, Open Source, multi-platform library for OpenGL
            : application development that provides a powerful API for handling
            : operating system specific tasks such as opening an OpenGL window,
            : reading keyboard, mouse, joystick and time input, creating
            : threads, and more.

Available Packages
Name        : glfw
Arch        : i686
Version     : 3.0
Release     : 0.7.20120812gita9ed5b1.fc18
Size        : 50 k
Repo        : fedora/18/x86_64
Summary     : A cross-platform multimedia library
URL         : http://www.glfw.org/index.html
License     : zlib
Description : GLFW is a free, Open Source, multi-platform library for OpenGL
            : application development that provides a powerful API for handling
            : operating system specific tasks such as opening an OpenGL window,
            : reading keyboard, mouse, joystick and time input, creating
            : threads, and more.
Comment 1 MERCIER Jonathan 2013-06-26 17:12:12 EDT
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
Comment 2 D. Stimits 2013-11-06 16:51:57 EST
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
Comment 3 Fedora End Of Life 2013-12-21 08:42:14 EST
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.
Comment 4 Martin Preisler 2014-01-27 08:49:53 EST
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.
Comment 5 MERCIER Jonathan 2014-03-10 17:12:46 EDT
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.
Comment 6 MERCIER Jonathan 2014-03-10 17:22:25 EDT
*** Bug 1028665 has been marked as a duplicate of this bug. ***
Comment 7 Martin Preisler 2014-03-31 07:37:33 EDT
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.
Comment 8 Martin Preisler 2014-07-03 10:08:23 EDT
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.
Comment 9 Martin Preisler 2014-07-07 11:24:25 EDT
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.
Comment 10 Martin Preisler 2014-07-30 06:05:42 EDT
No real response from Jonathan, I have created a FESCo ticket related to this bug, see https://fedorahosted.org/fesco/ticket/1328
Comment 11 Martin Preisler 2014-08-14 07:52:55 EDT
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@redhat.com> - 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
Comment 12 D. Stimits 2014-08-14 11:45:01 EDT
(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@redhat.com> - 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.
Comment 13 Kevin Fenzi 2014-08-14 11:48:50 EDT
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?
Comment 14 Martin Preisler 2014-08-14 14:40:30 EDT
(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.
Comment 15 Kevin Fenzi 2014-08-14 17:44:24 EDT
derelict-GLFW3 doesn't actually seem to depend on glfw (at least not at the rpm level).
Comment 16 Martin Preisler 2014-08-15 07:22:00 EDT
(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?
Comment 17 Kevin Fenzi 2014-08-15 11:30:31 EDT
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
Comment 18 Martin Preisler 2014-08-18 05:46:07 EDT
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.
Comment 19 Martin Preisler 2014-08-23 09:58:37 EDT
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
Comment 20 Kevin Fenzi 2014-08-23 10:39:27 EDT
Note that due to various slipage we have not yet frozen, so the f21 build should go out in the next days compose. ;)
Comment 21 Martin Preisler 2014-08-23 15:05:46 EDT
Ah, cool! That actually helps me right now :-)
Comment 22 Jaroslav Reznik 2015-03-03 11:53:15 EST
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

Note You need to log in before you can comment on or make changes to this bug.