[{"id":37835,"web_url":"https://patchwork.libcamera.org/comment/37835/","msgid":"<20260122022259.GC209830@killaraus>","date":"2026-01-22T02:22:59","subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Mon, Jan 19, 2026 at 11:20:37AM +0100, Barnabás Pőcze wrote:\n> Add a job that builds a debian rootfs and uploads it to the gitlab container\n> registry, with the dependencies needed by libcamera created in the\n> build-debian-cross job.\n\nI'm not sure this belongs to the FDO CI. Can't we build this container\nlocally instead, to avoid consuming CPU and network bandwidth from FDO ?\nThe Containerfile for this can be stored in a subdirectory of\ncontainers/.\n\n> Signed-off-by: Barnabás Pőcze \n> ---\n> .gitlab-ci/build-debian-rootfs.sh | 79 +++++++++++++++++++++++++++++++\n> gitlab-ci.yml | 47 ++++++++++++++++++\n> 2 files changed, 126 insertions(+)\n> create mode 100755 .gitlab-ci/build-debian-rootfs.sh\n> \n> diff --git a/.gitlab-ci/build-debian-rootfs.sh b/.gitlab-ci/build-debian-rootfs.sh\n> new file mode 100755\n> index 0000000..800ba5f\n> --- /dev/null\n> +++ b/.gitlab-ci/build-debian-rootfs.sh\n> @@ -0,0 +1,79 @@\n> +#!/bin/bash\n> +# based on https://gitlab.freedesktop.org/freedesktop/ci-templates/-/blob/fb9d50ccb3cbbb4c6dc5f9ef53a0ad3cb0d8a177/bootstrap/cbuild\n> +\n> +set -ex\n> +\n> +packages=(\n> +\t# misc.\n> +\tca-certificates\n> +\tcoreutils\n> +\tchrony\n> +\tcurl\n> +\tiproute2\n> +\tkmod\n> +\tmoreutils\n> +\topenssh-server\n> +\tv4l-utils\n> +\twget\n> +\n> +\t# runtime dependencies\n> +\tlibevent-2.1-7\n> +\tlibevent-pthreads-2.1-7\n> +\tlibpisp1\n> +\tlibssl3t64\n> +\tlibudev1\n> +\tlibyaml-0-2\n> +\tudev\n> +)\n> +\n> +podman login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n> +skopeo login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n> +\n> +deb_distribution=\"$1\"\n> +deb_arch=\"$2\"\n> +container_image_path=\"$3\"\n> +container_image_tag=\"$4\"\n> +overlay_dir=\"$5\"\n> +\n> +container_image_name=\"$CI_REGISTRY_IMAGE/$container_image_path:$container_image_tag\"\n> +\n> +if skopeo inspect --no-tags --retry-times 3 \"docker://$container_image_name\"; then\n> +\techo \"container image exists\"\n> +\texit 0\n> +fi\n> +\n> +# TODO: Check if image already exists in the registry of $FDO_UPSTREAM_REPO?\n> +\n> +newcontainer=$(buildah from scratch)\n> +scratchmnt=$(buildah mount \"$newcontainer\")\n> +\n> +debootstrap --arch=\"$deb_arch\" --variant=minbase \"$deb_distribution\" \"$scratchmnt\"\n> +\n> +buildah run --isolation=chroot \"$newcontainer\" apt update -y\n> +buildah run --isolation=chroot \"$newcontainer\" apt install -y --no-install-recommends systemd systemd-sysv\n> +buildah run --isolation=chroot \"$newcontainer\" apt install -y --no-install-recommends \"${packages[@]}\"\n> +buildah run --isolation=chroot \"$newcontainer\" bash -c 'printf \"root\\nroot\\n\" | passwd root'\n> +buildah run --isolation=chroot \"$newcontainer\" bash -c 'echo \"PermitRootLogin yes\" > /etc/ssh/sshd_config.d/10-allow-root-password.conf'\n> +buildah run --isolation=chroot \"$newcontainer\" apt autoclean -y\n> +buildah run --isolation=chroot \"$newcontainer\" apt autopurge -y\n> +\n> +buildah run --isolation=chroot \"$newcontainer\" rm -rf /var/cache/\n> +buildah run --isolation=chroot \"$newcontainer\" rm -rf /var/lib/apt/\n> +\n> +if [[ -d \"$overlay_dir\" ]]; then\n> +\trsync -av --chown=root:root \"$overlay_dir/\" \"$scratchmnt/\"\n> +fi\n> +\n> +buildah unmount \"$newcontainer\"\n> +\n> +buildah config -l fdo.pipeline_id=\"$CI_PIPELINE_ID\" \"$newcontainer\"\n> +buildah config -l fdo.job_id=\"$CI_JOB_ID\" \"$newcontainer\"\n> +buildah config -l fdo.project=\"$CI_PROJECT_PATH\" \"$newcontainer\"\n> +buildah config -l fdo.commit=\"$CI_COMMIT_SHA\" \"$newcontainer\"\n> +buildah config --entrypoint '[\"/sbin/init\"]' \"$newcontainer\"\n> +\n> +buildah commit --format=docker \"$newcontainer\" \"$container_image_name\"\n> +\n> +podman image inspect \"$container_image_name\"\n> +\n> +podman push --compression-format=gzip \"$container_image_name\"\n\nIf running on FDO, why do you reimplement all this instead of using the\nCI templates ? And if not running on FDO, a Containerfile could be used.\n\n> diff --git a/gitlab-ci.yml b/gitlab-ci.yml\n> index b7362d7..36032e3 100644\n> --- a/gitlab-ci.yml\n> +++ b/gitlab-ci.yml\n> @@ -144,6 +144,33 @@ container-build-debian-cross:\n> .gitlab-ci/setup-debian-cross-container.sh \"$ARCH\" ;\n> gem install fpm ;\n> \n> +.container-build-debian-rootfs:\n> + variables:\n> + FDO_DISTRIBUTION_VERSION: 'trixie'\n> + FDO_DISTRIBUTION_TAG: 'build-debian-rootfs-2026-01-12.0'\n> +\n> +container-build-debian-rootfs:\n> + extends:\n> + - .fdo.container-build@debian\n> + - .container-build-debian-rootfs\n> + stage: container\n> + needs: []\n> + variables:\n> + GIT_STRATEGY: none\n> + FDO_DISTRIBUTION_PACKAGES: >-\n> + buildah\n> + ca-certificates\n> + debootstrap\n> + dpkg-dev\n> + findutils\n> + fuse-overlayfs\n> + git\n> + jq\n> + meson\n> + podman\n> + rsync\n> + skopeo\n> +\n> # ------------------------------------------------------------------------------\n> # Build stage - Build libcamera for various platforms and configurations\n> # ------------------------------------------------------------------------------\n> @@ -432,6 +459,26 @@ build-debian-cross:\n> - build/build.ninja\n> - \"*.deb\"\n> \n> +build-debian-rootfs:\n> + extends:\n> + - .fdo.distribution-image@debian\n> + - .container-build-debian-rootfs\n> + - .debian-cross-build\n> + - .debian-cross-build-architectures\n> + - .libcamera-ci.scripts\n> + stage: build\n> + needs:\n> + - job: container-build-debian-rootfs\n> + artifacts: false\n> + variables:\n> + GIT_STRATEGY: none\n> + script:\n> + - $CI_PROJECT_DIR/.gitlab-ci/build-debian-rootfs.sh\n> + \"$CROSS_BUILD_DISTRIBUTION_VERSION\"\n> + \"$ARCH\"\n> + \"$CROSS_BUILD_IMAGE\"\n> + \"$CROSS_BUILD_TAG-$ARCH\"\n> +\n> # ------------------------------------------------------------------------------\n> # Lint stage - Run checkstyle.py and check merge suitability\n> # ------------------------------------------------------------------------------","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id A385CBDCBF\n\tfor ;\n\tThu, 22 Jan 2026 02:23:03 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8C70361FCA;\n\tThu, 22 Jan 2026 03:23:02 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4025161A35\n\tfor ;\n\tThu, 22 Jan 2026 03:23:01 +0100 (CET)","from pendragon.ideasonboard.com\n\t(2001-14ba-703d-e500--ff4.rev.dnainternet.fi\n\t[IPv6:2001:14ba:703d:e500::ff4])\n\tby perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id BB6A4324;\n\tThu, 22 Jan 2026 03:22:28 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"bA0/Avhd\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1769048548;\n\tbh=WSUAea6r6wWZ5T43KCtqxQYLnsJzcniq85SzGU2llSw=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=bA0/AvhdzmgUjTjRbCczpDd7ZLT6KvlLXNdl8Q5D8mxu/GufRRE88oxVeJU7Nw/Ci\n\tuMwm7uf4jRs0vQoKEat9vnS2We/gov3bNd6LjWa5Tt1lsM+FvCmVfH8BUgeP7EYq5a\n\tQgY6QFCE9Pir/LYleC2fIo0RI3C8cykLqf7/pckA=","Date":"Thu, 22 Jan 2026 04:22:59 +0200","From":"Laurent Pinchart ","To":"=?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= ","Cc":"libcamera-devel@lists.libcamera.org","Subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","Message-ID":"<20260122022259.GC209830@killaraus>","References":"<20260119102039.3521673-1-barnabas.pocze@ideasonboard.com>\n\t<20260119102039.3521673-4-barnabas.pocze@ideasonboard.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260119102039.3521673-4-barnabas.pocze@ideasonboard.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":37864,"web_url":"https://patchwork.libcamera.org/comment/37864/","msgid":"<25691548-d660-4151-8a38-500ae969f53f@ideasonboard.com>","date":"2026-01-22T09:30:56","subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","submitter":{"id":216,"url":"https://patchwork.libcamera.org/api/people/216/","name":"Barnabás Pőcze","email":"barnabas.pocze@ideasonboard.com"},"content":"2026. 01. 22. 3:22 keltezéssel, Laurent Pinchart írta:\n> On Mon, Jan 19, 2026 at 11:20:37AM +0100, Barnabás Pőcze wrote:\n>> Add a job that builds a debian rootfs and uploads it to the gitlab container\n>> registry, with the dependencies needed by libcamera created in the\n>> build-debian-cross job.\n> \n> I'm not sure this belongs to the FDO CI. Can't we build this container\n> locally instead, to avoid consuming CPU and network bandwidth from FDO ?\n> The Containerfile for this can be stored in a subdirectory of\n> containers/.\n\nAs mentioned in the cover letter, I think it would be nice to have the rootfs\nin the ci pipeline. Normally this job, like the other `container-*` jobs, won't\ndo anything processing intensive, so my assumption was that it was fine.\n(Especially if all this is guarded my a manual trigger / variable.)\n\nYes, this can be built locally, certainly. I think the main question is, do we\never want to have the whole rootfs creation and deployment automated? If so, then\nI believe it makes sense to keep it in a fdo ci \"compatible\" state. Since that\nautomation is still missing pieces on the hardware side, it might also make sense,\nfor the time being, to move these parts into a `containers/` with some documentation\n\n\n> \n>> Signed-off-by: Barnabás Pőcze \n>> ---\n>> .gitlab-ci/build-debian-rootfs.sh | 79 +++++++++++++++++++++++++++++++\n>> gitlab-ci.yml | 47 ++++++++++++++++++\n>> 2 files changed, 126 insertions(+)\n>> create mode 100755 .gitlab-ci/build-debian-rootfs.sh\n>>\n>> diff --git a/.gitlab-ci/build-debian-rootfs.sh b/.gitlab-ci/build-debian-rootfs.sh\n>> new file mode 100755\n>> index 0000000..800ba5f\n>> --- /dev/null\n>> +++ b/.gitlab-ci/build-debian-rootfs.sh\n>> @@ -0,0 +1,79 @@\n> [...]\n>> +buildah config -l fdo.pipeline_id=\"$CI_PIPELINE_ID\" \"$newcontainer\"\n>> +buildah config -l fdo.job_id=\"$CI_JOB_ID\" \"$newcontainer\"\n>> +buildah config -l fdo.project=\"$CI_PROJECT_PATH\" \"$newcontainer\"\n>> +buildah config -l fdo.commit=\"$CI_COMMIT_SHA\" \"$newcontainer\"\n>> +buildah config --entrypoint '[\"/sbin/init\"]' \"$newcontainer\"\n>> +\n>> +buildah commit --format=docker \"$newcontainer\" \"$container_image_name\"\n>> +\n>> +podman image inspect \"$container_image_name\"\n>> +\n>> +podman push --compression-format=gzip \"$container_image_name\"\n> \n> If running on FDO, why do you reimplement all this instead of using the\n> CI templates ? And if not running on FDO, a Containerfile could be used.\n\nOn a second look, it may be possible, although mapping between the docker\nplatform and debian architecture might be a bit inconvenient.\n\n\n> [...]","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 2CBD7C3220\n\tfor ;\n\tThu, 22 Jan 2026 09:31:04 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 0376761FC9;\n\tThu, 22 Jan 2026 10:31:03 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 355CB61FA0\n\tfor ;\n\tThu, 22 Jan 2026 10:31:01 +0100 (CET)","from [192.168.33.25] (185.221.143.114.nat.pool.zt.hu\n\t[185.221.143.114])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 286892DD;\n\tThu, 22 Jan 2026 10:30:28 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"GX0kkqjt\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1769074228;\n\tbh=nY8OJOF3Usj6SFlpHKcD1nuhwMbUfvHMEpCJf5BU6sw=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=GX0kkqjtaPiP3ylQIc0Y9+Q+1lvKrso0R0XG1SicP692yrsuXMjhH42UI0bkQWsSB\n\tD0CdIAERUjHL28XisX18rkV3AVxOpBApyCAmw20aLIipje9O/Zu/8Vo8npyM5Z30DC\n\tVfOIIcKg0IH4GQxy0Db+FXP1hoe3H3TNjvmgZGdo=","Message-ID":"<25691548-d660-4151-8a38-500ae969f53f@ideasonboard.com>","Date":"Thu, 22 Jan 2026 10:30:56 +0100","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","To":"Laurent Pinchart ","Cc":"libcamera-devel@lists.libcamera.org","References":"<20260119102039.3521673-1-barnabas.pocze@ideasonboard.com>\n\t<20260119102039.3521673-4-barnabas.pocze@ideasonboard.com>\n\t<20260122022259.GC209830@killaraus>","From":"=?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= ","Content-Language":"en-US, hu-HU","In-Reply-To":"<20260122022259.GC209830@killaraus>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":37894,"web_url":"https://patchwork.libcamera.org/comment/37894/","msgid":"<20260122233054.GD215800@killaraus>","date":"2026-01-22T23:30:54","subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Thu, Jan 22, 2026 at 10:30:56AM +0100, Barnabás Pőcze wrote:\n> 2026. 01. 22. 3:22 keltezéssel, Laurent Pinchart írta:\n> > On Mon, Jan 19, 2026 at 11:20:37AM +0100, Barnabás Pőcze wrote:\n> >> Add a job that builds a debian rootfs and uploads it to the gitlab container\n> >> registry, with the dependencies needed by libcamera created in the\n> >> build-debian-cross job.\n> > \n> > I'm not sure this belongs to the FDO CI. Can't we build this container\n> > locally instead, to avoid consuming CPU and network bandwidth from FDO ?\n> > The Containerfile for this can be stored in a subdirectory of\n> > containers/.\n> \n> As mentioned in the cover letter, I think it would be nice to have the rootfs\n> in the ci pipeline. Normally this job, like the other `container-*` jobs, won't\n> do anything processing intensive, so my assumption was that it was fine.\n> (Especially if all this is guarded my a manual trigger / variable.)\n> \n> Yes, this can be built locally, certainly. I think the main question is, do we\n> ever want to have the whole rootfs creation and deployment automated? If so, then\n> I believe it makes sense to keep it in a fdo ci \"compatible\" state. Since that\n> automation is still missing pieces on the hardware side, it might also make sense,\n> for the time being, to move these parts into a `containers/` with some documentation\n\nI'm in two minds about this. I see advantages in building the rootfs at\nthe same time as building libcamera, to ensure they're always in sync.\nOn the other hand, I don't expect frequent updates to the base Debian\nversion, and there are upsides of building the rootfs manually while we\nexperiment with all this. I'm slightly in favour of starting with a\nContainerfile to decouple the rootfs from CI while we ramp up testing on\nhardware, and then consider moving it to FDO. What do you think ?\n\n> >> Signed-off-by: Barnabás Pőcze \n> >> ---\n> >> .gitlab-ci/build-debian-rootfs.sh | 79 +++++++++++++++++++++++++++++++\n> >> gitlab-ci.yml | 47 ++++++++++++++++++\n> >> 2 files changed, 126 insertions(+)\n> >> create mode 100755 .gitlab-ci/build-debian-rootfs.sh\n> >>\n> >> diff --git a/.gitlab-ci/build-debian-rootfs.sh b/.gitlab-ci/build-debian-rootfs.sh\n> >> new file mode 100755\n> >> index 0000000..800ba5f\n> >> --- /dev/null\n> >> +++ b/.gitlab-ci/build-debian-rootfs.sh\n> >> @@ -0,0 +1,79 @@\n> >\n> > [...]\n> >\n> >> +buildah config -l fdo.pipeline_id=\"$CI_PIPELINE_ID\" \"$newcontainer\"\n> >> +buildah config -l fdo.job_id=\"$CI_JOB_ID\" \"$newcontainer\"\n> >> +buildah config -l fdo.project=\"$CI_PROJECT_PATH\" \"$newcontainer\"\n> >> +buildah config -l fdo.commit=\"$CI_COMMIT_SHA\" \"$newcontainer\"\n> >> +buildah config --entrypoint '[\"/sbin/init\"]' \"$newcontainer\"\n> >> +\n> >> +buildah commit --format=docker \"$newcontainer\" \"$container_image_name\"\n> >> +\n> >> +podman image inspect \"$container_image_name\"\n> >> +\n> >> +podman push --compression-format=gzip \"$container_image_name\"\n> > \n> > If running on FDO, why do you reimplement all this instead of using the\n> > CI templates ? And if not running on FDO, a Containerfile could be used.\n> \n> On a second look, it may be possible, although mapping between the docker\n> platform and debian architecture might be a bit inconvenient.\n> \n> > [...]","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id DC9C5C3220\n\tfor ;\n\tThu, 22 Jan 2026 23:30:58 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 255D161FC9;\n\tFri, 23 Jan 2026 00:30:58 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id DFA9D61F9F\n\tfor ;\n\tFri, 23 Jan 2026 00:30:55 +0100 (CET)","from pendragon.ideasonboard.com\n\t(2001-14ba-703d-e500--2a1.rev.dnainternet.fi\n\t[IPv6:2001:14ba:703d:e500::2a1])\n\tby perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id B501922F;\n\tFri, 23 Jan 2026 00:30:22 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"dbQqqU71\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1769124622;\n\tbh=w73rpUI2778DekBYz+fv97adWATMt4sG2w1PtzMPIIc=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=dbQqqU71aFOL4iNE90y5lkUsdhRIXKYvK8knWb0aafzCj9vBifNvPZEpbCnmF1byR\n\tq1NhoDODFOV/5zsWObmV8u9OlAyEBeXVeLHEm0UxOsWx3qg+2WY2S9JKkxGW8s973w\n\tTfCA4QGKyuXUYscqf75tZVJ8xRxDqzRSiZnRmj1s=","Date":"Fri, 23 Jan 2026 01:30:54 +0200","From":"Laurent Pinchart ","To":"=?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= ","Cc":"libcamera-devel@lists.libcamera.org","Subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","Message-ID":"<20260122233054.GD215800@killaraus>","References":"<20260119102039.3521673-1-barnabas.pocze@ideasonboard.com>\n\t<20260119102039.3521673-4-barnabas.pocze@ideasonboard.com>\n\t<20260122022259.GC209830@killaraus>\n\t<25691548-d660-4151-8a38-500ae969f53f@ideasonboard.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<25691548-d660-4151-8a38-500ae969f53f@ideasonboard.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":37904,"web_url":"https://patchwork.libcamera.org/comment/37904/","msgid":"","date":"2026-01-23T10:59:37","subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","submitter":{"id":216,"url":"https://patchwork.libcamera.org/api/people/216/","name":"Barnabás Pőcze","email":"barnabas.pocze@ideasonboard.com"},"content":"2026. 01. 23. 0:30 keltezéssel, Laurent Pinchart írta:\n> On Thu, Jan 22, 2026 at 10:30:56AM +0100, Barnabás Pőcze wrote:\n>> 2026. 01. 22. 3:22 keltezéssel, Laurent Pinchart írta:\n>>> On Mon, Jan 19, 2026 at 11:20:37AM +0100, Barnabás Pőcze wrote:\n>>>> Add a job that builds a debian rootfs and uploads it to the gitlab container\n>>>> registry, with the dependencies needed by libcamera created in the\n>>>> build-debian-cross job.\n>>>\n>>> I'm not sure this belongs to the FDO CI. Can't we build this container\n>>> locally instead, to avoid consuming CPU and network bandwidth from FDO ?\n>>> The Containerfile for this can be stored in a subdirectory of\n>>> containers/.\n>>\n>> As mentioned in the cover letter, I think it would be nice to have the rootfs\n>> in the ci pipeline. Normally this job, like the other `container-*` jobs, won't\n>> do anything processing intensive, so my assumption was that it was fine.\n>> (Especially if all this is guarded my a manual trigger / variable.)\n>>\n>> Yes, this can be built locally, certainly. I think the main question is, do we\n>> ever want to have the whole rootfs creation and deployment automated? If so, then\n>> I believe it makes sense to keep it in a fdo ci \"compatible\" state. Since that\n>> automation is still missing pieces on the hardware side, it might also make sense,\n>> for the time being, to move these parts into a `containers/` with some documentation\n> \n> I'm in two minds about this. I see advantages in building the rootfs at\n> the same time as building libcamera, to ensure they're always in sync.\n> On the other hand, I don't expect frequent updates to the base Debian\n> version, and there are upsides of building the rootfs manually while we\n> experiment with all this. I'm slightly in favour of starting with a\n> Containerfile to decouple the rootfs from CI while we ramp up testing on\n> hardware, and then consider moving it to FDO. What do you think ?\n\nOkay, I can move the scripts and overlay directory into `containers/`.\nBut would you prefer a `Containerfile` or is `buildah` fine? I imagine\n`debootstrap` cannot really be used with a `Containerfile`, can it? So\nyou would use `debian:13-slim` or similar as base, I imagine? And skip\nthe manual `debootstrap` step?\n\n\n> \n>>>> Signed-off-by: Barnabás Pőcze \n>>>> ---\n>>>> .gitlab-ci/build-debian-rootfs.sh | 79 +++++++++++++++++++++++++++++++\n>>>> gitlab-ci.yml | 47 ++++++++++++++++++\n>>>> 2 files changed, 126 insertions(+)\n>>>> create mode 100755 .gitlab-ci/build-debian-rootfs.sh\n>>>>\n>>>> diff --git a/.gitlab-ci/build-debian-rootfs.sh b/.gitlab-ci/build-debian-rootfs.sh\n>>>> new file mode 100755\n>>>> index 0000000..800ba5f\n>>>> --- /dev/null\n>>>> +++ b/.gitlab-ci/build-debian-rootfs.sh\n>>>> @@ -0,0 +1,79 @@\n>>>\n>>> [...]\n>>>\n>>>> +buildah config -l fdo.pipeline_id=\"$CI_PIPELINE_ID\" \"$newcontainer\"\n>>>> +buildah config -l fdo.job_id=\"$CI_JOB_ID\" \"$newcontainer\"\n>>>> +buildah config -l fdo.project=\"$CI_PROJECT_PATH\" \"$newcontainer\"\n>>>> +buildah config -l fdo.commit=\"$CI_COMMIT_SHA\" \"$newcontainer\"\n>>>> +buildah config --entrypoint '[\"/sbin/init\"]' \"$newcontainer\"\n>>>> +\n>>>> +buildah commit --format=docker \"$newcontainer\" \"$container_image_name\"\n>>>> +\n>>>> +podman image inspect \"$container_image_name\"\n>>>> +\n>>>> +podman push --compression-format=gzip \"$container_image_name\"\n>>>\n>>> If running on FDO, why do you reimplement all this instead of using the\n>>> CI templates ? And if not running on FDO, a Containerfile could be used.\n>>\n>> On a second look, it may be possible, although mapping between the docker\n>> platform and debian architecture might be a bit inconvenient.\n>>\n>>> [...]\n> \n> --\n> Regards,\n> \n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 22297BDCBF\n\tfor ;\n\tFri, 23 Jan 2026 10:59:43 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 4413261FC4;\n\tFri, 23 Jan 2026 11:59:42 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 1D7E561F61\n\tfor ;\n\tFri, 23 Jan 2026 11:59:41 +0100 (CET)","from [192.168.33.29] (185.221.143.114.nat.pool.zt.hu\n\t[185.221.143.114])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 960BD103D;\n\tFri, 23 Jan 2026 11:59:07 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"X5CZVn06\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1769165947;\n\tbh=F5IVp7ZsdrWvfeA7+zqMF8QUwYZ2kOKViRr2xxiQQ7k=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=X5CZVn06pP01L7X8TxVQkEh1sTOhj3qnOgtZiQBivKgcUkMEunyaA8MgYgoEyZNTW\n\t/x8xfcKMpOgx2dWL8OYkvFSM+lcbIAIydtnivG4gcedgJUs6EsINVbY0B76kkrqH8x\n\tGsrL9r5Gyaj5LR2Rq7ZD0I22cOhPXaX1pPvyTLiQ=","Message-ID":"","Date":"Fri, 23 Jan 2026 11:59:37 +0100","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","To":"Laurent Pinchart , =?utf-8?q?Barnab?=\n\t=?utf-8?b?w6FzIFDFkWN6ZQ==?= ","Cc":"libcamera-devel@lists.libcamera.org","References":"<20260119102039.3521673-1-barnabas.pocze@ideasonboard.com>\n\t<20260119102039.3521673-4-barnabas.pocze@ideasonboard.com>\n\t<20260122022259.GC209830@killaraus>\n\t<25691548-d660-4151-8a38-500ae969f53f@ideasonboard.com>\n\t\n\t<20260122233054.GD215800@killaraus>","From":"=?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= ","Content-Language":"en-US, hu-HU","In-Reply-To":"<20260122233054.GD215800@killaraus>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":37917,"web_url":"https://patchwork.libcamera.org/comment/37917/","msgid":"<20260123144550.GI215800@killaraus>","date":"2026-01-23T14:45:50","subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Fri, Jan 23, 2026 at 11:59:37AM +0100, Barnabás Pőcze wrote:\n> 2026. 01. 23. 0:30 keltezéssel, Laurent Pinchart írta:\n> > On Thu, Jan 22, 2026 at 10:30:56AM +0100, Barnabás Pőcze wrote:\n> >> 2026. 01. 22. 3:22 keltezéssel, Laurent Pinchart írta:\n> >>> On Mon, Jan 19, 2026 at 11:20:37AM +0100, Barnabás Pőcze wrote:\n> >>>> Add a job that builds a debian rootfs and uploads it to the gitlab container\n> >>>> registry, with the dependencies needed by libcamera created in the\n> >>>> build-debian-cross job.\n> >>>\n> >>> I'm not sure this belongs to the FDO CI. Can't we build this container\n> >>> locally instead, to avoid consuming CPU and network bandwidth from FDO ?\n> >>> The Containerfile for this can be stored in a subdirectory of\n> >>> containers/.\n> >>\n> >> As mentioned in the cover letter, I think it would be nice to have the rootfs\n> >> in the ci pipeline. Normally this job, like the other `container-*` jobs, won't\n> >> do anything processing intensive, so my assumption was that it was fine.\n> >> (Especially if all this is guarded my a manual trigger / variable.)\n> >>\n> >> Yes, this can be built locally, certainly. I think the main question is, do we\n> >> ever want to have the whole rootfs creation and deployment automated? If so, then\n> >> I believe it makes sense to keep it in a fdo ci \"compatible\" state. Since that\n> >> automation is still missing pieces on the hardware side, it might also make sense,\n> >> for the time being, to move these parts into a `containers/` with some documentation\n> > \n> > I'm in two minds about this. I see advantages in building the rootfs at\n> > the same time as building libcamera, to ensure they're always in sync.\n> > On the other hand, I don't expect frequent updates to the base Debian\n> > version, and there are upsides of building the rootfs manually while we\n> > experiment with all this. I'm slightly in favour of starting with a\n> > Containerfile to decouple the rootfs from CI while we ramp up testing on\n> > hardware, and then consider moving it to FDO. What do you think ?\n> \n> Okay, I can move the scripts and overlay directory into `containers/`.\n> But would you prefer a `Containerfile` or is `buildah` fine? I imagine\n> `debootstrap` cannot really be used with a `Containerfile`, can it? So\n> you would use `debian:13-slim` or similar as base, I imagine? And skip\n> the manual `debootstrap` step?\n\nThat's what I had in mind, but if buildah is a more modern and better\nsolution for the problem at hand, I'm OK with that too. We use\nContainerfile for the CrOS container, it would be nice to standardize on\none technical solution if we can.\n\n> >>>> Signed-off-by: Barnabás Pőcze \n> >>>> ---\n> >>>> .gitlab-ci/build-debian-rootfs.sh | 79 +++++++++++++++++++++++++++++++\n> >>>> gitlab-ci.yml | 47 ++++++++++++++++++\n> >>>> 2 files changed, 126 insertions(+)\n> >>>> create mode 100755 .gitlab-ci/build-debian-rootfs.sh\n> >>>>\n> >>>> diff --git a/.gitlab-ci/build-debian-rootfs.sh b/.gitlab-ci/build-debian-rootfs.sh\n> >>>> new file mode 100755\n> >>>> index 0000000..800ba5f\n> >>>> --- /dev/null\n> >>>> +++ b/.gitlab-ci/build-debian-rootfs.sh\n> >>>> @@ -0,0 +1,79 @@\n> >>>\n> >>> [...]\n> >>>\n> >>>> +buildah config -l fdo.pipeline_id=\"$CI_PIPELINE_ID\" \"$newcontainer\"\n> >>>> +buildah config -l fdo.job_id=\"$CI_JOB_ID\" \"$newcontainer\"\n> >>>> +buildah config -l fdo.project=\"$CI_PROJECT_PATH\" \"$newcontainer\"\n> >>>> +buildah config -l fdo.commit=\"$CI_COMMIT_SHA\" \"$newcontainer\"\n> >>>> +buildah config --entrypoint '[\"/sbin/init\"]' \"$newcontainer\"\n> >>>> +\n> >>>> +buildah commit --format=docker \"$newcontainer\" \"$container_image_name\"\n> >>>> +\n> >>>> +podman image inspect \"$container_image_name\"\n> >>>> +\n> >>>> +podman push --compression-format=gzip \"$container_image_name\"\n> >>>\n> >>> If running on FDO, why do you reimplement all this instead of using the\n> >>> CI templates ? And if not running on FDO, a Containerfile could be used.\n> >>\n> >> On a second look, it may be possible, although mapping between the docker\n> >> platform and debian architecture might be a bit inconvenient.\n> >>\n> >>> [...]","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 1F0A5C3220\n\tfor ;\n\tFri, 23 Jan 2026 14:45:53 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 5136B61FC4;\n\tFri, 23 Jan 2026 15:45:52 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A4CE8615B2\n\tfor ;\n\tFri, 23 Jan 2026 15:45:51 +0100 (CET)","from pendragon.ideasonboard.com\n\t(2001-14ba-703d-e500--2a1.rev.dnainternet.fi\n\t[IPv6:2001:14ba:703d:e500::2a1])\n\tby perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id 2C239103D; \n\tFri, 23 Jan 2026 15:45:18 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"arJ+5vbW\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1769179518;\n\tbh=ghZ0joaeEsYm458TUWMWnCHdsU+hQhuwBKIOZNwd9B4=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=arJ+5vbWF18F5Gpwr7eSYkXpEr+UHKoBGp4deZjmXSPSLWW/47Qydem+GnoIINhKw\n\tdpz+DJ9l43Iuq0/2/bV8deulZGYnOTC4Neaf6HGMoWhk2zrh+U21Om25tqLErqQz0n\n\thg7GncCNc18t9UsyDGnOepdwDE7kUOl/IsKi09iM=","Date":"Fri, 23 Jan 2026 16:45:50 +0200","From":"Laurent Pinchart ","To":"=?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= ","Cc":"libcamera-devel@lists.libcamera.org","Subject":"Re: [libcamera-ci] [RFC PATCH v1 3/5] Add job to build debian rootfs","Message-ID":"<20260123144550.GI215800@killaraus>","References":"<20260119102039.3521673-1-barnabas.pocze@ideasonboard.com>\n\t<20260119102039.3521673-4-barnabas.pocze@ideasonboard.com>\n\t<20260122022259.GC209830@killaraus>\n\t<25691548-d660-4151-8a38-500ae969f53f@ideasonboard.com>\n\t\n\t<20260122233054.GD215800@killaraus>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]