xref: /dragonfly/contrib/xz/NEWS (revision 926deccb)
1
2XZ Utils Release Notes
3======================
4
55.0.4 (2012-06-22)
6
7    * liblzma:
8
9        - Fix lzma_index_init(). It could crash if memory allocation
10          failed.
11
12        - Fix the possibility of an incorrect LZMA_BUF_ERROR when a BCJ
13          filter is used and the application only provides exactly as
14          much output space as is the uncompressed size of the file.
15
16        - Fix a bug in doc/examples_old/xz_pipe_decompress.c. It didn't
17          check if the last call to lzma_code() really returned
18          LZMA_STREAM_END, which made the program think that truncated
19          files are valid.
20
21        - New example programs in doc/examples (old programs are now in
22          doc/examples_old). These have more comments and more detailed
23          error handling.
24
25    * Fix "xz -lvv foo.xz". It could crash on some corrupted files.
26
27    * Fix output of "xz --robot -lv" and "xz --robot -lvv" which
28      incorrectly printed the filename also in the "foo (x/x)" format.
29
30    * Fix exit status of "xzdiff foo.xz bar.xz".
31
32    * Fix exit status of "xzgrep foo binary_file".
33
34    * Fix portability to EBCDIC systems.
35
36    * Fix a configure issue on AIX with the XL C compiler. See INSTALL
37      for details.
38
39    * Update French, German, Italian, and Polish translations.
40
41
425.0.3 (2011-05-21)
43
44    * liblzma fixes:
45
46        - A memory leak was fixed.
47
48        - lzma_stream_buffer_encode() no longer creates an empty .xz
49          Block if encoding an empty buffer. Such an empty Block with
50          LZMA2 data would trigger a bug in 5.0.1 and older (see the
51          first bullet point in 5.0.2 notes). When releasing 5.0.2,
52          I thought that no encoder creates this kind of files but
53          I was wrong.
54
55        - Validate function arguments better in a few functions. Most
56          importantly, specifying an unsupported integrity check to
57          lzma_stream_buffer_encode() no longer creates a corrupt .xz
58          file. Probably no application tries to do that, so this
59          shouldn't be a big problem in practice.
60
61        - Document that lzma_block_buffer_encode(),
62          lzma_easy_buffer_encode(), lzma_stream_encoder(), and
63          lzma_stream_buffer_encode() may return LZMA_UNSUPPORTED_CHECK.
64
65        - The return values of the _memusage() functions are now
66          documented better.
67
68    * Fix command name detection in xzgrep. xzegrep and xzfgrep now
69      correctly use egrep and fgrep instead of grep.
70
71    * French translation was added.
72
73
745.0.2 (2011-04-01)
75
76    * LZMA2 decompressor now correctly accepts LZMA2 streams with no
77      uncompressed data. Previously it considered them corrupt. The
78      bug can affect applications that use raw LZMA2 streams. It is
79      very unlikely to affect .xz files because no compressor creates
80      .xz files with empty LZMA2 streams. (Empty .xz files are a
81      different thing than empty LZMA2 streams.)
82
83    * "xz --suffix=.foo filename.foo" now refuses to compress the
84      file due to it already having the suffix .foo. It was already
85      documented on the man page, but the code lacked the test.
86
87    * "xzgrep -l foo bar.xz" works now.
88
89    * Polish translation was added.
90
91
925.0.1 (2011-01-29)
93
94    * xz --force now (de)compresses files that have setuid, setgid,
95      or sticky bit set and files that have multiple hard links.
96      The man page had it documented this way already, but the code
97      had a bug.
98
99    * gzip and bzip2 support in xzdiff was fixed.
100
101    * Portability fixes
102
103    * Minor fix to Czech translation
104
105
1065.0.0 (2010-10-23)
107
108    Only the most important changes compared to 4.999.9beta are listed
109    here. One change is especially important:
110
111      * The memory usage limit is now disabled by default. Some scripts
112        written before this change may have used --memory=max on xz command
113        line or in XZ_OPT. THESE USES OF --memory=max SHOULD BE REMOVED
114        NOW, because they interfere with user's ability to set the memory
115        usage limit himself. If user-specified limit causes problems to
116        your script, blame the user.
117
118    Other significant changes:
119
120      * Added support for XZ_DEFAULTS environment variable. This variable
121        allows users to set default options for xz, e.g. default memory
122        usage limit or default compression level. Scripts that use xz
123        must never set or unset XZ_DEFAULTS. Scripts should use XZ_OPT
124        instead if they need a way to pass options to xz via an
125        environment variable.
126
127      * The compression settings associated with the preset levels
128        -0 ... -9 have been changed. --extreme was changed a little too.
129        It is now less likely to make compression worse, but with some
130        files the new --extreme may compress slightly worse than the old
131        --extreme.
132
133      * If a preset level (-0 ... -9) is specified after a custom filter
134        chain options have been used (e.g. --lzma2), the custom filter
135        chain will be forgotten. Earlier the preset options were
136        completely ignored after custom filter chain options had been
137        seen.
138
139      * xz will create sparse files when decompressing if the uncompressed
140        data contains long sequences of binary zeros. This is done even
141        when writing to standard output that is connected to a regular
142        file and certain additional conditions are met to make it safe.
143
144      * Support for "xz --list" was added. Combine with --verbose or
145        --verbose --verbose (-vv) for detailed output.
146
147      * I had hoped that liblzma API would have been stable after
148        4.999.9beta, but there have been a couple of changes in the
149        advanced features, which don't affect most applications:
150
151          - Index handling code was revised. If you were using the old
152            API, you will get a compiler error (so it's easy to notice).
153
154          - A subtle but important change was made to the Block handling
155            API. lzma_block.version has to be initialized even for
156            lzma_block_header_decode(). Code that doesn't do it will work
157            for now, but might break in the future, which makes this API
158            change easy to miss.
159
160      * The major soname has been bumped to 5.0.0. liblzma API and ABI
161        are now stable, so the need to recompile programs linking against
162        liblzma shouldn't arise soon.
163
164