manually add dependency on go-getter

vendor/github.com/ulikunitz/xz/doc/.gitignore

@@ -0,0 +1,2 @@
+# .gitignore
+LZMA2.html

vendor/github.com/ulikunitz/xz/doc/LZMA2.md

@@ -0,0 +1,91 @@
+% LZMA2 format
+
+The LZMA2 format supports flushing, parallel encoding or decoding.
+Chunks of data that cannot be compressed are copied as such.
+
+## Dictionary Size
+
+LZMA2 requires information about the size of the dictionary. This is
+provided by a single byte. 
+
+Bits | Mask | Description
+----:|-----:|:------------------------------------------------
+ 0-5 | 0x3F | Dictionary Size
+ 6-7 | 0xC0 | Reserved for future use; Must be zero
+
+The dictionary size is encoded with a one-bit mantissa and five-bit
+exponent. The smallest dictionary size is 4 KiB and the biggest is 4 GiB
+- 1 B.
+
+|Raw Value | Mantissa | Exponent | Dictionary size|
+|---------:|---------:|---------:|---------------:|
+|        0 |        2 |       11 |          4 KiB |
+|        1 |        3 |       11 |          6 KiB |
+|        2 |        2 |       12 |          8 KiB |
+|        3 |        3 |       12 |         12 KiB |
+|      ... |      ... |      ... |            ... |
+|       36 |        2 |       29 |       1024 MiB |
+|       37 |        3 |       29 |       1536 MiB |
+|       38 |        2 |       30 |       2048 MiB |
+|       39 |        3 |       30 |       3072 MiB |
+|       40 |        2 |       31 |  4096 MiB - 1B |
+
+For test purposes we add the dictionary size byte as first byte of an
+LZMA2 stream.
+
+## Chunks
+
+An LZMA2 stream is a sequence of chunks. Each chunk is preceded by a
+control byte and other information.
+
+Following the C implementation in the LZMA SDK the control byte can be
+described as such:
+
+Chunk header         | Description
+:------------------- | :--------------------------------------------------
+`00000000`           | End of LZMA2 stream
+`00000001 U U`       | Uncompressed chunk, reset dictionary
+`00000010 U U`       | Uncompressed chunk, no reset of dictionary
+`100uuuuu U U C C`   | LZMA, no reset
+`101uuuuu U U C C`   | LZMA, reset state
+`110uuuuu U U C C S` | LZMA, reset state, new properties
+`111uuuuu U U C C S` | LZMA, reset state, new properties, reset dictionary
+
+The symbols used are described by following table.
+
+Symbol | Description
+:----- | :--------------------
+u      | uncompressed size bit
+U      | uncompressed size byte
+C      | uncompressed size byte
+S      | properties byte
+
+A dictionary reset requires always new properties. If this is an
+uncompressed chunk the properties need to be provided in the next
+compressed chunk. New properties require a reset of the state.
+
+A dictionary reset puts the current position to zero. Uncompressed data
+is written into the dictionary.
+
+The uncompressed size and compressed size are given in big-endian byte order.
+The values need to be incremented for the actual size. So a chunk with 1
+byte uncompressed data will store size 0 in the uncompressed bits and bytes.
+
+The properties byte provides the parameters pb, lc, lp using following
+formula:
+
+    S = (pb * 5 + lp) * 9 + lc
+
+This is same encoding used for LZMA. For LZMA2 following condition has
+been introduced:
+
+    lc + lp <= 4.
+
+The parameters are defined as follows:
+
+Name  | Range  | Description
+:---- | :----- | :------------------------------
+lc    | [0,8]  | number of literal context bits
+lp    | [0,4]  | number of literal pos bits
+pb    | [0,4]  | the number of pos bits
+

vendor/github.com/ulikunitz/xz/doc/make-docs

@@ -0,0 +1,4 @@
+#!/bin/sh
+
+set -x
+pandoc -t html5 -f markdown -s --css=md.css -o LZMA2.html LZMA2.md

vendor/github.com/ulikunitz/xz/doc/md.css

@@ -0,0 +1,20 @@
+/* md.css */
+
+body {
+	font-family: "Verdana", sans-serif;
+	font-size: 10pt;
+	width: 40em;
+	background-color: #FFFAF0;
+}
+
+h1 { font-size: 18pt; }
+
+h2 { font-size: 14pt; }
+
+h3 { font-size: 12pt; }
+
+h4 { font-size: 10pt; }
+
+code { font-size: 10pt; }
+
+.nobr { white-space: nowrap; }

vendor/github.com/ulikunitz/xz/doc/relnotes/release-v0.3.md

@@ -0,0 +1,12 @@
+# Release Notes v0.3
+
+This release provides an lzmago command that provides a complete set of
+flags to decompress and compress .lzma files. It is interoperable with
+the lzma tool from the xz package.
+
+The release changed the lzma implementation to support later
+optimizations of the compression algorithm as well as the plumbing
+required to support the LZMA2 format.
+
+The release provides the ground work to provide full support for the
+full xz specification.

vendor/github.com/ulikunitz/xz/doc/relnotes/release-v0.4.1.md

@@ -0,0 +1,4 @@
+# Release Notes v0.4.1
+
+The release fixes issue #7 LZMA2 reader. There has been a bug in the
+LZMA2 reader.

vendor/github.com/ulikunitz/xz/doc/relnotes/release-v0.4.md

@@ -0,0 +1,12 @@
+# Release Notes v0.4
+
+This release support the compression and decompression to xz files. Note
+that only the LZMA filter is supported for the xz format, but this seems
+to be the standard setup anyway.
+
+The performance and compression ration is not good compared to the xz
+tool written in C. But optimization has not been the target of this
+release.
+
+A gxz binary is included that supports the compression and decompression of
+xz files.

vendor/github.com/ulikunitz/xz/doc/relnotes/release-v0.5.1.md

@@ -0,0 +1,5 @@
+# Release Notes v0.5.1
+
+The release fixes a problem with 32-bit integers on 32-bit platforms.
+
+Many thanks to Bruno Bigras, who reported the issue.

vendor/github.com/ulikunitz/xz/doc/relnotes/release-v0.5.2.md

@@ -0,0 +1,6 @@
+# Release Notes v0.5.2
+
+The release fixes an issue decoding files that contain a block header
+padding of 4 bytes.
+
+Many thanks to Greg (@myfreeweb on github) for reporting this issue.

vendor/github.com/ulikunitz/xz/doc/relnotes/release-v0.5.3.md

@@ -0,0 +1,5 @@
+# Release Notes v0.5.2
+
+The realease fixes issue #12 related an XZ stream with no data.
+
+Many thanks to Tomasz Kłak for reporting the issue.

vendor/github.com/ulikunitz/xz/doc/relnotes/release-v0.5.4.md

@@ -0,0 +1,6 @@
+# Release Notes v0.5.4
+
+The release fixes issue #15 related to an unexpeded padding size of 5.
+The padding size test has now been removed.
+
+Many thanks to Dórian C. Langbeck for reporting the issue.

vendor/github.com/ulikunitz/xz/doc/relnotes/release-v0.5.md

@@ -0,0 +1,16 @@
+# Release Notes v0.5
+
+This release supports multiple xz streams in xz files. The older release
+couldn't support those files and there are files (linux kernel
+tarballs) that couldn't be decompressed by the code.
+
+The API has changed. Types ReaderConfig, WriterConfig, etc. are
+introduced to provide parameters to the readers and writers in the
+packages xz and lzma. The old API had multiple inconsistent mechanisms.
+Making NewReader or NewWriter a method of the Config types provides more
+clarity then the old NewReaderParams and NewWriterParams.
+
+The compression ratio and performance has been improved. An experimental
+Binary Tree Matcher has been added, but performance and compression
+ratio is poor. It's is not recommended.
+

vendor/github.com/ulikunitz/xz/doc/xz-issues.md

@@ -0,0 +1,55 @@
+# Issues in the XZ file format
+
+During the development of the xz package for Go a number of issues with
+the xz file format were observed. They are documented here to help a
+later development of an improved format.
+
+# xz file format
+
+## Consistency
+
+## General
+
+Packets should either be constant size or should have encoded the size
+in the header. File header and footer are constant size and the block
+header has the size encoded. The index doesn't fulfill the criteria even
+when its size is included in the footer.
+
+## Index
+
+The index doesn't have the size in the header. So in a stream you are
+forced to read the whole index to identify its length.
+
+The index should have made optional. This would require to remove the
+index size from the footer and include its own footer in the index.
+
+## Padding
+
+The padding should allow direct mapping of the CRC values into memory, but it
+wastes bytes bearing no information. This is certainly not optimal for a
+compression format. It is argued alignment makes it faster to read and
+write the checksum values, but the time spent there is much less than on
+encoding and decoding itself.
+
+## Filters for each block
+
+Filters should have been defined in front of blocks. This way they
+would not need to be repeated.
+
+# LZMA2 
+
+## Consistent header byte.
+
+LZMA2 consists of a series of chunks with a header byte. The header byte
+has a different format depending on whether it is an uncompressed or
+compressed chunk. This has the consequence a complete reset of state,
+properties and dictionary is not possible with an uncompressed chunk.
+The encoder has to keep a state variable tracking a dictionary reset in
+an uncompressed chunk to ensure that the flags are added in the first
+compressed chunk to follow. This complicates the implementation of the
+encoder and decoder.
+
+## Dictionary capacity is not encoded
+
+LZMA2 doesn't encode the dictionary capacity, so LZMA2 doesn't work
+standalone.