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
> 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
> > == uploaded by particular developer ==
> > saucy-adt-dirspec (never worked, dobey)
> I'm guessing this is the python unit tests printing stuff to stderr
> 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 ./setup.py build test clea...
You see that the job has a "stderr" attachment, like here:
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel