All of lore.kernel.org
 help / color / mirror / Atom feed
From: Todd Zullinger <tmz@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] test-lib: try harder to ensure a working jgit
Date: Tue, 14 May 2019 21:18:51 -0400	[thread overview]
Message-ID: <20190515011851.GP3654@pobox.com> (raw)
In-Reply-To: <87o945wj7w.fsf@evledraar.gmail.com>

Hi,

Ævar Arnfjörð Bjarmason wrote:
> 
> On Tue, May 14 2019, Jonathan Nieder wrote:
> 
>> Todd Zullinger wrote:
>>
>>> The JGIT prereq uses 'type jgit' to determine whether jgit is present.
>>> While this should be sufficient, if the jgit found is broken we'll waste
>>> time running tests which fail due to no fault of our own.
>>>
>>> Use 'jgit --version' instead, to catch some badly broken jgit
>>> installations.
>>>
>>> Signed-off-by: Todd Zullinger <tmz@pobox.com>
>>> ---
>>> I ran into such a broken jgit on Fedora >= 30¹.  This is clearly a
>>> problem in the Fedora jgit package which will hopefully be resolved
>>> soon.  But it may be good to avoid wasting time debugging tests which
>>> fail due to a broken tool outside of our control.
>>>
>>> ¹ https://bugzilla.redhat.com/1709624
>>
>> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>>
>> It would be nice to describe that bug in the commit message, to save
>> readers some head scratching.
> 
> FWIW the jgit in Debian testing/unstable is similarly broken right now:
[...]

Hah, small world. :)

> So rather than describe specific bugs on RedHat/Debian maybe just say:
> 
>     This guards against cases where jgit is present on the system, but
>     will fail to run, e.g. because of some JRE issue, or missing Java
>     dependencies. Seeing if it gets far enough to process the
>     "--version" argument isn't perfect, but seems to be good enough in
>     practice. It's also consistent with how we detect some other
>     dependencies, see e.g. the CURL and UNZIP prerequisites.

Well said.  I indeed avoided putting the detail into the
commit message because it was such a Fedora-specific bug.
I'll update the commit message to add more details though,
borrowing liberally from^W^W^Wperhaps stealing your
suggested wording.

Thanks!

-- 
Todd

  reply	other threads:[~2019-05-15  1:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14  2:05 [PATCH] test-lib: try harder to ensure a working jgit Todd Zullinger
2019-05-14  2:14 ` brian m. carlson
2019-05-14  8:45   ` Jeff King
2019-05-15  0:52     ` Junio C Hamano
2019-05-15  1:12     ` Todd Zullinger
2019-05-15 23:20     ` brian m. carlson
2019-05-14  2:32 ` Jonathan Nieder
2019-05-14  8:09   ` Ævar Arnfjörð Bjarmason
2019-05-15  1:18     ` Todd Zullinger [this message]
2019-05-15  2:13       ` Junio C Hamano
2019-05-15  1:36 ` [PATCH v2] " Todd Zullinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190515011851.GP3654@pobox.com \
    --to=tmz@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.