10:30 a.m.
================================================================
Dear Bug Team!
On Sep 29 I sent a bug report using report-xemacs-bug, and the day
after I got a speedy and helpful response - thank you!
The strange thing is that on Oct 3, I received the attached message
from "XEmacs issue tracker" with totally confusing and non-helpful
contents. If I had not already received a response, I would have
thought that my bug report was delivered to /dev/null simply because
it wasn't already in the database...
Having an issue tracker is of course a good idea, but this one doesn't
seem to work, but only confuses the bug reporters, e.g. with
documentation of internal data structures of the tracker itself.
If this "issue tracker" is official XEmacs infrastructure, I think it
should be disabled and more thoroughly tested so that it works
together with the recommended way of reporting bugs, i.e.,
report-xemacs-bug, before being enabled again.
If the "issue tracker" is not official, but just some random user
scanning the xemacs-beta mailing list, I can only hope he/she reads
also this message and refrains from using the address
tracker(a)xemacs.org for his/her bogus messages.
(Since the issue tracker seems totally broken, I'm adressing this to
xemacs-beta(a)xemacs.org instead of tracker(a)xemacs.org. I apologise if
my choice is also broken...)
Cheers,
-- Bjorn
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux ke.mandrakesoft.com 2.4.18-21mdksmp #1 SMP Thu Jul 4 15:18:52 CEST 2002
i686 unknown unknown GNU/Linux
<#mml type=message/rfc822 disposition=inline>
X-From-Line: tracker(a)xemacs.org Fri Oct 03 17:51:21 2003
Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.253])
by aun.it.uu.se (8.12.8/8.12.8) with ESMTP id h9468Zd6028416
for <Bjorn.Victor(a)it.uu.se>; Sat, 4 Oct 2003 08:08:36 +0200 (MEST)
Received: from tleeps18.sk.tsukuba.ac.jp (tleeps18.sk.tsukuba.ac.jp [130.158.98.98])
by shako.sk.tsukuba.ac.jp (8.10.2+Sun/3.7W) with ESMTP id h9468XA15212
for <Bjorn.Victor(a)it.uu.se>; Sat, 4 Oct 2003 15:08:33 +0900 (JST)
Received: from localhost
([127.0.0.1] helo=tleeps18.sk.tsukuba.ac.jp ident=stephen)
by tleeps18.sk.tsukuba.ac.jp with esmtp (Exim 3.36 #1 (Debian))
id 1A5U5n-0001pE-00
for <Bjorn.Victor(a)it.uu.se>; Sat, 04 Oct 2003 02:51:51 +0900
X-Roundup-Loop: hello
Subject: Failed issue tracker submission
From: XEmacs issue tracker <tracker(a)xemacs.org>
To: Bjorn.Victor(a)it.uu.se
Date: Fri, 03 Oct 2003 17:51:21 +0000
Message-Id: <E1A5U5n-0001pE-00(a)tleeps18.sk.tsukuba.ac.jp>
Status: O
X-Content-Length: 9450
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Lines: 217
Xref: Nomen.it.uu.se mail.misc:11363
<#multipart type=mixed>
<#part type=text/plain charset="utf-8" nofile=yes>
I cannot match your message to a node in the database - you need to either
supply a full node identifier (with number, eg "[issue123]" or keep the
previous subject title intact so I can match that.
Subject was: "[Bug: 21.4.12] mail-extr uses defconst"
Mail Gateway Help
=================
Incoming messages are examined for multiple parts:
. In a multipart/mixed message or part, each subpart is extracted and
examined. The text/plain subparts are assembled to form the textual
body of the message, to be stored in the file associated with a "msg"
class node. Any parts of other types are each stored in separate files
and given "file" class nodes that are linked to the "msg" node.
. In a multipart/alternative message or part, we look for a text/plain
subpart and ignore the other parts.
Summary
-------
The "summary" property on message nodes is taken from the first non-quoting
section in the message body. The message body is divided into sections by
blank lines. Sections where the second and all subsequent lines begin with
a ">" or "|" character are considered "quoting sections".
The first line of
the first non-quoting section becomes the summary of the message.
Addresses
---------
All of the addresses in the To: and Cc: headers of the incoming message are
looked up among the user nodes, and the corresponding users are placed in
the "recipients" property on the new "msg" node. The address in the
From:
header similarly determines the "author" property of the new "msg"
node. The default handling for addresses that don't have corresponding
users is to create new users with no passwords and a username equal to the
address. (The web interface does not permit logins for users with no
passwords.) If we prefer to reject mail from outside sources, we can simply
register an auditor on the "user" class that prevents the creation of user
nodes with no passwords.
Actions
-------
The subject line of the incoming message is examined to determine whether
the message is an attempt to create a new item or to discuss an existing
item. A designator enclosed in square brackets is sought as the first thing
on the subject line (after skipping any "Fwd:" or "Re:" prefixes).
If an item designator (class name and id number) is found there, the newly
created "msg" node is added to the "messages" property for that item,
and
any new "file" nodes are added to the "files" property for the item.
If just an item class name is found there, we attempt to create a new item
of that class with its "messages" property initialized to contain the new
"msg" node and its "files" property initialized to contain any new
"file"
nodes.
Triggers
--------
Both cases may trigger detectors (in the first case we are calling the
set() method to add the message to the item's spool; in the second case we
are calling the create() method to create a new node). If an auditor raises
an exception, the original message is bounced back to the sender with the
explanatory message given in the exception.
$Id: mailgw.py,v 1.126 2003/06/25 08:02:51 neaj Exp $
<#part type=text/plain disposition=attachment nofile=yes description="Message you
sent">
Received: from gwyn.tux.org (localhost.localdomain [127.0.0.1])
by gwyn.tux.org (8.11.6p2/8.9.1) with ESMTP id h8TGY1v27978;
Mon, 29 Sep 2003 12:34:01 -0400
Received: (from turnbull＠localhost)
by gwyn.tux.org (8.11.6p2/8.9.1) id h8TGXOm27842
for xemacs-beta-mailman(a)xemacs.org; Mon, 29 Sep 2003 12:33:24 -0400
Received: (from mail＠localhost)
by gwyn.tux.org (8.11.6p2/8.9.1) id h8TGXNk27829
for turnbull(a)tux.org; Mon, 29 Sep 2003 12:33:23 -0400
Received: from meryl.it.uu.se (meryl.it.uu.se [130.238.12.42])
by gwyn.tux.org (8.11.6p2/8.9.1) with ESMTP id h8TGXIv27802
for <xemacs-beta(a)xemacs.org>; Mon, 29 Sep 2003 12:33:18 -0400
Received: from Nomine.it.uu.se (root(a)arachne.it.uu.se [130.238.12.8])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id SAA28585;
Mon, 29 Sep 2003 18:33:13 +0200 (MET DST)
Received: by Nomine.it.uu.se (Postfix, from userid 1020)
id 4D7FA902A2; Mon, 29 Sep 2003 18:33:13 +0200 (CEST)
From: Bjorn Victor <Bjorn.Victor(a)it.uu.se>
To: XEmacs Beta <xemacs-beta(a)xemacs.org>
Subject: [Bug: 21.4.12] mail-extr uses defconst
Message-Id: <20030929163313.4D7FA902A2(a)Nomine.it.uu.se>
Date: Mon, 29 Sep 2003 18:33:13 +0200 (CEST)
X-XEmacs-List: beta
X-Spam-Status: No, hits=-5.3 required=5.0
tests=BAYES_10
version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: xemacs-beta-admin(a)xemacs.org
Errors-To: xemacs-beta-admin(a)xemacs.org
X-BeenThere: xemacs-beta(a)xemacs.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:xemacs-beta-request＠xemacs.org?subject=help>
List-Post: <mailto:xemacs-beta＠xemacs.org>
List-Subscribe: <http://lists.xemacs.org/lists/listinfo/xemacs-beta>;,
<mailto:xemacs-beta-request＠xemacs.org?subject=subscribe>
List-Id: XEmacs Beta Testers <xemacs-beta.xemacs.org>
List-Unsubscribe: <http://lists.xemacs.org/lists/listinfo/xemacs-beta>;,
<mailto:xemacs-beta-request＠xemacs.org?subject=unsubscribe>
================================================================
Dear Bug Team!
The package mail-extr with its major function mail-extract-address-components,
is extremely useful for parsing mail addresses.
However, it has a major shortcoming: it doesn't parse addresses with
full-names starting (or ending) with non-ascii characters correctly,
such as
(mail-extract-address-components "Olov Ågren <foo(a)bar.se>")
=> ("Olov" "foo(a)bar.se")
In principle it is easy to fix, by setting mail-extr-first-letters and
mail-extr-last-letters to include these funny non-ascii letters, but
the patch is inconvenient because of the use of defconst in mail-extr.el.
In order to change the parsing, I not only need to set the constants
*after* loading the package, but I also need to set all constants
which depend on them - which are also defconst's. (These are
mail-extr-bad-dot-pattern, mail-extr-name-pattern,
mail-extr-initial-pattern, and mail-extr-normal-name-pattern).
Please consider changing mail-extr.el to use defvar instead of
defconst. This would make life easier for non-Americans.
Best regards,
--
Bjorn Victor Bjorn.Victor(a)it.uu.se
Dept. of Information Technology tel: +46 18 471 3169
Uppsala University mobile: +46 70 425 0239
Box 337 fax: +46 18 511925
S-751 05 Uppsala, SWEDEN web: http://user.it.uu.se/~victor
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux ke.mandrakesoft.com 2.4.18-21mdksmp #1 SMP Thu Jul 4 15:18:52 CEST 2002
i686 unknown unknown GNU/Linux
../../configure 'i386-mandrake-linux' '--prefix=/usr'
'--exec-prefix=/usr' '--package-path=//usr/share/xemacs/'
'--datadir=//usr/share' '--mandir=//usr/share/man/man0'
'--infodir=//usr/share/info' '--libdir=//usr/lib'
'--bindir=//usr/bin' '--infopath=//usr/share/info' '--with-gpm=no'
'--with-sound=none' '--with-pop' '--mail-locking=flock'
'--with-clash-detection' '--with-scrollbars=lucid'
'--with-menubars=lucid' '--with-xpm' '--with-xface'
'--with-png' '--with-jpeg' '--with-tiff' '--dynamic=yes'
'--with-ncurses' '--without-ldap' '--without-postgresql'
'--with-gpm=no' '--with-clash-detection' '--debug=no'
'--error-checking=none' '--prefix=/usr' '--exec-prefix=/usr'
'--with-x11' '--with-tty=yes' '--with-dialogs=athena'
'--with-widgets=athena' '--with-athena=3d' '--with-file-coding'
XEmacs 21.4.12 "Portable Code" configured for `i386-mandrake-linux'.
Compilation / Installation:
Source code location: /home/warly/rpm/BUILD/xemacs-21.4.12
Installation prefix: /usr
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -O2 -fomit-frame-pointer -pipe -march=i586
-mcpu=pentiumpro
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw3d
- Athena library to link: Xaw3d
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Databases:
Internationalization:
Compiling in support for file coding.
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "flock" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new portable dumper.
<#/multipart>
<#/mml>