Hi, On Mon, Dec 23, 2013 at 05:23:42AM +0100, Guillem Jover wrote: > Hi! > > On Sun, 2013-12-22 at 10:18:32 +0100, Guido Günther wrote: > > I't be nice if dpkg-buildpackage would report build information (e.g. > > things like the name of the generated changes file) to build-tools > > invoking it. > > > > Doing this via a status fd would be nice[1] since we could then > > implement more nice things like progress information (we'd then be able > > to detect easily which dpkg-buildpackage's steps failed) without parsing > > the full build output. > > > [1] The status fd has the disadvantage that we need to pass it through > > tools like pbuilder and sbuild as well so a file at a well known > > location might be simpler. > > How do you see that progress information being used? Or to report > what?
The progress information could be useful on the buildds and in CI systems like e.g. Jenkins. It would allow us to get a better idea at what stage we're currently at (like the steps 1-9 from dpkg-buildpackage's manapage). It will also help us to report more detailed what step failed so we can see at a glance if we had unmet build-deps or if the binary build failed. > I'm not saying a --status-fd kind of option might not be useful, just > interested to know, if maybe there's something else that needs fixing > instead in dpkg-buildpackage, now that I'm reworking it. For example > if its error reporting leaves to be desired, then I'd rather improve > that, rather than adding support for wrappers to workaround it. :) The current unstructured output of dpkg-buildpackage leaves us only with parsing the logs and looking at the exit status. Since the exit status seems to be that of the invoked command mostly (except for dpkg-checkbuilddeps) we can't infere what failed. So there are two parts: 1.) progress report (which step are we currently at) 2.) error report (which step failed and why) While 2.) can be fixed via more detailed exit codes 1.) can't. > For example for 1.17.6 I'm adding hooks support, which can be useful > for wrappers. Hooks are nice and can be useful but they can also be confusing: gbp (hooks) -> pbuilder (hooks) -> dpkg-buildpackage (hooks) If dpkg-buildpackage doesn't want to suck in the functionality of the other two a nice way to propagate information like progress, errors, build results up the chain would be really nice. > > This report is triggered by #732678 where gbp failed to find the > > generated changes file for a architecture independent package build > > since it didn't look at the options passed to dpkg-buildpackage until > > recently. > > For the problem described in the bug report, I think a better way to > solve this is to run lintian directly from dpkg-buildpackage, which > will be possible with dpkg 1.17.6, by using the new check-command > support. See the following commit for further details: > > <http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commitdiff;h=1cef5694> > > Or do you need the .changes file for something else? (Rahpael pointed this out already) If one may want the build environment to be as minimalistic as possible and not want to have lintian or other verifiers in there. We can also use the changes file to find out about the other build artifacts to upload them to a temp repository or some such. So invoking lintian is not the only usage and I'd rather not see every usage scenario crammed into dpkg-buildpackage itself. Cheers and thanks for your quick response, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
