During a @preserved-rebuild, net-misc/streamtuner-0.99.99-r5 wouldn't compile due to its ./configure aborting on the unknown '--enable-compile-warnings=minimum' option. streamtuner *does* support '--enable-compile-warnings', which causes gnome2.eclass to add this option to its ./configure call; but (the package being quite old and apparently not being autoreconf'd) it does *not* support the 'minimum' level. A simple workaround/fix is to add a supported variant of the configure option explicitly: src_configure() { gnome2_src_configure --enable-compile-warnings=no } Alternatively, see #339189 for a successor of streamtuner.
seems like the... if grep -q "enable-compile-warnings"... in gnome2.eclass is not sufficient check, should propably be something like... if grep -q "enable-compile-warnings.*minimal"... assigning to gnome@ for eclass fixing
Probably we should only be passing --enable-compile-warnings=minimum to packages that use the GNOME_COMPILE_WARNINGS macro in their configure.{ac,in}; in other cases, it's not obvious that this flag is safe and sane to set.
I would keep eclass as is because it also helps to catch packages not using the macro (or a equivalent, last time I checked, there were some tarballs not yet migrated to the macro but using a 100% equivalent one). That way, in this case we would simply need to append the proper --enable-compile-warnings to get the similar behavior (of not appending -Werror stuff usually by still providing -Wall and co) If we wouldn't had the eclass as-is, I think that this package could have still uncared for more years (I mean -> using the defaults whatever they are)
We should probably use the macros for checks like this whenever there is one. It is far more reliable _and_ we can check macro version if needed from the embedded .m4 file.
(In reply to Pacho Ramos from comment #3) > If we wouldn't had the eclass as-is, I think that this package could have > still uncared for more years (I mean -> using the defaults whatever they are) sounds good to me, streamtuner's ebuild and build-sys has been fine for years :)
OK, rethinking that, looks better to make the check more reliable
(In reply to Alexandre Rostovtsev from comment #2) > Probably we should only be passing --enable-compile-warnings=minimum to > packages that use the GNOME_COMPILE_WARNINGS macro in their > configure.{ac,in}; in other cases, it's not obvious that this flag is safe > and sane to set. Can anybody look at this? It should be similar as current one we use for maintainer mode: # Pass --disable-maintainer-mode when needed if grep -q "^[[:space:]]*AM_MAINTAINER_MODE(\[enable\])" \ "${ECONF_SOURCE:-.}"/configure.*; then G2CONF="--disable-maintainer-mode ${G2CONF}" fi
(In reply to Pacho Ramos from comment #7) > (In reply to Alexandre Rostovtsev from comment #2) > > Probably we should only be passing --enable-compile-warnings=minimum to > > packages that use the GNOME_COMPILE_WARNINGS macro in their > > configure.{ac,in}; in other cases, it's not obvious that this flag is safe > > and sane to set. > > Can anybody look at this? It should be similar as current one we use for > maintainer mode: > # Pass --disable-maintainer-mode when needed > if grep -q "^[[:space:]]*AM_MAINTAINER_MODE(\[enable\])" \ > "${ECONF_SOURCE:-.}"/configure.*; then > G2CONF="--disable-maintainer-mode ${G2CONF}" > fi And when AC_CONFIG_AUX_DIR is set, and ${ECONF_SOURCE} contains only the final ./configure script and some custom directory, like build/ has all the autotools file like configure.ac That's not uncommon at all So I think you should stick to parsing configure
The problem is that, with that way, we keep appending *minimum* always even if it will end up setting other flags because it's not using the macro, but I agree that it's probably the safest we can do :/
+ 27 Sep 2013; Pacho Ramos <pacho@gentoo.org> streamtuner-0.99.99-r5.ebuild: + Pass proper option to compile-warnings to enable warnings but not errors + (#481124), fix desktop entry +
