gpgme 1.5.5 tests failing

Daiki Ueno ueno at
Wed Jul 1 11:18:34 CEST 2015

Werner Koch <wk at> writes:

> On Fri, 12 Jun 2015 23:19, dkg at said:
>> But...  should gpgme require the existence or proper configuration of
>> /dev/pts in some particular mode to be able to work?  It seems to me
>> that a system without /dev/pts at all should still be able to use gpgme,
> Right.  As long as stderr and stdout are not connceted to a tty there
> should be no problem.   Maybe due to setlocale ?

The error is around engine-gpg.c:518:

  if (isatty (1))
      int err;

      err = ttyname_r (1, dft_ttyname, sizeof (dft_ttyname));
      if (err)
	rc = gpg_error_from_errno (err);

With glibc and such chroot setting, I get:

- isatty (1) => returns 0
- ttyname (1) => returns NULL, and doesn't set errno
- ttyname_r (1, ...) => returns ENOTTY

I am not sure if either of them is posixly correct, but maybe we can
avoid the undefined behavior, by rewriting the above code to:

  err = ttyname_r (1, dft_ttyname, sizeof (dft_ttyname));
  if (err != ENOTTY)
      if (err)
	rc = gpg_error_from_errno (err);

This is what the 'tty' command (in coreutils) does.  I'm attaching a
tentative patch.

For reproducing the error, I used the mock command on Fedora:

  $ mock -r fedora-rawhide-x86_64 --init

  $ mock -r fedora-rawhide-x86_64 --rebuild gpgme*.src.rpm
  (This actually runs "make check", but succeeds because stdout is redirected)

  $ mock -r fedora-rawhide-x86_64 --shell
  <mock-chroot>sh-4.3# cd builddir/build/BUILD/gpgme-1.4.3
  <mock-chroot>sh-4.3# make check
  t-encrypt.c:60: GPGME: Inappropriate ioctl for device
  FAIL: t-encrypt
  t-encrypt-sym.c:67: GPGME: Inappropriate ioctl for device
  FAIL: t-encrypt-sym
  t-encrypt-sign.c:116: GPGME: Inappropriate ioctl for device

Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Work-around-isatty-misbehavior-in-chroot.patch
Type: text/x-patch
Size: 4639 bytes
Desc: not available
URL: </pipermail/attachments/20150701/48248073/attachment.bin>

More information about the Gnupg-devel mailing list