| Message ID | 20260130160254.1770742-2-barnabas.pocze@ideasonboard.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
Hi Barnabás On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: > `fpm` will be used to easily build debian packages. Would be nice to explain what it is needed for > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > --- > .gitlab-ci/setup-container.sh | 6 ++++++ > gitlab-ci.yml | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh > index 3506271..c9bae0e 100755 > --- a/.gitlab-ci/setup-container.sh > +++ b/.gitlab-ci/setup-container.sh > @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in > PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) > # Sphinx theme for the documentation. > PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) > + # For creating debian packages with `fpm` (https://github.com/jordansissel/fpm). > + PKGS_LIBCAMERA_RUNTIME+=( ruby ) I can't really comment if using fpm is the correct way to build debs and what the implications are. Sure, relying on something that seems a (probably very nice) piece of software that lives on github instead of the official debian tools make me wonders how robust is this This guide seems to suggest to use dpkg-buildpackage https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ I don't know much about debian packaging, just checking if you have considered this solution > # libclang-rt-dev for the clang ASan runtime. > PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) > # For the Android camera HAL and the virtual pipeline handler. > @@ -277,6 +279,10 @@ Version: ${version} > Cflags: -I\${includedir} > EOF > fi > + > + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then > + gem install fpm > + fi > } > > cbuild_cleanup_pkgs() { > diff --git a/gitlab-ci.yml b/gitlab-ci.yml > index 3f80cb8..6cc2026 100644 > --- a/gitlab-ci.yml > +++ b/gitlab-ci.yml > @@ -70,7 +70,7 @@ include: > .libcamera-ci.debian:13: > variables: > FDO_DISTRIBUTION_VERSION: 'trixie' > - FDO_DISTRIBUTION_TAG: '2026-01-23.0' > + FDO_DISTRIBUTION_TAG: '2026-01-29.0' Maybe this is worth a separate commit ? > > .container-debian: > extends: > -- > 2.52.0
2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: > Hi Barnabás > > On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: >> `fpm` will be used to easily build debian packages. > > Would be nice to explain what it is needed for > >> >> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> >> --- >> .gitlab-ci/setup-container.sh | 6 ++++++ >> gitlab-ci.yml | 2 +- >> 2 files changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh >> index 3506271..c9bae0e 100755 >> --- a/.gitlab-ci/setup-container.sh >> +++ b/.gitlab-ci/setup-container.sh >> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in >> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) >> # Sphinx theme for the documentation. >> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) >> + # For creating debian packages with `fpm` (https://github.com/jordansissel/fpm). >> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) > > I can't really comment if using fpm is the correct way to build debs > and what the implications are. > > Sure, relying on something that seems a (probably very nice) piece of > software that lives on github instead of the official debian > tools make me wonders how robust is this > > This guide seems to suggest to use dpkg-buildpackage > https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ > > I don't know much about debian packaging, just checking if you have > considered this solution I really wanted to avoid having to create all the necessary files and configurations that is needed for a "proper" debian package. I originally wanted to use `checkinstall`, which is packaged, but it is too old to be usable with `meson install`. So in the end `fpm` seemed like a good replacement for `checkinstall`. As far as I understand both essentially use the official debian packaging tools, but they generate all the necessary files, etc. > > >> # libclang-rt-dev for the clang ASan runtime. >> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) >> # For the Android camera HAL and the virtual pipeline handler. >> @@ -277,6 +279,10 @@ Version: ${version} >> Cflags: -I\${includedir} >> EOF >> fi >> + >> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then >> + gem install fpm >> + fi >> } >> >> cbuild_cleanup_pkgs() { >> diff --git a/gitlab-ci.yml b/gitlab-ci.yml >> index 3f80cb8..6cc2026 100644 >> --- a/gitlab-ci.yml >> +++ b/gitlab-ci.yml >> @@ -70,7 +70,7 @@ include: >> .libcamera-ci.debian:13: >> variables: >> FDO_DISTRIBUTION_VERSION: 'trixie' >> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' >> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' > > Maybe this is worth a separate commit ? The changes don't take effect without rebuilding the container, so I believe it is preferable to keep the two together. > >> >> .container-debian: >> extends: >> -- >> 2.52.0
On Thu, Feb 05, 2026 at 01:56:30PM +0100, Barnabás Pőcze wrote: > 2026. 02. 05. 13:49 keltezéssel, Laurent Pinchart írta: > > On Thu, Feb 05, 2026 at 01:24:43PM +0100, Barnabás Pőcze wrote: > >> 2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: > >>> On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: > >>>> `fpm` will be used to easily build debian packages. > >>> > >>> Would be nice to explain what it is needed for > >>> > >>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > >>>> --- > >>>> .gitlab-ci/setup-container.sh | 6 ++++++ > >>>> gitlab-ci.yml | 2 +- > >>>> 2 files changed, 7 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh > >>>> index 3506271..c9bae0e 100755 > >>>> --- a/.gitlab-ci/setup-container.sh > >>>> +++ b/.gitlab-ci/setup-container.sh > >>>> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in > >>>> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) > >>>> # Sphinx theme for the documentation. > >>>> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) > >>>> + # For creating debian packages with `fpm` (https://github.com/jordansissel/fpm). > >>>> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) > >>> > >>> I can't really comment if using fpm is the correct way to build debs > >>> and what the implications are. > >>> > >>> Sure, relying on something that seems a (probably very nice) piece of > >>> software that lives on github instead of the official debian > >>> tools make me wonders how robust is this > >>> > >>> This guide seems to suggest to use dpkg-buildpackage > >>> https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ > >>> > >>> I don't know much about debian packaging, just checking if you have > >>> considered this solution > >> > >> I really wanted to avoid having to create all the necessary files and configurations > >> that is needed for a "proper" debian package. > > > > libcamera is packaged in Debian, so maybe we can just reuse the upstream > > files and configuration ? > > Possibly, but this was also something that I intentionally avoided. I can try to see if > it works, but at that point why not have the package definitions in the libcamera > repository itself? That's a good point, but I think it's still best to keep them separate. I don't want to open the door to maintaining the packaging infrastructure for every distribution out there in the libcamera tree. Distributions may also want to carry patches, which I don't think should live in libcamera. > I have also looked at https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging > to see if something minimal is easy to assemble, but in the end, I am not sure one can > go simpler than checkinstall/fpm. How difficult is it to do it "the native Debian way" ? Is it mostly a one time effort, or would it significantly increase the CI maintenance burden too ? > >> I originally wanted to use `checkinstall`, > >> which is packaged, but it is too old to be usable with `meson install`. So in the end > >> `fpm` seemed like a good replacement for `checkinstall`. As far as I understand both > >> essentially use the official debian packaging tools, but they generate all the necessary > >> files, etc. > >> > >>>> # libclang-rt-dev for the clang ASan runtime. > >>>> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) > >>>> # For the Android camera HAL and the virtual pipeline handler. > >>>> @@ -277,6 +279,10 @@ Version: ${version} > >>>> Cflags: -I\${includedir} > >>>> EOF > >>>> fi > >>>> + > >>>> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then > >>>> + gem install fpm > >>>> + fi > >>>> } > >>>> > >>>> cbuild_cleanup_pkgs() { > >>>> diff --git a/gitlab-ci.yml b/gitlab-ci.yml > >>>> index 3f80cb8..6cc2026 100644 > >>>> --- a/gitlab-ci.yml > >>>> +++ b/gitlab-ci.yml > >>>> @@ -70,7 +70,7 @@ include: > >>>> .libcamera-ci.debian:13: > >>>> variables: > >>>> FDO_DISTRIBUTION_VERSION: 'trixie' > >>>> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' > >>>> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' > >>> > >>> Maybe this is worth a separate commit ? > >> > >> The changes don't take effect without rebuilding the container, so I believe > >> it is preferable to keep the two together. > >> > >>>> > >>>> .container-debian: > >>>> extends:
2026. 02. 05. 14:09 keltezéssel, Laurent Pinchart írta: > On Thu, Feb 05, 2026 at 01:56:30PM +0100, Barnabás Pőcze wrote: >> 2026. 02. 05. 13:49 keltezéssel, Laurent Pinchart írta: >>> On Thu, Feb 05, 2026 at 01:24:43PM +0100, Barnabás Pőcze wrote: >>>> 2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: >>>>> On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: >>>>>> `fpm` will be used to easily build debian packages. >>>>> >>>>> Would be nice to explain what it is needed for >>>>> >>>>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> >>>>>> --- >>>>>> .gitlab-ci/setup-container.sh | 6 ++++++ >>>>>> gitlab-ci.yml | 2 +- >>>>>> 2 files changed, 7 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh >>>>>> index 3506271..c9bae0e 100755 >>>>>> --- a/.gitlab-ci/setup-container.sh >>>>>> +++ b/.gitlab-ci/setup-container.sh >>>>>> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in >>>>>> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) >>>>>> # Sphinx theme for the documentation. >>>>>> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) >>>>>> + # For creating debian packages with `fpm` (https://github.com/jordansissel/fpm). >>>>>> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) >>>>> >>>>> I can't really comment if using fpm is the correct way to build debs >>>>> and what the implications are. >>>>> >>>>> Sure, relying on something that seems a (probably very nice) piece of >>>>> software that lives on github instead of the official debian >>>>> tools make me wonders how robust is this >>>>> >>>>> This guide seems to suggest to use dpkg-buildpackage >>>>> https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ >>>>> >>>>> I don't know much about debian packaging, just checking if you have >>>>> considered this solution >>>> >>>> I really wanted to avoid having to create all the necessary files and configurations >>>> that is needed for a "proper" debian package. >>> >>> libcamera is packaged in Debian, so maybe we can just reuse the upstream >>> files and configuration ? >> >> Possibly, but this was also something that I intentionally avoided. I can try to see if >> it works, but at that point why not have the package definitions in the libcamera >> repository itself? > > That's a good point, but I think it's still best to keep them separate. > I don't want to open the door to maintaining the packaging > infrastructure for every distribution out there in the libcamera tree. > Distributions may also want to carry patches, which I don't think should > live in libcamera. > >> I have also looked at https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging >> to see if something minimal is easy to assemble, but in the end, I am not sure one can >> go simpler than checkinstall/fpm. > > How difficult is it to do it "the native Debian way" ? Is it mostly a > one time effort, or would it significantly increase the CI maintenance > burden too ? I suppose it is more a one time thing with small changes later. Nonetheless I personally am no expert of debian packaging, in fact I find it somewhat unapproachable. It appears more considerably more involved than a simple PKGBUILD (pacman), and I'm sure the complexity is justified. But here we're only building a "throwaway" debian package that is deployed into a known environment, installed once, and forgotten forever; so eliminating any and all complexity seems to be the best choice in my opinion. So what should it be? > >>>> I originally wanted to use `checkinstall`, >>>> which is packaged, but it is too old to be usable with `meson install`. So in the end >>>> `fpm` seemed like a good replacement for `checkinstall`. As far as I understand both >>>> essentially use the official debian packaging tools, but they generate all the necessary >>>> files, etc. >>>> >>>>>> # libclang-rt-dev for the clang ASan runtime. >>>>>> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) >>>>>> # For the Android camera HAL and the virtual pipeline handler. >>>>>> @@ -277,6 +279,10 @@ Version: ${version} >>>>>> Cflags: -I\${includedir} >>>>>> EOF >>>>>> fi >>>>>> + >>>>>> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then >>>>>> + gem install fpm >>>>>> + fi >>>>>> } >>>>>> >>>>>> cbuild_cleanup_pkgs() { >>>>>> diff --git a/gitlab-ci.yml b/gitlab-ci.yml >>>>>> index 3f80cb8..6cc2026 100644 >>>>>> --- a/gitlab-ci.yml >>>>>> +++ b/gitlab-ci.yml >>>>>> @@ -70,7 +70,7 @@ include: >>>>>> .libcamera-ci.debian:13: >>>>>> variables: >>>>>> FDO_DISTRIBUTION_VERSION: 'trixie' >>>>>> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' >>>>>> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' >>>>> >>>>> Maybe this is worth a separate commit ? >>>> >>>> The changes don't take effect without rebuilding the container, so I believe >>>> it is preferable to keep the two together. >>>> >>>>>> >>>>>> .container-debian: >>>>>> extends: >
Barnabás Pőcze <barnabas.pocze@ideasonboard.com> writes: > 2026. 02. 05. 14:09 keltezéssel, Laurent Pinchart írta: >> On Thu, Feb 05, 2026 at 01:56:30PM +0100, Barnabás Pőcze wrote: >>> 2026. 02. 05. 13:49 keltezéssel, Laurent Pinchart írta: > >>>> On Thu, Feb 05, 2026 at 01:24:43PM +0100, Barnabás Pőcze wrote: >>>>> 2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: >>>>>> On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: >>>>>>> `fpm` will be used to easily build debian packages. >>>>>> >>>>>> Would be nice to explain what it is needed for >>>>>> >>>>>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> >>>>>>> --- >>>>>>> .gitlab-ci/setup-container.sh | 6 ++++++ >>>>>>> gitlab-ci.yml | 2 +- >>>>>>> 2 files changed, 7 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh >>>>>>> index 3506271..c9bae0e 100755 >>>>>>> --- a/.gitlab-ci/setup-container.sh >>>>>>> +++ b/.gitlab-ci/setup-container.sh >>>>>>> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in >>>>>>> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) >>>>>>> # Sphinx theme for the documentation. >>>>>>> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) >>>>>>> + # For creating debian packages with `fpm` (https://github.com/jordansissel/fpm). >>>>>>> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) >>>>>> >>>>>> I can't really comment if using fpm is the correct way to build debs >>>>>> and what the implications are. >>>>>> >>>>>> Sure, relying on something that seems a (probably very nice) piece of >>>>>> software that lives on github instead of the official debian >>>>>> tools make me wonders how robust is this >>>>>> >>>>>> This guide seems to suggest to use dpkg-buildpackage >>>>>> https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ >>>>>> >>>>>> I don't know much about debian packaging, just checking if you have >>>>>> considered this solution >>>>> >>>>> I really wanted to avoid having to create all the necessary files and configurations >>>>> that is needed for a "proper" debian package. >>>> >>>> libcamera is packaged in Debian, so maybe we can just reuse the upstream >>>> files and configuration ? >>> >>> Possibly, but this was also something that I intentionally avoided. I can try to see if >>> it works, but at that point why not have the package definitions in the libcamera >>> repository itself? >> That's a good point, but I think it's still best to keep them separate. >> I don't want to open the door to maintaining the packaging >> infrastructure for every distribution out there in the libcamera tree. >> Distributions may also want to carry patches, which I don't think should >> live in libcamera. >> >>> I have also looked at https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging >>> to see if something minimal is easy to assemble, but in the end, I am not sure one can >>> go simpler than checkinstall/fpm. >> How difficult is it to do it "the native Debian way" ? Is it mostly a >> one time effort, or would it significantly increase the CI maintenance >> burden too ? > > I suppose it is more a one time thing with small changes later. Nonetheless > I personally am no expert of debian packaging, in fact I find it somewhat > unapproachable. It appears more considerably more involved than a simple > PKGBUILD (pacman), and I'm sure the complexity is justified. But here we're > only building a "throwaway" debian package that is deployed into a known > environment, installed once, and forgotten forever; so eliminating any and > all complexity seems to be the best choice in my opinion. I would agree. Also, in case you still decide to add some Debian packaging, don't add it as `debian' top directory included in the main git branch and/or in the release tarball, see https://wiki.debian.org/UpstreamGuide#Do_not_include_a_.2Fdebian_directory > So what should it be? > > >> >>>>> I originally wanted to use `checkinstall`, >>>>> which is packaged, but it is too old to be usable with `meson install`. So in the end >>>>> `fpm` seemed like a good replacement for `checkinstall`. As far as I understand both >>>>> essentially use the official debian packaging tools, but they generate all the necessary >>>>> files, etc. >>>>> >>>>>>> # libclang-rt-dev for the clang ASan runtime. >>>>>>> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) >>>>>>> # For the Android camera HAL and the virtual pipeline handler. >>>>>>> @@ -277,6 +279,10 @@ Version: ${version} >>>>>>> Cflags: -I\${includedir} >>>>>>> EOF >>>>>>> fi >>>>>>> + >>>>>>> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then >>>>>>> + gem install fpm >>>>>>> + fi >>>>>>> } >>>>>>> >>>>>>> cbuild_cleanup_pkgs() { >>>>>>> diff --git a/gitlab-ci.yml b/gitlab-ci.yml >>>>>>> index 3f80cb8..6cc2026 100644 >>>>>>> --- a/gitlab-ci.yml >>>>>>> +++ b/gitlab-ci.yml >>>>>>> @@ -70,7 +70,7 @@ include: >>>>>>> .libcamera-ci.debian:13: >>>>>>> variables: >>>>>>> FDO_DISTRIBUTION_VERSION: 'trixie' >>>>>>> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' >>>>>>> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' >>>>>> >>>>>> Maybe this is worth a separate commit ? >>>>> >>>>> The changes don't take effect without rebuilding the container, so I believe >>>>> it is preferable to keep the two together. >>>>> >>>>>>> >>>>>>> .container-debian: >>>>>>> extends: >>
On Mon, Feb 09, 2026 at 12:03:09PM +0100, Barnabás Pőcze wrote: > 2026. 02. 05. 14:09 keltezéssel, Laurent Pinchart írta: > > On Thu, Feb 05, 2026 at 01:56:30PM +0100, Barnabás Pőcze wrote: > >> 2026. 02. 05. 13:49 keltezéssel, Laurent Pinchart írta: > >>> On Thu, Feb 05, 2026 at 01:24:43PM +0100, Barnabás Pőcze wrote: > >>>> 2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: > >>>>> On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: > >>>>>> `fpm` will be used to easily build debian packages. > >>>>> > >>>>> Would be nice to explain what it is needed for > >>>>> > >>>>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > >>>>>> --- > >>>>>> .gitlab-ci/setup-container.sh | 6 ++++++ > >>>>>> gitlab-ci.yml | 2 +- > >>>>>> 2 files changed, 7 insertions(+), 1 deletion(-) > >>>>>> > >>>>>> diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh > >>>>>> index 3506271..c9bae0e 100755 > >>>>>> --- a/.gitlab-ci/setup-container.sh > >>>>>> +++ b/.gitlab-ci/setup-container.sh > >>>>>> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) > >>>>>> # Sphinx theme for the documentation. > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) > >>>>>> + # For creating debian packages with `fpm` (https://github.com/jordansissel/fpm). > >>>>>> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) > >>>>> > >>>>> I can't really comment if using fpm is the correct way to build debs > >>>>> and what the implications are. > >>>>> > >>>>> Sure, relying on something that seems a (probably very nice) piece of > >>>>> software that lives on github instead of the official debian > >>>>> tools make me wonders how robust is this > >>>>> > >>>>> This guide seems to suggest to use dpkg-buildpackage > >>>>> https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ > >>>>> > >>>>> I don't know much about debian packaging, just checking if you have > >>>>> considered this solution > >>>> > >>>> I really wanted to avoid having to create all the necessary files and configurations > >>>> that is needed for a "proper" debian package. > >>> > >>> libcamera is packaged in Debian, so maybe we can just reuse the upstream > >>> files and configuration ? > >> > >> Possibly, but this was also something that I intentionally avoided. I can try to see if > >> it works, but at that point why not have the package definitions in the libcamera > >> repository itself? > > > > That's a good point, but I think it's still best to keep them separate. > > I don't want to open the door to maintaining the packaging > > infrastructure for every distribution out there in the libcamera tree. > > Distributions may also want to carry patches, which I don't think should > > live in libcamera. > > > >> I have also looked at https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging > >> to see if something minimal is easy to assemble, but in the end, I am not sure one can > >> go simpler than checkinstall/fpm. > > > > How difficult is it to do it "the native Debian way" ? Is it mostly a > > one time effort, or would it significantly increase the CI maintenance > > burden too ? > > I suppose it is more a one time thing with small changes later. Nonetheless > I personally am no expert of debian packaging, in fact I find it somewhat > unapproachable. It appears more considerably more involved than a simple > PKGBUILD (pacman), and I'm sure the complexity is justified. But here we're > only building a "throwaway" debian package that is deployed into a known > environment, installed once, and forgotten forever; so eliminating any and > all complexity seems to be the best choice in my opinion. > > So what should it be? I would have a preference for the native Debian packaging approach as it's one less dependency, and the one time effort would hopefully not be too high given that there's already a Debian package for libcamera that we can use as a starting point. This being said, it could also be done later, this patch should work. Maybe you could give it a try and see if it can be done quickly, and postpone it otherwise ? > >>>> I originally wanted to use `checkinstall`, > >>>> which is packaged, but it is too old to be usable with `meson install`. So in the end > >>>> `fpm` seemed like a good replacement for `checkinstall`. As far as I understand both > >>>> essentially use the official debian packaging tools, but they generate all the necessary > >>>> files, etc. > >>>> > >>>>>> # libclang-rt-dev for the clang ASan runtime. > >>>>>> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) > >>>>>> # For the Android camera HAL and the virtual pipeline handler. > >>>>>> @@ -277,6 +279,10 @@ Version: ${version} > >>>>>> Cflags: -I\${includedir} > >>>>>> EOF > >>>>>> fi > >>>>>> + > >>>>>> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then > >>>>>> + gem install fpm > >>>>>> + fi > >>>>>> } > >>>>>> > >>>>>> cbuild_cleanup_pkgs() { > >>>>>> diff --git a/gitlab-ci.yml b/gitlab-ci.yml > >>>>>> index 3f80cb8..6cc2026 100644 > >>>>>> --- a/gitlab-ci.yml > >>>>>> +++ b/gitlab-ci.yml > >>>>>> @@ -70,7 +70,7 @@ include: > >>>>>> .libcamera-ci.debian:13: > >>>>>> variables: > >>>>>> FDO_DISTRIBUTION_VERSION: 'trixie' > >>>>>> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' > >>>>>> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' > >>>>> > >>>>> Maybe this is worth a separate commit ? > >>>> > >>>> The changes don't take effect without rebuilding the container, so I believe > >>>> it is preferable to keep the two together. > >>>> > >>>>>> > >>>>>> .container-debian: > >>>>>> extends:
There is modern version of fpm: https://nfpm.goreleaser.com/ On Tue, Feb 10, 2026 at 12:06 AM Laurent Pinchart < laurent.pinchart@ideasonboard.com> wrote: > On Mon, Feb 09, 2026 at 12:03:09PM +0100, Barnabás Pőcze wrote: > > 2026. 02. 05. 14:09 keltezéssel, Laurent Pinchart írta: > > > On Thu, Feb 05, 2026 at 01:56:30PM +0100, Barnabás Pőcze wrote: > > >> 2026. 02. 05. 13:49 keltezéssel, Laurent Pinchart írta: > > >>> On Thu, Feb 05, 2026 at 01:24:43PM +0100, Barnabás Pőcze wrote: > > >>>> 2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: > > >>>>> On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: > > >>>>>> `fpm` will be used to easily build debian packages. > > >>>>> > > >>>>> Would be nice to explain what it is needed for > > >>>>> > > >>>>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > >>>>>> --- > > >>>>>> .gitlab-ci/setup-container.sh | 6 ++++++ > > >>>>>> gitlab-ci.yml | 2 +- > > >>>>>> 2 files changed, 7 insertions(+), 1 deletion(-) > > >>>>>> > > >>>>>> diff --git a/.gitlab-ci/setup-container.sh > b/.gitlab-ci/setup-container.sh > > >>>>>> index 3506271..c9bae0e 100755 > > >>>>>> --- a/.gitlab-ci/setup-container.sh > > >>>>>> +++ b/.gitlab-ci/setup-container.sh > > >>>>>> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in > > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) > > >>>>>> # Sphinx theme for the documentation. > > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) > > >>>>>> + # For creating debian packages with `fpm` ( > https://github.com/jordansissel/fpm). > > >>>>>> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) > > >>>>> > > >>>>> I can't really comment if using fpm is the correct way to build > debs > > >>>>> and what the implications are. > > >>>>> > > >>>>> Sure, relying on something that seems a (probably very nice) piece > of > > >>>>> software that lives on github instead of the official debian > > >>>>> tools make me wonders how robust is this > > >>>>> > > >>>>> This guide seems to suggest to use dpkg-buildpackage > > >>>>> > https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ > > >>>>> > > >>>>> I don't know much about debian packaging, just checking if you have > > >>>>> considered this solution > > >>>> > > >>>> I really wanted to avoid having to create all the necessary files > and configurations > > >>>> that is needed for a "proper" debian package. > > >>> > > >>> libcamera is packaged in Debian, so maybe we can just reuse the > upstream > > >>> files and configuration ? > > >> > > >> Possibly, but this was also something that I intentionally avoided. I > can try to see if > > >> it works, but at that point why not have the package definitions in > the libcamera > > >> repository itself? > > > > > > That's a good point, but I think it's still best to keep them separate. > > > I don't want to open the door to maintaining the packaging > > > infrastructure for every distribution out there in the libcamera tree. > > > Distributions may also want to carry patches, which I don't think > should > > > live in libcamera. > > > > > >> I have also looked at > https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging > > >> to see if something minimal is easy to assemble, but in the end, I am > not sure one can > > >> go simpler than checkinstall/fpm. > > > > > > How difficult is it to do it "the native Debian way" ? Is it mostly a > > > one time effort, or would it significantly increase the CI maintenance > > > burden too ? > > > > I suppose it is more a one time thing with small changes later. > Nonetheless > > I personally am no expert of debian packaging, in fact I find it somewhat > > unapproachable. It appears more considerably more involved than a simple > > PKGBUILD (pacman), and I'm sure the complexity is justified. But here > we're > > only building a "throwaway" debian package that is deployed into a known > > environment, installed once, and forgotten forever; so eliminating any > and > > all complexity seems to be the best choice in my opinion. > > > > So what should it be? > > I would have a preference for the native Debian packaging approach as > it's one less dependency, and the one time effort would hopefully not be > too high given that there's already a Debian package for libcamera that > we can use as a starting point. > > This being said, it could also be done later, this patch should work. > Maybe you could give it a try and see if it can be done quickly, and > postpone it otherwise ? > > > >>>> I originally wanted to use `checkinstall`, > > >>>> which is packaged, but it is too old to be usable with `meson > install`. So in the end > > >>>> `fpm` seemed like a good replacement for `checkinstall`. As far as > I understand both > > >>>> essentially use the official debian packaging tools, but they > generate all the necessary > > >>>> files, etc. > > >>>> > > >>>>>> # libclang-rt-dev for the clang ASan runtime. > > >>>>>> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) > > >>>>>> # For the Android camera HAL and the virtual pipeline > handler. > > >>>>>> @@ -277,6 +279,10 @@ Version: ${version} > > >>>>>> Cflags: -I\${includedir} > > >>>>>> EOF > > >>>>>> fi > > >>>>>> + > > >>>>>> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then > > >>>>>> + gem install fpm > > >>>>>> + fi > > >>>>>> } > > >>>>>> > > >>>>>> cbuild_cleanup_pkgs() { > > >>>>>> diff --git a/gitlab-ci.yml b/gitlab-ci.yml > > >>>>>> index 3f80cb8..6cc2026 100644 > > >>>>>> --- a/gitlab-ci.yml > > >>>>>> +++ b/gitlab-ci.yml > > >>>>>> @@ -70,7 +70,7 @@ include: > > >>>>>> .libcamera-ci.debian:13: > > >>>>>> variables: > > >>>>>> FDO_DISTRIBUTION_VERSION: 'trixie' > > >>>>>> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' > > >>>>>> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' > > >>>>> > > >>>>> Maybe this is worth a separate commit ? > > >>>> > > >>>> The changes don't take effect without rebuilding the container, so > I believe > > >>>> it is preferable to keep the two together. > > >>>> > > >>>>>> > > >>>>>> .container-debian: > > >>>>>> extends: > > -- > Regards, > > Laurent Pinchart >
On Wed, Feb 11, 2026 at 05:30:58AM +0200, Nerijus Bendžiūnas wrote: > There is modern version of fpm: https://nfpm.goreleaser.com/ Thanks for the pointer. I'm a bit concerned about how this would increase the container size though. Ruby may also significantly increase the container size though. > On Tue, Feb 10, 2026 at 12:06 AM Laurent Pinchart wrote: > > On Mon, Feb 09, 2026 at 12:03:09PM +0100, Barnabás Pőcze wrote: > > > 2026. 02. 05. 14:09 keltezéssel, Laurent Pinchart írta: > > > > On Thu, Feb 05, 2026 at 01:56:30PM +0100, Barnabás Pőcze wrote: > > > >> 2026. 02. 05. 13:49 keltezéssel, Laurent Pinchart írta: > > > >>> On Thu, Feb 05, 2026 at 01:24:43PM +0100, Barnabás Pőcze wrote: > > > >>>> 2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: > > > >>>>> On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: > > > >>>>>> `fpm` will be used to easily build debian packages. > > > >>>>> > > > >>>>> Would be nice to explain what it is needed for > > > >>>>> > > > >>>>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > >>>>>> --- > > > >>>>>> .gitlab-ci/setup-container.sh | 6 ++++++ > > > >>>>>> gitlab-ci.yml | 2 +- > > > >>>>>> 2 files changed, 7 insertions(+), 1 deletion(-) > > > >>>>>> > > > >>>>>> diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh > > > >>>>>> index 3506271..c9bae0e 100755 > > > >>>>>> --- a/.gitlab-ci/setup-container.sh > > > >>>>>> +++ b/.gitlab-ci/setup-container.sh > > > >>>>>> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in > > > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) > > > >>>>>> # Sphinx theme for the documentation. > > > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) > > > >>>>>> + # For creating debian packages with `fpm` ( https://github.com/jordansissel/fpm). > > > >>>>>> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) > > > >>>>> > > > >>>>> I can't really comment if using fpm is the correct way to build debs > > > >>>>> and what the implications are. > > > >>>>> > > > >>>>> Sure, relying on something that seems a (probably very nice) piece of > > > >>>>> software that lives on github instead of the official debian > > > >>>>> tools make me wonders how robust is this > > > >>>>> > > > >>>>> This guide seems to suggest to use dpkg-buildpackage > > > >>>>> https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ > > > >>>>> > > > >>>>> I don't know much about debian packaging, just checking if you have > > > >>>>> considered this solution > > > >>>> > > > >>>> I really wanted to avoid having to create all the necessary files and configurations > > > >>>> that is needed for a "proper" debian package. > > > >>> > > > >>> libcamera is packaged in Debian, so maybe we can just reuse the upstream > > > >>> files and configuration ? > > > >> > > > >> Possibly, but this was also something that I intentionally avoided. I can try to see if > > > >> it works, but at that point why not have the package definitions in the libcamera > > > >> repository itself? > > > > > > > > That's a good point, but I think it's still best to keep them separate. > > > > I don't want to open the door to maintaining the packaging > > > > infrastructure for every distribution out there in the libcamera tree. > > > > Distributions may also want to carry patches, which I don't think should > > > > live in libcamera. > > > > > > > >> I have also looked at https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging > > > >> to see if something minimal is easy to assemble, but in the end, I am not sure one can > > > >> go simpler than checkinstall/fpm. > > > > > > > > How difficult is it to do it "the native Debian way" ? Is it mostly a > > > > one time effort, or would it significantly increase the CI maintenance > > > > burden too ? > > > > > > I suppose it is more a one time thing with small changes later. Nonetheless > > > I personally am no expert of debian packaging, in fact I find it somewhat > > > unapproachable. It appears more considerably more involved than a simple > > > PKGBUILD (pacman), and I'm sure the complexity is justified. But here we're > > > only building a "throwaway" debian package that is deployed into a known > > > environment, installed once, and forgotten forever; so eliminating any and > > > all complexity seems to be the best choice in my opinion. > > > > > > So what should it be? > > > > I would have a preference for the native Debian packaging approach as > > it's one less dependency, and the one time effort would hopefully not be > > too high given that there's already a Debian package for libcamera that > > we can use as a starting point. > > > > This being said, it could also be done later, this patch should work. > > Maybe you could give it a try and see if it can be done quickly, and > > postpone it otherwise ? > > > > > >>>> I originally wanted to use `checkinstall`, > > > >>>> which is packaged, but it is too old to be usable with `meson install`. So in the end > > > >>>> `fpm` seemed like a good replacement for `checkinstall`. As far as I understand both > > > >>>> essentially use the official debian packaging tools, but they generate all the necessary > > > >>>> files, etc. > > > >>>> > > > >>>>>> # libclang-rt-dev for the clang ASan runtime. > > > >>>>>> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) > > > >>>>>> # For the Android camera HAL and the virtual pipeline handler. > > > >>>>>> @@ -277,6 +279,10 @@ Version: ${version} > > > >>>>>> Cflags: -I\${includedir} > > > >>>>>> EOF > > > >>>>>> fi > > > >>>>>> + > > > >>>>>> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then > > > >>>>>> + gem install fpm > > > >>>>>> + fi > > > >>>>>> } > > > >>>>>> > > > >>>>>> cbuild_cleanup_pkgs() { > > > >>>>>> diff --git a/gitlab-ci.yml b/gitlab-ci.yml > > > >>>>>> index 3f80cb8..6cc2026 100644 > > > >>>>>> --- a/gitlab-ci.yml > > > >>>>>> +++ b/gitlab-ci.yml > > > >>>>>> @@ -70,7 +70,7 @@ include: > > > >>>>>> .libcamera-ci.debian:13: > > > >>>>>> variables: > > > >>>>>> FDO_DISTRIBUTION_VERSION: 'trixie' > > > >>>>>> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' > > > >>>>>> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' > > > >>>>> > > > >>>>> Maybe this is worth a separate commit ? > > > >>>> > > > >>>> The changes don't take effect without rebuilding the container, so I believe > > > >>>> it is preferable to keep the two together. > > > >>>> > > > >>>>>> > > > >>>>>> .container-debian: > > > >>>>>> extends:
Currently nfpm is 19.84 MiB. On Wed, Feb 11, 2026 at 10:18 AM Laurent Pinchart < laurent.pinchart@ideasonboard.com> wrote: > On Wed, Feb 11, 2026 at 05:30:58AM +0200, Nerijus Bendžiūnas wrote: > > There is modern version of fpm: https://nfpm.goreleaser.com/ > > Thanks for the pointer. I'm a bit concerned about how this would > increase the container size though. Ruby may also significantly increase > the container size though. > > > On Tue, Feb 10, 2026 at 12:06 AM Laurent Pinchart wrote: > > > On Mon, Feb 09, 2026 at 12:03:09PM +0100, Barnabás Pőcze wrote: > > > > 2026. 02. 05. 14:09 keltezéssel, Laurent Pinchart írta: > > > > > On Thu, Feb 05, 2026 at 01:56:30PM +0100, Barnabás Pőcze wrote: > > > > >> 2026. 02. 05. 13:49 keltezéssel, Laurent Pinchart írta: > > > > >>> On Thu, Feb 05, 2026 at 01:24:43PM +0100, Barnabás Pőcze wrote: > > > > >>>> 2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: > > > > >>>>> On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: > > > > >>>>>> `fpm` will be used to easily build debian packages. > > > > >>>>> > > > > >>>>> Would be nice to explain what it is needed for > > > > >>>>> > > > > >>>>>> Signed-off-by: Barnabás Pőcze < > barnabas.pocze@ideasonboard.com> > > > > >>>>>> --- > > > > >>>>>> .gitlab-ci/setup-container.sh | 6 ++++++ > > > > >>>>>> gitlab-ci.yml | 2 +- > > > > >>>>>> 2 files changed, 7 insertions(+), 1 deletion(-) > > > > >>>>>> > > > > >>>>>> diff --git a/.gitlab-ci/setup-container.sh > b/.gitlab-ci/setup-container.sh > > > > >>>>>> index 3506271..c9bae0e 100755 > > > > >>>>>> --- a/.gitlab-ci/setup-container.sh > > > > >>>>>> +++ b/.gitlab-ci/setup-container.sh > > > > >>>>>> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in > > > > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) > > > > >>>>>> # Sphinx theme for the documentation. > > > > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) > > > > >>>>>> + # For creating debian packages with `fpm` ( > https://github.com/jordansissel/fpm). > > > > >>>>>> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) > > > > >>>>> > > > > >>>>> I can't really comment if using fpm is the correct way to > build debs > > > > >>>>> and what the implications are. > > > > >>>>> > > > > >>>>> Sure, relying on something that seems a (probably very nice) > piece of > > > > >>>>> software that lives on github instead of the official debian > > > > >>>>> tools make me wonders how robust is this > > > > >>>>> > > > > >>>>> This guide seems to suggest to use dpkg-buildpackage > > > > >>>>> > https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ > > > > >>>>> > > > > >>>>> I don't know much about debian packaging, just checking if you > have > > > > >>>>> considered this solution > > > > >>>> > > > > >>>> I really wanted to avoid having to create all the necessary > files and configurations > > > > >>>> that is needed for a "proper" debian package. > > > > >>> > > > > >>> libcamera is packaged in Debian, so maybe we can just reuse the > upstream > > > > >>> files and configuration ? > > > > >> > > > > >> Possibly, but this was also something that I intentionally > avoided. I can try to see if > > > > >> it works, but at that point why not have the package definitions > in the libcamera > > > > >> repository itself? > > > > > > > > > > That's a good point, but I think it's still best to keep them > separate. > > > > > I don't want to open the door to maintaining the packaging > > > > > infrastructure for every distribution out there in the libcamera > tree. > > > > > Distributions may also want to carry patches, which I don't think > should > > > > > live in libcamera. > > > > > > > > > >> I have also looked at > https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging > > > > >> to see if something minimal is easy to assemble, but in the end, > I am not sure one can > > > > >> go simpler than checkinstall/fpm. > > > > > > > > > > How difficult is it to do it "the native Debian way" ? Is it > mostly a > > > > > one time effort, or would it significantly increase the CI > maintenance > > > > > burden too ? > > > > > > > > I suppose it is more a one time thing with small changes later. > Nonetheless > > > > I personally am no expert of debian packaging, in fact I find it > somewhat > > > > unapproachable. It appears more considerably more involved than a > simple > > > > PKGBUILD (pacman), and I'm sure the complexity is justified. But > here we're > > > > only building a "throwaway" debian package that is deployed into a > known > > > > environment, installed once, and forgotten forever; so eliminating > any and > > > > all complexity seems to be the best choice in my opinion. > > > > > > > > So what should it be? > > > > > > I would have a preference for the native Debian packaging approach as > > > it's one less dependency, and the one time effort would hopefully not > be > > > too high given that there's already a Debian package for libcamera that > > > we can use as a starting point. > > > > > > This being said, it could also be done later, this patch should work. > > > Maybe you could give it a try and see if it can be done quickly, and > > > postpone it otherwise ? > > > > > > > >>>> I originally wanted to use `checkinstall`, > > > > >>>> which is packaged, but it is too old to be usable with `meson > install`. So in the end > > > > >>>> `fpm` seemed like a good replacement for `checkinstall`. As far > as I understand both > > > > >>>> essentially use the official debian packaging tools, but they > generate all the necessary > > > > >>>> files, etc. > > > > >>>> > > > > >>>>>> # libclang-rt-dev for the clang ASan runtime. > > > > >>>>>> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev > ) > > > > >>>>>> # For the Android camera HAL and the virtual pipeline > handler. > > > > >>>>>> @@ -277,6 +279,10 @@ Version: ${version} > > > > >>>>>> Cflags: -I\${includedir} > > > > >>>>>> EOF > > > > >>>>>> fi > > > > >>>>>> + > > > > >>>>>> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then > > > > >>>>>> + gem install fpm > > > > >>>>>> + fi > > > > >>>>>> } > > > > >>>>>> > > > > >>>>>> cbuild_cleanup_pkgs() { > > > > >>>>>> diff --git a/gitlab-ci.yml b/gitlab-ci.yml > > > > >>>>>> index 3f80cb8..6cc2026 100644 > > > > >>>>>> --- a/gitlab-ci.yml > > > > >>>>>> +++ b/gitlab-ci.yml > > > > >>>>>> @@ -70,7 +70,7 @@ include: > > > > >>>>>> .libcamera-ci.debian:13: > > > > >>>>>> variables: > > > > >>>>>> FDO_DISTRIBUTION_VERSION: 'trixie' > > > > >>>>>> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' > > > > >>>>>> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' > > > > >>>>> > > > > >>>>> Maybe this is worth a separate commit ? > > > > >>>> > > > > >>>> The changes don't take effect without rebuilding the container, > so I believe > > > > >>>> it is preferable to keep the two together. > > > > >>>> > > > > >>>>>> > > > > >>>>>> .container-debian: > > > > >>>>>> extends: > > -- > Regards, > > Laurent Pinchart >
On Wed, Feb 11, 2026 at 09:05:33PM +0200, Nerijus Bendžiūnas wrote: > Currently nfpm is 19.84 MiB. But it's not packaged by Debian, so we'll need to install all the required packages to compile it. I have a hard time feeling enthusiastic about this, especially as we have a libcamera Debian package we can use as a starting point. > On Wed, Feb 11, 2026 at 10:18 AM Laurent Pinchart wrote: > > On Wed, Feb 11, 2026 at 05:30:58AM +0200, Nerijus Bendžiūnas wrote: > > > There is modern version of fpm: https://nfpm.goreleaser.com/ > > > > Thanks for the pointer. I'm a bit concerned about how this would > > increase the container size though. Ruby may also significantly increase > > the container size though. > > > > > On Tue, Feb 10, 2026 at 12:06 AM Laurent Pinchart wrote: > > > > On Mon, Feb 09, 2026 at 12:03:09PM +0100, Barnabás Pőcze wrote: > > > > > 2026. 02. 05. 14:09 keltezéssel, Laurent Pinchart írta: > > > > > > On Thu, Feb 05, 2026 at 01:56:30PM +0100, Barnabás Pőcze wrote: > > > > > >> 2026. 02. 05. 13:49 keltezéssel, Laurent Pinchart írta: > > > > > >>> On Thu, Feb 05, 2026 at 01:24:43PM +0100, Barnabás Pőcze wrote: > > > > > >>>> 2026. 02. 04. 10:02 keltezéssel, Jacopo Mondi írta: > > > > > >>>>> On Fri, Jan 30, 2026 at 05:02:50PM +0100, Barnabás Pőcze wrote: > > > > > >>>>>> `fpm` will be used to easily build debian packages. > > > > > >>>>> > > > > > >>>>> Would be nice to explain what it is needed for > > > > > >>>>> > > > > > >>>>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > > > >>>>>> --- > > > > > >>>>>> .gitlab-ci/setup-container.sh | 6 ++++++ > > > > > >>>>>> gitlab-ci.yml | 2 +- > > > > > >>>>>> 2 files changed, 7 insertions(+), 1 deletion(-) > > > > > >>>>>> > > > > > >>>>>> diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh > > > > > >>>>>> index 3506271..c9bae0e 100755 > > > > > >>>>>> --- a/.gitlab-ci/setup-container.sh > > > > > >>>>>> +++ b/.gitlab-ci/setup-container.sh > > > > > >>>>>> @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in > > > > > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) > > > > > >>>>>> # Sphinx theme for the documentation. > > > > > >>>>>> PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) > > > > > >>>>>> + # For creating debian packages with `fpm` (https://github.com/jordansissel/fpm). > > > > > >>>>>> + PKGS_LIBCAMERA_RUNTIME+=( ruby ) > > > > > >>>>> > > > > > >>>>> I can't really comment if using fpm is the correct way to build debs > > > > > >>>>> and what the implications are. > > > > > >>>>> > > > > > >>>>> Sure, relying on something that seems a (probably very nice) piece of > > > > > >>>>> software that lives on github instead of the official debian > > > > > >>>>> tools make me wonders how robust is this > > > > > >>>>> > > > > > >>>>> This guide seems to suggest to use dpkg-buildpackage > > > > > >>>>> https://about.gitlab.com/blog/automated-debian-package-build-with-gitlab-ci/ > > > > > >>>>> > > > > > >>>>> I don't know much about debian packaging, just checking if you have > > > > > >>>>> considered this solution > > > > > >>>> > > > > > >>>> I really wanted to avoid having to create all the necessary files and configurations > > > > > >>>> that is needed for a "proper" debian package. > > > > > >>> > > > > > >>> libcamera is packaged in Debian, so maybe we can just reuse the upstream > > > > > >>> files and configuration ? > > > > > >> > > > > > >> Possibly, but this was also something that I intentionally avoided. I can try to see if > > > > > >> it works, but at that point why not have the package definitions in the libcamera > > > > > >> repository itself? > > > > > > > > > > > > That's a good point, but I think it's still best to keep them separate. > > > > > > I don't want to open the door to maintaining the packaging > > > > > > infrastructure for every distribution out there in the libcamera tree. > > > > > > Distributions may also want to carry patches, which I don't think should > > > > > > live in libcamera. > > > > > > > > > > > >> I have also looked at https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging > > > > > >> to see if something minimal is easy to assemble, but in the end, I am not sure one can > > > > > >> go simpler than checkinstall/fpm. > > > > > > > > > > > > How difficult is it to do it "the native Debian way" ? Is it mostly a > > > > > > one time effort, or would it significantly increase the CI maintenance > > > > > > burden too ? > > > > > > > > > > I suppose it is more a one time thing with small changes later. Nonetheless > > > > > I personally am no expert of debian packaging, in fact I find it somewhat > > > > > unapproachable. It appears more considerably more involved than a simple > > > > > PKGBUILD (pacman), and I'm sure the complexity is justified. But here we're > > > > > only building a "throwaway" debian package that is deployed into a known > > > > > environment, installed once, and forgotten forever; so eliminating any and > > > > > all complexity seems to be the best choice in my opinion. > > > > > > > > > > So what should it be? > > > > > > > > I would have a preference for the native Debian packaging approach as > > > > it's one less dependency, and the one time effort would hopefully not be > > > > too high given that there's already a Debian package for libcamera that > > > > we can use as a starting point. > > > > > > > > This being said, it could also be done later, this patch should work. > > > > Maybe you could give it a try and see if it can be done quickly, and > > > > postpone it otherwise ? > > > > > > > > > >>>> I originally wanted to use `checkinstall`, > > > > > >>>> which is packaged, but it is too old to be usable with `meson install`. So in the end > > > > > >>>> `fpm` seemed like a good replacement for `checkinstall`. As far as I understand both > > > > > >>>> essentially use the official debian packaging tools, but they generate all the necessary > > > > > >>>> files, etc. > > > > > >>>> > > > > > >>>>>> # libclang-rt-dev for the clang ASan runtime. > > > > > >>>>>> PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) > > > > > >>>>>> # For the Android camera HAL and the virtual pipeline handler. > > > > > >>>>>> @@ -277,6 +279,10 @@ Version: ${version} > > > > > >>>>>> Cflags: -I\${includedir} > > > > > >>>>>> EOF > > > > > >>>>>> fi > > > > > >>>>>> + > > > > > >>>>>> + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then > > > > > >>>>>> + gem install fpm > > > > > >>>>>> + fi > > > > > >>>>>> } > > > > > >>>>>> > > > > > >>>>>> cbuild_cleanup_pkgs() { > > > > > >>>>>> diff --git a/gitlab-ci.yml b/gitlab-ci.yml > > > > > >>>>>> index 3f80cb8..6cc2026 100644 > > > > > >>>>>> --- a/gitlab-ci.yml > > > > > >>>>>> +++ b/gitlab-ci.yml > > > > > >>>>>> @@ -70,7 +70,7 @@ include: > > > > > >>>>>> .libcamera-ci.debian:13: > > > > > >>>>>> variables: > > > > > >>>>>> FDO_DISTRIBUTION_VERSION: 'trixie' > > > > > >>>>>> - FDO_DISTRIBUTION_TAG: '2026-01-23.0' > > > > > >>>>>> + FDO_DISTRIBUTION_TAG: '2026-01-29.0' > > > > > >>>>> > > > > > >>>>> Maybe this is worth a separate commit ? > > > > > >>>> > > > > > >>>> The changes don't take effect without rebuilding the container, so I believe > > > > > >>>> it is preferable to keep the two together. > > > > > >>>> > > > > > >>>>>> > > > > > >>>>>> .container-debian: > > > > > >>>>>> extends:
diff --git a/.gitlab-ci/setup-container.sh b/.gitlab-ci/setup-container.sh index 3506271..c9bae0e 100755 --- a/.gitlab-ci/setup-container.sh +++ b/.gitlab-ci/setup-container.sh @@ -138,6 +138,8 @@ case $FDO_DISTRIBUTION_VERSION in PKGS_LIBCAMERA_RUNTIME+=( g++-13 ) # Sphinx theme for the documentation. PKGS_LIBCAMERA_RUNTIME+=( python3-sphinx-book-theme ) + # For creating debian packages with `fpm` (https://github.com/jordansissel/fpm). + PKGS_LIBCAMERA_RUNTIME+=( ruby ) # libclang-rt-dev for the clang ASan runtime. PKGS_LIBCAMERA_RUNTIME_MULTIARCH+=( libclang-rt-19-dev ) # For the Android camera HAL and the virtual pipeline handler. @@ -277,6 +279,10 @@ Version: ${version} Cflags: -I\${includedir} EOF fi + + if [[ $FDO_DISTRIBUTION_VERSION == 'trixie' ]] ; then + gem install fpm + fi } cbuild_cleanup_pkgs() { diff --git a/gitlab-ci.yml b/gitlab-ci.yml index 3f80cb8..6cc2026 100644 --- a/gitlab-ci.yml +++ b/gitlab-ci.yml @@ -70,7 +70,7 @@ include: .libcamera-ci.debian:13: variables: FDO_DISTRIBUTION_VERSION: 'trixie' - FDO_DISTRIBUTION_TAG: '2026-01-23.0' + FDO_DISTRIBUTION_TAG: '2026-01-29.0' .container-debian: extends:
`fpm` will be used to easily build debian packages. Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> --- .gitlab-ci/setup-container.sh | 6 ++++++ gitlab-ci.yml | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.52.0