On Sat, Oct 28, 2017 at 02:21:37PM +0200, Axel Beckert wrote: > Do I understand it correctly that with "Rules-Requires-Root: no" the > root:root ownership is only set by dh_builddeb? Well, by dpkg-deb of course :) Check the --root-owner-group option of dpkg-deb 1.19.0. > > > > dh_strip_nondeterminism > > > > dh_strip_nondeterminism: debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png: debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png: open: Permission denied at /usr/share/perl5/File/StripNondeterminism/handlers/png.pm line 60. > > > > > > > > debian/rules:5: recipe for target 'binary' failed > > > > make: *** [binary] Error 13 > > > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 > > > > > > The file in question is read-only, but belongs to the user trying to > > > build the package: > > > > > > -r--r--r-- 1 abe abe 1749 Oct 27 22:48 debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png > [...] > > > The culprit seems to be in ExtUtils::Install (part of > > > ExtUtils::MakeMaker) [...]'s install() subroutine which > > > later copies files from blib/ to $DESTDIR/$PREFIX/ which [...] > > > looks like a hardcoded 0444 plus executable bit where necessary: [snip] > > > So IMHO it's not dh_strip_nondeterminism's fault, also because it > > > perl's open() which indeed does bail out on trying to write to files > > > with 444 (i.e. read-only) permissions (at least as unprivileged user). [huge cut] Whilst I conisder ExtUtils::MakeMaker's behaviour fairly weird (and besides, if left alone it wouldn't be complian with Policy §10.9 - probably that's hidden by dh_fixperms?), I don't think we need to do any of the change you suggest in your mail. I might be heavily downgrading the issue you found, and simply say that File::StripNondeterminism::handlers::png is too eager in the open(). Amongst the various handlers, png and ar are the only to that uses +< while opening the original file, but the png one has no reason to. What it does it a series of read()s to get data out, write it to a temporary file, and then copy the data over the original file in some other way (it uses File::Copy::copy). I tried live patching strip-nd by chaging the open(my $fh, '+<', $filename) to open(my $fh, '<', $filename) and indeed I could get a build completely identical to the one done without R³ and unpatched strip-nd (and the log confirms files are still being processed by strip-nd. So, I think that to handle this issue we should just drop that single byte from strip-nd and consider it done. This leaves the ar handler. I don't think there are many (if any) perl packages shipping ar files that aren't otherwise writable, but I believe anybody with some perl knowledge could change the strip-nd ar handler to use the same temporary file structure uesd by the other handlers as well. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature