Hello Nis, On Tue, Feb 12, 2019 at 11:46:59PM +0100, Nis Martensen wrote: > Your mail should probably not have gone to debian bug #853915 > (python-debianbts retrieving undecoded text), but to #888988 (reportbug > sending in base64).
Sorry, taking the right bug in CC now.
> Anyway some comments below.
>
> On 9 Jan 2019 Helge Kreutzmann wrote:
> > I'm often hit by this bug, as I have several Debian instances where no
> > e-mail
> > conection is available. So I save the report of reportbug, transfer
> > the file to another machine and then I need to massage the e-mail to
> > get it accepted (currently removing all but the base64 part, running
> > "base64 -d " on the remaining part and inserting the output back into
> > the original mail. I'm probably going to skript it soon.
> >
> > So it would be very helpful for me if either temporarily stored
> > e-mails of reportbug are not stored in base64 format at all or at
> > least configurable, so that I can always see the contents after "mutt
> > -H reportbug …".
>
> In my tests mutt was able to deal with these base64-encoded files just
> fine, no manual conversion was needed. I've tested with mutt both in
> stable and unstable. You seem to describe that it does not work for you?
Yes. I was an older mutt, but I can do tests with a more recent one,
maybe this bug is fixed.
> One (other) way to automate the conversion from base64 to 8bit is the
> "reformime" tool from the maildrop package:
> $ reformime -u < /tmp/reportbug-<whateverfilename>
> should output the text in readable form.
Yes, thanks for the pointer, this works nicely.
> > Since all e-mails sent by mutt at least arrived in the BTS without
> > problems I do not see the point of encoding e-mails in base64 at all.
> > (But there may be use cases, so makeing this configurable would
> > probably be the best option).
>
> reportbug is using python's email package for setting up its messages.
> reportbug does not actually want to deal with such encoding issues, but
> wants to rely on the email package for making the proper decisions.
> Making this configurable is not a desirable step from reportbug's
> perspective, as it would make the code more complex for no significant gain.
I see.
> > Having the BTS accept the base64 encoded e-mails is suboptimal, as I
> > can no longer read the e-mails in mutt and sometimes I notice things
> > just before sending, prompting me to update the report in mutt.
>
> I suspect that the BTS may already be able to deal with base64-encoded
> mail bodies, because not everybody who sends control messages to the BTS
> uses a mailer where they can control the content transfer encoding. But
> I haven't checked. I'm planning to run a few tests to check this soon.
Thanks.
Greetings
Helge
--
Dr. Helge Kreutzmann [email protected]
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: Digital signature
