Following Emacs' transition to git, the hashes of commits have changed
because some commits were edited to remove bzr specific
referefences (e.g. revnos in commit messages).
Note: the equivalent bzr commit had revno 103620 on trunk, revid
cyd@stupidchicken.com-20110310234046-vzsm4s3pjxc1aids.
First line of commit: "Fix package.el handling of version numbers like
1.0pre6"
* recipes/package.rcp (package):
* test/travis-ci.sh: Update hash for last package.el version compatible
with Emacs 23.
Also skip testing with emacs-snapshot if only recipes have been updated.
* test/run-travis-ci.sh: Deleted.
* test/travis-ci.sh (prereqs, byte-compile, check-recipes,
check-whitespace): New functions.
* .travis.yml (language): emacs-lisp -> generic. emacs-lisp is not
recognized, so Travis would treat it as ruby and needlessly install
rvm.
(install, script): Call functions from travis-ci.sh.
- If the file was changed on the HTTP server before you restarted emacs,
the checksum wouldn't be recomputed because it would be taken from the
cache.
- The cached value was wrongly including the HTTP headers in the
computation. Added a test for this.
- Computing a SHA1 is not so expensive that it needs the complication of
caching.
* methods/el-get-http.el
(el-get-http-checksums): remove.
(el-get-http-retrieve-callback): don't compute hash on HTTP headers.
(el-get-http-compute-checksum): always compute a fresh hash.
* test/el-get-issue-1752.el: new test.
The travis script has set -e enabled which prints out command line to be
executed. However, it prints the command line after glob expansion, so
having recipes/*.rcp in a command would be a pain to scroll through.
- use github emacs mirror for travis test: repo.or.cz was down a few
times; since github.com must be up to run anything anyway, it's
preferable to rely on that instead.
- run all the apt commands separately; there have been some intermittent
failures, this should make it easier to diagnose.
- suppress curl progress bar
- show emacs --version before running tests
If a package to be init'd has new dependencies, simply install them
rather than throwing an error about missing packages. A warning about
changing non-whitelisted properties is still issued.
In particular I neglected the fact that I've introduced a conditional
which blocked package-refresh-contents from el-get-elpa-install in some
cases. Practically the smae bug which I attempted to fix, could have
been encountered if packages were installing in opposite order, whcich i
try to reflect in added variant of the test.
ELPA Package directories are named <package>-<version>. Previously
`el-get-elpa-package-directory' looked for package-dirs using
`all-completions' meaning anything starting with <package> would match.
This is problematic if a package is a prefix of another package, eg the
`s' and `solarized-theme' packages.
Instead of doing that, look for a directory that is precisely
<package>-<version> where <version> is something acceptable to
`version-to-list'.
Fixes#1189.
This test attempts to recreate the situation described in #809. The test
passes, which means either the issue has been fixed, or this test case
isn't actually testing the right thing.
closes#809