Message ID | cover.1693590982.git.sanastasio@raptorengineering.com (mailing list archive) |
---|---|
Headers | show |
Series | ppc: Enable full Xen build | expand |
On 01.09.2023 20:25, Shawn Anastasio wrote: > Hello all, > > This patch series performs all of the additions necessary to drop the > build overrides for PPC and enable the full Xen build. Except in cases > where compatibile implementations already exist (e.g. atomic.h and > bitops.h), the newly added definitions are simple, unimplemented stubs > that just call BUG_ON("unimplemented"). > > A few miscellaneous changes were also made to non-ppc code as well, > specifically a few missing header fixes in common. Nit: This is stale now, isn't it? But what I really wanted to mention here: Something's odd with how you sent this series. I received 0, 1, and 3 as one thread, 2 and 5 as another one, and 4 entirely standalone. The list archive [1] has all of 2, 4, and 5 as standalone mails. Another thing I wanted to ask: Would it be possible to configure whatever mail client you use for sending patches to send plain ASCII or UTF-8 text, not quoted-printable ones? At least for me, so far having shoveled in most of your patches, that encoding gets in the way of running a pre-apply-test with plain "patch --dry-run -F0" on all patches (from a script I use for committing). I can help myself with plain "git am", but sooner or later some patch will end up having a collision with something else having gone in, and then I'll need to manually clean up after the failed / incomplete command. Jan [1] https://lists.xen.org/archives/html/xen-devel/2023-09/threads.html
On 9/5/23 11:07 AM, Jan Beulich wrote: > On 01.09.2023 20:25, Shawn Anastasio wrote: >> Hello all, >> >> This patch series performs all of the additions necessary to drop the >> build overrides for PPC and enable the full Xen build. Except in cases >> where compatibile implementations already exist (e.g. atomic.h and >> bitops.h), the newly added definitions are simple, unimplemented stubs >> that just call BUG_ON("unimplemented"). >> >> A few miscellaneous changes were also made to non-ppc code as well, >> specifically a few missing header fixes in common. > > Nit: This is stale now, isn't it? Yes, I'll drop that sentence. > But what I really wanted to mention here: Something's odd with how you > sent this series. I received 0, 1, and 3 as one thread, 2 and 5 as > another one, and 4 entirely standalone. The list archive [1] has all of > 2, 4, and 5 as standalone mails. > I'm also seeing this in my own inbox -- I'm not sure what happened here since I used the same exact git send-email invocation that I used last time. > Another thing I wanted to ask: Would it be possible to configure > whatever mail client you use for sending patches to send plain ASCII or > UTF-8 text, not quoted-printable ones? At least for me, so far having > shoveled in most of your patches, that encoding gets in the way of > running a pre-apply-test with plain "patch --dry-run -F0" on all > patches (from a script I use for committing). I can help myself with > plain "git am", but sooner or later some patch will end up having a > collision with something else having gone in, and then I'll need to > manually clean up after the failed / incomplete command. > If I'm understanding correctly, it looks like git send-email's --transfer-encoding=8bit [1] should do what you're asking. I'll do this for future submissions. [1] https://git-scm.com/docs/git-send-email > Jan Thanks, Shawn
On 9/5/23 4:02 PM, Shawn Anastasio wrote: > On 9/5/23 11:07 AM, Jan Beulich wrote: >> On 01.09.2023 20:25, Shawn Anastasio wrote: >> Another thing I wanted to ask: Would it be possible to configure >> whatever mail client you use for sending patches to send plain ASCII or >> UTF-8 text, not quoted-printable ones? At least for me, so far having >> shoveled in most of your patches, that encoding gets in the way of >> running a pre-apply-test with plain "patch --dry-run -F0" on all >> patches (from a script I use for committing). I can help myself with >> plain "git am", but sooner or later some patch will end up having a >> collision with something else having gone in, and then I'll need to >> manually clean up after the failed / incomplete command. >> > > If I'm understanding correctly, it looks like git send-email's > --transfer-encoding=8bit [1] should do what you're asking. I'll do this > for future submissions. I've done this for my latest series dropping pseries support, but it seems the messages that reached the mailing list are still encoded as quoted-printable, despite git reporting that they were sent as 8bit. I suppose my SMTP server is mangling the encoding, then. I'll look into this some more, but hopefully the quoted-printable patches I send in the meantime won't pose too much of an inconvenience. Thanks, Shawn