Might depend on the sender. It has worked for me before.
Try this.
dw
On 3/21/2017 9:48 PM, Liu Hao wrote:
On 2017/3/22 4:57, Mateusz Mikuła wrote:
Sorry for the delay but I spent almost whole day in college.
Thank you for adding it, here comes small patch to test it.
I got the attachme
On 2017/3/22 4:57, Mateusz Mikuła wrote:
> Sorry for the delay but I spent almost whole day in college.
>
> Thank you for adding it, here comes small patch to test it.
I got the attachment but its Content-Type said plain text. Is this
normal behavior?
* * * * *
Content-Type: text/plain; charset=
Sorry for the delay but I spent almost whole day in college.
Thank you for adding it, here comes small patch to test it.
-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const
LPVOID' for VerQueryValue
Date: Mon, 20 Mar 2017 21:19:0
> We have text/x-patch, not application/x-patch. I don't understand the
> difference. Do you?
The problem with mime types is that anyone can use any string they want
and it means whatever they want it to mean. Of course to be "generally
useful" the meaning must be "generally agreed upon."
I
On Mon, Mar 20, 2017 at 9:42 PM, David Wohlferd wrote:
>
>> I don't think application/octet-stream is something we would want to
>> enable. Doesn't that sound like something that would be abused?
>
> I suppose application/octet-stream might be useful if we commonly worked
> with binary files for
> I don't think application/octet-stream is something we would want to
> enable. Doesn't that sound like something that would be abused?
I suppose application/octet-stream might be useful if we commonly worked
with binary files for patches. But I agree with you, don't do it.
A google search t
On Mon, Mar 20, 2017 at 9:34 AM, Mateusz Mikuła wrote:
> It explains why my patches created with `git format-patch` couldn't
> make it.
>
> Their mime type is `text/x-diff`.
I added text/x-diff to the list. Give it a shot.
---
On Mon, Mar 20, 2017 at 9:23 AM, David Grayson wrote:
> Oops, that was the problem then. It was "application/octet-stream" because
> I was constructing the email with the Ruby "mail" gem that doesn't
> recognize ".patch" files as being text. I'll use better methods in the
> future.
I don't thin
I checked it with `file --mime-type something.patch` in MSYS2 shell;
something.patch was generated by git.
-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const
LPVOID' for VerQueryValue
Date: Mon, 20 Mar 2017 23:15:21 +0800
To: Mingw-
On 2017/3/20 22:34, Mateusz Mikuła wrote:
> It explains why my patches created with `git format-patch` couldn't
> make it.
>
> Their mime type is `text/x-diff`.
Isn't it our mail clients that guess MIME types of attachments? The diff
file doesn't have any MIME type information stored with it.
--
It explains why my patches created with `git format-patch` couldn't
make it.
Their mime type is `text/x-diff`.
-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const
LPVOID' for VerQueryValue
Date: Mon, 20 Mar 2017 00:13:44 -050
Oops, that was the problem then. It was "application/octet-stream" because
I was constructing the email with the Ruby "mail" gem that doesn't
recognize ".patch" files as being text. I'll use better methods in the
future.
--David
On Sun, Mar 19, 2017 at 10:13 PM, NightStrike wrote:
> Do you kn
Do you know what content type you attached as? We have to explicitly
allow each type. The current list is:
application/pgp-signature
multipart/mixed
multipart/alternative
multipart/signed
text/plain
text/x-patch
If the content type is left unspecified, then the attachment is
deleted. I can add
NightStrike,
The mailing list swallowed the patch in the message I sent on March 16th.
I can see in GMail that I did have a patch attached to my message, but no
attachment is visible in the archive here:
https://sourceforge.net/p/mingw-w64/mailman/message/35729302/
--David Grayson
On Sun, Mar 1
On Mar 16, 2017 1:40 PM, "Liu Hao" wrote:
On 2017/3/17 0:51, David Grayson wrote:
> I was trying to compile Qt and I ran into an error because Qt is
> passing a const pointer to the first argument of VerQueryValue, which
> is not properly marked as const in the mingw-w64 header files. This
> pat
On 2017/3/17 0:51, David Grayson wrote:
> I was trying to compile Qt and I ran into an error because Qt is
> passing a const pointer to the first argument of VerQueryValue, which
> is not properly marked as const in the mingw-w64 header files. This
> patch fixes that.
Please send the patch both in
I was trying to compile Qt and I ran into an error because Qt is
passing a const pointer to the first argument of VerQueryValue, which
is not properly marked as const in the mingw-w64 header files. This
patch fixes that.
Apparently "const LPVOID" is different from "LPCVOID". You can see
the diff
17 matches
Mail list logo
