Thursday, 25 July 2013

Re: Review of current autopkgtest failures, bucket into teams

Hey Rodney,

Rodney Dawes [2013-07-25 11:22 -0400]:
> > saucy-adt-ubuntuone-client (supposed to work now, problem with "allow-stderr")
> This just requires a new upload, to add the allow-stderr flag, if one
> hasn't
> been done already.

I did in,
but it's still failing due to some bug. That's now infrastructure and
hence in JB's/my corner, so don't worry.

> > saucy-adt-software-center (never worked)

> These apparently never worked, and instead of constantly uploading
> new versions that simply removes the newly failing tests, I decided
> it's best to just remove the autopkgtest config, as it never worked.
> This should have been removed by jenkins by now as well, as I
> alerted you on IRC that I was doing this.

Agreed. It's already removed from the internal Jenkins, just the
public one needs to be handled by IS (sorry, forgot about it). It's
gone now.

> > == uploaded by particular developer ==
> > saucy-adt-dirspec (never worked, dobey)
> I'm guessing this is the python unit tests printing stuff to stderr
> problem?
> The tests are passing, but adt-run is failing anyway.

Right. I uploaded a new version with the new "Restrictions:

> For the stderr case, it would be helpful if adt-run also printed
> something informative
> to stderr itself, stating the tests failed for that reason. This is all
> I see in the
> "console output" on jenkins, and it's not very helpful to know what
> exactly went
> wrong (without external context/knowledge):

It says here:

adt-run: trace: & dsc0t-run-tests: - - - - - - - - - - results - - - - - - - - - -
dsc0t-run-tests FAIL status: 0, stderr: + python ./ build test clea...

You see that the job has a "stderr" attachment, like here:,label=adt/


Martin Pitt |
Ubuntu Developer ( | Debian Developer (

ubuntu-devel mailing list
Modify settings or unsubscribe at: