|author||Joey Hess||2017-07-30 11:13:15 -0400|
|committer||Joey Hess||2017-07-30 11:13:15 -0400|
Diffstat (limited to 'doc/forum/propellor_failed_to_sign_the_commit/comment_1_c1dab7554841bd88d2109e9d46b31102._comment')
1 files changed, 30 insertions, 0 deletions
diff --git a/doc/forum/propellor_failed_to_sign_the_commit/comment_1_c1dab7554841bd88d2109e9d46b31102._comment b/doc/forum/propellor_failed_to_sign_the_commit/comment_1_c1dab7554841bd88d2109e9d46b31102._comment
new file mode 100644
@@ -0,0 +1,30 @@
+ subject="""comment 1"""
+I guess the problem involves running propellor at a unix tty, not in a
+GUI's virtual terminal?
+My limited understanding of `GPG_TTY`, refreshed by re-reading this ooold
+thread <https://bugs.debian.org/316388> is that gpg is normally able to
+detect if it's in a GUI or at a tty, and will prompt in the tty if
+necessary. Where that may fall down is when gpg is run with its stdio
+connected to pipes, since then probably isatty fails. Although in at least
+some cases, gpg apparently then
+[falls back to /dev/tty](https://dev.gnupg.org/T1434).
+Propellor runs gpg with stdin and stdout piped to it when eg, decrypting
+the privdata file. I tried `propellor --list-fields` at the linux console
+and it fails there.
+But, when I tried `propellor --spin host` at the linux console, that worked
+ok, including making the gpg signed git commit. Of course git is running
+gpg in this case, and perhaps my version of git has its own way to avoid
+This does seems like something propellor could work around fairly
+(See also [[propellor_and_gpg2]].)