staging.inyokaproject.org

stesind schrieb:

versteh die Antwort nicht ganz.

Klar will sich Pidgin nach /usr/local installieren. Leider funktioniert es dann nicht, libpurple wird nicht gefunden. Jedenfalls bei mir und bei etlichen Anderen, wie in den Foren zu lesen war. Ich bin natürlich für eine bessere Lösung dankbar.

Ich wollte nur klarstellen, dass es dir nicht nur um das -fstrans=no geht und du das --prefix=/usr nur bei deiner Recherche "aufgeschnappt" hast.

Klar hab ich das in einem Formum gelesen.

Mir geht es nur darum, dass mit dem Wiki-Artikel reibungslos installiert werden kann. Ob dazu nun wichtig ist klarzustellen, dass ich /usr irgendwo "aufgeschnappt" habe kann jeder selber beurteilen.

Der Abschnitt "Paketquellen der Entwickler" ist nicht mehr gültig. Es gibt keine Pakete für Intrepid dort. Die letzte Version wurde vor über einen halben Jahr eingestellt und ist längst veraltet.

Den kompletten Teil also raus, oder nur den Intrepid Teil? Aber das Hardy Paket ist auch veraltet!

Gruß, Kölly

Ich hatte bei der Kompilierung von Pidgin folgendes Problem:

Nach der Installation kam beim Starten von Pidgin stets die Meldung

pidgin: error while loading shared libraries: libpurple.so.0: cannot open shared object file: No such file or directory 

Die fehlende Datei lag in /usr/local/lib, konnte aber nicht gefunden werden, weil vorher noch der folgende Befehl ausgeführt werden muss:

sudo ldconfig 

Vielleicht kann jemand, der sich besser auskennt, an der richtigen Stelle darauf hinweisen? Ich könnte mir vorstellen, dass das vielleicht eher in Programme kompilieren gehört.

Hallo,

also ich würde einfach die Paketquellen einfach rausnehmen.

Steffen

Koelly schrieb:

Der Abschnitt "Paketquellen der Entwickler" ist nicht mehr gültig. Es gibt keine Pakete für Intrepid dort. Die letzte Version wurde vor über einen halben Jahr eingestellt und ist längst veraltet.

Den kompletten Teil also raus, oder nur den Intrepid Teil? Aber das Hardy Paket ist auch veraltet!

Gruß, Kölly

Hallo Beutlin,

Zu Deiner Frage. Bei mir ist das Selbe aufgetreten. Du hast bestimmmt versucht mit checkinstall ein deb-Paket zu erzeugen und installieren. Mit make install funktioniert es so. Aber dies erzeugt halt kein deb-Paket.

Ich habe es gelöst, indem ich ./configure --prefix=/usr vor dem make ausgeführt habe. Es sorgt dafür, dass das Programm nicht in /usr/local installiert wird, sondern in /usr. Der Paketmanager den Du implizit zum installieren nutzt, sucht in /usr und findet libpurple nicht. Alternativ kannst Du den von March beschriebenen Weg nehmen und einfach einen logischen Link erzeugen, was wahrscheinlich schneller ist. Wenn Du in den von mir Oben angemerkten Forenlink schaus, wirst Du beide Lösungen finden.

Ich denke, das Kompilieren von Pidgin an dieser Stelle zu beschreiben hilft bestimmt vielen. Dagegen spricht, dass das Thema scheinbar so komplex ist, als das es mit einem einfachen Hinweis abgedeckt werden kann.

Steffen

Beutlin schrieb:

Ich hatte bei der Kompilierung von Pidgin folgendes Problem:

Nach der Installation kam beim Starten von Pidgin stets die Meldung

pidgin: error while loading shared libraries: libpurple.so.0: cannot open shared object file: No such file or directory 

Die fehlende Datei lag in /usr/local/lib, konnte aber nicht gefunden werden, weil vorher noch der folgende Befehl ausgeführt werden muss:

sudo ldconfig 

Vielleicht kann jemand, der sich besser auskennt, an der richtigen Stelle darauf hinweisen? Ich könnte mir vorstellen, dass das vielleicht eher in Programme kompilieren gehört.

Also noch mal zum Wiki Artikel.

Ich würde, wenn alle einverstanden sind, folgendes ändern:

1. die Ergänzung reinschreiben, falls jemand mit checkinstall installiert, entweder ./configure --prefix=/usr ausführt oder einen logischen Link anlegt, da es ansonst zu der Fehlermeldung "pidgin: error while loading shared libraries: libpurple.so.0: cannot open shared object file: No such file or directory " kommt. Bei make install bleibt alles beim alten.

2. den Hinweis aufnehmen, dass falls bei checkinstall die betreffende Fehlermeldung auftritt, man den folgenden Aufruf machen sollte: sudo checkinstall -fstrans=no

Sind alle damit einverstanden? Formulier es natürlich noch besser.

Steffen

Nochmal zu meinem (bereits gelösten) Problem: Ich habe Pidgin - wie im Wikiartikel angegeben - kompiliert, mit checkinstall ein deb-Paket erzeugt und dieses installiert. Aber beim Ausführen von Pidgin kam die folgende Fehlermeldung:

pidgin: error while loading shared libraries: libpurple.so.0: cannot open shared object file: No such file or directory  

Lösen konnte ich das Problem, indem ich den Befehl sudo ldconfig gestartet habe. Danach hat alles geklappt.

Ich habe hier einen kurzen Artikel zu ldconfig gefunden, der das vielleicht erklärt: Wenn ein neues Programm installiert wurde und für dieses Programm auch Bibliotheken installiert wurden, kann das Programm zunächst nicht gestartet werden, da die Bibliotheken dem "Runtime Linker" noch nicht bekannt sind. Deshalb muss das Programm ldconfig gestartet werden, um den Cache des "Runtime Linkers" zu aktualisieren.

Das finde ich etwas eleganter als das manuelle Anlegen eines Symlinks. Denn der Vorteil des deb-Paketes liegt ja darin, dass man das Paket auch einfach wieder deinstallieren kann. Ein manuell angelegter Symlink müsste dann aber auch manuell wieder entfernt werden.

Hallo,

ich sehe das auch so. Bleibt für mich die Frage, ob ein selbst erstelltes Deb lieber in /usr oder in /usr/local installiert werden soll. Ich tendiere zu /usr.

Steffen

Hallo,

ich hab mal eine Änderung vorbereitet:

Hinweis: Das Erzeugen des deb-Pakets mit checkinstall birgt einige Fallstricke. Diese werden hier kurz angerissen, für weitere Informationen bitte hier nachlesen: Programme kompilieren. Bei Benutzung von make-install ist dieses nicht notwendig, allerdings wird dann auch kein deb-Paket erzeugt.

Wenn man checkinstall zum Erstellen eines deb-Packetes benutzt, kann der folgende Fehler auftreten: "No such file or directory " und checkinstall bricht ab. Abhilfe schafft das Aufrufen wie folgt:

sudo checkinstall -fstrans=no  

Während der Paketerstellung wird man u.A. nach der Versionsnummer gefragt. Dort kann man eine Epoch-Nummer verwenden, damit die Aktualisierungsverwaltung nicht gleich wieder versucht, die soeben installierte Version zu ersetzen. Beispielsweise könnte: "1:2.5.5" eingetragen werden.

Nach erfolgreicher Installation und Start von Pidgin kann dieser Fehler auftreten:

pidgin: error while loading shared libraries: libpurple.so.0: cannot open shared object file: No such file or directory 

Das liegt daran, dass Pidgin nun in /usr/local installiert ist und das (vorher in /urs installierte) libpurple nicht gefunden wird. Selbst installierten Programme sollten immer in /usr/local oder /opt liegen. Da hier aber ein deb-Paket erzeugt wird, das anschliessend vom Paketmanager installiert wird kann es auch in /usr installiert werden. Das ist das Verzeichnis in das der Paketmanager normalerweise installiert.

Einfach lässt es sich durch folgenden Befehl beheben:

sudo ldconfig 

Oder wenn man in /usr installieren möchte vorher:

./configure --prefix=/usr 

ausführen.

Die Schritte sehen dann bei der Installation eines deb-Pakets in /usr beispielsweise so aus:

./configure --prefix=/usr
make
sudo checkinstall -fstrans=no  

Oder wenn man in /usr/local installieren möchte:

./configure 
make
sudo checkinstall -fstrans=no 
sudo ldconfig 

stesind schrieb:

Bleibt für mich die Frage, ob ein selbst erstelltes Deb lieber in /usr oder in /usr/local installiert werden soll.

Wenn ich den entsprechenden Wikipedia-Artikel lese, würde ich sagen, dass /usr/local passender ist:

/usr/local – distributionsunabhängige lokale Hierarchie. Hier kann und soll die lokale Systemadministration Programme und Daten ablegen, die von der entsprechenden Distribution des jeweiligen Systems unabhängig installiert worden sind, wie etwa selbstkompilierte oder unabhängig von der Distribution heruntergeladene Programme und Dateien.

Andererseits liest man hier:

Lokal installierte Software gehört nach /usr/local und nicht nach /usr, solange sie nicht Software in /usr ersetzen oder erweitern soll.

Ich denke aber, mit /usr/local macht man nichts verkehrt.

Ich hatte übrigens noch ein Problem mit checkinstall: Ich hatte die Version 2.5.5 kompiliert und dementsprechend war die Versionsnummer meines deb-Paketes auch 2.5.5. Im Ubuntu-Repository ist noch eine ältere Version (in meinem Fall 1:2.2.1). Aber die führende Epoch-Nummer ließ die Version im Repository neuer erscheinen und so meldete sich sofort nach der Installation meines deb-Paketes die automatische Aktualisierung. Deshalb habe ich beim Ausführen von checkinstall bei der Versionsnummer die Epoch-Nummer ergänzt (in meinem Fall 1:2.5.5).

Ja genau,

hatte ich auch mal so gemacht, oben in der Beschreibung aber die Version gesperrt. Um den Aufwand bei Neuinstallationen zu minimieren, sollte man lieber die Epochnummer verwenden. Falls die Änderung mal reinkommt, sollte das noch angepasst werden.

Habs gleich mal Oben reingeschrieben.

Ich würde gerne noch folgende Interessante Erweiterungen im Bereich Plugins hinzufügen:

• gfire - Plugin für das XFire Protokoll

• pidgin-musictracker - Plugin für den Status des MusicPlayer

• microblog-purple - Plugin für Microblogs bsp.Twitter

Ich persönlich benutze diese und habe Spass daran. Natürlich würde ich es nicht so eintragen, sondern mit ausgearbeiteten Informationen.

Was denkt Ihr darüber ? Fehl am Platz oder doch was für das Wiki?

Hallo,

das würde dann eine etwas größere Ergänzung werden? Dann ist es sicher sinnvoll, wenn wir den Artikel vorübergehend in die Baustelle verschieben.

Gruß pippovic