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
