On Wed, Jan 18, 2017 at 08:03:12PM +0100, Evgeni Golov wrote: > On Tue, Jan 17, 2017 at 06:05:38AM -0800, Steve Langasek wrote: > > > > 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.
My concern here is not the count itself but the lack of even an "I'm busy, please go ahead" response to NMU talk. I feel uneasy messing with a vital package without an ok from the maintainer. > That is true and it's good to hear that you are back! Awesome! > > 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.) Upstream autoconfage looks for presence of the entire xsl stack, and regenerates the manpages only if those build-dependencies are installed. This means, to get consistent results, we need to always either have them not installed (and use prebuilt copies) or have them installed (and regenerate). As it's impossible to Build-Conflict with your own Build-Depends-Indep, only the latter can be done. This also happens to agree with the "build everything from source" principle. > > 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. In my tests (in unstable), the generator does the right thing if all bdeps are there. I'm not sure if this is true in jessie, it's possible unstable/stretch toolchain has been tampered with by our reproducible builds guys. > > 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. As jessie has no source-only uploads, I guess you had B-D-Indep for amd64 but not for the rest. > Sorry for the overall fuckup - I did not expect a simple "dget, > dpkg-source -x and replacing a patch" to cause multi-arch issues :/ Not your fault, I've fixed the issue only in unstable. > > 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? I have some doubts if it's the right thing to do. A stable update would help only for new installs, and by the time of the next point release, stretch will be released or about to be released. It is possible to install oldstable, yeah, but the number of new users is sharply reduced. Thus, perhaps it'd be enough for Steve to remember the issue, and, in case the security team wants to make an upload, warn them? I guess decisions like this are best done by the maintainer; I can help with the actual work. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
