Error while running pip

[get....@gmail.com]

I'm trying to upgrade pip, but this error happens:

ci20@ci20:~$ sudo pip install -U pip
[sudo] password for ci20:
Cleaning up...
Exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in main
    status = self.run(options, args)
  File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 290, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "/usr/lib/python2.7/dist-packages/pip/req.py", line 1097, in prepare_files
    req_to_install, self.upgrade)
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 194, in find_requirement
    page = self._get_page(main_index_url, req)
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 568, in _get_page
    session=self.session,
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 694, in get_page
    req, link, "connection error: %s" % exc, url,
TypeError: __str__ returned non-string (type Error)

Storing debug log for failure in /root/.pip/pip.log
ci20@ci20:~$ pip install -U pip
Cleaning up...
Exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in main
    status = self.run(options, args)
  File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 290, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "/usr/lib/python2.7/dist-packages/pip/req.py", line 1097, in prepare_files
    req_to_install, self.upgrade)
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 194, in find_requirement
    page = self._get_page(main_index_url, req)
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 568, in _get_page
    session=self.session,
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 694, in get_page
    req, link, "connection error: %s" % exc, url,
TypeError: __str__ returned non-string (type Error)

Storing debug log for failure in /home/ci20/.pip/pip.log
ci20@ci20:~$

ci20@ci20:~$ uname -a
Linux ci20 3.18.3-ci20-1 #1 SMP PREEMPT Wed May 25 10:24:41 UTC 2016 mips GNU/Linux

Any solutions?

[Paul Boddie]

On Monday, November 27, 2017 at 2:09:41 PM UTC+1, get....@gmail.com wrote:

I'm trying to upgrade pip, but this error happens:

 

Perhaps ask on the appropriate Python mailing lists or IRC?

https://mail.python.org/mailman/listinfo/distutils-sig
https://www.python.org/community/irc/

I'm not sure if the error is really specific to the CI20. I guess it could have something to do with the Debian package providing pip, though. I do wonder if pip is indeed upgradeable in this way within Debian, because that would be a rather un-Debian thing to do.

One thing you might do is to try and see what the values are in the place where the error occurs. Just adding a print statement before the error line with something like this might help:

print repr(exc)

It looks like something tries to convert an exception/error to a string (fairly common and unremarkable) which actually fails. Why there is an exception/error in the first place might also be worth investigating, although the packaging infrastructure for Python is not exactly the most robust thing out there, so they might easily occur if some remote resource is down or has moved.

Paul

[get....@gmail.com]

The problem was the system time. Whenever I reboot the system, it goes back to 2014.
Once I set the date manually, everything works fine :)

[Paul Boddie]

On Tuesday, November 28, 2017 at 5:27:48 AM UTC+1, get....@gmail.com wrote:

The problem was the system time. Whenever I reboot the system, it goes back to 2014.
Once I set the date manually, everything works fine :)

 

That's a strange failure mode, but I imagine that quite a bit of software can act strangely with a date in the past.

I probably need to set up network time initialisation to avoid having to set the date every time I power up the CI20. It's good that it doesn't have a nasty "coin cell" battery mounted on the board that is both hazardous when used with such a "bare" unit (for people with young children and pets around) and also ultimately harmful to the hardware (opening up old gear can be an eye-opener), but then other measures are needed for settings persistence.

Paul

[Maarten ter Huurne]

On Wednesday, 29 November 2017 01:03:45 CET Paul Boddie wrote:
> On Tuesday, November 28, 2017 at 5:27:48 AM UTC+1, get....@gmail.com
wrote:
> > The problem was the system time. Whenever I reboot the system, it
> > goes back to 2014.
> > Once I set the date manually, everything works fine :)
>
> That's a strange failure mode, but I imagine that quite a bit of
> software can act strangely with a date in the past.

My guess would be that a certificate check failed because the start date
was considered to be in the future, but there was an error in the code
handling that. Error handling code is often poorly tested.

Bye,
Maarten