Inspired from report by bfr: going to http://bugs.darcs.net/xyz leads to 
a yucky:

MOD_PYTHON ERROR

ProcessId:      23780
Interpreter:    'bugs.darcs.net'

ServerName:     'bugs.darcs.net'
DocumentRoot:   '/var/lib/roundup/trackers/darcs'

URI:            '/xyz'
Location:       None
Directory:      '/var/lib/roundup/trackers/'
Filename:       '/var/lib/roundup/trackers/darcs/dummy.py'
PathInfo:       '/xyz'

Phase:          'PythonHandler'
Handler:        'roundup.cgi.apache'

Traceback (most recent call last):

  File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 
1537, in HandlerDispatch
    default=default_handler, arg=req, silent=hlist.silent)

  File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 
1229, in _process_target
    result = _execute_target(config, req, object, arg)

  File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 
1128, in _execute_target
    result = object(arg)

  File "/usr/lib/pymodules/python2.5/roundup/cgi/apache.py", line 135, 
in handler
    _client.main()

  File "/usr/lib/pymodules/python2.5/roundup/cgi/client.py", line 361, 
in main
    self.inner_main()

  File "/usr/lib/pymodules/python2.5/roundup/cgi/client.py", line 529, 
in inner_main
    raise NotFound, e

NotFound: xyz

The behaviour if you go to a non-existing object of a known class like 
http://bugs.darcs.net/issue39779709876 (non-existent at the time of this 
writing), or if you repeat the same experiment on another roundup 
instance http://issues.roundup-tracker.org/xyz seems much more 
reasonable.

So we need to work out what exactly roundup do differently and possibly 
imitate it.  Alternatively, we could figure out where to trap the error 
and give a more reasonable page.