
Hi, I get the following traceback with bdist_rpm command: calvin@treasure:/~/projects/linkchecker> python setup.py bdist_rpm SSL header file ssl.h found, enabling SSL compilation. running bdist_rpm Traceback (innermost last): File "setup.py", line 116, in ? data_files = [('share/locale/de/LC_MESSAGES', File "/usr/lib/python1.5/site-packages/distutils/core.py", line 111, in setup dist.run_commands () File "setup.py", line 47, in run_commands self.run_command (cmd) File "/usr/lib/python1.5/site-packages/distutils/dist.py", line 787, in run_command cmd_obj.ensure_finalized () File "/usr/lib/python1.5/site-packages/distutils/cmd.py", line 95, in ensure_finalized self.finalize_options () File "/usr/lib/python1.5/site-packages/distutils/command/bdist_rpm.py", line 168, in finalize_options self.finalize_package_data() File "/usr/lib/python1.5/site-packages/distutils/command/bdist_rpm.py", line 191, in finalize_package_data self.changelog = self._format_changelog(self.changelog) File "/usr/lib/python1.5/site-packages/distutils/command/bdist_rpm.py", line 440, in _format_changelog for line in string.split(string.strip(changelog), '\n'): TypeError: read-only character buffer, None calvin@treasure:/~/projects/linkchecker> Reason is that the Command.ensure_string() function has default=None and so self.changelog is None and not "". Bastian

On Thu, Jun 08, 2000 at 10:25:14AM +0200, Bastian Kleineidam wrote:
Reason is that the Command.ensure_string() function has default=None and so self.changelog is None and not "".
Okay, None is the correct, so I altered _format_changelog() so that if it gets a false value it echos it back. -- Harry Henry Gebel, Senior Developer, Landon House SBS ICQ# 76308382 West Dover Hundred, Delaware

On 08 June 2000, Harry Henry Gebel said:
Okay, None is the correct, so I altered _format_changelog() so that if it gets a false value it echos it back.
Thanks, checked it in. Greg -- Greg Ward - Linux weenie gward@python.net http://starship.python.net/~gward/ The enemy of my enemy is my friend... unless of course we are talking about Microsoft and Sun.

Hi, when I tried to build a binary distribution I found that there were no headers in it. (But a normal install worked.) Also I found bdist_rpm didn't work with headers and data files. There were two problems: Someone simply forgot the headers in the install command.

On Thu, 8 Jun 2000, Rene Liebscher wrote:
PS: I send the last version of my cygwin-compiler class with this mail. If someone wants to try it, simply copy it in the commands directory. (The compiler mapping is already inserted in the current cvs version.)
Great work, but one small nit: you use try/except in two places there. The first just catch ValueError's, and the second can catch (IOError, os.error), though I'm not sure what for: if there are problems reading config.h, it seems we're in a pretty mess: pretending everything is alright won't make it so <wink> -- Moshe Zadka <moshez@math.huji.ac.il> http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com

Moshe Zadka wrote:
Great work, but one small nit: you use try/except in two places there. The first just catch ValueError's, and the second can catch (IOError, os.error), though I'm not sure what for: if there are problems reading config.h, it seems we're in a pretty mess: pretending everything is alright won't make it so <wink>
If there are problems reading config.h then probably the user deleted it or moved it to another place. In this case the user has the whole responibility for his doing. ( for example he could specify a path to search -I my/new/python/include/directory ) If it was deleted accidently or something similar, then we should let the compiler complain about this missing file. I think we only should print warnings if we are sure that we are right. Without this file we cannot be sure that something is wrong. kind regards Rene Liebscher

On 08 June 2000, Moshe Zadka said:
Great work, but one small nit: you use try/except in two places there. The first just catch ValueError's, and the second can catch (IOError, os.error), though I'm not sure what for: if there are problems reading config.h, it seems we're in a pretty mess: pretending everything is alright won't make it so <wink>
As of a few days ago, the "correct" way to deal with IOError and os.error is to call 'grok_environment_error()'. Eg. from core.py (well, this is how it *should* look...): try: dist.run_commands () except KeyboardInterrupt: raise SystemExit, "interrupted" except EnvironmentError, exc: error = grok_environment_error(exc) if DEBUG: sys.stderr.write(error + "\n") raise else: raise SystemExit, error 'grok_environment_error()' makes the best of a bad situation, ie. the number of inconsistent ways that an IOError or os.error object can exist (sigh). Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ I once decorated my apartment entirely in ten foot salad forks!!

On 08 June 2000, Rene Liebscher said:
when I tried to build a binary distribution I found that there were no headers in it. (But a normal install worked.) Also I found bdist_rpm didn't work with headers and data files.
There were two problems: Someone simply forgot the headers in the install command.
From install_headers and install_data you couldn't get the copied files (outfiles.) (rpm seems to use it.)
Good catch. Thanks!
And here is now a patch which solves both problems.
OK, I've checked in fixes that were "inspired" by your patch. Note that 'copy_file()' returns the name of the output file, so there's no need to override it and generate the filename ourselves; just get the value returned from 'copy_file()' and append to 'outfiles'
Shouldn't header files be installed in /usr/local/python1.5/include instead of /usr/local/python/1.5/include ?
Already fixed, thanks.
Another problem is that MANIFEST is build from two sources.
MANIFEST.in > MANIFEST parameters of setup()
If someone changes the parameter of setup() the MANIFEST file should be rebuild.
Duh, good point! So-obvious-I-should-have-thought-of-it-myself. Again I checked in a fix strongly inspired by yours. Another note: 'newer()' doesn't mind if the *target* doesn't exist; it just returns true, meaning that the target needs to be regenerated. So the 'isfile()' check on 'manifest' is unneeded.
PS: I send the last version of my cygwin-compiler class with this mail.
OK, I just checked it in, unreviewed and untested. (What the hell.) Now at least others can try it and it'll get in the next code snapshot, whenever I do that. Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ Laziness, Impatience, Hubris.
participants (5)
-
Bastian Kleineidam
-
Greg Ward
-
Harry Henry Gebel
-
Moshe Zadka
-
Rene Liebscher