Re: CFW weekly builds
Verfasst: 17 Apr 2017, 14:02
Er war eben auf github tätig, also....
Das Forum der ftcommunity
https://forum.ftcommunity.de/
Messerscharf geraten - ich hatte letzte Woche viel zu tun und bin deswegen zu wenig gekommen, und war über Ostern dann weg und Offline.ski7777 hat geschrieben:Richard war jetzt lange nicht mehr online. Wenn es nach den Ferien geht, muss er ja heute nach Hause kommen. In Hessen geht die Schule morgen wieder los.
Ich habs mal kurz überflogen - heute oder morgen schaue ich es mir noch mal genauer an. Zwei Punkte hätte ich aber schon:ski7777 hat geschrieben:Hat das schon remand reviewed? Gibt es Bugs, Anregungen oder so?
Grundsätzlich verstehe ich das Problem, aber solange wir nicht anders z.B. mit Signaturen oder so feststellen können, ob die Datei valide ist, sollten wir trotzdem irgendetwas überprüfen. Am Schluss bootet ein TXT nicht mehr, weil die zip korrupt war.richard.kunze hat geschrieben:
- Die Überprüfung der Dateigröße im Update-Script würde ich wieder rausnehmen. Das Script läuft mit Rootrechten (das muss es, um die Dateien an die richtige Stelle packen zu können), und ist deshalb absichtlich so primitiv wie möglich gehalten (je weniger das Script macht, desto weniger Möglichkeiten gibt es, dabei was falsch zu machen). Und die Größenprüfung hilft nicht so arg viel, braucht dafür aber einen Haufen Zeug (Python selbst, JSON, HTTP, ...). Eigentlich ist in dem Script schon das wget für den Download zuviel, aber solange wir keine echten signierten Files haben muss das Script den Download halt selbst machen damit man ihm nicht völlig trivial irgendwelche anderen Dateien unterschieben kann (mit Signatur - und die wird irgendwann kommen - fliegt der Download dann auch wieder raus, und das Script prüft dann nur noch die Signatur der schon vorliegenden Datei).
Das war mein erster Versuch. Ich hatte Versucht, das ganze so zu machen, wie früher bei den TextMode Apps, aber es wollte einfach nicht. Die AUsgaben kamen erst, als das Skript durch war und dann interessiert mich nur noch der ExitCode. ICh weiß, das die aktuelle Methode zugegebener Maßen sehr schmutzig ist, aber solange ich nichts anderes finden kann, muss ich es leider so machen.richard.kunze hat geschrieben:[/list]
- Schau mal, ob Du den Ouput vom Script statt über den Hack mit der temporären Datei nicht besser über eine Pipe in die GUI kriegst. Das relevante Python-Modul dafür ist subprocess, und Du willst daraus dann vermutlich subprocess.Popen() verwenden
Prinzipiell hast Du damit recht, aber die Prüfung der Dateigröße hilft dabei herzlich wenig. Wenn, dann müsste man da eine Checksumme der Datei prüfen (z.B. einen SHA-256-Hash oder etwas vergleichbares). Sowas gibts aber halt nicht "gratis" auf Github, und wenn wir selber eine Checksumme da hinlegen, dann können wir das mit demselben Aufwand auch gleich richtig machen und das Zipfile signieren (das Problem dabei ist übrigens nicht technisch, sondern organisatorsich: Wer darf Releases signieren, und wie organisiert man das so, dass der Signierschlüssel sicher aufgehoben wird, trotzdem nicht verlorengeht, und bei Bedarf auch sicher ausgetauscht werden kann).ski7777 hat geschrieben:Grundsätzlich verstehe ich das Problem, aber solange wir nicht anders z.B. mit Signaturen oder so feststellen können, ob die Datei valide ist, sollten wir trotzdem irgendetwas überprüfen. Am Schluss bootet ein TXT nicht mehr, weil die zip korrupt war.
Könnte eventuell daran liegen, dass die gesamte Ausgabe des Scripts problemlos in den Default-Puffer für die Pipe passt. Schau da vielleicht mal nach, wie man das in Python so einstellen kann dass die Pipe für stdout entweder gar nicht gepuffert wird, oder (am Besten) nur zeilenweise.ski7777 hat geschrieben:Das war mein erster Versuch. Ich hatte Versucht, das ganze so zu machen, wie früher bei den TextMode Apps, aber es wollte einfach nicht. Die AUsgaben kamen erst, als das Skript durch war
Sobald die eingebettet App in einen solchen Puffer schreibt wird sie (bzw. die EA-Bibliotheken, die sie nutzt)auch puffern. Deswegen leite ich immer über ptys, denn die können nicht puffern und das merkt die App und verhält sich entsprechend. Da findet man im Internet viele Diskussionen zu: http://stackoverflow.com/questions/1077 ... -bufferingrichard.kunze hat geschrieben: Könnte eventuell daran liegen, dass die gesamte Ausgabe des Scripts problemlos in den Default-Puffer für die Pipe passt. Schau da vielleicht mal nach, wie man das in Python so einstellen kann dass die Pipe für stdout entweder gar nicht gepuffert wird, oder (am Besten) nur zeilenweise.
Code: Alles auswählen
/usr/bin/netreq_setup.sh
Kannst Du die Build-Logs irgendwo mit ablegen? Dann könnte ich nach sowas schauen.PHabermehl hat geschrieben:Hmm, merkwürdig, ich mache grundsätzlich einen kompl. Rebuild...