staging.inyokaproject.org

aasche schrieb:

Justin Time schrieb:

Also ich würde nun aber wirklich gerne die git Anleitung in den Artikel aufnehmen eventuell sogar als Unterartikel Tomahawk/Kompilieren

Sehr gute Idee - ein Unterartikel waere perfekt geeignet ☺

Da ich schon etwas vorbereitet hatte: da ist er, der Unterartikel! 😀 Getestet wurde er von mir unter einem frischen Ubuntu GNOME 14.04 und spiegelt den aktuellen Stand wieder. Meinungen, Anregungen, Kritik?

Gruß Justin Time

Hier hat niemand eine Meinungen? Na dann kommt der Artikel so morgen ins Wiki. Ihr habt es ja nicht anders gewollt. 😈

Der Vorgang ist dermassen aufwendig, dass bei einem Review nur formale Sachen moeglich sind. Ein einziger Kritikpunkt:

Möchte man Tomahawk wieder deinstallieren, dann muss man einfach das Arbeitsverzeichnis und den selbst erstellten Starter löschen.

Ok. Und was ist mit den selbstgebauten Bibliotheken? Wie wird man die wieder los? Das wird insbesondere die Personen betreffen, die dann irgendwann in der Zukunft und trotz aller Warnungen ein Upgrade auf die naechste Ubuntu-Version versuchen.

Dieser Punkt ist in meinen Augen der groesste Schwachpunkt der diversen Kompilier-Anleitungen im Wiki: wie den ganzen Krempel wieder loswerden. Sei es, weil das selbstkompilierte Programm doch nicht den Erwartungen entspricht oder zwischenzeitlich ein leichter nutzbares PPA zur Verfuegung steht.

Alternativ dem Artikel eine "Fortgeschritten"-Box verpassen, dann muss jeder selbst wissen, worauf er sich einlaesst.

aasche schrieb:

Alternativ dem Artikel eine "Fortgeschritten"-Box verpassen, dann muss jeder selbst wissen, worauf er sich einlaesst.

Der Artikel hat schon von Anfang an die "Fortgeschritten"-Box. Aber danke für den Gedankenanstoß… Nur libechonest bietet eine Deinstallation mithilfe von sudo make uninstall bei allen anderen muss man die Dateien per Hand heraus löschen?! Sicher das solche Komponenten ein Upgrade verhindern? Sie werden nach /usr/locals/libs installiert und ersetzten keine veralteten Versionen aus den Quellen, sondern sind gar nicht in den Quellen verfügbar.

Justin Time schrieb:

Sicher das solche Komponenten ein Upgrade verhindern?

Letztlich haengt es natuerlich vom Einzelfall ab. Eine potentielle Fehlerquelle ist es dennoch, da solche Anleitungen gerne von Personen genutzt werden, die nur c&p beherrschen und keine Ahnung haben, was sie da eigentlich machen. Durchaus ueblich ist z.B. die gleichzeitige Parallel-Installation eines Programms aus den offiziellen Paketquellen und aehnliche Dinge. Denn im Artikel steht ja nicht, dass man vorher eine vorhandene Programmversion aus den Paketquellen (vollstaendig!) deinstallieren sollte...

Sie werden nach /usr/locals/libs installiert

Das sollte unbedingt noch in den Artikel.

und ersetzten keine veralteten Versionen aus den Quellen, sondern sind gar nicht in den Quellen verfügbar.

aha - die Pakete libechonest2.1, liblastfm1, libjreen1 und libquazip0 sind also voellig ueberfluessig? 😉

aasche schrieb:

Denn im Artikel steht ja nicht, dass man vorher eine vorhandene Programmversion aus den Paketquellen (vollstaendig!) deinstallieren sollte...

Nein, weil die sich auch überhaupt nicht in die Quere kommen und parallel installiert werden können (zu mindestens betreibe ich die schon seit mehreren Monaten ohne Probleme parallel). Tomahawk überprüft beim Start, ob es schon selbst im Hintergrund läuft und falls dies der Fall ist, dann startet es nicht erneut. Bisher habe ich auch noch keine Datenbankschäden davon getragen, die Programmversionen scheinen untereinander kompatibel zu sein.

Sie werden nach /usr/locals/libs installiert

Das sollte unbedingt noch in den Artikel.

und ersetzten keine veralteten Versionen aus den Quellen, sondern sind gar nicht in den Quellen verfügbar.

aha - die Pakete libechonest2.1, liblastfm1, libjreen1 und libquazip0 sind also voellig ueberfluessig? 😉

Oh je… du hast Recht, ich sollte das alles noch einmal genauer testen…

Danke aasche!

Durch deine Paketliste kam ich auf die Idee einfach mal zu überprüfen, ob wirklich so viele Bibliotheken kompiliert werden müssen. Ich konnte erfreulicherweise feststellen, dass alles - bis auf libechonest2.1, welches in Version 2.3.0. benötigt wird – aus den Paketquellen verwendet werden kann. (Das ich darauf nicht früher gekommen bin…).

Wie schon vorher erwähnt, lässt sich libechonest einfach mit dem Befehl sudo make uninstall entfernen. Daher müssten nun alle Punkte geklärt sein.

Gruß Justin Time

Justin Time schrieb:

Danke aasche!

dafuer nicht 😉

Durch deine Paketliste kam ich auf die Idee einfach mal zu überprüfen, ob wirklich so viele Bibliotheken kompiliert werden müssen. Ich konnte erfreulicherweise feststellen, dass alles - bis auf libechonest2.1, welches in Version 2.3.0. benötigt wird – aus den Paketquellen verwendet werden kann.

Das mag im Augenblick so sein - aber es kann sich bei einer Entwicklerversion jederzeit aendern. Deswegen ist es ja eine Entwicklerversion. Wie man das jetzt praktisch umsetzt? Gute Frage...

Nachtrag: eigentlich nur durch einen Hinweis, der diese Problematik verdeutlicht. Denn es kann durchaus sein - trotz "Getestet mit..." - dass der Artikel schneller veraltet als einem lieb ist. Waehrend man bei einer Programmversion diese exakt angeben kann, ist dass bei Benutzung des Quellcodes via Git nicht moeglich, oder?

aasche schrieb:

Das mag im Augenblick so sein - aber es kann sich bei einer Entwicklerversion jederzeit aendern. Deswegen ist es ja eine Entwicklerversion. Wie man das jetzt praktisch umsetzt? Gute Frage...

Nachtrag: eigentlich nur durch einen Hinweis, der diese Problematik verdeutlicht. Denn es kann durchaus sein - trotz "Getestet mit..." - dass der Artikel schneller veraltet als einem lieb ist. Waehrend man bei einer Programmversion diese exakt angeben kann, ist dass bei Benutzung des Quellcodes via Git nicht moeglich, oder?

Ja, da ich aktuell wöchentlich Tomahawk neu kompiliere, an der Übersetzung ins Deutsche mithelfe und ansonsten die Entwicklung verfolge, kriege ich Änderungen an den Abhängigkeiten aktuell direkt mit. Aber ich habe eine Warnung in den Artikel integriert.

Ich denke es eventuell besser den Quellcode von libechonest von dieser 🇬🇧 Seite herunterzuladen, oder? Dies ist dann keine Entwicklungsversion, sondern die stabile Version 2.3.0.

Justin Time schrieb:

Ich denke es eventuell besser den Quellcode von libechonest von dieser 🇬🇧 Seite herunterzuladen, oder? Dies ist dann keine Entwicklungsversion, sondern die stabile Version 2.3.0.

Nuetzt das wirklich etwas? Wenn - sagen wir mal, im Fruehjahr 2015 - jemand auf den Artikel stoesst, stimmt er dann noch? Damit geht es eher darum, die "Version" von Tomahawk irgendwie festzuklopfen, die dem Artikel zugrunde lag.

In diesem Sinn ist ein Kompilieren-Artikel grundsaetzlich nur eine Momentaufnahme. Solange darauf hingewiesen wird und idealerweise auch ein Ort genannt wird (Entwicklerforum o.ae.), wo man weitere Hilfe bekommt, ist der Artikel in der bisherigen Form voellig in Ordnung.

aasche schrieb:

Justin Time schrieb:

Ich denke es eventuell besser den Quellcode von libechonest von dieser 🇬🇧 Seite herunterzuladen, oder? Dies ist dann keine Entwicklungsversion, sondern die stabile Version 2.3.0.

Nuetzt das wirklich etwas?

Teilweise ja, denn so ist nur noch Tomahawk eine Entwicklerversion, dessen Abhängigkeiten sich ändern können. libechonest ist im Vergleich zur Version aus git-Verzeichnis stabil. Das der Artikel nicht ewig so gültig ist, ist mir bewusst. Aber dafür pflege ich ihn ja.

Solange darauf hingewiesen wird und idealerweise auch ein Ort genannt wird (Entwicklerforum o.ae.), wo man weitere Hilfe bekommt, ist der Artikel in der bisherigen Form voellig in Ordnung.

Hmm… das Tomahawk Forum 🇬🇧 sieht extrem verweist aus, ich habe es trotzdem mal erwähnt.

Damit geht es eher darum, die "Version" von Tomahawk irgendwie festzuklopfen, die dem Artikel zugrunde lag.

Ah ok, die Version lautet gerade 0.8.99, also die Vorschau zur Version 0.9 (obwohl 0.8 noch nicht erschienen ist…).

Ich habe den Artikel jetzt mal ins Wiki entlassen, mal abwarten, wie lange der aktuell bleibt.

könnte IMHO ins Archiv - es sei denn, nach 5 Jahren will den Artikel jemand testen?

Gruß BillMaier

Ich könnte mich fast dazu bereit erklären, wenn das Projekt nicht bereits in 2017 für eingestellt erklärt worden wäre (Commit). Danach gab es bis Anfang des Jahres mehrere Patches, die mehr Bereinigungen für das Build-System darzustellen scheinem (Commits).

Schwierig wird es vor allem mit Blick auf weitergehende Unterstützung bzw. das Testen des Ergebnisses auf Herz und Nieren. Einfach einen Kasten mit "Feature x konnte mangels Account nicht getestet werden" oder "YMMV" reinzustecken klingt mir zu einfach. ☺

Hi!

OK, Artikel ist damit jetzt im Archiv.

so long
hank