@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! -- ConsoleKit integration https://bugs.launchpad.net/bugs/199486 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
