If there are non-ASCII characters in the context and when I download a
patch via the patch tracker web interface, it applies fine.

However, if I save the attachment from my mail client and then apply
that as the patch, then I get the bug in get_extra error message (see
http://wiki.darcs.net/Troubleshooting).

Furthermore, if I use my mail client to edit the MIME type of the
attachment, replacing usascii with utf-8, then the patch applies fine
again (to do this, I hit Ctrl-E in the mutt attachment viewer).

Looking at roundupdb.py I suspect there are some sort of not very nice
things happening in its send_message function... this bug needs further
investigation (preferably by a Pythonista with correctness geek tendencies).

I'm CC'ing Trent because I think he's been bitten by this too.

Eric Kow wrote:
> Looking at roundupdb.py I suspect there are some sort of not very
> nice things happening in its send_message function... this bug needs
> further investigation (preferably by a Pythonista with correctness
> geek tendencies).

Orthogonal to this, it would be nice if Darcs was a bit more helpful
about this particular case (i.e. suggest encoding issues to the user).

On Tue, Mar 30, 2010 at 10:11:33 +0000, Trent W. Buck wrote:
> Orthogonal to this, it would be nice if Darcs was a bit more helpful
> about this particular case (i.e. suggest encoding issues to the user).

Perhaps we could avoid the orthogonal issue altogether by fixing
issue1521 (patch bundle hash verification too late).  I'm guessing that
in the cases where this fails, we actually should have been getting
patch bundle hash errors...

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Testing a non-darcs attachment

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Attachments

• utf-8-file

The previous test shows that we get this annoying behaviour with regular
incoming email attachments, not necessarily darcs patches.

Test again this time with the attachment attached via the web interface.

If we have the same problem, I would say this isolates it to sending mail.

Attachments

• utf-8-file

If we attach files via the web interface, they are associated with the
type application/octet-stream which seems to completely avoid the issue

Mail sent to roundup-users (attached because SourceForge's fancy
archives seem can't seem to understand my mail from mutt :-/).

I guess we're waiting on roundup-users to respond.  Assigning to me so
we know who to follow up on

Attachments

• mail-to-roundup-users