Public bug reported:
Some messages held on admindb cannot display correctly becase of partial
Unicode conversion error or
incomplete multi-byte character on mm_cfg.ADMINDB_PAGE_TEXT_LIMIT boundary.
Message character corruption has been occured in conditions below.
(1) Message charset/encoding i
** Branch linked: lp:mailman/2.1
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1415406
Title:
Message excerpt corruption on admindb Web UI
To manage notifications about this bug go to:
http
It is pretty difficult to make sample of a) case in my working environment, so
try to make it after b) case.
(One of case a) is known as a bogus iso-2022-jp message, which is one of reason
why Mr. Kikuchi was maintain his own local branch 2.1-japan.)
The attachment below is a sample of b) case,
Answer of #3 question:
I'm afraid if ADMINDB_PAGE_TEXT_LIMIT is much smaller than last line which goes
over the limit. I'm not sure that a 'format=flowed' message is decoded into one
line or not, but if it is, one line may much bigger than 1000 octets.
An alternate of this way of fix, changing me
Here is a sample of a) case.
sample-a-message.eml ... E-Mail message ((bogus) iso-2022-jp)
admindb-sample-a.html ... output of admindb Web UI with msgid (EUC-JP)
** Attachment added: "bug-1415406-sample-a.tar.gz"
https://bugs.launchpad.net/mailman/+bug/1415406/+attachment/4308721/+files/bug-1
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/fix-typo-in-nondigest-help into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/fix-typo-in-nondigest-help/+merge/285829
I think
Oviously first occurrence of 'regular_exclude_lists' in above description
sentence is a typo of 'regular_exlude_lists', auto spell correction system
corrected unexpectedly
--
https://code.launchpad.net/~futatuki/mailman/fix-typo-in-nondigest-help/+merge/285829
Your team Mailman Coders is req
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/286473
This is tentative Japanese
This bug still annoys Japanese users using ja_JP.UTF-8 locale on their
terminals, using euc-jp as list charset.
Fortunately, patch attached to comment #1 has been maintained on rpm sources
for fedora/RHEL
with additional patches, so I'm try to review them and working on a branch to
follow lates
** Branch linked: lp:mailman/2.1
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/558167
Title:
Use correct char set for command-line scripts
To manage notifications about this bug go to:
http
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-commandline-locale into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-commandline-locale/+merge/287282
This is a branch to fix
I have tested for each commands under bin, with -h option on both of
ja_JP.UTF-8 and ja_JP.eucJP terminal
environment by using LC_CTYPE and LC_MESSAGES environment variables. It works
fine.
Some commands still outputs untranslated messages, bin/b4b5-archfix and
bin/transcheck for example,
but I
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/303372
Update Japanese translation
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/304157
* Translate untranslated
Public bug reported:
If from_is_list feature is used, From: header's `realname' field is composed by
original realname
and translation of '%(realname)s via %(lrn)s' which may contain non-ascii
character.
The realname field is encoded before compose if nessesary, but translation part
is not.
So
Public bug reported:
Take a look at Mailman/Handlers/*.py, some of handlers seems to get translation
of server language
when mail list preferred language or user preferred language context is needed,
for lack of
set_language() (or set_translation). (Some handlers like Hold.py seems to
switch l
I'm sorry I had misunderstood about this mechanism.(My test case was
server's lang = sender's lang...)
This affects only when sender's preferred language and list's one is deffer and
some of headers
to be encoded with RFC 2047 manner. In this case, the translation is sender's
preferred language
My #1 patch try to adjust to charset/encoding list's preferred. But
after I realize my misunderstanding, it is better to adjust to sender's
preference. Anyways original senders `realname' charset and translation
of '%(realname)s via %(lrn)s' charset and list's preference can differ
each other.
**
Suppose sender is a member who set preference language ja, the list language is
french and original From: is 'From: =?UTF-8?B?5LqM5pyoIOmdluS7gQ==?=
'.
The translation of '%(realname)s via %(lrn)s' is taken from sender's language
context, ja, and its charset is euc-jp. The display name of origin
The lrn part is always us-ascii so it is vallid string in all encodings
that currently supported by Mailman.
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1643210
Title:
'from_is_list' does
It seems my patch in #2 also doesn't work if sender is not a list
member.
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1643210
Title:
'from_is_list' does not RFC2047 encode correctly when t
Thank you for your better fix. The fix in #10 also works fine for my
environment, except a small issue that it always encodes non-ascii to
UTF-8 even if sender's preferred language is same as list's but its
encoding is not UTF-8.
A test case.
list's language : fr (iso-8859-1)
sender's la
How about using "dn = str(Header(uvia, lcs))" instead of "dn = str(Header(uvia,
'utf-8'))" ?
As variable uvia is always unicode, there is no afraid to be mistaken
encodings. Header() treats charset parameter only for a hint, so it uses
'utf-8' as the fall back if it fail to encode to lcs.
test
test case 5.
list's language : fr (iso-8859-1)
sender's language : ja (euc-jp, out going messages are encoded to iso-2022-jp)
sender's display name: =?ISO-2022-JP?B?GyRCRnNMWkx3P04bKEI=?=
(results)
From: =?utf-8?b?5LqM5pyo6Z2W5LuBIHZpYSBNYWlsbWFuLXRlc3Q=?= <...>
is a rational results, I th
The only handler seems to be affected by this, CookeHeaders.py, had been
fixed with Bug #1643210.
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1643215
Title:
Some Handlers get translation o
Public bug reported:
On non ascii locale and DISABLE_COMMAND_LOCALE_CSET = yes,
bin/add_members get NameError because of uninitialized variable
Mailman.i18n._ctype_charset, which is used by Mailman.i18n.tolocale().
When DISABLE_COMMAND_LOCALE_CSET = yes, the function tolocale() is used
by bin/add
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/323207
Update Japanese translation
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/62
messages/ja/doc/Defaults.py.in
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/336404
Update Japanese translation for
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/336810
Update Japanese translation of
Public bug reported:
When I rebuild mailman.pot on lp:mailman/2.1 rev 1739, I found msgid added on
rev 1738 are corrupted.
This is caused by wrong _() usage.
** Affects: mailman
Importance: Undecided
Status: New
** Patch added: "subscribe.py.diff"
https://bugs.launchpad.net/bu
** Branch linked: lp:mailman/2.1
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1746189
Title:
wrong usage of _() in Mailman/Cgi/subscribe.py
To manage notifications about this bug go to:
ht
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/336861
Update Japanese message catalog
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-add-smtp-timeout into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-add-smtp-timeout/+merge/337353
This add a feature to
Thank you for your consideration for this issue.
> But there is an issue in how socket.timeout is handled in OutgoingRunner.
> Currently, OutgoingRunner treats all socket exceptions as a failure to
> connect. I think I'd want to catch socket.timeout in SMTPDirect, log the fact
> and then raise Som
Public bug reported:
When mm_cfg.DISABLE_COMMAND_LOCALE_CSET is false, bin/arch try to use
locale environment variables to determin which language/charset to use
for output messages, but only help message is affected by command line
locale, progression messages are still reported in lists
language
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Commit message:
ja translation update up to lp:mailman/2.1 rev. 1756, with some translation fix.
P.S. I want to internationalize message for note, added on rev 1753.
Though I have no
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-forbid-subscription into lp:mailman/2.1.
Commit message:
Add new value for MailList.subscribe_policy 4 as forbid
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net
Public bug reported:
Utils.banned_ip() introduced at rev 1762 has Python 2.7 dependency.
The feature allows to ommit positional argument specifiers of
str.format() appeared in Python 2.7.
** Affects: mailman
Importance: Undecided
Status: New
** Patch added: "banned_ip_py26_patch.t
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Commit message:
Update ja translation up to lp:mailman/2.1 rev 1766
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1.
Commit message:
Add '%(whence)s' to adminsubscribeack.txt and adminunsubscribeack.txt, for each
language.
Requested reviews:
Mailman Coders (mailman-co
Public bug reported:
If
* a list allows to use different language from list.preferred_language
* its policy requires admin approval for subscribes
* it set to send welcome message to new member
and admin approves subscription request of user who select his language
different from list's on Web U
This is caused by MailList.ApprovedAddMember(), which is not preserve
translation object on sending welcome message by using
Deliverer.SendSubscribeAck().
** Attachment added: "fix_admindb_result_patch.txt"
https://bugs.launchpad.net/mailman/+bug/1777222/+attachment/5153279/+files/fix_admindb
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1.
Commit message:
i18nize whence candidate message strings
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net
The proposal to merge
lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1
has been updated.
Description changed to:
This is a solution of problem left in mp+347992.
To mark whence messages for pygettext, I introduced dummy function i18n.D_(s)
returns s it self, and
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Commit message:
Update ja translation up to lp:mailman/2.1 rev.1776
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/enhance-i18n-list-overview into lp:mailman/2.1.
Commit message:
enhance i18n of listinfo/admin overview page
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki
Public bug reported:
In Mailman's web administrative interface, edithtml page saves en
language templates by using iso-8859-1 raw character if the template
uses html entity reference like " ".
For example, If "General list information page"
(templates/en/listinfo.html), which contains ", has be
I understand that your fix is to preserve character entity reference in
the text of TextArea through the post method and I made sure it have
been fixed in Rev 1788. Thank you.
I think one more problem about charset of query strings from Text or
TextArea which is not restricted to ascii text for al
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/edithtml-lang-select into lp:mailman/2.1.
Commit message:
Allow to edit templates other than lists preferred language
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net
I don't think it is a significant, as I mentioned comment #5 in last
sentence within the ()'s. So I won't open a bug for it. I'm sorry to
bother you.
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bu
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/edithtml-lang-select into lp:mailman/2.1.
Commit message:
fix layout problem of previous merge
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/edithtml
Oh, I'm very sorry, and thank you very much!
--
https://code.launchpad.net/~futatuki/mailman/edithtml-lang-select/+merge/349104
Your team Mailman Coders is requested to review the proposed merge of
lp:~futatuki/mailman/edithtml-lang-select into lp:mailman/2.1.
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/fix-Defaults.py into lp:mailman/2.1.
Commit message:
add description about IPv6 support of subscribe blocking to Defaults.py.in
fix a typo in comment of BLOCK_SPAMHAUS_LISTED_DBL_SUBSCRIBE
Requested reviews:
Mailman Coders
> I have mixed feelings about this MR.
I also have complex feelings about this.
> On the one hand, it is valid and represents a significant amount of work, and
> I hate to just ignore it.
>
> On the other, I have concerns. While it is true that the URL
> http://docs.python.org/library/stdtypes.
> (I don't think Python 2 library docs will not be removed even if their URL
> will be changed)
I'm sorry, I did't intend double negation, this was intended "(I don't think
Python 2 library docs will be removed soon, even if their URL will be changed)"
I'll stand by your choice even if it is not
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Commit message:
Update Japanese translations up to lp:mailman/2.1 rev 1817
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Commit message:
Update Japanese translation for new msgids added on r1820..1823
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net
Public bug reported:
MailList.AddMember crashes with UnicodeDecodeError if all conditions below are
satisfied.
* subscribe_policy of the lists is 1 or 3 (user confirmaion required)
* charset of preferred_language of the list is other than us-ascii
* translation for ' from %(remote)s' in the langu
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Commit message:
update Japanese translation for lp:mailman/2.1 rev 1825-1826
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net
Yasuhito FUTATSUKI at POEM has proposed merging
lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.
Commit message:
Update Japanese translation
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation
Public bug reported:
If the recipient mail address is too long, local part of VERP sender may
exceed 64 octet, the maximum total length of local-part provided by RFC
5321.
I think it should be checked in Mailman/Hander/SMTPDirect.py and fall
back to original envsender.
e.g. (not tested yet)
---
Thank you for the evaluation of this issue. I make sense.
However, FYI, here is an example that mail gateway to use this limitation.
(I've only heard, not tested by myself actually).
https://kc.mcafee.com/corporate/index?page=content&id=KB89997&locale=en_US
--
You received this bug notification
Public bug reported:
In Bouncer.Bouncer.__sendAdminBounceNotice(), default value of "did"
argment is evaluated only once on method definition and not evaluated at
runtime. This causes that the translation of 'disabled' is never used
other than default one.
A fix will be like a patch below (but no
64 matches
Mail list logo
