GNU bug report logs - #29187
flymake ruby and perl tests fail on rhel7.4

Previous Next

Full log

Message #30 received at 29187 <at> debbugs.gnu.org (full text, mbox):

From: joaotavora <at> gmail.com (João Távora)
To: Glenn Morris <rgm <at> gnu.org>
Cc: 29187 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#29187: flymake ruby and perl tests fail on rhel7.4
Date: Tue, 07 Nov 2017 22:58:35 +0000

Glenn Morris <rgm <at> gnu.org> writes:

> João Távora wrote:
>
>> This is bizarre, because I did manage to reproduce and fix, on a
>> separate Ubuntu machine I have access to, one of the errors that you
>> had, Glenn, and that was indeed due to the extra diagnostic line
>> produced by your perl.
>>
>> But I don't get any differences between interactive and non-interactive
>> cases and I can't understand how your test run could possibly have
>> succeeded interactively since it produces that same extra line.
>
> There's no difference between the interactive and non-interactive case
> for me with the Perl test (I don't think I said there was?).

Well, you did write "same here" after Dmitry said there was a
difference.

>> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>[...]
>>> It also fails here via 'make check' (with Ruby 1.9.3) but succeeds
>>> interactively.
>Same here.
 ^^^^^^^^^

>> and non-interactively (make check also works, obviuosly)
>>
>>    $ src/emacs -Q --eval "(setq load-prefer-newer t)" -l test/lisp/progmodes/flymake-tests.el --batch --eval "(ert-run-tests-batch-and-exit \"\")"
>
> This is not equivalent to make check, which sets HOME=/nonexistent.
> Indeed that is the cause of the issue for me:
>
> HOME=/nonexistent ruby -wc test/lisp/progmodes/flymake-resources/test.rb 
>
> fails with a ruby error:
>
> /usr/share/rubygems/rubygems/path_support.rb:68:in `path=': undefined
> method `+' for nil:NilClass (NoMethodError)
>        from /usr/share/rubygems/rubygems/path_support.rb:30:in `initialize'
>
> I don't use ruby and have no idea if this is normal.

Wow, subtle stuff. My ruby (2.3) doesn't crash. Does yours also fail if
you use a absolute path after -wc instead of a relative one?
>
> It does, thanks.

So I guess all that's missing is a fix to the ruby case. If the absolute
path doesn't fix it, I think we can fake a dummy HOME

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.