Bug 434100 - qtiplot failed massrebuild attempt for GCC 4.3
qtiplot failed massrebuild attempt for GCC 4.3
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: qtiplot (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Frank Büttner
Fedora Extras Quality Assurance
:
: 440844 (view as bug list)
Depends On:
Blocks: gcc43errors F10FTBFS
  Show dependency treegraph
 
Reported: 2008-02-22 08:05 EST by Jesse Keating
Modified: 2013-01-09 21:53 EST (History)
5 users (show)

See Also:
Fixed In Version: qtiplot-0.9-11.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-16 01:56:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to get this to build again (835 bytes, patch)
2008-12-15 08:19 EST, Caolan McNamara
no flags Details | Diff

  None (edit)
Description Jesse Keating 2008-02-22 08:05:18 EST
This is an automatically filed bug for a failed rebuild attempt for GCC 4.3.

http://fedoraproject.org/wiki/JesseKeating/gcc43MassRebuildProposal

Please verify why this build failed and fix it.
http://koji.fedoraproject.org/koji/taskinfo?taskID=438946
Exit code was 1, check the build.log for the failed buildArch task.
Comment 1 Frank Büttner 2008-02-22 09:04:09 EST
Can't be fixed until the mock problem with EPEL is fixed.
Comment 2 Tyler Owen 2008-02-24 13:38:13 EST
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
Comment 3 Bug Zapper 2008-05-14 01:26:03 EDT
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
Comment 4 Matt Domsch 2008-07-03 13:27:00 EDT
*** Bug 440844 has been marked as a duplicate of this bug. ***
Comment 5 Kevin Kofler 2008-07-17 22:47:24 EDT
Missing #include <cstring> (and possibly using directives too).
Comment 6 FTBFS 2008-09-05 12:26:26 EDT
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.
Comment 7 Matt Domsch 2008-09-17 00:50:45 EDT
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
Comment 8 Eric Tanguy 2008-09-17 02:55:02 EDT
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
Comment 9 Matt Domsch 2008-09-17 09:14:03 EDT
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)]
Comment 10 Eric Tanguy 2008-09-17 09:22:05 EDT
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
...
Comment 11 Matt Domsch 2008-09-17 10:38:35 EDT
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'
Comment 12 Kevin Kofler 2008-09-17 19:38:42 EDT
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.
Comment 13 Matt Domsch 2008-09-17 22:35:22 EDT
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.
Comment 14 Caolan McNamara 2008-12-15 08:19:34 EST
Created attachment 326943 [details]
patch to get this to build again
Comment 15 Kevin Kofler 2008-12-16 01:56:37 EST
qtiplot-0.9-11.fc11 built successfully, thanks!

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