On Mon, Mar 02, 2020 at 05:54:42PM +0100, Ján Tomko wrote:
> The commit summary is too generic.
> How about:
> rpc: getaddrinfo: also accept IPv4-mapped IPv6 addresses
>
> On a Monday in 2020, Zhimin Feng wrote:
> > If only IPv6 is configured and nscd is started, getaddrinfo
>
> Is ncsd required
The commit summary is too generic.
How about:
rpc: getaddrinfo: also accept IPv4-mapped IPv6 addresses
On a Monday in 2020, Zhimin Feng wrote:
If only IPv6 is configured and nscd is started, getaddrinfo
Is ncsd required to reproduce this?
Looking at glibc source:
libvirt passes AI_ADDRCONFIG
Apart from the WebUI-based review process which is rather painful (but I guess
anything is better than gerrit for that matter) and non-existent threading
within discussion topics, I agree to all the points, as having a nice SaaS
platform alleviating us from much of the maintenance burden is the way
On Mon, Mar 02, 2020 at 02:17:02PM +0100, Ján Tomko wrote:
> On a Monday in 2020, Daniel P. Berrangé wrote:
> > 1. Use gitlab.com as the location of the "master" git repositories
> >
> >Current committers to libvirt.org would have create accounts on
> > gitlab.com
> >and upload their SSH
On Mon, Mar 02, 2020 at 11:01:55AM +, Daniel P. Berrangé wrote:
[...]
> 9. Use gitlab.com merge requests for non-core projects
>
> This means every git repo that is not the core libvirt.org. All the
> language bindings, the other object mappings (libvirt-dbus/snmp/etc)
> and sup
On a Monday in 2020, Daniel P. Berrangé wrote:
1. Use gitlab.com as the location of the "master" git repositories
Current committers to libvirt.org would have create accounts on gitlab.com
and upload their SSH key.
No change in development workflow, merely update the "origin" URI.
If only IPv6 is configured and nscd is started, getaddrinfo
function reture value is -9. So hints.ai_flags should include
the AI_V4MAPPED flag.
The following is the partial implementation of getaddrinfo(glibc):
if (req->ai_family == AF_UNSPEC || req->ai_family == AF_INET)
at->family =
We've discussed the idea of moving to a GitForge before, with the debate
circling around the pros/cons of mailing list vs merge request workflows.
This mail is NOT focused on that particular debate, rather it is tackling the
much broader issue of libvirt project infrastructure consolidation, such
On Mon, Mar 02, 2020 at 09:17:27AM +0100, Michal Privoznik wrote:
> Libvirt tries to forbid migration onto the same host and it does
> that by checking if local and remote hostnames are the same and
> whether local and remote UUIDs are the same. Well, the latter
> makes sense but the former doesn't
On Mon, Mar 02, 2020 at 14:13:28 +0530, Gaurav Agrawal wrote:
> On review by Jan Tomko, for my earlier Patchv2, which had the return NULL
Please don't top-post on technical mailing lists.
> replace by the return conn ,
He told you the correct thing to do:
> here is the review:
> ```
> >+cleanup
On review by Jan Tomko, for my earlier Patchv2, which had the return NULL
replace by the return conn ,
here is the review:
```
>+cleanup:
> return conn;
>
> error:
> virDispatchError(NULL);
>-virObjectUnref(conn);
'conn' is still not marked as g_auto, so this unref needs to stay.
>
On Mon, Mar 02, 2020 at 07:22:03 +0530, Gaurav Agrawal wrote:
> Signed-off-by: Gaurav Agrawal
> ---
> src/admin/libvirt-admin.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
[...]
> @@ -251,16 +251,11 @@ virAdmConnectOpen(const char *name, unsigned int flags)
> i
Libvirt tries to forbid migration onto the same host and it does
that by checking if local and remote hostnames are the same and
whether local and remote UUIDs are the same. Well, the latter
makes sense but the former doesn't really because libvirtd can be
running inside an UTS namespace and hostna
13 matches
Mail list logo
