Troubleshoot ============ Error ``Requires: python(abi) = 2.6`` ------------------------------------- If you see such an error, start by comparing the version of the complaining package with the one which is in the diracos_repo. If they do not match, then you need to update the version shipped with DIRACOS. The whole point of building so many RPMs is because we try to get rid of python2.6 in all the low level packages. If you see such a message, that means that one of the package you are building requires a dependency that we do not provide. And if that’s the case, you might want to look at version change. For example: .. code-block:: text Getting requirements for yum-3.2.29-81.el6.py27.usc4.src --> python-2.7.13-2.el6.x86_64 --> gettext-0.17-18.el6.x86_64 --> intltool-0.41.0-1.1.el6.noarch --> python-nose-0.10.4-3.1.el6.py27.usc4.noarch --> python-2.7.13-2.el6.x86_64 --> rpm-python-4.8.0-59.el6.x86_64 --> Already installed : rpm-4.8.0-59.el6.x86_64 --> python-iniparse-0.3.1-2.1.el6.py27.usc4.noarch --> python-2.7.13-2.el6.x86_64 --> python-urlgrabber-3.9.1-11.el6.py27.usc4.noarch --> yum-metadata-parser-1.1.2-16.el6.py27.usc4.x86_64 --> pygpgme-0.1-18.20090824bzr68.el6.py27.usc4.x86_64 Error: Package: rpm-python-4.8.0-59.el6.x86_64 (base) Requires: libpython2.6.so.1.0()(64bit) Error: Package: rpm-python-4.8.0-59.el6.x86_64 (base) Requires: python(abi) = 2.6 Installing: python-2.7.13-2.el6.x86_64 (local-py2.7) python(abi) = 2.7 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest This stack trace is due to ``rpm-python-4.8.0-59`` being pulled from the ``base`` repo, despite we provide ``rpm-python-4.8.0-55``. This is because some packages (``yum`` in that case) has a loose dependency (no specific version ) on ``rpm-python``, so it takes the latest. The solution is to update our version of ``rpm-python`` Build is failing for broken rpm dependencies -------------------------------------------- Sometimes, the build will fail, for some weird reasons. To start with, do not bother. Clean the mock cache, the mock work directory, and restart the build. It might just work Script fails for missing python module -------------------------------------- When crashing, mock sometimes messes up the actual environment. Log out from the machine, come back, and try again. Symlinks -------- Some RPMs will create broken symlinks. The existing ones are know, and are in the file ``tests/integration/knownBrokenLinks.txt``. Shall a new one appear, this test should trigger, and you should either fix it, or add it to the list. Singularity ----------- Singularity needs to be built from source to disable ``setuid`` support and make the binaries smaller by stripping debugging information. It is tricky to build within DIRACOS due to it’s dependency on ``golang`` as recent versions depend on ``subversion`` (for pulling dependencies). As ``subversion`` has a lot of Python dependencies which it cause many errors of the form ```Requires: python(abi) = 2.6`` <#error-requires-pythonabi--26>`__ which eventually become circular dependencies when trying to rebuild everythin for Python 2.7. Additionaly, compiling ``golang`` to remove the ``subversion`` dependency requires an existing ``golang`` package. Fortunately older ``golang`` pakcages don’t require ``subversion``, but does still require an existing ``golang``. This is avoided using prebuilt RPMs for an old ``golang`` version (split into ``golang``/``golang-bin``/``golang-src``) that then enables a newer ``golang`` package to be built with the ``subversion`` dependency removed. Singularity can then be built from source as is the case for other packages. Davix (Cmake3) -------------- Latest davix versions require ``CMake3``, which is available as RPM in the SLC6 environment in which we build. To solve this, we download in the ``davix`` routine a binary of ``CMake3`` that we then inject in the ``mock`` environment. We may have to do similar tricks for other packages in the future... About manualDependencies ------------------------ The packages that are in ``manualDependencies`` are added to the dependencies that are pulled together with DIRACOS. In principle, since we build all the packages we need and pull their dependencies, there should be no need for such a thing. THere are however two cases where it shows useful: - In case of RPM dependencies badly defined - In case of premature stop when pulling the dependencies. ``NSS`` falls in the later one. LDD check failing ----------------- The ``check_ldd`` test looks at the dependencies of the binaries in DIRACOS. It finds those pointing outside of DIRACOS (can be due to rpath) and those not found. There is a list of known “broken” dependencies (``tests/integration/knownMissingDependencies.txt``). Ideally, this list should be empty, but it will never be the case. So if you cannot do differently, you can always add your libraries there. ldconfig_scriptlets ------------------- Some spec files use ``ldconfig_scriptlets`` to trigger ``ldconfig``. This does not work with DIRACOS because it relies on some packages in EPEL that we exclude on purpose. You can simply replace :: %ldconfig_scriptlets with :: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig Firefox and Thunderbird in dependency list ------------------------------------------ On October 2 the packages of firefox and thunderbird have been updated to a version that ships several base libraries as part of firefox and does not rely on system libraries anymore. This has as a consequence that several libraries mistakingly resolve firefox as a dependency e.g.: .. code-block:: text DEBUG:root:openldap-clients requires set(['cyrus-sasl-lib', 'firefox', 'nspr', 'glibc', u'openldap-clients', 'nss-util', 'openldap', 'nss']) One can see that `openldap-clients` needs `nss-util` but this is resolved via: .. code-block:: text repoquery --whatprovides 'libnssutil3.so()(64bit)' nss-util-0:3.12.10-2.el6.x86_64 firefox-0:78.3.0-1.el6_10.x86_64 nss-util-0:3.14.3-4.el6_4.x86_64 nss-util-0:3.21.0-0.3.el6_7.x86_64 nss-util-0:3.36.0-1.el6.x86_64 The problems is it caused by `libnssutil3.so` which is offered by `nss-util`, `thunderbird` and `firefox`, winning the latter because it comes first in alphabetic order. The same behaviour can be observer in the dependency resolution of many other packages. To mitigate this problem, we have added `firefox` and `thunderbird` into the mockCofigs build and install exclusion list .. code-block:: text [updates] name=updates enabled=1 baseurl=http://linuxsoft.cern.ch/cern/slc6X/x86_64/yum/updates/ failovermethod=priority exclude=boost*,python*,PyXML*,firefox*,thundrbird*