Unable to download wheels from AMD PyPI (Vitis AI 6.2 Yocto build)

[xfemerj]

Hi,

we are trying to build the Yocto-based reference design using Vitis AI 6.2 create_pfm_sw.sh and are encountering issues fetching the vart-ml, vart-x and flexmlrt packages from:
https://pypi.amd.com/vai/6.2/simple

The package index is accessible:
https://pypi.amd.com/vai/6.2/simple/vart-ml/

However, downloading the referenced wheel fails with:
AccessDenied

This causes Yocto builds to fail with:
Could not find a version that satisfies the requirement vart-ml

In previous Vitis AI releases, these dependencies were provided as local archives within the reference design. Vitis AI 6.2 now depends on fetching wheels from pypi.amd.com.

Questions:

• Are these wheels intended to be publicly accessible?
• Do they require authentication, or could this be a network issue on our side?

Thanks,
Jonas

[Rohithmatham12]

I can reproduce the access pattern from outside the reported network. The simple index is public, but the wheel object advertised by that index is not downloadable.\n\nFor example:\n\nbash\ncurl -I https://pypi.amd.com/vai/6.2/simple/vart-ml/\n# HTTP/2 200\n\ncurl -I https://pypi.amd.com/vai/6.2/simple/vart-ml/vart_ml-0.3.0.dev20260601181346+g669a1c0-py3-none-any.whl\n# HTTP/2 403\n# server: AmazonS3\n\n\nSo this does not look like a local Yocto/pip resolver issue. The package index page is reachable and advertises the wheel, but the S3 object behind the wheel URL returns 403.\n\nThe affected Yocto recipe paths appear to be:\n\n- versal_2ve/reference_design/vek385/rev-b/sw/yocto/meta-vitis-ai/recipes-vaiml-examples/vart-ml_vart-x/vart-ml.bb\n- versal_2ve/reference_design/vek385/rev-b/sw/yocto/meta-vitis-ai/recipes-vaiml-examples/vart-ml_vart-x/vart-x.bb\n- versal_2ve/reference_design/vek385/rev-b/sw/yocto/meta-vitis-ai/recipes-vaiml/ryzenai-wheels/ryzenai-wheels_1.0.bb for flexmlrt / related wheels\n\nGiven the current response, the durable fix likely needs to be in the AMD PyPI/S3 publishing or access policy for the Vitis AI 6.2 wheel objects. A repo-side change could make the BitBake error clearer, but it would not make the advertised wheels installable.

[DamoderAMD]

Hi,
Thank you for trying out the Vitis AI tools, and apologies for the inconvenience caused during your platform build.
We have verified the build on our side, and it is working as expected. To help us investigate your issue further, could you please:

1. Try the command below and let us know if it succeeds in your environment

   pip download --no-deps --extra-index-url https://pypi.amd.com/vai/6.2/simple vart-ml

2. Provide the complete error logs from your build environment

This information will help us better understand and debug the issue.

Thanks,
Damoder

[xfemerj]

Hi Damoder,

thank you for your support! I tried manually downloading the required wheels using your suggested pip download command, and that worked.
Previously, I had only tested downloading via curl, which did not work. With this in mind, it appears that the issue is related to how the requests are handled rather than general access.

However, for me, the pip download still does not work within the Yocto build process (create_pfm_sw.sh). This seems to be related to our network restrictions and/or the Python environment used during the Yocto build.

For now, I have modified the recipes to use locally downloaded wheel files, which works fine.
From my side, the issue can be closed.

Thanks and best regards,
Jonas

[DamoderAMD]

Hi Jonas,
Thank you for the update.
Glad to hear that the pip download command worked and that you are unblocked with the build using locally downloaded wheel files as a workaround.
On our side, the Yocto build works with the pip-based download flow. If you still have logs from your setup, it would be helpful if you could share the build errors you encountered. We can take a closer look and see if there is anything further we can address.
Best regards,
Damoder

[xfemerj]

Hi Damoder,

here is the error log I am getting when running the Yocto build, for example when fetching the vart-ml wheel:

DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are ['path_to_platform/sw/yocto/sources/poky/meta/recipes-core/glibc/glibc_2.39.bb:do_populate_sysroot', 'path_to_platform/sw/yocto/sources/poky/meta/recipes-devtools/gcc/gcc-cross_13.4.bb:do_populate_sysroot', 'path_to_platform/sw/yocto/sources/poky/meta/recipes-devtools/gcc/gcc-runtime_13.4.bb:do_populate_sysroot', 'path_to_platform/sw/yocto/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:path_to_platform/sw/yocto/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:path_to_platform/sw/yocto/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:path_to_platform/sw/yocto/sources/poky/meta/recipes-devtools/python/python3-pip_24.0.bb:do_populate_sysroot', 'virtual:native:path_to_platform/sw/yocto/sources/poky/meta/recipes-devtools/python/python3_3.12.11.bb:do_populate_sysroot', 'virtual:native:path_to_platform/sw/yocto/sources/poky/meta/recipes-extended/unzip/unzip_6.0.bb:do_populate_sysroot']
NOTE: Installed into sysroot: []
NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'glibc', 'binutils-cross-aarch64', 'cmake-native', 'gcc-cross-aarch64', 'gcc-runtime', 'libgcc', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'linux-libc-headers', 'util-linux-libuuid-native', 'openssl-native', 'expat-native', 'ncurses-native', 'zlib-native', 'flex-native', 'gnu-config-native', 'libedit-native', 'make-native', 'patch-native', 'perl-native', 'pseudo-native', 'python3-build-native', 'python3-flit-core-native', 'python3-installer-native', 'python3-packaging-native', 'python3-pip-native', 'python3-pyproject-hooks-native', 'python3-setuptools-native', 'python3-wheel-native', 'python3-native', 'bzip2-native', 'libnsl2-native', 'libtirpc-native', 'unzip-native', 'xz-native', 'zstd-native', 'attr-native', 'gdbm-native', 'gmp-native', 'libffi-native', 'libmpc-native', 'mpfr-native', 'sqlite3-native']
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_configure
NOTE: Downloading vart-ml wheel from https://pypi.amd.com/vai/6.2/simple
Looking in indexes: https://some_company_artifactory/artifactory/api/pypi/pypi/simple, https://pypi.amd.com/vai/6.2/simple
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))': /vai/6.2/simple/vart-ml/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))': /vai/6.2/simple/vart-ml/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))': /vai/6.2/simple/vart-ml/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))': /vai/6.2/simple/vart-ml/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))': /vai/6.2/simple/vart-ml/
ERROR: Could not find a version that satisfies the requirement vart-ml (from versions: none)
ERROR: No matching distribution found for vart-ml
WARNING: exit code 1 from a shell command.

For comparison, here is the log from a manual pip download:

pip download --no-deps --extra-index-url https://pypi.amd.com/vai/6.2/simple vart-ml
Looking in indexes: https://some_company_artifactory/artifactory/api/pypi/pypi/simple, https://pypi.amd.com/vai/6.2/simple
Collecting vart-ml
  Using cached https://pypi.amd.com/vai/6.2/simple/vart-ml/vart_ml-0.3.0.dev20260601181346%2Bg669a1c0-py3-none-any.whl (4.2 MB)
Saved ./vart_ml-0.3.0.dev20260601181346+g669a1c0-py3-none-any.whl
Successfully downloaded vart-ml

My current assumption is that this is related to differences in network/proxy handling between the interactive environment and the Yocto build environment (e.g. missing or not propagated proxy settings), although I have not yet verified this.

Best regards,
Jonas

[Rohithmatham12]

One detail that may be worth checking: the successful manual command says Using cached ..., so it may not prove that a fresh wheel download succeeds from the same network path. It might be using a wheel that pip already cached from an earlier successful/manual run, while BitBake's task environment has a different cache and/or different proxy variables.

A useful next repro would be to force a network fetch both outside and inside the Yocto/BitBake environment:

python3 -m pip download --no-cache-dir -vvv --no-deps \
  --extra-index-url https://pypi.amd.com/vai/6.2/simple \
  vart-ml

If the no-cache command works interactively but fails from do_configure, I would compare the task environment for proxy/cert variables. In Yocto builds behind a corporate proxy, it is common to need explicit passthrough for variables such as:

BB_ENV_PASSTHROUGH_ADDITIONS += "http_proxy https_proxy ftp_proxy no_proxy HTTP_PROXY HTTPS_PROXY FTP_PROXY NO_PROXY PIP_INDEX_URL PIP_EXTRA_INDEX_URL PIP_CERT PIP_TRUSTED_HOST REQUESTS_CA_BUNDLE SSL_CERT_FILE"

The repeated ConnectionResetError(104, 'Connection reset by peer') against /vai/6.2/simple/vart-ml/ looks more like the network/proxy path being different inside the BitBake task than a missing package version. If the no-cache interactive command also fails, then the earlier curl/S3 behavior and pip behavior are worth re-checking from a clean cache.

[DamoderAMD]

Hi Jonas and Rohit,

Thanks for sharing the detailed logs and observations.
We’ll review the behavior and analyze the issue from our side, and share the updates here.

Best regards,
Damoder

[Rohithmatham12]

Thanks Damoder, appreciate the follow-up. The no-cache / BitBake-environment comparison should help distinguish a cache/proxy propagation issue from an AMD PyPI object-access issue. I'll watch for your findings.