On Sat, May 26, 2012 at 01:57:34AM -0500, Jonathan Nieder wrote: > tags 651912 + pending > quit > > Jonathan Nieder wrote: > > Vincent Bernat wrote: > >> 03:19, Jonathan Nieder <jrnie...@gmail.com> disait : > > >>> | SECStatus > >>> | RNG_RNGInit(void) > >>> | { > >>> | /* Allow only one call to initialize the context */ > >>> | fprintf(stderr, "about to call rng_init()\n"); <--- reached > >>> | PR_CallOnce(&coRNGInit, rng_init); > >>> | fprintf(stderr, "not printed\n"); <--- not reached > > > > The underlying problem was probably fixed by [1]. Thanks to rsleevi > > for pointing it out[2]. > > Looks like the /dev/urandom guess was wrong. Based on testing, this > is fixed by upgrading to libnspr4 2:4.9-2 (4.9-1 still reproduces the > bug). Most prominent change from that update: > > * debian/control, debian/libnspr4*, debian/rules, > mozilla/nsprpub/config/rules.mk, mozilla/nsprpub/configure.in, > mozilla/nsprpub/lib/ds/Makefile.in, > mozilla/nsprpub/lib/libc/src/Makefile.in, > mozilla/nsprpub/pr/src/Makefile.in: Move to unversioned library. > ABI compatibility is ensured upstream, and the SO version, if it needed > a change at any time, would be a change in the library name. There is > no reason to keep making compatibility more difficult with other distros > and upstream binary releases. While previous versions were one-way > compatible (binaries built against other distros or upstream nspr could > work on Debian), this approach works both ways. > > I don't understand why this changed anything. Mike, does this make > any sense? (Why would changing the soname of libnspr4 make it easier > to resolve references from libsoftokn3.so to nspr functions?)
I... don't know :-/ Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org