* [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. @ 2017-02-16 16:30 Chad Joan 2017-02-16 16:58 ` Paolo Bonzini ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Chad Joan @ 2017-02-16 16:30 UTC (permalink / raw) To: qemu-devel, qemu-trivial [-- Attachment #1: Type: text/plain, Size: 339 bytes --] Hello, This is a one-line patch to the configure script that will allow QEMU to be built on musl-libc based Linux systems. This problem is only noticeable when QEMU is built with --enable-curses. Detailed reading material if you want to know where this came from: https://bugs.gentoo.org/show_bug.cgi?id=609364 Hope that helps! - Chad [-- Attachment #2: qemu-2.8.0-musl-ncurses.patch --] [-- Type: application/octet-stream, Size: 322 bytes --] diff --git configure configure index 1c9655e..9f83176 100755 --- configure +++ configure @@ -682,6 +682,7 @@ Haiku) vhost_net="yes" vhost_scsi="yes" vhost_vsock="yes" + QEMU_CFLAGS="-D_XOPEN_SOURCE=500 $QEMU_CFLAGS" QEMU_INCLUDES="-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers $QEMU_INCLUDES" ;; esac ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-16 16:30 [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems Chad Joan @ 2017-02-16 16:58 ` Paolo Bonzini 2017-02-16 17:23 ` Laszlo Ersek 2017-02-16 16:59 ` Eric Blake 2017-02-16 17:05 ` Peter Maydell 2 siblings, 1 reply; 36+ messages in thread From: Paolo Bonzini @ 2017-02-16 16:58 UTC (permalink / raw) To: Chad Joan, qemu-devel, qemu-trivial On 16/02/2017 17:30, Chad Joan wrote: > Hello, > > This is a one-line patch to the configure script that will allow QEMU to be > built on musl-libc based Linux systems. This problem is only noticeable > when QEMU is built with --enable-curses. > > Detailed reading material if you want to know where this came from: > https://bugs.gentoo.org/show_bug.cgi?id=609364 Hi, can you explain exactly which function is missing without -D_XOPEN_SOURCE=500? If it is curses' wide-char functions, why does it fail with musl but not with glibc? Is _XOPEN_SOURCE always defined by glibc if you have _D_GNU_SOURCE? Paolo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-16 16:58 ` Paolo Bonzini @ 2017-02-16 17:23 ` Laszlo Ersek 2017-02-16 17:47 ` Chad Joan ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Laszlo Ersek @ 2017-02-16 17:23 UTC (permalink / raw) To: Paolo Bonzini, Chad Joan, qemu-devel, qemu-trivial On 02/16/17 17:58, Paolo Bonzini wrote: > > > On 16/02/2017 17:30, Chad Joan wrote: >> Hello, >> >> This is a one-line patch to the configure script that will allow QEMU to be >> built on musl-libc based Linux systems. This problem is only noticeable >> when QEMU is built with --enable-curses. >> >> Detailed reading material if you want to know where this came from: >> https://bugs.gentoo.org/show_bug.cgi?id=609364 > > Hi, > > can you explain exactly which function is missing without > -D_XOPEN_SOURCE=500? If it is curses' wide-char functions, why does it > fail with musl but not with glibc? Is _XOPEN_SOURCE always defined by > glibc if you have _D_GNU_SOURCE? It is not necessarily auto-defined, but the effect is "as if". It is documented in the libc info: https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fXOPEN_005fSOURCE > Macro: _XOPEN_SOURCE > Macro: _XOPEN_SOURCE_EXTENDED > > If you define this macro, functionality described in the X/Open > Portability Guide is included. This is a superset of the POSIX.1 > and POSIX.2 functionality and in fact _POSIX_SOURCE and > _POSIX_C_SOURCE are automatically defined. > > As the unification of all Unices, functionality only available in > BSD and SVID is also included. > > If the macro _XOPEN_SOURCE_EXTENDED is also defined, even more > functionality is available. The extra functions will make all > functions available which are necessary for the X/Open Unix brand. > > If the macro _XOPEN_SOURCE has the value 500 this includes all > functionality described so far plus some new definitions from the > Single Unix Specification, version 2. https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fGNU_005fSOURCE > Macro: _GNU_SOURCE > > If you define this macro, everything is included: ISO C89, ISO > C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions. > In the cases where POSIX.1 conflicts with BSD, the POSIX > definitions take precedence. Curiously, I managed to recall this from years ago, when I was still living and breathing the SUS (and looking frequently at the glibc info too). Laszlo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-16 17:23 ` Laszlo Ersek @ 2017-02-16 17:47 ` Chad Joan 2017-02-17 6:43 ` Fam Zheng 2017-02-17 8:45 ` Paolo Bonzini 2017-02-17 8:56 ` Paolo Bonzini 2 siblings, 1 reply; 36+ messages in thread From: Chad Joan @ 2017-02-16 17:47 UTC (permalink / raw) To: Laszlo Ersek; +Cc: Paolo Bonzini, qemu-devel, qemu-trivial I am glad others are chiming in and might provide better solutions. Honestly, following the instructions at http://wiki.qemu-project.org/Contribute/SubmitAPatch to-the-letter is quite daunting to me, just to get one line of code changed. It might help if that page had some kind of dead-simple example for trivial patches; something like: $ cd <QEMU directory> $ git format-patch blah blah blah $ maybe-some-other-command $ # Now copy the contents of file xyz.patch into your email client and send to qemu-devel@nongnu.org and qemu-trivial@nongnu.org Ask me to do signing/secure-signatures/etc (or any foray into gnupg commands), setup and secure new email connectivity (ex: git send-email), or install new software on my system... and I'm going to bounce ;) Sorry. I kind of expected that discerning maintainers might want to do this patch differently. I'm not familiar with the why's of how your configure script is organized, so I really hope the QEMU devs can meet me in the middle and take this the rest of the way. I am perfectly willing to run commands on my machine and echo results to you if it helps you learn the nature of this problem. Hope that helps. - Chad On Thu, Feb 16, 2017 at 12:23 PM, Laszlo Ersek <lersek@redhat.com> wrote: > On 02/16/17 17:58, Paolo Bonzini wrote: > > > > > > On 16/02/2017 17:30, Chad Joan wrote: > >> Hello, > >> > >> This is a one-line patch to the configure script that will allow QEMU > to be > >> built on musl-libc based Linux systems. This problem is only noticeable > >> when QEMU is built with --enable-curses. > >> > >> Detailed reading material if you want to know where this came from: > >> https://bugs.gentoo.org/show_bug.cgi?id=609364 > > > > Hi, > > > > can you explain exactly which function is missing without > > -D_XOPEN_SOURCE=500? If it is curses' wide-char functions, why does it > > fail with musl but not with glibc? Is _XOPEN_SOURCE always defined by > > glibc if you have _D_GNU_SOURCE? > > It is not necessarily auto-defined, but the effect is "as if". > > It is documented in the libc info: > > https://www.gnu.org/software/libc/manual/html_node/Feature- > Test-Macros.html#index-_005fXOPEN_005fSOURCE > > > Macro: _XOPEN_SOURCE > > Macro: _XOPEN_SOURCE_EXTENDED > > > > If you define this macro, functionality described in the X/Open > > Portability Guide is included. This is a superset of the POSIX.1 > > and POSIX.2 functionality and in fact _POSIX_SOURCE and > > _POSIX_C_SOURCE are automatically defined. > > > > As the unification of all Unices, functionality only available in > > BSD and SVID is also included. > > > > If the macro _XOPEN_SOURCE_EXTENDED is also defined, even more > > functionality is available. The extra functions will make all > > functions available which are necessary for the X/Open Unix brand. > > > > If the macro _XOPEN_SOURCE has the value 500 this includes all > > functionality described so far plus some new definitions from the > > Single Unix Specification, version 2. > > https://www.gnu.org/software/libc/manual/html_node/Feature- > Test-Macros.html#index-_005fGNU_005fSOURCE > > > Macro: _GNU_SOURCE > > > > If you define this macro, everything is included: ISO C89, ISO > > C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions. > > In the cases where POSIX.1 conflicts with BSD, the POSIX > > definitions take precedence. > > Curiously, I managed to recall this from years ago, when I was still > living and breathing the SUS (and looking frequently at the glibc info > too). > > Laszlo > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-16 17:47 ` Chad Joan @ 2017-02-17 6:43 ` Fam Zheng 2017-02-17 9:23 ` Laszlo Ersek 2017-02-17 9:28 ` Peter Maydell 0 siblings, 2 replies; 36+ messages in thread From: Fam Zheng @ 2017-02-17 6:43 UTC (permalink / raw) To: Chad Joan; +Cc: Laszlo Ersek, qemu-trivial, Paolo Bonzini, qemu-devel On Thu, 02/16 12:47, Chad Joan wrote: > I am glad others are chiming in and might provide better solutions. > > Honestly, following the instructions at > http://wiki.qemu-project.org/Contribute/SubmitAPatch to-the-letter is quite > daunting to me, just to get one line of code changed. It might help if > that page had some kind of dead-simple example for trivial patches; > something like: > $ cd <QEMU directory> > $ git format-patch blah blah blah > $ maybe-some-other-command > $ # Now copy the contents of file xyz.patch into your email client and send > to qemu-devel@nongnu.org and qemu-trivial@nongnu.org Makes sense in general except for the sending part - email clients tend to damage the patch when you copy and paste by wrapping long lines or messing up other things. But your point is taken, we should make the first (or a one-shot) contribution as easy as possible. Fam ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 6:43 ` Fam Zheng @ 2017-02-17 9:23 ` Laszlo Ersek 2017-02-17 10:11 ` Fam Zheng 2017-02-17 9:28 ` Peter Maydell 1 sibling, 1 reply; 36+ messages in thread From: Laszlo Ersek @ 2017-02-17 9:23 UTC (permalink / raw) To: Fam Zheng, Chad Joan; +Cc: qemu-trivial, Paolo Bonzini, qemu-devel On 02/17/17 07:43, Fam Zheng wrote: > On Thu, 02/16 12:47, Chad Joan wrote: >> I am glad others are chiming in and might provide better solutions. >> >> Honestly, following the instructions at >> http://wiki.qemu-project.org/Contribute/SubmitAPatch to-the-letter is quite >> daunting to me, just to get one line of code changed. It might help if >> that page had some kind of dead-simple example for trivial patches; >> something like: >> $ cd <QEMU directory> >> $ git format-patch blah blah blah >> $ maybe-some-other-command >> $ # Now copy the contents of file xyz.patch into your email client and send >> to qemu-devel@nongnu.org and qemu-trivial@nongnu.org > > Makes sense in general except for the sending part - email clients tend to > damage the patch when you copy and paste by wrapping long lines or messing up > other things. But your point is taken, we should make the first (or a one-shot) > contribution as easy as possible. I disagree (from the sidelines, that is; I'm not a QEMU maintainer -- I'm a co-maintainer elsewhere). The patch submission process exists for a reason, the goal is to maximize the throughput of long-term contributors and maintainers, because that's the best for the project's overall health and progress. It does not mean that one-off contributions are not welcome -- all contributions are welcome that follow the process (and beyond that, everyone is welcome to become a long-term contributor). Just my two cents, of course; don't take this as an official standpoint or whatever. (And, I'm saying this after having manually fixed up garbled patches from one-off contributors.) Laszlo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 9:23 ` Laszlo Ersek @ 2017-02-17 10:11 ` Fam Zheng 0 siblings, 0 replies; 36+ messages in thread From: Fam Zheng @ 2017-02-17 10:11 UTC (permalink / raw) To: Laszlo Ersek; +Cc: Chad Joan, qemu-trivial, Paolo Bonzini, qemu-devel On Fri, 02/17 10:23, Laszlo Ersek wrote: > On 02/17/17 07:43, Fam Zheng wrote: > > On Thu, 02/16 12:47, Chad Joan wrote: > >> I am glad others are chiming in and might provide better solutions. > >> > >> Honestly, following the instructions at > >> http://wiki.qemu-project.org/Contribute/SubmitAPatch to-the-letter is quite > >> daunting to me, just to get one line of code changed. It might help if > >> that page had some kind of dead-simple example for trivial patches; > >> something like: > >> $ cd <QEMU directory> > >> $ git format-patch blah blah blah > >> $ maybe-some-other-command > >> $ # Now copy the contents of file xyz.patch into your email client and send > >> to qemu-devel@nongnu.org and qemu-trivial@nongnu.org > > > > Makes sense in general except for the sending part - email clients tend to > > damage the patch when you copy and paste by wrapping long lines or messing up > > other things. But your point is taken, we should make the first (or a one-shot) > > contribution as easy as possible. > > I disagree (from the sidelines, that is; I'm not a QEMU maintainer -- > I'm a co-maintainer elsewhere). The patch submission process exists for > a reason, the goal is to maximize the throughput of long-term > contributors and maintainers, because that's the best for the project's > overall health and progress. Having a process and smoothly revealing it to new contributors are not in conflict. The problem here is the long SubmitAPatch I think. It does include more details than needed for the minimum of the very first submission; also it is not in an easy-to-follow step-by-step form. I believe people will happily learn the process once he feels appreciation on his effort, once they get replies to his patch. :) > > It does not mean that one-off contributions are not welcome -- all > contributions are welcome that follow the process (and beyond that, > everyone is welcome to become a long-term contributor). IMHO one-off _fixes_ are also good, like this one. Like Peter noted, the only recommendation for those who don't like formalities and have no intention to contribute regularly, is to add a "signed-off-by" line to their patch. > > Just my two cents, of course; don't take this as an official standpoint > or whatever. (And, I'm saying this after having manually fixed up > garbled patches from one-off contributors.) > > Laszlo Fam ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 6:43 ` Fam Zheng 2017-02-17 9:23 ` Laszlo Ersek @ 2017-02-17 9:28 ` Peter Maydell 2017-02-17 15:34 ` Eric Blake 1 sibling, 1 reply; 36+ messages in thread From: Peter Maydell @ 2017-02-17 9:28 UTC (permalink / raw) To: Fam Zheng Cc: Chad Joan, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers On 17 February 2017 at 06:43, Fam Zheng <famz@redhat.com> wrote: > But your point is taken, we should make the first (or a one-shot) > contribution as easy as possible. Yes; we could do with providing a "This page seems very long..." introduction section. The absolute bare minimum requirements for a submitter I think are: * Provide a Signed-off-by: line (this is a hard requirement because it's how you say "I'm legally OK to contribute this and am happy for it to go into QEMU") * send patch by email * read replies and act on them if you want your patch to go in The larger your contribution is, the more important the other requirements detailed on the page are; but personally I'm happy to manually fix up patches from a first-time submitter, and I think most other maintainers are too. thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 9:28 ` Peter Maydell @ 2017-02-17 15:34 ` Eric Blake 2017-02-17 16:54 ` Chad Joan 2017-02-17 18:13 ` John Snow 0 siblings, 2 replies; 36+ messages in thread From: Eric Blake @ 2017-02-17 15:34 UTC (permalink / raw) To: Peter Maydell, Fam Zheng Cc: QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers, Chad Joan [-- Attachment #1: Type: text/plain, Size: 1101 bytes --] On 02/17/2017 03:28 AM, Peter Maydell wrote: > On 17 February 2017 at 06:43, Fam Zheng <famz@redhat.com> wrote: >> But your point is taken, we should make the first (or a one-shot) >> contribution as easy as possible. > > Yes; we could do with providing a "This page seems very long..." > introduction section. The absolute bare minimum requirements > for a submitter I think are: > * Provide a Signed-off-by: line (this is a hard requirement > because it's how you say "I'm legally OK to contribute this > and am happy for it to go into QEMU") > * send patch by email > * read replies and act on them if you want your patch to go in > > The larger your contribution is, the more important the other > requirements detailed on the page are; but personally I'm > happy to manually fix up patches from a first-time submitter, > and I think most other maintainers are too. I've updated the wiki to put in that nice bullet list, prior to the table of contents. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 15:34 ` Eric Blake @ 2017-02-17 16:54 ` Chad Joan 2017-02-17 16:56 ` Peter Maydell ` (3 more replies) 2017-02-17 18:13 ` John Snow 1 sibling, 4 replies; 36+ messages in thread From: Chad Joan @ 2017-02-17 16:54 UTC (permalink / raw) To: Eric Blake Cc: Peter Maydell, Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers Wow, that is some quick turn-around. Well done! My thoughts: - I find this summary info very helpful! On behalf of the N people trying to heal paper cuts: thank you! - I still recommend an example snippet for shell/bash interaction that demonstrates the workflow you expect from a first-time contributor. It should be populated with commonly used values (ex: mailing list addresses). I don't expect this to happen fast like the summary info; I suspect someone is going to have to pretend they are submitting a patch, write down what they do, and then think about how to present this. - Regarding the signature: IIRC, setting up certificates on a machine using gpg can be quite time consuming and learning-intensive if you've never needed to do it before. Having that example will go a long way to help with this. There is still a possible pain-point: you might write one line of git code in the example, and it is easy for you due to your workflow, but it could be hours of fiddling for someone who has never done it before. If I'm wrong, show me (the hypothetical reader) how easy it is ;) If I'm right (and that would be unfortunate, in this case), then it might be helpful if you politely ask the reader to spend time X amount of time on it (establish accurate expectations) and then provide a link to the most helpful how-to article you can find on the subject. - The email thing is a pain-point, but I wonder if QEMU can make it wonderful without sacrificing much--perhaps just a few words on the page. Presumably, not every email client mangles patches. Can we have a whitelist? So far the whitelist has one item: git send-email. But git send-email is probably not even part of the majority population's workflow, so if we can test and approve even /some/ of the more popular mail clients (ex: gmail, thunderbird, outlook, etc) for use, it would help newbies A LOT. Less importantly; a blacklist could be useful too, to prevent unnecessary "what about my mail client?" questions and unnecessary redundant testing in the future. - I should also mention that I found the rest of the document to be very well-written. It's comprehensiveness became its weakness, but that's still important long-term, hence why I think an alternative path with a short example for trivial patches is plenty sufficient: from my perspective, there's no need to change the rest of the text; it is already good :). Note that I'm bothering to stick around and provide feedback, despite other pressing life obligations. Providing advice on submit-a-patch usability for QEMU isn't on my schedule, but I don't have the heart to bail on this, especially when you all are kindly listening, having high quality discussion, and sincerely trying to improve things. If you read between the lines, you see the truth: I am a yak shaver! Oh man, when I hit a topic like "use git send-email", the hair started flying: learning new git commands, two-factor auth on gmail, U2F keys, governance for the no-mans-land of a server, and so on, a real yak-shaving party. After an hour or two, my safety triggered, and I thought, "man, I am spending way too much time perfecting this workflow that I might never do again" and I spent a few minutes writing a message in gmail. I certainly don't expect QEMU devs to fix garbled patches either: that also seems like a huge waste of valuable time (and for talented and passionate individuals, too). There has to be a better way! So I hope the whitelist idea helps, or maybe it's enough to just call awareness to this potential improvement. Well, that ended up being very long. I hope this is helpful and doesn't spend too much of your time. Thanks for listening! On Fri, Feb 17, 2017 at 10:34 AM, Eric Blake <eblake@redhat.com> wrote: > On 02/17/2017 03:28 AM, Peter Maydell wrote: > > On 17 February 2017 at 06:43, Fam Zheng <famz@redhat.com> wrote: > >> But your point is taken, we should make the first (or a one-shot) > >> contribution as easy as possible. > > > > Yes; we could do with providing a "This page seems very long..." > > introduction section. The absolute bare minimum requirements > > for a submitter I think are: > > * Provide a Signed-off-by: line (this is a hard requirement > > because it's how you say "I'm legally OK to contribute this > > and am happy for it to go into QEMU") > > * send patch by email > > * read replies and act on them if you want your patch to go in > > > > The larger your contribution is, the more important the other > > requirements detailed on the page are; but personally I'm > > happy to manually fix up patches from a first-time submitter, > > and I think most other maintainers are too. > > I've updated the wiki to put in that nice bullet list, prior to the > table of contents. > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 16:54 ` Chad Joan @ 2017-02-17 16:56 ` Peter Maydell 2017-02-17 16:57 ` Paolo Bonzini ` (2 subsequent siblings) 3 siblings, 0 replies; 36+ messages in thread From: Peter Maydell @ 2017-02-17 16:56 UTC (permalink / raw) To: Chad Joan Cc: Eric Blake, Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers On 17 February 2017 at 16:54, Chad Joan <chadjoan@gmail.com> wrote: > Regarding the signature: IIRC, setting up certificates on a machine using > gpg can be quite time consuming and learning-intensive if you've never > needed to do it before. There is no requirement for gpg (except for maintainers submitting pull requests). When we say "We need a signed-off-by" what we mean is literally "your commit message must include a line of the form Signed-off-by Some Person <some.person@wherever.com>". I agree that gpg is terrible as a UI and we definitely don't want it in our patch workflow for submitters ;-) thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 16:54 ` Chad Joan 2017-02-17 16:56 ` Peter Maydell @ 2017-02-17 16:57 ` Paolo Bonzini 2017-02-17 17:07 ` Chad Joan 2017-02-17 17:15 ` Peter Maydell 2017-02-17 17:17 ` Eric Blake 3 siblings, 1 reply; 36+ messages in thread From: Paolo Bonzini @ 2017-02-17 16:57 UTC (permalink / raw) To: Chad Joan, Eric Blake Cc: Peter Maydell, Fam Zheng, QEMU Trivial, Laszlo Ersek, QEMU Developers On 17/02/2017 17:54, Chad Joan wrote: > Regarding the signature: IIRC, setting up certificates on a machine > using gpg can be quite time consuming and learning-intensive if you've > never needed to do it before. Having that example will go a long way to > help with this. There is still a possible pain-point: you might write > one line of git code in the example, and it is easy for you due to your > workflow, but it could be hours of fiddling for someone who has never > done it before. If I'm wrong, show me (the hypothetical reader) how > easy it is ;) If I'm right (and that would be unfortunate, in this > case), then it might be helpful if you politely ask the reader to spend > time X amount of time on it (establish accurate expectations) and then > provide a link to the most helpful how-to article you can find on the > subject. GPG signing is not needed. All you need is "git commit -s". Adding "Signed-off-by: Chad Joan <chadjoan@gmail.com>" basically is a way to tell us "I understand I'm contributing this under the GNU GPL or a compatible license". It's not a cryptographic signature. Paolo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 16:57 ` Paolo Bonzini @ 2017-02-17 17:07 ` Chad Joan 0 siblings, 0 replies; 36+ messages in thread From: Chad Joan @ 2017-02-17 17:07 UTC (permalink / raw) To: Paolo Bonzini Cc: Eric Blake, Peter Maydell, Fam Zheng, QEMU Trivial, Laszlo Ersek, QEMU Developers How wonderful! Problem solved. Now I think that just having an example could kill the misconception forever ;) On Fri, Feb 17, 2017 at 11:57 AM, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On 17/02/2017 17:54, Chad Joan wrote: > > Regarding the signature: IIRC, setting up certificates on a machine > > using gpg can be quite time consuming and learning-intensive if you've > > never needed to do it before. Having that example will go a long way to > > help with this. There is still a possible pain-point: you might write > > one line of git code in the example, and it is easy for you due to your > > workflow, but it could be hours of fiddling for someone who has never > > done it before. If I'm wrong, show me (the hypothetical reader) how > > easy it is ;) If I'm right (and that would be unfortunate, in this > > case), then it might be helpful if you politely ask the reader to spend > > time X amount of time on it (establish accurate expectations) and then > > provide a link to the most helpful how-to article you can find on the > > subject. > > GPG signing is not needed. All you need is "git commit -s". > > Adding "Signed-off-by: Chad Joan <chadjoan@gmail.com>" basically is a > way to tell us "I understand I'm contributing this under the GNU GPL or > a compatible license". It's not a cryptographic signature. > > Paolo > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 16:54 ` Chad Joan 2017-02-17 16:56 ` Peter Maydell 2017-02-17 16:57 ` Paolo Bonzini @ 2017-02-17 17:15 ` Peter Maydell 2017-02-19 7:22 ` Chad Joan 2017-02-21 2:53 ` Eric Blake 2017-02-17 17:17 ` Eric Blake 3 siblings, 2 replies; 36+ messages in thread From: Peter Maydell @ 2017-02-17 17:15 UTC (permalink / raw) To: Chad Joan Cc: Eric Blake, Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers On 17 February 2017 at 16:54, Chad Joan <chadjoan@gmail.com> wrote: > so if we can test and > approve even /some/ of the more popular mail clients (ex: gmail, > thunderbird, outlook, etc) for use, it would help newbies A LOT. Pretty sure we've seen mangled emails from all of those. The problem is that most email clients will automatically wrap long lines, which is fine for text but breaks an inline patch. Changing trailing whitespace in patches is also a common issue. The documentation in "git help format-patch" has a section "MUA-SPECIFIC HINTS" which says that gmail's web interface is definitely no good, and Thunderbird defaults to the wrong thing and requires a bunch of config changes which you'd then have to switch back to your preferences for normal mail when you're done sending patches. Outlook is so hopeless for patch mail it isn't even listed :-) The kernel docs have a longer list of mail clients with notes about suitability: https://kernel.org/doc/html/latest/process/email-clients.html but the set of "just works" clients is very small. thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 17:15 ` Peter Maydell @ 2017-02-19 7:22 ` Chad Joan 2017-02-19 12:12 ` Peter Maydell 2017-02-21 2:53 ` Eric Blake 1 sibling, 1 reply; 36+ messages in thread From: Chad Joan @ 2017-02-19 7:22 UTC (permalink / raw) To: Peter Maydell Cc: Eric Blake, Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers This is kinda depressing to read :( But thanks for explaining. I got a good laugh when it mentioned of Lotus Notes, "Run away from it." Would it be reasonable to stick a link to that article in the submit a patch document? Something like, "If you can't use 'git send-email' for any reason, then please review [link]this article[/link] to understand which clients are capable of sending acceptable patches and how to configure them." I suspect I'm going to encounter this problem again as I try to make small fixes for more projects, so it might be worth it for me to spend a small amount of time at some point setting up a mail client that I can send git patches with. Or perhaps I can just move the patch(es) onto another machine (ex: my personal laptop) and send it with 'git send-email' from there, instead of needing to install a mail client that is outside of my normal workflow. I am not comfortable with putting smtp login information onto the server that I am using for this work. If anyone has any advice on how to handle this situation, I'd appreciate it. That kernel doc that Peter linked is already pretty helpful, at least. Thanks! On Fri, Feb 17, 2017 at 12:15 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 17 February 2017 at 16:54, Chad Joan <chadjoan@gmail.com> wrote: > > so if we can test and > > approve even /some/ of the more popular mail clients (ex: gmail, > > thunderbird, outlook, etc) for use, it would help newbies A LOT. > > Pretty sure we've seen mangled emails from all of those. > The problem is that most email clients will automatically > wrap long lines, which is fine for text but breaks an > inline patch. Changing trailing whitespace in patches is > also a common issue. > > The documentation in "git help format-patch" has a section > "MUA-SPECIFIC HINTS" which says that gmail's web interface > is definitely no good, and Thunderbird defaults to the wrong > thing and requires a bunch of config changes which you'd then > have to switch back to your preferences for normal mail when > you're done sending patches. Outlook is so hopeless for > patch mail it isn't even listed :-) > > The kernel docs have a longer list of mail clients with > notes about suitability: > https://kernel.org/doc/html/latest/process/email-clients.html > but the set of "just works" clients is very small. > > thanks > -- PMM > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-19 7:22 ` Chad Joan @ 2017-02-19 12:12 ` Peter Maydell 0 siblings, 0 replies; 36+ messages in thread From: Peter Maydell @ 2017-02-19 12:12 UTC (permalink / raw) To: Chad Joan Cc: Eric Blake, Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers On 19 February 2017 at 07:22, Chad Joan <chadjoan@gmail.com> wrote: > I suspect I'm going to encounter this problem again as I try to make small > fixes for more projects, so it might be worth it for me to spend a small > amount of time at some point setting up a mail client that I can send git > patches with. Or perhaps I can just move the patch(es) onto another machine > (ex: my personal laptop) and send it with 'git send-email' from there, > instead of needing to install a mail client that is outside of my normal > workflow. I am not comfortable with putting smtp login information onto the > server that I am using for this work. Yes, I'd do that. If you do git format-patch on one machine you can then copy the patch files onto another where you do git send-email (my workflow actually involves something similar to this). Or if the machine you're running on is a server with limited development facilities you might prefer to do development entirely on a different machine and then on the server just do a git fetch or git pull from the git tree on your development machine to build it. (I do this when I'm doing build tests, since there usually isn't a nice dev environment with my preferred editor and tools and so on on the test machine.) Then your patches are all on the dev machine to start with. thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 17:15 ` Peter Maydell 2017-02-19 7:22 ` Chad Joan @ 2017-02-21 2:53 ` Eric Blake 1 sibling, 0 replies; 36+ messages in thread From: Eric Blake @ 2017-02-21 2:53 UTC (permalink / raw) To: Peter Maydell, Chad Joan Cc: Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers [-- Attachment #1: Type: text/plain, Size: 529 bytes --] On 02/17/2017 11:15 AM, Peter Maydell wrote: > The kernel docs have a longer list of mail clients with > notes about suitability: > https://kernel.org/doc/html/latest/process/email-clients.html > but the set of "just works" clients is very small. Currently fails with 403 Forbidden You don't have permission to access /doc/html/latest/process/email-clients.html on this server. Hopefully its transient? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 16:54 ` Chad Joan ` (2 preceding siblings ...) 2017-02-17 17:15 ` Peter Maydell @ 2017-02-17 17:17 ` Eric Blake 2017-02-19 7:02 ` Chad Joan 3 siblings, 1 reply; 36+ messages in thread From: Eric Blake @ 2017-02-17 17:17 UTC (permalink / raw) To: Chad Joan Cc: Peter Maydell, Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers [-- Attachment #1: Type: text/plain, Size: 5226 bytes --] On 02/17/2017 10:54 AM, Chad Joan wrote: > Wow, that is some quick turn-around. Well done! > > My thoughts: > > - I find this summary info very helpful! On behalf of the N people > trying to heal paper cuts: thank you! > - I still recommend an example snippet for shell/bash interaction that > demonstrates the workflow you expect from a first-time contributor. It > should be populated with commonly used values (ex: mailing list > addresses). I don't expect this to happen fast like the summary info; I > suspect someone is going to have to pretend they are submitting a patch, > write down what they do, and then think about how to present this. For a quickie patch, I make my edits, then 'git commit -a -s' and 'git send-email -1' - but that works because I've already set up git hooks to auto-cc the list, and I already debugged my 'get send-email' setup years ago. So yeah, doing it from a completely virgin environment could benefit from a complete command line that reproduces what I take for granted in my normal environment. And some email setups are a lot friendlier than others (I personally do not use gmail, but will readily admit that it is probably a lot easier to set up my work emails to use Red Hat's SMTP servers than it is for a gmail contributor to get their email setup working in a way that does not mangle patches). > - Regarding the signature: IIRC, setting up certificates on a machine > using gpg can be quite time consuming and learning-intensive if you've > never needed to do it before. But nothing requires you to set up a certificate to submit a patch. I'm not sure which piece of the documentation got you steered in that direction, but gpg signing of patches is only required of maintainers, not contributors (or maybe you're hinting at the extra effort required to set up gmail as a valid 'git send-email' target, to which I have no experience, but which starts to leave the realm of qemu-specific instructions into something where it would be better to link to a good git setup tutorial, if one exists). > Having that example will go a long way to > help with this. <snip lots of useful ideas for improvement> > - I should also mention that I found the rest of the document to be very > well-written. It's comprehensiveness became its weakness, but that's still > important long-term, hence why I think an alternative path with a short > example for trivial patches is plenty sufficient: from my perspective, > there's no need to change the rest of the text; it is already good :). Thanks for that feedback. It's often hard for a core contributor to remember what it was like to submit their first patch years ago, and having a fresh take on the matter from a new contributor is well worth the reminders. It's also nice to hear this as a compliment, and not just a complaint. > > Note that I'm bothering to stick around and provide feedback, despite other > pressing life obligations. Providing advice on submit-a-patch usability > for QEMU isn't on my schedule, but I don't have the heart to bail on this, > especially when you all are kindly listening, having high quality > discussion, and sincerely trying to improve things. If you read between > the lines, you see the truth: I am a yak shaver! At the risk of pushing too hard, you could always turn your (good!) suggestions into concrete wording, or even request a wiki account to make the changes yourself. But even if that is beyond your planned level of involvement, I do hope that various readers will be able to act on the suggestions in this mail to improve things. > > Oh man, when I hit a topic like "use git send-email", the hair started > flying: learning new git commands, two-factor auth on gmail, U2F keys, > governance for the no-mans-land of a server, and so on, a real yak-shaving > party. After an hour or two, my safety triggered, and I thought, "man, I > am spending way too much time perfecting this workflow that I might never > do again" and I spent a few minutes writing a message in gmail. I > certainly don't expect QEMU devs to fix garbled patches either: that also > seems like a huge waste of valuable time (and for talented and passionate > individuals, too). There has to be a better way! So I hope the whitelist > idea helps, or maybe it's enough to just call awareness to this potential > improvement. Again, part of the problem may be that gmail is not really suited to the ideal patch flow, and so that's going to be a pain point for any such contributor. Submitting patches as an attachment is harder than the inline version you get with 'git send-email', but it is one of those one-off manual fixups that a maintainer can overlook, as long as it really is a one-off thing and not a repeated pattern. And yes, we should document that use of an attachment is the most likely to avoid mangling the patch if you don't have 'git send-email' working, even if it is harder for the maintainer to apply such a patch. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 17:17 ` Eric Blake @ 2017-02-19 7:02 ` Chad Joan 2017-02-21 3:02 ` Eric Blake 0 siblings, 1 reply; 36+ messages in thread From: Chad Joan @ 2017-02-19 7:02 UTC (permalink / raw) To: Eric Blake Cc: Peter Maydell, Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers On Fri, Feb 17, 2017 at 12:17 PM, Eric Blake <eblake@redhat.com> wrote: > On 02/17/2017 10:54 AM, Chad Joan wrote: > > Wow, that is some quick turn-around. Well done! > > > > My thoughts: > > > > - I find this summary info very helpful! On behalf of the N people > > trying to heal paper cuts: thank you! > > - I still recommend an example snippet for shell/bash interaction that > > demonstrates the workflow you expect from a first-time contributor. > It > > should be populated with commonly used values (ex: mailing list > > addresses). I don't expect this to happen fast like the summary > info; I > > suspect someone is going to have to pretend they are submitting a > patch, > > write down what they do, and then think about how to present this. > > For a quickie patch, I make my edits, then 'git commit -a -s' and 'git > send-email -1' - but that works because I've already set up git hooks to > auto-cc the list, and I already debugged my 'get send-email' setup years > ago. So yeah, doing it from a completely virgin environment could > benefit from a complete command line that reproduces what I take for > granted in my normal environment. And some email setups are a lot > friendlier than others (I personally do not use gmail, but will readily > admit that it is probably a lot easier to set up my work emails to use > Red Hat's SMTP servers than it is for a gmail contributor to get their > email setup working in a way that does not mangle patches). > > I appreciate this retrospective :) In my case I am working on a machine that wasn't even supposed to see any development work. There are no user accounts, just root. I have tried to avoid putting any personal information on it. If I am on it, then I'm editing files in /etc or installing system-wide software. I'm realizing that I might have to change this a bit due to the WIP nature of the hardened-musl profile: ultimately I *am* doing development work on it, and that kind of snuck up on me. If I give myself a user account, then authoring patches with git (and using send-email) becomes somewhat more practical (putting smtp login information onto the machine still bugs me). Still, I can't imagine I'm the only person who runs into this kind of thing and wants to write quick patches on an impersonal machine. > [...] > > But nothing requires you to set up a certificate to submit a patch. I'm > not sure which piece of the documentation got you steered in that > direction, but gpg signing of patches is only required of maintainers, > not contributors (or maybe you're hinting at the extra effort required > to set up gmail as a valid 'git send-email' target, to which I have no > experience, but which starts to leave the realm of qemu-specific > instructions into something where it would be better to link to a good > git setup tutorial, if one exists). > > I think this is just language ambiguity and confirmation bias doing their thing. Usually when I read "you have to sign this" in an OSS context, I think of cryptographic signing. I haven't encountered the requirement for non-cryptographic signing before. Language is arbitrary and we all have different experiences and backgrounds. This is one of the reasons why I suggest a simple example: it would be both very concise and unambiguous. If there are no signing steps in the example then you don't even need to spend words telling the reader that cryptographic signing is unnecessary. It'll be implied. Thankfully, this is a separate concern from the 'git send-email' thing. > > Having that example will go a long way to > > help with this. > > <snip lots of useful ideas for improvement> > > > - I should also mention that I found the rest of the document to be > very > > well-written. It's comprehensiveness became its weakness, but that's > still > > important long-term, hence why I think an alternative path with a > short > > example for trivial patches is plenty sufficient: from my perspective, > > there's no need to change the rest of the text; it is already good :). > > Thanks for that feedback. It's often hard for a core contributor to > remember what it was like to submit their first patch years ago, and > having a fresh take on the matter from a new contributor is well worth > the reminders. It's also nice to hear this as a compliment, and not > just a complaint. > > Thanks for listening :) I know what you mean about the complaint thing. It's unfortunate, but it can be very hard to know the significance of your words for others. For many people (possibly myself included; hard to remember) it may take a long time to learn and internalize the implications of a truth such as "no one wants to be hurt". I try to be the world that I want to live in. I'm glad it's working out for everyone this time around. FWIW, this thread has also left me impressed with the culture in the QEMU community, and it makes me feel good about choosing this software too. Good job everyone! > > > > Note that I'm bothering to stick around and provide feedback, despite > other > > pressing life obligations. Providing advice on submit-a-patch usability > > for QEMU isn't on my schedule, but I don't have the heart to bail on > this, > > especially when you all are kindly listening, having high quality > > discussion, and sincerely trying to improve things. If you read between > > the lines, you see the truth: I am a yak shaver! > > At the risk of pushing too hard, you could always turn your (good!) > suggestions into concrete wording, or even request a wiki account to > make the changes yourself. But even if that is beyond your planned level > of involvement, I do hope that various readers will be able to act on > the suggestions in this mail to improve things. > > It's always worth asking! I'm in deep enough now that I wouldn't cheap out on it ;) I'm more worried that I'm completely unqualified to do this. I could try to read the whole thing and make a small 2-4 liner that would do what QEMU devs want. But I'm almost certain I'd botch it up somehow. I've already misinterpreted the gpg signature thing; there's more where that came from! I think a QEMU dev would get results that a QEMU dev would expect. Well, let me know if you want me to try *anyways*. > > > > Oh man, when I hit a topic like "use git send-email", the hair started > > flying: learning new git commands, two-factor auth on gmail, U2F keys, > > governance for the no-mans-land of a server, and so on, a real > yak-shaving > > party. After an hour or two, my safety triggered, and I thought, "man, I > > am spending way too much time perfecting this workflow that I might never > > do again" and I spent a few minutes writing a message in gmail. I > > certainly don't expect QEMU devs to fix garbled patches either: that also > > seems like a huge waste of valuable time (and for talented and passionate > > individuals, too). There has to be a better way! So I hope the > whitelist > > idea helps, or maybe it's enough to just call awareness to this potential > > improvement. > > Again, part of the problem may be that gmail is not really suited to the > ideal patch flow, and so that's going to be a pain point for any such > contributor. Submitting patches as an attachment is harder than the > inline version you get with 'git send-email', but it is one of those > one-off manual fixups that a maintainer can overlook, as long as it > really is a one-off thing and not a repeated pattern. And yes, we > should document that use of an attachment is the most likely to avoid > mangling the patch if you don't have 'git send-email' working, even if > it is harder for the maintainer to apply such a patch. > > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > Interesting. I certainly think that would help. If the QEMU maintainers could meet me (the hypothetical mass of first-timers) in the middle and handle 1-3 attachments or so, then that would make things very painless on my side. And at the point where I am submitting more than a few patches, I know that there is a pattern developing and I wouldn't mind spending the effort to streamline it for everyone. tl;dr: This idea makes sense on my side too. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-19 7:02 ` Chad Joan @ 2017-02-21 3:02 ` Eric Blake 2017-02-21 9:41 ` Markus Armbruster 0 siblings, 1 reply; 36+ messages in thread From: Eric Blake @ 2017-02-21 3:02 UTC (permalink / raw) To: Chad Joan Cc: Peter Maydell, Fam Zheng, QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers [-- Attachment #1: Type: text/plain, Size: 3335 bytes --] On 02/19/2017 01:02 AM, Chad Joan wrote: > development work. There are no user accounts, just root. I have tried to > avoid putting any personal information on it. If I am on it, then I'm > editing files in /etc or installing system-wide software. I'm realizing > that I might have to change this a bit due to the WIP nature of the > hardened-musl profile: ultimately I *am* doing development work on it, and > that kind of snuck up on me. If I give myself a user account, then > authoring patches with git (and using send-email) becomes somewhat more > practical (putting smtp login information onto the machine still bugs me). You don't have to store your SMTP passwords; git is smart enough to ask you interactively if you (intentionally) omit the passwords from .gitconfig. But I agree that even storing your SMTP address and username in configs can be a bit hairier than you want on some boxes. > Still, I can't imagine I'm the only person who runs into this kind of thing > and wants to write quick patches on an impersonal machine. There's always the option to float the patches back to a personal machine before posting to the list (yes, it requires more work on your end, but if it serves as a nice manual wall between your internal and external machines, it may well be worth the discipline). > > >> [...] >> >> But nothing requires you to set up a certificate to submit a patch. I'm >> not sure which piece of the documentation got you steered in that >> direction, but gpg signing of patches is only required of maintainers, >> not contributors (or maybe you're hinting at the extra effort required >> to set up gmail as a valid 'git send-email' target, to which I have no >> experience, but which starts to leave the realm of qemu-specific >> instructions into something where it would be better to link to a good >> git setup tutorial, if one exists). >> >> > I think this is just language ambiguity and confirmation bias doing their > thing. Usually when I read "you have to sign this" in an OSS context, I > think of cryptographic signing. I haven't encountered the requirement for > non-cryptographic signing before. Language is arbitrary and we all have > different experiences and backgrounds. Is it sufficient to just give the example of 'git commit -s' being the trick to automatically adding the necessary Signed-off-by: line? (Of course, automating the process like that, without actually reading http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297 to understand what it means and that you actually comply, is risky) > > This is one of the reasons why I suggest a simple example: it would be both > very concise and unambiguous. If there are no signing steps in the example > then you don't even need to spend words telling the reader that > cryptographic signing is unnecessary. It'll be implied. > > Thankfully, this is a separate concern from the 'git send-email' thing. 'git send-email -s' can also add Signed-off-by: lines, if you didn't add them earlier (but only if you use send-email, rather than attachments) :) -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-21 3:02 ` Eric Blake @ 2017-02-21 9:41 ` Markus Armbruster 2017-02-21 9:58 ` Peter Maydell 0 siblings, 1 reply; 36+ messages in thread From: Markus Armbruster @ 2017-02-21 9:41 UTC (permalink / raw) To: Eric Blake Cc: Chad Joan, Peter Maydell, Fam Zheng, QEMU Trivial, QEMU Developers, Paolo Bonzini, Laszlo Ersek Eric Blake <eblake@redhat.com> writes: [...] > 'git send-email -s' can also add Signed-off-by: lines, if you didn't add > them earlier (but only if you use send-email, rather than attachments) :) That's fine, as you *should* use git send-email. If it looks unattractive to you because it needs some setup, then that's because you haven't wasted your time failing at all the alternatives. Hiding patches in attachments counts as failure. We should be nice about new contributors failures, of course. Still, you might want to spend your new contributor goodwill budget on more interesting mistakes ;) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-21 9:41 ` Markus Armbruster @ 2017-02-21 9:58 ` Peter Maydell 0 siblings, 0 replies; 36+ messages in thread From: Peter Maydell @ 2017-02-21 9:58 UTC (permalink / raw) To: Markus Armbruster Cc: Eric Blake, Chad Joan, Fam Zheng, QEMU Trivial, QEMU Developers, Paolo Bonzini, Laszlo Ersek On 21 February 2017 at 09:41, Markus Armbruster <armbru@redhat.com> wrote: > Eric Blake <eblake@redhat.com> writes: > > [...] >> 'git send-email -s' can also add Signed-off-by: lines, if you didn't add >> them earlier (but only if you use send-email, rather than attachments) :) > > That's fine, as you *should* use git send-email. It has the disadvantage that checkpatch will complain at you when you test your patches before sending them, because the sign-off is missing... Personally I recommend adding the signoff lines earlier in the process. thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 15:34 ` Eric Blake 2017-02-17 16:54 ` Chad Joan @ 2017-02-17 18:13 ` John Snow 1 sibling, 0 replies; 36+ messages in thread From: John Snow @ 2017-02-17 18:13 UTC (permalink / raw) To: Eric Blake, Peter Maydell, Fam Zheng Cc: QEMU Trivial, Paolo Bonzini, Laszlo Ersek, QEMU Developers, Chad Joan On 02/17/2017 10:34 AM, Eric Blake wrote: > On 02/17/2017 03:28 AM, Peter Maydell wrote: >> On 17 February 2017 at 06:43, Fam Zheng <famz@redhat.com> wrote: >>> But your point is taken, we should make the first (or a one-shot) >>> contribution as easy as possible. >> >> Yes; we could do with providing a "This page seems very long..." >> introduction section. The absolute bare minimum requirements >> for a submitter I think are: >> * Provide a Signed-off-by: line (this is a hard requirement >> because it's how you say "I'm legally OK to contribute this >> and am happy for it to go into QEMU") >> * send patch by email >> * read replies and act on them if you want your patch to go in >> >> The larger your contribution is, the more important the other >> requirements detailed on the page are; but personally I'm >> happy to manually fix up patches from a first-time submitter, >> and I think most other maintainers are too. > > I've updated the wiki to put in that nice bullet list, prior to the > table of contents. > Is there a way we can make the quickstart exist in a pop-box? Also, any way to wrap the text on the rest of the introductory article? If you fullscreen this on a widescreen monitor you have to chase the letters to the far corners of the earth. Formatting the article more nicely might help its readability. It's also worth noting that just /reading the outline/ gives you enough advice, reading the details are actually not strictly necessary. --js ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-16 17:23 ` Laszlo Ersek 2017-02-16 17:47 ` Chad Joan @ 2017-02-17 8:45 ` Paolo Bonzini 2017-02-17 8:56 ` Paolo Bonzini 2 siblings, 0 replies; 36+ messages in thread From: Paolo Bonzini @ 2017-02-17 8:45 UTC (permalink / raw) To: Laszlo Ersek, Chad Joan, qemu-devel, qemu-trivial On 16/02/2017 18:23, Laszlo Ersek wrote: >> Hi, >> >> can you explain exactly which function is missing without >> -D_XOPEN_SOURCE=500? If it is curses' wide-char functions, why does it >> fail with musl but not with glibc? Is _XOPEN_SOURCE always defined by >> glibc if you have _D_GNU_SOURCE? > It is not necessarily auto-defined, but the effect is "as if". > > It is documented in the libc info: > > https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fXOPEN_005fSOURCE > So is this a musl bug? Paolo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-16 17:23 ` Laszlo Ersek 2017-02-16 17:47 ` Chad Joan 2017-02-17 8:45 ` Paolo Bonzini @ 2017-02-17 8:56 ` Paolo Bonzini 2017-02-17 9:17 ` Laszlo Ersek 2017-02-17 10:18 ` Peter Maydell 2 siblings, 2 replies; 36+ messages in thread From: Paolo Bonzini @ 2017-02-17 8:56 UTC (permalink / raw) To: Laszlo Ersek, Chad Joan, qemu-devel, qemu-trivial On 16/02/2017 18:23, Laszlo Ersek wrote: > On 02/16/17 17:58, Paolo Bonzini wrote: >> >> >> On 16/02/2017 17:30, Chad Joan wrote: >>> Hello, >>> >>> This is a one-line patch to the configure script that will allow QEMU to be >>> built on musl-libc based Linux systems. This problem is only noticeable >>> when QEMU is built with --enable-curses. >>> >>> Detailed reading material if you want to know where this came from: >>> https://bugs.gentoo.org/show_bug.cgi?id=609364 >> >> Hi, >> >> can you explain exactly which function is missing without >> -D_XOPEN_SOURCE=500? If it is curses' wide-char functions, why does it >> fail with musl but not with glibc? Is _XOPEN_SOURCE always defined by >> glibc if you have _D_GNU_SOURCE? > > It is not necessarily auto-defined, but the effect is "as if". Ok, so the bug is that glibc _does_ auto-define _XOPEN_SOURCE: #ifdef _GNU_SOURCE # undef _ISOC95_SOURCE # define _ISOC95_SOURCE 1 # undef _ISOC99_SOURCE # define _ISOC99_SOURCE 1 # undef _ISOC11_SOURCE # define _ISOC11_SOURCE 1 # undef _POSIX_SOURCE # define _POSIX_SOURCE 1 # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE 200809L # undef _XOPEN_SOURCE # define _XOPEN_SOURCE 700 # undef _XOPEN_SOURCE_EXTENDED # define _XOPEN_SOURCE_EXTENDED 1 # undef _LARGEFILE64_SOURCE # define _LARGEFILE64_SOURCE 1 # undef _DEFAULT_SOURCE # define _DEFAULT_SOURCE 1 # undef _ATFILE_SOURCE # define _ATFILE_SOURCE 1 #endif and ncursesw looks for _XOPEN_SOURCE exclusively: #ifndef NCURSES_WIDECHAR #if defined(_XOPEN_SOURCE_EXTENDED) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE - 0 >= 500)) #define NCURSES_WIDECHAR 1 #else #define NCURSES_WIDECHAR 0 #endif #endif /* NCURSES_WIDECHAR */ So I do think that if musl wants to support _GNU_SOURCE, it should also auto-define; however it doesn't, see https://git.musl-libc.org/cgit/musl/tree/include/features.h. Alternatively, ncurses should be patched to look at _GNU_SOURCE in addition to _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED. In any case, it's not a QEMU bug. Other packages likely are going to have the same issue, and fixing all of them is the wrong course of action. Paolo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 8:56 ` Paolo Bonzini @ 2017-02-17 9:17 ` Laszlo Ersek 2017-02-17 11:11 ` Paolo Bonzini 2017-02-17 10:18 ` Peter Maydell 1 sibling, 1 reply; 36+ messages in thread From: Laszlo Ersek @ 2017-02-17 9:17 UTC (permalink / raw) To: Paolo Bonzini, Chad Joan, qemu-devel, qemu-trivial On 02/17/17 09:56, Paolo Bonzini wrote: > > > On 16/02/2017 18:23, Laszlo Ersek wrote: >> On 02/16/17 17:58, Paolo Bonzini wrote: >>> >>> >>> On 16/02/2017 17:30, Chad Joan wrote: >>>> Hello, >>>> >>>> This is a one-line patch to the configure script that will allow QEMU to be >>>> built on musl-libc based Linux systems. This problem is only noticeable >>>> when QEMU is built with --enable-curses. >>>> >>>> Detailed reading material if you want to know where this came from: >>>> https://bugs.gentoo.org/show_bug.cgi?id=609364 >>> >>> Hi, >>> >>> can you explain exactly which function is missing without >>> -D_XOPEN_SOURCE=500? If it is curses' wide-char functions, why does it >>> fail with musl but not with glibc? Is _XOPEN_SOURCE always defined by >>> glibc if you have _D_GNU_SOURCE? >> >> It is not necessarily auto-defined, but the effect is "as if". > > Ok, so the bug is that glibc _does_ auto-define _XOPEN_SOURCE: > > #ifdef _GNU_SOURCE > # undef _ISOC95_SOURCE > # define _ISOC95_SOURCE 1 > # undef _ISOC99_SOURCE > # define _ISOC99_SOURCE 1 > # undef _ISOC11_SOURCE > # define _ISOC11_SOURCE 1 > # undef _POSIX_SOURCE > # define _POSIX_SOURCE 1 > # undef _POSIX_C_SOURCE > # define _POSIX_C_SOURCE 200809L > # undef _XOPEN_SOURCE > # define _XOPEN_SOURCE 700 > # undef _XOPEN_SOURCE_EXTENDED > # define _XOPEN_SOURCE_EXTENDED 1 > # undef _LARGEFILE64_SOURCE > # define _LARGEFILE64_SOURCE 1 > # undef _DEFAULT_SOURCE > # define _DEFAULT_SOURCE 1 > # undef _ATFILE_SOURCE > # define _ATFILE_SOURCE 1 > #endif > > and ncursesw looks for _XOPEN_SOURCE exclusively: > > #ifndef NCURSES_WIDECHAR > #if defined(_XOPEN_SOURCE_EXTENDED) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE - 0 >= 500)) > #define NCURSES_WIDECHAR 1 > #else > #define NCURSES_WIDECHAR 0 > #endif > #endif /* NCURSES_WIDECHAR */ > > > So I do think that if musl wants to support _GNU_SOURCE, it should also auto-define; > however it doesn't, see https://git.musl-libc.org/cgit/musl/tree/include/features.h. > > Alternatively, ncurses should be patched to look at _GNU_SOURCE in addition to > _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED. > > In any case, it's not a QEMU bug. Other packages likely are going to have the same > issue, and fixing all of them is the wrong course of action. I'm somewhat unsure -- I think it's debatable whether other libc (or Curses) implementations should care about _GNU_SOURCE at all. After all, _GNU_SOURCE says "GNU" in the name. However, defining _XOPEN_SOURCE as 500 is specified in an industry standard (SUSv2): http://pubs.opengroup.org/onlinepubs/7908799/xsh/compilation.html and the same standard defines Curses too (and it describes the relationship of Curses interfaces with _XOPEN_SOURCE): http://pubs.opengroup.org/onlinepubs/7908799/xcurses/implement.html So I think if an application wants to support Curses *without* necessarily depending on glibc, then the application should explicitly define _XOPEN_SOURCE. If that other libc and that Curses implementation don't care about GNU, only SUSv2 (which is entirely in their right), then they'll look only for _XOPEN_SOURCE. And, if other packages have the same issue, then they all should be patched, for better standards conformance. Of course, *if* that other C library, and the Curses implementation, claim compatibility with glibc as far as _GNU_SOURCE goes, *then* I fully agree with you. (IOW, it depends on the condition that you formulated above, "if musl wants to support _GNU_SOURCE".) Same for ncurses -- do they aim at SUSv2 conformance, or do they intend to consider _GNU_SOURCE specifically? Thanks Laszlo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 9:17 ` Laszlo Ersek @ 2017-02-17 11:11 ` Paolo Bonzini 2017-02-17 11:43 ` Chad Joan 0 siblings, 1 reply; 36+ messages in thread From: Paolo Bonzini @ 2017-02-17 11:11 UTC (permalink / raw) To: Laszlo Ersek, Chad Joan, qemu-devel, qemu-trivial On 17/02/2017 10:17, Laszlo Ersek wrote: > Of course, *if* that other C library, and the Curses implementation, > claim compatibility with glibc as far as _GNU_SOURCE goes, *then* I > fully agree with you. (IOW, it depends on the condition that you > formulated above, "if musl wants to support _GNU_SOURCE".) They at least try, since their features.h supports it. > Same for ncurses -- do they aim at SUSv2 conformance, or do they intend > to consider _GNU_SOURCE specifically? Well, ncurses is a GNU project so I suppose they mostly care about whatever Autoconf does. And indeed Autoconf does have some special casing for -D_XOPEN_SOURCE=500: AC_CACHE_CHECK([whether _XOPEN_SOURCE should be defined], [ac_cv_should_define__xopen_source], [ac_cv_should_define__xopen_source=no AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[ #include <wchar.h> mbstate_t x;]])], [], [AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[ #define _XOPEN_SOURCE 500 #include <wchar.h> mbstate_t x;]])], [ac_cv_should_define__xopen_source=yes])])]) test $ac_cv_should_define__xopen_source = yes && AC_DEFINE([_XOPEN_SOURCE], [500]) If musl needs _XOPEN_SOURCE for wchar.h, then it would be worth working around in QEMU. If it's just happening with ncurses, however, it'd be a musl bug, which should be fixed in musl or worked around in ncurses. Chad, can you check whether the programs below fails with musl: /* First program */ #define _GNU_SOURCE #include <wchar.h> mbstate_t x; /* Second program */ #include <wchar.h> mbstate_t x; /* Third program */ #define _XOPEN_SOURCE 500 #include <wchar.h> mbstate_t x; Just compile them with "gcc foo.c -O2". Thanks, Paolo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 11:11 ` Paolo Bonzini @ 2017-02-17 11:43 ` Chad Joan 0 siblings, 0 replies; 36+ messages in thread From: Chad Joan @ 2017-02-17 11:43 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Laszlo Ersek, qemu-devel, qemu-trivial Sure. I'll see your -O2 and raise you a -c ;) It went like this: $ gcc -c first.c -O2 $ gcc -c second.c -O2 $ gcc -c third.c -O2 No complaints from gcc whatsoever (unless I drop the -c, then ld complains about the undefined reference to main, which I think we all expect). Just incase you expected one of them to fail (ex: as a control test), I verified that the original snippet from the configure script still causes an error on the system: ######### $ cat << EOF > reference.c > #include <locale.h> > #include <curses.h> > #include <wchar.h> > int main(void) { > const char *s = curses_version(); > wchar_t wch = L'w'; > setlocale(LC_ALL, ""); > resize_term(0, 0); > addwstr(L"wide chars\n"); > addnwstr(&wch, 1); > add_wch(WACS_DEGREE); > return s != 0; > } > EOF $ gcc reference.c -O2 reference.c: In function 'main': reference.c:11:11: error: 'WACS_DEGREE' undeclared (first use in this function) add_wch(WACS_DEGREE); ^ reference.c:11:11: note: each undeclared identifier is reported only once for each function it appears in ######### Hope that helps. On Fri, Feb 17, 2017 at 6:11 AM, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On 17/02/2017 10:17, Laszlo Ersek wrote: > > Of course, *if* that other C library, and the Curses implementation, > > claim compatibility with glibc as far as _GNU_SOURCE goes, *then* I > > fully agree with you. (IOW, it depends on the condition that you > > formulated above, "if musl wants to support _GNU_SOURCE".) > > They at least try, since their features.h supports it. > > > Same for ncurses -- do they aim at SUSv2 conformance, or do they intend > > to consider _GNU_SOURCE specifically? > > Well, ncurses is a GNU project so I suppose they mostly care about > whatever Autoconf does. And indeed Autoconf does have some special > casing for -D_XOPEN_SOURCE=500: > > AC_CACHE_CHECK([whether _XOPEN_SOURCE should be defined], > [ac_cv_should_define__xopen_source], > [ac_cv_should_define__xopen_source=no > AC_COMPILE_IFELSE( > [AC_LANG_PROGRAM([[ > #include <wchar.h> > mbstate_t x;]])], > [], > [AC_COMPILE_IFELSE( > [AC_LANG_PROGRAM([[ > #define _XOPEN_SOURCE 500 > #include <wchar.h> > mbstate_t x;]])], > [ac_cv_should_define__xopen_source=yes])])]) > test $ac_cv_should_define__xopen_source = yes && > AC_DEFINE([_XOPEN_SOURCE], [500]) > > If musl needs _XOPEN_SOURCE for wchar.h, then it would be worth working > around in QEMU. If it's just happening with ncurses, however, it'd be a > musl bug, which should be fixed in musl or worked around in ncurses. > > Chad, can you check whether the programs below fails with musl: > > /* First program */ > #define _GNU_SOURCE > #include <wchar.h> > mbstate_t x; > > /* Second program */ > #include <wchar.h> > mbstate_t x; > > /* Third program */ > #define _XOPEN_SOURCE 500 > #include <wchar.h> > mbstate_t x; > > Just compile them with "gcc foo.c -O2". > > Thanks, > > Paolo > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 8:56 ` Paolo Bonzini 2017-02-17 9:17 ` Laszlo Ersek @ 2017-02-17 10:18 ` Peter Maydell 2017-02-17 11:20 ` Paolo Bonzini 1 sibling, 1 reply; 36+ messages in thread From: Peter Maydell @ 2017-02-17 10:18 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Laszlo Ersek, Chad Joan, QEMU Developers, QEMU Trivial On 17 February 2017 at 08:56, Paolo Bonzini <pbonzini@redhat.com> wrote: > So I do think that if musl wants to support _GNU_SOURCE, it should also auto-define; > however it doesn't, see https://git.musl-libc.org/cgit/musl/tree/include/features.h. Yes, I agree that this looks like a musl bug. I spoke to a musl developer I happen to know, and he agreed to submit a patch to see what the other musl devs think. In the meantime, we should probably work around this system bug for the benefit of the existing musl installs in the field. Defining _XOPEN_SOURCE is easy enough, and I think we should do it unconditionally. We should check what effect this has on the BSD hosts though I guess. (You could argue that we should be defining _XOPEN_SOURCE anyway for the benefit of the non-glibc BSD/Solaris/etc platforms.) thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 10:18 ` Peter Maydell @ 2017-02-17 11:20 ` Paolo Bonzini 2017-02-17 16:57 ` Peter Maydell 0 siblings, 1 reply; 36+ messages in thread From: Paolo Bonzini @ 2017-02-17 11:20 UTC (permalink / raw) To: Peter Maydell; +Cc: Laszlo Ersek, Chad Joan, QEMU Developers, QEMU Trivial On 17/02/2017 11:18, Peter Maydell wrote: > Defining _XOPEN_SOURCE is easy enough, and I think we should > do it unconditionally. We should check what effect this has > on the BSD hosts though I guess. (You could argue that we > should be defining _XOPEN_SOURCE anyway for the benefit of > the non-glibc BSD/Solaris/etc platforms.) Sounds good, then I think we should define it to 700 just like glibc does. Paolo ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 11:20 ` Paolo Bonzini @ 2017-02-17 16:57 ` Peter Maydell 2017-04-06 18:15 ` Rainer Müller 0 siblings, 1 reply; 36+ messages in thread From: Peter Maydell @ 2017-02-17 16:57 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Laszlo Ersek, Chad Joan, QEMU Developers, QEMU Trivial On 17 February 2017 at 11:20, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On 17/02/2017 11:18, Peter Maydell wrote: >> Defining _XOPEN_SOURCE is easy enough, and I think we should >> do it unconditionally. We should check what effect this has >> on the BSD hosts though I guess. (You could argue that we >> should be defining _XOPEN_SOURCE anyway for the benefit of >> the non-glibc BSD/Solaris/etc platforms.) > > Sounds good, then I think we should define it to 700 just like glibc does. Unfortunately this idea turns out to break OSX compiles, because on OSX saying _XOPEN_SOURCE=anything disables all the non-X/Open APIs (which you get by default, and some of which like mkdtemp we use). Looking at the manpage for Solaris https://www.freebsd.org/cgi/man.cgi?query=standards&apropos=0&sektion=0&manpath=SunOS+5.8&format=html it seems to also go with "_XOPEN_SOURCE means *only* those functions", though its mechanism for saying "and the other stuff too" is different (define __EXTENSION__). So perhaps we'd better stick with "only define this for Linux hosts". thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-17 16:57 ` Peter Maydell @ 2017-04-06 18:15 ` Rainer Müller 2017-04-06 18:36 ` Peter Maydell 0 siblings, 1 reply; 36+ messages in thread From: Rainer Müller @ 2017-04-06 18:15 UTC (permalink / raw) To: qemu-devel On 2017-02-17 17:57, Peter Maydell wrote: > On 17 February 2017 at 11:20, Paolo Bonzini <pbonzini@redhat.com> wrote: >> >> >> On 17/02/2017 11:18, Peter Maydell wrote: >>> Defining _XOPEN_SOURCE is easy enough, and I think we should >>> do it unconditionally. We should check what effect this has >>> on the BSD hosts though I guess. (You could argue that we >>> should be defining _XOPEN_SOURCE anyway for the benefit of >>> the non-glibc BSD/Solaris/etc platforms.) >> >> Sounds good, then I think we should define it to 700 just like glibc does. > > Unfortunately this idea turns out to break OSX compiles, > because on OSX saying _XOPEN_SOURCE=anything disables > all the non-X/Open APIs (which you get by default, and > some of which like mkdtemp we use). A bit late to this thread, but the original problem was also reported for Mac OS X with --enable-curses in MacPorts. The build fails with the same symptoms as in the original report. https://trac.macports.org/ticket/53929 As you identified, the problem is that ncurses expects the define _XOPEN_SOURCE >= 500 to enable the wide-char function declarations. The solution to retain access to non-standard API on Mac OS X would be to also define _DARWIN_C_SOURCE which enables extensions. $ cat foo.c #include <unistd.h> int main() { mkdtemp("/tmp/test-XXXXXX"); } $ cc -D_XOPEN_SOURCE=500 -c foo.c foo.c:4:5: warning: implicit declaration of function 'mkdtemp' is invalid in C99 [-Wimplicit-function-declaration] mkdtemp("/tmp/test-XXXXXX"); ^ 1 warning generated. $ cc -D_XOPEN_SOURCE=500 -D_DARWIN_C_SOURCE -c foo.c $ A quick test on current master with configure patched to define QEMU_CFLAGS="-D_XOPEN_SOURCE=500 -D_DARWIN_C_SOURCE $QEMU_CFLAGS" compiled fine for both a default configure and with --enable-curses. Rainer ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-04-06 18:15 ` Rainer Müller @ 2017-04-06 18:36 ` Peter Maydell 2017-06-02 13:58 ` Peter Maydell 0 siblings, 1 reply; 36+ messages in thread From: Peter Maydell @ 2017-04-06 18:36 UTC (permalink / raw) To: Rainer Müller; +Cc: QEMU Developers On 6 April 2017 at 19:15, Rainer Müller <raimue@codingfarm.de> wrote: > A bit late to this thread, but the original problem was also reported > for Mac OS X with --enable-curses in MacPorts. The build fails with the > same symptoms as in the original report. > > https://trac.macports.org/ticket/53929 > > As you identified, the problem is that ncurses expects the define > _XOPEN_SOURCE >= 500 to enable the wide-char function declarations. > > The solution to retain access to non-standard API on Mac OS X would be > to also define _DARWIN_C_SOURCE which enables extensions. Thanks for the report. I have a feeling that fixing this bug got lost somewhere -- there was a long thread about it but I don't think an actual patch ever came out of it :-( At this point (very near to release of 2.9) I think I'd rather postpone fixing this until after release. It should be possible to work around it with an --extra-cflags configure setting, and our current behaviour is something we've had for many releases now. thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-04-06 18:36 ` Peter Maydell @ 2017-06-02 13:58 ` Peter Maydell 0 siblings, 0 replies; 36+ messages in thread From: Peter Maydell @ 2017-06-02 13:58 UTC (permalink / raw) To: Rainer Müller; +Cc: QEMU Developers On 6 April 2017 at 19:36, Peter Maydell <peter.maydell@linaro.org> wrote: > On 6 April 2017 at 19:15, Rainer Müller <raimue@codingfarm.de> wrote: >> A bit late to this thread, but the original problem was also reported >> for Mac OS X with --enable-curses in MacPorts. The build fails with the >> same symptoms as in the original report. >> >> https://trac.macports.org/ticket/53929 >> >> As you identified, the problem is that ncurses expects the define >> _XOPEN_SOURCE >= 500 to enable the wide-char function declarations. >> >> The solution to retain access to non-standard API on Mac OS X would be >> to also define _DARWIN_C_SOURCE which enables extensions. > > Thanks for the report. I have a feeling that fixing this bug > got lost somewhere -- there was a long thread about it but I > don't think an actual patch ever came out of it :-( I've got back to looking at this, and it turns out that the situation is a complete mess. In particular, on OSX if you define _XOPEN_SOURCE=600 then it causes _POSIX_C_SOURCE to be set such that the getpagesize() prototype is not provided, and even if you set _DARWIN_C_SOURCE this does not override that. Similarly, on FreeBSD if you define _XOPEN_SOURCE then it doesn't provide any APIs that aren't in that standard and there is no provided mechanism at all to say "and also the FreeBSD APIs" please. My conclusion from this is that we must not set _XOPEN_SOURCE, but instead have to tell ncurses directly that we definitely want the widechar prototypes, by defining NCURSES_WIDECHAR. Since ncurses 20111030 this is sufficient I think; if you're still using an older ncurses then you'll need to upgrade it (older ncurses ignore NCURSES_WIDECHAR and only pay attention to _XOPEN_SOURCE_EXTENDED, etc). thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-16 16:30 [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems Chad Joan 2017-02-16 16:58 ` Paolo Bonzini @ 2017-02-16 16:59 ` Eric Blake 2017-02-16 17:05 ` Peter Maydell 2 siblings, 0 replies; 36+ messages in thread From: Eric Blake @ 2017-02-16 16:59 UTC (permalink / raw) To: Chad Joan, qemu-devel, qemu-trivial [-- Attachment #1: Type: text/plain, Size: 1258 bytes --] On 02/16/2017 10:30 AM, Chad Joan wrote: > Hello, > > This is a one-line patch to the configure script that will allow QEMU to be > built on musl-libc based Linux systems. This problem is only noticeable > when QEMU is built with --enable-curses. > > Detailed reading material if you want to know where this came from: > https://bugs.gentoo.org/show_bug.cgi?id=609364 > > Hope that helps! > - Chad > > > qemu-2.8.0-musl-ncurses.patch > Thanks for the patch. However, it is not in the usual format (we prefer 'git send-email's inline format, rather than attachements), and is missing a Signed-off-by: designation, so it cannot be applied without that being fixed first. More information at: http://wiki.qemu-project.org/Contribute/SubmitAPatch > > diff --git configure configure > index 1c9655e..9f83176 100755 > --- configure > +++ configure > @@ -682,6 +682,7 @@ Haiku) > vhost_net="yes" > vhost_scsi="yes" > vhost_vsock="yes" > + QEMU_CFLAGS="-D_XOPEN_SOURCE=500 $QEMU_CFLAGS" > QEMU_INCLUDES="-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers $QEMU_INCLUDES" > ;; > esac > -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems. 2017-02-16 16:30 [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems Chad Joan 2017-02-16 16:58 ` Paolo Bonzini 2017-02-16 16:59 ` Eric Blake @ 2017-02-16 17:05 ` Peter Maydell 2 siblings, 0 replies; 36+ messages in thread From: Peter Maydell @ 2017-02-16 17:05 UTC (permalink / raw) To: Chad Joan; +Cc: QEMU Developers, QEMU Trivial On 16 February 2017 at 16:30, Chad Joan <chadjoan@gmail.com> wrote: > Hello, > > This is a one-line patch to the configure script that will allow QEMU to be > built on musl-libc based Linux systems. This problem is only noticeable > when QEMU is built with --enable-curses. > > Detailed reading material if you want to know where this came from: > https://bugs.gentoo.org/show_bug.cgi?id=609364 Thanks for the bug report and the patch. I'm a bit confused about why it's necessary, though. We already define _GNU_SOURCE, which the musl docs say implies _XOPEN_SOURCE: https://www.musl-libc.org/doc/1.0.0/manual.html Is that not true for your musl, or is our configure script failing to pass -D_GNU_SOURCE when building the curses test program? If we do need an explicit define of _XOPEN_SOURCE I think we should do it at the same place where we add -D_GNU_SOURCE to the cflags. thanks -- PMM ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2017-06-02 13:59 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-16 16:30 [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems Chad Joan 2017-02-16 16:58 ` Paolo Bonzini 2017-02-16 17:23 ` Laszlo Ersek 2017-02-16 17:47 ` Chad Joan 2017-02-17 6:43 ` Fam Zheng 2017-02-17 9:23 ` Laszlo Ersek 2017-02-17 10:11 ` Fam Zheng 2017-02-17 9:28 ` Peter Maydell 2017-02-17 15:34 ` Eric Blake 2017-02-17 16:54 ` Chad Joan 2017-02-17 16:56 ` Peter Maydell 2017-02-17 16:57 ` Paolo Bonzini 2017-02-17 17:07 ` Chad Joan 2017-02-17 17:15 ` Peter Maydell 2017-02-19 7:22 ` Chad Joan 2017-02-19 12:12 ` Peter Maydell 2017-02-21 2:53 ` Eric Blake 2017-02-17 17:17 ` Eric Blake 2017-02-19 7:02 ` Chad Joan 2017-02-21 3:02 ` Eric Blake 2017-02-21 9:41 ` Markus Armbruster 2017-02-21 9:58 ` Peter Maydell 2017-02-17 18:13 ` John Snow 2017-02-17 8:45 ` Paolo Bonzini 2017-02-17 8:56 ` Paolo Bonzini 2017-02-17 9:17 ` Laszlo Ersek 2017-02-17 11:11 ` Paolo Bonzini 2017-02-17 11:43 ` Chad Joan 2017-02-17 10:18 ` Peter Maydell 2017-02-17 11:20 ` Paolo Bonzini 2017-02-17 16:57 ` Peter Maydell 2017-04-06 18:15 ` Rainer Müller 2017-04-06 18:36 ` Peter Maydell 2017-06-02 13:58 ` Peter Maydell 2017-02-16 16:59 ` Eric Blake 2017-02-16 17:05 ` Peter Maydell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.