On 12/11/2011 05:52 PM, Michael Jones wrote:
Attached is indent-2.2.10-5.2.el6.src.rpm
Difference between indent-2.2.10-5.1.el6.i686 and
indent-2.2.10-5.2.el6.i686 is
indent-2.2.9-no-double-const.patch
diff -burp indent-2.2.10-orig/src/indent.c indent-2.2.10/src/indent.c
--- indent-2.2.10-orig/src/indent.c 2008-03-11 14:50:42.000000000
-0400
+++ indent-2.2.10/src/indent.c 2011-12-11 16:39:19.146289250 -0500
@@ -1534,7 +1534,7 @@ static void handle_token_decl(
if ((parser_state_tos->last_token == rparen) &&
parser_state_tos->in_parameter_declaration &&
parser_state_tos->saw_double_colon &&
- !strncmp (token, "const", 5))
+ ! (strncmp (token, "const", 5)==0))
{
char * t_ptr;
set_buf_break (bb_const_qualifier, paren_target);
This prevents indent from printing the "const" keyword twice on const
function definitions in C++
Cheers
Hi Michael,
Thanks for taking the time to research, write, and send this to
Scientific Linux![1] The best way to get this patch included in a new
version of Scientific Linux is to get the fix included further up
stream.[2] That way groups other than this one can benefit from your
work on this issue. From our side we try not to deviate very much from
what our upstream provider is doing. Our hope is that by following them
closely we reduce the possible problems our users encounter. But this
can lead to some tension in the application of patches, particularly
patches that fix problems.
One of the best ways we can give back to our upstream providers is fixes
like this one. I hope that you can open a bug with them so that
everyone can benefit from this. As a point of etiquette, they prefer
not to have mention of SL on their bug tracker. Our source, for any
package they provide, is their source. Any patches we apply are noted
in the changelog with justifications and generally attributed to Connie,
Troy (who has left us), myself, or the Scientific Linux Development list.
Right now our commitment to improving SL, assisting upstream in fixes,
and generally trying to give back to the linux community at large gives
us pause before applying any patch for upstream packages which doesn't
have an associated bugzilla number. They've given us so much, we want
to try and give back where we can and help encourage others to do so in
the spirit of the open source movement.
Again, thank you for your efforts here!
Pat
[1] As an aside, we have a dedicated development list which you may want
to join http://listserv.fnal.gov/archives/scientific-linux-devel.html
[2] http://bugzilla.redhat.com/
--
Pat Riehecky
Scientific Linux Developer
