Ok, switched to 8th version for auto-running dpkg-gensymbols, but some
DDs (on #d-mentor) prefer to package with 7th debhelper to simplify
backporting.

> * I'm not sure what I should think about debian/Makefile-rhash-1.2.6rc1.
> Why didn't you merge those changes with your upstream Makefile, since
> you are upstream yourself? If you really want to keep it out of your
> upstream source, please use a quilt patch [3] instead.

The Makefile-rhash-1.2.6rc1 is already upstream. The RHash v1.2.6 is
actively developed and can't be released half-done.
This Makefile is needed, cause it has better support for SONAME and
library installation/testing. It helped to write better rules file.
You sound reasonable about making quilt patch, but putting auxiliary
file into debian is much simpler, than hunting lintian warnings on
absent source/option file. That way I can concentrate on development
instead of packaging issues.

a few notes about your package you may want to consider (I'm no DD, so I
can't sponsor you though):
* debian/changelog: Please don't explain in the changelog what your
package is for. We have a short and a long description for that. See [1]
for some hints. You should neither mention the SONAME change there
unless you changed it for the Debian package exclusively. If the latter
you might want to elaborate the reason in a README.Debian file.
* Please push debhelper compatibility to version 8 (debian/compat,
debian/control), see debhelper(7).
* debian/control: It is considered a best practice to have VCS links in
debian/control which point to the repository where you develop the
Debian package. See [2].
* Do you really need the minor version in the SONAME (and hence
correctly reflected in the package name)? It is not wrong to do so, but
since your package is new and your both, major and minor version are 0
you could probably just use the major version instead of an odd name
like librhash0.0.
* You replicate the package priority for your binary packages when
compared to the source package in debian/control. No need for that
unless you change priorities for binary packages.
* I'm not sure what I should think about debian/Makefile-rhash-1.2.6rc1.
Why didn't you merge those changes with your upstream Makefile, since
you are upstream yourself? If you really want to keep it out of your
upstream source, please use a quilt patch [3] instead.
* Your upstream sources are missing copyright headers. Please consider
adding them.
* You could earn some bonus points for shipping a symbol file, see
dpkg-gensymbols(1)
* Your package synopsis should not start with an upper case letter, see
[4]. Long description is fine, but I'm not entirely happy with the
synopsis lines for each package. Tastes may vary.
* Your debian/copyright provides conflicting license headers. I'm aware
yor package is dual-licensed, see DEP-5 on how to specify such use
cases, "Syntax" in [5]. Also consider the MIT hint mentioned in DEP-5.
Moreover don't use hash marks like programming style comments, use the
"Comment" header instead.
* You ship some cryptographic algorithms, I hope you checked all legal
issues with that?
[1]
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog
[2]
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-vcs
[3] http://wiki.debian.org/UsingQuilt, among others
[4]
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-desc-basics
[5] http://dep.debian.net/deps/dep5/