Bug 1180861 - Please update python-boto to the latest version (v2.36.0)
Summary: Please update python-boto to the latest version (v2.36.0)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: python-boto
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Garrett Holmstrom
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-11 09:48 UTC by Elad Alfassa
Modified: 2015-06-19 05:36 UTC (History)
5 users (show)

Fixed In Version: python-boto-2.38.0-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-13 19:35:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Elad Alfassa 2015-01-11 09:48:54 UTC
python-boto 2.35.1 is available. The version in EPEL is 2.34.0.

Please update the package in EPEL to 2.35.1

Thanks.

Comment 1 Garrett Holmstrom 2015-01-16 07:30:40 UTC
This is currently blocked by a regression that was introduced in version 2.35.0:  https://github.com/boto/boto/issues/2885

Comment 2 Elad Alfassa 2015-03-26 09:38:42 UTC
According to the github issue mentioned here, this is just a clock skew issue. Meanwhile, boto is already at 2.36.0, and EPEL is still at 2.34.0

Comment 3 Fedora Update System 2015-04-10 23:50:57 UTC
python-boto-2.38.0-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/python-boto-2.38.0-1.fc21

Comment 4 Fedora Update System 2015-04-10 23:51:45 UTC
python-boto-2.38.0-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/python-boto-2.38.0-1.fc20

Comment 5 Fedora Update System 2015-04-10 23:54:06 UTC
python-boto-2.38.0-1.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/python-boto-2.38.0-1.el7

Comment 6 Fedora Update System 2015-04-10 23:56:12 UTC
python-boto-2.38.0-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-boto-2.38.0-1.el6

Comment 7 Fedora Update System 2015-04-12 02:44:32 UTC
Package python-boto-2.38.0-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing python-boto-2.38.0-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5760/python-boto-2.38.0-1.el6
then log in and leave karma (feedback).

Comment 8 Stefan van der Eijk 2015-04-16 20:32:04 UTC
python-boto-2.38.0-1.el6.noarch breaks duplicity-0.7.02-2.1.csc.x86_64 on centos6:
BackendException: Could not initialize backend: No module named vendored

Comment 9 Garrett Holmstrom 2015-04-17 02:16:56 UTC
Do you have the full traceback?  I suspect it may be using a code path I somehow didn't reach while testing with unbundled python-six.

Comment 10 Stefan van der Eijk 2015-04-21 21:36:48 UTC
(In reply to Garrett Holmstrom from comment #9)
> Do you have the full traceback?  I suspect it may be using a code path I
> somehow didn't reach while testing with unbundled python-six.

how do I do a full traceback?

Comment 11 Garrett Holmstrom 2015-04-22 04:50:25 UTC
To be honest, I am not 100% sure.  :-\  Try running it with -v9.

This could be due to having an old version of python-six.  Which version of python-six do you have installed, and where did you get that duplicity package from?

Comment 12 Stefan van der Eijk 2015-04-22 05:34:19 UTC
python-six-1.7.3-1.el6.centos.noarch

The duplicity package can be found in this repo: http://anorien.csc.warwick.ac.uk/mirrors/OBS/warwick.ac.uk:/CSC:/Public/CentOS_6/

Last part of the output when running it with -v9:

Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.copycombackend Succeeded
Import of duplicity.backends.dpbxbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Failed: invalid syntax (onedrivebackend.py, line 175)
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Using temporary directory /tmp/duplicity-CNVVda-tempdir
Backend error detail: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1519, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1513, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1354, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib64/python2.6/site-packages/duplicity/commandline.py", line 1070, in ProcessCommandLine
    backup, local_pathname = set_backend(args[0], args[1])
  File "/usr/lib64/python2.6/site-packages/duplicity/commandline.py", line 961, in set_backend
    globals.backend = backend.get_backend(bend)
  File "/usr/lib64/python2.6/site-packages/duplicity/backend.py", line 223, in get_backend
    obj = get_backend_object(url_string)
  File "/usr/lib64/python2.6/site-packages/duplicity/backend.py", line 211, in get_backend_object
    raise BackendException(_("Could not initialize backend: %s") % str(sys.exc_info()[1]))
BackendException: Could not initialize backend: No module named vendored

BackendException: Could not initialize backend: No module named vendored

Comment 13 Fedora Update System 2015-06-06 23:54:56 UTC
python-boto-2.38.0-1.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 eyal.roth 2015-06-07 14:32:37 UTC
The release of 'python-boto-2.38.0-1.el7' to the stable repository seems to be bugged.

I just installed a new CentOS-7 machine today, installed 'python-boto' and got an error:

[vagrant@localhost ~]$ python
Python 2.7.5 (default, Jun 17 2014, 18:11:42)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import boto
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/boto/__init__.py", line 27, in <module>
    from boto.pyami.config import Config, BotoConfigLocations
  File "/usr/lib/python2.7/site-packages/boto/pyami/config.py", line 29, in <module>
    from boto.compat import expanduser, ConfigParser, StringIO
  File "/usr/lib/python2.7/site-packages/boto/compat.py", line 58, in <module>
    from boto.vendored import six
ImportError: No module named vendored

Installing the older rpm 'python-boto-2.34.0-4.el7' works as expected: http://koji.fedoraproject.org/koji/buildinfo?buildID=591755

Comment 15 Fedora Update System 2015-06-07 16:00:08 UTC
python-boto-2.38.0-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2015-06-07 16:05:03 UTC
python-boto-2.38.0-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Garrett Holmstrom 2015-06-09 20:29:32 UTC
The failure on RHEL 7 is bug 1229863.

Comment 18 Fedora Update System 2015-06-13 19:35:44 UTC
python-boto-2.38.0-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Stefan van der Eijk 2015-06-16 09:25:23 UTC
Thanks for breaking duplicity on centos6. The error in comment 12 is still caused by the updated python-boto package.

Comment 20 Garrett Holmstrom 2015-06-16 17:23:54 UTC
I haven't been able to reproduce that.  What exactly did you invoke?

Comment 21 Stefan van der Eijk 2015-06-17 11:53:06 UTC
You can find the duplicity package by following the link in comment 12. 

This is the command I'm using (s3 bucket name starred out):

duplicity \
>         / \
>         --s3-european-buckets \
>         --s3-use-multiprocessing \
>         --s3-use-new-style \
>         --encrypt-key="${GPG_KEY}" \
>         --sign-key="${GPG_KEY}" \
>         --full-if-older-than 1M \
>         s3://s3-eu-west-1.amazonaws.com/*****************/
BackendException: Could not initialize backend: No module named vendored

Comment 22 Garrett Holmstrom 2015-06-18 21:00:40 UTC
Works for me:

% /usr/bin/duplicity -v9 --s3-european-buckets --s3-use-multiprocessing --s3-use-new-style --full-if-older-than 1M /var/tmp/foo s3://s3-eu-west-1.amazonaws.com/gholms-test-02/
Using archive dir: /root/.cache/duplicity/0b436d0e2efd7a96575243c9d8a676c2
Using backup name: 0b436d0e2efd7a96575243c9d8a676c2
Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.copycombackend Succeeded
Import of duplicity.backends.dpbxbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Failed: invalid syntax (onedrivebackend.py, line 175)
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Setting multipart boto backend process pool to 4 processes
Main action: inc
================================================================================
duplicity 0.7.02 (March 11, 2015)
Args: /usr/bin/duplicity -v9 --s3-european-buckets --s3-use-multiprocessing --s3-use-new-style --full-if-older-than 1M /var/tmp/foo s3://s3-eu-west-1.amazonaws.com/gholms-test-02/
...

This is with python-boto-2.38.0-1.el6 and duplicity-0.7.02-2.2.csc.

Do you have a manually-installed copy of boto sitting around somewhere?  What does ``python -c 'import boto; print boto.__version__, boto.__file__''' yield?

Comment 23 Stefan van der Eijk 2015-06-18 21:08:11 UTC
# python -c 'import boto; print boto.__version__, boto.__file__'''
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.6/site-packages/boto/__init__.py", line 27, in <module>
    from boto.pyami.config import Config, BotoConfigLocations
  File "/usr/lib/python2.6/site-packages/boto/pyami/config.py", line 29, in <module>
    from boto.compat import expanduser, ConfigParser, StringIO
  File "/usr/lib/python2.6/site-packages/boto/compat.py", line 58, in <module>
    from boto.vendored import six
ImportError: No module named vendored

Comment 24 Garrett Holmstrom 2015-06-18 23:37:29 UTC
Well, that's certainly the right place on the filesystem.  The other thing that tends to cause that exception is an insufficiently-recent version of python-six, but the version you mentioned earlier is the same one I tested with, and it definitely works.  Is that the one python is using or could there be a locally-installed copy lurking somewhere?  (python -c 'import six; print six.__version__, six.__file__')

If that points to /usr/lib/python2.6/site-packages/six.pyc and you're positive the version is correct then I'm more or less out of ideas.  Do you have any?  Are you able to replicate this on a clean install?

Comment 25 Stefan van der Eijk 2015-06-19 05:36:57 UTC
$ python -c 'import six; print six.__version__, six.__file__'
1.2.0 /usr/lib/python2.6/site-packages/six-1.2.0-py2.6.egg/six.pyc

$ rpm -qf /usr/lib/python2.6/site-packages/six-1.2.0-py2.6.egg
file /usr/lib/python2.6/site-packages/six-1.2.0-py2.6.egg is not owned by any package

Ah!

$ ls /usr/lib/python2.6/site-packages | grep six
six-1.2.0-py2.6.egg
six-1.7.3-py2.6.egg-info
six.py
six.pyc
six.pyo

$ rpm -qf /usr/lib/python2.6/site-packages/*six*
file /usr/lib/python2.6/site-packages/six-1.2.0-py2.6.egg is not owned by any package
python-six-1.7.3-1.el6.centos.noarch
python-six-1.7.3-1.el6.centos.noarch
python-six-1.7.3-1.el6.centos.noarch
python-six-1.7.3-1.el6.centos.noarch

Moved away the unowned file. Now:

$ python -c 'import six; print six.__version__, six.__file__'
1.7.3 six.pyc

It now works. Mystery solved.


Note You need to log in before you can comment on or make changes to this bug.