Full traceback:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/roundup/cgi/client.py", line 808, in
renderContext
    result = pt.render(self, None, None, **args)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/templating.py", line 327,
in render
    getEngine().getContext(c), output, tal=1, strictinsert=0)()
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 192, in __call__
    self.interpret(self.program)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 666, in do_useMacro
    self.interpret(macro)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 411, in do_optTag_tal
    self.do_optTag(stuff)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 396, in do_optTag
    return self.no_tag(start, program)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 391, in no_tag
    self.interpret(program)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 689, in do_defineSlot
    self.interpret(slot)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/usr/lib/python2.5/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 462, in do_setLocal_tal
    self.engine.setLocal(name, self.engine.evaluateValue(expr))
  File "/usr/lib/python2.5/site-packages/roundup/cgi/PageTemplates/TALES.py",
line 227, in evaluate
    return expression(self)
  File
"/usr/lib/python2.5/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 194, in __call__
    return self._eval(econtext)
  File
"/usr/lib/python2.5/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 189, in _eval
    return render(ob, econtext.vars)
  File
"/usr/lib/python2.5/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 95, in render
    ob = ob()
  File "/usr/lib/python2.5/site-packages/roundup/cgi/templating.py", line 2549,
in batch
    l = [id for id in klass.filter(matches, filterspec, sort, group)
  File "/usr/lib/python2.5/site-packages/roundup/backends/rdbms_common.py", line
2360, in filter
    self.db.sql(sql, args)
  File "/usr/lib/python2.5/site-packages/roundup/backends/rdbms_common.py", line
165, in sql
    self.cursor.execute(sql)
ProgrammingError: ERROR:  syntax error at or near ")"
LINE 1: ...ue.id=issue_nosy.nodeid and issue_nosy.linkid in () and _iss...

I can't reproduce the problem here, e.g. browsing to
http://bugs.darcs.net/issue?@filter=nosy&nosy=twb
works for me.  Eric, can you confirm this is/isn't still broken?

Thanks, Trent!  We have now narrowed this down a little.  Try
http://bugs.darcs.net/issue?@filter=nosy&nosy=lispy

This was me searching for bugs by Jason.  Turns out his user here is 'dagit'

OK, so URLs such as below cause Python to crash (500) instead of
returning either a 4xx or a meaningful 2xx page (e.g. an empty table,
or error text).  This is not-our-bug and needs to be passed upstream
to the Roundup maintainers.

    http://bugs.darcs.net/issue?@filter=nosy&nosy=not-a-real-user
    http://bugs.darcs.net/issue?@filter=topic&topic=asdf

Compare with referring to a nonexistent user by its ID, or referring
to a nonexistent priority, topic or status by name.  All these give an
empty table.  I actually prefer a 500 to an empty table, because at
least I can *detect* that something has gone wrong... :-)

    http://bugs.darcs.net/issue?@filter=nosy&nosy=9999
    http://bugs.darcs.net/issue?@filter=priority&priority=asdf
    http://bugs.darcs.net/issue?@filter=status&status=asdf

This problem is actually pretty common in Roundup.  For example, this
URL gives a 500 because there's no 404 template!

    http://bugs.darcs.net/issue9999

Regarding not-a-real-user, the nature of the error makes me suspect
that roundup is simply concatenating together an SQL command instead
of composing one using symbols.  Thus, something like

    "select foo from bar where baz = " + toID("foo")

becomes "..." + "" due to shitty error handling, and thus becomes an
invalid SQL query.

PS: if it has your password, ru 1.3 gives a more meaningful error.
(It needs a password because usernames aren't readable by anonymous
users.  Sigh.)

    $ ru query --nosy asdf
    Invalid nosy `asdf'.
    Valid choices are: admin darcs-users droundy jch marnix tommy
    beschmi kowey radekg markstos wglozer vmiklos fx taral brendan
    [...]

Thanks, Trent!

On Mon, Aug 10, 2009 at 09:39:22 +0000, Trent W. Buck wrote:
> OK, so URLs such as below cause Python to crash (500) instead of
> returning either a 4xx or a meaningful 2xx page (e.g. an empty table,
> or error text).  This is not-our-bug and needs to be passed upstream
> to the Roundup maintainers.
> 
>     http://bugs.darcs.net/issue?@filter=nosy&nosy=not-a-real-user
>     http://bugs.darcs.net/issue?@filter=topic&topic=asdf

So I was able to search for 'not-a-real-user' on both the roundup
and Python trackers and what we get is a nice empty list of results.
It looks like something is wrong with our setup.

I think we need somebody to study this in more detail, perhaps by
checking with the Roundup team

> Compare with referring to a nonexistent user by its ID, or referring
> to a nonexistent priority, topic or status by name.  All these give an
> empty table.  I actually prefer a 500 to an empty table, because at
> least I can *detect* that something has gone wrong... :-)
> 
>     http://bugs.darcs.net/issue?@filter=nosy&nosy=9999
>     http://bugs.darcs.net/issue?@filter=priority&priority=asdf
>     http://bugs.darcs.net/issue?@filter=status&status=asdf

For reference, this sort of thing also displays an empty table.

By the way, I haven't figured out what subset of the fields you need
to pass in to the script.  It seems like the sensible thing you
supply above doesn't have the intended effect and you have to use
the whole lot from the search template.  You probably know better
than I do what's going on given your ru experience.

> This problem is actually pretty common in Roundup.  For example, this
> URL gives a 500 because there's no 404 template!
> 
>     http://bugs.darcs.net/issue9999

I think this may have been our fault, perhaps due to Roundup 1.4
growing a 404 template while our config was Roundup 1.2.

I've copied the
  /usr/share/roundup/templates/minimal/html/_generic.404.html
to our tracker directory.

If anybody wants to jazz this up a tiny bit, remember that you
can access http://darcs.net/darcs-bugtracker

> Regarding not-a-real-user, the nature of the error makes me suspect
> that roundup is simply concatenating together an SQL command instead
> of composing one using symbols.  Thus, something like
> 
>     "select foo from bar where baz = " + toID("foo")
> 
> becomes "..." + "" due to shitty error handling, and thus becomes an
> invalid SQL query.

Worth talking with them about this if we sort the above you, I imagine.