On Wed, Feb 6, 2013 at 4:57 AM, Nick Jones nick.fa.jo...@gmail.com wrote:
On Tue, Jan 29, 2013 at 9:47 PM, Miloslav Trmač m...@volny.cz wrote:
On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones nick.fa.jo...@gmail.com wrote:
As a quick summary: I would suggest, in addition to addressing
the
- Original Message -
From: Nick Jones nick.fa.jo...@gmail.com
In the summary of this Fedora feature for fixing name resolution is
this snippet: Fedora could be seen as the leader in linux networking
Yep. My intention to improve the overall networking features is not limited to
what is
On Tue, Jan 29, 2013 at 9:47 PM, Miloslav Trmač m...@volny.cz wrote:
Hello,
just a minor point, not getting into the wider should getaddrinfo()
be the primary interface debate...
On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones nick.fa.jo...@gmail.com wrote:
As a quick summary: I would suggest,
Hello,
just a minor point, not getting into the wider should getaddrinfo()
be the primary interface debate...
On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones nick.fa.jo...@gmail.com wrote:
As a quick summary: I would suggest, in addition to addressing
the outstanding bugs and issues covered by the
On Mon, Jan 21, 2013 at 6:25 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Fri, Jan 18, 2013 at 09:37:37AM +0800, Nick Jones wrote:
On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote:
As the Feature was renamed and the content of Feature has been extended
as requested by
On 01/23/2013 07:31 PM, John Reiser wrote:
On 01/23/2013 10:35 AM, Dan Williams wrote:
On Wed, 2013-01-23 at 09:48 -0800, John Reiser wrote:
The signal handler can write a packet into a pipe from the process to
itself,
and that can be hooked up to an event loop API.
Clearly. But then
On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
On Mon, 21.01.13 10:25, Daniel P. Berrange (berra...@redhat.com) wrote:
The glibc maintainers don't seem to be against this idea and I am
willing to put time into design and implementation.
Perhaps I'm misunderstanding what
On Wed, Jan 23, 2013 at 11:24:25AM -0600, Dan Williams wrote:
On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
On Mon, 21.01.13 10:25, Daniel P. Berrange (berra...@redhat.com) wrote:
The glibc maintainers don't seem to be against this idea and I am
willing to put time
On 01/23/2013 09:27 AM, Daniel P. Berrange wrote:
On Wed, Jan 23, 2013 at 11:24:25AM -0600, Dan Williams wrote:
On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
On Mon, 21.01.13 10:25, Daniel P. Berrange (berra...@redhat.com) wrote:
The glibc maintainers don't seem to be against
On Wed, 2013-01-23 at 09:48 -0800, John Reiser wrote:
On 01/23/2013 09:27 AM, Daniel P. Berrange wrote:
On Wed, Jan 23, 2013 at 11:24:25AM -0600, Dan Williams wrote:
On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
On Mon, 21.01.13 10:25, Daniel P. Berrange (berra...@redhat.com)
On Wed, 23.01.13 12:35, Dan Williams (d...@redhat.com) wrote:
Bh. It's designed around process signal delivery. I am
shuddering.
Ew. Signals are not an event loop API. Signals are not an event loop
API. Signals are not an event loop API. But apparently that's hard for
On 01/23/2013 10:35 AM, Dan Williams wrote:
On Wed, 2013-01-23 at 09:48 -0800, John Reiser wrote:
The signal handler can write a packet into a pipe from the process to itself,
and that can be hooked up to an event loop API.
Clearly. But then you have to deal with signal handling and all the
On Mon, 21.01.13 10:25, Daniel P. Berrange (berra...@redhat.com) wrote:
The glibc maintainers don't seem to be against this idea and I am
willing to put time into design and implementation.
Perhaps I'm misunderstanding what you're after, but doesn't getaddrinfo_a
already provide an async
On Fri, Jan 18, 2013 at 09:37:37AM +0800, Nick Jones wrote:
On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote:
As the Feature was renamed and the content of Feature has been extended
as requested by FESCo, re-announcing it to the community for re-review.
See
On Wed, Jan 16, 2013 at 6:38 PM, Sam Varshavchik mr...@courier-mta.com wrote:
Jaroslav Reznik writes:
See https://fedorahosted.org/fesco/ticket/986
= Features/Fix Network Name Resolution =
https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
Why would this be a Fedora issue or
On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote:
As the Feature was renamed and the content of Feature has been extended
as requested by FESCo, re-announcing it to the community for re-review.
See https://fedorahosted.org/fesco/ticket/986
= Features/Fix Network Name Resolution =
As the Feature was renamed and the content of Feature has been extended
as requested by FESCo, re-announcing it to the community for re-review.
See https://fedorahosted.org/fesco/ticket/986
= Features/Fix Network Name Resolution =
https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
Jaroslav Reznik writes:
See https://fedorahosted.org/fesco/ticket/986
= Features/Fix Network Name Resolution =
https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
Why would this be a Fedora issue or a feature?
Seems to me this falls squarely inside the scope of glibc, and it
= Features/Fix Network Name Resolution =
https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
Why would this be a Fedora issue
Isn't glibc used in Fedora for name resolution?
or a feature?
See https://fedoraproject.org/wiki/Features/FixNetworkNameResolution#Rationale
Seems
As the Feature was renamed and the content of Feature has been extended
as requested by FESCo, re-announcing it to the community for re-review.
See https://fedorahosted.org/fesco/ticket/986
= Features/Fix Network Name Resolution =
https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
20 matches
Mail list logo
