node-liblzma 1.0.4 → 1.1.4

package/deps/xz/PACKAGERS

@@ -1,231 +0,0 @@
-
-Information to packagers of XZ Utils
-====================================
-
-    0. Preface
-    1. Package naming
-    2. Package description
-    3. License
-    4. configure options
-    5. Additional documentation
-    6. Extra files
-    7. Installing XZ Utils and LZMA Utils in parallel
-    8. Example
-
-
-0. Preface
-----------
-
-    This document is meant for people who create and maintain XZ Utils
-    packages for operating system distributions. The focus is on GNU/Linux
-    systems, but most things apply to other systems too.
-
-    While the standard "configure && make DESTDIR=$PKG install" should
-    give a pretty good package, there are some details which packagers
-    may want to tweak.
-
-    Packagers should also read the INSTALL file.
-
-
-1. Package naming
------------------
-
-    The preferred name for the XZ Utils package is "xz", because that's
-    the name of the upstream tarball. Naturally you may have good reasons
-    to use some other name; I won't get angry about it. ;-) It's just nice
-    to be able to point people to the correct package name without asking
-    what distro they have.
-
-    If your distro policy is to split things into small pieces, here is
-    one suggestion:
-
-        xz              xz, xzdec, scripts (xzdiff, xzgrep, etc.), docs
-        xz-lzma         lzma, unlzma, lzcat, lzgrep etc. symlinks and
-                        lzmadec binary for compatibility with LZMA Utils
-        liblzma         liblzma.so.*
-        liblzma-devel   liblzma.so, liblzma.a, API headers
-
-
-2. Package description
-----------------------
-
-    Here is a suggestion which you may use as the package description.
-    If you can use only one-line description, pick only the first line.
-    Naturally, feel free to use some other description if you find it
-    better, and maybe send it to me too.
-
-        Library and command line tools for XZ and LZMA compressed files
-
-        XZ Utils provide a general purpose data compression library
-        and command line tools. The native file format is the .xz
-        format, but also the legacy .lzma format is supported. The .xz
-        format supports multiple compression algorithms, of which LZMA2
-        is currently the primary algorithm. With typical files, XZ Utils
-        create about 30 % smaller files than gzip.
-
-    If you are splitting XZ Utils into multiple packages, here are some
-    suggestions for package descriptions:
-
-    xz:
-
-        Command line tools for XZ and LZMA compressed files
-
-        This package includes the xz compression tool and other command
-        line tools from XZ Utils. xz has command line syntax similar to
-        that of gzip. The native file format is the .xz format, but also
-        the legacy .lzma format is supported. The .xz format supports
-        multiple compression algorithms, of which LZMA2 is currently the
-        primary algorithm. With typical files, XZ Utils create about 30 %
-        smaller files than gzip.
-
-        Note that this package doesn't include the files needed for
-        LZMA Utils 4.32.x compatibility. Install also the xz-lzma
-        package to make XZ Utils emulate LZMA Utils 4.32.x.
-
-    xz-lzma:
-
-        LZMA Utils emulation with XZ Utils
-
-        This package includes executables and symlinks to make
-        XZ Utils emulate lzma, unlzma, lzcat, and other command
-        line tools found from the legacy LZMA Utils 4.32.x package.
-
-    liblzma:
-
-        Library for XZ and LZMA compressed files
-
-        liblzma is a general purpose data compression library with
-        an API similar to that of zlib. liblzma supports multiple
-        algorithms, of which LZMA2 is currently the primary algorithm.
-        The native file format is .xz, but also the legacy .lzma
-        format and raw streams (no headers at all) are supported.
-
-        This package includes the shared library.
-
-    liblzma-devel:
-
-        Library for XZ and LZMA compressed files
-
-        This package includes the API headers, static library, and
-        other development files related to liblzma.
-
-
-3. License
-----------
-
-    If the package manager supports a license field, you probably should
-    put GPLv2+ there (GNU GPL v2 or later). The interesting parts of
-    XZ Utils are in the public domain, but some less important files
-    ending up into the binary package are under GPLv2+. So it is simplest
-    to just say GPLv2+ if you cannot specify "public domain and GPLv2+".
-
-    If you split XZ Utils into multiple packages as described earlier
-    in this file, liblzma and liblzma-dev packages will contain only
-    public domain code (from XZ Utils at least; compiler or linker may
-    add some third-party code, which may be copyrighted).
-
-
-4. configure options
---------------------
-
-    Unless you are building a package for a distribution that is meant
-    only for embedded systems, don't use the following configure options:
-
-        --enable-debug
-        --enable-encoders (*)
-        --enable-decoders
-        --enable-match-finders
-        --enable-checks
-        --enable-small (*)
-        --disable-threads (*)
-
-    (*) These are OK when building xzdec and lzmadec as described
-        in INSTALL.
-
-    xzdec and lzmadec don't provide any functionality that isn't already
-    available in the xz tool. Shipping xzdec and lzmadec without size
-    optimization and statically-linked liblzma isn't very useful. Doing
-    that would give users the xzdec man page, which may make it easier
-    for people to find out that such tools exists, but the executables
-    wouldn't have any advantage over the full-featured xz.
-
-
-5. Additional documentation
----------------------------
-
-    "make install" copies some additional documentation to $docdir
-    (--docdir in configure). There is a copy of the GNU GPL v2, which
-    can be replaced with a symlink if your distro ships with shared
-    copies of the common license texts.
-
-    liblzma API is currently only documented using Doxygen tags in the
-    API headers. It hasn't been tested much how good results Doxygen
-    is able to make from the tags (e.g. Doxyfile might need tweaking,
-    the tagging may need to be improved etc.), so it might be simpler
-    to just let people read docs directly from the .h files for now,
-    and also save quite a bit in package size at the same time.
-
-
-6. Extra files
---------------
-
-    The "extra" directory contains some small extra tools or other files.
-    The exact set of extra files can vary between XZ Utils releases. The
-    extra files have only limited use or they are too dangerous to be
-    put directly to $bindir (7z2lzma.sh is a good example, since it can
-    silently create corrupt output if certain conditions are not met).
-
-    If you feel like it, you may copy the extra directory under the doc
-    directory (e.g. /usr/share/doc/xz/extra). Maybe some people will find
-    them useful. However, most people needing these tools probably are
-    able to find them from the source package too.
-
-    The "debug" directory contains some tools that are useful only when
-    hacking on XZ Utils. Don't package these tools.
-
-
-7. Installing XZ Utils and LZMA Utils in parallel
--------------------------------------------------
-
-    XZ Utils and LZMA Utils 4.32.x can be installed in parallel by
-    omitting the compatibility symlinks (lzma, unlzma, lzcat, lzgrep etc.)
-    from the XZ Utils package. It's probably a good idea to still package
-    the symlinks into a separate package so that users may choose if they
-    want to use XZ Utils or LZMA Utils for handling .lzma files.
-
-
-8. Example
-----------
-
-    Here is an example for i686 GNU/Linux that
-      - links xz and lzmainfo against shared liblzma;
-      - links size-optimized xzdec and lzmadec against static liblzma
-        while avoiding libpthread dependency;
-      - includes only shared liblzma in the final package; and
-      - copies also the "extra" directory to the package.
-
-    PKG=/tmp/xz-pkg
-    tar xf xz-x.y.z.tar.gz
-    cd xz-x.y.z
-    ./configure \
-            --prefix=/usr \
-            --disable-static \
-            --disable-xzdec \
-            --disable-lzmadec \
-            CFLAGS='-march=i686 -mtune=generic -O2'
-    make
-    make DESTDIR=$PKG install-strip
-    make clean
-    ./configure \
-            --prefix=/usr \
-            --disable-shared \
-            --disable-nls \
-            --disable-encoders \
-            --enable-small \
-            --disable-threads \
-            CFLAGS='-march=i686 -mtune=generic -Os'
-    make -C src/liblzma
-    make -C src/xzdec
-    make -C src/xzdec DESTDIR=$PKG install-strip
-    cp -a extra $PKG/usr/share/doc/xz
-

package/deps/xz/README

@@ -1,308 +0,0 @@
-
-XZ Utils
-========
-
-    0. Overview
-    1. Documentation
-       1.1. Overall documentation
-       1.2. Documentation for command-line tools
-       1.3. Documentation for liblzma
-    2. Version numbering
-    3. Reporting bugs
-    4. Translating the xz tool
-    5. Other implementations of the .xz format
-    6. Contact information
-
-
-0. Overview
------------
-
-    XZ Utils provide a general-purpose data-compression library plus
-    command-line tools. The native file format is the .xz format, but
-    also the legacy .lzma format is supported. The .xz format supports
-    multiple compression algorithms, which are called "filters" in the
-    context of XZ Utils. The primary filter is currently LZMA2. With
-    typical files, XZ Utils create about 30 % smaller files than gzip.
-
-    To ease adapting support for the .xz format into existing applications
-    and scripts, the API of liblzma is somewhat similar to the API of the
-    popular zlib library. For the same reason, the command-line tool xz
-    has a command-line syntax similar to that of gzip.
-
-    When aiming for the highest compression ratio, the LZMA2 encoder uses
-    a lot of CPU time and may use, depending on the settings, even
-    hundreds of megabytes of RAM. However, in fast modes, the LZMA2 encoder
-    competes with bzip2 in compression speed, RAM usage, and compression
-    ratio.
-
-    LZMA2 is reasonably fast to decompress. It is a little slower than
-    gzip, but a lot faster than bzip2. Being fast to decompress means
-    that the .xz format is especially nice when the same file will be
-    decompressed very many times (usually on different computers), which
-    is the case e.g. when distributing software packages. In such
-    situations, it's not too bad if the compression takes some time,
-    since that needs to be done only once to benefit many people.
-
-    With some file types, combining (or "chaining") LZMA2 with an
-    additional filter can improve the compression ratio. A filter chain may
-    contain up to four filters, although usually only one or two are used.
-    For example, putting a BCJ (Branch/Call/Jump) filter before LZMA2
-    in the filter chain can improve compression ratio of executable files.
-
-    Since the .xz format allows adding new filter IDs, it is possible that
-    some day there will be a filter that is, for example, much faster to
-    compress than LZMA2 (but probably with worse compression ratio).
-    Similarly, it is possible that some day there is a filter that will
-    compress better than LZMA2.
-
-    XZ Utils doesn't support multithreaded compression or decompression
-    yet. It has been planned though and taken into account when designing
-    the .xz file format.
-
-
-1. Documentation
-----------------
-
-1.1. Overall documentation
-
-    README              This file
-
-    INSTALL.generic     Generic install instructions for those not familiar
-                        with packages using GNU Autotools
-    INSTALL             Installation instructions specific to XZ Utils
-    PACKAGERS           Information to packagers of XZ Utils
-
-    COPYING             XZ Utils copyright and license information
-    COPYING.GPLv2       GNU General Public License version 2
-    COPYING.GPLv3       GNU General Public License version 3
-    COPYING.LGPLv2.1    GNU Lesser General Public License version 2.1
-
-    AUTHORS             The main authors of XZ Utils
-    THANKS              Incomplete list of people who have helped making
-                        this software
-    NEWS                User-visible changes between XZ Utils releases
-    ChangeLog           Detailed list of changes (commit log)
-    TODO                Known bugs and some sort of to-do list
-
-    Note that only some of the above files are included in binary
-    packages.
-
-
-1.2. Documentation for command-line tools
-
-    The command-line tools are documented as man pages. In source code
-    releases (and possibly also in some binary packages), the man pages
-    are also provided in plain text (ASCII only) and PDF formats in the
-    directory "doc/man" to make the man pages more accessible to those
-    whose operating system doesn't provide an easy way to view man pages.
-
-
-1.3. Documentation for liblzma
-
-    The liblzma API headers include short docs about each function
-    and data type as Doxygen tags. These docs should be quite OK as
-    a quick reference.
-
-    I have planned to write a bunch of very well documented example
-    programs, which (due to comments) should work as a tutorial to
-    various features of liblzma. No such example programs have been
-    written yet.
-
-    For now, if you have never used liblzma, libbzip2, or zlib, I
-    recommend learning the *basics* of the zlib API. Once you know that,
-    it should be easier to learn liblzma.
-
-        http://zlib.net/manual.html
-        http://zlib.net/zlib_how.html
-
-
-2. Version numbering
---------------------
-
-    The version number format of XZ Utils is X.Y.ZS:
-
-      - X is the major version. When this is incremented, the library
-        API and ABI break.
-
-      - Y is the minor version. It is incremented when new features
-        are added without breaking the existing API or ABI. An even Y
-        indicates a stable release and an odd Y indicates unstable
-        (alpha or beta version).
-
-      - Z is the revision. This has a different meaning for stable and
-        unstable releases:
-
-          * Stable: Z is incremented when bugs get fixed without adding
-            any new features. This is intended to be convenient for
-            downstream distributors that want bug fixes but don't want
-            any new features to minimize the risk of introducing new bugs.
-
-          * Unstable: Z is just a counter. API or ABI of features added
-            in earlier unstable releases having the same X.Y may break.
-
-      - S indicates stability of the release. It is missing from the
-        stable releases, where Y is an even number. When Y is odd, S
-        is either "alpha" or "beta" to make it very clear that such
-        versions are not stable releases. The same X.Y.Z combination is
-        not used for more than one stability level, i.e. after X.Y.Zalpha,
-        the next version can be X.Y.(Z+1)beta but not X.Y.Zbeta.
-
-
-3. Reporting bugs
------------------
-
-    Naturally it is easiest for me if you already know what causes the
-    unexpected behavior. Even better if you have a patch to propose.
-    However, quite often the reason for unexpected behavior is unknown,
-    so here are a few things to do before sending a bug report:
-
-      1. Try to create a small example how to reproduce the issue.
-
-      2. Compile XZ Utils with debugging code using configure switches
-         --enable-debug and, if possible, --disable-shared. If you are
-         using GCC, use CFLAGS='-O0 -ggdb3'. Don't strip the resulting
-         binaries.
-
-      3. Turn on core dumps. The exact command depends on your shell;
-         for example in GNU bash it is done with "ulimit -c unlimited",
-         and in tcsh with "limit coredumpsize unlimited".
-
-      4. Try to reproduce the suspected bug. If you get "assertion failed"
-         message, be sure to include the complete message in your bug
-         report. If the application leaves a coredump, get a backtrace
-         using gdb:
-           $ gdb /path/to/app-binary   # Load the app to the debugger.
-           (gdb) core core   # Open the coredump.
-           (gdb) bt   # Print the backtrace. Copy & paste to bug report.
-           (gdb) quit   # Quit gdb.
-
-    Report your bug via email or IRC (see Contact information below).
-    Don't send core dump files or any executables. If you have a small
-    example file(s) (total size less than 256 KiB), please include
-    it/them as an attachment. If you have bigger test files, put them
-    online somewhere and include a URL to the file(s) in the bug report.
-
-    Always include the exact version number of XZ Utils in the bug report.
-    If you are using a snapshot from the git repository, use "git describe"
-    to get the exact snapshot version. If you are using XZ Utils shipped
-    in an operating system distribution, mention the distribution name,
-    distribution version, and exact xz package version; if you cannot
-    repeat the bug with the code compiled from unpatched source code,
-    you probably need to report a bug to your distribution's bug tracking
-    system.
-
-
-4. Translating the xz tool
---------------------------
-
-    The messages from the xz tool have been translated into a few
-    languages. Before starting to translate into a new language, ask
-    the author whether someone else hasn't already started working on it.
-
-    Test your translation. Testing includes comparing the translated
-    output to the original English version by running the same commands
-    in both your target locale and with LC_ALL=C. Ask someone to
-    proof-read and test the translation.
-
-    Testing can be done e.g. by installing xz into a temporary directory:
-
-        ./configure --disable-shared --prefix=/tmp/xz-test
-        # <Edit the .po file in the po directory.>
-        make -C po update-po
-        make install
-        bash debug/translation.bash | less
-        bash debug/translation.bash | less -S  # For --list outputs
-
-    Repeat the above as needed (no need to re-run configure though).
-
-    Note especially the following:
-
-      - The output of --help and --long-help must look nice on
-        an 80-column terminal. It's OK to add extra lines if needed.
-
-      - In contrast, don't add extra lines to error messages and such.
-        They are often preceded with e.g. a filename on the same line,
-        so you have no way to predict where to put a \n. Let the terminal
-        do the wrapping even if it looks ugly. Adding new lines will be
-        even uglier in the generic case even if it looks nice in a few
-        limited examples.
-
-      - Be careful with column alignment in tables and table-like output
-        (--list, --list --verbose --verbose, --info-memory, --help, and
-        --long-help):
-
-          * All descriptions of options in --help should start in the
-            same column (but it doesn't need to be the same column as
-            in the English messages; just be consistent if you change it).
-            Check that both --help and --long-help look OK, since they
-            share several strings.
-
-          * --list --verbose and --info-memory print lines that have
-            the format "Description:   %s". If you need a longer
-            description, you can put extra space between the colon
-            and %s. Then you may need to add extra space to other
-            strings too so that the result as a whole looks good (all
-            values start at the same column).
-
-          * The columns of the actual tables in --list --verbose --verbose
-            should be aligned properly. Abbreviate if necessary. It might
-            be good to keep at least 2 or 3 spaces between column headings
-            and avoid spaces in the headings so that the columns stand out
-            better, but this is a matter of opinion. Do what you think
-            looks best.
-
-      - Be careful to put a period at the end of a sentence when the
-        original version has it, and don't put it when the original
-        doesn't have it. Similarly, be careful with \n characters
-        at the beginning and end of the strings.
-
-      - Read the TRANSLATORS comments that have been extracted from the
-        source code and included in xz.pot. If they suggest testing the
-        translation with some type of command, do it. If testing needs
-        input files, use e.g. tests/files/good-*.xz.
-
-      - When updating the translation, read the fuzzy (modified) strings
-        carefully, and don't mark them as updated before you actually
-        have updated them. Reading through the unchanged messages can be
-        good too; sometimes you may find a better wording for them.
-
-      - If you find language problems in the original English strings,
-        feel free to suggest improvements. Ask if something is unclear.
-
-      - The translated messages should be understandable (sometimes this
-        may be a problem with the original English messages too). Don't
-        make a direct word-by-word translation from English especially if
-        the result doesn't sound good in your language.
-
-    In short, take your time and pay attention to the details. Making
-    a good translation is not a quick and trivial thing to do. The
-    translated xz should look as polished as the English version.
-
-
-5. Other implementations of the .xz format
-------------------------------------------
-
-    7-Zip and the p7zip port of 7-Zip support the .xz format starting
-    from the version 9.00alpha.
-
-        http://7-zip.org/
-        http://p7zip.sourceforge.net/
-
-    XZ Embedded is a limited implementation written for use in the Linux
-    kernel, but it is also suitable for other embedded use.
-
-        http://tukaani.org/xz/embedded.html
-
-
-6. Contact information
-----------------------
-
-    If you have questions, bug reports, patches etc. related to XZ Utils,
-    contact Lasse Collin <lasse.collin@tukaani.org> (in Finnish or English).
-    I'm sometimes slow at replying. If you haven't got a reply within two
-    weeks, assume that your email has got lost and resend it or use IRC.
-
-    You can find me also from #tukaani on Freenode; my nick is Larhzu.
-    The channel tends to be pretty quiet, so just ask your question and
-    someone may wake up.
-

package/deps/xz/THANKS

@@ -1,116 +0,0 @@
-
-Thanks
-======
-
-Some people have helped more, some less, but nevertheless everyone's help
-has been important. :-) In alphabetical order:
-  - Mark Adler
-  - H. Peter Anvin
-  - Jeff Bastian
-  - Nelson H. F. Beebe
-  - Karl Berry
-  - Anders F. Björklund
-  - Emmanuel Blot
-  - Martin Blumenstingl
-  - Jakub Bogusz
-  - Maarten Bosmans
-  - Trent W. Buck
-  - James Buren
-  - David Burklund
-  - Daniel Mealha Cabrita
-  - Milo Casagrande
-  - Marek Černocký
-  - Tomer Chachamu
-  - Gabi Davar
-  - Chris Donawa
-  - Andrew Dudman
-  - Markus Duft
-  - İsmail Dönmez
-  - Robert Elz
-  - Gilles Espinasse
-  - Denis Excoffier
-  - Michael Felt
-  - Michael Fox
-  - Mike Frysinger
-  - Daniel Richard G.
-  - Bill Glessner
-  - Jason Gorski
-  - Juan Manuel Guerrero
-  - Diederik de Haas
-  - Joachim Henke
-  - Christian Hesse
-  - Vincenzo Innocente
-  - Peter Ivanov
-  - Jouk Jansen
-  - Jun I Jin
-  - Per Øyvind Karlsen
-  - Thomas Klausner
-  - Richard Koch
-  - Ville Koskinen
-  - Jan Kratochvil
-  - Christian Kujau
-  - Stephan Kulow
-  - Peter Lawler
-  - James M Leddy
-  - Hin-Tak Leung
-  - Andraž 'ruskie' Levstik
-  - Cary Lewis
-  - Wim Lewis
-  - Lorenzo De Liso
-  - Bela Lubkin
-  - Gregory Margo
-  - Jim Meyering
-  - Arkadiusz Miskiewicz
-  - Conley Moorhous
-  - Rafał Mużyło
-  - Adrien Nader
-  - Hongbo Ni
-  - Jonathan Nieder
-  - Andre Noll
-  - Peter O'Gorman
-  - Peter Pallinger
-  - Rui Paulo
-  - Igor Pavlov
-  - Diego Elio Pettenò
-  - Elbert Pol
-  - Mikko Pouru
-  - Trần Ngọc Quân
-  - Pavel Raiskup
-  - Ole André Vadla Ravnås
-  - Robert Readman
-  - Bernhard Reutner-Fischer
-  - Eric S. Raymond
-  - Cristian Rodríguez
-  - Christian von Roques
-  - Torsten Rupp
-  - Jukka Salmi
-  - Alexandre Sauvé
-  - Benno Schulenberg
-  - Andreas Schwab
-  - Dan Shechter
-  - Stuart Shelton
-  - Brad Smith
-  - Jonathan Stott
-  - Dan Stromberg
-  - Vincent Torri
-  - Paul Townsend
-  - Mohammed Adnène Trojette
-  - Alexey Tourbin
-  - Patrick J. Volkerding
-  - Martin Väth
-  - Adam Walling
-  - Christian Weisgerber
-  - Bert Wesarg
-  - Fredrik Wikstrom
-  - Ralf Wildenhues
-  - Charles Wilson
-  - Lars Wirzenius
-  - Pilorz Wojciech
-  - Ryan Young
-  - Andreas Zieringer
-
-Also thanks to all the people who have participated in the Tukaani project.
-
-I have probably forgot to add some names to the above list. Sorry about
-that and thanks for your help.
-