Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
Hi Peff, On Thu, 3 Nov 2016, Jeff King wrote: > On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote: > > > This is missing a Content-Transfer-Encoding. I think the default is the > > traditional 7-bit ascii encoding, but your body has characters with the > > high-bit set (your UTF-8 bullet). > > > > Try adding: > > > > Content-Transfer-Encoding: 8bit > > > > I haven't seen this before, but I do recall that vger's MTA is very > > picky about this and wants to rewrite transfer-encodings, so it seems > > plausible. > > Technically, I think you'd also need a: > > MIME-Version: 1.0 > > header. That seems to have done the trick, thank you so much! Ciao, Dscho
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
On Thu, Nov 03, 2016 at 11:38:45AM -0400, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
>
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your UTF-8 bullet).
> >
> > Try adding:
> >
> > Content-Transfer-Encoding: 8bit
> >
> > I haven't seen this before, but I do recall that vger's MTA is very
> > picky about this and wants to rewrite transfer-encodings, so it seems
> > plausible.
>
> Technically, I think you'd also need a:
>
> MIME-Version: 1.0
>
> header. That being said, I just peeked at the send-email code and it
> looks like we try to add in these headers as necessary. It's possible
> there's a bug, though. What does "git send-email --dry-run" say is in
> the headers it sends out?
Answering my own question, it looks like send-email gets confused when
you give a content-type but no content-transfer-encoding. It wants to
fill in both or neither.
This probably helps:
diff --git a/git-send-email.perl b/git-send-email.perl
index da81be40c..784bb874b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1568,11 +1568,13 @@ foreach my $t (@files) {
push @cc, recipients_cmd("cc-cmd", "cc", $cc_cmd, $t)
if defined $cc_cmd && !$suppress_cc{'cccmd'};
- if ($broken_encoding{$t} && !$has_content_type) {
+ if ($broken_encoding{$t}) {
$xfer_encoding = '8bit' if not defined $xfer_encoding;
- $has_content_type = 1;
- push @xh, "Content-Type: text/plain;
charset=$auto_8bit_encoding";
- $body_encoding = $auto_8bit_encoding;
+ if (!$has_content_type) {
+ $has_content_type = 1;
+ push @xh, "Content-Type: text/plain;
charset=$auto_8bit_encoding";
+ $body_encoding = $auto_8bit_encoding;
+ }
}
if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
but I think there is more cleanup to handle this case (e.g., it
auto-guesses utf-8, but it should pull the value from the existing
content-type header).
-Peff
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote: > This is missing a Content-Transfer-Encoding. I think the default is the > traditional 7-bit ascii encoding, but your body has characters with the > high-bit set (your UTF-8 bullet). > > Try adding: > > Content-Transfer-Encoding: 8bit > > I haven't seen this before, but I do recall that vger's MTA is very > picky about this and wants to rewrite transfer-encodings, so it seems > plausible. Technically, I think you'd also need a: MIME-Version: 1.0 header. That being said, I just peeked at the send-email code and it looks like we try to add in these headers as necessary. It's possible there's a bug, though. What does "git send-email --dry-run" say is in the headers it sends out? -Peff
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
On Thu, Nov 03, 2016 at 04:15:05PM +0100, Johannes Schindelin wrote: > When it finally sent out the mail, and I thought everything was alright, > thinking that I could turn out for the night with a well-deserved drink, I > got this from vger.kernel.org: > > -- snip -- > SMTP error from remote server for TEXT command, host: vger.kernel.org > (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong MIME > labeling on 8-bit character texts. > -- snap -- > > Is there *anybody* who could give me a clue what this means? That's a new one for me. One guess, though... > For the record, I tried to use `git send-email` to send out the > announcement for the very first time, and the headers of the mbox file I > fed to that command read thusly: > > -- snip -- > From 2.10.2.windows.1 Mon Sep 17 00:00:00 2001 > From: Johannes Schindelin <johannes.schinde...@gmx.de> > Date: Wed, 02 Nov 2016 21:43:54 +0100 > To: git-for-wind...@googlegroups.com, git@vger.kernel.org > Subject: [ANNOUNCE] Git for Windows 2.10.2 > Content-Type: text/plain; charset=UTF-8 > Fcc: Sent > -- snap -- This is missing a Content-Transfer-Encoding. I think the default is the traditional 7-bit ascii encoding, but your body has characters with the high-bit set (your UTF-8 bullet). Try adding: Content-Transfer-Encoding: 8bit I haven't seen this before, but I do recall that vger's MTA is very picky about this and wants to rewrite transfer-encodings, so it seems plausible. -Peff
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
Johannes Schindelin <johannes.schinde...@gmx.de> writes: > thinking that I could turn out for the night with a well-deserved drink, I > got this from vger.kernel.org: > > -- snip -- > SMTP error from remote server for TEXT command, host: vger.kernel.org > (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong MIME > labeling on 8-bit character texts. > -- snap -- > > Is there *anybody* who could give me a clue what this means? Have you tried postmaster (at vger.kernel.org)? > > For the record, I tried to use `git send-email` to send out the > announcement for the very first time, and the headers of the mbox file I > fed to that command read thusly: > > -- snip -- > From 2.10.2.windows.1 Mon Sep 17 00:00:00 2001 > From: Johannes Schindelin <johannes.schinde...@gmx.de> > Date: Wed, 02 Nov 2016 21:43:54 +0100 > To: git-for-wind...@googlegroups.com, git@vger.kernel.org > Subject: [ANNOUNCE] Git for Windows 2.10.2 > Content-Type: text/plain; charset=UTF-8 > Fcc: Sent > -- snap -- > > The only problem I could *possibly* imagine is this UTF-8 bullet character > used in the enumerations in the mail body: > >• [...] The above header you showed says "Content-type: text/plain; charset=UTF-8" and I am hoping that this response to you will go out with that labelling back to vger, so we will hopefully see if that bullet is the culprit (I doubt it, though). I have no specific suspect at this point yet, other than "somebody that gets your message from send-email and passes to vger may be mangling it".
Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
Hi all, On Wed, 2 Nov 2016, Johannes Schindelin wrote: > Dear Git users, > > It is my pleasure to announce that Git for Windows 2.10.2 is available from: > > https://git-for-windows.github.io/ > [...] I originally intended this to be sent out at the same time as the announcement to the Git for Windows mailing list, finally in an automated manner so that I do not have to sit by the keyboard waiting for the uploads to finish (every new Git for Windows version is bundled into 9 different distributables that all want to be uploaded). But. When it finally sent out the mail, and I thought everything was alright, thinking that I could turn out for the night with a well-deserved drink, I got this from vger.kernel.org: -- snip -- SMTP error from remote server for TEXT command, host: vger.kernel.org (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong MIME labeling on 8-bit character texts. -- snap -- Is there *anybody* who could give me a clue what this means? For the record, I tried to use `git send-email` to send out the announcement for the very first time, and the headers of the mbox file I fed to that command read thusly: -- snip -- From 2.10.2.windows.1 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin <johannes.schinde...@gmx.de> Date: Wed, 02 Nov 2016 21:43:54 +0100 To: git-for-wind...@googlegroups.com, git@vger.kernel.org Subject: [ANNOUNCE] Git for Windows 2.10.2 Content-Type: text/plain; charset=UTF-8 Fcc: Sent -- snap -- The only problem I could *possibly* imagine is this UTF-8 bullet character used in the enumerations in the mail body: • [...] FWIW I like that bullet very much, even if it was not my doing, but w3m's rendering of the release notes [*1*]. I would really, really, *really* like to keep automating things to make the release engineering of Git for Windows more painless and boring, but this thing, this unhelpful vger error message is blocking me from doing so right now. Help, anyone? Thanks, Dscho Footnote *1*: The release notes are actually written using Markdown: https://github.com/git-for-windows/build-extra/blob/master/ReleaseNotes.md Those release notes are then rendered into HTML when releasing: https://github.com/git-for-windows/build-extra/blob/4d6097f/installer/release.sh#L86 They are also rendered into nice-looking ASCII via HTML by using both Markdown.perl and w3m, for use in the tag message: https://github.com/git-for-windows/build-extra/blob/4d6097f/please.sh#L1063-L1066 Same procedure is used again (to allow for very, very last-minute changes, such as the inclusion of Git Credential Manager v1.8.1 late yesterday, just because I still chased a bug introduced during the high-intensity installer patching bout last Tuesday) when announcing the new version: https://github.com/git-for-windows/build-extra/blob/4d6097f/please.sh#L1580-L1582
[ANNOUNCE] Git for Windows 2.10.2
Dear Git users, It is my pleasure to announce that Git for Windows 2.10.2 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.10.1(2) (October 13th 2016) Git for windows v2.10.1(2) was a MinGit-only release (i.e. there was no Git for windows installer for that version). New Features • Comes with Git v2.10.2. • Comes with Git Credential Manager v1.8.1. • Comes with cURL v7.51.0. • Git for Windows can now be built easily with Visual C++ 2015. • The installer now logs post-install errors more verbosely. • A new option asks the installer to skip installation if Git's files are in use. • A new option asks the installer to quietly skip downgrading Git for Windows, without indicating failure. • There is now an explicit option for symbolic link support, including a link to a more verbose explanation of the issue. Bug Fixes • when upgrading Git for Windows, SSH agent processes are now auto-terminated. • When trying to install/upgrade on a Windows version that is no longer supported, we now refuse to do so. Filename | SHA-256 | --- Git-2.10.2-64-bit.exe | 57238ebf86f8b51e32cab44bb91c8060e04774676b77b9fb92f78e7bc7e9a179 Git-2.10.2-32-bit.exe | 8b15054a4ea2dd5d2be0471a430d8ae7c772b94e1a1048221083a0040011011c PortableGit-2.10.2-64-bit.7z.exe | 101314826892480043d5b11989726fc8ee448991eb7b0a1c61aca751161bc15b PortableGit-2.10.2-32-bit.7z.exe | edc616817e96a6f15246bb0dd93c97e53d38d3b2a0b7375f26bd0bd082c41a73 MinGit-2.10.2-64-bit.zip | a10de5d5a8e71e207eff20d833ca56902a0668940e3def5f21d089e4f533ea40 MinGit-2.10.2-32-bit.zip | 2b191598bcb37565a2b80729ef8d00c03df02b75f6b9d012080c458999f89cc0 Git-2.10.2-64-bit.tar.bz2 | 7df449ac1813876b5a2e9215d94bca9458c2e0870c65e5b78bd7fc2a448a2a90 Git-2.10.2-32-bit.tar.bz2 | 3f8d0bebc53fabad863b8fe352a317fde61833efa4750f96656cf95017a621e8 Ciao, Johannes -- You received this message because you are subscribed to the Google Groups "git-for-windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windows+unsubscr...@googlegroups.com. To post to this group, send email to git-for-wind...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/20161102204358.6856-1-johannes.schindelin%40gmx.de. For more options, visit https://groups.google.com/d/optout.
