[Python] PyQt5 Bindings

[MacDuff]

Wie kann ich denn den RED auf PyQt5 aktualisieren? Ich habe via Synaptic die PyQt5-Pakete installiert, ich habe die Source von Riverbank-Computing geladen und per configure.py installiert. Qt5 ist bereits installiert.

Trotzdem -- die Paketliste im Brickviewer > Versions zeigt mit nur die qt4-Bindings. Und wenn ich ein Testprogramm starten will (GUI gebaut mit PyQt5), dann bricht es ab und es heißt im stdout-log: "QXcbConnection: Could not connect to display".

Wäre das nicht sinnvoll, generell Qt5/PyQt5 mit dem Image auszuliefern?

merci, md

[remotecontrol]

"Could not connect to display"

ist doch eher eine Fehlermeldung, dass sich die Anwendung nicht zum X-Server verbinden kann?

 

Hast Du einen X-Server am laufen und startest die Anwendung aus einer X-Session?

[MacDuff]

Diese Fehlermeldung kann ich nicht einordnen. Desktop Environment und GPU sind in den RED-Services gestartet. Den Desktop kann ich mir über TightVNC auch ansehen. 

Im alten (Full)Image kam die Fehlermeldung "Package PyQt5 nicht gefunden" o.ä., wenn ich versuchte, eine PyQt5-GUI-Anwendung zu starten.

[remotecontrol]

Es scheint aber eher so, als wäre Dein Update OK, aber der Start der Anwendung von der falschen Stelle aus passiert.

 

Wenn Du Dich gegen den Desktop per VNC verbindest und dann aus einem XTerm die Anwendung startest: wann kommt dann für eine Fehlermeldung?

[MacDuff]

Teilerfolg! Wenn ich über TightVNC den Red-desktop aufrufe, lässt sich das Programm starten -- via Terminal, direkt in home/tf/programs/programmname/bin > python3 progname.py. GUI erscheint, funktioniert.

Eine Warnung wird zuvor im Terminal ausgegeben: "libEGL warning: GLX/DRI2 is not supported". -? Und eine aufs Keyboard bezogene Meldung von Qt, was sich aber nicht weiter bemerkbar macht.

So.

Jetzt denke ich mir, das müsste doch auch über den Brickviewer gehen, oder? Also aufm Program-Tab "Start" klicken, aber da fliegt das Ding jedesmal wieder nach ein paar Sekunden raus, noch bevor irgendwo irgendwas vom GUI zu sehen ist. Fehlermeldung wie gehabt: "QXcbConnection: Could not connect to display 0". Env-Variable DISPLAY:0 ist gesetzt.

Monitor ist über HDMI angeschlossen, aber ich seh nur den Desktop.

Liegt hier irgendein Denkfehler meinerseits vor?

grazie, macduff

 

 

[remotecontrol]

Wenn Du über die Brickv-Console ein Programm startest, dann musst Du

 

- ein laufendes X oder VNC haben

- das Display des X-Servers kennen (remote ist nicht :0)

- Zugriffsrechte auf das Display haben

 

Wenn Du Dich z.B. mit einer ssh-Session anmeldest (die hat erstmal keine Verbindung zu X) kannst Du zwar über "export DISPLAY=:0" das Display auf das Hauptdisplay lenken, aber in einem X-Terminal des Hauptdisplays musst Du erstmal "xhost +" eingeben, damit Du von einem anderen Terminal graphische Anwendungen starten darfst, sonst könnte ja jeder auf Deinem Bildschirm was starten...

[MacDuff]

Viele Dank für die Mühe, remotecontrol.

Die Sache liegt ein bisschen anders: ich möchte das Programm nicht über die Console im Brickviewer starten, sondern nach Upload via Programm-Tab -- so wie im RedBrick-Tutorial für eine kleine Python-App mit GUI beschrieben (http://www.tinkerforge.com/de/doc/Tutorials/Tutorial_RED_Brick/Tutorial.html#tutorial-red-brick).

Dass meine Anwendung grundsätzlich läuft, auf dem Red, habe ich ja per TightVNC überprüft.

 

[remotecontrol]

OK, da kann ich nicht weiterhelfen.

[photron]

MacDuff, ich hab das gerade mal getestet und dazu folgendes getan:

 

- RED Brick mit Image Version 1.5 und Monitor per HDMI

- "sudo apt-get install python3-pyqt5" auf dem RED Brick

- entsprechend des Tutorials diese PyQt5 Beispiel hochgeladen

- funktioniert

[MacDuff]

Ich schätze mal, mein Image (1.4) hat bei all der Rumprobiererei einen Schaden abbekommen, denn es startet trotz in brickviewer > settings > services aktivierten Desktops nur bis zum prompt. "startx" via Console führt zu einer fehlermeldung. Jetzt mach ich halt einen neuen Anlaug mit einem frischen 1.5...

- md

[MacDuff]

danke, photron.

Aber ... ich habe's jetzt genauso gemacht wie von dir beschrieben, und bekomme nach wie vor die gleiche Meldung:

"QXcbConnection: Could not connect to display"

Mit neuem & sauberen Image 1.5, Aktualisierung auf PyQt5 per apt-get, mit dem von dir angegebenen PyQt5-Beispiel, mit dem ausm Tutorial, mit meinem Programm. Sowie ein anderer Monitor. Hilft alles nix. Nach einer Sekunde stoppt die Anwendung mit eben dieser Meldung.

Tja, was tun? Ich würde schon gern einen Monitor verwenden...

 

Nebenbei:

Beim apt-get upgrade bleiben am ende diese errors übrig:

 

dpkg: error processing archive /var/cache/apt/archives/systemd_215-11_armhf.deb

(--unpack):                                                                   

trying to overwrite '/usr/share/dbus-1/system-services/org.freedesktop.systemd1

.service', which is also in package systemd-shim 9-1                           

dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)           

Failed to set capabilities on file `/usr/bin/systemd-detect-virt' (Invalid argum

ent)                                                                           

The value of the capability argument is not permitted for a file. Or the file is

not a regular (non-symlink) file                                             

Processing triggers for dbus (1.8.12-3) ...                                   

Errors were encountered while processing:                                     

/var/cache/apt/archives/systemd_215-11_armhf.deb                             

E: Sub-process /usr/bin/dpkg returned an error code (1)                       

[photron]

Den QXcbConnection kann ich hier erzeugen wenn ich die DISPLAY Umbegungsvariable für das Programm nicht setzte. Hast du DISPLAY auf :0 gesetzt wie hier im Tutorial zu sehen?

 

[photron]

Das apt-get upgrade Problem kann ich hier reproduzieren. Sieht aus als wäre dieser Debian Bug aus 2014 wieder aufgetaucht. Da habe ich ad hoc keinen Lösungsvorschlag für. Laut Bugreport soll man systemd-shim deinistallieren können und das würde das Problem lösen. Allerdings lässt mich apt das Package nicht purgen, da es erst systemd upgraden will.

[MacDuff]

Ja, Video :0 ist gesetzt, genau wie abgebildet.

 

Das apt-get-Problem ist lästig. Ich wollte nun wenigstens mal TightVNC installieren -- geht nicht.

"The following packages have unmet dependencies:

libpam-systemd : Depends: systemd (= 215-11) but 215-10 is to be installed

systemd : Depends: libsystemd0 (= 215-10) but 215-11 is to be installed

E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution)."

Die -f Option führt allerdings auch in eine Sackgasse.

 

Hm. Vielleicht zurück auf Image 1.3?

 

 

 

[photron]

Läuft denn der X Server auch?

 

Das systemd Package Problem habe ich so behoben:

 

sudo dpkg --purge systemd-shim
sudo apt-get -f install

 

Zwar lässt mich apt-get das systemd-shim Package nicht deinstallieren, aber dpkg macht das ohne Murren.

[MacDuff]

uh, ich denke schon ... wenn ich "X" am prompt eingebe, bekomme ich die mitteilung, dass  der server "active for display 0" ist.

den desktop hab ich in den services aktiviert, und ich seh ihn auch auf dem monitor. falls das nicht ausreichen sollte, bitte ich um weitere hinweise, wie das mit GUI-Apps funktionieren soll.

systemd usw dank deiner hilfe erfolgreich entfernt...

[mblank]

Ich hatte ebenfalls bei der Installation von neuen Paketen das Abhängigkeitsproblem:

 

"The following packages have unmet dependencies:

libpam-systemd : Depends: systemd (= 215-12) but 215-10 is to be installed

systemd : Depends: libsystemd0 (= 215-10) but 215-12 is to be installed  ..."

 

und habe dann per dpkg "systemd-shim" deinstalliert. Nach einem Reboot funktioniert dann allerdings die Serielle Konsole nicht mehr!

 

Re-installation von "systemd-shim" beseitigt dieses Problem wieder und /dev/ttyACM0 taucht wieder auf - so ganz überflüssig ist systemd-shim ("This package emulates the systemd function that are required to run the systemd helpers without using the init service") wohl doch nicht...