[Bug 596138] Review Request: nss-gui - A graphical user interface for NSS security databases

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=596138

--- Comment #13 from Kai Engert (kaie) <kengert at redhat.com> 2011-01-13 14:52:41 EST ---
I think I adressed all your comments (besides the one that the purpose of the
package is cryptic).

New spec uploaded to
http://kuix.de/fedora/nss-gui/nss-gui.spec

New SRPM uploaded to
http://kuix.de/fedora/nss-gui/nss-gui-0.3.5-1.fc14.src.rpm


Today I wrote a manpage, added a lincese file, fixed some dependencies, and
made a new release.

I noticed a missing dependency, added:
    Requires:         boost-program-options

Also, I added the required dependencies necessary to build a manpage using the
AsciiDoc tool.


More replies inline:


> Even though it's a small package, it still needs a bit of work.  Did you ever
> run rpmlint over the srpm

    $ rpmlint SRPMS/nss-gui-0.3.4-1.fc14.src.rpm
    nss-gui.src: W: invalid-url Source0: nss-gui-0.3.4.tar.bz2
    1 packages and 0 specfiles checked; 0 errors, 1 warnings.

I've now changed Source0 to a real URL pointing to the released tarball.
The warning is gone.


> and resulting binary rpms?  It's expected that you do so.
>   nss-gui.x86_64: W: no-documentation
>   nss-gui.x86_64: W: no-manual-page-for-binary nss-gui

Thank your for reminding me.
Now I did, and I fixed the resulting mistakes.
Result for the new version is:

    $ rpmlint RPMS/i686/nss-gui-0.3.4-1.fc14.i686.rpm
    1 packages and 0 specfiles checked; 0 errors, 0 warnings.


> It might be nice to have some documentation.  It would also be nice to have
> some indication of the license.

The header in the spec file indicates that it's triple license as usually used
for Mozilla software: MPL/GPL/LGPL.

I added a LICENSE file that contains the MPL 1.3 license text.


>   nss-gui-debuginfo.x86_64: E: debuginfo-without-sources
> This generally indicates a build problem and indeed it seems that the compiler
> is not being called with the proper flags.  You'll need to figure out how to
> pass %optflags or $RPM_OPT_FLAGS.  Looks like this will involve Makefile
> patching as the included makefile doesn't seem to pay attention to anything.

Still using a minimal Makefile, but this is now fixed:

    $ rpmlint nss-gui-debuginfo-0.3.5.beta1-1.fc14.i686.rpm 
    1 packages and 0 specfiles checked; 0 errors, 0 warnings.


> The use of macros in the spec is inconsistent.  Generally you should just not
> use %{__rm} and such unless for some reason you really like pointless typing,
> but if you really do want to use those macros then you also need to use %{__cp}
> and %{__make} and such.

Fixed. No longer using macros for rm, install, mkdir.


> The description could use a bit less cryptic, I think.  If this is end-user
> software then some additional explanation is warranted.  Perhaps that's why you
> haven't attracted any reviewers; they can't figure out what it's supposed to
> do.

I can't do much about this one.
As of today, most users will not run it.

In the future, this app (or a replacement) might turn into the user's
central application for managing the user's private keys and certificates,
the CA certificates the user trusts, etc.

However, we're not there yet.
Today, users manage their data separately in each application, for example
using the certificate manager available in Firefox or Thunderbird.

Before we can make this claim (this tool is universal), all applications
will have to change to using the shared NSS database for crypto objects.

Today this software is mostly for security experts and administrators.
However, I know of corporate deployments that are waiting for this tool to 
become available.

We need to make a first step.


> The software doesn't seem to work for me.  I built in mock for x86_64 rawhide
> and installed it on a rawhide VM; nss-gui fails to start:
> 
> Error: Platform version '2.0b7' is not compatible with
> minVersion >= 1.9
> maxVersion <= 1.9.2.*
> 
> At the least that indicates that some dependencies are off.

Sorry, it had bitrotted since I had submitted it.

Rawhide uses a newer XULRunner runtime environment.
It's still compatible, though.
I've updated the compatibility version, which should work.

I will find a rawhide machine to get this version string tested.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.