debian-rcm - Debian packaging for rcm

	Commit message (Collapse)	Author	Age
*	Do not depend on readlink(1) or -q	Jarkko Kniivilä	2015-11-01
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	Solaris 10 lacks readlink(1). Additionally, its different grep(1) and diff(1) do not take a `-q` flag. Use a Perl one-liner instead of readlink(1) which is missing on Solaris 10. Also because /usr/bin/grep and diff(1) don't understand the `-q` option, make them go quiet by redirecting stdout to `/dev/null` instead. The Perl dependency only exists in the test suite, so it does not incur a runtime penalty for end users. This is to work around the fact that readlink(1) is missing on Solaris. The tradeoff is: on Solaris, installing third-party software (readlink) is a pain, whereas on e.g. FreeBSD installing third-party software (Perl) is simple and common.
*	Only use the host's name in the test	Mike Burns	2014-11-19
\| \| \| \| \| \| \| \| \| \| \| \|	The test uses `$(hostname)`, which can produce the FQDN; however, the code only uses the host name portion of that. Modify the test to do the same by defining a `hostname` function that calls the hostname(1) binary then pipes it through sed(1). Use command instead of hardcoding the path. OS X uses `$HOSTNAME` instead of the result of hostname(1). In the test suite, use `$HOSTNAME` first, falling back to hostname(1).
*	Manually resolve symlinks in test helpers	Melissa Xie	2014-11-17
\| \| \| \| \| \| \| \| \| \| \| \|	Mac OS X's `readlink` command does not support the same options as GNU, FreeBSD, and other operating systems, nor does it support canonicalizing symlink resolutions. In place of `readlink`, we're going to borrow [this] suggested implementation from the community. [this]: http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac
*	An integration test suite	patrick brisbin	2014-04-08
	This test suite uses cram to run integration tests through `/bin/sh`. The tests are all high-level acceptance tests; they should work regardless of the implemention code. To run them, you must first install cram: sudo pip install cram Then the `check` target will run them: make check Failure output should be printed clearly to stdout, but in general: full test output is in `test/test-suite.log` and output specific to a test named `foo.t` is in `foo.t.log`. Tests are now encouraged in `CONTRIBUTING.md` as part of the normal pull request process. This is a TAP-enabled test suite.