same on elm , 57.0.2987.137

emerge calls /usr/bin/python2.7, but python2.7 is in /usr/local/bin. /usr/bin/python is a symlink:

ls -l /usr/bin/python
lrwxrwxrwx. 1 root root 24 Mar 29 04:16 /usr/bin/python -> /usr/local/bin/python2.7

So emerge should call python2.7 in /usr/local/bin, or call the symlink.

Same on cyan, M61:
Installing (3 of 9) dev-python/six-1.10.0::portage-stable to /usr/local/
 * Running stacked hooks for pre_pkg_preinst
 *    wrap_old_config_scripts ...                                                                     [ ok ]
/usr/local/var/tmp/portage/dev-python/six-1.10.0/temp/environment: line 3222: /usr/bin/python2.7: No such file or directory
 * ERROR: dev-python/six-1.10.0::portage-stable failed (preinst phase):
 *   (no error message)
 * 

Hmm would it work better if $EPYTHON instead of PYTHON in the six ebuild?

There are a lot of places that use $PYTHON and expect it to point to the right path. And python_export() really assumes that all python implementations are in /usr/bin:

python_export() {
...
        for var; do
                case "${var}" in
...
                        PYTHON)
                                export PYTHON=${EPREFIX}/usr/bin/${impl}


Seems like we should probably arrange a symlink not only for /usr/bin/python -> /usr/local/... but also for the implementations of it (e.g., python2.7).

We do this for dev and test images in src/scripts/build_library/dev_image_util.sh:

  # If python is installed on stateful-dev, fix python symlinks.
  # Really we need to do this in order to clean up the python-wrapper
  # mess from the eselect-python package.
  if [[ -n $(ls "${root_fs_dir}"/usr/local/bin/python* 2>/dev/null) ]]; then
    local pyver=$(ROOT="${root_fs_dir}/usr/local" eselect python show --ABI)
    if [[ -z ${pyver} ]]; then
      # TODO(build): Should be able to make this fatal once python-2.7 lands.
      pyver=$(readlink "${root_fs_dir}"/usr/local/bin/python2 | sed s:python::)
    fi
    local python_path="/usr/local/bin/python${pyver}"

    info "Fixing python symlinks for developer and test images."
    local cmds=() path python_paths=(
      /usr/{local/,}bin/python
      /usr/{local/,}bin/python${pyver:0:1}
      /usr/bin/python${pyver}
    )
    for path in "${python_paths[@]}"; do
      cmds+=(
        "ln -sfT '${python_path}' '${root_fs_dir}${path}'"
      )
    done
    sudo_multi "${cmds[@]}"
  fi


I wonder if we can't just do this for all images?

Did we make any progress on this? I hit it today.

Heh, I just asked on  bug 758667 , which looks like a duplicate. lhchavez has this up for review, but that sorta stalled I think:

https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/634205

BTW, even if this installation fails as part of dev_install, 'emerge' and friends should still be set up, and you can usually install what you want (unless what you wants happens to depend on python's 'six' library...)

 Issue 758667  has been merged into this issue.

Ah, I see build_packages didn't like that CL, because the python ebuild would have a conflict on /usr/bin/python2.7.

vapier had some old work here, that looks a little more along the lines of my comment #6, but he still ran into problems:

https://chromium-review.googlesource.com/c/chromiumos/platform/crosutils/+/257301
https://chromium-review.googlesource.com/c/chromiumos/platform/crosutils/+/461519

I think I hit this same issue (or something related) on my eve device; running dev_install gave an error:
(I'm not sure why flashing/installing a test image didn't include rsync, etc. to let me deploy_chrome)

curl: (22) The requested URL returned error: 403 Forbidden
ERROR(dev_install): Could not download package.
ERROR(dev_install): Command curl --fail -o /usr/local/portage/packages/app-admin/python-updater-0.11.tbz2 https://commondatastorage.googleapis.com/chromeos-dev-installer/board/eve/canary-R-10486.0.0/packages/app-admin/python-updater-0.11.tbz2 failed.

Using a usb ethernet adapter and blue/green port, my device got an ip address that might be odd: 172.18.XXX.XX
xiyuan@ said it's apparently not an eng or lab vnet... "cdb netblock show 172.18.XXX.XX" yields:
VLAN                : 220
Description         : US-MTV-900 RUNT

Using Xiyuan's local off-corp network, the device got a more expected ip address 10.10.XX.XX (I think?).
From that connection, dev_install completed successfully...

Perhaps there's a related network operations issue? (can provide more info offline or in a restricted bug)

I had the same experience as msw on both my PixelBook and the CB Pixel. Output from lsb-release shows the DEVSERVER with no value. Should this be the case?

CHROMEOS_ARC_ANDROID_SDK_VERSION=25
CHROMEOS_ARC_VERSION=4691625
CHROMEOS_AUSERVER=https://tools.google.com/service/update2
CHROMEOS_BOARD_APPID={F67500C1-C6D8-5287-E4EC-F9BBB4AEE5C5}
CHROMEOS_CANARY_APPID={90F229CE-83E2-4FAF-8479-E368A34938B1}
CHROMEOS_DEVSERVER=
CHROMEOS_RELEASE_APPID={F67500C1-C6D8-5287-E4EC-F9BBB4AEE5C5}
CHROMEOS_RELEASE_BOARD=samus-signed-mp-v3keys
CHROMEOS_RELEASE_BRANCH_NUMBER=42
CHROMEOS_RELEASE_BUILDER_PATH=samus-release/R66-10452.42.0
CHROMEOS_RELEASE_BUILD_NUMBER=10452
CHROMEOS_RELEASE_BUILD_TYPE=Official Build
CHROMEOS_RELEASE_CHROME_MILESTONE=66
CHROMEOS_RELEASE_DESCRIPTION=10452.42.0 (Official Build) beta-channel samus 
CHROMEOS_RELEASE_NAME=Chrome OS
CHROMEOS_RELEASE_PATCH_NUMBER=0
CHROMEOS_RELEASE_TRACK=beta-channel
CHROMEOS_RELEASE_VERSION=10452.42.0
DEVICETYPE=CHROMEBOOK
GOOGLE_RELEASE=10452.42.0

Temporary workaround:

cd /usr/bin
ln -s /usr/local/bin/python2.7

dev_install --reinstall