From metatracker at psf.upfronthosting.co.za  Wed Jan  2 19:32:00 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Wed, 02 Jan 2013 18:32:00 +0000
Subject: [Tracker-discuss] [issue483] irker detector for roundup
In-Reply-To: <1348834053.04.0.0348292997231.issue483@psf.upfronthosting.co.za>
Message-ID: <1357151520.98.0.0452199669656.issue483@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

FTR this has been reported upstream at http://issues.roundup-tracker.org/issue2550782 and now Roundup ships the irker detector by default.
The instructions to install/update the irker detector are available at http://wiki.python.org/moin/TrackerDevelopment#irker_setup.

----------
status: resolved -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue483>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Jan  2 19:57:55 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Wed, 02 Jan 2013 18:57:55 +0000
Subject: [Tracker-discuss] [issue498] Don't reopen resolved issues when a
	comment is added
Message-ID: <1357153075.25.0.415892643879.issue498@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

Attached patch does what the title says.

----------
assignedto: ezio.melotti
files: dontreopen.diff
messages: 2674
nosy: ezio.melotti
priority: wish
status: unread
title: Don't reopen resolved issues when a comment is added

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue498>
_______________________________________________________
-------------- next part --------------
diff --git a/detectors/statusauditor.py b/detectors/statusauditor.py
--- a/detectors/statusauditor.py
+++ b/detectors/statusauditor.py
@@ -21,11 +21,9 @@
 #$Id$
 
 def chatty(db, cl, nodeid, newvalues):
-    ''' If the issue is currently 'unread', 'resolved', 'done-cbb' or None,
-        then set it to 'chatting'
-    '''
+    """If the issue is currently 'unread' or None, then set it to 'chatting'"""
     # don't fire if there's no new message (ie. chat)
-    if not newvalues.has_key('messages'):
+    if 'messages' not in newvalues:
         return
     if newvalues['messages'] == cl.get(nodeid, 'messages'):
         return
@@ -41,17 +39,15 @@
     current_status = cl.get(nodeid, 'status')
 
     # see if there's an explicit change in this transaction
-    if newvalues.has_key('status'):
+    if 'status' in newvalues:
         # yep, skip
         return
 
-    # determine the id of 'unread', 'resolved' and 'chatting'
-    fromstates = []
-    for state in 'unread resolved done-cbb'.split():
-        try:
-            fromstates.append(db.status.lookup(state))
-        except KeyError:
-            pass
+    # determine the id of 'unread'
+    try:
+        fromstates.append(db.status.lookup('unread'))
+    except KeyError:
+        pass
 
     # ok, there's no explicit change, so check if we are in a state that
     # should be changed
@@ -61,9 +57,8 @@
 
 
 def presetunread(db, cl, nodeid, newvalues):
-    ''' Make sure the status is set on new issues
-    '''
-    if newvalues.has_key('status') and newvalues['status']:
+    """Make sure the status is set on new issues"""
+    if 'status' in newvalues and newvalues['status']:
         return
 
     # get the unread state ID

From metatracker at psf.upfronthosting.co.za  Wed Jan  2 20:00:30 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Wed, 02 Jan 2013 19:00:30 +0000
Subject: [Tracker-discuss] [issue498] Don't reopen resolved issues when a
	comment is added
In-Reply-To: <1357153075.25.0.415892643879.issue498@psf.upfronthosting.co.za>
Message-ID: <1357153230.81.0.260902488957.issue498@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Committed in http://hg.python.org/tracker/meta/rev/0695400dc093.

----------
status: unread -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue498>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Jan  2 20:03:52 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Wed, 02 Jan 2013 19:03:52 +0000
Subject: [Tracker-discuss] [issue498] Don't reopen resolved issues when a
	comment is added
In-Reply-To: <1357153075.25.0.415892643879.issue498@psf.upfronthosting.co.za>
Message-ID: <1357153432.15.0.893304597704.issue498@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Testing.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue498>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Jan  2 22:35:07 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Wed, 02 Jan 2013 21:35:07 +0000
Subject: [Tracker-discuss] [issue497] Resort "Assign To" list
In-Reply-To: <1356888801.68.0.806413565727.issue497@psf.upfronthosting.co.za>
Message-ID: <1357162507.64.0.493134268124.issue497@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Here's a patch.

----------
assignedto:  -> ezio.melotti
nosy: +ezio.melotti
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue497>
_______________________________________________________
-------------- next part --------------
diff --git a/html/issue.item.html b/html/issue.item.html
--- a/html/issue.item.html
+++ b/html/issue.item.html
@@ -144,10 +144,13 @@
  <td tal:condition="context/assignee/is_edit_ok">
   <select name="assignee">
    <option value="-1">nobody</option>
-   <tal:block tal:repeat="userdata python:db._db.user.filter_sql('select id,_username from _user where _roles like \'%Developer%\' order by _username')">
-    <option tal:attributes="value python:userdata[0];
-                            selected python:str(userdata[0]) == context.assignee._value"
-            tal:content="python:userdata[1]"></option>
+   <option tal:attributes="value request/user/id"
+           tal:content="request/user/username">current_user</option>
+   <tal:block tal:repeat="userdata python:sorted(db._db.user.filter_sql('select id,_username from _user where _roles like \'%Developer%\''), key=lambda user:user[1].lower())">
+   <option tal:condition="python:str(userdata[0]) != request.user.id"
+           tal:attributes="value python:userdata[0];
+                           selected python:str(userdata[0]) == context.assignee._value"
+           tal:content="python:userdata[1]"></option>
    </tal:block>
   </select>
  </td>

From metatracker at psf.upfronthosting.co.za  Wed Jan  2 22:53:01 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Wed, 02 Jan 2013 21:53:01 +0000
Subject: [Tracker-discuss] [issue497] Resort "Assign To" list
In-Reply-To: <1356888801.68.0.806413565727.issue497@psf.upfronthosting.co.za>
Message-ID: <1357163581.59.0.57759237695.issue497@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Done in http://hg.python.org/tracker/python-dev/rev/505ba6c440c9.

----------
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue497>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Thu Jan  3 22:34:03 2013
From: metatracker at psf.upfronthosting.co.za (Serhiy Storchaka)
Date: Thu, 03 Jan 2013 21:34:03 +0000
Subject: [Tracker-discuss] [issue499] Add separator to "Assigned To" list
Message-ID: <1357248843.5.0.857883743192.issue499@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Please add followed line between current user name and rest names in "Assigned To" combobox:

<option value="" disabled="disabled">------------</option>

It will add a nice separator as in "Search" form.

----------
messages: 2680
nosy: serhiy.storchaka
priority: wish
status: unread
title: Add separator to "Assigned To" list

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue499>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Fri Jan  4 04:18:27 2013
From: metatracker at psf.upfronthosting.co.za (Stephen Turnbull)
Date: Fri, 04 Jan 2013 03:18:27 +0000
Subject: [Tracker-discuss] [issue500] Posting changes from "old" tracker
	pages causes spurious	updates
Message-ID: <1357269507.95.0.118401099594.issue500@psf.upfronthosting.co.za>


New submission from Stephen Turnbull:

See also thread starting at http://mail.python.org/pipermail/python-dev/2013-January/123437.html.

Jesus Cea writes:

I get the notification about new issues open in the bugtracker. If I 
see an interesting "bug", I usually open a Firefox tab with it, to 
monitor it, decide if I will work on it in the future, whatever. 
 
When I have time to decide, I proceed. If I find the issue interesting 
but don't have the time to work on it, or somebody else is taking care 
of it, I just add myself to the nosy list, and close the tab. 
 
The problem with this is that even if I reload the tab, flags are 
usually stale and when I add myself to the nosy list, I revert flags 
to the old value.

----------
messages: 2681
nosy: stephen
priority: bug
status: unread
title: Posting changes from "old" tracker pages causes spurious updates

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue500>
_______________________________________________________

From stephen at xemacs.org  Fri Jan  4 04:20:37 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 04 Jan 2013 12:20:37 +0900
Subject: [Tracker-discuss] [Python-Dev] Posting frequent spurious
	changes in bugtracker
In-Reply-To: <CAP1=2W4DhnSKVCMvRNm-PvEpkRNkntLM=tbuNQWCgnXuwsvnnQ@mail.gmail.com>
References: <50E5E2DA.4090606@jcea.es>
	<CAP1=2W4DhnSKVCMvRNm-PvEpkRNkntLM=tbuNQWCgnXuwsvnnQ@mail.gmail.com>
Message-ID: <87txqxbpmi.fsf@uwakimon.sk.tsukuba.ac.jp>

Now that Jesus has provided a heads-up, detailed discussion belongs on
the metatracker IMO.  Warning: Reply-To set to tracker-discuss at python.org.

metatracker workers: Created issue500.  More info: see this thread:
http://mail.python.org/pipermail/python-dev/2013-January/123437.html

Brett Cannon writes:

 > > Or am I doing something fundamentally wrong?. I reflesh 99% of the
 > > time, but could forget sometimes, and some other times I need a
 > > "shift+reload" to bypass browser cache.
 > >
 > Well, I would argue you are doing something fundamentally wrong by
 > submitting anything without refreshing first. It is a form so technically
 > nothing is being done incorrectly in changing values based on what you
 > submit, whether you view them stale or not.

That's beside the point, Brett.  First, his intent is to refresh, so
he's doing his best - he merely admits he's human, and would like help
from the machine.  But the nub of his report is the fact that nothing
he *can* do seems to do the whole job of refreshing.

Nor is he complaining about the form processing at the HTML/HTTP
level.  The limits of the HTTP transport don't justify the defects of
the database backend, although they are likely to cause inconvenience
to users (ie, the easy patch is to block the whole update, rather than
update only the fields the user has explicitly changed).

I need to update XEmacs's tracker anyway, I'll investigate whether
upstream has a fix for this, and if not, see if I can come up with a
patch for this while I'm updating.  Technically it shouldn't be hard
to implement Jesus's suggestion, and at least reject potential
spurious updates (the tracker db has a timestamp on every change).

metatracker workers: no ETA on this, feel free to ping me for updates
or prod me to get to work.<wink>

From metatracker at psf.upfronthosting.co.za  Sun Jan  6 01:11:08 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Sun, 06 Jan 2013 00:11:08 +0000
Subject: [Tracker-discuss] [issue500] Posting changes from "old" tracker
	pages causes spurious	updates
In-Reply-To: <1357269507.95.0.118401099594.issue500@psf.upfronthosting.co.za>
Message-ID: <1357431068.8.0.438569592937.issue500@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> The problem with this is that even if I reload the tab, flags are 
> usually stale and when I add myself to the nosy list, I revert flags 
> to the old value.

Preserving form data on reload is a browser feature.
The solution is either to reload with CTRL+F5 or opening the page again (this can also be done with CTRL+L, Enter).  Both will update the form with the most recent data, discarding anything you might have changed/added.
The CTRL+L, Enter can also be used when Roundup displays a red bar about a conflict.  In that case CTRL+F5 might resend the POST data and cause the conflict again.  Opening the page on a new tab also works.

I don't think there's anything more Roundup should do.  (Maybe something can be done, but I'm not sure it's worth to fix this specific "problem".)

----------
nosy: +ezio.melotti
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue500>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan  6 01:13:47 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Sun, 06 Jan 2013 00:13:47 +0000
Subject: [Tracker-discuss] [issue499] Add separator to "Assigned To" list
In-Reply-To: <1357248843.5.0.857883743192.issue499@psf.upfronthosting.co.za>
Message-ID: <1357431227.32.0.0501708645967.issue499@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'm going to reject this.  I don't think it's necessary to divide the current username from the rest of the usernames.  The fact that it has been moved to the top should already be enough.

----------
nosy: +ezio.melotti
status: unread -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue499>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan  6 13:14:12 2013
From: metatracker at psf.upfronthosting.co.za (Antoine Pitrou)
Date: Sun, 06 Jan 2013 12:14:12 +0000
Subject: [Tracker-discuss] [issue501] mail gateway broken
Message-ID: <1357474452.13.0.621512044097.issue501@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I got the following error when trying to reply to an issue via e-mail:


This is the mail system at host psf.upfronthosting.co.za.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

Reporting-MTA: dns; psf.upfronthosting.co.za
X-Postfix-Queue-ID: 105911CDFE
X-Postfix-Sender: rfc822; pitrou at free.fr
Arrival-Date: Sun,  6 Jan 2013 13:10:48 +0100 (CET)

Final-Recipient: rfc822; roundup+tracker at psf.upfronthosting.co.za
Original-Recipient: rfc822;report at bugs.python.org
Action: failed
Status: 5.3.0
Diagnostic-Code: x-unix; Traceback (most recent call last):   File
    "/home/roundup/roundup/bin/roundup-mailgw", line 4, in <module>     import
    pkg_resources   File "/usr/lib/python2.6/dist-packages/pkg_resources.py",
    line 2671, in <module>     working_set.require(__requires__)   File
    "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 654, in require
    needed = self.resolve(parse_requirements(requirements))   File
    "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 552, in resolve
    raise DistributionNotFound(req) pkg_resources.DistributionNotFound:
    roundup==1.4.21

----------
messages: 2684
nosy: pitrou
priority: critical
status: unread
title: mail gateway broken

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue501>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Jan  9 05:01:59 2013
From: metatracker at psf.upfronthosting.co.za (py.user)
Date: Wed, 09 Jan 2013 04:01:59 +0000
Subject: [Tracker-discuss] [issue502] Can't find by the search of
	bugs.python.org topics with	some hour activity
Message-ID: <1357704119.71.0.916124593547.issue502@psf.upfronthosting.co.za>


New submission from py.user:

"1 hour ago" shows "32 months ago"
"1 hours ago" shows "32 months ago"
"-1 hour" shows "32 months ago"
"-01:00" shows "32 months ago"
"from -01:00" shows "32 months ago"

"from 01:00" shows "1/4 hour ago"
"from 05:00" shows "empty"
"from -05:00" shows "8 months ago"


I know that some activity was 3 hours ago, and I want to get all topics from 4 hours ago to 2 hours ago.
What shall I write to the search field ?

----------
messages: 2685
nosy: py.user
priority: wish
status: unread
title: Can't find by the search of bugs.python.org topics with some hour activity

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue502>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Jan  9 05:13:59 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Wed, 09 Jan 2013 04:13:59 +0000
Subject: [Tracker-discuss] [issue502] Can't find by the search of
	bugs.python.org topics with	some hour activity
In-Reply-To: <1357704119.71.0.916124593547.issue502@psf.upfronthosting.co.za>
Message-ID: <1357704839.09.0.48819835747.issue502@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Have you checked this http://roundup.sourceforge.net/docs/user_guide.html#date-properties ?
IIUC if you use from/to with times you have to use the absolute time (i.e. if now it's 10:00, and you want the issues from 4 hours ago to 2 hours ago you would have to specify from 06:00 to 08:00).

----------
nosy: +ezio.melotti
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue502>
_______________________________________________________

From roundup-admin at psf.upfronthosting.co.za  Sat Jan 12 16:45:11 2013
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Sat, 12 Jan 2013 15:45:11 +0000
Subject: [Tracker-discuss] Failed issue tracker submission
Message-ID: <20130112154511.874F21CAC5@psf.upfronthosting.co.za>



The node specified by the designator in the subject of your message
("16992") does not exist.

Subject was: "[issue16992]"



Mail Gateway Help
=================
Incoming messages are examined for multiple parts:
 . In a multipart/mixed message or part, each subpart is extracted and
   examined. The text/plain subparts are assembled to form the textual
   body of the message, to be stored in the file associated with a "msg"
   class node. Any parts of other types are each stored in separate files
   and given "file" class nodes that are linked to the "msg" node.
 . In a multipart/alternative message or part, we look for a text/plain
   subpart and ignore the other parts.
 . A message/rfc822 is treated similar tomultipart/mixed (except for
   special handling of the first text part) if unpack_rfc822 is set in
   the mailgw config section.

Summary
-------
The "summary" property on message nodes is taken from the first non-quoting
section in the message body. The message body is divided into sections by
blank lines. Sections where the second and all subsequent lines begin with
a ">" or "|" character are considered "quoting sections". The first line of
the first non-quoting section becomes the summary of the message.

Addresses
---------
All of the addresses in the To: and Cc: headers of the incoming message are
looked up among the user nodes, and the corresponding users are placed in
the "recipients" property on the new "msg" node. The address in the From:
header similarly determines the "author" property of the new "msg"
node. The default handling for addresses that don't have corresponding
users is to create new users with no passwords and a username equal to the
address. (The web interface does not permit logins for users with no
passwords.) If we prefer to reject mail from outside sources, we can simply
register an auditor on the "user" class that prevents the creation of user
nodes with no passwords.

Actions
-------
The subject line of the incoming message is examined to determine whether
the message is an attempt to create a new item or to discuss an existing
item. A designator enclosed in square brackets is sought as the first thing
on the subject line (after skipping any "Fwd:" or "Re:" prefixes).

If an item designator (class name and id number) is found there, the newly
created "msg" node is added to the "messages" property for that item, and
any new "file" nodes are added to the "files" property for the item.

If just an item class name is found there, we attempt to create a new item
of that class with its "messages" property initialized to contain the new
"msg" node and its "files" property initialized to contain any new "file"
nodes.

Triggers
--------
Both cases may trigger detectors (in the first case we are calling the
set() method to add the message to the item's spool; in the second case we
are calling the create() method to create a new node). If an auditor raises
an exception, the original message is bounced back to the sender with the
explanatory message given in the exception.
-------------- next part --------------
Return-Path: <tracker-discuss at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [IPv6:2001:888:2000:d::a6])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id 4666A1CAA7
	for <report at bugs.python.org>; Sat, 12 Jan 2013 16:45:11 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id 3Yk4yZ5xVWzR8Q
	for <report at bugs.python.org>; Sat, 12 Jan 2013 16:45:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1358005510; bh=SehEg72utNrz6fJzmmdyvLMhOgFNXvysU43q+Tc4oj0=;
	h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To:
	 Subject:Message-Id:Date;
	b=b7RffX5UEohHIeS9IQJ77e+K4WVwMHB3Lw1anfjzZE8TxrmDfgmr4kEbYNGclgGFk
	 CmXwNfotD1DGe3MzlEbT4tJMUYGryNtBhJ5+mQBJqTeEkgORGHETspi7IR0PwyPniC
	 3UpSUKiYCVJidfNgKA2DtsPuErujh0vDr9YcBbP0=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 12 Jan 2013 16:45:10 +0100
Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72])
	by mail.python.org (Postfix) with ESMTP
	for <report at bugs.python.org>; Sat, 12 Jan 2013 16:45:10 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: tracker-discuss at python.org
To: report at bugs.python.org
Subject: [issue16992]
Message-Id: <3Yk4yZ5xVWzR8Q at mail.python.org>
Date: Sat, 12 Jan 2013 16:45:10 +0100 (CET)

TmV3IGNoYW5nZXNldCBmOWQxZDEyMGMxOWUgYnkgRWxpIEJlbmRlcnNreSBpbiBicmFuY2ggJzMu
Myc6Cklzc3VlcyAjMTUwODMgYW5kICMxNjk5MjogcG9ydCBmaW5kLiogbWV0aG9kIHRlc3RzIHRv
IHVuaXR0ZXN0Cmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2Y5ZDFkMTIwYzE5ZQoK
Ck5ldyBjaGFuZ2VzZXQgMThiMTYxMDQxNjZjIGJ5IEVsaSBCZW5kZXJza3kgaW4gYnJhbmNoICdk
ZWZhdWx0JzoKSXNzdWVzICMxNTA4MyBhbmQgIzE2OTkyOiBwb3J0IGZpbmQuKiBtZXRob2QgdGVz
dHMgdG8gdW5pdHRlc3QKaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvMThiMTYxMDQx
NjZjCg==

From roundup-admin at psf.upfronthosting.co.za  Mon Jan 14 02:24:48 2013
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Mon, 14 Jan 2013 01:24:48 +0000
Subject: [Tracker-discuss] Failed issue tracker submission
Message-ID: <20130114012448.237781CE85@psf.upfronthosting.co.za>


An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
-------------- next part --------------
Return-Path: <tracker-discuss at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id E13021CEF8
	for <report at bugs.python.org>; Mon, 14 Jan 2013 02:24:33 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id 3Ykxmd4Pq8zSK5
	for <report at bugs.python.org>; Mon, 14 Jan 2013 02:24:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1358126673; bh=zzR/ZiAmkpDFg4Ur/DLPfb6x7cFX8ie4Dxsj/2BSIxo=;
	h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To:
	 Subject:Message-Id:Date;
	b=vmVlBNCQovPdKsB3S7LDhzOs+qoMbTYONphXpHPRZ214FTskgHWbl7l+2SjgXJmp5
	 BAv0OijmEXFb1PRi+7y1crK6wEgL/tqfzaOTnsUvH+u+OmMHBjF0CCY5AenL5/VsMs
	 +RkEX6tmiTpgrgW0paXBBruk0GQ1kf8Qzaix+WWA=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 14 Jan 2013 02:24:33 +0100
Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72])
	by mail.python.org (Postfix) with ESMTP
	for <report at bugs.python.org>; Mon, 14 Jan 2013 02:24:33 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: tracker-discuss at python.org
To: report at bugs.python.org
Subject: [issue10527]
Message-Id: <3Ykxmd4Pq8zSK5 at mail.python.org>
Date: Mon, 14 Jan 2013 02:24:33 +0100 (CET)

TmV3IGNoYW5nZXNldCA4OGZhZGMwZDdiMjAgYnkgR2lhbXBhb2xvIFJvZG9sYScgaW4gYnJhbmNo
ICczLjMnOgpmaXggZm9yIHByZXZpb3VzIGNvbW1pdCByZWxhdGVkIHRvIGlzc3VlIDEwNTI3IHdo
aWNoIGRpZG4ndCBoYXZlIHRoZSBpbnRlbmRlZCBlZmZlY3QgYXMgcGVyIGh0dHA6Ly9idWdzLnB5
dGhvbi5vcmcvaXNzdWUxMDUyNyNtc2cxNzk4OTUKaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhv
bi9yZXYvODhmYWRjMGQ3YjIwCg==

From metatracker at psf.upfronthosting.co.za  Thu Jan 17 22:38:12 2013
From: metatracker at psf.upfronthosting.co.za (Antoine Pitrou)
Date: Thu, 17 Jan 2013 21:38:12 +0000
Subject: [Tracker-discuss] [issue503] OpenID provider discovery failed
Message-ID: <1358458692.41.0.731551385801.issue503@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

When trying to associate the following OpenID URL with my account
https://ssl.pitrou.net/openid/antoine
I get the error "OpenID provider discovery failed".

----------
messages: 2687
nosy: ezio.melotti, loewis, pitrou
priority: bug
status: unread
title: OpenID provider discovery failed

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue503>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Jan 19 07:57:35 2013
From: metatracker at psf.upfronthosting.co.za (Izak Burger)
Date: Sat, 19 Jan 2013 06:57:35 +0000
Subject: [Tracker-discuss] [issue504] Server error
Message-ID: <CAGscxN3+=MBwz3Dsz6Wyg2LMDwn4x0EgZ5tSwnKbgadyLFFUSQ@mail.gmail.com>


New submission from Izak Burger:

Hi all,

I got an notification during the night that something is amiss on the
psf virtual server hosting bugs.python.org. I've checked the
filesystem, repaired it, and restarted the virtual server. The ground
reason appears to be that we lost a disk in the RAID1. This means
we'll need to replace it on Monday. I'll let you know as soon as that
has been scheduled.

regards,
Izak

----------
messages: 2688
nosy: izak
status: unread
title: Server error

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Jan 19 09:09:11 2013
From: metatracker at psf.upfronthosting.co.za (Izak Burger)
Date: Sat, 19 Jan 2013 08:09:11 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <CAGscxN3+=MBwz3Dsz6Wyg2LMDwn4x0EgZ5tSwnKbgadyLFFUSQ@mail.gmail.com>
Message-ID: <CAGscxN3S2_-4x9p+SH4eP2++Z3-QtBKWPyZNKX0wVFN8-zmfbA@mail.gmail.com>


Izak Burger added the comment:

It turns out the issue is a bit more complex than that. /dev/sda has
been removed from the array. Normally just re-adding it causes the bad
block to be swapped out, but /dev/sdb has sectors itself that might be
suspect, so it cannot rebuild. It appears all these are in the area
where the logical volumes live, so the plan is to copy everything to a
new logical volume, thereby effectively writing fresh copies to a new
area of the disk. I will then overwrite the old area with zeroes,
effectively forcing the hardware to swap the sector, hopefully
allowing us to reover the raid array. At the very least, we'll have a
copy of everything if it doesn't work.

On Sat, Jan 19, 2013 at 8:57 AM, Izak Burger
<metatracker at psf.upfronthosting.co.za> wrote:
>
> New submission from Izak Burger:
>
> Hi all,
>
> I got an notification during the night that something is amiss on the
> psf virtual server hosting bugs.python.org. I've checked the
> filesystem, repaired it, and restarted the virtual server. The ground
> reason appears to be that we lost a disk in the RAID1. This means
> we'll need to replace it on Monday. I'll let you know as soon as that
> has been scheduled.
>
> regards,
> Izak
>
> ----------
> messages: 2688
> nosy: izak
> status: unread
> title: Server error
>
> _______________________________________________________
> PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue504>
> _______________________________________________________

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan 20 01:14:37 2013
From: metatracker at psf.upfronthosting.co.za (Antoine Pitrou)
Date: Sun, 20 Jan 2013 00:14:37 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <CAGscxN3+=MBwz3Dsz6Wyg2LMDwn4x0EgZ5tSwnKbgadyLFFUSQ@mail.gmail.com>
Message-ID: <1358640877.73.0.278354832933.issue504@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The requests are very slow on bugs.p.o currently, and Ezio Melotti points out that the 8 CPUs are at 50% in the "waiting" state.

----------
nosy: +pitrou
priority:  -> urgent

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan 20 01:15:05 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Sun, 20 Jan 2013 00:15:05 +0000
Subject: [Tracker-discuss] [issue501] mail gateway broken
In-Reply-To: <1357474452.13.0.621512044097.issue501@psf.upfronthosting.co.za>
Message-ID: <1358640905.29.0.604769435271.issue501@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

FTR this was caused by a failed attempted to updated Roundup.

----------
nosy: +ezio.melotti
status: unread -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue501>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan 20 02:13:34 2013
From: metatracker at psf.upfronthosting.co.za (Antoine Pitrou)
Date: Sun, 20 Jan 2013 01:13:34 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <CAGscxN3+=MBwz3Dsz6Wyg2LMDwn4x0EgZ5tSwnKbgadyLFFUSQ@mail.gmail.com>
Message-ID: <1358644414.44.0.985993074917.issue504@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hi Izak,

There are lots of problems with the tracker tonight, requests sometimes fail or take a lot of time. Ezio Melotti, who has shell access to the machine, says the CPUs are sometimes all waiting for I/O. Also, a bug I posted got an id but apparently was never committed to disk, which hints to an underlying I/O error.

I hope you can look into this quickly.

----------
nosy: +ezio.melotti, pitrou
priority:  -> critical

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan 20 02:30:05 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Sun, 20 Jan 2013 01:30:05 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <CAGscxN3+=MBwz3Dsz6Wyg2LMDwn4x0EgZ5tSwnKbgadyLFFUSQ@mail.gmail.com>
Message-ID: <1358645405.87.0.195925104556.issue504@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Also, a bug I posted got an id but apparently was never committed to disk,
> which hints to an underlying I/O error.

I've seen this happening other times in the past, and I don't think it necessarily imply that it couldn't commit it to disk -- it might have been caused by something else (e.g. a timeout), even though the original cause is likely the disk problem.
I noticed that Roundup stopped running a couple of times.  I'm not sure if someone stopped it intentionally or if it crashed.
I also saw a few "mailhost timed out" errors, but no other unusual errors.

----------
nosy: +r.david.murray

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan 20 08:35:13 2013
From: metatracker at psf.upfronthosting.co.za (Izak Burger)
Date: Sun, 20 Jan 2013 07:35:13 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <1358645405.87.0.195925104556.issue504@psf.upfronthosting.co.za>
Message-ID: <CAGscxN0VsPZQ618B+YbSks3GZ+J-tX2yk5kpcCQMk4XeproEiQ@mail.gmail.com>


Izak Burger added the comment:

I worked on it quite a bit yesterday. I pushed the load average to 36
at times, which was almost entirely because of disk issues (Linux
deems processes in the disk queue as runnable, so a high load average
often points to a long disk queue). It should be better since about 7
hours ago. I'm still writing zeroes to the rest of the open space, in
an attempt to force the disk to swap the sectors (which it can usually
only do on a write). The raid array rebuilt to 95% last night before
it failed, so we're getting close to getting redundancy back. I highly
suspect a disk swap might still be necessary, but at the moment it
seems the disk that is not in the array is the better one, so I want
the array back in sync first.

At the moment I'm not having joy with smartmontools. The initial stats
showed some 28 bad sectors that were pending a swap, which isn't too
bad, but a full offline scan (which despite it's name can be done
while the disk is online) will take a full day.

The files we lost were almost all log files, even in the other virtual
hosts on that machine. One of postgresql's WAL logs also failed but I
could recover it from a previous copy. By simply doing a few
successive rsyncs I got all the data back.

regards,
Izak

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From izak at upfrontsystems.co.za  Sun Jan 20 08:35:08 2013
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sun, 20 Jan 2013 09:35:08 +0200
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <1358645405.87.0.195925104556.issue504@psf.upfronthosting.co.za>
References: <CAGscxN3+=MBwz3Dsz6Wyg2LMDwn4x0EgZ5tSwnKbgadyLFFUSQ@mail.gmail.com>
	<1358645405.87.0.195925104556.issue504@psf.upfronthosting.co.za>
Message-ID: <CAGscxN0VsPZQ618B+YbSks3GZ+J-tX2yk5kpcCQMk4XeproEiQ@mail.gmail.com>

I worked on it quite a bit yesterday. I pushed the load average to 36
at times, which was almost entirely because of disk issues (Linux
deems processes in the disk queue as runnable, so a high load average
often points to a long disk queue). It should be better since about 7
hours ago. I'm still writing zeroes to the rest of the open space, in
an attempt to force the disk to swap the sectors (which it can usually
only do on a write). The raid array rebuilt to 95% last night before
it failed, so we're getting close to getting redundancy back. I highly
suspect a disk swap might still be necessary, but at the moment it
seems the disk that is not in the array is the better one, so I want
the array back in sync first.

At the moment I'm not having joy with smartmontools. The initial stats
showed some 28 bad sectors that were pending a swap, which isn't too
bad, but a full offline scan (which despite it's name can be done
while the disk is online) will take a full day.

The files we lost were almost all log files, even in the other virtual
hosts on that machine. One of postgresql's WAL logs also failed but I
could recover it from a previous copy. By simply doing a few
successive rsyncs I got all the data back.

regards,
Izak

From izak at upfrontsystems.co.za  Sun Jan 20 09:03:12 2013
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sun, 20 Jan 2013 10:03:12 +0200
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <CAGscxN0VsPZQ618B+YbSks3GZ+J-tX2yk5kpcCQMk4XeproEiQ@mail.gmail.com>
References: <CAGscxN3+=MBwz3Dsz6Wyg2LMDwn4x0EgZ5tSwnKbgadyLFFUSQ@mail.gmail.com>
	<1358645405.87.0.195925104556.issue504@psf.upfronthosting.co.za>
	<CAGscxN0VsPZQ618B+YbSks3GZ+J-tX2yk5kpcCQMk4XeproEiQ@mail.gmail.com>
Message-ID: <CAGscxN1vfbqLMv9xE6p5nT_XNiVAcYbA58iLx6riiDQ4bpyHBQ@mail.gmail.com>

On Sun, Jan 20, 2013 at 9:35 AM, Izak Burger <izak at upfrontsystems.co.za> wrote:
> The files we lost were almost all log files, even in the other virtual
> hosts on that machine. One of postgresql's WAL logs also failed but I
> could recover it from a previous copy. By simply doing a few
> successive rsyncs I got all the data back.

And another thing :-) I saw the virtual host was running low on space
and doubled the disk space.

From metatracker at psf.upfronthosting.co.za  Sun Jan 20 09:03:14 2013
From: metatracker at psf.upfronthosting.co.za (Izak Burger)
Date: Sun, 20 Jan 2013 08:03:14 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <CAGscxN0VsPZQ618B+YbSks3GZ+J-tX2yk5kpcCQMk4XeproEiQ@mail.gmail.com>
Message-ID: <CAGscxN1vfbqLMv9xE6p5nT_XNiVAcYbA58iLx6riiDQ4bpyHBQ@mail.gmail.com>


Izak Burger added the comment:

On Sun, Jan 20, 2013 at 9:35 AM, Izak Burger <izak at upfrontsystems.co.za> wrote:
> The files we lost were almost all log files, even in the other virtual
> hosts on that machine. One of postgresql's WAL logs also failed but I
> could recover it from a previous copy. By simply doing a few
> successive rsyncs I got all the data back.

And another thing :-) I saw the virtual host was running low on space
and doubled the disk space.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan 20 13:09:44 2013
From: metatracker at psf.upfronthosting.co.za (Antoine Pitrou)
Date: Sun, 20 Jan 2013 12:09:44 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <CAGscxN0VsPZQ618B+YbSks3GZ+J-tX2yk5kpcCQMk4XeproEiQ@mail.gmail.com>
Message-ID: <1358683616.3429.1.camel@localhost.localdomain>


Antoine Pitrou added the comment:

Le dimanche 20 janvier 2013 ? 07:35 +0000, Izak Burger a ?crit :
> At the moment I'm not having joy with smartmontools. The initial stats
> showed some 28 bad sectors that were pending a swap, which isn't too
> bad, but a full offline scan (which despite it's name can be done
> while the disk is online) will take a full day.
> 
> The files we lost were almost all log files, even in the other virtual
> hosts on that machine. One of postgresql's WAL logs also failed but I
> could recover it from a previous copy. By simply doing a few
> successive rsyncs I got all the data back.

Thank you very much :-)

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan 20 22:37:22 2013
From: metatracker at psf.upfronthosting.co.za (Izak Burger)
Date: Sun, 20 Jan 2013 21:37:22 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <1358683616.3429.1.camel@localhost.localdomain>
Message-ID: <CAGscxN0N1EBbVgBCGe6UFFSWPenC=XcSrezmdCo62xfSj5d9-w@mail.gmail.com>


Izak Burger added the comment:

The situation has been resolved. The RAID array is back in sync and
all seems well again. No more klingon messages in syslog :-)

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Jan 21 00:05:03 2013
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Sun, 20 Jan 2013 23:05:03 +0000
Subject: [Tracker-discuss] [issue504] Server error
In-Reply-To: <CAGscxN3+=MBwz3Dsz6Wyg2LMDwn4x0EgZ5tSwnKbgadyLFFUSQ@mail.gmail.com>
Message-ID: <1358723103.71.0.346053563116.issue504@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks!

----------
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue504>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Jan 23 11:28:48 2013
From: metatracker at psf.upfronthosting.co.za (Izak Burger)
Date: Wed, 23 Jan 2013 10:28:48 +0000
Subject: [Tracker-discuss] [issue505] Abuse Message
Message-ID: <CAGscxN3xwoJ-qhgumYe9DQjxMgP60V71ZTr0Xxafe2cngMJsFg@mail.gmail.com>


New submission from Izak Burger:

Hi all,

I received this abuse report from Hetzner. Basically someone used a
file attached on an issue to bounce people to a spam site for
buying... medication.

I've cleared out the contents of the file so that this will no longer
happen. The original file is in the roundup user's home directory,
file 291, in case anyone wants to see what was done, but it appears to
be a javascript attack. It seems that by adding "doc7.html" to the url
it has somehow tricked the tracker into serving the content with a
content type of html, which causes the browser to execute the
javascript, instead of displaying plain text as it should.

----- attachment -----

Return-path: <spamlinks at spamlinks.blocklist.de>
Envelope-to: abuse at hetzner.de
Delivery-date: Fri, 18 Jan 2013 18:11:51 +0100
Received: from [46.252.24.141] (helo=j15757.servers.jiffybox.net)
        by lms.your-server.de with esmtp (Exim 4.74)
        (envelope-from <spamlinks at spamlinks.blocklist.de>)
        id 1TwFTr-0005pn-0y
        for abuse at hetzner.de; Fri, 18 Jan 2013 18:11:51 +0100
Received: by j15757.servers.jiffybox.net (Postfix, from userid 0)
        id B43322375; Fri, 18 Jan 2013 18:24:01 +0100 (CET)
To: abuse at hetzner.de
Subject: [NOREPLY][Blocklist-9095] Spam-Link at your service
X-PHP-Originating-Script: 0:reporting.php
From: Abuse-Team Blocklist.de <spamlinks at spamlinks.blocklist.de>
Reply-To: spamlinks at spamlinks.blocklist.de
X-Mailer: antiabusemailer
X-Arf: yes
X-Report-ID: 9095
MIME-Version: 1.0
Content-type: multipart/mixed;
boundary="81fd830c85363675edb98d2879916d8c"; charset=iso-8859-1
Message-Id: <20130118172401.B43322375 at j15757.servers.jiffybox.net>
Date: Fri, 18 Jan 2013 18:24:01 +0100 (CET)
X-Virus-Scanned: Clear (ClamAV 0.97.5/16520/Fri Jan 18 16:15:26 2013)
X-Spam-Score: 1.3 (+)
Delivered-To: he1-abuse at hetzner.de

--81fd830c85363675edb98d2879916d8c
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=utf-8

Hello Abuse-Team,

your server with the IP: 46.4.197.70 is currently hosting a possible scam-site.
This site has reached an Blocklist-Spamscore of 3600. The concerning
site is following site:
http://psf.upfronthosting.co.za/roundup/meta/file291/doc7.html

Please check this site and do a cleanup if necessary. To resolve this
case, please visit
http://spamlinks.blocklist.de/resolve.php?case=190640713c8ae5259fc9ef68229059b026eda118bd5a083b0d27d1a4

You also can parse this mail with X-ARF tools that can be found at
http://www.x-arf.org/specification.html .

We found your address in the abusix abuse contact database at
http://abusix.com/global-reporting/abuse-contact-db . If this contact
is wrong, please inform info at abusix.com about this.

Please do NOT reply at this email, use the contact form instead.

Regards,
Abuse-Team blocklist.de
http://www.blocklist.de/en/

--81fd830c85363675edb98d2879916d8c
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=utf-8; name="report.txt";

---
Reported-From: spamlinks at spamlinks.blocklist.de
Category: fraud
Report-Type: scam
Service: http
Version: 0.1
User-Agent: V.A.L.O.R. 1.0
Date: Fri, 18 Jan 2013 18:24:01 +0100
Source-Type: uri
Source: http://psf.upfronthosting.co.za/roundup/meta/file291/doc7.html
Domain: psf.upfronthosting.co.za
Port: 80
Report-ID: 9095 at spamlinks.blocklist.de
Schema-URL: http://www.x-arf.org/schema/fraud_0.1.3.json
Attachment: none

--81fd830c85363675edb98d2879916d8c

----------
messages: 2699
nosy: izak
status: unread
title: Abuse Message

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue505>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Jan 23 12:32:53 2013
From: metatracker at psf.upfronthosting.co.za (Izak Burger)
Date: Wed, 23 Jan 2013 11:32:53 +0000
Subject: [Tracker-discuss] [issue505] Abuse Message
In-Reply-To: <CAGscxN3xwoJ-qhgumYe9DQjxMgP60V71ZTr0Xxafe2cngMJsFg@mail.gmail.com>
Message-ID: <CAGscxN0Aaz8tCNET_zipjzv7+bmXnkvm2p5dNWSS3DmxTOi=zw@mail.gmail.com>


Izak Burger added the comment:

Hi again,

I noted that the detector that is deployed on the main tracker, for
ensuring that text/html content types are not allowed, was not on the
meta tracker. I've copied it there.

I don't think this is enough though. Consider for a second this
command, just to illustrate:

(wget -q -S -O-
http://psf.upfronthosting.co.za/roundup/meta/file291/doc7.html 3>&1
1>&2- 2>&3- ) 2> /dev/null | grep Content-Type

It looks terrible but I just swapped stdout and stderr so I can grep
through the headers.

It appears that once roundup finds the document it is looking for, the
rest of the traversal string is ignored, except that it causes the
Content-Type header to be set to "html". This is not a valid content
type, and will cause some versions of IE to default to html, and some
other browsers to look at the extension (html), so this will be
rendered as html in almost all browsers.

The fix might be as simple as using "text/plain" instead of "html",
wherever this default happens to be.

regards,
Izak

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue505>
_______________________________________________________

From stephen at xemacs.org  Wed Jan 23 13:37:32 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Jan 2013 21:37:32 +0900
Subject: [Tracker-discuss]  Abuse Message
In-Reply-To: <CAGscxN3xwoJ-qhgumYe9DQjxMgP60V71ZTr0Xxafe2cngMJsFg@mail.gmail.com>
References: <CAGscxN3xwoJ-qhgumYe9DQjxMgP60V71ZTr0Xxafe2cngMJsFg@mail.gmail.com>
Message-ID: <87libk3wj7.fsf@uwakimon.sk.tsukuba.ac.jp>

Izak Burger writes:

 > I've cleared out the contents of the file so that this will no longer
 > happen. The original file is in the roundup user's home directory,
 > file 291, in case anyone wants to see what was done, but it appears to
 > be a javascript attack.

I mostly just lurk on this list and don't have shell access to the
Python tracker.  However I do run a roundup tracker, and am a little
concerned about this.  Does it seem to be roundup-specific?  Could you
mail me a copy of the exploit file?

Steve