[Bug 492609] Review Request: hmaccalc - Tools for computing and checking HMAC values for files

[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=492609


Jason Tibbitts <tibbs at math.uh.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody at fedoraproject.org    |tibbs at math.uh.edu
               Flag|                            |fedora-review?




--- Comment #1 from Jason Tibbitts <tibbs at math.uh.edu>  2009-04-01 18:03:28 EDT ---
Builds fine; rpmlint says:
  hmaccalc.x86_64: W: only-non-binary-in-usr-lib
which is true as there's only a directory and some small text files.  However,
it touches on my ignorance: I understand what this package does, but I don't
understand the conventions behind the .hmac files.  What specifically would
care whether the .hmac files were in a subdirectory of %{_libdir}, whether
they're off in /usr/share or even stuck in %{_bindir} with the executables? 
Other packages that have .hmac files seem to put them directly in with the
libraries. openssl, for instance, has them for the four libraries (two
symlinked) but not for the executable in /usr/bin.

Also, I understand the trick with __spec_install_post to get the hmac files
generated after everything's been processed and debuginfo has been stripped. 
However, the comment before that bit confuses me:
  # We need to regenerate the HMAC values after the buildroot policies have
  # mucked around with them.  This overrides the default which was in place
  # at least from Red Hat Linux 9 through Fedora 11's development cycle.
I'm reading into that implication there that something will generate .hmac
files as a normal part of building things and that needs overriding in this
case, but I don't think I've ever seen one that wasn't generated manually by a
package using exactly that __spec_install_post manipulation.  Am I
misunderstanding things?

Is it possible to run the included test suite?  I tried the naive approach, but
I just get:
+ ./run-tests.sh
  /usr/lib64/hmaccalc/sha1hmac.hmac: No such file or directory
which, I think, might be a clue to my first question above.


* source files match upstream.  sha256sum:
   c3f490fb6cbd8d11ba072f9278fc32bac76aa6de51c51167e213add52f5ff153  
   hmaccalc-0.9.5.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
? rpmlint has a complaint; I'm not sure how valid it is.
* final provides and requires are sane:
   hmaccalc = 0.9.5-1.fc11
   hmaccalc(x86-64) = 0.9.5-1.fc11
  =
   libnspr4.so()(64bit)
   libnss3.so()(64bit)
   libnss3.so(NSS_3.2)(64bit)
   libnss3.so(NSS_3.3)(64bit)
   libnssutil3.so()(64bit)
   libplc4.so()(64bit)
   libplds4.so()(64bit)
   libsmime3.so()(64bit)
   libssl3.so()(64bit)

? There's a test suite but I don't know if it can be run at build time.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.

-- 
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.