Bug 1160251

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