On 04 September 2000, M.-A. Lemburg said:
error: can't copy 'pkg': doesn't exist or not a regular file
and immediate termination of the setup script (hey, it's an error, not a warning). I'll admit that's not as useful as it could be, but as long as there's no traceback it's not a bug! ;-)
You're right; it's not an exception, but still something which causes distutils to stop ;-)
It is fixable, I was just making sure that you and I were seeing the same problem -- "that's not a bug, it's a misfeature". Another thing I discovered this morning is that if MANIFEST is empty, then you *do* get an exception -- definitely a bug. So at least a "! empty" check of the file list is required before trying to copy files and create the tarball; might as well throw in a "isfile or warn" check on everything at the same time.
Would it hurt much adding a "continue" somewhere to remedy this minor "caveat" :-)
Well, it'll print a warning that "foo is not a regular file (skipped)". Not nice to silently skip things!
That could have been the cause. While testing this I stumbled over another bugglet:
Executing: %build + umask 022 + cd /data/home/lemburg/projects/tmp/build/bdist.linux2/rpm/BUILD + cd mx-Extensions-BASE-1.0.0 + env 'CFLAGS=-O2 -m486 -fno-strength-reduce' python setup.py build Traceback (innermost last): File "setup.py", line 7, in ? from distutils.core import setup, Extension File "/home/lemburg/lib/distutils/core.py", line 146 raise ^ SyntaxError: invalid syntax
This is due to RPM finding a Python 1.5 version under the simple name "python".... distutils doesn't seem to be compatible with multiple installed Python versions :-( [I did run the setup.py file using Python 2.0].
Yup, there's another thread about this very issue going on at this very moment. Everyone who has spoken up (me, AMK, and Harry Gebel) thinks that it should at least be an option to put the value of sys.executable in the spec file, instead of hard-coding "python". I think you've raised another good argument in favour of making this the default, but I'm biased -- I do think it should be the default. ;-)
I then tried:
projects/tmp> python2.0 setup.py bdist_rpm --prep-script ./prep-script invalid command name './prep-script'
Looks like somethings wrong there: I can't seem to pass a script filename to the command.
The RPM script options are, ummm, not well-thought-out. Possibly unfinished, I'm not sure. Those are the options I was thinking of when I said it might have been unwise to attempt to mirror *all* of RPM's spec file in Distutils options. My inclination is to delete them, rather than expose a broken interface.
OK, after that hack the RPM compile runs through, but it now finishes with the following lines (and no apparent reason):
creating /var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/mx/Tools creating /var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/mx/Tools/mxTools copying build/lib.linux2/mx/Tools/mxTools/mxTools.so -> /var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/mx/Tools/mxTools byte-compiling /var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/mx/__init__.py to __init__.pyc writing list of installed files to 'INSTALLED_FILES' warning: install: modules installed to '/var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself + exit 0 Processing files: mx-Extensions-BASE File listed twice: /usr/local/lib/python2.0/site-packages/mx/Tools/mxTools/mxTools.so Finding provides... Finding requires... Provides: mxDateTime.so mxProxy.so mxQueue.so mxStack.so mxTextTools.so mxTools.so Requires: ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) error: command 'rpm' failed with exit status 1
??? I'm confused again. Try running "bdist_rpm" with the --source-only option, and then see if you can build from the source RPM directly. About the only way to debug these sort of problems is to break the thing down, and a *heck* of a lot of stuff happens between you typing "setup.py bdist_rpm" and the finished RPM files being moved into dist/. (Just listen to your hard drive go!)
* does /data/home/lemburg/projects/tmp/build/bdist.linux2/rpm/RPMS/i386 exist?
No.
* if you create it, does the bdist_rpm command then run successfully?
Yes.
OK, based on that and Andrew's feedback, I'd say we blame RPM 3.0.3. Bottom line: building RPMs with the Distutils requires RPM 3.0.4 or better. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/