The intention behind keeping the generated man pages is to avoid
requiring downstreams to have xsltproc and the DocBook stylesheets
installed. However, for that they don't have to be stored in the
repository. Generating them upon release and including them in the
source tarball is enough.
The default palette used will not look good in most of the cases, but
it's hard to guess a palette and pretty much impossible without actually
decoding a lot of the packets.
Implements #1854.
The process can take a lot of time, therefore only do it if there's a
reasonable chance that files will have to be cleaned up — which is after
a version change.
Another piece of the fix for #1860.
With a large number of files cleaning the cache can take quite some
time. During that time file identification won't work as it tries to
acquire a lock that's already held by the cleanup process.
With this change the cleanup process will release the lock after having
processed each file allowing the identification process to obtain the
lock temporarily.
Fixes#1860.
Things that are checked include:
• Can the mkvmerge executable be found?
• Can the mkvmerge executable be executed?
• Is mkvmerge's version the same as the GUI's?
• Only on Windows: Does the 'magic.mgc' file exist?
All of these are causes of problems that have been reported by users
multiple times over the years.
JSON parsing failures usually indicate a problem with the setup,
e.g. mkvmerge missing, being from a different release of MKVToolNix or
the anti virus solution blocking mkvmerge.
Both codes come from the range "qaa–qtz" which is "reserved for local
use". Adding all of them would blow up the list of available languages
overly much, but adding just two is quite OK. These two are often used
in France.
See #1848.
This prevents the error message "not enough space on disk" being shown
twice.
Whenever a write fails, an exception is throw, and an appropriate error
message is shown. This is the first time.
Next mkvmerge goes into its cleanup routine. There it closes the output
file. The output file uses a write buffer implementation. Before closing
the file any outstanding buffered content is written to the disk. The
disk is still full, though, triggering another exception, and another
error message is output.
The workaround is to discard any buffered content still remaining at
cleanup time. This is safe as the output file is closed manually normal
program flow. Therefore no buffered content is lost in a successful run.
Fixes#1850.
rake 10.1.0, which is part of Ruby v2.1.x, can do parallel builds, too,
and supports the same option -j that drake does. And it even defaults to
"number of cores + 1".
However, the tasks that can be executed in parallel have to be set up
with "multitask" instead of "task". There is an option to enable
parallel processing for all tasks defined as "tasks", though, and the
commit enables this option.
