> not that i'm aware of, as you said in comment 9 this is a danger to future srus.
Only if the uploader runs autoreconf manually, right? IOW, it won't happen by accident? If so, then I'm not sure it makes sense to upload this to Xenial, even with block-proposed-xenial. Say for example that a critical vulnerability is discovered and the security team need to patch it urgently (seems unlikely for dpkg, but let's go with it). If we accept this SRU then an undetected regression introduced by running autoreconf would have been staged, the security team would base on that, and then it'd get released, hitting users at large. OTOH, if we do nothing now, then the security team will likely be able to patch without running autoreconf, and any latent regression activated by running autoreconf will not get released because autoreconf didn't get run. Only if a future update requires autoreconf (or autoreconf gets run at upload time without knowledge of this issue) at upload stage would this SRU be beneficial. That seems unlikely to me, given that we don't intend to make feature changes to dpkg. Therefore, I'm not sure that an SRU to Xenial makes sense. What am I missing? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1842947 Title: dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1842947/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
