[Python-modules-commits] [python-sabyenc] 01/08: Import python-sabyenc_3.3.2.orig.tar.gz
JCF Ploemen
jcfp-guest at moszumanska.debian.org
Tue Jan 2 10:08:40 UTC 2018
This is an automated email from the git hooks/post-receive script.
jcfp-guest pushed a commit to branch master
in repository python-sabyenc.
commit 92213df31aed1c7c599db5a25e3339a932215d39
Author: JCF Ploemen (jcfp) <linux at jcf.pm>
Date: Tue Jan 2 10:56:08 2018 +0100
Import python-sabyenc_3.3.2.orig.tar.gz
---
.gitignore | 59 +
.travis.yml | 34 +
CHANGES.md | 0
LICENSE.md | 165 +
MANIFEST.in | 1 +
PKG-INFO | 27 -
README.md | 28 +
appveyor.yml | 27 +
doc/yenc-draft.1.3.txt | 423 ++
examples/try_out_sabyenc.py | 62 +
sabyenc.egg-info/PKG-INFO | 27 -
sabyenc.egg-info/SOURCES.txt | 7 -
sabyenc.egg-info/dependency_links.txt | 1 -
sabyenc.egg-info/top_level.txt | 1 -
setup.cfg | 4 -
setup.py | 119 +-
src/sabyenc.c | 1198 ++--
src/sabyenc.h | 97 +-
tests/check_debug_pickles.py | 90 +
tests/check_pickles.py | 98 +
tests/speed_compare.py | 254 +
tests/test_decoder.py | 114 +
tests/test_inputvalidation.py | 47 +
tests/testsupport.py | 138 +
tests/yencfiles/crc_1485266801.08 | 114 +
tests/yencfiles/crc_1485266861.43 | 14 +
tests/yencfiles/crc_1485267447.62 | 18 +
tests/yencfiles/crc_1485267596.51 | 112 +
tests/yencfiles/crc_1485268062.82 | 18 +
tests/yencfiles/crc_1485268203.06 | 26 +
tests/yencfiles/crc_1485269041.69 | 24 +
tests/yencfiles/crc_1485269517.52 | 114 +
tests/yencfiles/crc_1485269689.29 | 110 +
tests/yencfiles/crc_1485269752.39 | 120 +
tests/yencfiles/crc_1485270313.16 | 14 +
tests/yencfiles/crc_1485270667.79 | 106 +
tests/yencfiles/crc_1485270694.38 | 112 +
tests/yencfiles/crc_1485270919.57 | 20 +
tests/yencfiles/crc_1485270952.33 | 110 +
tests/yencfiles/crc_1491378708.6 | 6 +
.../crc_2qDcLdjDym75k6PkUdMz_2o22 at JBinUp.local | 101 +
.../crc_5nCweVA4aKnlBTG1s0K8_4o22 at JBinUp.local | 79 +
.../crc_KnHUroIRrzDYAHcb6cy3_3o22 at JBinUp.local | 35 +
.../crc_Pk0XqpdPC5s7KPOuYdFP_3o22 at JBinUp.local | 33 +
.../crc_QDnu3FWODC48Sphi9dSF_5o22 at JBinUp.local | 31 +
.../crc_Vm2lffi01UsDowtJ9NL3_2o22 at JBinUp.local | 107 +
.../crc_ZHJFBWeh9fHrUhh3fwME_4o22 at JBinUp.local | 113 +
.../crc_aH9oa06pKCAEeBIvr2h0_4o22 at JBinUp.local | 133 +
tests/yencfiles/emptysize_67caae212 | 61 +
tests/yencfiles/split_filename | 133 +
tests/yencfiles/test_badcrc.txt | 6099 ++++++++++++++++++++
tests/yencfiles/test_no_name.txt | 3056 ++++++++++
tests/yencfiles/test_partial.txt | 9 +
tests/yencfiles/test_regular.txt | 3056 ++++++++++
tests/yencfiles/test_regular_2.txt | 3053 ++++++++++
tests/yencfiles/test_single_part.txt | 132 +
tests/yencfiles/test_special_chars.txt | 3051 ++++++++++
travis/build-wheels.sh | 15 +
58 files changed, 22608 insertions(+), 748 deletions(-)
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..f8f1ea1
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,59 @@
+# Windows image file caches
+Thumbs.db
+ehthumbs.db
+
+# Folder config file
+Desktop.ini
+
+# Recycle Bin used on file shares
+$RECYCLE.BIN/
+
+# Windows Installer files
+*.cab
+*.msi
+*.msm
+*.msp
+
+# Windows shortcuts
+*.lnk
+
+# =========================
+# Operating System Files
+# =========================
+
+# OSX
+# =========================
+
+.DS_Store
+.AppleDouble
+.LSOverride
+
+# Thumbnails
+._*
+
+# Files that might appear in the root of a volume
+.DocumentRevisions-V100
+.fseventsd
+.Spotlight-V100
+.TemporaryItems
+.Trashes
+.VolumeIcon.icns
+
+# Directories potentially created on remote AFP share
+.AppleDB
+.AppleDesktop
+Network Trash Folder
+Temporary Items
+.apdisk
+
+# Building
+Build
+*.egg-info
+build
+examples
+test
+dist
+
+# Compiled python
+*.py[cod]
+__pycache__
\ No newline at end of file
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 0000000..8dfd18c
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,34 @@
+notifications:
+ email: false
+
+matrix:
+ include:
+ - sudo: required
+ services:
+ - docker
+ env: DOCKER_IMAGE=quay.io/pypa/manylinux1_x86_64
+ language: python
+ python: "2.7"
+ - sudo: required
+ services:
+ - docker
+ env: DOCKER_IMAGE=quay.io/pypa/manylinux1_i686 PRE_CMD=linux32
+ language: python
+ python: "2.7"
+ - os: osx
+ osx_image: xcode6.4
+ env: HOMEBREW_NO_AUTO_UPDATE=1
+
+install:
+- if [[ "$TRAVIS_OS_NAME" != "osx" ]]; then docker pull $DOCKER_IMAGE; fi
+# On macOS we need to build with GCC, because CLang is somehow much slower
+- if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then brew install python gcc; fi
+- if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then pip install --upgrade wheel setuptools; fi
+
+script:
+- mkdir wheelhouse
+- if [[ "$TRAVIS_OS_NAME" != "osx" ]]; then docker run --rm -v `pwd`:/io $DOCKER_IMAGE $PRE_CMD /io/travis/build-wheels.sh; fi
+- if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then env CC=gcc-6 python setup.py bdist_wheel --dist-dir wheelhouse; fi
+- ls -al wheelhouse/
+- pip install twine
+- twine upload --skip-existing -u Safihre -p $pypassword wheelhouse/*
diff --git a/CHANGES.md b/CHANGES.md
new file mode 100644
index 0000000..e69de29
diff --git a/LICENSE.md b/LICENSE.md
new file mode 100644
index 0000000..65c5ca8
--- /dev/null
+++ b/LICENSE.md
@@ -0,0 +1,165 @@
+ GNU LESSER GENERAL PUBLIC LICENSE
+ Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+
+ This version of the GNU Lesser General Public License incorporates
+the terms and conditions of version 3 of the GNU General Public
+License, supplemented by the additional permissions listed below.
+
+ 0. Additional Definitions.
+
+ As used herein, "this License" refers to version 3 of the GNU Lesser
+General Public License, and the "GNU GPL" refers to version 3 of the GNU
+General Public License.
+
+ "The Library" refers to a covered work governed by this License,
+other than an Application or a Combined Work as defined below.
+
+ An "Application" is any work that makes use of an interface provided
+by the Library, but which is not otherwise based on the Library.
+Defining a subclass of a class defined by the Library is deemed a mode
+of using an interface provided by the Library.
+
+ A "Combined Work" is a work produced by combining or linking an
+Application with the Library. The particular version of the Library
+with which the Combined Work was made is also called the "Linked
+Version".
+
+ The "Minimal Corresponding Source" for a Combined Work means the
+Corresponding Source for the Combined Work, excluding any source code
+for portions of the Combined Work that, considered in isolation, are
+based on the Application, and not on the Linked Version.
+
+ The "Corresponding Application Code" for a Combined Work means the
+object code and/or source code for the Application, including any data
+and utility programs needed for reproducing the Combined Work from the
+Application, but excluding the System Libraries of the Combined Work.
+
+ 1. Exception to Section 3 of the GNU GPL.
+
+ You may convey a covered work under sections 3 and 4 of this License
+without being bound by section 3 of the GNU GPL.
+
+ 2. Conveying Modified Versions.
+
+ If you modify a copy of the Library, and, in your modifications, a
+facility refers to a function or data to be supplied by an Application
+that uses the facility (other than as an argument passed when the
+facility is invoked), then you may convey a copy of the modified
+version:
+
+ a) under this License, provided that you make a good faith effort to
+ ensure that, in the event an Application does not supply the
+ function or data, the facility still operates, and performs
+ whatever part of its purpose remains meaningful, or
+
+ b) under the GNU GPL, with none of the additional permissions of
+ this License applicable to that copy.
+
+ 3. Object Code Incorporating Material from Library Header Files.
+
+ The object code form of an Application may incorporate material from
+a header file that is part of the Library. You may convey such object
+code under terms of your choice, provided that, if the incorporated
+material is not limited to numerical parameters, data structure
+layouts and accessors, or small macros, inline functions and templates
+(ten or fewer lines in length), you do both of the following:
+
+ a) Give prominent notice with each copy of the object code that the
+ Library is used in it and that the Library and its use are
+ covered by this License.
+
+ b) Accompany the object code with a copy of the GNU GPL and this license
+ document.
+
+ 4. Combined Works.
+
+ You may convey a Combined Work under terms of your choice that,
+taken together, effectively do not restrict modification of the
+portions of the Library contained in the Combined Work and reverse
+engineering for debugging such modifications, if you also do each of
+the following:
+
+ a) Give prominent notice with each copy of the Combined Work that
+ the Library is used in it and that the Library and its use are
+ covered by this License.
+
+ b) Accompany the Combined Work with a copy of the GNU GPL and this license
+ document.
+
+ c) For a Combined Work that displays copyright notices during
+ execution, include the copyright notice for the Library among
+ these notices, as well as a reference directing the user to the
+ copies of the GNU GPL and this license document.
+
+ d) Do one of the following:
+
+ 0) Convey the Minimal Corresponding Source under the terms of this
+ License, and the Corresponding Application Code in a form
+ suitable for, and under terms that permit, the user to
+ recombine or relink the Application with a modified version of
+ the Linked Version to produce a modified Combined Work, in the
+ manner specified by section 6 of the GNU GPL for conveying
+ Corresponding Source.
+
+ 1) Use a suitable shared library mechanism for linking with the
+ Library. A suitable mechanism is one that (a) uses at run time
+ a copy of the Library already present on the user's computer
+ system, and (b) will operate properly with a modified version
+ of the Library that is interface-compatible with the Linked
+ Version.
+
+ e) Provide Installation Information, but only if you would otherwise
+ be required to provide such information under section 6 of the
+ GNU GPL, and only to the extent that such information is
+ necessary to install and execute a modified version of the
+ Combined Work produced by recombining or relinking the
+ Application with a modified version of the Linked Version. (If
+ you use option 4d0, the Installation Information must accompany
+ the Minimal Corresponding Source and Corresponding Application
+ Code. If you use option 4d1, you must provide the Installation
+ Information in the manner specified by section 6 of the GNU GPL
+ for conveying Corresponding Source.)
+
+ 5. Combined Libraries.
+
+ You may place library facilities that are a work based on the
+Library side by side in a single library together with other library
+facilities that are not Applications and are not covered by this
+License, and convey such a combined library under terms of your
+choice, if you do both of the following:
+
+ a) Accompany the combined library with a copy of the same work based
+ on the Library, uncombined with any other library facilities,
+ conveyed under the terms of this License.
+
+ b) Give prominent notice with the combined library that part of it
+ is a work based on the Library, and explaining where to find the
+ accompanying uncombined form of the same work.
+
+ 6. Revised Versions of the GNU Lesser General Public License.
+
+ The Free Software Foundation may publish revised and/or new versions
+of the GNU Lesser General Public License from time to time. Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.
+
+ Each version is given a distinguishing version number. If the
+Library as you received it specifies that a certain numbered version
+of the GNU Lesser General Public License "or any later version"
+applies to it, you have the option of following the terms and
+conditions either of that published version or of any later version
+published by the Free Software Foundation. If the Library as you
+received it does not specify a version number of the GNU Lesser
+General Public License, you may choose any version of the GNU Lesser
+General Public License ever published by the Free Software Foundation.
+
+ If the Library as you received it specifies that a proxy can decide
+whether future versions of the GNU Lesser General Public License shall
+apply, that proxy's public statement of acceptance of any version is
+permanent authorization for you to choose that version for the
+Library.
diff --git a/MANIFEST.in b/MANIFEST.in
new file mode 100644
index 0000000..28e3353
--- /dev/null
+++ b/MANIFEST.in
@@ -0,0 +1 @@
+recursive-include src *
\ No newline at end of file
diff --git a/PKG-INFO b/PKG-INFO
deleted file mode 100644
index 569095a..0000000
--- a/PKG-INFO
+++ /dev/null
@@ -1,27 +0,0 @@
-Metadata-Version: 1.1
-Name: sabyenc
-Version: 3.0.2
-Summary: yEnc Module for Python modified for SABnzbd
-Home-page: https://github.com/sabnzbd/sabnzbd-yenc
-Author: Safihre
-Author-email: safihre at sabnzbd.org
-License: LGPLv3
-Description:
- yEnc Decoding for Python
- ---------------------------------
-
- Mofied the original yenc module by Alessandro Duca for use within SABnzbd.
-
- The module was extended to do header parsing and full yEnc decoding from a Python
- list of chunks, the way in which data is retrieved from usenet.
-
-Platform: UNKNOWN
-Classifier: Programming Language :: Python
-Classifier: Programming Language :: Python :: 2.7
-Classifier: Programming Language :: C
-Classifier: License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3)
-Classifier: Operating System :: Unix
-Classifier: Development Status :: 4 - Beta
-Classifier: Environment :: Other Environment
-Classifier: Topic :: Software Development :: Libraries :: Python Modules
-Classifier: Topic :: Communications :: Usenet News
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..2d12e01
--- /dev/null
+++ b/README.md
@@ -0,0 +1,28 @@
+SABYenc - yEnc Decoding for Python
+===============================
+
+Modified the original yenc module by Alessandro Duca <alessandro.duca at gmail.com>
+for use within SABnzbd.
+
+The module was extended to do header parsing and full yEnc decoding from a Python
+list of chunks, the way in which data is retrieved from usenet.
+This is particularly beneficial when SSL is enabled, which limits the size of each chunk to 16K. Parsing these chunks in python is much more costly.
+Additionally, this module releases Python's GIL during decoding, greatly increasing performance of the overall download process.
+
+Installing
+===============================
+As simple as running:
+```
+pip install sabyenc --upgrade
+```
+When you want to compile from sources, you can run in the `sabyenc` directory:
+```
+python setup.py install
+```
+
+Testing
+===============================
+For testing we use `pytest` (install via `pip install pytest`) and test can simply be executed by browsing to the `sabyenc` directory and running:
+```
+pytest
+```
diff --git a/appveyor.yml b/appveyor.yml
new file mode 100644
index 0000000..f441817
--- /dev/null
+++ b/appveyor.yml
@@ -0,0 +1,27 @@
+environment:
+ pypassword:
+ secure: fYF+6TvQdqbg7u+c+NraAg==
+
+ matrix:
+ # For Python versions available on Appveyor, see
+ # http://www.appveyor.com/docs/installed-software#python
+ # The list here is complete (excluding Python 2.6, which
+ # isn't covered by this document) at the time of writing.
+
+ - PYTHON: "C:\\Python27"
+ - PYTHON: "C:\\Python27-x64"
+
+install:
+ # We need wheel installed to build wheels
+ - "%PYTHON%\\python.exe -m pip install --upgrade setuptools wheel twine"
+
+after_test:
+ # This step builds your wheels.
+ # You need to use %PYTHON% to get the correct interpreter
+ - "%PYTHON%\\python.exe setup.py bdist_wheel"
+ - "%PYTHON%\\python.exe setup.py sdist"
+
+build: off
+
+on_success:
+ - "%PYTHON%\\python.exe -m twine upload --skip-existing -u Safihre -p %pypassword% dist/*"
diff --git a/doc/yenc-draft.1.3.txt b/doc/yenc-draft.1.3.txt
new file mode 100644
index 0000000..172fdba
--- /dev/null
+++ b/doc/yenc-draft.1.3.txt
@@ -0,0 +1,423 @@
+yEncode - A quick and dirty encoding for binaries
+---------------------------------------------------------------------------
+Version 1.2 - 28-Feb-2002 - by Juergen Helbing
+
+
+Revisions:
+v1.0, 31-Jul-2001 - Juergen Helbing (juergen at helbing.de)
+v1.1, 17-Feb-2002 - Steve Blinch (yenc32 at esitemedia.com)
+v1.2, 28-Feb-2002 - Juergen Helbing (juergen at helbing.de)
+v1.3, 05-Mar-2002 - Juergen Helbing (juergen at helbing.de)
+
+Introduction
+---------------------------------------------------------------------------
+This document describes a mechanism for encoding arbitrary binary
+information for transmission by electronic mail and newsgroups. Unlike
+similar encoding schemes, yEncode takes advantage of the entire 8-bit
+character set, rendering output only 1-2% larger than the original binary
+source.
+
+
+Motivation
+---------------------------------------------------------------------------
+Existing mechanisms for transmission of binary information by electronic
+mail and newsgroups make use of only 7-bit ASCII text. The resulting
+encoded data are up to 40% larger than the original binary information.
+
+yEncode intends to reduce the additional overhead of existing encoding
+schemes by taking advantage of the full 8-bit character set, which has
+become widely used and acceptable in Internet newsgroups. Special
+consideration is provided for specific reserved ASCII control characters to
+avoid interference with existing message transfer protocols.
+
+The overhead of yEncoded binary data can be as little as 1-2%.
+
+
+Encoding Principle
+---------------------------------------------------------------------------
+The encoding process represents each octet of input data with a single
+corresponding encoded output character. The ASCII value of each output
+character is derived by the following simple formula:
+
+O = (I+42) % 256
+
+That is, the output value is equal to the ASCII value of each input
+character plus 42, all modulo 256. This reduces overhead by reducing the
+number of NULL characters (ASCII 00) that would otherwise have had needed
+to be escaped, since many binaries contain a disproportionately large
+number of NULLs).
+
+Under special circumstances, a single escape character (ASCII 3Dh, "=") is
+used to indicate that the following output character is "critical", and
+requires special handling.
+
+Critical characters include the following:
+
+ASCII 00h (NULL)
+ASCII 0Ah (LF)
+ASCII 0Dh (CR)
+ASCII 3Dh (=)
+
+> ASCII 09h (TAB) -- removed in version (1.2)
+
+These characters should always be escaped. Additionally, technique used to
+encode critical characters (described in the next section) provides for any
+character to be escaped; yDecoder implementations should be capable of
+decoding any character following an escape sequence.
+
+The probability of occurance of these 4 characters in binary input data is
+approximately 0.4%. On average, escape sequences cause approximately 1.6%
+overhead when only these 4 characters are escaped.
+
+The carriage return/linefeed overhead for every line depends on the
+developer-defined line length. Header and trailer lines are relatively
+small, and cause negligible impact on output size.
+
+>(1.2) Careful writers of encoders will encode TAB (09h) SPACES (20h)
+>if they would appear in the first or last column of a line.
+>Implementors who write directly to a TCP stream will care about the
+doubling of dots in the first column - or also encode a DOT in the
+first column.
+
+
+Encoding Technique
+---------------------------------------------------------------------------
+A typical encoding process might look something like this:
+
+
+ 1. Fetch a character from the input stream.
+ 2. Increment the character's ASCII value by 42, modulo 256
+ 3. If the result is a critical character (as defined in the previous
+ section), write the escape character to the output stream and increment
+ character's ASCII value by 64, modulo 256.
+ 4. Output the character to the output stream.
+ 5. Repeat from start.
+
+
+To facilitate transmission via existing standard protocols (most notably
+NNTP), carriage return/linefeed pairs should be written to the output
+stream after every n characters, where n is the desired line length.
+Typical values for n are 128 and 256.
+>(1.2) See additional experience information
+
+If a critical character appears in the nth position of a line, both the
+escape character and the encoded critical character must be written to the
+same line, before the carriage return/linefeed. In this event, the actual
+number of characters in the line is equal to n+1. Effectively, this means
+that a line cannot end with an escape character, and that a line with n+1
+characters must end with an encoded critical character.
+
+
+Headers and Trailers
+---------------------------------------------------------------------------
+Similar to other binary encoding mechanisms, yEncode makes use of special
+keyword lines to mark the beginning and end of encoded data blocks. These
+blocks may be embedded in any standard 8-bit ASCII text file. yDecoder
+implementations must ignore any text outside the header/trailer blocks.
+
+All keyword lines must begin with an escape character ('='), followed by an
+ASCII 79h ('y'). This '=y' combination uniquely identifies a line as a
+keyword line, since 'y' is not a valid encoded critical character.
+
+Header and trailer keyword lines always begin with an escape character,
+followed by a keyword indicating the line type, followed by any keywords
+appropriate for that particular line type.
+
+A typical header line should look similar to this:
+
+
+=ybegin line=128 size=123456 name=mybinary.dat
+
+
+>(1.2) Future versions of yEnc (if any) might use a different keyword
+> than =ybegin. Perhaps "=ybegin2". Decoders should scan for "=ybegin "
+> - with a SPACE behind =ybegin.
+
+>(1.2) If the parameters "line=" "size=" "name=" are not present then
+>the =ybegin might be part of a text-message with a discussion about
+>yEnc. In such cases the decoder should assume that there is no binary.
+
+
+Header lines must always begin with the "ybegin" keyword, and contain the
+typical line length, the size of the original unencoded binary (in bytes),
+and the name of the original binary file.
+
+The filename must always be the last item on the header line. This ensures
+that all characters and character sequences may be included in the filename
+without interfering with other keywords. Although quotes (ASCII 22h, '"')
+are technically permitted, they are not recommended for use in filenames.
+
+> (1.2): Leading and trailing spaces will be cut by decoders!
+> (1.2): See additional experience information
+> Implementors of decoders should be careful about the filename.
+> It can contain non-US-ASCII-characters (80h-FFh), control-characters
+> (01h..1Fh), and characters which conflict with the current platform:
+> / \ < | > : ? * @
+> It can be a very long parameter (up to 256 characters).
+
+
+A typical trailer line should look similar to this:
+
+
+=yend size=123456
+
+
+Trailer lines must always begin with the "yend" keyword, and must contain
+the size of the original unencoded binary (in bytes).
+
+The size of the original binary must be repeated in the trailer for
+redundancy checking. yDecoder implementations should compare the header
+size value with both the trailer size value and the actual size of the
+resulting decoded binary. If any of these three values differ then the
+attachment is corrupt, and a warning must be issued; the resulting decoded
+binary must be discarded. (1.2) See additional experience information
+
+
+Verifying Integrity
+---------------------------------------------------------------------------
+yEncoded documents may also include a 32-bit Cyclic Redundancy Check (CRC)
+value, to assist in verifying the integrity of the encoded binary data.
+
+A CRC32 value, if present, should be included as a "crc32" keyword in the
+trailer line. Such a trailer line might look similar to this:
+
+
+=yend size=123456 crc32=abcdef12
+
+
+It should be noted that CRC32 values are not mandatory, but should, if
+possible, be processed if present.
+
+>(1.2) See additional experience information
+
+Sample yEncoded File Part
+---------------------------------------------------------------------------
+The following is an excerpt from an actual yEncoded file block:
+
+
+=ybegin line=128 size=111401 name=al_larsonbw030_ball.jpg
+)_)=J*:tpsp*++++V+V**)_*m*0./0/.00/011024:44334>896:A>....
+....
+....
+....R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴
+´R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴R̴Rͩ)_
+=yend size=111401
+
+
+Complete yEncoded file samples are also available at www.yenc.org.
+
+
+Multi-part Encoded Binaries
+---------------------------------------------------------------------------
+It is frequently desirable to split large binary files into multiple parts
+for transmissio n over the Internet. Such binaries are often rendered
+unusable by missing parts and/or data corruption.
+
+To address these problems, yEncode defines an additional keyword line,
+"ypart", and several additional keywords to handle multipart binaries.
+
+Each individual file part begins with a standard "ybegin" header line, but
+an additional keyword, "part", is added to specify the part number and
+identify the file as a multipart binary.
+
+When the "part" keyword is included in a header line, the following line
+must be a "ypart" keyword line which specifies information about the part.
+The "ypart" keyword line requires a "begin" and "end" keyword; these
+specify the starting and ending points, in bytes, of the block in the
+original file.
+
+The file part must end with a slightly modified "ypart" trailer line. An
+additional keyword, "part", is added to specify the part number. This part
+number must match the part number found in the header line.
+
+> (1.2) An additional keyword "total" should be also added.
+> This total number must match the total number of parts found in the header
+> line. First implementation of yEnc do NOT include this parameter.
+
+The trailer line must also contain a "pcrc32" keyword representing the
+CRC32 of the preceeding encoded part. As always, it is also desirable (but
+not required) to include a "crc32" keyword representing the CRC32 of the
+entire encoded binary.
+
+Unlike single-part yEncoded documents, the "size" keyword in the trailer
+lines of multipart encoded binaries must represent the size of the file
+part, not the size of the entire file. To verify integrity, a decoder
+implementation must recompute the expected part size from the "begin" and
+"end" keyword values in the "ypart" line. If the expected part size
+differs from the part size specified in the "yend" line, the file is
+corrupt.
+
+A sample multipart encoded binary might look similar to this:
+
+
+> (1.1) =ybegin part=1 line=128 size=500000 name=mybinary.dat
+> (1.2) =ybegin part=1 total=10 line=128 size=500000 name=mybinary.dat
+=ypart begin=1 end=100000
+.... data
+=yend size=100000 part=1 pcrc32=abcdef12
+
+
+=ybegin part=5 line=128 size=500000 name=mybinary.dat
+=ypart begin=400001 end=500000
+.... data
+=yend size=100000 part=10 pcrc32=12a45c78 crc32=abcdef12
+
+
+It should be noted that if a decoder does not implement multipart support,
+or fails to detect a multipart encoded binary, then it will not
+successfully decode the individual file parts because the "size" keyword in
+the "ybegin" line will differ from the "size" keyword in the "yend" line.
+
+Multipart binaries are usually quite sensitive to corruption. Transferring
+hundreds of megabytes in vain, simply because a corrupt part cannot be
+identified is a significant waste of bandwidth.
+
+Using the "begin" and "end" keywords, yEncode allows decoders to identify
+the position of an individual part in a larger file, which allows parts to
+be combined from several different sources regardless of the part size.
+This feature is unique to yEncode, and is very easy to include in an
+encoder implementation.
+
+
+Subject Line Conventions
+---------------------------------------------------------------------------
+Standard single-part yEncoded binaries require no special conventions for
+the subject line. It is recommended, however, that yEncoded binaries be
+specifically identified as such, until the yEncode encoding format becomes
+more widely implemented.
+
+The suggested format for subject lines for single-part binaries is:
+
+[Comment1] "filename" 12345 yEnc bytes [Comment2]
+
+[Comment1] and [Comment2] are optional. The filename should always be
+enclosed in quotes; this allows for easy detection, even when the filename
+includes spaces or other special characters. The word "yEnc" should be
+placed in between the file size and the word "bytes".
+> (1.2) see additional experience information
+> Placing the word "yEnc" between filename+bytes or bytes+comment2
+> is acceptable.
+
+Multi-part archives should always be identified as such. As with
+single-part binaries, they should also be identified as yEncoded until
+yEncoding becomes more mainstream.
+
+The (strongly) recommended format for subject lines for multi-part binaries
+is:
+
+[Comment1] "filename" yEnc (partnum/numparts) [size] [Comment2]
+
+Again, [Comment1] and [Comment2] are optional. The [size] value is also
+optional here. The filename must be included, in quotes. The keyword
+"yEnc" is mandatory, and must appear between the filename and the size (or
+Comment2, if size is omitted). Future revisions of the draft may specify
+additional information may be inserted between the "yEnc" keyword and the
+opening parenthesis of the part number.
+> (1.2) see additional experience information
+> Placing the word "yEnc" between (#/#)+size or size+comment2
+> is acceptable.
+
+
+>(1.2) Handling of corrupt messages
+>(1.2) -------------------------------------------------------------------
+
+Decoders should use error-detection whenever possible.
+The user should be notified about corrupt messages.
+If warnings are disabled then it is strongly recommended to store
+binaries with an error-text in the filename. Examples:
+
+picture(size-error).jpg
+homemovie(crc32-error).avi
+document(line-error).rtf
+longmusic(missing-parts).mp3
+
+It is acceptable to store also corrupt binaries
+(some might be even partially usable).
+But it is _not_ acceptable to hide detected errors from the user entirely.
+
+yEnc has the design target to _detect_ corruption.
+Advanced newsreaders might fetch corrupt messages even from other sources.
+
+
+
+Protection and Copyright
+---------------------------------------------------------------------------
+The yEncode encoding method is released into the public domain. Everyone
+is permitted to copy it, to use it, and to implement it.
+
+Neither this document nor the yEncode encoding method may be patented,
+protected, or restricted in any way. Everyone should benefit from it, and
+its predecessors.
+
+This document may be freely distributed, as long as credit remains with the
+original author(s). Do not claim that it's your own work!
+
+Public domain example software is also available at www.yenc.org.
+
+
+Credits
+---------------------------------------------------------------------------
+This document has been created based on my [Juergen Helbing] own personal
+experience, and help and input from a few Usenet activists. Thanks to:
+
+Jeremy Nixon
+Curt Welch
+Ed
+Andrew
+Stuart
+JBerg
+Marco d'Itri
+The Meowbot
+Jan Ingvoldstat
+The UseFor taskforce
+(others - please remind me!)
+....
+
+Draft revised (02/17/02) by Steve Blinch
+Draft extended (02/28/02) by Juergen Helbing
+
+
+Conclusion
+---------------------------------------------------------------------------
+This is an informal proposal, not an RFC. Your input is greatly
+appreciated. The author is just a poor programmer - with a few years of
+binary experience.
+
+Thanks for reading.
+
+Juergen Helbing (yenc at infostar.de)
+
+
+
+-----------------------
+Changes from 1.1 -> 1.2
+-----------------------
+
+The "total=" parameter has been added to =ybegin
+
+TAB is no longer a critical character
+No. of critical characters is now 4 (old: 5)
+
+Leading TABs & SPACEs, Trailing TABs and SPACEs and leading DOTs
+may be encoded as critical characters.
+
+Additional hints for filenames
+Additional hints for corrupted by size-value
+Additional hints for position of "yEnc" keyword
+Additional hints for line sizes
+
+Scanning for the keword =ybegin should scan for "=ybegin " with
+a SPACE at the end - for avoiding conflicts with successor versions
+of yEnc "=ybegin2 ".
+Missing parameters behind =ybegin
+
+Handling of corrupt messages.
+Mailbox changed
+
+
+Changes from 1.2 -> 1.3
+-----------------------
+"the proceeding character" --> "the following character" (N.R.)
+"modulo 255" -> "modulo 256" (J.H.)
+"should be encoded" -> "may be encoded" (J.B.)
+
diff --git a/examples/try_out_sabyenc.py b/examples/try_out_sabyenc.py
new file mode 100644
index 0000000..1fb69bc
--- /dev/null
+++ b/examples/try_out_sabyenc.py
@@ -0,0 +1,62 @@
+#!/usr/bin/env python
+
+'''
+This is example code how to use 'sabyenc' to decode yencoded articles (used on Usenet)
+
+More info on sabyenc:
+https://pypi.python.org/pypi/sabyenc
+https://github.com/sabnzbd/sabyenc
+'''
+
+import sabyenc # sudo -H pip install sabyenc --upgrade (after: sudo apt-get install python-dev)
+import sys
+import re
+
+print "Version of sabyenc on this system:", sabyenc.__version__
+
+# See if an input file (with yencoded info) was given as argument
+try:
+ inputfilename = sys.argv[1]
+ print "Reading from", inputfilename
+ with open (inputfilename, "r") as myfile:
+ data=myfile.readlines()
+except:
+ # No input, so use a pre-fab yencoded file / string, just like you get the BODY (or ARTICLE) from a newsserver
+ # source: http://nzbindex.com/search/?q=verysmallfile+2384928394820394
+
+ data = ['=ybegin line=128 size=173 name=smallfile.rar\r\n',
+ '|\x8b\x9cKD1*\xf9\xba\x9d**7*******\xcb\xfb\x9eJ\xaa[*\x8b***\x8b***-MW\xe5\xb8\x8e\x92\x95s>Z;*\xde\xab**\x9e\x8f\x9d\x9eW[ZZ\x8c\xa3\x9e\x8f\x9dX\x93\x97\x91\x8b\x8c\x8d\x8e\x8f\x8e\x90\x91\x92\x93\x944\x8b\x8c\x8d\x8e\x8f\x8e\x90\x91\x92\x93\x944\x8b\x8c\x8d\x8e\x8f\x8e\x90\x91\x92\x93\x944\x8b\x8c\x8d\x8e\x8f\x8e\x90\x91\x92\x93\x944\x8b\x8c\x8d\x8e\x8f\x8e\x90\x91\x92\x93\x94\r\n',
+ '4\x8b\x8c\x8d\x8e\x8f\x8e\x90\x91\x92\x93\x944\x8b\x8c\x8d\x8e\x8f\x8e\x90\x91\x92\x93\x944\x8b\x8c\x8d\x8e\x8f\x8e\x90\x91\x92\x93\x9444\xeeg\xa5*j1*\r\n',
+ '=yend size=173 crc32=8828b45c\r\n']
+
+print "\nINPUT:"
+print "First Line", data[0].rstrip()
+print "Last Line", data[-1].rstrip()
+
+
+# Find size in laste line of yencoded message:
+lastline = data[-1] # For example: '=yend size=173 crc32=8828b45c\r\n' (and ... assuming it's in the last line)
+m = re.search('size=(.\d+?) ', lastline)
+if m:
+ size = int(m.group(1))
+print "size of decoded info will be", size
+
+# Now do the yencode-decoding using sabyenc:
+decoded_data, output_filename, crc, crc_yenc, crc_correct = sabyenc.decode_usenet_chunks(data,size)
+
+print "\nOUTPUT:"
+
+#print "decoded_data, first 20 bytes (Warning: probably binary stuff!):\n", decoded_data[:20]
+print "decoded_data -> length:", len(decoded_data)
+print "output_filename:", output_filename
+print "crc:", crc
+print "crc_yenc:", crc_yenc
+print "crc_correct:", crc_correct
+
+print "\nWriting to:", output_filename
+file = open(output_filename, "w")
+file.write(decoded_data)
+file.close()
+
+print "Done"
+
diff --git a/sabyenc.egg-info/PKG-INFO b/sabyenc.egg-info/PKG-INFO
deleted file mode 100644
index 569095a..0000000
--- a/sabyenc.egg-info/PKG-INFO
+++ /dev/null
@@ -1,27 +0,0 @@
-Metadata-Version: 1.1
-Name: sabyenc
-Version: 3.0.2
-Summary: yEnc Module for Python modified for SABnzbd
-Home-page: https://github.com/sabnzbd/sabnzbd-yenc
-Author: Safihre
-Author-email: safihre at sabnzbd.org
-License: LGPLv3
-Description:
- yEnc Decoding for Python
- ---------------------------------
-
- Mofied the original yenc module by Alessandro Duca for use within SABnzbd.
-
- The module was extended to do header parsing and full yEnc decoding from a Python
- list of chunks, the way in which data is retrieved from usenet.
-
-Platform: UNKNOWN
-Classifier: Programming Language :: Python
-Classifier: Programming Language :: Python :: 2.7
-Classifier: Programming Language :: C
-Classifier: License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3)
-Classifier: Operating System :: Unix
-Classifier: Development Status :: 4 - Beta
-Classifier: Environment :: Other Environment
-Classifier: Topic :: Software Development :: Libraries :: Python Modules
-Classifier: Topic :: Communications :: Usenet News
diff --git a/sabyenc.egg-info/SOURCES.txt b/sabyenc.egg-info/SOURCES.txt
deleted file mode 100644
index 1d19e4c..0000000
--- a/sabyenc.egg-info/SOURCES.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-setup.py
-sabyenc.egg-info/PKG-INFO
-sabyenc.egg-info/SOURCES.txt
-sabyenc.egg-info/dependency_links.txt
-sabyenc.egg-info/top_level.txt
-src/sabyenc.c
-src/sabyenc.h
\ No newline at end of file
diff --git a/sabyenc.egg-info/dependency_links.txt b/sabyenc.egg-info/dependency_links.txt
deleted file mode 100644
... 22793 lines suppressed ...
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-sabyenc.git
More information about the Python-modules-commits
mailing list