Following up on review of patch2044.

The reason for bundling the .gnupg directory is that key generation requires
lots of system entropy which is pretty soon exhausted if we generate keys in
the test scripts. This will then make gpg --key-gen (and thus the test
suite) hang without apparent reason.

1 patch for repository http://darcs.net/screened:

patch 2556f6181ff4661217b1f22546a5c3969692bdf8
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Jul 20 14:14:16 CEST 2020
  * add a test for gng signed send/apply

Attachments

• add-a-test-for-gng-signed-send_apply.dpatch
• patch-preview.txt
• unnamed

FYI the test harness just gets stuck on Windows when I run this test. I
haven't yet figured out why, darcs-test doesn't even seem to have
child processes running when it stops. I will try to debug it properly
more promptly than the previous tests I reported problems with...

> FYI the test harness just gets stuck on Windows when I run this test.
> I haven't yet figured out why, darcs-test doesn't even seem to have 
> child processes running when it stops. I will try to debug it
> properly more promptly than the previous tests I reported problems
> with...

This is most probably because the directory where gpg stores its
internal data is named differently i.e. not $HOME/.gnupg. If this is the
case then we will have to rename the directory after unpacking it on
Windows.

>> FYI the test harness just gets stuck on Windows when I run this test.
>> I haven't yet figured out why, darcs-test doesn't even seem to have 
>> child processes running when it stops. I will try to debug it
>> properly more promptly than the previous tests I reported problems
>> with...
> 
> This is most probably because the directory where gpg stores its
> internal data is named differently i.e. not $HOME/.gnupg. If this is the
> case then we will have to rename the directory after unpacking it on
> Windows.

I'm using gpg from mingw/msys and I do have a $HOME/.gnupg

But I experimented with the test a bit more and noticed that gpg-agent
was running trying to use $APPDATA/gnupg, which also has some plausible
looking content. When I kill gpg-agent then the test stops hanging and
fails, even though gpg itself didn't appear to be running at that point.

This is all even though the test is of course supposed to be isolated -
this is probably tricky to do perfectly when running under my user.

So I think I need to figure out exactly what is going on with my GPG
setup. But also I'm now a bit nervous that the test does an 'rm -rf
.gnupg' in case I ever run it in a non-isolated way :-)

I was having similar problems when I tried to run the test remotely via ssh
on another Linux machine. After several trials including re-creating the
gnupg home directory more than once, I have now got it working for me. I
hope this also fixes the problem on Windows.


1 patch for repository http://darcs.net/screened:

patch d18a97df3bde6a17b2ae33ed61b9d655b13e645d
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Jul 20 14:14:16 CEST 2020
  * add a test for gng signed send/apply

Attachments

• add-a-test-for-gng-signed-send_apply.dpatch
• patch-preview.txt
• unnamed

fails - see attached. I haven't had a chance to investigate at all.

Attachments

• gpg.txt

PS next time you amend please fix gng => gpg in the description :-)

> fails - see attached.

Hmm. It says

| export DARCS_TEST_GPG_OPTIONS="--homedir $(pwd)/gpghome"
| ++ pwd
| ++ ghc --make -o hspwd /home/ganesh/darcs/screened/tests/bin/hspwd.hs
| ++ ./hspwd
| + export 'DARCS_TEST_GPG_OPTIONS=--homedir
C:\Users\Ganesh\AppData\Local\Temp\tmpC31E/gpghome'
| + DARCS_TEST_GPG_OPTIONS='--homedir
C:\Users\Ganesh\AppData\Local\Temp\tmpC31E/gpghome'

[...]

| gpg: keyblock resource
'/c/Users/Ganesh/AppData/Local/Temp/tmpC31E/S/C:\Users\Ganesh\AppData\Local\Temp\tmpC31E/gpghome/pubring.kbx':
No such file or directory

I guess we should not use the hspwd here, because that means we get a
path with mixed '\\' and '/' separators, which cannot be properly translated
back to a native Windows path. I replaced it with '/bin/pwd'. Might work or
not.

1 patch for repository http://darcs.net/screened:

patch f5c6bd16d406ca5d8ddb0cda2e7417512a9e0c6b
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Jul 20 14:14:16 CEST 2020
  * add a test for gpg signed send/apply

Attachments

• add-a-test-for-gpg-signed-send_apply.dpatch
• patch-preview.txt
• unnamed

Unfortunately this now gets stuck again until I kill gpg-agent. Before
debugging it, I started googling, and came across this long thread:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840669

My two takeaways were that gpg is amazingly unfriendly to programmatic
usage, and that we should be setting GNUPGHOME. I'll have a go at that
the next time I look at this patch, if you don't figure something out
first.

Here is yet another version. I removed the DARCS_TEST_GPG_OPTIONS hack in
favour of using GNUPGHOME.

From the thread you linked I learned that to manipulate the gpg-agent
explicitly, you need to use gpgconf.

I added explicit steps to create a socket directory, kill the gpg-agent, and
finally remove the socket directory. Removing the socket directories is
needed because otherwise these directories accumulate and fill up /run/user
each time you run the test.


1 patch for repository http://darcs.net/screened:

patch 83c95346d569717ac2fcda9256d56567371be4bb
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 28 10:48:18 CEST 2020
  * add a test for gpg signed send/apply

Attachments

• add-a-test-for-gpg-signed-send_apply.dpatch
• patch-preview.txt
• unnamed

2 patches for repository http://darcs.net/screened:

patch 83c95346d569717ac2fcda9256d56567371be4bb
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 28 10:48:18 CEST 2020
  * add a test for gpg signed send/apply

patch 13a28cdd2ada9c1ce2deee15a2cc92facd1c0851
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 28 12:08:15 CEST 2020
  * tests/send_apply_signed.sh: also kill gpg-agent initially

Attachments

• add-a-test-for-gpg-signed-send_apply.dpatch
• patch-preview.txt
• unnamed

Please disregard the latest patch I sent. It destroys the ability to 
run the tests in parallel.

Do you want me to try the first one (83c95346d569717ac2fcda9256d56567371be4bb)
or to disregard both for now and wait for another update?

Yes, please test the first one 
(83c95346d569717ac2fcda9256d56567371be4bb), ignoring 
13a28cdd2ada9c1ce2deee15a2cc92facd1c0851 which is broken. It's in 
the second to last patch bundle:

http://bugs.darcs.net/file8852/add-a-test-for-gpg-signed-
send_apply.dpatch

If this also hangs I think we have to investigate your gpg 
installation more closely.

Failed again. 'gpgconf --create-socketdir' fails even when I run it from the
command-line with no special environment, so I agree something must be up
with my gpg installation in some sense, though I haven't done anything weird
to it deliberately.

Attachments

• gpg.txt

I am marking this followup-requested, hoping that at some point 
someone will able to help us get this test to work on Windows.

I am giving up on getting this to work on OSes other than Linux. Will
self-accept.

1 patch for repository http://darcs.net/screened:

patch ec6761124953ef5f117a30d5c7a684f612622b62
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jul 28 10:48:18 CEST 2020
  * add a test for gpg signed send/apply (Linux only)
  
  On both Windows and MacOS, gpgconf --create-socketdir fails with "no
  /run/user dir; using homedir as fallback; error creating socket directory".

Attachments

• add-a-test-for-gpg-signed-send_apply-_linux-only_.dpatch
• patch-preview.txt
• unnamed

Now it fails on Linux, too, at least in the CI. Will *not* self-
accept!