Le jeudi 05 juin 2008 à 17:33 +0200, Manuel Metz a écrit : > well yes, I did. I don't know/work with "meld". So, it might be that > there is more that causes trouble with this software, which I can not > know of (but according to the bug reports the bug was resolved in > 2.12.1-4, wasn't it ?).
No, it was not. The problem is not caused by the patch itself, but by the introduction of wakeupfd in pygtk, which is in use since python2.5 2.5.2-5. > I was reporting the other bug because the very simple example did not > work. I AM MORE THAN HAPPY TO HELP TO IMPROVE Debian, but _excuse me_, I > can not understand why to call a patch "part of the solution" if it > causes a problem that was NOT apparent before. And I have not seen any > other bug-report that is solved by this patch. So for me, this solution > caused a problem, which I was reporting. > There might be, of course, another problem which has not not been > reported, and the patch might be part of that other problem - that I can > not know since it was not talked about. But how can it be a solution to > the problem I was reporting, when the former package worked fine ??? There are applications that lock without the patch. Some lock with this patch, and some lock with the new version that has been proposed by upstream. The wakeupfd stuff is dealing with the main loop's internals, and it is hard to understand the implications - I’m pretty sure I don’t understand half of them. In all cases, I fail to see how you can call the 2.12.1-4 version “working”, since the memory corruption bug causes crashes in most pygtk applications with this version. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
