[pkg-gnupg-maint] Bug#902316: Bug#902316: gnupg failing completely in dgit autopkgtests [and 1 more messages]

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#902316: gnupg failing completely in dgit autopkgtests [and 1 more messages]"):
> Hi Ian--
> 
> I don't know what the current status of the failing tests suites is for
> dgit -- last i heard, you had to have major, clunky workarounds to avoid
> problems with concurrent access to gpg-agent, or else gpg-agent would
> (intermittently, unpredictably) fail on some requests.
> 
> Please correct me if that description is wrong.  It sounds pretty
> frustrating.

Hi.  The workarounds are horrific, yes.  That description is accurate.
These workarounds have been working, so I don't know what bug(s)
remain.

> I'd like to nudge upstream about this, but getting feedback in the wild
> would be really useful.
> 
> I don't know whether you have any patience left to experiment with this,
> or whether you're still using gpg at all, but if you are, this would be
> a useful test for me:
> 
>  - set aside the scaffolding you used as a workaround to avoid these
>    failures
> 
>  - reproduce the failure
> 
>  - add "auto-expand-secmem" to the relevant gpg-agent.conf before you
>    start the agent for dgit
> 
>  - try to reproduce the failure again

Why do you think this option might make any difference ?  Doesn't
whatever condition it avoids produce an error message somewhere ?

I remember being fairly convinced that the real problem was simply
that gnupg and its various daemonic subprocesses didn't have a
race-free startup/shutdown approach.  From the sound of the option
that doesn't seem likely to be the issue.

> Sorry for the hassle here, and i hope this is useful in moving the
> situation forward.  (if you've given up, that's also fair -- please let
> me know if that's the case so i can try to track down the errors in a
> more synthetic context).

At the very least I could point you to the tests.

The test site is src:dgit and is a standard autopkgtest suite which
you can run via adt-run.  But to run the tests ad-hoc in a highly
concurrent mode,
    [ install the test dependencies, sorry I don't know
      a better way than to read debian/test/control and prat
      about ]
    dgit clone dgit  # or git clone salsa something something
    cd dgit
    tests/using-intree tests/run-all

If you have `nproc' installed it will parallelise.

I forget precisely how to disable the workarounds, but I think,
in tests/setup/gnupg, comment out the line
         t-tstunt gpg
and I think all the several bodges hang off that.

This way of disabling the bodges will also disable passing some other
options to gpg-agent, notably --debug-quick-random, which I don't
think there was a way to easily control other than by wrapping
gpg-agent.

AFAICT the bodges are in
    tests/tstunt/gpg
    tests/tstunt/gpg-withagent
    tests/tstunt/gpg-agent
and tests/tstunt/gpg-locked is a previous attempt which is no longer
used.

HTH.

Regards,
Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.