Control: reassign -1 qa.debian.org Control: retitle -1 UDD: upstream watch file checker is broken with devscripts 2.16.1
On Fri, 2016-02-26 at 11:45 +0100, Vincent Danjean wrote: > Package: tracker.debian.org > Severity: normal > > Hi, > > In the PTS, all packages I currently look at display the following > "action needed" item: > * Problems while searching for a new upstream version > > When looking at the details, it seems to be a connectivity problem > (and I checked for a few packages that the watch file is correct). I think this is rooted in UDD which tracker.debian.org gets its data from. For example, If I run this against UDD it returns "errors" none of which are actually errors: > jcowgill@quantz:~$ psql service=udd -x -c "SELECT * FROM upstream WHERE > source='easytag'" > -[ RECORD 1 > ]-----------+--------------------------------------------------------------------------------------------------------- > source | easytag > version | 2.4.2-1 > distribution | debian > release | sid > component | main > watch_file | version=3 > | > http://ftp.gnome.org/pub/GNOME/sources/easytag/(\d.)+/ \ > | easytag-([\d.]+)\.tar\.xz > | > signing_key_pgp | > signing_key_asc | > debian_uversion | 2.4.2 > debian_mangled_uversion | 2.4.2 > upstream_version | 2.4.2 > upstream_url | > http://ftp.gnome.org/pub/GNOME/sources/easytag/2.4/easytag-2.4.2.tar.xz > errors | uscan output on stderr: uscan: Newest version of > easytag on remote site is 2.4.2, local version is 2.4.2 > | uscan warn: No upstream tarball downloaded. No > further processing with mk_origtargz ... > | > | > warnings | No upstream tarball downloaded. No further > processing with mk_origtargz ... > | > status | up to date > last_check | 2016-02-26 00:04:48.688531 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. If all errors uscan gives are always given in the relevant dehs element, can the output from stderr simply be ignored? James
signature.asc
Description: This is a digitally signed message part
