Re: Summary of python transition problems
On Sun, Oct 05, 2003 at 11:40:50AM +1000, Donovan Baarda wrote: > On Sun, 2003-10-05 at 02:55, Matthias Klose wrote: > > Donovan Baarda writes: > > > The second problem is is when we get python (2.4), a new python2.3 > > > package will need to be released just to fix the dependencies. The > > > Python Policy was designed so that no pythonX.Y(-foo) packages would > > > need to be updated when python (X.Y+1) is released. > > > > not true. the 2.3 upload is needed for not building the unversioned > > python packages. > > Hmm, I forgot about that. Is this a hassle? Would it be possible, and > would it help, to have "python" built from it's own empty source > package? For what it's worth, I think a python-defaults source package or some such would help: at the moment there are several packages needlessly stalled on python2.3, even though their dependencies are simply 'python2.3 (>= 2.3)' or similar. If the python binary package were built from a separate source package then we could decouple transitions from the task of keeping the versioned packages up to date. -- Colin Watson [EMAIL PROTECTED]
Python transition
Hello, I hope I am not alone in this. I find the whole Python transition process to be rather confusing. For instance, I recently received an e-mail asking me not to upload various Python packages. A day later, one of them got NMU'd. I am confused; what exactly is the problem and why would a simple upload in any way inconvenience anyone, ESPECIALLY if it fixes problems? And why are maintainers not supposed to upload their packages but others can? I'm tempted to say "to hell with it" and just upload packages as normal, make them work with Python 2.3 as proper, fix any bugs, and just go on with life. -- John
Re: Python transition
John Goerzen writes: > Hello, > > I hope I am not alone in this. > > I find the whole Python transition process to be rather confusing. For > instance, I recently received an e-mail asking me not to upload various > Python packages. A day later, one of them got NMU'd. I am confused; what > exactly is the problem and why would a simple upload in any way > inconvenience anyone, ESPECIALLY if it fixes problems? And why are > maintainers not supposed to upload their packages but others can? > > I'm tempted to say "to hell with it" and just upload packages as normal, > make them work with Python 2.3 as proper, fix any bugs, and just go on with > life. John, I hope you are alone with your temptation ... The e-mail I sent made several exceptions from the freeze, one of them fixing RC reports. So yes, you are supposed to fix these problems yourself. As I introduced this RC in 0.5.1-5.1, I fixed it in 0.5.1-5.2. Unfortunately I did not get any response from you asking for NMU's for forg and gnupginterface. Matthias
Re: Summary of python transition problems
Colin Watson writes: > On Sun, Oct 05, 2003 at 11:40:50AM +1000, Donovan Baarda wrote: > > On Sun, 2003-10-05 at 02:55, Matthias Klose wrote: > > > Donovan Baarda writes: > > > > The second problem is is when we get python (2.4), a new python2.3 > > > > package will need to be released just to fix the dependencies. The > > > > Python Policy was designed so that no pythonX.Y(-foo) packages would > > > > need to be updated when python (X.Y+1) is released. > > > > > > not true. the 2.3 upload is needed for not building the unversioned > > > python packages. > > > > Hmm, I forgot about that. Is this a hassle? Would it be possible, and > > would it help, to have "python" built from it's own empty source > > package? > > For what it's worth, I think a python-defaults source package or some > such would help: at the moment there are several packages needlessly > stalled on python2.3, even though their dependencies are simply > 'python2.3 (>= 2.3)' or similar. If the python binary package were built > from a separate source package then we could decouple transitions from > the task of keeping the versioned packages up to date. It does help for python applications, which depend on an explicit python version. I did not count packages with a 'python2.3 (>= 2.3)' dependency. It does not help for library packages building a python-foo binary package. For this case you would have to separate this binary package to build from it's own source (but maybe this could be built from the python-defaults package as well ...). IMO it depends on the amount of packages that explicitely depend on python2.3. But maybe an upload of the current python2.3 packages (without changing the default version) to testing would help as well in this case. Matthias
Re: Python transition
On Tue, Oct 07, 2003 at 07:18:41PM +0200, Matthias Klose wrote: > The e-mail I sent made several exceptions from the freeze, one of them > fixing RC reports. So yes, you are supposed to fix these problems > yourself. As I introduced this RC in 0.5.1-5.1, I fixed it in > 0.5.1-5.2. Which is nice, but still does not explain why the freeze is necessary. I don't understand the reason for it. > Unfortunately I did not get any response from you asking for NMU's for > forg and gnupginterface. I don't recall getting messages from you about that, but I will look into it right away. -- John
Re: Python transition
John Goerzen writes: > On Tue, Oct 07, 2003 at 07:18:41PM +0200, Matthias Klose wrote: > > The e-mail I sent made several exceptions from the freeze, one of them > > fixing RC reports. So yes, you are supposed to fix these problems > > yourself. As I introduced this RC in 0.5.1-5.1, I fixed it in > > 0.5.1-5.2. > > Which is nice, but still does not explain why the freeze is necessary. I > don't understand the reason for it. Packages, that are too young are not considered for migration to testing. As these packages have a dependency on "python (>=2.3)", they need to be migrated together with the migration to the default python version. IIRC it's possible for the release managers to override the constraints for some packages, but it gets tedious if many are affected. Matthias
Re: Python transition
On Tue, Oct 07, 2003 at 08:29:12PM +0200, Matthias Klose wrote: > Packages, that are too young are not considered for migration to > testing. As these packages have a dependency on "python (>=2.3)", they Few, if any, of my packages have such a dependency. In most packages, I depend on the specific version of Python that I will be using (ie, python2.3) and the appropriate libs for that version of Python. Is Python 2.3 already in testing, but the python package simply isn't updated? -- John
Status of python packages (20031007)
changes from 20031003: - missing s390 builds done - some progress for missing m68k builds - some RC reports fixed nearly no changes for missing mips/mipsel builds. does somebody has free resources on a mips machine to rebuild these packages? Matthias missing builds: gimp-python (mips) dia (m68k, building on wouter-quickstep) affix (dependency out of date on alpha) python-gtkextra (mips) cooledit (m68k, beeing prepared) vim (new upload, buggy) plplot (m68k building on cts-tanda, mips) widestudio (arm, powerpc, ) postgresql (new upload, buggy) pybliographer (mips) python-gnome2 (libxml2 dependency, otherwise ok) xchat (new upload, m68k beeing prepared, mips, mipsel) python-qt2 (dependency out of date on mips) python-qt3 (mips, mipsel) glimmer (mips) gaby (mips) ecasound (mips) ecasound2.2 (mips) pyvorbis (mipsel) jack (mips) psycopg (mips) mooix (arm, mips) solfege (arm, not in testing) sqlrelay (buggy, not in testing) python-pylibacl (m68k, mips, not in testing) python-pyxattr (m68k, mips, not in testing) pyx (m68k, mips, not in testing) pyxmms (m68k, mips, not in testing) superkaramba (mips, not in testing) (currently building the latter four missing m68k packages) 10: gimp1.3 (not in testing) 9: spkproxy 8: gnue-common jack psycopg 7: jabber.py 6: mayavi gdesklets-data (not in testing) forg 5: archivemail libmusicbrainz vte python-stats gramps thuban (not in testing) 4: gnupginterface python-imaging python2.2 libapache2-mod-python 3: python-gd roundup libapache2-mod-python python-adns reportbug koffice 2: pilot-link plywood pymbus python-aima python-pam pyvtk spkproxy xkeysw python2.3 1: python-email subterfugue
