Hello! I wanted to discuss the (lib)gnome-keyring status and the state we want it to be in before the freeze.
To sum up the current problem, the versions in unstable are RC-buggy because of FTBFS. The FTBFS is caused by a newly introduced testsuite which basically showed the package never worked on kFreeBSD. There has been discussions about the use of mlock(all) and we have over the past year not been able to reach a consensus. I don't feel comfortable making the descision to rip out security features on my own as proposed by porters and noone has been willing to take the discussion upstream. I don't think releasing with really old 3.4 versions is a good idea. I seen two solutions, either ... a/ accept that the software has never really worked on kfreebsd and remove the kfreebsd-any builds from testing. b/ get back to the status quo by disabling the problematic tests on kfreebsd letting the package build and work equally as before. My opinion is that because of how I interpret the part about hiding problems in the social contract, (a) is preferrable. If for some reason (a) is not possible, please tell me and I'll implement (b). For more background, see: https://packages.qa.debian.org/libg/libgnome-keyring.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628383 https://packages.qa.debian.org/g/gnome-keyring.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750883 (As I see it, the gnome-keyring FTBFS is only because of libgnome-keyring being non-functional and not a problem in gnome-keyring itself.) Regards, Andreas Henrikson -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
