'zypper up' gives a strange warning

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
        Mountpoint: 
        Configfile: 
Sorry, the error (#40) occurred ;(
Description: failed to open default backend (see warnings for more information)
Ingroup: kdb
Module: 
At: /home/abuild/rpmbuild/BUILD/elektra-0.8.19/src/libs/elektra/kdb.c:287
Reason: could not open default backend
Mountpoint: 
Configfile: 

There is no such thing as ‘/home/abuild’ at all. There has never been, no such user whatsoever. What is it looking for?

Any idea what the problem/fix might be?

Here is the full output:

http://paste.opensuse.org/87e694b7

Sounds like packaging bug - somehow it recorded locations on build system. Open bug report.

I’m not familiar with ‘libelektra4’, but a quick search shows that it is available from OBS repos, including the multimedia:colour_management repo you have subscribed to. As such, it will need to fixed by the packager.

https://build.opensuse.org/project/show/multimedia:color_management

Done:

https://bugzilla.opensuse.org/show_bug.cgi?id=1020109

Thanks.

Just for the record:

Not in your system, but in the system the package was built on and /home/abuild/rpmbuild/BUILD/$SOME_NAME_SOME_VERSION" is the location where the sources are being compiled.

The user “abuild” is the default user building packages in OBS.

This is not a bug and your warning just shows you the full path in the source where this warning has been triggered from while executing the binary.

Just for the fun of it, run


grep 'home\/abuild' /usr/bin/* /usr/lib*/*.so.*

and be suprised how many hits you will get.

You mean that

is not a bug?

In bugzilla the status has been updated to CONFIRMED, so obviously there is a problem.

No, I did not mean (and write) that.

The presence of “/home/abuild” in the path of some warning/error message is not a bug, no more, no less.

You will find that path quite often in binaries/libraries and if some execption is triggered this path might be shown in debugging/error output.

If some application actually searches inside this (non-existent) path for some components, that would certainly be a bug.

AK