Spec URL: http://mnowak.fedorapeople.org/fltk2/fltk2.spec SRPM URL: http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.1.r6525.fc10.src.rpm Description: FLTK is a cross-platform C++ GUI toolkit for UNIX®/Linux® (X11), Microsoft® Windows®, and MacOS® X. FLTK provides modern GUI functionality without the bloat and supports 3D graphics via OpenGL® and its built-in GLUT emulation. FLTK is designed to be small and modular enough to be statically linked, but works fine as a shared library.
Known problems http://fltk.org/str.php?L2109 W: no-soname /usr/lib/libfltk2* -- provide SONAME for FLTK2 libs http://fltk.org/str.php?L2111 W: shared-lib-calls-exit /usr/lib/libfltk2.so.2.0 and perhaps http://fltk.org/str.php?L2110 E: no-ldconfig-symlink /usr/lib/libfltk2*
That looks like the SONAME problem :( fltk2-fluid-2.0.x-0.1.r6525.fc10.i386 from /home/newman/rpmbuild/RPMS/i386/fltk2-fluid-2.0.x-0.1.r6525.fc10.i386.rpm has depsolving problems --> Missing Dependency: libfltk2.so is needed by package fltk2-fluid-2.0.x-0.1.r6525.fc10.i386 (/home/newman/rpmbuild/RPMS/i386/fltk2-fluid-2.0.x-0.1.r6525.fc10.i386.rpm) fltk2-fluid-2.0.x-0.1.r6525.fc10.i386 from /home/newman/rpmbuild/RPMS/i386/fltk2-fluid-2.0.x-0.1.r6525.fc10.i386.rpm has depsolving problems --> Missing Dependency: libfltk2_images.so is needed by package fltk2-fluid-2.0.x-0.1.r6525.fc10.i386 (/home/newman/rpmbuild/RPMS/i386/fltk2-fluid-2.0.x-0.1.r6525.fc10.i386.rpm) Error: Missing Dependency: libfltk2.so is needed by package fltk2-fluid-2.0.x-0.1.r6525.fc10.i386 (/home/newman/rpmbuild/RPMS/i386/fltk2-fluid-2.0.x-0.1.r6525.fc10.i386.rpm) Error: Missing Dependency: libfltk2_images.so is needed by package fltk2-fluid-2.0.x-0.1.r6525.fc10.i386 (/home/newman/rpmbuild/RPMS/i386/fltk2-fluid-2.0.x-0.1.r6525.fc10.i386.rpm)
Is there any explanation of why the existing fltk package can't just be updated?
ahem, yes, this looks pretty familiar alright.
ok, double checked, hopefully these fltk v1 and fltk2 can be installed in parallel.
(In reply to comment #3) > Is there any explanation of why the existing fltk package can't just be > updated? * FLTK2 - is unstable, fast moving target - long way to stabilization - come concerns on its future, because of FLTK1.3 line now having some FLTK2 features and is considered being merge of FLTK1+2 * FLTK1 - only bug-fixes - stable API Upgrading FLTK to version 2 means breakage of API/ABI and also regressions: """ However, the momentum of the FLTK-1.1.x development meant that there are many bug-fixes in 1.1.x that are not available in 2.0. """ see: http://fltk.org/articles.php?L825+I0+TFAQ+P1+Q
Well, given that, surely you anticipated the followup question: If there's concern for its future, and it's that unstable and buggy, why do we want it in Fedora in the first place?
(In reply to comment #7) > If there's concern for its future, and it's that unstable and buggy, why do we > want it in Fedora in the first place? There's a concern from my POV on FLTK2's *short*-term future w.r.t. its API/ABI stability, because it's released thru snapshots only but that's something we don't care much, OpenSSL used to break ABI every its second release. Rapidly changing library might be a problem for Fedora in case we have a lot of FLTK2-dependent apps, which we don't have; Dillo2 should be the first and most demanded one. From my experience with Dillo2, FLTK2 behaves quite nice, I wouldn't say it's unstable w.r.t core library (on API/ABI I have elaborated already) & buggy -- it's supported upstream (read its "FLTK 2.0.x Weekly Snapshot" reports).
Just skimming over the spec file: * The guidelines want you to choose either %buildroot or $RPM_BUILD_ROOT, not both. * Use "install -p ..." especially when installing files yourself. * Unowned directories alarm in -devel package! It can easily be seen that the following %files entries are missing: %dir %{_includedir}/%{project_name} %dir %{_includedir}/%{project_name}/compat %dir %{_includedir}/%{project_name}/compat/FL > %package doc > Summary: Doxygen documentation for FLTK2 > Group: Documentation > Requires: %{name} = %{version}-%{release} Why that? > BuildRoot: doxygen Uh? A typo, most likely. Make that BuildRequires: doxygen
(In reply to comment #9) > * The guidelines want you to choose either %buildroot or $RPM_BUILD_ROOT, not > both. OK. Will be fixed. > * Use "install -p ..." especially when installing files yourself. It's only in commented lines, will be removed completely in new revision. > * Unowned directories alarm in -devel package! It can easily be seen that the > following %files entries are missing: Will fix. > > %package doc > > Summary: Doxygen documentation for FLTK2 > > Group: Documentation > > Requires: %{name} = %{version}-%{release} > > Why that? Not sure what you mean. The whole sub-package seems to you useless, or you're pointing to the 'Require:' field? To the first point: it's 2.2 MB more data, which are not directly useful. To the second one: sure it can be avoided, no problem here. > > BuildRoot: doxygen > > Uh? A typo, most likely. Make that BuildRequires: doxygen Typo.
http://mnowak.fedorapeople.org/fltk2/fltk2.spec http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.2.r6525.fc10.src.rpm -- * Wed Jan 14 2009 Michal Nowak <mnowak> - 2.0.x-0.2.r6525 - use $RPM_BUILD_ROOT instead of %%{buildroot} - added library header files directories to %%files section - fixed bad field in -doc sub-package to contain BR field
> Not sure what you mean. The whole sub-package seems to you > useless, or you're pointing to the 'Require:' field? The latter. Why does a plain -doc package require the main library pkg? If it's just packager's personal preference, I would understand if it required the -devel package instead. Else it shouldn't require the library pkg as it doesn't need it in any way.
* Mon Mar 9 2009 Michal Nowak <mnowak> - 2.0.x-0.3.r6525 - dumped doc's dependency on main pkg -- http://mnowak.fedorapeople.org/fltk2/fltk2.spec http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.3.r6525.fc10.src.rpm
* Mon Mar 16 2009 Michal Nowak <mnowak> - 2.0.x-0.4.r6671 - snapshot 6671 -- http://mnowak.fedorapeople.org/fltk2/fltk2.spec http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.4.r6671.fc10.src.rpm
* Tue Mar 17 2009 Michal Nowak <mnowak> - 2.0.x-0.5.r6671 - soname patch http://mnowak.fedorapeople.org/fltk2/fltk2.spec http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.5.r6671.fc10.src.rpm -- Fixed problem with missing soname but still there's some problem with symlinks I am no able to figure out. Anyone? newman BUILD $ rpmlint ../SPECS/fltk2.spec /home/newman/rpmbuild/SRPMS/fltk2-2.0.x-0.5.r6671.fc10.src.rpm /home/newman/rpmbuild/RPMS/i386/fltk2-2.0.x-0.5.r6671.fc10.i386.rpm /home/newman/rpmbuild/RPMS/i386/fltk2-devel-2.0.x-0.5.r6671.fc10.i386.rpm /home/newman/rpmbuild/RPMS/i386/fltk2-fluid-2.0.x-0.5.r6671.fc10.i386.rpm /home/newman/rpmbuild/RPMS/i386/fltk2-doc-2.0.x-0.5.r6671.fc10.i386.rpm /home/newman/rpmbuild/RPMS/i386/fltk2-debuginfo-2.0.x-0.5.r6671.fc10.i386.rpm fltk2.i386: E: no-ldconfig-symlink /usr/lib/libfltk2_images.so.2.0 fltk2.i386: E: no-ldconfig-symlink /usr/lib/libfltk2_glut.so.2.0 fltk2.i386: E: no-ldconfig-symlink /usr/lib/libfltk2_gl.so.2.0 fltk2.i386: E: no-ldconfig-symlink /usr/lib/libfltk2.so.2.0 fltk2.i386: W: shared-lib-calls-exit /usr/lib/libfltk2.so.2.0 exit 6 packages and 1 specfiles checked; 4 errors, 1 warnings.
The SONAMEs you set are bad. Example: SONAME Library soname: [../lib/libfltk2.so.2.0] Must not contain any path and not the trailing minor version either: libfltk2.so.2 [...] Please delete .SILENT from the top-level "makeincludes" file fragment, so the build output becomes verbose.
Thanks for tips Michael, I finally figured it all out: %changelog * Wed Jun 17 2009 Michal Nowak <mnowak> - 2.0.x-0.11.r6786 - disabling the workaroung for fedora < 11 * Wed Jun 17 2009 Michal Nowak <mnowak> - 2.0.x-0.10.r6786 - rpath killer - ® sign killer * Wed Jun 17 2009 Michal Nowak <mnowak> - 2.0.x-0.9.r6786 - setting correct soname * Wed Jun 17 2009 Michal Nowak <mnowak> - 2.0.x-0.8.r6786 - rebuild * Wed Jun 17 2009 Michal Nowak <mnowak> - 2.0.x-0.7.r6786 - fltk-2.0.x-r6786-scandir-workaround.patch to workaroung glibc-2.10 non standard behavior * Tue Jun 16 2009 Michal Nowak <mnowak> - 2.0.x-0.6.r6786 - r6786 - fltk-2.0.x-r6671-non-silence-build.patch newman@dhcp-lab-124 SPECS $ rpmlint /home/newman/rpmbuild/SRPMS/fltk2-2.0.x-0.11.r6786.fc11.src.rpm /home/newman/rpmbuild/RPMS/x86_64/fltk2-2.0.x-0.11.r6786.fc11.x86_64.rpm /home/newman/rpmbuild/RPMS/x86_64/fltk2-devel-2.0.x-0.11.r6786.fc11.x86_64.rpm /home/newman/rpmbuild/RPMS/x86_64/fltk2-fluid-2.0.x-0.11.r6786.fc11.x86_64.rpm /home/newman/rpmbuild/RPMS/x86_64/fltk2-doc-2.0.x-0.11.r6786.fc11.x86_64.rpm /home/newman/rpmbuild/RPMS/x86_64/fltk2-debuginfo-2.0.x-0.11.r6786.fc11.x86_64.rpm fltk2.x86_64: W: shared-lib-calls-exit /usr/lib64/libfltk2.so.2.0 exit.5 6 packages and 0 specfiles checked; 0 errors, 1 warnings. http://mnowak.fedorapeople.org/fltk2/fltk2.spec http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.11.r6786.fc11.src.rpm dillo-2.1 (pre-release) compilation & run tested against this version.
http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.12.r6793.fc11.src.rpm
http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.13.r6829.fc11.src.rpm
Updated to r6834: http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.14.r6834.fc11.src.rpm
The upstream status of the patches is missing: https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment
Thanks for the heads up. Fixed and updated to newest snapshot. http://mnowak.fedorapeople.org/fltk2/fltk2-2.0.x-0.17.r6858.fc12.src.rpm
Just FYI, outside of the rpmlint complaints posted in comment 17, there are also a very large number of undefined-non-weak-symbol complaints along with a few unused-direct-shlib-dependency warnings. There are a couple hundred complaints in total; to see them, install the package and run "rpmlint fltk2". It is possible that these aren't problematic; the undefined-non-weak-symbol complaints indicate that you can't make use of the library without also linking to the libraries which provide those symbols. Bad practise and good to fix if possible, but probably not a serious issue. The unused-direct-shlib-dependency complaints indicate that the libraries in question are linked against various libraries but don't actually call into them. Again, this may not be problematic; if there aren't any extra dependencies caused by this and the libraries are going to be in memory anyway. You should check those and verify that there aren't any actual problems indicated. The versioning of this package doesn't seem to follow Fedora guidelines, although I can't really tell. What do you expect the actual release version to be? If it's 2.0.0 or something, then note that you'll have to use epoch to keep ordering. because '0' (or indeed any digit) is less than 'x'.
Jason, thanks for bringing it once again to my attention. fltk2 is broken in several POVs. It's not released software (but apps are using it), it's not progressing much (just humble changes in SVN tree), fltk2 as a shared lib is not supported (static is), so, that's why there are so much so-related problems. From dillo m-l I know that fltk2 is dying in favor of fltk1.3, which should have release "soon" (whatever it meens...) and then dillo might move to this fltk implementation. I have no time & no interest in fixing what's broken by design. If anyone needs fltk2 for dillo, feel free to use this RPMs, they "works" but I won't update to newer snapshots anymore.
I would suggest visioning the package 2.0.0. That would solve at least that problem. Another solution could be to include fltk2 with dillo2 as this is the main fltk2 application.
(In reply to comment #25) > I would suggest visioning the package 2.0.0. That would solve at least that > problem. That makes sence. > Another solution could be to include fltk2 with dillo2 as this is the > main fltk2 application. Could be main but I believe there are others. Bundling Dillo2 with FLTK2(svn) would be no-go situation (but that's question for dillo maintainer). Personally I lost hope in FLTK devs to ever release FLTK2 (and I somewhat doubt about even FLTK1.3 release).