Bug#383304: bin-NMU scheduling for python transition
On Mon, Aug 21, 2006 at 11:16:28PM -0300, Gustavo Noronha Silva wrote: The other two packages are arch: any and so can be binNMUed, but I'm puzzled why they build-depend on python-all-dev if they only build for the current version of python. Perhaps this is something you would like to fix with a sourceful upload? Actually, they build extensions for both versions of Python - 2.3 and 2.4; the dependencies are wrong; I guess I'll do a sourceful upload to get a higher build-dep on debhelper to ensure the deps are generated correctly, though. Ah, if this was a problem caused by a previous version of debhelper, it would have been fixable using just binNMUs. Sorry for the trouble. FWIW, I remain pretty unimpressed with the decision to make the control fields optional in the python policy. The pycentral-using packages which are binNMUable for the transition have all already been binNMUed using only the information in the Packages and Sources files, but hunting down the list of binNMUable packages that aren't using these fields will require a full, current source mirror and a lot of unpacking and rooting around in source packages. You mean the XB-Python-Version or both? I must confess I failed to see a reason for XS-Python-Version, but I'm definately willing to include them in my packages if you say they're both useful. Both. XB-Python-Version tells which version of python a package is currently built against, XS-Python-Version tells which versions it *could* be built against. Yes, there are some limitations to the current specification of these fields, but their abandonment means having to pick through source packages to try to accurately identify which packages are binNMUable for python transitions, which means we save hardly any time at all from the use of binNMUs. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#383304: bin-NMU scheduling for python transition
Oi Gustavo, On Fri, Aug 18, 2006 at 12:20:29AM -0300, Gustavo Noronha Silva wrote: Some of my Python packages should simply require a binNMU to be in shape with the new python package which is 2.4: ruledispatch (python-dispatch) pyprotocols (python-protocols) turbojson (python-turbojson) turbogears (python-turbogears) This last one is in experimental, so I'm not sure a binNMU scheduled by the Release Team is possible, so if a different action on my part (such as a manual binNMU or a sourceful upload) is required, please let me know. turbojson and turbogears are arch: all packages and cannot be binNMUed. It also doesn't look like they need to be -- they depend on python (= 2.4) | python2.4, which is satisfied just fine. The other two packages are arch: any and so can be binNMUed, but I'm puzzled why they build-depend on python-all-dev if they only build for the current version of python. Perhaps this is something you would like to fix with a sourceful upload? FWIW, I remain pretty unimpressed with the decision to make the control fields optional in the python policy. The pycentral-using packages which are binNMUable for the transition have all already been binNMUed using only the information in the Packages and Sources files, but hunting down the list of binNMUable packages that aren't using these fields will require a full, current source mirror and a lot of unpacking and rooting around in source packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#383304: bin-NMU scheduling for python transition
Hello, Some of my Python packages should simply require a binNMU to be in shape with the new python package which is 2.4: ruledispatch (python-dispatch) pyprotocols (python-protocols) turbojson (python-turbojson) turbogears (python-turbogears) This last one is in experimental, so I'm not sure a binNMU scheduled by the Release Team is possible, so if a different action on my part (such as a manual binNMU or a sourceful upload) is required, please let me know. Thanks, -- Gustavo Noronha Silva [EMAIL PROTECTED] http://people.debian.org/~kov/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
