Updates für das Fonz fun_plug 0.5 vom 11. May 2011

fun_plugIch habe heute eine kleine Session mit meinem ffp build-environment und dem dns-320 build-environment eingelegt und einige Updates für das funplug 0.5 fertig gemacht:

  • apr-util-1.3.10: Aktualisiert
  • curl-7.21.6: Aktualisiert
  • eventlog-0.2.12: Hinzugefügt
  • libassuan-2.0.1: Hinzugefügt
  • libksba-1.2.0: Hinzugefügt
  • librsync-0.9.7: Hinzugefügt
  • mysql-5.1.56: Aktualisiert
  • ncftp-3.2.4: Hinzugefügt
  • nettle-2.1: Hinzugefügt
  • openvpn-2.1.4: Aktualisiert
  • proftpd-1.3.3e: Aktualisiert
  • pth-2.0.7: Hinzugefügt
  • subversion-1.6.16: Aktualisiert
  • unrar-4.0.7: Aktualisiert
  • xz-5.0.2: Aktualisiert

OpenVPN beinhaltet nun zusätzlich das Kernelmodul für das DNS-320 bzw. DNS-325 (Kernel 2.6.22.18). Das herunterladen der Updates geht wie immer:

mkdir -p /ffp/pkg/
cd /ffp/pkg/
wget http://wolf-u.li/u/173/ -O /ffp/pkg/updater.sh
chmod a+x /ffp/pkg/updater.sh
sh /ffp/pkg/updater.sh

Beispiel für ein AuthzSVNAccessFile von Subversion

Soeben habe ich bei einem Kollegen dessen Subversion-Repositories konfiguriert. Da er mehrere Repositories über eine Domain mit verschiedenen Zugriffsrechten im Web nutzen möchte, haben wir uns für das dav_svn-Modul von Apache entschieden. Zur Absicherung sollte ein AuthzSVNAccessFile genutzt werden. Da ich ihm ein Beispiel für dieses AuthzSVNAccessFile geschrieben habe, möchte dieses hier kurz präsentieren.
Beispiel für ein AuthzSVNAccessFile von Subversion weiterlesen

svnversion: Version mismatch in ’svn_wc‘: found 1.5.5, expected 1.6.0

Ich wollte heute für das fun_plug das Tool „subversion“ updaten. Leider trat während des Kompilierens beim make install der Fehler:

svnversion: Version mismatch in 'svn_wc': found 1.5.5, expected 1.6.0

auf, welcher sich auf den Vorgang make revision-install eingrenzen lies, welcher laut Subversion-maillingliste von keinem Tool genutzt wird.

Hierfür gibt es zwei Lösungsansätze:

  • Bestehende Subversion-Installation entfernen (inklusive libsvn)
  • Statt make install einfach make external-install local-install ausführen

Ich bin letzteren gegangen, hat hervorragend funktioniert.

Export in den Webroot des Apache Webservers per Post-Commit von Subversion

Seit ein paar Tagen setze ich mich wieder intensiv mit dem Zend Framework auseinander und bastle an einer Applikation. Um meine Änderungen einfach nachzuverfolgen habe ich mir ein Subversion-Repository auf meinem Server eingerichtet. Um in verschiedenen Testumgebungen die Applikation testen zu können, soll diese automatisch in einen Webroot „deployed“ werden. Hierzu habe ich ein kleines Skript geschrieben, welches sind an den post-commit-Mechanismus von Subversion hängt und darüber den Export steuert.
Export in den Webroot des Apache Webservers per Post-Commit von Subversion weiterlesen

Portable SVN-Client für den USB-Stick

Seit einigen Wochen bearbeite ich ein Dokument, was ich am liebsten in einem Subversion-Repository versioniert ablegen würde. Leider habe ich aber keine Administratorrechte auf dem Erstellungs-PC, sodass mir keine Installation eines Subversion-Clients wie TortoiseSVN möglich war.
Heute hat es mir nun endlich gereicht und ich habe mich auf die Suche gemacht. Ich setze auf meinem USB-Stick schon länger die Suite von portableapps.com ein, die sich bei mir bereits bewährt hat. In deren Forum wurde ich dann auch fündig, was den Client betraf: Thread 6767
Portable SVN-Client für den USB-Stick weiterlesen

Fehler: „svn: Unrecognized URL scheme for ‚http://some.subdomain.wolf-u.li'“ mit Subversion

Soeben wollte ich in der Kommandozeile ein SVN auf meinem Server auschecken und erhielt folgenden Fehler (URL wurde von mir maskiert):

svn: Unrecognized URL scheme for 'http://some.subdomain.wolf-u.li'

Dieser Fehler ist auf subversion selbst zurückzuführen, nicht auf eine Notation. Subversion wurde hierbei ohne „Neon“ kompiliert, was daher keinen Zugriff auf ein WebDAV (http://) erlaubt.
Unter Gentoo ist die Lösung folgende:

echo "dev-util/subversion webdav-neon" >> /etc/portage/package.use
echo "net-misc/neon ~x86" >> /etc/portage/package.keywords
emerge -av subversion

(Neon ist leider noch nicht stable, bei mir läufts trotzdem 😉 )

„(20014)Internal error: Version mismatch in ’svn_delta‘: found 1.5.0-rc4, expected 1.5.0-rc5“ lösen

Nach einem Update von Subversion unter Gentoo von 1.5.0-rc4 auf 1.5.0-rc5 erhielt ich von Apache beim Abrufen des SVN über HTTP einen Fehler und fand in den Logs die folgenden Einträge

[error] (20014)Internal error: Version mismatch in 'svn_delta': found 1.5.0-rc4, expected 1.5.0-rc5
[error] Could not fetch resource information.  [500, #0]
[error] Could not open the requested SVN filesystem  [500, #200019]

Die Lösung war sehr einfach: Einmal Apache durchstarten.