Bug 1020109 - multimedia:color_management: Bug - 'zypper up' gives a warning
multimedia:color_management: Bug - 'zypper up' gives a warning
Classification: openSUSE
Product: openSUSE.org
Classification: openSUSE
Component: 3rd party software
Other openSUSE 42.1
: P5 - None : Major (vote)
: ---
Assigned To: Kai-Uwe Behrmann
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2017-01-16 09:54 UTC by Deleted Name
Modified: 2018-03-15 11:27 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Deleted Name 2017-01-16 09:54:45 UTC
I run 'zypper up' almost daily. This is the firs time I see a message like this one:

(12/12) Installing: libelektra4-0.8.19-6.1.x86_64 ...........................................................................................[done]
Additional rpm output:
The command global-mount failed while accessing the key database with the info:
 Sorry, 1 warning was issued ;(
 Warning (#1):
        Description: could not load module, dlopen failed
        Ingroup: modules
        Module: dl
        At: /home/abuild/rpmbuild/BUILD/elektra-0.8.19/src/libs/loader/dl.c:88
        Reason: of module: libelektra-resolver.so, because: libelektra-resolver.so: cannot open shared object file: No such file or directory
Sorry, the error (#40) occurred ;(
Description: failed to open default backend (see warnings for more information)
Ingroup: kdb
At: /home/abuild/rpmbuild/BUILD/elektra-0.8.19/src/libs/elektra/kdb.c:287
Reason: could not open default backend

There is no such thing as '/home/abuild' at all. There has never been, no such user whatsoever.

Here is the full output:


I have been advised to report as a bug in this forum thread:


Comment 1 Kai-Uwe Behrmann 2017-01-16 14:47:28 UTC
Thanks for reporting. Meanwhile the package was updated some days ago. 
The following call is fine in Tumbleweed without errors:
$ zypper install libelektra4
libelektra4-0.8.19-6.2.x86_64 gets installed.

It looks like the error is already present in the build logs for 42.1.
The change introducing to fix usage of libelektra4 is in rev6:

@@ -193,11 +193,13 @@
 #rm $RPM_BUILD_ROOT%{_bindir}/kdb-static
 # not known by any package?
 rm -r $RPM_BUILD_ROOT%{_datadir}/zsh/vendor-completions/
+# add elektra modules paths
+mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/
+echo "%{_libdir}/elektra%{api}" > $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/elektra.conf
 %post -n lib%{name}%{api}
 # activate dbus messages on db changes
-export LD_LIBRARY_PATH=%{_libdir}/elektra%{api}/:$LD_LIBRARY_PATH
 %{_bindir}/kdb global-mount dbus || :
 %postun -n lib%{name}%{api} -p /sbin/ldconfig
@@ -220,6 +222,7 @@
 %dir %{_datadir}/doc/elektra
 %if 0%{?use_qt5} > 0
 %files -n %{name}-qt-gui

%{_sysconfdir}/ld.so.conf.d/elektra.conf is considered to be loaded by ldconfig and make the libelektra-resolver.so module visible to the dynamic library loader for the kdb tool from the script.
I have on glue why this scheme does not work.
Comment 2 Kai-Uwe Behrmann 2017-01-16 15:37:08 UTC
package install appears to fail in 42.1. while it is fine in Tumbleweed
Comment 3 Deleted Name 2017-01-16 15:59:58 UTC
Thanks for the feedback.

So is there anything to do on my end or should I simply wait that to be resolved?

Comment 4 Tomáš Chvátal 2018-03-15 11:27:21 UTC
This should've been fixed on its own now. At least it does not error out when I test it on currently supported leap release.