On Wed, Jan 06, 2010 at 05:43:35PM +0000, Sam Morris wrote:
> On Wed, 2010-01-06 at 18:10 +0100, Mike Hommey wrote:
> > On Wed, Jan 06, 2010 at 05:06:08PM +0000, Sam Morris wrote:
> > > On Wed, 2010-01-06 at 17:39 +0100, Mike Hommey wrote:
> > > > On Wed, Jan 06, 2010 at 02:22:32PM +0000, Sam Morris wrote:
> > > > > I just noticed that, when I downgrade to NSS 3.12.2, evolution
> > > > > populates
> > > > > its certificate authorities list (edit -> preferences -> certificates
> > > > > ->
> > > > > authorities). If I upgrade to 3.12.5, run 'evolution
> > > > > --force-shutdown',
> > > > > then re-run evolution, the certificate authority list is empty.
> > > >
> > > > Can you run evolution under strace -eopen and send the output here ?
> > > > That could well be due to changes to the debian changes that happened in
> > > > 3.12.5.
> > >
> > > This call:
> > >
> > > open("/usr/lib/nss/libnssckbi.so", O_RDONLY) = 21
> > >
> > > is present with the old NSS, but not the new. The strace output is
> > > attached in case it's something else.
> >
> > mmmm maybe stat,lstat and others would be needed too. Could you just
> > send a full strace ?
>
> Here you go.
Thanks.
I have identified what i think is only one part of the problem. It is due
to a change in our Debian changes. The previous changes would load
/usr/lib/nss/libnssckbi.so if trying to load a non existing
libnssckbi.so. The new version would only load /usr/lib/nss/libnssckbi.so
if asked for "libnssckbi.so" without a path. What I will try to do is to
still allow loading /usr/lib/nss/libnssckbi.so when detecting the
wrongly populated secmod.db (due to previous behaviour).
What i think is the other part of the problem is that evolution tries to
find libnssckbi.so itself before giving it to libnss. If you give
evolution a new profile, is the certificate list populated in the new
profile under nss 3.12.5 ?
Cheers,
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
