This comment pertains to the bug report/comment by my above, and *not* to the bug originally reported by Brian Kelly, I believe.
I upgraded 4 machine. Two of those machines had Python 3 installed under /usr/local (from source). The other two did not have Python 3 installed under /usr/local. The two machines with Python 3 at /usr/local failed during the upgrade; the two that did not have Python 3 under /usr/local did not fail.
So, I removed Python 3 from /usr/local/bin and /usr/local/lib. Now, I can run `sudo aptitude full-upgrade` without failures.
Is it possible that this means that there is some Python script that is run during the install/upgrade than has "#!/usr/bin/env python3" at the top and that is being run as:
$ ./somescript.py
instead of as:
$ python3 ./somescript.py
Although, since "local" does not seem to show up in the traceback, I'm not sure ...
This comment pertains to the bug report/comment by my above, and *not* to the bug originally reported by Brian Kelly, I believe.
I upgraded 4 machine. Two of those machines had Python 3 installed under /usr/local (from source). The other two did not have Python 3 installed under /usr/local. The two machines with Python 3 at /usr/local failed during the upgrade; the two that did not have Python 3 under /usr/local did not fail.
So, I removed Python 3 from /usr/local/bin and /usr/local/lib. Now, I can run `sudo aptitude full-upgrade` without failures.
Is it possible that this means that there is some Python script that is run during the install/upgrade than has "#!/usr/bin/env python3" at the top and that is being run as:
$ ./somescript.py
instead of as:
$ python3 ./somescript.py
Although, since "local" does not seem to show up in the traceback, I'm not sure ...