Compatibility notes:
- you may need to use -v (or --info) more often to actually see
output emitted at INFO log level (because it is suppressed at
the default WARNING log level). See the general section in the
usage docs.
- for borg create, you need --list (additionally to -v) to see
the long file list (was needed so you can have e.g. --stats
alone without the long list)
- see link below about BORG_DELETE_I_KNOW_WHAT_I_AM_DOING
(was: BORG_CHECK_I_KNOW_WHAT_I_AM_DOING)
More: https://github.com/borgbackup/borg/blob/0.30.0/docs/changes.rst
‘When upgrading to 0.29.0 you need to upgrade client as well as server
installations due to the locking and commandline interface changes
otherwise you’ll get an error msg about a RPC protocol mismatch or a
wrong commandline option. if you run a server that needs to support both
old and new clients, it is suggested that you have a “borg-0.28.2” and a
“borg-0.29.0” command. clients then can choose via e.g. “borg
–remote-path=borg-0.29.0 ...”.’
‘The default waiting time for a lock changed from infinity to 1 second
for a better interactive user experience. if the repo you want to access
is currently locked, borg will now terminate after 1s with an error
message. if you have scripts that shall wait for the lock for a longer
time, use –lock-wait N (with N being the maximum wait time in seconds).’
All changes: http://borgbackup.readthedocs.org/en/stable/changes.html
This also fixes the same build failure present in `scrypt-1.2.0`,
which is quite trivial.
(partially cherry picked from commit 54c7053b)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Many (less easily automatically converted) old-style strings
remain.
Where there was any possible ambiguity about the exact version or
variant intended, nothing was changed. IANAL, nor a search robot.
Use `with stdenv.lib` wherever it makes sense.
S3QL is a file system that stores all its data online using storage
services like Google Storage, Amazon S3, or OpenStack. S3QL effectively
provides a hard disk of dynamic, infinite capacity that can be accessed
from any computer with internet access running Linux, FreeBSD or OS-X.
I don't know what changed, but apparently something did. We're using
fetchzip and the 0.14 tag doesn't seem to have moved (AFAICS).
Build and run-tested.
For reference, the (current) annotated tag '0.14' is dated
"Wed Dec 17 23:32:11 2014 +0100" and points to commit
f342621dff8065b29aeda238ccce5ac92d04f5b6 ("Preparing release").
Without this one cannot mount the backup repository:
$ attic mount /backups/backup.attic mnt
attic: the "llfuse" module is required to use this feature
attic: Exiting with failure status due to previous errors
fetchzip calculates the hash of the extracted archive, so that
(irrelevant) changes done to the dynamically generated archive doesn't
cause our hash to be outdated.
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
