Latest upstream release: 1.3.3 Current version/release in Fedora Rawhide: 1.3.2-7.fc22 URL: http://www.fltk.org/software.php Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition.
Rex, let me know if you would like help maintaining this package. I have several packages both current and future that use FLTK. I have a local build of 1.3.3 but need to make sure everything is OK. If the patch failed to apply I temporarily disabled it, if it came up as already applied I assumed it was upstream and removed it. I also tried doing a cmake build. The main components build fine and install properly with a little patching of the cmake config but it's still a bit rough around the edges. No documentation build, install of desktop files or icons, etc.
Help is welcome, sure. Yeah, the hard part here is forward maintenance of the patches we carry. Most of those are waiting to get included upstream in their bug tracker, so I'm not sure what the holdup there is. :-/ As far as cmake goes, the support there isn't good enough to replace automake and friends yet (not sure it ever will be).
working on it...
I'm pretty much already done if you want to wait for me. I've got the package building nicely, most of the patches are not needed anymore and now I'm doing a mock build of 1.3.2 and 1.3.3 to run abi-compliance-checker against to make sure it's ABI compatible.
Heh, here I am crabbing about patches not getting accepted upstream, and turns out they all were. Yay! Thanks! you have my blessing to commit when you're ready.
Created attachment 954211 [details] abi-compliance-checker report from 1.3.2 to 1.3.3 The tool isn't foolproof but it looks like it may not be a drop in replacement. I would assume a patch level increment SHOULD be ABI compatible though...
I suspect at least some of those changes were due to the preliminary feature patches we carried (now upstreamed, but not fully compatible) The list of items depending on fltk isn't *that* big, I'd be happy to help with rebuilding all of them. Given the ease of rebuilding stuff ^^, I'm largely indifferent to considerations of bumping sonames (I'm ok either way). Any opinions?
I really need to get around to requesting to be a proven packager but for now I have requested ACLs in pkgdb. And if we do need to do a rebuild here is a non-authoritative list from f20: $ repoquery --resolve --qf=%{name} --whatrequires "libfltk.so.1.3()(64bit)" | uniq | sort alsamixergui alsa-tools cinepaint-libs coda-vcodacon csound-fltk csound-gui csound-virtual-keyboard dillo ed2k_hash-gui edelib eureka fgrun flamp fldigi FlightGear fllog flmsg flnet flpsed flrig fltk-devel fltk-fluid giada gipfel gmsh gmsh-libs gmsh-mpich gmsh-mpich-libs gmsh-openmpi gmsh-openmpi-libs htmldoc lmms mathgl mathgl-examples mathgl-mpich mathgl-openmpi minicomputer mup non-session-manager nut-nutrition octave OpenEXR_Viewers OpenEXR_Viewers-nonfree OpenSceneGraph-examples-fltk oyranos paulstretch plus4emu posterazor rakarrack rasterview seaview stage stage-playerplugin SteGUI tigervnc VirtualGL yoshimi zynaddsubfx
I posted to the fltkdev group about the ABI compatibility, we'll see what they say. Also, would this be a good time to request an EPEL7 branch?
Re: epel7 yes, sounds like a good idea
Ok, upstreams response did not give me a warm and fuzzy so we should probably proceed with rebuilds of dependant packages. I figure we can do rawhide first so when I request epel7 it will inherit 1.3.3 from the beginning.
Ok, if you're up for the rebuilds I'm ready to build fltk.
Where are we on this? With all of the gcc 5 C++11 ABI issues floating around I was going to rebuild fltk when I noticed that the 1.3.3 version checked in hasn't been built yet. Shall we kick this off?
Oh sheesh, I totally forgot about this bug, and updated it myself recently, %changelog * Fri Feb 13 2015 Rex Dieter <rdieter> 1.3.3-1 - 1.3.3 Sorry Richard, I think you'd already prepped 1.3.3 for packaging, can you please review what I did and make sure I didn't botch things? Hrm, apparently the build didn't succeed, I'm looking for logs now.
rdieter's fltk-1.3.3-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=612640
I'll work on rebuilding dependent stuff for f23 first, then will turn eye on f22.
I'll take care of fldigi. I think there's a bug (nothing major) and I'm working with upstream to fix.
Well, if there was any doubt that dependent packages need to be rebuilt: error: /usr/lib/octave/3.8.2/oct/i686-redhat-linux-gnu/PKG_ADD: /usr/lib/octave/3.8.2/oct/i686-redhat-linux-gnu/__init_fltk__.oct: failed to load: /lib/libfltk_gl.so.1.3: undefined symbol: _ZN18Fl_XFont_On_Demand5valueEv I'm rebuilding octave now.
Thanks for the confirmation, rebasing to f22 (and continuing to work my way through the list of depdendencies on master/f23 first)
Looking into OpenSceneGraph FTBFS, /usr/lib/gcc/i686-redhat-linux/5.0.0/../../../libfltk_gl.so: undefined reference to `Fl_XFont_On_Demand::value()' collect2: error: ld returned 1 exit status Some references: http://comments.gmane.org/gmane.comp.lib.fltk.general/27466 https://bugzilla.opensuse.org/show_bug.cgi?id=915435 Looks like that symbol isn't exported properly
(same problem as with octave before, sorry for not noticing that)
upstream issue tracking, http://www.fltk.org/str.php?L3156
hopefully this takes care of it %changelog * Wed Feb 18 2015 Rex Dieter <rdieter> 1.3.3-2 - pull in upstream fixes for undefined symbols
rdieter's fltk-1.3.3-2.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=612869
rdieter's fltk-1.3.3-2.fc22 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=612991