Test bzrlib.tests.test_tuned_gzip.TestToGzip.test_enormous_chunk fails - potential regression in python2.7 2.7.3-15ubuntu1

[Jean-Baptiste Lallement]

The following test bzrlib.tests.test_tuned_gzip.TestToGzip.test_enormous_chunk fails with:

======================================================================
FAIL: bzrlib.tests.test_tuned_gzip.TestToGzip.test_enormous_chunks
----------------------------------------------------------------------
_StringException: Empty attachments:
  log

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/test_tuned_gzip.py", line 129, in test_enormous_chunks
    self.assertToGzip(['a large string\n'*1024*256])
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/test_tuned_gzip.py", line 116, in assertToGzip
    self.assertEqual(bytes, decoded)
AssertionError: not equal:
a = 'a large string\na large string\na large string\na larg
[...]

This is reproducible with:
$ bzr selftest -s bzrlib.tests.test_tuned_gzip.TestToGzip.test_enormous_chunk

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: bzr 2.6.0~bzr6571-4ubuntu1
ProcVersionSignature: Ubuntu 3.8.0-2.6-generic 3.8.0-rc4
Uname: Linux 3.8.0-2-generic x86_64
ApportVersion: 2.8-0ubuntu4
Architecture: amd64
Date: Tue Feb 5 10:17:58 2013
MarkForUpload: True
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: bzr
UpgradeStatus: Upgraded to raring on 2012-01-31 (370 days ago)

[Vincent Ladeuil (vila)]

As discussed on IRC, the test starts succeed with:

  self.assertToGzip(['a large string\n'*1024*34])

and starts failing with:

  self.assertToGzip(['a large string\n'*1024*35])

[Vincent Ladeuil (vila)]

s/starts succeed/succeed with values up to 34 (instead of 256).

[Jean-Baptiste Lallement (jibel)]

Actually the decoded string is much shorter (511630 characters) than the original string (3932160 characters)

[Jean-Baptiste Lallement (jibel)]

After further analysis and downgrading python2.7 this issue is not reproducible with python2.7 2.7.3-14ubuntu1 (it started with python2.7 2.7.3-15ubuntu1) , so it's potentially a regression introduced in python2.7 2.7.3-15ubuntu1

[Jean-Baptiste Lallement (jibel)]

The regression in the testsuite could have been introduced by this change
    - Issue #1159051: GzipFile now raises EOFError when reading a corrupted file with truncated header or footer. (http://bugs.python.org/issue1159051)

[Matthias Klose (doko)]

from the python tracker:

tuned_gzip does dangerous things, it overloads private methods of GzipFile.

From Bazaar 2.3 Release Notes:

* Stop using ``bzrlib.tuned_gzip.GzipFile``. It is incompatible with
  python-2.7 and was only used for Knit format repositories, which haven't
  been recommended since 2007. The file itself will be removed in the next
  release. (John Arbash Meinel)

Current version is 2.6b2. bzrlib.tuned_gzip.GzipFile should be removed two releases ago.

[Launchpad Janitor (janitor)]

This bug was fixed in the package python2.7 - 2.7.3-16ubuntu2

---------------
python2.7 (2.7.3-16ubuntu2) raring; urgency=low

  * Update to 20130315, taken from the 2.7 branch.
    - Issue #1285086: Get rid of the refcounting hack and speed
      up urllib.unquote().
    - Issue #17368: Fix an off-by-one error in the Python JSON decoder
      that caused a failure while decoding empty object literals when
      object_pairs_hook was specified.
    - Issue #17299: Add test coverage for cPickle with file objects and general
      IO objects.
    - Issue #11963: Remove human verification from test_parser and
      test_subprocess.
    - Issue #16004: Add `make touch`.
    - Issue #17412: Update 2.7 Doc/make.bat to also use sphinx-1.0.7.
    - Issue #17047: Remove doubled words in docs and docstrings.
  * Revert the patch for Issue #1159051, handling corrupted gzip files
    with unexpected EOF. LP: #1116079.
 -- Matthias Klose <email address hidden> Fri, 15 Mar 2013 12:20:10 -0700

[Robert Collins (lifeless)]

Agreed, this is most likely a bzr bug in obsolete code. I'd want to see a reproduction on the base gzip class before assessing this as a Python upstream issue. We'd see rather massive issues if it was an upstream issue.

[Dimitri John Ledkov (xnox)]

Remove explicit target raring from bzr task, thus to remove it from the rls-r-tracking bugs report. Python got uploaded thus this issue is not a priority for raring release at the moment.

[Matthias Klose (doko)]

reverted:

* Revert the patch for Issue #1159051, handling corrupted gzip files
    with unexpected EOF. LP: #1116079.

so bzr needs the fix for raring.

[Matthias Klose (doko)]

bzr issue now tracked in #1160572 for raring

[Launchpad Janitor (janitor)]

This bug was fixed in the package bzr - 2.6.0~bzr6571-4ubuntu2

---------------
bzr (2.6.0~bzr6571-4ubuntu2) raring; urgency=low

  * Remove the test_tuned_gzip.TestToGzip.test_enormous_chunks test.
    LP: #1116079, #1160572.
 -- Matthias Klose <email address hidden> Tue, 02 Apr 2013 12:09:24 +0200