Hoping I might have better luck with Python-3.1.3, I tried it instead and got a little farther...

The make gave me this same warning:

Python build finished, but the necessary bits to build these modules were not found:
_curses _curses_panel _dbm
_gdbm _hashlib _sqlite3
_ssl _tkinter bz2
readline zlib
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
. . .

So, I checked setup.py but couldn't really figure anything out from that code (still need to learn Python), so ignored this message for now in hopes that I don't need these things yet and went ahead with the final make install step. Part way through, I started to get the same sort of error in the Python 3.1.3 version, but it seemed to recover from it better:

PYTHONPATH=/usr/local/lib/python3.1 \
./python -Wi /usr/local/lib/python3.1/compileall.py \
-d /usr/local/lib/python3.1 -f \
-x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
/usr/local/lib/python3.1
Traceback (most recent call last):
File "/usr/local/lib/python3.1/compileall.py", line 17, in <module>
import struct
File "/usr/local/lib/python3.1/struct.py", line 12, in <module>
from _struct import *
ImportError: No module named _struct
make: [libinstall] Error 1 (ignored)
PYTHONPATH=/usr/local/lib/python3.1 \
./python -Wi -O /usr/local/lib/python3.1/compileall.py \
-d /usr/local/lib/python3.1 -f \
-x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
/usr/local/lib/python3.1
Traceback (most recent call last):
File "/usr/local/lib/python3.1/compileall.py", line 17, in <module>
import struct
File "/usr/local/lib/python3.1/struct.py", line 12, in <module>
from _struct import *
ImportError: No module named _struct
make: [libinstall] Error 1 (ignored)
PYTHONPATH=/usr/local/lib/python3.1 \
./python -Wi /usr/local/lib/python3.1/compileall.py \
-d /usr/local/lib/python3.1/site-packages -f \
-x badsyntax /usr/local/lib/python3.1/site-packages
Traceback (most recent call last):
File "/usr/local/lib/python3.1/compileall.py", line 17, in <module>
import struct
File "/usr/local/lib/python3.1/struct.py", line 12, in <module>
from _struct import *
ImportError: No module named _struct
make: [libinstall] Error 1 (ignored)
PYTHONPATH=/usr/local/lib/python3.1 \
./python -Wi -O /usr/local/lib/python3.1/compileall.py \
-d /usr/local/lib/python3.1/site-packages -f \
-x badsyntax /usr/local/lib/python3.1/site-packages
Traceback (most recent call last):
File "/usr/local/lib/python3.1/compileall.py", line 17, in <module>
import struct
File "/usr/local/lib/python3.1/struct.py", line 12, in <module>
from _struct import *
ImportError: No module named _struct
make: [libinstall] Error 1 (ignored)
PYTHONPATH=/usr/local/lib/python3.1 \
./python -Wi -c "import lib2to3.pygram, lib2to3.patcomp;lib2to3.patcomp.PatternCompiler()"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/local/lib/python3.1/lib2to3/pygram.py", line 11, in <module>
from .pgen2 import driver
File "/usr/local/lib/python3.1/lib2to3/pgen2/driver.py", line 21, in <module>
import logging
File "/usr/local/lib/python3.1/logging/__init__.py", line 26, in <module>
import sys, os, time, io, traceback, warnings
ImportError: No module named time
make: [libinstall] Error 1 (ignored)
Creating directory /usr/local/include/python3.1
/usr/bin/install -c -m 644 ./Include/abstract.h /usr/local/include/python3.1
/usr/bin/install -c -m 644 ./Include/asdl.h /usr/local/include/python3.1
. . . (etc.) . .
changing mode of /usr/local/lib/python3.1/lib-dynload/ to 755
running install_scripts
copying build/scripts-3.1/2to3 -> /usr/local/bin
copying build/scripts-3.1/pydoc3 -> /usr/local/bin
copying build/scripts-3.1/idle3 -> /usr/local/bin
changing mode of /usr/local/bin/2to3 to 755
changing mode of /usr/local/bin/pydoc3 to 755
changing mode of /usr/local/bin/idle3 to 755
running install_egg_info
Writing /usr/local/lib/python3.1/lib-dynload/Python-3.1.3-py3.1.egg-info
/usr/bin/install -c -m 644 ./Misc/python.man \
/usr/local/share/man/man1/python3.1.1
if test -f /usr/local/bin/python3 -o -h /usr/local/bin/python3; \
then rm -f /usr/local/bin/python3; \
else true; \
fi
(cd /usr/local/bin; ln python3.1 python3)
rm -f /usr/local/bin/python3-config
(cd /usr/local/bin; ln -s python3.1-config python3-config)
rm -f /usr/local/lib/pkgconfig/python3.pc
(cd /usr/local/lib/pkgconfig; ln -s python-3.1.pc python3.pc)
[root@skye Python-3.1.3]#

. . . so then I crossed my fingers and tried yum again, finally getting different results (so I am not crazy after all?):

[root@skye Python-3.1.3]# yum info
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
File "/usr/lib64/python2.7/encodings/utf_8.py", line 9, in <module>
Aborted (core dumped)

. . . I then spotted the "2.7" in the error, which is actually not even the "2.7.1" version that I installed previously. So this means that Python is hardcoding the config somewhere. I decided to look for PYTHONHOME environment variable, and sure enough:

[root@skye Python-3.1.3]# env|grep PY
PYTHONOPTIMIZE=true
PYTHONHOME=/usr/lib64/python2.7
PYTHONPATH=/usr/lib64/python2.7

. . . So I am getting closer anyway.

It turns out that there is an ongoing problem with configuring Python on 64 bit systems as well which may have something to do with all of this. Check here:

http://bugs.python.org/issue858809

Also, I should mention that someone else had suggested I try this:

rpm -Uvh --force http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm --nodeps

... and while it did seem to successfully reinstall Python 2.7, yum is still exhibiting the same error.

At this point, I have the following three different versions of Python:

2.7
2.7.1
3.1.3

I had started to experiment with each by setting a symbolic link on /usr/bin/python to point to the actual python (as well as setting PYTHONHOME and PYTHONPATH in my /etc/profile as I might point to different Java versions), but this doesn't appear to be working.

After running the above rpm, things seem to have reset themselves to 2.7 (and I commented out my PYTHONHOME and PYTHONPATH), but still no luck.

Maybe time to reboot...?

Err, maybe time to redo your system if you have to go through this much trouble..... I need to ask though. How the hell did you mess your system up that bad? I'm sorry, but standard Fedora Updates would never do this. I used Fedora for a very long time....

I have a couple options for you. The python rpm packages are on the DVD under the Packages directory. If you run into the issue that a package is already installed you can use the --replacepkgs option in rpm. You can also download rpms from http://download.fedoraproject.org, which will direct you to a mirror. Then follow the path to your fedora release and eventually to the Packages directory where you can download whatever is needed.

If you are set on building python from source I would use the source rpm's and rpmbuild. Building from source rpm's will create an rpm on your system that you can install. By installing rpm's you will keep your rpm database intact for future updates. The source rpm's are available at the same site mentioned above. Look under source/SRPMS to find your packages. I think it is actually a good exercise to learn how rpm's are built.

Last option of course is to do a reinstall. As someone mentioned you may have more going on here than a busted Python package. It might be wise in the long run to save your data and reinstall. Might even upgrade to F14 while you are at it.

Thanks for the rpm tips (etc.). Like I said, I am already running F14, and I think I have managed to reinstall the Python 2.7 package which was part of the original distribution (not to mention cpp and gcc). It (yum) still doesn't work however, but I also have yet to reboot since the Python 2.7 reinstall (I'm hoping this helps anyway, but I won't know until I get home later).

I mentioned that I am not real sure I want to risk a full system reinstall at this point because I have a fair amount of time invested in this machine already (bookmarks, packages, workspaces, etc.). It is also a dual boot system and multiple people are also using the Windows image on the other boot, so losing that would really cause problems.

I actually don't know what might have caused this problem. I sort of doubt that the Fedora updates caused it - or I would hate to think they did anyway, as I too am a long time Fedora fan. I just recall doing the updates on Saturday - which were the second of two groups of very recent automatic updates - and then the 2nd group required a reboot. It was after the reboot that I noticed the issue, but to be honest, the issue could have been there for a while because it's probably been a while since I have attempted to run yum from the command line like that.

There is also one other suspect in this case however. I was looking for an alternative to the Nautilus file browser on Saturday and also ended up downloading something called XnView ( http://www.xnview.com ). Now I'm not assigning any blame here - chances are this is a perfectly fine application. I tried to install the 64 bit version of this package however, and recalled wondering why it seemed so non-standard looking. The install also didn't seem to work - it just sort of hung. At some point during the installation - while it was apparently hung - I sort of panicked and in a fit of paranoia I bailed out of the install by killing the install process. I then removed all traces of this application from my system (the symlink in /usr/local, together with the package directory), and rebooted again, for the 2nd time that day. It was later, at some point after having rebooted this 2nd time that I noticed that my yum package was broken, and also my cpp/gcc tools were missing. Chances are, my problem has more to do with the fact that I killed the XnView install process than anything else - probably corrupted something in the process - who knows?

Dav0, My apologies, I replied to your post not realizing the thread went to more than one page. After rereading the entire thread I see some things that could create more issues for you.

When distributions, such as F14, are built they are designed with specific packages in mind, this includes updates. By installing python-3.1.3 you went outside the packages that are meant to be on this distribution. I also noticed that you installed packages meant for fc13 (this is why I thought you were on Fedora 13) and even fc15. Another thing I want to advise against is using --force with rpm. My experience with rpm goes back to Red Hat Linux 4.2 (August 1997) when all we had for package maintenance was rpm. I did a number on glibc that made the system unusable and required a great deal of time and learning on my part to bring it back to life.

It looks like you are on your way to getting things working again with the reinstall of python-2.7 . Once yum is working I would suggest running the command yum distro-sync. This will get your system back in sync with the latest packages for F14. It is different from update in that it will also downgrade packages when appropriate.

I'll keep watching the thread if you run into something else. I'm sure others will too.

Still pondering this one... the reboot didn't help (didn't think it would).

I had the idea that uninstalling and then reinstalling python might help. The reason being, that my python config seems so wacked out after all of the torture I've been putting it through.

[root@skye lib64]# rpm -e --nodeps python
[root@skye lib64]# rpm -Uvh http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm
Retrieving http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm
Retrieving http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm
Preparing... ########################################### [100%]
package python-libs-2.7-8.fc14.3.x86_64 is already installed
[root@skye lib64]# rpm -Uvh --force http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm --nodeps
Retrieving http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm
Retrieving http://kojipkgs.fedoraproject.org/pa...4.3.x86_64.rpm
Preparing... ########################################### [100%]
1ython-libs ########################################### [ 50%]
2ython ########################################### [100%]
[root@skye lib64]# rpm -q *|grep python
package libpyglib-2.0-python.so is not installed
package libpyglib-2.0-python.so.0 is not installed
package libpyglib-2.0-python.so.0.0.0 is not installed
package libpython2.7.so.1.0 is not installed
package python2.7 is not installed
[root@skye lib64]# yum info
Traceback (most recent call last):
File "/usr/lib64/python2.7/site.py", line 553, in <module>
main()
File "/usr/lib64/python2.7/site.py", line 535, in main
known_paths = addusersitepackages(known_paths)
File "/usr/lib64/python2.7/site.py", line 264, in addusersitepackages
user_site = getusersitepackages()
File "/usr/lib64/python2.7/site.py", line 239, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
File "/usr/lib64/python2.7/site.py", line 229, in getuserbase
USER_BASE = get_config_var('userbase')
File "/usr/lib64/python2.7/sysconfig.py", line 518, in get_config_var
return get_config_vars().get(name)
File "/usr/lib64/python2.7/sysconfig.py", line 421, in get_config_vars
_init_posix(_CONFIG_VARS)
File "/usr/lib64/python2.7/sysconfig.py", line 275, in _init_posix
raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/lib64/python2.7/lib64/python2.7/config/Makefile (No such file or directory)

[root@skye lib64]# cd python2.7/
[root@skye python2.7]# pwd
/usr/lib64/python2.7
[root@skye python2.7]# find . -name Makefile -print
./config/Makefile

-- ugh ---

I think I am giving up on this Linux install after all. Reading more on this, I am learning that Python is apparently much less forgiving than I would have ever imagined an interpreted language could possibly be - especially when it comes to installing multiple versions of the language on the same system.

Coming from the Java world, I am used to installing three or four different versions of the JDK and pointing to whichever one I feel like running with on a given day by simply pointing the JAVA_HOME variable, but not so with Python. I probably broke this system for good while trying to fix it the other day when I installed Python 3-1-3 over 2.7.

I now realize that I probably could have survived installing multiple versions of Python on the same box if I had known to carefully read the README and use the --prefix switch and make altinstall, but I also can't believe that such a dangerous operation isn't protected against a little better. Especially something which can apparently break the entire system.

I think you're actually closer than you think. Looking at post #22 I find this part odd...

Notice how the lib64/python2.7 is in the path twice. The python environment variables (PYTHONHOME or PYTHONPATH) are not set in my installation, they default. Are these still in your /etc/profile or did you remove them?

Could you also post the result of rpm -qa | grep python. Lastly, what happens when you type python at the command line?

I had tried to override the existing definitions of PYTHONHOME and PYTHONPATH in my /etc/profile, but later commented them out again when I discovered that defining them there seemed to have no effect. So, to answer your question on these two variables, no - I do not have them defined anywhere, but they are being defined somehow somewhere to point to the python2.7 install (in a Makefile most likely).

I too noticed the odd directory structure that yum (via Python) seems to be trying to reference in the error message. I think this problem is all related to some ongoing issues with Python configuration on 64 bit systems (AMD64 in particular, as this is an HP box with an AMD64 chip on it). See this topic for more details:

http://bytes.com/topic/python/answer...rhel4-x86_64-a

There would seem to be a whole host of Python bugs which have been being kicked around for years on this subject, and at least one of which (6060) is marked "won't fix":

Various related problem descriptions:
http://bugs.python.org/issue858809
http://bugs.python.org/issue1019715
http://bugs.python.org/issue6060
http://bugs.python.org/issue1294959#msg94941
http://bugs.python.org/issue1294959#msg94986

Of course, there is some hope for a solution to these problems, but I am not yet sure how hopeful they are:

http://mail.python.org/pipermail/pyt...il/072653.html
https://bitbucket.org/tarek/distutil...esign/wiki.rst
http://wiki.debian.org/ReleaseGoals/MultiArch
https://wiki.ubuntu.com/MultiarchSpec

In any case, I will likely take another look at this mess when I get home from work tonight.

Thanks for the support!

As a quick fix you could fool it by creating a symbolic link back to itself.

Not the ultimate solution, but it should find the Makefile and might even get python up and running again.

I've been able to get a little closer by hacking such as this, but then I get a missing pyconfig-64.h file:

[root@skye bin]# cd /usr/lib64/python2.7
[root@skye python2.7]# mkdir lib64
[root@skye python2.7]# cd lib64
[root@skye lib64]# ln -s /usr/lib64/python2.7 python2.7
[root@skye lib64]# yum info
Traceback (most recent call last):
File "/usr/lib64/python2.7/site.py", line 553, in <module>
main()
File "/usr/lib64/python2.7/site.py", line 535, in main
known_paths = addusersitepackages(known_paths)
File "/usr/lib64/python2.7/site.py", line 264, in addusersitepackages
user_site = getusersitepackages()
File "/usr/lib64/python2.7/site.py", line 239, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
File "/usr/lib64/python2.7/site.py", line 229, in getuserbase
USER_BASE = get_config_var('userbase')
File "/usr/lib64/python2.7/sysconfig.py", line 518, in get_config_var
return get_config_vars().get(name)
File "/usr/lib64/python2.7/sysconfig.py", line 421, in get_config_vars
_init_posix(_CONFIG_VARS)
File "/usr/lib64/python2.7/sysconfig.py", line 285, in _init_posix
raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/lib64/python2.7/include/python2.7/pyconfig-64.h (No such file or directory)


I'm apparently not alone on this error - see https://bugzilla.redhat.com/show_bug.cgi?id=620354 - which has since been marked as a duplicate of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=620274

I'm not real sure what to do with this information. Does this mean I need to cut a new DVD and reinstall - or is there an easier and less risky way to fix this?

Thanks

Does anyone have an AMD64 pyconfig-64.h file I can borrow?

Wow, this is wacky. That file should be in /usr/include/python2.7/pyconfig-64.h. You can extract it from the rpm using
Just be aware that it will put the entire path in whatever directory you execute that command from.

Getting closer... looks like I just need to reinstall yum now maybe?

[root@skye python2.7]# pwd
/usr/lib64/python2.7
[root@skye python2.7]# mkdir include
[root@skye python2.7]# cd include
[root@skye include]# mkdir python2.7
[root@skye include]# cp /opt/kits/langs/Python/pyconfig-64.h python2.7
[root@skye include]# yum info
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

No module named yum

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7 (r27:82500, Sep 27 2010, 17:57:21)
[GCC 4.5.1 20100924 (Red Hat 4.5.1-4)]

If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq