Bug#815980: tracker.debian.org: All packages have uscan issues

Osamu Aoki osamu at debian.org
Thu Mar 3 12:17:37 UTC 2016


Hi,

I think I can propose peaceful solution.

On Sun, Feb 28, 2016 at 03:18:21PM +0100, Lucas Nussbaum wrote:
> On 26/02/16 at 19:10 -0500, James McCoy wrote:
...
> > > My guess is that this was triggered in UDD when devscripts 2.16.1 got
> > > uploaded to jessie-backports. In devscripts 2.15.10, the interface to
> > > uscan changed with everything being printed to stderr (even if it's not
> > > an error) if --dehs is used.
> > 
> > Then this is what needs to be fixed.  The behavior, especially for
> > something that's intended to be used by automation, shouldn't have
> > changed such that it broke the major user of such functionality.
> 
> The code that runs uscan in UDD is
> http://anonscm.debian.org/cgit/collab-qa/udd.git/tree/rimporters/upstream.rb
> (starting around line 50).

I have never learned ruby but the exit code "status" obtained by:
   stdout, stderr, status = Open3.capture3(cmd)
is not used to determin if the program suceeded or not.

Instead stderr != '' check is used.  Unexpected :-)

> As you can see, the code is already quite complicated:
> uscan warnings are outputted in the <warnings> tag, but not all uscan
> errors are: sometimes they are in an <errors> tag, sometimes they are
> just displayed on stderr.

The old code turned off verbose outputs and warnings if --dehs is used.
This was bad for tweaking watch file etc.  So I activated them while
making sure stdout os used only by --dehs and stderr has them.
 
> It would be better if all uscan errors were displayed in <errors>. Then
> UDD could just ignore the stderr output.

Now the dehs output marked with <errors> has all uscan errors, if uscan
starts to process watch file(s) :-)  (I think it was not the case
previously.)

But reading what James said, I can satisfy my thought by introducing new
option --dehs-verbose while making --dehs to be quiet for warning.

This way, no pain for everyone.

Let me think a bit more but the above seems to be most rationale thing
to do.

Osamu




More information about the devscripts-devel mailing list