staging.inyokaproject.org

karzer schrieb:

Du kannst gerne schon Änderungen vornehmen.

Da tue ich mir etwas schwer. Zumindest hätte ich gerne abgesprochen, ob mein Vorschlag, erst mal den einfachsten Weg zu erklären, und die Spezialitäten hinten anzustellen, bei Dir Anklang findet. So, wie der Artikel jetzt ist, eignet er sich ja nur für das Patchen schon existierender Pakete. Ich hatte nämlich auch mal versucht, die Änderung manuell ohne den Patch-Mechanismus per quilt durchzuführen, doch da stieß ich auf Fehlermeldungen. Der Artikel ist also nutzlos, wenn man ein neues Paket auf Basis von neuem Sourcecode bauen will, wo es noch kein Original für gibt, worauf man Patches anwenden könnte. Das wäre auch genau der Fall, der mich für mein eigenes Projekt interessieren würde.

Der Grund dafür ist bereits im Artikel vermerkt:

Für das Beispiel wird nun die Version des Paketes von 2.7-1 zu 1:2.7-1~0ubuntu1 geändert. Die Epoch-Nummer wird gesetzt, da das Paket hello bereits in den Ubuntuquellen vorhanden ist und je nach Ubuntuversion schon in neuerer Version vorliegt, das selbsterstellte Paket aber installiert bleiben soll.

Ach jetzt versthe ich das erst richtig. Danke.

Durch den Watch-Mechanismus sollte das doch eigentlich so sein. […]

Die Funktionsweise dieses Mechanismus hatte ich ja bereits in 9476472 erläutert; der ist nur für Paketierer sinnvoll, die ihr eigenes Paket auf eine neue Version anpassen wollen und hat mit apt nichts zu tun.

Ach so, dann wäre das ja auch ein Kandidat für nachfolgende Spezial-Abschnitte.

Weil ein Patch idealerweise auch genau einen Fehler beheben sollte; so kann man die Patches besser verwalten ...

Verstehe. Ich würde sagen, da ist von Fall zu Fall die Strategie unterschiedlich. Wenn der Fehler z.B. Lautet: "Projekt kompiliert nicht", könnte man die Änderungen, die für das korrekte Kompilieren nötig sind, auch in einen Patch packen, auch wenn davon mehrere Dateien betroffen sind.

UlfZibis schrieb:

[…] Ich hatte nämlich auch mal versucht, die Änderung manuell ohne den Patch-Mechanismus per quilt durchzuführen, doch da stieß ich auf Fehlermeldungen.

Das ist nicht verwunderlich; es gibt insgesamt drei Varianten zum Patchen des Quellcodes, von denen quilt m. E. die bequemste ist. Wenn Du also manuelle etwas geändert hast, wirst Du wohl eine Fehlermeldung nach dem Schema "modification to the upstream source" erhalten haben?

Der Artikel ist also nutzlos, wenn man ein neues Paket auf Basis von neuem Sourcecode bauen will, wo es noch kein Original für gibt, worauf man Patches anwenden könnte. Das wäre auch genau der Fall, der mich für mein eigenes Projekt interessieren würde.

Das verstehe ich nicht; der Artikel liefert doch Grundwissen für die Erstellung von einfachen, single-arch Paketen, ob da nun eigener oder „geklauter“ Quellcode zugrunde liegt. Sicher, im Zweifel wird ein anderes Build-System verwendet, aber dafür gibt es ja ausführliche Beispiele. Oder was genau ist Dein Problem?

[…] Verstehe. Ich würde sagen, da ist von Fall zu Fall die Strategie unterschiedlich. Wenn der Fehler z.B. Lautet: "Projekt kompiliert nicht", könnte man die Änderungen, die für das korrekte Kompilieren nötig sind, auch in einen Patch packen, auch wenn davon mehrere Dateien betroffen sind.

Sicher, mit einem entsprechend ausführlichen Patch-Header nach DEP 3 geht das. Dieser Hinweis darauf gehört übrigens zu den bisherigen Überarbeitungen, die Du gerne mal kritisch prüfen kannst.

karzer schrieb:

Wenn Du also manuelle etwas geändert hast, wirst Du wohl eine Fehlermeldung nach dem Schema "modification to the upstream source" erhalten haben?

Genau die bekam ich.

Der Artikel ist also nutzlos, wenn man ein neues Paket auf Basis von neuem Sourcecode bauen will, wo es noch kein Original für gibt, worauf man Patches anwenden könnte. Das wäre auch genau der Fall, der mich für mein eigenes Projekt interessieren würde.

Das verstehe ich nicht; der Artikel liefert doch Grundwissen für die Erstellung von einfachen, single-arch Paketen, ob da nun eigener oder „geklauter“ Quellcode zugrunde liegt.

Ach jetzt klingelt's, wieder was verstanden. Bei einem jungfräulichen Projekt muss man den "upstream" tar ball aus den eigenen Sourcen selbst bauen und es gibt nichts zu patchen.

Also nochmal ein neuer skizzenhafter Vorschlag für den Aufbau des Artikels.

1. Einfaches Debian-Paket bauen

   1. Die Sourcen müssen als tar ball vorliegen.

   2. für diese Anleitung nehmen wir ....

   3. debian templates erstellen

   4. debian templates bearbeiten / vervollständigen

   5. Quell-Paket bauen

   6. Binär-Paket bauen

   7. Wie wir nun sehen, kompiliert / baut dieser alte tar ball nicht mehr, also müssen wir die Ursache finden und einen Patch erstellen →

2. Weitere / fortgeschrittene Maßnahmen

   1. Patchen

      1. Patch einpflegen

      2. ...

      3. changelog aktualisieren

      4. Binär-Paket bauen

   2. Spätere Neupaketierung (watch)

      1. ...

Die beiden Über-Kapitel kann man evtl. auch weglassen.

... aber dafür gibt es ja ausführliche Beispiele.

Fündig geworden. Das passt wohl am besten zu meinem Projekt: https://www.debian.org/doc/manuals/debmake-doc/ch14.en.html#autotools-multi

Sicher, mit einem entsprechend ausführlichen Patch-Header nach DEP 3 geht das. Dieser Hinweis darauf gehört übrigens zu den bisherigen Überarbeitungen, die Du gerne mal kritisch prüfen kannst.

Ich habe da eine Idee zur Verbesserung, und werde die mal einbauen.

UlfZibis schrieb:

Ich habe da eine Idee zur Verbesserung, und werde die mal einbauen.

Schau mal ob's Dir gefällt.

1. Kann man nicht mit uquilt gleich die selbst erstellte Patch-Datei verwenden, statt dass uquilt sie noch mal baut?

2. Evtl. kann man auch das Einpflegen der beiden Patches "mergen" und so ein paar doppelte Befehle wie z.B. uquilt refresh einsparen. Dann würde aber die kompakte Version für den 2. Patch wegfallen.

1. Bzgl. uquilt header --dep3 -e könnte man vielleicht noch grob erläutern, was da wichtig ist reinzuschreiben.

2. Ich habe auch herausgefunden, dass man das ganze quilt-Gedöns weglassen kann, wenn man die beiden Patch-Dateien einfach manuell in den Ordner debian/patches einfügt und die Datei debian/patches/series manuell ausfüllt. Das ist um vielfaches weniger aufwendig.
   Zumindest braucht man den uquilt-Alias nicht, denn es gibt auch ein passendes dquilt.

3. Auch die deb3-Header kann man manuell den Patch-Dateien hinzufügen, wenn man die denn unbedingt braucht.

PS: Leider geht seit dem letzten Ubuntu-Update die Back-Tick-Taste nicht mehr und auch die Hütchen-Taste, deshalb fehlen oben die Befehls-Formatierungen.

UlfZibis schrieb:

[…] Evtl. kann man auch das Einpflegen der beiden Patches "mergen" und so ein paar doppelte Befehle wie z.B. uquilt refresh einsparen. Dann würde aber die kompakte Version für den 2. Patch wegfallen.

Ich find’s so gut und übersichtlich, danke!

UlfZibis schrieb:

1. Bzgl. uquilt header --dep3 -e könnte man vielleicht noch grob erläutern, was da wichtig ist reinzuschreiben.

Erledigt.

Ich habe auch herausgefunden, dass man das ganze quilt-Gedöns weglassen kann, wenn man die beiden Patch-Dateien einfach manuell in den Ordner debian/patches einfügt und die Datei debian/patches/series manuell ausfüllt. Das ist um vielfaches weniger aufwendig.

Finde ich jetzt nicht unbedingt, zumal wenn man viele evtl. aufeinander aufbauende und umfangreiche Patches hat ist die Verwendung von quilt doch deutlich komfortabler. Die Bedienung fällt doch eigentlich leicht. Außerdem ist quilt unter Paketierern gang und gäbe.

Zumindest braucht man den uquilt-Alias nicht, denn es gibt auch ein passendes dquilt. […]

Du bist gut 😉 Die haben das doch auch erst als Alias definiert.

UlfZibis schrieb:

[…] Also nochmal ein neuer skizzenhafter Vorschlag für den Aufbau des Artikels.

1. Einfaches Debian-Paket bauen

   1. Die Sourcen müssen als tar ball vorliegen.

   2. für diese Anleitung nehmen wir ....

Können wir so machen.

1. Quell-Paket bauen

2. Binär-Paket bauen

3. Wie wir nun sehen, kompiliert / baut dieser alte tar ball nicht mehr, also müssen wir die Ursache finden und einen Patch erstellen →

Hört sich nach einer sinnvollen hands-on Herangehensweise an.

[…] 1. Binär-Paket bauen

Das müsste dann ein Verweis auf den vorigen Abschnitt sein.

Spätere Neupaketierung (watch)

Das habe ich jetzt mal nach Grundlagen der Paketerstellung/Optionale Konfigurationsdateien verschoben und einen Verweis im Hauptartikel belassen.

karzer schrieb:

UlfZibis schrieb:

Ich habe auch herausgefunden, dass man das ganze quilt-Gedöns weglassen kann, wenn man die beiden Patch-Dateien einfach manuell in den Ordner debian/patches einfügt und die Datei debian/patches/series manuell ausfüllt. Das ist um vielfaches weniger aufwendig.

Finde ich jetzt nicht unbedingt,

Naja, wenn man schon eine / mehrere Patch-Datei(en) hat, mit denen dann die Sourcen ändert, und daraus mit quilt wieder ein zweites Mal jeweils eine Patch-Datei erzeugen muss, sind das schon ziemlich viele Befehle, die da per copy-paste abgearbeitet werden müssen. Gerade auf kleinem Laptop-Bildschirm ziemlich lästig Terminal und Browser abwechselnd in den Vordergrund zu holen.

zumal wenn man viele evtl. aufeinander aufbauende und umfangreiche Patches hat ist die Verwendung von quilt doch deutlich komfortabler.

Wäre für mich eher ein Fall für einen fortgeschrittenen Abschnitt.
All das bedacht fände ich es jetzt doch besser, hier die manuelle Änderung der 3 Zeilen zu beschreiben, statt den Artikel mit noch erst selbst zu erstellenden Patch-Dateien zu überfrachten.

Die Bedienung fällt doch eigentlich leicht

Rein optisch ist sie schon mal ziemlich erschreckend, weshalb ich vorschlagen würde, die Erstellung des Alias in einem Hinweiskasten abzugrenzen oder wenigstens in einen extra Abschnitt zu verschieben.

Du bist gut 😉 Die haben das doch auch erst als Alias definiert.

Das ist mir später dann auch aufgefallen. Schande auf mein Haupt.
Die verwenden da aber einen 3-Zeiler statt einen 2-Zeiler. Kapierst Du, was da die mittlere Zeile macht?

Außerdem ist quilt unter Paketierern gang und gäbe.

Aus dem Grund verstehe ich ja überhaupt nicht, warum da nicht schon längst einer auf die Idee gekommen ist, diese Abwandlung von quilt gleich in das deb-helper-Paket mit aufzunehmen. Noch besser als einen geskripteten Alias (=lahm) fände ich einen zusätzlichen Schalter für quilt, die die Funktion passend für debuild macht.

1. Quell-Paket bauen

Ich denke, das müssen wir irgendwie anders nennen. Im Ergebnis hello_2.7-1~0ubuntu1.debian.tar.xz sind ja gar keine Quell-Dateien drin. Unter Quell-Paket würde ich ein *-dev.deb-Paket verstehen, oder zumindest einen tar ball mit den vollständigen gepatchten Sourcen.

UlfZibis schrieb:

[...] All das bedacht fände ich es jetzt doch besser, hier die manuelle Änderung der 3 Zeilen zu beschreiben, statt den Artikel mit noch erst selbst zu erstellenden Patch-Dateien zu überfrachten.

Ich finde die Patches auch primär sinnvoll, damit man auf den ersten Blick sieht, welche Änderungen gemacht werden sollen. Wie es vorher aussah, kannst Du hier sehen. Natürlich kann man auch sagen, dass das manuelle geändert werden soll. Häufig ist es aber auch so, dass man einen bereits bestehenden Patch irgendwo herunterlädt und auf seine lokale Kopie anwendet.

Die Bedienung fällt doch eigentlich leicht

Rein optisch ist sie schon mal ziemlich erschreckend, weshalb ich vorschlagen würde, die Erstellung des Alias in einem Hinweiskasten abzugrenzen oder wenigstens in einen extra Abschnitt zu verschieben.

Das ist ja nur die Konfiguration, nicht die Bedienung, das macht man einmal und feddich. Wir können ruhig ein bisschen „Gefasstheit“ von Seiten des Lesers erwarten, oder? Was aber ginge, wäre einfach QUILT_PATCHES="debian/patches" (zzgl. der anderen Variablen) zur .quiltrc-dpkg hinzuzufügen. Dann könnte man das Ding halt nur für den Paketbau benutzen.

Du bist gut 😉 Die haben das doch auch erst als Alias definiert.

Die verwenden da aber einen 3-Zeiler statt einen 2-Zeiler. Kapierst Du, was da die mittlere Zeile macht?

. ist ein Alias für source. Das liest die Datei ein, in der die quilt-Autokomplettierung gespeichert ist, sodass in der nächsten Zeile die Funktion _quilt_completion verfügbar ist… Moment… funktioniert die Komplettierung momentan überhaupt?

Außerdem ist quilt unter Paketierern gang und gäbe.

Aus dem Grund verstehe ich ja überhaupt nicht, warum da nicht schon längst einer auf die Idee gekommen ist, diese Abwandlung von quilt gleich in das deb-helper-Paket mit aufzunehmen. Noch besser als einen geskripteten Alias (=lahm) fände ich einen zusätzlichen Schalter für quilt, die die Funktion passend für debuild macht.

Bisschen komisch, stimmt. Aber Paketierer sind ja sowieso meistens Nerds. Wahrscheinlich macht das denen nichts aus.

1. Quell-Paket bauen

Ich denke, das müssen wir irgendwie anders nennen. Im Ergebnis hello_2.7-1~0ubuntu1.debian.tar.xz sind ja gar keine Quell-Dateien drin. Unter Quell-Paket würde ich ein *-dev.deb-Paket verstehen, oder zumindest einen tar ball mit den vollständigen gepatchten Sourcen.

Was ein Quell-Paket ist, ist klar definiert. Habe den Link jetzt auch zum Artikel hinzugefügt.

karzer schrieb:

Wie es vorher aussah, kannst Du hier sehen.

Interessant. Wie kommt es, dass da damals nicht der Alias für quilt nötig war?

karzer schrieb:

Ich finde die Patches auch primär sinnvoll, damit man auf den ersten Blick sieht, welche Änderungen gemacht werden sollen. Wie es vorher aussah, kannst Du hier sehen. Natürlich kann man auch sagen, dass das manuelle geändert werden soll. Häufig ist es aber auch so, dass man einen bereits bestehenden Patch irgendwo herunterlädt und auf seine lokale Kopie anwendet.

Ich konnte es nicht lassen, und hab' den "kurzen Dienstweg" mal eingebaut. Nebenbei veranschaulicht der auch, was das eigentliche Ziel der komplizierten quilt-Verwendung ist.

karzer schrieb:

Endlich, es funktioniert etwas! Ich habe den Artikel eben in die Baustelle verschoben, Du kannst gerne schon Änderungen vornehmen.

Ich bin nun fertig mit meinen Verbesserungen. Bitte guck' mal drüber.

Die quilt-Methode habe habe ich jetzt für den Fall "Manuelle Code-Veränderung" deklariert und demnach eine "hemdsärmelige" manuelle Code-Änderung für das Beispiel konstruiert. Das passt dann IMHO besser, wenn man ein Paket aus eigenen Sourcen aus dem Stand heraus bauen will, wo man ja üblicherweise direkt den Code editiert, statt Patch-Dateien anfertigt.

karzer schrieb:

Wie es vorher aussah, kannst Du hier sehen.

Interessant. Wie kommt es, dass da damals der Alias für quilt nicht nötig war?

UlfZibis schrieb:

karzer schrieb:

Endlich, es funktioniert etwas! Ich habe den Artikel eben in die Baustelle verschoben, Du kannst gerne schon Änderungen vornehmen.

Ich bin nun fertig mit meinen Verbesserungen. Bitte guck' mal drüber.

Sieht gut aus, vielen Dank! Ich habe noch ein paar kleinere Anpassungen vorgenommen. Außerdem habe ich unter Baustelle/Grundlagen der Paketerstellung (Abschnitt „Herstellen-einer-Arbeitsumgebung“) Grundlegendes zum Bau des Programms erläutert, damit man den Prozess in rules besser versteht.

Ich würd’ übrigens compat drin lassen, da ja das Festlegen des Kompatibilitätsmodus für debhelper eine durchaus wichtige Sache ist / sein kann.

Die quilt-Methode habe habe ich jetzt für den Fall "Manuelle Code-Veränderung" deklariert und demnach eine "hemdsärmelige" manuelle Code-Änderung für das Beispiel konstruiert. Das passt dann IMHO besser, wenn man ein Paket aus eigenen Sourcen aus dem Stand heraus bauen will, wo man ja üblicherweise direkt den Code editiert, statt Patch-Dateien anfertigt.

Ja, das passt schon, zumal sich die entsprechenden Zeilen ja nicht ändern können.

karzer schrieb:

Wie es vorher aussah, kannst Du hier sehen.

Interessant. Wie kommt es, dass da damals der Alias für quilt nicht nötig war?

Frag mich nicht. War offenbar 2014 schon ein Thema. Aus dem Changelog des Ubuntu-Paketes bin ich leider nicht schlau geworden. Eigentlich kann das ja nur ein Patch gewesen sein, der irgendwann aus irgendeinem Grund entfernt wurde.

karzer schrieb:

Sieht gut aus, vielen Dank!

Das erfreut mich ja.

Ich habe noch ein paar kleinere Anpassungen vorgenommen.

Ich hatte da "*.deb-Paket-Bau" geschrieben, weil in dem Artikel "Paket" mehrdeutig verwendet wird. Mal ist das Konglomerat aus einem Projekt gemeint, mal der Upstream-Tarball, mal eben die finale *.deb-Datei. Alternative wäre vielleicht DEBIAN-Paket-Bau.

Außerdem habe ich unter Baustelle/Grundlagen der Paketerstellung (Abschnitt „Herstellen-einer-Arbeitsumgebung“) Grundlegendes zum Bau des Programms erläutert, damit man den Prozess in rules besser versteht.

Den Teil finde ich eher irritierend und teils schädlich und ich gehe davon aus, das jemand, der ein DEB-Paket bauen will, sich schon ausreichend mit seinem Programm und dessen Kompilier- und Lauffähigkeit und auch Bau-Art beschäftigt hat. Ein Verweis auf den Artikel "Kompilieren" sollte also reichen. Speziell mit dem hier verwendeten alten GNU-Hello, finde ich es sogar lehrreich, dass der unbedarfte Nutzer dieser Anleitung an passender Stelle "auf den Bauch fällt", womit klar wird, dass man sich nicht immer auf Upstream-Sourcen verlassen kann, bzw. man sie vielleicht von falscher Stelle und / oder in falscher Version besorgt hat.
1. gibt es in GNU hello keine autogen.sh. 2. ist die Datei in manchen Projekten uralt und nicht mehr funktionsfähig. 3. moderner ist die Nutzung von autoconf oder autoreconf. Da die dabei zu verwendenden Schalter je nach Projekt recht unterschiedlich sein können, hilft hier kein "Musterbefehl". 4. im Beispiel liegt configure schon vor, sodass es den Schritt überhaupt nicht braucht.
5. sudo make install finde ich hier ziemlich gefährlich, da man sich damit schnell das System zerschießen kann, vor allem wenn damit ein vorhandenes Programm überschrieben wird. Zum Testen eines Programms ist doch erst mal sowas wie ./configure --prefix=$HOME/Pfad/zum/Projekt/dist angebracht.

Da die oben gezeigte Bau-Prozedur durch die vorgefertigten Skripte ausgeführt wird ...

... ist dann also auch falsch, weil bebuild weder autogen.sh noch sudo ... ausführt.

Da fände ich es also besser, den Abschnitt "rules" direkt zu verbessern. Wegen zu wenig Kenntnis habe ich da keine Idee wie, aber zumindest kürzer könnte man das IMHO fassen.

Ich würd’ übrigens compat drin lassen, da ja das Festlegen des Kompatibilitätsmodus für debhelper eine durchaus wichtige Sache ist / sein kann.

Im vorliegenden, auch nicht gerade taufrischen Beispiel erscheint die Datei überhaupt nicht. Schon von daher ist das irritierend. Wenn ich das richtig verstehe, war compat nur früher von Bedeutung, und die Kompatibilität wird ja nun in control festgelegt. Nach meinem Geschmack ein Fall für "Optionale Konfigurationsdateien".

Ja, das passt schon, zumal sich die entsprechenden Zeilen ja nicht ändern können.

Schön, dass Du da "mit an Bord kommst".

War offenbar 2014 schon ...

Ungültiger Link, Präfix "post" vergessen.

PS: Ist der mit Datei ~/.bash_aliases angelegte Alias eigentlich sofort verfügbar, oder erst nach Ein-/Ausloggen? Ich hatte die 3 Zeilen deshalb vorsorglich immer im Terminal manuell ausgeführt. Dürfte auch für die export ...-Befehle gelten, wenn man die nur in Datei ~/.profile anlegt.

UlfZibis schrieb:

[…]

Ich habe noch ein paar kleinere Anpassungen vorgenommen.

Ich hatte da "*.deb-Paket-Bau" geschrieben, weil in dem Artikel "Paket" mehrdeutig verwendet wird. Mal ist das Konglomerat aus einem Projekt gemeint, mal der Upstream-Tarball, mal eben die finale *.deb-Datei. Alternative wäre vielleicht DEBIAN-Paket-Bau.

Ja, wäre vielleicht sinnvoll.

Außerdem habe ich unter Baustelle/Grundlagen der Paketerstellung (Abschnitt „Herstellen-einer-Arbeitsumgebung“) Grundlegendes zum Bau des Programms erläutert, damit man den Prozess in rules besser versteht.

Den Teil finde ich eher irritierend und teils schädlich und ich gehe davon aus, das jemand, der ein DEB-Paket bauen will, sich schon ausreichend mit seinem Programm und dessen Kompilier- und Lauffähigkeit und auch Bau-Art beschäftigt hat. Ein Verweis auf den Artikel "Kompilieren" sollte also reichen.

Ich habe weiter unten konkret auf das Standard-Prozedere verwiesen.

Speziell mit dem hier verwendeten alten GNU-Hello, finde ich es sogar lehrreich, dass der unbedarfte Nutzer dieser Anleitung an passender Stelle "auf den Bauch fällt", womit klar wird, dass man sich nicht immer auf Upstream-Sourcen verlassen kann, bzw. man sie vielleicht von falscher Stelle und / oder in falscher Version besorgt hat.

Idealerweise sollte doch aber von vornherein die Reihenfolge bei der Paketierung klar sein, oder? Erst ausprobieren, dann bauen.

1. […]

Dafür muss ich mich entschuldigen. Ich hatte das auf einem anderen Rechner ausprobiert und mir dabei glatt Version 2.7.1 besorgt. Schande, Schande über Schande. Wer konnte auch ahnen, dass… Naja, keine Ausflüchte.

Da fände ich es also besser, den Abschnitt "rules" direkt zu verbessern. Wegen zu wenig Kenntnis habe ich da keine Idee wie, aber zumindest kürzer könnte man das IMHO fassen.

Ist jetzt bei einem Link geblieben.

Ich würd’ übrigens compat drin lassen, […]

Nach meinem Geschmack ein Fall für "Optionale Konfigurationsdateien".

Ausgelagert.

[…] PS: Ist der mit Datei ~/.bash_aliases angelegte Alias eigentlich sofort verfügbar, oder erst nach Ein-/Ausloggen? Ich hatte die 3 Zeilen deshalb vorsorglich immer im Terminal manuell ausgeführt.

Nach Neustart einer Terminal-Sitzung. Alternativ direkt durch Ausführen von source .bash_aliases. Kannst Du noch hinzufügen.

karzer schrieb:

Nach Neustart einer Terminal-Sitzung. Alternativ direkt durch Ausführen von source .bash_aliases. Kannst Du noch hinzufügen.

Done!