We just upgraded our roundup install at
issues.fresco.org, and a bug we'd hacked around before
resurfaced, reminding us that we should fix it properly.

The problem is the same as that described at
http://sourceforge.net/mailarchive/forum.php?thread_id=1424613&forum_id=966x
-- to wit, we can't log in, because we have our
DocumentRoot set to .../roundup.cgi/issues/, which
works fine otherwise, except roundup tries to set the
login cookie with a path of /issues/.  I've just
rehacked our version of client.py with the attached
patch.  It's a bit better than the hard-coding we had
before; now it checks for an env var
ROUNDUP_COOKIE_PATH and only uses the old logic if said
variable is undefined.  This should work okay, though
it has the flaw that it doesn't easily support multiple
trackers.  (On the other hand, people with multiple
trackers are less likely to run into this problem; and
it's a Simple Matter Of httpd.conf'ing to set this
envvar to different values depending on the particular
URL being accessed.)

The thread mentioned above suggests using
dirname(REQUEST_URI), which would in fact work in our
situation, but has two maybe-major flaws that I see:
  1) it's still programmatic; URL mapping can be very
weird,      and I don't know that it'll work in all
cases.  A way to explicitly set the cookie path avoids
these problems.
  2) it assumes that URLs within a single tracker will
never contain slashes, which is quite an assumption to
make in such an implicit way.

But, anyway, those are two possibilities for your
consideration; I suppose a third is to combine them, by
using the dirname() trick as the fall-back logic in the
first possibility.

Logged In: YES 
user_id=6405

We should be able to use the TRACKER_WEB variable to help us out here, 
shouldn't we? In fact, the path for the cookie should just be the path in that 
config var... 
 

Logged In: YES 
user_id=765

I wasn't actually aware of that variable, but now that you
point it out, it does look like the thing to use.