Hilfe beim RPM bauen
Hallo,
ich hab' meine neue Version von PythonMagick (http://www.procoders.net/pythonmagick) so gut wie fertig. Da die Bibliothek aber von boost.python und GraphicsMagick abhängt, ist sie nicht ganz einfach zu übersetzen. Unter Windows ist das kein Problem, da gibt's Installer. Aber was mache ich unter Linux? Würde jemand mit mir RPMs bauen? Ich entwickle auf Gentoo was keine RPMs kennt, aber ich teste auch auf Linux, d.h. da sollte es keine Probleme geben.
Gruß, Achim
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Achim Domma (ProCoders) wrote:
Hallo,
ich hab' meine neue Version von PythonMagick (http://www.procoders.net/pythonmagick) so gut wie fertig. Da die Bibliothek aber von boost.python und GraphicsMagick abhängt, ist sie nicht ganz einfach zu übersetzen. Unter Windows ist das kein Problem, da gibt's Installer. Aber was mache ich unter Linux? Würde jemand mit mir RPMs bauen?
Ich kenn mich da halbwegs aus - hab früher viel RPMs gebaut, Python, PostgreSQL & omniORB für SuSE 7.x gepackt, usw :-) Bei mir zu Hause hab ich aber vor kurzem das letzte RPM-basierte System abgeschafft, jetzt gibt's nur noch Debian (& FreeBSD). Man kann jedoch auch unter Debian die RPM-tools installieren und RPMs bauen. Das Testen wird halt schwieriger, weil die ganzen Abhängigkeiten fehlen.
Ich entwickle auf Gentoo was keine RPMs kennt, aber ich teste auch auf Linux, d.h. da sollte es keine Probleme geben.
Man sollte auch auf Gentoo RPM installieren können. Dann schaun wir mal weiter :-)
-- Gerhard
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Ich kenn mich da halbwegs aus - hab früher viel RPMs gebaut, Python, PostgreSQL & omniORB für SuSE 7.x gepackt, usw :-)
Das hört sich gut an! :-) Das System von Gentoo gefällt mir sehr gut, aber wie jemand sagen kann, daß RPMs besser funktionieren als Windows Installer ist mir bis heute unklar.
Bei mir zu Hause hab ich aber vor kurzem das letzte RPM-basierte System abgeschafft, jetzt gibt's nur noch Debian (& FreeBSD).
Ich hab' auch nichts gegen Packete für Debian! ;-)
Man kann jedoch auch unter Debian die RPM-tools installieren und RPMs bauen. Das Testen wird halt schwieriger, weil die ganzen Abhängigkeiten fehlen.
[...]
Man sollte auch auf Gentoo RPM installieren können. Dann schaun wir mal weiter :-)
Ja, aber die ganzen Distributionen haben das Zeugs doch in verschiedenen Verzeichnissen und verschiedene libcs, oder? Ich glaub' ich hab' RPM einfach nicht verstanden!? Wenn ich auf meinem Gentoo mit gcc3.2 und meiner libc compilieren, dann nützt das einem Suse 7.x User doch wenig, oder?
Gruß, Achim
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Achim Domma (ProCoders) wrote:
Ich kenn mich da halbwegs aus - hab früher viel RPMs gebaut, Python, PostgreSQL & omniORB für SuSE 7.x gepackt, usw :-)
Das hört sich gut an! :-) Das System von Gentoo gefällt mir sehr gut, aber wie jemand sagen kann, daß RPMs besser funktionieren als Windows Installer ist mir bis heute unklar.
Bei mir zu Hause hab ich aber vor kurzem das letzte RPM-basierte System abgeschafft, jetzt gibt's nur noch Debian (& FreeBSD).
Ich hab' auch nichts gegen Packete für Debian! ;-)
Sollte nicht schwierig sein, da Boost & Konsorten für Debian schon gepackt sind. Wenn du faul bist, kannst du bei Debian auch einen RfP (Request for Packaging) bug report einschicken ;-) Wenn das Paket interessant ist, wird es irgendwann auch mal jemand für Debian verpacken :-)
Man sollte auch auf Gentoo RPM installieren können. Dann schaun wir mal weiter :-)
Ja, aber die ganzen Distributionen haben das Zeugs doch in verschiedenen Verzeichnissen und verschiedene libcs, oder?
Ja. Und oft gibt es wahrscheinlich für Boost::Python keine Pakete.
Ich glaub' ich hab' RPM einfach nicht verstanden!? Wenn ich auf meinem Gentoo mit gcc3.2 und meiner libc compilieren, dann nützt das einem Suse 7.x User doch wenig, oder?
Korrekt. Er kann jedoch evtl. sich das Source-RPM schnappen und ein "rpm --rebuild", "rpm -b /path/to/mypkg.spec" oder was in der Art anstoßen, um sich RPMs für *seine* Distribution zu backen.
Die Binaries werden in jedem Fall nur auf wenigen Systemen laufen. Insebesondere wg. der unterschiedlichen C++-ABIs.
-- Gerhard
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Ojeeee, rpms hab ich einmal versucht zu bauen und hab aus Ungeduld aufgegeben. Ich glaube es gibt inzwischen eine Möglichkeit mit den Python distutils rpms zu bauen....
Gruß, Uwe.
:: -----Ursprüngliche Nachricht----- :: Von: python-de-admin@python.net [mailto:python-de-admin@python.net]Im :: Auftrag von Achim Domma (ProCoders) :: Gesendet: Mittwoch, 21. Mai 2003 17:42 :: An: python-de@python.net :: Betreff: [privat] [Python-de] Hilfe beim RPM bauen :: :: :: Hallo, :: :: ich hab' meine neue Version von PythonMagick :: (http://www.procoders.net/pythonmagick) so gut wie fertig. Da :: die Bibliothek :: aber von boost.python und GraphicsMagick abhängt, ist sie nicht :: ganz einfach :: zu übersetzen. Unter Windows ist das kein Problem, da gibt's :: Installer. Aber :: was mache ich unter Linux? Würde jemand mit mir RPMs bauen? Ich entwickle :: auf Gentoo was keine RPMs kennt, aber ich teste auch auf Linux, d.h. da :: sollte es keine Probleme geben. :: :: Gruß, :: Achim :: :: :: _______________________________________________ :: Python-de maillist - Python-de@python.net :: http://python.net/mailman/listinfo/python-de ::
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo!
Das Verhalten von Python-2.2.1 (Version 2.2.3c1 ebenso) ist bei der Behandlung von Samba Laufwerken problematisch. Getestet mit Windows NT SP6 und oben genannten Python Versionen:
Samba bindet Unix Laufwerke in Windows ein. Die Unix Filenamen sind case sensitiv, unter Windows sind Filenamen nicht case sensitiv AFAIK.
Ein Directory, sagen wir "m:\TestDir" - also 'TestDir' in der Unix Welt muß exakt als "m:\TestDir" und nicht etwa als "m:\testdir" angegeben werden. Dummerweise erzeugt os.listdir("m:\testdir") aber die Liste der Filenamen in "m:\TestDir". Was soll's, aber leider funktioniert dies bei verschachtelten Pfaden nicht: os.listdir("m:\testdir\big") statt os.listdir("m:\TestDir\BIG") erzeugt eine leere Liste statt der Fileliste in "m:\TestDir\BIG"
Richtig wäre doch ein Exception (WindowsError, Errno 3) wie unter Windows Laufwerken.. Übrigens wird diese Exception auch bei völlig falschen Directorynamen nicht geworfen; stattdessen wird eine leere Liste erzeugt. os.path.isdir() und os.path.isfile() erzeugen korrekterweise 0.
Ist das ein bekannter Bug - bei sourceforge habe ich dergleichen nicht gefunden, allerding auch nicht exsessiv gesucht,
C. Kleffner
Carl Kleffner wrote:
Das Verhalten von Python-2.2.1 (Version 2.2.3c1 ebenso) ist bei der Behandlung von Samba Laufwerken problematisch. Getestet mit Windows NT SP6 und oben genannten Python Versionen:
Samba bindet Unix Laufwerke in Windows ein. Die Unix Filenamen sind case sensitiv, unter Windows sind Filenamen nicht case sensitiv AFAIK.
Du kannst in samba.conf einstellen, daß Verzeichnisse case insensitiv sein sollen. Dann probiert samba den richtigen Pfad zu finden.
Grüße Daniel
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Carl Kleffner wrote:
Das Verhalten von Python-2.2.1 (Version 2.2.3c1 ebenso) ist bei der Behandlung von Samba Laufwerken problematisch. Getestet mit Windows NT SP6 und oben genannten Python Versionen:
Samba bindet Unix Laufwerke in Windows ein. Die Unix Filenamen sind case sensitiv, unter Windows sind Filenamen nicht case sensitiv AFAIK.
Du kannst in samba.conf einstellen, daß Verzeichnisse case insensitiv sein sollen. Dann probiert samba den richtigen Pfad zu finden.
Grüße Daniel
Aber wie kommt es zu dem unvorhersagbaren Verhalten, das os.listdir("nicht_existierender_pfad_auf_samba_laufwerk") keine Exception wirft, sondern schlicht eine leere List zurückgibt? Das ist übrigens ganz unabhängig vom case.
Grüße
Carl
Carl Kleffner wrote:
Ein Directory, sagen wir "m:\TestDir" - also 'TestDir' in der Unix Welt muß exakt als "m:\TestDir" und nicht etwa als "m:\testdir" angegeben werden.
Warum? Samba kann problemlos case insensitive arbeiten, auch wenn das Dateisystem case sensitive ist.
Dummerweise erzeugt os.listdir("m:\testdir") aber die Liste der Filenamen in "m:\TestDir".
Genau. Weil Samba nämlich case insensitive ist. Python denkt sich das nicht aus.
Was soll's, aber leider funktioniert dies bei verschachtelten Pfaden nicht: os.listdir("m:\testdir\big") statt os.listdir("m:\TestDir\BIG") erzeugt eine leere Liste statt der Fileliste in "m:\TestDir\BIG"
Das ist vielleicht ein Bug in Samba.
Ist das ein bekannter Bug - bei sourceforge habe ich dergleichen nicht gefunden, allerding auch nicht exsessiv gesucht,
Wenn, dann ein Bug in Samba. Python reicht wirklich die Fehlermeldungen vom Windows direkt, unverändert und sofort weiter.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Carl Kleffner wrote:
Ein Directory, sagen wir "m:\TestDir" - also 'TestDir' in der Unix
Welt
muß exakt als "m:\TestDir" und nicht etwa als "m:\testdir" angegeben werden.
Warum? Samba kann problemlos case insensitive arbeiten, auch wenn das Dateisystem case sensitive ist.
Dummerweise erzeugt os.listdir("m:\testdir") aber die Liste der Filenamen in "m:\TestDir".
Genau. Weil Samba nämlich case insensitive ist. Python denkt sich das nicht aus.
Was soll's, aber leider funktioniert dies bei verschachtelten Pfaden nicht: os.listdir("m:\testdir\big") statt os.listdir("m:\TestDir\BIG") erzeugt eine leere Liste statt der Fileliste in "m:\TestDir\BIG"
Das ist vielleicht ein Bug in Samba.
Ist das ein bekannter Bug - bei sourceforge habe ich dergleichen nicht gefunden, allerding auch nicht exsessiv gesucht,
Wenn, dann ein Bug in Samba. Python reicht wirklich die Fehlermeldungen vom Windows direkt, unverändert und sofort weiter.
Ciao, Martin
Mag sein, daß es ein bug in samba oder ein Konfigurationsproblem ist. Es war auf jeden Fall verwirrend genug um mich eine Weile mit einem Fehler zu beschäftigen, dessen Grund nicht offensichtlich ist. Vielleicht sollte os.listdir(pfad) nicht nur Windows Fehlermeldungen weiterreichen, sondern vorher prüfen ob pfad auf ein gültiges Verzeichnis zeigt -- was man natürlich auch selber prüfen kann. Aber wer weiss schon, dass dies bei samba Laufwerken nötog ist?
Gruß
Carl
Carl Kleffner cmkleffner@gmx.de writes:
Mag sein, daß es ein bug in samba oder ein Konfigurationsproblem ist. Es war auf jeden Fall verwirrend genug um mich eine Weile mit einem Fehler zu beschäftigen, dessen Grund nicht offensichtlich ist. Vielleicht sollte os.listdir(pfad) nicht nur Windows Fehlermeldungen weiterreichen, sondern vorher prüfen ob pfad auf ein gültiges Verzeichnis zeigt -- was man natürlich auch selber prüfen kann.
Wie prüfst Du denn, ob das Verzeichnis da ist? Wenn os.listdir keinen Fehler produziert, obwohl das Verzeichnis nicht existiert, halte ich es für möglich, dass auch os.stat keinen Fehler liefert - dass es also schlichtweg keine Möglichkeit gibt, herauszufinden, dass es dieses Verzeichnis *nicht* gibt.
Was passiert denn, wenn Du in dir.exe auf die entsprechenden Pfade aufrufst?
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Carl Kleffner cmkleffner@gmx.de writes:
Mag sein, daß es ein bug in samba oder ein Konfigurationsproblem ist. Es war auf jeden Fall verwirrend genug um mich eine Weile mit einem Fehler zu beschäftigen, dessen Grund nicht offensichtlich ist. Vielleicht sollte os.listdir(pfad) nicht nur Windows Fehlermeldungen weiterreichen, sondern vorher prüfen ob pfad auf ein gültiges Verzeichnis zeigt -- was man natürlich auch selber prüfen kann.
Wie prüfst Du denn, ob das Verzeichnis da ist? Wenn os.listdir keinen Fehler produziert, obwohl das Verzeichnis nicht existiert, halte ich es für möglich, dass auch os.stat keinen Fehler liefert - dass es also schlichtweg keine Möglichkeit gibt, herauszufinden, dass es dieses Verzeichnis *nicht* gibt.
Was passiert denn, wenn Du in dir.exe auf die entsprechenden Pfade aufrufst?
Kann ich erst ab Mittwoch wieder testen ... so long.
Ich hatte aber den Effekt, das os.listdir(pfad) keine Exception wirft und gleichzeitig os.path.isdir(pfad) false zurückgibt. pfad war in diesem Fall ein beliebiger syntaktisch gültiger aber nicht existierender Pfad auf dem samba Laufwerk. Mit kurzen Worten: es ist mir nicht gelungen mit einem falschen Pfadnamen eine Exception zu produzieren. Was in diesem Fall dir.exe sagt, werde ich wie gesagt ab Mittwoch testen.
Ciao
Carl
Carl Kleffner wrote:
Ich hatte aber den Effekt, das os.listdir(pfad) keine Exception wirft und gleichzeitig os.path.isdir(pfad) false zurückgibt.
Auf os.path.isdir() (resp. generell auf os.stat()) wuerde ich mich in diesem Kontext auch nicht zu sehr verlassen. Ich habe das seither nicht mehr getestet, aber um aehnliche Probleme unter Windows zu umgehen habe ich vor einiger Zeit mal für Python 1.5.2 folgenden Ersatz gebastelt:
def isdir(s): '''For os.path.isdir(), thanks to the broken posix stat(2) on Windows.''' if os.name == 'nt': if s[:2] == '\\': # UNC directories are only recognized *with* the trailing "" if s[-1] != '\': s = s + '\' elif len(s) > 3 and s[1] == ':': # drive based paths are only recognized *without* the trailing "" while s[-1] == '\' and s[-2] != ':': s = s[:-1] elif len(s) == 2 and s[1] == ':': # except for the root path. s = s + '\' return os.path.isdir(s)
Ich weiss aber jetzt nicht mehr auswendig, welche der Probleme mit, und welche ohne Samba auftraten. Es kann auch sein, dass bei neueren Windows/Samba Versionen die Details anders sind. Vielleicht kann mal jemand mit Zugriff auf diverse Varianten systematischere Tests anstellen?
Natürlich wäre es schön, wenn Python bei solchem relativ offensichtlichen Fehlverhalten des unterliegenden Systems das im jeweiligen Standardmodul abfangen würde. Oder hat sich da seither etwas getan?
-schorsch
Wie prüfst Du denn, ob das Verzeichnis da ist? Wenn os.listdir keinen Fehler produziert, obwohl das Verzeichnis nicht existiert, halte ich es für möglich, dass auch os.stat keinen Fehler liefert - dass es also schlichtweg keine Möglichkeit gibt, herauszufinden, dass es dieses Verzeichnis *nicht* gibt.
Was passiert denn, wenn Du in dir.exe auf die entsprechenden Pfade aufrufst?
Ciao, Martin
Hier die Antwort:
existierender Pfad: m:\RL Test mit falscher Schreibweise (lowercase) auf Samba Laufwerk:
1) unter der Console: dir m:\rl Datenträger in Laufwerk M: ist test1 Datenträgernummer: 71E6-07A6
Verzeichnis von m:\
Datei nicht gefunden
2) Python-2.2.1: os.stat
os.stat("m:\rl")
Traceback (most recent call last): File "<stdin>", line 1, in ? OSError: [Errno 2] No such file or directory: 'm:\rl'
3) Python-2.2.1: os.path.isdir
os.path.isdir("m:\rl")
0
4) Python-2.2.1: os.listdir
os.listdir("m:\rl")
[]
Wie man sieht wirft os.stat eine Exception, os.path.isdir liefert den korrekten Wert, aber os.listdir erzeugt eine leere Liste. Übrigens liefer os.listdir bei jedem nicht existierenden Samba Pfad eine leere Liste!!!
Es sollte aber folgende exception erzeut werden: Bsp:
os.listdir("c:\rl") # <-- Windows Laufwerk C
Traceback (most recent call last): File "<stdin>", line 1, in ? WindowsError: [Errno 3] Das System kann den angegebenen Pfad nicht finden: 'c:\rl/*.*'
Das Fehlverhalten von os.listdir() bei Samba Laufwerken ist meiner Meinung nach ein Python Bug.
Carl
PS: Man beachte, das os.stat und os.listdir unterschiedliche Exceptions produzieren (ERRNO 2 und ERRNO 3).
Carl Kleffner cmkleffner@gmx.de writes:
Man beachte, das os.stat und os.listdir unterschiedliche Exceptions produzieren (ERRNO 2 und ERRNO 3).
Das würde ich jetzt nicht interpretieren. Vielmehr scheint es unterschiedliche Fehler zu geben, je nachdem, ob das Verzeichnis lokal oder auf Samba ist. Was liefert denn os.stat("c:\rl")?
Wenn das so ist, ist es ein Fehler im Samba: Samba sollte den gleichen Fehlercode liefern wie Windows im lokalen Fall.
Jedenfalls erklärt dieser Fehlercode das Pythonverhalten. Der Python-Code lautet
hFindFile = FindFirstFile(namebuf, &FileData); if (hFindFile == INVALID_HANDLE_VALUE) { errno = GetLastError(); if (errno == ERROR_FILE_NOT_FOUND) return d; Py_DECREF(d); return win32_error("FindFirstFile", namebuf); }
und die Checkin-Message dazu lautet
revision 2.89 date: 1998/08/06 03:23:32; author: guido; state: Exp; lines: +2 -0 In Win32 version of listdir(), when FindFirstFile() returns ERROR_FILE_NOT_FOUND, return an empty list instead of raising an exception.
Der Grund dieser Änderung (in Python 1.5.2) liegt offenbar in
http://www.codeguru.com/files/CAdvFind.html
Wenn FindFirstFile ERROR_FILE_NOT_FOUND zurückgibt, dann bedeutet das *nicht*, dass es den Pfad nicht gibt, sondern, dass das Verzeichnis leer ist (also das erste File nicht gefunden wurde).
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Das würde ich jetzt nicht interpretieren. Vielmehr scheint es unterschiedliche Fehler zu geben, je nachdem, ob das Verzeichnis lokal oder auf Samba ist. Was liefert denn os.stat("c:\rl")?
In der Tat das gleiche wie os.stat("m:\rl")
Wenn das so ist, ist es ein Fehler im Samba: Samba sollte den gleichen Fehlercode liefern wie Windows im lokalen Fall.
Jedenfalls erklärt dieser Fehlercode das Pythonverhalten. Der Python-Code lautet
hFindFile = FindFirstFile(namebuf, &FileData); if (hFindFile == INVALID_HANDLE_VALUE) { errno = GetLastError(); if (errno == ERROR_FILE_NOT_FOUND) return d; Py_DECREF(d); return win32_error("FindFirstFile", namebuf); }
und die Checkin-Message dazu lautet
revision 2.89 date: 1998/08/06 03:23:32; author: guido; state: Exp; lines: +2 -0 In Win32 version of listdir(), when FindFirstFile() returns ERROR_FILE_NOT_FOUND, return an empty list instead of raising an exception.
Der Grund dieser Änderung (in Python 1.5.2) liegt offenbar in
http://www.codeguru.com/files/CAdvFind.html
Wenn FindFirstFile ERROR_FILE_NOT_FOUND zurückgibt, dann bedeutet das *nicht*, dass es den Pfad nicht gibt, sondern, dass das Verzeichnis leer ist (also das erste File nicht gefunden wurde).
Ciao, Martin
Genau dieser fehlerhafte Rückgabewert scheint in der Tat ein Bug in samba zu sein - siehe Anhänge unten. Es ist wohl nicht anzunehmen, das es ein sinnvolles Vorgehen ist im Python Quellcode einen workaround um diesen samba bug einzupflegen.
In der Python Dokumentation wäre ein Hinweis auf diesen Bug sicher nicht verkehrt. Die Existenz eines Samba Verzeichnisses sollte also mit os.stat oder os.path.isdir überprüft werden.
Carl
Anhang --------------------------------------------------------------------------------- http://samba.cadcamlab.org/lists/samba-technical/Sep2000/00104.html
FW: [PATCH] mkdir.cc - mkdir_p() (was: Samba install problems)
* To: "SAMBA tecnical list" samba-technical@samba.org * Subject: FW: [PATCH] mkdir.cc - mkdir_p() (was: Samba install problems) * From: "Andrej Borsenkow" Andrej.Borsenkow@mow.siemens.ru * Date: Thu, 14 Sep 2000 11:03:45 +0400 * Delivered-To: samba-technical@us4.samba.org * Delivered-To: samba-technical@samba.org * Importance: Normal * List-Id: Discussions on Samba internals. For general questions please subscribe to the list samba@samba.org <samba-technical.lists.samba.org>
Browsing samba-technical, I remeber the problem with creating directory with missing directories in path. I.e. mkdir -p //samba/foo/bar/com fails if ``bar'' does not exists. I hit it when installing off SAMBA share (2.0.7)
Here it seems that one nice person analysed the problem. May be, it helps. The mentioned patch is for Cygwin setup.exe problem, not for SAMBA.
regards
-andrej
-----Original Message----- From: cygwin-owner@sources.redhat.com [mailto:cygwin-owner@sources.redhat.com]On Behalf Of Harold Hunt Sent: Tuesday, September 12, 2000 7:24 AM To: 'cygwin@sources.redhat.com' Subject: [PATCH] mkdir.cc - mkdir_p() (was: Samba install problems)
Samba 2.0.6+ seems to return ERROR_FILE_NOT_FOUND when a directory in the path handed to CreateDirectory() is not found; earlier versions of Samba seem to follow the Windows convention of returning ERROR_PATH_NOT_FOUND for missing directories.
I sent the patch directly to DJ, and I believe he has reviewed it; this post is merely an announcement to those that may have been following the
Samba
installation problems thread.
Harold
siehe auch http://sources.redhat.com/ml/cygwin/2000-09/msg00372.html
sowie http://www.winehq.com/hypermail/wine-devel/2002/05/0561.html Failures on NT4 in dlls/kernel/tests/path.c From: Francois Gouget (fgouget_at_free.fr) Date: Mon May 20 2002 - 20:06:48 CDT
Carl Kleffner wrote:
Es ist wohl nicht anzunehmen, das es ein sinnvolles Vorgehen ist im Python Quellcode einen workaround um diesen samba bug einzupflegen.
Nein, glaube ich auch nicht.
In der Python Dokumentation wäre ein Hinweis auf diesen Bug sicher nicht verkehrt. Die Existenz eines Samba Verzeichnisses sollte also mit os.stat oder os.path.isdir überprüft werden.
Ein patch zu Doc/lib ist jederzeit willkommmen.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (8)
-
"Martin v. Löwis" -
Achim Domma (ProCoders) -
Carl Kleffner -
daniel.poelzleithner -
Georg Mischler -
Gerhard Häring -
martin＠v.loewis.de
-
Uwe Schmitt