On 16-05-16 12:32:48, georg@riseup.net wrote: > On 16-05-16 12:04:38, Jérémy Bobbio wrote: > > 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. > > I could generate the keys on the fly sure...but, not sure if I'm missing > something here: Right now the quilt patch which injects gpg.conf and > gpg-agent.conf into the upstream provided gpghome inside the build dir. > Even if I would generate the keys myself: How would I get these two > configs into a temp dir, without the need to specify the path the configs > should be copied from? ...or, if going the "generate all the stuff on the fly route": Should I create gpg.conf and gpg-agent.conf as well, and not use a patch for these?
Attachment:
signature.asc
Description: Digital signature