Mal wieder Probleme beim Kompilen der ftplib

[lord-of-linux]

Hallo,

ich habe mal wieder ein paar Probleme beim Kompilieren einer Bibliothek, dieses mal bei der ftplib. (http://nbpfaus.net/~pfau/ftplib/)

Ich habe ein makefile erstellt und dieses funktioniert soweit auch. Allerdings funktioniert die kompilierte Bibliothek nicht. Ich habe es mit dem enthaltenen qftp getestet und bekomme folgende ausgabe:

/var/tmp/ftplib $ ./qftp list 127.0.0.1 -l ftpuser -p PW -r uStor01
getservbyname: Input/output error
Unable to connect to node 127.0.0.1

Ich steig da mit meinen mangelnden C-Kenntnissen leider nicht durch, brauche die Lib aber für ein Programm, dass gerade in der Entwicklung ist. Vielleicht kann mal jemand drüberschauen?

Hier gibt es mein Makefile und ein Patch für das ganze:
http://lord-of-linux.homelinux.net/svn/solarlog/other-projects/fritzbox_ds-mod/makefiles/ftplib/

 

[olistudent]

Kann es sein, dass getservbyname die /etc/services benötigt?

MfG Oliver

 

[lord-of-linux]

Ja, das ist es. Danke. Mit soetwas einfachem habe ich nun garnicht gerechnet.

Wie kann ich denn am Einfachsten die Datei schon vor dem Flashen anpassen?
EDIT: Ich meine hiermit am Liebsten gleich per makefile.

 

[kriegaex]

Falls Du ein DS-Mod-Paket (kein Add-On) baust, kannst Du die Datei im Package-Unterverzeichnis erzeugen. Aber Vorsicht, andere Pakete könnten heute oder in Zukunft ebenfalls /etc/services enthalten - die letzte beim Firmware-Bau von fwmod eingebaute Version würde gewinnen. Momentan enthält OpenNTPD eine /etc/services. Am saubersten wäre es, wenn alle Pakete die als leeres Dummy unter root/etc existierende Datei per sed oder cat >> bla modifizieren statt dumpf anlegen würden, aber momentan ist das nicht so, weil nur OpenNTPD sie benutzt. (Ich weiß, ich erzähle Dir wahrscheinlich mehr, als Du wissen willst).

Eine weitere simple Möglichkeit, die Datei unter root/etc anzulegen oder zu patchen bietet fwmod_custom, vgl. meinen Beitrag dazu weiter oben im Thread.

Ach ja, noch ein Tip: Falls Du root/etc/services als Symlink z.B. auf /var/tmp/services anlegst, kann Dein Paket oder Add-On auch zur Laufzeit (z.B. beim ersten Start) die Datei modifizieren, das ist noch flexibler.

 

[lord-of-linux]

Thx, das ist ja genug auswahl.

Habe mich für die fwmod_custom-Merhode entschieden.

PS: Wann dürfte den die nächste Version des Mods kommen? Vielleicht habt ihr ja Lust, die ftplib mit aufzunehmen?

 

[kriegaex]

Es ist keine neue Version geplant im Moment, wir machen nicht viel. Nennen wir es so eine Art Sommerpause.

Wenn es ein sinnvolles Einsatzszenario für die Ftplib gibt, können wir sie durchaus in den Mod mit aufnehmen, mir fällt momentan aber keines ein. Wir haben Wget und BusyBox-ftpget für Downloads und Bftpd als Server zusätzlich zum AVM-ftpd sowie BusyBox-ftpput für den Upload. Mach doch mal ein bißchen Werbung für Ftplib.

 

[olistudent]

Habe mich für die fwmod_custom-Merhode entschieden.

So war das mit dem Patch nicht gemeint! :mrgreen:
Nicht die fwmod wird gepatcht, sondern die /etc/services aus fwmod.

MfG Oliver

 

[kriegaex]

Hat jemand etwas anderes gesagt? (verwirrtsei)

 

[olistudent]

Nö, aber gemacht. Link

MfG Oliver

 

[kriegaex]

211-fwmod_custom.ftplib.patch sieht für mich in Ordnung aus. Er bewirkt, daß wiederum fwmod_custom unter build/modified/filesystem die etc/services patcht, das ist ordentlich gelöst, finde ich.

 

[lord-of-linux]

Es ist keine neue Version geplant im Moment, wir machen nicht viel. Nennen wir es so eine Art Sommerpause.

Wenn es ein sinnvolles Einsatzszenario für die Ftplib gibt, können wir sie durchaus in den Mod mit aufnehmen, mir fällt momentan aber keines ein.

OK, dann habe ich ja noch ein bisschen Zeit, auch das eigentliche Programm makefile-Mäßig aufzubereiten. Handelt sich dabei um einen Logger für Photovoltaik-Anlagen. Das heißt, er zeichnet informationen der Wechselrichter auf, die per serieller Schnittstelle abgefragt werden. Der Daemon kümmert sich dann um die Veröffentlichung des Status auf einem Webserver und macht dazu eben einen ftp-Upload. Der Entwickler hat sich dazu für ftplib entschieden und somit brauche ich eben diese.


@olistudent: Wie von Alexander schon festgestellt, patche ich fwmod_custom, damit diese die Datei erstellt oder um FTP ergänzt, falls falls sie schon vorhanden ist. Somit wird nicht einfach der OpenNTP-Eintrag überschrieben. Wie hätte ich es sonst elegant lösen können/sollen?


PS: Wie erfolgt bei euch eigentlich die Durchnummerierung der Patches?

 

[RalfFriedl]

Die Nummern der Patches bewirken, daß die Patches in der angegebenen Reihenfolge ausgeführt werden.

Solange sich die Patches auf verschiedene Dateien beziehen, ist die Reihenfolge, in der sie ausgeführt werden, nicht von Bedeutung.

 

[olistudent]

Okay.
Da hat jemand weitergedacht wie ich:

if [ ! -z "`cat fwmod_custom | grep ftp`" ]; then rm $(FTPLIB_MAKE_DIR)/patches/*fwmod*.ftplib.patch; fi

MfG Oliver

 

[lord-of-linux]

Okay.
Da hat jemand weitergedacht wie ich:

Aber erst nachdem es eine Fehlermeldung diesbezüglich gab *g*

 

[RalfFriedl]

Trotzdem ist es keine gute Idee, eine Quelldatei zu löschen, und die Patch Datei ist in diesem Fall auch eine Quelldatei.

Eine Idee wäre, im ds-mod die Datei fwmod_custom in fwmod_custom-template umzubenennen. Wer sie verwenden will, kopiert sie nach fwmod_custom und macht dort seine Änderungen. Das Skript fwmod prüft, ob die Datei existiert und ruft sie nur auf, wenn sie vorhanden ist.

Dadurch würde nie eine fwmod_custom durch eine leere ersetzt, wenn man einen neuen ds-mod auspackt. Wenn man mit einem neuen ds-mod in einem anderen Verzeichnis anfängt, muß man daran denken, die fwmod_custom (und .config und verschiedene andere) aus dem alten Verzeichnis zu übernehmen.

Das konkrete Problem mit /etc/services ließe sich so lösen, daß jedes Package die benötigten Zeilen für diese Datei an einem festgelegten Platz ablegt und fwmod sie dann einsammelt und daraus eine Datei /etc/services erstellt.

 

[lord-of-linux]

Ich stimme RalfFriedl zu, da wäre eine Möglichkeit seitens des ds-mod, die sich um solche Aufgaben kümmert, wahrscheinlich das Beste. Denn wenn jemand seine fwmod_custom für sich angepasst hat, dann funktioniert dieser Patch auch nicht.

Und zum Löschen des Patches: Das habe ich gemacht, da ansonsten ja immer Fehler auftreten, die keine sind. Und die fwmod_custom bleibt dann ja so. Aber vorerst ist das wohl eine der elegantesten Lösungen denke ich.

 

[kriegaex]

Moment, Moment! Wer die fwmod_custom ändert, soll sich bitteschön selbst darum kümmern, private Add-Ons so einzubauen, daß sie auch funktionieren. Der Patch ist aus meiner Sicht reine Bequemlichkeit. Wenn er nicht paßt, weil die fwmod_custom schon verändert wurde - Pech gehabt. Dann kopiert man die paar Zeilen selbst rein und nimmt die Pluszeichen vorne weg. Ich kann mir auch durchaus ein begleitendes README oder INSTALL vorstellen, das die Zeilen enthält. Es ist schlechterdings unmöglich, daß jedes nicht zum DS-Mod gehörende Add-On alle anderen kennt und entsprechende Patch-Varianten enthält.

Wer einen DS-Mod auspackt, muß wissen, was er tut, wenn er ihn über einen vorhandenen entpackt. Die Idee mit dem fwmod_custom-Template lehne ich ab. Custom heißt nicht umsonst Custom. Ich überlebe es auch, falls Oliver das ändert, finde es aber reichlich übertrieben und unnötig.

 

[olistudent]

Wieso sollte ich? :gruebel:

MfG Oliver

 

[kriegaex]

Vielleicht, weil Du als der andere "Kern-Entwickler" zu einer anderen Einsicht hättest gelangen können als ich. Ich lebe schließlich auch nur in meiner eigenen kleinen Welt und habe die Weisheit nicht gepachtet, auch wenn ich mir größte Mühe gebe, so zu wirken. ;-)

 

[lord-of-linux]

Moment, Moment! Wer die fwmod_custom ändert, soll sich bitteschön selbst darum kümmern, private Add-Ons so einzubauen, daß sie auch funktionieren. Der Patch ist aus meiner Sicht reine Bequemlichkeit. Wenn er nicht paßt, weil die fwmod_custom schon verändert wurde - Pech gehabt. Dann kopiert man die paar Zeilen selbst rein und nimmt die Pluszeichen vorne weg. Ich kann mir auch durchaus ein begleitendes README oder INSTALL vorstellen, das die Zeilen enthält. Es ist schlechterdings unmöglich, daß jedes nicht zum DS-Mod gehörende Add-On alle anderen kennt und entsprechende Patch-Varianten enthält.

Das will ich ja garnicht. Vielleicht habt ihr ja irgend eine Idee, sowas wie die Anpassung der /etc/services zu standardisieren, damit man nicht von so einem Patch wie diesem abhängig ist oder es manuell machen muss. Ist ja nur ne Anregung.

Wer einen DS-Mod auspackt, muß wissen, was er tut, wenn er ihn über einen vorhandenen entpackt. Die Idee mit dem fwmod_custom-Template lehne ich ab. Custom heißt nicht umsonst Custom. Ich überlebe es auch, falls Oliver das ändert, finde es aber reichlich übertrieben und unnötig.

Da bin ich teilweise auch deiner Meinung. Allerdings sollte es vielleicht eine Alternative geben. Ich würde so ne Art fwmod pro Paket vorschlagen. Also jeweils in make/SOFTWARE/fwmod
Das sollte bei sauberer Programmierung dieser Scripte dann ja die Aufgabe lösen.