35014 2018-06-09 16:32:10 +0300 treat undefined macros as errors in more sections 2018-06-09 16:32:10 +0300 1 1 4 Development Sisyphus rpm-build unstable all Linux NEW P3 enhancement --- 1 imz placeholder arseny glebfm imz ldv placeholder vt qa-sisyphus oldest_to_newest 171790 0 imz 2018-06-09 16:32:10 +0300 rpm-build-4.0.4-alt111.x86_64 When someone uses an undefined macro in %build, this is usually an error. Now it is just a warning. Sometimes, the % signs are to be passed verbatim. Sometimes, they are even to be used to generate rpm directives (say, sed generating a %files section). These cases can be fixed. There are not so many packages with these warnings: [imz@team success]$ fgrep 'warning: Macro %' -slr . | wc -l 257 [imz@team success]$ pwd /beehive/logs/Sisyphus-x86_64/latest/success Here is a related discussion of this feature (but not about turning on errors for %build): http://lists.rpm.org/pipermail/rpm-maint/2013-February/003383.html More details about the motivation: if I use a (new) macro in a spec (as the author), I want that other people when trying to build the package either get an explicit error (if they don't have the definition of this macro) or build correctly (if this macro is defined for them already). Now I need to worry whether it will always be built correctly. Putting BuildPreReq on a specific release of rpm-build is a way which I don't like because the definitions in question can be cherry-picked, so there is no fixed release number which guarantees the presence of this macro definition.