Hallo,
ich habe auf meinem QNAP NAS eine svn/trac installation laufen. Anbindung an Apache über mod-wsgi. Nach dem letzten Firmware-Update stellte sich heraus, dass zwei Pakete an unterschiedliche Python-Versionen gebunden sind:
mod-wsgi_3.3-1 benötigt python25
svn-py_1.6-17 benötigt python26
Trac kann ich entweder für python25 oder python26 installieren. Mit python25 klappt dann aber der Zugriff auf svn nicht mehr, da svn-py ja für python26 geschrieben wurde. Installiere ich trac für python26, dann kann mein wsgi-script nicht geladen werden, da mod-wsgi den python25 interpreter aufruft, trac aber in meiner python26 Installation liegt.
Ich finde keine anderen Pakete für ein Down- oder Upgrade. Ich kann auch leider nicht cross-kompilieren, um mir eines der Pakete selbst zu bauen.
Gibt es eine Möglichkeit aus Apache heraus mod-wsgi mit python26 starten zu lassen anstatt mit python25? Setzen von WSGIPythonHome und WSGIPythonPath in der apache.conf brachten keine Abhilfe.
mod-wsgi mit Python2.6 aus Apache starten
Leider nein. Da solltest du dich mit den maintainern auseinandersetzen. mod_wsgi ist gelinkt gegen eine spezifisch version - das kann man nicht so einfach aendern.
Die Alternative waere, trac als eigenen Daemon zu starten mit py26, und dann mittels mod_rewrite/mod_proxy darauf zuzugreifen.
Die Alternative waere, trac als eigenen Daemon zu starten mit py26, und dann mittels mod_rewrite/mod_proxy darauf zuzugreifen.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Du könntest http://wiki.python.de/SSH%20installation propieren und beide Versionen gleichzeitig installieren.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ich rede auch nicht von cross-compilieren (Auf einen PC für die NAS Platform compilieren) sondern von installieren auf dem NAS selbst.
Dazu müßen natürlich ein paar Tools zur Verfügung stehen.
btw. das QNAP NAS läßt sich doch bestimmt auch schön hacken, siehe: http://qnap.nas-central.org/
Was läuft darauf überhaupt für ein System? Das original?
Dazu müßen natürlich ein paar Tools zur Verfügung stehen.
btw. das QNAP NAS läßt sich doch bestimmt auch schön hacken, siehe: http://qnap.nas-central.org/
Was läuft darauf überhaupt für ein System? Das original?
Yep, das Original. Ist ein NSLU2-Linux, wenn ich es richtig verstanden habe. Von dort bezieht das Tool "ipkg" zumindest seine Pakete.jens hat geschrieben:Was läuft darauf überhaupt für ein System? Das original?
Das probiere ich gerade. Es gibt dieses Forum hier: http://www.nslu2-info.dedeets hat geschrieben:Leider nein. Da solltest du dich mit den maintainern auseinandersetzen.
Aber ich kann mich da nicht anmelden, da ich nie die Registrierungsemail bekomme! Habe auch schon das Kontaktformular dort verwendet, um darauf hinzuweisen. Aber wahrscheinlich geht deren Mailer Daemon nicht und sie merken nicht, dass man sie nicht kontaktieren kann bzw. dass sich neue Mitglieder nicht registrieren können...
OK. Anscheinend muss ich größeren Aufwand betreiben und doch cross kompilieren. Damit kenne ich mich aber nur bedingt aus. Habe schon versucht auf meinem Mac eine cross-compile Umgebung einzurichten, scheitere aber kläglich, weil ich es nicht verstehe. Nativ für den Mac kann ich mod-wsgi problemlos kompilieren.
Ich dachte evtl. daran mir eine bereits gut konfigurierte Linux-Distri als VMWare-Image zu besorgen. Kennt jemand so eine Distri mit der man für arm-linux cross-kompilieren kann?
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Was auch geht, aber ein wenig mehr Aufwand, dafür mehr Freiheiten: Eine chroot Umgebung bauen.
Hab ich auf dem Medion NAS http://www.mikrocontroller.net/articles/P89626 gemacht. Einmal mit Debian und einmal mit ArchLinuxARM, siehe:
http://www.mikrocontroller.net/articles ... ebootstrap
http://www.mikrocontroller.net/articles ... chLinuxARM
Hab ich auf dem Medion NAS http://www.mikrocontroller.net/articles/P89626 gemacht. Einmal mit Debian und einmal mit ArchLinuxARM, siehe:
http://www.mikrocontroller.net/articles ... ebootstrap
http://www.mikrocontroller.net/articles ... chLinuxARM
Ich habe versucht ein Debian-Paket zu installieren, das brachte aber auch nichts. Wenn ich es richtig gesehen habe, enthält das Debian Paket nur eine lib, nicht aber die Python-Skripte.
Evtl. kann ich das ja selbst patchen. Dazu muss ich aber den Fehler verstehen. Hier die Ausgabe meines trac-logs, wenn ich versuche mittels trac-admin auf meine svn repositories zuzugreifen ("trac-admin <meinProj> repository sync <meinRepos>")
Ich verstehe es so, dass der Python2.5 Interpreter sich durch die trac-Scripte hangelt, die dann am Ende die Funktion svn_fs_revision_prop aufrufen. Dort kommt es zu dem TypeError. Nach meinem Verständnis liegt das daran, dass die svn-python-Scripte für Python2.6 geschrieben wurden und es hier zu einer Inkompatibilität kommt.
Ich kenne Python aber nicht und kann nicht verstehen, was genau schief läuft und wie ich das patchen könnte.
Evtl. kann ich das ja selbst patchen. Dazu muss ich aber den Fehler verstehen. Hier die Ausgabe meines trac-logs, wenn ich versuche mittels trac-admin auf meine svn repositories zuzugreifen ("trac-admin <meinProj> repository sync <meinRepos>")
Code: Alles auswählen
2012-01-06 12:51:30,795 Trac[console] ERROR: Exception in trac-admin command:
Traceback (most recent call last):
File "/opt/lib/python2.5/site-packages/trac/admin/console.py", line 107, in onecmd
rv = cmd.Cmd.onecmd(self, line) or 0
File "/opt/lib/python2.5/cmd.py", line 218, in onecmd
return self.default(line)
File "/opt/lib/python2.5/site-packages/trac/admin/console.py", line 266, in default
return cmd_mgr.execute_command(*args)
File "/opt/lib/python2.5/site-packages/trac/admin/api.py", line 123, in execute_command
return f(*fargs)
File "/opt/lib/python2.5/site-packages/trac/versioncontrol/admin.py", line 156, in _do_sync
self._sync(reponame, rev, clean=False)
File "/opt/lib/python2.5/site-packages/trac/versioncontrol/admin.py", line 139, in _sync
repos.sync(self._sync_feedback, clean=clean)
File "/opt/lib/python2.5/site-packages/trac/versioncontrol/cache.py", line 240, in sync
@self.env.with_transaction()
File "/opt/lib/python2.5/site-packages/trac/db/api.py", line 77, in transaction_wrapper
fn(ldb)
File "/opt/lib/python2.5/site-packages/trac/versioncontrol/cache.py", line 247, in do_transaction
cset = self.repos.get_changeset(next_youngest)
File "/opt/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 442, in get_changeset
return SubversionChangeset(self, rev, self.scope, self.pool)
File "/opt/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 856, in __init__
message = self._get_prop(core.SVN_PROP_REVISION_LOG)
File "/opt/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 968, in _get_prop
return fs.revision_prop(self.fs_ptr, self.rev, name, self.pool())
File "/opt/lib/svn-python/libsvn/fs.py", line 729, in svn_fs_revision_prop
return apply(_fs.svn_fs_revision_prop, args)
TypeError: argument number 2:
Ich verstehe es so, dass der Python2.5 Interpreter sich durch die trac-Scripte hangelt, die dann am Ende die Funktion svn_fs_revision_prop aufrufen. Dort kommt es zu dem TypeError. Nach meinem Verständnis liegt das daran, dass die svn-python-Scripte für Python2.6 geschrieben wurden und es hier zu einer Inkompatibilität kommt.
Ich kenne Python aber nicht und kann nicht verstehen, was genau schief läuft und wie ich das patchen könnte.