subversion für freetz

[cuma]

@er13: Kanns mit eigentlich nicht erklären, bekam keinen ping von der Box zurück und die Status-LED blinkte. Ich baue nachher einfach nochmal.
MOD_LIMIT hab ich eh erhöht, inetd benutze ich nicht

 

[er13]

wenn ich versuche, z.B. des Freetz-Repository auszuchecken bekomme ich folgende Fehlermeldung

Könntest Du bitte testen, ob der angehängte Patch Dein Problem löst? Mein Problem aus #36 löst er nämlich bzw. workarounded - da bin ich mir noch nicht sicher, wie ich es nennen soll. Daher würde ich, bevor ich ihn eincheck', erstmal klären, was dieses pthread-Problem auf sich hat, ob apr-/svn-Problem überhaupt dasselbe Problem ist, wodurch genau das Problem behoben wird, wenn man die Toolchain selber baut (so heißt es hier), wieso man es in der downloadable Version nicht beheben kann usw...

Edit: die Toolchain selber bauen hat leider nicht geholfen...

 

[cuma]

OK, neues Image bootet. War wohl irgendetwas anderes. Danke!

 

[olistudent]

Wenn ich jetzt wüßte, ob ich die Toolchain mit dem Fix neu gebaut habe. Theoretisch sollte das mit der Download-Toolchain vom Trunk nicht mehr auftreten, soweit ich mich erinnere. Aber ich schau nochmal.

MfG Oliver

edit: Sollte in r3325 passiert sein.

 

[Trialer1]

Hi,

ich bin neu hier und bin noch nicht in allen Themen so drin wie weit der Stand ist daher meine Frage.

Gibt es ein fertiges SVN Addon für Freetz inkl. WEB-IF?


Nachtrag:
Mir geht es darum Sachen aus einem SVN auszuchecken und nicht die FB als SVN Server zu nutzen

 

[olistudent]

Mir ist nicht so ganz klar was du damit machen willst? Wo liegt der Sinn darin ein svn von der Box aus auszuchecken?

Momentan gibt es keine Weboberfläche für den Client.

MfG Oliver

 

[Trialer1]

Der Sinn liegt darin, dass ich z.B. Fritz!Load Version aus dem SVN auschecken kann.
Damit erspare ich mir den Weg des Kopierens, der beim auschecken unter einem anderen System entsteht.
Normalfall:
- SVN Checkout
- auf Stick oder irgendwas kopieren
- auf FB kopieren
FERTIG

mein Fall:
- SVN Checkout
FERTIG

 

[er13]

Theoretisch sollte das mit der Download-Toolchain vom Trunk nicht mehr auftreten, soweit ich mich erinnere.

Damit die Patches aus make/target/uclibc/0.9.29 greifen, muss, wenn ich's richtig verstehe, die uClibc mit diesen übersetzt werden und anschließend die Version, die AVM liefert, durch diese ersetzt werden. In der Download-Toolchain wirst Du wahrscheinlich die Patches angewandt haben, die Version von AVM wird jedoch nicht ersetzt... Sofern die AVM die Patches nicht anwendet, besteht das Problem also in der Download-Toolchain weiterhin...

Eine Frage an Dich, Oliver, oder auch an den, der sich damit auskennt. Es gab/gibt ja mehrere Probleme mit der pthread-Implementierung in uClibc-0.9.29. Das Daemon-Problem wurde behoben. Bei den anderen gab's außer threads-Disablen keine richtige Lösung. Habe ich das so richtig den verschiedenen Threads bzw. Tickets entnommen?

Momentan gibt es keine Weboberfläche für den Client.

Und wird's von mir auch nicht geben, denn der Sinn von der "Weboberfläche für den Client" ist mir völlig unklar. Was noch auf meiner TODO-Liste steht, ist das Trennen des subversion-Packages in subversion und subversion-cgi. Momentan ist es nämlich möglich nur den Client zu selektieren, die Weboberfläche zum Konfigurieren des Servers landet aber mit in der Firmware. Kann man übrigens die Files aus dem files Verzeichnis des Pakets selektiv installieren(dann müsste man das Paket nicht aufteilen) oder werden immer alle installiert?

 

[HAL 9000]

Eine kleine Verbesserung für die Einzelauswahl: Gebaut werden ja nicht nur die diversen svn-binaries, sondern auch noch jede Menge Bibliotheken (/usr/lib/libsvn*). Allerdings hängt nicht jedes binary von allen diesen Bibliotheken ab. Durch den angehängten Patch werden nur die Bibliotheken ins image gepackt, die für die ausgewählten binaries gebraucht werden.
Mein svn auf der Box läuft schon mit dem patch, ich habe allerdings nicht alle möglichen Kombinationen von binaries getestet, feedback ist also gerne willkommen.

 

[olistudent]

In freetz-1.1.1 wird noch eine ältere Version der Download-Toolchain genutzt. Darin ist der Fix noch nicht enthalten. In der Download-Toolchain die der Trunk nutzt ist der Fix drin!

Die Probleme in den Paketen wurden "umgangen" indem threads deaktiviert wurden. Nachdem die Ursache des Problems in der uClibc gelöst ist kann pthreads für die betreffenden Pakete wieder aktiviert werden. Bei meinen Versuchen war es jedoch so, dass das Problem nur für dynamische Binaries gelöst war, aber nicht für statische. (uClibc-Ticket)

MfG Oliver

 

[er13]

@HAL9000: bitte nicht böse sein, aber in dem Zustand werde ich den Patch nicht einchecken. Ich habe schon viele Code-Clones im Makefile, Du machst noch mehr draus. Ein logisches OR kann übrigens mittels filter simuliert werden (ein echtes OR fehlt leider in make):

ifneq (,$(filter value,$(VAR1) $(VAR2)))

Außerdem würde ich mich ungern um die internen Abhängigkeiten von subversion (manuell) kümmern müssen, wer weiß, ob sich diese von Version zu Version nicht ändern. Eine "readelf -d und grep"-basierte Lösung wäre mir da deutlich lieber.

 

[HAL 9000]

Böse bin ich nicht, dass das hässlich aussieht weiß ich selbst Dass es kein oder gibt ist mir aufgefallen, und das mit dem filter kannte ich so nicht, deshalb wusste ich nicht wies besser geht.
Die Clones kann ich noch rausmachen, aber das mit readelf und grep ist mir im Moment zu hoch. Wenn das die Voraussetzung fürs einchecken ist, dann darf sich jemand anders drum kümmern (oder eben nicht, mir eigentlich egal denn bei mir läufts so )