Can't be fixed until the mock problem with EPEL is fixed.

Moving to gcc43errors per
http://fedoraproject.org/wiki/BugZappers/GCC43RebuildFailures

Errors in x8_64 build.log:
../3rdparty/liborigin/OPJFile.cpp:47: error: 'strcasecmp' was not declared in
this scope
../3rdparty/liborigin/OPJFile.cpp: In member function 'void
OPJFile::convertSpreadToExcel(int)':
../3rdparty/liborigin/OPJFile.cpp:182: warning: comparison between signed and
unsigned integer expressions
../3rdparty/liborigin/OPJFile.cpp:194: warning: comparison between signed and
unsigned integer expressions
../3rdparty/liborigin/OPJFile.cpp: In member function 'int OPJFile::Parse()':
../3rdparty/liborigin/OPJFile.cpp:229: warning: ignoring return value of 'size_t
fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result
../3rdparty/liborigin/OPJFile.cpp: In member function 'int
OPJFile::ParseFormatOld()':
../3rdparty/liborigin/OPJFile.cpp:351: error: 'strtok' was not declared in this
scope
../3rdparty/liborigin/OPJFile.cpp:354: error: 'strcat' was not declared in this
scope
../3rdparty/liborigin/OPJFile.cpp:356: error: 'strcpy' was not declared in this
scope

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

*** Bug 440844 has been marked as a duplicate of this bug. ***

Missing #include <cstring> (and possibly using directives too).

This package has Failed to Build From Source for many months.  Per
http://fedoraproject.org/wiki/FTBFS, this package is now proposed for
removal from the distribution.  Please address this FTBFS bug
immediately, or this package will be removed from the distribution
within the next few weeks.

Thank you for your continued contributions to Fedora, and your
commitment to ensuring Fedora packages remain buildable from source
code.

Frank, this has been broken since at least February 2008.  I took a look at it tonight, but version 0.9.7 (the latest) expects to find qwt and QwtPlot3D sources extracted into its build environment.  Seeing this, I gave up.

The dos2unix commands really need to use find, as it's dying otherwise when it hits a directory.

@@ -54,13 +54,13 @@
 #fix default path for the Plug-Ins
 sed -i "s\/usr/lib/qtiplot/plugins\%{_libdir}/%{name}\g" qtiplot/src/ApplicationWindow.cpp
 #fix source files for debug package
-dos2unix qtiplot/src/*
+find qtiplot/src -type f | xargs dos2unix -k
 dos2unix fitPlugins/fitRational0/*
 dos2unix fitPlugins/fitRational1/*
 dos2unix 3rdparty/zlib123/*.c
 dos2unix 3rdparty/zlib123/include/*
 dos2unix 3rdparty/liborigin/*
-chmod 0644 qtiplot/src/*
+find qtiplot/src/* -type f -exec chmod 0644 \{\} \;
 chmod 0644 fitPlugins/fitRational0/*
 chmod 0644 fitPlugins/fitRational1/*
 chmod 0644 3rdparty/zlib123/*.c


Unfortunately, qtiplot is required by scidavis.  Letting Eric know of this failure, and potential to remove qtiplot, and thus scidavis, from Fedora 10 unless this is addressed pronto.

Thanks,
Matt

scidavis does not require qtiplot so if you remove qtiplot (i don't why to remove it beacuse it was never released ...) it does not matter for scidavis.

Thanks

Eric

scidavis had a dependency on libfitRational[01].so.1, which is provided by qtiplot.  Is this an unneeded dependency?

qtiplot-0.9-8.fc9.x86_64 [cmd line]
 \_  scidavis-0.1.3-2.fc10.x86_64 [2: libfitRational0.so.1()(64bit), libfitRational1.so.1()(64bit)]

rpm -ql scidavis

...
/usr/lib/scidavis/plugins/libfitRational0.so
/usr/lib/scidavis/plugins/libfitRational0.so.1
/usr/lib/scidavis/plugins/libfitRational0.so.1.0
/usr/lib/scidavis/plugins/libfitRational0.so.1.0.0
/usr/lib/scidavis/plugins/libfitRational1.so
/usr/lib/scidavis/plugins/libfitRational1.so.1
/usr/lib/scidavis/plugins/libfitRational1.so.1.0
/usr/lib/scidavis/plugins/libfitRational1.so.1.0.0
...

ah ha.  Turns out they're identical libraries because they're identical plugins, one for each package.  Those should not be included as Provides (which are handed by the automatic provides detection) in either package.  Turns out yum gets it right, and installing one doesn't pull in the other, but they're useless (and potentially harmful) Provides anyhow.

http://fedoraproject.org/wiki/Packaging/Perl#Filtering_Requires:_and_Provides
describes how to filter these out for a perl package.  It's the same idea for C, except you'll be filtering libfitRational* out.

With help from ajax:

%{expand:%%define prev__find_provides %{__find_provides}}
%define __find_provides %{SOURCE11} %{prev__find_provides}

where SOURCE11 is a shell script that does "$@" | awk 'filter out the badness'

Indeed, the current version expects to find private copies of several system libraries:
INCLUDEPATH       += ../3rdparty/muparser/include
INCLUDEPATH       += ../3rdparty/qwtplot3d/include
INCLUDEPATH       += ../3rdparty/qwt/src
INCLUDEPATH       += ../3rdparty/liborigin
INCLUDEPATH       += ../3rdparty/gsl/include
INCLUDEPATH       += ../3rdparty/zlib123/include

The old version already had a private fork of liborigin, which in the meantime has been hacked beyond recognition (so there's no hope of ever using a shared copy), a private copy of muParser and the minigzip.c in the zlib123 directory (thankfully not all of zlib!). The new version now wants private copies of qwt and gsl. This looks like an unpackagable mess. :-( And I'm not even sure they fixed the GCC 4.3 build issues yet.

I think that if we want to get this to build soon, patching would be a better approach than upgrading, but I have my doubts about the long-term maintainability of this. The current version definitely needs patching to use system libraries, and I'm worried that they might start completely forking qwt and gsl just like they did with liborigin.

It's a leaf node, nothing in the distro depends on it.  Not sure how many users of it exist, but my inclination would be to remove it for now, and ask the package owner to work with upstream to undo their mess before bringing it back in.

Created attachment 326943 [details]
patch to get this to build again

qtiplot-0.9-11.fc11 built successfully, thanks!