On Tue, Jan 17, 2017 at 06:05:38AM -0800, Steve Langasek wrote: > On Tue, Jan 17, 2017 at 01:36:43PM +0100, Evgeni Golov wrote: > > > > The fix was tested in unstable (like yours) and in Ubuntu for a long > > > > time, but I did not have any tests outside of the specific codepath I > > > > touched. > > > > I guess the core problem here is that we have a non-trivial essential > > > package that's not seeing enough tuits: five NMUs in a row in unstable, > > > yours in stable (plus a DSA). In a random shit package I wouldn't > > > hesitate, > > > but here it needs some thinking+communicating first. > > > Totally agreed that pam needs a maintainer. > > It has a maintainer. When people decide to upload to the delayed queue > instead of discussing first, the maintainer does not feel compelled to > intervene. The NMU count in unstable is at least as much a measure of > others' impatience as it is of my inactivity.
That is true and it's good to hear that you are back! > The bug with mismatched generated manpages is previously known to me; at the > moment the best available solution I have is to regenerate the manpages as > part of the patches that touch them and ship them in the source. (This is > at least consistent with the fact that they're present in the upstream tree, > despite being autogenerated.) *nod* > An alternative solution would be to leverage the reproducible builds work to > pass appropriate arguments to the manpage generator and ensure that dates > are consistent regardless of when someone rebuilds the package. That sounds like the better approach long term, yeah. > For the specific case of libpam-modules 1.1.8-3.1+deb8u2, however, it > appears the problem is the manpage *was* regenerated at build time on amd64, > and was *not* regenerated at build time on !amd64. This perhaps points to > an unclean build environment for the amd64 upload, or a build tree that was > not unpacked in the correct order causing files to be regenerated which > otherwise would not have been. Since pam 1.1.8-3.1+deb8u2 amd64 was built > on the uploader's machine, there is no log file at > https://buildd.debian.org/status/package.php?p=pam&suite=jessie so it's hard > to be sure. I'll see if I still have the logs on my laptop at home (~ weekend-ish). Same applies for checking if the building chroot was clean - I would expect so, but I'll double-check. Sorry for the overall fuckup - I did not expect a simple "dget, dpkg-source -x and replacing a patch" to cause multi-arch issues :/ > To fix this, regenerate debian/patches-applied/cve-2015-3238.patch to > include the changes to the generated manpages (pam_exec(8), pam_unix(8)). Can you take care of this? Or shall I give it a shot? Regards Evgeni
