Re: RRID update on salsa on packages starting with A+B
On Wed, Mar 28, 2018 at 12:03:54PM +0200, Steffen Möller wrote:
> But I found artemis
> (https://salsa.debian.org/med-team/artemis/tree/master/debian/upstream)
> which was not touched for a while and looks syntactically just fine but has
> its RRIDs not shown.
Checking UDD log
blends_prospective_gatherer.log:2018-03-27 08:32:05,582 - ERROR - (110): Scanner error in file /srv/udd.debian.org/mirrors/machine-readable/a/artemis.upstream of debian-med: mapping values are not allowed here
blends_prospective_gatherer.log: Entry: artemis
Checking package:
$ yamllint debian/upstream/metadata
debian/upstream/metadata
1:1 warning missing document start "---" (document-start)
2:81 error line too long (111 > 80 characters) (line-length)
2:111 error trailing spaces (trailing-spaces)
3:81 error line too long (126 > 80 characters) (line-length)
12:81 error line too long (82 > 80 characters) (line-length)
13:81 error line too long (139 > 80 characters) (line-length)
23:81 error line too long (83 > 80 characters) (line-length)
24:81 error line too long (164 > 80 characters) (line-length)
25:81 error line too long (104 > 80 characters) (line-length)
34:81 error line too long (84 > 80 characters) (line-length)
41:9 error syntax error: mapping values are not allowed here
Well, yamllint is a bit picky but the mapping values error matches the
UDD importer.
So lets have a look:
$ git diff
diff --git a/debian/upstream/metadata b/debian/upstream/metadata
index 4bede0a..a9906a8 100644
--- a/debian/upstream/metadata
+++ b/debian/upstream/metadata
@@ -37,5 +37,5 @@ Registry:
Entry: SCR_004267
- Name: OMICtools
Entry: OMICS_00903
- - Name; bio.tools
+ - Name: bio.tools
Entry: artemis
... voila, the bug in question vanished.
> Please also have an eye on clonalframe
> (https://salsa.debian.org/med-team/clonalframe/tree/master/debian/upstream)
> which was not updated even though the other changes of mine seem to be all
> in.
Same here. Importer says:
blends_prospective_gatherer.log:2018-03-27 08:34:50,809 - ERROR - (110): Scanner error in file /srv/udd.debian.org/mirrors/machine-readable/c/clonalframe.upstream of debian-med: mapping values are not allowed here
$ yamllint debian/upstream/metadata
debian/upstream/metadata
1:1 warning missing document start "---" (document-start)
21:10 error syntax error: mapping values are not allowed here
$ git diff
diff --git a/debian/upstream/metadata b/debian/upstream/metadata
index 79c7b56..98566d5 100644
--- a/debian/upstream/metadata
+++ b/debian/upstream/metadata
@@ -17,5 +17,5 @@ Registry:
Entry: SCR_016060
- Name: bio.tools
Entry: NA
- - Name. OMICtools
+ - Name: OMICtools
Entry: NA
So please use yamllint on all your updates - if not on all at least
those that are suspicious since not showing up on the sentinel page. It
seems just editing in Salsa online is a bit error prone.
>From time to time (every half year or so) I'm doing some QA on the UDD
log but inbetween I will not notice those things. Here is the full list
of yaml issues in upstream files:
$ grep "ERROR.*\.upstream of" blends_prospective_gatherer.log
2018-03-27 08:32:05,582 - ERROR - (110): Scanner error in file /srv/udd.debian.org/mirrors/machine-readable/a/artemis.upstream of debian-med: mapping values are not allowed here
2018-03-27 08:33:15,614 - ERROR - (110): Scanner error in file /srv/udd.debian.org/mirrors/machine-readable/o/octave-stk.upstream of pkg-octave: mapping values are not allowed here
2018-03-27 08:33:17,622 - ERROR - (110): Scanner error in file /srv/udd.debian.org/mirrors/machine-readable/o/octave-divand.upstream of pkg-octave: mapping values are not allowed here
2018-03-27 08:34:00,876 - ERROR - (110): Scanner error in file /srv/udd.debian.org/mirrors/machine-readable/r/rapmap.upstream of debian-med: mapping values are not allowed here
2018-03-27 08:34:50,809 - ERROR - (110): Scanner error in file /srv/udd.debian.org/mirrors/machine-readable/c/clonalframe.upstream of debian-med: mapping values are not allowed here
> I'll wait for tomorrow to indicate the others. Anyway, good to hear that no
> extra upload is required.
I can confirm that for this kind of data no upload was required for
years.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: