I have the same error. Solved by installing gnupg package.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug is still present. I consider this a packaging issue.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Similar problem here (no error, but just no PGP keys shown in Seahorse); one possible workaround solution is to migrate your keys from gpg to gpg2 as described on https://ask.fedoraproject.org/en/question/77129/gnome-passwords-and-keys-seahorse-doesnt-display-any-of-my-gpgpgp-keys/ :

    gpg --export-secret-keys >secretkeys
    gpg --export >publickeys
    gpg2 --import secretkeys publickeys

You should of course also wipe secretkeys after. Also note that you may only see it in “Passwords and Keys” [Seahorse] after a Desktop user session logout and re-login.

This is still a problem in Fedora 25. This is a packaging issue.

Package: https://admin.fedoraproject.org/pkgdb/package/rpms/seahorse/

Source: http://pkgs.fedoraproject.org/cgit/rpms/seahorse.git/tree/seahorse.spec

In case the maintainer(s) don't respond, we should probably go for the "non-responsive package maintainers" policy: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Btw, according to the package database, Matthias Clasen, who is an active package maintainer, also owns this package. And there is another packager awaiting review: https://admin.fedoraproject.org/pkgdb/package/rpms/seahorse/

Seahorse works just fine here with gpg2. Sounds like it's an issue with gpgme's automatic engine selection if it tries to run a non-existent /usr/bin/gpg as reported in comment #0. If this is still the case that it should be a gpgme bug.

As for the keys not showing up with gpg2 and only showing up with gpg that's reported in comment #7, that sounds like a migration issue that gpg2 should handle (but apparently doesn't).

Not sure there's anything to do here for Seahorse. Stef?

Created attachment 1244015 [details]
Reproducing comment #0, output of $ strace -f -e trace=process seahorse

(In reply to Kalev Lember from comment #11)
> Seahorse works just fine here with gpg2. Sounds like it's an issue with
> gpgme's automatic engine selection if it tries to run a non-existent
> /usr/bin/gpg as reported in comment #0. If this is still the case that it
> should be a gpgme bug.

Are you sure it is using gpg2, not gpg? Which of them do you have installed?
I tried to reproduce comment #0 and seahorse still uses /usr/bin/gpg although /usr/bin/gpg2 is installed. I still can reproduce that with only gnupg2 but not gnupg (1.4.x) installed. Note that seahorse does correctly start gpg2 at first, but still tries to use gpg (1) to import later.

> As for the keys not showing up with gpg2 and only showing up with gpg that's
> reported in comment #7, that sounds like a migration issue that gpg2 should
> handle (but apparently doesn't).

Yes, that's a known version intolerance issue with GnuPG. The solution is to only use one version and never downgrade. Since gpg2 has been around for a while, and to my knowledge all other GUI tools related to GnuPG are using version 2, so Seahorse should default to using version 2.

A truncated backtrace of running 

$ gdb seahorse
[reproduce comment #0 up to step 2]
Ctrl+C
(gdb) follow-fork-mode child
(gdb) break execve
(gdb) continue
[reproduce step 3]
(gdb) backtrace


#0  0x00007ffff3634c90 in execve () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff5049706 in g_execute (search_path_from_envp=0, search_path=0, envp=0x5555562aea40, argv=0x5555561d2690, file=0x5555562caee0 "/usr/bin/gpg") at gspawn.c:1678
#2  0x00007ffff5049706 in do_exec (child_err_report_fd=26, stdin_fd=<optimized out>, stdout_fd=30, stderr_fd=32, working_directory=working_directory@entry=0x0, argv=argv@entry=0x5555561d2690, envp=0x5555562aea40, close_descriptors=1, search_path=0, search_path_from_envp=0, stdout_to_null=0, stderr_to_null=0, child_inherits_stdin=0, file_and_argv_zero=0, child_setup=0x7ffff5b29250 <on_gnupg_process_child_setup>, user_data=0x7fffffffb540) at gspawn.c:1229
#3  0x00007ffff504a263 in fork_exec_with_pipes (intermediate_child=intermediate_child@entry=0, working_directory=0x0, argv=0x5555561d2690, envp=0x5555562aea40, close_descriptors=close_descriptors@entry=1, search_path=search_path@entry=0, search_path_from_envp=0, stdout_to_null=0, stderr_to_null=0, child_inherits_stdin=0, file_and_argv_zero=0, cloexec_pipes=0, child_setup=0x7ffff5b29250 <on_gnupg_process_child_setup>, user_data=0x7fffffffb540, child_pid=0x7fffffffb514, standard_input=0x7fffffffb510, standard_output=0x7fffffffb508, standard_error=0x7fffffffb50c, error=0x7fffffffb518) at gspawn.c:1426
#4  0x00007ffff504ace5 in g_spawn_async_with_pipes (working_directory=<optimized out>, argv=<optimized out>, envp=<optimized out>, flags=flags@entry=G_SPAWN_DO_NOT_REAP_CHILD, child_setup=child_setup@entry=0x7ffff5b29250 <on_gnupg_process_child_setup>, user_data=user_data@entry=0x7fffffffb540, child_pid=0x7fffffffb514, standard_input=0x7fffffffb510, standard_output=0x7fffffffb508, standard_error=0x7fffffffb50c, error=0x7fffffffb518) at gspawn.c:656
#5  0x00007ffff5b2af09 in _gcr_gnupg_process_run_async (self=0x55555629f170 [GcrGnupgProcess], argv=argv@entry=0x7fffffffb5b0, envp=envp@entry=0x0, flags=flags@entry=GCR_GNUPG_PROCESS_WITH_STATUS, cancellable=cancellable@entry=0x55555622a370 [GCancellable], callback=callback@entry=0x7ffff5b27920 <on_process_run_complete>, user_data=0x5555562de190) at gcr/gcr-gnupg-process.c:1041
#6  0x00007ffff5b278ea in _gcr_gnupg_importer_import_async (importer=<optimized out>, cancellable=0x55555622a370 [GCancellable], callback=0x7ffff7781cd0 <on_import_complete>, user_data=0x5555560c6830)
    at gcr/gcr-gnupg-importer.c:332
#7  0x00007ffff77818eb in gcr_import_button_clicked (button=<optimized out>)
    at ui/gcr-import-button.c:478
#8  0x00007ffff52db614 in _g_closure_invoke_va (closure=closure@entry=0x555555a0e290, return_value=return_value@entry=0x0, instance=instance@entry=0x5555560c6830, args=args@entry=0x7fffffffb890, n_params=<optimized out>, param_types=0x0) at gclosure.c:867
#9  0x00007ffff52f5dd9 in g_signal_emit_valist (instance=0x5555560c6830, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffb890) at gsignal.c:3300
#10 0x00007ffff52f643f in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3447
#11 0x00007ffff6f7478d in gtk_button_do_release (button=0x5555560c6830 [GcrImportButton], emit_clicked=<optimized out>) at gtkbutton.c:1843
#12 0x00007ffff6f747f5 in gtk_real_button_released (button=0x5555560c6830 [GcrImportButton])
    at gtkbutton.c:1961
#13 0x00007ffff52db614 in _g_closure_invoke_va (closure=closure@entry=0x555555a0e180, return_value=return_value@entry=0x0, instance=instance@entry=0x5555560c6830, args=args@entry=0x7fffffffbbf0, n_params=<optimized out>, param_types=0x0) at gclosure.c:867
#14 0x00007ffff52f5dd9 in g_signal_emit_valist (instance=0x5555560c6830, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffbbf0) at gsignal.c:3300
#15 0x00007ffff52f643f in g_signal_emit (instance=instance@entry=0x5555560c6830, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447
#16 0x00007ffff6f72be0 in multipress_released_cb (gesture=0x555556236260 [GtkGestureMultiPress], n_press=<optimized out>, x=<optimized out>, y=<optimized out>, widget=0x5555560c6830 [GcrImportButton])
    at gtkbutton.c:666
#17 0x00007fffee491c58 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#18 0x00007fffee4916ba in ffi_call (cif=cif@entry=0x7fffffffbf50, fn=fn@entry=0x7ffff6f72bc0 <multipress_released_cb>, rvalue=<optimized out>, avalue=avalue@entry=0x7fffffffbe20) at ../src/x86/ffi64.c:525
#19 0x00007ffff52dc0fa in g_cclosure_marshal_generic_va (closure=0x5555561fb3a0, return_value=0x0, instanQuit

If you need more details (full backtrace), please give me an email address + PGP key to send/encrypt to.

Aha! Looks like gcr is compiled to use /usr/bin/gpg instead of gpg2.

gcr-3.20.0-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb86e0feb

Can you try again with the linked gcr update, please?

gcr-3.20.0-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb86e0feb

gcr-3.20.0-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.