[this problem is already known by the developers. i'm 
submitting a bug report here for the record and hoping 
that some win32 expert can solve the issue ;-) ]

Roundup has code to support Windows Services to let a 
user run the roundup-server in background and manage 
the process thru the Control  Panel. It's broken thou.

Follows the symptoms of the problem:

 C:>roundup-server -p 8080 -d pid -l log 
support=c:\\tracker\\support
 Usage: '-c [options] install|update|remove|start [...]
|stop|restart 
 [...]|debug[...]'
 Options for 'install' and 'update' commands only:
   --username domain\username : The Username the 
service is to run under
   --password password : The password for the username
   --startup [manual|auto|disabled] : How the service 
starts, default = 
 manual
 
 C:>roundup-server -p 8080 -d pid -l log 
support=c:\\tracker\\support
 -c install
 Error: exceptions.ValueError: Instances must be 
name=home
 
 Usage:
 roundup-server [-n hostname] [-p port] [-l file] [-d file] 
[name=tracker 
 home]*
 ... etc ...

Regards,
-Hernan

Logged In: YES 
user_id=6405

I've removed the code from roundup-server. Now I just need to find the 
old submitted windows service ... 
 

Logged In: YES 
user_id=112690

really? too bad...
i almost made it work. :-)
there's still a problem though: i would like to configure the 
web server parameters (host, port, trackers, etc.) like we do 
it now (thru command parameters) but i'm unable to do so, 
host and port work hardwired.
i'll see if i can do something about it tomorrow. success or not 
i'll send you my modified round_server.py. (sorry, no diffs)

Logged In: YES 
user_id=6405

I'd assumed that the windows service code would need to be split into a 
separate program so the command line arguments didn't get confused 
like in the present scheme. If you can offer a solution either way, I'd be 
very grateful! 

Logged In: YES 
user_id=112690

there are several ways to do it.
it much depends on the final user interface.

right now what i've got working is the standard server script
with the "-c" service option providing it is the *first* option
in the opt list. the configure options ("-p","-n") aren't
working at all so you have to modify the "address = ('',8888)"
line in roundup_server.py and the TRACKER_WEB dict in the
same file to meet custom needs. options -d -l must be
provided just to conform to validation piece of code and
to distinguish from background/foreground startup.
the limitations i mentioned are due to the *minimal* changes
i made (less than 10 lines) but resulting in a server able
to be installed, removed, started and stopped either by
command line or thru windows' control panel.
basically, what i did was to separate the "-c" optargs
from the rest and send them to an appropiate call of
win32serviceutil.HandleCommandLine()
i'm attaching here my version of roundup_server.py for your
best convinience.

some alternatives for server customization that i can
imagine now are:
a. use the same command line options. say:
   C:>roundup-server.bat "-c install" -n SERVER -p 8765 ..etc..
   
b. use an external custom parameter file, something along the
   lines you did in trackers/config.py. say:
   C:>roundup-server.bat "-c install" -f 
c:/roundup/websrvcfg.py
   
c. use module variables in roundup_server.py.
d. do nothing :-)

for alternative a, we have to rearrange the code because
RoundupService class will have to parse the options at
*execution time*

fyi, whatever we do the server needs to modify and read
the registry. not a problem because those custom keys will be 
under
the Roundup Service registry subtree.

Logged In: YES 
user_id=112690

I saw some changes on round_server.py in CVS so I made a 
patch that could be applied to such version.
I made it very simple. Standard (-n, -p, -h, etc) options are 
mutually exclusive from Windows service option -c.
You have to customize roundup_service.py to add trackers 
and to change port number, host name, etc.
I'm uploading here my patch. Please review it, test it under 
un*x and tell me what do you think about it.
An extended usage() message that include the windows 
service part is missing. My english ain't so good...

-Hernan

Logged In: YES 
user_id=112690

what's the status of this? do you (roundup developers) want 
me to do something else? do you still want to support 
windows service in the future?
giving 0.6.3 the patch is obsolete now :(
i can try to make another patch but i still need some external 
support to test on non-windows system.
regards,
-hernan

Logged In: YES 
user_id=6405

Sorry, I lost track of this bug! 
 
Please, revise the patch as necessary and I'll release 0.6.4 ASAP. 
 

Logged In: YES 
user_id=112690

wrt branches you said:
> > Browsing CVS I couldn't find the tags for 0.6.3 or 0.6.3.1
> > Am I missing something?
> 
> Nope, I haven't tagged those releases.
>
> Note that you can get them as the latest version on the
> maint-0-6 branch.

then, the patch on windows services for roundup_server.py
over which branch do you want me to make diff? maint-0-6, 
HEAD, or both?

Logged In: YES 
user_id=6405

maint-0-6 would be preferable, as I'd like to see the server fixed for a 
0.6 release. 

Logged In: YES 
user_id=858274

This bug seems close to being a duplicate of my feature 
request 799854 ?

Logged In: YES 
user_id=112690

attached is a patch (a correct unified one) to add windows 
service support to roundup-server.py
the patch is against the last revision of maint-0-6 branch.
it does not add registry configuration parameters like the 
feature request 799854 does.  mine it's a *minimal* patch 
just to make the current code work.
please, test it on un*x.
let me know if there are problems with it.

-Hernan

Logged In: YES 
user_id=112690

btw, the patch file is "win-svc-patch.txt".
-H.

Logged In: YES 
user_id=6405

I've applied the patch, thanks! Please confirm that maint-0-6 works for 
you on Windows. 
 
Not applied to HEAD yet - will await confirmation that it works :) 

Logged In: YES 
user_id=112690

it's working.
there's still an "inconvinient" (bug?):
Windows Services commands may use additional parameters 
(for instance, if you want the service to be registered in 
automatic mode.)  the problem is that the win32 machinery 
uses long options (ie: --startup auto) that interferes with 
getopt.
to solve this i would need to complete rearrange the code 
that process command line options.  a windows sysadmin can 
manage the service via the standard admins tools so i think 
it's not an urgent request.
i'd recommend you apply it as it is and with time i can 
refactor that part of the code.  that will also allow to solve 
feature request 799854.