Beiträge von dlueth

Ist das nicht eigentlich der default? fds97AVVS

fds97AVVS wo genau muss das hin bzw an wen richtet sich das?

So, hab die fehlenden Binaries manuell gebaut und ins Repo gepackt, kann sie nachträglich wohl nicht zum Release hinzufügen: https://github.com/dlueth/teleris…e/main/binaries

Also technisch alles fein, bis auf das Sky evtl doch nicht läuft? easy4me

easy4me Hast Du Deine letzten Änderungen schon released? Weil der Build bei mir lief automatisch, müsste also von Dir ausgegangen sein

easy4me war wohl doch nur ein temporäres Problem, die 0.13.7 ist durchgelaufen. Ich bau jetzt noch die arm/v6 und arm64/v8 16k Version lokal und schieb die Binaries hier in den Thread

easy4me wenn du nen fix hast, immer gern her damit

Ja, easy4me ist es. Ich hab's schon gesehen, und nochmal manuell angestoßen. Ist aber wieder gefailed. Ich schaue sobald ich kann. Nuitka failed in Bezug auf scons, was entweder am code oder am compiler liegen kann wohl

Bei Docker hat man halt ein gekapseltes System was man ggf. nach belieben starten und beenden kann. Alles, was gebraucht wird ist drin und das umgebende System benötigt nur und ausschließlich Docker. Klar, die Config muss man ggf. wegsichern - aber das sollte man ja sowieso tun.

Ich persönlich finde (und das muss nicht jeder so sehen), dass es durchaus von Vorteil ist, dass ich außer Docker rein gar nichts auf dem umgebenden System brauche. Es gibt hier dann nämlich auch null komma null null Potential für Konflikte (was durchaus auch vorkommt, wenn man viel installiert hat, z. B. bei Java) und auch keine "Update-Sorgen", sofern die Container vernünfitg gewartet werden von den Erstellern. Ich kann also auch beliebige Software einfach testen ohne irgendwelche Rückstände auf dem System zu hinterlassen. Ich kann sogar solche Software testen oder benutzen, die es für meine Distribution oder sogar meine CPU-Architektur z.B. gar nicht gibt.

Für unsere Fälle mag das vielleicht nicht ganz so relevant sein, aber auch ein "Neu Aufsetzen" kann (nicht muss) mit Docker durchaus um einiges schneller sein. Nacktes Betriebssystem drauf, Docker installieren, Konfiguration der Container Wiederherstellen, Container starten, läuft... (gilt allerdings nicht für TVHeadend, was aber an deren Konfiguration liegt)

Ich persönlich benutze folgende Images:

lscr.io/linuxserver/tvheadend:latest

qoopido/telerising.minimal:latest

qoopido/easyepg.minimal:lite-scratch

Wobei letzterer die "Scratch"-Variante ist, die nochmal deutlich kleiner ist als "latest". Telerising von mir gibt es sowieso nur noch als "Scratch".

LooseMyMindOnLinux das ist echt komisch, da bookworm ja neuer ist als bullseye. Aber bullseye war ja auch problematisch, was das Bauen angeht, weswegen ich letztlich auf Buster geblieben bin...

Und LooseMyMindOnLinux also wenn klar ist, dass die Version so weit stabil läuft würde ich sie bei mir - solange es geht - als festen Bestandteil mit aufnehmen

Also: gebaut wird die arm32v6 Version auf einem buster basierenden raspbian Image in arm/v6, von daher wüsste ich jetzt nicht, wo da ein Fehler passieren sollte. Insbesondere, weil es ja auf einem PiZeroW sauber zu laufen scheint.

Aber generell bestätigst Du meine Vermutung, die neulich schonmal auftauchte: die Pagesize scheint hier nur die inkludierten libs zu betreffen, nicht aber die binary Ansich. Ergo kann man die nachträglich austauschen wie es scheint. Und ja, mein build ist statisch. Vielleicht würde es mit einem dynamischen build auf den rpis besser/einfacher laufen? Da ich für Docker baue brauche ich allerdings statisch...

vossi68 du meinst die v7 läuft nicht auf dem PiZeroW? Das wäre ja so weit korrekt, denn der kann nur v6. Allerdings müsste die v6 Version auch auf einem 32bit v7 System laufen.

Kleiner kann sie durchaus sein, denn ich lasse noch ein paar Optimierungen drüber laufen um sie so klein wie möglich zu bekommen

So, hier nun die Binaries gesammelt mit der Bitte um Feedback: https://limewire.com/d/172c526f-e89…hQi_30RrmPLmk4A

arm32v6 war etwas anstrengender als erwartet, da Debian das gar nicht mehr offiziell bereitstellt, aber könnte/müsste laufen

Ach, wer weiß wer die noch brauchen kann evtl. XD

Das Bauen wird voraussichtlich bis morgen brauchen. Mein neues MacBook mit Arm-Architektur kommt erst mitte Januar und bis dahin bin ich noch auf Intel unterwegs, was das bauen für Arm extrem verlängert.

So, ich baue jetzt mal neue binaries für alle Architekturen, also amd64, arm64v8, arm32v7 und zusätzlich arm32v6 + arm64v8-16k für die RPI5 Besitzer und packe sie dann hier dazu. Bitte die dann mal gegenchecken und ich setze mich im Nachgang hin und ändere den GitHub Workflow entsprechend.

Für Docker bedeutet das, dass es nun zusätzlich ein arm32v6 image gibt, mehr erstmal nicht. Der läuft also vorerst nicht auf einem Pi5 mit Pagesize 16k. Im GitHub Repo sollte sich dann aber eine kompatible Binary beim release finden. Da Docker anhand der Pagesize nicht unterscheiden kann, muss es demnach im weiteren Nachgang wohl einen extra "Tag" für die 16k-Version geben.

easy4me d.h. es reicht hier eigentlich ein einiziges build für die 16k Pagesize, nämlich das für arm64v8, korrekt? Oder gibt es auch die Möglichkeit, dass es ein arm32v7/arm32v6 mit 16k Pagesize braucht?

vossi68 Die Frage hier hattest Du gesehen? RE: Telerising API - Zattoo, blue TV & Sky CH für tvHeadend und VLC [Web App]

OK, und da easy, soweit ich weiß, die Binaries direkt auf einem Pi gebaut hat wird das wohl deswegen hingehauen haben...