Debuggen Sie den Lexmark 08zero-Treiber in Linux

328
Janos

Fedora 3: Versuch, Lexmark Z24020 zu drucken (übrigens, ich konnte keinen Treiber auf xubuntu> 11 installieren, da er auf einem 64-Bit-Computer installiert ist und der Lexmark-Treiber nur für 32-Bit-Versionen geeignet ist). Es funktionierte auf derselben FC3-Installation, als ich alle möglichen Updates zusammenstellte und das ursprüngliche FC3-System entstellte. Jetzt habe ich FC3 wieder in den ursprünglichen Zustand versetzt und der Druckvorgang wird abgebrochen, wenn der Drucker an den installierten Lexmark Drucker gesendet wird (HP LaserJet P1102w funktioniert bereits). Das Fehlerprotokoll der Becher zeigt an, dass die Druckertreiberkomponente der Lexmark Software gestartet ist, der nächste Becher-Sockel gestartet wird. Der Druckertreiber wird jedoch fehlerhaft gestoppt und der Becher bricht ab. Der ldd-Druckertreiber ist zufrieden. Dies ist bei Cups 1.1.22.0 der Fall. Zuvor war mit meinen verstümmelten FC3-Bechern der 1.4.6. Die Frage ist also: Wie gehe ich beim Debuggen vor und finde heraus, was jetzt inkompatibel ist? Schrieb ein einfaches Skript zum Starten des Druckertreibers mit ltrace, Dies funktioniert jedoch nur, wenn ich den Druckertreiber (der den umbenannten ursprünglichen Druckertreiber startet) von der Shell aus ausführt. ltrace funktioniert jedoch nicht, wenn mein Druckertreiber-Skript vom cups-Prozess aufgerufen wird. Genug gesagt und danke für alle Ideen.

-1
Hallo und herzlich willkommen bei Superuser. Dies ist eine Textwand und schwer zu lesen. Wenn Sie möchten, dass mehr Personen lesen und Ihnen helfen, schreiben Sie Ihre Frage bitte mit den richtigen Sätzen, Abständen und Großschreibung um. Mogget vor 8 Jahren 0

1 Antwort auf die Frage

0
Janos

Das Problem, Lexmark-Druck zu erstellen, wird durch das Kompilieren der Cups 1.2 (die in der ppd-Datei von Lexmark als Version der Cups angegeben sind) und des Kompilierens von qgostscript 9.02 gelöst. Anscheinend funktioniert der Lexmark Druckertreiber nicht mit früheren Versionen von Cups und Ghostscript. Dies war eine brutale Lösung, eine Trial-and-Error-Lösung. Es bleibt immer noch die Frage, wie in diesem Fall ein Debugging durchgeführt werden kann und wie der Punkt gefunden werden kann, an dem der Prozess zusammenbricht.

Verwandte Probleme