On Fri, 2016-01-15 at 17:07 +0000, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH OSSTEST] make-flight: Support specifying > a mini-os tree+revision"): > > On Fri, 2015-12-11 at 15:16 +0000, Ian Jackson wrote: > > unable to determine vcs > > bash: line 5: fail: command not found > > > > I'm not sure if this is a bug (i.e. it was intended to be "echo fail") > > or > > if it is deliberately using a non-existent command (which seems risky > > to > > me). > > It's deliberately using the command `fail' which is supposed to be in > scope and fail. I think this is harmless.
Where does that command come into scope from? Are you thinking of the sub fail() in Perl (from Osstest::TestSupport)? The fail quoted above is from: sub dir_identify_vcs ($$) { my ($ho,$dir) = @_; return target_cmd_output($ho, <<END); set -e if ! test -e $dir; then echo none; exit 0; fi cd $dir (test -e .git && echo git) || (test -d .hg && echo hg) || (echo >&2 'unable to determine vcs'; fail) END } i.e. it is in a shell snippet run on the target. I'm not sure where fail would come into scope in that context. I don't see it in the tcmd infrastructure. > > All the other store_revisions refer to the symlink rather than the > > -remote > > which is the actual clone (when one is made), so I don't think > > s#extras/mini-os#extras/mini-os-remote# is the answer. Perhaps "fail" > > should become "echo fail" and store_revision should treat that like it > > does > > fail (which is to accept it if $optional). > > That would be tolerable, I think. It's probably the best answer. I'll wait and check I'm not terribly confused above before moving in this direction. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel