Beiträge von letsfindaway

  • Browser kann nicht auf *.js dateien zugreifen

    Hmm, interessanterweise steht der GET /nextcloud/core/js/backgroundjobs.js?v=41101509-0 trotzdem mit 200 OK im Protokoll, aber mit 0 Bytes. Dann würde ich erwarten, dass du diese leere Antwort auch im Netzwerklog siehst. Trotzdem: Das würde mir nun in der Tat eher nach Server als nach Client riechen.


    Alle fehlgeschlagenen haben außerdem einen ?v=41101509-0 Query Parameter. Der wird typischerweise verwendet, um das Caching zu steuern, wenn sich der Inhalt einer Datei unter der abgefragten URL ändert. Kannst du mal versuchen, die URL http://192.168.178.30//nextcloud/core/js/backgroundjobs.js?v=41101509-0  direkt aufzurufen, am besten mit Shift-Enter, um das Neuladen zu erzwingen? Ich erwarte entweder einen Timeout oder eine Antwort oder ein "Connection closed". Mich würde interessieren, was da kommt.


    Und dann wäre es noch interessant, die Apache access_log und error_log Files zum gleichen Zeitpunkt anzuschauen. Findest du da einen Anhaltspunkt?

  • Browser kann nicht auf *.js dateien zugreifen

    Ob es auf der Anfrageseite (Browser) liegt oder auf der Serverseite (Apache), darüber könnte das Netzwerkprotokoll Auskunft geben. Ich will wissen, ob der Browser überhaupt die Anfrage absendet, wenn ja, wie sie aussieht und was die Antwort ist.


    Du greifst auf den Server schon über die URL http://192.168.178.30/nextcloud zu oder benutzt du da einen Hostnamen?

  • Repos / Onlinebanking

    :)


    Wenn du nachverfolgen willst, wie das zustande kam:

    • Unter Show Java:packages / hibiscus -
      openSUSE Build Service       siehst du, das vor wenigen Stunden ein Request akzeptiert wurde.
    • Klickst du diesen an, (Request 740232 -
      openSUSE Build Service      ) dann siehst du, dass ecsos damit angefordert hat, dass die Version aus seinem Home Repository übernommen werden soll.
    • Da er Maintainer ist, hat er den Request gestellt und auch gleich selbst akzeptiert. Sonst sind das natürlich eher zwei Personen.
    • In seinem Home Repository hat er zuvor die neue Version gebaut und getestet

    Also: der Maintainer hat sich direkt darum gekümmert.

  • Repos / Onlinebanking

    Ich glaube der Fragesteller hat 2 Fragen:

    • wie kriege ich das Banking mit PSD2 zum Laufen?
    • wie gehe ich sinnvollerweise vor, wenn ich ein aktualisiertes Paket nicht nur für mich bauen, sondern der Community beisteuern will?

    Ihr habt jetzt viel zur ersten Frage gesagt und ich nehme mal an, das kriegt er hin. Mein Fokus war eher eine Antwort auf die zweite Frage und da will ich noch mal etwas ausholen, weil mir das wichtig ist:


    Open Source lebt vom Mitmachen. openSUSE unterstützt das ganz besonders gut mit dem Open Build Service. Dort werden die offiziellen Pakete für Tumbleweed und Leap gebaut. Aber auch jeder andere kann seine eigenen Pakete da erstellen. Außerdem kann jeder auch zu den offiziellen Paketen beitragen. Das ist bei openSUSE deutlich einfacher und transparenter als bei jeder anderen Distribution, die ich kenne.


    Wie oben beschrieben ist das im Grunde genommen ein einfacher Dreisatz: Branchen, patchen, Request stellen.


    Und ich fände es super, wenn @Welm jetzt nicht nur die neueste Version von Willuhn runterlädt und für sich zum Laufen bringt, sondern diese Version in der Tat in das Devel-Package auf java:packages und damit in die offiziellen Repos einbringt.

  • Repos / Onlinebanking

    Und wenn du die offiziellen Repos nicht vergessen willst:


    Das Paket auf java:packages ist das offizielle "devel" Projekt, d.h. da werden die Pakete gebaut, die nach Tumbleweed und irgendwann auch nach Leap gehen. Du kannst:

    • dieses Paket im OBS branchen
    • den Branch auf die aktuelle Version hochziehen
    • dann einen Request stellen, dass deine Änderung in java:packages übernommen werden soll.

    Wird dein Request akzeptiert, dann steht das Paket erst mal in java:packages zur Verfügung. Einige Zeit später kann das neue Paket dann in Tumbleweed erscheinen. Wenig Hoffnung kann ich dur machen, dass sie dann aber so schnell in Leap übernommen wird. Dort ist man mit neuen Versionen eher konservativ. Vielleicht ist 15.2 eine Möglichkeit, aber da wird momentan auch noch die "alte" Version gebaut.


    Du kannst auch versuchen, ecsos zu kontaktieren. Der ist Maintainer für hibiscus (siehe Users of hibiscus (Project Java:packages) -
    openSUSE Build Service).


    Noch ein paar Links:
    https://en.opensuse.org/openSUSE:Build_Service_Collaboration
    https://en.opensuse.org/openSUSE:Package_maintenance
    https://en.opensuse.org/openSU…kaging_Patches_guidelines

  • Drucker druckt nicht mehr - filtrer failed

    siehe oben, ich bin mir ziemlich sicher, dass das dein Problem ist. Sicherheit kannst du durch einen Ausschnitt aus der Datei /var/log/cups/error_log bekommen. Da steht der Grund, warum der Filter nicht geht. Es geht darum, dass er zur Bestimmung der Seitenzahl ein API aus ghostscript verwendet, das in der neuen Version 9.27 entfernt wurde. Deshalb muss man entweder cups-filters patchen (erste Lösung in meinem Post oben) oder einen aktuellen cups-filters installieren, der das Problem bereits gelöst hat (zweite vorgestellt Lösung).


    Die /var/log/cups/error_log ist zwar lang, aber die fragliche Fehlermeldung steht ja ganz hinten bei der aktuellen Uhrzeit. Sollte also leicht zu finden sein. Bei mir sahen die entsprechenden Zeilen so aus:


    Code
    D [30/Sep/2019:20:56:05 +0200] [Job 586] GPL Ghostscript 9.27: Unrecoverable error, exit code 1
D [30/Sep/2019:20:56:05 +0200] [Job 586] Process is dying with \"Unable to determine number of pages, page count: -1
D [30/Sep/2019:20:56:05 +0200] [Job 586] \", exit stat 3
D [30/Sep/2019:20:56:05 +0200] [Job 586] Cleaning up...
D [30/Sep/2019:20:56:05 +0200] [Job 586] PID 2950 (/usr/lib/cups/filter/foomatic-rip) stopped with status 3.