Packages that pretend to support Python 2.4
Hello, 19 packages uses syntax constructs specific to Python 2.5+ in their public modules but don't declare that minimum supported version is 2.5. I'm looking for volunteers to do MBF. Packages: calibre_0.5.14+dfsg-1 elyxer_0.98-1 epigrass_2.0.1~dfsg-1 idjc_0.8.2-2 moovida-plugins-bad_1.0.9+bzr1614-1 python-apptools_3.3.1-1 python-django-treebeard_1.60-3 python-docky_2.0.3.1-1 python-envisageplugins_3.1.2-1 python-lamson_1.0pre11-1 python-netio230a_1.0.1-2 python-paver_1.0.2-1 python-pesto_16-1 python-pydhcplib_0.6.2-1 python-tegaki-gtk_0.3.1-1 python-tegaki_0.3.1-1 python-traitsbackendqt_3.3.0-1 python-traitsbackendwx_3.3.0-1 pytrainer_1.7.2-1 Dd-list: Marcelo Jorge Vieira (metal) me...@debian.org python-pesto LI Daobing lidaob...@debian.org python-tegaki python-tegaki-gtk Debian CLI Applications Team pkg-cli-apps-t...@lists.alioth.debian.org python-docky Debian LyX Maintainers pkg-lyx-de...@lists.alioth.debian.org elyxer Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org epigrass Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org idjc Debian Python Modules Team python-modules-t...@lists.alioth.debian.org python-apptools python-envisageplugins python-paver python-traitsbackendqt python-traitsbackendwx Jan Dittberner ja...@debian.org python-paver (U) Free Ekanayaka fr...@debian.org idjc (U) Varun Hiremath va...@debian.org epigrass (U) python-apptools (U) python-envisageplugins (U) python-traitsbackendqt (U) python-traitsbackendwx (U) Sven Hoexter hoex...@debian.org elyxer (U) Philipp Huebner debala...@debian.org python-netio230a Philipp Kern pk...@debian.org python-pydhcplib Noèl Köthe n...@debian.org pytrainer Chris Lamb la...@debian.org python-django-treebeard Maintainers of GStreamer packages pkg-gstreamer-maintain...@lists.alioth.debian.org moovida-plugins-bad Loic Minier l...@dooz.org moovida-plugins-bad (U) Martin Pitt mp...@debian.org calibre (U) Charles Plessy ple...@debian.org epigrass (U) Arnaud Quette aque...@debian.org moovida-plugins-bad (U) Christopher James Halse Rogers r...@ubuntu.com python-docky (U) Miriam Ruiz little_m...@yahoo.es calibre Reinhard Tartler siret...@tauware.de idjc (U) Paul van Tilburg pau...@debian.org moovida-plugins-bad (U) Andreas Tille ti...@debian.org epigrass (U) Alessio Treglia quadris...@ubuntu.com idjc (U) David Watson dwat...@debian.org python-lamson (U) David Watson da...@kutoken.com python-lamson Torsten Werner twer...@debian.org epigrass (U) -- Jakub Wilk signature.asc Description: Digital signature
Re: Packages that pretend to support Python 2.4
* Vincent Bernat ber...@debian.org, 2010-05-17, 21:43: 19 packages uses syntax constructs specific to Python 2.5+ in their public modules but don't declare that minimum supported version is 2.5. I'm looking for volunteers to do MBF. Out of curiosity, what method did you use to determine that those packages use 2.5+ constructs? I byte-compiled all of them using comileall.py. PS I discovered that there are some false-positives; sorry about that. -- Jakub Wilk signature.asc Description: Digital signature
Re: Packages that pretend to support Python 2.4
Hi Jakub (2010.05.17_20:01:25_+0200) 19 packages uses syntax constructs specific to Python 2.5+ in their public modules but don't declare that minimum supported version is 2.5. I'm looking for volunteers to do MBF. Done, only 13 real bugs. calibre_0.5.14+dfsg-1 False positive elyxer_0.98-1 Fixed in 0.98-2 epigrass_2.0.1~dfsg-1 False positive idjc_0.8.2-2False positive moovida-plugins-bad_1.0.9+bzr1614-1 Existing bug: http://bugs.debian.org/572188 python-apptools_3.3.1-1 False positive python-django-treebeard_1.60-3 Filed http://bugs.debian.org/582045 python-docky_2.0.3.1-1 Filed http://bugs.debian.org/582046 python-envisageplugins_3.1.2-1 False positive python-lamson_1.0pre11-1Filed http://bugs.debian.org/582047 python-netio230a_1.0.1-2Filed http://bugs.debian.org/582048 python-paver_1.0.2-1Existing bug: http://bugs.debian.org/575186 python-pesto_16-1 Filed http://bugs.debian.org/582050 python-pydhcplib_0.6.2-1Filed http://bugs.debian.org/582051 python-tegaki-gtk_0.3.1-1 Filed http://bugs.debian.org/582052 python-tegaki_0.3.1-1 Existing bug: http://bugs.debian.org/577096 python-traitsbackendqt_3.3.0-1 Filed http://bugs.debian.org/582054 python-traitsbackendwx_3.3.0-1 False positive pytrainer_1.7.2-1 Filed http://bugs.debian.org/582056 All the bugs were just errors thrown in the python-support hook, except for python-traitsbackendqt (Bug #582054) which was an install failure. I've usertagged them all python2.4-incompatible. A possibly cause for these issues is Bug #582061 where the python-support documentation isn't as clear as it could be about specifying python-version compatibility. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100518001453.gj20...@bach
Post-install compilation of packages for unsupported Python versions (was: Packages that pretend to support Python 2.4)
Stefano Rivera stef...@rivera.za.net writes: Hi Jakub (2010.05.17_20:01:25_+0200) 19 packages uses syntax constructs specific to Python 2.5+ in their public modules but don't declare that minimum supported version is 2.5. I'm looking for volunteers to do MBF. Done, only 13 real bugs. […] Thanks for filing those, Stefano. All the bugs were just errors thrown in the python-support hook, […] I admit to being surprised that it was attempting to compile for Python 2.4 when that version isn't supported any longer. Do we consider it a bug that ‘python-support’ is attempting to compile for Python versions we don't support? Should it constrain itself only to those Python versions supported? That leads, though, to the question of what to do about systems which upgrade to Squeeze but still have Python 2.4 installed. -- \ “Often, the surest way to convey misinformation is to tell the | `\ strict truth.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739xpkit9.fsf...@benfinney.id.au
Bug#557293: polybori: FTBFS without Python 2.4
Package: polybori Version: 0.5~rc1-2 Severity: important User: debian-python@lists.debian.org Usertags: python2.6 ftbfs polybori hardcodes Python version it uses at build time in python-polybori.install, despite have a build-depends on python-all-dev. This means that polybori will fail to build once Python 2.4 is removed from the list of support Python versions. While you're there, you might also migrate from python-central to python-support (this is the advice of the debian-python list): http://wiki.debian.org/DebianPython/central2support -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Boost.Python: Build and Install with Python 2.4 and 2.5?
on Thu Mar 13 2008, Steve M. Robbins steve-AT-sumost.ca wrote: Actually, the only thing about Boost that causes grief to packagers is that the toolset name (e.g. gcc42) is embedded in the library filename. I just wrote a response on Boost.Build outlining this in some detail [1]. Embedding the compiler version requires Debian to rebuild all the boost packages each time a compiler change is made. This is unnecessary when the compiler ABI is maintained (e.g 4.1 - 4.2) and also unnecessary when the ABI is broken, as Debian has another mechanism to handle that. Note that rebuilding the boost packages has a huge ripple effect, so it is more than simply unnecessary, it is a very large headache. I'm not sure that's the end of the story. One reason we embed the compiler name in the library name is that version-specific workarounds often show up in header files. The result is that when compiled against gcc-4.2, client code will effectively see different header contents than the precompiled boost library that was built with gcc-4.1 did. I think we'd need to work out a discipline of avoiding BOOST_WORKAROUND code in headers that distinguishes compiler minor versions. I'm not very confident that I've thought that issue through completely... is it that simple? The fact that Boost embeds the Boost version in the library name is cause for grief to client software authors. But this is unavoidable as long as Boost doesn't take care to maintain ABI across versions. Fortunately, there is a simple solution to this, which I touch on in my post [1]. This is just a change to bjam? Have you gotten any traction with that idea? -- Dave Abrahams Boost Consulting http://boost-consulting.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote: on Thu Mar 13 2008, Steve M. Robbins steve-AT-sumost.ca wrote: Actually, the only thing about Boost that causes grief to packagers is that the toolset name (e.g. gcc42) is embedded in the library filename. I just wrote a response on Boost.Build outlining this in some detail [1]. Embedding the compiler version requires Debian to rebuild all the boost packages each time a compiler change is made. This is unnecessary when the compiler ABI is maintained (e.g 4.1 - 4.2) and also unnecessary when the ABI is broken, as Debian has another mechanism to handle that. Note that rebuilding the boost packages has a huge ripple effect, so it is more than simply unnecessary, it is a very large headache. I'm not sure that's the end of the story. One reason we embed the compiler name in the library name is that version-specific workarounds often show up in header files. The result is that when compiled against gcc-4.2, client code will effectively see different header contents than the precompiled boost library that was built with gcc-4.1 did. Interesting. I didn't know that. Debian's unstable distribution has been using the same compiled Boost libraries with a mix of GCC 4.1 and 4.2 since December. GCC 4.3 is being added to the mix, too. I should grep the boost headers for BOOST_WORKAROUND to see what differences might arise. I think we'd need to work out a discipline of avoiding BOOST_WORKAROUND code in headers that distinguishes compiler minor versions. I'm not very confident that I've thought that issue through completely... is it that simple? If possible, that would be nice from a library distributor's point of view. The fact that Boost embeds the Boost version in the library name is cause for grief to client software authors. But this is unavoidable as long as Boost doesn't take care to maintain ABI across versions. Fortunately, there is a simple solution to this, which I touch on in my post [1]. This is just a change to bjam? Have you gotten any traction with that idea? It turns out to be simpler than that. With a small tweak to boost's Jamroot file, I'm now generating libraries without the toolset and without the Boost version decorations. I will use this for the upcoming Boost 1.35.0 Debian packages. We had a long thread in Boost.Build about this idea [1]. I'm not sure I convinced anyone to my point of view. :-) We'll proceed with Debian-specific changes for the short term and see how it goes. Regards, -Steve [1] Thread starts at http://lists.boost.org/boost-build/2008/04/18835.php The shortest statement of Debian's position is http://lists.boost.org/boost-build/2008/04/18839.php (And please ignore http://lists.boost.org/boost-build/2008/04/18918.php as I've changed my mind again) signature.asc Description: Digital signature
Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?
Steve, Steve M. Robbins wrote: It turns out to be simpler than that. With a small tweak to boost's Jamroot file, I'm now generating libraries without the toolset and without the Boost version decorations. I will use this for the upcoming Boost 1.35.0 Debian packages. By all means, could you please get together with other packagers (fedora, notably) and try to establish a common procedure ? (Ideally this procedure would be christened by boost itself, eventually, but unfortunately I just don't see that happening anytime soon.) This is really a big usability issue for developers who want to develop on platforms such as debian or fedora, but still remain as portable as possible, as they have to be prepared for lots of subtle and not-so-subtle variations, complicating their life unnecessarily. It's bad enough that there is no API ABI stability guarantee from one boost version to the next... Thanks ! Stefan -- ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Boost.Python: providing libs for both Python 2.4 and 2.5.
On Fri, Mar 21, 2008 at 12:18:17PM -0500, Steve M. Robbins wrote: I wrote about three weeks ago [1] that I'm trying to get Boost's Python extension helper library building with multiple Python versions. Several very helpful suggestions were made, for which I am grateful. I have been plugging away, very slowly, ever since. I'm hoping to upload it later today and I'd appreciate have some second opinions on what I've done. I settled on creating libraries with suffix -py24 and -py25 using the available Boost mechanism of --buildid since that ensures the SONAME also has -py24 or -py25. The shared library files thus coexist peacefully. Hi, I see you've now uploaded this, and it seems to fix my problem building the mapnik python bindings[1]. Thanks! However, it looks to be like the shlibs file needs updating. My python-mapnik package is linked against the py25 library: [EMAIL PROTECTED]:~$ ldd /usr/lib/python2.5/site-packages/mapnik/_mapnik.so|grep boost_python libboost_python-gcc42-mt-1_34_1-py25.so.1.34.1 = /usr/lib/libboost_python-gcc42-mt-1_34_1-py25.so.1.34.1 (0xb7b2c000) yet my package still has a Depends line (generated from shlibdeps) of libboost-python1.34.1 (= 1.34.1-2.1) which I don't think is going to work, since that library only appeared in libboost-python1.34.1 1.34.1-8. Hence upgrades will potentially break. Have I done something wrong, or is this analysis correct and the shlibs file needs updating? If that latter, let me know if a report in the BTS[2] would be (more) useful. Thanks, Dominic. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468770 -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-boost-devel] Boost.Python: providing libs for both Python 2.4 and 2.5.
On Mon, Mar 24, 2008 at 05:52:47PM +, Dominic Hargreaves wrote: However, it looks to be like the shlibs file needs updating. Yes, and thanks for the bug report. Upload is being prepared now. -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Boost.Python: providing libs for both Python 2.4 and 2.5.
On Fri, Mar 21, 2008 at 03:59:30PM -0400, Aaron M. Ucko wrote: I do, however, see a couple of concrete issues with your script: if [ $1 = -d ]; then debug=-d shift fi Shouldn't you fix that at build time à la $version? You noticed a complication I was avoiding. There are actually two packages that need an rtupdate script: libboost-python-dev, and libboost-dbg. The latter holds all the debug versions of the libraries, including the Boost.Python libraries. The only difference in names is that the debug libraries have -d in them. So I was avoiding two scripts by this parameterization. [I have subsequently done the parameterization slightly differently; consult the boost svn repo for details or wait for the upload in a few hours] rtupdate) rtupdate $1 ;; More critically, AFAICT you want to pass $2, not $1. Indeed. I had sent out the note before fully testing the script. How embarrassing. Thanks, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Boost.Python: providing libs for both Python 2.4 and 2.5.
Steve M. Robbins [EMAIL PROTECTED] writes: libraries, including the Boost.Python libraries. The only difference in names is that the debug libraries have -d in them. So I was avoiding two scripts by this parameterization. Ah, thanks for clarifying; I had forgotten about the -dbg package, and thought that there might instead be a build-time switch. [I have subsequently done the parameterization slightly differently; consult the boost svn repo for details or wait for the upload in a few hours] I took a quick glance, and have no further concerns offhand. Thanks for the excellent work! Indeed. I had sent out the note before fully testing the script. How embarrassing. No problem; typos happen, and help remind reviewers to stay on their toes. :-) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Boost.Python: providing libs for both Python 2.4 and 2.5.
Hello,
I wrote about three weeks ago [1] that I'm trying to get Boost's
Python extension helper library building with multiple Python
versions. Several very helpful suggestions were made, for which I am
grateful.
I have been plugging away, very slowly, ever since. I'm hoping to
upload it later today and I'd appreciate have some second opinions on
what I've done.
I settled on creating libraries with suffix -py24 and -py25 using
the available Boost mechanism of --buildid since that ensures the
SONAME also has -py24 or -py25. The shared library files thus
coexist peacefully.
For the link libraries, I chose to retain both the fully-decorated
forms including the -pyXY suffix, as well as create symlinks (with
no suffix) for those who just want the default python version. These
symlinks are maintained by an rtupdate script as suggested by a
couple of people.
Focusing only on the simpler, Debian-specific, library names,
the intent is that the following link libraries are availble:
libboost_python-py24.a - libboost_python-gcc42-1_34_1-py24.a
libboost_python-py24.so - libboost_python-gcc42-1_34_1-py24.so
libboost_python-py25.a - libboost_python-gcc42-1_34_1-py25.a
libboost_python-py25.so - libboost_python-gcc42-1_34_1-py25.so
libboost_python.a - libboost_python-py24.a
libboost_python.so - libboost_python-py24.so
The rtupdate script (attached) will replace the last two libraries
with
libboost_python.a - libboost_python-py25.a
libboost_python.so - libboost_python-py25.so
This allows extension builders to select either the default Python
version, or a specific version, without knowing the Boost
and GCC versions [2].
I'd appreciate any feedback on the above, and especially on what
follows.
I'd love some folks to look over the attached rtupdate script. My
understanding is that this gets run when the Python default version
changes. If so, I guess that a bug in the script will cause the
Python package install to fail. I'd like to avoid the hate mail
generated if that happened; so if you've got a moment, have a look at
the script.
I'd like to ask about intended behaviour if a bad action is supplied.
Or if an unsupported python version is given. I chose to exit with an
error message and status 1. Now I'm a little worried that will break
some Python installs and generate the hate mail. What's the
recommended behaviour here?
Note that my libboost-python-dev postinst script calls it
to populate the symlinks initially:
/usr/share/python/runtime.d/libboost-python-dev.rtupdate \
rtupdate none $(pyversions -d)
I also use it in the prerm to remove all the symlinks:
/usr/share/python/runtime.d/libboost-python-dev.rtupdate \
remove
Thanks,
-Steve
[1] http://lists.debian.org/debian-python/2008/02/msg00033.html
[2] http://lists.debian.org/debian-python/2008/02/msg00045.html
#! /bin/sh
#
# Update link-library symlinks after a Python default runtime change
set -e
version=1_34_1
die() {
echo $@ 2
exit 1
}
update_linklibs() {
py=$1
suf=$2
cd /usr/lib
for thread in -mt; do
for gcc in gcc41 gcc42; do
ln -s -f
libboost_python-${gcc}${thread}${debug}-${version}-${py}.${suf} \
libboost_python-${gcc}${thread}${debug}-${version}.${suf}
done
ln -s -f libboost_python${thread}${debug}-${py}.${suf} \
libboost_python${thread}${debug}.${suf}
done
}
remove_linklibs() {
suf=$1
cd /usr/lib
for thread in -mt; do
for gcc in gcc41 gcc42; do
rm -f libboost_python-${gcc}${thread}${debug}-${version}.${suf}
done
rm -f libboost_python${thread}${debug}.${suf}
done
}
rtupdate() {
case $1 in
python2.4) py=py24 ;;
python2.5) py=py25 ;;
*) die $0 unknown python version $1 ;;
esac
update_linklibs $py a
update_linklibs $py so
}
remove() {
remove_linklibs a
remove_linklibs so
}
if [ $1 = -d ]; then
debug=-d
shift
fi
action=$1
shift
case $action in
pre-rtupdate) ;;
post-rtupdate) ;;
rtupdate) rtupdate $1 ;;
remove)remove ;;
*) die $0 called with unknown argument '$action' ;;
esac
signature.asc
Description: Digital signature
Re: Boost.Python: providing libs for both Python 2.4 and 2.5.
Steve M. Robbins [EMAIL PROTECTED] writes: This allows extension builders to select either the default Python version, or a specific version, without knowing the Boost and GCC versions [2]. Yep; so far so good. I'd like to ask about intended behaviour if a bad action is supplied. Or if an unsupported python version is given. I chose to exit with an error message and status 1. Now I'm a little worried that will break some Python installs and generate the hate mail. What's the recommended behaviour here? Good question. I'd favor exiting with non-zero status, per the proposed implementation; if you're really concerned about potential disruption, you can always add || true to the prerm's invocation so that users can at least readily pull libboost-python-dev from their systems until you resolve the breakage. I do, however, see a couple of concrete issues with your script: if [ $1 = -d ]; then debug=-d shift fi Shouldn't you fix that at build time à la $version? rtupdate) rtupdate $1 ;; More critically, AFAICT you want to pass $2, not $1. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote: on Sat Feb 23 2008, Steve M. Robbins steve-AT-sumost.ca wrote: [...] This produces pairs of library files such as bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a (and similar pairs for shared libraries and all other variants). The key item to note is that the two files have the same name. The python version, unlike the GCC version, is not embedded in the library name. So these files cannot both be installed into /usr/lib. I don't know how such name gristing is generated in Boost.Build, but IMO we should change the naming to account for the Python version. Perhaps. For the moment, I can get the desired effect using --buildid. The question, then, is how to distinguish them once installed? Should we: 1. Rename the resulting libraries to decorate them with the python version in addition to the gcc version? This could generate libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.a I'm not an expert in this area, but it's been my understanding that simply renaming library files doesn't work for some reason. Partly true. I believe you can rename the static libs (.a files) at will. The problem lies in the shared libs. Subsequent to writing the above, I discovered that the two shared libraries (.so.*) have exactly the same SONAME, so renaming doesn't work for them. 2. Similar to above, but use bjam's --buildid option? This has the drawback that the build ID shows up differently than the GCC version decoration, e.g. libboost_python-gcc42-1_34_1-py24.a libboost_python-gcc42-1_34_1-py25.a Sounds more likely to work, even though it's ugly. Yes, this works because the --buildid is incorporated into the SONAMEs, thus distinguishing them. Using --buildid is therefore the *only* solution short of hacking the soname generation myself. I'd appreciate your thoughts. Have I overlooked a better solution? What are the other packagers of Boost.Python doing? Unfortunately, we don't tend to get a lot of interaction with packagers around here, so we don't tend to know what they're doing. I think Boost raises more packaging issues than most other libraries, so it would be good to have more involvement from y'all. Actually, the only thing about Boost that causes grief to packagers is that the toolset name (e.g. gcc42) is embedded in the library filename. I just wrote a response on Boost.Build outlining this in some detail [1]. Embedding the compiler version requires Debian to rebuild all the boost packages each time a compiler change is made. This is unnecessary when the compiler ABI is maintained (e.g 4.1 - 4.2) and also unnecessary when the ABI is broken, as Debian has another mechanism to handle that. Note that rebuilding the boost packages has a huge ripple effect, so it is more than simply unnecessary, it is a very large headache. The fact that Boost embeds the Boost version in the library name is cause for grief to client software authors. But this is unavoidable as long as Boost doesn't take care to maintain ABI across versions. Fortunately, there is a simple solution to this, which I touch on in my post [1]. Regards, -Steve [1] http://lists.boost.org/boost-build/2008/03/18565.php signature.asc Description: Digital signature
Re: [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Tue, Feb 26, 2008 at 10:04:26PM -0600, Steve M. Robbins wrote: On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote: Decorate only the shared library names with the python versions, and retain the current names for the .a files and .so symlinks - with two separate -dev packages that conflict with one another? That still prevents anyone from packaging an extension that builds for both python2.4 and python2.5 at once using Boost.Python, but I think it solves all the other drawbacks of the other solutions you suggested. Indeed. Do you think this is a serious restriction? Given that Debian likes to package extensions for all python versions, I tend to think it will become a problem. I think it's a tolerable restriction. Clearly there are no packages using Boost.Python today to build for more than one version of python, so it's of course not a regression in any case; and we don't *need* all python extensions to be built for all python versions, it just makes transitions easier the more there are. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [boost] [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?
Hi, On Tue, Feb 26, 2008 at 10:04:26PM -0600, Steve M. Robbins wrote: On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote: The solution is to keep the names decorated with both python versions, but to maintain a farm of symbolic links pointing to the current python version. As Steve noted, you don???t need one for the runtime libs, but for the .a and the .so symlink that are used at build time, this is required. OK, both you and Bernd suggested rtupdate. Bernd even pointed me to a description of it [1]; thanks. Let me see if I understand your proposal. The idea is to create a single -dev package that contains the following in /usr/lib: libboost_python-py24-gcc42-1_34_1.so libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.so libboost_python-py25-gcc42-1_34_1.a The -dev package contains an rtupdate script to create the following symlinks (also in /usr/lib): libboost_python-gcc42-1_34_1.so libboost_python-gcc42-1_34_1.a Does that sound right? It may sound even better if multiple Boost versions were considered, packaging them in versioned source packages (ie boost-1.34.1, boost-1.35.0). Respective -dev packages should then be also versioned and conflicting each other, as the mostly undecorated symlinks there provided. Having boost-defaults driving the default Boost and Python versions and the completely undecorated symlinks. This, for instance, would allow Boost 1.35.0 in lenny while 1.34.1 being the default one. I frankly doubt a full transition to 1.35.0 would happen before the release of lenny. Ciao, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?
Le mardi 26 février 2008 à 22:04 -0600, Steve M. Robbins a écrit : The idea is to create a single -dev package that contains the following in /usr/lib: libboost_python-py24-gcc42-1_34_1.so libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.so libboost_python-py25-gcc42-1_34_1.a The -dev package contains an rtupdate script to create the following symlinks (also in /usr/lib): libboost_python-gcc42-1_34_1.so libboost_python-gcc42-1_34_1.a Does that sound right? Yes. This has the advantage that a Python extension can be build and packaged for either or both supported Python versions, albeit at the cost of changing the link line. Code that just needs the default version can use the undecorated form in the link line. The disadvantage is that if you use the undecorated form, you're not quite sure what version of Boost.Python is linked in. This sounds good as this way, extensions using boost can be made to build with all available python versions. It would be nice to have libboost_python2.4.so and libboost_python2.5.so symbolic links as well, so that building an extension for all available python versions doesn’t require setting the GCC version and boost version in the link line. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Wed, Feb 27, 2008 at 08:43:43AM -0500, Stefan Seefeld wrote: (I still don't see the problem: Source packages don't depend on binary packages, only binary packages do. Source packages *do*, in fact, depend on binary packages. Each source package describes exactly the packages required to build the source; e.g. whether Qt3 libraries or X11 libraries are needed. These are called build-time dependencies or build-deps for short. And if you package your extension module you are in control of what python version(s) you build against, no ?) That's a true statement. Several extension modules will, in fact, build for both Python 2.4 and 2.5. Now imagine an extension module that uses Boost.Python. As mentioned, it must have the relevant build-deps. To support this, the relevant boost-python development packages must be co-installable (i.e. not conflict with each other). It's not yet clear to me whether this is an achievable goal, but it would be nice. Regards, -Steve signature.asc Description: Digital signature
Re: [boost] [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?
Steve M. Robbins wrote: Hi, Thanks to Steve, Bernd, and Josselin for ideas. On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote: Decorate only the shared library names with the python versions, and retain the current names for the .a files and .so symlinks - with two separate -dev packages that conflict with one another? That still prevents anyone from packaging an extension that builds for both python2.4 and python2.5 at once using Boost.Python, but I think it solves all the other drawbacks of the other solutions you suggested. Indeed. Do you think this is a serious restriction? Given that Debian likes to package extensions for all python versions, I tend to think it will become a problem. extensions for different python installations don't conflict because they end up in separate directories. Python's own runtime library does a similar thing: it is installed in prefix/lib/pythonversion/config. What if boost.python gets installed into that directory, too ? Wouldn't this solve the issue ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote: Steve M. Robbins wrote: Hi, Thanks to Steve, Bernd, and Josselin for ideas. On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote: Decorate only the shared library names with the python versions, and retain the current names for the .a files and .so symlinks - with two separate -dev packages that conflict with one another? That still prevents anyone from packaging an extension that builds for both python2.4 and python2.5 at once using Boost.Python, but I think it solves all the other drawbacks of the other solutions you suggested. Indeed. Do you think this is a serious restriction? Given that Debian likes to package extensions for all python versions, I tend to think it will become a problem. extensions for different python installations don't conflict because they end up in separate directories. The proposal above is that we provide a boost-python-2.4-dev and a boost-python-2.5-dev package that conflict with one another (because they would contain files of the same name). This prevents a source package from depending on both for a build, and therefore a source package for a Python extension cannot produce an extension for each Python version. -Steve signature.asc Description: Digital signature
Re: Boost.Python: Build and Install with Python 2.4 and 2.5?
Hi, I'd suggest to do 3. Put the libraries in different subdirectories, e.g. /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a and add a symlink to /usr/lib which points to the library version for the current default python version. You could use rtupdate to handle the symlink, so there's no need to rebuild the package when the default Python version is changed. Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Boost.Python: Build and Install with Python 2.4 and 2.5?
Hi, I'm part of the Debian Boost packaging team, seeking some guidance on how to build and install Boost.Python so that it is usable with all Python versions shipped in Debian. Debian currently ships Python 2.4 and 2.5. When reading the following, keep in mind that Boost.Python is not a Python extension but, rather, a library that eases writing an extension in C++. So it is necessary that the compiled libraries be visible to be linked with user-written C++ code. One idea is to use a user-config.jam file containing using python : 2.4 : /usr ; using python : 2.5 : /usr ; Then run jam twice bjam variant= ... bjam variant= ... python python=2.5 This produces pairs of library files such as bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a (and similar pairs for shared libraries and all other variants). The key item to note is that the two files have the same name. The python version, unlike the GCC version, is not embedded in the library name. So these files cannot both be installed into /usr/lib. The question, then, is how to distinguish them once installed? Should we: 1. Rename the resulting libraries to decorate them with the python version in addition to the gcc version? This could generate libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.a 2. Similar to above, but use bjam's --buildid option? This has the drawback that the build ID shows up differently than the GCC version decoration, e.g. libboost_python-gcc42-1_34_1-py24.a libboost_python-gcc42-1_34_1-py25.a 3. Put the libraries in different subdirectories, e.g. /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a 4. Put the default version directly in /usr/lib and the others in subdirectories, e.g. /usr/lib/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a The drawback to all these approaches is that client code has to be adjusted to build on Debian. Linking against Boost (for non-bjam projects) is already hard enough with the decorated library names that I fear making the situation worse. The attraction of #4 is that at least the variants for the default python version are found in a natural manner. This has some appeal to me, personally, but I worry that it is too easy to build an extension to python 2.5 and link in the wrong Boost.Python library. In contrast, the other options have the advantage that it forces the user to declare which version of Python is being used. I'd appreciate your thoughts. Have I overlooked a better solution? What are the other packagers of Boost.Python doing? In principle, it would be nice to have the Boost libraries named the same across distributions. Thanks, -Steve signature.asc Description: Digital signature
Help with #381343 (FutureWarning: hex/oct constants sys.maxint will return positive values in Python 2.4 and up)
Hello, I am _not_ a Python user/developper but maintain the plucker and plucker-desktop packages which are Python scripts. The warnings I get are: /usr/lib/python2.3/site-packages/PyPlucker/helper/gettext.py:131: FutureWarning: hex/oct constants sys.maxint will return positive values in Python 2.4 and up if _lsbStrToInt(buffer[:4]) != 0x950412de: /usr/lib/python2.3/site-packages/PyPlucker/helper/gettext.py:176: FutureWarning: hex/oct constants sys.maxint will return positive values in Python 2.4 and up f.write(_intToLsbStr(0x950412de))# magic number /usr/lib/python2.3/site-packages/PyPlucker/helper/prc.py:244: FutureWarning: hex/oct constants sys.maxint will return positive values in Python 2.4 and up attr = (auid 0xff00) 24 /usr/lib/python2.3/site-packages/PyPlucker/helper/prc.py:876: FutureWarning: hex/oct constants sys.maxint will return positive values in Python 2.4 and up attr = (auid 0xff00) 24 What is the best way to solve these warnings and avoid possible problems with Python 2.4? Please cc: me on replies since I am not a subscriber of this list. Thanks, -- Dr. Ludovic Rousseau[EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.4 / Changing the packaging style for python packages
Matthias, On Tue, Jun 13, 2006, Matthias Klose wrote: We will prepare the transition in experimental by an upload of the python, python-dev packages I tried testing my rtupdates scripts by installing python version 2.4.3-5 from experimental, but they didn't seem to run, and I couldn't find anywhere in the maintainer scripts of the python package a place where they would be run. Is this feature already included in the python packages? In experimental? Or do I need to depend on something? I checked the python package from http://people.debian.org/~doko/pythontst/, and its maintainer scripts didn't seem to have the feature either. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.4 / Changing the packaging style for python packages
Hi, With the upcoming releases of the last packages which didn't support 2.4 yet (Plone on the Zope application server) we may be able to drop support for 2.3 in sid and etch as well. For reference, decompyle still needs python2.3. There are two issues: 1. It won't build under python2.4. I have fixes for this that I haven't uploaded (and that need some more testing and tidying up). 2. It won't decompile python2.4 bytecode. This will be somewhat harder to fix (and I haven't done it yet). Issue #2 is not really relevant to dropping python2.3, since keeping python2.3 around is not going to help the fact that people will be wanting to decompile bytecode for the new default python2.4. Issue #1 is a problem however, so if there are plans to drop 2.3 for etch, I'd be very happy for a rough timeframe so I know when this all needs to be dealt with. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.4 / Changing the packaging style for python packages
Coin, Ben Burton [EMAIL PROTECTED] writes: For reference, decompyle still needs python2.3. There are two issues: 1. It won't build under python2.4. I have fixes for this that I haven't uploaded (and that need some more testing and tidying up). You may still ask for help. 2. It won't decompile python2.4 bytecode. This will be somewhat harder to fix (and I haven't done it yet). If it is not able to decompile recent python version, then it is a kind of useless one. Python 2.4 is out since a while, what are upstream plans for their software ? -- Marc Dequènes (Duck) pgpASsE9n5U8g.pgp Description: PGP signature
Re: Move to python 2.4 / Changing the packaging style for python packages
Hi, 1. It won't build under python2.4. I have fixes for this that I haven't uploaded (and that need some more testing and tidying up). You may still ask for help. This will be easy enough to have ready by the time 2.3 is removed, which I'm assuming is not happening tomorrow. Where I'd love the help is with the python2.4 decompilation (see below). 2. It won't decompile python2.4 bytecode. This will be somewhat harder to fix (and I haven't done it yet). If it is not able to decompile recent python version, then it is a kind of useless one. Well, it's certainly useful at the moment since python2.3 is the default, and I claim it's still useful even after python2.3 is dropped -- just because debian changes the default python doesn't mean all your old bytecode disappears. One of the more important uses of this software is for repairing things in an emergency (e.g., rm *.py, oops), which is why I want to keep it around. Python 2.4 is out since a while, what are upstream plans for their software ? Upstream went commercial back in the 2.2 days. The debian packages forked and essentially became the de-facto upstream source when 2.3 decompilation was introduced, and it's still that way now. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
Steve Langasek [EMAIL PROTECTED] writes: That much is obvious. The point is wouldn't it be confusing to the user to call the package python-ctypes when it doesn't support the current python version? Oh well, I guess I can put in something in the description to explain this. A package named python-ctypes must support the current python version: it must ensure this by having a versioned dependency on the versions of python that it is compatible with. That means that if python-ctypes only supports python ( 2.5), and python is at Version: 2.5.0-1, python-ctypes will not be installable (and will need to be updated). This is exactly my point. There will be no python-ctypes supporting python = 2.5. That's why I am arguing that there needs to policy exceptions to allow a package named python2.4-ctypes. Josselin seems to think different. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
Josselin Mouette [EMAIL PROTECTED] writes: Le jeudi 18 mai 2006 à 00:11 -0500, Steve Langasek a écrit : A package named python-ctypes must support the current python version: it must ensure this by having a versioned dependency on the versions of python that it is compatible with. That means that if python-ctypes only supports python ( 2.5), and python is at Version: 2.5.0-1, python-ctypes will not be installable (and will need to be updated). At that moment, python could even start to provide python-ctypes. Then what would you name the ctypes package supporting python2.4? Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
Steve Langasek writes: On Wed, May 17, 2006 at 10:03:15AM +0530, Ganesan Rajagopal wrote: Josselin Mouette [EMAIL PROTECTED] writes: In short, the main decision has been to drop entirely python2.x-foo packages. They will, however, be provided as virtual packages, but only if something actually needs them. ... For C extensions, it was decided to build them for all available python versions in a single python-foo package. For example, currently we have python2.3 and python2.4. The package would contain /usr/lib/python2.[34]/site-packages/foo.so and depend on python (= 2.3), python ( 2.5). The python-all-dev package will be used to build this. Hmm, seems a bit backward to me. What if I don't have python2.3 installed at all. What's the point in keeping /usr/lib/python2.3/site-packages/foo.so around? The advantage to have extensions for the python version you switch from and for the version you switch to is: you don't need an upload for the transition, potentially adding dependencies on new library packages. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
On Wed, May 17, 2006 at 10:03:15AM +0530, Ganesan Rajagopal wrote: Josselin Mouette [EMAIL PROTECTED] writes: In short, the main decision has been to drop entirely python2.x-foo packages. They will, however, be provided as virtual packages, but only if something actually needs them. ... For C extensions, it was decided to build them for all available python versions in a single python-foo package. For example, currently we have python2.3 and python2.4. The package would contain /usr/lib/python2.[34]/site-packages/foo.so and depend on python (= 2.3), python ( 2.5). The python-all-dev package will be used to build this. Hmm, seems a bit backward to me. What if I don't have python2.3 installed at all. What's the point in keeping /usr/lib/python2.3/site-packages/foo.so around? Nothing in policy will require that you do this. We discussed specifically in the BoF whether it was appropriate to allow building binary modules only for the current version of python, and the agreement was that yes, this was appropriate and support will be implemented. -- 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/
Re: python 2.4?
Josselin Mouette [EMAIL PROTECTED] writes: Le mercredi 17 mai 2006 à 14:12 +0530, Ganesan Rajagopal a écrit : I understand the upgrade issues that pythonX.Y packages cause with multiple versions of python in Debian. However, for binary modules I don't really see an alternative in some cases. How about this alternate proposal for binary modules * python-foo must support the current python version. * python-foo can optionally include support for older python versions (I am still not convinced on this one). * Alternatively, pythonX.Y-foo is allowed to support older versions of python in the archive. Over my dead body. That makes it a bit difficult, where do you live ;-)? There's no point in simplifying python packaging if in fact it becomes more complicated because we allow exceptions. Then please suggest how to handle the issues that I raised with the new policy. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
On Thu, May 18, 2006 at 10:06:59AM +0530, Ganesan Rajagopal wrote: Josselin Mouette [EMAIL PROTECTED] writes: Le jeudi 18 mai 2006 à 08:17 +0530, Ganesan Rajagopal a écrit : There's no point in simplifying python packaging if in fact it becomes more complicated because we allow exceptions. Then please suggest how to handle the issues that I raised with the new policy. I don't see any issues raised in your messages. Having extra .so files is the drawback we have accepted when deciding upon this new policy. Okay, if that's the decision, then I guess I can live with that. As for the ctypes example, it can be trivially handled with dependencies. That much is obvious. The point is wouldn't it be confusing to the user to call the package python-ctypes when it doesn't support the current python version? Oh well, I guess I can put in something in the description to explain this. A package named python-ctypes must support the current python version: it must ensure this by having a versioned dependency on the versions of python that it is compatible with. That means that if python-ctypes only supports python ( 2.5), and python is at Version: 2.5.0-1, python-ctypes will not be installable (and will need to be updated). -- 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/ signature.asc Description: Digital signature
Re: python 2.4?
On 5/13/06, Raphael Hertzog [EMAIL PROTECTED] wrote: On Fri, 12 May 2006, Andreas Barth wrote: How about, right now, just a statement this is what the issues are. Or even, this [URL here] is the mailing list post where the issues are outlined. I forgot about them. So, I need to collect them again. Even release managers don't have a superhuman brain (though we sometimes pretend we do :). The only issue is Matthias Klose who absolutely wants to push big packaging changes at the same time[1] whereas everybody else agree that we should take our time for those changes since we managed to live with the current python policy until now. Doko wants python-central but the python modules team uses mostly python-support: http://wiki.debian.org/DebianPythonTODO I certainly hope we can discuss that IRL at Debconf. I would welcome a Python BoF. I think the Python BoF happened, so is there a thread somewhere with what was discussed, a wiki article or even a blog entry ? I trust that the guys involved took non insane decisions but i would like to know, since we've more than 50 packages to keep ok for Etch just in the Debian Python Modules Team and a lot more that i would like to give attention too out of our team. Closing, who from dpmt was there? I hope buxy was, because i think he's the only dpmt admin in mx (gpastore and i weren't). Probably others dmpt members were too. Well, break the silence and give me updates, please. :) regards, -- stratus
Re: python 2.4?
On Tue, 16 May 2006, Gustavo Franco wrote: I think the Python BoF happened, so is there a thread somewhere with what was discussed, a wiki article or even a blog entry ? I trust that the guys involved took non insane decisions but i would like to know, since we've more than 50 packages to keep ok for Etch just in the Debian Python Modules Team and a lot more that i would like to give attention too out of our team. Closing, who from dpmt was there? I hope buxy was, because i think he's the only dpmt admin in mx (gpastore and i weren't). Probably others dmpt members were too. Well, break the silence and give me updates, please. :) I were, Matthias Klose was, and Josselin was (and many more people like Jeroen, Anthony, Andreas, ...). The discussion has been interesting and we have a kind of new python-policy. More on that later, hopefully from someone else than me... Matthias has some updates on python-central on his laptop and he should upload it somewhere so that we can take a look. We agreed to switch to python-2.4 in the week following debconf (next week that is) and go on with whatever we have at that time. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
On 5/16/06, Raphael Hertzog [EMAIL PROTECTED] wrote: On Tue, 16 May 2006, Gustavo Franco wrote: I think the Python BoF happened, so is there a thread somewhere with what was discussed, a wiki article or even a blog entry ? I trust that the guys involved took non insane decisions but i would like to know, since we've more than 50 packages to keep ok for Etch just in the Debian Python Modules Team and a lot more that i would like to give attention too out of our team. Closing, who from dpmt was there? I hope buxy was, because i think he's the only dpmt admin in mx (gpastore and i weren't). Probably others dmpt members were too. Well, break the silence and give me updates, please. :) I were, Matthias Klose was, and Josselin was (and many more people like Jeroen, Anthony, Andreas, ...). The discussion has been interesting and we have a kind of new python-policy. More on that later, hopefully from someone else than me... Hopefully soon. :) Matthias has some updates on python-central on his laptop and he should upload it somewhere so that we can take a look. Ok, but what's the point here? Are we going to drop python-support usage ? Will python-central provides python-support ? Can we technically keep using both (we shouldn't IMHO!) ? We agreed to switch to python-2.4 in the week following debconf (next week that is) and go on with whatever we have at that time. Great news, i just want to have an idea now, how much work we will need to put dpmt packages in shape for release. Thanks, -- stratus
Re: python 2.4?
Le mardi 16 mai 2006 à 17:04 -0300, Gustavo Franco a écrit : Matthias has some updates on python-central on his laptop and he should upload it somewhere so that we can take a look. Ok, but what's the point here? Are we going to drop python-support usage ? Will python-central provides python-support ? Can we technically keep using both (we shouldn't IMHO!) ? Even after the talk, I have no idea of what python-central exactly does. It is supposed to help us in building the new policy, but I don't know how exactly. In short, the main decision has been to drop entirely python2.x-foo packages. They will, however, be provided as virtual packages, but only if something actually needs them. For python-only modules, it has been decided to use python-support. The python modules team already knows it and won't have anything to change in such packages. The necessary code for dh_python will be back soon. For C extensions, it was decided to build them for all available python versions in a single python-foo package. For example, currently we have python2.3 and python2.4. The package would contain /usr/lib/python2.[34]/site-packages/foo.so and depend on python (= 2.3), python ( 2.5). The python-all-dev package will be used to build this. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: python 2.4?
On 5/16/06, Josselin Mouette [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 17:04 -0300, Gustavo Franco a écrit : Matthias has some updates on python-central on his laptop and he should upload it somewhere so that we can take a look. Ok, but what's the point here? Are we going to drop python-support usage ? Will python-central provides python-support ? Can we technically keep using both (we shouldn't IMHO!) ? Even after the talk, I have no idea of what python-central exactly does. It is supposed to help us in building the new policy, but I don't know how exactly. http://wiki.debian.org/DebianPythonTODO points out a thread were doko explain this. In short, the main decision has been to drop entirely python2.x-foo packages. They will, however, be provided as virtual packages, but only if something actually needs them. Great news. For python-only modules, it has been decided to use python-support. The python modules team already knows it and won't have anything to change in such packages. The necessary code for dh_python will be back soon. Well, i'm part of the dpmt and it wasn't really decided to stick with python-support after/while moving to python 2.4. I've recommended the group pick python-support for python-only modules because the pythonX.X-foo thing sucks, and it was clear that we were going to get rid of that. Of course, the python-support solution seemed to be a good one instead use python-all-dev and keep wit the versioned packages until 2.4 and after that start the move. buxy that is other group admin agreed too (based on my opinion about his words and wiki article). For C extensions, it was decided to build them for all available python versions in a single python-foo package. For example, currently we have python2.3 and python2.4. The package would contain /usr/lib/python2.[34]/site-packages/foo.so and depend on python (= 2.3), python ( 2.5). The python-all-dev package will be used to build this. Sounds good. Any comment about the policy changes and where python-central will fit there? Meanwhile, i'll check if dpmt group's policy needs update. regards, -- stratus
Re: python 2.4?
Josselin Mouette [EMAIL PROTECTED] writes: In short, the main decision has been to drop entirely python2.x-foo packages. They will, however, be provided as virtual packages, but only if something actually needs them. ... For C extensions, it was decided to build them for all available python versions in a single python-foo package. For example, currently we have python2.3 and python2.4. The package would contain /usr/lib/python2.[34]/site-packages/foo.so and depend on python (= 2.3), python ( 2.5). The python-all-dev package will be used to build this. Hmm, seems a bit backward to me. What if I don't have python2.3 installed at all. What's the point in keeping /usr/lib/python2.3/site-packages/foo.so around? Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
On Fri, 12 May 2006, Andreas Barth wrote: How about, right now, just a statement this is what the issues are. Or even, this [URL here] is the mailing list post where the issues are outlined. I forgot about them. So, I need to collect them again. Even release managers don't have a superhuman brain (though we sometimes pretend we do :). The only issue is Matthias Klose who absolutely wants to push big packaging changes at the same time[1] whereas everybody else agree that we should take our time for those changes since we managed to live with the current python policy until now. Doko wants python-central but the python modules team uses mostly python-support: http://wiki.debian.org/DebianPythonTODO I certainly hope we can discuss that IRL at Debconf. I would welcome a Python BoF. Cheers, [1] Otherwise he could already have uploaded them since the packages are ready... cf http://lists.debian.org/debian-python/2006/01/msg00028.html -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, 2006-04-12 at 22:58 +0200, Jeroen van Wolffelaar wrote: zope2.9 is simply still sitting in NEW, and is not rejected. I see there was a clarification requested over the weekend about the big number of zope versions in the archive (2.9 would be the 4th), and Fabio replied. This was two days ago, nothing happened since as far as I can see, so I'd advice to just wait a bit. Fwiw, I don't see a zope2.7 removal request yet, but maybe I'm looking wrongly? We are working on this, but before filing a zope2.7 request we need to check what packages are incompatible with zope = 2.8 and *then* ask for the removal of zope2.7. In the end, in a few days I'll file the removal request of zope2.7 and (I hope) ftp-masters will accept zope2.9 package. -- Fabio Tranchitella [EMAIL PROTECTED].''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: This is a digitally signed message part
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, 12 Apr 2006, Matthias Klose wrote: ok, I did run out of time last weekend, however python2.5, python2.3-doc, python2.4-doc are in NEW. According your logic about vacation times, the change of the default version probably should not be done before Easter. Easter is 4 days or a full week for some: nothing problematic. Please go ahead with the python 2.4 change ASAP. Unfortunately FTP masters did reject the Zope2.x upload, which uses python2.4. Any reasons for that? Zope2.7 already was scheduled for removal. I'm not ftpmaster so I can't comment, but usually they give a reason in the rejection notice... what did it say ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, Apr 12, 2006 at 04:33:35PM +0200, Matthias Klose wrote: Jeroen van Wolffelaar writes: On Wed, Apr 12, 2006 at 12:41:13AM +0200, Jeroen van Wolffelaar wrote: So, because there were no objections to the python 2.1/2.2 removal, I'll be proceeding with that. Done now, I'd like to announce this, together with some warning about default python version changes, if they're going to happen soon (best to not to have multiple separate announcements if they can be joined). It'll be a bit (about 24h) before a dropped python2.1 python2.2 will reach the mirrors, and impact should be reasonably limited, so otoh, it isn't totally required. So, any opinion on the -defaults change, esp. from Matthias of course, is very welcomed. ok, I did run out of time last weekend, however python2.5, python2.3-doc, python2.4-doc are in NEW. Cool According your logic about vacation times, the change of the default version probably should not be done before Easter. I don't know, while some people (including, at least, myself) will be unavailable during Easter to do any Debian work, others might rather have lots of time because of it being a holiday and no daytime job being in the way. Having this change done before easter will leverage both groups of people. But I don't care about the exact timing, but I do think we should really do this sooner rather than later, to get things going. Therefore, I'd like to urge you to simply do the move, and have anyone interested help out fixing up all the packages that get broken by it and need an update. Unfortunately FTP masters did reject the Zope2.x upload, which uses python2.4. Any reasons for that? Zope2.7 already was scheduled for removal. Can you please be more specific? And/or reply to the REJECT mail, as it states at the bottom of every reject? That way, all the info is at hand for us ftp-people to look into it. I can't find any NEW reject for zope2.anything during the whole of 2006. At least listing the exact filename of the .changes is already very useful to find the upload you're talking about. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
Jeroen van Wolffelaar writes: Unfortunately FTP masters did reject the Zope2.x upload, which uses python2.4. Any reasons for that? Zope2.7 already was scheduled for removal. Can you please be more specific? And/or reply to the REJECT mail, as it states at the bottom of every reject? That way, all the info is at hand for us ftp-people to look into it. I can't find any NEW reject for zope2.anything during the whole of 2006. At least listing the exact filename of the .changes is already very useful to find the upload you're talking about. CC'ing Fabio, AFAIK that was a zope2.9 upload. Maybe it would be better, if FTP masters send the reject mail to the Maintainer address, not the uploader address? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, Apr 12, 2006 at 10:32:28PM +0200, Matthias Klose wrote: Jeroen van Wolffelaar writes: Unfortunately FTP masters did reject the Zope2.x upload, which uses python2.4. Any reasons for that? Zope2.7 already was scheduled for removal. Can you please be more specific? And/or reply to the REJECT mail, as it states at the bottom of every reject? That way, all the info is at hand for us ftp-people to look into it. I can't find any NEW reject for zope2.anything during the whole of 2006. At least listing the exact filename of the .changes is already very useful to find the upload you're talking about. CC'ing Fabio, AFAIK that was a zope2.9 upload. Maybe it would be better, if FTP masters send the reject mail to the Maintainer address, not the uploader address? zope2.9 is simply still sitting in NEW, and is not rejected. I see there was a clarification requested over the weekend about the big number of zope versions in the archive (2.9 would be the 4th), and Fabio replied. This was two days ago, nothing happened since as far as I can see, so I'd advice to just wait a bit. Fwiw, I don't see a zope2.7 removal request yet, but maybe I'm looking wrongly? About who to inform, typically there isn't a maintainer yet for packages in NEW, so it's a bit tricky. The actual maintainer is only available after a package is installed, because it's not in the .changes. In most cases it doesn't matter (uploader maintainer same person), so while I agree better notification might be worthwhile, it's also not terribly high on my list of things to look into. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
Matthias Klose wrote: Jeroen van Wolffelaar writes: The first freezes are already closing in fast, did I miss something? There's no update since http://lists.debian.org/debian-devel-announce/2005/10/msg4.html Yes. At least the January, 3rd one (http://lists.debian.org/debian-devel-announce/2006/01/msg1.html) --- snip --- [...] Our time line still is: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] The good news is that we are on track to reach this goal. [...] --- snip --- Regards, Rene signature.asc Description: Digital signature
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 01:49:52PM +0200, Matthias Klose wrote: Jeroen van Wolffelaar writes: The first freezes are already closing in fast, did I miss something? There's no update since http://lists.debian.org/debian-devel-announce/2005/10/msg4.html We're roughly 16 weeks from the python freeze, including the debconf period and the summer holiday period (for the northern hemisphere, that is). During these mere 16 weeks, python 2.1 2.2 needs to be dropped, the default moved to 2.4, and the plan is to overhaul the python policy/infrastructure. We can use all of those weeks to get settled over each of those issues, and many more that are important for the release. Having 4 (or maybe even 5) python versions would be a release blocker, and the two oldest ones can be removed without any serious direct consequences, and simply would provide a better urge for people to fix up their packages. Several people already asked for removal, sponsoring, and I noticed some more packages simply getting fixed over the weekend. So, because there were no objections to the python 2.1/2.2 removal, I'll be proceeding with that. Regarding 2.4, I'd really like to get started with it asap, and having the policy stuff happening in parallel. Are there any objections/reasons to *not* do so in like a week from now, starting with a simple upload of python-defaults? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, Apr 12, 2006 at 12:41:13AM +0200, Jeroen van Wolffelaar wrote: So, because there were no objections to the python 2.1/2.2 removal, I'll be proceeding with that. Done now, I'd like to announce this, together with some warning about default python version changes, if they're going to happen soon (best to not to have multiple separate announcements if they can be joined). It'll be a bit (about 24h) before a dropped python2.1 python2.2 will reach the mirrors, and impact should be reasonably limited, so otoh, it isn't totally required. So, any opinion on the -defaults change, esp. from Matthias of course, is very welcomed. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
decompyle2.2 has an unsatisfied build-dependency: python2.2-dev This is a legacy package, and it requires python 2.2 (it will not work with 2.3 or newer). I have just filed an ftp.d.o bug asking for it to be removed. Users should have no problem switching to the newer decompyle package instead. jython has an unsatisfied build-dependency: python2.1 I orphaned this a couple of months ago. It requires python2.1 at runtime because it is actually an implementation of python2.1. The simplest fix is probably to copy across the pure python modules from cpython2.1 and add them to the jython2.1 package in /usr/share/jython/Lib/, at which point the python2.1 dependency should be able to be removed. However, the jython packages are not ageing gracefully. Unless someone has time to spend actively looking after this (see my WNPP bug for what is required), I'd (regretfully) suggest its removal also. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote: python-pylibacl has an unsatisfied build-dependency: python2.2-dev python-pyxattr has an unsatisfied build-dependency: python2.2-dev I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. Regards, Iustin Pop signature.asc Description: Digital signature
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 01:38:43PM +0200, Iustin Pop wrote: On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote: python-pylibacl has an unsatisfied build-dependency: python2.2-dev python-pyxattr has an unsatisfied build-dependency: python2.2-dev I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. If nobody else beats me to it, I'll sponsor you on monday. Ensure that the URL to your package is in the bug report filed on it regarding this transition, so that I, or whoever wants to look into this bug/package, can find it. This advice is valid for everyone, if you are a non-DD maintaining such package, make sure people can sponsor you instead of NMUing, without the need to ask first for URLs etc, by providing all necessary information in a bug. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, 07 Apr 2006, Iustin Pop wrote: On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote: python-pylibacl has an unsatisfied build-dependency: python2.2-dev python-pyxattr has an unsatisfied build-dependency: python2.2-dev I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. Please don't hesitate to ask for sponsorship of python related modules here. Where can we find your packages ? BTW, there's no response in the BTS to these bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351149 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351150 Submitting in the BTS any relevant information, like availability of fixed packages, and the need for sponsor is always a good idea so that anyone else stumbling upon it could offer you his help. Maybe Matthias himself could have sponsored your upload since he reported the bug ... :-) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
Jeroen van Wolffelaar writes: The first freezes are already closing in fast, did I miss something? There's no update since http://lists.debian.org/debian-devel-announce/2005/10/msg4.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 01:38:43PM +0200, Iustin Pop wrote: I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. Thanks everyone for the suggestions. Will update the bug reports later today with the relevant information. Thanks, Iustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Wither the Python 2.4 migration?
hi, i asked a similar question in september : http://lists.debian.org/debian-python/2005/09/msg4.html Any news ? cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Wither the Python 2.4 migration?
Hi Matthias, What's the status of the Python 2.4 transition? During January you said you were waiting on feedback from Steve Langasek and Josselin Mouette, but Steve said he hasn't heard anything from you in a while, and thinks that the transition outweighs whatever other Python improvements you're working on. A couple weeks ago you told me (on IRC) that you'd have a new python-central/support-like thing ready for me to look at in a few days. I still haven't heard anything from you. I have to agree with Steve, if this is holding up the transition, it should stop -- the focus of the Python packages right now should be the 2.4 transition. From the looks of the Python buglists, and your responses on bugs like #340791, it looks like you might not have enough time to maintain Python anymore. Have you considered group or co-maintainership? Facing a transition may not be the best time to start it, but this needs to start very soon. The etch release plan starts calling for freezes by July, and I know you're going to need time working on other parts of the toolchain before then. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
