I have seen such failures and they were the result of digest verifification and signature verifification failing because the expetcet length of the didest or signature didn't match. The signing and verification is done by a postinstall scriptlet at the top of the sec file

%define __spec_install_post \
    %{?__debug_package:%{__debug_install_post}} \
    %{__arch_install_post} \
    %{__os_install_post} \
    $RPM_BUILD_ROOT/%{unsupported_tools_directory}/shlibsign -i $RPM_BUILD_ROOT/%{_libdir}/libsoftokn3.so \
    $RPM_BUILD_ROOT/%{unsupported_tools_directory}/shlibsign -i $RPM_BUILD_ROOT/%{_libdir}/libfreebl3.so \
    $RPM_BUILD_ROOT/%{unsupported_tools_directory}/shlibsign -i $RPM_BUILD_ROOT/%{_libdir}/libnssdbm3.so \
%{nil}
S
ince 3.14 the signing is done with DSA2 and SHA256 whereas previously (3.13.x) we were signing with DSA and SHA1. I bet in the buildroot for sparc{64} we have the older softoken/freebl libraries. 

Until all supprted platforms are at 3.14 we must to ensure that the signing tool is linking to the newest freebl library instead of the older version that may be in the system. On x86_64 and i686 we already had the system at 3.14 but for for the other platforms (sparc64, etc) that is not the case yet.

This is what I previosly had to solve this problem:

# Produce .chk files for the final stripped binaries
# keep the LD_LIBRARY_PATH line intil the sytem has been bootstrapped.
%define __spec_install_post \
    %{?__debug_package:%{__debug_install_post}} \
    %{__arch_install_post} \
    %{__os_install_post} \
    export LD_LIBRARY_PATH=$RPM_BUILD_ROOT/%{_libdir} \
    $RPM_BUILD_ROOT/%{unsupported_tools_directory}/shlibsign -i $RPM_BUILD_ROOT/%{_libdir}/libsoftokn3.so \
    $RPM_BUILD_ROOT/%{unsupported_tools_directory}/shlibsign -i $RPM_BUILD_ROOT/%{_libdir}/libfreebl3.so \
    $RPM_BUILD_ROOT/%{unsupported_tools_directory}/shlibsign -i $RPM_BUILD_ROOT/%{_libdir}/libnssdbm3.so \
%{nil}

I'll restore this version of the scriplet.

Soo,.. I should be able to bootstrap 3.14 with 

export LD_LIBRARY_PATH=$RPM_BUILD_ROOT/%{_libdir} \
    $RPM_BUILD_ROOT/%{unsupported_tools_directory}/shlibsign -i

and then rebuild it again normally into the tree?
 (or whenever I can get spot/dennis to do the deed)

If thats the case then would just adding in these lines would suffice?

%global bootstrap %{?_with_bootstrap:%{!?_with_bootstrap:0}
...

%if %{bootstrap}
export LD_LIBRARY_PATH=$RPM_BUILD_ROOT/%{_libdir} \
%endif
...

(thats just off the top of  my head, not tested!)

rpmbuild -ba -v --with bootstrap

Created attachment 671636 [details]
Fix post-install scriplet for signing tool to use in-tree freebl

shlibsign links with the just build freebl and verification will use the same algorithm used when signing.

Hi Bryce, 

Apologies for not having included your suggestions in my patch. I wanted to get a build going as soon as possible and stop the sparc breakage. Please let me know if nss-softokn-3.14.1-6.fc18 works for you on the sparc{64} build. Thanks.

-Elio

Umm don't think so,.. your attachment doesn't actually have
    export LD_LIBRARY_PATH=$RPM_BUILD_ROOT/%{_libdir} \
in it! 8)

+# until all mock platforms have been updated.
+#
 %define __spec_install_post \
     %{?__debug_package:%{__debug_install_post}} \
     %{__arch_install_post} \
@@ -16,7 +24,7 @@
 Summary:          Network Security Services Softoken Module
 Name:             nss-softokn

unless whats in bugzilla here differs from what is running through the build system 8) but I did it by hand here and after bootstrapping then yes it all comes good again thanks

Phil (resurrecting the sparc port in the fedora secondary archs)
=--=

Added the comments but forgot the line in question. New build soon. Thanks.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 
'version' of '18'.

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 prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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 to Fedora 18's end of life.

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 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.