staging.inyokaproject.org

trick17 schrieb:

cornix schrieb:

Die Unterscheidung ist nicht 32 Bit oder 64 Bit, sondern Binär-Datei oder selbst kompiliert.

Generell natürlich ja - aber in diesem speziellen Fall unterscheidet sich die Installation des Programms doch für den Anwender doch danach, ob er ein 32 oder 64 Bit-System hat, oder?

Der Artikel muss auch gepflegt werden, wenn sich die Voraussetzungen ändern. Wenn gosm mal vernünftig paketiert wird und über die Paketquellen installiert werden kann, verkürzt sich der Abschnitt zur Installation ungemein und eine Unterscheidung nach X Bit wird hinfällig. Eine Anleitung zum Kompilieren kann aber auch aus anderen Gründen langfristig interessant sein. Hierbei kann es auch so sein, dass der eigentliche Artikel für jede Version gepflegt wird, sich aber für die Pflege des Kompilier-Gedöns nur ein Benutzer von LTS-Versionen findet.

Daher mein Vorschlag:

1. neue Baustelle gosm/Kompilieren

2. gosm/Kompilieren verschieben

3. im Artikel gosm darauf hinweisen, dass die vom Entwickler kompilierte Version eine 32-Bit Version ist (inkl. andere Webkit Version, daher der fiese Trick mit dem symbolischen Link) und auf Unterartikel zum Kompilieren verlinken

Punkt eins ist für trick17, zwei nehm ich, drei überlassen wir march. 😀

Kompiliermeister

Nein. Sonst würde ich eine anständige Makefile anlegen, ein Debian-Paket erstellen und es nach Debian-testing hochladen. 😉

/opt als Arbeitsverzeichnis ist in dem Fall auch ehr ungünstig und nur bei der Variante von march sinnvoll.

Sondern?

Irgendein (bestenfalls sinnvoll benanntes) Verzeichnis in dem man die Rechte zum Lesen und Schreiben hat und in dem man eigenhändig kompillierte/paketierte/installierte Software verwaltet.

Gruß, cornix

cornix schrieb:

Daher mein Vorschlag:

1. neue Baustelle gosm/Kompilieren

2. gosm/Kompilieren verschieben

3. im Artikel gosm darauf hinweisen, dass die vom Entwickler kompilierte Version eine 32-Bit Version ist (inkl. andere Webkit Version, daher der fiese Trick mit dem symbolischen Link) und auf Unterartikel zum Kompilieren verlinken

Punkt eins ist für trick17, zwei nehm ich, drei überlassen wir march. 😀

Einverstanden mit Punkt eins, wenn du mir hier:

/opt als Arbeitsverzeichnis ist in dem Fall auch ehr ungünstig und nur bei der Variante von march sinnvoll.

Sondern?

Irgendein (bestenfalls sinnvoll benanntes) Verzeichnis in dem man die Rechte zum Lesen und Schreiben hat und in dem man eigenhändig kompillierte/paketierte/installierte Software verwaltet.

...später nochmal unter die Arme greifst und auch über das ganze mit deinem geschulteren Blick nochmal gehst vor Punkt zwei. 😉

Auch einverstanden?

Gruß, Patrick

Punkt eins ist für trick17, zwei nehm ich, drei überlassen wir march. 😀

😛

Auch einverstanden?

Jup

Gruß, cornix

Kann man das Programm nur unter Lucid verwenden oder was ist mit "vollen Funktionsumfang" gemeint?

Ich habe es geprüft:

./gosm: error while loading shared libraries: libwebkit-1.0.so.1: cannot open shared object file: No such file or directory

Man müßte das Webkit kompilieren. IMHO ein Kandidat für das Archiv.

Mit libwebkit-dev und Symlinks habe ich es nicht hinbekommen. Das heißt aber nichts, da ich mein System zerschossen habe. 😉

Das Programm funktioniert bei mir auch unter Ubuntu 12.04 - auch ohne Linken für WebKit.

Allerdings muss man die Binary wohl einmal neu kompilieren. Ein einfaches make reicht dafür - siehe auch README.

Über die konkreten Abhängigkeiten kann ich keine Aussage machen, weil ich recht viel selber kompiliere und deswegen reichlich relevante Pakete bei mir sozusagen vorinstalliert sind.

Das Programm funktioniert bei mir auch unter Ubuntu 12.04 - auch ohne Linken für WebKit.

Gut zu hören. Also kann man den Artikel - mit einer Überarbeitung - im Wiki lassen.

Allerdings muss man die Binary wohl einmal neu kompilieren. Ein einfaches make reicht dafür - siehe auch README.

Habe ich eben auch gelesen und die Seite schon als Lesezeichen hinterlegt.

Über die konkreten Abhängigkeiten kann ich keine Aussage machen, weil ich recht viel selber kompiliere und deswegen reichlich relevante Pakete bei mir sozusagen vorinstalliert sind.

Ich habe nicht alles vorinstalliert und suche derzeit die mir fehlenden Komponenten zusammen.

Edit: Es läuft - mir fehlten libcurl und bzlib.

Ich habe jetzt gerade nochmal einen Blick in die Makefile geworfen. Das scheint in diesem Fall mit den Abhängigkeiten doch recht einfach zu interpretieren zu sein.

sudo apt-get install build-essential libgtk2.0-dev libwebkit-dev libbz2-dev curl 

Alle weiteren, benötigten Pakete scheinen als Abhängigkeiten der beiden oben genannten mitinstalliert zu werden.

Ich habe jetzt gerade nochmal einen Blick in die Makefile geworfen. Das scheint in diesem Fall mit den Abhängigkeiten doch recht einfach zu interpretieren zu sein.

Super - Danke. 👍

Magst du den Artikel dahingehend verbessern?

Ich check das mit den Abhängigkeiten nachher nochmal gegen. Dann kümmere ich mich gerne darum, die Änderungen in den Artikel zu übernehmen. 🤓

Klasse. Kompilieren ist nicht meine Welt. ☺ Soll ich den Artikel in die Baustelle verschieben?

Ich habe die Abhängigkeiten einmal in einem blanken Live-System (Xubuntu 12.04.3) getestet - und lag nur mit cURL scheinbar etwas daneben.

Die entsprechenden Änderungen habe ich im Artikel vorgenommen, bin mir allerdings nicht sicher, ob das in dieser Form ausreichend ist. Wenn Kompilieren nicht march's Welt ist, dann ist das erklärende Schreiben darüber nicht meine 😬

Also lest da bitte nochmal drüber.

Edit: Mit Lubuntu 13.04 als Live-System gab es ebenfalls keine Problem.

Ich wollte es jetzt auch mal testen, bekomme aber folgenden Fehler:

sudo apt-get install build-essential libwebkit-dev libgtk2.0-dev libcurl4-gnutls-dev libbz2-dev                                 :(
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
build-essential ist schon die neueste Version.
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libgtk2.0-dev : Hängt ab von: libpango1.0-dev (>= 1.20) soll aber nicht installiert werden
                 Hängt ab von: libcairo2-dev (>= 1.6.4-6.1) soll aber nicht installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Liegt das an meinem System? Eventuell an irgendeinem PPA?

Seit 2013 gibt es keine Änderungen auf Sourceforge und als Status ist dort noch immer Alpha angeben. Archiv?

LG
tuxifreund