From seefeld at sympatico.ca Sun Jan 4 14:55:34 2004 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sun Jan 4 13:58:47 2004 Subject: [Distutils] build_clib Message-ID: <3FF86FB6.2010909@sympatico.ca> hi there, I posted about this issue already in the past, but didn't get any answer. In the hope that someone may know the answer I'm trying again...: I notice some code in the distutils package for a 'build_clib' command, for which the documentation reads: """distutils.command.build_clib Implements the Distutils 'build_clib' command, to build a C/C++ library that is included in the module distribution and needed by an extension module.""" I'm at a point in one of my own projects where such a command would be very useful. Is this command finished ? How should I use it ? I can neither find any documentation for it, nor any way to set it up properly (the 'distribution.libraries' variable for example is not set anywhere). I'm about to implement something similar on my own, but if it already existed I wouldn't need to reinvent the wheel... Thanks a lot, Stefan From theller at python.net Mon Jan 5 04:42:50 2004 From: theller at python.net (Thomas Heller) Date: Mon Jan 5 04:42:52 2004 Subject: [Distutils] build_clib In-Reply-To: <3FF86FB6.2010909@sympatico.ca> (Stefan Seefeld's message of "Sun, 04 Jan 2004 14:55:34 -0500") References: <3FF86FB6.2010909@sympatico.ca> Message-ID: Stefan Seefeld writes: > hi there, > > I posted about this issue already in the past, but didn't > get any answer. In the hope that someone may know the answer > I'm trying again...: > > I notice some code in the distutils package for a > 'build_clib' command, for which the documentation reads: > > """distutils.command.build_clib > > Implements the Distutils 'build_clib' command, to build a C/C++ library > that is included in the module distribution and needed by an extension > module.""" > > I'm at a point in one of my own projects where such a command > would be very useful. Is this command finished ? How should I use it ? > I can neither find any documentation for it, nor any way to set it > up properly (the 'distribution.libraries' variable for example is not > set anywhere). > I'm about to implement something similar on my own, but if it already > existed I wouldn't need to reinvent the wheel... > > Thanks a lot, > Stefan I don't really remember (except that it may have been used by Numeric?) - unless someone else does, your only chance is to wade through the distutils-sig archives. Thomas From DavidA at ActiveState.com Tue Jan 6 23:50:51 2004 From: DavidA at ActiveState.com (David Ascher) Date: Tue Jan 6 23:52:30 2004 Subject: [Distutils] Full Distutils-SIG archive In-Reply-To: References: Message-ID: <3FFB902B.3060308@ActiveState.com> Bill Spotz wrote: > Does an archive exist for the entire Distutils-SIG history, or are the > individual month archives the only option? This may not be what you wanted, but: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/distutils-sig cheers, --david ascher From tjenkins at devis.com Thu Jan 8 13:13:13 2004 From: tjenkins at devis.com (Tom Jenkins) Date: Thu Jan 8 13:13:26 2004 Subject: [Distutils] installing docs Message-ID: <3FFD9DB9.2090706@devis.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I'm attempting to create a win32 binary installation for Medusa. the resulting structure i want is: ... ~ /site-packages ~ /medusa ~ /demo ~ /docs i can get the demo directory by including it as a package, but i can't seem to get docs put where i want. i've tried data_files but that puts ~ /docs up under the Python2.x directory. here is the slightly modified version included with Medusa: from distutils.core import setup setup( ~ name = 'medusa', ~ version = "0.5.4", ~ description = "A framework for implementing asynchronous servers.", ~ author = "Sam Rushing", ~ author_email = "rushing@nightmare.com", ~ maintainer = "A.M. Kuchling", ~ maintainer_email = "amk@amk.ca", ~ url = "http://oedipus.sourceforge.net/medusa/", ~ packages = ['medusa', 'medusa.demo', ], ~ package_dir = {'medusa':'.'}, ~ ) i've read the distutils docs and googled till i'm goggly-eyed. can someone point me in the right direction, please? thanks - -- Tom Jenkins devIS - Development Infostructure http://www.devis.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0-nr2 (Windows XP) Comment: Using GnuPG with MultiZilla - http://enigmail.mozdev.org iD8DBQE//Z25V7Yk9/McDYURAmLQAJ0VBoe5RVRkKblPKym/1cZJIKEw3wCfRBdS grD0AfiBterQtn+d2hZtgYM= =8VuT -----END PGP SIGNATURE----- From wfspotz at sandia.gov Fri Jan 9 17:53:05 2004 From: wfspotz at sandia.gov (Bill Spotz) Date: Fri Jan 9 17:53:32 2004 Subject: [Distutils] Linking C++ under Linux Message-ID: <95DA5026-42F6-11D8-8CF6-0003930F2154@sandia.gov> I am developing a set of extension modules for python written in C++ and have successfully written a setup.py that works on my mac. Portability is important, though, and under Linux, the linking command I get from distutils appears to be not what I want. Specifically, on the mac, the compile command from distutils is gcc with the appropriate command line options and the link command is c++. On the Linux machine, gcc is both the compile and linking command, and when the module is loaded, I get ImportError: ../build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so: undefined symbol: endl__FR7ostream which sure looks like a missing c++ library to me. In my searching through distutils documentation, all I can find is a warning to "Be sure to use appropriate extensions to distinguish C++ source files: .cc and .cpp seem to be recognized by both Unix and Windows compilers." But changing my suffix from .cxx to .cpp didn't help. (I was using .cxx because that is the default suffix produced by SWIG -- but I'm currently calling swig via a Makefile because distutils doesn't appear to be robust enough yet to handle everything I need it to do.) System info: sahp4960(41)$ uname -a Linux sahp4960 2.4.18-17.7.xsmp #1 SMP Tue Oct 8 12:37:04 EDT 2002 i686 unknown Python info: sahp4960(42)$ python Python 2.2.1 (#1, May 14 2002, 16:46:34) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 [It just occurred to me that this could be a python version issue, as my working mac version is under python 2.3. I'll be looking into this, but would still appreciate a response.] Thanks ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wfspotz@sandia.gov ** From mats at laplaza.org Sat Jan 10 01:42:41 2004 From: mats at laplaza.org (Mats Wichmann) Date: Sat Jan 10 01:43:21 2004 Subject: [Distutils] Linking C++ under Linux In-Reply-To: <95DA5026-42F6-11D8-8CF6-0003930F2154@sandia.gov> Message-ID: <5.1.0.14.1.20040109230520.00aa6be8@mail.laplaza.org> >ImportError: ../build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so: >undefined symbol: endl__FR7ostream > >which sure looks like a missing c++ library to me. Well, a linking problem anyway. according to c++filt: endl(long double, ostream) I'm not that much of a c++ expert, but this looks like a non-standard overload of endl, is that maybe provided by some of /your/ code and not getting linked in? From wfspotz at sandia.gov Mon Jan 12 11:55:43 2004 From: wfspotz at sandia.gov (Bill Spotz) Date: Mon Jan 12 11:56:02 2004 Subject: [Distutils] Linking C++ under Linux In-Reply-To: <5.1.0.14.1.20040109230520.00aa6be8@mail.laplaza.org> Message-ID: <289E42E8-4520-11D8-8CF6-0003930F2154@sandia.gov> On Friday, January 9, 2004, at 11:42 PM, Mats Wichmann wrote: > >ImportError: ../build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so: > >undefined symbol: endl__FR7ostream > > > >which sure looks like a missing c++ library to me. > > Well, a linking problem anyway. > > according to c++filt: endl(long double, ostream) > > I'm not that much of a c++ expert, but this looks > like a non-standard overload of endl, is that > maybe provided by some of /your/ code and not > getting linked in? Hmmm. On the system where I'm getting the problem, I get sahp4960(1)$ c++filt endl__FR7ostream endl(ostream &) which looks like the standard definition of endl. Interestingly, on my mac, I get samt5735a(29)$ c++filt endl__FR7ostream long double which looks like some type of misinterpretation (the "l" at the end of "endl" wrongly interpreted as a long modifier? I don't know). But if I use c++filt's "standard input mode", I get samt5735a(33)$ c++filt endl__FR7ostream # Standard input endl(ostream &) # Standard output Ctrl-D Anyway, I'm pretty sure endl__FR7ostream gets demangled as endl(ostream &), and while I am not a primary developer of the software I am trying to wrap, I'd be very surprised if this gets overloaded somewhere (at least, a cursory search using grep didn't turn anything up). Here is the link line generated by distutils on the Linux platform: gcc -shared build/temp.linux-i686-2.2/Epetra_wrap.o -LCommon -L/usr/netpub/Trilinos-10_31_03/lib -L/usr/netpub/swig-1.3.19/lib -L/usr/local/python-2.2.1/lib/python2.2/config -lcommon -lswigpy -lepetra -lblas -llapack -lg2c -lpython2.2 -o build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so What surprises me is that the command is gcc rather than c++ (as it is on the mac) and that, given this fact, there are no c++ libraries included in the command line. ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wfspotz@sandia.gov ** From wfspotz at sandia.gov Mon Jan 12 12:49:54 2004 From: wfspotz at sandia.gov (Bill Spotz) Date: Mon Jan 12 12:50:04 2004 Subject: [Distutils] Linking C++ under Linux In-Reply-To: <289E42E8-4520-11D8-8CF6-0003930F2154@sandia.gov> Message-ID: On Monday, January 12, 2004, at 09:55 AM, Bill Spotz wrote: > Here is the link line generated by distutils on the Linux platform: > > gcc -shared build/temp.linux-i686-2.2/Epetra_wrap.o -LCommon > -L/usr/netpub/Trilinos-10_31_03/lib -L/usr/netpub/swig-1.3.19/lib > -L/usr/local/python-2.2.1/lib/python2.2/config -lcommon -lswigpy > -lepetra -lblas -llapack -lg2c -lpython2.2 -o > build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so > > What surprises me is that the command is gcc rather than c++ (as it is > on the mac) and that, given this fact, there are no c++ libraries > included in the command line. OK, on the PythonMac-SIG list, Jack Jansen wrote > Distutils doesn't properly support C++ until Python 2.3; for earlier > versions you have to do various bizarre things to force it to link on > various platforms. Which would seem to be the answer to my problem. And in fact, upgrading to python 2.3 and recompiling, the link command from distutils changes from gcc to c++, which is what I was hoping for. Now it is not finding SWIG_TypeClientData, so I may be switching over to a SWIG mailing list. ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wfspotz@sandia.gov ** From mats at laplaza.org Mon Jan 12 14:32:26 2004 From: mats at laplaza.org (Mats Wichmann) Date: Mon Jan 12 14:32:56 2004 Subject: [Distutils] Linking C++ under Linux In-Reply-To: <289E42E8-4520-11D8-8CF6-0003930F2154@sandia.gov> References: <5.1.0.14.1.20040109230520.00aa6be8@mail.laplaza.org> Message-ID: <5.1.0.14.1.20040112122932.025d1e90@mail.laplaza.org> C++ standard? Hah. I guess I've got an odd one here... >Here is the link line generated by distutils on the Linux platform: > >gcc -shared build/temp.linux-i686-2.2/Epetra_wrap.o -LCommon >-L/usr/netpub/Trilinos-10_31_03/lib -L/usr/netpub/swig-1.3.19/lib >-L/usr/local/python-2.2.1/lib/python2.2/config -lcommon -lswigpy >-lepetra -lblas -llapack -lg2c -lpython2.2 -o >build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so > >What surprises me is that the command is gcc rather than c++ (as it is >on the mac) and that, given this fact, there are no c++ libraries >included in the command line. Some people try to link without the full C++ library. I've seen programs that use gcc and link with libsupc++, which is supposed to work, but I don't /think/ gcc will put that library in for you by magic. All of which doesn't seem to be helping your problem. Is there any way to force it to try g++ instead of gcc? From mdboom at jhu.edu Wed Jan 14 11:15:57 2004 From: mdboom at jhu.edu (Michael Droettboom) Date: Wed Jan 14 11:16:01 2004 Subject: [Distutils] Compiling extensions with MingW32 / python.org binary Message-ID: <40056B3D.1000902@jhu.edu> I've come across a possible bug with --compiler=mingw32 and --compiler=cygwin support when using the standard python.org 2.3.3 .exe. (I do this so I can distribute binary installers that work with the standard Python distribution, but don't want to buy MS Visual Studio...) It seems that the linker command being used is cc.exe, which on Cygwin 1.5.5-1 is actually a symlink to gcc.exe. This works fine if your Python interpreter was compiled with Cygwin, because it handles the symlink correctly. However, when using the python.org interpreter, you get a: command 'cc' failed: Invalid argument error. Making cc.exe a real copy of gcc.exe fixes the problem. Looking in cygwinccompiler.py, it seems that the linker is getting set to 'gcc', so it must be getting changed to 'cc' at somewhere else in the heirarchy... Any ideas? I'd be happy to submit a patch if this is in fact a new bug. Note also, that things worked correctly in Python 2.2.3. It is only when I moved to Python 2.3 that this error occurred. Michael Droettboom From Paul.Moore at atosorigin.com Wed Jan 14 11:34:33 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Wed Jan 14 11:34:38 2004 Subject: [Distutils] Compiling extensions with MingW32 / python.org binary Message-ID: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> From: Michael Droettboom > I've come across a possible bug with --compiler=mingw32 and > --compiler=cygwin support when using the standard python.org 2.3.3 > .exe. (I do this so I can distribute binary installers that work with > the standard Python distribution, but don't want to buy MS Visual Studio...) I don't have a C extension handy to try at the moment, but I haven't had a problem in the past using mingw (--compiler=mingw32) and python.org python 2.3.3. Can you clarify what you are having problems with? Using python.org python with cygwin gcc (--compiler=cygwin)? If so, I have no experience with that, so I can't help (beyond saying that mingw works fine, so don't break that in the process of fixing the cygwin case!) Paul. From mdboom at jhu.edu Wed Jan 14 11:37:58 2004 From: mdboom at jhu.edu (Michael Droettboom) Date: Wed Jan 14 11:38:06 2004 Subject: [Distutils] Compiling extensions with MingW32 / python.org binary In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> Message-ID: <40057066.2020602@jhu.edu> Moore, Paul wrote: >From: Michael Droettboom > > >>I've come across a possible bug with --compiler=mingw32 and >>--compiler=cygwin support when using the standard python.org 2.3.3 >>.exe. (I do this so I can distribute binary installers that work with >>the standard Python distribution, but don't want to buy MS Visual Studio...) >> >> > >I don't have a C extension handy to try at the moment, but I haven't >had a problem in the past using mingw (--compiler=mingw32) and >python.org python 2.3.3. > >Can you clarify what you are having problems with? Using python.org >python with cygwin gcc (--compiler=cygwin)? If so, I have no experience >with that, so I can't help (beyond saying that mingw works fine, so >don't break that in the process of fixing the cygwin case!) > > I'm having problems with both --compiler=cygwin and --compiler=mingw32. From Paul.Moore at atosorigin.com Wed Jan 14 11:40:29 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Wed Jan 14 11:45:32 2004 Subject: [Distutils] Compiling extensions with MingW32 / python.org binary Message-ID: <16E1010E4581B049ABC51D4975CEDB8802C09B8F@UKDCX001.uk.int.atosorigin.com> From: Michael Droettboom [mailto:mdboom@jhu.edu] > I'm having problems with both --compiler=cygwin and --compiler=mingw32. What version of mingw do you have installed, and are you sure it's getting used in preference to the cygwin one (ie, is it in your PATH before the cygwin directory)? I'll check when I get home. (Where I have something I can compile :-)) Paul From mal at egenix.com Wed Jan 14 11:40:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 14 11:46:14 2004 Subject: [Distutils] Compiling extensions with MingW32 / python.org binary In-Reply-To: <40057066.2020602@jhu.edu> References: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> <40057066.2020602@jhu.edu> Message-ID: <40057100.4010603@egenix.com> Michael Droettboom wrote: > Moore, Paul wrote: > >> From: Michael Droettboom >> >> >>> I've come across a possible bug with --compiler=mingw32 and >>> --compiler=cygwin support when using the standard python.org 2.3.3 >>> .exe. (I do this so I can distribute binary installers that work >>> with the standard Python distribution, but don't want to buy MS >>> Visual Studio...) >>> >> >> >> I don't have a C extension handy to try at the moment, but I haven't >> had a problem in the past using mingw (--compiler=mingw32) and >> python.org python 2.3.3. >> >> Can you clarify what you are having problems with? Using python.org >> python with cygwin gcc (--compiler=cygwin)? If so, I have no experience >> with that, so I can't help (beyond saying that mingw works fine, so >> don't break that in the process of fixing the cygwin case!) >> >> > I'm having problems with both --compiler=cygwin and --compiler=mingw32. Please check your environment: could be that distutils picks up an environment setting that changes gcc to cc. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mdboom at jhu.edu Wed Jan 14 13:24:06 2004 From: mdboom at jhu.edu (Michael Droettboom) Date: Wed Jan 14 13:24:14 2004 Subject: [Distutils] Compiling extensions with MingW32 / python.org binary In-Reply-To: <40057100.4010603@egenix.com> References: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> <40057066.2020602@jhu.edu> <40057100.4010603@egenix.com> Message-ID: <40058946.2000206@jhu.edu> M.-A. Lemburg wrote: > Michael Droettboom wrote: > >> Moore, Paul wrote: >> >>> From: Michael Droettboom >>> >>> >>>> I've come across a possible bug with --compiler=mingw32 and >>>> --compiler=cygwin support when using the standard python.org 2.3.3 >>>> .exe. (I do this so I can distribute binary installers that work >>>> with the standard Python distribution, but don't want to buy MS >>>> Visual Studio...) >>>> >>> >>> >>> >>> I don't have a C extension handy to try at the moment, but I haven't >>> had a problem in the past using mingw (--compiler=mingw32) and >>> python.org python 2.3.3. >>> >>> Can you clarify what you are having problems with? Using python.org >>> python with cygwin gcc (--compiler=cygwin)? If so, I have no experience >>> with that, so I can't help (beyond saying that mingw works fine, so >>> don't break that in the process of fixing the cygwin case!) >>> >>> >> I'm having problems with both --compiler=cygwin and --compiler=mingw32. > > > Please check your environment: could be that distutils picks > up an environment setting that changes gcc to cc. > Here's my os.environ (no mention of cc anywhere...): {'TMP': 'c:\\DOCUME~1\\MICHAE~1\\LOCALS~1\\Temp', 'TEXMF': '{/usr/share/lilypond /2.0.1,/usr/share/texmf}', 'COMPUTERNAME': 'MASTA-BOOM', 'USERDOMAIN': 'MASTA-BOOM', 'COMMONPROGRAMFILES': 'C:\\Program Files\\Common Files', 'PROCESSOR_IDENTIFIER': 'x86 Family 15 Model 2 Stepping 4, GenuineIntel', 'CVS_RSH': 'ssh', 'USER': 'Michael Droettboom', 'PROCESSOR_REVISION': '0204', 'PATH': 'C:\\cygwin\\usr\\local\\bin;C:\\cygwin\\bin;C:\\cygwin\\bin;c:\\PROGRA~1\\PYTHON23;C:\\cygwin\\us r\\X11R6\\bin', 'SYSTEMROOT': 'C:\\WINDOWS', 'PS1': '\\[\\033]0;\\w\\007\n\\033[32m\\]\\u@\\h \\[\\033[33m\\w\\033[0m\\]\n$ ', 'KDEHOME': '"C:\\Documents and Settings\\Michael Droettboom\\Application Data"', 'KDEDIR': 'C:\\cygwin\\opt\\kde3', 'TERM': 'cygwin', 'TEMP': 'c:\\DOCUME~1\\MICHAE~1\\LOCALS~1\\Temp', 'SHLVL': '1', 'PROCESSOR_ARCHITECTURE': 'x86', 'ALLUSERSPROFILE': 'C:\\Documents and Settings\\All Users', 'CLIENTNAME': 'Console', 'MANPATH': ':/usr/X11R6/man:/usr/ssl/man', 'HOMEPATH': '\\Documents and Settings\\Michael Droettboom', 'HOME': 'c:\\DOCUME~1\\MICHAE~1\\MYDOCU~1', 'USERNAME': 'Michael Droettboom', 'LOGONSERVER': '\\\\MASTA-BOOM', 'PROMPT': '$P$G', 'COMSPEC': 'C:\\WINDOWS\\system32\\cmd.exe', 'MAKE_MODE': 'unix', 'SESSIONNAME': 'Console', 'PATHEXT': '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH', '_': '/cygdrive/c/PROGRA~1/PYTHON23/python', 'WINDIR': 'C:\\WINDOWS', 'CYGWIN_ROOT': 'C:\\cygwin', 'APPDATA': 'C:\\Documents and Settings\\Michael Droettboom\\Application Data', 'HOMEDRIVE': 'C:', 'OLDPWD': '/cygdrive/c/DOCUME~1/MICHAE~1/MYDOCU~1/gamera', 'NUMBER_OF_PROCESSORS': '4', 'PWD': '/cygdrive/c/Program Files/python23/Lib/distutils', 'LTDL_LIBRARY_PATH': 'C:\\cygwin\\opt\\kde3\\lib;C:\\cygwin\\opt\\kde3\\lib\\kde3', 'PROCESSOR_LEVEL': '15', 'USERPROFILE': 'C:\\Documents and Settings\\Michael Droettboom', 'OS': 'Windows_NT', 'SYSTEMDRIVE': 'C:', 'PROGRAMFILES': 'C:\\Program Files'} From mdboom at jhu.edu Wed Jan 14 15:38:34 2004 From: mdboom at jhu.edu (Michael Droettboom) Date: Wed Jan 14 15:38:44 2004 Subject: [Distutils] Compiling extensions with MingW32 / python.org binary In-Reply-To: <40058946.2000206@jhu.edu> References: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> <40057066.2020602@jhu.edu> <40057100.4010603@egenix.com> <40058946.2000206@jhu.edu> Message-ID: <4005A8CA.1000409@jhu.edu> Michael Droettboom wrote: > M.-A. Lemburg wrote: > >> Michael Droettboom wrote: >> >>> Moore, Paul wrote: >>> >>>> From: Michael Droettboom >>>> >>>> >>>>> I've come across a possible bug with --compiler=mingw32 and >>>>> --compiler=cygwin support when using the standard python.org 2.3.3 >>>>> .exe. (I do this so I can distribute binary installers that work >>>>> with the standard Python distribution, but don't want to buy MS >>>>> Visual Studio...) >>>>> >>>> >>>> >>>> >>>> >>>> I don't have a C extension handy to try at the moment, but I haven't >>>> had a problem in the past using mingw (--compiler=mingw32) and >>>> python.org python 2.3.3. >>>> >>>> Can you clarify what you are having problems with? Using python.org >>>> python with cygwin gcc (--compiler=cygwin)? If so, I have no >>>> experience >>>> with that, so I can't help (beyond saying that mingw works fine, so >>>> don't break that in the process of fixing the cygwin case!) >>>> >>>> >>> I'm having problems with both --compiler=cygwin and --compiler=mingw32. >> Okay, the detail that I realise is important is that this is a C++ extension. From unixccompiler.py (line 169 in Python 2.3.3): try: if target_desc == CCompiler.EXECUTABLE: linker = self.linker_exe[:] else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: #*** linker[0] = self.compiler_cxx[0] #*** self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg Since target_lang == "c++", and self.compiler_cxx is defined in unixccompiler.py as "cc", but not overridden in cygwinccompiler.py (as compiler, compiler_so, linker_exe and linker_so are...) we end up with the command line having cc instead of gcc at the front. In the Python CVS history, it seems that the lines marked *** were added since the release22-maint branch, which explains why this used to work for me with Python 2.2. Under a Cygwin or Mingw32 build where Python was built with Cygwin, the symlink from cc to gcc works. However, "standard" Windows executables, such as the python.org interpreter can not follow Cygwin symlinks and it chokes. I seems that compiler_cxx should be defined as "gcc -mcygwin" and "gcc -mnocygwin" in cygwinccompiler.py. I have a patch -- not sure what the procedure is to submit it, however. Hope I'm on the right track... Mike From pf_moore at yahoo.co.uk Wed Jan 14 15:45:29 2004 From: pf_moore at yahoo.co.uk (Paul Moore) Date: Wed Jan 14 15:45:38 2004 Subject: [Distutils] Re: Compiling extensions with MingW32 / python.org binary References: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> <40057066.2020602@jhu.edu> <40057100.4010603@egenix.com> <40058946.2000206@jhu.edu> Message-ID: Michael Droettboom writes: >> Please check your environment: could be that distutils picks >> up an environment setting that changes gcc to cc. >> > Here's my os.environ (no mention of cc anywhere...): [...] Your PATH has cygwin in, but not mingw. Therefore, I wouldn't expect --compiler=mingw32 to work. I can't help with --compiler=cygwin, sorry. Paul. -- This signature intentionally left blank From pf_moore at yahoo.co.uk Wed Jan 14 16:05:41 2004 From: pf_moore at yahoo.co.uk (Paul Moore) Date: Wed Jan 14 16:08:21 2004 Subject: [Distutils] Re: Compiling extensions with MingW32 / python.org binary References: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> <40057066.2020602@jhu.edu> <40057100.4010603@egenix.com> <40058946.2000206@jhu.edu> <4005A8CA.1000409@jhu.edu> Message-ID: <65fe5jh6.fsf@yahoo.co.uk> Michael Droettboom writes: > Okay, the detail that I realise is important is that this is a C++ > extension. Yes, that's pretty important :-) I don't use C++, so I didn't see this. > I seems that compiler_cxx should be defined as "gcc -mcygwin" and "gcc > -mnocygwin" in cygwinccompiler.py. I have a patch -- not sure what > the procedure is to submit it, however. The following works for me, for a trivial test: --- cygwinccompiler.py.orig 2003-04-14 13:51:26.000000000 +0100 +++ cygwinccompiler.py 2004-01-14 21:00:33.000000000 +0000 @@ -108,6 +108,7 @@ # XXX optimization, warnings etc. should be customizable. self.set_executables(compiler='gcc -mcygwin -O -Wall', compiler_so='gcc -mcygwin -mdll -O -Wall', + compiler_cxx='g++ -mcygwin -O -Wall', linker_exe='gcc -mcygwin', linker_so=('%s -mcygwin %s' % (self.linker_dll, shared_option))) @@ -295,6 +296,7 @@ self.set_executables(compiler='gcc -mno-cygwin -O -Wall', compiler_so='gcc -mno-cygwin -mdll -O -Wall', + compiler_cxx='g++ -mno-cygwin -O -Wall', linker_exe='gcc -mno-cygwin', linker_so='%s -mno-cygwin %s %s' % (self.linker_dll, shared_option, How does it compare with your patch? You should submit your patch to sourceforge. On www.python.org, there's a "bugs" link in the left hand sidebar, under the "Documentation" section. Thanks for persisting with this! Paul. -- This signature intentionally left blank From mdboom at jhu.edu Wed Jan 14 16:42:04 2004 From: mdboom at jhu.edu (Michael Droettboom) Date: Wed Jan 14 16:42:23 2004 Subject: [Distutils] Re: Compiling extensions with MingW32 / python.org binary In-Reply-To: <65fe5jh6.fsf@yahoo.co.uk> References: <16E1010E4581B049ABC51D4975CEDB8802C09B8E@UKDCX001.uk.int.atosorigin.com> <40057066.2020602@jhu.edu> <40057100.4010603@egenix.com> <40058946.2000206@jhu.edu> <4005A8CA.1000409@jhu.edu> <65fe5jh6.fsf@yahoo.co.uk> Message-ID: <4005B7AC.2010204@jhu.edu> Paul Moore wrote: >Michael Droettboom writes: > > > >>Okay, the detail that I realise is important is that this is a C++ >>extension. >> >> > >Yes, that's pretty important :-) I don't use C++, so I didn't see >this. > > > >>I seems that compiler_cxx should be defined as "gcc -mcygwin" and "gcc >>-mnocygwin" in cygwinccompiler.py. I have a patch -- not sure what >>the procedure is to submit it, however. >> >> > >The following works for me, for a trivial test: > >--- cygwinccompiler.py.orig 2003-04-14 13:51:26.000000000 +0100 >+++ cygwinccompiler.py 2004-01-14 21:00:33.000000000 +0000 >@@ -108,6 +108,7 @@ > # XXX optimization, warnings etc. should be customizable. > self.set_executables(compiler='gcc -mcygwin -O -Wall', > compiler_so='gcc -mcygwin -mdll -O -Wall', >+ compiler_cxx='g++ -mcygwin -O -Wall', > linker_exe='gcc -mcygwin', > linker_so=('%s -mcygwin %s' % > (self.linker_dll, shared_option))) >@@ -295,6 +296,7 @@ > > self.set_executables(compiler='gcc -mno-cygwin -O -Wall', > compiler_so='gcc -mno-cygwin -mdll -O -Wall', >+ compiler_cxx='g++ -mno-cygwin -O -Wall', > linker_exe='gcc -mno-cygwin', > linker_so='%s -mno-cygwin %s %s' > % (self.linker_dll, shared_option, > >How does it compare with your patch? > > That's exactly what I did (with the exception of the -O -Wall , which isn't in the version I have here.) >You should submit your patch to sourceforge. On www.python.org, >there's a "bugs" link in the left hand sidebar, under the >"Documentation" section. > >Thanks for persisting with this! > > No problem. >Paul. > > From paul at prescod.net Sun Jan 18 18:10:31 2004 From: paul at prescod.net (Paul Prescod) Date: Sun Jan 18 18:12:07 2004 Subject: [Distutils] Manifests Message-ID: <400B1267.4030007@prescod.net> I love distutils. It is a key piece of Python infrastructure. But I'm not happy with one of its design decisions. Consider the case of Joe Blow. He creates the simplest possible distribution structure: from distutils.core import setup setup( name = "pyximport", version = "1.0", url = "http://www.example.com", author = "Joe Blow", author_email = "joe@example.com", py_modules = ["doit"]) The distutils docs[1] say: "If you don't supply an explicit list of files (or instructions on how to generate one), the sdist command puts a minimal default set into the source distribution." The default set described is just what Joe needs. He is happy. He tries to create the distribution: bash-2.05a$ python setup.py sdist running site customization running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) warning: sdist: standard file not found: should have one of README, README.txt writing manifest file 'MANIFEST' ... Oops. Forgot the README. So Joe adds the README. He also remembers that there is a nother module: "dothat". So he updates py_modules in setup.py. He regenerates and gets no errors. He uploads to his website. The problem is: his users WILL NOT get README or dothat.py. Distutils will not update the MANIFEST file. Joe probably didn't even notice that a MANIFEST exists and certainly won't care about it until it bites him in the ass. Even if he read the documentation closely, he would get a wrong impression: "if either MANIFEST.in or the setup script ( setup.py ) are more recent than MANIFEST , recreate MANIFEST by reading MANIFEST.in" That's not quite true because of the special case described in Distutil's source code: # The contents of the manifest file almost certainly depend on the # setup script as well as the manifest template -- so if the setup # script is newer than the manifest, we'll regenerate the manifest # from the template. (Well, not quite: if we already have a # manifest, but there's no template -- which will happen if the # developer elects to generate a manifest some other way -- then we # can't regenerate the manifest, so we don't.) I propose that if distutils is going to generate a MANIFEST then it should generate it to its temporary cruft directory, not to the source directory. If there is some reason that a user would want to hand-edit the output of this process and use it from then on as INPUT then they can copy it OUT of their distribution to the top-level directory where distutils will treat it from then on as INPUT. Their explicit copying action will indicate that they want to take control of its maintenance henceforth. I really don't know why anyone would want to hand-maintain (or use a program to generate) a MANIFEST file when they could just as easily hand-maintain or code-generate the much more flexible manifest template file. === (mostly unrelated thought:) I am not clear why distutils separates the concept of manifest template from setup.py. Couldn't you express your complete set of dependencies using globs etc. in the Python code? The whole manifest template seems like just one more file syntax to learn and one more file to maintain. Paul Prescod From jeremy at alum.mit.edu Mon Jan 19 09:52:35 2004 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Mon Jan 19 09:58:05 2004 Subject: [Distutils] Manifests In-Reply-To: <400B1267.4030007@prescod.net> References: <400B1267.4030007@prescod.net> Message-ID: <1074523954.14813.75.camel@localhost.localdomain> On Sun, 2004-01-18 at 18:10, Paul Prescod wrote: > I propose that if distutils is going to generate a MANIFEST then it > should generate it to its temporary cruft directory, not to the source > directory. If there is some reason that a user would want to hand-edit > the output of this process and use it from then on as INPUT then they > can copy it OUT of their distribution to the top-level directory where > distutils will treat it from then on as INPUT. Their explicit copying > action will indicate that they want to take control of its maintenance > henceforth. Good idea. > I really don't know why anyone would want to hand-maintain (or use a > program to generate) a MANIFEST file when they could just as easily > hand-maintain or code-generate the much more flexible manifest template > file. Me neither. At least in the absence of a better tool than MANIFEST.in. > (mostly unrelated thought:) I am not clear why distutils separates the > concept of manifest template from setup.py. Couldn't you express your > complete set of dependencies using globs etc. in the Python code? The > whole manifest template seems like just one more file syntax to learn > and one more file to maintain. I think the MANIFEST.in language is a little odd and poorly documented, but I don't know that it would be any better if I had to write Python code to achieve the same effect. Here's a MANIFEST.in for a project I work on: include MANIFEST* include *.txt include test.py recursive-include persistent *.h *.c recursive-include ZODB .c *.xml recursive-include BTrees *.h .c *.txt recursive-include BDBStorage *.c recursive-include ZEO *.xml *.txt recursive-include zLOG *.xml recursive-include zdaemon *.xml *.conf *.sh recursive-include ZConfig *.xml *.conf include ZConfig/scripts/zconfig graft Doc graft Tools graft ZConfig/doc global-exclude .cvsignore I guess that could be improved: m = Manifest() m.include("MANIFEST*") for dir in "ZODB", "BTrees", "BDBStorage", "ZEO", ..., "ZConfig": m.recursive_include(dir, ".c", ".xml", ".txt") for dir in "Doc", "Tools", "ZConfig/doc": m.graft(dir) Jeremy From fdrake at acm.org Mon Jan 19 10:21:41 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Jan 19 10:21:53 2004 Subject: [Distutils] Manifests In-Reply-To: <1074523954.14813.75.camel@localhost.localdomain> References: <400B1267.4030007@prescod.net> <1074523954.14813.75.camel@localhost.localdomain> Message-ID: <16395.62981.479570.206768@sftp.fdrake.net> Jeremy Hylton writes: > I think the MANIFEST.in language is a little odd and poorly documented, > but I don't know that it would be any better if I had to write Python > code to achieve the same effect. Here's a MANIFEST.in for a project I I think a lot of milage could be had if there were a way to specify additional file extensions that should be copied as part of packages along with .py files. The would certainly be a reasonable 80% solution for the packages for which I work on the setup.py files. The next most important improvement would be a way to say the Python packages are "over there" in cases where they aren't in the top-level directory where the setup.py resides. I'm thinking of cases where the Python packages are located in a src/ or lib/python/ directory. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From jeremy at alum.mit.edu Mon Jan 19 10:40:06 2004 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Mon Jan 19 10:45:37 2004 Subject: [Distutils] Manifests In-Reply-To: <16395.62981.479570.206768@sftp.fdrake.net> References: <400B1267.4030007@prescod.net> <1074523954.14813.75.camel@localhost.localdomain> <16395.62981.479570.206768@sftp.fdrake.net> Message-ID: <1074526806.14813.110.camel@localhost.localdomain> On Mon, 2004-01-19 at 10:21, Fred L. Drake, Jr. wrote: > Jeremy Hylton writes: > > I think the MANIFEST.in language is a little odd and poorly documented, > > but I don't know that it would be any better if I had to write Python > > code to achieve the same effect. Here's a MANIFEST.in for a project I > I think a lot of milage could be had if there were a way to specify > additional file extensions that should be copied as part of packages > along with .py files. The would certainly be a reasonable 80% > solution for the packages for which I work on the setup.py files. Good point! If we could have that option work for a bunch of commands, it would help. We also suffer to get data files copied into site-packages along with their modules. If you could just say .xml files in my modules should get installed just like .py files, life would be much simpler. > The next most important improvement would be a way to say the Python > packages are "over there" in cases where they aren't in the top-level > directory where the setup.py resides. I'm thinking of cases where the > Python packages are located in a src/ or lib/python/ directory. We've already got that, unless i misunderstand you: package_dir. The package_dir dictionary tells distutils where to find various packages. The keys are package names, the values are directories. The empty string is provides a default package directory. See the Zope3 setup.py for an example. Jeremy From fdrake at acm.org Mon Jan 19 11:51:15 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Jan 19 11:51:24 2004 Subject: [Distutils] Manifests In-Reply-To: <1074526806.14813.110.camel@localhost.localdomain> References: <400B1267.4030007@prescod.net> <1074523954.14813.75.camel@localhost.localdomain> <16395.62981.479570.206768@sftp.fdrake.net> <1074526806.14813.110.camel@localhost.localdomain> Message-ID: <16396.2819.444907.230639@sftp.fdrake.net> Jeremy Hylton writes: > We've already got that, unless i misunderstand you: package_dir. The > package_dir dictionary tells distutils where to find various packages. > The keys are package names, the values are directories. The empty > string is provides a default package directory. See the Zope3 setup.py > for an example. Sheesh, and that's actually documented! Thanks! That makes some things much easier to work with. (I hearby withdraw my objection to your ZODB3 layout changes as well. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From z971bulro at fusemail.com Tue Jan 20 16:39:56 2004 From: z971bulro at fusemail.com (Abe Sims) Date: Tue Jan 20 03:42:45 2004 Subject: [Distutils] Backup your DVd's and VHS tapes with your CDR beecham Message-ID: <43$f951pl$-8f9-$1nju$316cd4@bkkklctli2oymj> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040120/02a6dea6/attachment.html From brandishing at terra.es Tue Jan 20 23:48:07 2004 From: brandishing at terra.es (Brandishing) Date: Tue Jan 20 23:48:11 2004 Subject: [Distutils] Fwd[6]: Via-Grra. Allmoosstt ffrree. 0nIy T0d@y (distutils-sig@python.org). In-Reply-To: <169IG6B3K87IF1BC@python.org> References: <169IG6B3K87IF1BC@python.org> Message-ID: <5IJD9IIIK88148H3@terra.es> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040121/9113554d/attachment.html From R.Liebscher at gmx.de Wed Jan 21 09:43:22 2004 From: R.Liebscher at gmx.de (=?iso-8859-1?Q?Ren=E9?= Liebscher) Date: Wed Jan 21 09:43:44 2004 Subject: [Distutils] Manifests References: <400B1267.4030007@prescod.net> <1074523954.14813.75.camel@localhost.localdomain> <16395.62981.479570.206768@sftp.fdrake.net> <1074526806.14813.110.camel@localhost.localdomain> Message-ID: <400E900A.755B6548@gmx.de> Jeremy Hylton wrote: > > On Mon, 2004-01-19 at 10:21, Fred L. Drake, Jr. wrote: > > Jeremy Hylton writes: > > > I think the MANIFEST.in language is a little odd and poorly documented, > > > but I don't know that it would be any better if I had to write Python > > > code to achieve the same effect. Here's a MANIFEST.in for a project I > > > I think a lot of milage could be had if there were a way to specify > > additional file extensions that should be copied as part of packages > > along with .py files. The would certainly be a reasonable 80% > > solution for the packages for which I work on the setup.py files. > > Good point! If we could have that option work for a bunch of commands, > it would help. > We also suffer to get data files copied into > site-packages along with their modules. If you could just say .xml > files in my modules should get installed just like .py files, life would > be much simpler. This is not a problem by writing an own sub class of install_data. Much better however would be to have such functionality in one of the next versions of distutils by default. My first try to extend distutils in this way was June 2000. (see also http://aspn.activestate.com/ASPN/Mail/Message/distutils-sig/587620 ) Some improved version of this script does its job in PyOpenGL ( http://cvs.sourceforge.net/viewcvs.py/pyopengl/PyOpenGL2/setup/my_install_data.py ) and PyXML ( http://cvs.sourceforge.net/viewcvs.py/pyxml/xml/setupext/install_data.py ) for years now. May be it is time to replace distutils install_data with this. (It accepts old parameter lists.) > > > ... > ... > Jeremy > Kind regards Rene Liebscher From paul at prescod.net Wed Jan 21 12:44:24 2004 From: paul at prescod.net (Paul Prescod) Date: Wed Jan 21 12:47:14 2004 Subject: [Distutils] build_lib Message-ID: <400EBA78.7080102@prescod.net> I'm having trouble in my code spelunking. Where does distutils.command.build_ext.build_ext get its build_platlib from? I'm guessing it is somewhere in distutils.command.build but there are two reasons I am confused. 1. Sometimes you invoke build_ext directly from the command line. Does a build object ever get created? 2. I can't find where the variable is passed explicitly. Maybe as part of some dictionary? Really, all I want to do is: python Setup.py build_ext --build-base=/tmp/junk But it won't work becaus build-base is defined on "build", not "build_ext". I could use the more specific "--build-lib" option but I like the way distutils lays out its directory. I just want to BOTH do a direct build_ext (rather than a higher level build) AND have control over the build-base. In the end it is going into a directory named "build" anyway, just not one in the current directory. Paul Prescod From mhammond at skippinet.com.au Wed Jan 21 19:03:30 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed Jan 21 19:03:43 2004 Subject: [Distutils] msvccompiler clobbers LIB/INCLUDE vars Message-ID: <002701c3e07b$2b7a9940$2c00a8c0@eden> I've recently noticed that msvccompiler clobbers the LIB and INCLUDE environment variables set in the environment. What happens is that distutils looks up the registry entries for the DevStudio include and lib file settings, then *sets* the LIB and INCLUDE environment with these values, ignoring any previous values. It is quite common (for me anyway ) to say something like: set LIB=%LIB%;c:\some_obscure_sdk\lib set INCLUDE=%INCLUDE%;c:\some_obscure_sdk\include make But if I try and use the same technique with distutils, these variable values are lost. It seems the *only* way I can add new paths that will work with distutils is via the DevStudio GUI, rather than these standard environment variables. Is that the intent? I understand we need to work when these variables are not set. Thanks, Mark. From revisits at truthmail.com Wed Jan 21 21:38:53 2004 From: revisits at truthmail.com (Revisits) Date: Wed Jan 21 21:38:57 2004 Subject: [Distutils] Distutils-sig, J0|N N0\/\/ to see new 2004 foorblddeen lnccessst scenes In-Reply-To: References: Message-ID: <1H21G9D473AH41GI@truthmail.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040122/9e4608ab/attachment.html From theller at python.net Thu Jan 22 02:43:46 2004 From: theller at python.net (Thomas Heller) Date: Thu Jan 22 02:43:50 2004 Subject: [Distutils] msvccompiler clobbers LIB/INCLUDE vars In-Reply-To: <002701c3e07b$2b7a9940$2c00a8c0@eden> (Mark Hammond's message of "Thu, 22 Jan 2004 11:03:30 +1100") References: <002701c3e07b$2b7a9940$2c00a8c0@eden> Message-ID: "Mark Hammond" writes: > I've recently noticed that msvccompiler clobbers the LIB and INCLUDE > environment variables set in the environment. What happens is that > distutils looks up the registry entries for the DevStudio include and lib > file settings, then *sets* the LIB and INCLUDE environment with these > values, ignoring any previous values. It was decided in the early distutils development to prefer the registry entries over env variables. Heck, most of my C/C++ developer collegues *never* run *anything* from the command line, or even know about the msvcvars.bat, vcvars32.bat, and vsvars32.bat batch files. Given the amount of complaints we get here about this, maybe the decision was wrong. > It is quite common (for me anyway ) to say something like: > set LIB=%LIB%;c:\some_obscure_sdk\lib > set INCLUDE=%INCLUDE%;c:\some_obscure_sdk\include > make > > But if I try and use the same technique with distutils, these variable > values are lost. > > It seems the *only* way I can add new paths that will work with distutils is > via the DevStudio GUI, rather than these standard environment variables. Is > that the intent? I understand we need to work when these variables are not > set. Can't you use the include_dirs and library_dirs arguments to the setup function? Thomas From mhammond at skippinet.com.au Thu Jan 22 03:09:02 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu Jan 22 03:09:16 2004 Subject: [Distutils] msvccompiler clobbers LIB/INCLUDE vars In-Reply-To: Message-ID: <00b801c3e0bf$000419f0$2c00a8c0@eden> > It was decided in the early distutils development to prefer > the registry > entries over env variables. Heck, most of my C/C++ developer > collegues > *never* run *anything* from the command line, or even know about the > msvcvars.bat, vcvars32.bat, and vsvars32.bat batch files. Yes, I understand, hence my question about the intent. > Given the amount of complaints we get here about this, maybe the > decision was wrong. Do you get alot about this exact same thing? If so, I see no reason not to honour *both* LIB and the registry. Users who never run these batchfiles or use the commandline should have a fairly benign LIB/INCLUDE. > Can't you use the include_dirs and library_dirs arguments to the setup > function? The problem is that these paths are local to my machine. Eg, you ask the user to install some random MS SDK, so it is this user that needs to specify the new path. I'm not sure of the best way to hook that up. I did find it very confusing though - I knew that it was the compiler itself that used the LIB/INCLUDE vars, and was very surprised to find the compiler didn't see what I explicitly set in the environment. Is there a reason you can't do something like: os.environ["lib"] = get_registry_libs() + os.environ["lib"] instead of what you do currently: os.environ["lib"] = get_registry_libs() ? Putting what you read from the registry first should ensure the same semantics. I don't really care, as I will have to work something out for 2.2/2.3 too. I'm now sidetracked on what to do regarding the lack of install-script on 2.2 ;) Thanks! Mark. From theller at python.net Thu Jan 22 03:24:16 2004 From: theller at python.net (Thomas Heller) Date: Thu Jan 22 03:24:20 2004 Subject: [Distutils] msvccompiler clobbers LIB/INCLUDE vars In-Reply-To: <00b801c3e0bf$000419f0$2c00a8c0@eden> (Mark Hammond's message of "Thu, 22 Jan 2004 19:09:02 +1100") References: <00b801c3e0bf$000419f0$2c00a8c0@eden> Message-ID: "Mark Hammond" writes: >> It was decided in the early distutils development to prefer the >> registry entries over env variables. Heck, most of my C/C++ >> developer collegues *never* run *anything* from the command line, or >> even know about the msvcvars.bat, vcvars32.bat, and vsvars32.bat >> batch files. > > Yes, I understand, hence my question about the intent. > >> Given the amount of complaints we get here about this, maybe the >> decision was wrong. > > Do you get alot about this exact same thing? If so, I see no reason not to > honour *both* LIB and the registry. Users who never run these batchfiles or > use the commandline should have a fairly benign LIB/INCLUDE. Most complaints that I remember were from users having 'broken' MSVC installs - they installed MSVC, but never run the GUI, which is required to complete the registry entries. >> Can't you use the include_dirs and library_dirs arguments to the setup >> function? > > The problem is that these paths are local to my machine. Eg, you ask the > user to install some random MS SDK, so it is this user that needs to specify > the new path. I'm not sure of the best way to hook that up. Well, distutils probably behaves the same as MS IDE - when you install the platforma sdk, you have to register it with visual studio: there's a start menu entry for this ;-). > I did find it very confusing though - I knew that it was the compiler itself > that used the LIB/INCLUDE vars, and was very surprised to find the compiler > didn't see what I explicitly set in the environment. > > Is there a reason you can't do something like: > os.environ["lib"] = get_registry_libs() + os.environ["lib"] > instead of what you do currently: > os.environ["lib"] = get_registry_libs() > > ? Putting what you read from the registry first should ensure the same > semantics. I don't really care, as I will have to work something out for > 2.2/2.3 too. That may be, but IMO it's too late to change distutils. And usually there's a workaround by subclassing a distutils command or whatever. > I'm now sidetracked on what to do regarding the lack of > install-script on 2.2 ;) You should be able to use 2.3's distutils on 2.2 to build your installation without problems. It is only needed on build time. Thomas From cbass233 at yahoo.com Thu Jan 22 08:46:48 2004 From: cbass233 at yahoo.com (Chuck Bass) Date: Thu Jan 22 08:47:01 2004 Subject: [Distutils] Are there command line options for wininst builds? In-Reply-To: Message-ID: <20040122134648.46172.qmail@web13905.mail.yahoo.com> When we do fresh installs, our app requires python, numarray, random array, linear algegra, PIL, reportlabs and packages that we've written. I'm installing the whole mess using innosetup which does a fine job of packaging this all up. Unfortunately our users still have to go through many (default) steps. Is there a way (e.g. command line /silent or /defaults) to make the wininst installer just go about it's businsess without user intervention or perhaps less intervention? Chuck __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From theller at python.net Thu Jan 22 09:24:02 2004 From: theller at python.net (Thomas Heller) Date: Thu Jan 22 09:24:08 2004 Subject: [Distutils] Are there command line options for wininst builds? In-Reply-To: <20040122134648.46172.qmail@web13905.mail.yahoo.com> (Chuck Bass's message of "Thu, 22 Jan 2004 05:46:48 -0800 (PST)") References: <20040122134648.46172.qmail@web13905.mail.yahoo.com> Message-ID: Chuck Bass writes: > When we do fresh installs, our app requires python, numarray, random > array, linear algegra, PIL, reportlabs and packages that we've > written. I'm installing the whole mess using innosetup which does a > fine job of packaging this all up. Unfortunately our users still have > to go through many (default) steps. Is there a way (e.g. command line > /silent or /defaults) to make the wininst installer just go about it's > businsess without user intervention or perhaps less intervention? Sorry, no. Thomas From cbass233 at yahoo.com Thu Jan 22 11:59:58 2004 From: cbass233 at yahoo.com (Chuck Bass) Date: Thu Jan 22 12:00:19 2004 Subject: [Distutils] Are there command line options for wininst builds? In-Reply-To: Message-ID: <20040122165958.16732.qmail@web13909.mail.yahoo.com> I've looked at the wininst code and they do some tricky stuff with appending some binary to build an exe file on the fly. Is the source available that made that binary. If it is available I'd be willing to take a look at making it accept some command line parameters. Chuck > > Sorry, no. > > Thomas > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From theller at python.net Thu Jan 22 14:27:05 2004 From: theller at python.net (Thomas Heller) Date: Thu Jan 22 14:27:11 2004 Subject: [Distutils] Are there command line options for wininst builds? In-Reply-To: <20040122165958.16732.qmail@web13909.mail.yahoo.com> (Chuck Bass's message of "Thu, 22 Jan 2004 08:59:58 -0800 (PST)") References: <20040122165958.16732.qmail@web13909.mail.yahoo.com> Message-ID: Chuck Bass writes: > I've looked at the wininst code and they do some tricky stuff with > appending some binary to build an exe file on the fly. Is the source > available that made that binary. If it is available I'd be willing to > take a look at making it accept some command line parameters. > The source is in python CVS: But be warned, it's not an example how to separate view and model ;-(. It might be *much* easier to come up with a bdist_wininst_2 command or so, which uses Python's zipfile module and maybe a py2exe built exefile, and silently installs the stuff just where Python is installed. The zipfile module wasn't standard when the source code was written, so the C code had to handle unpacking of the zip archive. Gee, this may even be a project idea if I wouldn't have other things to do. Thomas From cbass233 at yahoo.com Thu Jan 22 16:00:30 2004 From: cbass233 at yahoo.com (Chuck Bass) Date: Thu Jan 22 16:00:37 2004 Subject: [Distutils] Are there command line options for wininst builds? In-Reply-To: Message-ID: <20040122210030.46912.qmail@web13907.mail.yahoo.com> Thomas thanks for your quick responses. Your emails are doubling up for some reason. I looked at the source. It looks like it might be reasonable to change things around a bit. What I don't see is instructions on how to turn the EXE that MSVC builds into the binary 'text' that disutils uses to build the installation program. Is this documented somewhere? Chuck --- Thomas Heller wrote: > Chuck Bass writes: > > > I've looked at the wininst code and they do some tricky stuff with > > appending some binary to build an exe file on the fly. Is the source > > available that made that binary. If it is available I'd be willing to > > take a look at making it accept some command line parameters. > > > > The source is in python CVS: > > > > But be warned, it's not an example how to separate view and model ;-(. > > It might be *much* easier to come up with a bdist_wininst_2 command or > so, which uses Python's zipfile module and maybe a py2exe built exefile, > and silently installs the stuff just where Python is installed. > > The zipfile module wasn't standard when the source code was written, so > the C code had to handle unpacking of the zip archive. > > Gee, this may even be a project idea if I wouldn't have other things to do. > > Thomas > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From theller at python.net Thu Jan 22 16:09:33 2004 From: theller at python.net (Thomas Heller) Date: Thu Jan 22 16:09:41 2004 Subject: [Distutils] Are there command line options for wininst builds? In-Reply-To: <20040122210030.46912.qmail@web13907.mail.yahoo.com> (Chuck Bass's message of "Thu, 22 Jan 2004 13:00:30 -0800 (PST)") References: <20040122210030.46912.qmail@web13907.mail.yahoo.com> Message-ID: Chuck Bass writes: > Thomas thanks for your quick responses. Your emails are doubling up for some reason. Wrong setup of my email client, I guess ;-) > I looked at the source. It looks like it might be reasonable to > change things around a bit. What I don't see is instructions on how > to turn the EXE that MSVC builds into the binary 'text' that disutils > uses to build the installation program. Is this documented somewhere? It seems you're using Python 2.2. The Lib\distutils\command\bdist_wininst.py file, when run as a script without any arguments, recreates itself if it finds the wininst.exe in a certain place. I'm sure you can figure it out, the code is around line 221. If you use Python 2.3 (or copy the distutils package from 2.3 to your 2.2 installation), this is no longer needed. The bdist_wininst command from 2.3 just expects the wininst.exe file in the same directory. Whatever you use, make sure that you use C sources belonging to the distutils version you use. Thomas From mhammond at skippinet.com.au Sun Jan 25 18:37:32 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun Jan 25 18:37:45 2004 Subject: [Distutils] MSVC7 directories Message-ID: <075401c3e39c$34d84d60$2c00a8c0@eden> Just incase it slips under the radar, I have opened a bug regarding MSVC7 directories. Specifically, changes I make to the directories in the MSVC7 GUI are not seen by distutils. All the details, and a patch, is in the bug: http://www.python.org/sf/883969 [ 883969 ] distutils doesn't see user-directories set via VisStudio 7.1 Any comments appreciated, Thanks, Mark From robin at jessikat.fsnet.co.uk Mon Jan 26 04:02:58 2004 From: robin at jessikat.fsnet.co.uk (Robin Becker) Date: Mon Jan 26 04:03:23 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <075401c3e39c$34d84d60$2c00a8c0@eden> References: <075401c3e39c$34d84d60$2c00a8c0@eden> Message-ID: In article <075401c3e39c$34d84d60$2c00a8c0@eden>, Mark Hammond writes >Just incase it slips under the radar, I have opened a bug regarding MSVC7 >directories. Specifically, changes I make to the directories in the MSVC7 >GUI are not seen by distutils. All the details, and a patch, is in the bug: > >http://www.python.org/sf/883969 >[ 883969 ] distutils doesn't see user-directories set via VisStudio 7.1 > >Any comments appreciated, > >Thanks, > >Mark Always seemed a bit daft to do this implicitly from the IDE (eg when I set things up for stackless my ordinary stuff seems to see the wrong paths). There is special code in there about version >=7 though. if self.__version >= 7: key = (r"%s\%0.1f\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Director ies" % (self.__root, self.__version)) else: key = (r"%s\6.0\Build System\Components\Platforms" r"\Win32 (%s)\Directories" % (self.__root, platform)) -- Robin Becker From wtbridgman at radix.net Mon Jan 26 15:13:12 2004 From: wtbridgman at radix.net (W.T. Bridgman) Date: Mon Jan 26 15:12:24 2004 Subject: [Distutils] Newbie Q:Why no _mylib.so? Message-ID: <115C86F0-503C-11D8-AE15-0050E485FC7A@radix.net> I've made a C-extension python wrapper with SWIG and now want to make a distutils script to compile & install it. Note I am *NOT* trying to let distutils build the SWIG wrapper (at least not yet). I can successfully build the extension from the command line and access it from python but one of the problems I've encountered is that when distutils builds the library, it comes out as myllib.so, not _mylib.so. Python insists on importing _mylib and SWIG seems determined to generate code for a target _mylib.so. I'm also having problems getting distutils to place the _mylib.so and mylib.py files in the proper locations. Is there a way to get distutils to generate the _mylib.so or change the import behavior in Python? I examined several installers that do about what I want (like numarray v0.8) but they have a lot of other code whose behavior I am uncertain about. In case it matters, I'm on MacOS X 10.2.6, SWIG 1.3.19, Python 2.3. Thanks, Tom From groff-admin at ffii.org Mon Jan 26 17:36:25 2004 From: groff-admin at ffii.org (groff-admin@ffii.org) Date: Mon Jan 26 17:36:27 2004 Subject: [Distutils] Your message to Groff awaits moderator approval Message-ID: Your mail to 'Groff' with the subject hi Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. From fetchmail-friends-admin at lists.ccil.org Mon Jan 26 19:26:05 2004 From: fetchmail-friends-admin at lists.ccil.org (fetchmail-friends-admin@lists.ccil.org) Date: Mon Jan 26 19:30:01 2004 Subject: [Distutils] Your message to Fetchmail-friends awaits moderator approval Message-ID: <20040127002605.6603.4135.Mailman@saturn.ccil.org> Your mail to 'Fetchmail-friends' with the subject ERROR Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. From confirm-bounce-59c70b5ae32b3a2582a02d240c07642d-distutils-sig=python.org at lists.mysql.com Mon Jan 26 19:58:47 2004 From: confirm-bounce-59c70b5ae32b3a2582a02d240c07642d-distutils-sig=python.org at lists.mysql.com (MySQL Lists Automoderator) Date: Mon Jan 26 19:59:12 2004 Subject: [Distutils] MySQL posting confirmation for distutils-sig@python.org Message-ID: <20040127005847.22318.qmail@lists.mysql.com> This is an automatic reply to an email you sent to a MySQL mailing address protected by our 'self-moderation' system. To reduce the amount of spam received at these addresses, we require you to confirm that you're a real person before your email will be allowed through. All you have to do in order to have your original message sent is click on the following link (or cut-and-paste it to a browser): http://lists.mysql.com/c/59c70b5ae32b3a2582a02d240c07642d/distutils-sig@python.org After we have received your confirmation, "distutils-sig@python.org" will be added to the list of pre-approved mail addresses for all of the MySQL mailing lists, your original message will be delivered, and future emails from that address will be delivered without delay automatically. You will not receive an emailed confirmation of your confirmation -- your original message (and any other messages you have sent since then) will simply be sent to its original destination (possibly after a short delay). Sorry for the hassle, but the volume of unsolicited commercial email sent to these addresses has made this step necessary. --- Your original email is below. From postmaster at aconex.com Mon Jan 26 20:35:07 2004 From: postmaster at aconex.com (postmaster@aconex.com) Date: Mon Jan 26 20:35:28 2004 Subject: [Distutils] VIRUS IN YOUR MAIL Message-ID: <20040127013507.AA8622260B8@mail.aconex.com> V I R U S A L E R T Our viruschecker found the 'W32/MyDoom-A' virus(es) in your email to the following recipient(s): -> ifvol@amsppt.sty Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Received: from python.org (unknown [192.168.0.163]) by mail.aconex.com (Postfix) with ESMTP id 9407B2260BD for ; Tue, 27 Jan 2004 12:35:05 +1100 (EST) From: distutils-sig@python.org To: ifvol@amsppt.sty Subject: HI Date: Tue, 27 Jan 2004 12:34:38 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_73C6DD33.8BA20972" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20040127013505.9407B2260BD@mail.aconex.com> -------------------------- END HEADERS ------------------------------ From owner-mutt-users at mutt.org Mon Jan 26 20:57:00 2004 From: owner-mutt-users at mutt.org (owner-mutt-users@mutt.org) Date: Mon Jan 26 20:57:04 2004 Subject: [Distutils] mutt-users@mutt.org: Non-member submission from distutils-sig@python.org Message-ID: <20040127015700.9779.qmail@agent57.gbnet.net> Your submission to the list has been forwarded to the list owner for approval because you do not seem to be on that list. If you want to join the list, send email to , with "subscribe mutt-users" in the message text (not the subject). From slash at dotnetslash.net Mon Jan 26 20:59:35 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Mon Jan 26 21:00:16 2004 Subject: [Distutils] Anti-bacteria treatment In-Reply-To: <20040127013507.AA8622260B8@mail.aconex.com> References: <20040127013507.AA8622260B8@mail.aconex.com> Message-ID: <20040127015935.GB9776@dotnetslash.net> Ok. 1) All distutils subscribers using Windows, _please_ update your anti-virus software and scan again now. (Quick! The cows are out of the barn!) Someone with the distutils address in there address book _is_ (or was) infected and it really _could_ be you... 2) Can this list refuse mail from non-subscribers, like the other ones rejecting the spoofed vir** apparently are, so we stop getting notices from vir** spoofing the distutils list address? If Python wasn't cross-platform, there'd be _no_ use for Windows -- Mark W. Alexander slash@dotnetslash.net From theller at python.net Tue Jan 27 03:04:39 2004 From: theller at python.net (Thomas Heller) Date: Tue Jan 27 03:04:44 2004 Subject: [Distutils] Anti-bacteria treatment In-Reply-To: <20040127015935.GB9776@dotnetslash.net> (Mark W. Alexander's message of "Mon, 26 Jan 2004 20:59:35 -0500") References: <20040127013507.AA8622260B8@mail.aconex.com> <20040127015935.GB9776@dotnetslash.net> Message-ID: "Mark W. Alexander" writes: > 2) Can this list refuse mail from non-subscribers, like the other ones > rejecting the spoofed vir** apparently are, so we stop getting notices > from vir** spoofing the distutils list address? Personally, I find member-post only lists a pain. I'd rather delete the occasional spam messages (the spam from mailing lists like this is only a small fraction of the total spam I get) from mailing lists than to manage all the subscriptions. Spam in the mailing list archives is probably another problem, although gmane has a nice solution for that - you can report the message as spam and it will vanish from the archives. Thomas From mal at egenix.com Tue Jan 27 04:22:54 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 27 04:24:31 2004 Subject: [Distutils] Anti-bacteria treatment In-Reply-To: References: <20040127013507.AA8622260B8@mail.aconex.com> <20040127015935.GB9776@dotnetslash.net> Message-ID: <40162DEE.2060001@egenix.com> Thomas Heller wrote: > "Mark W. Alexander" writes: > > >>2) Can this list refuse mail from non-subscribers, like the other ones >>rejecting the spoofed vir** apparently are, so we stop getting notices >>from vir** spoofing the distutils list address? > > > Personally, I find member-post only lists a pain. I'd rather delete the > occasional spam messages (the spam from mailing lists like this is only > a small fraction of the total spam I get) from mailing lists than to > manage all the subscriptions. > > Spam in the mailing list archives is probably another problem, although > gmane has a nice solution for that - you can report the message as spam > and it will vanish from the archives. Same here. Subscribers can use the spambayes header to filter these: X-Spam-Status: OK (lists-python 0.000) If you filter out everything that's *not* marked OK you should get a pretty clean mailing list input. BTW, the same is true for all python.org mailing lists. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 26 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From owner-mutt-users at mutt.org Tue Jan 27 04:49:34 2004 From: owner-mutt-users at mutt.org (owner-mutt-users@mutt.org) Date: Tue Jan 27 04:49:38 2004 Subject: [Distutils] mutt-users@mutt.org: Non-member submission from distutils-sig@python.org Message-ID: <20040127094934.12780.qmail@agent57.gbnet.net> Your submission to the list has been forwarded to the list owner for approval because you do not seem to be on that list. If you want to join the list, send email to , with "subscribe mutt-users" in the message text (not the subject). From pearu at cens.ioc.ee Tue Jan 27 05:06:15 2004 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue Jan 27 05:06:37 2004 Subject: [Distutils] Newbie Q:Why no _mylib.so? In-Reply-To: <115C86F0-503C-11D8-AE15-0050E485FC7A@radix.net> Message-ID: On Mon, 26 Jan 2004, W.T. Bridgman wrote: > I've made a C-extension python wrapper with SWIG and now want to make a > distutils script to compile & install it. Note I am *NOT* trying to > let distutils build the SWIG wrapper (at least not yet). > > I can successfully build the extension from the command line and access > it from python but one of the problems I've encountered is that when > distutils builds the library, it comes out as myllib.so, not _mylib.so. > Python insists on importing _mylib and SWIG seems determined to > generate code for a target _mylib.so. I'm also having problems getting > distutils to place the _mylib.so and mylib.py files in the proper > locations. > > Is there a way to get distutils to generate the _mylib.so or change the > import behavior in Python? Use Extension('_mylib',..) instead of Extension('mylib',..) in your setup.py file. Pearu From dave at turbocat.de Tue Jan 27 03:31:50 2004 From: dave at turbocat.de (dave@turbocat.de) Date: Tue Jan 27 07:28:48 2004 Subject: [Distutils] Server Report Message-ID: <200401270832.i0R8VmYU054599@mxzilla8.xs4all.nl> The message contains Unicode characters and has been sent as a binary attachment. From alert at notification.messagelabs.com Tue Jan 27 07:48:58 2004 From: alert at notification.messagelabs.com (alert@notification.messagelabs.com) Date: Tue Jan 27 07:49:04 2004 Subject: [Distutils] WARNING. You tried to send a potential virus or unauthorised code Message-ID: <20040127124858.32605.qmail@server-8.tower-33.messagelabs.com> The MessageLabs SkyScan Anti-Virus service discovered a possible virus or unauthorised code (such as a joke program or trojan) in an email sent by you. The email has now been quarantined and was not delivered. Please read the whole of this email carefully. It explains what has happened to your email, which suspected virus has been caught and what to do if you need help addressing the problem. To help identify the quarantined email: The message sender was distutils-sig@python.org The message recipients were anna@sweng.stortek.com The message title was Error The message date was Tue, 27 Jan 2004 13:51:27 -0600 The virus or unauthorised code identified in the email is >>> W32/MyDoom.A in '230059_3X_AZ-S_PA2__test.txt=R46.pif' Some viruses forge the sender address. For more information please visit the link to the virus FAQ's at the bottom of this page. The message was diverted into the virus holding pen on mail server server-8.tower-33.messagelabs.com (pen id 230059_1075207738) and will be held for 30 days before being destroyed Corporate Users: If you sent the email from a corporate network, you should first contact your local IT Helpdesk or System Administrator for advice. They will be able to help you disinfect your workstation. If you would like further information on how to subscribe to MessageLabs SkyScan AV service, a proactive anti-virus service working around the clock, around the globe, please complete our enquiry form. Personal or Home users: If you sent the email from a personal or home account, you will need to disinfect your computer yourself. Please contact your anti-virus software vendor for support. You may like to read the virus FAQ's at: http://www.messagelabs.com/page.asp?id=628 which will answer most virus related questions. ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From virusalert at dlh.net Tue Jan 27 10:01:19 2004 From: virusalert at dlh.net (virusalert@dlh.net) Date: Tue Jan 27 10:01:29 2004 Subject: [Distutils] VIRUS IN YOUR MAIL Message-ID: V I R U S A L E R T Our viruschecker found the I-Worm.Novarg virus(es) in your email to the following recipient(s): -> pl@dlh.net Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Received: from port-213-160-25-94.reverse.qsc.de ([213.160.25.94] helo=python.org) by mail.dlh.net with esmtp (Exim 3.36 #9 (Debian)) id 1AlUiJ-0002iE-00 for ; Tue, 27 Jan 2004 16:01:15 +0100 From: distutils-sig@python.org To: pl@dlh.net Subject: Test Date: Tue, 27 Jan 2004 16:01:15 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_B13230BB.356C1949" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: -------------------------- END HEADERS ------------------------------ From postmaster at ct.infn.it Tue Jan 27 12:46:29 2004 From: postmaster at ct.infn.it (postmaster@ct.infn.it) Date: Tue Jan 27 12:42:58 2004 Subject: [Distutils] VIRUS IN YOUR MAIL Message-ID: <20040127174629.6194A25FB9@clusma1.ct.infn.it> V I R U S A L E R T Our viruschecker found the [Win32/Shimg.Worm] virus in your email to the following recipient: -> adam@ct.infn.it Delivery of the email was stopped! Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the SMTP envelope originator and headers from your email: >From distutils-sig@python.org ------------------------- BEGIN HEADERS ----------------------------- Received: by clusma1.ct.infn.it (Postfix on SuSE Linux 8.0 (i386), from userid 501) id 92F4325FA8; Tue, 27 Jan 2004 18:46:28 +0100 (CET) Received: from python.org (unknown [202.62.79.2]) by clusma1.ct.infn.it (Postfix on SuSE Linux 8.0 (i386)) with ESMTP id 9767625FBB for ; Tue, 27 Jan 2004 18:46:19 +0100 (CET) From: distutils-sig@python.org To: adam@ct.infn.it Subject: hello Date: Tue, 27 Jan 2004 23:10:21 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_4927BB71.666E17AC" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20040127174619.9767625FBB@clusma1.ct.infn.it> X-Spam-Status: No, hits=4.4 required=5.0 tests=MISSING_MIMEOLE,NO_REAL_NAME,PRIORITY_NO_NAME,SUB_HELLO version=2.53 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) -------------------------- END HEADERS ------------------------------ From iww.webschool.nl/webschool at webschool.nl Tue Jan 27 13:47:18 2004 From: iww.webschool.nl/webschool at webschool.nl (iww.webschool.nl/webschool@webschool.nl) Date: Tue Jan 27 13:48:30 2004 Subject: [Distutils] NAV heeft een virus gevonden in uw document. / NAV detected a virus in a document you authored. Message-ID: Neem contact op met uw systeembeheerder. Please contact your system administrator. The scanned document was QUARANTINED. Virus Information: The attachment data.zip contained the virus W32.Novarg.A@mm and could NOT be repaired. The attachment data.zip [data.scr] contained the virus W32.Novarg.A@mm and could NOT be repaired. From mail.administrator at milliman.com Tue Jan 27 14:05:01 2004 From: mail.administrator at milliman.com (mail.administrator@milliman.com) Date: Tue Jan 27 14:05:40 2004 Subject: [Distutils] (ScanMail has found a virus) Message-ID: The Trend Micro ScanMail service on one or more Milliman Notes servers has detected a virus. The virus infected file has been quarantined.ScanMail has detected a virus during a real-time scan of the email traffic. Date: 01/27/2004 11:05:01 AM Subject: [POTENTIAL SPAM - OPEN AT USER DISCRETION] hello Virus: WORM_MIMAIL.R File: document.zip From: distutils-sig@python.org@MRUS To: carol.zhang@milliman.com Bcc: Carol Zhang Action: Uncleanable, Quarantined; Scanned by ScanMail for Lotus Notes 2.6 with scanengine 6.810-1005 and patternfile lpt$vpn.745 ************************************************************************************** This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Unless indicated to the contrary: it does not constitute professional advice or opinions upon which reliance may be made by the addressee or any other party, and it should be considered to be a work in progress. ************************************************************************************** From anti-virus at mgn.net Tue Jan 27 14:47:31 2004 From: anti-virus at mgn.net (anti-virus@mgn.net) Date: Tue Jan 27 14:48:09 2004 Subject: [Distutils] Virus Alert Message-ID: <200401271947.i0RJlUN29002@yder.mgn.net> The mail message (file: document.zip) you sent to root-sandra@mgn.net contains a virus. From shipmana at acm.org Tue Jan 27 15:30:49 2004 From: shipmana at acm.org (shipmana@acm.org) Date: Tue Jan 27 15:30:05 2004 Subject: [Distutils] HELLO Message-ID: <200401272030.i0RKU05G017440@mx2.upv.es> ------------------ Virus Warning Message (on mx2.cc.upv.es) Found virus WORM_MIMAIL.R in file doc.pif The uncleanable file doc.pif is moved to /var/log/iscan/virus/vir6PtQCV. --------------------------------------------------------- -------------- next part -------------- -------------- next part -------------- ------------------ Virus Warning Message (on mx2.cc.upv.es) doc.pif is removed from here because it contains a virus. --------------------------------------------------------- From slash at dotnetslash.net Tue Jan 27 18:52:18 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Tue Jan 27 18:52:22 2004 Subject: [Distutils] Anti-bacteria treatment In-Reply-To: References: <20040127013507.AA8622260B8@mail.aconex.com> <20040127015935.GB9776@dotnetslash.net> Message-ID: <20040127235218.GA12433@dotnetslash.net> On Tue, Jan 27, 2004 at 09:04:39AM +0100, Thomas Heller wrote: > "Mark W. Alexander" writes: > > > 2) Can this list refuse mail from non-subscribers, like the other ones > > rejecting the spoofed vir** apparently are, so we stop getting notices > > from vir** spoofing the distutils list address? > > Personally, I find member-post only lists a pain. I'd rather delete the > occasional spam messages (the spam from mailing lists like this is only > a small fraction of the total spam I get) from mailing lists than to > manage all the subscriptions. Ok, I'll cope. I mostly wanted to get Windows washed. > Spam in the mailing list archives is probably another problem, although > gmane has a nice solution for that - you can report the message as spam > and it will vanish from the archives. So if I realize something I said was really stupid, I can call it "spam" and have the public display of my stupidity removed? Cool! mwa -- Mark W. Alexander slash@dotnetslash.net From virencheck at repas-aeg.de Wed Jan 28 05:28:44 2004 From: virencheck at repas-aeg.de (virencheck@repas-aeg.de) Date: Tue Jan 27 23:29:20 2004 Subject: [Distutils] Virenchecker Information Message-ID: <200401280429.i0S4TD818739@gwineta.repas.de> Dies ist eine automatisch generierte Meldung. Die Mail mit folgenden Eigenschaften: Subjekt: HI Absender: Empfänger: wurde nicht weitergeleitet, da sie vermutlich ein oder mehrere Attachment[s] mit potentiell gefährlich eingestufter Extension enthält! Für die Bewertung relevanter Abschnitt: <1> name="document.scr" <2> filename="document.scr" From robert.smith at intel.com Wed Jan 28 02:27:36 2004 From: robert.smith at intel.com (Smith, Robert) Date: Wed Jan 28 02:27:43 2004 Subject: [Distutils] Out of Office AutoReply: Status Message-ID: <6A52D76F047B5B4497C40B00097C876F04FBB60B@pgsmsx403.png.intel.com> Jan 22 and 23, 2004 are public holidays in Malaysia. I will be on vacation WW05. In office WW06.2 Penang Server Ops - Beng Kean Chuah, 253-7765 Kulim Server Ops - Dinesh Chandrakesan, 408- 2172 Urgent management escalations, Zulkifli Zakaria, 408-7888 From theller at python.net Wed Jan 28 02:53:19 2004 From: theller at python.net (Thomas Heller) Date: Wed Jan 28 02:53:30 2004 Subject: [Distutils] Anti-bacteria treatment In-Reply-To: <20040127235218.GA12433@dotnetslash.net> (Mark W. Alexander's message of "Tue, 27 Jan 2004 18:52:18 -0500") References: <20040127013507.AA8622260B8@mail.aconex.com> <20040127015935.GB9776@dotnetslash.net> <20040127235218.GA12433@dotnetslash.net> Message-ID: "Mark W. Alexander" writes: > On Tue, Jan 27, 2004 at 09:04:39AM +0100, Thomas Heller wrote: >> Spam in the mailing list archives is probably another problem, although >> gmane has a nice solution for that - you can report the message as spam >> and it will vanish from the archives. > > So if I realize something I said was really stupid, I can call it "spam" > and have the public display of my stupidity removed? Cool! I think the admin(s) still look at it. But I never tried this... Thomas From 817svlv at post.cz Wed Jan 28 06:51:54 2004 From: 817svlv at post.cz (Stella Logan) Date: Wed Jan 28 02:59:26 2004 Subject: [Distutils] Hi! Distutils-sig, Chance of a Lifetime!....==>... Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040128/0d286fdc/attachment.html From love2 at jobmail.to Wed Jan 28 06:49:50 2004 From: love2 at jobmail.to (love2@jobmail.to) Date: Wed Jan 28 06:50:00 2004 Subject: [Distutils] Re:TEST Message-ID: <20040128114950.42626.qmail@jobmail.to> ?? From MAILER-DAEMON at ms.nifs.ac.jp Wed Jan 28 08:56:46 2004 From: MAILER-DAEMON at ms.nifs.ac.jp (Mail Delivery Subsystem) Date: Wed Jan 28 08:56:53 2004 Subject: [Distutils] Returned mail: User unknown Message-ID: <200401281356.WAA11601@ms.nifs.ac.jp> Skipped content of type multipart/report-------------- next part -------------- ---------- Virus was removed from this mail Found virus WORM_MIMAIL.R in file document.pif (in document.zip) The uncleanable file document.zip is moved to /var/iscan/virus/virARE0CgMgZ. For more information, see http://ccweb.nifs.ac.jp/nifs-vaccine-isvw/ or contact to cc-net-staff@nifs.ac.jp (Computer Center, NIFS). ---------- Vaccine software on NIFS mail server ..... nifs-vaccine-isvw From mbabcock at fibrespeed.net Wed Jan 28 16:00:03 2004 From: mbabcock at fibrespeed.net (Michael T. Babcock) Date: Wed Jan 28 15:59:54 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) Message-ID: <401822D3.8070009@fibrespeed.net> Would it be worthwhile to stipulate that anyone who wants to submit a package to an automated distutils system have a PGP/GPG key signed by an appropriate Python authority or another developper? Initially these would all be an "authority" of some form, of course. This at least allows the authentication of authors' packages as being intact and submitted by themselves, which then allows a good method of filtering /? la/ "I like this author's software", etc. via rating systems and the like. Just a thought from a PGP activist. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040128/9ba0c372/attachment.html From VirusScan at mitel.com Wed Jan 28 21:49:18 2004 From: VirusScan at mitel.com (VirusScan@mitel.com) Date: Wed Jan 28 21:49:22 2004 Subject: [Distutils] Virus Detected by Network Associates, Inc. Webshield SMTP V4.5 MR1a Message-ID: <200401290249.i0T2nJYv027773@mitel.mitel.com> ottscan01 at MItel Networks detected virus W32/Mydoom@MM in attachment file.scr from and it was Deleted. From Symantec_AntiVirus_for_SMTP_Gateways at cc.stonybrook.edu Thu Jan 29 03:31:03 2004 From: Symantec_AntiVirus_for_SMTP_Gateways at cc.stonybrook.edu (Symantec_AntiVirus_for_SMTP_Gateways@cc.stonybrook.edu) Date: Thu Jan 29 03:31:08 2004 Subject: [Distutils] A virus was detected in a message you sent Message-ID: <200401290831.i0T8TAt4021978@ms.cc.sunysb.edu> From Paul.Moore at atosorigin.com Thu Jan 29 03:58:07 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Thu Jan 29 03:58:10 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060DD5@UKDCX001.uk.int.atosorigin.com> From: Michael T. Babcock > Would it be worthwhile to stipulate that anyone who wants to submit a > package to an automated distutils system have a PGP/GPG key signed by > an appropriate Python authority or another developper? Initially these > would all be an "authority" of some form, of course. This at least > allows the authentication of authors' packages as being intact and > submitted by themselves, which then allows a good method of filtering > ? la "I like this author's software", etc. via rating systems and the > like. -1. The effect would be to bar new submitters, who wouldn't have the necessary signed key, as well as to people like myself who can't be bothered trying to maintain a PGP key. Paul From owner-mutt-users at mutt.org Thu Jan 29 05:09:58 2004 From: owner-mutt-users at mutt.org (owner-mutt-users@mutt.org) Date: Thu Jan 29 05:10:03 2004 Subject: [Distutils] mutt-users@mutt.org: Non-member submission from distutils-sig@python.org Message-ID: <20040129100958.1801.qmail@agent57.gbnet.net> Your submission to the list has been forwarded to the list owner for approval because you do not seem to be on that list. If you want to join the list, send email to , with "subscribe mutt-users" in the message text (not the subject). From anthony at interlink.com.au Thu Jan 29 06:15:36 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Thu Jan 29 06:16:09 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060DD5@UKDCX001.uk.int.atosorigin.com> Message-ID: <20040129111536.30B4B25AE97@bonanza.off.ekorp.com> >>> "Moore, Paul" wrote > From: Michael T. Babcock > > Would it be worthwhile to stipulate that anyone who wants to submit a > > package to an automated distutils system have a PGP/GPG key signed by > > an appropriate Python authority or another developper? > -1. The effect would be to bar new submitters, who wouldn't have the > necessary signed key, as well as to people like myself who can't be > bothered trying to maintain a PGP key. It should be at least an option, anyway. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From Paul.Moore at atosorigin.com Thu Jan 29 06:18:47 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Thu Jan 29 06:18:50 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) Message-ID: <16E1010E4581B049ABC51D4975CEDB8802C09C2F@UKDCX001.uk.int.atosorigin.com> From: Anthony Baxter >>>> "Moore, Paul" wrote >> From: Michael T. Babcock >> > Would it be worthwhile to stipulate that anyone who wants to submit a >> > package to an automated distutils system have a PGP/GPG key signed by >> > an appropriate Python authority or another developper? >> -1. The effect would be to bar new submitters, who wouldn't have the >> necessary signed key, as well as to people like myself who can't be >> bothered trying to maintain a PGP key. > It should be at least an option, anyway. Optional's certainly OK. It's really the "signed by an ... authority" bit that seems draconic. Paul From bob at redivi.com Thu Jan 29 06:26:29 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 29 06:23:50 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: <20040129111536.30B4B25AE97@bonanza.off.ekorp.com> References: <20040129111536.30B4B25AE97@bonanza.off.ekorp.com> Message-ID: On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote: > >>>> "Moore, Paul" wrote >> From: Michael T. Babcock >>> Would it be worthwhile to stipulate that anyone who wants to submit a >>> package to an automated distutils system have a PGP/GPG key signed by >>> an appropriate Python authority or another developper? > >> -1. The effect would be to bar new submitters, who wouldn't have the >> necessary signed key, as well as to people like myself who can't be >> bothered trying to maintain a PGP key. > > It should be at least an option, anyway. Isn't most of the stuff used to support GPG under the GNU GPL license? I think that would preclude it from being incorporated into the mainline of distutils. Personally, I don't think it would be a popular enough feature to justify the changes. For the people who do care, a "meta-index" could be created where the developer could, email a pgp-signed or s/mime signed message containing the URLs and sha1 hashes of the files to some robot-address that would insert it into the "meta-index" if the credentials were ok. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040129/3bb30aa6/smime.bin From Steward-owner at hethmon.com Thu Jan 29 17:48:57 2004 From: Steward-owner at hethmon.com (Steward-owner) Date: Thu Jan 29 18:06:15 2004 Subject: [Distutils] Steward Results Message-ID: <20040129174857-1638-6976@mail.hethmon.com> >>>this is a multi-part message in MIME format. Unknown command ignored. >>>------=_nextpart_000_0003_f9fcc063.dcee70bd Unknown command ignored. >>>content-type: text/plain; Unknown command ignored. >>>charset="windows-1252" Unknown command ignored. >>>content-transfer-encoding: 7bit Unknown command ignored. >>>------=_nextpart_000_0003_f9fcc063.dcee70bd Unknown command ignored. >>>content-type: application/octet-stream; Unknown command ignored. >>>name="readme.zip" Unknown command ignored. >>>content-transfer-encoding: base64 Unknown command ignored. No valid commands found in your message. Sending help instead. >>> This is the Steward mailing list software, Version 1.17 of 23 August 2002. Steward understands the following commands: subscribe [
] Subscribe yourself to the named .
is optional. sub [
] Subscribe yourself to the named .
is optional. post [
] Add your email address for posting only to the list named .
is optional. unsubscribe [
] Unsubscribe yourself to the named .
is optional. unsub [
] Unsubscribe yourself to the named .
is optional. kill [
] Unsubscribe someone from the list named .
is optional. who List the list members email addresses. help Send this message. lists Show the lists available from this server. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of the email message to Steward@hethmon.com. Multiple commands may be included in one message provided each is on its own line. Commands in the "Subject" field are ignored. Questions should be sent to postmaster@hethmon.com. From simon at arrowtheory.com Thu Jan 29 18:41:51 2004 From: simon at arrowtheory.com (Simon Burton) Date: Thu Jan 29 18:36:54 2004 Subject: [Distutils] building a wrapper on OSX Message-ID: <20040130104151.3585ef97.simon@arrowtheory.com> I'm having trouble linking my wrapper on OSX. It works fine on linux. The linker complains about undefined symbols from the wrapped library. If I use "-undefined suppress" the link happens, but then python stumbles with the same complaint when I do the import. ZMA:~/dsp$ python2.3 setup.py build running build running build_py copying test_sndfile.py -> build/lib.darwin-6.8-Power_Macintosh-2.3 running build_ext building 'sndfile' extension gcc -Wl,-F. -bundle -framework Python build/temp.darwin-6.8-Power_Macintosh-2.3/sndfile.o -L/usr/local/lib -lsndfile -o build/lib.darwin-6.8-Power_Macintosh-2.3/sndfile.so ld: Undefined symbols: _sf_open_fd error: command 'gcc' failed with exit status 1 ZMA:~/dsp$ Somehow the info on the original libsndfile is lost. Any ideas? Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com From bob at redivi.com Thu Jan 29 18:47:20 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 29 18:44:51 2004 Subject: [Distutils] building a wrapper on OSX In-Reply-To: <20040130104151.3585ef97.simon@arrowtheory.com> References: <20040130104151.3585ef97.simon@arrowtheory.com> Message-ID: <7A7DD912-52B5-11D8-8870-000A95686CD8@redivi.com> On Jan 29, 2004, at 6:41 PM, Simon Burton wrote: > > I'm having trouble linking my wrapper on OSX. > It works fine on linux. The linker complains about undefined symbols > from the wrapped library. > If I use "-undefined suppress" the link happens, but then python > stumbles with the same complaint > when I do the import. > > ZMA:~/dsp$ python2.3 setup.py build > running build > running build_py > copying test_sndfile.py -> build/lib.darwin-6.8-Power_Macintosh-2.3 > running build_ext > building 'sndfile' extension > gcc -Wl,-F. -bundle -framework Python > build/temp.darwin-6.8-Power_Macintosh-2.3/sndfile.o -L/usr/local/lib > -lsndfile -o build/lib.darwin-6.8-Power_Macintosh-2.3/sndfile.so > ld: Undefined symbols: > _sf_open_fd > error: command 'gcc' failed with exit status 1 > ZMA:~/dsp$ > > Somehow the info on the original libsndfile is lost. > Any ideas? First off: never, ever, do -undefined suppress. Its use is only applicable to OS X 10.0 -> 10.1, later versions of OS X have better mechanisms for dealing with this. Chances are, either the symbol is static (not exported), or it's external to libsndfile. You can run nm on libsndfile.dylib (or .a, whatever it is) and see if it's actually defined. If it's not defined, it's probably in one of the frameworks or dylibs it links to, you can check that with otool -L libsndfile.dylib. On OS X, you need to directly link to anything that you use symbols from. If you still have trouble, point me to libsndfile and I will take a look at it. -bob BTW: the best mailing list for this sort of inquiry is pythonmac-sig From simon at arrowtheory.com Thu Jan 29 19:08:55 2004 From: simon at arrowtheory.com (Simon Burton) Date: Thu Jan 29 19:02:32 2004 Subject: [Distutils] building a wrapper on OSX In-Reply-To: <7A7DD912-52B5-11D8-8870-000A95686CD8@redivi.com> References: <20040130104151.3585ef97.simon@arrowtheory.com> <7A7DD912-52B5-11D8-8870-000A95686CD8@redivi.com> Message-ID: <20040130110855.65b24c35.simon@arrowtheory.com> On Thu, 29 Jan 2004 18:47:20 -0500 Bob Ippolito wrote: > First off: never, ever, do -undefined suppress. Its use is only > applicable to OS X 10.0 -> 10.1, later versions of OS X have better > mechanisms for dealing with this. > > Chances are, either the symbol is static (not exported), or it's > external to libsndfile. You can run nm on libsndfile.dylib (or .a, > whatever it is) and see if it's actually defined. If it's not defined, > it's probably in one of the frameworks or dylibs it links to, you can > check that with otool -L libsndfile.dylib. On OS X, you need to > directly link to anything that you use symbols from. > > If you still have trouble, point me to libsndfile and I will take a > look at it. > > -bob > > BTW: the best mailing list for this sort of inquiry is pythonmac-sig > Yep, thats it. The library was a slightly older version. "select is not broken!" Thanks, Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com From sylpheed-jp-admin at good-day.net Thu Jan 29 19:33:31 2004 From: sylpheed-jp-admin at good-day.net (sylpheed-jp-admin@good-day.net) Date: Thu Jan 29 19:33:37 2004 Subject: [Distutils] You distutils-sig@python.org are not member (sylpheed-jp ML) References: <20040130003331.08D363A6334@sloth.good-day.net> Message-ID: <200401300933.FMLAAB21364.sylpheed-jp@good-day.net> ?????????????? ????????????? ??????????????????????????? guide ???????? sylpheed-jp-ctl@good-day.net ????????????? From owner-mutt-dev at mutt.org Thu Jan 29 19:58:53 2004 From: owner-mutt-dev at mutt.org (owner-mutt-dev@mutt.org) Date: Thu Jan 29 19:58:58 2004 Subject: [Distutils] mutt-dev@mutt.org: Non-member submission from distutils-sig@python.org Message-ID: <20040130005853.9521.qmail@agent57.gbnet.net> Your submission to the list has been forwarded to the list owner for approval because you do not seem to be on that list. If you want to join the list, send email to , with "subscribe mutt-dev" in the message text (not the subject). From virus.manager at st.com Fri Jan 30 04:49:41 2004 From: virus.manager at st.com (virus.manager@st.com) Date: Fri Jan 30 04:50:49 2004 Subject: [Distutils] Virus Alert Message-ID: <20040130094941.ED132F3B5@zeta.dmz-eu.st.com> The mail message (file: text.zip) you sent to contains a virus. (on zeta) From xml-bindings-admin at gnome.org Fri Jan 30 10:47:17 2004 From: xml-bindings-admin at gnome.org (xml-bindings-admin@gnome.org) Date: Fri Jan 30 10:56:58 2004 Subject: [Distutils] Your message to xml-bindings awaits moderator approval Message-ID: <20040130154717.30982.9277.Mailman@moniker.gnome.org> Your mail to 'xml-bindings' with the subject ERROR Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. From nobody at netapp.com Fri Jan 30 17:41:41 2004 From: nobody at netapp.com (Auto-Reply Daemon for maryh) Date: Fri Jan 30 17:41:49 2004 Subject: [Distutils] Your mail to maryh@netapp.com Message-ID: <200401302241.i0UMffc5017761@caesar.europe.netapp.com> This is either an invalid user name or the person you have sent mail to, 'maryh', is no longer employed with Network Appliance. Please take a moment to check your mailing list and update if necessary. Regrettably, we have no forwarding information for 'maryh'. Your message has NOT been forwarded. Please update your records and try again. Please Contact HELPDESK at X6466 for any inquiries. Thank you, IT Department [the body of your message is below] >From distutils-sig@python.org Fri Jan 30 14:41:37 2004 >Received: from psmtp.com (caesar [10.64.2.67]) > by caesar.europe.netapp.com (8.12.9/8.12.9/NTAP-1.5) with SMTP id i0UMfaKG017752 > for ; Fri, 30 Jan 2004 14:41:36 -0800 (PST) >Received: from source ([10.64.46.6]) by caesar ([10.64.2.67]) with SMTP; > Fri, 30 Jan 2004 14:41:36 PST >Received: from python.org (lns-th2-13-82-64-76-127.adsl.proxad.net [82.64.76.127]) > by mx03.netapp.com (8.12.10/8.12.10/NTAP-1.5) with ESMTP id i0UMfU7i029090 > for ; Fri, 30 Jan 2004 14:41:31 -0800 (PST) >Message-Id: <200401302241.i0UMfU7i029090@mx03.netapp.com> >From: distutils-sig@python.org >To: mary@netapp.com >Subject: SPAM: test >Date: Fri, 30 Jan 2004 23:41:25 +0100 >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_0014_FACD4707.AF086ECF" >X-Priority: 3 >X-MSMail-Priority: Normal >X-pstn-levels: (C:80.0762 M:99.4056 P:95.9108 R:95.9108 S: 7.2366 ) >X-pstn-settings: 3 (1.0000:1.0000) pmCr >X-pstn-addresses: from > >This is a multi-part message in MIME format. > >------=_NextPart_000_0014_FACD4707.AF086ECF >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >------------------ Virus Warning Message (on caesar) > >Found virus WORM_MYDOOM.A in file doc.exe (in doc.zip) >The file is deleted. > >If you have questions, please contact helpdesk@netapp.com. > >--------------------------------------------------------- > >------=_NextPart_000_0014_FACD4707.AF086ECF >Content-Type: text/plain; > charset="Windows-1252" >Content-Transfer-Encoding: 7bit > >The message contains Unicode characters and has been sent as a binary attachment. > > >------=_NextPart_000_0014_FACD4707.AF086ECF >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > > >------------------ Virus Warning Message (on caesar) > >doc.zip is removed from here because it contains a virus. > >--------------------------------------------------------- >------=_NextPart_000_0014_FACD4707.AF086ECF-- > > From postmaster at panoramix.ift.uni.wroc.pl Sat Jan 31 10:45:55 2004 From: postmaster at panoramix.ift.uni.wroc.pl (postmaster@panoramix.ift.uni.wroc.pl) Date: Sat Jan 31 09:42:25 2004 Subject: [Distutils] VIRUS IN YOUR MAIL Message-ID: <20040131154555.0CBBE2001@panoramix.ift.uni.wroc.pl> V I R U S A L E R T Our viruschecker found the 'W32/MyDoom-A' virus in your email to the following recipient: -> george@panoramix.ift.uni.wroc.pl Delivery of the email was stopped! Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the SMTP envelope originator and headers from your email: >From distutils-sig@python.org ------------------------- BEGIN HEADERS ----------------------------- Received: from python.org (82-35-43-90.cable.ubr02.camd.blueyonder.co.uk [82.35.43.90]) by panoramix.ift.uni.wroc.pl (Postfix) with ESMTP id 18B4E16FF for ; Sat, 31 Jan 2004 15:45:48 +0000 (WET) From: distutils-sig@python.org To: george@panoramix.ift.uni.wroc.pl Subject: Hello Date: Sat, 31 Jan 2004 14:42:01 +0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_2E75EDA7.DE95A0BC" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20040131154548.18B4E16FF@panoramix.ift.uni.wroc.pl> -------------------------- END HEADERS ------------------------------ From krjackson at lbl.gov Sat Jan 31 16:59:52 2004 From: krjackson at lbl.gov (Keith Jackson) Date: Sat Jan 31 16:59:45 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: References: <20040129111536.30B4B25AE97@bonanza.off.ekorp.com> Message-ID: On Jan 29, 2004, at 3:26 AM, Bob Ippolito wrote: > On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote: > >> >>>>> "Moore, Paul" wrote >>> From: Michael T. Babcock >>>> Would it be worthwhile to stipulate that anyone who wants to submit >>>> a >>>> package to an automated distutils system have a PGP/GPG key signed >>>> by >>>> an appropriate Python authority or another developper? I'm not a lawyer, but this makes me uncomfortable. Seems to bring up a whole can of liability worms. >> >>> -1. The effect would be to bar new submitters, who wouldn't have the >>> necessary signed key, as well as to people like myself who can't be >>> bothered trying to maintain a PGP key. >> >> It should be at least an option, anyway. > > Isn't most of the stuff used to support GPG under the GNU GPL license? > I think that would preclude it from being incorporated into the > mainline of distutils. > Yes, but I don't think that prevents distutils from running a shell command to invoke gpg. I'd really like to see this as an option. As soon as people start putting more things up in a repository, the more likely it will become that someone tries to trojan things. I'd also like to see M2Crypto or pyOpenSSL support for S/MIME sigs. Personally I'd be willing to settle for a separate machine that maintained the sha1 hashes of all the code. At least then you'd have to crack two machines to trojan software. distutils could have built in support for getting the sha1 hash and verifying it. I'm much more concerned with the code integrity then authenticating who wrote it. This is open-source, so I'm not going to have any legal options against someone who wrote bad code. What I am concerned about is minimizing the likelihood that someone can trojan a distutils repository. Given how frequently this has happened to other sites, it seems like a reasonable concern. > Personally, I don't think it would be a popular enough feature to > justify the changes. For the people who do care, a "meta-index" could > be created where the developer could, email a pgp-signed or s/mime > signed message containing the URLs and sha1 hashes of the files to > some robot-address that would insert it into the "meta-index" if the > credentials were ok. > Yes, but of course this begs the age old key distribution problem. I'm all in favor of some kind of optional support for PGP or S/MIME signatures, I exist in an X.509 world, so I could take advantage of it for my own work. That said, I think that code integrity in the repository is a much bigger issue that authenticating who put the code into the repository. (yes i do understand that the sig will also handle integrity, but it is probably overkill) All a sha1 hash would say is that: The distutils repository only contains the code that was legitimately submitted. That doesn't mean someone didn't submit a trojan, but it does mean that for major projects like wxPython that if the hash verifies then most likely things are ok. Sorry for the long post, but I think if we're going to do a python repository, we should be concerned about the integrity of the repository. --keith p.s. How does CPAN deal with these issues? From bob at redivi.com Sat Jan 31 17:34:28 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 31 17:31:43 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: References: <20040129111536.30B4B25AE97@bonanza.off.ekorp.com> Message-ID: On Jan 31, 2004, at 4:59 PM, Keith Jackson wrote: > On Jan 29, 2004, at 3:26 AM, Bob Ippolito wrote: > >> On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote: >> >>> >>>>>> "Moore, Paul" wrote >>>> From: Michael T. Babcock >>>>> Would it be worthwhile to stipulate that anyone who wants to >>>>> submit a >>>>> package to an automated distutils system have a PGP/GPG key signed >>>>> by >>>>> an appropriate Python authority or another developper? > > I'm not a lawyer, but this makes me uncomfortable. Seems to bring up a > whole can of liability worms. > >>> >>>> -1. The effect would be to bar new submitters, who wouldn't have the >>>> necessary signed key, as well as to people like myself who can't be >>>> bothered trying to maintain a PGP key. >>> >>> It should be at least an option, anyway. >> >> Isn't most of the stuff used to support GPG under the GNU GPL >> license? I think that would preclude it from being incorporated into >> the mainline of distutils. >> > > Yes, but I don't think that prevents distutils from running a shell > command to invoke gpg. I'd really like to see this as an option. As > soon as people start putting more things up in a repository, the more > likely it will become that someone tries to trojan things. I'd also > like to see M2Crypto or pyOpenSSL support for S/MIME sigs. Well, right now there is no repository, PyPI links to the author's page. There are repositories for Mac ports, though, but we're not terribly worried at the moment (I maintain one of them, python.org has the other maintained by Jack). The package index has MD5 hashes and URLs to tarballs (that can be anywhere). Obviously you have to trust me or Jack, and the integrity of our servers, but I don't think that's a huge problem right now. I do have a CA-signed SSL cert for pythonmac.org and I could put a package index there.. so you could verify that there wasn't some sort of spoof or man in the middle attack, but it just hasn't been worth doing so far. > Personally I'd be willing to settle for a separate machine that > maintained the sha1 hashes of all the code. At least then you'd have > to crack two machines to trojan software. distutils could have built > in support for getting the sha1 hash and verifying it. I'm much more > concerned with the code integrity then authenticating who wrote it. > This is open-source, so I'm not going to have any legal options > against someone who wrote bad code. > > What I am concerned about is minimizing the likelihood that someone > can trojan a distutils repository. Given how frequently this has > happened to other sites, it seems like a reasonable concern. > >> Personally, I don't think it would be a popular enough feature to >> justify the changes. For the people who do care, a "meta-index" >> could be created where the developer could, email a pgp-signed or >> s/mime signed message containing the URLs and sha1 hashes of the >> files to some robot-address that would insert it into the >> "meta-index" if the credentials were ok. > > Yes, but of course this begs the age old key distribution problem. So does anything else? > I'm all in favor of some kind of optional support for PGP or S/MIME > signatures, I exist in an X.509 world, so I could take advantage of it > for my own work. That said, I think that code integrity in the > repository is a much bigger issue that authenticating who put the code > into the repository. (yes i do understand that the sig will also > handle integrity, but it is probably overkill) > > All a sha1 hash would say is that: The distutils repository only > contains the code that was legitimately submitted. That doesn't mean > someone didn't submit a trojan, but it does mean that for major > projects like wxPython that if the hash verifies then most likely > things are ok. md5 and sha1 hashes are fine, Python comes with those.. but crypto isn't really an option because there are people who are concerned about the associated export/import laws that will not let it go into mainline Python (I tried). > Sorry for the long post, but I think if we're going to do a python > repository, we should be concerned about the integrity of the > repository. > --keith > > p.s. How does CPAN deal with these issues? They don't, and I haven't really heard of any problems. From what I understand, the author uploads a package to PAUSE (w/ a login/password, probably not even over SSL), and it gets replicated throughout CPAN in a few hours. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040131/7f71727a/smime.bin