Netatalk Paket (TimeMachine): Devs gesucht / Looking for Devs

[ebeneezer]

Sorry nicht verstanden - vielleicht kannst Du mal direkt schauen: ssh freetz:[email protected]

 

[sf3978]

Sorry nicht verstanden - ...

Was hast Du nicht verstanden bzw. was soll ich nachschauen?

 

[ebeneezer]

Da hatten sich zwei Antworten überschnitten: Trunk frisch ausgechecked und make menuconfig gemacht, ja.

 

[sf3978]

... Trunk frisch ausgechecked und make menuconfig gemacht, ja.

OK, dann kann ich dir nicht weiter helfen. Ich empfehle dir, dich zu gedulden. Wenn ein Freetzentwickler, Zeit, Lust und Laune hat, wird man dir evtl. helfen.

EDIT:

Evtl. versuchst Du es mit einem anderen Linux (als Build-System). Ich habe schon einige Male bei Freunden, auf deren PCs mit Windows als OS, mit der aktuellen KNOPPIX-Live-DVD, ohne Probleme erfolgreich funktionierende Freetz-Images kompiliert.

 

[ebeneezer]

Lösung:

Das Problem war die LD_LIBRARY_PATH Environment Variable. Diese zeigt auf einen falschen Pfad und erzeugt einen Fehler bei der Suche nach den Libs der libdb, was aber ursächlich gar nichts mit libdb zu tun hat (daher sucht man in die falsche Richtung).

Schnelle, schmutzige Lösung: Im configure im source dir von netatalk direkt vor der Suche nach den libdb Libraries LD_LIBRARY_PATH leeren (Zeile 31460 etwa):

---
atalk_cv_bdb_version=no
maj=$atalk_cv_bdb_MAJOR
min=$atalk_cv_bdb_MINOR
atalk_cv_bdb_try_libs="db$maj$min db$maj.$min db-$maj$min db-$maj.$min db$maj-$maj.$min db"

export LD_LIBRARY_PATH=""


for lib in $atalk_cv_bdb_try_libs ; do
LIBS="-l$lib $savedlibs"
{ echo "$as_me:$LINENO: checking Berkeley DB library (-l$lib)" >&5
echo $ECHO_N "checking Berkeley DB library (-l$lib)... $ECHO_C" >&6; }
if test "$cross_compiling" = yes; then

bdblibs=`ls $bdblibdir/lib$lib.* 2>/dev/null`

---

Dann alles gut und netatalk läuft auch.

Fritzbox 7390 nun in meinem Mac Netzwerk!

 

[sf3978]

... die LD_LIBRARY_PATH Environment Variable. Diese zeigt auf einen falschen Pfad und erzeugt einen Fehler bei der Suche nach den Libs der libdb, ...

Warum ist das bei dir so?

 

[BBsan]

sehr seltsam.. Ich habe auf einem frisch aufgesetzten ubuntu server 32bit genau dasselbe Problem, auf meiner Desktop Edition klappt es aber 100%

 

[er13]

@BBsan: könntest Du bitte die config.log (zu finden in source/target-mips*_uClibc-*/netatalk-2.2.0) von dem Rechner, auf dem configure scheitert, hier anhängen. Ich habe mir das configure-Script angeschaut und auch LD_LIBRARY_PATH auf einen unsinnigen Wert gesetzt und kann bisher nicht nachvollziehen, was es mit LD_LIBRARY_PATH zu tun haben soll. Bei mir klappt es mit und ohne LD_LIBRARY_PATH.

 

[boing2]

Hallo,

ich habe eine 7390 und würde gerne netatalk mit time machine benutzen. Super, dass es das jetzt für freetz gibt!

Jetzt habe ich den aktuellen trunk ausgecheckt und versucht in make menuconfig netatalk auszuwählen, kann es aber weder unter Standard- noch Testing Packages finden. Auf freetz.org wird es ja als unstable gelistet. Wie kann ich das Package denn dann auswählen?

Empfiehlt es sich eigentlich dafür auch HFS+ zu installieren oder kann ich einfach ein FAT32 oder Ext2/3 nehmen?

 

[olistudent]

Na, wahrscheinlich unter "unstable". ;-)

Gruß
Oliver

 

[boing2]

Danke. Mit dem Workaround für den Berkeley DB Pfad kompiliert es auch durch.

Wie gross schätzt ihr denn die Chance das der trunk in Grundkonfiguration + netatalk auf der 7390 läuft?

 

[sf3978]

... Workaround für den Berkeley DB Pfad kompiliert es auch durch.

Welches linux hast Du als Build-System?

 

[boing2]

Ubuntu 11.04 32-bit in einer Virtual Box VM, die ich extra für den Zweck frisch aufgesetzt habe.

 

[er13]

Mit dem Workaround für den Berkeley DB Pfad kompiliert es auch durch.

Und würde bitte jemand endlich die config.log (s. hier) hier anhängen, damit wir das Problem lösen können?

 

[boing2]

Hier ist das File. Allerdings nachdem ich den "export LD_LIBRARY_PATH=""" Workaround gemacht habe. Ich habe es zwischendurch nach der Fehlermeldung aber nicht gelöscht. Wenn ich den Fehler nochmal frisch reproduzieren soll, sag Bescheid.

 

[er13]

Natürlich brauchen wir die config.log von dem gescheiterten configure-Lauf.

 

[boing2]

Ok, hier das config.log von dem gescheiterten make Lauf.

 

[boing2]

Falls ich einen Fix testen soll, sagt Bescheid.