From facundobatista at gmail.com  Sat Sep  1 18:26:57 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 1 Sep 2007 13:26:57 -0300
Subject: [Tracker-discuss] Bulk info
Message-ID: <e04bdf310709010926te40dfe1u9e4488d1298a6a0b@mail.gmail.com>

Hola a todos! (Hi everybody!)

I'm trying to get bulk information of the roundup tracker we're now
using. My idea is to keep this resumes updated:

    http://www.taniquetil.com.ar/facundo/py_patchs_00.html
    http://www.taniquetil.com.ar/facundo/py_bugs_00.html

Of course, these two will be merged in one report, and I want to add a
column there ("Keyword").

I didn't find any link to download something like a "resume" of the
tracker, but I can grab almost all the info I need with this URL:

  http://bugs.python.org/issue?
        @columns=id,title,creation,creator,activity,actor&
        @filter=status&status=1,3&
        @pagesize=2000

I have two problems with this, though.

One is very small: I won't have the quantity of comments of movements
a issue had, but I think that's not so important information in the
page I generated.

The big problem is that the dates of creation and last modification
are not accurate. "3 months ago" is fuzzy.

Do you know how can I get this information?

Are there plans to publish a nightly updated packed resume of the tracker?

Thank you!!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From metatracker at psf.upfronthosting.co.za  Sun Sep  2 21:19:28 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 02 Sep 2007 19:19:28 -0000
Subject: [Tracker-discuss] [issue146] File upload form should allow editing
	description
Message-ID: <1188760768.47.0.124668807895.issue146@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

The description field for a file from SF was recently added, but the pages were
not updated to allow entering the description on upload (it *is* possible to
edit it afterwards).

I suggest to add a new Description: text box in a line below the File: box.

----------
messages: 748
nosy: loewis
priority: feature
status: unread
title: File upload form should allow editing description

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

From metatracker at psf.upfronthosting.co.za  Mon Sep  3 17:19:59 2007
From: metatracker at psf.upfronthosting.co.za (Dennis Allison)
Date: Mon, 03 Sep 2007 15:19:59 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
Message-ID: <1188832799.31.0.267708229765.issue147@psf.upfronthosting.co.za>


New submission from Dennis Allison:

The "From:" header for issue tracking report email contains multiple lines. 
Some mail readers (e.g., Pine) expect single line mail headers.  (I believe
single line headers are required by the RFC's.)  Multi-line entries corrupt the
mail summary display, etc.  .

----------
messages: 749
nosy: allison
priority: bug
status: unread
title: Current email headers corrupt mail reader display

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

From metatracker at psf.upfronthosting.co.za  Tue Sep  4 04:36:00 2007
From: metatracker at psf.upfronthosting.co.za (Huang Peng)
Date: Tue, 04 Sep 2007 02:36:00 -0000
Subject: [Tracker-discuss] [issue148] 'Make a Copy' failed
Message-ID: <1188873360.02.0.256456370115.issue148@psf.upfronthosting.co.za>


New submission from Huang Peng:

I want to 'make a copy' an issue (http://bugs.python.org/issue708374), but it
was failed. The error page is listed below.
=================================================================
Templating Error

psycopg.ProgrammingError: ERROR: current transaction is aborted, commands
ignored until end of transaction block select id from _user where
_username='akuchling' and __retired__ <> 1

Debugging information follows

   1. Looking for "nosy", current path:
   2. In path expression "nosy/field"
   3. While evaluating the standard:'context/nosy/field' expression on line 145
      Current variables:
      templates	<roundup.cgi.templating.Templates instance at 0x2b8f33f2efc8>
      repeat	<roundup.cgi.PageTemplates.TALES.SafeMapping instance at
0x2b8f3500f1b8>
      false	0
      context	<HTMLClass(0x2b8f3500f128) issue>
      utils	<roundup.cgi.templating.TemplatingUtils instance at 0x2b8f3500f0e0>
      db	<roundup.cgi.templating.HTMLDatabase instance at 0x2b8f3500f098>
      nothing	None
      i18n	<roundup.cgi.TranslationService.TranslationService instance at
0x2b8f35037c20>
      true	1
      default	<roundup.cgi.PageTemplates.TALES.Default instance at 0x2b8f33dbcb90>
      request	<HTMLRequest {'_context': None, 'startwith': 0, 'show':
<roundup.support.TruthDict instance at 0x2b8f3500cea8>, 'classname': 'issue',
'special_char': '@', 'dispname': None, 'group': [], '_client':
<roundup.cgi.client.Client instance at 0x2b8f35037b48>, 'template': 'item',
'input': <function input_xhtml at 0x2b8f33dc3758>, 'columns': [], 'sort': [],
'env': {'HTTP_AUTHORIZATION': None, 'SERVER_PORT': '8080', 'SERVER_NAME':
'localhost', 'HTTP_COOKIE':
'roundup_session_Tracker=MTE4ODQ0MTYyMS4zMTAuOTIzODA1MzYwMzA2',
'HTTP_ACCEPT_LANGUAGE': 'en-us,en;q=0.5', 'SCRIPT_NAME': '', 'REQUEST_METHOD':
'GET', 'HTTP_HOST': 'localhost:8080', 'PATH_INFO': 'issue', 'CONTENT_TYPE':
'text/plain', 'QUERY_STRING':
'status=open&severity=normal&title=add%20offset%20to%20mmap&superseder=&versions=Python%202.6&resolution=&priority=normal&@note=Copy%20of%20issue%20708374&dependencies=&assignee=akuchling&nosy=akuchling%2C%20josiahcarlson%2C%20loewis%2C%20nnorwitz%2C%20phuang%2C%20rhettinger%2C%20yotam&components=Extension%20Modules&@template=item&keywords=patch&type=',
'TRACKER_NAME': 'tracker'}, 'form': FieldStorage(None, None,
[MiniFieldStorage('status', 'open'), MiniFieldStorage('severity', 'normal'),
MiniFieldStorage('title', 'add offset to mmap'), MiniFieldStorage('versions',
'Python 2.6'), MiniFieldStorage('priority', 'normal'), MiniFieldStorage('@note',
'Copy of issue 708374'), MiniFieldStorage('assignee', 'akuchling'),
MiniFieldStorage('nosy', 'akuchling, josiahcarlson, loewis, nnorwitz, phuang,
rhettinger, yotam'), MiniFieldStorage('components', 'Extension Modules'),
MiniFieldStorage('@template', 'item'), MiniFieldStorage('keywords', 'patch')]),
'nodeid': None, 'base': 'http://bugs.python.org/', 'user':
<HTMLItem(0x2b8f3500cfc8) user 3982>, 'search_text': None, 'pagesize': 50,
'filterspec': {}, 'filter': [], 'client': <roundup.cgi.client.Client instance at
0x2b8f35037b48>}>
      tracker	<roundup.instance.Tracker instance at 0x2b8f33f25cf8>
      template	<Roundup PageTemplate 'issue.item.html'>
      config	<roundup.configuration.CoreConfig instance at 0x2b8f33f25d40>
      options	{'ok_message': [], 'error_message': []}
      loop	<roundup.cgi.PageTemplates.TALES.SafeMapping instance at 0x2b8f3500f1b8>
      status_notresolved	'-1,1,3'
      columns_showall	'id,activity,title,creator,assignee,status'
      kw_create	0
      attrs	{'tal:replace': 'structure context/nosy/field'}
      columns	'id,activity,title,creator,status'
   4. A problem occurred in your template "issue.item.html".

Full traceback:

Traceback (most recent call last):
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/client.py",
line 770, in renderContext
    result = pt.render(self, None, None, **args)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/templating.py",
line 323, in render
    getEngine().getContext(c), output, tal=1, strictinsert=0)()
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 192, in __call__
    self.interpret(self.program)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 666, in do_useMacro
    self.interpret(macro)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 411, in do_optTag_tal
    self.do_optTag(stuff)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 396, in do_optTag
    return self.no_tag(start, program)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 391, in no_tag
    self.interpret(program)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 689, in do_defineSlot
    self.interpret(slot)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 632, in do_condition
    self.interpret(block)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 564, in do_insertStructure_tal
    structure = self.engine.evaluateStructure(expr)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/TALES.py",
line 227, in evaluate
    return expression(self)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 194, in __call__
    return self._eval(econtext)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 182, in _eval
    ob = self._subexprs[-1](econtext)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 138, in _eval
    ob = restrictedTraverse(ob, path, getSecurityManager())
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 317, in restrictedTraverse
    o = guarded_getattr(object, name, M)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/templating.py",
line 548, in __getattr__
    return self[attr]
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/templating.py",
line 524, in __getitem__
    handleListCGIValue(form[item]), fail_ok=1)
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/templating.py",
line 373, in lookupIds
    l.append(cl.lookup(entry))
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/backends/rdbms_common.py",
line 1876, in lookup
    self.db.sql(sql, (keyvalue, 1))
  File
"/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/backends/rdbms_common.py",
line 154, in sql
    self.cursor.execute(sql, args)
ProgrammingError: ERROR:  current transaction is aborted, commands ignored until
end of transaction block

select id from _user where _username='akuchling' and __retired__ <> 1

----------
messages: 750
nosy: phuang
priority: bug
status: unread
title: 'Make a Copy' failed

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

From metatracker at psf.upfronthosting.co.za  Tue Sep  4 08:33:24 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Tue, 04 Sep 2007 06:33:24 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <1188832799.31.0.267708229765.issue147@psf.upfronthosting.co.za>
Message-ID: <20070904083319.75ac3a2b@impertigo.lkpg.cendio.se>


Erik Forsberg added the comment:

On Mon, 03 Sep 2007 15:19:59 -0000
Dennis Allison <metatracker at psf.upfronthosting.co.za> wrote:

> 
> New submission from Dennis Allison:
> 
> The "From:" header for issue tracking report email contains multiple
> lines. Some mail readers (e.g., Pine) expect single line mail
> headers.  (I believe single line headers are required by the RFC's.)

RFC2822 allows "Folded" header lines, see sections "2.2. Header Fields"
and "2.2.3. Long Header Fields". Are you sure roundup break these
rules?

Regards,
\EF
-- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9

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

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

From metatracker at psf.upfronthosting.co.za  Tue Sep  4 16:09:02 2007
From: metatracker at psf.upfronthosting.co.za (Dennis Allison)
Date: Tue, 04 Sep 2007 14:09:02 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <20070904083319.75ac3a2b@impertigo.lkpg.cendio.se>
Message-ID: <Pine.LNX.4.44.0709040646470.29151-100000@shasta.stanford.edu>


Dennis Allison added the comment:

I use pine which is an ascii mail reader with a long history (that is, it 
is old).   The index display gets corrupted.

I believe that roundup does break the rules.  I suspect that the problem 
lies with the use of quotes which interferes with processing of folded 
lines.  

On Tue, 4 Sep 2007, Erik Forsberg wrote:

> 
> Erik Forsberg added the comment:
> 
> On Mon, 03 Sep 2007 15:19:59 -0000
> Dennis Allison <metatracker at psf.upfronthosting.co.za> wrote:
> 
> > 
> > New submission from Dennis Allison:
> > 
> > The "From:" header for issue tracking report email contains multiple
> > lines. Some mail readers (e.g., Pine) expect single line mail
> > headers.  (I believe single line headers are required by the RFC's.)
> 
> RFC2822 allows "Folded" header lines, see sections "2.2. Header Fields"
> and "2.2.3. Long Header Fields". Are you sure roundup break these
> rules?
> 
> Regards,
> \EF
> 

--

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

From metatracker at psf.upfronthosting.co.za  Tue Sep  4 22:18:59 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Tue, 04 Sep 2007 20:18:59 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <Pine.LNX.4.44.0709040646470.29151-100000@shasta.stanford.edu>
	(Dennis Allison's message of "Tue, 04 Sep 2007 14:09:02 -0000")
Message-ID: <87k5r6rxp1.fsf@uterus.efod.se>


Erik Forsberg added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dennis Allison <metatracker at psf.upfronthosting.co.za> writes:

> I use pine which is an ascii mail reader with a long history (that is, it 
> is old).   The index display gets corrupted.

Oh, I know about it, even though I was born as late as in the late
seventies.. ;-)

> I believe that roundup does break the rules.  I suspect that the problem 
> lies with the use of quotes which interferes with processing of folded 
> lines.  

Could you please attach such a message to this issue for inspection? I
tried finding messages with a long From line in the python-bugs-list
archives, but failed.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFG3b2qrJurFAusidkRArIHAJ9ry9+kvR8o6jY1L5BBbWc9wXU0EgCfWjDB
FJ5GDHSHeyre1ALutaWHIGE=
=LmON
-----END PGP SIGNATURE-----

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

From metatracker at psf.upfronthosting.co.za  Wed Sep  5 14:13:59 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 05 Sep 2007 12:13:59 -0000
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
Message-ID: <1188994439.71.0.74190997041.issue149@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

It appears that Bug #1523853 was not converted. Its original URL was


https://sourceforge.net/tracker/?func=detail&aid=1523853&group_id=5470&atid=105470

and http://bugs.python.org/issue1523853 does not exist.

I think it is important to determine what happened to that item, and how many
other items potentially got lost in the conversion.

----------
messages: 754
nosy: loewis
priority: critical
status: unread
title: 1523853 was not converted

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

From metatracker at psf.upfronthosting.co.za  Wed Sep  5 14:51:04 2007
From: metatracker at psf.upfronthosting.co.za (Georg Brandl)
Date: Wed, 05 Sep 2007 12:51:04 -0000
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
In-Reply-To: <1188994439.71.0.74190997041.issue149@psf.upfronthosting.co.za>
Message-ID: <46DEA636.8000501@python.org>


Georg Brandl added the comment:

Martin v. L?wis schrieb:
> New submission from Martin v. L?wis:
> 
> It appears that Bug #1523853 was not converted. Its original URL was
> 
> 
> https://sourceforge.net/tracker/?func=detail&aid=1523853&group_id=5470&atid=105470
> 
> and http://bugs.python.org/issue1523853 does not exist.

I just counted issues. The new tracker has 12591 issues, of which 109 are
from after the switch (the highest low ID is 1108), so there are 12482
issues converted.

After fiddling with SF (the only way to get total issue counts seems to
be the tracker summary page, which only lists tracker that aren't hidden,
so I had to unhide them for a short while), it seems that the total issue
count in all three trackers was 12785 (bugs 7878, patches 4278, rfe 559).

So either SF's count is wrong, I did something stupid or we have lost
303 issues.

Georg

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

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

From metatracker at psf.upfronthosting.co.za  Wed Sep  5 20:19:53 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Wed, 05 Sep 2007 18:19:53 -0000
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
In-Reply-To: <1188994439.71.0.74190997041.issue149@psf.upfronthosting.co.za> (Martin v. Löwis's message of "Wed, 05 Sep 2007 12:13:59 -0000")
Message-ID: <874pi9rn3v.fsf@uterus.efod.se>


Erik Forsberg added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <metatracker at psf.upfronthosting.co.za> writes:

> It appears that Bug #1523853 was not converted. Its original URL was

> I think it is important to determine what happened to that item, and how many
> other items potentially got lost in the conversion.

% grep 1523853 final-2007-08-23_13:23-UTC.xml
<details>This patch is to fix bug 1523853.
3. Please mention bug 1523853 in a comment near the test.  
Added a comment that mentions bug 1523853.

That is, issue 1523853 is only *mentioned* in the data dump, there is
no <tracker_item> with <id>1523853</id>.

They make backup scripts of high quality at sourceforge.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFG3vNErJurFAusidkRAkw9AJ9si4P9TqK1vo5ElKAINxXtNTRVhwCgkEcM
Tp3nma39TJwjI77F+dCNKxk=
=sDmI
-----END PGP SIGNATURE-----

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

From metatracker at psf.upfronthosting.co.za  Wed Sep  5 20:23:15 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Wed, 05 Sep 2007 18:23:15 -0000
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
In-Reply-To: <46DEA636.8000501@python.org> (Georg Brandl's message of "Wed,
	05 Sep 2007 12:51:04 -0000")
Message-ID: <87zm01q8ds.fsf@uterus.efod.se>


Erik Forsberg added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Georg Brandl <metatracker at psf.upfronthosting.co.za> writes:

> After fiddling with SF (the only way to get total issue counts seems to
> be the tracker summary page, which only lists tracker that aren't hidden,
> so I had to unhide them for a short while), it seems that the total issue
> count in all three trackers was 12785 (bugs 7878, patches 4278, rfe 559).

I took note of how many issues of different types we imported when we
did the final import:

7640 bugs.
4362 patches.
480 rfe.

So, we seem to have lost 238 bugs, gained 84 patches and lost 79
rfe. That's interesting.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFG3vQPrJurFAusidkRAgqJAKCn2jxJUMFx6hymysO0WmYUHsq/PACgiu6v
MzuTfCAekDoW7+9+jRUanVs=
=adau
-----END PGP SIGNATURE-----

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

From draghuram at gmail.com  Wed Sep  5 21:15:13 2007
From: draghuram at gmail.com (Raghuram Devarakonda)
Date: Wed, 5 Sep 2007 15:15:13 -0400
Subject: [Tracker-discuss] mailing list for new tracker items
Message-ID: <2c51ecee0709051215t49b2f92cp17be2b9e2d652c5a@mail.gmail.com>

Hi,

I vaguely remember that as part of the new tracker, a new mailing list
was being considered which would only get mails when a new issue is
created. I couldn't find easily from python's web site about any such
list. Is there one?

Thanks,
Raghu

From metatracker at psf.upfronthosting.co.za  Wed Sep  5 21:23:39 2007
From: metatracker at psf.upfronthosting.co.za (Georg Brandl)
Date: Wed, 05 Sep 2007 19:23:39 -0000
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
In-Reply-To: <874pi9rn3v.fsf@uterus.efod.se>
Message-ID: <46DF026E.1050705@python.org>


Georg Brandl added the comment:

Erik Forsberg schrieb:
> Erik Forsberg added the comment:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> "Martin v. L?wis" <metatracker at psf.upfronthosting.co.za> writes:
> 
>> It appears that Bug #1523853 was not converted. Its original URL was
> 
>> I think it is important to determine what happened to that item, and how many
>> other items potentially got lost in the conversion.
> 
> % grep 1523853 final-2007-08-23_13:23-UTC.xml
> <details>This patch is to fix bug 1523853.
> 3. Please mention bug 1523853 in a comment near the test.  
> Added a comment that mentions bug 1523853.
> 
> That is, issue 1523853 is only *mentioned* in the data dump, there is
> no <tracker_item> with <id>1523853</id>.
> 
> They make backup scripts of high quality at sourceforge.

Argh. It might be inevitable to write a scraper that lists every item ID
in sourceforge, so that it can be checked which issues are lost and how many
of them are open.

Georg

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

From forsberg at efod.se  Wed Sep  5 21:33:40 2007
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 05 Sep 2007 21:33:40 +0200
Subject: [Tracker-discuss] mailing list for new tracker items
In-Reply-To: <2c51ecee0709051215t49b2f92cp17be2b9e2d652c5a@mail.gmail.com>
	(Raghuram Devarakonda's message of "Wed, 5 Sep 2007 15:15:13 -0400")
References: <2c51ecee0709051215t49b2f92cp17be2b9e2d652c5a@mail.gmail.com>
Message-ID: <87odggrjor.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Raghuram Devarakonda" <draghuram at gmail.com> writes:

> I vaguely remember that as part of the new tracker, a new mailing list
> was being considered which would only get mails when a new issue is
> created. I couldn't find easily from python's web site about any such
> list. Is there one?

http://mail.python.org/mailman/listinfo/new-bugs-announce

Regards,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFG3wSTrJurFAusidkRAmU3AKDF60XwJ8gn1DpB5/8+osHQMa9mxwCglI3N
SHse3Ibl1YgykVUKC+nIbm8=
=9Qrv
-----END PGP SIGNATURE-----

From metatracker at psf.upfronthosting.co.za  Wed Sep  5 22:39:29 2007
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Wed, 05 Sep 2007 20:39:29 -0000
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
In-Reply-To: <46DF026E.1050705@python.org>
Message-ID: <bbaeab100709051339o2a2b7a10kd352525df38a3ec5@mail.gmail.com>


Brett C. added the comment:

On 9/5/07, Georg Brandl <metatracker at psf.upfronthosting.co.za> wrote:
>
> Georg Brandl added the comment:
>
> Erik Forsberg schrieb:
> > Erik Forsberg added the comment:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > "Martin v. L?wis" <metatracker at psf.upfronthosting.co.za> writes:
> >
> >> It appears that Bug #1523853 was not converted. Its original URL was
> >
> >> I think it is important to determine what happened to that item, and how many
> >> other items potentially got lost in the conversion.
> >
> > % grep 1523853 final-2007-08-23_13:23-UTC.xml
> > <details>This patch is to fix bug 1523853.
> > 3. Please mention bug 1523853 in a comment near the test.
> > Added a comment that mentions bug 1523853.
> >
> > That is, issue 1523853 is only *mentioned* in the data dump, there is
> > no <tracker_item> with <id>1523853</id>.
> >
> > They make backup scripts of high quality at sourceforge.
>
> Argh. It might be inevitable to write a scraper that lists every item ID
> in sourceforge, so that it can be checked which issues are lost and how many
> of them are open.

I hate SourceForge.

-Brett

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

From brett at python.org  Wed Sep  5 22:39:26 2007
From: brett at python.org (Brett Cannon)
Date: Wed, 5 Sep 2007 13:39:26 -0700
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
In-Reply-To: <46DF026E.1050705@python.org>
References: <874pi9rn3v.fsf@uterus.efod.se> <46DF026E.1050705@python.org>
Message-ID: <bbaeab100709051339o2a2b7a10kd352525df38a3ec5@mail.gmail.com>

On 9/5/07, Georg Brandl <metatracker at psf.upfronthosting.co.za> wrote:
>
> Georg Brandl added the comment:
>
> Erik Forsberg schrieb:
> > Erik Forsberg added the comment:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > "Martin v. L?wis" <metatracker at psf.upfronthosting.co.za> writes:
> >
> >> It appears that Bug #1523853 was not converted. Its original URL was
> >
> >> I think it is important to determine what happened to that item, and how many
> >> other items potentially got lost in the conversion.
> >
> > % grep 1523853 final-2007-08-23_13:23-UTC.xml
> > <details>This patch is to fix bug 1523853.
> > 3. Please mention bug 1523853 in a comment near the test.
> > Added a comment that mentions bug 1523853.
> >
> > That is, issue 1523853 is only *mentioned* in the data dump, there is
> > no <tracker_item> with <id>1523853</id>.
> >
> > They make backup scripts of high quality at sourceforge.
>
> Argh. It might be inevitable to write a scraper that lists every item ID
> in sourceforge, so that it can be checked which issues are lost and how many
> of them are open.

I hate SourceForge.

-Brett

From metatracker at psf.upfronthosting.co.za  Thu Sep  6 19:32:59 2007
From: metatracker at psf.upfronthosting.co.za (Collin Winter)
Date: Thu, 06 Sep 2007 17:32:59 -0000
Subject: [Tracker-discuss] [issue150] Add a 2to3 component
Message-ID: <1189099979.77.0.948941945749.issue150@psf.upfronthosting.co.za>


New submission from Collin Winter:

I'd appreciate it if there could be a 2to3 component for reporting bugs related
to that tool. Even better would be if issues filed under this component were
automatically assigned to me.

----------
messages: 760
nosy: collinwinter
priority: feature
status: unread
title: Add a 2to3 component

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

From metatracker at psf.upfronthosting.co.za  Thu Sep  6 19:48:07 2007
From: metatracker at psf.upfronthosting.co.za (Georg Brandl)
Date: Thu, 06 Sep 2007 17:48:07 -0000
Subject: [Tracker-discuss] [issue150] Add a 2to3 component
Message-ID: <1189100887.5.0.293236502782.issue150@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I've added the component. I'm not sure how much work it is to implement the
auto-assign feature in roundup, which is not present ATM, IIRC.

----------
assignedto:  -> forsberg
nosy: +forsberg
status: unread -> done-cbb

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

From metatracker at psf.upfronthosting.co.za  Sat Sep  8 19:15:02 2007
From: metatracker at psf.upfronthosting.co.za (Guido van Rossum)
Date: Sat, 08 Sep 2007 17:15:02 -0000
Subject: [Tracker-discuss] [issue151] Show authors' real names in web UI
Message-ID: <1189271702.84.0.00608650967194.issue151@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I notice that we have authors' real names, e.g. the email lists these. But the
web UI only gives the username. Sometimes that's fine (e.g. georg.brandl) but
sometimes it's not (pythonmeister == Stefan Sonnenberg-Carstens).  I'd like to
see the real names in the web UI too.

----------
messages: 762
nosy: guido
priority: wish
status: unread
title: Show authors' real names in web UI

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

From metatracker at psf.upfronthosting.co.za  Sat Sep  8 19:18:27 2007
From: metatracker at psf.upfronthosting.co.za (Georg Brandl)
Date: Sat, 08 Sep 2007 17:18:27 -0000
Subject: [Tracker-discuss] [issue151] Show authors' real names in web UI
Message-ID: <1189271907.19.0.330966350567.issue151@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Dupe of issue133.

----------
status: unread -> resolved
superseder: +show real name of comment authors

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

From metatracker at psf.upfronthosting.co.za  Sun Sep  9 23:36:21 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 09 Sep 2007 21:36:21 -0000
Subject: [Tracker-discuss] [issue52] Easy way to tell when code is attached
	to an issue
Message-ID: <1189373781.64.0.761553494776.issue52@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

There is the patch keyword now, and it should be used to indicate that a patch
is attached to an issue. ISTM that this keyword resolves the issue. Brett?

______________________________________________________
Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue52>
______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Sep  9 23:40:28 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 09 Sep 2007 21:40:28 -0000
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
Message-ID: <1189374028.5.0.0156839036217.issue149@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Downgrading priority. The issues are still stored at SF, and we can try to add
them at any point, ISTM.

----------
priority: critical -> bug

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 10 05:08:43 2007
From: metatracker at psf.upfronthosting.co.za (Paul Dubois)
Date: Mon, 10 Sep 2007 03:08:43 -0000
Subject: [Tracker-discuss] [issue150] Add a 2to3 component
Message-ID: <1189393723.18.0.426764444743.issue150@psf.upfronthosting.co.za>


Paul Dubois added the comment:

I will take a shot at the auto-assign task. -- Paul

----------
assignedto: forsberg -> dubois
nosy: +dubois
status: done-cbb -> chatting

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 10 05:15:28 2007
From: metatracker at psf.upfronthosting.co.za (Paul Dubois)
Date: Mon, 10 Sep 2007 03:15:28 -0000
Subject: [Tracker-discuss] [issue152] roundup-summary does not seem to be
	firing on time
Message-ID: <1189394128.31.0.870011972753.issue152@psf.upfronthosting.co.za>


New submission from Paul Dubois:

roundup-summary has not sent mail to python-dev since we went live. I can run it
as the roundup user without problem, using the exact text in the crontab;
usually when that is true a script will work under crontab. I edited the crontab
for user roundup and changed the day and time and will see if that makes a
difference -- perhaps it is religious and feels it shouldn't work on Sunday.
File permissions look ok.

If anyone has any insight I'd like to hear it.

----------
assignedto: dubois
messages: 767
nosy: dubois, izak, roche, stefan
priority: bug
status: unread
title: roundup-summary does not seem to be firing on time

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 10 05:20:18 2007
From: metatracker at psf.upfronthosting.co.za (Paul Dubois)
Date: Mon, 10 Sep 2007 03:20:18 -0000
Subject: [Tracker-discuss] [issue152] roundup-summary does not seem to be
	firing on time
Message-ID: <1189394418.3.0.0787343391522.issue152@psf.upfronthosting.co.za>


Paul Dubois added the comment:

I ran a summary since Aug. 23 by hand and sent it to myself, and after I
received it did a forward to python-dev. Interestingly it got held for approval
as being too big. Now, it is bigger than a weekly summary would be normally, but
I wonder if the summaries have been sent but got held or discarded, perhaps for
coming from an unknown address? I know we thought of that before but...

----------
nosy: +loewis
status: unread -> chatting

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 10 21:04:08 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Mon, 10 Sep 2007 19:04:08 -0000
Subject: [Tracker-discuss] [issue152] roundup-summary does not seem to be
	firing on time
In-Reply-To: <1189394418.3.0.0787343391522.issue152@psf.upfronthosting.co.za>
Message-ID: <20070910210358.2414aa6e@uterus>


Erik Forsberg added the comment:

On Mon, 10 Sep 2007 03:20:18 -0000
Paul Dubois <metatracker at psf.upfronthosting.co.za> wrote:

> 
> Paul Dubois added the comment:
> 
> I ran a summary since Aug. 23 by hand and sent it to myself, and
> after I received it did a forward to python-dev. Interestingly it got
> held for approval as being too big. Now, it is bigger than a weekly
> summary would be normally, but I wonder if the summaries have been
> sent but got held or discarded, perhaps for coming from an unknown
> address? I know we thought of that before but...

The cronjob did run:

# grep roundup-summary syslog.0 
Sep 10 03:56:01 psf /USR/SBIN/CRON[28838]: (roundup) CMD
(/home/roundup/roundup/bin/roundup-summary /home/roundup/trackers/tracker
--mail python-dev<at>python.org)

..and the mail was sent:

Sep 10 03:56:55 psf postfix/smtpd[28894]: connect from localhost[10.0.0.1] 
Sep 10 03:56:56 psf postfix/smtpd[28894]:EC0FA782C1:
client=localhost[10.0.0.1] 
Sep 10 03:56:56 psf postfix/cleanup[28897]:
EC0FA782C1: message-id=<200709100356
55.EC0FA782C1 at psf.upfronthosting.co.za> Sep 10 03:56:56 psf
postfix/qmgr[21557]: EC0FA782C1: from=<roundup-admin<at>psf.upf
ronthosting.co.za>, size=43926, nrcpt=1 (queue active) Sep 10 03:56:56
psf postfix/smtpd[28894]: disconnect from localhost[10.0.0.1] Sep 10
03:56:56 psf postfix/smtp[28898]: EC0FA782C1:
to=<python-dev<at>python.org>, relay=mail.python.org[194.109.207.14]:25,
delay=1, delays=0.09/0.01/0.15/0.79, dsn=2.0.0, status=sent (250 2.0.0
Ok: queued as E3A361E4004) Sep 10 03:56:56 psf postfix/qmgr[21557]:
EC0FA782C1: removed

(@ converted into <at> to protect the innocent)

I guess the rest is up to the python postmaster to debug.

\EF
-- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9

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

From facundobatista at gmail.com  Mon Sep 10 22:25:11 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 10 Sep 2007 17:25:11 -0300
Subject: [Tracker-discuss] Python tickets summary
Message-ID: <e04bdf310709101325o1315adb0pebcb2f33d8313f35@mail.gmail.com>

People:

I modified my tool, whichs makes a summary of all the Python tickets
(I moved the source where the info is taken from SF to our Roundup).

In result, the summary is now, again, updated daily:

  http://www.taniquetil.com.ar/facundo/py_tickets.html


Enjoy it.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From metatracker at psf.upfronthosting.co.za  Tue Sep 11 07:25:38 2007
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Tue, 11 Sep 2007 05:25:38 -0000
Subject: [Tracker-discuss] [issue153] trigger traceback when doing issue
	search on non-existent username
Message-ID: <1189488338.51.0.328974488764.issue153@psf.upfronthosting.co.za>


New submission from Brett C.:

http://bugs.python.org/issue?%40search_text=&title=&%40columns=title&id=&%40columns=id&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&type=&components=&versions=&severity=&dependencies=&assignee=bcannon&keywords=&priority=&%40group=priority&status=2&%40columns=status&resolution=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search

I tried to search for issues that I had closed and were assigned to me, but I
accidentally used my old username, "bcannon".   That triggered a traceback.

----------
messages: 770
nosy: brettcannon
priority: urgent
status: unread
title: trigger traceback when doing issue search on non-existent username

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 11 12:36:29 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 11 Sep 2007 10:36:29 -0000
Subject: [Tracker-discuss] [issue149] 1523853 was not converted
Message-ID: <1189506989.69.0.321789103513.issue149@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I filed

http://sourceforge.net/tracker/index.php?func=detail&aid=1792262&group_id=1&atid=200001

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 11 22:13:22 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Tue, 11 Sep 2007 20:13:22 -0000
Subject: [Tracker-discuss] [issue153] trigger traceback when doing issue
	search on non-existent username
In-Reply-To: <1189488338.51.0.328974488764.issue153@psf.upfronthosting.co.za>
Message-ID: <20070911221313.0b99ef52@uterus>


Erik Forsberg added the comment:

> priority: urgent

Are you sure you mean that this really really needs to be fixed ASAP?

\EF
-- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9

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

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 11 23:24:57 2007
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Tue, 11 Sep 2007 21:24:57 -0000
Subject: [Tracker-discuss] [issue153] trigger traceback when doing issue
	search on non-existent username
Message-ID: <1189545897.9.0.966356866608.issue153@psf.upfronthosting.co.za>


Brett C. added the comment:

I guess not.  Habit of not liking anything that seems like a "crash".  But since
it isn't preventing the tracker from working it is not that big of a deal.

----------
priority: urgent -> bug

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 12 21:47:25 2007
From: metatracker at psf.upfronthosting.co.za (Guido van Rossum)
Date: Wed, 12 Sep 2007 19:47:25 -0000
Subject: [Tracker-discuss] [issue154] auto-link to svn.python.org for
	revision IDs
Message-ID: <1189626445.51.0.600267667041.issue154@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I wish there was automatic linking to the appropriate URL on svn.python.org
whenever the pattern "revision NNNNN" or "rNNNNN" is found anywhere in a comment.

----------
messages: 774
nosy: guido
priority: wish
status: unread
title: auto-link to svn.python.org for revision IDs

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 12 21:49:03 2007
From: metatracker at psf.upfronthosting.co.za (Georg Brandl)
Date: Wed, 12 Sep 2007 19:49:03 -0000
Subject: [Tracker-discuss] [issue154] auto-link to svn.python.org for
	revision IDs
Message-ID: <1189626543.58.0.403444183656.issue154@psf.upfronthosting.co.za>


Georg Brandl added the comment:

While we're at it, it could also link to Python source files, provided they're
qualified with the full relative path.

Since we have only few toplevel paths (Lib, Modules, ...), this should be an
easy thing to do.

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

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 12 21:56:53 2007
From: metatracker at psf.upfronthosting.co.za (Stefan Seefeld)
Date: Wed, 12 Sep 2007 19:56:53 -0000
Subject: [Tracker-discuss] [issue154] auto-link to svn.python.org for
	revision IDs
In-Reply-To: <1189626445.51.0.600267667041.issue154@psf.upfronthosting.co.za>
Message-ID: <46E8447A.1060302@sympatico.ca>


Stefan Seefeld added the comment:

Guido van Rossum wrote:
> New submission from Guido van Rossum:
> 
> I wish there was automatic linking to the appropriate URL on svn.python.org
> whenever the pattern "revision NNNNN" or "rNNNNN" is found anywhere in a comment.

I do have some code (which I use in my own Synopsis project), which does
exactly this. Someone may want to adapt and integrate it into the python
tracker. It's attached to this mail.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________________
Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue154>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CustomTags.py
Type: text/x-python
Size: 1330 bytes
Desc: not available
Url : http://mail.python.org/pipermail/tracker-discuss/attachments/20070912/40d63555/attachment.py 

From metatracker at psf.upfronthosting.co.za  Wed Sep 12 22:01:50 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 12 Sep 2007 20:01:50 -0000
Subject: [Tracker-discuss] [issue154] auto-link to svn.python.org for
	revision IDs
Message-ID: <1189627310.28.0.700459077723.issue154@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I guess the appropriate URL would be this one:

http://svn.python.org/view?rev=NNNNN&view=rev

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

From metatracker at psf.upfronthosting.co.za  Thu Sep 13 14:36:53 2007
From: metatracker at psf.upfronthosting.co.za (Jeff Rush)
Date: Thu, 13 Sep 2007 12:36:53 -0000
Subject: [Tracker-discuss] [issue155] Add to Python Bug Sys RSS Feeds for
	Bug Reports, with Filters
Message-ID: <1189687013.8.0.983775873845.issue155@psf.upfronthosting.co.za>


New submission from Jeff Rush:

To help raise the visibility of bug work in the Python community, consider
adding a series of RSS feeds for those who keep RSS viewers at-hand all day. 
This can take either of two forms:

1) Add to the RSS list those bugs that have some activity, whether closing or
not, similar to how the PEP RSS feed jumps a doc to the front when it changes. 
People would then click thru to follow the activity.

2) Keep on the RSS list the highest priority N bugs; this would be a slow
changing list but the idea is to motivate people to 'knock them off' the list
because they keep seeing them and getting mindshare.

Another possibility is a 'quick things to do' RSS feed, if the bugs were so
tagged.  In this case its the person who has 1-2 hours free, sees a
quick-response bug and tackles it spontaneously.

Any RSS feed URL should take a few URL qualifiers, to select between Python 2.x
and Python 3.x bugs, for those not yet using/working on Python 3.x.  These
qualifiers could be also be used to get the short-duration action items, or the
oldest on the list or only documentation bugs for tech writers, etc.  Not saying
go crazy here with a full query language, just provide a handful of distinctions.

In general I find the bugs system for Python to be rather invisible in the local
community - people think they get fixed by gnomes in the night. ;-)  With this
feature I'm trying to raise that visibility.

----------
messages: 778
nosy: jrush
priority: wish
status: unread
title: Add to Python Bug Sys RSS Feeds for Bug Reports, with Filters

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

From metatracker at psf.upfronthosting.co.za  Thu Sep 13 14:47:45 2007
From: metatracker at psf.upfronthosting.co.za (Jeff Rush)
Date: Thu, 13 Sep 2007 12:47:45 -0000
Subject: [Tracker-discuss] [issue156] Have a Core Bug Chaser Create a Bug
	Reporting Screencast
Message-ID: <1189687665.63.0.143239718478.issue156@psf.upfronthosting.co.za>


New submission from Jeff Rush:

To help those who want to help fix/report bugs, have someone experienced with
the system record 5-minute "How to Report a Bug" and a "How to Find a Bug to
Tackle" screencasts.

When I go to bugs.python.org and search for things to help with, I'm overwhelmed
with the query options and am not sure where to start.  This is the kind of
thing a screencast is good for and a written document/wiki page is bad for.

Might also expand the screencast a bit, in that do one for tech-writers, teach
briefly how the doc tools work, then how to find an unfixed doc bug to work,
then how to submit their finished work into the system for integration.

----------
messages: 779
nosy: jrush
priority: wish
status: unread
title: Have a Core Bug Chaser Create a Bug Reporting Screencast

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

From facundobatista at gmail.com  Thu Sep 13 21:08:48 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 13 Sep 2007 16:08:48 -0300
Subject: [Tracker-discuss] Python tickets summary
In-Reply-To: <e04bdf310709101325o1315adb0pebcb2f33d8313f35@mail.gmail.com>
References: <e04bdf310709101325o1315adb0pebcb2f33d8313f35@mail.gmail.com>
Message-ID: <e04bdf310709131208v307bb273gd47a48779b4db61b@mail.gmail.com>

2007/9/10, Facundo Batista <facundobatista at gmail.com>:

> I modified my tool, whichs makes a summary of all the Python tickets
> (I moved the source where the info is taken from SF to our Roundup).
>
> In result, the summary is now, again, updated daily:

Taking an idea from Jeff Rush, now there're separate listings in
function of the keyword of the ticket.

This way, you can see only the Py3k tickets, or the patchs, etc.

All the listings are accesible from the same pages, start here:

  http://www.taniquetil.com.ar/facundo/py_tickets.html

(remember to refresh)

Any idea to improve these pages is welcomed.

Regards,

--
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From metatracker at psf.upfronthosting.co.za  Thu Sep 13 22:19:17 2007
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Thu, 13 Sep 2007 20:19:17 -0000
Subject: [Tracker-discuss] [issue156] Have a Core Bug Chaser Create a Bug
	Reporting Screencast
In-Reply-To: <1189687665.63.0.143239718478.issue156@psf.upfronthosting.co.za>
Message-ID: <bbaeab100709131319l4cd3cedfwb86bf6831d942530@mail.gmail.com>


Brett C. added the comment:

This should probably wait until we redesign the workflow of the issue
tracker.  Once people have experience with it and all initial bugs are
worked (and Erik is ready for more trouble  =) out I plan to bring up
with python-dev the question of how we want our bugs to look instead
of continuing to force ourselves to work within SF's issue workflow.

On 9/13/07, Jeff Rush <metatracker at psf.upfronthosting.co.za> wrote:
>
> New submission from Jeff Rush:
>
> To help those who want to help fix/report bugs, have someone experienced with
> the system record 5-minute "How to Report a Bug" and a "How to Find a Bug to
> Tackle" screencasts.
>
> When I go to bugs.python.org and search for things to help with, I'm overwhelmed
> with the query options and am not sure where to start.  This is the kind of
> thing a screencast is good for and a written document/wiki page is bad for.
>
> Might also expand the screencast a bit, in that do one for tech-writers, teach
> briefly how the doc tools work, then how to find an unfixed doc bug to work,
> then how to submit their finished work into the system for integration.
>
> ----------
> messages: 779
> nosy: jrush
> priority: wish
> status: unread
> title: Have a Core Bug Chaser Create a Bug Reporting Screencast
>
> _______________________________________________________
> Meta Tracker <metatracker at psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue156>
> _______________________________________________________
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

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

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

From g.brandl at gmx.net  Sat Sep 15 17:59:49 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 15 Sep 2007 17:59:49 +0200
Subject: [Tracker-discuss] Spam/vandalism
Message-ID: <46EC0175.4030100@gmx.net>

It looks like we have the first vandalism incident in the live tracker,
see issues #1165, #1166.

How to proceed here?

In #1165, the spammer added a comment and made several changes to metadata.
Marking the offensive message ("Hi guys.") as spam doesn't make sense. I can
delete the message, but it doesn't seem that I can easily delete the metadata
changes made.

#1166 is a newly created nonsense issue. Can it be deleted completely?

Also, since the offending username "esr" was part of the Python SF.net
project, how did the spammer gain access to the account?

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/tracker-discuss/attachments/20070915/2a51d630/attachment.pgp 

From pfdubois at gmail.com  Sat Sep 15 18:47:04 2007
From: pfdubois at gmail.com (Paul Dubois)
Date: Sat, 15 Sep 2007 09:47:04 -0700
Subject: [Tracker-discuss] Spam/vandalism
In-Reply-To: <46EC0175.4030100@gmx.net>
References: <46EC0175.4030100@gmx.net>
Message-ID: <f74a6c2f0709150947m404cc0cmac6f91f4d865478e@mail.gmail.com>

An issue can be 'retired' using an administrative tool on the tracker
machine. I'm signed up to be the person who does this. While I check for
spam periodically it is always good to be told about some.

The metadata can be reversed because the log tells what the changes were.
Again, I will take care of this.

I'll have to change the password on the offending account and see if I can
contact the owner.

On 9/15/07, Georg Brandl <g.brandl at gmx.net> wrote:
>
> It looks like we have the first vandalism incident in the live tracker,
> see issues #1165, #1166.
>
> How to proceed here?
>
> In #1165, the spammer added a comment and made several changes to
> metadata.
> Marking the offensive message ("Hi guys.") as spam doesn't make sense. I
> can
> delete the message, but it doesn't seem that I can easily delete the
> metadata
> changes made.
>
> #1166 is a newly created nonsense issue. Can it be deleted completely?
>
> Also, since the offending username "esr" was part of the Python SF.net
> project, how did the spammer gain access to the account?
>
> Georg
>
>
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20070915/007c03e6/attachment.htm 

From brett at python.org  Sat Sep 15 23:14:20 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 15 Sep 2007 14:14:20 -0700
Subject: [Tracker-discuss] Spam/vandalism
In-Reply-To: <f74a6c2f0709150947m404cc0cmac6f91f4d865478e@mail.gmail.com>
References: <46EC0175.4030100@gmx.net>
	<f74a6c2f0709150947m404cc0cmac6f91f4d865478e@mail.gmail.com>
Message-ID: <bbaeab100709151414r272bbcc6m9b7ccb4bba3e2dc5@mail.gmail.com>

On 9/15/07, Paul Dubois <pfdubois at gmail.com> wrote:
> An issue can be 'retired' using an administrative tool on the tracker
> machine. I'm signed up to be the person who does this. While I check for
> spam periodically it is always good to be told about some.
>
> The metadata can be reversed because the log tells what the changes were.
> Again, I will take care of this.
>
> I'll have to change the password on the offending account and see if I can
> contact the owner.

Wow.  The guy went as far as to add a new keyword.  That sucks.

-Brett

From martin at v.loewis.de  Sun Sep 16 00:36:22 2007
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Sep 2007 00:36:22 +0200
Subject: [Tracker-discuss] Spam/vandalism
In-Reply-To: <46EC0175.4030100@gmx.net>
References: <46EC0175.4030100@gmx.net>
Message-ID: <46EC5E66.6070600@v.loewis.de>

> How to proceed here?

I revoked his Developer privileges, and confronted him
with the claim that he hijacked some account. I'm fairly
certain he is *not* Eric S. Raymond, but I don't think
Eric needs developer status any longer.

Regards,
Martin

From brett at python.org  Sun Sep 16 02:11:22 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 15 Sep 2007 17:11:22 -0700
Subject: [Tracker-discuss] Spam/vandalism
In-Reply-To: <46EC5E66.6070600@v.loewis.de>
References: <46EC0175.4030100@gmx.net> <46EC5E66.6070600@v.loewis.de>
Message-ID: <bbaeab100709151711o4ec9a4c0j49e31d0e46585976@mail.gmail.com>

On 9/15/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > How to proceed here?
>
> I revoked his Developer privileges, and confronted him
> with the claim that he hijacked some account. I'm fairly
> certain he is *not* Eric S. Raymond, but I don't think
> Eric needs developer status any longer.

Perhaps we should go through and clean up who has Developer
privileges?  If we said people needed to change their usernames to
match their svn name would it be difficult to just programmatically
disable Developer privs for everyone who doesn't match the svn list
(which is available from http://www.python.org/dev/committers)?  This
could at least initially clean out stale accounts.  From there we can
just add people as needed.

Or maybe this just an isolated incident and we really don't need to
spend the time.

-Brett

From pfdubois at gmail.com  Sun Sep 16 04:49:36 2007
From: pfdubois at gmail.com (Paul Dubois)
Date: Sat, 15 Sep 2007 19:49:36 -0700
Subject: [Tracker-discuss] Spam/vandalism
In-Reply-To: <46EC5E66.6070600@v.loewis.de>
References: <46EC0175.4030100@gmx.net> <46EC5E66.6070600@v.loewis.de>
Message-ID: <f74a6c2f0709151949h1089623bv934b380746a77fa@mail.gmail.com>

I went ahead and changed the password to prevent further mischief. I didn't
retire the user because if the real Eric wants esr back it is easiest if I
don't.

On 9/15/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> > How to proceed here?
>
> I revoked his Developer privileges, and confronted him
> with the claim that he hijacked some account. I'm fairly
> certain he is *not* Eric S. Raymond, but I don't think
> Eric needs developer status any longer.
>
> Regards,
> Martin
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20070915/8bfc9feb/attachment.htm 

From brett at python.org  Sun Sep 16 06:54:55 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 15 Sep 2007 21:54:55 -0700
Subject: [Tracker-discuss] Spam/vandalism
In-Reply-To: <f74a6c2f0709151949h1089623bv934b380746a77fa@mail.gmail.com>
References: <46EC0175.4030100@gmx.net> <46EC5E66.6070600@v.loewis.de>
	<f74a6c2f0709151949h1089623bv934b380746a77fa@mail.gmail.com>
Message-ID: <bbaeab100709152154l1be77318ud93a19da8b647786@mail.gmail.com>

On 9/15/07, Paul Dubois <pfdubois at gmail.com> wrote:
> I went ahead and changed the password to prevent further mischief. I didn't
> retire the user because if the real Eric wants esr back it is easiest if I
> don't.

OK.  Thanks for handling this, Paul.

-Brett

From metatracker at psf.upfronthosting.co.za  Sun Sep 16 14:36:13 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Sun, 16 Sep 2007 12:36:13 -0000
Subject: [Tracker-discuss] [issue154] auto-link to svn.python.org for
	revision IDs
In-Reply-To: <1189626445.51.0.600267667041.issue154@psf.upfronthosting.co.za>
Message-ID: <20070916143555.033378b2@uterus>


Erik Forsberg added the comment:

On Wed, 12 Sep 2007 19:47:25 -0000
Guido van Rossum <metatracker at psf.upfronthosting.co.za> wrote:

> 
> New submission from Guido van Rossum:
> 
> I wish there was automatic linking to the appropriate URL on
> svn.python.org whenever the pattern "revision NNNNN" or "rNNNNN" is
> found anywhere in a comment.

A typical "sunday afternoon hack" :-), made easy by the fact that there
was already a extensions/local_replace.py for the translation of #NNN
-> issue links.

Linking to python source files is up for somebody else to fix - marking
as 'done-cbb' (Done, Could Be Better).

\EF
-- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9

----------
assignedto:  -> forsberg
nosy: +forsberg
status: chatting -> done-cbb

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

From metatracker at psf.upfronthosting.co.za  Sun Sep 16 16:57:34 2007
From: metatracker at psf.upfronthosting.co.za (Guido van Rossum)
Date: Sun, 16 Sep 2007 14:57:34 -0000
Subject: [Tracker-discuss] [issue154] auto-link to svn.python.org for
	revision IDs
In-Reply-To: <20070916143555.033378b2@uterus>
Message-ID: <ca471dc20709160757p67c0bf5av10cf243f5f2fbfe0@mail.gmail.com>


Guido van Rossum added the comment:

On 9/16/07, Erik Forsberg <metatracker at psf.upfronthosting.co.za> wrote:

> Guido van Rossum <metatracker at psf.upfronthosting.co.za> wrote:
> > I wish there was automatic linking to the appropriate URL on
> > svn.python.org whenever the pattern "revision NNNNN" or "rNNNNN" is
> > found anywhere in a comment.

> A typical "sunday afternoon hack" :-), made easy by the fact that there
> was already a extensions/local_replace.py for the translation of #NNN
> -> issue links.
>
> Linking to python source files is up for somebody else to fix - marking
> as 'done-cbb' (Done, Could Be Better).

Yay - thanks!!

----------
status: done-cbb -> chatting

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 17 18:39:14 2007
From: metatracker at psf.upfronthosting.co.za (Paul Dubois)
Date: Mon, 17 Sep 2007 16:39:14 -0000
Subject: [Tracker-discuss] [issue157] What policy about users with bad
	emails?
Message-ID: <1190047154.71.0.546658708048.issue157@psf.upfronthosting.co.za>


New submission from Paul Dubois:

When the tracker's emails can't be delivered the tracker sends mail to
roundup-admin informing us of the failure. Many such failures are temporal in
nature but some of them will be repeated because the email address really has
gone bad. A human could decide enough is enough. But, what to do?

We cannot set the email to blank, it is a required field. We can retire the user
altogether, but that stops the user from logging in and fixing it. We could add
a flag to the user class suspending any email to them. 

Any thoughts?

----------
messages: 783
nosy: dubois
priority: wish
status: unread
title: What policy about users with bad emails?

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 17 19:33:16 2007
From: metatracker at psf.upfronthosting.co.za (Georg Brandl)
Date: Mon, 17 Sep 2007 17:33:16 -0000
Subject: [Tracker-discuss] [issue157] What policy about users with bad
	emails?
Message-ID: <1190050396.12.0.104291370829.issue157@psf.upfronthosting.co.za>


Georg Brandl added the comment:

How many accounts are that? If it's not too many, I'd give them maybe half a
year, then try to send a mail again and it that fails, delete the account.

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

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 17 20:05:37 2007
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Mon, 17 Sep 2007 18:05:37 -0000
Subject: [Tracker-discuss] [issue157] What policy about users with bad
	emails?
In-Reply-To: <1190050396.12.0.104291370829.issue157@psf.upfronthosting.co.za>
Message-ID: <bbaeab100709171105t1930edb2k7557d69325cffce6@mail.gmail.com>


Brett C. added the comment:

Somehow flagging the account in a way that the next time the user logs
in they are notified their email is bad would be good.  And if they
don't deal with it in a timely manner their account is deactivated or
retired.

Six months seems long, but I guess if we disabled the delivery during
that time it is not a huge deal.

On 9/17/07, Georg Brandl <metatracker at psf.upfronthosting.co.za> wrote:
>
> Georg Brandl added the comment:
>
> How many accounts are that? If it's not too many, I'd give them maybe half a
> year, then try to send a mail again and it that fails, delete the account.
>
> ----------
> status: unread -> chatting
>
> _______________________________________________________
> Meta Tracker <metatracker at psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue157>
> _______________________________________________________
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 19 00:25:05 2007
From: metatracker at psf.upfronthosting.co.za (Guido van Rossum)
Date: Tue, 18 Sep 2007 22:25:05 -0000
Subject: [Tracker-discuss] [issue158] multi-line From headers in outgoing
	mail break PINE
Message-ID: <1190154305.88.0.203478393492.issue158@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I received a complaint from Dennis Allison that the tracker sends email with
multiline From headers, which (he thinks) are disallowed by the RFC and in any
case cause problems with his PINE email reader (a fine email reader I might add).

Example:

Date: Tue, 18 Sep 2007 21:30:46 -0000
From: "[utf-8]
                                       Jim Jewett
                               " <report at bugs.python.org>
To: python-bugs-list at python.org
Subject: [issue1177] urllib* 20x responses not OK?

...

----------
messages: 786
nosy: guido
priority: urgent
status: unread
title: multi-line From headers in outgoing mail break PINE

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 19 08:25:07 2007
From: metatracker at psf.upfronthosting.co.za (Georg Brandl)
Date: Wed, 19 Sep 2007 06:25:07 -0000
Subject: [Tracker-discuss] [issue141] Should send email on assignment
Message-ID: <1190183107.81.0.221014416235.issue141@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Can we please fix this?

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 19 19:38:11 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Wed, 19 Sep 2007 17:38:11 -0000
Subject: [Tracker-discuss] [issue158] multi-line From headers in outgoing
	mail break PINE
Message-ID: <1190223491.73.0.506725761765.issue158@psf.upfronthosting.co.za>


Erik Forsberg added the comment:

> I received a complaint from Dennis Allison that the tracker sends
> email with multiline From headers, which (he thinks) are disallowed
> by the RFC and in any case cause problems with his PINE email reader

Yes, this has been recorded as issue147 in the meta tracker. In the
last message of this issue, I asked Dennis to provide an example
message. I'm still waiting for a reply. 

I'm also not convinced the from lines produced by roundup are forbidden by
RFC.

> (a fine email reader I might add).

Well.. let's just say that that's not an opinion shared by everyone :-).

(Closing as duplicate of issue147)

----------
status: unread -> resolved
superseder: +Current email headers corrupt mail reader display

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 19 19:43:05 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Wed, 19 Sep 2007 17:43:05 -0000
Subject: [Tracker-discuss] [issue141] Should send email on assignment
Message-ID: <1190223785.18.0.432966507871.issue141@psf.upfronthosting.co.za>


Erik Forsberg added the comment:

I'll take a look.

----------
assignedto:  -> forsberg
nosy: +forsberg

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 19 20:23:47 2007
From: metatracker at psf.upfronthosting.co.za (Guido van Rossum)
Date: Wed, 19 Sep 2007 18:23:47 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
Message-ID: <1190226227.6.0.785455151701.issue147@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I pasted the headers from the example that Dennis mailed me into issue 158.

I also noted this in the new-bugs digest email. It seems to be a problem only
with Jim Jewett:

"""
Message: 3
Date: Tue, 18 Sep 2007 20:22:53 -0000
From: 					Jim Jewett				 	<report at bugs.python.org>
Subject: [New-bugs-announce] [issue1177] urllib* 20x responses not OK?
To: new-bugs-announce at python.org
Message-ID:
	<1190146973.85.0.192058090901.issue1177 at psf.upfronthosting.co.za>
Content-Type: text/plain; charset=utf-8


New submission from 
					Jim Jewett
				:

Under the http protocol, any 2xx response is OK.
"""

Note the extra whitespace around Jim Jewett.  Perhaps something wacky is going
on with Jim Jewett's user entry?  Other entries in the same digest don't have this.

Even if the RFC doesn't strictly disallow this behavior, I think we should fix
it if we can.

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

From skip at pobox.com  Wed Sep 19 20:24:29 2007
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 19 Sep 2007 13:24:29 -0500
Subject: [Tracker-discuss] [issue158] multi-line From headers in
 outgoing mail break PINE
In-Reply-To: <1190223491.73.0.506725761765.issue158@psf.upfronthosting.co.za>
References: <1190223491.73.0.506725761765.issue158@psf.upfronthosting.co.za>
Message-ID: <18161.26973.687573.112085@montanaro.dyndns.org>


    >> I received a complaint from Dennis Allison that the tracker sends
    >> email with multiline From headers, which (he thinks) are disallowed
    >> by the RFC and in any case cause problems with his PINE email reader

    Erik> Yes, this has been recorded as issue147 in the meta tracker. In the
    Erik> last message of this issue, I asked Dennis to provide an example
    Erik> message. I'm still waiting for a reply. 

    Erik> I'm also not convinced the from lines produced by roundup are
    Erik> forbidden by RFC.

Though to play nicely in the sandbox Roundup should be strict in what it
produces and Pine should be forgiving in what it accepts.

The From_ (as opposed to the From:) header of the message I'm responding to
is 96 characters long and was not wrapped.  Is it possible that Roundup is
doing the right thing but that some misbehaving MTA between Roundup and
Dennis is doing the line wrapping he sees?

Skip

From metatracker at psf.upfronthosting.co.za  Wed Sep 19 20:37:26 2007
From: metatracker at psf.upfronthosting.co.za (Paul Dubois)
Date: Wed, 19 Sep 2007 18:37:26 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <1190226227.6.0.785455151701.issue147@psf.upfronthosting.co.za>
Message-ID: <f74a6c2f0709191137j3a06c369o4725c860075a95f5@mail.gmail.com>


Paul Dubois added the comment:

I examined his user record and do not see any extra spaces.

On 9/19/07, Guido van Rossum <metatracker at psf.upfronthosting.co.za> wrote:
>
>
> Guido van Rossum added the comment:
>
> I pasted the headers from the example that Dennis mailed me into issue
> 158.
>
> I also noted this in the new-bugs digest email. It seems to be a problem
> only
> with Jim Jewett:
>
> """
> Message: 3
> Date: Tue, 18 Sep 2007 20:22:53 -0000
> From:                                   Jim
> Jewett                                      <report at bugs.python.org>
> Subject: [New-bugs-announce] [issue1177] urllib* 20x responses not OK?
> To: new-bugs-announce at python.org
> Message-ID:
>         <1190146973.85.0.192058090901.issue1177 at psf.upfronthosting.co.za>
> Content-Type: text/plain; charset=utf-8
>
>
> New submission from
>                                         Jim Jewett
>                                 :
>
> Under the http protocol, any 2xx response is OK.
> """
>
> Note the extra whitespace around Jim Jewett.  Perhaps something wacky is
> going
> on with Jim Jewett's user entry?  Other entries in the same digest don't
> have this.
>
> Even if the RFC doesn't strictly disallow this behavior, I think we should
> fix
> it if we can.
>
> _______________________________________________________
> Meta Tracker <metatracker at psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue147>
> _______________________________________________________
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

_______________________________________________________
Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue147>
_______________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20070919/9d865ebf/attachment.htm 

From metatracker at psf.upfronthosting.co.za  Wed Sep 19 20:49:20 2007
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Wed, 19 Sep 2007 18:49:20 -0000
Subject: [Tracker-discuss] [issue158] multi-line From headers in outgoing
	mail break PINE
In-Reply-To: <1190223491.73.0.506725761765.issue158@psf.upfronthosting.co.za>
Message-ID: <18161.26973.687573.112085@montanaro.dyndns.org>


Skip Montanaro added the comment:

>> I received a complaint from Dennis Allison that the tracker sends
    >> email with multiline From headers, which (he thinks) are disallowed
    >> by the RFC and in any case cause problems with his PINE email reader

    Erik> Yes, this has been recorded as issue147 in the meta tracker. In the
    Erik> last message of this issue, I asked Dennis to provide an example
    Erik> message. I'm still waiting for a reply. 

    Erik> I'm also not convinced the from lines produced by roundup are
    Erik> forbidden by RFC.

Though to play nicely in the sandbox Roundup should be strict in what it
produces and Pine should be forgiving in what it accepts.

The From_ (as opposed to the From:) header of the message I'm responding to
is 96 characters long and was not wrapped.  Is it possible that Roundup is
doing the right thing but that some misbehaving MTA between Roundup and
Dennis is doing the line wrapping he sees?

Skip

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

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

From metatracker at psf.upfronthosting.co.za  Wed Sep 19 21:08:12 2007
From: metatracker at psf.upfronthosting.co.za (Dennis Allison)
Date: Wed, 19 Sep 2007 19:08:12 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <f74a6c2f0709191137j3a06c369o4725c860075a95f5@mail.gmail.com>
Message-ID: <Pine.LNX.4.44.0709191147370.4089-100000@shasta.stanford.edu>


Dennis Allison added the comment:

Paul, I was the source of the original problem.  I suspect that the module
that constructs the email message sent out to all of use that track bug   
reports does not construct the  From header in the proper form.                    

The mail reader that is failing is Pine.  It's an ascii reader, old and 
stable.

When I export some example headers I get: 

From: =?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=
        <report at bugs.python.org>
and

From: =?utf-8?q?=0A=09=09=09=09=09Mark_Dickinson=0A=09=09=09=09?=
        <report at bugs.python.org>

The header is supposed to be limited to 72 characters and folded if it is
long (RFC2882).  These headers looks to be too long and/or incorrectly 
folded.  I do not know how well Pine deals with the utf-8 but I suspect 
that the safe limit is the byte length of the header and not the 
character count.  

The problem seems to be the =0A element which will be decoded into a
newline character.  The =09 element is a tab which is likely to mess up 
formatting as well.

On Wed, 19 Sep 2007, Paul Dubois wrote:

> 
> Paul Dubois added the comment:
> 
> I examined his user record and do not see any extra spaces.
> 
> On 9/19/07, Guido van Rossum <metatracker at psf.upfronthosting.co.za> wrote:
> >
> >
> > Guido van Rossum added the comment:
> >
> > I pasted the headers from the example that Dennis mailed me into issue
> > 158.
> >
> > I also noted this in the new-bugs digest email. It seems to be a problem
> > only
> > with Jim Jewett:
> >
> > """
> > Message: 3
> > Date: Tue, 18 Sep 2007 20:22:53 -0000
> > From:                                   Jim
> > Jewett                                      <report at bugs.python.org>
> > Subject: [New-bugs-announce] [issue1177] urllib* 20x responses not OK?
> > To: new-bugs-announce at python.org
> > Message-ID:
> >         <1190146973.85.0.192058090901.issue1177 at psf.upfronthosting.co.za>
> > Content-Type: text/plain; charset=utf-8
> >
> >
> > New submission from
> >                                         Jim Jewett
> >                                 :
> >
> > Under the http protocol, any 2xx response is OK.
> > """
> >
> > Note the extra whitespace around Jim Jewett.  Perhaps something wacky is
> > going
> > on with Jim Jewett's user entry?  Other entries in the same digest don't
> > have this.
> >
> > Even if the RFC doesn't strictly disallow this behavior, I think we should
> > fix
> > it if we can.
> >
> > _______________________________________________________
> > Meta Tracker <metatracker at psf.upfronthosting.co.za>
> > <http://psf.upfronthosting.co.za/roundup/meta/issue147>
> > _______________________________________________________
> > _______________________________________________
> > Tracker-discuss mailing list
> > Tracker-discuss at python.org
> > http://mail.python.org/mailman/listinfo/tracker-discuss
> >
> 
> _______________________________________________________
> Meta Tracker <metatracker at psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue147>
> _______________________________________________________

--

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

From facundobatista at gmail.com  Wed Sep 19 22:41:49 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 19 Sep 2007 17:41:49 -0300
Subject: [Tracker-discuss] Python tickets summary
In-Reply-To: <e04bdf310709101325o1315adb0pebcb2f33d8313f35@mail.gmail.com>
References: <e04bdf310709101325o1315adb0pebcb2f33d8313f35@mail.gmail.com>
Message-ID: <e04bdf310709191341l289c034fjb4bf6d6b88ae4ef9@mail.gmail.com>

2007/9/10, Facundo Batista <facundobatista at gmail.com>:

> I modified my tool, whichs makes a summary of all the Python tickets
> (I moved the source where the info is taken from SF to our Roundup).

Based on an idea from Dennis Benzinger, now the temporal bars show the
moments where each comment was made, so it's easy to see the "rhythm"
of the ticket activity:

  http://www.taniquetil.com.ar/facundo/py_tickets.html

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From stephen at xemacs.org  Thu Sep 20 02:50:11 2007
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 20 Sep 2007 09:50:11 +0900
Subject: [Tracker-discuss] [issue158] multi-line From headers in
 outgoing mail break PINE
In-Reply-To: <18161.26973.687573.112085@montanaro.dyndns.org>
References: <1190223491.73.0.506725761765.issue158@psf.upfronthosting.co.za>
	<18161.26973.687573.112085@montanaro.dyndns.org>
Message-ID: <874phqdut8.fsf@uwakimon.sk.tsukuba.ac.jp>

skip at pobox.com writes:

 >     >> I received a complaint from Dennis Allison that the tracker sends
 >     >> email with multiline From headers, which (he thinks) are disallowed
 >     >> by the RFC and in any case cause problems with his PINE email reader
 > 
 >     Erik> Yes, this has been recorded as issue147 in the meta tracker. In the
 >     Erik> last message of this issue, I asked Dennis to provide an example
 >     Erik> message. I'm still waiting for a reply. 
 > 
 >     Erik> I'm also not convinced the from lines produced by roundup are
 >     Erik> forbidden by RFC.

Folding white space (ie, a CRLF pair followed by a sequence of SPACE
or TAB) is legal in certain places in the From header, including in
the contents of a quoted-string.

For example, both

From: "Stephen J. Turnbull" <stephen at xemacs.org>,
      Skip <skip at pobox.com>

and

From: "Jugemu Jugemu Gokonosurikire Kaijarisuigyono Suigyomatsu
       Unraimatsu Kuunerutokoroni Sumutokoro Yaburakoujino Burakouji
       Paipopaipopaipono Shuringan Shuringan'no Gurindai Gurindaino
       Ponpokopino Ponpokonano Choukyuumeino Chousuke"
      <longluckylife at rakugo.or.jp>

are legal from headers according to both RFC 822 (which is still STD
11) and RFC 2822 (the heir apparent).  Neither is in any way abusive.
The ones posted in issue147 were legal as posted (but I'd still LART
the MUA that produced it -- or the MTA that munged it -- a good one!)

 > Though to play nicely in the sandbox Roundup should be strict in what it
 > produces and Pine should be forgiving in what it accepts.
 > 
 > The From_ (as opposed to the From:) header of the message I'm responding to
 > is 96 characters long and was not wrapped.

From_ headers are added by the receiving MTA (per Unix mbox tradition,
AFAIK there is no formal standard for these), so clearly are not the
responsibility of Roundup.

 > Is it possible that Roundup is doing the right thing but that some
 > misbehaving MTA between Roundup and Dennis is doing the line
 > wrapping he sees?

This is quite possible, but it's likely that Roundup (or the Python
email module) is doing it.


From metatracker at psf.upfronthosting.co.za  Thu Sep 20 03:29:40 2007
From: metatracker at psf.upfronthosting.co.za (Will Maier)
Date: Thu, 20 Sep 2007 01:29:40 -0000
Subject: [Tracker-discuss] [issue123] Have issue ID search work from "search
	tracker" box
Message-ID: <20070920012937.GX8914@lass.lfod.us>


Will Maier added the comment:

With the attached patch[0], the quick search box behaves similarly
to the 'show issue' box -- if the requested ID does not exist, the
tracker returns a 404. If the requested issue does indeed exist, the
tracker will warp to its item page.

The implementation uses the same process already in templating.py to
identify the search text; then, if the text looks like an int, it's
assumed to be an issue id. It would probably be best to factor this
snippet into something more reusable, but I found no obvious place
to put it. I'd be happy to find a better place for it.

(Sorry for the delay; I finally got an internet connection at my
house yesterday, and so can start poking at the tracker.)

Thanks!

[0] mq patch against a mercurial tree synced to SVN rev 58212.

-- 

[Will Maier]-----------------[willmaier at ml1.net|http://www.lfod.us/]

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

_______________________________________________________
Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue123>
_______________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: issue125-quicksearch.patch
Url: http://mail.python.org/pipermail/tracker-discuss/attachments/20070920/299c7f2f/attachment.txt 

From metatracker at psf.upfronthosting.co.za  Fri Sep 21 09:13:34 2007
From: metatracker at psf.upfronthosting.co.za (Stephen Turnbull)
Date: Fri, 21 Sep 2007 07:13:34 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
Message-ID: <1190358814.51.0.218519189014.issue147@psf.upfronthosting.co.za>


Stephen Turnbull added the comment:

It occurs to me that this looks like a problem that has been reported on the GNU
Mailman lists.

The issue there happens because the Python email module likes to fold lines and
use a TAB character as the leading character on the second line.  Some MUAs may
add more space or a Re:, causing the header to fold at an earlier column.  This
then adds another TAB when it goes through Mailman, etc.

It might help (and certainly would aid readability until the full cause of the
expanding headers is understood) if instead of using TABs to creating folding
whitespace, the email module was told to use a SPACE for that.

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

From barry at python.org  Fri Sep 21 13:11:07 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 21 Sep 2007 07:11:07 -0400
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <1190358814.51.0.218519189014.issue147@psf.upfronthosting.co.za>
References: <1190358814.51.0.218519189014.issue147@psf.upfronthosting.co.za>
Message-ID: <CAC4CC59-BD28-40F0-A7C3-1D9D0CFF2962@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 21, 2007, at 3:13 AM, Stephen Turnbull wrote:

> It might help (and certainly would aid readability until the full  
> cause of the
> expanding headers is understood) if instead of using TABs to  
> creating folding
> whitespace, the email module was told to use a SPACE for that.

The email package in Python 3 is (I believe) much better at  
preserving existing folding whitespace according to the rues of RFC  
2822.  This code should be backported to Python 2 and a new version  
should be released.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRvOmzHEjvBPtnXfVAQLETAQArUNHFlTkzWmBBi6Hwmrp6oZ5dALQbXcs
XTdghck4uDWvsXSVF+ILIdxUlkfKIDWwD+6tf8uwTKj2jFBQ8bDgeWtmmdVMjTgB
xZEM8qdZ9TRmaVPAhf9nT+ueMK220D+blvhUyLeAH+1R15Bh1FdBEwNFmHM170zK
N23p4fEeNDw=
=I6lm
-----END PGP SIGNATURE-----

From metatracker at psf.upfronthosting.co.za  Fri Sep 21 13:13:38 2007
From: metatracker at psf.upfronthosting.co.za (Barry Warsaw)
Date: Fri, 21 Sep 2007 11:13:38 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <1190358814.51.0.218519189014.issue147@psf.upfronthosting.co.za>
Message-ID: <CAC4CC59-BD28-40F0-A7C3-1D9D0CFF2962@python.org>


Barry Warsaw added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 21, 2007, at 3:13 AM, Stephen Turnbull wrote:

> It might help (and certainly would aid readability until the full  
> cause of the
> expanding headers is understood) if instead of using TABs to  
> creating folding
> whitespace, the email module was told to use a SPACE for that.

The email package in Python 3 is (I believe) much better at  
preserving existing folding whitespace according to the rues of RFC  
2822.  This code should be backported to Python 2 and a new version  
should be released.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRvOmzHEjvBPtnXfVAQLETAQArUNHFlTkzWmBBi6Hwmrp6oZ5dALQbXcs
XTdghck4uDWvsXSVF+ILIdxUlkfKIDWwD+6tf8uwTKj2jFBQ8bDgeWtmmdVMjTgB
xZEM8qdZ9TRmaVPAhf9nT+ueMK220D+blvhUyLeAH+1R15Bh1FdBEwNFmHM170zK
N23p4fEeNDw=
=I6lm
-----END PGP SIGNATURE-----

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

From metatracker at psf.upfronthosting.co.za  Sat Sep 22 18:08:50 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Sep 2007 16:08:50 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
Message-ID: <1190477330.18.0.487721961996.issue147@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Dennis, can you kindly attach the *original*, *full* email that causes the
problem? The file "broken" that you attached cannot possibly be the message that
you have received. For one thing, it does not include any Received headers.

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

From metatracker at psf.upfronthosting.co.za  Sat Sep 22 22:46:42 2007
From: metatracker at psf.upfronthosting.co.za (Dennis Allison)
Date: Sat, 22 Sep 2007 20:46:42 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <1190477330.18.0.487721961996.issue147@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.44.0709221344020.15512-300000@shasta.stanford.edu>


Dennis Allison added the comment:

Martin, 
Here are two examples with headers. I have dropped my subscription to the 
bug list for the moment because of this.

On Sat, 22 Sep 2007, [utf-8] Martin v. L??wis wrote:

> 
> Martin v. L??wis added the comment:
> 
> Dennis, can you kindly attach the *original*, *full* email that causes the
> problem? The file "broken" that you attached cannot possibly be the message that
> you have received. For one thing, it does not include any Received headers.
> 
> _______________________________________________________
> Meta Tracker <metatracker at psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue147>
> _______________________________________________________
> 

--

_______________________________________________________
Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue147>
_______________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: example1
Url: http://mail.python.org/pipermail/tracker-discuss/attachments/20070922/f234bf1f/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: example2
Url: http://mail.python.org/pipermail/tracker-discuss/attachments/20070922/f234bf1f/attachment-0001.txt 

From metatracker at psf.upfronthosting.co.za  Sat Sep 22 23:40:30 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 22 Sep 2007 21:40:30 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
Message-ID: <1190497230.49.0.905090905731.issue147@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Dennis: unfortunately, these are still not the original messages. In example2,
the text "Your display is set for the "ISO-8859-1" character set." appears,
which was *not* in the original message. Please try to retrieve the original
message from disk, e.g. from an mbox file, in the hopes that your email reader
has not tampered with it yet (in case you are uncertain what the original text
is: it also should not say "Unable to print this part.")

I can't stress enough the importance of getting the *original*, *unmodified*,
*untampered*, *full* message that has been sent out to analyze the problem further.

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

From metatracker at psf.upfronthosting.co.za  Sun Sep 23 07:35:18 2007
From: metatracker at psf.upfronthosting.co.za (Dennis Allison)
Date: Sun, 23 Sep 2007 05:35:18 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
In-Reply-To: <1190497230.49.0.905090905731.issue147@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.44.0709222156210.15512-100000@shasta.stanford.edu>


Dennis Allison added the comment:

These examples were pulled out of the mbox file directly using vi.  Since 
I copied them out, I have deleted them and unsubscribed from the list 
while this problem is being resolved.  I can resubscribe if necessary.

The Stanford mail system has a mail hub that gathers messages and then
redistributes them.  In this case, the mail went to mx1, one of the mail
hubs, then to the leland cluster of machines. On those machines I have a
.forward set to forward the mail to shasta.stanford.edu, a virtual server
running Linux using Xen or an equivalent.

At each stage, it's likely that some headers are appended and some 
translation may occur, but it is unlikely that anything is done to the 
From: header which appears to be what is broken.

When Pine grabs the From: header and tries to display it, the header 
behaves as if it has CRLFs in it.  The GUI is ncurses based, I believe, 
and so gets quite confused overwriting lines here and there and generally 
making navigation in the index complicated.

From: =?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=
        <report at bugs.python.org>

ends up being displayed as three lines.   

The From: header seems to be the only thing that is mucked up.

What I suspect is happending is that the header is in UTF-8 and the
charset information is added at some point in the mail transmission. =0A
is a newline, =09 is a tab, The various "?' characters are out of range
ASCII characters, probably utf-8 escapes which are inserted at some point
(possibly by Pine) when mapping utf-8 to ASCII.  Pine's support for
unicode is likely to be limited to doing a best guess remap to ASCII.

Applying the folding rules to unfold, the two lines in the From: header 
are joined, then the characters are translated from the encoded to 
unencoded form giving (modulo some special characters):

[utf-8]\n\t\t\t\tHirokazu_Yamamoto\n\t\t\t\t<report at bugs.python.org>

which would display as
-------------------
[utf-8]
				Hirokazu_Yamamoto
				<report at bugs.pythong.org>
--------------------
overwriting lines following it in the ncurses display.

I believe that the program that generates the email does not construct a 
proper From: header.

On Sat, 22 Sep 2007, [utf-8] Martin v. L??wis wrote:

> 
> Martin v. L??wis added the comment:
> 
> Dennis: unfortunately, these are still not the original messages. In example2,
> the text "Your display is set for the "ISO-8859-1" character set." appears,
> which was *not* in the original message. Please try to retrieve the original
> message from disk, e.g. from an mbox file, in the hopes that your email reader
> has not tampered with it yet (in case you are uncertain what the original text
> is: it also should not say "Unable to print this part.")
> 
> I can't stress enough the importance of getting the *original*, *unmodified*,
> *untampered*, *full* message that has been sent out to analyze the problem further.
> 
> _______________________________________________________
> Meta Tracker <metatracker at psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue147>
> _______________________________________________________
> 

--

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

From metatracker at psf.upfronthosting.co.za  Sun Sep 23 08:44:11 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 23 Sep 2007 06:44:11 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
Message-ID: <1190529851.33.0.896383185823.issue147@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I think I have a theory what's happening. It seems that the name of the roundup
user (i.e. "Mark Dickinson") has leading and trailing tabs and line breaks in
the data base. In the display of the user data, e.g. in

http://bugs.python.org/user1118

it's not clearly visible, but if you look at the HTML code, you see that the
value= field has such extra white space. That would explain that the From: field
reportedly reads

=?utf-8?q?=0A=09=09=09=09=09Mark_Dickinson=0A=09=09=09=09?=

and that would explain that Dennis sees corrupted display - it would then have
nothing to do with the line length, or whether or not the From: field is broken
into multiple lines in the raw message.

Tentatively assigning this to Paul, but anybody with access to the database
could really fix this. I recommend to change the database directly, rather 
than going through an API that would leave log entries. I'll attach a script
that performs the fixing.

----------
assignedto:  -> dubois
nosy: +dubois, forsberg
priority: bug -> urgent

_______________________________________________________
Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue147>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixuser.py
Type: application/x-python
Size: 462 bytes
Desc: not available
Url : http://mail.python.org/pipermail/tracker-discuss/attachments/20070923/ad97a34b/attachment.bin 

From metatracker at psf.upfronthosting.co.za  Mon Sep 24 20:11:46 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Mon, 24 Sep 2007 18:11:46 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
Message-ID: <1190657506.3.0.303798416168.issue147@psf.upfronthosting.co.za>


Erik Forsberg added the comment:

I've now edited the user, via the web interface. I first removed the last 'd' in
the username, then pressed save, and then added it again. I think that helped,
at least it looks so checking the object in SQL.

I guess there should be a check for extra whitespace around the username in a
reactor or in roundup core.

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 24 20:20:55 2007
From: metatracker at psf.upfronthosting.co.za (Paul Dubois)
Date: Mon, 24 Sep 2007 18:20:55 -0000
Subject: [Tracker-discuss] [issue150] Add a 2to3 component
Message-ID: <1190658055.14.0.38686473028.issue150@psf.upfronthosting.co.za>


Paul Dubois added the comment:

Added auditor 'audit2to3', tested on an existing issue and on a new issue. Seems
to work. To change name of the person who will get the assignment, edit auditor
lines that set 'theMan'.

----------
nosy: +gbrandl
status: chatting -> resolved

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 24 20:57:47 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Mon, 24 Sep 2007 18:57:47 -0000
Subject: [Tracker-discuss] [issue123] Have issue ID search work from "search
	tracker" box
Message-ID: <1190660267.2.0.176663988024.issue123@psf.upfronthosting.co.za>


Erik Forsberg added the comment:

Hmm.. an alternative implementation, that would not require changes to roundup
core, would be to add a new action by use of the extensions mechanism, and then
let this action try to "intify" the search, passing the result to the real
search action. The modified register action in extensions/timestamp.py might
serve as inspiration.

On the other hand, your solution might be a good default behaviour for roundup -
you could ask on the roundup-users list for opinions. 

(I'm also sorry for the delay - busy week..)

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 24 21:20:59 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Mon, 24 Sep 2007 19:20:59 -0000
Subject: [Tracker-discuss] [issue141] Should send email on assignment
Message-ID: <1190661659.61.0.165105712699.issue141@psf.upfronthosting.co.za>


Erik Forsberg added the comment:

I intend to solve this by modifying the detectors that send mail so that they
send mail even on property-only changes, to all members of the nosy list. This
will make sure a mail is sent to the assignee when the assignee is assigned.

This might take a week or so.

We all know that Paul will now start screaming and kicking, but I'll just ignore
that as I believe this is the right way for a public tracker to behave.

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

From metatracker at psf.upfronthosting.co.za  Mon Sep 24 21:50:29 2007
From: metatracker at psf.upfronthosting.co.za (Paul Dubois)
Date: Mon, 24 Sep 2007 19:50:29 -0000
Subject: [Tracker-discuss] [issue141] Should send email on assignment
In-Reply-To: <1190661659.61.0.165105712699.issue141@psf.upfronthosting.co.za>
Message-ID: <f74a6c2f0709241250y3644127fv97eea0881b200af9@mail.gmail.com>


Paul Dubois added the comment:

Paul has experience with intellectuals who have beliefs but no experience,
and the many wonderful things that has brought to the world. He has learned
not to scream. (:->

Seriously, I have no problem with this at this point, but note that the bad
effect of something that increases mail is hard to measure, consisting of a
numbing effect that causes mail to be ignored.

On 9/24/07, Erik Forsberg <metatracker at psf.upfronthosting.co.za> wrote:
>
>
> Erik Forsberg added the comment:
>
> I intend to solve this by modifying the detectors that send mail so that
> they
> send mail even on property-only changes, to all members of the nosy list.
> This
> will make sure a mail is sent to the assignee when the assignee is
> assigned.
>
> This might take a week or so.
>
> We all know that Paul will now start screaming and kicking, but I'll just
> ignore
> that as I believe this is the right way for a public tracker to behave.
>
> _______________________________________________________
> Meta Tracker <metatracker at psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue141>
> _______________________________________________________
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

_______________________________________________________
Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue141>
_______________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20070924/34ae1998/attachment.htm 

From metatracker at psf.upfronthosting.co.za  Mon Sep 24 22:04:12 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Sep 2007 20:04:12 -0000
Subject: [Tracker-discuss] [issue147] Current email headers corrupt mail
	reader display
Message-ID: <1190664252.82.0.223028158757.issue147@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

There are many more users affected: Tim Cera, Brian Mansell, Ondra Krajicek, ...
in total several dozens (or perhaps hundreds). Editing them manually is not
feasible; I presume this problem was introduced during the import.

----------
status: done-cbb -> chatting

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

From amk at amk.ca  Tue Sep 25 02:13:48 2007
From: amk at amk.ca (A.M. Kuchling)
Date: Mon, 24 Sep 2007 20:13:48 -0400
Subject: [Tracker-discuss] Obtaining names of bug/patch submitters
Message-ID: <20070925001348.GA11061@mac.local>

I try to credit the submitters of patches in the "what's new"
document.  Roundup accepts a 'name' field as part of the user's
profile, but it seems to always display the login name (akuchling and
not A.M. Kuchling).  How do I view the name of a particular user?

--amk

From metatracker at psf.upfronthosting.co.za  Tue Sep 25 02:35:23 2007
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Tue, 25 Sep 2007 00:35:23 -0000
Subject: [Tracker-discuss] [issue159] Creating multiple queries with same
	name should overwrite
Message-ID: <1190680523.3.0.864241878408.issue159@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

I was composing a search by successively approximating the
desired result.  I filled in the query name field.  Every
time I searched it created a new query with the same name.
I think that (at least by default), reusing the same name
should cause any existing query with that name to be
overwritten by the new query.  Having multiple queries with
the same name makes little sense since you can't distinguish
one from another.

Skip

----------
messages: 808
nosy: montanaro
priority: feature
status: unread
title: Creating multiple queries with same name should overwrite

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 25 02:40:23 2007
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Tue, 25 Sep 2007 00:40:23 -0000
Subject: [Tracker-discuss] [issue160] Can't make a query private once it's
	been made public
Message-ID: <1190680823.03.0.264914740135.issue160@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

I have this "nosy" query.  I visited by query edit page
and made the mistake of making it not private to me.  Now
I can't make it private anymore or delete it.  It shouldn't
really be public as it shows those issues for which I
am on the nosy list and not likely to be all that interesting
to anyone else.

Skip

----------
messages: 809
nosy: montanaro
priority: bug
status: unread
title: Can't make a query private once it's been made public

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 25 02:41:55 2007
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Tue, 25 Sep 2007 00:41:55 -0000
Subject: [Tracker-discuss] [issue161] Retiring a query should remove it
Message-ID: <1190680915.28.0.44802944461.issue161@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

What is the use of leaving a query in the display after it's
been removed (and thus marked as "retired" on the query
edit page)?

Skip

----------
messages: 810
nosy: montanaro
priority: bug
status: unread
title: Retiring a query should remove it

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 25 05:31:06 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 25 Sep 2007 03:31:06 -0000
Subject: [Tracker-discuss] [issue160] Can't make a query private once it's
	been made public
Message-ID: <1190691066.15.0.104681092353.issue160@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I deleted that query.

----------
priority: bug -> urgent
status: unread -> resolved

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 25 05:36:41 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 25 Sep 2007 03:36:41 -0000
Subject: [Tracker-discuss] [issue161] Retiring a query should remove it
Message-ID: <1190691401.96.0.407868818903.issue161@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

That's standard roundup behavior. Roundup *never* deletes anything, it only ever
marks things as "retired". "Retired" things are not found through searches,
don't show up in drop-down boxes etc, but they remain in the places where they
are referred to already. So once you remove the query from "your queries", and
it is retired, you won't be able to add it back.

I'm closing this as resolved, since the issue was a question only, and I believe
I provided the correct answer. If you think the answer was incorrect, or you
have a further issue with it, feel free to reopen it.

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

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

From martin at v.loewis.de  Tue Sep 25 07:00:43 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 25 Sep 2007 07:00:43 +0200
Subject: [Tracker-discuss] Obtaining names of bug/patch submitters
In-Reply-To: <20070925001348.GA11061@mac.local>
References: <20070925001348.GA11061@mac.local>
Message-ID: <46F895FB.7000709@v.loewis.de>

> I try to credit the submitters of patches in the "what's new"
> document.  Roundup accepts a 'name' field as part of the user's
> profile, but it seems to always display the login name (akuchling and
> not A.M. Kuchling).  How do I view the name of a particular user?

In

http://psf.upfronthosting.co.za/roundup/meta/issue133

display of the real name is requested; this has not been implemented
yet.

You should be able to find the real name through

http://bugs.python.org/user

Type the username in search, and it should bring up the user's record.

I say "should" because it might be that I can do this only because
I also have the Coordinator role; if you find it doesn't work for
you and you also also want the Coordinator role, please let me know.

Regards,
Martin

From amk at amk.ca  Tue Sep 25 15:23:21 2007
From: amk at amk.ca (A.M. Kuchling)
Date: Tue, 25 Sep 2007 09:23:21 -0400
Subject: [Tracker-discuss] Obtaining names of bug/patch submitters
In-Reply-To: <46F895FB.7000709@v.loewis.de>
References: <20070925001348.GA11061@mac.local> <46F895FB.7000709@v.loewis.de>
Message-ID: <20070925132321.GA15399@amk-desktop.matrixgroup.net>

On Tue, Sep 25, 2007 at 07:00:43AM +0200, "Martin v. L?wis" wrote:
> I say "should" because it might be that I can do this only because
> I also have the Coordinator role; if you find it doesn't work for
> you and you also also want the Coordinator role, please let me know.

Thanks!  This works fine for me; the Coordinator role doesn't seem to
be necessary.

--amk

From metatracker at psf.upfronthosting.co.za  Tue Sep 25 15:26:37 2007
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Tue, 25 Sep 2007 13:26:37 -0000
Subject: [Tracker-discuss] [issue160] Can't make a query private once it's
	been made public
In-Reply-To: <1190691066.15.0.104681092353.issue160@psf.upfronthosting.co.za>
Message-ID: <18169.3209.20321.976945@montanaro.dyndns.org>


Skip Montanaro added the comment:

Martin> I deleted that query.

Thanks Martin.  That solves the immediate problem.  Is this a bug in Roundup
or in our specific tracker?  If it's a Roundup bug I'll report it there.  If
not we should reopen this issue.

Skip

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

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 25 18:08:46 2007
From: metatracker at psf.upfronthosting.co.za (Erik Forsberg)
Date: Tue, 25 Sep 2007 16:08:46 -0000
Subject: [Tracker-discuss] [issue160] Can't make a query private once it's
	been made public
In-Reply-To: <18169.3209.20321.976945@montanaro.dyndns.org>
Message-ID: <20070925180837.02749331@uterus>


Erik Forsberg added the comment:

On Tue, 25 Sep 2007 13:26:37 -0000
Skip Montanaro <metatracker at psf.upfronthosting.co.za> wrote:

> 
> Skip Montanaro added the comment:
> 
> Martin> I deleted that query.
> 
> Thanks Martin.  That solves the immediate problem.  Is this a bug in
> Roundup or in our specific tracker?  If it's a Roundup bug I'll
> report it there.  If not we should reopen this issue.

It's a roundup bug, and I think a saw a checkin to fix it the other
day, so it's probably fixed in CVS.

\EF
-- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9

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

From metatracker at psf.upfronthosting.co.za  Tue Sep 25 21:01:33 2007
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 25 Sep 2007 19:01:33 -0000
Subject: [Tracker-discuss] [issue160] Can't make a query private once it's
	been made public
Message-ID: <1190746892.99.0.52970834518.issue160@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I'm not so sure there is a bug at all. Once you made a query public, you
*cannot* delete it anymore, since somebody else may be using it.

----------
priority: urgent -> bug

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

From metatracker at psf.upfronthosting.co.za  Thu Sep 27 19:42:32 2007
From: metatracker at psf.upfronthosting.co.za (Paul Dubois)
Date: Thu, 27 Sep 2007 17:42:32 -0000
Subject: [Tracker-discuss] [issue150] Add a 2to3 component
Message-ID: <1190914952.09.0.378960797852.issue150@psf.upfronthosting.co.za>


Paul Dubois added the comment:

I fixed an error in the 2to3 auditor. You can ignore the tracebacks sent to
roundup-admin this morning.

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

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