Hi Ross:

I'm including another dev on this. I am rapidly running out of ideas as to the cause 
here. Ralf, if you have a chance can you look at this issue and see if you have any 
ideas?

Covering a couple of replies here:

> Also, I had to add a ) at the end of demo.py before it would run.

You are correct I was missing a close ) on the prior line. That is fixed.
I incorrectly transcribed the line from the live CD devel system to the
system I use for checkin. I am using a live CD booted system so I can be
sure I am running in a clean system.

> There's an error in the new code: self has no log_info attribute.

self.log_info() should be self.log_message()

Regarding:

> Error: Arguments are not allowed when running an existing demo.
>       Use the 'nuke' command to start over.

just run 'python ./demo.py' with no arguments. It will discover the existing
demo tracker and serve it. The directions from the script say:

  1. Log in as "demo"/"demo" or "admin"/"admin".
  2. Hit Control-C to stop the server.
  3. Re-start the server by running "./demo.py" again.
  4. Reset the tracker by running "./demo.py nuke".

Would it be better if 3 reads:
  
  3. Re-start the server by running "./demo.py" without any arguments.

demo.py always uses ./demo as the tracker home directory. If run 
without arguments it prompts you for database etc. interactively.
All the arguments are for use when recreating a tracker.

It looks like the traceback in msg8441 has the sequence I expect.

> 127.0.0.1 - - [18/May/2026 15:31:10] "GET / HTTP/1.1" 302 -
> 127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/index HTTP/1.1" 200 -
> 127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/@@file/style.css HTTP/1.1" 200 -
> [... 2 lines]
> 127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/rest HTTP/1.1" 403 -

The 403 is expected as you have not logged in yet. So you are the anonymous
user. The anonymous user doesn't have permissions to use the rest interface
and gets a 403.

> 127.0.0.1 - - [18/May/2026 22:31:12] "GET /favicon.ico HTTP/1.1" 200 -
> # and here it stopped for awhile

Yup the request is done. Nothing more to do until you touch the browser.

> # I don't think I touched any of the controls on the window, and certainly
> # did not try to login
> 127.0.0.1 - - [18/May/2026 22:32:12] Request timed out: timeout('timed out')

Timeout about 1 minute after the last message as expected.

> # after seeing the previous message, I did try to login as demo
> 127.0.0.1 - - [18/May/2026 22:32:23] "POST /demo/ HTTP/1.1" 302 -
> 127.0.0.1 - - [18/May/2026 22:32:23] "GET /demo/index?%40ok_message=Welcome [...] 
> 127.0.0.1 - - [18/May/2026 22:32:23] "GET /demo/rest HTTP/1.1" 200 -

This GET succeeds since you have logged in as demo. The demo user has the
role 'user' which does have permission to access the rest interface.

> 127.0.0.1 - - [18/May/2026 22:32:23] "GET /favicon.ico HTTP/1.1" 200 -
----------------------------------------
Exception occurred during processing of request from ('127.0.0.1', 43348)
Traceback (most recent call last):
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 275, in 
run_cgi
    self.inner_run_cgi()
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 420, in 
inner_run_cgi
    self.wfile.write(data)
  File "/usr/lib/python3.9/socketserver.py", line 799, in write
    self._sock.sendall(b)
BrokenPipeError: [Errno 32] Broken pipe
# Since there is no "Client has gone" message, it seems the new
# except clause didn't activate. However it's the next reported 
# error, and so this may just reflect the order in which nested errors
# are reported.

I think you are right. Since the exception code threw an exception 8-/, it just 
dumped the exceptions in creation order.

# Line 275 is reported as the most 
# recent call, and it certainly looks as if it's covered by the new except
# The next failure definitely reflects the new code.
# Unfortunately, the new code has an error.

Replace log_info with log_message() as above and see if that generates the
Client has gone message.

As to why you are getting the BrokenPipeError, I still have no idea. That
code is doing the following:

    buffer the status response,
    buffer some headers,
    end headers which writes the buffered headers and IIRC a blank line using
         self.wfile.write. So at this point the client connection is open.

then we try to write the data and get the BrokenPipeError indicating the
client connection is closed. My WAG is that something in the headers is
causing the issue. My WAG was that this call:

            self.send_header('Content-Length', len(favico))

is sending 0 as the len of favico. That could cause the browser to close the
connection since there is nothing to read. However we already got the favico
in the original get and it should be cached. I also just tried replacing
len(favico) with 0 (and 20) and I don't get a BrokenPipeError in my environment.
This is with Roundup running in HTTP/1.1 or HTTP/1.0 modes.

Can you use the devtools to look at the login sequence and see what the favicon
request looks like. The headers tab for the favico request should show a
Content-Length of 1406 and the response tab should show the cowboy on a horse.

You orginally reported:

> I logged in with demo/demo and got no response.

This is really weird as you indicated that you are actually logged in.
The favicon failing shouldn't change anything as it is a totally separate
request. You got the login page back according to the logs. Do you have any
Firefox plugins that act as sanitizers or block bad pages?

One other thing to try is to rather than running demo.py run:

   python roundup/scripts/roundup_server -p 8917 -V HTTP/1.0 demo=demo

roundup_server is what demo.py is running under the hood.
This should cause roundup_server to use HTTP version 1.0 rather than the
default of version 1.1. So every connection is closed after the response.
This should eliminate the timeout log as well.

Do you have another graphical browser available? You can use a text mode browser
like w3m or lynx, but they won't get the favicon which is where things fail.
I doubt curl for favico would trigger the issue. Trying a different version of
firefox or chrome might be helpful. You can change demo/config.ini's 'web' stting
from localhost:8917 to hostname:8917 and try connecting from another computer if
you have one.

Thanks for bringing me an interesting problem.

-- rouilj