understanding ubuntu's patches to cpython

This particular patch caused virtualenv issue #118 and a subsequent workaround: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty/... <http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty-...> Although this patch sits on the trusty branch of cpython patckaging, in point of fact on that line i have `return os.path.join(get_config_var('LIBPL'), "Makefile")`. I see that other patches in the same project also touch this line, but none of them have this LIBPL code that I find in my actual installation. Can any of you all help me understand what's going on here? I'm trying to pinpoint exactly when/how the problematic code (.replace("/usr/local","/usr") went away. I'm hoping "doko" is on this mailing list. Of course feel free to advise if there's a more appropriate forum for this discussion.

In article <CAPQx2vfoNWaTeOb=TkftLc9ZVP-mtL7tPFcCt16T=9G+X+VWcA@mail.gmail.com>, Buck Evan <buck.2019@gmail.com> wrote:
This particular patch caused virtualenv issue #118 and a subsequent workaround: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty/... ew/head:/debian/patches/distutils-install-layout.diff#L281 <http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty-... roposed/view/head:/debian/patches/distutils-install-layout.diff#L281>
Although this patch sits on the trusty branch of cpython patckaging, in point of fact on that line i have `return os.path.join(get_config_var('LIBPL'), "Makefile")`. I see that other patches in the same project also touch this line, but none of them have this LIBPL code that I find in my actual installation.
Can any of you all help me understand what's going on here? I'm trying to pinpoint exactly when/how the problematic code (.replace("/usr/local","/usr") went away.
I'm hoping "doko" is on this mailing list. Of course feel free to advise if there's a more appropriate forum for this discussion.
This isn't really the place to ask about Ubuntu- (or Debian-) specific downstream modifications to CPython. Yes, there are people here who contribute to CPython, Debian, and Ubuntu but I think the best place to bring up questions like this, based on the Ubuntu project page, might be on the Ubuntu Core Developers mailing list: http://packages.ubuntu.com/source/utopic/python-defaults https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss Perhaps someone more familiar with the Ubuntu dev process will have a better suggestion. -- Ned Deily, nad@acm.org

On 11/16/2014 11:23 PM, Buck Evan wrote:
This particular patch caused virtualenv issue #118 and a subsequent workaround: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty/... <http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty-...>
Although this patch sits on the trusty branch of cpython patckaging, in point of fact on that line i have `return os.path.join(get_config_var('LIBPL'), "Makefile")`. I see that other patches in the same project also touch this line, but none of them have this LIBPL code that I find in my actual installation.
I'm not sure what issue you have here. Indeed, as Ned suggested, best thing would be to open a bug report in Launchpad [1].
Can any of you all help me understand what's going on here? I'm trying to pinpoint exactly when/how the problematic code (.replace("/usr/local","/usr") went away.
See the README.Debian. In the past people installed packages into the system path using "sudo python setup.py --install", and breaking applications shipped with Ubuntu. This avoids accidental installation of such packages. Unfortunately you can do this again with pip, because pip acting on the system python silently overwrites system installed python modules. Matthias [1] https://bugs.launchpad.net/ubuntu/+source/python2.7/+filebug

I feel that you've misunderstood my request entirely. I'm not trying to report an issue, just requesting help understanding how the resulting package relates to version-controlled source. It's possible that I have the wrong source entirely. Your comments seem to indicate that you believe I've clobbered my installation with something other than the standard ubuntu package. I attempt to show otherwise below. I'm pretty confident that the source on disk ('LIBPL') represents the package that all trusty users have. My aim is to track down what (version-controlled) change caused this function to change between precise and trusty. $ ls -l /usr/lib/python2.7/sysconfig.py -rw-r--r-- 1 root root 25048 Mar 22 2014 /usr/lib/python2.7/sysconfig.py $ sudo touch !$ sudo touch /usr/lib/python2.7/sysconfig.py $ ls -l /usr/lib/python2.7/sysconfig.py -rw-r--r-- 1 root root 25048 Nov 18 08:57 /usr/lib/python2.7/sysconfig.py $ sudo apt-get install --reinstall libpython2.7-minimal <snip> Preparing to unpack .../libpython2.7-minimal_2.7.6-8_amd64.deb ... Unpacking libpython2.7-minimal:amd64 (2.7.6-8) over (2.7.6-8) ... Setting up libpython2.7-minimal:amd64 (2.7.6-8) ... $ ls -l /usr/lib/python2.7/sysconfig.py -rw-r--r-- 1 root root 25048 Mar 22 2014 /usr/lib/python2.7/sysconfig.py $ grep -A3 def\ _get_makefile_filename /usr/lib/python2.7/sysconfig.py def _get_makefile_filename(): if _PYTHON_BUILD: return os.path.join(_PROJECT_BASE, "Makefile") return os.path.join(get_config_var('LIBPL'), "Makefile") $ apt-cache show libpython2.7-dev Package: libpython2.7-dev Priority: optional Section: libdevel Installed-Size: 32956 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Original-Maintainer: Matthias Klose <doko@debian.org> Architecture: amd64 Source: python2.7 Version: 2.7.6-8 Replaces: python2.7 (<< 2.7-3), python2.7-dev (<< 2.7.3-10), python2.7-minimal (<< 2.7.3-10) Depends: libpython2.7-stdlib (= 2.7.6-8), libpython2.7 (= 2.7.6-8), libexpat1-dev Pre-Depends: multiarch-support Recommends: libc6-dev | libc-dev Filename: pool/main/p/python2.7/libpython2.7-dev_2.7.6-8_amd64.deb Size: 22005790 MD5sum: 6b088fe5ee9bdb69296447a0b51f926e SHA1: 6356820a6b7fce13e1539dbe88b4292a0c8f2a8d SHA256: 646170fe0b0976d38252e474a8ac4ef5d52af93158b5a489da92c2225fbd1640 Description-en: Header files and a static library for Python (v2.7) Header files, a static library and development tools for building Python (v2.7) modules, extending the Python interpreter or embedding Python (v2.7) in applications. . Maintainers of Python packages should read README.maintainers. . This package contains development files. It is normally not used on it's[sic] own, but as a dependency of python2.7-dev. Description-md5: 2ef5e0390998d9ab1872bc0f6b694ff7 Multi-Arch: same Bugs: https://bugs.launchpad.net/ubuntu/+filebug Origin: Ubuntu Supported: 5y On Tue, Nov 18, 2014 at 2:56 AM, Matthias Klose <doko@ubuntu.com> wrote:
On 11/16/2014 11:23 PM, Buck Evan wrote:
This particular patch caused virtualenv issue #118 and a subsequent workaround: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/ python2.7/trusty/view/head:/debian/patches/distutils- install-layout.diff#L281 <http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/ python2.7/trusty-proposed/view/head:/debian/patches/ distutils-install-layout.diff#L281>
Although this patch sits on the trusty branch of cpython patckaging, in point of fact on that line i have `return os.path.join(get_config_var('LIBPL'), "Makefile")`. I see that other patches in the same project also touch this line, but none of them have this LIBPL code that I find in my actual installation.
I'm not sure what issue you have here. Indeed, as Ned suggested, best thing would be to open a bug report in Launchpad [1].
Can any of you all help me understand what's going on here? I'm trying to
pinpoint exactly when/how the problematic code (.replace("/usr/local","/usr") went away.
See the README.Debian. In the past people installed packages into the system path using "sudo python setup.py --install", and breaking applications shipped with Ubuntu. This avoids accidental installation of such packages. Unfortunately you can do this again with pip, because pip acting on the system python silently overwrites system installed python modules.
Matthias
[1] https://bugs.launchpad.net/ubuntu/+source/python2.7/+filebug
participants (3)
-
Buck Evan
-
Matthias Klose
-
Ned Deily