Yes, that did the trick. Had a little quirk in that flatpak version. I created a style so I could have lens correction enabled, saved it, selected all my photos and double clicked the style and it turned them all (well, 98% of them!) pink. Turns out the raw black/white point module had chosen strange values; setting them to the default fixed it. Then I ran from the source from git and this wasn’t a problem except for the ones I’d previously fixed by hand - resetting to the default values for that module again fixed the problem, but with different default values. Odd.
1 Like
Just to answer the starting question: I changed from Linux Mint to Debian Buster last year and use 3.0.2 from OBS.
Only one unexpected crash since I started using 3.0.x stable series around Feb. 2020.
Happy so far.
Will try do set up a second parallel install of master branch but still figuring out how to do this best from a maintenance point of view …
1 Like
There are some pretty good guides on the github darktable page now.
1 Like
Thanks - worked on this for the last few days - now I have dt 3.0.2 running from OBS and darktable master running from self compiled source.
Indeed the description is useful even for non-devs - as long as there aren’t too many or complex build-errors.
I use Manjaro/Arch … I get the latest dt git from the Arch repos. It installs without any know-how from myself. There is usually one update every day (sometimes two). I can simply ignore updates. Update takes less than one minute on my system. I find it very stable.
Exactly the same setup I use. Eventually when the Beta comes out I’ll switch to the OBS beta channel, because from the tests I done with the master version things feel stable and I really need the lighttable changes.
I’ve been building Darktable from GitHub source. It took a bit of dependency fighting to get it to compile. But now it does. Everytime I clone the source again.
I’m not always so lucky. I my workflow is geeqie->darktable->gimp. Gimp I still get from apt-get install and geeqie I haven’t succeeded in compiling yet. Too many library inconsistencies.
1 Like
Via snap or/and Flatpak. Also via obs for master branch, it would be better to have master snap channel or flatpak repo.
A flatpak of the master branch has been on my list of things to do.
6 Likes
I also use Manjaro/Arch linux. I clone the GitHub repository to my system, checkout the release label or branch I am interested in, and compile it. That way I know for sure what I’m getting, which is especially important if you are editing the same files from different systems (eg. have photos on a shared cloud drive, and sometimes edit from one Linux system or another, or even from my Mac).
I build from source on Ubuntu.
I have my compile scripts on Githup. Out of the box they compile darktable in a VM using multipaas. Once everything looks good, I use the script on my live system.
I have got myself a new desktop machine a few days ago - the 20.04 script is known good 
As 3.2.0 is not yet an official release, think about using the 3.2.0 branch just yet…
/Per
1 Like
Hi, @xyzzy. I always build from the source, after tweaking it a little. The source code is either a release or trunk some days before the release.
Is there a way to compile darktable without needing to use virtual machines etc? This is a bit beyond me I’m afraid! I suspect I’ll just need to wait until 3.2.1 packages are released for Ubuntu / Mint!
There are some good instructions on the github readme
1 Like
@elstoc, however the website listed on the readme, for installing missing dependencies, is coming up as a 502 bad gateway for me 
https://redmine.darktable.org/projects/darktable/wiki/Building_darktable_26
Yes redmine is down now but the dependencies are listed on github
1 Like
Ahah! https://github.com/darktable-org/darktable/wiki/Build-instructions-for-Ubuntu-18.04-to-20.04
Especially the tip about enabling source repository, then updating and running apt-get build-dep darktable to install all the required dependencies!
I am on Arch Linux and, until yesterday, I had been running 3.0.2 from the main Arch repository. But there was some stuff I wanted to do, but couldn’t do with 3.0, so I updated from the AUR. What I got was a development version of 3.3. The AUR makefile downloaded the source from GITHub and compiled it on my host.
I neglected to save my database, so I guess this is where I am. Luckily for me, everything seems to work.
I think 3.3 edits should still be compatible with 3.2 for the moment (very little new stuff has been added to 3.3 so far) so when 3.2 comes out on ArchLinux you could probably switch to that fairly easily (but backup first just in case).
1 Like
@elstoc, I need a little help, please.
Today, my distro got 3.2.1 into its main repository. So, I removed the 3.3 version from my system and installed 3.2.1. However, when I try to start it, a “wait” spinner appears for 10-15 seconds and disappears. My guess is that it doesn’t like the database.
I have backed up everything in ~/.config/darktable to a new directory. Can you suggest what I should do to get 3.2.1 to start? Here are the contents:
Aug 9 21:01 darktablerc
Aug 9 18:23 data.db
Aug 31 2017 data.db-pre-3.0.2
Aug 9 07:48 data.db-pre-3.3.0
Apr 24 2017 keyboardrc
Aug 9 18:23 keyboardrc_default
Aug 9 21:01 library.db
Aug 31 2017 library.db-pre-3.0.2
Aug 9 08:14 library.db-pre-3.3.0
As you can see, nothing has been updated since the last time I ran 3.3.0, last night.