Comment 19 for bug 199486

@Michael: almost there:

1) I wasn't clear when I said to move things to an automake patch; I meant to please move the Makefile.in updates *only*; the Makefile.am changes do belong logically with the .c addition; the reasons I requested a separate patch for Makefile.in is to:
- keep generated data separate from source data
- this typically represents what you would send upstream, or also the "interesting" part to review for me; the Makefile.in parts aren't ever going to be submitted to an upstream nor am I interested in reviewing them if they are autogenerated
- it's very likely that conflicts happen with Makefile.in updates, having them separately means that it's easy to redo this part of the patch from scratch by simply running automake again
- it happens that multiple patches touch Makefile.am, it's easier to generate a single patch by running automake
- it helps to make sure that Makefile.in timestamps will be newer than Makefile.am timestamps once the two patches have been applied in the proper order; this is particulary important when you update configure as the files are usually ordered as configure first and configure.in/.ac second, and hence let autotools think that autoconf needs to be run (as configure.in is newer than configure) -- unless AM_MAINTAINER_MODE is used, which is the case here

2) the Makefile.in patch should be applied after the backport patch; usually patches are ordered by being named 10_foo.patch, 70_relibtoolize.patch etc., but here it's not the case :-/ You could try zzz_automake.patch.

3) Please mention you added these as a patch in debian/changelog and mention the name of the patch: this allows to lookup in changelog when a patch was added / updated / removed.

Thanks!