Bug#789581: marked as pending

[Guillem Jover]

Hi!

On Thu, 2016-11-24 at 13:37:05 -0500, James McCoy wrote:
> On Thu, Nov 24, 2016 at 05:41:21AM +0100, Guillem Jover wrote:
> > Also checking what's missing, I guess I could add a new --sign-option,
> > in which case iff when passed, I could make --sign-command receive just
> > the file to sign, so that you could pass debsign/debrsign? I think that
> > would allow eliminating another good chunk of code?
> 
> That should work, yes.

Hmm although one problem is how to pass the userid/keyid. Because that
might have been specified on the command-line, or on the config file.

> Another thing to think about is allowing
> --check-command to be specified multiple times, and therefore have
> --check-command/--check-option be positional.  This would allow running
> multiple checkers (e.g., --check-command=lintian --check-option=-i
> --check-command=piuparts --check-option=--distribution=testing
> --check-option=--distribution=sid).

Yes, I've also been annoyed by the fact that we can only currently run
one checker, and had already the piuparts case in mind. But making the
check arguments positional is probably a good way to solve this.

> > Also probably we should move the Ubuntu checks into a new hook in
> > Dpkg::Vendor::Ubuntu?
> 
> You're referring to the changes file checks?  That'd be useful.

We might need to ask Ubuntu people, as I'm not sure if they'd like to
enforce that at such lower level though?

> > Should DPKG_.* environment variables also be preserved?
> 
> Which ones?  dpkg-buildpackage(1) refers to a few DEB_* variables, which
> are already preserved.  I should probably add SOURCE_DATE_EPOCH anyway,
> so the only other one is DPKG_COLORS which isn't relevant until #679645
> is addressed.

Right, DPKG_COLORS would not take effect now anyway, but there's also
at least DPKG_ROOT, DPKG_ADMINDIR, DPKG_GENSYMBOLS_CHECK_LEVEL and
DPKG_ORIGINS_DIR. There's a whitelist in the Dpkg::Build::Info module
(which thinking about it now, seems like a misnomer, but oh well),
which could perhaps be used here? I've included several of the above
to that whitelist, and will be included in dpkg 1.18.16.

On Thu, 2016-11-24 at 14:29:28 -0500, James McCoy wrote:
> On Thu, Nov 24, 2016 at 01:37:05PM -0500, James McCoy wrote:
> > That should work, yes.  Another thing to think about is allowing
> > --check-command to be specified multiple times, and therefore have
> > --check-command/--check-option be positional.  This would allow running
> > multiple checkers (e.g., --check-command=lintian --check-option=-i
> > --check-command=piuparts --check-option=--distribution=testing
> > --check-option=--distribution=sid).
> 
> In a similar manner, being able to specify multiple --rules-target
> options would be handy to reduce the overhead of debuild's target mode.
> Currently (in git), "debuild build binary" will need to invoke
> dpkg-buildpackage twice, once for each target.

Ah, indeed, I think it might also be a very clean way to solve #671074.
One could then run something like:

  $ dpkg-buildpackage -T clean,build,binary,clean,build,binary

would that work for you, Jakub? The only problem is that dpkg-source
--before-build and --after-build are not run, but perhaps we can add
an option to use those if needed.

(I've got a patch for this already but I've yet to test it, it should
get into 1.18.16.)

Thanks,
Guillem