[libcamera-devel] [PATCH v2 1/2] libcamera: ipa_manager: Only parse IPA modules

[Dylan Aissi]

Hi,

On 2/19/25 18:03, Kieran Bingham wrote:
> Quoting Dylan Aissi (2025-02-19 16:13:28)
> 
>> What do you think about using
>> usr/libexec/$(DEB_HOST_MULTIARCH)/libcamera/ instead of
>> usr/libexec/libcamera/ ? That would keep these packages multi-arch
>> co-installable.
> 
> I think that's fine. As long as the IPA components are distinctly
> separated from the normal system libraries.
> 
>   
>>> I agree with the reasoning. All components needed at build time should
>>> come from multiarch packages. Components needed at runtime only (IPA
>>> modules, IPA proxies, and v4l2-compat.so) don't need to be
>>> multiarch-compatible as far as I can tell.
>>>
>>
>>>> Will you make an update to the debian packages?
>>
>> Of course! Especially because the freeze of Debian Trixie is coming [1]
>> and I don't want to provide a package of libcamera with bugs in the
>> future Debian stable :-)
> 
> Awesome, thanks. out of interest,
> https://lists.debian.org/debian-devel-announce/2025/01/msg00004.html
> lists:
> 
> 2025-03-15      - Milestone 1 - Transition and toolchain freeze
> 2025-04-15      - Milestone 2 - Soft Freeze
> 2025-05-15      - Milestone 3 - Hard Freeze - for key packages and
>                                  packages without autopkgtests
> To be announced - Milestone 4 - Full Freeze
> 
> Which of those milestones is the last time a new version of libcamera
> will be updated in debian trixie?

It depends! :-)

If the next version of libcamera introduces a soname change, then the
deadline to get it in Trixie is 2025-03-15 (transition freeze). Because 
it will require a transition, that means I will have to update the 
package, upload it to debian/experimental, then wait for builders to 
build the package on all architectures (at least the official ones [1]).
Once built, I will have to ping the Debian release team to get their 
approval to start the transition [2]. Which is to upload the package to 
debian/unstable and wait the rebuild of libcamera and other packages 
depending on it. Ideally, this hypothetical version should be released 
some days before to give enough time to all parties involved.

On the other hand, if there is no soname change, we can easily upload a 
new version until 2025-04-15 (Soft freeze). After this date, it's still 
possible to cherry-pick some commits to fix targeted bugs. And after the 
2025-05-15 (Hard freeze), fixes will have to be manually approved by the 
release team (libcamera is now part of the key packages [3]). For more 
details see [4].

This applies only for new upstream releases, it will be much easier to 
apply packaging fixes during freezes.

[1] https://www.debian.org/ports/
[2] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
[3] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
[4] https://release.debian.org/testing/freeze_policy.html

>> I have created two merge requests to fix the debian packaging, one
>> dropping the override of --libexecdir [2] and the other using
>> libexec/$(DEB_HOST_MULTIARCH) to override it [3].
>>
> 
> [3] looks pretty reasonable to me.

I will finalize the package early next week, just in case of last minute 
feedback. :-)

> --
> Kieran
> 
> 
>>
>> Best regards,
>> Dylan
>>
>> [1] https://lists.debian.org/debian-devel-announce/2025/01/msg00004.html
>> [2] https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/15
>> [3] https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/16

-- 
Dylan Aïssi | Software Engineer

Collabora Limited | Platinum Building, Cowley Road, Cambridge CB4 0DS, 
UK Registered in England & Wales no 5513718.