Reviews for libultrahdr
All reviews for this package from team members (across all versions).
| Reviewer | Version | Allocated | Started | Status | Completed | Comment | |
|---|---|---|---|---|---|---|---|
| eamanu | 2.0.2-1 | 1 month, 26 days ago | 1 month, 26 days ago | rejected | 1 month, 26 days ago | Thanks for your contributions to Debian! I'm leaving some comments for the package: - Please reviewthe '*' in the BSD-3-Clause - Review trhid_party/image_io/src/modp_b64/Makefile license, seems to be Apache-2.0. - These files seems that doesn't have the dual license: - lib/include/ultrahdr/avifultrahdr.h - lib/include/ultrahdr/heifultrahdr.h - lib/src/avifultrahdr.cpp - lib/src/avifultrahdr.cpp - lib/src/heifultrahdr.cpp - scripts/auto_repair.py - scripts/report_regression_issue.py | View |
| awm | 2.0.2-1 | 27 days ago | 27 days ago | accepted | 27 days ago | Hi, A couple of issues you should fix in your next upload... 1. [important] packaging libheif-dev not in Build-Depends: HEIF/AVIF support silently disabled Files: debian/control (Build-Depends); CMakeLists.txt:648-744; debian/ultrahdr_app.1 (-z option) Evidence: option_if_not_defined(UHDR_ENABLE_HEIF "Build with HEIF/AVIF support via libheif" TRUE) then find_package(libheif QUIET) … message(WARNING "libheif not found. Building without HEIF/AVIF support.") set(UHDR_ENABLE_HEIF FALSE); heifultrahdr.cpp/avifultrahdr.cpp are whole-file #ifdef UHDR_ENABLE_HEIF; docs/api_changes_v1.5_to_v2.0.md: “When disabled: libultrahdr builds as a standalone, zero-dependency JPEG-only library”. Build-Depends has no libheif-dev, so a clean sbuild gets the JPEG-only fallback. Problem: The shipped libuhdr.so and ultrahdr_app lose HEIF/HEIC/AVIF encode/decode although the library’s man page documents .heic/.heif/.avif output selection and upstream enables this by default; callers calling HEIF/AVIF API modes will get errors at runtime. The degradation is silent and undocumented. Fix: Add libheif-dev to Build-Depends (libheif 1.23.4 in unstable provides the ISO 21496-1 gain-map API that Findlibheif.cmake checks; the runtime shlibs:Depends on libheif1 follows automatically), and verify the build; if a deliberate JPEG-only build is intended instead, document it in debian/control, the changelog and the man page. 2. [minor] licensing cmake/patches/libheif_pr1503.patch is libheif (LGPL-3.0-or-later) code but only covered by the Apache-2.0 or MIT catch-all Files: debian/copyright Files: * stanza; cmake/patches/libheif_pr1503.patch Evidence: The patch is a verbatim diff of the libheif project (paths libheif/CMakeLists.txt, libheif/api/libheif/heif.cc, heifio) adding the gain-map API; libheif is LGPL-3.0-or-later. It has no license header of its own and falls under Files: * with Copyright 2022-2026 The Android Open Source Project, License: Apache-2.0 or MIT, which misstates its provenance and licence. Problem: debian/copyright should reflect that a file is third-party libheif content under its own licence rather than the project’s dual licence; the file is inert in the Debian build (UHDR_BUILD_DEPS is off) so this is documentation-only, not a DFSG issue. Fix: Add a Files: cmake/patches/libheif_pr1503.patch stanza attributing it to the libheif project / its author under LGPL-3.0-or-later (with the licence text), or note the provenance in the existing catch-all. Thanks! | View |