Bug#381389: Reproduceable, and not smart-notifier's fault
Hi, On Thu, 05 Oct 2006, Brian Sutherland wrote: I reproduced the installation problem, but didn't try the build leading up to it with the latest debhelper. I wanted to prepare a patch for this, but I really get 2.4 and not current when building smart-notifier with python 2.4... Yeah, I get the same. But I will note that the smart-notifier binary in the archive has Python-Version set to current and build depends on =5.0.37.2. [...] I guess now the bug should be sent back to smart-notifier to be fixed with an updated build dependency. Yes but it doesn't bring much as the 5.0.37.2 version is nowhere (and thus not on buildd). But you should at least rebuild the package with a current debhelper to fix #383099. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#381389: Reproduceable, and not smart-notifier's fault
On Wed, 16 Aug 2006, Brian Sutherland wrote: On Sat, Aug 12, 2006 at 12:17:21PM -0300, Margarita Manterola wrote: I can reproduce this in my machine. It's due to the fact that /usr/bin/python points to python2.3 in my box, and smart-notifier's python version is current. Changing this in /var/lib/dpkg/status, fixes this bug. Therefore, as discussed with Pierre Habouzit, this is a bug in dh_python, which is not placing the correct version in the Python-Version field, and It looks to me like this is what happens: smart-notifier has XS-Python-Version set to 2.4 but the binary package gets Python-Version current if built with python2.4 as the default python. Can you really reproduce that with the dh_python of debhelper 5.0.37.3 ? I wanted to prepare a patch for this, but I really get 2.4 and not current when building smart-notifier with python 2.4... Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#381389: Reproduceable, and not smart-notifier's fault
On Wed, Oct 04, 2006 at 09:42:14AM +0200, Raphael Hertzog wrote: On Wed, 16 Aug 2006, Brian Sutherland wrote: On Sat, Aug 12, 2006 at 12:17:21PM -0300, Margarita Manterola wrote: I can reproduce this in my machine. It's due to the fact that /usr/bin/python points to python2.3 in my box, and smart-notifier's python version is current. Changing this in /var/lib/dpkg/status, fixes this bug. Therefore, as discussed with Pierre Habouzit, this is a bug in dh_python, which is not placing the correct version in the Python-Version field, and It looks to me like this is what happens: smart-notifier has XS-Python-Version set to 2.4 but the binary package gets Python-Version current if built with python2.4 as the default python. Can you really reproduce that with the dh_python of debhelper 5.0.37.3 ? I reproduced the installation problem, but didn't try the build leading up to it with the latest debhelper. I wanted to prepare a patch for this, but I really get 2.4 and not current when building smart-notifier with python 2.4... Yeah, I get the same. But I will note that the smart-notifier binary in the archive has Python-Version set to current and build depends on =5.0.37.2. So looks like it was only a problem in 5.0.37.2, or something else changed in between then and now. Thanks for looking into it. I guess now the bug should be sent back to smart-notifier to be fixed with an updated build dependency. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381389: Reproduceable, and not smart-notifier's fault
On Tue, 22 Aug 2006, Brian Sutherland wrote: On Tue, Aug 22, 2006 at 12:42:03AM +0200, Josselin Mouette wrote: Le mercredi 16 ao?t 2006 ? 11:34 +0200, Brian Sutherland a ?crit : It seems to me that dh_python should set Python-Version to x.y if XS-Python-Version is x.y regardless of what the current default python is. At least that is what I would have expected. This is one of the reasons why I don't like the X?-Python-Version fields. There is no way for the build process to tell between those two cases: 1. building for python2.4 only as we build for one version only and python2.4 is the default version; 2. building for python2.4 only as this is the only supported version. Does this not work for case 1: XS-Python-Version: current and for case 2: XS-Python-Version: 2.4 Yes it should. It's solely a dh_python bug... and not really a design issue with the field as Joss thinks. I could create a patch for it but as Joey wants to remove dh_python altogether, I try to make it happen by moving what's required to dh_pycentral/dh_pysupport instead of fixing something that will go away. (If only Joey had been a bit more involved when the discussion on python policy was live he could have advised me to create a library for dependency generation from the beginning instead of letting me use dh_python. And at that time, I would have had no problem pushing it into python-support/python-central.) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#381389: Reproduceable, and not smart-notifier's fault
Le mercredi 16 août 2006 à 11:34 +0200, Brian Sutherland a écrit : smart-notifier has XS-Python-Version set to 2.4 but the binary package gets Python-Version current if built with python2.4 as the default python. In my tests with python2.3 as the default, Python-Version is set to 2.4. In both cases there is no python dependency (only python2.4). So anyone installing smart-notifier built with python2.4 as the defualt on a machine with python2.3 as the default experiences breakage when python-central tries to compile the bytecode for python2.3. It seems to me that dh_python should set Python-Version to x.y if XS-Python-Version is x.y regardless of what the current default python is. At least that is what I would have expected. This is one of the reasons why I don't like the X?-Python-Version fields. There is no way for the build process to tell between those two cases: 1. building for python2.4 only as we build for one version only and python2.4 is the default version; 2. building for python2.4 only as this is the only supported version. If we apply the solution you describe, case 2 will be fixed, but case 1 will break: when upgrading the default python interpreter, the module will not be available for the new version. Thus, we need separate interfaces to tell the helper tools about that. The -V flag was reintroduced in dh_pysupport (in 0.4) to fix this case, and I believe something similar should be done in dh_pycentral as well - dh_python is doomed to be removed anyway. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Bug#381389: Reproduceable, and not smart-notifier's fault
On Tue, Aug 22, 2006 at 12:42:03AM +0200, Josselin Mouette wrote: Le mercredi 16 ao�t 2006 � 11:34 +0200, Brian Sutherland a �crit : smart-notifier has XS-Python-Version set to 2.4 but the binary package gets Python-Version current if built with python2.4 as the default python. In my tests with python2.3 as the default, Python-Version is set to 2.4. In both cases there is no python dependency (only python2.4). So anyone installing smart-notifier built with python2.4 as the defualt on a machine with python2.3 as the default experiences breakage when python-central tries to compile the bytecode for python2.3. It seems to me that dh_python should set Python-Version to x.y if XS-Python-Version is x.y regardless of what the current default python is. At least that is what I would have expected. This is one of the reasons why I don't like the X?-Python-Version fields. There is no way for the build process to tell between those two cases: 1. building for python2.4 only as we build for one version only and python2.4 is the default version; 2. building for python2.4 only as this is the only supported version. Does this not work for case 1: XS-Python-Version: current and for case 2: XS-Python-Version: 2.4 If we apply the solution you describe, case 2 will be fixed, but case 1 will break: when upgrading the default python interpreter, the module will not be available for the new version. Thus, we need separate interfaces to tell the helper tools about that. The -V flag was reintroduced in dh_pysupport (in 0.4) to fix this case, and I believe something similar should be done in dh_pycentral as well - dh_python is doomed to be removed anyway. Yep, with the latest strategy of dh_python, this is probably a python-central bug and has very little to do with dh_python or python-support. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!!
Bug#381389: Reproduceable, and not smart-notifier's fault
On Sat, Aug 12, 2006 at 12:17:21PM -0300, Margarita Manterola wrote: I can reproduce this in my machine. It's due to the fact that /usr/bin/python points to python2.3 in my box, and smart-notifier's python version is current. Changing this in /var/lib/dpkg/status, fixes this bug. Therefore, as discussed with Pierre Habouzit, this is a bug in dh_python, which is not placing the correct version in the Python-Version field, and It looks to me like this is what happens: smart-notifier has XS-Python-Version set to 2.4 but the binary package gets Python-Version current if built with python2.4 as the default python. In my tests with python2.3 as the default, Python-Version is set to 2.4. In both cases there is no python dependency (only python2.4). So anyone installing smart-notifier built with python2.4 as the defualt on a machine with python2.3 as the default experiences breakage when python-central tries to compile the bytecode for python2.3. It seems to me that dh_python should set Python-Version to x.y if XS-Python-Version is x.y regardless of what the current default python is. At least that is what I would have expected. I'm reassigning to debhelper (I'm sorry :-/) :) No worries. Just my luck to update this in the middle of a python transition! -- Love, Marga -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381389: Reproduceable, and not smart-notifier's fault
reassign 381389 debhelper 5.0.37.3 thanks I can reproduce this in my machine. It's due to the fact that /usr/bin/python points to python2.3 in my box, and smart-notifier's python version is current. Changing this in /var/lib/dpkg/status, fixes this bug. Therefore, as discussed with Pierre Habouzit, this is a bug in dh_python, which is not placing the correct version in the Python-Version field, and I'm reassigning to debhelper (I'm sorry :-/) -- Love, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
