dt unknown-version? ["solved" -- sort of]

[Claes]

/opt/darktable/bin/darktable --version
this is darktable unknown-version

darktable-git, arch linux

What has happened?
What have I missed?

Have fun!
Claes in Lund, Sweden

[elstoc (Chris E)]

It’s hard to know, since you haven’t told us what you did

[Claes]

Standard get source from github,
standard compile and install, which has
worked fine for more than a year…

om ändringar equals if any changes.

[afre (Alan)]

Which commit, etc.? The more details the better.

[priort (Todd Prior)]

can’t you just click on the logo to confirm…or is it unknown as well ??

[Claes]

@priort That is unknown, as well:

@afre current master

[kmilos]

Looks like something went wrong with your git clone, and both attempts to get the revision or commit hash failed…

[Claes]

Agree…
And the “unknown-version” seems to be set in CMakeLists.txt:

set(PROJECT_VERSION “unknown-version”)

That file also contains two FIXMEs:

FIXME: PROJECT_VERSION will not be updated automatically, until you rerun cmake

FIXME: (irrelevant) PROJECT_VERSION will not be updated automatically, until you rerun cmake but generate_version target expects it to be in build dir, so we need to copy it

[kmilos]

Before all that, please post the output of ./tools/get_git_version_string.sh and the two git describe commands in it.

[Claes]

Thank you, @kmilos,
Here are the three replies:

sh get_git_version_string.sh
3.9.0+1071~gd8f9de0b1

git describe --tags --dirty
release-3.9.0-1071-gd8f9de0b1

git describe --always --dirty
release-3.9.0-1071-gd8f9de0b1

[kmilos]

Ok, that eliminates the shallow git cloning issues…

I’d start w/ a clean slate then by rm -rf build (or add the --clean-build -f option to your build command line above, perhaps even --clean-all -f).

[Claes]

Thank you.
a) I removed everything in my source folder, everything in /opt, and .config/darktable and .cache/darktable

b) git-cloned master branch and compiled again.

Result:
Unknown-version. (Both as a result from --version and from clicking the logo.)

sh get_git_version_string.sh
3.9.0+1073~g981c390a9

git describe --tags
release-3.9.0-1073-g981c390a9

git describe --always --dirty
release-3.9.0-1073-g981c390a9

Sincerely,
Claes in Lund, Sweden

[kmilos]

Next thing I guess is to insert some message("I''m here") commands into that big if-else block of CmakeLists.txt to try to figure out which case you end up in… Don’t forget to comment out the build and install lines in build.sh, you don’t need to go that far, you just want to see the debug messages during the configuration step, and verify the generated version_gen.c

[Claes]

The problem is solved.
Actually, not “solved”, but circumvented, because I still do not know the reason for the dilemma. My “solution” was to install a brand new OS onto an empty SSD.

So from now on, I am running Debian 11 instead of Garuda Linux.

Have fun,
Claes in Lund, Sweden

[paperdigits (Mica)]

Well the wallpaper is awesome, so you have that going for you.

[pehar]

The issue is related to a security update of git on Ubuntu 20.04. It has been announced 12 april 2022 (Git security vulnerability announced - The GitHub Blog). A new configuration parameter has been introduced (from Git - git-config Documentation) :

safe.directory

These config entries specify Git-tracked directories that are considered safe even if they are owned by someone other than the current user. By default, Git will refuse to even parse a Git config of a repository owned by someone else, let alone run its hooks, and this config setting allows users to specify exceptions, e.g. for intentionally shared repositories (see the --shared option in git-init[1]).

This is a multi-valued setting, i.e. you can add more than one directory via git config --add. To reset the list of safe directories (e.g. to override any such directories specified in the system config), add a safe.directory entry with an empty value.

This config setting is only respected when specified in a system or global config, not when it is specified in a repository config or via the command line option -c safe.directory=<path>.

The value of this setting is interpolated, i.e. ~/<path> expands to a path relative to the home directory and %(prefix)/<path> expands to a path relative to Git’s (runtime) prefix.

For me the issue is solved adding

sudo git config --global --add safe.directory /home/user/darktable/master

before

sudo cmake --build "/home/user/darktable/master/build" --target install -- -j12

where /home/user/darktable/master is the location of the git clone of darktable master.

[criadoperez]

Thank you @pehar for this solution! It works great!

[Till80 (Till)]

With Ubuntu 22.04 I ran now into the same problem and tried the steps described above and on darktable reports "unknown version" · Issue #11542 · darktable-org/darktable · GitHub. But still DT states “unknown version”. For compiling I used
./build.sh --prefix /opt/darktable --build-type Release --install --sudo
after running
sudo git config --global --add safe.directory /home/till/git/darktable

EDIT:
When running ./build.sh without ‘–install’ and then checking ‘./build/bin/darktable --version’ shows the correct version, but after running installation by
‘sudo cmake --build “/home/till/git/darktable/build” --target install – -j16’
‘/opt/darktable/bin/darktable --version’ shows ‘unknown-version’.

Did you observed similar behavior recently?

Thanks for your help!
Till

[pehar]

This is how I build / install :

cd /home/user/darktable/master
git pull https://github.com/darktable-org/darktable.git
cd build
sudo make clean
cd ..
git submodule init
git submodule update
./build.sh --build-type Release |& tee ../build.log
sudo mv /opt/darktable /opt/darktable-3.9.0-previous-version
sudo git config --global --add safe.directory /home/user/darktable/master
sudo cmake --build "/home/user/darktable/master/build" --target install -- -j12

and this still works on Ubuntu 20.04.

[Till80 (Till)]

Thanks, pehar! I am not sure, if the reason was that I had a final ‘/’ in my path when adding the safe directory, but it works now.