ldbl128 transition for alpha, powerpc, sparc and s390?
Hello The email in [1] discusses the long double transition from 64 to 128 bit. It claims that the python2.[45]-dev packages need to be updated for this too, however I can not find the related bug reports for this. I have also looked in de changelog files but can't seem to find a mention of it. So have the python packages been updated for this? The reason I'd like to know is because #430281 is a serious bug filed against a package for this long double (ldbl) transition. But this package does itself depend on python-dev so I need to wait for python2.[45]-dev to have done this transition first. Any clues? Cheers Floris [1] http://liss.debian.org/debian-devel/2007/05/msg01173.html -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldbl128 transition for alpha, powerpc, sparc and s390?
On Sun, Sep 30, 2007 at 10:54:14PM +0100, Floris Bruynooghe wrote: The email in [1] discusses the long double transition from 64 to 128 bit. It claims that the python2.[45]-dev packages need to be updated for this too, however I can not find the related bug reports for this. I have also looked in de changelog files but can't seem to find a mention of it. So have the python packages been updated for this? The reason I'd like to know is because #430281 is a serious bug filed against a package for this long double (ldbl) transition. But this package does itself depend on python-dev so I need to wait for python2.[45]-dev to have done this transition first. A number of the packages identified as being affected by the ldbl transition were false-positives, because 'long double' appeared in their headers but was not related to declarations of symbols exported by the library itself. python2.4-dev was such a false positive. If a bug was ever opened for it, it's been closed and archived long ago. You should proceed with the ldbl transition for your own package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Tool support for private modules
Howdy all, The Debian Python Policy, chapter 3 URL:http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html says: 3.1.1 Programs Shipping Private Modules A program using /usr/bin/python as interpreter can come up with private Python modules. These modules should be installed in /usr/share/module, or /usr/lib/module if the modules are architecture-dependent (e.g. extensions). /usr/lib/site-python is deprecated and should no longer be used for this purpose. But the Python distutils and setuptools will install the modules to /usr/lib/site-python/. My 'debian/rules' already has a 'dh_pycentral' line. How can I best conform to the above policy? The dumb way, I imagine, would be to manually install the foles to those specific locations. I'm wondering what tools (e.g. debhelper) support something better, and how to use them to conform to the policy. -- \ God forbid that any book should be banned. The practice is as | `\ indefensible as infanticide. -- Dame Rebecca West | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
