list mirror (unofficial, one of many)
 help / color / Atom feed
From: Todd Zullinger <>
To: SZEDER Gábor <>
Cc:, Henning Schild <>
Subject: Re: [PATCH 0/2] t/lib-gpg: a gpgsm fix, a minor improvement, and a question
Date: Thu, 14 Feb 2019 01:32:02 -0500
Message-ID: <> (raw)
In-Reply-To: <>

SZEDER Gábor wrote:
> On Sat, Feb 09, 2019 at 06:05:53PM -0500, Todd Zullinger wrote:
>> SZEDER Gábor wrote:
>>> Just curious: how did you noticed the missing GPGSM prereq?
>> I just grep the build output for '# SKIP|skipped:' and then
>> filter out those which I expect (thing like MINGW and
>> NATIVE_CRLF that aren't likely to be in a Fedora build).
>> Far more manual than the slick method you have below. :)
> Yeah, but yours show the SKIP cases, too, i.e. when the whole test is
> skipped by:
>   if check-something
>   then
>         skip_all="no can do"
>         test_done
>   fi
> I didn't bother with that because in those cases the prereq is not
> denoted by a single word, but rather by a human-readable phrase, and
> becase 'prove' runs those skipped test scripts at last when running
> slowest first, so I could already see them anyway.

Ahh, good points.

>>> I'm asking because I use a patch for a good couple of months now that
>>> collects the prereqs missed by test cases and prints them at the end
>>> of 'make test'.  Its output looks like this:
>>> Since you seem to be interested in that sort of thing as well, perhaps
>>> it would be worth to have something like this in git.git?  It's just
>>> that I have been too wary of potentially annoying other contributors
>>> by adding (what might be perceived as) clutter to their 'make test'
>>> output :)
>> Indeed, I think that would be useful.  At the very least,
>> the .missing_prereqs files look quite handy.  I wouldn't
>> mind the output from 'make test' either, but building
>> packages surely shifts my perspective toward more verbose
>> build logs than someone hacking on git regularly and reading
>> the 'make test' output.
> The problem with those files is that a successful 'make test'
> automatically and unconditionally removes the whole 'test-results'
> directory at the end.  So a separate and optional 'make test ; make
> show-missed-prereqs' wouldn't have worked, that's why I did it this
> way.
> I think it would be better if we kept the 'test-results' directory
> even after a successful 'make test', there are some interesting things
> to be found there:

Maybe that's something which could be controlled with a make
var, to allow folks like us to keep the tests but clean them
up by default for everyone else?

Though even in the fedora package builds, I don't have
access to poke around in test-results and likely wouldn't
want to make the effort to extract the results and dump them
into the build logs (like ci/util/ does
for the trash dirs).

>> I can certainly live with setting '--root' to a shorter path
>> and waiting to see if GnuPG upstream will come up with
>> something a little more friendly to users like us - running
>> gpg in a test suite.
> Are they aware of the issue?

Yeah, it was filed as, as a
result of the gnupg-users thread you mention below.  There
hasn't been any progress on it since 2017 though, so it's
doubtful that upstream will fix it anytime soon.  If (or
when) it's resolved, I wouldn't be surprised if only gnupg
>= 2.3 included the fix.  So we'll probably have numerous
systems with this issue for quite some time.

> suggests to put the socket in '/var/run/user/$(id -u)', but that's for
> the "regular" use case, and we should take extra steps to prevent the
> tests' gpg from interfering with the gpg of the user running the
> tests.  Not sure it would work on macOS.  And ultimately it's not much
> different from your GIT_TEST_GNUPGHOME_ROOT suggestion.
> Then I stumbled on these patches patches:
> suggesting that at least one other project is working around this
> issue instead of waiting for upstream to come up with something.

Heh, the gnupg ticket mentions that the notmuch project
similarly had to work around gpg2's socket handling for
their tests:

>> Though if we do just wait it out,
>> maybe we could/should add a note in t/README or t/
>> about this to warn others?
> Well, a comment could help others to not waste time on figuring out
> this "path is too long for a unix domains socket" issue...  but now
> they will be able to find this thread in the list archives as well :)

True.  Will they curse us for not adding a comment to save
them some effort or can we just say we were waiting for them
to submit such a patch? ;)

> On a related note: did you happen to notice occasional failures with
> gpg2 on Fedora builds?  I observed some lately in tests like
> './' or '' on the Travis CI macOS
> builds: it appears as if the gpg process were to die mid-verification.
> Couldn't make any sense of it yet, though didn't tried particularly
> hard either.

I have not seen any such failures.  I've done a few dozen
test builds on fedora systems where /bin/gpg is gnupg-2.2
and other than the socket path issues, the tests have all
worked well.  But I'll be sure to mention it if I do run
into any such failures.


  reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08  3:17 Todd Zullinger
2019-02-08  3:17 ` [PATCH 1/2] t/lib-gpg: quote path to ${GNUPGHOME}/trustlist.txt Todd Zullinger
2019-02-08 20:11   ` SZEDER Gábor
2019-02-08 20:25     ` Todd Zullinger
2019-02-08 20:35       ` SZEDER Gábor
2019-02-08  3:17 ` [PATCH 2/2] t/lib-gpg: drop redundant killing of gpg-agent Todd Zullinger
2019-02-08  8:33 ` [PATCH 0/2] t/lib-gpg: a gpgsm fix, a minor improvement, and a question Henning Schild
2019-02-08 18:04   ` Junio C Hamano
2019-02-09 14:06 ` SZEDER Gábor
2019-02-09 23:05   ` Todd Zullinger
2019-02-11 19:51     ` SZEDER Gábor
2019-02-14  6:32       ` Todd Zullinger [this message]
2019-02-12  0:44   ` Jeff King
2019-02-12  2:38     ` Junio C Hamano
2019-02-12  2:45     ` SZEDER Gábor

Reply instructions:

You may reply publically 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:

  List information:

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

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone