Bug 434100

Summary: qtiplot failed massrebuild attempt for GCC 4.3
Product: [Fedora] Fedora Reporter: Jesse Keating <jkeating>
Component: qtiplotAssignee: Frank Büttner <bugzilla>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: dcantrell, eric.tanguy, ftbfs, kevin, matt_domsch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: qtiplot-0.9-11.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-16 06:56:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 433629, 463452    
Attachments:
Description Flags
patch to get this to build again none

Description Jesse Keating 2008-02-22 13:05:18 UTC
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 14:04:09 UTC
Can't be fixed until the mock problem with EPEL is fixed.

Comment 2 Tyler Owen 2008-02-24 18:38:13 UTC
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 05:26:03 UTC
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 17:27:00 UTC
*** Bug 440844 has been marked as a duplicate of this bug. ***

Comment 5 Kevin Kofler 2008-07-18 02:47:24 UTC
Missing #include <cstring> (and possibly using directives too).

Comment 6 FTBFS 2008-09-05 16:26:26 UTC
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 04:50:45 UTC
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 06:55:02 UTC
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 13:14:03 UTC
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 13:22:05 UTC
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 14:38:35 UTC
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 23:38:42 UTC
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-18 02:35:22 UTC
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 13:19:34 UTC
Created attachment 326943 [details]
patch to get this to build again

Comment 15 Kevin Kofler 2008-12-16 06:56:37 UTC
qtiplot-0.9-11.fc11 built successfully, thanks!