Da Plattenplatz Heute glücklicherweise irrelevant ist spricht auch nichts dagegen.
Natürlich kann man bei jedem Problem die Software gleich in die Tonne schmeissen und die Nächste testen. Den Adobe Reader habe ich auch erst installiert nachdem das Drucken mit Okular überhaupt nicht funktionierte (bzw. nur Mist aus dem Drucker kam).
Wenn sich das Druckverhalten vom Adobe Reader nicht beeinflussen lässt, kann ich ja auch mal Evince austesten.
Ich habe auf meiner openSuSE 13.1 (x86-64) Desktopinstallation den Adobe Reader installiert (als RPM). Als Drucker verwende ich einen Canon MF 8030CN mit passendem Linux Treiber.
Wenn ich nun ein PDF aus dem Adobe Reader drucken will, so ist der Druck "negativ" (invertiert) - also ich habe ein schwarzes Papier mit weisser Schrift, was ausser dem Tonerhersteller keinem was nützt 
Aus anderen Programmen sind die Ausdrucke aber ok - auch die Druckertestseite passt.
Kennt jemand diesen Effekt und hätte eine Lösung?
Falls es sich um offizielle Repositories handelt und die Abhängigkeiten somit vorhanden sein müssten, hilft manchmal auch ein:
zypper refreshIn ganz hartnäckigen Fällen kann man sogar die Datenbank neu aufbauen mit:
zypper refresh -fdbIch habe meinen letzten Bugreport am 17.10.2013 eröffnet um ein Installationsproblem in 13.1 RC1 zu melden das im Milestone 3 noch nicht auftrat. Als das Problem in RC2 immer noch bestand fragte ich am 9.11.2013 nach, ob man es nicht vor dem Release noch fixen wolle?
Da kam die erste Reaktion mit einer provisorischen Umgehungslösung (auf die grafische Installationsroutine verzichten und textbasiert mit dem entsprechenden Kernelparameter zu installieren). Am 12.11.2013 wurde der Bug einer anderen Stelle zugeteilt - seither ging nichts mehr. Der Bug fand nun auch Einzug in den Final Release.
Es war nicht die erste Bugmeldung bei openSuSE - aber bisher wurde keine wirklich ernstgenommen (ok, eine Nachfrage nach einem halben Jahr ob der Bug noch existiert vom Aufräumkommando mal ausgenommen). Ich habe mich daher entschieden in Zukunft darauf zu verzichten und Fehler in Eigenregie zu fixen. Der Aufwand einer detaillierten Fehlerbeschreibung mit Anleitung zur Reproduktion sind mir unter solchen Umständen zu hoch.
Ich benutze openSuSE als reines Serverbetriebssystem - zudem noch auf einer ESXi Plattform - ich denke meine Probleme interessieren eh kaum andere User. Die werden dann in der entsprechenden SLES Version entdeckt und kostenpflichtig gefixt.
Postgrey läuft für mich - das config.postfix Script ist angepasst - das genügt mir 
Schade steht da nichts über die Fehler, die das Script produziert und die verschluckten Konfigurationsoptionen.
Besonders sauber haben die es aber noch nicht gestrichen. Zum Beispiel ist die Postfix Konfiguration noch irgendwie mit /etc/sysconfig verbunden und manuelle Änderungen in der main.cf verschwinden nach einem Restart des Dienstes teilweise. Diesbezüglich ist mir auch die fehlerhafte Funktion des Scriptes /usr/sbin/config.postfix noch ein Rätsel, welches Daten aus /etc/sysconfig übernimmt - leider teilweise unvollständig.
Wer einmal versucht Postgrey in 13.1 zum Laufen zu bringen, kann sich deswegen auf einige Stolpersteine gefasst machen.
Nein, man setzt die Rechte richtig auf /media/Daten und der Benutzer kann dann innerhalb von /media/Daten abwärts soviele Ordner anlegen wie er will. Jeder vom Benutzer angelegte Ordner gehört auch dem Benutzer - er hat dann also alle nötigen Rechte dort.
Das Linux Rechtesystem ist nicht so kompliziert
Userrechte setzt man nicht in der fstab - jedenfalls nicht bei ext4 Platten. das funktioniert mittels umask nur bei vfat oder ntfs.
Bei ext4 musst Du die Verzeichnisse direkt mit entsprechenden Linux Berechtigungen versehen.
Um die Sache voranzutreiben habe ich nun erst einmal das 2.7.STABLE6 RPM von openSuSE 11.4 auf meinem 13.1 System installiert und mit der alten Konfiguration in Betrieb genommen. Lief absolut problemlos und ohne zusätzliche Anpassungen am System.
Dennoch wäre es eigentlich das Ziel, die Umstellung auf die aktuelle 3.3 Version zu schaffen.
