Bug 511425 - FTBFS xqilla-2.1.3-0.6.fc11
FTBFS xqilla-2.1.3-0.6.fc11
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xqilla (Show other bugs)
12
All Linux
high Severity high
: ---
: ---
Assigned To: Jonathan Robie
Fedora Extras Quality Assurance
http://linux.dell.com/files/fedora/Fi...
: Triaged
Depends On:
Blocks: F12FTBFS
  Show dependency treegraph
 
Reported: 2009-07-14 22:52 EDT by FTBFS
Modified: 2013-08-05 20:53 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-09 11:28:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
root.log (561.68 KB, text/plain)
2009-07-14 22:52 EDT, FTBFS
no flags Details
build.log (549.44 KB, text/plain)
2009-07-14 22:52 EDT, FTBFS
no flags Details
mock.log (956 bytes, text/plain)
2009-07-14 22:52 EDT, FTBFS
no flags Details
root.log (717.24 KB, text/plain)
2009-07-14 22:52 EDT, FTBFS
no flags Details
build.log (524.09 KB, text/plain)
2009-07-14 22:52 EDT, FTBFS
no flags Details
mock.log (963 bytes, text/plain)
2009-07-14 22:52 EDT, FTBFS
no flags Details
Patch to fix build issue (removes duplicate entries from Makefile) (808 bytes, patch)
2010-01-15 12:09 EST, Nuno Santos
no flags Details | Diff

  None (edit)
Description FTBFS 2009-07-14 22:52:17 EDT
xqilla-2.1.3-0.6.fc11.src.rpm Failed To Build From Source against the rawhide tree.  See http://fedoraproject.org/wiki/FTBFS for more information.
Comment 1 FTBFS 2009-07-14 22:52:20 EDT
Setting to ASSIGNED per Fedora Bug Triage workflow.  https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Comment 2 FTBFS 2009-07-14 22:52:23 EDT
Created attachment 351769 [details]
root.log

root.log for i386
Comment 3 FTBFS 2009-07-14 22:52:25 EDT
Created attachment 351770 [details]
build.log

build.log for i386
Comment 4 FTBFS 2009-07-14 22:52:26 EDT
Created attachment 351771 [details]
mock.log

mock.log for i386
Comment 5 FTBFS 2009-07-14 22:52:27 EDT
Created attachment 351772 [details]
root.log

root.log for x86_64
Comment 6 FTBFS 2009-07-14 22:52:29 EDT
Created attachment 351773 [details]
build.log

build.log for x86_64
Comment 7 FTBFS 2009-07-14 22:52:30 EDT
Created attachment 351774 [details]
mock.log

mock.log for x86_64
Comment 8 Matt Domsch 2009-10-22 16:08:43 EDT
http://koji.fedoraproject.org/koji/buildinfo?buildID=124374
failed in koji.
Comment 9 Matt Domsch 2009-10-22 16:29:05 EDT
This package failed to build in Koji for Fedora 12, and at this point in the release cycle (Beta is out), we'll have to live with the F11 build of the package unless there is another bug in your package which would prevent the release of Fedora 12.

If your package is now obsolete and should be removed from Fedora 12 and future, please follow the End of Life instructions here:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

If your package is not obsolete, and you wish it to remain in the distribution for Fedora 13, please update your package's devel branch in CVS so that it builds, build it in koji, and close this bug as "CLOSED RAWHIDE", including the link to the koji build that succeeded.  You can do this now, while final touches are being placed on Fedora 12 without affecting F12.

Shortly after F12 is out, but before the F13 Alpha release, all F12FTBFS-blocking bugs will be re-evaluated.  At that time, if progress has not been made to fix the package, it will be removed from the distribution for F13.
Comment 10 Bug Zapper 2009-11-16 05:53:21 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Matt Domsch 2010-01-15 01:03:42 EST
I am proposing that this package be dropped from Fedora due to the longstanding FTBFS bug against it.  Unfortunately, this package has several interesting components that depend upon it:

Removing xqilla removes these:
dbxml-utils-0:2.4.16-0.5.fc12.x86_64
dbxml-python-0:2.4.16-0.5.fc12.x86_64
dbxml-devel-0:2.4.16-0.5.fc12.x86_64
dbxml-0:2.4.16-0.5.fc12.x86_64
xqilla-devel-0:2.1.3-0.6.fc11.x86_64
xqilla-devel-0:2.1.3-0.6.fc11.i586
dbxml-devel-0:2.4.16-0.5.fc12.i686
qpidd-xml-0:0.5.819819-1.fc13.x86_64

Please make an effort to resolve this ASAP, to allow these components to remain.
Comment 12 Nuno Santos 2010-01-15 12:09:51 EST
Created attachment 384661 [details]
Patch to fix build issue (removes duplicate entries from Makefile)

Patch needs to be committed and added to specfile (I dont' have commit rights on the package), as such:

$ cvs diff
Index: xqilla.spec
===================================================================
RCS file: /cvs/pkgs/rpms/xqilla/F-12/xqilla.spec,v
retrieving revision 1.12
diff -r1.12 xqilla.spec
7c7
< Release: 0.7%{?dist}
---
> Release: 0.8%{?dist}
22a23
> Patch2: dup.patch
53a55
> %patch2
109a112,114
> * Fri Jan 15 2010 Nuno Santos <nsantos@redhat.com> - 2.1.3-0.8
> - Patch to remove duplicate entries in Makefile
>
Comment 13 Toshio Ernie Kuratomi 2010-01-15 12:10:12 EST
Started to look into this and found that 

* Tue Feb 19 2008 Milan Zazrivec <mazrivec@redhat.com> 2.0.0-2
- Included Xerces-C 2.8.0 sources

The README in xqilla talks about patching the downloaded xerces-c sources and building xqilla against that.

Our Xerces package has this as its most recent changelog:
* Thu Aug 06 2009 Peter Lemenkov <lemenkov@gmail.com> 2.8.0-5
- Fix CVE-2009-1885

Which mitre.org says is an application crash DOS.

I downloaded the latest XQilla: xqilla-2.2.3 and the README still says to download the Xerces-C source but I found this in the configure.in: 

if test "$xerces_version_major" -lt "3" -a "$xerces_source_tree" = "no"; then
   AC_MSG_ERROR([For Xerces-C versions before 3.0 the source tree is required to build XQilla. You must specify the path to the Xerces-C source tree using --with-xerces.])
fi

So I strongly recommend that xqilla be dropped.  When xqilla is updated and can build against the system xerces (may require an update of xerces as well; F-12 has xerces-2.8.0) it can be brought back.
Comment 14 John Snelson 2010-01-18 08:25:22 EST
I'm the lead developer for XQilla. If there's any way I can help you get XQilla in the latest Fedora, please feel free to contact me. Xerces-C 3.0 has been out quite a while now, so it might be worth upgrading to it, or having it as an additional package. It's not binary ( or source) compatible with 2.8.
Comment 15 Jonathan Robie 2010-01-19 09:20:31 EST
I'm in contact with John. He thinks that adding some headers should allow XQilla to build against Xerces 2.8, and will provide us with a list. 

It would still be very desireable to upgrade Xerces to a more recent version on any platforms where this is possible. Xerces 3.0 has been out since September 2008 - but of course many packages depend on it, so we have to be certain that upgrading would not introduce compatibility issues.
Comment 16 John Snelson 2010-01-19 10:01:42 EST
In order to build XQilla 2.2.3 against Xerces-C 2.8 (or any version before 3.0), XQilla requires the following (formerly) private headers:

xercesc/dom/impl/DOMAttrImpl.hpp
xercesc/dom/impl/DOMCasts.hpp
xercesc/dom/impl/DOMDocumentImpl.hpp
xercesc/dom/impl/DOMDocumentTypeImpl.hpp
xercesc/dom/impl/DOMElementNSImpl.hpp
xercesc/dom/impl/DOMNodeImpl.hpp
xercesc/dom/impl/DOMRangeImpl.hpp
xercesc/dom/impl/DOMTypeInfoImpl.hpp
xercesc/dom/impl/DOMWriterImpl.hpp

Packaging XQilla along with these headers from Xerces-C should allow a stand alone build without the Xerces-C source code (ie: from a normal install of Xerces-C).
Comment 17 Toshio Ernie Kuratomi 2010-01-21 11:51:36 EST
Cool. So it looks like xqilla is not affected by the security issue as it is just using the extra headers in order to build.  We can track the bundling issue in bug 555836 and resolve it during the F13 rawhide cycle.

Since jrobie has taken over the xqilla package, he can apply the patch from nsantos,make a build, and we can close this FTBFS bug.  Thanks everyone!
Comment 18 Jonathan Robie 2010-02-05 14:02:31 EST
(In reply to comment #16)
> In order to build XQilla 2.2.3 against Xerces-C 2.8 (or any version before
> 3.0), XQilla requires the following (formerly) private headers:
> 
> xercesc/dom/impl/DOMAttrImpl.hpp
> xercesc/dom/impl/DOMCasts.hpp
> xercesc/dom/impl/DOMDocumentImpl.hpp
> xercesc/dom/impl/DOMDocumentTypeImpl.hpp
> xercesc/dom/impl/DOMElementNSImpl.hpp
> xercesc/dom/impl/DOMNodeImpl.hpp
> xercesc/dom/impl/DOMRangeImpl.hpp
> xercesc/dom/impl/DOMTypeInfoImpl.hpp
> xercesc/dom/impl/DOMWriterImpl.hpp
> 
> Packaging XQilla along with these headers from Xerces-C should allow a stand
> alone build without the Xerces-C source code (ie: from a normal install of
> Xerces-C).    


The XQilla ./configure script wants me to provide the path to the Xerces source tree:

http://xqilla.sourceforge.net/UnixBuild:

./configure --with-xerces=/path/to/xerces/source/tree

If I have Xerces 3.0.1 installed and configure without specifying --with-xerces, the configure does not succeed. How do I configure if I don't have the Xerces source tree?
Comment 19 Jonathan Robie 2010-02-05 18:40:20 EST
This configure command works, if xerces-devel 3.0.1 is installed:

./configure --with-xerces=/usr
Comment 20 Jonathan Robie 2010-03-04 17:41:47 EST
Closing this, since it's fixed in rawhide.
Comment 21 Jonathan Robie 2010-03-05 17:02:43 EST
In the upstream, I just checked in a configure.ac and modified XmlExchange.cpp that support either API.  

I test for the presence of xqilla/ast/XQEffectiveBooleanValue.hpp to decide which API to use.

configure.ac

# Check to see if we need to use legacy calls for effective boolean value
  xqilla_has_ebv=yes
  AC_CHECK_HEADER([xqilla/ast/XQEffectiveBooleanValue.hpp], , [xqilla_has_ebv=no])
  test $xqilla_has_ebv = no &&
    AC_DEFINE([XQILLA_2_1_3], [1], [Use the old XQilla 2.1.3 API to get effective boolean value.])

XmlExchange.cpp:

#ifndef XQILLA_2_1_3
#include <xqilla/ast/XQEffectiveBooleanValue.hpp>
#endif
...
#ifndef XQILLA_BEFORE_2_2_3
      Item::Ptr first_ = result->next(context.get());
      Item::Ptr second_ = result->next(context.get());
      return XQEffectiveBooleanValue::get(first_, second_, context.get(), 0);
#else
      return result->getEffectiveBooleanValue(context.get(), 0);
#endif

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