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.
Setting to ASSIGNED per Fedora Bug Triage workflow. https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Created attachment 351769 [details] root.log root.log for i386
Created attachment 351770 [details] build.log build.log for i386
Created attachment 351771 [details] mock.log mock.log for i386
Created attachment 351772 [details] root.log root.log for x86_64
Created attachment 351773 [details] build.log build.log for x86_64
Created attachment 351774 [details] mock.log mock.log for x86_64
http://koji.fedoraproject.org/koji/buildinfo?buildID=124374 failed in koji.
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.
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
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.
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> - 2.1.3-0.8 > - Patch to remove duplicate entries in Makefile >
Started to look into this and found that * Tue Feb 19 2008 Milan Zazrivec <mazrivec> 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> 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.
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.
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.
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).
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!
(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?
This configure command works, if xerces-devel 3.0.1 is installed: ./configure --with-xerces=/usr
Closing this, since it's fixed in rawhide.
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