Arch Linux User Repository

@ninetailedtori package updated to match the latest upstream changes.

Right, fixed the whole issue!

    export WHEEL_VERSION="${pkgver%%_vc*}"

This fixed it, there was some change with how the wheel version was generated upstream?

Wait, but now I'm throwing this, in the phase of packaging:

==> Checking for packaging issues...
==> WARNING: Package contains reference to $srcdir
usr/lib/openvino/libopenvino_intel_npu_plugin.so
==> Creating package "openvino-intel-npu-plugin-git"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Starting package_python-openvino-git()...
Traceback (most recent call last):
  File "/tmp/makepkg/openvino-git/src/openvino/setup.py", line 810, in <module>
    setup(
    ~~~~~^
        name="openvino",
        ^^^^^^^^^^^^^^^^
    ...<18 lines>...
        zip_safe=False,
        ^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/lib/python3.13/site-packages/setuptools/__init__.py", line 115, in setup
    return distutils.core.setup(**attrs)
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/setuptools/_distutils/core.py", line 148, in setup
    _setup_distribution = dist = klass(attrs)
                                 ~~~~~^^^^^^^
  File "/usr/lib/python3.13/site-packages/setuptools/dist.py", line 332, in __init__
    self.metadata.version = self._normalize_version(self.metadata.version)
                            ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/setuptools/dist.py", line 368, in _normalize_version
    normalized = str(Version(version))
                     ~~~~~~~^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/packaging/version.py", line 202, in __init__
    raise InvalidVersion(f"Invalid version: {version!r}")
packaging.version.InvalidVersion: Invalid version: '2025.4.1_vc_mt'
==> ERROR: A failure occurred in package_python-openvino-git().
    Aborting...
 -> error making: openvino-git-exit status 4
removing untracked AUR files from cache...
:: Cleaning (1/1): /tmp/makepkg/openvino-git
 -> Failed to install the following packages. Manual intervention is required:

Right, it's due to the fact that python-openvino-git ends up with non-semantic versioning somewhere, which is incompatible with the >66 versions of setuptools, but, we use the latest setuptools in this project, of course. This causes the error to be thrown, oddly, and I'm not sure if it's within our system that's causing that issue or, if it's something system-based.

Do you know how to fix this issue btw, daniel? Bit of a weird issue, and my paths do look like they're ordered correctly.

CMake Error in src/bindings/python/src/pyopenvino/CMakeLists.txt:
  Imported target "pybind11::headers" includes non-existent path

    "/include"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

Not sure why there's a /include as it's not in my local include paths at all, so there must be an issue within one of the repo build toolchains somewhere maybe I've missed? Or I'm just missing something hahah.

Edit: Found it, what fixed it for me was this:

env PATH="/usr/lib/python3.13/site-packages/:$PATH"

Seems my PATH didn't include the site-packages for some weird reason, must've been in a system refactor. Is it possible to get that added to the PATH if not found in the user's PATHs? Or would that be considered bad etiquette in a PKGBUILD? Not too sure hahah

@ninetailedtori A patch needed an update to match the latest upstream changes. I've updated the package, and now it's building fine. Thanks for reporting.

Hiya, I'm getting a hunk error when trying to make this package right now, would it be possible to let me know how to fix it? Tried everything, even in chroot with all defaults it seems to be failing ;w; Not sure if it's my fault, if I did something wrong, but I should mention this is with everything wiped each attempt build.

Updated Git hooks.
Git LFS initialized.
Skipping submodule 'src/bindings/python/thirdparty/pybind11'
Skipping submodule 'thirdparty/flatbuffers/flatbuffers'
Skipping submodule 'thirdparty/ocl/icd_loader'
Skipping submodule 'thirdparty/pugixml'
Skipping submodule 'thirdparty/snappy'
patching file cmake/developer_package/packaging/archive.cmake
patching file src/common/util/src/file_util.cpp
Hunk #1 FAILED at 422.
1 out of 1 hunk FAILED -- saving rejects to file src/common/util/src/file_util.cpp.rej
patching file src/plugins/intel_npu/tools/compile_tool/CMakeLists.txt
patching file src/plugins/intel_npu/tools/protopipe/CMakeLists.txt
patching file src/plugins/intel_npu/tools/single-image-test/CMakeLists.txt
==> ERROR: A failure occurred in prepare().
    Aborting...

build error https://pastebin.com/V8hjnqU3

@Eirikr Sorry, but I have no interest in maintaining packages for older versions of openvino. You can take a look at openvino AUR package and use the PKGBUILD from older versions. It should work, but there is a chance that some dependency version bump breaks it. Some comments regarding your PKGBUILD: 1) 'pkgdesc' should not contain the package name (should not contain 'OpenVINO is...', see pkgdesc in Arck Wiki); 2) 'pkgdesc' is too large (try to make it under 80 characters if possible, see pkgdesc in Arck Wiki); 3) versioned pkgname should not contain the exact minor/patch version, otherwise you need a new PKGBUILUD (and a new AUR package) if upstream unexpectedly bumps a lts version from 2022.3.1 to 2022.3.2 (yes, they can do it); 4) versioned pkgname should not contain hyphen between pkgname and the version (use 'openvino2022' instead of 'openvino-2022', see versioned packages in the official repositories, like gcc12); 5) 'conflicts' should not include all possible openvino packages in existence (like openvino-git), but specify only the base 'openvino' package on it (see conflicts in Arck Wiki); 6) do not rename the git clone download dir in the source array if the cloned project have an unique name like openvino, as it duplicates source files when building multiple variant packages (do not use '"${pkgname}::' for 'git+' urls, unless when needed); 7) source tarballs in github can be accessed with an url in the format 'https://github.com/<user>/<project>/archive/<tag>/<desired_filename>.tar.gz' (do not do not download tarballs from github with urls containing 'refs/tags' + file renaming, but use the mentioned url format to specify the output filename directly; 8) unless you a have a strong reason for not doing such, specify the git submodules in the source array and initialize all of them, instead of using a generic git command for submodule initialization in prepare(); 9) no need to use an extra line for 'cd' before the 'git' command, use git '-C' option; 10) no need to use an extra line to create the build directory, use cmake '-B' option for creating/specifying it; 10.1) if, for some obscure reason, you prefer to create the build directory with a separate command (and increase the line count of the PKGBUILD), do it in prepare(), not in build(); 11) no need to use an extra line for 'cd' before the cmake command, use cmake '-S' option for specifying the source directory; 12) cmake command should specify the '-G' option for the cmake generator, otherwise the user can override it with an environment variable, and this is not desirable; 13) Arch Linux packages do not use '/usr/local', and packages should never be installed to it, so never use '/usr/local' to install anything in PKGBUILDs (change the cmake install prefix from '/usr/local' to '/usr', see package etiquette in Arch Wiki; 14) use 'cmake --build build' instead of the generator (ninja) directly; 15) use 'cmake --install build' instead of the generator (ninja) directly (also, no need to 'cd' before it); 16) no need to create the library symlink in package() when the libs are not installed into the standard directory, use a 'ld.so' configuration file instead; 17) do not hardcode the python version in the install directories (since python 3.10 will not be available forever, and you will need to fix the PKGBUILD when python gets a version bump), but retrieve the current python directory information using a python command (see using python version in Arch Wiki).

Thank you for your openvino, openvino-git packages AND your responsiveness!!

Requesting:

1) A PKGBUILD for OpenVINO 2021.4.1 LTS (final version to support NCSDK2 and the original Neural Compute Stick Movidius Myriad X VPU (of course, still supports Neural Compute Stick 2 for mixed-device environments) https://github.com/openvinotoolkit/openvino/archive/refs/tags/2021.4.1.tar.gz - That package works in tandem with this: This package is de-listed but works w/ git clone: https://aur.archlinux.org/ncsdk.git. The version in that PKGBUILD is 2.08.01.02 but it should be v.2.10.01.01.

So if a PKGBUILD maintainer were cool with updating the PKGBUILD listed for the ncsdk2; notating its the final build for the original intel compute stick / intel movidius myriad x vpu; along with the OpenVINO 2021.4.1 LTS as a dependency (and maybe vice-versa) then "budget" AI can live on! All thanks to @dbermond!!!

2) A PKGBUILD for OpenVINO 2022.3.1 LTS which is the last version of OpenVINO to have Movidius/Neural Compute Stick 2 support. (ncsdk2 + Movidius VPU unsupported)

I suck at PKGBUILDing. But I do not like to just say "please give!" without at least trying to provide the sauce. Not sure if I have the dependencies quite right... eeeeep. Feel free obviously to start from scratch. This is just me learning and playing show-and-tell to see if I came close:

pkgname=openvino-2022.3.1
pkgver=2022.3.1
pkgrel=1
pkgdesc='OpenVINO toolkit is a comprehensive toolkit for quickly developing applications and solutions that solve a variety of tasks including emulation of human vision, automatic speech recognition, natural language processing, recommendation systems, and many others. This LTS version is the final to support NCS2 and HDDL. Original NCS Movidius Myriad X VPU deprecated.'
arch=('x86_64')
url='https://docs.openvinotoolkit.org/'
license=('Apache-2.0')
depends=('intel-media-sdk' 'intel-compute-runtime' 'intel-opencl' 'intel-level-zero-gpu' 
         'tbb' 'opencv' 'python' 'python-numpy' 'python-cython' 'libusb' 'libxml2' 'protobuf')
makedepends=('git' 'cmake' 'ninja')
provides=('openvino')
conflicts=('openvino' 'openvino-git')
source=("${pkgname}::git+https://github.com/openvinotoolkit/openvino.git#tag=${pkgver}"
        "${pkgname}-ocl::https://github.com/intel/compute-runtime/archive/refs/tags/19.41.14441.tar.gz")
sha256sums=('SKIP'
            'ab9a54da2b7c10cfd08efdeec11ee1a3433aae4d97fba1e30a52c05c4a24e96c')

prepare() {
  cd "${srcdir}/${pkgname}"
  git submodule update --init --recursive

  # Apply patch for compute runtime
  mkdir -p "${srcdir}/${pkgname}/inference-engine/thirdparty/ocl/opencl"
  tar -xf "${srcdir}/${pkgname}-ocl" -C "${srcdir}/${pkgname}/inference-engine/thirdparty/ocl/opencl" --strip-components=1
}

build() {
  cd "${srcdir}/${pkgname}"
  mkdir build && cd build

  cmake .. \
    -G Ninja \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_INSTALL_PREFIX=/usr/local \
    -DENABLE_INTEL_CPU=ON \
    -DENABLE_INTEL_GPU=ON \
    -DENABLE_INTEL_GNA=ON \
    -DENABLE_INTEL_MYRIAD=ON \
    -DENABLE_INTEL_HDDL=ON \
    -DENABLE_PYTHON=ON \
    -DENABLE_WHEEL=ON \
    -DTHREADING=TBB

  ninja
}

package() {
  cd "${srcdir}/${pkgname}/build"
  DESTDIR="${pkgdir}" ninja install

  install -d "${pkgdir}/usr/lib"
  ln -s /usr/local/lib/libinference_engine.so "${pkgdir}/usr/lib/libinference_engine.so"

  install -d "${pkgdir}/usr/lib/python3.10/site-packages"
  ln -s /usr/local/lib/python3.10/site-packages/openvino "${pkgdir}/usr/lib/python3.10/site-packages/openvino"
}

Finally: if anyone has a 13th/14th Gen CPU/GPU, Intel Xe or Intel Arc GPU they need to use the newest openvino. If someone has that setup with some Compute Sticks and Compute Sticks 2; then openvino or openvino-git need a fork and a patch to reintroduce VPU support. That is not easy and not exciting. So the best solution is multiple OpenVINO versions unless a diety-tier dev comes around to create a forked "openvino-vpu" with all those cool pieces re-added.

Sorry that I'm out of ideas.

This is partially been in response to person in an Arch-focused Telegram group complaining about their compute sticks not working.