Changelog:
- Configurable status line via -F option, see manpage for a listing of
format specifier.
- Improve display of device name in status line.
- Script: Binary transmission feature via "!<"
- Bugfixes
Changes since 1.6.0:
1.7.3 (3.4.2014)
- bugfix: test routines, gpg2 asked for passphrase although GPG_PW was set
1.7.2 (1.4.2014 "April,April")
- bugfix: debian Bug#743190 "duply no longer allows restoration without
gpg passphrase in conf file"
GPG_AGENT_INFO env var is now needed to trigger --use-agent
- bugfix: gpg keyenc test routines didn't work if GPG_PW was not set
1.7.1 (30.3.2014)
- bugfix: purge-* commands renamed to purgeFull, purgeIncr due to
incompatibility with new minus batch separator
1.7.0 (20.3.2014)
- disabled gpg key id plausibility check, too many valid possibilities
- featreq 7 "Halt if precondition fails":
added and(+), or(-) batch command(separator) support
- featreq 26 "pre/post script with shebang line":
if a script is flagged executable it's executed in a subshell
now as opposed to sourced to bash, which is the default
- bugfix: do not check if dpbx, swift credentials are set anymore
- bugfix: properly escape profile name, archdir if used as arguments
- add DUPL_PRECMD conf setting for use with e.g. trickle
Release 1.25.27 (released March 15, 2014):
Fix bug: When serializing a very large floating point number, sender
of an XML-RPC message adds some junk after the decimal point. With
assertion checking enabled, it just crashes. Broken in 1.15 (June 2008).
Changes since 0.7.5:
* added libav 10 and ffmpeg 2.2 support;
* fixed url parsing;
* fixed freezing on playback resume;
* fixed random freezing in the mplayer plugin;
* fixed reset selection of tracks when calling context menu;
* fixed multimedia keys support under win32.
(And update liburcu to 0.8.4 according to release notes for lttng 2.4.x.)
In addition to new features and bug fixes, version 2.4.x is needed to build
against Linux 3.12 (our new stable kernel).
Previously we were setting GRKERNSEC_PROC_USER y, which was a little bit
too strict. It doesn't allow a special group (e.g. the grsecurity group
users) to access /proc information - this requires
GRKERNSEC_PROC_USERGROUP y, and the two are mutually exclusive.
This was also not in line with the default automatic grsecurity
configuration - it actually defaults to USERGROUP (although it has a
default GID of 1001 instead of ours), not USER.
This introduces a new option restrictProcWithGroup - enabled by default
- which turns on GRKERNSEC_PROC_USERGROUP instead. It also turns off
restrictProc by default and makes sure both cannot be enabled.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
