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