Preparing (lib)gnome-keyring for the freeze.
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
Reply to: