classification
Title: Problems with /usr/lib64 builds.
Type: behavior Stage:
Components: Build Versions: Python 3.3, Python 3.2, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, akitada, andybuckley, barry, belopolsky, catalin.iacob, christian.heimes, doko, eric.araujo, ivazquez, jafo, jcea, lemburg, matejcik, pitrou, tarek
Priority: normal Keywords: patch

Created on 2005-09-19 03:05 by jafo, last changed 2013-11-07 17:55 by barry.

Files
File name Uploaded Description Edit
python-2.3.4-lib64-regex.patch jafo, 2005-09-19 03:05 One of the Fedora patches.
python-2.4.1-lib64.patch jafo, 2005-09-19 03:06 Another of the Fedora patches.
japanese-codecs-lib64.patch jafo, 2005-09-19 03:06 The third obviously lib64 Fedora patch.
Python-2.6.2-multilib.patch matejcik, 2009-08-14 16:27 SUSE patch for the lib64 issue
Python-3.3.0b2-multilib.patch matejcik, 2013-11-07 15:40 SUSE patch in python3
Repositories containing patches
http://hg.python.org/users/barry#multiarch
Messages (38)
msg26314 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2005-09-19 03:05
This is something that's becoming more and more of a
problem as more people get systems that run both 32-bit
and 64-bit code.  There are patches (926209 858809) in
the tracker to resolve this issue, I don't know exactly
what state they are in.  They seem fairly old, one is
closed and one is still open.

The Fedora RPMs include the following patches for lib64
(attached).

Any thoughts on what we need to do to allow building
lib64 as a part of the standard release?  Or do we just
want to wait for these terrible transition days to end
and rely on 32+64 packagers to deal with it?

Here's a short run-down of the situation:  Some systems
can run both 32 and 64 bit software.  On these systems
you *CAN* install a native 64-bit tool-chain, but some
people set up both 32 and 64 bit software on these
systems for compatibility.  You can do 32+64 in a
couple of ways, one is to set up a "chroot" environment
for the secondary (typically 32-bit) set of libraries
and programs.  The other is to run the system with
64-bit libraries in /usr/lib64 and 32-bit in /usr/lib
(because most software that needs compatibility would
be running against /usr/lib, not /usr/lib32).

It's a kludge to be sure, but if you need any legacy
software that you do not have source for, this is a way
of getting 64-bits while still retaining the ability to
run 32-bit  This is not a problem for systems which
only run 64-bit code, nor is it a problem for these
32+64 systems which are running only 64-bit
distributions on them.

Thoughts?
Sean
msg59310 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-05 19:33
The problem with 64 bit builds should be discussed before we release
2.6. Another bug day topic.
msg64592 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-27 14:11
Can someone update the priority so that this is looked at before the 2.6 
release?
msg64593 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-27 14:31
Placing the entire library tree in /usr/lib64 is wasteful on dual 
32/64bit installation, but placing just the C modules there is contrary 
to python import logic and may cause problems to relative imports.

I have suggested what I believed was a workable solution: have 64-bit 
python search lib64-dynload subdirectories instead of lib-dynload.

See http://mail.python.org/pipermail/python-dev/2007-April/072653.html

Currently $(prefix)/pythonX.Y/lib-dynload is inserted in the sys.path, 
but I think it would be better to handle this inside the importer in a 
way similar to how the importer looks for both foo.so and foomodule.so 
when importing foo. This would allow submodules and user modules treated  
the same way.
msg81099 - (view) Author: Akira Kitada (akitada) Date: 2009-02-03 21:23
Similar problem report: http://bugs.python.org/issue1019715
msg82929 - (view) Author: Akira Kitada (akitada) Date: 2009-02-28 17:32
3rd party C modules are put in site-packages,
so just having importer of 64-bit python look at lib64-dynload is not
enough for solving this.

To work around this problem, I did some hacks on my local Python to look
at lib and lib64. It worked, but just as belopolsky said, this is
wasteful and ugly.
msg91559 - (view) Author: jan matejek (matejcik) Date: 2009-08-14 16:27
for completenes, here's a patch that's in use in SUSE. it's advantage
over Fedora's is that it works on both 32bit and 64bit installs
msg91769 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2009-08-20 11:01
both patches assume that everybody uses lib64 for 64bit libs, which is
not true for Debian/Ubuntu. Even the FHS doesn't mandate the use of lib64.
msg91781 - (view) Author: jan matejek (matejcik) Date: 2009-08-20 18:29
well in our patch, at least, the directory is governed by sys.lib which
is defined through configure.
i don't understand the configure language well enough, but i'd assume
that making it parametrized isn't too hard?
msg92541 - (view) Author: Akira Kitada (akitada) Date: 2009-09-12 12:46
I think this is duplicate of issue858809.
msg94941 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2009-11-05 19:23
If I understand correctly, using lib32 or lib64 is a kludge. Debian
and Ubuntu want to come up with a better way to do this:
http://wiki.debian.org/ReleaseGoals/MultiArch
https://wiki.ubuntu.com/MultiarchSpec

Kind regards.
msg94982 - (view) Author: jan matejek (matejcik) Date: 2009-11-06 16:26
thanks for the info; however, it still means that python needs to learn
to live in places other than "/usr/lib"
msg94986 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2009-11-06 17:27
jan matejek wrote:
> 
> jan matejek <jmatejek@suse.cz> added the comment:
> 
> thanks for the info; however, it still means that python needs to learn
> to live in places other than "/usr/lib"

The main problem is that Python's configuration system is not
geared up to having the lib directories for platform dependent
and platform independent parts use different names.

It currently only supports using different path *prefixes* for
such setups (--prefix and --exec-prefix), e.g. /usr and /usr64
would work just fine. It doesn't follow --libdir.

Note that Tarek is currently working on a cleanup of the
installation schemes (see distutils/commands/install.py,
distutils/sysconfig.py and site.py) which will then also
be used by site.py to setup sys.path.

A new modules will unite all these settings, so this should
be the target of any patches regarding installation and
path lookup schemes.

BTW: The "sys.lib" setting mentioned on the tracker is not standard.
The naming also doesn't look right, since the name of the "lib"
directory path component is an OS feature, not a system one that
you configure. os.lib_dir would be more appropriate.
msg94989 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2009-11-06 17:41
Adding Tarek to the ticket.
msg132424 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-03-28 21:29
Please note another aspect of this problem will bite all Python developers on Ubuntu 11.04.  With the introduction of multiarch, not all stdlib Python extension modules can be built out of the box, as seen here:

https://bugs.launchpad.net/ubuntu/+source/db4.8/+bug/738213/comments/13

Ubuntu's source package was hacked to make things work, by calling out to dpkg-architecture and adding the resulting directories to library_dirs and include_dirs search paths.  That patch would obviously have to be modified at the very least to be robust on non-Debian/Ubuntu platforms.

I'm not sure what the right solution is for upstream.
msg132503 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-03-29 19:11
Here's a fix that works for me on Ubuntu 11.04.
msg132505 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-03-29 19:19
I should note that I'd love to backport this to Python 3.2, 3.1, 2.7 and 2.6 since none of them can build entirely now on multiarch systems.  Since it only affects search order in the build process, one could argue that it's not a new feature :).
msg132506 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-03-29 19:28
Barry: does it allow to install Python into /usr/lib/whateverarch, or is it just a partial fix for something slightly unrelated to this issue?
msg132511 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * Date: 2011-03-29 19:38
A proper fix is to introduce sys.libdir, which would be controllable by --libdir=${value} option of `configure`. If --libdir=${value} is not passed, then sys.libdir would default to sys.prefix + "/lib".
sysconfig, distutils etc. would have to use sys.libdir.
msg132535 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-03-29 21:39
On Mar 29, 2011, at 07:28 PM, Antoine Pitrou wrote:

>
>Antoine Pitrou <pitrou@free.fr> added the comment:
>
>Barry: does it allow to install Python into /usr/lib/whateverarch, or is it
>just a partial fix for something slightly unrelated to this issue?

Antoine, you're right that the problem and fix I'm talking about is probably
different than the original bug report.  I really should create a new issue,
since mine isn't about building multiarch for Python, but instead just being
able to build Python on a multiarch system.  My problem is thankfully much
simpler.
msg132537 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-03-29 21:49
I retract my patch for this bug because the issue described here is actually different than the one I want to fix.  See issue 11715 for the problem of building Python on multiarch Debian and Ubuntu (e.g. Ubuntu 11.04).
msg132538 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-03-29 22:05
On Mar 29, 2011, at 07:38 PM, Arfrever Frehtes Taifersar Arahesis wrote:

>A proper fix is to introduce sys.libdir, which would be controllable by
>--libdir=${value} option of `configure`. If --libdir=${value} is not passed,
>then sys.libdir would default to sys.prefix + "/lib".  sysconfig, distutils
>etc. would have to use sys.libdir.

Please note that I'm not interested (right now <wink>) in building Python
multiarch, but building Python *on* multiarch.  So I think simply adding the
right search paths to setup.py is the right way to go, and I've opened a
separate issue for it.
msg132540 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2011-03-29 22:11
heh, that's easy, just add the multiarch id to the extension name ;-)
msg132542 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2011-03-29 22:12
On 29.03.2011 21:28, Antoine Pitrou wrote:
> > Barry: does it allow to install Python into /usr/lib/whateverarch,
no, it looks for headers and libraries in more directories.  But really, this
whole testing for paths is wrong. Just use the compiler to search for headers
and libraries, no need to check these on your own.

> > or is it just a partial fix for something slightly unrelated to this issue?

IMO, unrelated to the original report.
msg132544 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-03-29 22:15
On Mar 29, 2011, at 10:12 PM, Matthias Klose wrote:

>no, it looks for headers and libraries in more directories.  But really, this
>whole testing for paths is wrong. Just use the compiler to search for headers
>and libraries, no need to check these on your own.

You're probably right about that, but reimplementing Python's build system is
out of scope for right now. ;)  For one thing, doing so wouldn't allow me to
backport to older Pythons, which I really want to do.
msg132546 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-03-29 22:15
On Mar 29, 2011, at 10:11 PM, Matthias Klose wrote:

>heh, that's easy, just add the multiarch id to the extension name ;-)

Clever! :)
msg160482 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * Date: 2012-05-12 17:00
I currently think that sys.libdir should be only basename of libdir (e.g. "lib" or "lib64") to allow to easily use it with something else than sys.prefix.
msg160671 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-05-14 22:14
On Mar 29, 2011, at 10:12 PM, Matthias Klose wrote:
> no, it looks for headers and libraries in more directories.  But really, this
> whole testing for paths is wrong. Just use the compiler to search for headers
> and libraries, no need to check these on your own.

Do all compilers provide this info, including Windows ones?  If so, that would be a nice feature for distutils2.

Arfrever Frehtes Taifersar Arahesis (Arfrever) on 2012-05-12 19:00
> I currently think that sys.libdir should be only basename of libdir (e.g.
> "lib" or "lib64") to allow to easily use it with something else than sys.prefix.

With the new sysconfig module I don’t think we need to clutter sys with another attribute.
msg160691 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2012-05-15 07:42
Éric Araujo wrote:
> 
> Éric Araujo <merwok@netwok.org> added the comment:
> 
> On Mar 29, 2011, at 10:12 PM, Matthias Klose wrote:
>> no, it looks for headers and libraries in more directories.  But really, this
>> whole testing for paths is wrong. Just use the compiler to search for headers
>> and libraries, no need to check these on your own.
> 
> Do all compilers provide this info, including Windows ones?  If so, that would be a nice feature for distutils2.

This only works for a handful of system library paths, not the extra
ones that you may need to search for local installations of
libraries and which you have to inform the compiler about :-)

Many gcc installations, for example, don't include the /usr/local
or /opt/local dir trees in the search. On Windows, you have to
run the correct vc*.bat files to have the paths setup and optional
software rarely adds the correct paths to LIB and INCLUDE.

The compiler also won't help with the problem Sean originally
pointed to: building software on systems that can run both
32-bit and 64-bit and finding the right set of libs to
link at.

Another problem is finding the paths to the right version of a
library (both include files and corresponding libraries).

While it would be great to have a system tool take care of setting
things up correctly, I don't know of any such tool, so searching
paths and inspecting files using REs appears to be the only way
to build a general purpose detection scheme.

mxSetup.py (included in egenix-mx-base) uses such a scheme, distutils
has one too.
msg202341 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-11-07 15:17
Is this issue still relevant?
msg202343 - (view) Author: jan matejek (matejcik) Date: 2013-11-07 15:40
Yes. We still have a patch for two things:
1. fix setup.py script to look for libraries in correct (lib64) prefixes, and
2. fix values returned from sysconfig, to reflect that python resides in lib64

"$prefix/lib" is hardcoded in many places. Lib64 is probably not going away anytime soon, so it would be nice if this was solved once and for all ;)
The good thing is that with sysconfig, we don't have to do much beyond teaching sysconfig about the right values.

To reiterate, our current solution is to introduce "sys.lib" (and "sys.arch", but that is never used anymore) that is either "lib" or "lib64", and use this in place of the string "lib" wherever appropriate. We find the value for sys.lib through configure magic.
msg202354 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2013-11-07 15:56
the patch in msg202343 is wrong, hardcoding lib64 on Debian/Ubuntu. At least the configure check should check for lib64 as a directory and not a symlink, and only then default to lib64.

two other issues with the patch:

 - I would like to see any new OS-dependent locations in the sysconfig module, not the sys module.

 - Please don't depend on uname for the autoconf check, but on the gnu host triplet.

 - Please don't add another `arch' attribute to sys. We already have enough of these in sysconfig.
msg202359 - (view) Author: jan matejek (matejcik) Date: 2013-11-07 16:05
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 7.11.2013 16:56, Matthias Klose napsal(a):
> 
> Matthias Klose added the comment:
> 
> the patch in msg202343 is wrong, hardcoding lib64 on Debian/Ubuntu.

This patch is provided for reference only - it works for us at SUSE. I'll be
happy to spend some time improving it for general usage, if this has any
chance of being commited.

> At least the configure check should check for lib64 as a directory and not
> a symlink, and only then default to lib64.

Maybe this should be detected differently altogether. Perhaps by working with
LIBDIR, which is known to configure?

> 
> two other issues with the patch:
> 
> - I would like to see any new OS-dependent locations in the sysconfig
> module, not the sys module.

how would you propose to put the value into sysconfig in the first place? It
seems to rely heavily on existing attributes from sys.

> 
> - Please don't depend on uname for the autoconf check, but on the gnu host
> triplet.
> 
> - Please don't add another `arch' attribute to sys. We already have enough
> of these in sysconfig.

We don't use this one anymore, and i'm not entirely sure that we ever did. I
am happy to drop it.

> 
> ----------
> 
> _______________________________________ Python tracker
> <report@bugs.python.org> <http://bugs.python.org/issue1294959> 
> _______________________________________
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSe7pdAAoJEIskb84DCy7LvwcP/2n74K2XDsRu7K6OV9S4SzDa
v7vpDVhAgTBQlHglY+wavUQU2WLBlGyVEk2xHDV8WdI4zU7rAbn7XAW5URxznctq
t/Ptvt0IsDAqONrF8ezg8/eTUkcP3nV2Hk90RNe0gliDH6uc0wekKUZzVaTObO1L
3vM8XfEtTQstmK1VxQVpYolUPZm8n7Fe8NEPA6A8bu8CU736cg+wWdbDrr6Mjowo
OuO4b56J1P3BIQkBcOLe3mH20Bv8O03P9iNADwYHUOayvgthFWCmoDzh0Y1dQa9/
ynT+G9BuYyXOli6Yr15W0L8OFU+nwxByK81lEClz6UonCvoStnEWnXIN3JYW15Yb
rNwb5HKNmKB16yx/RuV3WCvlKbg6ziMlfWGW6qTA1g0P0ivU+sRVQXv5gI8NHcQ9
/4jmaUh7Dr1T4KHujI57Z99kLQHvSlHEM3v4aT96IZNaPghkA+e7TjhMdHmvYtQz
YoY75FIy0xVStdXzw8zbM2LVlKp8vxncrjYbuzJYgG1jiYwmF6gDoztXRVP/zwei
PypIiui4QaQc32V5dCwpQYpAvpgCVHm6sGSO0HbLWSUK71M8f1YU2BPwvglHb6jh
N9tmYfmahvQSyIFOZdb4C6HLlzEezENdYYIf7oMW07z8SOOLU+8eKP13dp6NWINP
HCSU34LLYTfwnQ+27aMk
=raBO
-----END PGP SIGNATURE-----
msg202365 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-11-07 16:51
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Nov 07, 2013, at 04:05 PM, jan matejek wrote:

>> - I would like to see any new OS-dependent locations in the sysconfig
>> module, not the sys module.
>
>how would you propose to put the value into sysconfig in the first place? It
>seems to rely heavily on existing attributes from sys.

Actually, I think it mostly parses these values from the installed Makefile.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBCAAGBQJSe8T6AAoJEBJutWOnSwa/6oAQAJM3IksGydXk9CEp7rbSrHea
DvYUccmyon1xrmu5RjWnz6ZbJdWlFwx8ouFpbzmZvfAF8E2m0HliNzW+/w28sik5
F37p5/7hScQ2x/AcmdnVrzDotMkvcvMILsCDIhSy/nPIWkI4hAuRGLdPJmgiE3HE
b3hjQDCgsVDrp8arJioepx6xWSMpE1dQ/KsL6DDuNl3rUNVR1E1jTYEqY12+fOjc
Mcgz6lVndyZreY958iQE/UR7MKoW5lcLnin44PtMYrizwWv82kgwhkqU5tubnTBD
m9tD16uCz7xvATM5XI8nmXeLcLMSMfUdaG+4ny//cIjDKYIC6XXoZvCgE7iSEws1
pEIQCmrs6mpk6d83Yz/XDXc4OqjqC+tUPY1TGNqAI/nm416uoKUuO/f1eU397EV+
2RqJqev8Ho8Sgk7skFJGwcCfTO4yDR40+0wm3u2BiM9bTcnGiJaC7z2TAp9eb4Qs
jo/cmYi3BbqPu9Xx3P4oX11NHmjTPBUcZjqsJa8w8q3lf9r5haE5EqlLaNgDnGtL
efu7OMom2yQHXdwIJ2efmefjoby812uNFSbTiMvDxZTVCCUyBczBT/Q7gu/4S9Ks
Mv3oY1bkq6qAXKKOwzKoblzHJ6VW+A3Rn15Lh6Tb2kj1pTbdS9fFJASWr6CprjWi
XbCdez4dMhd+PGwgxHs6
=/r/D
-----END PGP SIGNATURE-----
msg202366 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-11-07 16:53
On Nov 07, 2013, at 03:40 PM, jan matejek wrote:

>To reiterate, our current solution is to introduce "sys.lib" (and "sys.arch",
>but that is never used anymore) that is either "lib" or "lib64", and use this
>in place of the string "lib" wherever appropriate. We find the value for
>sys.lib through configure magic.

PEP 421 added sys.implementation, which contains provisions for
implementation-specific additions.  So a better place to put these
non-standard values is sys.implementation._lib and sys.implementation._arch,
either instead of or in addition to sysconfig variables.
msg202367 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2013-11-07 16:56
I disagree about sys.implementation. It's useless and wrong for cross builds.  Please use sysconfig instead. What sysconfig is maybe missing is a set of variables which you can rely on.
msg202368 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * Date: 2013-11-07 16:59
configure.ac should accept an option, which allows to set any custom libdir.

Examples (architecture: libdir) in Gentoo:
x32:       libx32
mips o32:  lib
mips n32:  lib32
mips n64:  lib64
msg202378 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-11-07 17:55
On Nov 07, 2013, at 04:56 PM, Matthias Klose wrote:

>I disagree about sys.implementation. It's useless and wrong for cross builds.
>Please use sysconfig instead. What sysconfig is maybe missing is a set of
>variables which you can rely on.

Agreed that sysconfig is a better place for more general values.  My point was
that if OpenSUSE wants to carry deltas that are specific only to its platform,
then sys.implementation._<whatever> is the standard place to put it.
History
Date User Action Args
2013-11-07 17:55:15barrysetmessages: + msg202378
2013-11-07 16:59:02Arfreversetmessages: + msg202368
2013-11-07 16:56:50dokosetmessages: + msg202367
2013-11-07 16:53:50barrysetmessages: + msg202366
2013-11-07 16:51:09barrysetmessages: + msg202365
2013-11-07 16:05:54matejciksetmessages: + msg202359
2013-11-07 15:56:17dokosetmessages: + msg202354
2013-11-07 15:40:04matejciksetfiles: + Python-3.3.0b2-multilib.patch

messages: + msg202343
2013-11-07 15:17:59barrysetmessages: + msg202341
2013-08-01 20:40:31catalin.iacobsetnosy: + catalin.iacob
2012-05-15 07:42:31lemburgsetmessages: + msg160691
2012-05-14 22:14:43eric.araujosetmessages: + msg160671
versions: + Python 3.3, - Python 3.1
2012-05-12 17:00:21Arfreversetmessages: + msg160482
2011-03-29 22:15:34barrysetmessages: + msg132546
2011-03-29 22:15:07barrysetmessages: + msg132544
2011-03-29 22:12:15dokosetmessages: + msg132542
2011-03-29 22:11:04dokosetmessages: + msg132540
2011-03-29 22:05:33barrysetmessages: + msg132538
2011-03-29 21:50:14barrysetfiles: - a4dcae4cd033.diff
2011-03-29 21:49:54barrysetmessages: + msg132537
2011-03-29 21:39:30barrysetmessages: + msg132535
2011-03-29 19:38:53Arfreversetmessages: + msg132511
2011-03-29 19:28:41pitrousetnosy: + pitrou
messages: + msg132506
2011-03-29 19:19:37barrysetmessages: + msg132505
2011-03-29 19:13:41barrysetfiles: + a4dcae4cd033.diff
2011-03-29 19:13:20barrysetfiles: - a9b05b89ea39.diff
2011-03-29 19:11:50barrysetfiles: + a9b05b89ea39.diff
2011-03-29 19:11:23barrysethgrepos: + hgrepo12
messages: + msg132503
2011-03-28 21:29:10barrysetmessages: + msg132424
2011-03-17 12:53:40jceasetnosy: + jcea
2011-03-16 13:55:54andybuckleysetnosy: + andybuckley
2010-08-21 19:41:29BreamoreBoysettype: behavior
versions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6, Python 3.0
2010-08-11 05:48:58eric.araujosetnosy: + barry
2009-11-06 17:41:23lemburgsetnosy: + tarek
messages: + msg94989
2009-11-06 17:27:21lemburgsetnosy: + lemburg
messages: + msg94986
2009-11-06 16:47:16Arfreversetnosy: + Arfrever
2009-11-06 16:26:22matejciksetmessages: + msg94982
2009-11-05 19:23:07eric.araujosetnosy: + eric.araujo
messages: + msg94941
2009-09-12 12:46:31akitadasetmessages: + msg92541
2009-08-20 18:29:01matejciksetmessages: + msg91781
2009-08-20 11:01:02dokosetnosy: + doko
messages: + msg91769
2009-08-14 16:27:32matejciksetfiles: + Python-2.6.2-multilib.patch

messages: + msg91559
2009-03-30 04:23:41ajaksu2linkissue1536339 superseder
2009-03-30 03:23:22ajaksu2linkissue1553166 superseder
2009-03-03 16:17:33matejciksetnosy: + matejcik
2009-02-28 17:32:01akitadasetmessages: + msg82929
2009-02-03 21:23:29akitadasetnosy: + akitada
messages: + msg81099
2008-03-27 14:31:02belopolskysetmessages: + msg64593
2008-03-27 14:11:17belopolskysetnosy: + belopolsky
messages: + msg64592
2008-02-03 07:18:05ivazquezsetnosy: + ivazquez
2008-01-05 19:33:54christian.heimessetkeywords: + patch
nosy: + christian.heimes
messages: + msg59310
components: + Build, - None
versions: + Python 2.6, Python 3.0
2005-09-19 03:05:28jafocreate