Wrong version reported by --version option

[dwrobel]

The --version option report wrong version:

$ libcamera-jpeg --version
libcamera-apps build: 81925eccaf76 11-10-2021 (17:11:09)
libcamera build: v0.0.0+1-c1d703c3

The correct versions are:

$ rpm -qv libcamera-apps
libcamera-apps-0.0.0-0.7.20211011git0ddf74f.fc34.armv7hl
$ rpm -qv libcamera
libcamera-0.0.0-0.11.20211009gitfa7a95b.fc34.armv7hl

which translates to:

• libcamera-apps@0ddf74f
• libcamera-org/libcamera@fa7a95b
  respectively.

The problem comes from the fact that the RPM build system (but it applies to many other build systems) fetches tarball based on the gitsha from github and such a tarball is then converted to git repository where other local patches can be easilly applied.

Please note, that the git repository created by the build system does not have any references to the original github repository (tarball does not convery git repository - see Source0 example below). Not to mention that when no patches are to be applied then the git repository might not be created out of tarball.

So, please consider to use other more reliable system for retrieving software version as the case that original git repository will be used is very uncommon for most linux distributions.

Example what I currently use for building libcamera-apps (source tarball + patch):

$ spectool -l libcamera-apps.spec 
Source0: https://github.com/raspberrypi/libcamera-apps/archive/0ddf74f1a0705961bc281eb4da914ec20ce6a671/libcamera-apps-0ddf74f1a0705961bc281eb4da914ec20ce6a671.tar.gz
Patch0: https://github.com/raspberrypi/libcamera-apps/pull/121.patch#/libcamera-apps-Do-not-override-CXXFLAGS-from-external-build-system.patch

[naushir]

Thanks for submitting this issue. I'm not really aware of how the library packaging in various distributions work, but this does seem like it might be quite problematic. The original intention of this feature was for us to get users to report the exact state of the libcamera-apps and libcamera trees for the builds if they had problems.

Running --version on the Raspberry Pi OS distribution binaries gives:

pi@pi4:~ $ libcamera-hello --version
libcamera-apps build: 000000000000 01-10-2021 (12:15:28)
libcamera build: v0.0.0

which implies that the source tree that the libraries were built from does not seem to be a git repo.

Given I know nothing about how all of this works on the disto side, I am not sure how to proceed. @XECDesign, we will probably need some guidance from you here, any thoughts?

[kbingham]

Yes, indeed that's why I originally wanted to get the version exposed by libcamera.
I wanted to be sure we could tie problems to exact commits. Let us know if there's anything we need to do to support this on the libcamera side.
But if a distro adds patches, or takes away the version information, I guess we simply can't provide it.

And of course, if built from a tar-ball - then there is no git log to capture the version / sha1 from - so we'd have to find another way to identify it anyway.

[XECDesign]

Right, debian packages are built from source tarballs which don't contain version control files in them. If you run apt policy libcamera-apps, the git hash and date are in the version numbers there.

I could patch it to do something different, like extract the version from debian/changelog at build time, but that wouldn't address it on other distros.

[dwrobel]

Basically at the build system there is an information about the version either in the form of tag or gitsha, it's just a matter of providing an option to pass that to cmake, meson, etc. Please consider to add a possibility to pass e.g. -DVERSION=\"version-string\" and if it is given then it should take precedence over the data from the local git repository.

[naushir]

Ok, having a version string passed in as a cmake variable sounds plausible. This string really wants to be the sha-1 of the top commit, and if no version string is passed, we do what we do right now.

@kbingham, would you consider a similar change for the libcamera library builds? Otherwise, libcamera will also report a version string of 0.0. I'd be happy to make the change and submit for review if you think that would be an acceptable approach.

[kbingham]

At least initially yes, I think letting us override the version at build time makes sense.

That means if the distro takes away our versioning, they are responsible for setting it again.
Worth a patch on the list to discuss it there anyway.

I expect Javier @ Redhat will have opinions too as he's recently been packaging libcamera RPMs.

[naushir]

With #124 now merged, this can be closed.