Python Transition, Mass Bug fill and NMUs…
Yesterday, a last round of bugs has been filled against packages that may need an upgrade to comply with the recent python policy[1]. Some developpers have raised concerns directly to me about the 0-day NMU policy warning in that report. This § has been added because /usr/bin/python beeing python2.4 is a release goal, and that migrating packages to that policy indeed helps to that. That's a statement for a fact, not a thread. If you don't want an NMU, just state it in an answer to the bug, that shows that you are aware, but that for some foo or bar reason you want to deal with that bug with a later upload. this is *OK*. So, dear developpers: if you don't want to be NMUed, just say it. If you don't want to be NMUed just for that, but want your next upload to deal with the python policy, and that you don't know how to handle that new policy correctly, just tag your bug + help, I do follow those bugs, and I've already prepared and sent (or am currently preparing) patches for those who already asked for some. If you want help, but already have a preference between python-support/python-central please state it also, so that the patch do follow your choice, else the one that helps will choose for you (if one or the other helper is indeed needed). So, dear NMUers: *DO* respect the wish of maintainers that ask not beeing NMUed. If you really feel a maintainer just procrastinates, sending a 'NMU patch' on the bug is OK though. If a bug is tagged + help, please do only send the patch, except if the maintainer explicitely allowed NMUs. That way this messy transition will be able to come to an end, peacefully. Thanks for caring. [1] yes I know this was not re-announced, but it was obvious to me that the repeated announces (at least 2 or 3 mails on d-d-a@) about the python transition were sufficient. that plus the fact that the bugs are /important/ and not RC (some may become, for packages that B-D upon python2.3 where they should on python-dev, but we are not here yet, and /that/ will be announced and coordinated with the RM team). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYXThd7cENR.pgp Description: PGP signature
Re: Python Transition, Mass Bug fill and NMUs…
Le mercredi 02 août 2006 à 10:21 +0200, Pierre Habouzit a écrit : > Yesterday, a last round of bugs has been filled against packages that > may need an upgrade to comply with the recent python policy[1]. Please also note that some of these bugs are invalid. For example, if the package ships some private extensions, of if it only ships scripts that aren't imported anywhere, you can safely close it. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Python Transition, Mass Bug fill and NMUs...
On Wed, Aug 02, 2006, Pierre Habouzit wrote: > Yesterday, a last round of bugs has been filled against packages that > may need an upgrade to comply with the recent python policy[1]. That's great! We all want python to be python2.4 in etch, thanks for your work. We already discussed together why it would be nice to announce / discuss future mass bug filings to allow peer review (also when reporting bugs that were missed by the initial filing). Here are some suggestions of things I think would have improved the Python transition: - status of the transition Wiki page: a summary of steps which are in progress (pointer to python transition pseudo-bug, pointers to the list of bugs to be fixed in the mass bug filing, description of the step) - collection of things to do and no to do: this is both intended as a reference of things that we have discussed and decided to be good or wrong, and might help in defining the exact criteria prior to e.g. a mass bug filing; this probably belong to the FAQ on the Wiki - test suite I've found some Wiki pages approaching these, such as the DebianPythonTODO, DebianPythonFAQ, or the DebianPython/NewPolicy pages, but they didn't cover the results of discussions that happened on the debian-python@ lists before, during, or after the implementation of the python packaging tools. It seems to me it's a bit late to do this now, but if people find some of the above interesting, I might take some time during my holidays (starting friday) for this. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python Transition, Mass Bug fill and NMUs...
Le mer 2 août 2006 11:23, Loïc Minier a écrit : > - status of the transition Wiki page: a summary of steps which are >in progress (pointer to python transition pseudo-bug, pointers to >the list of bugs to be fixed in the mass bug filing, description of >the step) that could have been more clear, but I do have such tools to follow the transition, I use[1]. The two rounds of mass bug have been package that build public modules and extensions, and then all the other ones (+ some missed one at the first stage). > - collection of things to do and no to do: this is both intended as >a reference of things that we have discussed and decided to be good >or wrong, and might help in defining the exact criteria prior to >e.g. a mass bug filing; this probably belong to the FAQ on the >Wiki this seems to be quite well documented on the DebianPython/NewPolicy pages, buxy added some full examples, and I added some more things about cdbs recenlty. The page was also updated for private modules before the second mass bug fill. > - test suite that misses, and this is IMHO *the* real thing that sucks here. the rest lacked some advertising, but exists. [1] http://bugs.debian.org/from:[EMAIL PROTECTED] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpStUj93TdFU.pgp Description: PGP signature
Re: Python Transition, Mass Bug fill and NMUs...
On Wed, Aug 02, 2006, Pierre Habouzit wrote: > that could have been more clear, but I do have such tools to follow the > transition, I use[1]. The two rounds of mass bug have been package that > build public modules and extensions, and then all the other ones (+ > some missed one at the first stage). Ok, some things I consider bugs with the current state of the transition and I would have expected in a "Status of the Python transition" page: - way of expressing dependencies on a particular version of python modules (#379455) - support of rtupdate scripts - support of pure python2.3 modules (raised on debian-python@ last week) - reports of upgrade testing > this seems to be quite well documented on the DebianPython/NewPolicy > pages, buxy added some full examples, and I added some more things > about cdbs recenlty. The page was also updated for private modules > before the second mass bug fill. An example of what I would have expected to find on the page I describe is: what to do when your package ships both private extensions and private modules; solution a) could be to configure the package with a --libexecdir or similar containing the name of the python runtime and build it multiple times, solution b) could be to only build for one version of python. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Request for help to convert the lyx package
Hello, I've been working on the lyx package to get it in a state complying with the new python policy. LyX generates some .pyc and .pyo files during build time and I'm not sure what to do with them because I thought that the dh_pycentral call would handle them correctly. Having build a package[1] from the stuff we currently have in our svn repo[2] I can not find a postinst/prerm script added to handle the recompilation of those files. >From the resulting packages lyx-common is the one with the python stuff. I'd appreciate if someone could enlight me and tell me how to deal with this case correctly. Regards, Sven [1] http://sven.stormbind.net/debian/lyx/ [2] http://svn.debian.org/wsvn/pkg-lyx/lyx/trunk/?rev=0&sc=0 -- If you won't forgive me the rest of my life Let me apologize while I'm still alive I know it's time to face all of my past mistakes [Less than Jake - Rest Of My Life] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for help to convert the lyx package
Le mer 2 août 2006 12:37, Sven Hoexter a écrit : > Hello, > I've been working on the lyx package to get it in a state complying > with the new python policy. > > LyX generates some .pyc and .pyo files during build time and I'm not > sure what to do with them because I thought that the dh_pycentral > call would handle them correctly. Having build a package[1] from the > stuff we currently have in our svn repo[2] I can not find a > postinst/prerm script added to handle the recompilation of those > files. > > >From the resulting packages lyx-common is the one with the python > > stuff. > > I'd appreciate if someone could enlight me and tell me how to deal > with this case correctly. first you need to build depends on python-dev and not python. and the pyo and pyc files are generated by your build process. you have to remove them manually, e.g. using some find -name '*.pyo' mantra. there should be no .pyo/.pyc in the packages you build, those are created by pycentral at postinst / prerm time of your package, thanks to debhelper magic. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpzPlPQad2S6.pgp Description: PGP signature
Re: Request for help to convert the lyx package
On Wed, Aug 02, 2006 at 07:42:40PM +0200, Pierre Habouzit wrote: > and the pyo and pyc files are generated by your build process. you have > to remove them manually, e.g. using some find -name '*.pyo' mantra. The (old) dh_python did remove the .pyc and .pyo files at package build time, so one did not have to bother with their removal. Are the new fancy tools not doing this (asks a developer still not up-to-date with the new python policy)? Thanks, Iustin Pop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for help to convert the lyx package
Le mer 2 août 2006 19:51, Iustin Pop a écrit : > On Wed, Aug 02, 2006 at 07:42:40PM +0200, Pierre Habouzit wrote: > > and the pyo and pyc files are generated by your build process. you > > have to remove them manually, e.g. using some find -name '*.pyo' > > mantra. > > The (old) dh_python did remove the .pyc and .pyo files at package > build time, so one did not have to bother with their removal. Are the > new fancy tools not doing this (asks a developer still not up-to-date > with the new python policy)? looking at dh_python source, bumping PYCOMPAT to 2 does not changes that part of its behaviour. though, even for the lyx-common in the archive there is .pyo/.pyc in /usr/share/lyx/lyx2lyx/ (wich in itself is quite bad). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQzUzv9T3YE.pgp Description: PGP signature
Re: Request for help to convert the lyx package
On Wed, Aug 02, 2006 at 08:02:05PM +0200, Pierre Habouzit wrote: > Le mer 2 août 2006 19:51, Iustin Pop a écrit : > > On Wed, Aug 02, 2006 at 07:42:40PM +0200, Pierre Habouzit wrote: > > > and the pyo and pyc files are generated by your build process. you > > > have to remove them manually, e.g. using some find -name '*.pyo' > > > mantra. > > > > The (old) dh_python did remove the .pyc and .pyo files at package > > build time, so one did not have to bother with their removal. Are the > > new fancy tools not doing this (asks a developer still not up-to-date > > with the new python policy)? > > looking at dh_python source, bumping PYCOMPAT to 2 does not changes that > part of its behaviour. > > though, even for the lyx-common in the archive there is .pyo/.pyc > in /usr/share/lyx/lyx2lyx/ (wich in itself is quite bad). Ah, then that must be it - it must be invoked as: dh_python /usr/share/lyx/lyx2lyx in order for it to scan other dirs and generate the correct postinstall/prerm. Iustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for help to convert the lyx package
Le mer 2 août 2006 20:09, Iustin Pop a écrit : > On Wed, Aug 02, 2006 at 08:02:05PM +0200, Pierre Habouzit wrote: > > Le mer 2 août 2006 19:51, Iustin Pop a écrit : > > > On Wed, Aug 02, 2006 at 07:42:40PM +0200, Pierre Habouzit wrote: > > > > and the pyo and pyc files are generated by your build process. > > > > you have to remove them manually, e.g. using some find -name > > > > '*.pyo' mantra. > > > > > > The (old) dh_python did remove the .pyc and .pyo files at package > > > build time, so one did not have to bother with their removal. Are > > > the new fancy tools not doing this (asks a developer still not > > > up-to-date with the new python policy)? > > > > looking at dh_python source, bumping PYCOMPAT to 2 does not changes > > that part of its behaviour. > > > > though, even for the lyx-common in the archive there is .pyo/.pyc > > in /usr/share/lyx/lyx2lyx/ (wich in itself is quite bad). > > Ah, then that must be it - it must be invoked as: > dh_python /usr/share/lyx/lyx2lyx > in order for it to scan other dirs and generate the correct > postinstall/prerm. well actually, with pycompat to 2, it does not generates the pre/postrm. pycentral/support do takes care of that part. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQq2dIHJIwa.pgp Description: PGP signature
