darktable und das doppelte Lottchen

veröffentlicht am 07.07.2020 in * PROGRAMME * SOFTWARE *

Inhaltsverzeichnis

Auch das darktable-Projekt scheint ein Opfer der Corona-Pandemie 2020 zu sein: Die Entwickler sehen sich außer Stande, bis zum regulären Release-Termin zu Weihnachten mit der nächsten Hauptversion 3.2 zu warten und wollen diese schon im August veröffentlichen 😏. Und für die Neugierigen: Hier soll eine Anleitung folgen, wie man schon vor der offiziellen Veröffentlichung zum aktuellen Entwicklungsstand der neuen Version kommt, um damit “herumzuspielen”, ohne die “ernsthafte Arbeit” mit der stabilen Version zu gefährden.

update 01/2024: Aktualsierung: Seit der Version 4.4 von darktable ist die Installation aus dem Quelltext zumindest für den "Normalnutzer" nicht mehr so einfach. Die Nutzung des seitens des Projekts bereitgestellten AppImage (Artikel hierzu) umgeht das Problem.

In dieser neuen Version wird z. B. auch ein neues Modul Negadoctor kommen, das das bisherige Invertieren ergänzen soll, um eingescannte oder abfotografierte Farbnegativfilme zu bearbeiten.

=Bildbeschreibung=

Zwei Versionen von darktable nebeneinander betreiben

Anmerkung: es geht hier um den Betrieb von darktable unter Linux, genauer: Debian 10 (Buster)

Die Voraussetzungen

Für den produktiven Einsatz nutze ich stets die für meine Distribution erstellten Pakete über den Paketmanager. Nun soll also zusätzlich eine zweite Version von darktable für Tests oder Vergleichszwecke hinzuinstalliert werden (ohne die vorhandene Installation zu überschreiben!).

Um die hier genannten Voraussetzungen zum Betrieb zweier oder mehrerer verschiedener Versionen von darktable zu verstehen, ist die Kenntnis des Artikels zum Backup der darktable-Einstellungen hilfreich.
Wie dort erläutert, speichert darktable seine Anwendungsdaten

in zwei versteckten Verzeichnissen: ~/.config/darktable und ~/.cache/darktable
in .xmp-Sidecar-Dateien in den Verzeichnissen der Bilder

Die ausführbaren Programmdateien liegen bei Linux-Systemen in der Regel in Unterverzeichnisssen von /usr, also in der Regel /usr/bin, /usr/lib und /usr/share.

An keinem dieser Orte darf durch die Zweitinstallation “Schaden angerichtet werden”, es dürfen dort also keine Dateien überschrieben oder unbeabsichtigt modifiziert werden.

Lösungsansatz

Installation der ausführbaren Dateien

Hier kommen zwei Möglichkeiten in Betracht:

Installationspaket für das Betriebssystem aus dem Entwickler-Repositiory herunterladen und mittels
dpkg -i --root=/opt/darktable-master darktable_{Versionsbezeichnung}_amd64.deb
an einen anderen Ort installieren (Achtung: ungetestet)
Quellcode herunterladen und selbst kompilieren, dabei läßt sich der Installationspfad festlegen - dieses Vorgehen werde ich unten beschreiben.

Anwendungsdaten

Wenn man darktable aus dem Terminal startet, dann hat man die Möglichkeit, die Optionen --configdir und --cachedir zu benutzen, damit werden die Anwendungsdaten nicht in die Standard-Profilverzeichnisse gespeichert, sondern deren Orte können vorgegeben werden.
.xmp-Sidecar-Dateien
- In den darktable-Voreinstellungen läßt sich das Schreiben dieser Dateien verhindern, dann werden die Bearbeitungsschritte ausschließlich in der darktable-Datenbank gespeichert. Das mag für eine Testumgebung ausreichend sein, für das Produktivsystem würde ich nie auf das “Auffangnetz” der xmp-Dateien verzichten wollen.
- alternativ kann man auch ein paar Testdateien in ein eigenes Verzeichnis kopieren und nur dieses in der Testinstallation importieren und damit arbeiten.

Nachdem jetzt also geklärt ist, worauf zu achten ist und wie die Probleme gelöst werden können, kann’s losgehen:

darktable aus den Quelltext-Dateien “bauen”

Anmerkung 1: ich gehe hier von einem normalen Debian-System mit vollwertigem Root-Account aus. Wer ein sudo-System nutzt, muß die entsprechenden Befehle, die ich hier als root ausführe, eben entsprechend ergänzen.

Anmerkung 2: Grundsätzlich lassen sich alle Arbeiten mit normalen Benutzerrechten durchführen, solange das nicht ausdrücklich anders angegeben ist.

Die Entwickler haben eine recht brauchbare Anleitung geschrieben, an die ich mich hier angelehnt habe. Diese werde ich aber durch ausführliche Erläuterungen und auch Screenshots ergänzen, um die Materie für den “Nicht-Entwickler” (wie auch ich einer bin) etwas anschaulicher zu gestalten.

Notwendige Tools installieren

Um ein darktable aus dem Quelltext ‘bauen’ zu können, bedarf es einiger Entwickler-Tools wie Compiler etc., diese müssen zunächst auf dem Rechner installiert werden.

root@{rechnername}:~# apt-get build-dep darktable

Was da alles an Paketen kommt, das hab ich im Anhang gelistet.

Quelltext herunterladen

Wie schon geschrieben steht der Quellcode von darktable bei github zur Verfügung. Auf den eigenen Rechner kann er auf zwei möglichen Wegen gelangen, die ich nachfolgend beschreiben.

Als ersten Schritt muß aber ein Ort festgelegt werden, wohin dieser Quelltext zu kopieren ist. Ich lege dazu im Home-Verzeichnis (mit ~ abgekürzt) ein Unterverzeichnis github an, in dem ich für die einzelnen Projekte Unterverzeichnisse anlege, für darktable also:

~/github/darktable-org/

Quelltext als Archiv herunterladen

Auf der genannten Seite findet sich oben rechts ein grüner Button (1), der im unteren Teil des Aufklappfeldes die Option Download ZIP (2) anbietet.

Quelltext-Archiv per ZIP von github laden

Diese Methode empfehle ich nicht:

Das Quelltext-Paket ist groß
für jede Aktualisierung muß das komplette Quelltext-Paket neu geladen werden, auch wenn sich nur wenige Dateien von ein paar Kilobyte Größe geändert haben

Quelltext per git auf den Rechner kopieren

man installiert sich git auf dem Rechner:

 root@{rechnername}:~#  apt install git

im zweiten Schritt kopiert man sich den Link im Aufklappfeld auf der github-Seite (2)

wechselt als normaler Benutzer mit dem Terminal in das Verzeichnis ~/github/darktable-org/ und gibt dann den Befehl ein:
```
 $ git clone {kopierte Adresse (2)}
```
hier also ganz konkret:
```
 {benutzername}@{rechnername}:$ cd ~/github/darktable-org/
 {benutzername}@{rechnername}:~/github/darktable-org/$ git clone https://github.com/darktable-org/darktable.git
```
und wartet dann einige Zeit, bis der Quelltext komplett in dem angelegten Verzeichnis “angekommen” ist - er landet dort in einem Unterverzeichnis /darktable …
Vorteil: spätere Aktualisierungen sind ganz einfach.

Quelltext vorbereiten

Arbeitsverzeichnis erstellen

Als Benutzer wird ein Arbeitsverzeichnis /build erstellt

{benutzername}@{rechnername}:~/github/darktable-org/darktable/$ mkdir build/

und in dasselbe gewechselt:

{benutzername}@{rechnername}:~/github/darktable-org/darktable/$ cd build/

Kompilieren

Um ein Programm auf einem Rechner ausführen zu können, muß der Quellcode in maschinenlesbare Sprache übertragen werden. Dazu dienen die hier gelisteten Schritte:

Aufbereiten des Quelltextes durch Entfernen von Kommentaren, sowie z. B. Ersetzen von Macros in C.
Überprüfen der Syntax des Quelltextes, Verwendung Funktionen und globale Variablen
Übersetzen des Quelltextes in Assemblersprache
Übersetzen der Assemblersprache in Maschinencode - Bits und Bytes, Einsen und Nullen.
Zusammenfügen einer aus mehreren Quelltextdateien zu erstellenden ausführbaren Datei 1. Ausarbeiten, wie das Programm aussehen muss, damit der Lader zur Laufzeit des Systems dieses in den Speicher laden und ausführen kann.
Endgültiges Schreiben der ausführbaren Datei in das Dateisystem.

Die darktable-Entwickler verwenden hier CMAKE:

CMake ist eine quelloffene, plattformübergreifende Familie von Werkzeugen zum Erstellen, Testen und Paketieren von Software. CMake wird verwendet, um den Software-Kompilierungsprozess mit einfachen plattform- und compilerunabhängigen Konfigurationsdateien zu steuern und native Makefiles und Workspaces zu erzeugen, die in der Compilerumgebung Ihrer Wahl verwendet werden können.

Mangels besserer Kenntnisse führen wir hier also den von den Entwicklern vorgegebenen Befehl aus 😆 :

{benutzername}@{rechnername}:~/github/darktable-org/darktable/build$ cmake -DCMAKE_INSTALL_PREFIX=/opt/darktable/ ..

Es werden jede Menge Terminalmeldungen ausgegeben. Hier ist auf echte Fehler zu achten, bei mir war das beim ersten Mal

-- Looking for external programs
-- Found perl
-- Found intltool-merge
-- Found desktop-file-validate
-- Could NOT find LLVM (missing: LLVM_DIR)
-- Could NOT find LLVM (missing: LLVM_DIR)
-- Could NOT find LLVM (missing: LLVM_DIR)
-- Could NOT find LLVM (missing: LLVM_DIR)
-- Could NOT find LLVM (missing: LLVM_DIR)
-- Could NOT find LLVM (missing: LLVM_DIR)
-- Could NOT find LLVM (missing: LLVM_DIR)
-- Could NOT find LLVM (missing: LLVM_DIR)
CMake Warning at CMakeLists.txt:329 (message):
Could not find LLVM 3.9+

was sich durch

root@{rechnername}:~#  apt install llvm

beheben ließ.

In der Beschreibung der Entwickler wurde bereits auf die abschließende und gravierende Fehlermeldung verwiesen:

CMake Error at src/external/CMakeLists.txt:15 (message):
RawSpeed submodule not found. You probably want to run:

$ git submodule init

and then

$ git submodule update


-- Configuring incomplete, errors occurred!

und wie in der Beschreibung und auch der obigen Terminalausgabe erwähnt, beheben die beiden folgenden Befehle das Problem:

{benutzername}@{rechnername}:~/github/darktable-org/darktable/build$ git submodule init
{benutzername}@{rechnername}:~/github/darktable-org/darktable/build$ git submodule update

Rawspeed ist der RAW-Decoder, der in darktable verwendet wird. Der Quelltext wird zwar auch auf dem darktable-github-Account, aber in einem separaten Submodul, entwickelt und muß daher auf diese Weise eingebunden werden.

Als nächstes muß dann ausgeführt werden (man erhält wiederum viele Ausgabezeilen):

{benutzername}@{rechnername}:~/github/darktable-org/darktable/build$ make

Ist dieser Befehl beendet, können die ausführbaren Dateien erstellt werden.

‘Binary’ erstellen und installieren

Auch hier gibt es zwei mögliche Vorgehensweisen:

Einfache direkte Installation

Zunächst muß root in dasjenige Benutzerverzeichnis wechseln, in dem die vorbereiteten Dateien liegen:

root@{rechnername}:~# cd /home/{benutzername}/github/darktable-org/darktable/build

und dort die Installation anstoßen:

root@{rechnername}:/home/{benutzername}/github/darktable-org/darktable/build# make install

Diese Methode empfehle ich nicht aus den weiter unten beschriebenen Gründen.

Checkinstall: Installation mit Erstellung eines Pakets für den Paketmanager

Nutzt man stattdessen checkinstall, so bekommt man gleichzeitig ein Debian-Paket, das man dann auf anderen Rechnern installieren kann, ohne die ganze obige Prozedur durchführen zu müssen. Um auch hier noch auf root-Rechte verzichten zu können, lasse ich nur das Installationspaket erstellen, das ich dann im Anschluß selbst manuell per Paketmanager installiere.

{benutzername}@{rechnername}:~/github/darktable-org/darktable/build$ checkinstall -D --install=no make install

checkinstall 1.6.3, Copyright 2010 Felipe Eduardo Sanchez Diaz Duran
  Diese Software wurde unter der GNU GPL veröffentlicht


The package documentation directory ./doc-pak does not exist. 
Should I create a default set of package docs?  [y]: n

Bitte geben Sie eine Beschreibung für das Paket ein.
Beenden Sie Ihre Beschreibung mit einer leeren Zeile oder EOF.
>> Entwicklerversion von darktable
>> 

*****************************************
**** Debian package creation selected ***
*****************************************

Das Paket wird entsprechend dieser Vorgaben erstellt:

0 -  Maintainer: [ {benutzername}@{rechnername} ]
1 -  Summary: [ Entwicklerversion von darktable ]
2 -  Name:    [ darktable-master ]
3 -  Version: [ 20200628 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ graphics ]
7 -  Architecture: [ amd64 ]
8 -  Source location: [ build ]
9 -  Alternate source location: [  ]
10 - Requires: [ libc6 (>= 2.27), libcairo2 (>= 1.14.0), libcolord-gtk1 (>= 0.1.20), libcolord2 (>= 1.4.3), libcups2 (>= 1.7.0), libcurl3-gnutls (>= 7.56.1), libexiv2-14 (>= 0.25), libgcc1 (>= 1:4.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.39.4), libgomp1 (>= 4.9), libgphoto2-6 (>= 2.5.10), libgphoto2-port12 (>= 2.5.10), libgraphicsmagick-q16-3 (>= 1.3.5), libgtk-3-0 (>= 3.22), libilmbase23 (>= 2.2.1), libjpeg62-turbo (>= 1.3.1), libjson-glib-1.0-0 (>= 0.13.2), liblcms2-2 (>= 2.2+git20110628), liblensfun1 (>= 0.3.2), liblua5.3-0, libopenexr23, libopenjp2-7 (>= 2.0.0), libosmgpsmap-1.0-1 (>= 1.1.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpng16-16 (>= 1.6.2-1), libpugixml1v5 (>= 1.6), librsvg2-2 (>= 2.14.4), libsecret-1-0 (>= 0.7), libsoup2.4-1 (>= 2.47.4), libsqlite3-0 (>= 3.6.0), libstdc++6 (>= 5.2), libtiff5 (>= 4.0.3), libwebp6 (>= 0.5.1), libx11-6, libxml2 (>= 2.7.4), libxrandr2 (>= 2:1.2.99.3), zlib1g (>= 1:1.2.0), libjs-prototype, libjs-scriptaculous, fonts-roboto, iso-codes ]
11 - Recommends: [  ]
12 - Suggests: [  ]
13 - Provides: [ darktable-master ]
14 - Conflicts: [  ]
15 - Replaces: [  ]

Geben Sie die betreffende Nummer ein, um die Vorgaben zu ändern: 

Installing with make install...

====================== Installations-Ergebnisse ==========================
[  0%] Updating version string (git checkout)
Version string: 3.1.0+2383~gc9ca6258d
[  0%] Built target create_version_gen
[  0%] Built target generate_version
...

Angepaßt habe ich dabei die Zeilen 1, 2, 6, 10 (hier habe ich die Abhängigkeiten der aktuellen stabilen Version übernommen) sowie 13.

Es folgen wieder “endlos viele” Ausgabezeilen und wenn am Ende diese Meldungen erscheinen

Some of the files created by the installation are inside the home directory: /home

You probably don't want them to be included in the package.
Soll ich diese Dateien anzeigen? [n]: n
Soll ich sie aus dem Paket ausschließen? (yes ist hier eine gute Idee) [n]: y

Kopiere Dateien in das temporäre Verzeichnis...OK

Stripping ELF binaries and libraries...OK

Komprimiere man-Seiten...OK

Erzeuge Datei-Liste...OK

Erstelle Debian-Paket...OK

ANMERKUNG: Das Paket wird nicht installiert

Lösche temporäre Dateien...OK

Schreibe Sicherungs-Paket...OK

Lösche temporäres Verzeichnis...OK

Wichtig ist hier die Bemerkung ANMERKUNG: Das Paket wird nicht installiert: Aufgrund des Parameters --install=no des Befehls checkinstall soll ja nur ein Paket erzeugt werden, ohne dieses aber direkt zu installieren (dies würde mit normalen Benutzerrechten ohnehin scheitern) - dies ist also die Bestätigung, daß es genau wie geplant gelaufen ist.

Wenn dann diese Meldung erscheint:

**********************************************************************

 Done. The new package has been saved to

 /home/{benutzername}/github/darktable-org/darktable/build/darktable-master_20200628-1_amd64.deb
 You can install it in your system anytime using: 

      dpkg -i darktable-master_20200628-1_amd64.deb

**********************************************************************

dann wurde das Installationspaket erfolgreich erzeugt.

Das erstellte *.deb im aktuellen Verzeichnis (also .../build) kann dann lokal installiert werden:

=Bildbeschreibung=

und mit der Bestätigung

=Bildbeschreibung=

kommen wir zum nächsten Schritt:

Der Beweis

Es sind tatsächlich beide Versionen nebeneinander installiert und werden vom Paketmanager auch unabhängig erkannt:

{benutzername}@{rechnername}:~$ dpkg -l | grep darktable
ii  darktable          3.0.2-1.1    amd64    virtual lighttable and darkroom for photographers
ii  darktable-master   20200628-1   amd64    Entwicklerversion von darktable

darktable einrichten und starten

Start aus dem Terminial

Gestartet wird darktable master dann mit dem folgenden Befehl:

{benutzername}@{rechnername}:~/github/darktable-org/darktable/build$ /opt/darktable-master/bin/darktable --configdir "~/.config/darktable-master"  --cachedir "~/.cache/darktable-master"

Start vom Desktop oder aus dem Menü

Der obige Terminal-Befehl kann auch in einen Starter für den Desktop eingetragen werden

=Bildbeschreibung=

und auch ein Eintrag im Startmenü läßt sich mit diesen Angaben anlegen:

=Bildbeschreibung=

Zweite Installation wieder entfernen

Methode `install`

Es ist im allgemeinen deshalb problematisch, ein Programm unter Umgehung des Paketmanagers zu installieren, weil es dann keine sauberen Routinen zum deinstallieren gibt. Niemand (außer den Entwicklern (hoffentlich!)) weiß, wo überall im System Veränderungen vorgenommen wurden.
Dieselbe Problematik tritt bei Aktualisierungen auf.

Das darktable-Entwicklerteam hat hier großen Wert auf Transparenz gelegt - es genügt hier, das in --prefix angegebene Verzeichnis /opt/darktable-master zu löschen.
Will man die Installation ganz “loswerden”, so müssen dann auch noch die selbst angelegten Starter und Menüeinträge händisch entfernt werden.

Methode `checkinstall`

Hier erfolgte die Installation über das Paketmanagement des Betriebssystems. Im einfachsten Fall kann man das wie hier gezeigt über gdebi erledigen:

=Bildbeschreibung=

Paket entfernen klicken … und gut ist 😄 …
… oder man benutzt dpkg oder Synaptik oder … der Möglichkeiten gibt es viele.

Aktualisierung der selbst gebauten zweiten Installation

Hierzu muß man - dank git- nicht wieder den kompletten neuen Quelltext herunterladen. Es genügt, eine Aktualisierung anzustoßen - für den Entwicklerzweig master mit dem folgenden Kommando:

{benutzername}@{rechnername}:~/github/darktable-org/darktable$ git pull origin master

In der Ausgabe sieht man dann schön dargestellt, ob und welche Dateien in der Zwischenzeit bearbeitet wurden (mit der Zahl der Änderungen darin):

{benutzername}@{rechnername}:~/github/darktable-org/darktable$ git pull origin master
remote: Enumerating objects: 28, done.
remote: Counting objects: 100% (28/28), done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 28 (delta 18), reused 19 (delta 12), pack-reused 0
Entpacke Objekte: 100% (28/28), Fertig.
Von https://github.com/darktable-org/darktable
 * branch                master     -> FETCH_HEAD
   54a0ddd6e..68cac8199  master     -> origin/master
Aktualisiere 40f2f94e3..68cac8199
Fast-forward
 po/fr.po                | 741 ++++++++++++++++++++--------------------
 po/ru.po                | 882 ++++++++++++++++++++++++------------------------
 src/develop/blend_gui.c |  10 +-
 src/iop/dither.c        |   2 +-
 src/iop/graduatednd.c   |  12 +-
 src/iop/vignette.c      |   2 +-
 6 files changed, 836 insertions(+), 813 deletions(-)

Ist der Quelltext aktualisiert, so kann man fortfahren wie im Abschnitt Quelltext vorbereiten beschrieben.

Wurde die vorherige Version direkt (nicht über den Paketmanager) installiert, so ist es ratsam, diese vor der Aktualisierung zu entfernen.

Kleiner Ausblick in die neue Version:

Als erstes fällt der neu gestaltete Leuchttisch auf, als zweites findet man ein ebenfalls neues Design des Voreinstellungs-Dialogs:

Bis einschl. Version 3.0.x fanden sich hier die Tabs für die Unterrubriken am oberen Rand (wo ihre Zahl begrenzt ist):

=Bildbeschreibung=

In der kommenden Version 3.2 finden sie sich am linken Rand untereinander, was eine bessere funktionelle Auf- und Zuteilung und damit bessere Übersicht erlaubt.

=Bildbeschreibung=

Was sich sonst noch alles ändert und verbessert? Das herauszufinden - dazu habe ich ja die Entwicklerversion zusätzlich installiert …
Übrigens: der oben erwähnte ‘Negadoctor’ verursacht zwar eine Lernkurve, die ersten Ergebnisse finde ich aber schon mal ganz gut.

Happy darktableing 😄 !

Nachtrag

Nachdem das soweit ganz toll funktioniert hat, wollte ich das von mir zuletzt vor der Version 3.0 genutzte darktable 2.4.4 “zurückholen” auf mein aktuelles Debian-System. Dazu muß man erst einmal aus dem Gesamt-Quelltext diese Version quasi “filtern”:

{benutzername}@{rechnername}:~/github/darktable-org/darktable$ git fetch --tags
{benutzername}@{rechnername}:~/github/darktable-org/darktable$ git checkout tags/release-2.4.4

Dann wird wie gewohnt ein Arbeitsverzeichnis erstellt und in dieses gewechselt:

{benutzername}@{rechnername}:~/github/darktable-org/darktable$ mkdir darktable24
{benutzername}@{rechnername}:~/github/darktable-org/darktable$ cd darktable24

Nun kann man (eigentlich) der Anleitung oben wie gehabt folgen, aber:

Dieses Vorhaben endete aber sehr zügig mit einer Reihe von make-Fehlermeldungen wie dieser hier:

~/github/darktable-org/darktable/src/common/cups_print.c: In function ‘dt_get_printer_info’:
~/github/darktable-org/darktable/src/common/cups_print.c:56:5: error: ‘cupsGetPPD’ is deprecated: 
Use cupsCopyDestInfo and friends instead. [-Werror=deprecated-declarations]
     const char *PPDFile = cupsGetPPD (printer_name);
     ^~~~~
In file included from ~/github/darktable-org/darktable/src/common/cups_print.c:20:
/usr/include/cups/ppd.h:366:20: note: declared here
 extern const char *cupsGetPPD(const char *name) _PPD_DEPRECATED;
                    ^~~~~~~~~~
~/github/darktable-org/darktable/src/common/cups_print.c:59:5: error: ‘ppdOpenFile’ is deprecated: 
Use cupsCopyDestInfo and friends instead. [-Werror=deprecated-declarations]
     ppd_file_t *ppd = ppdOpenFile(PPDFile);
     ^~~~~~~~~~

und so weiter und so weiter.

Nach meinem - zugegebenermaßen - begrenzten Verständnis handelt es sich hier um Aufrufe, bei denen darktable auf Betriebssystemfunktionen zurückgreift (hier: cups Drucker), die offenbar im aktuellen Betriebssystem so nicht mehr vorhanden sind und durch andere Funktionsaufrufe ersetzt wurden.

Die Entwickler sagen:

We only release the source tarballs. Everything else is done not by the team. (…) We make sure that darktable can be built on Debian stable, and latest Ubuntu LTS

übersetzt:

Wir geben nur die Quell-Tarballs frei. Alles andere wird nicht vom Team gemacht. (…) Wir stellen sicher, dass darktable auf Debian stable und dem neuesten Ubuntu-LTS gebaut werden kann

Tja - auch selbst bauen ist eben keine Zeitmaschine 👎 .

Anhänge

Abhängigkeiten

Liste der Files, die mit build-dep darktable installiert werden:

Die folgenden NEUEN Pakete werden installiert:
  autopoint cmake cmake-data debhelper dh-autoreconf dh-strip-nondeterminism dwz gir1.2-gtk-2.0 gir1.2-harfbuzz-0.0 gir1.2-osmgpsmap-1.0 gir1.2-rsvg-2.0 icu-devtools libatk-bridge2.0-dev libatk1.0-dev libatspi2.0-dev libblkid-dev libbz2-dev libcairo-script-interpreter2 libcairo2-dev libcolord-dev libcolord-gtk-dev libcups2-dev libcupsimage2-dev libcurl4-gnutls-dev libdbus-1-dev libdrm-dev libegl1-mesa-dev libepoxy-dev libexiv2-dev libffi-dev libfile-stripnondeterminism-perl libflickcurl-dev libfontconfig1-dev libfreetype6-dev libfribidi-dev libgdk-pixbuf2.0-dev libgl1-mesa-dev libgles1 libglib2.0-dev libglib2.0-dev-bin libglvnd-core-dev libglvnd-dev libgraphicsmagick1-dev libgraphite2-dev libgtk-3-dev libgtk2.0-dev libharfbuzz-dev libharfbuzz-gobject0 libice-dev libicu-dev libilmbase-dev libjbig-dev libjpeg-dev libjpeg62-turbo-dev libjson-glib-dev liblcms2-dev liblensfun-dev liblua5.3-dev liblzma-dev liblzo2-2 libmount-dev libncurses-dev libopenexr-dev libopenjp2-7-dev libosmgpsmap-1.0-dev libpango1.0-dev libpcre16-3 libpcre3-dev libpcre32-3 libpcrecpp0v5 libpixman-1-dev libpng-dev libpthread-stubs0-dev libpugixml-dev libraptor2-dev libreadline-dev librhash0 librsvg2-dev libsecret-1-dev libselinux1-dev libsepol1-dev libsm-dev libsoup2.4-dev libsqlite3-dev libtiff-dev libtiffxx5 libuv1 libwayland-bin libwayland-dev libwebp-dev libwmf-dev libx11-dev libx11-xcb-dev libxau-dev libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev libxcb-randr0-dev libxcb-render0-dev libxcb-shape0-dev libxcb-shm0-dev libxcb-sync-dev libxcb-xfixes0-dev libxcb1-dev libxcomposite-dev libxcursor-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxft-dev libxi-dev libxinerama-dev libxkbcommon-dev libxml2-dev libxml2-utils libxrandr-dev libxrender-dev libxshmfence-dev libxslt1-dev libxtst-dev libxxf86vm-dev libyajl-dev libzstd-dev mesa-common-dev pango1.0-tools po-debconf uuid-dev wayland-protocols x11proto-composite-dev x11proto-core-dev x11proto-damage-dev x11proto-dev x11proto-fixes-dev x11proto-input-dev x11proto-randr-dev x11proto-record-dev x11proto-xext-dev x11proto-xf86vidmode-dev x11proto-xinerama-dev xorg-sgml-doctools xtrans-dev
0 aktualisiert, 143 neu installiert, 0 zu entfernen und 5 nicht aktualisiert.
Es müssen 62,0 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 279 MB Plattenplatz zusätzlich benutzt.

2868 Worte - Lesezeit: 14 Minute(n)

Zu diesem Artikel:

darktable und das doppelte Lottchen

Zwei Versionen von darktable nebeneinander betreiben

Die Voraussetzungen

Lösungsansatz

Installation der ausführbaren Dateien

Anwendungsdaten

darktable aus den Quelltext-Dateien “bauen”

Notwendige Tools installieren

Quelltext herunterladen

Quelltext als Archiv herunterladen

Quelltext per git auf den Rechner kopieren

Quelltext vorbereiten

Arbeitsverzeichnis erstellen

Kompilieren

‘Binary’ erstellen und installieren

Einfache direkte Installation

Checkinstall: Installation mit Erstellung eines Pakets für den Paketmanager

Der Beweis

darktable einrichten und starten

Start aus dem Terminial

Start vom Desktop oder aus dem Menü

Zweite Installation wieder entfernen

Methode `install`

Methode `checkinstall`

Aktualisierung der selbst gebauten zweiten Installation

Kleiner Ausblick in die neue Version:

Nachtrag

Anhänge

Abhängigkeiten

weitere Artikel

Zweite Instanz von darktable für Linux - die einfache Variante

darktable: Backup der Daten

Offizielle Windows-Vorabversion von darktable

Gewitterstimmung - und die Rettung toter RAW-Dateien

darktable und das doppelte Lottchen

Zwei Versionen von darktable nebeneinander betreiben

Die Voraussetzungen

Lösungsansatz

Installation der ausführbaren Dateien

Anwendungsdaten

darktable aus den Quelltext-Dateien “bauen”

Notwendige Tools installieren

Quelltext herunterladen

Quelltext als Archiv herunterladen

Quelltext per git auf den Rechner kopieren

Quelltext vorbereiten

Arbeitsverzeichnis erstellen

Kompilieren

‘Binary’ erstellen und installieren

Einfache direkte Installation

Checkinstall: Installation mit Erstellung eines Pakets für den Paketmanager

Der Beweis

darktable einrichten und starten

Start aus dem Terminial

Start vom Desktop oder aus dem Menü

Zweite Installation wieder entfernen

Methode install

Methode checkinstall

Aktualisierung der selbst gebauten zweiten Installation

Kleiner Ausblick in die neue Version:

Nachtrag

Anhänge

Abhängigkeiten

weitere Artikel

Zweite Instanz von darktable für Linux - die einfache Variante

darktable: Backup der Daten

Offizielle Windows-Vorabversion von darktable

Gewitterstimmung - und die Rettung toter RAW-Dateien

Methode `install`

Methode `checkinstall`