Instead of self-written validation methods to validate IPv4 and IPv6 addresses.
Use Python's standard library functions `ipaddress`.
Signed-off-by: Ashish Singh <assingh@redhat.com>
so user can install python3-rados, instead of python36-rados, without
specifying the minor version of python. also, we should not break our
teuthology tests with this naming scheme change. for instance, our
cephfs qa suite installs `python3-cephfs` for testing the `cephfs-shell`
Signed-off-by: Kefu Chai <kchai@redhat.com>
some of our centos7 jenkins builders are failing to build ceph master and
nautilus branches. because EPEL7 recently switched from python3.4 to
python3.6 as the native python3. see
https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/message/EGUMKAIMPK2UD5VSHXM53BH2MBDGDWMO/
and one of our BuildRequires, cmake3,
was offered by EPEL7. it also followed the python3.6 switch-over to
rebuild against python3.6. as a result, the cmake3-data-3.13.4-2.el7
started to depend on /usr/bin/python3.6, which is in turn offered by
python36 package. after installing python36 as a dependency of the
updated cmake3. but in cmake, we originally checks for the latest
python3 interpreter if WITH_PYTHON3 is enabled, that's why these
builders which happen to install these updated packages started to fail
when detecting the existence of python3.6 related build dependencies.
as a fix, in d1e83082,
python%{python3_pkgversion}-{devel,setuptools,Cython} are listed as
BuildRequires to reflect this change in EPEL7. before d1e83082, we
hardwired them to python34-*.
but as following analysis puts, there are cases where `yum-builddep`
is inconsistent with `rpmbuild`. as `yum-builddep` changes the how
`python3_pkgversion` and `python3_version` macros are expanded:
- none of the packages installed by `yum-builddep` installs the python3
related rpm macros, so the system stays with whatever python3 it was
using. in this case, `rpmbuild` won't complain, as the
`python3_pkgversion` and `python_version` are consistent before and
after `yum-builddep`.
- system has python3.4 installed before `yum-builddep`. but
`yum-builddep` installed python3.6 and also the updated
`python-rpm-macros` packages, which points `python3_version` and
`python3_pkgversion` to 3.6 and 36 respectively. in this case,
`rpmbuild` will complain, because when we run `yum-builddep`,
`python3_version` was still "3.4".
- system does not have python3 installed before `yum-builddep`. so
it was using python34 for preparing the "BuildRequires". but some
of the packages installed by `yum-builddep` installs python36, and
also the updated `python-rpm-macros` packages, which points
`python3_version` and `python3_pkgversion` to 3.6 and 36 respectively.
in this case, `rpmbuild` will complain, because the python36 related
dependencies are missing. what the system has is python34
dependencies.
- system does not have python3 installed before `yum-builddep`. so
it was using python34 for preparing the "BuildRequires". but some
of the packages installed by `yum-builddep` installs python34, and
also the updated `python-rpm-macros` packages, which points
`python3_version` and `python3_pkgversion` to 3.4 and 34 respectively.
in this case, `rpmbuild` won't complain, as the
`python3_pkgversion` and `python_version` are also consistent before and
after `yum-builddep`.
as we cannot tell if the system has python3 or what the python3 version
the system has before `yum-builddep`, so what we can do is to ensure
`rpmbuild` has what it needs to build Ceph. so let's just stick with
python3.6.
Signed-off-by: Kefu Chai <kchai@redhat.com>
to force cmake to use the python3 and python3 modules for building
python3 bindings
on the debian side, it's okay to continue using "-DWITH_PYTHON3=ON", as
- cmake does normalize "ON" to 3
- debian's cmake extension lives on /usr/lib/python3/dist-packages/
not in a specific /usr/lib/python3.x/dist-packages directory
Signed-off-by: Kefu Chai <kchai@redhat.com>
ceph-common depends on librados2, but ceph-immutable-object-cache only
uses librados2's C++ API, so librados2 would suffice.
rpmbuild is able to figure out the .so dependencies, and let
ceph-immutable-object-cache depend on the package which offers
librados2, but we'd better make sure immutable-object-cache is linked
against the librados2 of the same version, to ensure that librados2
offers the correct C++ symbols. as we only version the C++ API in the
librados2 after nautilus.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* remove "libradospp1" from immutable-object-cache's runtime
dependencies. this package was removed in 65c8733b
Signed-off-by: Kefu Chai <kchai@redhat.com>
as immutable-object-cache has the prefix of "ceph", no need to use "-n"
option. so this change is but a cleanup.
* use "%package immutable-object-cache" not "%package
ceph-immutable-object-cache" for naming subpackage of
"ceph-immutable-object-cache". this would result in package name of
"ceph-immutable-object-cache". see
http://ftp.rpm.org/max-rpm/s1-rpm-subpack-spec-file-changes.html
* the same applies to other directives with "-n" options, see
http://ftp.rpm.org/max-rpm/s1-rpm-inside-package-directive.html
Signed-off-by: Kefu Chai <kchai@redhat.com>
seems devtools-8 is not packaged on aarch64. and we are suffering from
ICE on centos7 when building with GCC-7.3. so let's try GCC-8.2!
Fixes: http://tracker.ceph.com/issues/38892
Signed-off-by: Kefu Chai <kchai@redhat.com>
We do not build for RHEL 6 and below, so "rhel == 7" is just as good, while
also avoiding the bug.
In addition, "rhel == 7" is the conditional we are using everywhere else in the
spec file for this purpose.
Fixes: https://tracker.ceph.com/issues/38810
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The libstoragemgmt package is needed so we can activate the drive
blink-led feature so we should pull that package.
Signed-off-by: Sébastien Han <seb@redhat.com>
"Recommends" and other weak dependencies were introduced in rpm 4.12. it
is included by quite a few distros, including fedora 21 and up, and
recent SUSE distros. but RHEL7 still ships rpm 4.11. see
https://fedoraproject.org/wiki/Changes/RPM-4.12 and
https://software.opensuse.org/package/rpm . so we enable Recommends on
fedora and SUSE distros.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Without this patch, attempts to install the ceph-mgr-diskprediction-local RPM
fail on SUSE platforms with the following error:
can't install ceph-mgr-diskprediction-local-14.1.0.402+ga396e8bf3b-3742.1.noarch:
nothing provides numpy needed by ceph-mgr-diskprediction-local-14.1.0.402+ga396e8bf3b-3742.1.noarch
nothing provides scipy needed by ceph-mgr-diskprediction-local-14.1.0.402+ga396e8bf3b-3742.1.noarch
Also take into account package naming differences between Fedora and
RHEL/CentOS.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Signed-off-by: Nathan Cutler <ncutler@suse.com>
* refs/pull/26694/head:
rpm: drop use of $FIRST_ARG
Reviewed-by: Boris Ranto <branto@redhat.com>
Reviewed-by: Tim Serong <tserong@suse.com>
Reviewed-by: Ken Dreyer <kdreyer@redhat.com>
The "restful" MGR module is part of ceph-mgr, and is active by default when
deploying a Ceph cluster from scratch.
Without this patch, the cluster never reaches HEALTH_OK due to the following
health warning: "Module 'restful' has failed dependency: No module named
'OpenSSL'"
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The use of $FIRST_ARG was probably required because the SUSE-specific
%service_* rpm macros were playing tricks on the shell positional parameters.
This is bad practice and error-prone, so let's assume that no macros should do
that anymore and hence it's safe to assume that positional parameters remain
unchanged after any rpm macro call.
Thanks to Franck Bui for providing this patch.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Without this patch, the Python 2 version of python-remoto is always installed,
even on Python 3 systems.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
In very recent SUSEs (e.g. Leap 15.1), the build dependencies needed for the
lttng build are satisfied for this architecture.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Since the lttng-ust-devel and babeltrace-devel RPMs are not maintained for s390x
in openSUSE, we have to exclude the lttng build on this architecture.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
This reverts commit c32c4874e1.
An updated python2-kubernetes package that does not depend on
python-adal has made it into the epel7 repos. With that change,
we can now revert this patch.
When we readd it back though, add in %{_python_buildid} so that
this works correctly on python3-based distros as well.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
cmake,rgw: make amqp support optional
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Yuval Lifshitz <yuvalif@yahoo.com>
Reviewed-by: Willem Jan Withagen <wjw@digiware.nl>
In RHEL 8, rpmbuild does not automatically generate __pycache__
directories. Generate them explicitly with the %py_byte_compile macro.
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
On RHEL 7, this package is named "pyOpenSSL", but on RHEL 8, Fedora, and
SUSE, it is named "python3-pyOpenSSL".
Prior to this change, the RHEL conditional was applying to both RHEL 7
and 8, so we would fail to resolve the "pyOpenSSL" package dependency on
RHEL 8.
Update the RPM conditionals to use "pyOpenSSL" on RHEL 7 and
"python3-pyOpenSSL" on all other distributions.
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
