On 03/04/13 16:09, Jack Bates wrote: > Hi, here is a blog post about this issue: > > http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html >
Really very interesting stuff. Thanks for sharing Now I'm convinced that the right fix for this is to revert upstream d769529a71ccda4e833f919f3c5693d25b005ff0 [1] commit on libgcrypt like Ubuntu did. The Regression introduced on python-gnutls by such reversion was already fixed on Ubuntu with another patch (see LP:#1013798 [2]) and they have been running with the patch for some time without more problems (AFAIK) so I think that we can assume that there are no more regressions. Therefore I think we should reassign this bug back to libgcrypt11. Fix it with a patch that reverts d769529a71ccda4e833f919f3c5693d25b005ff0 [1] and then fill another RC bug for python-gnutls asking for applying the same patch that Ubuntu applied (see LP:#1013798 [2]) Andreas.. what do you think? looks this like the way to go for you? Furthermore libgcrypt upstream seems to be ok with this change, isn't it? [3] Regards! -------- [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=d769529a71ccda4e833f919f3c5693d25b005ff0 [2] https://bugs.launchpad.net/bugs/1013798 [3] http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198
signature.asc
Description: OpenPGP digital signature
