Yadi-script-Entwickler kontaktieren?

[jw]

Hallo!

In den letzten Wochen habe ich mich mehr oder weniger intensiv mit den Internas von Yadi-Script befasst. Dabei sind mir eine Reihe von Ungereimtheiten aufgefallen.

Ich wuerde nun gerne diese Ungereimtheiten mit den Yadi-Entwicklern diskutieren. Leider scheint das nicht ganz einfach zu sein. Es scheint wohl keine Mailing-Liste zu existieren. Auf http://www.yadi.org wird lediglich auf dieses Forum hier verwiesen.

Wie geht man also vor, wenn man patches/bugfixes beitragen will oder einfach nur eventuelle Probleme (oder das was man fuer ein Problem haelt) mit den Entwicklern besprechen will?

[mogway]

Hi,

am besten im IRCnet #yadi oder per Mail, PN.

Gruß
mogway

[jw]

am besten im IRCnet #yadi oder per Mail, PN.

Hmm, von IRC halte ich nicht viel. Da muesste der entsprechende Entwickler (also derjenige, der evtl den Patch einspielen oder die Frage beantworten koennte) zur gleichen Zeit online sein. Das halte ich fuer sehr unwahrscheinlich.

Mail waere OK, aber wohin? Eine Maillist scheint nicht zu existieren. Einzelne Entwickler anzumailen halte ich wiederum fuer wenig sinnvoll, denn ich weiss ja nicht welcher Entwickler sich um welche Teilgebiete kuemmert.

Was ist "PN"?

[mogway]

Hmm, von IRC halte ich nicht viel. Da muesste der entsprechende Entwickler (also derjenige, der evtl den Patch einspielen oder die Frage beantworten koennte) zur gleichen Zeit online sein. Das halte ich fuer sehr unwahrscheinlich.

Morgends um 6:00 Uhr schon. Abends ab 22:00 Uhr nicht

Mail waere OK, aber wohin?

Hmmm, in den meisten Scripten stehen eMail Adressen. Du könntest auch einfach meinen eMail Button benutzen.

Was ist "PN"?

PN gibt es auch als Button, das ist dein Private Nachricht übers Forum.

Gruß
mogway

[jw]

Hmm, von IRC halte ich nicht viel. Da muesste der entsprechende Entwickler (also derjenige, der evtl den Patch einspielen oder die Frage beantworten koennte) zur gleichen Zeit online sein. Das halte ich fuer sehr unwahrscheinlich.

Morgends um 6:00 Uhr schon. Abends ab 22:00 Uhr nicht

Die Frage ist, ob man da dann _den_ Entwickler antrifft, der sich mit dem aktuellen Problem auskennt.

Mail waere OK, aber wohin?

Hmmm, in den meisten Scripten stehen eMail Adressen. Du könntest auch einfach meinen eMail Button benutzen.

Aeh, bei deiner ersten Antwort hatte ich noch garnicht realisiert dass du auch zu den Entwicklern gehoerst .

Da nutze ich die Gelegenheit doch gleich fuer eine Frage:
scripts/patch_cvs versucht cdk/linux-2.4.31/drivers/mtd/maps/dbox2-flash.c zu patchen. Das geht (zumindest beim ersten Durchlauf) schief, denn diese Datei wird erst spaeter (in scripts/squashfs_kernel) angelegt. Das Verhalten ist also nicht wirklich deterministisch. Beim ersten Durchlauf wird die ungepatchte dbox2-flash.c verwendet, bei allen spaeteren Durchlaeufen wird hingegen die gepatchte Version verwendet.

Was ist "PN"?

PN gibt es auch als Button, das ist dein Private Nachricht übers Forum.

Ummm... Also mit dem Forum habe ich noch so meine Probleme. Es ist zB garnicht so einfach die quoting-Ebenen sauber auf die Reihe zu kriegen. Das geht bei Mail erheblich einfacher.

[mogway]

Da nutze ich die Gelegenheit doch gleich fuer eine Frage:
scripts/patch_cvs versucht cdk/linux-2.4.31/drivers/mtd/maps/dbox2-flash.c zu patchen. Das geht (zumindest beim ersten Durchlauf) schief, denn diese Datei wird erst spaeter (in scripts/squashfs_kernel) angelegt. Das Verhalten ist also nicht wirklich deterministisch. Beim ersten Durchlauf wird die ungepatchte dbox2-flash.c verwendet, bei allen spaeteren Durchlaeufen wird hingegen die gepatchte Version verwendet.

Der erste Patch Aufruf (in patch_cvs) ist für das jffs2 Image, vor dem Aufruf von patch_cvs ist das Linuxdir ja schon vorhanden. Für das Squashfs wird eine andere dbox2-flash.c kopiert in (squashfs_kernel).

Gruß
mogway

[jw]

Der erste Patch Aufruf (in patch_cvs) ist für das jffs2 Image, vor dem Aufruf von patch_cvs ist das Linuxdir ja schon vorhanden.

Ah, das "make .deps/linuxdir" in configure hatte ich uebersehen. Danke fuer die Klarstellung.

Wenn wir schon dabei sind, moechte ich dich gleich mit der naechsten Frage nerven:
In neutrino_changes wird sowohl $DBOX/cdkflash/root/var als auch $DBOX/cdkflash/var befuellt. Ist das Absicht?
[/code]

[mogway]

In neutrino_changes wird sowohl $DBOX/cdkflash/root/var als auch $DBOX/cdkflash/var befuellt. Ist das Absicht?

Das ist ein Fehler, danke für die Info.

$DBOX/cdkflash/root/var ist der richtige Pfad. Für das Squashfs Image wird $DBOX/cdkflash/root/var später nach $DBOX/cdkflash/var verschoben (siehe squashfs_move_files).

Gruß
mogway

[jw]

Ich habe noch einige Sachen die ich nicht so ganz verstehe:
Zum Beispiel ruft enigma_changes "make install" innerhalb von $PLUGIN_DIR/boot auf. Dieses wiederum versucht nach
$DBOX/cdkflash/root/lib/tuxbox/eplugins zu installieren. Dieses Verzeichnis wird jedoch erst spaeter in squashfs_move_files angelegt. Beim allerersten Lauf wird also das boot-plugin nur im sqashenigma image installiert.

PS: Wieso ist eigentlich sqashfs_kernel im sqashenigma-Abschnitt vin scripts/yadi auskommentiert?

[mogway]

Zum Beispiel ruft enigma_changes "make install" innerhalb von $PLUGIN_DIR/boot auf. Dieses wiederum versucht nach
$DBOX/cdkflash/root/lib/tuxbox/eplugins zu installieren. Dieses Verzeichnis wird jedoch erst spaeter in squashfs_move_files angelegt. Beim allerersten Lauf wird also das boot-plugin nur im sqashenigma image installiert.

Da hat wohl der Pluginentwickler nicht den richtigen Pfad geprüft.

PS: Wieso ist eigentlich sqashfs_kernel im sqashenigma-Abschnitt vin scripts/yadi auskommentiert?

Der Kernel für das Squashfs wird ja schon in dem Neutrino Abschnitt (ein paar Zeilen darüber) gebaut. Somit ist dies im Enigma Teil nicht mehr nötig.

Gruß
mogway

[jw]

Zum Beispiel ruft enigma_changes "make install" innerhalb von $PLUGIN_DIR/boot auf. Dieses wiederum versucht nach
$DBOX/cdkflash/root/lib/tuxbox/eplugins zu installieren. Dieses Verzeichnis wird jedoch erst spaeter in squashfs_move_files angelegt. Beim allerersten Lauf wird also das boot-plugin nur im sqashenigma image installiert.

Da hat wohl der Pluginentwickler nicht den richtigen Pfad geprüft.

Hmm, und was heisst das konkret? Muss das Verzeichnis frueher erstellt werden? Oder muss das Makefile des plugins angepasst werden?

PS: Wieso ist eigentlich sqashfs_kernel im sqashenigma-Abschnitt vin scripts/yadi auskommentiert?

Der Kernel für das Squashfs wird ja schon in dem Neutrino Abschnitt (ein paar Zeilen darüber) gebaut. Somit ist dies im Enigma Teil nicht mehr nötig.

Waere es dann nicht sinnvoll, sqashfs_kernel aus dem gui-spezifischen Abschnitt herauszunehmen?

[mogway]

Hmm, und was heisst das konkret? Muss das Verzeichnis frueher erstellt werden? Oder muss das Makefile des plugins angepasst werden?

Ich habe gerade das Makefile entsprechend angepasst.

Waere es dann nicht sinnvoll, sqashfs_kernel aus dem gui-spezifischen Abschnitt herauszunehmen?

Imho nicht, da ja noch einige Dinge drumherum passieren.

Gruß
mogway

[jw]

Hmm, und was heisst das konkret? Muss das Verzeichnis frueher erstellt werden? Oder muss das Makefile des plugins angepasst werden?

Ich habe gerade das Makefile entsprechend angepasst.

Evtl wuerde es Sinn machen, bei solchen Fehlern den Script-Ablauf abzubrechen, damit man den Fehler fruehzeitig bemerkt? Auch wenn zB das Applizieren eines Patches fehlschlaegt waere es sinnvoll abzubrechen. Mir ist es schon mehrfach passiert dass ein Patch rejected wurde, der Fehler aber erst nach stundenlangem Compiler-Lauf an einer Stelle abbricht, bei der man nur schwer auf den eigentlichen Fehler (den Patch-Reject) schliessen kann.

[jw]

Folgende Passage in squashfs_move_files:

Code: Alles auswählen

cd $DBOX/cdkflash/var/
ln -sf /tmp tmp
ln -sf log tmp
ln -sf pid tmp
ln -sf run tmp

sieht mir auch ein wenig suspekt aus. Muesste das nicht

Code: Alles auswählen

cd $DBOX/cdkflash/var/
ln -sf /tmp tmp
ln -sf tmp log
ln -sf tmp pid
ln -sf tmp run

bzw.

Code: Alles auswählen

cd $DBOX/cdkflash/var/
ln -sf /tmp tmp
ln -sf /tmp log
ln -sf /tmp pid
ln -sf /tmp run

heissen?
[/code]

[mogway]

Evtl wuerde es Sinn machen, bei solchen Fehlern den Script-Ablauf abzubrechen, damit man den Fehler fruehzeitig bemerkt? Auch wenn zB das Applizieren eines Patches fehlschlaegt waere es sinnvoll abzubrechen. Mir ist es schon mehrfach passiert dass ein Patch rejected wurde, der Fehler aber erst nach stundenlangem Compiler-Lauf an einer Stelle abbricht, bei der man nur schwer auf den eigentlichen Fehler (den Patch-Reject) schliessen kann.

Wenn du möchtest kannst du dieses unterbinden:

Code: Alles auswählen

--- y_patch.sh  10 Oct 2004 15:56:17 -0000      1.15
+++ y_patch.sh  18 Jul 2005 20:22:39 -0000
@@ -109,7 +109,7 @@
     $EDITOR $ORIGINAL.rej &
     $EDITOR $ORIGINAL
    fi
-   read -p "Druecken Sie [RETURN] wenn die Aenderungen abgeschlossen sind -> " -t 15
+   read -p "Druecken Sie [RETURN] wenn die Aenderungen abgeschlossen sind -> "
   fi
 }

cd $DBOX/cdkflash/var/
ln -sf /tmp tmp
ln -sf /tmp log
ln -sf /tmp pid
ln -sf /tmp run

Ja, das sieht besser aus - Danke

Gruß
mogway

[jw]

Evtl wuerde es Sinn machen, bei solchen Fehlern den Script-Ablauf abzubrechen, damit man den Fehler fruehzeitig bemerkt?

Wenn du möchtest kannst du dieses unterbinden:

Ja, fuer diesen Einzelfall schon. Meine obige Bemerkung war aber allgemeingueltiger gemeint. Wenn irgendwo etwas schief geht, sollte IMHO ein Entwickler durch eine Fehlermeldung auf das Problem aufmerksam gemacht werden. Langfristig wird das eine deutliche Verbesserung der Code-Qualitaet mit sich bringen, weil Fehler schneller erkannt werden.

BTW: build_gui besorgt sich mitten im Build mittels "cvs update" zuvor geloeschte Dateien wieder. Das halte ich fuer problematisch. Sollte in der Zwischenzeit ein checkin stattgefunden haben, kann es zu Inkonsistenzen kommen. Der Build wuerde deterministischer werden, wenn man allen cvs-Aufrufen die -D option mitgeben wuerde. Mit der -D option wuerde es auch fuer nicht-Entwickler moeglich, ein Image zu bauen, das dem von den yadi-Entwicklern erstellten entspricht. Das wuerde nicht-Entwicklern die Fehlersuche erheblich erleichtern.