Opensuse 12.3 – OpenClipart-Definitionen für Libreoffice unvollständig

Posted on by

Ich habe ja vor kurzem auf zwei Systemen Opensuse 12.3 installiert. Im Zuge davon habe ich auch ein Update der Libreoffice-Installation vorgenommen. Danach wollte ich im Rahmen eines Projektes mit Hilfe der Clipart-Gallery ein paar Draw-Zeichnungen anfertigen. Die notwendigen Clipart-Pakete

  • libreoffice-openclipart
  • openclipart-svg (in der Version 0.18

hatte ich natürlich installiert.

Zur Voransicht der Cliparts gibt es in den Libreoffice-Anwendungen ein Fenster, in dem die Cliparts nach thematischen Bereichen gegliedert dargestellt werden. Soweit ich mich erinnern kann, hatte ich dort zumindest in einer OS 12.1 / LibreOffice 3.5-Installation für alle Themenbereiche der Gallery auch eine Voransicht zugehöriger Ciparts gefunden.

Leere Ansicht für viele Gallery-Themenbereiche unter OS 12.2 und OS 12.3

Leider wird nun für die meisten thematischen Gallery-Bereiche in Libreoffice 3.5 bis 4.0.2 unter Opensuse 12.2 oder Opensuse 12.3 gar nichts mehr angezeigt. Beispiele liefern "Science" oder "Shapes" ; im Gallery-Fenster ist zu beiden Themenbereichen kein Clip zu sehen:

gallery_leer_600

Das ist ein typischer Mangel an qualitätsgesicherter Paket-Aufbereitung, wie er mich an der Verbreitung von Opensource-Produkten durch einige Distributoren manchmal an den Rand der Verzweiflung treibt. Was macht denn eine normaler Anwender bei einem solchen Befund? Er zuckt mit den Achseln, wundert sich und geht davon aus, dass es da halt keine Bilder gibt. das ist zugleich falsch und schade!

Eine Fehlersuche zeigt, dass es im Verzeichnis /usr/lib64/libreoffice/share/gallery/ Softlinks auf *sdg-Dateien gibt, die im korrespondierenden Verzeichnis /usr/share/libreoffice/share/gallery/ leider ins Nirwana führen. Für die entsprechenden Themenbereich wird in der Clipart-Ansicht der Libre-Office-Bereiche deshalb nichts angezeigt, obwohl im thematischen Subverzeichnis unter /usr/share/openclipart/ haufenweise svg-Dateien vorhanden sind.

Ein Blick in die Verzeichnisliste des Openclipart-Pakets von Opensuse zeigt, dass die beschreibenden "sdg"-Dateien für viele Themenberieche tatsächlich nicht ausgeliefert werden – also bereits im RPM-Paket von Opensuse selbst fehlen. Warum auch immer …. Ein Bug?

Eine parallele Windows-Installation ist wenigstens ehrlicher – die bietet von Haus aus nur wenige gefüllte Themenbereich an. Den Rest muss man sich sowieso selbst zusammenstellen.

OpenClipart-Download als Alternative ? Nein !

Alternativ und naiv dachte ich nun daran, mir etwas von der OpenClipart-Seite im Web herunterzuladen. Da wurde alles nur schlimmer; ein Download aktuellerer Clipart-Pakete ab Version 0.19 führt in den Abgrund.

Man erhält dann nämlich keine vorsortierte thematische Zusammenstellung an Files mehr, die man in ein Subverzeichnis von "/user/share/clipart/" einfügen könnte. Stattdessen kommen HTML-Dateien mit Bildern aus einem Verzeichnis, das nach allen möglichem (u.a. Autoren) aber nicht thematisch untergliedert ist. Vielmehr wird hier eine komplexe Installation von HTML-Seiten mit PHP-MySQL-basierter Suchmaschine erwartet. Leider funktioniert das vorgesehen “make install” unter OS 12.3 gar nicht. Schauder … – in dieser Form ist OpenClipart 2.x weder für LibreOffice noch sonst irgendwie brauchbar. Keine Zeit, mich damit zu befassen. Ich will doch nur ein paar faktisch vorhandene Cliparts unter Libreoffice sehen und nutzen!

Workaround

Ich habe dann versuchsweise Libreoffice komplett deinstalliert, alle zugehörigen Konfigurationsdateien in meinem Home-Verzeichnis entfernt und Libreoffice neu installiert. Das half leider auch nichts. Aus Zeitmangel habe ich nun einen Workaround per Handarbeit vorgenommen:

Schritt 1: Man muss in Libreoffice im Gallery-Fenster selbst ein neues Thema zu einem der vorhandenen thematischen, aber leider als leer angzeigten Bereiche wie “Shapes” anlegen. Ich gebe dem neuen Thema z.B. den Namen "shapes_2".

Schritt 2: Im Subdialog-Fenster zu diesem neuen Thema lässt man im thematischen Unterverzeichnis von /usr/share/openclipart/ [hier also im Verzeichnis "/usr/share/clipart/openclipart/shapes/" ] alle passenden Dateien zusammensuchen, markiert dann alle oder eine Unterauswahl und drückt auf den Button "Hinzufügen". Die Anzeige des folgenden kleinen Dialoginhalts ist unter meinem KDE 4.10 dann leider nicht vollständig zu erkennen – aber man wartet einfach, bis der Übernahmeprozess erfolgt ist.

Schritt 3: Das Ergebnis sind dann 3 Dateien unter /home/USER/.config/libreoffice/4-suse/user/gallery/ (USER ist dabei dein Username):

  • sgxxx.sdg,
  • sgxxx.thm,
  • sgxxx.sdv

xxx steht dabei für eine 2- oder dreistellige Ziffer. Das eben installierte Clipart-Thema hat die höchste Nummer.
Man wird in unserem Beispiel feststellen, dass Libreoffice nun im Gallery-Fenster unter "shapes_2"alle svg-Dateien von "/usr/share/clipart/openclipart/shapes/" tatsächlich anzeigt. Die drei beschreibenden Dateien, im besonderen die sdg-Datei, sind dafür hinreichend.

Schritt 4:
Nun ermittelt man unter Libreoffice im Galleryfenster durch einen Rechtsklick auf das ursprüngliche “Shapes” dessen "Eigenschaften". In einem Dialofenster wird u.a. ein File-Pfad und ein File-Name einer zugehörigen Deskriptionsdatei sgxxx.sdg angezeigt – bei mir ist Shapes z.B. mit dem File "sg85" assoziiert.

Man fertige nun eine Kopie der obigen drei Dateien sgxxx.sdg, sgxxx.thm, sgxxx.sdv an und benenne die Ziffern "xxx" in "85" (bzw. die eben ermittelte Nummer) um. Danach verschiebe man diese deskriptiven Dateien als root (!) in das Verzeichnis "/usr/share/libreoffice/share/gallery/". (Root-rechte sind dort zum Schreiben erforderlich.

Danach funktioniert auch die Anzeige der Dateien unter dem ursprünglichen Themenbereich "Shapes" und nicht nur unter "shapes_2".

gallery_voll_600

Den für den Workaround angelegten Themenbereich "shapes_2" kann man nun eigentlich auch löschen löschen. Ich würde ihn aber behalten, da die Deskriptonsdateien für "Shapes" bei einer Neuinstallation der Opensuse-RPMs möglicherweise wieder gelöscht werden. Dann kann seine alte Auswahl im Eigenschaftsdialog von shapes_2 aktualisieren lassen und wie oben beschrieben weiterverfahren.

Nach diesem kleinen Desaster zur Korrektur einer unvollständigen OpenClipart-V18–Installation unter Opensuse 12.3 bleibt abzuwarten, wie Opensuse und LibreOffice mit der Integration von OpenClipart-Galleries der aktuellen Versionen 0.19 und 2.X umgehen werden.

Opensuse 12.2 – textbasierter Boot Screen ohne Plymouth Animation

Posted on by

Leider ist unter einem aktuellem Suse oder Red Hat System Plymouth so stark in das Gespann grub2 und systemd integriert, dass ich mich eher davor hüte, alle Plymouth bezogenen Pakete zu deinstallieren. Nebenbei: Inzwischen ist wohl auch unter Ubuntu eine starke Einbindung von Plymouth in die Prozesse beim Systemstart vorgenommen worden. Siehe: http://ubuntuforums.org/showthread.php?t=1457388

Dennoch kommt ab und zu der Wunsch auf, den animierten Plymouth-Splash-Screen während des Boot-Vorgangs los zu werden, um ohne Umwege die Boot-Meldungen sehen zu können. Diesen Wunsch hatte zumindest ein Admin, der mich vorgestern per Mail anschrieb.

Auf meinen Opensuse 12.2-Systemen mit Grub2 half hier folgendes Vorgehen:

Deaktivieren des animierten Plymouth-Boot-Screens mit Hilfe von YaST2

Man öffne unter YaST2 das Modul “Boot Loader”. Im sich öffnenden Fenster gehe man zum Button “Boot Loader Options”. Das nächste Fenster zeigt eine Zeile zu Kerneloptionen:

no_plymouth_600

In dieser Zeile setzt man

splash=0

ein. Zudem entfernt man ein evtl. vorhandenes Schlüsselwort “quiet”. In Fall meines betrachteten Systems lautet die fertige Zeile dann:

video=1920×1200 resume=/dev/disk/by-id/scsi-3600050e004a669001c4b00002aaf0000-part1 splash=0 showopts

Auf anderen Systemen wird natürlich das Resume-Device für den Swap-Bereich eine andere Bezeichnung haben. Danach schließt man sukzessive die YaST2-Fenster.

YaST2 speichert die eben angegebenen YaST2-Bootloader-Daten übrigens in der Datei “/etc/default/grub” ab. Es lohnt sich, bei Gelegenheit mal einen Blick in diese Datei zu werfen! In dieser Datei kann man Basisoptionen für Grub2 hinterlegen. Auch ganz ohne YaST2, wenn es ein muss.

Auf dem hier veränderten System sieht die Datei dann so aus:

GRUB_DISTRIBUTOR=openSUSE
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=300
GRUB_CMDLINE_LINUX_DEFAULT=” video=1920×1200 resume=/dev/disk/by-id/scsi-3600050e004a669001c4b00002aaf0000-part1 splash=0 showopts”
# kernel command line options for failsafe mode
GRUB_CMDLINE_LINUX_RECOVERY=”showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe”
GRUB_CMDLINE_LINUX=””
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD …)
#GRUB_BADRAM=0x01234567,0xfefefefe,0x89abcdef,0xefefefef
# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=gfxterm
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command "vbeinfo"
GRUB_GFXMODE=auto
# Uncomment if you don’t want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_LINUX_RECOVERY=true
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png

Die dortigen Infos werden dann von einem der Scripts unter /etc/grub.d aufgegriffen, sobald YaST2 im Hintergrund
zusätzlich
grub2-mkconfig -o /boot/grub2/grub.cfg
ausführt, um die eigentliche grub2-Konfigurationsdatei unter /boot/grub2/grub.cfg erstellen zu lassen. Dort findet man die getroffenen Einstellungen letztlich natürlich auch wieder.

Bootet man nun neu, fährt das System dann schön im Textmodus hoch und man kann einen Blick auf die schnell vorbeiziehenden Meldungen von systemd und den gestarteten Applikationen zum Bootvorgang werfen.

——–
Drei ergänzende Hinweise

Hinweis 1:Grub 2
Nebenbei haben wir mal wieder gelernt, dass Grub2 relativ kompliziert – nämlich teils über die über die “/etc/default/grub”, teils über Script-Dateien – zu konfigurieren ist. Hierzu ein paar Links;
http://www.dedoimedo.com/computers/grub-2.html
http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/grub2.html
http://manual.siduction.org/de/sys-admin-grub2-de.htm

Hinweis 2: Etwas Tipparbeit beim Umgang mit grub2 sparen
Übrigens (off topic):
Um beim Experimentieren mit Grub etwas Tipparbeit zu sparen und eine Ähnlichkeit mit (älteren) Debian-Derivaten herzustellen, kann man sich unter SuSE einen abgekürzten Befehl “update-grub” als Skript (an geeigneter Stelle im Suchpfad) hinterlegen:

#!/bin/sh
set -e
exec grub2-mkconfig -o /boot/grub2/grub.cfg “$@”

Wer sich über das “$@” wundert: grub2-mkconfig hat z.Z. zwar nur 3 Parameter, kann ja aber künftig noch mehr bekommen:

mysystem:~/bin # ./update-grub -v
grub2-mkconfig (GRUB2) 2.00
mysystem:~/bin # ./update-grub -h
Usage: grub2-mkconfig [OPTION]
Generate a grub config file
 
-o, –output=FILE output generated config to FILE [default=stdout]
-h, –help print this message and exit
-v, –version print the version information and exit
 
Report bugs to <bug-grub@gnu.org>.
mysystem:~/bin #

Hinweis 3: Kein graphischer Grub2-Bildschirm
Übrigens: Will man neben Plymouth auch den grafischen Grub2-Schirm loswerden, so muss man im oben dargestellten YaST2-Fenster den Haken bei der Option “use graphical console” entfernen. Dies führt dann zu einem Eintrag “GRUB_TERMINAL=console” in der “/etc/default/grub”.

OX 6 – Upgrade von OX 6.20.7 auf OX 6.22.1 unter OS 12.2

Posted on by

Habe mich seit längerem nicht mehr um Upgrades des bei mir unter Opensuse 12.2 laufenden OX 6 kümmern können. Mein letzter Schritt war im letzten Jahr ein Update auf die Version 6.20.7 gewesen. Seitdem hat sich doch einiges geändert und demnächst steht auch die OX 7 App Suite vor der Tür.

Mögliche Upgrade-Pfade

Laut den Infos auf den einschlägigen Open-Xchange Webseiten sind folgende Upgrade-Pfade vorgesehen:

  • v6.20.7 auf v6.22.0 (man beachte die 0 bei der 6.22-er version!)
  • v6.22.x auf OX App Suite 7

Siehe hierzu:
http://oxpedia.org/wiki/index.php?title=Update_to_6_22
http://oxpedia.org/wiki/index.php?title=AppSuite:Upgrade_from_6.22_for_SLES11

Alle Wege führen also zwingend über die Version 6.22.0 !

Version 6.22 klingt harmlos. Diese Applikation bringt allerdings gegenüber den Versionen 6.20.X wesentliche Neuerungen mit sich. Insbesondere die Aufsplittung der Repositories für Server-Komponenten und das Ajax-Frontend. Zudem werden die bisher 2 Dämonen zum Starten des OX6-Systems zu einem zusammengefasst. Es verschwinden auch etliche der vielen bisherigen Pakete. Offenbar werden hier Änderungen vorgenommen, die in eine noch stärkere Rollenaufteilung zwischen einem komponentenbasierten Backend und mehreren unterschiedlich ausgeprägten Frontends in der App Suite münden werden.

Das machte mir dann doch ein wenig Angst vor einem Update des OX6 unter Opensuse 12.2. Die zugehörigen Infos in den OX-Webseiten entsprechen mehr denen eines echten Upgrades als eines kleineren Updates. Aber die nachfolgende Abbildung beweist, dass alles am Schluss glatt lief. Gezeigt wird der Blick von Kontact/Korganizer auf Kalender-Einträge auf meinem OX6 v6.22.1.

ox622_cal_600

Dennoch gab es ein paar kleinere Hürden zu überwinden, auf die ich nachfolgend eingehe.

Fehlendes Opensuse 12.2 Repository für die als Zwischenschritt erforderliche OX-Version 6.22.0

Unter den Repositories für Opensuse 12.2 findet man zwar bereits ein Verzeichnis für die App Suite. Das enthält aber noch keine Dateien. Also wollte ich auf meinem Opensuse 12.2-System zunächst nur das sowieso erforderliche Upgrade auf die Version v6.22 vornehmen.

Nun drohte dieses Vorhaben daran zu scheitern, dass sich im Moment kein Opensuse 12.2 Repository mit RPMs zur OX Version 6.22.0 mehr finden lässt. Vorhanden ist nur ein Repository zur Version v6.22.1. Dorthin führt aber z.B. von OX 6 V6.20.7 kein direkter Weg !

Umweg über ein 6.22.0 Repository für den SLES 11

Ich habe dann notgedrungen das Experiment gewagt, ein Repository für den SLES 11 zu benutzen. Ein solches Vorgehen ist nicht risikofrei. Bevor andere das nachmachen, empfehle ich unbedingt ein Backup der OX6 Datenbank auf seinem MySQL-Server, ein Backup der OX6-Verzeichnisse auf dem Apache-Server und ein Backup der OX6-Dateien – bei mir unter “/opt/open-xchange”.

Das von mir genutzten SLES11-Repositories findet man unter:
OX 6.22.0 Backend: http://software.open-xchange.com/OX6/6.22/6.22.0/backend/SLES11/
OX 6.22.0 Frontend: http://software.open-xchange.com/OX6/6.22/6.22.0/
frontend/SLES11/

Diese Repositories bindet man in die Paket-Verwaltung unter YaST2 ein. Unter YaST2’s Software-Update-Modul wechselt man dann am besten in die Ansicht für die “Installationsquellen”. Dort prüfe man für das Repository zum OX6-Backend und im Repository zum Frontend, welche Pakete als update-fähig angezeigt werden und hake die Einträge entsprechend ab. (Weiter unten findet man 2 Listen zu den erforderlichen Paketen). Man wundere sich beim Auflösen der Paketabhängigkeiten durch YaST2 nicht, dass dann sehr viele alte Pakete für als zu löschen markiert werden. Das hat tatsächlich seine Richtigkeit!

Ändern des OX6-Daemon-Starts über den Run-Level-Editor

Nachdem der Update gelaufen ist, muss man den Start des OX6-Daemons ändern. Die ursprünglich 2 Dämonen für die OX6-Groupware und die OX6-Administration sind nun zu einem Dämon zusammengezogen worden. Man nimmt die Änderungen am schnellsten über den YaST2-Runlevel-Editor vor. Ja, das geht auch unter den neuen systemd-Verhältnissen. YaST2 übersetzt die alten sysvinit-Angaben für diese konventionellen LSB-Applikationen unter systemd schon passend:

update_ox622_daemon_600

Nach dem Update funktioniert der OX6-Login über die Web-Oberfläche erstmal nicht – 503-Fehler

Hat man den OX6-Groupware-Server dann erneut gestartet, darf man sich ein kleines Frustrationserlebnis abholen. Versucht man sich nach den bisherigen Operationen auf dem OX6-Server über die OX6-Weboberfläche einzuloggen, so geht das schief. Egal, welchen User man probiert, man erhält eine “503-Meldung”: “Service temporarily not available”.

Zusätzlich tauchen in den OX6-Logs Fehlermeldungen zu fehlenden Sprachfiles auf.

Bevor du nun das Fluchen anfängt:
Prüfe erstmal, ob die Anbindung der Kalender-Clients unter OX6 funktioniert! Von dort klappt nämlich die Anbindung zum backend anstandslos, wie ich überrascht feststellen musste. So schlimm konnte der Fehler also nicht sein. Einige Minuten später stellte sich nach einem Blick auf den Webserver folgendes heraus:

Der Fehlschlag mit der OX6-Web-GUI liegt daran, dass für das 6.22-Frontend neue Pakete installiert werden müssen! Sieht man sich unter den OX6-Verzeichnissen seines Apache-Servers mal die Datumsangaben der installierten OX6-Files an, so wird man feststellen, dass der bisherige, oben beschriebene Update-Prozess die HTML- und Javascript-Files der früheren 6.20-Installation nicht angetastet hat. Der alte Client passt aber schlicht nicht zum neuen Backend! Wir korrigieren dieses Problem gleich im Zuge eines Upgrades auf die Version 6.22.1!

Upgrade auf die Version OX 6.22.1

Wir deaktivieren unter YaST2’s Paketverwaltung nun die OX 6.22.0-Repositories. Zusätzlich binden wir die aktuellen OX6-Repositories für OS 12.2 ein:

http://download.opensuse.org/repositories/server:/OX:/ox6.22:/frontend/openSUSE_12.2/
http://download.opensuse.org/repositories/server:/OX:/ox6.22:/backend/openSUSE_12.2/

Und nun stellen wir folgende Listen an Paketen für den Upgrade zusammen:

OX6-Backend (V6.22.1)
update_ox622_backend_600

Hier kommt zu den bisherigen Paketen eines für
die “de_DE”-Sprachunterstützung des Backends hinzu: open-xchange-l10n-de-de.

OX6-Frontend (V6.22.1)
update_ox622_frontend_600

Dies sind etliche Pakete mehr als beim Upgrade zu v6.22.0 ! Am wichtigsten ist das Paket “open-xchange-gui” ! Hinzu kommen Pakete zur deutschen Sprachunterstützung sowie zu Hilfe-Funktionen. Benötigt werden außerdem separate Pakete für die E-Mail-Account-Verwaltung und Plugin-Wizards:

open-xchange-gui-help-plugin, open-xchange-gui-help-plugin-gui, open-xchange-gui-l10n, open-xchange-gui-l10n-de-de, open-xchange-online-help-de-de, open-xchange-gui-themes-default, open-xchange-gui-loading-theme-default, open-xchange-gui-login-theme-default, open-xchange-gui-mail-accounts-plugin, open-xchange-gui-wizard-plugin, open-xchange-gui-wizard-plugin-gui

Man führe dann per YaST2 den Update zu diesen Paketen durch. Ein kurzer Blick auf den Webserver zeigt danach, dass dort jetzt aktuelle OX6-Web-GUI-Files mit einem neueren Datum vorliegen. Ferner ist jetzt auch das Verzeichnis “/opt/open-xchange/i18n” gefüllt.

Und jetzt klappt endlich auch der Web-Login für den OX6!

ox622_mail_600

Das Bild zeigt den Zugriff auf einen (separaten) IMAP-Server über den OX6! Der WE-GUI-Zugriff auf die im OX6 selbst verwalteten Kalender-Einträge, Aufgaben, den Infostrore, etc. funktionierten bei mir ebenso völlig anstandslos wie der Rest der upgedateten Web-GUI!

Ich musste nur bei einem einzigen User in die Datenbank eingreifen und dort den Email-Account für die Unified Mail (“unifiedinbox”) löschen. Bevor ich das tat, verweigerte OX6.22 für diesen speziellen Account jegliche Mail-Anzeige und deaktivierte das Mail-Modul. Die Ursache blieb unklar; aber das war mir auch egal, da dieser lokale Account sowieso nicht benutzt wurde. Bei keinem anderen User trat ein solches Problem auf!

Erfolgreicher Check des OX6-Zugriffs mit Kontact-Komponenten von KDE 4.10

Bleibt abschließend nur, den Zugriff von Kontakt/Organizer und vom Kontact/Addressbook (eiens aktuellen KDE 4.10) auf den OX6.22 zu prüfen. Der Zugriff läuft über Akonadi und da ist man bekanntlich nie vor Überraschungen gefeit.
Aber: Alles funktionierte auf Anhieb und ohne jede Änderungen oder Eingriffe. Der OX6-Konnektor von Akonadi funktioniert also auch mit OX 6.22.1 ! Interessant, dass auch die “Address Auto Completion” von Kmail 4.10 beim Zugriff auf das OX6-Adressbuch keine größeren Zicken machte. Soweit ich sehen kann, werden die vorhandenen Adressen genauso gut (oder schlecht) wie zuvor angezeigt. Sehr gut funktionierte CUH der Web-Dav-Zugriff auf die Verzeichnisse des InfoStore über Dolphin!

Geht doch !