Opened 23 months ago

Closed 23 months ago

ERROR: AnnounceSystem failed

Reported by: Owned by: anonymous doki_pen normal AnnouncerPlugin normal hasienda 0.12

I just tried to upgrade from the 0.11 announcer plugin to 0.12dev plugin and haven't been able to send any notifications. I have pasted the error below.

Additional information: I can assure you that my trac.ini has a good email server configured because the configuration I am using works with the default notificaiton system and the 0.11 Announcer plugin.

2012-01-28 18:12:42,588 Trac[api] ERROR: AnnouncementSystem failed.
Traceback (most recent call last):
File "build\bdist.win32\egg\announcer\api.py", line 561, in _real_send
evt)
File "build\bdist.win32\egg\announcer\distributors\mail.py", line 353, in distribute
self._do_send(transport, event, k, v, fmtdict[k])
File "build\bdist.win32\egg\announcer\distributors\mail.py", line 525, in _do_send
self.send(*package)
File "build\bdist.win32\egg\announcer\distributors\mail.py", line 534, in send
File "build\bdist.win32\egg\announcer\distributors\mail.py", line 590, in send
smtp = smtpclass(**args)
File "C:\Program Files (x86)\VisualSVN Server\trac\python\lib\smtplib.py", line 239, in __init__
(code, msg) = self.connect(host, port)
File "C:\Program Files (x86)\VisualSVN Server\trac\python\lib\smtplib.py", line 295, in connect
self.sock = self._get_socket(host, port, self.timeout)
File "C:\Program Files (x86)\VisualSVN Server\trac\python\lib\smtplib.py", line 273, in _get_socket
return socket.create_connection((port, host), timeout)
File "C:\Program Files (x86)\VisualSVN Server\trac\python\lib\socket.py", line 561, in create_connection
raise error, msg
error: [Errno 10061] No connection could be made because the target machine actively refused it


comment:1 Changed 23 months ago by rjollos

• Description modified (diff)

comment:2 in reply to: ↑ description Changed 23 months ago by rjollos

• Severity changed from blocker to normal

Additional information: I can assure you that my trac.ini has a good email server configured because the configuration I am using works with the default notificaiton system and the 0.11 Announcer plugin.

Some of the configuration options have changed for 0.12. Did you read the wiki page, and AnnouncerPlugin#EmailConfig in particular?

comment:3 Changed 23 months ago by rjollos

hasienda, since you know a lot of the history of this plugin, maybe you can help with a couple of minor fixes. The 0.12 link under AnnouncerPlugin#Download is broken, and it is potentially confusing to users that 0.11 and 0.11.2dev are not located under branches. I haven't heard from doki_pen for a while; he is probably busy with other things. Maybe we can do a little cleanup here in his absence?

comment:4 follow-up: ↓ 5 Changed 23 months ago by hasienda

Indeed, there is a frightening backlog of issues by now.

This can't stay that way, if this plugin should retain reasonable reputation. I've been starting to look into this plugin lately. After some rather big changes by doki_pen there are some tasks to finish this work and get issues fixed.

Best is to avoid trunk branch for now. This should change rapidly with me pushing it into my production environment. With repository layout in general I would still rely on a talk to doki_pen before doing changes there. The absence of a solid default policy for hacks repositories here is a known weakness IMHO.

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 8 Changed 23 months ago by rjollos

Best is to avoid trunk branch for now. This should change rapidly with me pushing it into my production environment.

I'm also happy to take on the risk of testing your latest changes in my production environment too, closely tracking changes to the trunk and giving quick feedback.

With repository layout in general I would still rely on a talk to doki_pen before doing changes there.

I imagine he receives many ticket notifications and doesn't have time to read them. Perhaps we should send him an email.

The absence of a solid default policy for hacks repositories here is a known weakness IMHO.

Could you explain further what you have in mind?

comment:6 follow-up: ↓ 7 Changed 23 months ago by anonymous

• Resolution set to invalid
• Status changed from new to closed

Thanks for having a look at this. I did not read the wiki page carefully enough because I missed the configuation changes for 0.12. Once I updated the config, all of my problems were solved.

Thanks again!

comment:7 in reply to: ↑ 6 Changed 23 months ago by hasienda

...
Thanks again!

You're welcome. Thank your for your quick response on rjollos's recommendations, much appreciated.

comment:8 in reply to: ↑ 5 Changed 23 months ago by hasienda

Best is to avoid trunk branch for now. This should change rapidly with me pushing it into my production environment.

I'm also happy to take on the risk of testing your latest changes in my production environment too, closely tracking changes to the trunk and giving quick feedback.

Ok, I know. Never meant to say it would be otherwise. The backlog is my own problem too, the missing feedback not so much.

With repository layout in general I would still rely on a talk to doki_pen before doing changes there.

I imagine he receives many ticket notifications and doesn't have time to read them. Perhaps we should send him an email.

Sure, this will be next, if it turns out to be impossible to make contact via IRC. Let me try only a few more days.

The absence of a solid default policy for hacks repositories here is a known weakness IMHO.

Could you explain further what you have in mind?

Sure. The unwritten branch-per-Trac-version agreement might have worked until 0.11, but now the 0.11/0.12 "hybrid" branch is more common. But more in general the approach of branch/tags/trunk structure is much less adopted by plugin authors than what would allow for quick orientation inside arbitrary branches. Sticking more to Trac core repo housekeeping style is not the only option, maybe not even the best, but we should more actively encourage a rather uniform repo structure to improve overall code accessibility and make mapping plugin version vs. Trac version obvious.

I'm not at all determined on the outcome, only we should improve this user-facing part of Trac hacks development activities.

Modify Ticket

Change Properties