Dear Robin,
in message 200705111804.30232.rgetz@blackfin.uclinux.org you wrote:
...
--- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -446,7 +446,7 @@ NXTARG: ; }
/* We're a bit of paranoid */ -#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) && !defined(__FreeBSD__)
^^^^^^^^ linewrap
+#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) && !defined(__FreeBSD__) && !defined(__APPLE__)
^^^^^^^^ linewrap
(void) fdatasync (ifd); #else (void) fsync (ifd); @@ -496,7 +496,7 @@ NXTARG: ; (void) munmap((void *)ptr, sbuf.st_size);
/* We're a bit of paranoid */ -#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) && !defined(__FreeBSD__)
^^^^^^^^ linewrap
+#if defined(_POSIX_SYNCHRONIZED_IO) && !defined(__sun__) && !defined(__FreeBSD__) && !defined(__APPLE__)
^^^^^^^^ linewrap
(void) fdatasync (ifd); #else (void) fsync (ifd);
...
How would you like to handle patches like this?
Well, of course we reject such a patch, as it does not apply to any code after being linewrapped by a broken / misconfigured mailer.
[But I guess this was not exactly your question :-) ]
Should an arch maintainer put it in their git tree, and push you the change - (even though it is common code) or is a patch to the mailing list the best way to handle?
The "official" approach is that ALL patches get posted to the mailing list, from where the respective custodian will pick it up. I intend to be the "ragpicker" to collect all items that are left. At the moment this still suffers from a working patch tracking system, but this is in the works (I know, I promised this too often already).
Best regards,
Wolfgang Denk