This is an automated message from the Debian DFSG, Licensing & New
Packages Team.
The Debian NEW review of amd-aie-rt 2026.1.1+dfsg-1 has been completed.
Decision: ACCEPTED
Reviewer: Andrew McMillan
Review comment:
Hi,
Some of these issues that the LLM review came up with seem kind of extreme -
like you wouldn't have been able to build and upload - but perhaps they're
real, and you managed to build from a dirty local tree and would fail from a
clean one.
They're not copyright issues, so I'll accept it in this case because if they
are real you'll be wanting to fix these pretty soon I guess!
1. [blocker] [packaging] libxaiefal-dev has nothing to install: dh_install will
abort
- Files: `debian/libxaiefal-dev.install`, `fal/src/CMakeLists.txt`,
`fal/CMakeLists.txt`
- Evidence: debian/libxaiefal-dev.install contains only
`usr/include/xaiefal/`; the effective branch of fal/src/CMakeLists.txt
(YOCTO=OFF) only does `file(COPY ... DESTINATION
${CMAKE_BINARY_DIR}/include/xaiefal)` and has no install() rule (the only
header install() is in the unused else()/YOCTO branch); nothing else in the fal
tree installs the fal headers.
- Problem: No CMake install() rule or rules-file copy ever creates
usr/include/xaiefal, so dh_install finds no files in the current directory or
in debian/tmp and aborts the arch build (`dh_install: error: cannot find
usr/include/xaiefal/`). Even if it did not abort, libxaiefal-dev would be
empty, so the header-only FAL would be unusable by its declared dependents.
- Fix: Point the install source at the build-tree copy, e.g.
`obj-${DEB_HOST_GNU_TYPE}/include/xaiefal usr/include/`, or add an upstream
install(DIRECTORY ...) for the fal headers (non-YOCTO branch) and keep
`usr/include/xaiefal/`. Verify with a clean `debian/rules binary`.
2. [blocker] [packaging] versal-linux toolchain forces aarch64-linux-gnu
compilers that are not in Build-Depends
- Files: `debian/rules`, `debian/control`,
`fal/cmake/platforms/versal-linux.cmake`,
`fal/cmake/platforms/cross-linux-g++.cmake`
- Evidence: debian/rules passes `-DCMAKE_TOOLCHAIN_FILE=versal-linux`;
versal-linux.cmake sets `CROSS_PREFIX=aarch64-linux-gnu-` and
`include(cross-linux-g++)`, which sets `CMAKE_C_COMPILER=aarch64-linux-gnu-gcc`
and `CMAKE_CXX_COMPILER=aarch64-linux-gnu-g++`.
- Problem: CMake will try to run aarch64-linux-gnu-gcc/g++ (also used by the
ExternalProject driver build via CC=${CC}) and fails configuration when the
cross compiler is absent; Build-Depends lists only cmake, cpputest,
liburing-dev, pkgconf and no gcc-aarch64-linux-gnu/g++-aarch64-linux-gnu, so a
clean pbuilder/salsa arm64 chroot cannot configure. The toolchain file
effectively assumes a cross build even though the package is native-arm64.
- Fix: Either add gcc-aarch64-linux-gnu and g++-aarch64-linux-gnu to
Build-Depends (and confirm the resulting binaries link against the native arm64
runtime, given CMAKE_FIND_ROOT_PATH_MODE_* are NEVER), or drop
-DCMAKE_TOOLCHAIN_FILE=versal-linux and build natively on arm64.
3. [minor] [packaging] No autopkgtests
- Files: `debian/tests/control`
- Evidence: There is no debian/tests/ directory; the package builds unit-test
binaries (run-test-aie, via WITH_TESTS=ON) but never wires them into the test
harness.
- Problem: The unit-test binaries are built but not exercised in any automated
way, so CI/autopkgtest regressions in the library API go undetected (tests do
need arm64 Versal hardware, but could at least be smoke-run).
- Fix: Add a debian/tests/control that smoke-runs the built unit tests and
examples (or drop WITH_TESTS=ON if the tests are only built, not run).
4. [minor] [packaging] driver/tests/utest CMake still references the excluded
elf_files directory
- Files: `driver/tests/utest/CMakeLists.txt:18`
- Evidence: `file(COPY elf_files DESTINATION ${CMAKE_CURRENT_BINARY_DIR})`
runs unconditionally when the driver's own CMake project is configured, but
driver/tests/utest/elf_files is listed in Files-Excluded and absent from the
tree.
- Problem: Configuring the upstream driver/ CMake (the upstream way to build
the unit tests) fails at configure time. The Debian build avoids this because
it builds the driver via Makefile.Linux through fal's ExternalProject, so it is
latent rather than a current build failure.
- Fix: Guard the copy with `if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/elf_files)`
or restore a minimal fixture, so the exclusion does not break upstream's own
test build.
5. [minor] [packaging] debian/watch is in the old version 4 format
- Files: `debian/watch`
- Evidence: `version=4`
- Problem: Version 5 is the current format of `debian/watch`.
- Fix: Convert it to version 5; a mechanical conversion is included below.
==========================================================================
Version: 5
Source: https://github.com/Xilinx/aie-rt.git
Matching-Pattern: refs/tags/xilinx_v@ANY_VERSION@
Dversionmangle: s/\+dfsg\d*$//
Mode: git
Repacksuffix: +dfsg
==========================================================================
Thanks!
Full review details: https://dfsg-new-queue.debian.org/reviews/amd-aie-rt
