[PATCH] nmcli: Made nmcli build optional

[Joel Holdsworth]

Hi, here's a patch to make the nmcli build optional. In my use-case I 
need to cross-build NetworkManager, and I don't want to have to 
cross-build GNU readline for a binary I don't need.


Best Regards
Joel Holdsworth
>From 6e0b258f7cea23834677be4f4ea85d46d7316114 Mon Sep 17 00:00:00 2001
From: Joel Holdsworth 
Date: Wed, 12 Aug 2015 23:40:35 +0100
Subject: [PATCH] nmcli: Made nmcli build optional

---
 clients/cli/Makefile.am |  4 
 configure.ac| 11 ---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/clients/cli/Makefile.am b/clients/cli/Makefile.am
index eef99cb..a2250ad 100644
--- a/clients/cli/Makefile.am
+++ b/clients/cli/Makefile.am
@@ -1,3 +1,5 @@
+if BUILD_NMCLI
+
 bin_PROGRAMS = \
 	nmcli
 
@@ -71,3 +73,5 @@ uninstall-hook:
 	rm -f $(DESTDIR)$(completiondir)/nmcli
 
 EXTRA_DIST += nmcli-completion
+
+endif
diff --git a/configure.ac b/configure.ac
index 7b4ca9a..3df98a1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -531,9 +531,6 @@ PKG_CHECK_MODULES(LIBNL, libnl-3.0 >= 3.2.8)
 # uuid library
 PKG_CHECK_MODULES(UUID, uuid)
 
-dnl Checks for readline library - used by nmcli
-AX_LIB_READLINE
-
 # Teamd control checks
 PKG_CHECK_MODULES(LIBTEAMDCTL, [libteamdctl >= 1.9], [have_teamdctl=yes],[have_teamdctl=no])
 AC_ARG_ENABLE(teamdctl, AS_HELP_STRING([--enable-teamdctl], [enable Teamd control support]),
@@ -860,6 +857,14 @@ AM_CONDITIONAL(WITH_CONCHECK, test "${enable_concheck}" = "yes")
 
 PKG_CHECK_MODULES(LIBNDP, [libndp])
 
+AC_ARG_WITH(nmcli, AS_HELP_STRING([--with-nmcli=yes|no], [Build nmcli]))
+if test "$with_nmcli" != no; then
+AX_LIB_READLINE
+else
+build_nmcli=no
+fi
+AM_CONDITIONAL(BUILD_NMCLI, test "$build_nmcli" = yes)
+
 AC_ARG_WITH(nmtui, AS_HELP_STRING([--with-nmtui=yes|no], [Build nmtui]))
 if test "$with_nmtui" != no; then
 PKG_CHECK_MODULES(NEWT, [libnewt >= 0.52.15], [build_nmtui=yes], [build_nmtui=no])
-- 
1.9.1

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Approaching NetworkManager 1.2

[Dan Williams]

On Fri, 2015-11-13 at 21:38 +0100, Olaf Hering wrote:
> On Mon, Nov 02, Lubomir Rintel wrote:
> 
> > If anyone believes anything important is missing it's a good time
> > to
> > speak up now.
> 
> The interface for scripts in /etc/NetworkManager/dispatcher.d/ is in
> a
> poor state. IMO there are likle two ways how third party apps
> interact
> with NM: either they receive "events" via the dispatcher hooks, or
> they
> are a dbus client. I dont know much about the latter, thats why I
> assume
> that an app is notified via dbus and get to the "full state" of NM
> via
> dbus. I assume such app does not need dispatcher events.
> 
> For apps/scripts called via the dispatcher interface the event should
> be
> a snapshot of the "full state". But instead they just get some "hey,
> something happend" event with an incomplete chunk of info.
> Essentially
> they are forced to make some sense of this incomplete chunk of info
> and
> maintain the state on their own. This is cumbersome and the amount of
> work
> to get this right is equal to turn them into full dbus apps and grab
> all
> the info from there. For short, the even must include the full info.
> 
> Examples:
> The remote VPN gateway sometimes drops the connection, or the router
> reconnects and gets a new public address. As a result openvpn
> reconnects. The reconnect event does not include the VPN route info,
> just the IPv4 address data. I'm sure NM still knows the routes, but I
> have not looked in dbus whats actually in there.

Can you grab some debug output from the dispatcher when this happens? 
 You can run the dispatcher like so:

nm-dispatcher --debug --persist

and it'll dump out exactly what it's sending to the scripts in the
environment.  Scripts should get a "vpn-down" without much info
(because the connection is already gone) and then a "vpn-up" with all
the addresses and routes in the environment.  If not, then its a bug.

> The bridge interface does dhcp, and the "up/dhcp4-change/dhcp6
> -change"
> events contain the desired info. But because its a bridge there is
> also
> the ethN slave. Most of the time its event carries no info. But it
> happend two times during boot that ethN instead of br0 carried the
> address info. Since my scripts have to ignore ethN the required info
> was
> essentially lost and the system in a wedged state.

Again, if you can get dispatcher debugging that would be great.  Slaves
should never have IP information *unless it's been added externally to
NM* by something, since they are slaves.

Dan

> Please either fix this, or document it clearly in NetworkManager(8)
> that
> the environment info for each event may be incomplete.
> 
> Olaf
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Approaching NetworkManager 1.2

[Olaf Hering]

On Tue, Nov 03, poma wrote:

> Please bring the bridges back to network-manager-applet!

Thanks for finding this...

The current way of how things are broken is that even if a bridge is
active the GNOME GUI still wants to manage a "cabled connection". But
instead of actually doing that it tries to fiddle with the slave of the
bridge instead of the bridge itself. As a result one gets two
connections: one is the bridge with its slave, and another one for eth0.

Please break things properly...


Olaf
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Approaching NetworkManager 1.2

[Olaf Hering]

On Mon, Nov 02, Lubomir Rintel wrote:

> If anyone believes anything important is missing it's a good time to
> speak up now.

The interface for scripts in /etc/NetworkManager/dispatcher.d/ is in a
poor state. IMO there are likle two ways how third party apps interact
with NM: either they receive "events" via the dispatcher hooks, or they
are a dbus client. I dont know much about the latter, thats why I assume
that an app is notified via dbus and get to the "full state" of NM via
dbus. I assume such app does not need dispatcher events.

For apps/scripts called via the dispatcher interface the event should be
a snapshot of the "full state". But instead they just get some "hey,
something happend" event with an incomplete chunk of info. Essentially
they are forced to make some sense of this incomplete chunk of info and
maintain the state on their own. This is cumbersome and the amount of work
to get this right is equal to turn them into full dbus apps and grab all
the info from there. For short, the even must include the full info.

Examples:
The remote VPN gateway sometimes drops the connection, or the router
reconnects and gets a new public address. As a result openvpn
reconnects. The reconnect event does not include the VPN route info,
just the IPv4 address data. I'm sure NM still knows the routes, but I
have not looked in dbus whats actually in there.

The bridge interface does dhcp, and the "up/dhcp4-change/dhcp6-change"
events contain the desired info. But because its a bridge there is also
the ethN slave. Most of the time its event carries no info. But it
happend two times during boot that ethN instead of br0 carried the
address info. Since my scripts have to ignore ethN the required info was
essentially lost and the system in a wedged state.


Please either fix this, or document it clearly in NetworkManager(8) that
the environment info for each event may be incomplete.

Olaf
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list