Just wondering the best way of keeping up with releases. I’m on Ubuntu, so that’s obviously not getting v3 until 2034 or whenever. The PPA looks retired. The SUSE download page has a number of releases but I’m not sure how often they’re updated. Am I better off just building from source myself? Are there likely to be any problems between releases in terms of file/db format changes? I’m interested in just tracking stable releases really. And I don’t mind having debug info available so that crashes/bug reports are more meaningful.
I use gentoo so for me it’s just emerge darktable and I’m done 
any updates i just do emerge --sync && emerge -uDN --with-bdeps=y @world and I’ll have newest versions of all installed apps
Regarding building - there’s no problem there. You can set build target as RELEASE and that will strip unnecessary debugging info. Your only job will be then to keep your repo on the stable tag (preferably update every tag update and you’ll be fine). You can also track stable branch, which currently is 3.0.x
2 Likes
I build from source for both the stable and the development version(s).
For the stable version I use the official tarball that can be found in the GitHub release article, which would be darktable-3.0.1.tar.xz atm.
For the development version I use the master branch to pull or clone the latest version. This I do every morning.
About building from source: The one thing that might be a one time frustration is making sure that all the dependencies (both required and/or optional) are present on your machine. I see that as part of the fun, but others might have a different opinion.
If you are new to this: Keep it simple at first and follow the guide that’s on the darktable install page.
I haven’t come across problems when building newer versions, be it stable or development.
2 Likes
Thanks. I’m more interested in using git than downloading tars as it’s surely easier to keep them up to date. Is “development” the master branch, and “stable” any tag (such as 3.0.1)?
the git builds are triggered by github so they are basically up2date when ever git changes.
for the stable package … it depends on when @asn has time to update them.
1 Like
I’m on Arch Linux. I have the official pacman version (just got 3.0.1) and I compiled my own git version (which I now have to continue to use because I updated my database )
But what constitutes stable? I don’t want a package; I want to clone then pull from git. There’s no stable branch, so is the concept of a “stable” commit “any commit with a tag that doesn’t have rc as part of the name”?
Basically: The tarball I pointed to in my previous reply are the stable versions and the ones you clone or pull from github are the development versions.
You can also look at the version number: an even minor number is a stable releae (3.0.1 or 2.6.3) and an odd minor number is a development version (3.1.0 or 2.7.0)
You mention wanting to be up-to-date: The development branch is the latest, but might have problems (this being development). It is not a rolling-release that pumps out stable versions!
This quote from the darktable install page I pointed to:
First a word of warning: Using the development version of darktable might be risky in that it can break anytime, kill your edits, eat your kittens or do other nasty things. It is also not guaranteed that XMP sidecars written by a development version will work with a release version. It is also quite certain that any older version of darktable will NOT be able to read the database once a development build updated it to the latest schema. So for your own safety and our sanity, do make backups of your XMP files as well as your library.db and data.db (by default it is in ~/.config/darktable/)
1 Like
I install from flatpak or nixpkg.
1 Like
the 3.0 branch is the current stable branch.
1 Like
I am also on Arch. At the moment I just use the the 3.01 version from the standard distribution repository. Before the stable release of darktable 3, there were many new features emerging in the development versions. At that time I installed the git version via the AUR.
Got it. Thanks everyone. For now I’m going to pull only tagged commits from the stable branch “darktable-3.0.x”, but I might knock up a VM and get the very latest commits from the dev branch “master” to have something to play with if there’s a crash/anything to report. (Seems like a few Arch users here so might give that a try).
1 Like
There are packages for the stable branch, for the master branch and for release tarballs.
What more do you need?
Its a bit off-topic here but in last days I’m getting this error message:
W: Fehlschlag beim Holen von http://download.opensuse.org/repositories/graphics:/darktable/xUbuntu_18.04/InRelease Die folgenden Signaturen waren ungültig: EXPKEYSIG 040524A84C70D8B5 graphics:darktable OBS Project <graphics:darktable@build.opensuse.org>
Some signatures are not valid any more.
1 Like
the key was refreshed. in doubt you have to reimport it
I don’t need anything else, do I? I wasn’t after a package - I wanted to know how to get the source via git so I could pull and build whenever a new stable commit was announced.
Am I doing something wrong?
s7habo@s7habo-System-Product-Name:~$ wget -nv https://download.opensuse.org/repositories/graphics:darktable:stable/xUbuntu_18.04/Release.key -O Release.key
2020-03-10 21:15:41 URL:https://download.opensuse.org/repositories/graphics:/darktable:/stable/xUbuntu_18.04/Release.key [1114/1114] -> "Release.key" [1]
s7habo@s7habo-System-Product-Name:~$ apt-key --keyring Release.key finger
/tmp/apt-key-gpghome.e7wY9U5ZRj/Release.key.gpg
-----------------------------------------------
pub rsa2048 2017-12-26 [SC] [verfallen: 2020-03-05]
3247 B751 9EDB EAB4 22E9 00A3 0405 24A8 4C70 D8B5
uid [ verfallen] graphics:darktable OBS Project <graphics:darktable@build.opensuse.org>
Bdw, key from master branch works 
maybe we have to make the stable and release package to be updated and then it will be published again. all distros should be republished now and have the new key.
3 Likes
Thanks. I built it without too much difficulty yesterday. Oddly, I initially tried setting the 3.0.x branch back to the commit tagged with release-3.0.1 and got an error when I tried to run it. Using the head of that branch was fine.