System Error on tar.bz2 upload

  Module zope.tales.expressions, line 198, in _eval
    return ob()
  Module canonical.launchpad.browser.potemplate, line 135, in submitForm
    self.upload()
  Module canonical.launchpad.browser.potemplate, line 174, in upload
    tarball = helpers.RosettaReadTarFile(stream=file)
  Module canonical.launchpad.helpers, line 126, in __init__
    self.tarfile = tarfile.open('', 'r', stream)
  Module tarfile, line 916, in open
    return func(name, "r", fileobj)
  Module tarfile, line 996, in bz2open
    raise ValueError, "no support for external file objects"
ValueError: no support for external file objects

It seems this is a problem with Python's bz2 module:

http://mail.python.org/pipermail/python-list/2005-August/296538.html

There's a workaround for this, which is to use

tarfile.open('', 'r|bz2', stream)

when the filename ends in '.bz2'. This means telling RosettaReadTarFile about the original filename when it is instantiated so that it can inspect it later.

Today someone on launchpad run into this bug so I'll append his oops id here:
OOPS-40A801

I just implemented a fix for this, but introduces a new dependency on launchpad so I'm waiting for an approval of it

I agree with James' consideration that you could probably do the sniffing yourself and avoid the extra dependency. What do you think?

Implemented looking directly for the bz2 magic code instead of use python2.4-magic.

It seems the workaround isn't working as per this OOPS-119D172
I'll re-open this bug.

Diogo, I think OOPS-119D172 is a different issue. See bug 44773, which is caused by tar.gz file uploads failing because of a bug in Python causing the bz2 file opener to raise ValueError before it tries the gz opener. The URL in that oops is the same as in 44773, and a user on the list reported they had 44773 with tar.gz files.

So that OOPS is a different bug, that tar.gz uploads fail, and is different to the (fixed) bug that tar.bz2 uploads fail. I recommend re-closing this bug.

(It's hard to be certain, because the OOPS report doesn't contain the filename or first few bytes of the uploaded file, so we're not sure which format file caused any particular OOPS, but it seems to be a safe bet here.)

Re-closing as per Andrew recommendation. Thanks for clarifying.