This patches the ffmpeg command path so that it will work without ffmpeg
being in the user's current path. The commit contains a suggestion from
me to patch command_output() instead of just replacing "ffmpeg" so that
if a user configuration alters the default commands it will still work.
The default convert configuration invokes ffmpeg, so this patches in the
right storepath. Since it patches the shlex split, even user config will
use the correct path. kudos @aszlig.
Features
========
* Fix#732: tcp-mss, outgoing-tcp-mss options for nsd.conf, patch from Daisuke Higashi.
* Fix#739: zonefile changes when mtime is small are detected on reload, if filesystem supports precision mtime values.
* RR type CSYNC (RFC7477) syntax is supported.
Bugfixes
========
* Change the nsd.db file version because of nanosecond precision fix.
* take advantage of arc4random_uniform if available, patch from Loganaden Velvindron.
* Fix flto check for OSX clang.
* Define _DEFAULT_SOURCE with _BSD_SOURCE for glibc 2.20 on Linux.
* Fix#736: segfault during zone transfer.
* Fix#744: Fix that NSD replies for configured but unloaded zone with SERVFAIL, not REFUSED.
This allows to use <olink> tags inside NixOS options to reference
sections from the manual. I've originally introduced it in #14476 to
reference the Taskserver specific documentation from the options
reference but as suggested by @nbp, this was done as a separate pull
request to ensure greater visibility rather than being "hidden" in the
Taskserver branch.
The build time for the manual is around 30s on my machine without this
change and 34s with this change, so it shouldn't have a very big impact
on the build time of the manual.
Olinks between the options reference and the manual now will look like
this:
"More instructions about NixOS in conjuction with Taskserver can be
found in the NixOS manual at Chapter 15, Taskserver."
More documentation about olinks can be found here:
http://www.sagehill.net/docbookxsl/Olinking.html
Acked-by: Eelco Dolstra <eelco.dolstra@logicblox.com>
The Chez build was failing, as usual, due to impurities. The build
system refers to absolute paths for tools like `ln` or `true`, which
was the real culprit here. Furthermore the build also 'helpfully'
suppresses errors in these cases by piping to /dev/null, so you never
see any errors at build time until it's too late (otherwise, you'd
see failures to call /bin/ln or at ./configure time).
This also re-enables parallel builds, as they should be safe from
all my testing, I believe.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
