[Note: I added the link to your manual testplan to the bug description above] Re-considering the MIR for libcamera 0.0.5-1ubuntu1 by checking the delta: I see that this package's quality has improved and the security team seems to be happy, too (especially considering the upstream activity). I still wouldn't call it "great" and it's still in its early development stages, but OTOH we need it for hardware enablement. The maintenance burden is on the maintaining team (Desktop) and security team, so considering both teams are fine with the current state and accept to e.g. take special considerations when doing SRUs, to avoid ABI breaking changes, this works for me. => MIR team ACK. For promoting the libcamera0.0.5, libcamera-{ipa,v4l2} and gstreamer1.0-libcamera binary packages. While excluding libcamera-tools. One Recommended (non-blocking) TODO: #12 Lintian warning: libcamera-v4l2: hardening-no-fortify-functions [usr/lib/x86_64-linux-gnu/v4l2-compat.so] => I assume this is related to libcamera-v4l2's LD_PRELOAD nature, but maybe this should be double-checked and any hardeding enabled if possible. > > #0 will we be demoting lib4vl2 in favor of this? How to avoid the duplication? > > There is no plan at this point to demote lib4vl2, those are different APIs. Libcamera provides a compatibility layer through LD_PRELOAD (https://libcamera.org/docs.html#v4l2-compatibility-layer) but it is described as 'best-effort basis' and not something we plan to rely on. OK, understood. Thanks for the clarification. > > #1 libcamera-tools should be excluded and stay in "universe" (due to libqt5) dep > ack OK, I think we should be fine to promote the (new/split) libcamera0.0.5, libcamera-{ipa,v4l2} and gstreamer1.0-libcamera binary packages. While avoiding libcamera-tools. > > #2 v0.0.1 is a very early (initial) release, which was just recently tagged, > > is it really mature enough for main inclusion? > > We are at 0.0.5 now, there isn't much we can do to fix the age factor though so it doesn't feel a fair reason to block promotion of something we need to support newer hardware. ACK. See my summary above. > > Required TODOs: > > #3 symbols tracking is in place, but failures being ignored via "-c0" > > => what's the plan to avoid ABI incompatibilities? (especially with such an > > early package version?) > > Debian removed the .symbols now in https://salsa.debian.org/multimedia-team/libcamera/-/commit/bcc162f8 > > The rational is that upstream is currently bumping the soname with each release. Would that be also an > acceptable situation for the Ubuntu MIR team? This is not the best solution from a MIR perspective, as it introduces potentially unnecessary transitions and we need to be extra cautious when doing SRUs to avoid potentially breaking ABI. But I guess it's acceptable as it avoids breaking ABI during regular package updates. > > #4 some concerning Lintian warnings: https://udd.debian.org/lintian/?packages=libcamera > > + executable-stack-in-shared-library > > + symbols-file-contains-[current-version-with-]debian-revision > > Those warnings have been resolved in the current version ACK > > Recommended TODOs: > > #5 contains some embedded code (mostly android related) and static linking, which > > seems to be unused – I'll leave making a call about how to handle this to the > > security team > ack OK. Security team seems to be fine with that. > > #6 You wrote: "We will test on a selection of that hardware" > > => please provide a written test plan for this > > https://wiki.ubuntu.com/DesktopTeam/TestPlans/Libcamera Thanks! I've added this link to the bug description above > > #7 weak autopkgtests: package is re-built during tests, > > instead of testing integration of pre-built binaries > > Debian added also a simple autopkgtest calling > $ cam --list > and > $ lc-compliance --list > > Would that be enough? The project doesn't have installed test, we could hack something around the existing tests but that's not great Yes. I think the combination of those superficial tests of pre-built binaries from Debian, the manual testplan and running (rebuilt) unittest should satisfy the MIR testing requirement! > > #8 FTBFS (dh_auto_test) locally (lunar sbuild), but passes in PPA (see below), > > I'll blame my local environment for now, but that might be investigated > > Could you provide a build log if you still see the issue? We had some new versions uploaded since the review and they built fine on launchpad, local build is already working for me on a lunar desktop. I cannot reproduce this on Mantic. The package builds fine. > > #9 Ubuntu delta carries quirks (skipping tests, fixing copyright), > > which should rather be handled in upstream/Debian > > Those changes got included in Debian now Thanks! The delta is relatively small now and under control (just some i386 build fixes and adding additional autopkgtest; I wonder if the latter could be upstreamed into Debian?) > > #10 We should upgrade to upstream's current v0.0.2 release > > We have 0.0.5 now which is the current upstream version ACK. > > #11 Errors/warnings during the build, to be discussed with upstream/Debian: > > Those warnings aren't in the current build log anymore at the expection of 'substitution variable ${shlibs:Depends} used, but is not defined' which should be fine to ignore since it provides some safety, if a binary ever get added to one of those packages the depends will be correct without relying on the maintainer to not forget to add those back to the control. ACK. That's looking much better.