[VAC] 18/05-31/05 Alicante, Spain
Hi, I will be away from my email from 18 May until 31 May. If something urgent occurs with one of my packages, please NMU. In the case of Python, Matthias Klose [EMAIL PROTECTED] is your preferred contact of course. Gregor PS: I will be in Alicante, Spain during that time (perhaps with visits to Valencia and Barcelona). If somebody would like to arrange a key signing, feel free to send me an email until this Friday. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: math.exp bug on alpha?
* Bastian Kleineidam [EMAIL PROTECTED] [020111 11:41]: On Thu, Jan 10, 2002 at 09:28:30PM +0300, Mikhail Sobolev wrote: On Thu, Jan 10, 2002 at 06:29:58PM +0100, Bastian Kleineidam wrote: On Thu, Jan 10, 2002 at 05:25:43PM +, Luigi Ballabio wrote: on alpha debian, python 2.1.1-8: Works for me, no aborts. (i386, python 2.1.1-8) Just compare the platform... :) I did. So its a platform specific bug. Cf. http://bugs.debian.org/106421. Gregor
Re: python2.1 and MySQLdb
* Rick Pasotto [EMAIL PROTECTED] [011226 18:11]: I just apt-get upgraded my python and the MySQLdb module now gives the following error: Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type copyright, credits or license for more information. from MySQLdb import * Traceback (most recent call last): File stdin, line 1, in ? AttributeError: 'MySQLdb' module has no attribute 'Date' Strange, I don't get this error with the packages currently in woody: freefly:9 dpkg -l python2.1 python2.1-mysqldb python2.1-egenix-mxdatetime ii python2.1 2.1.1-7An interactive object-oriented scripting lan ii python2.1-mysq 0.9.1-3A Python interface for MySQL No packages found matching python2.1-egenix-mxdatetime. freefly:10 python2.1 Python 2.1.1+ (#1, Dec 30 2001, 17:17:30) [GCC 2.95.4 20011223 (Debian prerelease)] on linux2 Type copyright, credits or license for more information. from MySQLdb import * With python2.1-egenix-mxdatetime installed, it works as well. Could you tell me which versions of the package you have installed ? Do you have python2-egenix-mxdatetime installed ? Gregor
Re: Packaging decompyle - policy question
* Ben Burton [EMAIL PROTECTED] [02 18:22]: Hi. So I'm packaging decompyle which decompiles a .pyc bytecode file and converts it back to python source. Thing is, decompyle needs to be run with the same version of python that was used to create the bytecode. So the question arises as to what should go in /usr/bin. Options I see are: a) A wrapper script /usr/bin/decompyle which takes an addition argument specifying the python version to run and calls the real decompyle with that version of python (and defaulting to the default version of python); b) A series of binaries /usr/bin/decompyle1.5, /usr/bin/decompyle2.1, etc with the additional /usr/bin/decompyle that uses the default debian version of python. Hmm, how about an third option: c) A wrapper that auto-detects the format of the .pyc file and calls the according variant (detection of the .pyc format should be pretty easy, it's just a magic number, cf. /usr/share/misc/magic). The doesn't resolve the original problem, but then you could issue a message to the user that he needs to install an according Python version. In the end, this case should be pretty rare, since in most cases, it seems to be a reasonable expectation that a user has an according Python version on the system. I'm leaning towards option (b), but this then leads to the issue of how the binaries should be packaged. Should there be a single package decompyle which provides all of these binaries? Or should there be packages decompyle1.5, decompyle2.1, etc.? If there are several packages then each package will literally contain a single script and a symlink to a man page and would depend on decompyle-common which contains the actual decompyle itself. This seems a bit of an overkill. But on the other hand I don't want to provide binaries that people can't run (if the appropriate python version is not installed) and I don't want decompyle to depend on *every* version of python in debian. Umm, are you talking about a *binary* or an *script* ? If binaries, how big are they ? Would it really be an issue to include three of them in a single package ? If you include that autodetection stuff, I would say go on and ship them into a single package (since the user gets a meaningful message if something doesn't work due to the lack of the correct Python version). Gregor
Re: Python-2.1 becoming Debian's default Python version
* Florian Weimer [EMAIL PROTECTED] [011107 15:04]: Neil Schemenauer [EMAIL PROTECTED] writes: It's probably better to check if you're unsure rather than speculate or guess. From the 2.1.1 LICENCE file: Python 1.6.1 is essentially the same as Python 1.6, with a few minor bug fixes, and with a different license that enables later versions to be GPL-compatible. The license claims to be GPL compatible, but according to the FSF, it isn't, because of the choice-of-law clause. ^^^ Can you provide any proof for this claim ? From http://www.gnu.org/licenses/license-list.html: The License of Python 1.6a2 and earlier versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that newer versions of Python are under other licenses (see below). The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that intermediate versions of Python (1.6b1, through 2.0 and 2.1) are under a different license (see below). Gregor
Re: Python-2.1 becoming Debian's default Python version
* Florian Weimer [EMAIL PROTECTED] [011107 16:08]: Gregor Hoffleit [EMAIL PROTECTED] writes: Python 1.6.1 is essentially the same as Python 1.6, with a few minor bug fixes, and with a different license that enables later versions to be GPL-compatible. The license claims to be GPL compatible, but according to the FSF, it isn't, because of the choice-of-law clause. ^^^ Can you provide any proof for this claim ? From http://www.gnu.org/licenses/license-list.html: The License of Python 1.6a2 and earlier versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that newer versions of Python are under other licenses (see below). The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that intermediate versions of Python (1.6b1, through 2.0 and 2.1) are under a different license (see below). You have to follow the see below link on this page. Sorry, I guess I was misinterpreting you. I think we do agree that the License of Python 2.1.1, according to the FSF, is compatible with the GPL ? (That was my point, and I think I was prejudicating you ;-) Now for Python 1.6.1. The 'see below' in the second paragraph links to this (refering to 'intermediate versions of Python (1.6b1, through 2.0 and 2.1)': The License of Python 1.6b1 and later versions, through 2.0 and 2.1. This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the State of Virginia, in the USA, and the GPL does not permit this. This section is incorrect, in that Python 1.6.1 has yet another different license. It should read something like The License of Python 1.6b1 and later versions, through 2.0 and 2.1, but excluding 1.6.1 and derivatives thereof. Then, there should be another section The License of Python 1.6.1 and derivatives thereof since this license is different from the license license of 1.6. In fact the modification between 1.6 and 1.6.1 (which was made possible by CNRI) was the major step in making the release of 2.0.1 and 2.1.1 possible. OTOH, I wonder if B. Kuhn would be glad to list *four* different Python licenses on that page ? ;-) Gregor
Final draft of Python Policy (hopefully ;-)
I've put a version 0.3.6 of the Python Policy Draft on http://people.debian.org/~flight/python/. The version is still a little bit rough and sometimes incomplete, but it already gives a good outline of the Python packaging system we are installing just now. Please have a look at the document, and post all fundamental problems you have with the content. If nobody find fundamental show-stoppers that render this unusable, we're going to submit it to Debian Policy very soon. Gregor
Re: What should we do now?
* Anthony Towns aj@azure.humbug.org.au [011023 09:07]: On Tue, Oct 23, 2001 at 01:31:50AM -0400, David M. Cooke wrote: At some point, Anthony Towns aj@azure.humbug.org.au wrote: Again, _why_ does this matter? Who does this? Is it even remotely common? That people would even consider installing another version of python in /usr/local surely just points to a problem with the Debian packaging, no? Well, I do it for one. And is there some reason you can't call them /usr/local/python2.1-opt, say? Or is there some reason you can't just install all the modules you otherwise have installed? Just to make the discussion a little bit more focussed: I think several issues were mixed up in my original mail: (1) For once, #!/usr/bin/env has it's problems. Scripts that use #!/usr/bin/env python are more fragile than scripts without. (2) Another issue is python vs. python1.5. It's a separate question whether scripts need to be strictly coupled to a specific Python version. Regarding (1): If you ask me how common the situation is that people install local Python versions in /usr/local, then I will ask you how common it is that it's reasonable that a script provided by a Debian package will benefit from using #!/usr/bin/env ? Regarding (2): Making the dependency explicit (by using /usr/bin/python1.5) is just playing safe. As far as I can see, if we hadn't the legacy of the existing packages and installations, and if versioned dependencies would work on all systems in all situations, we could come up with a quite clean setup: python-base et al. could be empty packages (virtual packages wouldn't work!), and other packages could depend on them (e.g. Depends: python-base (= 2.0), python-gtk for a package that need at least Python 2.0 or better. Still in this case, what could you do if Python 2.3 broke that script ?) But we haven't an ideal situation, so we have to fight with that kind of legacy. But maybe it brings us to the core of the problem: As far as I can tell our principal problem is that there's a large set of existing packages (from slink, potato) that have wrong dependencies (like unversioned Depends: python-base for packages that depend on Python 1.5.2) that would be (erronously) satisfied if we just continued to use python-base and so on. One way to resolve this is to include a huge list of conflicts in python-base et al. Another way to resolve this is to drop these package names, perhaps in favour of some other package names. IMHO, in the current, messed up situation, scripts and packages that play safe in explicitely stating a Python version have the big advantage that they will lead to these kinds of problems with underspecified dependencies. It's much the same reasoning why libraries have a number in them that will be increased for incompatible API changes. AFAICS, with the setup you are suggesting you can never warranty that kind of robustness. Gregor
Re: What should we do now?
* Anthony Towns aj@azure.humbug.org.au [011023 17:22]: On Tue, Oct 23, 2001 at 02:42:42PM +0200, Gregor Hoffleit wrote: Just to make the discussion a little bit more focussed: I think several issues were mixed up in my original mail: Sounds like a plan. (1) For once, #!/usr/bin/env has it's problems. Scripts that use #!/usr/bin/env python are more fragile than scripts without. (2) Another issue is python vs. python1.5. It's a separate question whether scripts need to be strictly coupled to a specific Python version. Regarding (1): If you ask me how common the situation is that people install local Python versions in /usr/local, then I will ask you how common it is that it's reasonable that a script provided by a Debian package will benefit from using #!/usr/bin/env ? Well, how about you answer the question instead? It's reasonable for Debian scripts to use #!/usr/bin/env because any harm that could be caused is both rare and easily avoidable, and because that's what many upstream scripts use. AFAICS. Certainly that's not a fair statistic, but if I grep through my /usr/bin, there are 12 scripts using some kind of #!/usr/bin/env python, but 79 scripts using something like #!/usr/bin/python (in /usr/local/bin, the ratio is 2 for /usr/bin/env and 4 for /usr/bin/python). That's consistent with my observations: The common idiom in the Python community is #!/usr/local/bin/python, /usr/bin/env is only rarely used. That means most Python scripts have to be modified anyway. It's just the question whether we should replace #!/usr/local/bin/python with #!/usr/bin/env python or with #!/usr/bin/python. (I don't really care if you want to encourage people to not use /usr/bin/env, though) Regarding (2): Making the dependency explicit (by using /usr/bin/python1.5) is just playing safe. It's not merely playing safe though. It's also creating a strict dependency that will bite you later (by making transitions to python X.Y++ require significantly more changes, by having packages break needlessly when those changes aren't made). As far as I can see, if we hadn't the legacy of the existing packages and installations, and if versioned dependencies would work on all systems in all situations, we could come up with a quite clean setup: python-base et al. could be empty packages (virtual packages wouldn't work!), and other packages could depend on them (e.g. Depends: python-base (= 2.0), python-gtk for a package that need at least Python 2.0 or better. Still in this case, what could you do if Python 2.3 broke that script ?) There're two possible solutions, obviously: either you assume in advance that scripts will work with new versions of python and allow them to be installed together, or you assume they don't and forbid them from being installed together. I think that's a correct statement: I can't see any other possibilities being even logically consistent. If you assume that scripts will work with new versions of python, you end up with the result that occassionally your assumption will be wrong for some scripts, and you'll have some possible partial upgrades that'll break. This isn't a cardinal sin. OTOH, if you assume that scripts *won't* work, you're committing yourselves and a bunch of other people to going through whole bunches of Python code checking that it works, and twiddling bits to note that fact. The only question is whether the (presumable) handful of bugs every year or two due to the former is worth the (presumable) whole lot of effort involved in the latter. The easiest way to handle the latter, IMO, is to add a: Depends: python-base ( X.Y+1) to the package, where X.Y is the most recent version of python that it works with. Note that this allows you to use a package on multiple versions of python (so if woody were to release with python 1.5 and 2.0, your package could conceivably Depend: python-base (= 2.0), python-base ( 2.3), and you won't have to make further changes when Debian packages for 2.1 or 2.2 come out), unlike #!pythonX.Y, which is much more restrictive. Just to make sure we have the same thing in mind: At this point, python-base is no virtual package provided by some real pythonX.Y-base package, but it's a real package, right ? This would work indeed, provided a single, canonical Python version was an option (see below). As far as I can tell our principal problem is that there's a large set of existing packages (from slink, potato) that have wrong dependencies (like unversioned Depends: python-base for packages that depend on Python 1.5.2) that would be (erronously) satisfied if we just continued to use python-base and so on. Well there's two questions; one is working out what we want, and the other is working out how to get there. One way to resolve this is to include a huge list of conflicts in python-base et al. Another way
Re: Updated experimental packages
* Neil Schemenauer [EMAIL PROTECTED] [010907 00:33]: I see now that the python2 packages made it into unstable. This is a mistake IMHO. The Perl guys tryed this and it didn't work. Also, the name should have been python2.1 not python2. What problem does naming the packages python2 solve? It seems like a big pain for everyone for no gain. Note that the python2 packages are, at this time, legacy. They were created at the time where Python 2.0 was incompatible with the GPL, and it was a hack to provide Python 1.5.2, which was GPL compatible, as well as 2.0, which was not. Cf. README.why-python2 for a more detailed explanation. Gregor
Re: Experimental Python packages
* Neil Schemenauer [EMAIL PROTECTED] [010906 16:27]: Gregor Hoffleit wrote: Have you looked at my experimental Python packages, at http://people.debian.org/~flight/python/snapshot/ ? I haven't yet tried your packages, but it sounds like you started from scratch ? No, I based them on your python and python2 packages. I've made quite a few bug fixes to them so you might want to do a diff between them an your packages. You'll have to ignore all the s/python2/python/ changes. Ok, thanks for the effort! In the experimental packages, the biggest difference is the modified build setup in ./debian/., which should make it much easier to package new upstream versions like 2.2. Gregor
python2.1 et al.
It's been much too long since I posted the last status report. I'm swamped with all kinds of real world work, and wasn't really able to keep up in time with the discussion. Reading the discussion, I thought that in order to consolidate a Python policy, it might help to collect the information in a Wiki. I tried to setup a ZWiki, and started to fill in a few statements. You can enter the ZWiki from this URL: http://people.debian.org/~flight/python/policy/ Up to now, that Wiki lacks memberships functions, i.e. you can only post anonymously. If somebody gives me a quick tutorial how to add membership functions to a ZWiki site in ten minutes, I'll do that. Until then, please include your name in all comments. If you're not used to Wiki sites, feel free to look at http://dev.zope.org/. They are using wikis for all discussions about Zope development. The ZWiki site, zwiki.org, seems to be down at the moment. Regarding the packaging: I'm working on the 2.1.1 packages. I'm currently changing the build environment in debian/, so that templates are used for most control files. That makes it very easy to package stuff under names as python2.1-base etc., and still, with one change in debian/rules, the packages build as python-base etc. That's an very necessary step to make maintenance of multiple Python versions easier. A snapshot of Python 2.1.1 (python2.1-*) and Python 1.5.2 builds (python1.5-*) using the new system can be previewed in http://people.debian.org/~flight/python/snapshot/ The 2.1.1 packages in fact are already installable; the 1.5.2 packages don't install, since the dependencies are not yet set up in order to make an upgrade from the python 1.5.2 packages. Still, all packages are buggy (2.1.1 fails five regrtests!), and only intended as preview. Since time is now very pressing (yes, I know, that's my fault), I'm afraid we won't be able to make the big jump to a halfway perfect solution for all the discussed problems. From the discussion, the most pressing problem is how we tackle the upgrade of potato python-* packages, especially when they have incomplete/incorrect dependencies. While I still think it's necessary that we find a solution how a Python extension package can install and register itself for a variety of different Python versions, I haven't seen a solution that's clean and obvious, easy and robust to implement and that's something we won't regret in a few months. My proposal for woody: Python 1.5.2 is renamed to python1.5-*. Python 2.1.1 will be shipped as python2.1-*. Do we need python2.0-* as well ? Then, we still have to agree on a strategy how to set up the dependencies, in order to make the upgrade work in an intuitive way. For maintainers of Python extension modules, this would mean that they would have to build one package for each included Python version, e.g. python1.5-mysqldb, python2.0-mysqldb and python2.1-mysqldb. There would be no python-* packages in woody!!! With that setup, we could use our existing, well-tested system, and still would resolve a few critical problems that we're currently facing due to the ambigous package names python-*. In a later future, I'd like to set up a robust system that makes it possible to provide python-* packages that work for all installed Python versions. Maybe like the emacsen system. Gregor
Re: python2.1 et al.
* Radovan Garabik [EMAIL PROTECTED] [010726 18:49]: On Thu, Jul 26, 2001 at 05:24:04PM +0200, Gregor Hoffleit wrote: Then, we still have to agree on a strategy how to set up the dependencies, in order to make the upgrade work in an intuitive way. For maintainers of Python extension modules, this would mean that they would have to build one package for each included Python version, e.g. python1.5-mysqldb, python2.0-mysqldb and python2.1-mysqldb. Is there a reason for python1.5 existance _other_ then supporting older application? If not, I'd propose to have packages named python1.5-foo for python1.5, and python-foo for current version of python (i.e. 2.1), and for packages that do not care about python version. You will have to do some work anyway for each new feature release, if you're maintainer of a Python extension package. When I release 2.1.1 packages, you'll have to change your packages in order to somehow make the stuff available under /usr/lib/python2.1/site-packages. According to python-dev, there are *no* serious Python things that do not care about the Python version. (Personally, I'd HATE to 1) rename my package whose upstream name is python-utmp, 2) maintain two versions of it. Ok, I'll probalby have to... sigh) Another problem would be that every time a new feature version of Python is released (i.e. 2.1, 2.2), *I* have to rename the packages of the current Python version from python to pythonX.Y ;-). More important, the names python-base, python-tk etc. are already used in dependencies of potato packages. There are many Python extension modules in potato that have a dependency like python-base (= 1.5), but install stuff in /usr/lib/python1.5/site-packages. If we ship python-base and python-tk 2.1.1-1 in woody, then a simple apt-get install python-base python-tk will render all these packages unusable. Seriously, as I wrote, I don't subscribe to that extreme pessimism that I felt on python-dev. I think we can come up with a solution like the emacsen setup that makes it possible and easy to write a package python-utmp that registers and installs for all installed Python versions. But, I'm afraid, we will have to use something like a registry. There's a discussion on the Distutils SIG as well about a Package DB (which I haven't followed). That sounds like something that might help us, too. But I'm afraid it's way too late to implement this for woody. Instead, for woody I would try to find a setup that's mostly neutral, that should mean it leaves us much room to move. That seems to be the case for the python1.5/python2.1(/python2.2) naming scheme, and that's why I would prefer it. There would be no python-* packages in woody!!! Why (even considering your proposal above)? If there is a package called python-foo, which is pure python and works with both 1.5 and 2.1, should there be 2 packages made of it? (different only in names) But how would a package look that works with 1.5 as well as 2.1 ? Would you install the stuff in /usr/lib/python2.1/site-packages, and use symlinks for all .py files in /usr/lib/python2.1/site-packages ? Or would you duplicate the .py files in both site-packages trees ? New problems arise when I would create (experimental) packages of Python 2.2a1 for developers, so that we have three different versions at the same time. The feedback from python-dev was that it's indeed possible that
lintian: Should check dependencies for python packages
Package: lintian Version: 1.20.13 Severity: normal Lintian should include a check for correct dependencies of Python extension packages. The rule is like follows: Any package that installs stuff in /usr/lib/pythonX.Y/site-packages must have a dependency on: python-base = X.Y, python-base X.(Y+1) Thanks, Gregor
Re: python 'release21-maint' branch GPL with changed license
On Sat, Jul 07, 2001 at 07:08:51PM +0200, Matthias Klose wrote: Looking at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/LICENSE?only_with_tag=release21-maint you see that the changed license is in the python-2.1 maintanance branch as well. What about python packages based on this branch? I has the advantage of a recent version which can go into woody. I guess this answers that question: On Wed, Jul 04, 2001 at 01:31:21PM +0200, Gregor Hoffleit wrote: First of all the good news: You have managed to talk me into making the big step, and going right to the 2.1.1 CVS branch. Thomas Wouters (release czar for Python 2.1.1) assured me that 2.1.1 will be released before the freeze, and Guido heavily supported that. For more information, read that Status report on python2 transition thread. Gregor
Re: Status report on python2 transition
On Thu, Jul 05, 2001 at 07:13:54AM -0700, Neil Schemenauer wrote: Gregor Hoffleit wrote: Until now I had the impression that in general it's not necessary to have more than one Python version on your machine at the same time (except perhaps you're a Python core developer). Feedback from python-dev though was that it's definitely necessary to allow and support multiple concurrent versions of Python even on production machines. This doesn't imply that Debian has to support multiple concurrent versions of Python _packages_. To me, it means Debian should play nicely if you want to install other versions of Python in /usr/local or wherever. Currently it does not. Sorry ? What problems do you have installing Python 2.1 in /usr/local on a Debian system ? For one, I've changed my mind and accepted that there's a need to support multiple concurrent Python versions in Debian. Woody should have one core Python package (python-base_2.1.1-X). Extension modules should have a versioned dependency on the interpreter (ie. python (= X.Y)). Pure Python packages should only have a dependency on python or perhaps python (= X.Y). That's our current setup (well-behaved packages should have a dependency on python-base = 1.5, python-base 1.6). Look at the mess we're now running into, now that we want to upgrade this to Python 2.1.1. All packages have to be recompiled at once. Gregor
Re: Status report on python2 transition
On Thu, Jul 05, 2001 at 07:56:57AM -0700, Neil Schemenauer wrote: Gregor Hoffleit wrote: Sorry ? What problems do you have installing Python 2.1 in /usr/local on a Debian system ? Sometimes /usr/local/bin/python is used instead of /usr/bin/python. For example, dput uses #!/usr/bin/env python. Also, its postinst script it does: python -c 'from compileall import main;main()' -q $DIR which fails if a stock distribution of compileall is used (it doesn't support -q). I've seen other packages do this as well. Ok, I see. The postinst problem is my fault; the scripts certainly should use an explicit path to a well-known python installation that does support this. I just browsed /usr/bin and /usr/sbin, and indeed there are plenty of scripts that use #!/usr/bin/env python. If we consider the possibility that somebody installs non-compatible Python versions in the path, then these are bugs in that packages. Thanks for pointing this out! I guess we really, really need a Debian Python policy that mentions all these things. That's our current setup (well-behaved packages should have a dependency on python-base = 1.5, python-base 1.6). Look at the mess we're now running into, now that we want to upgrade this to Python 2.1.1. All packages have to be recompiled at once. What's a well-behaved package? Extension modules depend on the version of Python that they were compiled against. If you upgrade the interpreter you must upgrade the extensions. How are you planning on avoiding this? Binary extension modules depend on the version of Python that they were compiled against (a different micro version should be ok, AFAIK). Pure Python extension modules not necessarily depend on the version of Python they were packaged for. There's a tricky situation wrt. byte-compilation in postinst, but currently, this shouldn't hurt us (since on upgrading python-base, site-packages is re-byte-compiled by an compileall.py call). s/not well-behaved/buggy/: Any binary Python extension package that doesn't depend on 'python-base = X.Y, python-base X.Y+1' is buggy (a few weeks ago I asked in debian-python for volunteers that filed bug reports against those packages; don't know about the current status, though). A pure Python extension package that installs stuff in /usr/lib/pythonX.Y and doesn't have this dependency is also buggy. A pure Python extension package that installs stuff in site-python doesn't need a versioned dependency. Gregor
Re: Status report on python2 transition
On Thu, Jul 05, 2001 at 05:33:37PM +0200, Gregor Hoffleit wrote: On Thu, Jul 05, 2001 at 07:56:57AM -0700, Neil Schemenauer wrote: That's our current setup (well-behaved packages should have a dependency on python-base = 1.5, python-base 1.6). Look at the mess we're now running into, now that we want to upgrade this to Python 2.1.1. All packages have to be recompiled at once. What's a well-behaved package? Extension modules depend on the version of Python that they were compiled against. If you upgrade the interpreter you must upgrade the extensions. How are you planning on avoiding this? I guess I missed your point here. Binary extensions certainly need to be rebuilt once for every Python feature version. Pure Python packages not necessarily would need to be rebuilt (if the code was cross-version compatible). That was the point of my original inquiry on python-dev. Possible solutions for cross-version compatible code would be installation in a version-neutral directory (e.g. /usr/lib/python/site-packages) and either adding this to sys.path (has been depreciated in python-dev) or somehow arranging symlinks into the actual versioned site-package directories. In this case, we would have to setup something comparable to the Debian emacsen's registration system. Gregor
Status report on python2 transition
First of all the good news: You have managed to talk me into making the big step, and going right to the 2.1.1 CVS branch. Thomas Wouters (release czar for Python 2.1.1) assured me that 2.1.1 will be released before the freeze, and Guido heavily supported that. Now for the bad news: I don't have any conclusive plan how to manage transitions for future Python feature releases, like 2.2, 2.3 and so on. Until now I had the impression that in general it's not necessary to have more than one Python version on your machine at the same time (except perhaps you're a Python core developer). Feedback from python-dev though was that it's definitely necessary to allow and support multiple concurrent versions of Python even on production machines. If we're going to support this in Debian regularly, then it get's even much more complicated than with our current setup of python-* and python2-*. Please have a look at the python-dev archives for the full discussions: http://mail.python.org/pipermail/python-dev/2001-July/015715.html The discussion -- - Python has now a reliable, well-behaved version numbering policy: - feature releases: may introduce new features, may change the bytecode format. The minor (middle) version number changes (e.g. 1.5.2 - 1.6, 2.0 - 2.1). - micro-versions: bug fixes only, bytecode format can't vary. Only the micro component of the version number changes (e.g. 1.5.1 - 1.5.2 or 2.0 - 2.0.1). - site-python is depreciated; Python code should go into a version specific directory (originally I thought I might use site-python for all packages--would make Python updates very much easier): Greg Ward [EMAIL PROTECTED]: Oh yeah, another thing I vaguely recall from the pre-Distutils-0.1 era: Guido doesn't (didn't?) like site-python and wanted to deprecate it. ... BTW, I'm skeptical about keeping .py and .pyc code in a non-Python-version-specific directory (ie. site-python). Debian's bytecode-recompilation at installation time scheme sounds cool, but the desire/need to have multiple Python versions available kind of nixes it. Fred L. Drake, Jr. [EMAIL PROTECTED]: Another reason not to use site-python is that it is actually still hard to write cross-version Python code -- there are enough differences that any substantial volume of code (and in Python, you don't need many KLoC to get substantial code!) is bound to encounter a few, especially if you get used to using only Python 2.0+ -- it's easy to get used to features like string methods, list comprehensions, and augmented assignment! The site-packages directory was introduced to avoid the deficiencies of the site-python directory. Guido van Rossum [EMAIL PROTECTED]: Indeed, /usr/local/lib/pythonmajor.minor/site-packages/ is where site packages should go. - Support for multiple concurrent Python versions on the same system is necessary: Barry A. Warsaw [EMAIL PROTECTED]: GH Seriously, does anybody (besides the Python developers) feel a GH need to have multiple Python versions on the same system ? Yes, definitely as both a Zope and Mailman developer wink I need multiple Python versions. But I suspect even normal users of the system will need multiple versions. Different Python-based apps are requiring their users to upgrade Python on their own schedule, so multiple versions will still be required. Fred L. Drake, Jr. [EMAIL PROTECTED]: Another excellent reason to support multiple versions! As more widely distributed applications are written using Python and don't want to include the interpreter, this becomes a more noticable issue. - If we want to support concurrent Python versions and still don't want to have multiple packages for each Python extension, a setup like the Debian Emacsen system might be a solution: Thomas Wouters [EMAIL PROTECTED]: None are compatible. This might change, but I don't think so -- I think the CVS tree already has a different bytecode magic than 2.1, though I haven't checked. Perhaps what Gregor wants is a set of symlinks in each python version's site-packages directory, to a system-wide one, and a 'register-python-version' script like the emacs/xemacs stuff has that adds those symlinks. That way, the .pyc/.pyo versions would remain in the version-specific directory. Conclusions --- I have no final conclusion what that means for our Debian Python policy. For one, I've changed my mind and accepted that there's a need to support multiple concurrent Python versions in Debian. The way we're doing this currently for python-* and python2-* is certainly no good--it means duplication of work, and it's a mess when it comes to installing a new version. If it's possible to do this before woody, by any means I would go that way. Everything else will be a mess later on. We should look at the perl packages (they support
Python 2.0.1; transition plans for woody
Hi, Python 2.0.1 is out, finally with a GPL compatible license. Zope 2.3.3 works fine with Python 2.0; I'm not aware of any problems with Debian packages wrt. Python 2.x. That nullifies all reasons for the existance of dual Python packages in Debian (cf. /usr/share/doc/python2/README.why-python2) IMHO this is the point where we should make a big step, and enforce a quick transition of the archive to Python 2.0.1. This would mean that I upload new versions of the Python packages: (1) python2 (python2-base etc.) would be removed (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16 (3) A new set of legacy packages python15 (python152 ???) for those who think that they depend on the old version 1.5.2. The transition would not be simple, though. Nearly all Python packages (to be exact: those who install things in /usr/lib/python1.5, those who build binary extension modules, and those who link with libpython1.5) would have to be modified and rebuilt. Those packages that provide both python2-* and python-* versions would have to be modified to instead build python-* and python15-* versions; the dependencies of those packages would need closer inspection. Still I think it is much preferable to make this transition before the release of woody; when we release woody with python2-* packages this will be a big unnecessary burden for the next release; when we make the migration now, only people who are using unstable might be hurt during the transition process. What do you think ? Gregor
Re: Python 2.0.1; transition plans for woody
On Tue, Jun 26, 2001 at 12:47:28AM +1000, Anthony Towns wrote: On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote: This would mean that I upload new versions of the Python packages: (1) python2 (python2-base etc.) would be removed (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16 (3) A new set of legacy packages python15 (python152 ???) for those who think that they depend on the old version 1.5.2. The transition would not be simple, though. How does this affect upgrades? Will potato packages that depend on python work with python 2.0.1 packages in general? What about ones that put stuff in /usr/lib/python1.5? If not, what will you do to ensure partial upgrades work correctly? If so, that may give us an easy out for transitioning the python2 packages. We have an option here: With the default setup, stuff in /usr/lib/python1.5/site-packages would be ignored by 2.0.1. In order to make the transition easier, we might decide to append /usr/lib/python1.5/site-packages to the sys.path, though: Almost all pure Python modules that are currently installed in the python1.5 directory will work with 2.0.1; Python 2.0.1 is almost completely backwards compatible, and one might consider all remaining problems bugs in the potato packages. Binary modules in /usr/lib/python1.5/site-packages won't work. Nearly all Python packages (to be exact: those who install things in /usr/lib/python1.5, those who build binary extension modules, and those who link with libpython1.5) would have to be modified and rebuilt. Those packages that provide both python2-* and python-* versions would have to be modified to instead build python-* and python15-* versions; the dependencies of those packages would need closer inspection. There are only a dozen or so packages in unstable/i386 that have versioned depends on python2 related stuff; anything else should be able to be handled with provides:. IMHO that's the most pressing problem, and has to be inspected carefully: Packages that have unversioned depends on python or python-base, but do in fact depend on Python 1.5.2. They would break after an upgrade to What do you think ? If you can make upgrades work; if you can not break too many people's testing or unstable systems; and if you can get everything rewritten/rebuilt relatively quickly, I'd say it's worth doing. A first try at an transition plan: (1) I upload python 2.0.1-1. python-base 2.0.1-1 provides 'python', 'python2' and 'python2-base'. /usr/lib/python1.5/site-packages will be appended to the sys.path. A bug will be filed against the archive to remove the python2 package. Most 'python-*' packages will continue to work in this setup. python2-* packages should continue to work as well. python-* Packages with binary extension modules will break. (2) python-* packages that broke should be rebuilt against the Python 2.0.1 package as fast as possible. Aggressive NMUs should be allowed here after a few days. (3) Bugs should be filed against all remaining packages that install stuff in /usr/lib/python1.5. They should be rebuilt against Python 2.0.1. Finally, no woody package should install stuff in /usr/lib/python1.5. I'm pretty sure that I miss some crucial points with this plan, though. Please correct me where due. My impression is that during a transition period, unstable's Python packages will be quite unstable. Still, rebuilding the packages should be a very simple thing in most cases, so the only crucial thing is that either maintainer act quickly, or we're going on NMU aggressively. One remaining problem is how to handle partial upgrades of a potato system: To handle this well, python-base 2.0.1-1 would have to include a list of conflicts against all potato packages that won't work with the new python packages (I guess in the end that's about a dozen packages). Gregor
Re: Python 2.0.1; transition plans for woody
On Mon, Jun 25, 2001 at 05:37:36PM +0200, Radovan Garabik wrote: I agree, but... why not wait until python 2.1.1 is released? (or, if we just discuss things a bit, it will be released before any action is taken and we can jump right to it :-)) You still need to modify packages when going from 2.0.1 to 2.1.1 I'm afraid that if we wait for 2.1.1, it will be to late to make the complete transition for woody. You're right, though, that with the current setup of the packages, 2.1.1 again will make a small transition necessary. We have to discuss the policy of dependencies and paths for the Python packages at some point. Gregor
Re: python-2.1 for unstable?
On Sun, Jun 03, 2001 at 07:06:09PM +0200, Florian Weimer wrote: Gregor Hoffleit [EMAIL PROTECTED] writes: This is probably correct, but it is completely irrelevant in our case. Some parts of Python 2.1 are still covered by the GPL-incompatible CNRI license, so Python 2.1 as a whole is not GPL compatible. I'm glad to correct you, but according to Guido and Eben, that's not the case. The only remaining problem with the CNRI license was the choice-of-law clause. Apparently Eben said to Guido that for GPL compatibility only the choice-of-law in the topmost license on the stack matters, and that's the PSF license. I'm no lawyer, so don't ask me why. This means that you can incorporate GPLed code whose copyright is owned by the FSF into Python, but other copyright owners might still ask you not to do this. This reminds me of the ipfilter license blowup (cf. http://lwn.net/2001/0524/#ipfilter), where the ipfilter author appearently claimed that a standard BSD license doesn't permit modification of the code. Certainly it's not unthinkable that people use the GPL for their own code, but don't agree with the FSF that this new Python license is compatible with the GPL. I would tend to think, though, that the vast majority of authors of GPL code will agree with the interpretation of Moglen and RMS. Therefore I can't see your point here. Gregor
Re: python-2.1 for unstable?
On Thu, May 24, 2001 at 01:02:29PM +0200, Florian Weimer wrote: Gregor Hoffleit [EMAIL PROTECTED] writes: I talked to RMS, Eben Moglen and GvR. The bad news: According to RMS+Moglen, the license used in Python 2.1 still is not yet compatible with the GPL. The good news: The PSF decided to drop the choice of law clause. A modified license is in CVS, and, according to Guido, will be used for the maintenance releases 2.0.1 and 2.1.1. The bright news: Moglen himself told me that the license text in CVS is compatible with the GPL. This is probably correct, but it is completely irrelevant in our case. Some parts of Python 2.1 are still covered by the GPL-incompatible CNRI license, so Python 2.1 as a whole is not GPL compatible. I'm glad to correct you, but according to Guido and Eben, that's not the case. The only remaining problem with the CNRI license was the choice-of-law clause. Apparently Eben said to Guido that for GPL compatibility only the choice-of-law in the topmost license on the stack matters, and that's the PSF license. I'm no lawyer, so don't ask me why. I have sent the file python/dist/src/LICENSE from CVS to Eben Moglen (which contains the complete stack of licenses), and he replied: Yes, you can say that I have advised you that if this is the license for Python 2.1.1 it would be a GPL-compatible release. Eben Moglen is the legal advisor of the FSF, so I think we could take his word for granted: If Python 2.1.1 will be released under the license currently in CVS, then it will be compatible with the GPL, according to the judgement of the FSF. Gregor
Python 2.0.1 release schedule ?
Hi Moshe, I'm trying to lay out a schedule for the Debian Python packages in woody. My plan would also depend on the release date of Python 2.0.1. Thomas Wouters wrote: Another couple of weeks at least, before a release candidate. It also depends on Moshe; if he actually releases 2.0.1 anytime soon, I'll hold off on 2.1.1 a bit longer. Do you think 2.0.1 might be out before July 1 ? IMHO this is the last date at which we could start a migration of the python2-* packages to the name python-* (the python-* 1.5.2 packages would be renamed python1.5-*, just for completeness). Gregor
Experimental Python 2.1 packages, release plans
I have uploaded experimental Python 2.1 packages. Grab them at http://people.debian.org/~flight/python2/ The packages are completely untested. I had to re-implement the building of the shared library (just finished), the remainder of the packages is mostly unchanged. In a few hours, I will leave to Illinois for two weeks. Thomas Wouters currently is preparing the Python 2.1.1 maintenance release, which will be the first GPL compliant release of Python 2.x (provided nothing desastrous happens). At the same time, Moshe Zadka is working on a 2.0.1 release, which will also be GPL compatible. Quoting Thomas: Another couple of weeks at least, before a release candidate. It also depends on Moshe; if he actually releases 2.0.1 anytime soon, I'll hold off on 2.1.1 a bit longer. A few days ago, I quoted from ajt's release schedule. Now if either Python 2.0.1 or 2.1.1 would be out before July 1, I would like to try and make a hard migration: Python 1.5.2 would be re-packaged as python1.5, and the then-GPL-compliant would be packaged under the name python. As a consequence, nearly all Python packages would have to be re-packaged. The goal should be to provide a smooth migration from potato to woody. This would involve a quite work-intensive period for the maintainers, but IMHO for the user it would be the best solution. I wouldn't like to start this migration, though, before Python 2.x is really GPL compliant. I don't like to release python-* packages with woody which are encumbered by license problems. I.e. I don't want to release woody with 2.0 or 2.1 as python-*, and I would prefer to release woody with python 2.0.1 and python1.5 1.5.2 over releasing woody with python2 2.1 and python 1.5.2. Now the problems start if neither 2.0.1 nor 2.1.1 would be ready in time. If it's obious early that the won't be ready in time, we could start to migrate the python2 packages to Python 2.1. Anyway, while I'm away, perhaps someone could start to audit the packages that depend on Python, and file bugs for all packages that don't have a correct, explicit versioned dependency on python-base like Depends: python-base (= 1.5), python-base ( 1.6) or Depends: python2-base (= 2.0), python2-base ( 2.1) Gregor
Re: python-2.1 for unstable?
Sorry guys for the silence. I had to go through upgrading my hardware, upgrading my line setup to a new provider with a flat fee, and finally, some real world work kept me busy. On Mon, May 21, 2001 at 10:35:15PM +0200, Tom Cato Amundsen wrote: On 21 May 2001 20:57:34 +0200, Matthias Klose wrote: I really would like to see 2.1 in the next Debian release. I'd like to ask Gregor (the maintainer) for an upload schedule, so that other maintainers can rely on this to get their packages ready for the next release as well. Are there still license issues which will be resolved in upcoming releases? Should we skip 2.1 and hope that 2.2 gets I don't think 2.1 is much better than 2.0 when it comes to GPL compatibility. But the roumurs say that there will be a 2.1.1 release that is fixes this and a few other bugs. I think the new (2.1.1) license was blessed by rms... Sorry, I don't remember where I read this. Here's a quick update: I talked to RMS, Eben Moglen and GvR. The bad news: According to RMS+Moglen, the license used in Python 2.1 still is not yet compatible with the GPL. The good news: The PSF decided to drop the choice of law clause. A modified license is in CVS, and, according to Guido, will be used for the maintenance releases 2.0.1 and 2.1.1. The bright news: Moglen himself told me that the license text in CVS is compatible with the GPL. Guido asked for our release plan. He'd like to inform the release managers of 2.0.1 and 2.1.1, and seemed to be quite interested to make sure that the next release of Debian will contain a fixed version: On Tue, May 08, 2001 at 04:32:13PM +0200, Gregor Hoffleit wrote: On Tue, May 08, 2001 at 09:48:38AM -0500, Guido van Rossum wrote: That would be great! When should 2.1.1 be out in order for it to be the default version? If I have a specific date I can put some pressure on the folks responsible for assembling the release! The earlier, the better, is all I can say ;-) According to our release manager, Anthony Towns [EMAIL PROTECTED], the critical dates for the next release or like this: * Policy goes into debugging mode on 1st June, and no further changes may be made after about 20th June. * Base packages must have all release-critical bugs fixed by 1st July, and no further changes may be made after about 20th Jul$ * Boot-floppies, standard packages, task packages, and packages included in tasks or in boot-floppies need all their release-critical bugs fixed by 1st August, and no further release-critical bugs fixed by 1st August, and no further changes may be made to them after about 20th August. * The remaining packages (optional, extra) need their release-critical bugs fixed by 1st September, and no further changes may be made to them after about 20th September. * We release early to mid October. Again this is still fairly optimistic, and not necessarily going to happen. (Hi Slashdot.) Looks like plenty of time, but due to the big tree of dependencies, the timeframes are still quite tight. python is now a 'standard' package in Debian. Therefore I should not make any critical changes on the default Python packages after August 1. Currently, the 'default' Python packages are built from Python 1.5.2. A problem is that it would take some time of preparation after the release of Python 2.1.1 to change the default Python to 2.1.1 (coordinating uploads of packages with new dependencies, testing of the dependencies, etc. pp.). Given that the above dates all hold true: If Python 2.1.1 is out by July 1, it should be possible to include it as default Python version in the next release. (And, it would be ready in time for the European Python Meeting in Bordeaux ;-). If it's out by mid-September, it still could be included, but only as second choice. Python 1.5.2 would then be default. Still, I would very much appreciate if it was released earlier, since that would allow for a much smoother transition and for a better testing.
Re: Python 2.1 out
On Thu, Apr 19, 2001 at 10:04:24AM +0200, Florian Weimer wrote: D-Man [EMAIL PROTECTED] writes: On Wed, Apr 18, 2001 at 10:25:52PM +0200, Florian Weimer wrote: | Steve Purcell [EMAIL PROTECTED] writes: | | Licenses aside, there are the same technical issues with Python 2.1 | as with Python 2.0. | | Python 2.1 seems to print some diagnostic messages during run-time; | this might affect scripts which are invoked in cron jobs. Are you sure they aren't warnings regarding code that will not work as expected in future versions? Yes, I think so. But that doesn't make them less annoying. ;-) Could you mail an example of such a message ? Gregor
Somebody interested in packaging Jython ?
Hi, the BTS still holds my ITP to package JPython (nowadays called Jython). Jython is an implementation of the Python language in pure Java, see http://www.jython.org/. As much as I'm interested in the issues involved with a painless coexistence of C-Python and Jython on Debian, I haven't really had time, though, to track the state of Java on Debian, and therefore I'm lacking many clues on how to package Jython for Debian in the best way. Perhaps there's an volunteer somewhere who'd like to give Jython a look and start packaging it. I think since we still have no Python policy, the final packaging should be coordinated with the C-Python packages, so that we can re-use as much of the Python library as possible (I don't like to have jython variants of pure Python packages, adding to the python- and python2- variants we're already forced to have). Gregor
RFC: python-base, debconf and py/pyc files
Hi, currently, our Python packages mostly ship .py files and compile them into .pyc files at run time in order to save space in the debs. There's no reason, though, to keep the .py files on machines that only deploy software[1] I wonder if I should debconf-ify python-base and add an debconf option that sets a system-wide policy about how to deal with .py/.pyc files. That could be one of: * install both .py and .pyc files * install only .pyc files * install only .py files The postinst scripts of the various python packages would then enforce this policy according to the global debconf option. Packages could also provide private debconf options to override this. Any comments ? Gregor [1] The iPAC Python packages contain a completely stripped-down version of the Python packages.
Re: 4Suite in Debian ?
On Wed, Feb 28, 2001 at 09:00:38AM -0800, Sean 'Shaleh' Perry wrote: On 28-Feb-2001 Jérôme Marant wrote: Hi, Would you think great to have 4Suite (http://www.4suite.org) in Debian ? As 4DOM was included in Python-xml, we could simply remove it from 4Suite add a dependency instead. I looked into packaging it for narval. However, the version of xml it wants versus what is in Debian were conflicting at the time. I no longer have the time to work on this, so feel free. Yep, please go ahead. I remember that some time ago somebody else volunteered, but appearently, it didn't get off. Gregor PS: How about the various XML tools by Lars Marius Garshol (http://www.garshol.priv.no/download/), e.g. xmlproc, pysp, XSA etc. ? And the stuff by Geir O. Grønmo (http://www.infotek.no/~grove/), xmarch, tmproc and GPS ? I'm not enough into XML to evaluate if they could have a broader audience, but they looked interesting to me. Or are they somehow superceded by the recent PyXML releases ?
Re: [Python-Dev] Re: Python 2.0 in Debian
On Fri, Feb 16, 2001 at 04:24:03PM +0100, M.-A. Lemburg wrote: Gregor Hoffleit wrote: Is there any reason for you to include this choice of law clause anyway, if you don't live in Virginia ? I have to make the governing law the German law since that is where my company is located. The text from my version is: This License Agreement shall be governed by and interpreted in all respects by the law of Germany, excluding conflict of law provisions. It shall not be governed by the United Nations Convention on Contracts for International Sale of Goods. Well, I guess that beyond my legal scope (why is it reasonable to exclude that UN Convention ?), and certainly it gets quite off-topic on this list. Is it really necessary to make a choice of law, and how does it help you? (I mean, the GPL, the X11 license, BSD-like licenses, the Apache license and the old Python license all work without such a clause). AFAIK, RMS and his lawyer say that any restriction on the choice of law is incompatible with the GPL, therefore I don't see how you could include such a clause in the license and still make it compatible with the GPL. If you're interested in some opinions from Debian, would you mind to send a mail to debian-legal@lists.debian.org and ask there for comments ? Have you considered mailing to [EMAIL PROTECTED] and ask them for their opinion ? Does anyone know of the wording of the new 1.6.1 license ? I didn't even knew there will be a 1.6.1 release. Will there be a change in the license ? Gregor
Re: Bug#82088: Request build against tcl/tk8.3
Hi Mike, On Sat, Jan 13, 2001 at 01:44:36PM -0800, Mike Markley wrote: You may want to hold off on that for a few days while I work out the strange bug that's preventing tcl8.3 from building only on m68k. That bug is the principal reason that tcl8.3 and tk8.3 aren't yet in testing, but Roman has promised an account on kullervo to try to figure it out. are you making any progress on this thing ? I should upload a new revision of the Python packages, and I'm wondering what to do about this. Gregor
Re: Bug#82088: Request build against tcl/tk8.3
On Sat, Jan 13, 2001 at 04:41:09AM -0600, Gordon Sadler wrote: Package: python2-tk Version: N/A; reported 2001-01-13 Severity: normal I haven't installed these from unstable yet. But I have had python1.52 and python2 from p.d.o/~flight, both downloaded as source and rebuilt locally with tcl/tk8.3. Now that python2 is coming into unstable, is there any reason we can't finally update to tcl/tk8.3? It doesn't take much work, change the Setup file to point to correct lib dir, _tkinter.c, and tkappinit.c . Would be very appreciated, it's annoying to keep multiple versions of libraries around without good cause. I'm all open for this, but I don't know what is best. Python 1.5.2 currently is built with Tcl/Tk8.0, since back in June I was told by both Fredrik Lundh (Tkinter) as well as our Tk maintainer David Engel, that using 8.0 would be the safest bet. Now I just saw that, starting with Python 1.6, Misc/NEWS says that we're now prepared for Tcl/Tk 8.2 and 8.3; I hadn't noticed that before. What makes me a little bit unsure is that Tcl/Tk8.3 isn't yet in testing, but only in unstable. This means that python2 will sit in unstable until tk8.3 moves to testing. Also, the vast majority of packages using Tk in sid still depend on tk8.0 (60 packages), compared to tk8.2 (19 packages) and tk8.3 (18 packages). Anyway, I guess I'll build the next package revision with Tcl/Tk8.3. I'm also working on backporting Tkinter from Python 1.6a2 to the python-tk package in order to make the transition complete (and in order to resolve me from the task of installing/deinstalling the correct tk8.x-dev packages each time I'm building python or python2 ;-). Or does somebody think it's worthwhile to provide python2-tk8.x packages ? Since the tk8.0-dev and tk8.3-dev still seem to conflict, the building of the packages would be the biggest problem. Gregor
Re: Packaging of more zope products
On Thu, Feb 17, 2000 at 11:39:06AM +0100, Christian Leutloff wrote: for ZOPE exists many many so called products that extends the functionality. Some are already available for Debian: zope-mysqlda, zope-pygresqld, zope-siteacces, zope-tinytable. Are there any plans to pack more of the available products? Are there any reasons why it hasn't happened so far (except nobody wants to do the work)? Time (missing, that is) is certainly one reason. Another reason I didn't package any other things is that I hoped to come up with a generic zproducttodeb tool (cf. gtkthemetodeb) that would help packaging this stuff. IMHO a problem with packaging Zope products is that most of them currently are very small, and packaging each of them introduces a quite a big overhead. Recently, there was a discussion on the Zope list about Zope packs--sounded like a generic package format for Zope products--if there was a decent solution for this, I'd certainly prefer this about manually packaging each single product. Then, somebody from zope.org/Members wrote a script to package a big number of Zope products in a single .deb file. Gregor
Do we prefer Tk8.0 or 8.2 ? (for python-tk, that is)
I have a quite urgent problem while polishing the new Python packages: Do we prefer our packages to use tk8.2 or on tk8.0 ? Python's Tkinter extension module (package python-tk) needs to be linked to libtk. I wonder if I should stay with libtk8.0 or switch to libtk8.2 for the final potato package, as wishlist bug #46705 suggests. A little bit more of half of the Tk packages in potato seem to use tk8.0, while the other half already uses tk8.2. Only three packages would need to be rebuilt after an switch to libtk8.2, so that's possible (python-imaging-tk, python-imaging-sane and sketch). I'm also thinking about providing two Tkinter packages, python-tk and python-tk8.2 (resp python-tk8.0 and python-tk). The problem with this is that the alternative package would have to be built from a pristine source package (tk8.0-dev and tk8.2-dev conflict), and that both packages either would have to conflict with each other, or I had to come up with some custom solution to make them coexist (renaming the module to _tkinter82, or using alternatives). Any opinions ? pgpVoQzM7PIWp.pgp Description: PGP signature
Trouble with libapache-mod-python: Any volunteers ?
Hi, I keep getting grave bug reports on the libapache-mod-python module. I don't use this module myself anymore, and I don't have much time to spend on it nor do I have much experience with debugging Apache modules. If somebody is interested in taking over the package, or at least debugging it, please tell me. I'm afraid I'll have to orphan the package otherwise. Gregor pgpK9ZGo64zVl.pgp Description: PGP signature
Re: Zope in Potato ?
On Wed, Jul 14, 1999 at 10:29:08AM -0700, Mike Orr wrote: On Wed, Jul 14, 1999 at 10:07:47AM -0500, Debian Developer wrote: Anybody thinking of adding zope www.zope.org into Potato ? No, but it would be great if we did. I'm not enough of a programmer to do this, though. This is my priority #2 task after pushing out the fixed python packages. I'll try to finally get out the package by the end of this week. I hoped Zope2 would be read for prime-time a little bit sooner, but since it's still in alpha, I guess I'll really have to go with Zope 1.10.3 or we won't get it in potato. Gregor
Re: Experimental Python 1.5.2c1 packages available
On Wed, Apr 14, 1999 at 09:15:53AM +0200, Paul Stevens wrote:
I seem to remember there is now a complete info set, which I sure
would like to install for use within {x,}emacs, but I don't know how
many of debian/python users would find a need for it.
I do. Please do include info docs.
I will.
Earlier python-doc packages already included info docs, but they had
been unavailable for 1.5.1, therefore they aren't included currently.
The docs are quite big (700k resp. 450k for html and info
gzipped). Is there support for splitting them in separate packages ?
Then, is there also a need for postscript resp. pdf packages ?
Gregor
Experimental Python 1.5.2c1 packages available
I have put together a set of experimental Python 1.5.2c1 packages. To use them with apt, try the following line: deb http://master.debian.org/~flight/python ./ They are also available via plain http (this time, I included a proper index.html so that it should be possible to download them with recursive wget as well): http://master.debian.org/~flight/python/ New features: * Python 1.5.2 release candidate 1. * libpython1.5.so reworked. Please report any anomalities! If I don't get any negative feedback, the next potato packages will use a shared libpython for the first time in Debian history ;-) * break sketch 0.5.4. This is a problem with the new multi-threaded Tkinter and sketch' Pax modules. Sketch' author will try to fix this, in the meantime sketch will have to provide an alternative python-tk-nothreads package. Not yet: * The great package renaming. * jpython * python-doc 1.5.2. Is html enough, or should I also include python-doc-ps and python-doc-pdf. The next release of JPython will have a free license. Since there are some build dependencies on non-free software, JPython probably will go into contrib at first. Nevertheless, this will make it necessary to have a common python library package (python-lib ?). Again, any Gregor
Experimental python 1.5.2b2 packages on master
Hi, I have finally put completed a first stage of experimental Python 1.5.2b2 packages. Since the packages don't have yet release quality, I have put them on master. News: - Python 1.5.2b2 - python built with shared library libpython1.5.so (this is highly experimental; I would welcome any comments) - apart from that, only small fixes compared to 1.5.1-7. Get them from this URL (I have a little of hope that the second line will work for apt): http://master.debian.org/~flight/python/ deb http://master.debian.org/~flight/python ./ (or http://www.mathi.uni-heidelberg.de/~flight/debian-private/python/) I intend to drop python-net and python-misc and merge them into python-base. python-base is already quite big (too big for a base package ?), so that wouldn't hurt. I wonder if I should start a big renaming in the prospect of the coming of a jpython package. Gregor -- |Gregor Hoffleit Mathematisches Institut, Uni HD| | [EMAIL PROTECTED] INF 288, 69120 Heidelberg, Germany | | (NeXTmail, MIME) (49)6221 54-5771fax 54-8312 | | We will make windows invisible |
Re: This license (JPython) acceptable ?
Following up on my recent inquiry about the JPython license, here is an update. Depending on the results of these issues, I will put the package into main, contrib or non-free. (1) License issues Judging from the repsonses, most of the license seems to be acceptable according to the terms of the DFSG. There's one clause (8.) which can be ignored by removing a third-party library from the packages (OROMatcher). The real problem seems to be 3.iii: 3. In the event Licensee, at its sole cost and expense, uses the Software to prepare a derivative work that is based on or incorporates the Software or any part thereof, and wants to make the derivative work available to the public for commercial or noncommercial purposes, or uses the software in this derivative form to provide a service to the public, then Licensee hereby agrees: (i) to indicate in any such work, in a prominently visible way, the specific modifications made to CNRI's Software; (ii) not to introduce deliberately any modifications where there is reason to believe they will be harmful to other users and their systems; and (iii) to notify CNRI of any release to the public of Licensee's derivative version, or any service offered to the public by Licensee based thereon. It is not obvious whether this is compatible with the DFSG. Therefore, I asked on the JPython list about the implications and intentions of this clause. I got responses from both Jim Hugunin and Guido van Rossum. Both told me that the intention of the license is clearly to make JPython Open Source compliant, and that they are aware of problems with 3.iii and are working to get rid of them. Then, I asked Eric Raymond on his position. He proposed dropping that notification requirement or at least including a clear statement on how this requirement can be fulfilled (e.g. an e-mail address for sending the notifications to). Judging from the discussions with Guido et al, I would think that we are completely safe if I add an statement to /usr/doc/jpython/copyright where I refer people that they can fulfill this requirement with sending a mail to [EMAIL PROTECTED] Would this be acceptable ? (2) Source issues In the upstream source, the Python grammar is included as input for JavaCC (Java Compiler Compiler). JavaCC compiles the grammar into .java source. Does this really make JPython go into contrib ? Or could I simply include the compiled .java files ? (3) Runtime issues kaffe is not yet able to run JPython, since kaffe lacks e.g. java.math.BigInteger. Therefore, JPython currently only works with jdk1.1. Does this make JPython go into contrib ? Or is this simply a bug in kaffe, so that JPython can be in main ? Gregor
