Fix string/bytes issues under python 3. 1) cgi/client.py: override cgi.FieldStorage's make_file so that file is always created in binary/byte mode. This means that json (and xml) are bytes not strings. 2) rest.py: try harder to find dicttoxml in roundup directory or on sys.path. This just worked under python 2 but python 3 only searches sys.path by default and does not search relative like python 2. 3) rest.py: replace headers.getheader call removed from python 3 with equivalent code. 4) rest.py: make value returned from dispatch into bytes not string. 5) test/caseinsensitivedict.py, test/test_CaseInsensitiveDict.py: get code from stackoverflow that implements a case insensitive key dict. So dict['foo'], dict['Foo'] are the same entry. Used for looking up headers in mocked http rewuset header array. 6) test/rest_common.py: rework tests for etags and rest to properly supply bytes to the called routines. Calls to s2b and b2s and use of BytesIO and overriding make_file in cgi.FieldStorage to try to make sure it works under python 3.

.TH ROUNDUP-ADMIN 1 "24 January 2003"
.SH NAME
roundup-admin \- administrate roundup trackers
.SH SYNOPSIS
\fBroundup-admin\fP [\fIoptions\fP] \fI<command>\fP \fI<arguments>\fP
.SH OPTIONS
.TP
\fB-i\fP \fIinstance home\fP
specify the issue tracker "home directory" to administer
.TP
\fB-u\fP \fIuser\fP[\fB:\fP\fIpassword\fP]
the user and password to use for commands
.TP
\fB-c\fP
When outputting lists of data, comma-separate them. Same as
\fB-S ","\fP.
.TP
\fB-S\fP \fIstring\fP
When outputting lists of data, separate items with given string.
.TP
\fB-s\fP
When outputting lists of data, space-separate them. Same as
\fB-S " "\fP.
.SH FURTHER HELP
 roundup-admin -h
 roundup-admin help                       -- this help
 roundup-admin help <command>             -- command-specific help
 roundup-admin help all                   -- all available help
.SH AUTHOR
This manpage was written by Bastian Kleineidam
<calvin@debian.org> for the Debian distribution of roundup.

The main author of roundup is Richard Jones
<richard@users.sourceforge.net>.