Re: Python rexec and Bastion flaws
Martin Schulze wrote: I'd rather know about the vulnerability (and maybe doko is able to implement a fix) than to blindly castrate software. Theo d.R. already taught us that blindly releasing updates are not good. Here's some relevant links for the bugs: Deleting __builtins__: http://python.org/sf/577530 Modifying new-style classes: http://mail.python.org/pipermail/python-dev/2002-December/031160.html Final thread about dropping rexec: http://mail.python.org/pipermail/python-dev/2003-January/031842.html Please note that the two bugs described above are only the two *known* bugs - nobody knows how many other bugs there are in rexec. -- Hanging is too good for a man who makes puns; he should be drawn and quoted. -- Fred Allen
Re: python-central 0.4
Donovan Baarda wrote: But this is redundant... if the package is installed, the corresponding *.py files _should_ be unpacked. How is testing for the existance of a file any better indication than testing for installation of the package? True... I think I'll try to blame my flawed argument on lack of caffeine in the bloodstream. [...] This is an interesting issue I hadn't considered. However, I can't see how seperate compilation scripts do a better job of avoiding this problem than dpkg-reconfigure. Since, in the absence of debconf, all dpkg-reconfigure does is run /var/lib/dpkg/info/package.postinst configure current-version /I guess editing the postinst would be fine as well. /However, it still seem to me that having recompilation separate from installing documentation, menus, MIME types and whatever else might be worthwhile. It might also be nice to have separate files that list the directories or source files to compile for each package, and have python-central call compileall itself, but I guess this is a separate issue. [...] So the postinst scripts get passed the version upgraded from? (I should know this :-) I should have checked too. See section 6 of Policy for details, especially what can happen if an error occurs, but the postinst is the one script that _doesn't_ get called with the other version number. The old version's prerm and postrm, and the new version's preinst, could all check whether an incompatible upgrade was going to or had occurred. In this case, I guess they'd set a flag and delete the old *.py[co] files.
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
From Appendix B.2: The new packages will conflict with every Python dependent package, that does depend on `python', `python-base', without depending on `python ( 1.6)' or `python-base ( 2.1)'. Since the new packages conflict with python-base itself, they don't need to conflict with packages that depend on python-base. I think the first `python-base' needs to be removed. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: Debian Python policy Upgrade Path (draft/proposal)
Donovan Baarda [EMAIL PROTECTED] writes: Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. Another possibility is for python-base to go away, and for a new package that conflicts with it, and has a different name, to take its place. In stable, it seems that only bg5ps, grmonitor, pythondoc and sketch depend on python, compared to 59 which depend on python-base, so this would make the Conflicts field just a little bit shorter. (Actually 60, but gimp-python also depends on python-base ( 1.6.0)). Packages that depend on python: grep-dctrl -FDepends -e 'python([ ,]|$)' Packages Packages that depend on python-base: grep-dctrl -FDepends python-base Packages It seems things have gotten worse... I count 22 packages in unstable that depend on python, and around 101 that depend on python-base only once. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: Debian Python policy Upgrade Path (draft/proposal)
Matthias Klose [EMAIL PROTECTED] writes: [...] exactly. But you see that these packages will break when you try to upgrade. We can't make 2.1 the default right now, because we will _silently_ break packages. Before python can point to python2.1, we will have to fix all packages which depend on python-base, to depend on python-base ( 1.6). But if we get Python 2.1 into Debian 3.0, people will be upgrading from the old Python 1.5 packages in Debian 2.2 directly to the new packages, and unless they use apt-get dist-upgrade to upgrade to the newest versions of everything, packages will still be broken. For that matter, just getting everyone using testing to transition over to the new versions properly will be nearly impossible unless there are appropriate conflicts and dependencies to make sure that only working combinations of packages can be installed. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: Debian Python policy Upgrade Path (draft/proposal)
Matthias Klose [EMAIL PROTECTED] writes: [...] 2.4. Dependencies - Packaged modules must depend on `python-base ( X.Y)' and `python-base ( X2.Y2)'. (= X.Y), right? Shouldn't this explain just what X2.Y2 is? I assume it's actually X.Y+1, i.e. =1.5 and 1.6, =2.1 and 2.2, =2.9 and 2.10, etc. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Python 2.1 crypto
I notice that python2.1-base depends on libssl0.9.6. I haven't been following the developments in Debian's crypto policy, but doesn't this mean that python2.1-base should have been uploaded to non-US? -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: Debian Python Policy [draft]
Neil Schemenauer [EMAIL PROTECTED] writes: spam should depend on python not python-2.1. In my original example, spam embeds libpython2.1.so. It would make sense for this to mean it depends on python-api-2.1, though this isn't what the current shlibs file says. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ You think you know... what's to come... what you are.
Re: Experimental Python packages
Gregor Hoffleit [EMAIL PROTECTED] writes: Have you looked at my experimental Python packages, at http://people.debian.org/~flight/python/snapshot/ ? I've had a look at these packages myself. Can you tell us what stage they're at, i.e. what still needs to be done, what problems you know about and what you want to hear about? Some things I've noticed to start with: - Lots of references to Python 1.5 or 2.0. - python2.1-base tries to install an alternative for /usr/bin/python in its postinst, so it has to conflict with old versions of python-base that contain this. - The shlibs file refers to python2-base (= 2.1-1) but the package is python2.1-base. - /usr/bin/pydoc isn't versioned, so python2.2-base will have to conflict with this version of python2.1-base. It should probably be /usr/bin/pydoc2.1 with a pydoc alternative, and start with #!/usr/bin/python2.x as appropriate, for future versions. I'd also like to know: - What dependencies should packaged modules declare: a) when the maintainer only plans on supported whatever the latest version of Python is? b) if there'll be one package per Python version? - What should packages that use Python depend on? Presumably python if the maintainer feels optimistic, otherwise python2.1-base. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ You think you know... what's to come... what you are.
Re: Proposal for transition--FRD
Mikael Hedin [EMAIL PROTECTED] writes: [...] 6) All packages with files in .../python1.5/ without versioned depends get a critical bug. Unfortunately, this leaves someone's system broken if they just install some Python packages, and leave the packages that currently depend on python-base ( 1.5.2) installed. The best solution to this is to get rid of python-base, and have all packages depend on python-base-x.y or similar. Packages only get into testing once their dependencies are consistent, and apt-get upgrade won't allow broken dependencies either, so this doesn't really cause much hardship. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ You think you know... what's to come... what you are.
Re: Proposal for transition--FRD
Mikael Hedin [EMAIL PROTECTED] writes: [...] Why not the exciting name python? And confilcts with python-base? Then all the module that depend on python-base (xxx) to be either upgrader or removed. Am I right? There's quite a few packages that depend on python, which is a virtual package, and it looks like it used to be a real package. Try apt-cache showpkg python. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ You think you know... what's to come... what you are.
Re: Status report on python2 transition (possible solution)
D-Man [EMAIL PROTECTED] writes: Yes. Maybe each extension should just depend on a single version of python and need to be rebuilt for each new python release. It makes things considerably simpler, from my point of view. Then, of course, we need unique package names for each package. Something like python-imaging-python1.5, python-imaging-python2.0 and python-imaging-2.1? Aagh. (Picking on python-imaging because it contains binary modules, so it's version specific anyway.) | Are there any other reasons to provide all the modules for Python | 1.5.2 (now more than two years old) in Debian 3.0? Who knows what people might be using that isn't packaged for Debian. True. I feel that we can't keep everyone happy forever, and Python 1.5 has to go away someday; OTOH, I'm running quite up to date unstable, so maybe I don't have the same perspective as many users. ;) -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition (possible solution)
D-Man [EMAIL PROTECTED] writes: It might be more convenient, unless a user, for some strange reason, wants to only have an older version of python. In which case they won't have anything else installed that depends on python, and they'll just install python-2.1, for example, and never see python-2.2. Given this, /usr/bin/python better be managed by alternatives. [...] Are you saying that gcc 2.95 and 3.0 can peacefully co-exist on a system? That would be good news to me :-). Yep. There's still the familiar problem of differing C++ ABIs, so everything in woody should still be compiled with gcc 2.95. [...] Sure, but also consider older packages. For example, we are now moving to 2.0 (or 2.1) for the default python. We still want to provide 1.5.2 versions of all the other packages, so they should (now) specify that they don't work with = 2.0 because we know that now. However, that can lead to packages breaking when a new version of Python is installed, without pulling in the newer extension modules and packages that use the new scope rules properly, and have variables named yield and div renamed to something else, etc. dpkg and apt provide very good dependency checking, so we should try to use it. Anyway, *do* we actually need all the extension modules for Python 1.5.2? For Debian itself, there's Zope and Mailman, but they don't depend on any other Python packages. reportbug uses python-newt, but it should be changed once python-2.1 is available, so that Python 1.5.2 isn't installed by default on new Debian 3.0 installations. Are there any other reasons to provide all the modules for Python 1.5.2 (now more than two years old) in Debian 3.0? Either it is optimistic, or there was no known conflict with a newer version (because it didn't exist ;-)) when it was built. This may be true, especially when Python 2, which would break lots of stuff, was in the distant future. Python 3K may be far away now, but Python 2.x is breaking stuff with every release. Well, I have no fancy title (like Debian Maintainer) so I really have no authority on the matter. The idea just came to me and it seemed pretty good so I thought I'd share it :-). You can do what you like with the idea. I probably shouldn't be using my @debian.org address for this discussion anyway; I've done one package upload in the last six months, which hardly makes me an active Debian maintainer or any kind of authority. I'm not really talking just to you, but generally; by all means keep coming up with ideas to improve the Debian Python packages, but please don't keep Python 2.1 out of Debian 3.0! -- Carey Evans http://home.clear.net.nz/pages/c.evans/ I'm not the only one who disagrees with everything. - Fur Patrol, _Man In A Box_
Re: Status report on python2 transition (possible solution)
D-Man [EMAIL PROTECTED] writes: Say, ..., is there a way for a python script to find out where the python binary executing it is? If so, then the real script could be run via os.system by the Debian script that uses #! deb_py_ver. sys.executable, which comes from argv[0] in Py_Main(), looking in $PATH if necessary. os.system isn't the best in terms of signal handling and return values; you'd probably want os.execv. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition
More random thoughts... How many versions of Python do we really need to support at one time? Zope and Mailman both need Python 1.5.2 (and depend on python-base = 1.5.2-x, BTW), but don't need any extra packages like mxDateTime. If there are any other packages that don't work with Python 2.1, do they need extra extensions themselves? It seems to me that each stable release of Debian will only need to support a maximum of two different versions of (C)Python, both of which will be quite different. All extra Python modules just have to be compiled against the latest package, and the version of Python from the last Debian release can be removed. For example, woody will have Python 1.5.2 and 2.1.1 when it's released. By the following release of Debian, 2.2 or even 2.3 will be current. Will there be any packages that need 2.1.1 by then? I think I was trying to make a point here: Especially while the freeze is beginning for woody, there's no time to design, implement, test and deploy any scheme for sharing module source, etc., or for doing really fancy dependencies. Instead we should ensure that there is a smooth upgrade path from potato to woody, and that future improvements for woody+0.1 are not ruled out. So... Python 1.5.2, in package python-1.5, installs modules in /usr/lib/python1.5/, installs the binary in /usr/bin/python1.5 and uses alternatives for /usr/bin/python. It conflicts with python-base. Zope and Mailman are recompiled with dependencies on python-1.5 (no versioned depends). Python 2.1.1, in package python-2.1, installs modules in /usr/lib/python2.1/, installs the binary in /usr/bin/python2.1, and uses alternatives, with a higher priority than python-1.5. python-2.1 conflicts with python-base, too. All other packages providing Python modules or using libpython, are recompiled against 2.1.1, with an unversioned dependency on python-2.1. python-base is removed from the archive. Virtual package python turns into a real but empty package, that depends on python-2.1. Scripts written in Python may depend on python, but may expect bug reports later when they turn out to be incompatible with a new version of Python. (Or an old version via alternatives. They should probably just depend on python-2.1 themselves.) Debian packages that have scripts written in Python should use one of /usr/bin/pythonx.y or /usr/bin/env pythonx.y if they depend on python-x.y. They should use /usr/bin/python or /usr/bin/env python if they depend on python. I have no idea whether /usr/bin/env python or /usr/bin/python is better. /usr/bin/env means that another version of Python can be installed in /usr/local, and scripts using env will start using it. Whether this is good or bad for a Debian package is another question. ... Wow. That got a bit longer than I anticipated. If anyone got down to here, do you have any comments? I can expand on my reasoning if it would help. Thanks. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition
Bruce Sass [EMAIL PROTECTED] writes: bms:~# ls -l /usr/bin/python* -rwxr-xr-x2 root root 3040 Apr 10 02:09 /usr/bin/python -rwxr-xr-x2 root root 3040 Apr 10 02:09 /usr/bin/python1.5 -rwxr-xr-x1 root root 3080 Jun 23 15:52 /usr/bin/python2 lrwxrwxrwx1 root root7 Jun 24 18:34 /usr/bin/python2.0 - python2 ...'cause I've never seen a 3k python executable. So, using an explicit python-wrapper in the #! line is a step backwards to me. $ ldd /usr/bin/python1.5 libpython1.5.so.0.0 = /usr/lib/libpython1.5.so.0.0 (0x4001f000) ... $ ldd /usr/bin/python2.0 libpython2.0.so.0.0 = /usr/lib/libpython2.0.so.0.0 (0x4001f000) ... These *are* real executables; it looks like all they do is call Py_Main from whichever libpython they're linked against. [...] I think it is perfectly reasonable for Debian to insist that a specific version of Python be installed, and that any Python programs distributed by Debian must work with a certain version of Python or better. Agreed, although it seems OK to me to only expect them to work with the current version, in any stable release of Debian. As the language changes, adding keywords like yield and div, etc., expecting full forwards compatibility might be a little unreasonable. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition
Chris Lawrence [EMAIL PROTECTED] writes: - My package is now broken and I have to reupload it, even though all I need to change is the #!. They'll probably be Debian policy changes, new upstream versions of your program, and/or changes in the Python language that require you to do a new upload between releases anyway. IMO, the minimal effort required here isn't worth the black magic. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: /usr/lib vs. /usr/share
Harry Henry Gebel [EMAIL PROTECTED] writes: On the other hand, we could put the .py files in /usr/share if we moved the generated .pyc/.pyo files to /usr/lib (can (should?) compileall be modified to do this automatically?) We would keep sys.path to the standard, and since the .py files would no longer be in sys.path they would no longer be executable and would qualify for /usr/share . I think a system similar to this is how the emacsen allow one Emacs mode package to be used by several Emacs versions. Yes - the Emacs packages actually work by copying the .el files into a temporary directory and compiling them there. For Python, a better solution would be a modified version of compileall, maybe under a new name. (compileall_debian?) By changing the call to py_compile.compile(), the byte-compiled file can be put in any directory or directories, e.g. both of /usr/lib/python1.5/site-packages/foo.pyc and /usr/lib/python2.1/site-packages/foo.pyc, without the source foo.py file being anywhere in sys.path. From a few quick tests, it seems that Python 2.0 remembers the path for the source file, so it can still fill in a traceback correctly even when the source isn't in sys.path. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition
Gregor Hoffleit [EMAIL PROTECTED] writes: 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). There's not much we can do about all the Python packages in stable that just depend on python-base (= 1.5.2-1) though, and I don't see why apt would upgrade to a new version of python-pqueue, for example, just because someone does apt-get install python-base after getting their shiny new Debian 3.0 CDs. The only way I can see around this is to scrap python-base and go for python-base-major.minor, or for a new name like python-dist-base. Some sort of python-base-x.y would be nice anyway, for maintainers and for the packaging system, so that modules can have a simple depends on a (maybe virtual) package, instead of a versioned depends. (Does dpkg support versioned virtual packages yet?) -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition
Here's my two cents. It might be a bit rambling, given how late it is here... [...] Barry A. Warsaw [EMAIL PROTECTED]: 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. For the big applications like Zope and Mailman, how much is required in the way of non-core packages? It would be considerably easier if the only versioned Python packages were those compiled from the distribution tarball, and extra packages like python-gnome were only required to be packaged for the latest Python version in time for each Debian release. [...] 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. This seems like a reasonable idea, for code that works with all available Python versions. There's no need to change the Python interpreter to look in different places, or even to change compileall.py. The registration/update script could be in a python-common package that each of the different Python version packages depend on. [...] Gregor Hoffleit: We should look at the perl packages (they support concurrent versions) and a Emacsen (they have a system for registration of .el files that can be byte-compiled at installation time, and they support this for concurent and different Emacsen flavors). *Does* Perl support concurrent versions? All I seem to have available from the mirrors is 5.6.1. Thinking about the transition, it seems to me that relying on all the Python packages to change their dependencies on python-base is going to be hard to get right. It would still be possible to use apt-get to install a new version of python-base, and existing packages that only depend on = 1.5.2 won't be automatically upgraded. Perhaps python-base should be removed in favour of Python package names that include the first and second version number components, something like the perl-api-x.y packages. (python-base-2.1 or just python-2.1?) The python package could be something like the gcc package - mostly just an indication of the default version from the user's point of view, and something to make sure the latest version is available after a dist-upgrade. Though that leaves the problem of the packages currently depending on python... If it's any consolation while you're trying to work out a plan, just be glad Python isn't Essential: yes like parts of Perl. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Python 2.1 out
Sean 'Shaleh' Perry [EMAIL PROTECTED] writes: last I checked it only helped derivatives of python, not python itself. AIUI, the point is that Python 2.1 is a derivative of CNRI Python 1.6.1. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
