Provide an update of the German translation.
* A lot of compound words were previously written with spaces, while
German orthography is relatively clear in that the components
should not be separated.
* When referring to the actual process of (de)compression rather than the
concept, replace “(De-)Kompression” with “(De-)Komprimierung”.
Previously, both forms were used in this context and are now used in a
manner consistent with “Komprimierung” being more likely to refer to
a process.
* Consistently translate “standard input”/“output”
* Use “Zeichen” instead of false friend “Charakter” for “character”
* Insert commas around relative clauses (as required in German)
* Some other minor corrections
* Capitalize “ß” as “ẞ”
* Consistently start option descriptions in --help with capital letters
Acked-By: Andre Noll <maan@tuebingen.mpg.de>
* Update after msgmerge
As pointed out by Robert Pollak, there's a typo in the German
translation of the compression preset option (-0 ... -9) help text.
"The compressor" translates to "der Komprimierer", and the genitive
form is "des Komprimierers". The old word makes no sense at all.
This reverts commit 7a11c4a8e5.
It is a problem when libc has pipe2() but the kernel is too
old to have pipe2() and thus pipe2() fails. In xz it's pointless
to have a fallback for non-functioning pipe2(); it's better to
avoid pipe2() completely.
Thanks to Michael Fox for the bug report.
The sandboxing is used conditionally as described in main.c.
This isn't optimal but it was much easier to implement than
a full sandboxing solution and it still covers the most common
use cases where xz is writing to standard output. This should
have practically no effect on performance even with small files
as fork() isn't needed.
C and locale libraries can open files as needed. This has been
fine in the past, but it's a problem with things like Capsicum.
io_sandbox_enter() tries to ensure that various locale-related
files have been loaded before cap_enter() is called, but it's
possible that there are other similar problems which haven't
been seen yet.
Currently Capsicum is available on FreeBSD 10 and later
and there is a port to Linux too.
Thanks to Loganaden Velvindron for help.
AU_ALIAS was removed because the new version is incompatible
with the old version.
It no longer checks for <sys/capability.h> separately.
It's enough to test for it as part of AC_CHECK_DECL.
The defines HAVE_CAPSICUM_SYS_CAPSICUM_H and
HAVE_CAPSICUM_SYS_CAPABILITY_H were removed as unneeded.
HAVE_SYS_CAPSICUM_H from AC_CHECK_HEADERS is enough.
It no longer does a useless search for the Capsicum library
if the header wasn't found.
Fixed a bug in ACTION-IF-FOUND (the first argument). Specifying
the argument omitted the default action but the given action
wasn't used instead.
AC_DEFINE([HAVE_CAPSICUM]) is now always called when Capsicum
support is found. Previously it was part of the default
ACTION-IF-FOUND which a custom action would override. Now
the default action only prepends ${CAPSICUM_LIB} to LIBS.
The documentation was updated.
Since there as no serial number, "#serial 2" was added.
The earlier version compiled but didn't actually work
since sysconf(_SC_PHYS_PAGES) always fails (or so I was told).
Thanks to Ole André Vadla Ravnås for the patch and testing.
It tried to use sysctl() on QNX but
- it broke the build because sysctl() needs -lsocket on QNX;
- sysctl() doesn't work for detecting the core count on QNX
even if it compiled.
sysconf() works. An alternative would have been to use
QNX-specific SYSPAGE_ENTRY(num_cpu) from <sys/syspage.h>.
Thanks to Ole André Vadla Ravnås.
In FreeBSD, cpuset_getaffinity() is the preferred way to get
the number of available cores.
Thanks to Rui Paulo for the patch. I edited it slightly, but
hopefully I didn't break anything.
It's a problem at least on OpenBSD which doesn't support
O_NONBLOCK on e.g. /dev/null. I'm not surprised if it's
a problem on other OSes too since this behavior is allowed
in POSIX-1.2008.
The code relying on this behavior was committed in June 2013
and included in 5.1.3alpha released on 2013-10-26. Clearly
the development releases only get limited testing.
Hiding them makes no sense since normally there's no error
when testing the "good" files. With "bad" files errors are
expected and then it makes sense to keep the messages hidden.
Mention the possible "make check" failure on Solaris in the
Solaris-specific section of INSTALL. It was already in
section 4.5 but it is better mention it in the OS-specific
section too.
Hauke Henningsen
Lasse Collin
Andre Noll