Change structure of frigate-nvr/hailort repo for better maintainability

[sairon]

When I proposed bump of the Hailo library in #17094, I was unable to open a PR for the update of the wheels and userspace binaries because the repository used for their build is a fork with downstream patches rebased on top of the upstream master branch every time there's a need for a new build. This makes it hard/impossible to accept pull request from third parties and makes the history hard to track, as the old releases exist only as tags with detached history.

A better solution would be to keep only the reference to the upstream code used for the build through a submodule. Updating to newer versions can be then easily achieved by bumping the submodule reference and creating the release from the head of the branch, persisting linear history with future changes. Eventually, an automation (e.g. Dependabot) could be also implemented to sync on new upstream releases, which would be also clumsy with the current approach.

I implemented this in the submodule-build branch of my fork (which also contains a minor change to use all cores for build, but otherwise it's equivalent to the old build workflow). As the solution is based on an orphan branch, it's not possible to submit it as a PR, and issues are closed in that repo too, hence this discussion thread. If this proposal is accepted, pushing my branch to frigate-nvr/hailort (and ideally setting it as the default branch of the repo) is the way forward.

[sairon]

When trying to build the latest version in my fork, the build failed after 1.5 hours on a random segfault when installing Python 3.11 build dependencies (while no error was raised for Python 3.9 build). This code was unchanged and the failure is probably caused by a known QEMU issue tonistiigi/binfmt#215 and the original repo would be affected too. As I don't have the nerves trying to fix it and wait another bunch of hours, I took a more radical approach and adjusted the workflow to run on native ARM64 builder, this is in branch native-build. The added benefit is that the build time is reduced from several hours to couple of minutes.

[sairon]

Okay, it turned out there were more gremlins haunting the original build repo. While the latest v4.20.0 tag tried to build wheels and binaries for two different Python versions, they couldn't work in Frigate v0.15.0 because they were built in Ubuntu Jammy container. Jammy uses newer glibc than Debian 11, and since glibc is only backwards-compatible, there was an ABI mismatch - running the Debian 11 runtime with binaries from Ubuntu builder caused these errors to appear on Hailo runtime import:

Error importing detector runtime: /usr/lib/aarch64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/local/lib/python3.9/dist-packages/hailo_platform/pyhailort/_pyhailort.cpython-39-aarch64-linux-gnu.so)

And with more errors apparent when running ldd on the built dynamic libraries.

I did more changes in my fork to parameterize the build on Debian version (which must match the Debian version the wheels/binaries are installed into). These changes aim at fixing the issues with Frigate containers only - as the library releases are used only for Frigate, the issues with different ABI can be mitigated by matching builder versions. If the goal was to have a universal builder for the Hailo Runtime, proper manylinux build would have to be implemented.

With these changes (and added forgotten ldconfig call), Frigate 0.15 runs on HAOS 15.0 with v4.20.1 driver.

[blakeblackshear]

Thanks for the suggestions. I have implemented these changes.