This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dmalcolm
Recipients Arfrever, Ramchandra Apte, amaury.forgeotdarc, barry, djc, dmalcolm, doko, eric.araujo, ezio.melotti, foom, gagern, jwilk, lemburg, loewis, neologix, petri.lehtinen, pitrou, python-dev, r.david.murray, rosslagerwall, sandro.tosi, vstinner
Date 2011-08-16.20:23:09
SpamBayes Score 1.20534e-05
Marked as misclassified No
Message-id <>
Another datapoint:

For Fedora 16, I haven't done any downstream patching (so far), because we hadn't run into any downstream problems.

I did some digging into why we're _not_ experiencing issues.

Currently for Fedora 16, we're shipping kernel-3.0 with python-2.7.2-4.fc16.x86_64 and python is reporting:

  $ python -c"import sys; print(sys.platform)"

I investigated why we have this discrepancy:  "uname" with the build environment for that RPM happens to be reporting a kernel-2*, whereas we're shipping a kernel-3*:

What's happening here is that although the chroot that the build was done in [1] has:

running "uname" in the chroot environment is reporting the kernel that's actually running, outside the chroot, which was:
and thus we have:
  checking MACHDEP... linux2
within the build log [2]

So in this case, "sys.platform"'s final digit is reporting the major release of the kernel running outside the chroot-ed build environment (ironically bearing even less relationship to that of the currently-running kernel :( )

Hope this is helpful

Date User Action Args
2011-08-16 20:23:11dmalcolmsetrecipients: + dmalcolm, lemburg, loewis, barry, doko, amaury.forgeotdarc, gagern, foom, pitrou, vstinner, jwilk, djc, ezio.melotti, eric.araujo, Arfrever, r.david.murray, sandro.tosi, neologix, rosslagerwall, python-dev, petri.lehtinen, Ramchandra Apte
2011-08-16 20:23:10dmalcolmsetmessageid: <>
2011-08-16 20:23:10dmalcolmlinkissue12326 messages
2011-08-16 20:23:09dmalcolmcreate