Re: Any way to tweak build apt-listchanges for testing [Partial Results]
On Tue, Oct 14, 2003 at 12:30:27AM -0700, Ross Boylan wrote: [... using python2.3 from testing, version 2.2.106] | I built the two packages and dpkg -i'd them. When I tried to run apt | I got the following: | | Traceback (most recent call last): | File /usr/bin/apt-listchanges, line 35, in ? | import apt_listchanges | File /usr/lib/python2.3/site-packages/apt_listchanges.py, line 9, in ? | import email.Message | File /usr/lib/python2.3/email/Message.py, line 17, in ? | from email import Charset | File /usr/lib/python2.3/email/Charset.py, line 6, in ? | import email.base64MIME | File /usr/lib/python2.3/email/base64MIME.py, line 31, in ? | from email._compat22 import _floordiv | ImportError: No module named _compat22 | Preconfiguring packages ... | | The python email package changes rapidly; I suspect what's happened is | that the the version in the testing python2.3 differs from that | in unstable. Some of the python2.3 packages were a little buggy. The 2.2.10X versions aren't actual releases, but are either CVS snapshots or alpha/beta releases that Matthias packaged prior to the 2.3 release. Apparently the version still in testing is one of the ones missing that file. A simple workaround is to copy /usr/lib/python2.2/email/_compat22.py from the python2.2 package to /usr/lib/python2.3/email/_compat22.py. | There were also some compiler warnings that may indicate similar drift | at the C level (for python-apt). Warnings (as opposed to errors) don't prevent the build from succeeding. However, if the program crashes or doesn't work right then the warnings may be indicative of the cause(s). | python/sourcelist.cc:30: warning: unused variable `PkgSourceListStructStruct' Unused variables won't cause problems. The unused variable should be removed from the source, but unless you're into house cleaning (IOW if you're not a developer on the project and not submitting patches) then ignore it. | python/sourcelist.cc:76: warning: `PyObject*Owner' might be used uninitialized |in this function | python/pkgsrcrecords.cc:111: warning: `PyObject*Owner' might be used |uninitialized in this function | python/tar.cc:45: warning: `const char*Type' might be used uninitialized in |this function If you run into crashes or other flaky behavior when running apt-listchanges then I would look into these and make sure they aren't part of the problem (or just eliminate the warnings altogether). Otherwise just ignore them. The compiler is not a perfect code checker, which is why it says might in the warning. If the program actually does try to use an uninitialized variable then the results are unpredictable, and certainly not a good thing. HTH, -D -- Through love and faithfulness sin is atoned for; through the fear of the Lord a man avoids evil. Proverbs 16:6 http://dman13.dyndns.org/~dman/ pgpnJJThRDNIR.pgp Description: PGP signature
Re: freezing python packages until python-2.3 becomes the default in testing
On Fri, Oct 10, 2003 at 06:10:27AM +0930, Ron wrote: | Howdy, | | Forgive my apparent ignorance here, but I'm a little confused if I read | Matthias' message correctly. I don't understand how uploading a new | libwxgtk2.4-python package (which build-deps on python2.3) might hold | up python from entering testing. Python doesn't depend on the wx | package (or presumably any of the wx deps either), so how does wx being | too new for testing hold up Python from entering it? Let's see if I correctly and/or completely understand the situation. The current python2.3 depends on python (2.3). So python2.3 won't move until python (2.3) does. The libwxgtk2.4-python in testing depends on python (2.2). Therefore, unless a version of libwxgtk2.4-python that depends on python (2.3) enters testing, then python (2.3) can't enter testing and thus python2.3 can't enter testing. What is needed is for all 3 of these packages to move to testing at once or else none of them will. HTH, -D -- Folly delights a man who lacks judgement, but a man of understanding keeps a straight course. Proverbs 15:21 http://dman13.dyndns.org/~dman/ pgpYG1p5MJE7p.pgp Description: PGP signature
Re: Python policy update
On Wed, Aug 20, 2003 at 02:09:48PM +0200, Josselin Mouette wrote: | In order to make it up to date, and to match current packaging | practices, I have prepared a draft for a python policy update. | It is available at: http://people.debian.org/~joss/python/ | | It includes clarifications, a new section on bytecompilation, treats the | case of private modules, and appendix B now describes a transition like | the current one (which is likely to happen again in the future). | | Please comment. Bullet 5 in Appendix B refers to the wrong section. -D -- Many are the plans in a man's heart, but it is the Lord's purpose that prevails. Proverbs 19:21 http://dman13.dyndns.org/~dman/ pgpqY8JgCVCbN.pgp Description: PGP signature
Re: python 2.2 - python 2.3 transition
I haven't sat down to respond before now, but I've been following the entire discussion. On Sat, Aug 16, 2003 at 11:07:26PM +1000, Donovan Baarda wrote: | On Sat, 2003-08-16 at 00:20, Matthias Klose wrote: | Donovan Baarda writes: | But that was kinda the point... you should be able to install a | pythonX.Y package without python (X.Y). This way you get | /usr/bin/pythonX.Y, but not /usr/bin/python. I don't see any reason why | python2.3 needs to depend on python at all. You should only need python | (2.3) depending on python2.3. | | IMO we want to have a way to ensure a specific version of python. I | don't know another way then having the dependency of python2.3 on | python. | | Check out the policy again... the entire point was if you want a | particular pythonX.Y, install the pythonX.Y package... if you want the | default python, install python. | | The pythonX.Y[-foo] packages should be self-sufficient and not depend on | the default python. The python[-foo] package is a simple wrapper that | depends on the default pythonX.Y[-foo]. Changing the default python | should be a simple process of releasing new python[-foo] packages that | depend on the new default pythonX.Y[-foo]. We had python2.3[-foo] | packages before python (2.3)... there was no need to even release new | versions of these packages to migrate to python (2.3). | | I fail to see what having python2.3 depend on python (2.3) gets you, | apart from tangled. I wholly agree with Donovan. Prior to python2.3 depending on python (2.3) I had python2.3 and python2.2 (and 2.1, but that's beside the point) all happily co-existing. Some libraries (such as wxPython) only existed for one or the other version, and so I used it only with that version of python. My system worked well, and even the transition from python (2.2) to python (2.3) in the archive caused no disruption in my system. It wasn't until python2.3 depended on python (2.3) that I was forced to choose between keeping python2.3 and keeping the other python-foo libraries I wanted. | There might be occasions where you want to install something like zope | that needs python2.1, but don't particularly want to install python. If | python2.1 had Depends: python (=2.1) then you couldn't do this. | | There is nothing that hinders you installing zope without python and | python2.3. | | Not right now, but thats because python2.1 never depended on python. | Hence python2.1 can be installed without any other versions of python. | | by making python2.3 depends on python, you are committing your self to | releasing a new python2.3 just to fix this IMHO broken dependency when | we have python (2.4). I agree here too. | You can't just have python2.3 depend on python (=2.3) so that it can | use #!/usr/bin/python for compiling because what happens when we have | python (2.4)? All the python2.3 modules get compiled with python (2.4) | and mass breakages. | | As long as there are unversioned modules they should break. The | package maintainer should take care that they work (or we provide them | with a pyc-recompiler for a major version change). | | I'm talking about python2.3 breaking... not other unversioned packages. | If you install python2.3 and python(2.4) then all of python2.3's *.py's | will be compiled with python2.4. | | You are going to have to fix the python2.3 package when we migrate to | python (2.4). If you didn't have this dependency then we could migrate | to python (2.4) without having to release a new python2.3 package at | all. This point here really interests me. When 2.3 is not the default version of python, then all scripts and stuff in python2.3 must use /usr/bin/python2.3. From my perspective, it seems worthwhile to me to make all those things use the versioned binary from the start so that they don't need to be fixed later. If this approach is taken, then the next question becomes why not remove the back dependency now and, as Donovan says, eliminate the need to modify the python2.3 package in the future (apart from upstream point releases, naturally). | It is also making migration from python (2.3) to python (2.4) bumpier | than it should be. Just as it makes the current 2.2-2.3 transition less smooth for cutting-edge users than it could have been. | IMHO the original bug poster and Derrick were correct; all | pythonX.Y[-foo] packages should be using /usr/bin/pythonX.Y explicitly | everywhere, and that includes pythonX.Y itself. | | I don't agree :-) We should not set our focus on having the | possibility having more than one python version installed in parallel, | but on having one preferred version installed. If the transition is | done, you shouldn't care on the dependency anymore. | | Didn't we discuss this to death during the development of the Python | Policy? Go back over the threads... the whole reason why it is what it | is was so that people could have more than one python version installed | in
Re: python 2.2 - python 2.3 transition
On Sun, Aug 17, 2003 at 11:22:43AM +0200, Torsten Landschoff wrote: | On Wed, Aug 13, 2003 at 08:33:26AM -0500, John Goerzen wrote: | Now, I could do the dependency on python (= 2.2), python (2.3) thing. | But what would that gain me or users? I see no benefit there, other than | people tracking sid would find OfflineIMAP uninstallable until it gets | updated to depend on Python 2.3. | | There are plenty of OfflineIMAP users that don't use Python themselves, | don't care that it's written in Python -- and probably some that don't | *know* it's written in Python. | | (And yes, the bang path explicitly calls python2.2) If the program explicitly calls python2.2, then it should depend on python2.2, not python (2.2). The usefulness of depending on the default python is (IMO) geared for libraries. wxPython is just one example. This allows an admin to install the library for the default python and not have to worry about package name changes when the default python changes. (IMO the libraries _should_ also provide versions for the other currently available python versions, if possible/feasible) | The dependency on python (= 2.2), python ( 2.3) is for the case where | you have a module which loads into python and supports only a single | python version. | | After python changed you can't install that package (wxgtk-python or | whatever) anymore. The positive effect for the users is that you can't | upgrade python while wxgtk-python is installed so your system won't | break. The negative effect for the users is that you can't upgrade python while wxgtk-python is installed so you can't try out the latest-and-greatest python in the meantime. This is the issue at hand. -D -- For society, it's probably a good thing that engineers value function over appearance. For example, you wouldn't want engineers to build nuclear power plants that only _look_ like they would keep all the radiation inside. (Scott Adams - The Dilbert principle) http://dman13.dyndns.org/~dman/ pgpZPpvOlma4t.pgp Description: PGP signature
Re: python 2.2 - python 2.3 transition
On Thu, Aug 14, 2003 at 03:42:56PM +1000, Donovan Baarda wrote: | On Wed, 2003-08-13 at 23:33, John Goerzen wrote: | On Wed, Aug 13, 2003 at 02:14:55PM +1000, Donovan Baarda wrote: |Actually, all that have that are now uninstallable. Some important ones |have that, such as libwxgtk2.4-python. | |Shouldn't they depend on python2.2 instead | | No. There is a reason they are not installable... they don't work with | python (2.3) | | But they do with Python 2.2... why not let them at least be installable with | that version? | | Because the package maintainer chose not to. Maybe he/she is regretting | that now :-) I hope so ... (because then it will be changed in the next upload :-)) | I personally agree that anyone producing python extension modules should | be using the pythonX.Y-foo + python-foo wrapper approach. This would | mean their old pythonX.Y-foo packages would still work during and after | a python transition. You get legacy support for free. That's the beautiful part of using that set of depends. | Fortunately, most python-foo packages are simple wrappers that have | Depends: python2.2-foo, so they are very small and easy to fix for | python (2.3) (changed to Depends: python2.3-foo). | | That makes a lot of sense to me, and I have no quibble with that approach. | If libwxgtk2.4-python took that approach, I'd have no complaints as I could | still install and use the lib under Python 2.2. As it is, that is | impossible, even though the lib remains compatible with Python 2.2. | | You can file a wishlist bug against libwxgtk2.4-python requesting that | it use that approach if you like. I would if it annoyed me :-) If enough of us submit the bug will it get fixed? ;-) (I know, it's up to the maintainer, not you) | Note that libwxgtk2.4-python _does_ work with python (2.2). Yes. | You can always install python (2.2) from testing and it will all | work. Not anymore : # apt-get -s install python/testing eading Package Lists... Done Building Dependency Tree... Done Selected version 2.2.3-3 (Debian:testing) for python Some packages could not be installed. This may mean that you have [... you know the long message ...] The following packages have unmet dependencies: python: Depends: python2.2 (= 2.2.3-2.1) but it is not going to be installed E: Broken packages # dpkg -l python | tail -1 ii python2.2 2.2.3-4An interactive high-level object-oriented la So what's the problem? The problem is $ apt-cache show python2.3 | grep Depends | head -1 Depends: libbz2-1.0, libc6 (= 2.3.2-1), libdb4.1, libncurses5 (= 5.3.20030510-1), libreadline4 (= 4.3-1), libssl0.9.7, zlib1g (= 1:1.1.4), python (= 2.3) ^^^ This wasn't an issue until Matthias added that versioned dependency on 'python' in response to bug #204748. In so doing, he has prevented people from having the fully functioning 'python' package (version 2.2) installed alongside the fully functioning 'python2.3' package and use libraries with the version of python that they are currently available for. IMO there should not be a pythonX.Y - python dependency. Instead, the problem reported in bug #204748 can be solved by requiring all pythonX.Y related packages to use /usr/bin/pythonX.Y instead of /usr/bin/python. Only packages which depend directly on 'python' can use /usr/bin/python. In fact, I'm tempted to hack up my local copy of the dependencies so that dpkg will overlook this artificial conflict and allow me to have wxPython (even though I haven't used it personally since my school projects are finished) and see what 'GNUe' is all about. | Note that python in testing will never be broken like this. The | dependencies ensure that testing can only transition to python (2.3) | when everything works. True, but I want the best ;-). (that is, I've had python2.3 installed for around a year now; ever since Matthias started providing the pre-alpha snapshots) -D PS. Thanks, Matthias, for providing the 2.3 packages so early! I really enjoyed having it available! -- Consider what God has done: Who can straighten what He has made crooked? Ecclesiastes 7:13 http://dman13.dyndns.org/~dman/ pgpMbpyIBy763.pgp Description: PGP signature
Re: python 2.2 to python 2.3 transition
On Tue, Aug 12, 2003 at 12:38:16PM +1000, Donovan Baarda wrote: | On Mon, 2003-08-11 at 22:03, Matthias Urlichs wrote: | Hrm, this could be achieved quite simply, /methinks. It needs little | changes in dh_python and some prerm/postinst stuff in the python package | (not the pythonX.Y package) to rebuild all .pyc's and .pyo's in this | directory upon upgrade. | | Matthias, do you think it is feasible ? | | Would work for me. /usr/lib/site-python is supposed to have clean python | scripts only, so running compileall.py on all subdirectories thereof | should pose no problem. | | The problem I have with it is it doesn't take into account programs with | python modules outside /usr/lib/site-python. Probably mailman is the | prime example. If you want more than one real-world example use zope and the zope-* add-ons. -D -- It took the computational power of three Commodore 64s to fly to the moon. It takes at least a 486 to run Windows 95. Something is wrong here. http://dman13.dyndns.org/~dman/ pgpshP3Eciert.pgp Description: PGP signature
Re: python 2.2 - python 2.3 transition
On Tue, Aug 05, 2003 at 10:31:53PM +0200, Matthias Klose wrote: | With the next python2.3 upload, python2.3 becomes the default python | version. Nice! This is the way to work on breaking dedian's reputation of always being way behind. -D -- If Microsoft would build a car... ... Occasionally your car would die on the freeway for no reason. You would have to pull over to the side of the road, close all of the car windows, shut it off, restart it, and reopen the windows before you could continue. For some reason you would simply accept this. http://dman13.dyndns.org/~dman/ pgpx5AcUOVKk0.pgp Description: PGP signature
Re: Error message from install of python packages
On Mon, Mar 24, 2003 at 08:35:13PM -0500, [EMAIL PROTECTED] wrote: | What do these messages mean...?? | | Setting up python-gtk (0.6.11-7) ... | 'import site' failed; use -v for traceback | 'import site' failed; use -v for traceback When the python interpreter starts up it imports the site module (/usr/lib/pythonX.Y/site.py) to load any site-specific customizations. Apparently there's a problem with your site.py. As the message says, use the -v flag to get a traceback which will give details. Run python -v and post the output here. -D -- Micros~1 : For when quality, reliability and security just aren't that important! http://dman.ddts.net/~dman/ pgpUYpjAmy3II.pgp Description: PGP signature
Re: python-central 0.4
On Mon, Sep 30, 2002 at 08:19:49AM +1000, Donovan Baarda wrote: | On Mon, Sep 30, 2002 at 08:13:23AM +1200, Carey Evans wrote: | It also makes it easier for users to modify if a Python package's | dependencies are incorrect, and it stops compiling under a newer version | of Python, making the whole dpkg run fail. | | 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. If there's a malfunctioning script in /somewhere that I can insert exit 0 ; or import sys ; sys.exit( 0 ) at the top, then as a user/admin I can sidestep the installation error. If the logic is tucked away in the bowels of some other program, it isn't as trivial to hack around. (I don't have a position on this issue, though, I'm just sorta lurking on the discussions) -D -- But As for me and my household, we will serve the Lord. Joshua 24:15 http://dman.ddts.net/~dman/ pgp0JFaZZdMpe.pgp Description: PGP signature
