On 6 April 2017 at 19:36, Peter Maydell wrote:
> On 6 April 2017 at 19:15, Rainer Müller 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.
>>
>> htt
On 6 April 2017 at 19:15, Rainer Müller 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 identifi
On 2017-02-17 17:57, Peter Maydell wrote:
> On 17 February 2017 at 11:20, Paolo Bonzini 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 th
On 21 February 2017 at 09:41, Markus Armbruster wrote:
> Eric Blake 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 h
Eric Blake 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
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 thi
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
On 19 February 2017 at 07:22, Chad Joan 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 per
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
On Fri, Feb 17, 2017 at 12:17 PM, Eric Blake 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!
> >
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 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 pag
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
On 17 February 2017 at 16:54, Chad Joan 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 clie
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 wrote:
>
>
> On 17/02/2017 17:54, Chad Joan wrote:
> > Regarding the signature: IIRC, setting up certificates on a machine
> > using gp
On 17 February 2017 at 11:20, Paolo Bonzini 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 b
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 possi
On 17 February 2017 at 16: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.
There is no requirement for gpg (except for maintainers submitting
pull req
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 fi
On 02/17/2017 03:28 AM, Peter Maydell wrote:
> On 17 February 2017 at 06:43, Fam Zheng 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
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 expec
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
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 _G
On 17 February 2017 at 08:56, Paolo Bonzini 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
de
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/SubmitAPat
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
On 17 February 2017 at 06:43, Fam Zheng 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 th
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-
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 notice
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?
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 he
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 exa
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.
>
On 16 February 2017 at 16: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
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
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
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
36 matches
Mail list logo