On Thu, 2010-01-07 at 10:03 +0100, Mike Hommey wrote:
> 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).
Great! Based on the strace output I tried symlinking libnssckbi.so into
~/.evolution and found that it works around this bug quite nicely.
> What i think is the other part of the problem is that evolution tries to
> find libnssckbi.so itself before giving it to libnss.
Is it wrong to do so? Or is the method for locating libnssckbi.so a grey
area?
I notice that evolution looks in MOZILLA_NSS_LIB_DIR which is populated
from the libdir variable in nss.pc. On Debian, of course,
that's /usr/lib. What about one of:
* if it's never correct for /usr/lib/libnssckbi.so to exist on a
Debian system, modifying NSS to open /usr/lib/nss/libnssckbi.so
when an application asks for it
* adding a Debian-specific variable in nss.pc that points
at /usr/lib/nss and patching Debian packages to use it when
locating libnssckbi.so
* patching Debian packages to open "libnssckbi.so" with that exact
name, and not try searching for it themselves
> If you give evolution a new profile, is the certificate list populated in the
> new
> profile under nss 3.12.5 ?
It is not populated in this case.
> Cheers,
>
> Mike
Thanks for the diagnosis! :)
--
Sam Morris <s...@robots.org.uk>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
