roundup-users Mailing List for Roundup Issue Tracker (Page 483)

Hi there,
> > No I did not. Should I have? Around the whole command
> > or just the parameters? Ah well, suppose I could try
> > both and see.
> 
> Yes, like in the INSTALL document.

Ahhhh, I'd followed the instructions as outlined
on http://roundup.sourceforge.net/doc/index.html
and there were no quotes there.
However, there are quotes in INSTALL doc that
came with the package. Should have known better.
My mistake.
 

> > 1 last question.
> > If I were to do a "roundup-admin -i /work/roundup init",
> > would I lose all the issues that were already in the
> > database? I'm too scared to try this.
> 
> That initialises a database, so yes, you'll lose everything! 
> Hrm, I think I 
> will put a check in there to see if the destination dir 
> already exists and 
> prompt the user in such instances...
> 
> Why were you considering running that command?

Wasnt really, was just curious.

Thanks again,
Chai
http://www.ozemail.com.au/~calcium

On Tuesday 04 December 2001 10:28, Cha...@ot... wrote:
> Hi there Richard,
> Thanks for the very quick reply.
>
> > >    I was getting 'service unavailable' initially.
> > >    It appears that the parameter '/work/roundup' (my instance home)
> > >    was not being passed to roundup-mailgw in the /etc/aliases.
> > >    Must be a RH7.1 thing?
> >
> > Anyone else had a problem with this? Did you have the
> > "quotes" around the command?
>
> No I did not. Should I have? Around the whole command
> or just the parameters? Ah well, suppose I could try
> both and see.

Yes, like in the INSTALL document.


> > > Q/ In the manual, for Apache, it says SetEnv ROUNDUP_INSTANCE_HOMES
> > >     "Default=/usr/local/share/roundup/instances/Default"
> > >    I checked and dont have this path. Do I create it or is this
> > >    supposed to be <instance_home>/instances/Default?
> >
> > It's supposed to be <instance_home>
>
> I dont have a <instance_home>/instances directory?
> Do I need to create this manually?
> ie mkdir -p /work/roundup/instances/Default
> or did I miss a step in the install procedures?

No, the line should be "Default=<instance_home>"

the manual has an example instance_home of 
/usr/local/share/roundup/instances/Default ... this will be clarified.


> 1 last question.
> If I were to do a "roundup-admin -i /work/roundup init",
> would I lose all the issues that were already in the
> database? I'm too scared to try this.

That initialises a database, so yes, you'll lose everything! Hrm, I think I 
will put a check in there to see if the destination dir already exists and 
prompt the user in such instances...

Why were you considering running that command?


    Richard

Hi there Richard,
Thanks for the very quick reply.

> >    I was getting 'service unavailable' initially.
> >    It appears that the parameter '/work/roundup' (my instance home)
> >    was not being passed to roundup-mailgw in the /etc/aliases.
> >    Must be a RH7.1 thing?
>
> Anyone else had a problem with this? Did you have the 
> "quotes" around the command?

No I did not. Should I have? Around the whole command
or just the parameters? Ah well, suppose I could try
both and see.


> > Q/ In the manual, for Apache, it says SetEnv ROUNDUP_INSTANCE_HOMES
> >     "Default=/usr/local/share/roundup/instances/Default"
> >    I checked and dont have this path. Do I create it or is this
> >    supposed to be <instance_home>/instances/Default?
> 
> It's supposed to be <instance_home>

I dont have a <instance_home>/instances directory?
Do I need to create this manually?
ie mkdir -p /work/roundup/instances/Default
or did I miss a step in the install procedures?


> >    However, when I do the following,
> >    $ echo test  | mail -s '[issue] mytest' issue_tracker
> >
> >    I get a bounced mail with the Python error messages as below.
> 
> The error is known - the quickest fix is to modify 
> roundup/mailwg.py. To do 
[Fix deleted]

Applied the fix to /usr/lib/python2.1/site-packages/roundup/mailgw.py
and the "echo test | mail etc..." test works!!!
Great!

1 last question.
If I were to do a "roundup-admin -i /work/roundup init",
would I lose all the issues that were already in the
database? I'm too scared to try this.

Many thanks again,
Chai
http://www.ozemail.com.au/~calcium

On Monday 03 December 2001 17:21, Cha...@ot... wrote:
> o By default, it seems to have put my stuff (ie roundup-admin
>   etc) in /usr/bin rather than /usr/local/bin as stated
>   in the doco. Doesnt matter, I think.

I'll look into cleaning up the documenation.


> I made my instance home directory /work/roundup
>
> o/ I tested the mail gateway using the echo test | mail etc...
>    thing. Perhaps something in the doco as to the expected
>    behaviour would be helpful. This is obvious *after* u get
>    it working but not while u're trying to get it to work.
>
>    I was getting 'service unavailable' initially.
>    It appears that the parameter '/work/roundup' (my instance home)
>    was not being passed to roundup-mailgw in the /etc/aliases.
>    Must be a RH7.1 thing?
>
>    The roundup-mailgw script in /etc/smrsh was modified
>    to call /usr/bin/roundup-mailgw with the instance home
>    hardcoded.
>    eg
>      #!/bin/sh
>      /usr/bin/roundup-mailgw /work/roundup
>
>    I dont get the service unavailable anymore. Yayyyy!!!

Anyone else had a problem with this? Did you have the "quotes" around the 
command?


>    However, when I do the following,
>    $ echo test  | mail -s '[issue] mytest' issue_tracker
>
>    I get a bounced mail with the Python error messages as below.

The error is known - the quickest fix is to modify roundup/mailwg.py. To do 
this, find the lines in roundup/mailgw.py:

        #
        # handle the users
        #
        author = self.db.uidFromAddress(message.getaddrlist('from')[0])
        # reopen the database as the author
        username = self.db.user.get(author, 'username')
        self.db.close()
        self.db = self.instance.open(username)

and just after the instance open, add:

        # re-get the class with the new database connection
        cl = self.db.getclass(classname)



> Q/ In the manual, for Apache, it says SetEnv ROUNDUP_INSTANCE_HOMES
>     "Default=/usr/local/share/roundup/instances/Default"
>    I checked and dont have this path. Do I create it or is this
>    supposed to be <instance_home>/instances/Default?

It's supposed to be <instance_home>


> Q/ How can I remove a roundup user?
>    I looked for a FAQ but couldnt find one.

You can't remove, only retire. The roundup-admin tool offers the retire 
command for this purpose.


> o  From the doco, wasnt immediately obvious that
>    the email interface could be done either via
>    /etc/aliases or via cron. I know. I should read
>    the manual more carefully. 8-)

I'll look into cleaning that up.


     Richard

Hi there all,
I'm trying to install roundup for a 6 person
team on a Linux RH7.1 installation.

First of all, I'm really grateful for the project.
The guys here think it's great as well.

Anyway, I've got the web interface up but am having a
bit of trouble with setting up the email interface.

Had a few questions. I hope someone will be able
to assist ( and have added some observations).

I have installed roundup 0.3.0.
(downloaded from the net on the 29th Nov 2001).

o By default, it seems to have put my stuff (ie roundup-admin
  etc) in /usr/bin rather than /usr/local/bin as stated
  in the doco. Doesnt matter, I think.

I made my instance home directory /work/roundup

o/ I tested the mail gateway using the echo test | mail etc...
   thing. Perhaps something in the doco as to the expected
   behaviour would be helpful. This is obvious *after* u get
   it working but not while u're trying to get it to work.

   I was getting 'service unavailable' initially.
   It appears that the parameter '/work/roundup' (my instance home)
   was not being passed to roundup-mailgw in the /etc/aliases.
   Must be a RH7.1 thing?
   
   The roundup-mailgw script in /etc/smrsh was modified
   to call /usr/bin/roundup-mailgw with the instance home
   hardcoded.
   eg
     #!/bin/sh
     /usr/bin/roundup-mailgw /work/roundup

   I dont get the service unavailable anymore. Yayyyy!!!

   However, when I do the following,
   $ echo test  | mail -s '[issue] mytest' issue_tracker 

   I get a bounced mail with the Python error messages as below.

#-- cut here---
----  traceback of failure  ----
Traceback (most recent call last):
  File "/usr/lib/python2.1/site-packages/roundup/mailgw.py", line 141, in
handle_Message
    self.handle_message(message)
  File "/usr/lib/python2.1/site-packages/roundup/mailgw.py", line 477, in
handle_message
    nodeid = cl.create(**props)
  File "/usr/lib/python2.1/site-packages/roundup/roundupdb.py", line 92, in
create
    react(self.db, self, nodeid, None)
  File "/work/roundup/detectors/nosyreaction.py", line 57, in nosyreaction
    cl.sendmessage(nodeid, msgid)
  File "/usr/lib/python2.1/site-packages/roundup/roundupdb.py", line 274, in
sendmessage
    recipients = self.db.msg.get(msgid, 'recipients')
  File "/usr/lib/python2.1/site-packages/roundup/backends/back_anydbm.py",
line 51, in __getattr__
    return self.classes[classname]
KeyError: msg

#-- end here

   What have I done wrong? Any suggestions?
   I go to the web interface and the issue *is* created.

Q/ In the manual, for Apache, it says SetEnv ROUNDUP_INSTANCE_HOMES
    "Default=/usr/local/share/roundup/instances/Default"
   I checked and dont have this path. Do I create it or is this
   supposed to be <instance_home>/instances/Default?

Q/ How can I remove a roundup user?
   I looked for a FAQ but couldnt find one.

o  From the doco, wasnt immediately obvious that
   the email interface could be done either via
   /etc/aliases or via cron. I know. I should read
   the manual more carefully. 8-)

Anyway, am very grateful for the package, again.

Many thanks in advance,  
Chai
http://www.ozemail.com.au/~calcium
Tel +61 3 8892 4606   +61 401 688 408 (m)

-> > I'm running the latest dist, 3.0.  Two questions that will either reveal
-> > my ignorance or some minor UI bugs ;):
-> >
-> > * When I select "my issues", redisplay, and then uncheck "deferred" so that
-> > 	I can see what issues I *haven't* deferred, it then redisplays all
-> > 	undeferred issues, not just mine;
-> 
-> Hrm - this works fine for me. What browser are you using?

I was pushing the wrong button ;).  It wasn't entirely clear that it was
the wrong button in Mozilla, for some reason, but when I tried it in IE
it became clear because the color scheme worked better in IE.

-> > * Is there any way to *unselect* an entry on the nosy list?
-> 
-> You should be able to deselect the entry from the list, and it'll go away 
-> when you save. There was an issue with the 0.3.0 release and the author 
-> removing themself from the nosy list, which is fixed in the CVS. 0.3.1 will 
-> be due out next week, or possibly the weekend and will have these fixes.

Ahh, didn't realize that CTRL-left-click (in Moz) deselected.  Oops ;).

thanks, & sorry for the cluelessness!

--titus

On Friday 30 November 2001 06:01, Titus Brown wrote:
> I'm running the latest dist, 3.0.  Two questions that will either reveal
> my ignorance or some minor UI bugs ;):
>
> * When I select "my issues", redisplay, and then uncheck "deferred" so that
> 	I can see what issues I *haven't* deferred, it then redisplays all
> 	undeferred issues, not just mine;

Hrm - this works fine for me. What browser are you using?

[I'm using the CVS code, but a quick check doesn't show up any changes that 
might have "fixed" this problem - I regularly use the filtering you describe]


> * Is there any way to *unselect* an entry on the nosy list?

You should be able to deselect the entry from the list, and it'll go away 
when you save. There was an issue with the 0.3.0 release and the author 
removing themself from the nosy list, which is fixed in the CVS. 0.3.1 will 
be due out next week, or possibly the weekend and will have these fixes.


    Richard

On Friday 30 November 2001 01:30, Patrick Ohly wrote:
> On Wed, 2001-11-28 at 23:25, Richard Jones wrote:
> > I'm just thinking out loud here, but what about (switching to the
> > proposed ConfigParser format):
> >
> > ----
> > [Mail address mappings]
> > bug...@bi...: bug
> > sup...@bi...: support
> > dis...@bi...: discuss
> > iss...@bi...: issue, support   # determine from
> > subject
> >
> > [Message class bug]
> > uses class: issue
> > priority: bug
> > assignedto: richard
> >
> > ----
>
> This looks good, and I don't mind how "uses class" is called. Any idea
> how long it might take to implement this? I'm afraid I won't be able
> to help as I haven't got much time to spare right now, but I don't mind
> testing the latest CVS as soon as this feature is there.

It's a while off. I have some other stuff I need to get into the code, like 
transaction support so things don't go strange when submissions fail half-way 
through.


    Richard

I'm running the latest dist, 3.0.  Two questions that will either reveal
my ignorance or some minor UI bugs ;):

* When I select "my issues", redisplay, and then uncheck "deferred" so that
	I can see what issues I *haven't* deferred, it then redisplays all
	undeferred issues, not just mine;

* Is there any way to *unselect* an entry on the nosy list?

cheers,
--titus

On Wed, 2001-11-28 at 23:25, Richard Jones wrote:
> On Thursday 29 November 2001 01:20, Patrick Ohly wrote:
> > I am currently evaluating roundup and hope to introduce it
> > as issue tracking system for our projects, which involve
> > several external developers.
> 
> I'd love to hear how it turns out!

Oh, I'm sure you would hear all the bloody details ;-)

> > Sending mail via localhost works, in fact, it even works
> > from within roundup if I modify an issue via web interface.
> > Replying to an issue adds the comment, then fails without
> > sending mails to the author or users on the nosy list:
> 
> This is a relatively long-standing bug (weeks, at least ;) and I've finally 
> had a chance to track it down. It's fixed in the CVS - the simple fix to 
> 0.3.0 is to find the lines in roundup/mailgw.py:
> 
[...]

Yes, now it works - thanks!

> Having the interface create different classes based on the e-mail address is 
> something I've been mulling over myself.

This is what I was aiming at.

> I'm just thinking out loud here, but what about (switching to the proposed 
> ConfigParser format):
> 
> ----
> [Mail address mappings]
> bug...@bi...: bug
> sup...@bi...: support
> dis...@bi...: discuss
> iss...@bi...: issue, support   # determine from subject
> 
> [Message class bug]
> uses class: issue
> priority: bug
> assignedto: richard
> 
> ----

This looks good, and I don't mind how "uses class" is called. Any idea
how long it might take to implement this? I'm afraid I won't be able
to help as I haven't got much time to spare right now, but I don't mind
testing the latest CVS as soon as this feature is there.

-- 
Freundliche Gruesse / Best Regards

Patrick Ohly
Software Engineer
--------------------------------------------------------------------
//// pallas 
Pallas GmbH / Hermuelheimer Str. 10 / 50321 Bruehl / Germany
Pat...@pa... / www.pallas.com
Tel +49-2232-1896-30 / Fax +49-2232-1896-29
--------------------------------------------------------------------

On Thursday 29 November 2001 01:20, Patrick Ohly wrote:
> I am currently evaluating roundup and hope to introduce it
> as issue tracking system for our projects, which involve
> several external developers.

I'd love to hear how it turns out!


> It's good to see that direct replies to an email that has
> created an issue are now handled correctly by matching
> against the subject - thanks Richard :-)

No probs :)



> Sending mail via localhost works, in fact, it even works
> from within roundup if I modify an issue via web interface.
> Replying to an issue adds the comment, then fails without
> sending mails to the author or users on the nosy list:

This is a relatively long-standing bug (weeks, at least ;) and I've finally 
had a chance to track it down. It's fixed in the CVS - the simple fix to 
0.3.0 is to find the lines in roundup/mailgw.py:

        #
        # handle the users
        #
        author = self.db.uidFromAddress(message.getaddrlist('from')[0])
        # reopen the database as the author
        username = self.db.user.get(author, 'username')
        self.db.close()
        self.db = self.instance.open(username)

and just after the instance open, add:

        # re-get the class with the new database connection
        cl = self.db.getclass(classname)


> I have some more questions: it isn't possible to query the database
> via email yet, is it? We don't want that anyway, unless there is some
> kind of access control.

Yeah, that's a fairly messy direction to go in. But hey, if you think of a 
way of dealing with it, punt it at us!


> Can I configure defaults for certain properties or even the class
> that is created by an email? We might create one account for discussion
> among developers and another for support requests, which would
> get a higher initial priority.

There's nothing stopping you creating extra classes in the database. The mail 
gateway uses the [class] specification in the Subject line to determine which 
class the message is to be entered into. The extended schema already supports 
[issue] and [support] classes.

Having the interface create different classes based on the e-mail address is 
something I've been mulling over myself. Some sort of configuration that 
basically says:

  MAIL_ADDRESS_MAPPINGS = {
    'iss...@bi...': None,        # default, use [class]
    'bug...@bi...': 'issue',       # no [issue] needed
    'sup...@bi...': 'support',
    'dis...@bi...': 'discuss',
  }

Also, the initial values of some of the node properties should also be 
configurable. For example, at the moment, we set the initial status to 
'unread', if it exists. If it doesn't, it's set to '1' (the first status 
created) ... suboptimal. It'd be good to be able to set those in the config. 
But the config could then get rather unwieldy...

I'm just thinking out loud here, but what about (switching to the proposed 
ConfigParser format):

----
[Mail address mappings]
bug...@bi...: bug
sup...@bi...: support
dis...@bi...: discuss
iss...@bi...: issue, support   # determine from subject

[Message class bug]
uses class: issue
priority: bug
assignedto: richard

----

The "issue", "support" and "discuss" classes are "real" classes. Hey, this 
also lets us validate the class that should be allowed in for each of the 
addresses, which is a Good Thing (it just occurred to me that there is no 
restriction, though only the issue/support classes will actually work)

The bug class is an extension of the issue class which is configured to use 
the issue class for storage, but has some defaults for properties. I don't 
particularly like the "uses class" syntax, any suggestions?



     Richard

Hi all,

I am currently evaluating roundup and hope to introduce it
as issue tracking system for our projects, which involve
several external developers.

They have no access to the machine where the web server
might be running, so all communication has to be done by
email. It should also integrate well or even replace the
current main communication channel, which is one mailing
list.

It's good to see that direct replies to an email that has
created an issue are now handled correctly by matching
against the subject - thanks Richard :-)

However, I ran into a problem when creating or replying to
an issue by email. I have set
  MAILHOST = localhost
  MAIL_DOMAIN = pallas.com
  ISSUE_TRACKER_EMAIL = 'tool-issues@%s'%MAIL_DOMAIN
  ADMIN_EMAIL = 'pohly@%s'%MAIL_DOMAIN
(full instance_config.py attached).

Sending mail via localhost works, in fact, it even works
from within roundup if I modify an issue via web interface.
Replying to an issue adds the comment, then fails without
sending mails to the author or users on the nosy list:

-----------------------------------------------------------------------
From: 	po...@pa...
Subject: 	failed issue tracker submission
Date: 	28 Nov 2001 14:51:11 +0100	
----  traceback of failure  ----
Traceback (most recent call last):
  File "/usr/lib/python2.1/site-packages/roundup/mailgw.py", line 141,
in handle_Message
    self.handle_message(message)
  File "/usr/lib/python2.1/site-packages/roundup/mailgw.py", line 477,
in handle_message
    nodeid = cl.create(**props)
  File "/usr/lib/python2.1/site-packages/roundup/roundupdb.py", line 92,
in create
    react(self.db, self, nodeid, None)
  File "/Projects/psp/roundup/tool-issues/detectors/nosyreaction.py",
line 57, in nosyreaction
    cl.sendmessage(nodeid, msgid)
  File "/usr/lib/python2.1/site-packages/roundup/roundupdb.py", line
274, in sendmessage
    recipients = self.db.msg.get(msgid, 'recipients')
  File
"/usr/lib/python2.1/site-packages/roundup/backends/back_anydbm.py", line
51, in __getattr__
    return self.classes[classname]
KeyError: msg

---- failed message follows ----
Received: from sux (sux [192.168.3.45])
        by olymp2.internal.pallas.com (8.8.8+Sun/8.8.8) with ESMTP id
OAA00746
        for <too...@pa...>; Wed, 28 Nov 2001 14:51:02 +0100
(MET)
Received: from pohly by sux with local (Exim 3.32 #1 (Debian))
        id 169579-0001Si-00
        for <too...@pa...>; Wed, 28 Nov 2001 14:51:03 +0100
Subject: [issue] Test with file
From: Patrick Ohly <Pat...@pa...>
To: too...@pa...
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.99.2 (Preview Release)
Date: 28 Nov 2001 14:51:03 +0100
Message-Id: <1006955463.5457.4.camel@sux>
Mime-Version: 1.0
Sender: Patrick Ohly <po...@pa...>
Content-Type: text/plain
Content-Length: 403

Second issue with the same title.

-----------------------------------------------------------------------

I have some more questions: it isn't possible to query the database
via email yet, is it? We don't want that anyway, unless there is some
kind of access control.

Can I configure defaults for certain properties or even the class
that is created by an email? We might create one account for discussion
among developers and another for support requests, which would
get a higher initial priority.

-- 
Freundliche Gruesse / Best Regards

Patrick Ohly
Software Engineer
--------------------------------------------------------------------
//// pallas 
Pallas GmbH / Hermuelheimer Str. 10 / 50321 Bruehl / Germany
Pat...@pa... / www.pallas.com
Tel +49-2232-1896-30 / Fax +49-2232-1896-29
--------------------------------------------------------------------

This release contains several new features which will require migration, so
please read MIGRATION.txt!

Big stuff in this release:
  - lots of bug fixes, thanks to all users for their great feedback!
  - much more flexible administration tool
  - much better handling of errors
  - more configuration options
  - CGI login uses cookies instead of basic auth
  - passwords are encoded in the database 
  - much, much more: see the CHANGES file for details.

Source and documentation is available at the website:
     http://roundup.sourceforge.net/

Release Info (via download page):
     http://sourceforge.net/project/showfiles.php?group_id=31577

Mailing lists - the place to ask questions:
     http://sourceforge.net/mail/?group_id=31577



About Roundup
=============

Roundup is a simple-to-use and -install issue-tracking system with  
command-line, web and e-mail interfaces. It is based on the winning design
from Ka-Ping Yee in the Software Carpentry "Track" design competition.

Note: Ping is not responsible for this project. The contact for this project
is ri...@us....

Roundup manages a number of issues (with flexible properties such as
"description", "priority", and so on) and provides the ability to
 (a) submit new issues,
 (b) find and edit existing issues, and
 (c) discuss issues with other participants.
The system will facilitate communication among the participants by managing
discussions and notifying interested parties when issues are edited. One of
the major design goals for Roundup that it be simple to get going. Roundup
is therefore usable "out of the box" with any python 2.0+ installation. It
doesn't even need to be "installed" to be operational, though a
disutils-based install script is provided.

It comes with two issue tracker templates and three database back-ends. 

Hi!

I just read migration.txt, and I think there should be an automated
instance update in case you did NOT change anything.

In another system, I use this algorithm:

- on first install, copy the *.py files and append a SHA digest of
them, as a comment, like this:

	#SHA: xx-xx-...-xx

- on update, read the installed files, check their SHA
	* if equal, just overwrite the file
   * if changed, give a warning (and possibly do a 3-way merge to
*.py.update)

This reduces the amount of the needed manual work dramatically.

Ciao, J=FCrgen

On Tue, 6 Nov 2001 08:34, David Edwards wrote:
> I've just set up roundup-0.3.0pre3 to run from Apache. It seems like
> everything works as admin, but I can't register a new user. When I fill
> in the required fields of the registration form and press the Register
> button, I get a new login and registration form. The is no indiction
> of success or failure. When I try to log in as the new user, I get a
> "no such user" message.

There's been some issues with the cookie which are resolved in the CVS.

I'll be bundling a new release tomorrow I hope.


    Richard

On Mon, 5 Nov 2001 16:34:46 -0500, David Edwards wrote:

>I've just set up roundup-0.3.0pre3 to run from Apache. It seems like
>everything works as admin, but I can't register a new user. When I fill
>in the required fields of the registration form and press the Register
>button, I get a new login and registration form. The is no indiction
>of success or failure. When I try to log in as the new user, I get a
>"no such user" message.
>
>Any help would be appreciated.

You prolly have the same prob I had, I had to change the cookie
handling to get the latest version running. Namely, the cookie needs an
expire else IE barfs (or more to the point, forgets it immediately).

Patches tomorrow. BTW, Richard, could you add me as a developer? I can
provide fixes for SuSE 7.0 and NT4 environments.

--
Juergen Hermann, Karlsruhe, Germany | IRC: snibril

I've just set up roundup-0.3.0pre3 to run from Apache. It seems like
everything works as admin, but I can't register a new user. When I fill
in the required fields of the registration form and press the Register
button, I get a new login and registration form. The is no indiction
of success or failure. When I try to log in as the new user, I get a
"no such user" message.

Any help would be appreciated.


-- 

David Edwards
ALH Systems, Inc.

On Wednesday 31 October 2001 07:57, Brad Clements wrote:
> Got tired of my issue messages being wider than my desktop, so I hacked in
> StructuredText into Roundup, very easy.

Yep, patched the source in CVS, thanks.



    Richard

On Wednesday 31 October 2001 17:47, junho lee wrote:
> hi, I am trying to install roundup in the HP-UX.
> when I run "python setup.py install", I get following
> error message.
>
> $ python setup.py install
> Running unit tests...
> Traceback (most recent call last):
>   File "setup.py", line 29, in ?
>     import test
>   File "test/__init__.py", line 22, in ?
>     import test_dates, test_schema, test_db,
> test_multipart, test_mailsplit
>   File "test/test_multipart.py", line 22, in ?
>     from roundup.mailgw import Message
>   File "roundup/mailgw.py", line 79, in ?
>     import string, re, os, mimetools, cStringIO,
> smtplib, socket, binascii, quopri
>   File "/usr/local/lib/python2.1/smtplib.py", line 42,
> in ?
>     import socket
>   File "/usr/local/lib/python2.1/socket.py", line 41,
> in ?
>     from _socket import *
> ImportError: No module named _socket
> $ version
> sh: version:  not found.

That looks like you've got a problem with your python installation in 
general. The following should work, even on HPUX :)

% python
Python 2.1.1 (#1, Aug 30 2001, 17:36:05) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on linux-i386
Type "copyright", "credits" or "license" for more information.
>>> import socket
>>> print socket
<module 'socket' from '/usr/lib/python2.1/socket.py'>
>>>

If that does't work, you need to post a message to the python mailing list 
for help - see

   http://www.python.org/psa/MailingLists.html#clp
   http://mail.python.org/mailman/listinfo/python-list


    Richard

hi, I am trying to install roundup in the HP-UX.
when I run "python setup.py install", I get following
error message.

$ python setup.py install
Running unit tests...
Traceback (most recent call last):
  File "setup.py", line 29, in ?
    import test
  File "test/__init__.py", line 22, in ?
    import test_dates, test_schema, test_db,
test_multipart, test_mailsplit
  File "test/test_multipart.py", line 22, in ?
    from roundup.mailgw import Message
  File "roundup/mailgw.py", line 79, in ?
    import string, re, os, mimetools, cStringIO,
smtplib, socket, binascii, quopri
  File "/usr/local/lib/python2.1/smtplib.py", line 42,
in ?
    import socket
  File "/usr/local/lib/python2.1/socket.py", line 41,
in ?
    from _socket import *
ImportError: No module named _socket
$ version
sh: version:  not found.

please help me.

thank you.



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Got tired of my issue messages being wider than my desktop, so I hacked in 
StructuredText into Roundup, very easy.

1. Get StructuredTextNG from Zope CVS, described here:

http://dev.zope.org/Members/jim/StructuredTextWiki/NGReleases


2. Install StructuredText into site-packages

3. Edit htmltemplate.py, add this to the top:

try:
    from StructuredText.StructuredText import HTML as StructuredText
except ImportError:
    StructuredText = None


4. Add a do_stext() function, as:

    def do_stext(self,property,escape=0):
        """render as structured text"""
        s = self.do_plain(property,escape=escape)
        if not StructuredText:
            return s
        else:
            return StructuredText(s,level=1,header=0)


5. Edit msg.index and msg.item, change plain() to stext()

Done .. 5 minute job.

Brad Clements,                bk...@mu...   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               AOL-IM: BKClements

On Sat, 27 Oct 2001 05:21, Brad Clements wrote:
> After upgrading to pre3, I find that my nosy list has bk...@Mu... and
> su...@an... in it
>
> Now, this may have been there before the upgrade, dunno.

Yep, but it's a pretty dumb behaviour.


> One thing is, my userid 'bkc' (also in the nosy list), uses
> bk...@mu... as it's email address (note the difference in case).
>
> I suspect that roundup took the email submission as a new user request
> thing, rather than using a caseless strcmp when looking at sender email
> addresses.

OK, the stringFind method in the hyperdatabase (used to match e-mail 
addresses for the nosy list, and also issue titles) has been changed to 
perform caseless matches.


> Also, I think it should be clearer or easier to turn off anonymous email
> (maybe I saw that in the new release)..

Nope, this isn't in, but could be added as a configuration option. Could I 
ask you to submit a feature request for this at the sf.net tracker please?


    Richard

On Sat, 27 Oct 2001 05:15, Juergen Hermann wrote:
> The docs should mention where to find "roundup.cgi"... after all, it's
> not installed anywhere.

Fixed, thanks.


   Richard

On Sat, 27 Oct 2001 06:00, Juergen Hermann wrote:
> What is that Rewrite rule supposed to do? I don't need it here, do I
> miss something?

It isn't needed any more - I'll remove it from the INSTALL doc.


    Richard

Hi!

What is that Rewrite rule supposed to do? I don't need it here, do I
miss something?

Ciao, J=FCrgen