Telerising API - Zattoo, blue TV & Sky CH für tvHeadend und VLC [Linux Pakete]

Also... deine v0.13.0-Binary läuft auf meinem RPi 5 dlueth

Die, die ich hier gerade angehângt hatte? easy4me

Zitat von dlueth

Vielleicht könnte mal einer von den RPI 5 Usern mit Bookworm folgende Binary ausprobieren bitte: https://filetransfer.io/data-package/6O1WVWYz#link

Diese Datei meine ich...

Ok, dann war das die Testversion, das ist schonmal gut! Und die andere, aus dem repo, lief ja problemlos unter bullseye?

Pagesize war 4k unter bullseye und 16k unter bookworm, korrekt?

Was den Docker angeht ist das echt mistig. Ein Image kann Multi-Arch sein und Docker wählt das zur Architektur passende Image selber aus (amd64/arm64/arm). Allerdings interessiert ihn dabei die Pagesize natürlich nicht und es gibt auch keine Möglichkeit Images für die gleiche Architektur bei unterschiedlicher Pagesize zu hinterlegen.

Es wird vermutlich darauf hinauslaufen, dass ich neben dem normalen Docker-Tag noch spezielle für den Pi bereitstellen muss. Diese dann an die zugrundeliegende Debian-Version zu hängen macht nicht wirklich Sinn, oder? Die Umstellung erfolgte zwar mit Umzug zu Bookworm, allerdings kann man den Kernel ja via config wieder auf 4k Pagesize zurückdrehen. Ergo erscheint es mir am sinnigsten ggf. sowas wie rpi-4k und rpi-16k zu verwenden.

Was meint Ihr?

Ich hoffe, das ist nicht zu sehr off topic - hat jedenfalls mit der aktuellen Diskussion zu tun, und möglicherweise kommt ja was hilfreiches bei raus.

Wo liegt denn genau die Abhängigkeit von der page size? Ich hätte erst Mal erwartet, dass Anwendungsprogramme nicht direkt von der Page Size abhängig sind (möglicherweise für spezifische Funktionen verwendete lib wie glibc schon, aber die ist ja schon passend im System). Spezifische Techniken, wie memory mapped files, sind abhängig von der page size. Aber dafür gibt es dann den getpagesize(2) Aufruf, was ein Anwendungsprogramm wiederum unabhängig von der tatsächlichen page size macht. Ist die page size hier irgendwo (möglicherweise implizit) hart codiert in den Programmen? Vielleicht kann man das dann relativ einfach im Quellcode fixen?

Ich hatte früher u.a. Linux Binaries eines eigenen Programms "vertrieben" (= verschenkt ...). Nach meiner Erinnerung liefen die identischen Binaries unter Linux Distributionen mit large page size und mit normal page size - ohne dass ich mir jemals Gedanken dazu gemacht habe.

buers Ich bin mir da ehrlich gesagt nicht ganz sicher. Ich bin zwar Softwareentwickler, allerdings weniger auf der Binary-Ebene. Ich glaube wir können Docker an der Stelle auch außen vor lassen, denn es läuft ja schon die "Standalone-Binary" nicht, ohne Docker.

Grundsätzlich sind die vermeintlich statischen Binaries (die via Nuitka aus Python-Code erstellt werden) eben nicht wirklich "statisch", da sie durchaus Libs aus dem Betriebssystem brauchen und mitbringen. Ich bin jetzt gerade nicht sicher, ob es der "Binary"-Teil ist, der Probleme macht oder der Lib-Part (die ja aus dem erstellenden System kommen). Nimmst Du das Archiv einer Binary und entpackst es, siehst Du auch die Libs die inkludiert sind. Ich baue meine Binaries im Docker auf Basis von Debian Buster mit Python 3.9.

Was ich jetzt testweise einfach mal gemacht habe ist, dass ich ein anderes Baseimage, nämlich ein Pi OS mit Python 3.9 auf Basis von Bookworm verwendet habe. Das scheint so weit zu laufen. Ich kann Dir aber nicht sagen, ob die Pagesize dabei jetzt beim erstellen der Binary wichtig ist oder schlicht die Libs entsprechend mit einer anderen Pagesize erstellt wurden.

Es könnten rein die Libs sein, denn ich meine mich zu erinnern, dass ich mal per E-Mail einen Kontakt zu einem QNAP-Nutzer hatte wo das OS auch eine andere Pagesize hatte. Und der hat, meine ich, einfach die Libs im Archiv ausgetauscht, nach dem Entpacken, und es lief - meine ich.

ergänzende Frage noch in Bezug auf die RPIs dieser Welt: Gibt es diesen Pagesize Wahnsinn nur bei 64 bit oder auch bei den 32 bit Varianten von Pi OS?

Kann hierzu leider nichts sagen, alle RPis laufen hier nur mit 64bit OS.