I posted up some build details a while back, these might (or might not) help you.
You can build R&Dt by following the Master process, but cloning the location you’re already using rather than the mainstream git location. You can have various independent builds of dt/R&Dt if you wish.
Are you sure you’ve built R&Dt? Was that your intention? I think by using the 3.8.1 tag you’ve built mainstream dt of that version. Or am I misunderstanding something? Have another look at the README in Aurelien’s github.
Thanks. I’ll take a look through: trying to learn more about this and not just “copy/paste” as I have done in the past. I’ll like to help as a tester for both this fork as well as the “VKDT” project that is coming down the pike, but I’m of no help if I can’t get things built.
I think I understand what you mean.
I’m pretty sure: the logo when you are in is changed to R&Darktable (with the Red A), and I have access to the Filmic V6, spot metering and spot color matching…
No, my intention was to build the R&Dt fork.
I don’t know why I have that tag in there. I will try building without it and see what happens and re
I was following the build instructions on the R&Dt readme.
To get things working as well as i did, I had to change the git call to the R&Dt repository and not the one listed on Aurelien’s readme
I think after his introduction to R&Dt Aurelien just copied the build instructions for 3.8.1 in his readme, thinking people that knew what they were doing would just change what is needed. It proves that I don’t know what I am doing… yet
Also, I would put this issue up on the github, but… I don’t know how to do this either. Lots to learn. Again, the good news for me in this is it will force me to learn these processes, something I have wanted to do, but always yeilded to other ways to get current Dt on linux.
Thanks for your suggestions: I’ll check out your build instructions, compare and contrast to what I was doing, and will report back.
git clone will use the name of the repo to create the directory, so it’ll check the code out to R-Darktable, not to darktable. So your cd darktable command is wrong; it should be cd R-Darktable.
You should not be building the release-3.8.1 tag, but the master branch, or the dev branch: git checkout master or git checkout dev, and then refresh it from time to time using git pull.
I came across this on AP’s Github repo as a comment…
" PS: For anyone using GNU Guix as a distro or package manager, I was able to build this fork with guix build darktable --with-git-url=darktable=https://github.com/aurelienpierre/R-Darktable or even better, run it directly with guix shell darktable --with-git-url=darktable=https://github.com/aurelienpierre/R-Darktable -- darktable . It just works."
It built with the same as before and I’ll still getting the same issue with creating an “icon” and letting my system know that darktable is a program:
I received the same error:
I’m open to suggestions, but for now, I’ll try using the Guix package manager, per @priort (and AP)… but I would like to know how to do this, if not for anything else, for pride…haha
The file in /usr/share/applications/darktable.desktop belongs to some package installed via your distro’s package manager. Don’t overwrite such files, or you’ll risk conflicts (e.g. when you remove or upgrade the package that originally provided the file, it’ll be removed or overwritten again).
You don’t need to put the .desktop files under /usr/share/application.
Personally, I run darktable and R-Darktable from the command-line, since when running dev versions, the debug output may come handy.
See here or use your favourite search engine with ‘linux how to use desktop files’:
This was reported for 4.0 on FB…I asked for the poster to check the coefficients…they don’t change so its just changing it to custom for some reason but I think there is no change in the wb at least that was what was reported in response to my query back to the poster there…
I installed it from Arch and it works perfectly. First I had download from git and compiled it from scratch but it did not seem to run smoothly on my laptop so I deleted it and went with the Arch version which worked perfect so I’ll go with this for now.
I know it would install in its default location but where is that on your system? I currently have rdarktable installed into /opt to allow concurrent running of both stock dt4.0 as well as rdarktable
The AUR package will install rdarktable into /usr/ and will remove the official darktable package if installed.
This is mainly because the author of R&Darktable hasn’t taken steps to make it coexist nicely with the official darktable release. For example, the main executable is called “darktable” for both the official application and the rdarktable fork. So, for now the rdarktable package is mutually exclusive with darktable.
That’s not say you can’t install one package in the official location, and then compile and install the other package in a different place such as /opt, as long as you invoke the manually installed instance with the correct path and command line options to set the config directory etc… What I personally do is install rdarktable with pacman and use this as my daily driver, then I clone, build and install the official darktable dev release into a separate development area so I can play with it if I want to keep track of the main project or work on any bugs.
When you look at AUR, the version will show whatever release was current when the rdarktable-git package was submitted, but when you come to install it, it will actually download the latest dev version of R&Darktable from the master branch (as is the normal practice for packages ending in “-git” in AUR). When/if Aurélien produces a stable release of R&Darktable, I’ll create a “stable” rdarktable package in AUR. But for now, rdarktable-git just installs the latest dev version.
That’s not say you can’t install one package in the official location, and then compile and install the other package in a different place such as /opt, as long as you invoke the manually installed instance with the correct path and command line options to set the config directory etc… What I personally do is install rdarktable with pacman and use this as my daily driver, then I clone, build and install the official darktable dev release into a separate development area so I can play with it if I want to keep track of the main project or work on any bugs.
Thanks, Matt! That’s exactly what I ended up doing. I even created a separate Desktop file and icon in my taskbar. The rdarktable one has this as “application” in its desktop file:
/opt/R-Darktable/bin/darktable --configdir /home/mike/.config/r-darktable %U
I thought there might have been a change I missed in the meantime (or overlooked) but this seems to be working perfectly OK for now.
I never install self-built experimental software under /opt: since I’m the only one using them, they go in subdirectories under my home: /home/kofa/darktable-master/ and /home/kofa/r-n-darktable-master, for example. This way:
there is no way they overwrite each-other’s application files (caches and config I still have to deal with);
I don’t need sudo and I don’t risk accidentally damaging files managed by my operating system.
I do the same – it also means you can conveniently delete the whole installation directory to make sure there are no stale files hanging around from previous builds before reinstalling (eg. obsoleted opencl kernels)
