Conflicts:

	ChangeLog

also reorder the stable changelog entries so they're in temporal order

Conflicts:

	ChangeLog
	configure.in
	contrib/tor-mingw.nsi.in
	src/win32/orconfig.h

this case can now legitimately happen, if you have a cached v2 status
from moria1, and you run with the new list of dirservers that's missing
the old moria1. it's nothing to worry about; the file will die off in
a month or two.

Fixes bug 1198. Solaris doesn't have RLIMIT_MEMLOCK for get/setrlimit,
so disable support because we don't know if all memory can be locked.

mfwitten authored 15 years ago and Nick Mathewson committed 15 years ago

The following commit:

    commit e56747f9
    Author: Nick Mathewson <nickm@torproject.org>
    Date:   Tue Dec 15 14:32:55 2009 -0500

        Refactor a bit so that it is safe to include math.h, and mostly not needed.

introduced this line:

    tor_resolve_LDADD = -lm ../common/libor.a @TOR_LIB_WS32@

which caused the build to fail, because only ../common/libor.a
(via the embedded ../common/util.o via ../common/util.c)
referenced libm's `lround' and `log' symbols, so that the
linker (GNU ld) didn't bother to import those symbols before
reading ../common/libor.a, thus leaving those symbols undefined.

The solution was to swap the order, producing the line:

    tor_resolve_LDADD = ../common/libor.a -lm @TOR_LIB_WS32@

Signed-off-by: Michael Witten <mfwitten@gmail.com>

Conflicts:
	ChangeLog
	configure.in
	contrib/tor-mingw.nsi.in
	src/win32/orconfig.h

if we try to read it to publish stats and it's not there,
that means there are no stats to publish.

reported by swisstorexit.

we never used them, and maybe it's a bad idea to publish them

somebody should add man page entries.

Mark them this way in add_trusted_dir_server

They weren't in sync with reality nor manpage, and only useful to a human
who could simply have checked the manpage.

...to let us
rate-limit client connections as they enter the network. It's
controlled in the consensus so we can turn it on and off for
experiments. It's starting out off. Based on proposal 163.

it's wrong, but that's our problem not its problem

Specifically, there are two cases: a) are we willing to start a new
circuit at a node not in your ExitNodes config option, and b) are we
willing to make use of a circuit that's already established but has an
unsuitable exit.

Now we discard all your circuits when you set ExitNodes, so the only
way you could end up with an exit circuit that ends at an unsuitable
place is if we explicitly ran out of exit nodes, StrictNodes was 0,
and we built this circuit to solve a stream that needs solving.

Fixes bug in dc322931, which would ignore the just-built circuit because
it has an unsuitable exit.