[Buildroot] [PATCH] package/libcamera: Bump to version 0.0.3

Thu Jan 26 13:34:35 UTC 2023

On Tue, Jan 24, 2023 at 11:52 AM Kieran Bingham
<kieran.bingham at ideasonboard.com> wrote:
>
> Quoting Quentin Schulz via buildroot (2023-01-23 13:25:52)
> > Hi Kieran,
> >
> > On 1/23/23 12:58, Kieran Bingham wrote:
> > > Quoting Quentin Schulz via buildroot (2023-01-23 10:57:16)
> > >> Hi Daniel,
> > >>
> > >> On 1/19/23 15:34, Daniel Semkowicz wrote:
> > >>> Libcamera recently started to version the software, so use the
> > >>> version tag instead of raw commit hash.
> > >>>
> > >>> Signed-off-by: Daniel Semkowicz <dse at thaumatec.com>
> > >>> ---
> > >>>    package/libcamera/libcamera.hash | 2 +-
> > >>>    package/libcamera/libcamera.mk   | 2 +-
> > >>>    2 files changed, 2 insertions(+), 2 deletions(-)
> > >>>
> > >>> diff --git a/package/libcamera/libcamera.hash b/package/libcamera/libcamera.hash
> > >>> index 68c9c1f005..033e318910 100644
> > >>> --- a/package/libcamera/libcamera.hash
> > >>> +++ b/package/libcamera/libcamera.hash
> > >>> @@ -1,4 +1,4 @@
> > >>> -sha256  59318208a9c1b183cacaf5a7175568d8a9fa094f2dd8c9794269bb6e9636986e  libcamera-ba6435930f08e802cffc688d90f156a8959a0f86-br1.tar.gz
> > >>> +sha256  d7100286616550aca487b46ae9de2a70bb471352a332b8214901b4148739990f  libcamera-v0.0.3-br1.tar.gz
> > >>>
> > >>>    # license files
> > >>>    sha256  fd38b2c053c0cce46d9c5ef3545a6e34d157a240ba99c9b8dca5d37a8147da6c  LICENSES/BSD-2-Clause.txt
> > >>> diff --git a/package/libcamera/libcamera.mk b/package/libcamera/libcamera.mk
> > >>> index 9c03d3a3b3..8979a43aca 100644
> > >>> --- a/package/libcamera/libcamera.mk
> > >>> +++ b/package/libcamera/libcamera.mk
> > >>> @@ -5,7 +5,7 @@
> > >>>    ################################################################################
> > >>>
> > >>>    LIBCAMERA_SITE = https://urldefense.com/v3/__https://git.linuxtv.org/libcamera.git__;!!OOPJP91ZZw!gtcDP1maf3PoJO88myqzbBZyOhNYHg7g4jGwno19jy5tFEHRgUuyBqm2zECw5wQOF6S4k8pRivumP5qJXTknCnAEvbE$
> > >>> -LIBCAMERA_VERSION = ba6435930f08e802cffc688d90f156a8959a0f86
> > >>> +LIBCAMERA_VERSION = v0.0.3
> > >>
> > >> I would actually advocate against using git tags, they are not
> > >> guaranteed to be stable over time (one can remove or move a tag), as
> > >> opposed to a git hash which is guaranteed to be.
> > >>
> > >> Can you use the commit hash please?
> > >
> > > Tags seem more convenient to me! - If you're not going to use the tag
> > > points, why am I bothering to make tagged releases? I could go back to
> > > just saying 'always use master as the latest release' if SHA1's are the
> > > release point.
> > >
> >
> > git tags aren't necessarily related to software releases, they just
> > happen to be. You could very well have releases without git tags though
> > that makes it quite difficult to know when a new release is out or to
> > know which commit exactly is a "release".
>
> Indeed, they're convenient, and at least 'signed' to verify too.
>
> > Just FYI, git tags are not allowed in Yocto officially maintained
> > layers. This has something to do with Yocto enforcing tag re-fetching,
> > thus requiring network access, breaking the ability to build offline.
>
> Ah I wasn't aware of that. I'm not sure I've seen much traffic from
> Yocto packaging libcamera recently though. Not through my inbox anyway.
>
>
> > > While, yes - tags can be deleted. I expect that any signed-by-me tag (or
> > > any other future libcamera release maintainer) is the correct tag for
> > > that release point. I would not expect to delete any tag once pushed to
> > > a public host.
> > >
> >
> > Expectations vs reality. People do all kinds of weird stuff. I was not
> > specifically talking about tag deletion but tag being moved. git hashes
> > aren't spared the deletion issue either (e.g. force-push to the git
> > branch). Considering I've seen this happen before, it's not an
> > hypothesis (that was a proprietary downstream project though). While I
> > appreciate with your experience with upstream projects you would know
> > that moving tags is really a bad idea, I was merely just pointing out a
> > pitfall of using git tags for builds that most people would like
> > reproducible.
>
> I understand. I'd happily state that for libcamera, we expect a
> (release) tag to be constant and immutable.
>
>
> > >> @Kieran: do you have manually generated tarballs for versions somewhere
> > >> so we could use this instead of a git repo?
> > >
> > > Do other projects honestly create manually generated tarballs?
> > >
> >
> > I was just asking if there was one already available. I was not
> > requesting one :)
>
> It's a recurring question though.
>
> So it turns out cgit /can/ provide these, but we must have it disabled.
> It might be feasible to enable it - but these will be unsigned.
>
> > > As in ... does the maintainer create a .tgz and scp it somewhere or some
> > > such?
> > >
> > > I would expect this can all be handled by git... - in particular, IMO -
> > > the signed tags I push are what I expect to be possible to validate and
> > > verify. Is it that the core issue here is that cgit isn't providing a
> > > tarball?  (while Github does?)
> > >
> >
> > Buildroot validates the sources it gets anyways with the hash. So moving
> > the tag will break the builds on systems where the repo is not already
> > in cache in BR2_DL_DIR.
>
> Yes, I would expect the existing validation to prevent it going
> unnoticed, so I don't think I see any specific issues, (other than the
> below...)
>
> I expect that it's the responsibility of whomever does the update to
> validate that the release is correctly signed?
>
> > Yocto has a strict requirement on automatically generated tarballs,
> > GitHub being one the tools generating them. Try to contribute a package
> > using GitHub archives/releases and I can guarantee you one of the first
> > comments you'll receive is that they don't want it, use git hashes
> > instead. Now, I see that Buildroot does not have the same restriction
> > since the github function is used to fetch releases. c.f. `git grep -A1
> > -B1 "_SITE.*github" | grep "tar\.` for a list of impacted packages, and
> > https://git.busybox.net/buildroot/tree/package/pkg-download.mk#n63 for
> > the implementation.
> >
> > AFAIR, it has to do with tarballs sometimes being recreated in the
> > future and, depending on the tool being used by GitHub or whatever, the
> > checksum changes (e.g. tarball creation date somewhere in the headers,
> > tarball tool version number in there, you name it, ...), breaking old
> > trees/projects.
>
> I can see how 'automagically' generating tarballs like this could be an
> issue. Changing the compression ratio or other internal parameters
> perhaps would then create a checksum failure.
>
> That would be caught by buildroot of course, and would require
> re-autheniticating / validating that the source is from the correctly
> signed release.
>
>
> > The issue in Buildroot is that the tag won't be re-fetched (while
> > re-fetching is enforced in Yocto for example), so you might have two PCs
> > building different git hashes because someone moved the tag upstream in
> > -between builds, c.f. the docs:
> > """
> >       due to local caching, Buildroot will not re-fetch the repository,
> > so people who expect to be able to follow the remote repository would be
> > quite surprised and disappointed;
> >      because two builds can never be perfectly simultaneous, and because
> > the remote repository may get new commits on the branch anytime, two
> > users, using the same Buildroot tree and building the same
> > configuration, may get different source, thus rendering the build non
> > reproducible, and people would be quite surprised and disappointed.
> > """
> >
> > The first mail was just out-of-habit with what usually happens when
> > reviewing recipe patches on the Yocto ML. I understand that Buildroot
> > works differently and git tags may be enough for you/Buildroot maintainers.
>
> At the moment, I plan to provide signed-git-tags. It's up to the
> distributions and builders from there ;-)
>
> As long as things can be mostly automated, I don't mind doing extra
> steps, but they need some justification, so that I'm not doing manual
> processing to support debian/fedora/buildroot/yocto/arch/everyone else
> separately.
>
> --
> Kieran

Hi,

I looked through other buildroot packages that use git as the fetching
method and it looks it is common to use git tags if available.

I understand it is usually better to limit the number of assumptions
in the system to lower the risk of error, but it also usually comes with
lowered comfort. As this practice is already widely used in the
buildroot, I would go for more convenience and prefer to use tag instead
of the commit hash in this case.

Best regards
Daniel Semkowicz