Description of problem: Package lasso fails to build from source with xmlsec1-1.2.25-2.fc28 in Fedora rawhide. tools.c:60:10: fatal error: xmlsec/soap.h: No such file or directory #include <xmlsec/soap.h> ^~~~~~~~~~~~~~~ compilation terminated. {standard input}: Assembler messages: {standard input}: Error: .size expression for tools.c does not evaluate to a constant make[5]: *** [Makefile:1058: tools.lo] Error 1 make[5]: *** Waiting for unfinished jobs.... It fails because xmlsec1-1.2.25 has disabled soap support by default. It will be fixed if a maintainer rebuilds xmlsec1 with '--enable-soap'. Version-Release number of selected component (if applicable): 2.5.1-9.fc28 Steps to Reproduce: koji build --scratch f28 lasso-2.5.1-9.fc28.src.rpm Additional info: This package is tracked by Koschei. See: http://apps.fedoraproject.org/koschei/package/lasso The dependency changes from the latest successful build: https://apps.fedoraproject.org/koschei/build/4009311
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
bug #1557090 created to get xmlsec1 to enable SOAP again.
See https://www.aleksey.com/xmlsec/ for xmlsec release notes. xmlsec 1.2.24 released April 20 2017 has this comment: Marked as deprecated all the functions in xmlsec/soap.h file and a couple other functions no longer required by xmlsec. These functions will be removed in the future releases. xmlsec 1.2.25 released September 12 2017 Added --enable-soap to the configure command. If --enable-soap is not passed to configure when xmlsec is built then when you try to build lasso you get this compilation error: tools.c:60:10: fatal error: xmlsec/soap.h: No such file or directory #include <xmlsec/soap.h> At first I thought the expedient answer was to make sure --enable-soap was used to build xmlsec but when I investigated further (see above) I realized that's only a temporary band-aid over the problem because soap in xmlsec will be removed. I took a look at how lasso uses the soap functionality in xmlsec and it's really minimal. Mostly it's extracting the soap header and body from a libxml2 document. The code is pretty straight forward and in truth lasso could have probably had it's own utility to perform the same function without needing xmlsec, but I guess because it was in xmlsec at the time of it's writing then why not use it? Anyway I think the answer is to add a few soap utility routines to lasso that replicates what xmlsec was doing and rid ourselves of the xmlsec soap dependency. I removed the dependency on bug #1557090. Instead I'll write a patch for lasso. I have been communicating with upstream lasso on this topic as well.
*** Bug 1556016 has been marked as a duplicate of this bug. ***
lasso-2.5.1-13.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3fcce95800
lasso-2.5.1-13.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-3fcce95800
lasso-2.5.1-13.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.