subversion für freetz

Edit: Bei mir hat alles sauber gebaut, als ich in einem frisch ausgecheckten freetz-ordner getestet habe. Eben habe ich das gleiche mal in meinem normalen Ordner probiert, aber da kam ein Fehler:
ich bin zwar nicht sicher, vermute jedoch, dass es bei dem Fehler um eine (durch ein configure-script?) beschädigte make/config.cache handeln könnte. In dieser könnten u.U. die auf den host und nicht auf das target zutreffenden Werte stehen. Aus einem ähnlich komischen Fehler ist auch mein Patch für expat.mk entstanden. Kannst Du vielleicht Deine config.cache umbennen/löschen und es nochmal in "deinem normalen Ordner" versuchen.

Wenn man googelt, findet man allerdings auch andere Erklärungen für Dein Problem.

[cut] -rpath /usr/lib [cut]
Kennt sich jemand mit dieser -rpath Geschichte aus? Wie wichtig ist es, dass diese Option nicht verwendet wird? Ich habe gesehen, dass einige Packages mit --disable-rpath konfiguriert werden. Leider unterstützt weder apr- noch subversion-configure-script diese Option, sodass man dieses -rpath, sofern es tatsächlich nicht verwendet werden darf, vor der Aufnahme in trunk noch rauspatchen müsste.
 
Hab' an das von astrapi erstellte Ticket meine aktuelle Version angehängt. Diese enthält
  • alle bisher in diesem Thread veröffentlichten Patches (zwar etwas überarbeitet, dennoch Danke an HAL9000 und astrapi)
  • Korrektur für die apr-util-URL
  • Korrektur für den cross-compile configure error in apr.mk (ac_cv_sizeof_struct_iovec wird jetzt explizit auf 8 gesetzt)
  • external feature für subversion
Das Ganze ist immer noch nur oberflächlich getestet, scheint jedoch zu laufen. Etwas mehr Feedback wäre wünschenswert.
 
hier nun der WebIF Patch. Vorerst ist nur der Pfad zu den Repositorys einstellbar. Was wäre noch nötig?

Benutzer- und Gruppenrechte für das Repository wären nicht schlecht. Nötig vielleicht nicht, aber schön zu haben.

Ansonsten: super Arbeit! Werde ich bei Gelegenheit mal richtig testen.
 
config.cache löschen hat erstmal nichts gebracht. Als ich danach mal ein make distclean versucht habe, habe ich festgestellt, dass ich gar keine neue Toolchain bauen konnte. Offenbar sitzt das Problem da etwas tiefer. Ich habe dann die Toolchain auf gcc 4.1.2 umgestellt, und damit läuft alles. Subversion läuft jetzt auf der Box. Webinterface geht auch, nachdem ich die o.g. Rechte gesetzt habe (+x für subversion.cgi und rc.subversion). Wenn ich noch irgendwas finde sage ich bescheid :)
 
Hallo,

irgendwie funktioniert das Anhängen der Dateien im Trac grade nicht, daher hänge ich mal die aktuelle Version hier an. Änderungen:
  • RPATH wird nicht mehr hardkodiert
  • Fehler im inetd-Modus beseitigt (Pfad zum Repository wurde vergessen)
  • md5-checksums in .mk Dateien hinzugefügt
  • die in config.cache gecachten ac_cv_path_(PERL|PYTHON|RUBY) Variablen werden umbenannt, um sicherzustellen, dass die von uns gesetzten Werte ("none") nur von subversion verwendet werden. Würde man es nicht tun, so könnte es dazu führen, dass andere Pakete nicht mehr übersetzt werden, die perl/python/ruby zum Übersetzen brauchen (bei mir war das wol, welches perl zum Doku-Übersetzen gebraucht hat).
  • svnserve wird nun unter einem eingeschränkten User gestartet
 

Anhänge

  • apr_aprutil_subversion-20091017.patch.bz2
    12.6 KB · Aufrufe: 0
Zuletzt bearbeitet:
Ich hab beim Bauen von apr-util folgenden Fehler:
Code:
checking whether /home/oliver/fritzbox/freetz/trunk-test/toolchain/target/bin/mipsel-linux-uclibc-gcc accepts -g... (cached) yes
checking for /home/oliver/fritzbox/freetz/trunk-test/toolchain/target/bin/mipsel-linux-uclibc-gcc option to accept ISO C89... (cached) none needed
Applying apr-util hints file rules for mipsel-unknown-linux-gnu
checking for APR... yes
[B]./configure: line 3913: cd: /usr/share/apr-1/build: No such file or directory[/B]
  setting CPP to "/home/oliver/fritzbox/freetz/trunk-test/toolchain/target/bin/mipsel-linux-uclibc-gcc -E"
  setting CPPFLAGS to " -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE"
checking how to run the C preprocessor... /home/oliver/fritzbox/freetz/trunk-test/toolchain/target/bin/mipsel-linux-uclibc-gcc -E
checking for grep that handles long lines and -e... (cached) /bin/grep
checking for egrep... (cached) /bin/grep -E
checking for ANSI C header files... (cached) yes
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking for strings.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for ldap support...
checking for default DBM... sdbm (default)
  adding "-I/home/oliver/fritzbox/freetz/trunk-test/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include" to CPPFLAGS
  setting LDFLAGS to "-L/home/oliver/fritzbox/freetz/trunk-test/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/lib "
configure: checking for sqlite3 in /home/oliver/fritzbox/freetz/trunk-test/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr
checking sqlite3.h usability... yes
checking sqlite3.h presence... yes
checking for sqlite3.h... yes
checking for sqlite3_open in -lsqlite3... yes
  adding "-I/home/oliver/fritzbox/freetz/trunk-test/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include" to APRUTIL_PRIV_INCLUDES
checking sybdb.h usability... no
checking sybdb.h presence... no
checking for sybdb.h... no
checking freetds/sybdb.h usability... no
checking freetds/sybdb.h presence... no
checking for freetds/sybdb.h... no
checking for odbc_config... no
checking sql.h usability... no
checking sql.h presence... no
checking for sql.h... no
checking odbc/sql.h usability... no
checking odbc/sql.h presence... no
checking for odbc/sql.h... no
  setting LDFLAGS to "-L/home/oliver/fritzbox/freetz/trunk-test/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/lib"
  adding "-I/home/oliver/fritzbox/freetz/trunk-test/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include" to CPPFLAGS
  setting APRUTIL_INCLUDES to "-I/home/oliver/fritzbox/freetz/trunk-test/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/include"
  setting APRUTIL_LDFLAGS to "-L/home/oliver/fritzbox/freetz/trunk-test/toolchain/build/gcc-4.2.4-uClibc-0.9.29/mipsel-linux-uclibc/usr/lib"
checking Expat 1.95.x... yes
  setting APRUTIL_EXPORT_LIBS to "-lexpat"
  setting APRUTIL_LIBS to "-lexpat"
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
  setting LIBS to "-liconv"
  adding "-liconv" to APRUTIL_LIBS
  adding "-liconv" to APRUTIL_EXPORT_LIBS
  nulling LIBS
checking for type of inbuf parameter to iconv... char **
checking for iconv.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking for nl_langinfo... yes
checking for CODESET in langinfo.h... yes
checking whether APR has DSO support... no
checking for library containing crypt... -lcrypt
checking if system crypt() function is threadsafe... no
checking for crypt_r... no
  adding "-lapr-1" to APRUTIL_LIBS
  adding "-lm" to APRUTIL_LIBS
  adding "-lcrypt" to APRUTIL_LIBS
  adding "-lpthread" to APRUTIL_LIBS
[B]cp: cannot stat `/apr_rules.mk': No such file or directory[/B]
configure: updating cache /home/oliver/fritzbox/freetz/trunk-test/make/config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: creating export_vars.sh
config.status: creating build/pkg/pkginfo
config.status: creating apr-util.pc
config.status: creating apu-1-config
config.status: creating include/private/apu_select_dbm.h
config.status: creating include/apr_ldap.h
config.status: creating include/apu.h
config.status: creating include/apu_want.h
config.status: creating test/Makefile
config.status: creating include/private/apu_config.h
config.status: executing default commands
configure: WARNING: unrecognized options: --with-gnu-ld, --disable-nls
touch source/apr-util-1.3.9/.configured
PATH="/home/oliver/fritzbox/freetz/trunk-test/toolchain/target/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" \
                make -j2 -C source/apr-util-1.3.9
make[1]: Entering directory `/home/oliver/fritzbox/freetz/trunk-test/source/apr-util-1.3.9'
Makefile:48: /home/oliver/fritzbox/freetz/trunk-test/source/apr-util-1.3.9/build/rules.mk: No such file or directory
make[1]: *** No rule to make target `/home/oliver/fritzbox/freetz/trunk-test/source/apr-util-1.3.9/build/rules.mk'.  Stop.
make[1]: Leaving directory `/home/oliver/fritzbox/freetz/trunk-test/source/apr-util-1.3.9'
make: *** [source/apr-util-1.3.9/.libs/libaprutil-1.so.0.3.9] Error 2
Ubuntu 9.04

MfG Oliver

edit: Hm, funktioniert plötzlich. Da hatte ich wohl noch eine alte Version der apr.mk.
 
Zuletzt bearbeitet:
So, die TODO-Liste ist abgearbeitet, alles getestet, bisher keine Fehler gefunden, in trunk eingechecked (damit hier eigentlich zu). Wer dennoch irgendwelche Probleme/Wünsche hat, bitte melden.

Benutzer- und Gruppenrechte für das Repository wären nicht schlecht. Nötig vielleicht nicht, aber schön zu haben.
Die einfachste Lösung wäre, das Editieren entsprechender Config-Files übers WebIf zu ermöglichen. Mache ich vielleicht bei Gelegenheit. Irgendetwas mit "Config-Files generieren" ist mir zu aufwendig.
 
Post 1: [gelöst]

ich weiß nicht ob das geklapt hat, im trac: Speicher des Pfades funktioniert nicht, hab die subversion.cgi entsprechend angepasst und patch im trac angehangen ...

http://trac.freetz.org/ticket/567

Post2:
Kann man svnserve tatsächlich auch über inetd starten, hast Du das getestet?

Theoretisch schon, nur leider nicht im derzeitigen trunk. Dort findet (in meinen Augen) ein komisches Verhalten statt:

1.

- Einstellung im WebIF - Starttyp: inetd
- svnserve startet nicht.

2.
- Einstellung im WebIF - Starttyp: manuell und händisches hinzufügen von
Code:
3690    stream    tcp    nowait    svn    /usr/bin/svnserve    svnserve -i --root /var/media/ftp/uStor01/root/srv/svn/repos
- svnserve startet
- ps bringt folgendes:
Code:
/usr/bin/svnserve --daemon --pid-file /var/run/svnserve.pid --listen-host 0.0.0.0 --listen-port 3690 --root /var/media/ftp/uStor01/root/srv/svn/repos
 
Zuletzt bearbeitet:
Vielen Dank für die Aufnahme von subversion in Freetz! Ich habe bei meiner aktuellen Freetz-Zusammenstellung nur "svn" ausgewählt, was auch fehlerfrei durchgelaufen ist, nur wenn ich versuche, z.B. des Freetz-Repository auszuchecken bekomme ich folgende Fehlermeldung:
Code:
/var/media/ftp/uStor01/SVNROOT # svn co http://svn.freetz.org/tags/freetz-1.1.1/
svn: OPTIONS of 'http://svn.freetz.org/tags/freetz-1.1.1': Unknown error. (http://svn.freetz.org)

Hat irgendjemand eine Ahnung, woran das liegen könnte?
 
Vielleicht bringst du mal strace mit auf die Box, denn der Fehler passiert nicht auf einem "echten" Linux.
 
@Silent-Tears: wen meinst du?
 
Ich meinte "The Brad", weil er den Fehler hat. Gut, oder jemand, der den Fehler nachvollziehen kann.
 
leider nicht im derzeitigen trunk. Dort findet (in meinen Augen) ein komisches Verhalten statt:

1.
- Einstellung im WebIF - Starttyp: inetd
- svnserve startet nicht.
hmm, startet nicht wann, sofort!? muss auch nicht, der svnserve-Prozess wird ja von inetd erst dann gestartet, wenn an dem eingestellten Port eine Anfrage ankommt. Bei mir wird der Prozess (bei einer Anfrage) auf jeden Fall gestartet, es gibt allerdings ein anderes Problem. Irgendwie fehlen dem von inetd gestarteten svnserve die Rechte - es kann auf irgendein temporäres Verzeichnis nicht zugreifen. Lässt man svnserve im inetd-Modus mit root-Rechten laufen, so funktioniert bei mir alles einwandfrei. Komisch an dem Problem ist, dass es nicht von Anfang an gegeben hat, sondern erst aufgetreten ist als mein Repository etwas gewachsen ist. Ich bin auf jeden Fall an dem Problem dran.

Das mit dem "komischen Verhalten" würde ich Dich bitten nochmals zu überprüfen, insbesondere ob Du den inetd-Modus auch wirklich richtig verstehst. Lauter svn-Anfragen gleichzeitig kannst Du z.B. mit Eclipse in "SVN Repositories"-View erzeugen, indem Du den Repository-Baum wild aufklappst, so verpasst Du svnserve bestimmt nicht.
 
Ich habe bei meiner aktuellen Freetz-Zusammenstellung nur "svn" ausgewählt, was auch fehlerfrei durchgelaufen ist, nur wenn ich versuche, z.B. des Freetz-Repository auszuchecken bekomme ich folgende Fehlermeldung:
Interessant, geht bei mir auch nicht, allerdings mit einer anderen Fehlermeldung (mit der gleichen wie hier). Dafür geht aber das Auschecken anderer Repositories, darunter auch welche mit http_s_ als Protokoll. Bei https geht die Box von der Last her schon an ihre Grenzen. Was bei mir definitiv nicht geht, ist das Auschecken großer Dateien, viel habe ich nicht probiert, aber bei einer 230MB großen Datei hat die Box brav neugestartet. Ich google mal weiter bezüglich Deines Problems, vielleicht findet sich die Lösung.
 
Das mit den grossen Files ist ziemlich klar, denn imho wird bei svn das File erst im Speicher gehalten, bis es vollständig ist. Mach bei 230MB schon nen grossen Brocken aus, der mit swap ja vielleicht zu bewältigen wäre, dort aber denke ich der Watchdog zuschläg, da das Schreiben von ca. 200MB swap doch ne Weile dauert.
 
Das mit dem "komischen Verhalten" würde ich Dich bitten nochmals zu überprüfen, insbesondere ob Du den inetd-Modus auch wirklich richtig verstehst. Lauter svn-Anfragen gleichzeitig kannst Du z.B. mit Eclipse in "SVN Repositories"-View erzeugen, indem Du den Repository-Baum wild aufklappst, so verpasst Du svnserve bestimmt nicht.

Sicher hab ich das richtig verstanden. Der Prozess wird nicht gestartet, heißt, das er bei Anfragen aus dem Netz nicht gestartet wird. Das Ändern auf root, bring den Erfolg. Was spricht dagegen?

Das Verhalten bei manuellen eintragen in die /etc/inetd.conf über das WebIF besteht wie beschrieben. Dort startet der Prozess auch ohne Anfragen aus dem Netz. Ist allerdings nicht so von Bedeutung.
 
Hi, könnte ihr das SSL noch statisch ermöglichen? Ich hab eine libcrypto-Warnung :-(
Es wäre auch noch toll wenn svnserve "nice" gestartet werden kann. Hatte das bislang immer so, da manchmal große Last verursacht wird.
 
Zuletzt bearbeitet:
Sicher hab ich das richtig verstanden.
bitte, bitte nicht böse sein, aus Deinem Posting oben war (mir) das nicht ganz ersichtlich bzw. ich habe es wahrscheinlich total mißverstanden (mir war z.B. nicht ganz klar, welches Verhalten zu welchem Zeitpunkt Du eigentlich erwartest)... Sollte ich Dich verletzt haben, so bitte ich um Entschuldigung

Der Prozess wird nicht gestartet, heißt, das er bei Anfragen aus dem Netz nicht gestartet wird.
Wie hat sich das Ganze dabei am Client geäußert? Gab's eine Fehlermeldung, wenn ja welche? Stieg Client mit timeout aus? Denn bei mir (mittlerweile) gab's am Client die folgende Fehlermeldung
Code:
svn: Can't find a temporary directory: Internal error
der Prozess auf der Box wurde aber definitiv gestartet - die Fehlermeldung kommt auch von ihm.

Das Ändern auf root, bring den Erfolg. Was spricht dagegen?
Naja, die üblichen Gründe so wenig wie möglich Dienste mit root-Rechten laufen zu lassen (auch wenn Du der einzige User bist und den Port gar nicht nach Außen frei gibst). Außerdem wäre es ein Workaround, besser wäre es das Problem zu verstehen und die eigentliche Ursache zu beheben, was, wie ich meine, mir gelungen ist.

Das Problem besteht darin, dass svnserve (nur im inetd-Modus) es versucht, ein Temp-Verzeichnis anzulegen, was schlicht und ergreifend scheitert, die Fehlermeldung sagt ja auch genau das. Dafür bedient es sich einer Funktion aus der apr-Library, welche wiederum dafür die Verzeichnisse /tmp, /var/tmp, /usr/tmp und noch ein paar andere durchprobiert. Scheitern tut's deswegen, weil der svn-User für keines dieser Verzeichnisse die Schreibrechte hat. Temporäre Lösung
Code:
chmod 1777 /var/tmp
dauerhafte bei mir getestete Anhang anzeigen fwmod_var_tmp_fixes.patch.txt
@Oliver, Silent-Tears und andere Developer, die vielleicht hier mitlesen: spricht etwas gegen die Aufnahme des Patches in trunk?

Das Verhalten bei manuellen eintragen in die /etc/inetd.conf über das WebIF besteht wie beschrieben. Dort startet der Prozess auch ohne Anfragen aus dem Netz. Ist allerdings nicht so von Bedeutung.
Konnte ich bei mir leider nicht reproduzieren. Das --daemon in der Ausgabe von ps (Punkt 2 aus Deinem Posting) deutet daraufhin, dass der Prozess über rc.subversion gestartet wurde und nicht von inetd (in diesem Fall müsste -i in der Ausgabe auftauchen) - vielleicht hast Du nur vergessen, nach dem Umstellen auf manuell, den Dienst zu beenden oder dieser aus irgendwelchen anderen Gründen nicht beendet werden konnte, das wäre dann aber ein komplett anderes Problem.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.