+1 Maintenance report from 23 June to 29 June
Hi, I was on +1 Maintenance last week. @schopin also shared the new +1 Maintenance Doc which was a great help.
I mostly focussed on the update-excuses page.
Work-needed items
- llama.cpp - They (the Debian uploader) have hardcoded the required version for dependencies, but those versions haven’t been uploaded to Debian yet. Need to contact the uploader to find out what is going on.
- ggml - Need to forward the proposed fix to Debian (or further upstream, depending on what the Debian uploader says)
Sponsorship needed
I’ll list all the bugs here, the details are given in the next section. All of this is in Universe.
Full logs
- libpisp and rpicam-apps: upstream broke the API which caused rpicam-apps to FTBFS when built with
-Wl, --no-undefined. Thanks @waveform for merging. This change has also been applied upstream. Now it needs a no-change-rebuild for libcamera and rpicam-apps should then build successfully, and no longer show up on the NBS tracker - cron: cron autopkgtests were failing at the start of the week due to logs spilled in stderr by cloud-init (not a failure of the package but additional logs from the testbed). This was blocking the migration of exim4 as well. @utkarsh suggested that we use
allow-stderroption for the failing tests. - freecad: FreeCAD added an autopkgtest which failed as it requires a display server, but this was not included in the test dependencies. This small fix allows it to pass.
- rust-zune-jpeg: autopktests for arm64 were failing due to the introduction of
color_convert/neon64.rs, which uses ARM64’s Neon SIMD instructions, but had an incorrect modpath. - armci-mpi: Prepared a merge for version 0.4-6
- ukui-session-manager: Prepared a merge for version 4.0.0.2-1
- rakarrack: No remaining delta against Debian anymore, so I put up a sync bug. Thanks @eeickmeyer for acting on this.
- clanlib: No remaining delta against Debian anymore, so I put up a sync bug.
- ggml: This turned out to be a pain (and the reason why this report is late). The ARM support for ggml is very inconsistent and seems to be centered around Apple Silicon. There is no distinction between arm64 and armhf, but the source uses features only available in arm64 and tries to compile them on armhf as well. The fix specifies the FPU while building libggml-cpu on armhf, skips compiling parts which rely on Apple’s proprietary libraries and fixes some parts where the CMake is choosing the wrong architecture:
in tests/CMakeLists.txt
#
# test-vec2 (arm)
if (${CMAKE_SYSTEM_PROCESSOR} MATCHES "arm")
set(TEST_TARGET test-vec2)
add_executable(${TEST_TARGET} ${TEST_TARGET}.c)
target_link_libraries(${TEST_TARGET} PRIVATE ggml)
endif()
-
CMAKE_SYSTEM_PROCESSORisaarch64on Ubuntu arm64 andarmv7lon Ubuntu armhf. This test needsarmv8.2-a+fp16(hence arm64) to compile according to it’s contents. However, this might work fine on Apple Silicon Macs, asuname -mgivesarm64, but on Ubuntu this target was matchingarmv7l(hence armhf) instead of arm64 -
llama.cpp: This is weird - not installable now as it depends on a version of ggml that is not uploaded yet. I must contact the uploader of llama.cpp and ggml (both are the same) as to why this is so (and to forward the ggml patches as well). Checking llama.cpp upstream, I see that they publish a new release every few hours or so, so I doubt if users will be installing these from the archive instead of building it from source themselves, but this still a weird case that should be resolved.
) all of the above MPs and added comments, either asking you to forward to Debian or drop a few things, et al.