Even Fedora is no longer shipping the WiMAX SDK, so it's likely we'll
eventually accidentally break some of the code in src/devices/wimax/
(if we haven't already). Discussion on the list showed a consensus for
dropping support for WiMAX.
So, remove the SDK checks from configure.ac, remove the WiMAX device
plugin and associated manager support, and deprecate all the APIs.
For compatibility reasons, it is still possible to create and save
WiMAX connections, to toggle the software WiMAX rfkill state, and to
change the "WIMAX" log level, although none of these have any effect,
since no NMDeviceWimax will ever be created.
nmcli was only compiling in support for most WiMAX operations when NM
as a whole was built with WiMAX support, so that code has been removed
now as well. (It is still possible to use nmcli to create and edit
WiMAX connections, but those connections will never be activatable.)
Before, the Wi-Fi plugin was always build. Users who didn't want
to use it would simply drop "libnm-device-plugin-wifi.so".
Add a compile time option to disable needlessly building the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=743388
If a connection has an associated "rule-NAME" or "rule6-NAME" file,
don't try to read in the routes, since NetworkManager won't be able to
parse them correctly. Instead, log a warning that they will need to be
applied via a dispatcher script, and provide a script that would do
that in examples/dispatcher/.
Team was split out between NM 0.9.10 and NM 1.0 after the other
sub-packages, so the existing obsoletes won't work for it (they
would cause all upgrades to install all sub-packages, instead
of replacing existing sub-packages without adding uninstalled
ones). We only want to unconditionally add the team sub-package.
s390 does not enable several device plugins, but ADSL and Wi-Fi
plugins are still build. They must be excluded in the spec file,
otherwise rpmbuild fails.
This partly reverts commit 1f631cd08d.
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/NetworkManager-1.1.0-11242.9709d009d5.el7.s390x
RPM build errors:
error: Installed (but unpackaged) file(s) found:
/usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
/usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Installed (but unpackaged) file(s) found:
/usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
/usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Child returncode was: 1
On s390/s390x we would disable hardware plugins, especially %{with_bluetooth} and
%{with_wwan}. Depending on that we would set 'BuildRequires: ModemManager-glib-devel'.
This was not corresponding to the '--with-modem-manager-1' configure
option, hence we did not have ModemManager-glib-devel, but
'--with-modem-manager-1=yes'
When quitting, the Manager asks each device to spawn the interface helper,
which persists and manages dynamic address on the interface after NetworkManager
is gone. If the dynamic address cannot be maintaned, the helper quits and
the interface's address may be removed when their lifetime runs out.
To keep the helper as simple as possible, NetworkManager passes most of the
configuration on the command-line, including some properties of the device's
current state, which are necessary for the helper to maintain DHCP leases
or IPv6 SLAAC addresses.
In case of a missing NetworkManager.conf (or a missing configuration option
main.plugins), allow to determine the fallback at compile time
https://bugzilla.gnome.org/show_bug.cgi?id=738611
Signed-off-by: Thomas Haller <thaller@redhat.com>
The revision number of the RPM (as build by contrib/rpm) should
be increasing so that newer packages can be installed using
`yum install` and older packages can be downgraded using
`yum downgrade`.
By counting only --first-parent, the following example turns
out wrong. Note the duplicate revision numbers.
-- A(100)----------------------------F(101)----G(102)
\ /
B(101)----C(102)----D(103)----E(104)
Just count *all* parent commits
This adds service discovery via SDP and RFCOMM tty management to
NetworkManager, as it was dropped from Bluez.
Based on work by Dan Williams <dcbw@redhat.com>.
The SDP discovery is based on code from Bluez project.
This makes NetworkManager independent of <polkit/polkit.h>
development headers and libpolkit-gobject-1.so library.
Instead communicate directly with polkit using its DBUS
interface.
PolicyKit support is now always compiled in. You can control
polkit authorization with the configuration option
[main]
auth-polkit=yes|no
If the configure option is omitted, a build time default
value is used. This default value can be set with the
configure option --enable-polkit.
This commit adds a new class NMAuthManager that reimplements the
relevant DBUS client parts. It takes source code from the polkit
library.
https://bugzilla.gnome.org/show_bug.cgi?id=734146
Signed-off-by: Thomas Haller <thaller@redhat.com>
The module is used for building man pages by generate-plugin-docs.pl script.
1c2174a libnm-util: generate-plugin-docs.pl script for extracting plugin docs
Add libnm to NetworkManager.spec, and try to update the descriptions
of NetworkManager-devel, NetworkManager-glib, and
NetworkManager-glib-devel to make sense in the libnm world...
Create a new clients/ subdirectory at the top level, and move cli/ and
tui/ into it, as well as nm-online.c (which was previously in test/,
which made no sense).
cli/ was split into two subdirectories, src/ and completion/. While
this does simplify things (given that the completion file and the
binary both need to be named "nmcli"), it bloats the source tree, and
we can work around it by just renaming the completion file at install
time. Then we can combine the two directories into one and just have
it all under clients/cli/.
There are three fixes:
1) the config packages shouldn't require the main NetworkManager
package. We explicitly make NetworkManager-glib not
depend on NM itself to ensure that clients can link to it (and thus
have an RPM dependency on -glib) without pulling in NetworkManager
itself. The same should hold true for the config packages, since
consumers of NetworkManager may want to pull them in, but not
necessarily pull NetworkManager in.
For example, GNOME Shell wants to make use of NetworkManager's
connectivity detection *if NM is available*, and this requires
pulling in NM-config-connectivity-fedora, but that shouldn't
pull in NetworkManager itself.
Similarly, we had a problem with RHEL7 making sure that
NM-config-server was installed by default on Server variants but
not on other variants; removing the dependency from the -config
subpackage was the cleanest way to fix that.
Furthermore, nothing in the config sub-packages actually
requires NetworkManager anyway since they are simply config files.
2) nmtui doesn't care what architecture the running NM is since
it communicates solely over D-Bus. So skip the %{?_isa}, just
like we do for other clients (nm-applet, GNOME Shell, etc)
3) Requiring NetworkManager.%{?_isa} from the -devel package
has problems with multilib (see rh #1112367). This is an issue
if you install a 32-bit development environment and try to build
something that uses NetworkManager. Since the -devel package
requires the main package, you can end up either having *both*
NetworkManager.i686 and NetworkManager.x86_64 installed, or you
end up having NetworkManager.i686 replace NetworkManager.x86_64.
Neither one is good. So remove the %{?_isa} bit.
Before, build_clean.sh always required building all NetworkManager
and doing another `make distcheck` before calling rpmbuild.
That is still a good idea, to ensure that we get a proper build.
For some quick testing however, lets speed this up with a new
--dist argument that only calls `make dist`.
Signed-off-by: Thomas Haller <thaller@redhat.com>
