> Please reply to debian-python with fix reports or reports of false
> positives.
Not quite either of these, but in a similar vein, I've filed bug #584833
against gourmet with the patch from Ubuntu for this issue as part of regular
due diligence on the Ubuntu side - so gourmet should probably be
On Sat, Jun 05, 2010 at 10:43:27PM -0400, Scott Kitterman wrote:
> As was recently discussed on debian-python:
>
> http://lists.debian.org/debian-python/2010/05/msg00111.html
>
> String exceptions are no longer supported at all in Python 2.6. Since this
> is
> the Python version planned to be
"Jakub Wilk" wrote:
>* Scott Kitterman , 2010-06-05, 19:31:
>>+ will represent the current default Debian Python version. The
>>+ binary package python3 will represent the current
>>+ Debian Python3 version. As far as is reasonable, python and python3
>>+ should be tre
* Vincent Bernat , 2010-06-06, 12:34:
Please note that even with the fact that string exceptions are not
supported, they raise a TypeError exception. Since the (almost) only
way to catch a string exception is to catch all exceptions, the
TypeError would be catched as well.
This is a bit oversim
* Emilio Pozuelo Monfort , 2010-06-06, 00:41:
Since the Debian Policy forbids packages that don't provide the same
functionality (like these two modules) to conflict with each other, you
cannot go that route.
Strictly speaking, policy you referred to (10.1) applies only to
conflicting binari
* Scott Kitterman , 2010-06-05, 19:31:
+ will represent the current default Debian Python version. The
+ binary package python3 will represent the current
+ Debian Python3 version. As far as is reasonable, python and python3
+ should be treated as separate runtim
OoO En ce milieu de nuit étoilée du dimanche 06 juin 2010, vers 04:43,
Scott Kitterman disait :
> A couple of weeks ago, Jakub Wilk noticed this issue and prepared both a DD
> list of affected packages and the grep output that was used to detect
> potentially affected packages. I know some o
> You put the module in some dir and then use a .pth so you can import it
> normally. This will avoid the file conflict, but not the namespace one, and
> I'm
> not sure what would happen if you install both modules, so you better prod
> upstream into renaming it.
> Cheers,
> Emilio
thanks, I wil
On 06/06/10 11:21, PICCA Frédéric-Emmanuel wrote:
>> Since the Debian Policy forbids packages that don't provide the same
>> functionality (like these two modules) to conflict with each other, you
>> cannot
>> go that route. You could probably hack it with .pth so that you don't need a
>> package
On 06/06/10 04:43, Scott Kitterman wrote:
> A couple of weeks ago, Jakub Wilk noticed this issue and prepared both a DD
> list of affected packages and the grep output that was used to detect
> potentially affected packages. I know some of these packages have been fixed
> already. Please reply
> Hi Frédéric,
Hello
> IMHO one of them needs to be renamed, probably the newest one. If the one you
> want to package is only used in the project upstream mentions, renaming that
> one
> would be a good option They can temporarily do something like this:
> try:
>import newname
> except Imp
11 matches
Mail list logo
