CROS_SDK fails unless python is explicitly set.

[Alex Frick]

Since M93, my chromium os builds were failing when making the chroot. The issues happened on fresh installs and old installs of Ubuntu 18.04.5, and Debian 10. It would throw errors after the tar unpack relating to .py files in chromite. After trying lots of different things, and running cros_sdk --delete, and completely rebuilding chromiumos source tree in between each one (so annoying, took hours) Everything ran smoothly after a simple update alternatives pointing python > python2.7.2 & python2.7.2 > python2.7.2 & python3 > python3.6.9. This was never needed before, and these alternatives are not set at all on debian 10 and ubuntu 16.04/18.04. I've never had issues and have been building my own CrOS with added firmware and media codecs since M78. This is strange and only happened like I said after M93. It happened even when using default amd64 and arm64 overlays. This is significant because setting python versions is not mentioned at all in the how to docs, nor has it ever been (in my experience) needed for anything in the chromium, chromiumos, or cros_sdk toolchain.

[Mike Frysinger]

we do not require /usr/bin/python point to any specific version of python.  if you're seeing misbehavior, it's probably a bug, but it's hard to say what's wrong without any example commands or logs.

-mike

On Tue, Jun 29, 2021 at 8:23 AM Alex Frick <alex3...@gmail.com> wrote:

Since M93, my chromium os builds were failing when making the chroot. The issues happened on fresh installs and old installs of Ubuntu 18.04.5, and Debian 10. It would throw errors after the tar unpack relating to .py files in chromite. After trying lots of different things, and running cros_sdk --delete, and completely rebuilding chromiumos source tree in between each one (so annoying, took hours) Everything ran smoothly after a simple update alternatives pointing python > python2.7.2 & python2.7.2 > python2.7.2 & python3 > python3.6.9. This was never needed before, and these alternatives are not set at all on debian 10 and ubuntu 16.04/18.04. I've never had issues and have been building my own CrOS with added firmware and media codecs since M78. This is strange and only happened like I said after M93. It happened even when using default amd64 and arm64 overlays. This is significant because setting python versions is not mentioned at all in the how to docs, nor has it ever been (in my experience) needed for anything in the chromium, chromiumos, or cros_sdk toolchain.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev

[Alex Frick]

Thats whats so weird though. Just to debug, as I said before, I made a two new partitions, with fresh deb 10 and ubuntu 18 installs, updated them, then followed the developer docs to a T which has always worked before. Doing the python pointing that made it work on my main partition fixed it just the same on the fresh deb 10 and ubuntu installs. The python and depot tools latest versions are both older than when the problem started appearing, but the cros_sdk is not. Also just tried in a virtual machine with 20.04 with the same bug and same fix occuring. So idk, I know it shouldn't affect things and pointing to a specific python version isn't mentioned anywhere, yet it still occurs. Removing all the python alternatives, deleting the chroot, and rebuilding causes the same behavior. Running bootstrap also fixes it, I just found out,  within the VM 20.04. All this points to a bug in the premade chroot tarball. But IDK Im just posting to make it known. I will cause the bug again and copy and paste the traceback here soon, so maybe you or someone else can have a looksie.

[Alex Frick]

Correction, it WAS depot_tools, the latest depot tools (updated 33 hours ago) fixes this with no python stuff necessary. The latest commits here >> https://chromium.googlesource.com/chromium/tools/depot_tools.git/+log since  commit 4577360 all reference python3 problems and vpython and include fixing cros_sdk errors. They are reverts encompassing the past couple of days. So looks like it was a bug upstream and not on my systems after all.

On Tuesday, June 29, 2021 at 10:05:42 AM UTC-5 Mike Frysinger wrote: