libreoffice-5.3.3_1

klimaschreck

Well-Known Member
Hallo zusammen,

ich habe heute die neue Version von libreoffice aus den Ports erstellt (FreeBSD 10.3 auf amd64). Es läuft durch, aber wenn ich libreoffice nutze, z.B. speicher, stürzt das Programm ab. Bei einem fertigen libreoffice Paket passiert dasselbe.

Die Fehlermeldung lautet: Durch einen unerwarteten Fehler ist LibreOffice abgestürzt. Alle Dateien, an denen Sie gearbeitet haben, werden gespeichert. Beim nächsten Start von LibreOffice werden Ihre Dokumente automatisch wiederhergestellt.

Habt ihr eine Idee? Ich habe libreoffice mit truss gestartet. Dort habe ich nur die Zeile "
Fatal exception: Signal 6" als Fehler erhalten.
 
Vielen Dank für den Hinweis, aber das war es wohl nicht. Zum einen startet libreoffice bei mir. Zum anderen habe ich das Verzeichnis, wie im Link beschrieben verschoben, aber es stürzt weiterhin ab.
 
Bei einem fertigen libreoffice Paket passiert dasselbe.

Meine eigene Version ist deutlich älter. Ich nutze den Quarterly-Branch. Der ist meines Wissens nach auch Default eingestellt. Ich muss mal eben nachsehen, Version: 5.2.6.2. Das sollte eigentlich aktuell sein.

Das würde dann bedeuten, dass es bei dir den gleichen Fehler erzeugt, wie die neuere Version aus den Ports (die ich bei mir nun nicht eigens nachgeschaut habe) und das wiederum würde ja den Verdacht nahe legen, dass der Fehler nicht aus dem aktuellen LibreOffice kommt, das du aus den Ports gebaut hattest, sondern irgendwo anders liegt. Da ist guter Rat echt schwer.
Wenn der Fehler immer beim Speichern auftritt, könnte vielleicht etwas am Speichermedium und/oder den Rechten für den Speicherort nicht stimmen.
Wird das .lock-File artig angelegt? Das wäre dann schon mal ein Hinweis, dass im Arbeitsverzeichnis geschrieben werden kann.
Laufen automatische Sicherungen während der Arbeit? Wie ist es mit "exportieren" und "speichern unter"? Nicht, dass ich kluge Empfehlungen hätte, die von der Beantwortung dieser Fragen abhängen, dann würde ich das sofort sagen. Nur mal als Hinweis, was ich so probieren würde um vielleicht etwas zu verstehen.

Im Zweifel würde ich da auf Versionskonflikte tippen, wenn du Pakete und Ports gemischt benutzt. Der erste Reflex war natürlich, dass die neuere Version aus den Ports einfach einen Fehler hat, aber du sagtest ja, die Paketversion machte das ebenfalls. Da kann fast nur was drum herum nicht stimmen.
 
man truss ->
The truss utility traces the system calls called by the specified process
or program. Output is to the specified output file, or standard error by
default. It does this by stopping and restarting the process being moni‐
tored via ptrace(2).
 
Ah, Danke.

Hast Du mal die Hardware geprüft, einen pkg check gemacht und ggf. die Pakte einfach alle neu installiert?
 
pkg check -Ba gibt folgendes aus:

Code:
(libreoffice-5.3.3_1) /usr/local/lib/libreoffice/program/libofficebean.so - required shared library libjawt.so not found

allerdings ist libjawt vorhanden im Verzeichnis /usr/local/openjdk8:

Code:
./jre/lib/amd64/libjawt.so
./lib/amd64/libjawt.so
 
Du hast ja sicher irgnendeinen Grund, warum du gerade dieses LibreOffice haben möchtest und warum du das aus Ports bauen willst.
Ohne das zu hinterfragen, kann ich dir berichten, dass ich letztens eine sehr alte Version von LO auf meinem 32Bit Asus fand und mit der konnte ich etwas nicht machen, was ich wollte. Also ich nach "Latest" umzog und nur die neuere Version von LO installierte, funktionierte die nicht. Das wunderte mich natürlich nicht weiter und ich zögerte auch nicht, das komplette System zu pkg upgraden. Mit Paketen geht das nämlich ratzfatz, also auch auf dem kleinen Asus EEE in vertretbar kurzer Zeit.
Wenn du also nicht unbedingt an deinen Gründen festhalten möchtest, dann würde ich das mal versuchen.
Gar keine Fehlersuche und keine Experimente.
Entscheiden, wo man stehen will, also "Latest" oder "Quarterly", /etc/pkg/FreeBSD.conf entsprechend anpassen und dann einfach mal einen pkg upgrade wagen.
Dabei werden alle Pakete auf dem System berücksichtigt (auch solche, die aus den Ports gebaut wurden). Du erhältst dann ein System, das wieder konsistent auf dem Stand des jeweiligen Zweiges sitzt. Dann kannst du mit viel größerer Sicherheit sagen, woher mögliche Probleme vielleicht kommen.
Darauf aufsetzend kannst du dann einzelne Ports manuell bauen und testen.

Die Fehlermeldung aus pkg check ist für mich unbedeutend, denn ich habe das auch für ApacheOpenOffice (nicht für LO!) und es funktioniert trotzdem. Ich nutze es aber nur als Fallback, falls LO mal versagt (was lange schon nicht mehr vorkam).
Da könnte ich mir vorstellen, dass das Programm nicht weiß, dass es bei openjdk nachsehen soll. Es gibt ja unterschiedliche Versionen und die wohnen in unterschiedlichen Verzeichnissen und hier will womöglich das Programm an einem anderen Ort etwas sehen. Ein Link könnte da helfen, wenn man denn wüsste, wo das Programm gerne nachsehen will, bzw, welche Version von Java es denn gerne hätte.
Grundsätzlich sollte LO auch vollkommen ohne Java und Java-Unterstützung laufen. Das habe ich früher oft weggelassen, um die Bauzeit zu verkürzen.
 
Ich möchte funktionierende Versionen haben. libreoffice sollte eigentlich auch auf meinem Rechner laufen. Nur erhalte ich keine Fehlermeldung, deshalb bin ich ratlos (OpenGL ist abgeschaltet).

Fertige Pakete kann ich aber nicht komplett übernehmen, da ich mitunter die Optionen anders gesetzt habe.

Wenn es kleine Lösung für mein Problem mit der Version 5.3.3. gibt, werde ich die alte Version 5.2.7. wieder installieren.
 
mit Ports ist das Verwalten der Versionen nochmal etwas schwieriger, aber nicht unmöglich.
Also, in der Annahme, dass es hier um Versionskonflikte geht.
Die bsdadminscripts von Kamikaze sind da immer noch sehr hilfreich, inzwischen in Version 2 verfügbar und darin nenne ich mal pkg.libcheck, ohne Garantier für die Korrektheit der Schreibweise.
Beim Bau der Ports helfen portupgrade oder portmaster.
Trotzdem ist es extrem wichtig, die Ports immer aktuell zu halten und dann nicht nur einzelne Ports alleine neu zu bauen, sondern eben auch alle Abhängigkeiten. Ich weiß natürlich nicht, ob du das alles gemacht und welche Befehle du eingesetzt hast.
Und dennoch wird das System im Laufe der zeit immer unsauberer werden und deshalb gilt, wenn jemand wirklich umfangreich Ports bauen will, dass er lieber poudriere in einer Jail nutzen möge, die dann sauber bleiben kann, weil nichts auf ihr selbst installiert oder deinstalliert wird.
Es ist sehr viel Aufwand, ein System über lange Jahre sauber aus den Ports zu bauen und aufrecht zu erhalten. Das ist weitaus mehr, als gelegentlich mal ein make install clean anzuwerfen.
Mit Paketen habe ich selbst schon lange Erfahrungen gemacht, schon vor pkgng. Obwohl die Optionen mir manchmal nicht passen, nutze ich doch soweit es geht Pakete, weil es eben sehr viel einfacher und schneller läuft. Gerade bei Mammut-Ports wie LO haben wir doch auch schon früher verschiedene Helden gehabt, die uns kostenlos und Frei ihre Pakete zur Verfügung stellten, damit wir eben nicht diese Giganten selbst bauen mussten. Es war immer ein Horror-Trip, diese Dinge selbst zu versuchen.
Also, ich würde da immer versuchen, Pakete zu nutzen.
Aber das Paket alleine hatte bei dir ja keinen Erfolg. Es muss wohl noch etwas mehr in Sync gebracht werden.
 
Hallo @klimaschreck

ich habe mal auf meinem Notebook (aktuelles FreeBSD 11 RELEASE mit KDE4) Libreoffice 5.3.3_1 gebaut, geändert habe ich bei den Optionen:
- gtk
+ kde
+ java

Nun habe ich übrigens auch eine /usr/local/lib/libreoffice/program/libofficebean.so, die hatte ich mit dem Binary mangels java-Unterstützungt nicht
Aber Deinen Fehler kann ich nicht reproduzieren, auch mit Java-Unterstützung startet bei mir Libreoffice und lässt sich bedienen. Dateien speichern geht auch.

Viele Grüße,
Holger
 
Hallo @klimaschreck

ich habe mal auf meinem Notebook (aktuelles FreeBSD 11 RELEASE mit KDE4) Libreoffice 5.3.3_1 gebaut, geändert habe ich bei den Optionen:
- gtk
+ kde
+ java

Nun habe ich übrigens auch eine /usr/local/lib/libreoffice/program/libofficebean.so, die hatte ich mit dem Binary mangels java-Unterstützungt nicht
Aber Deinen Fehler kann ich nicht reproduzieren, auch mit Java-Unterstützung startet bei mir Libreoffice und lässt sich bedienen. Dateien speichern geht auch.

Viele Grüße,
Holger
Kannste ja vielleicht auch mal noch einen pkg check drauf loslassen, würde mich interessieren, ob der bei dir die gleiche Fehlermeldung bringt. Dann könnten wir vielleicht schlussfolgern, ob es damit etwas zu tun hat oder nicht.
 
PS:
die zwei häufigsten Fehler bei Benutzung der Ports, die ich seinerzeit immer wieder machte, war das nicht Beachten der UPDATING und das Bauen von Ports in einem inkonsistenten Zustand des Portstree. Das heißt also, mein System war zB gebaut im Januar, im April aktualisierte ich dann die Ports und baute einzelne Programme neu, ohne zuvor den kompletten Rest des Systems neu aus dem gleichen Portstree gebaut zu haben. Mit Tools wie portsmaster kann man das automatisiert erledigen und nur die tatsächlich erneuerten Ports mit ihren Abhängigkeiten neu bauen lassen. Es ist eben ein riesiger Aufwand, der aber natürlich trotzdem von Zeit zu Zeit ansteht. Bei mir waren das oft Tage bis Wochen, die der PC nur mit Aktualisierung befasst war. Und das ist nicht zu reduzieren, auch nicht, wenn man häufiger Updates macht, denn es gibt solche Hammer-Anwendungen, die einfach Abhängigkeiten zu über 60% oder 70% aller installierten Anwendungen haben und dann quasi bei Veränderung immer auch einen kompletten Neubau nach sich ziehen.

Ich würde fast wetten wollen, dass der Fehler hier irgendwo liegt oder durch Mischen von Paketen und Ports sich eine Inkonsistenz eingeschlichen hat.
 
Ich hatte libreoffice mit portmaster erstellt.

So, nun habe ich libreoffice mit pouderie gebaut (399 Pakete). libreoffice stürzt weiter ab, wenn ich z.B. Speichere oder die Optionen aufrufe. Ich gebe nun auf und installiere die alte Version wieder.
 
Ich habe portmaster nie ausgiebig benutzt und stattdessen die Befehle mit portupgrade parat. portmaster hatte etwas andere Optionen, aber im Grunde vergleichbar.
Was ich denke, was du machen müsstest, das wäre das Äquivalent zu:
# portsnap fetch update && portupgrade -ack

portupgrade würde mit diesen Optionen alle installierten Ports upgraden, sprich neu bauen, dabei zuvor die Liste der Optionen durchgehen und bei einem Port, dessen Bau misslingt, nicht stehen bleiben, sondern weiter laufen.

Des weiteren etwas in der Art:
# pkg_libchk -q | xargs -o portupgrade -fu

pkg_libchk würde Ports finden, deren Libraries unerfüllte Abhängigkeiten aufweisen und mit xargs übergibt man diese Kandidaten an portupgrade, das diese auch dann neu baut, wenn bereits die aktuelle Version vorhanden ist (-f) und wenn ich jetzt nicht irre, die Paketdatenbank dazu updatet, aber ich bin mit den -u unsicher.

Insgesamt zögere ich aber, diese befehle überhaupt zu veröffentlichen, weil ich sie so lange nicht mehr gebraucht habe (FreeBSD 8.4). Da könnte sich was geändert haben und ich habe nicht aktuell nachgelesen. Das soll auch eher eine Idee vermitteln, was ich damit meine, dass das System komplett in Sync gebracht werden muss und nicht nur an einer Anwendung probiert wird.

Gerade nun, wo du schreibst, dass mit poudriere 399 Pakete gebaut wurden, kannst du wohl nicht sicher sein, welchen Stand dein System eigentlich hat. Wenn du diese 399 Pakete genommen und eingebaut hast, sind bestimmt noch eine Menge andere vorhanden, die du nicht erneuert hast.
Wenn du poudriere in einer Jail sitzen hast und wenn alle Optionen nach deinen Wünschen gesetzt sind, dann lasse alle von dir benötigten Anwendungen dort bauen und installiere sie alle in deinem System. Vollkommen egal, ob LO anschließend geht oder nicht, du brauchst Ordnung im System, wenn du es noch lange Zeit erhalten willst. Ein gängiges Konzept, das Ordnung schafft und erhält, ist dazu der einfachste Weg und den hast du nun mit poudriere ja schon beschritten.
 
Ich habe portmaster nie ausgiebig benutzt und stattdessen die Befehle mit portupgrade parat. portmaster hatte etwas andere Optionen, aber im Grunde vergleichbar.
Was ich denke, was du machen müsstest, das wäre das Äquivalent zu:
# portsnap fetch update && portupgrade -ack

portupgrade würde mit diesen Optionen alle installierten Ports upgraden, sprich neu bauen, dabei zuvor die Liste der Optionen durchgehen und bei einem Port, dessen Bau misslingt, nicht stehen bleiben, sondern weiter laufen.
...

Hey Pit!

wer -wie ich- oft zu faul ist, die man-pages zu lesen und dann ewig genervt ist,
dass z.B. portupgrade immer wieder irgendwo stehen bleibt,
weil irgendwelche Optionen abgefragt werden,
man dies aber oft stundenlang gar nicht bemerkt weil man nicht am Terminal sitzt oder weil
portupgrade in nen urxvt-window im Hintergrund werkelt ,,, der ist fuer "-ack" sehr dankbar :D

vor allem fuer das -c von dem die man-page (die ich jetzt tatsaechlich mal gelesen hab) sagt:

-c Run “make config-conditional” before everything for all tasks.

Gruss walter
 
Die drei Klassiker portmanager, portmaster und portupgrade sind de facto tot. Keines der 3 Tools hat jemals den Sprung in die pkg-Ära geschafft. Sie lösen zum Beispiel Abhängigkeiten selbst auf Basis der Port-Makefile auf, anstatt pkg zu nutzen. Das führt dann regelmäßig zu Chaos. portupgrade nutzt noch immer eine eigene Datenbank, was zu Split-Brain-Situationen führt; portmaster schreibt Einträge für die Datenbank der alten pkg_* Tools nach /var/db/pkg... Vor allem bauen sie alle nicht in einer sauberen Umgebung, stattdessen einfach im laufenden System und haben die Staging-Stufe nicht wirklich integriert. Viele Ports schlagen daher grundlos fehl, was immer wieder zu nicht reproduzierbaren Bugreports führt. Es gab auf freebsd-ports@ daher letztens eine Diskussion, ob man die 3 Tools nicht endlich offiziell als überholt erklären und in naher Zukunft entfernen sollte.

Also: Tut euch selbst den Gefallen und nehmt poudriere oder das schlankere, mehr an portmaster angelehnte synth. Ja, man muss etwas umlernen, aber als Ergebnis bauen die Ports dann auch zuverlässig.
 
...Tut euch selbst den Gefallen und nehmt poudriere oder das schlankere, mehr an portmaster angelehnte synth. Ja, man muss etwas umlernen, aber als Ergebnis bauen die Ports dann auch zuverlässig.

Hmm ... das "umlernen" sollte da nun nicht so das Problem sein.

Problematischer sehe ich den Umstand, dass -wenn, wie bei mir-,
vorher klassisch mit make install clean einige Ports erzeugt wurden, andere als Binaries mit pkg install geholt wurden...
auf jeden Fall ein "unsauberes System" vorliegt.
man muss nurmal schauen, was bei einem Bau von vim mit der default-config so alles installiert wird...

Egal ob nun zukuenftig poudriere oder synth zum Einsatz kommen wird ... es bedeutet:
System platt machen - und alles neu ;'(
 
Egal ob nun zukuenftig poudriere oder synth zum Einsatz kommen wird ... es bedeutet: System platt machen - und alles neu ;'(
Aber ganz sicher nicht! Wie kommst du darauf? Wir sind hier nicht bei Linux :D

FreeBSD trennt wunderbar zwischen Basesystem und Ports! Du kannst alle Ports problemlos löschen und wieder von Null beginnen.

Liste der Pakete erstellen:
Code:
pkg query -e "%a == 0" "%n" > /root/pkgliste.txt
Alle Pakete löschen und /usr/local entfernen:
Code:
pkg delete -a
rm -rf /usr/local/*
PKG neu installieren:
Code:
pkg-static install pkg
pkg update -f
Pakete wieder installieren:
Code:
xargs pkg install < /root/pkgliste.txt
Sollte so grundsätzlich gehen. Trotzdem bitte zuerst einen Snapshot/Backup machen!
 
Oh Danke @foxit - das ist wirklich sehr ausfuehrlich,
nett von Dir, dass Du das hier so umfassend dargestellt hast.
 
Problematischer sehe ich den Umstand, dass -wenn, wie bei mir-,
vorher klassisch mit make install clean einige Ports erzeugt wurden, andere als Binaries mit pkg install geholt wurden...
auf jeden Fall ein "unsauberes System" vorliegt.

Das muß ja nicht "unsauber" sein. Es wird nur unsauber, wenn Du z.B. "quarterly" Pakte mit "latest" Portstree nutzt, aber das nächste "pkg upgrade" klopft Dir die Dellen wieder gerade.
 
Guckst du hier: https://github.com/jrmarino/synth Ist recht schnuckelig, weil es zugänglicher und schlanker als Poudriere ist. Ist aber derzeit auf 12-CURRENT kaputt, weil der ino64-Merge eine Runtime zerdeppert hat, die es braucht.
 
Zurück
Oben