Dear BTS team, when I have forwarded a bug report to an upstream bug tracker, mailing list or forum and I want to document this in the Debian BTS with the "forward" tag, I often get replies like "Processed with 3 errors" back from the BTS. The reason is that my mail client breaks lines if they are longer than 70 characters. Well, the string "forwarded 123456 " alone is 17 characters long and URLs pointing to forums, mailing lists or bug trackers are often long enough to case my mail client to break lines then. The BTS-control then receives a mail with an incomplete "forwarded" comand in the first line, an unkown command (i.e. the URL) in the second line and thus throws errors here. I suggest that if the "forwarded" command is incomplete on its line and the next line does not contain another valid command, than the next line should be concatenated to the line containing the "forwarded" command. Maybe this should also be applied to other commends which may accept longer strings as parameters. - Fabian PS: You could of course tell me to "fix" my mail client, but I find it very convenient to have automatic line breaks in mails (it improves the readability a lot) and it never causes problems, except for this special case of Debian BTS-control handling. ;)
severity 568230 wishlist tag 568230 wontfix reassign 568230 debbugs thanks If your mail client is unable to send messages with long lines, your mail client is fundamentally broken. If you don't want to fix your MUA, use the bts command line tools instead. Don Armstrong
Could this sentiment probably get reconsidered? I filed this bug more than 12 years ago, and just today I got bitten by this again when I sent a mail to the Debian BTS containing a "forwarded" control command. I have sent this from a Windows PC using the roundcube webmail client, which apparently also insists to add line breaks to keep a certain line length in text-only mails. So, this time I had no chance to use the "bts" command lne tool, and I find it anachronistic to refer people to use such tools in times when e-mails are sent via webmailers or mobile phones. Thanks, - Fabian
The problem is that there is no easy way for the bug tracking system to reliably know whether the next line is part of the previous line or a new line. For example if you wanted to retitle a bug like so: retitle 1234 this bug demonstrates broken forwarded data: forwarded 1235 https://foo should that look like this: retitle 1234 this bug demonstrates broken forwarded data: forwarded 1235 https://foo We probably could support a line continuation escape (like \), but that would require a bit of a change management process to enable. Eventually we'll get around to supporting modifying things using a UI to generate mail, which will fix this problem. [Maybe in another 10 years at this rate?]