georg@riseup.net:
> On 16-05-11 09:53:06, Jérémy Bobbio wrote:
> > For this reason, I think you should find a way to restore
> > `debian/ruby-tests.rake` and make it work with gpg2 as gpg1 is likely
> > to go away in some near future…
>
> - I've made some progress: […]
Great! :)
I'm surprised you need to both launch and reload gpg-agent. I think it
would also be much better to kill the agent once the tests have been
run.
> - AFAICT: Two last major showstoppers left, I need support with
> these, because I can't find a way on my own to solve these:
>
> - * One of the tests [1] fails. Running this gives:
> Failure: <GPGME::Error::BadPassphrase> exception expected but none was thrown.
>
> I guess the output of gpg changed during the transition from version
> 1.x to 2.x - but I didn't find a way how to overcome this.
> Still I'm unsure, because there is "no exception thrown".
>
> Should I remove this part? Could someone of you have a look into
> this?
After fiddling around, I've managed to understand what's happening: the
agent is caching the passphrase. So it doesn't ask gpg to enter a new
one, and so the wrong passphrase is never given to gpg. So I guess the
agent needs to be told to forget the passphrase before this particular
test can be run properly.
> - In 'debian/ruby-tests.rake', I've to set two env vars to a path
> pointing at the upstream provided gpghome (this is: the upstream
> provided gpghome inside the build dir) and reload gpg-agent
> afterwards, so it picks up these.
>
> I've added debian/gbp.conf and set the export-dir in there to
> '../build-area/'.
>
> Right now, the path in 'debian/ruby-tests.rake' is hardcoded, aka
> "ruby-mail-gpg-0.2.6", which will fail obviously in the future.
>
> So...I'm searching for a way to get the Debian package version of
> the build.
> How should I deal with this? I've had a look into the env vars which
> are exported if using gbp buildpackage, but didn't found one which
> would help in this case (as long as I read the manpage correctly).
>
> - Minor question:
>
> - In the upstream provided gpghome, there are two (binary) files,
> which, in my opinion, don't belong there: 'random_seed' and
> 'pubring.gpg~'. Using quilt gives, after adding the files to the
> patch, removing the files from the filesystem, and refreshing the
> patch, "diff failed". Doesn't this work for binary files? Or is it
> because one isn't supposed to remove the files from the fs? Again, I
> couldn't find something about this on the Internets..
Both the hardcoded path and the binary files have the same root cause:
this should all be generated on the fly as part of the test setup
process. I really don't think it's a good thing to have GnuPG binary
files shipped as part of the source.
Storing armored versions of the keys and importing them in a fresh
temporary directory is a more robust approach, IMHO… This is how I did
it for Schleuder some time ago. The “around” block creates a new
temporary directory, sets the right environment variable and import keys
before running the tests. See:
https://sources.debian.net/src/schleuder/2.2.1-2%2Bdeb7u1/spec/schleuder/crypt_spec.rb/?hl=28:45#L28
If that feels like too much changes, you could at least copy upstream
binary files in a temporary and use that as the GNUPGHOME. Otherwise,
there's a risk that testing twice in a row will give surprising results.
Hope that helps,
--
Jérémy Bobbio .''`.
jeremy.bobbio@irq7.fr : : : lunar@debian.org
`. `'` lunar@torproject.org
`-
Attachment:
signature.asc
Description: Digital signature