Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the SVN-Notify CPAN distribution.

Report information
The Basics
Id: 35884
Status: resolved
Priority: 0/
Queue: SVN-Notify

People
Owner: Nobody in particular
Requestors: matt [...] majides.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 2.75



Subject: footer message encoding support
Date: Thu, 15 May 2008 02:55:32 +0900
To: bug-SVN-Notify [...] rt.cpan.org
From: Matthew Romaine <matt [...] majides.com>
version: 2.7.3 issue (bug?): When using --footer ' message ' and message is a double- byte string (such as なるほど - Japanese), the footer message becomes garbled in the actual email. I've tried a variety of switches, encodings, and email applications and am thinking that whatever program is reading the original footer message from the post-commit file is somehow not using the correct encoding type when reading / parsing. has anyone successfully sent a multi-byte footer message? cheers, matt
Subject: Re: [rt.cpan.org #35884] footer message encoding support
Date: Fri, 16 May 2008 09:05:13 -0700
To: bug-SVN-Notify [...] rt.cpan.org
From: "David E. Wheeler" <david [...] kineticode.com>
On May 14, 2008, at 10:56, Matthew Romaine via RT wrote: Show quoted text
> version: 2.7.3 > > issue (bug?): When using --footer ' message ' and message is a double- > byte string (such as なるほど - Japanese), the footer message > becomes garbled in the actual email. > > I've tried a variety of switches, encodings, and email applications > and am thinking that whatever program is reading the original footer > message from the post-commit file is somehow not using the correct > encoding type when reading / parsing. > > has anyone successfully sent a multi-byte footer message?
Probably not. Quick list for my own reference of command-line arguments that need to be properly encoded: --add-header --subject-prefix --author-url --revision-url --ticket-map --header --footer I'll have to add tests for the encoding of these options and make sure they come out right. I think I would require that they be encoded in -- encoding. Best, David
Should be fixed now in 2.75. Be sure to use the encoding specified by the --encoding option (UTF-8 by default).