Description of problem: The default specification for %configure in redhat-rpm-config now specifies --disable-silent-rules for all builds. This works fine for autotools builds, but some build systems (notably the samba WAF build system) does not ignore unknown configure options. This results in a FTBFS state for these packages on Rawhide right now. Version-Release number of selected component (if applicable): redhat-rpm-config-9.1.0-21.fc17 How reproducible: Every time Steps to Reproduce: 1. Attempt to build libtdb, libtalloc or samba4 (probably other packages as well) with koji on Rawhide. Actual results: + ./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --disable-silent-rules --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-rpath --bundled-libraries=NONE waf [command] [options] Main commands (example: ./waf build -j4) build : builds the project clean : removes the build files configure : configures the project dist : makes a tarball for distribution distcheck : checks if the sources compile (tarball from 'dist') distclean : removes the build directory install : installs the build files reconfigure: reconfigure if config scripts have changed test : run tdb testsuite uninstall : removes the installed files waf: error: no such option: --disable-silent-rules error: Bad exit status from /var/tmp/rpm-tmp.2Rxf1u (%build) Bad exit status from /var/tmp/rpm-tmp.2Rxf1u (%build) RPM build errors: Child returncode was: 1 EXCEPTION: Command failed. See logs for output. Expected results: Successful build Additional info: While I appreciate the intent of setting this flag, I think the more effective way might be to change %{?_smp_mflags} (or provide a new macro for standard make flags) and set the environment variable V=1 for builds.
Reassigning to Colin Walters who introduced this change. FWIW I'm not the biggest fan of this whole thing.
Any word on this issue?
This is causing FTBFS on multiple packages. Please revert it.
This should be changed on the make level so make V=1 and not using the configure option which will, according to the documentation, only work if the developer adds it to his configure.ac file.
I agree, but using %{?_smp_mflags} for this purpose sounds wrong to me.
(In reply to comment #5) > I agree, but using %{?_smp_mflags} for this purpose sounds wrong to me. Yeah, I agree. Maybe we might want to implement %{?_std_mflags} which would expand out to %{?_smp_mflags} V=1
(In reply to comment #6) > (In reply to comment #5) > > I agree, but using %{?_smp_mflags} for this purpose sounds wrong to me. > > Yeah, I agree. Maybe we might want to implement %{?_std_mflags} which would > expand out to > %{?_smp_mflags} V=1 Then you're back to patching every package though that uses autotools and AM_SILENT_RULES. If that's the way you guys want to go for RPM, fine by me. My own opinion is here: http://people.gnome.org/~walters/docs/build-api.txt
> http://people.gnome.org/~walters/docs/build-api.txt Is this document something that upstream maintainers follow? How does it apply on projects not based on autotools?
(In reply to comment #8) > > http://people.gnome.org/~walters/docs/build-api.txt > > Is this document something that upstream maintainers follow? How does it apply > on projects not based on autotools? I have been slowly changing bits of the GNOME dependency stack to implement it. Almost everything in GNOME git now implements it. I recently added a patch to mesa. Is it slow going? Yes. Is it worth doing? Totally. It's usually not very hard to implement if not using the autotools, but it depends on your project. (Also at some point I plan to write generic "adapters" so that if e.g. we detect the current source tree is using Python distutils, we automatically drop in a configure and Makefile that in turn just call into distutils).
Sadly, it seems that Colin's patch has been reverted in git by Dennis. IMO it's a mistake to hold improvements to %configure hostage to some build systems that choke on something they don't understand; packages using such systems shouldn't quite probably be using the %configure macro in the first place. Even though the one in redhat-rpm-config doesn't say it, the one shipped with rpm (/usr/lib/rpm/macros) clearly states in its comments that it is intended for running "autoconf configure". Please consider adding --disable-silent-rules back, and fixing the few packages/build systems that choke on it instead as appropriate.
(In reply to comment #10) > Please consider adding --disable-silent-rules back, and fixing the few > packages/build systems that choke on it instead as appropriate. On how many packages would changing the %configure macro take a (positive?) effect? Do you have any stats?
No, but I have encountered a few, and I have some other options that I will be suggesting to %configure soonish, and I'm available to help with fixing packages that choke on unknown options one way or another. BTW it's not that long ago when --disable-dependency-tracking was added to %configure; at that time packages some packages whose build broke were simply fixed, so there is a precedent.
Changes like this break building unpatched (e.g. RHEL) packages on up2date system. Developers then need to use mock in cases where rpmbuild would be sufficient, or they need to debug tricky build failures.
(In reply to comment #13) > Changes like this break building unpatched (e.g. RHEL) packages on up2date > system. Developers then need to use mock in cases where rpmbuild would be > sufficient, or they need to debug tricky build failures. Breaks...oh you mean like building a waf-based package on Fedora for RHEL? Yeah, well, Comment #10 is a better restatement of my position.
If comment 13 was a strong consideration (think bigger picture than just %configure as you already mentioned changes "like this"), then moving Fedora forward in the first place would be much harder than it is now -- we'd need to hold back on backwards incompatible improvements or provide bugwards compatibility cruft with $something pretty much indefinitely. I think that's very much a non-objective for Fedora.
The samba project has been convinced to add --disable-silent-rules as an (ignored) option for its WAF builds. You can re-enable this feature in %configure if you want.
(In reply to comment #16) > The samba project has been convinced to add --disable-silent-rules as an > (ignored) option for its WAF builds. You can re-enable this feature in > %configure if you want. I forget if I linked here, but I still think the best fix for waf is: https://code.google.com/p/waf/issues/detail?id=1023
Though I could be convinced a better approach would be for RPM (or other meta-build system) to run ./configure --help and grep for the availability of options before using them.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19