"build_clean.sh" is used to generate a distribution tarball. The tarball
contains pregenerated man pages with default values for paths, which in
turn depend on the configure options when creating the tarball.
Previously, the man page would have paths like "usr/local/etc/NetworkManager/...",
which doesn't seem the best choice for a default man page.
Explicitly set the installation paths.
Also, --disable-dependency-tracking in this mode. It may speed up the
build.
We configurably use --enable-gtk-doc/--disable-gtk-doc, but
we always require --enable-introspection (due to --enable-vala).
Add the missing build requirement to the "xsltproc" binary, which is in
libxslt package.
When we create a source tarball, documentation and other generated files
are disted. Those files depend on the configure options when creating
the tarball. For example, the generated man pages contain the compile time
configurable default values.
For that reason, it is generally better to regenerate the documentation when
building NetworkManager. However, let's set explict configure options to
have a more reproducible way to generate the tarball.
When doing a release, you should not just call `make dist`. Instead, the
proper way of creating an official source tarball is:
$ ./contrib/fedora/rpm/build_clean.sh --srpm
Since commit "c920909 contrib/rpm: put translations in
NetworkManager-libnm and NetworkManager-glib packages", both
subpackages install the same translation files without a direct
dependency between the two packages. Thus, if a user tries
to update only one of the two subpackages, it will fail
during the installation due to conflicting files.
Fix that by having the subpackages conflict (per version).
This way, the conflict is detected before starting the
installation.
https://bugzilla.redhat.com/show_bug.cgi?id=1406454
(cherry picked from commit b85b8ed6fa)
The ppp package split was introduced during 1.5.3 development. Thus,
we obsolete packages < 1:1.5.3.
Also, add conditionals around ppp-devel build-requirement.
- `make dist` requires --enable-gtk-doc --enable-introspection --with-libnm-glib
- --enable-gtk-doc requires --enable-introspection
- --with-nmcli requires either --enable-introspection or pregenerated
settings-docs.c files from the dist tarball. It does not require
--enable-gtk-doc.
There is a bit of a problem in that --enable-introspection requires
now xsltproc. However, gobject-introspection does itself not depend
on xsltproc. So, more correct might be a special --enable-doc argument,
that combines --enable-introspection --with-xsltproc. Anyway, that
seems to make it more complicated then it already is so just implicitly
(and surprisingly?) require xsltproc with --enable-introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=775003
# rpm -qf /usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-online.service
NetworkManager-1.5.2-16352.e0c50a9703.fc24.x86_64
# rpm -qf /usr/lib/systemd/system/network-online.target.wants
file /usr/lib/systemd/system/network-online.target.wants is not owned by any package
One can install the libraries without NetworkManager. Thus, the
translations should be there.
Doing this increases the package size of the libraries significantly.
For a user who only has libnm without NetworkManager installed, this
is acceptable, because the whole point of the change is to ensure such
a user also gets translations.
For a user who requires libnm and libnm-glib packages, this
unfortunately increases the additional package size as the translations
are now present twice.
What would be better is if NetworkManager-libnm would only contain
translations for libnm/NetworkManager, and NetworkManager-glib only
translations for libnm-util/libnm-glib.
Back this out. It breaks i686 build unnecessarily now and also is
something that proabably that should run on distcheck and not package
build.
This reverts commit cf678811b5.
This allows to get rid of the dhclient requirement of NetworkManager
package and moves the package dependency to the new sub package
NetworkManager-config-dhcp-dhclient.
For the moment, I think dhclient should still be the default choice for
regular users due to dhclient providing better better previledge separation
of network facing code. A user who knows that he's doing, can now however
remove dhclient while keeping NetworkManager.
https://bugzilla.redhat.com/show_bug.cgi?id=1204226
In case, where both
%global snapshot git20160606
%global git_sha b769b4df
is set, they version number should be
.git20160606.b769b4df
not
.b769b4df.git20160606
There are valid failures, for which sanitizer would kill
NetworkManager:
audit[1380]: AVC avc: denied { setrlimit } for pid=1380 comm="NetworkManager" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=process permissive=0
NetworkManager[1380]: ==1380==ERROR: AddressSanitizer setrlimit() failed 13
Disable sanitizer to make debug builds working again, at least for now.
This adds two new options to the configure scripts to compile NM,
clients and libraries with the address and undefined-behavior
sanitizers available in recent GCC versions. Clang is not supported at
moment.
rpmdiff complains:
Subpackage NetworkManager-bluetooth on aarch64 x86_64 ppc64 ppc64le s390x
consumes library libnm-wwan.so()(64bit) from subpackage NetworkManager-wwan
but does not have explicit package version requirement.
Please add Requires: NetworkManager-wwan = %{version}-%{release} to
NetworkManager-bluetooth in the specfile to avoid the need to test
interoperability between the various combinations of old and new subpackages.
And indeed, device plugins don't have a stable API/ABI, and requires
exact NetworkManager and wwan versions. This was already enforced implicitly,
because all device plugins require the same exact NetworkManager version.
Like we do on RHEL. The package-split was originally necessary because
installing a pre-up dispatcher script would block activation (even if there
were no relevant route files.
Even if we have now the no-wait.d/ directory for dispatchers, still
split the package. It makes sense to have the routing-rules in a
separate RPM.
For contrib/rpm, we don't properly obsolete an older version of
NetworkManager package and thus the upgrade path will be broken.
When the user neither specifies SOURCE or SOURCE_FROM_GIT,
we first want to detect a tarball in the current directory,
and as second fallback to SOURCE_FROM_GIT=1.
If either SOURCE or SOURCE_FROM_GIT is set, we want to do
that and not detect anything.
The logic was wrong.
Presiouvly, when there was a tarball file in the top git-tree, it would
have been choosen and no easy way to overwrite the decision to build
from a git-archive. Now you can safely build current HEAD by simply calling
./contrib/fedora/rpm/build_clean.sh -g
Contrary to the regular build which calls `make dist`, this doesn't
require a clean working copy and no need to purge it with git-clean.
- when user provided a $SOURCE argument, do call abs_path on
it. abs_path allows the user to provide relative paths in
the original directory.
- don't call abs_path on "$GITDIR/NetworkManager-$VERSION".tar.xz
abs_path is there to verify user input and it will abort the script
if the file doesn't exist.
- when creating a temporary tarball via git-archive, put it
into the output directory and not overwriting files in
$GITDIR.
- fix abs_path to return an error code and let callers abort
the script
- add a new parameter $SOURCE_FROM_GIT so that you can control
whether git-archive is used. You can now specify either $SOURCE
or $SOURCE_FROM_GIT. In case of absence of both, it tries to
detect a tar file in the $GITDIR directory.
Fixes: 9e9ec1a3da
Also add a new conditional "debug" to enable more assertions and
more logging, which is disabled by default.
Also add a conditional "test" to disable running the unit tests
(make check) while building the package.
http://rpm.org/wiki/PackagerDocs/ConditionalBuilds
The main reason to introduce the "no-wait.d" dispatcher directory was
"10-ifcfg-rh-routes.sh", which (as a pre-up script) delays activation.
We even extracted the script to a separate package on RHEL to avoid
delays by default.
Invoke the script via no-wait.d.
Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
NetworkManager-devel package contained development headers that
are useful without libnm-glib and without glib. But it is also
based on the legacy libnm-glib library as it has headers like
"/usr/include/NetworkManager/NetworkManager.h".
A glib-free devel package based on the new libnm library would
be needed to provide "/usr/include/libnm/nm-dbus-interface.h".
But that would amount to 4 devel packages. Instead, just move
the content of NetworkManager-devel into NetworkManager-glib-devel
package.
Note that NetworkManager-devel already contained several truely
libnm-glib dependent files, like the vala bindings (which require
libnm-glib). So that was another bug in the packaging and is fixed
by moving it all to NetworkManager-glib-devel.
https://bugzilla.gnome.org/show_bug.cgi?id=755938
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
Without that DATADIRNAME was not present in po/Makefile.in.in
and it resulted in /usr/\@DATADIRNAME\@/locale/cs/LC_MESSAGES/ path instead of
/usr/share/locale/cs/LC_MESSAGES/.
https://bugzilla.redhat.com/show_bug.cgi?id=1265117
When a script is a symbolic link to the 'no-wait.d' subdirectory, the
dispatcher now schedules it immediately and in parallel with other
no-wait scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=746703
The default SELinux policy on current RHEL and Fedora distributions
does not allow for NetworkManager to use audit. Hence, unless the user
changes the SELinux policy it will not work.
Disable auditing by default, but have it compiled so that the user can
enable it via "NetworkManager.conf".
Introduce some primitives to deliver messages about relevant
configuration changes to the Linux audit subsystem through libaudit
(if enabled at build time) and to the logging system.
NMVpnPluginInfo is little more then a wrapper around
the GKeyFile that describes the VPN plugin settings,
i.e. the name files under "/etc/NetworkManager/VPN/".
Add this class to make the VPN API more explicit. Clients
now can use NMVpnPluginInfo instead of concerning themselves
with loading the keyfile and the meaning of its properties.
Also add support for a new VPN plugins directory
"/usr/lib/NetworkManager/VPN", which should replace
"/etc/NetworkManager/VPN" in the future. But we have to
consider both locations for backward compatibility.
The content of the VPN directory is not user configuration,
hence it should not be under "/etc". See related bug 738853.
We don't really know which version it's going to be -- and thus if we're going
to actually need it (version 5), or not (version 4). It's going to be decided
at configure time.
Also, drop the bogus Fedora 19 conditionals; Fedora < 20 has ModemManager that's
too old for the WWAN code anyway.
NetworkManager uses wpa_supplicant, which in turn calls OpenSSL for verifying
certificates. wpa_supplicant calls
SSL_CTX_load_verify_locations(ctx, CAfile, CApath)
using its ca_cert and ca_path options as CAfile and CApath parameters.
We have a configure time option with_system_ca_path to override ca_path.
However, it doesn't work when a system (like Fedora) only uses bundled PEM
certificates instead of a directory with hashed certificates ([1], [2]).
So this commit allows setting --with_system_ca_path to a file name (the
trusted certificate bundle). Then the name is used to populate wpa_supplicant's
ca_cert instead of ca_path.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1053882
[2] https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/https://bugzilla.redhat.com/show_bug.cgi?id=1236548
Originally, ibft settings were handled by "ifcfg-rh" plugin. Later, we added
a separate "ibft" plugin and moved the functionality there.
The problem was that users quite possibly had a configuration like
[main]
plugins=ifcfg-rh
in their "NetworkManager.conf". That meant, after upgrade users would
no longer have ibft support.
We fixed that by installing "/etc/NetworkManager/conf.d/10-ibft-plugin.conf"
which was read after the main file and contained:
[main]
plugins+=ibft
We no longer want to install configuration snippets with our core packages to
/etc. Avoid the regression by changing the meaning of "ifcfg-rh". By enabling
"ifcfg-rh" you now implicitly enable "ibft" plugin as well. This can be
turned off via "no-ibft". And you can continue to enable "ibft" plugin
alone.
'main.plugins' is the only configuration options for which we
have a default value and which we always want to set.
This property has a compile time default and can be set via command line,
fix the logic to set the value.
The proper way is:
- first set it (always) to the compile time default
- then read the configuration files, which potentially modify
the value.
- finally, if set via command line, overwrite it because
command line always wins.
Also comment-out the setting from our default file in
"contrib/fedora/rpm/NetworkManager.conf". We don't really need it to be
configured there, as we have a compile time default. Commenting it out
makes this clearer to the user.
Note that we cannot drop "10-ibft-plugin.conf" snippet from
NetworkManager package, because many users might have an old
"NetworkManager.conf" file with "plugin=ifcfg-rh".
This is a change in behavior if the user has no explicit
"plugins=ifcfg-rh" setting but followed by "plugins+=ibft".
Don't move "10-ibft-plugin.conf", because we need it to be
read *after* "NetworkManager.conf". Many users might have
an old "NetworkManager.conf" file that contains "plugin=ifcfg-rh".
This allows packages to install their configuration snippets to
"/usr/", which is a better place for system-provided configuration
files then "/etc".
"/usr/lib/NetworkManager/conf.d/" is read first, so that the values
in /etc have higher priority.
In general, we want to move system-provided configuration away from
/etc, so that a user can do a "factory-reset" by purging /etc.
https://bugzilla.gnome.org/show_bug.cgi?id=738853
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>
Everytime you call mock again, the fstab file will be reset.
So, we have to write it shortly before creating the image.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Kernel changed default filesystem for roots from ramfs to tmpfs.
See http://lwn.net/Articles/559176/ for more information.
The change caused our initramfs to be mounted with size= parameter that equals
to the actual size of unpacked initramfs. That's why mounted / was full and no
space was available (without manual remounting: mount -o remount,size=100% /).
So we explicitly require usage of ramfs to have all RAM of the virtual machine
available for /.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
The user must still be member of the 'mock' group though.
Also, hack something, that the current git repositoy will be reused, so
that we don't have to fetch the entire repositoy from upstream.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The scripts use Fedora to build a Fedora 18 (i386) live image, and pack
it into a single self-extracting script, that can be easily distributed.
$ sudo ./build [-n name] [-b branch/commit]
will create name-bundle.sh with NM built of a specified NM branch(commit).
(defaults are: name="nm-live-vm"; branch="master")
Resulting nm-live-vm-bundle.sh can be run with almost any distro.
The only requirement is qemu-kvm (and VNC (tigervnc) on RHEL).
Unify the obsoletes so they don't have to be changed every time.
Clarify the WWAN package description, since it really applies to
2G/3G/4G devices, not just 3G.
Also sync the glib and dbus-glib required versions with actual
NetworkManager requirements from configure.ac.
nmtui is long part of the NM main source. Remove the code from the build.sh
script to add 'nmtui' from an external tarball.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Ensure the date in the generated changelog entry is in the POSIX locale
format. Otherwise rpmbuild might fail with "bad date in %changelog" due
to it not liking localised date formats.
https://mail.gnome.org/archives/networkmanager-list/2014-May/msg00034.html
Signed-off-by: Thomas Haller <thaller@redhat.com>
Commit a544aa374e extracts the wifi device
into a shared library. Update the (currently broken) default spec file to
build the new package NetworkManager-wifi.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When plugins are disabled (which is configurable), the additional files
must be excluded. Otherwise rpmbuild fails with:
Installed (but unpackaged) file(s) found:
Signed-off-by: Thomas Haller <thaller@redhat.com>
This reverts commit 8f44bf047f.
This spec file is not intended to be passed directly to rpmbuild,
because it contains placeholders that are substituted by the build.sh
script.
As such, the version we want to get is
NetworkManager-0.9.9.1-7922.66eb52b53d.fc20.src.rpm
instead of
NetworkManager-0.9.9.1-792266eb52b53d.fc20.src.rpm
Signed-off-by: Thomas Haller <thaller@redhat.com>
This one spec file is intended to build packages for F18, F19, F20, and
rhel-7.0.
The build script can be tweaked by setting environment variables, but it
is supposed to choose the right default values on it's own.
Signed-off-by: Thomas Haller <thaller@redhat.com>
