Beiträge von letsfindaway

Also das Spool-Verzeichnus für CUPS ist erst mal vorhanden. Nochmal langsam zum Verständnis von dem, was roger da macht.

roger richtet bei der Installation einen Drucker ein.Das Paket-Postinstall-Skript von @Sauerland macht das mit dem Befehl

lpadmin -p Roger-Router-Fax -E -v roger-cups:/ -P /usr/share/cups/model/roger-fax.ppd || :

Dieser Drucker hat als Backend-URL wie du oben siehst roger-cups:/. Das bedeutet, dass CUPS unter /usr/lib/cups/backend zum Versenden des Druckjobs an das Gerät nach einem Executable namens roger-cups sucht und dieses mit einer Menge vordefinierter Parameter aufruft. Im Falle von Roger ist dieses Executable ein Skript, das die als Parameter angegebene spool-Datei nach /var/spool/rm verschiebt. Dieses Verzeichnis hat mit CUPS nun schon gar nichts mehr zu tun. Nach dem Aufruf des Backend-Skriptes ist CUPS fertig. Alles andere ist "roger" - oder eben nicht.

Habe nun mal roger mit strace gestartet:

family@gepard:~> strace roger 2>&1 | grep "spool"

Das obige Fenster enthält die Eingabe einschließlich der Ausgabe, d.h. Ausgabe: keine. Auch andere greps haben keinerlei Aktivitäten auf einem /var/spool Verzeichnis o.ä. erkennen lassen. Das roger Executable liest also wohl keine Dateien in diesen Verzeichnissen.

Dann hab ich mir das mit /var/spool/roger und /var/spool/rm noch mal angesehen:

In share/install-fax.sh findet man Anweisungen, /var/spool/rm zu erstellen. Im Build Skript roger.spec findet man Anweisungen, /var/spool/roger zu erstellen. Ich denke, das Erstere war, was der Autor von roger eigentlich vorhatte. Allerdings findet sich sonst nirgends in den roger-Sourcen oder den librm-Sourcen irgendein Verweis auf dieses Verzeichnis! Nur das Backend-Skript will wie oben erwähnt Dateien dort reinschieben. Ich glaube, das ist ein halbgares Feature.

@Sauerland: hab gesehen, die Dependency auf capi4linux hast du schon drin. Wenn du nun noch den Drucker auf localhost:9100 verbindest, dürften wir der Sache sehr nahe kommen. Ob dann die Mitgliedschaft in der Gruppe fax oder lp überhaupt noch erforderlich ist, wage ich zu bezweifeln.

Zitat von Sauerland

Im branch sind nicht alle meine Pakete, das könnte zu Verwirrung führen....

Danke für die Erklärung Anderer

Zitat von Sauerland

Bist du in der Gruppe lp und fax?

ja, bin ich. Und ich sehe auch keine Fehlermeldung im Debug-Fenster, dass roger nicht auf das Spool-Verzeichnis zugreifen könnte. Ich werde mit strace oder im Source Code aber mal nachsehen, welches Verzeichnis roger öffnen will. Andererseits: müsste CUPS den Druckauftrag nicht selber puffern, solange localhost:9100 nicht verfügbar ist und dann, wenn man roger startet und der Server auf diesem Port lauscht, automatisch den Auftrag dorthin senden? So würde es ja zumindest bei einem "normalen" Drucker auch gehen.

Muss ich bei Gelegenheit mal rumexperimentieren.

Hallo zusammen,

hab bei mir auch mal die Version aus @Sauerland s Repository installiert - und auch bei mir ging der Faxversand nicht.

Ich habe daraufhin roger in der Konsole mit roger -d gestartet. Dort kam dann eine Fehlermeldung, dass CAPI20 nicht installiert sei. Weitere Nachforschungen haben ergeben, dass diese Meldung im Endeffekt von libcapi20-3 verursacht wird. Die ist nämlich nur ein Wrapper und benötigt noch eine CAPI 2.0 Implementierung.

Daraufhin habe ich noch capi4linux installiert - und beim nächsten Start von Roger war diese Meldung weg. Es ging aber immer noch nichts.

Weitere Analyse: Der Roger-Router-Fax Printer verwendet zur Ausgabe eine URL roger-cups:/. Diese spezifiziert gemäß CUPS ein Backend, das man unter /usr/lib/cups/backend findet. Dort liegt ein Skript roger-cups, das die weitere Verarbeitung übernehmen soll. Es versucht die Spool-Datei in einen Ordner /var/spool/rm zu verschieben. Diesen gibt es aber nicht, stattdessen gibt es /var/spool/roger. Ich habe den Pfad probehalber geändert, aber das hat auch nichts geholfen.

Nun ist es ja so, dass Roger Router auch einen virtuellen Druckerport unter localhost:9100 zur Verfügung stellt. Ich habe nun mittels der YaST Druckerkonfiguration und des Verbindungsassistenten kurzerhand die Verbindung des Roger-Router-Fax Druckers auf localhost:9100, Raw Queue konfiguriert. Und siehe da! Jetzt ging es!

Ich vermute, Roger Router hat zwei Methoden implementiert, Fax Druckaufträge anzunehmen: einmal über den Port 9100 (und dann natürlich nur, wenn das Programm läuft) und einmal über die Queue in /var/spool/roger. Letzteres könnte es ermöglichen, Druckaufträge auch ohne laufenden Roger Router zwischenzuspeichern und dann hinterher zu versenden. Aber da scheinen noch ein paar Bugs drin zu sein.

Mit der Variante über Port 9100 und installiertem capi4linux scheint es aber zu gehen!

Danke an @Sauerland für den Build! Und kurze Frage: Du baust Roger unter home:Sauerland und unter home:Sauerland:branches:home:Sauerland. Welches soll ich installieren? Was ist der Unterschied?

Das hängt auch von deinem Dateisystem ab. Hast du btrfs drauf, werden die 20GByte verdammt knapp. Mit ext4 könnte es reichen. Hängt u.a. davon ab, wie viele Programme du noch installierst und welche.

Persönlich bin ich ein Freund der "luftigen" Dateisysteme. Ich würde mir für root wenigstens 30 GByte gönnen (bei ext4), wenn es sonst nicht weh tut, auch 40 GByte. btrfs setze ich nicht ein, deshalb kann ich dazu nichts sagen. Aber da bin ich wahrscheinlich sehr vorsichtig. Ich bin nur in der Vergangenheit immer wieder bei zu kleinen Dateisystemen an die Grenzen gestoßen, zu große hatte ich noch nie

Den IRC hab ich bisher noch nicht bemüht, aber weiter nachgeforscht:

Also das "offizielle" wine wird deshalb nicht so oft gebaut, weil es noch im Auslieferungszustand vorliegt und noch nicht über das Update-Repository ausgeliefert wird. Im Leap-15.0-Distribution Projet sind die Builds aber alle abgeschaltet, siehe Repositories of openSUSE:Leap:15.0 - openSUSE Build Service die Build-Flags sind alle auf disabled gesetzt. Das macht ja auch irgendwie Sinn, denn am Auslieferungszustand will man ja nicht drehen. Änderungen laufen alle über das Update-Repository.

Dort ist wine aber noch nicht gelandet. Es gab keine Änderungen am Projekt, und anscheinend haben auch die Änderungen an Abhängigkeiten nicht dazu geführt, dass man wine ins Update-Projekt übernommen hätte. Sofern es sich nur um Bug Fixes handelt ist ja auch kaum anzunehmen, dass dadurch ein Problem auftritt.

Ich hab jetzt erst mal bei mir die Build-Flags auch abgeschaltet und muss mal überlegen, wie ich das in Zukunft (Leap 15.1, Leap 16.0 usw.) organisiere.

Danke aber soweit, für mich ist das Thema damit gelöst.

Okay, verstanden. Und wine hängt von einer ganzen Menge ab. Aber das "offizielle" wine unter Show openSUSE:Leap:15.0 / wine - openSUSE Build Service wird trotzdem nicht so oft gebaut, oder zumindest nicht so oft an die Anwender ausgeliefert. Wie machen die das?

Ich sehe das was von "locked" bei den Builds. Was ist das genau? Wie und warum ist der gesetzt?

Hallo zusammen,

ich glaube hier gibt es ein paar OBS-Experten, die mir sicher weiterhelfen können.

Ich habe mir im OBS eine gepatchte Variante von wine gebaut. Inhaltlich habe ich die MAPI gepatch, damit auch Mails mit Attachment versendet werden können - zumindest über Thunderbird. ich wollte das, weil ich Picasa auf wine verwende und die Funktion, dort Fotos per Mail zu versenden, ganz praktisch finde.

Aber jetzt zu meiner Frage. Ich habe das Paket als Branch der offiziellen Version angelegt unter Show home:letsfindaway:branches:openSUSE:Leap:15.0 / wine - openSUSE Build Service. Obwohl ich in den vergangenen Monaten nichts an dem Paket geändert habe, wird es etwa monatlich neu gebaut, kriegt eine neue Versionsnummer, und wird dann natürlich auch bei mir neu installiert. Das ist zwar nicht schlimm, aber unnötig.

Deshalb meine Frage: Warum wird dieses Projekt vom OBS neu gebaut? Ich sehe nicht, was sich geändert haben könnte. Auch das Original wine-Paket, das ich gebrancht habe, ändert sich nicht so oft. Was ist also der Trigger? Kann ich den abstellen?

Zitat von Kebe

AHCI and Hot Plug functions --> meinst Du diese Einstellung?

Hört sich gut an!

Und ja, /dev/sda4 wird nicht mehr angezeigt, aber unter /Linux_Daten solltest du schon noch was finden! Aber probier erst mal die BIOS Einstellung. Hot Plug disabeln.Du willst das Ding ja nicht im laufenden Betrieb ausstecken, oder?

Zitat von Kebe

Also wenn ich Leap 15 installiere sollte alles wieder laufen.

Nein, ich habe Leap 15 und der Kernel verhält sich genauso wie der 4.4. Und nochmal, es ist kein Kernel Bug, es ist ein Feature, allerdings ein manchmal etwas unglückliches. Hast du dir dein BIOS dazu schon mal angeschaut? Nochmal hier:

FS#48069 : [linux] 4.4.1-2: Seems to detect fixed disks as a removable device

Wenn du das Gerät im BIOS als "non-hotpluggable" markieren kannst, wäre das die Lösung.

Zitat von Kebe

Ergebnis: in Dolphin wird das Laufwerk /dev/sdb4 nicht angezeigt, wurde danach wieder gelöscht.

Wenn du das Laufwerk in der /etc/fstab mountest, dann ist es am passenden Pfad verfügbar. Als extra Gerät wird es aber nicht mehr angezeigt. Das ist schon ok so.