On Mon, Jan 25, 2016 at 02:46:54AM +, Vincent Fortier wrote:
> I was wondering how can I create a tap interface using nmcli? Search again
> and again witouth luck...
Hi,
creation of tun/tap devices is supported only in NetworkManager 1.2.
On such version you can create a tap connection using
On Sun, 2016-01-24 at 23:02 +0100, Matthias Berndt wrote:
> Hi,
>
> I've been thinking about the code that I recently modified. The
> handle_blob_item function checks if the blob markers (BEGIN
> CERTIFICATE etc.) are present and returns false without consuming
> any lines if they're missi
Thnx. So lets say I previously created a bridge interface and linked in my
eth0:
$ nmcli connection show
$ nmcli connection delete
$ nmcli connection add type bridge \
ifname br0 con-name br0
$ nmcli connection add type bridge-slave \
ifname eth0 con-name eth0 master br0
Presum
On Sat, 2016-01-23 at 19:07 +0100, Thomas Haller wrote:
> We want to specify the min/max version requirements for libnm-gtk
> (the
> user of libnm-glib), not for libnm-glib itself.
>
> Fixes: a0d4d15ed22fff2ed856ca6291812e96374afc94
>
> https://mail.gnome.org/archives/networkmanager-list/2016-Jan
On Mon, 2016-01-25 at 12:21 +, Vincent Fortier wrote:
> Thnx. So lets say I previously created a bridge interface and linked
> in my
> eth0:
> $ nmcli connection show
> $ nmcli connection delete
> $ nmcli connection add type bridge \
> ifname br0 con-name br0
> $ nmcli connection add
On Mon, 2016-01-25 at 10:08 -0600, Dan Williams wrote:
>
> So I'm thinking that LIBNM_CFLAGS is correct, but since NMA_CFLAGS
> isn't used anywhere and since LIBNM_GLIB_CFLAGS is used but isn't
> defined anywhere, that s/NMA_CFLAGS/LIBNM_GLIB_CFLAGS is the right
> thing to do?
I agree.
Merged:
>From 2370f508df8400b424fec032f8314cea97fdbaef Mon Sep 17 00:00:00 2001
From: Dan Williams
Date: Wed, 20 Jan 2016 13:52:59 -0600
Subject: [PATCH] dns: clean up error paths in dns-manager
Specifically for resolvconf, if the write succeeded, but the pclose()
failed error would be left NULL and SR_E
Drivers are stupid, and just like the platform ignores an all zeros
permanent address, so should it ignore all ones.
NetworkManager[509]: [1453743778.854919] [devices/nm-device.c:8885]
nm_device_update_hw_address(): [0x190370] (eth0): hardware address now
86:18:52:xx:xx:xx
NetworkManager[509]:
On Mon, Jan 25, 2016 at 01:05:17PM -0600, Dan Williams wrote:
> Drivers are stupid, and just like the platform ignores an all zeros
> permanent address, so should it ignore all ones.
>
> --- a/src/platform/nm-platform-utils.c
> +++ b/src/platform/nm-platform-utils.c
> @@ -142,7 +142,8 @@ nmp_utils_
On Sun, 2016-01-24 at 23:02 +0100, Matthias Berndt wrote:
>
> Oh, and there's another thing: afaics, if you don't use inline blobs
> but files for the certificate/key/ca, nm-openvpn will not copy them
> somewhere safe (~/.cert, say) – bad idea. Jane User will plug in her
> USB stick, import her Op
On Mon, Jan 25, 2016 at 12:59:22PM -0600, Dan Williams wrote:
> From 2370f508df8400b424fec032f8314cea97fdbaef Mon Sep 17 00:00:00 2001
> From: Dan Williams
> Date: Wed, 20 Jan 2016 13:52:59 -0600
> Subject: [PATCH] dns: clean up error paths in dns-manager
>
> Specifically for resolvconf, if the w
If the hostname file is a symbolic link, resolve the link until the
real file is located, otherwise g_file_set_contents will attempt to
replace the link with a plain file.
---
src/settings/nm-settings.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/setting
If the hostname file is a symbolic link, follow it to find where the
real file is located, otherwise g_file_set_contents will attempt to
replace the link with a plain file.
---
src/settings/nm-settings.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/settin
13 matches
Mail list logo