releng

Clone

#9859 Circular dependency with openldap package on F34
Closed: Fixed 3 years ago by mohanboddu. Opened 3 years ago by spichugi.

Closed: Fixed
Reopen Issue

  • Describe the issue
    A new build caused failures on 32-bit build.
    Now, it is impossible to create a scratch build.
    I have a fix for my build but I am unable to build it because there is a circular dependency issue.
    The commit that will fix the issue:
    https://src.fedoraproject.org/rpms/openldap/pull-request/5
    The scratch-build attempt with it(failed because of circular dependency issue):
    https://koji.fedoraproject.org/koji/taskinfo?taskID=55954312

  • When do you need this? (YYYY/MM/DD)
    As soon as possible (2020-11-20)

  • When is this no longer needed or useful? (YYYY/MM/DD)
    After it is fixed.

  • If we cannot complete your request, what is the impact?
    Fedora's build process is broken.

I've untagged openldap-2.4.56-2.fc34 from f34.

After the next newrepo's you should be able to build against the next oldest one.

Let us know if you have any issues with it.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
3 years ago

Metadata Update from @spichugi:
- Issue status updated to: Open (was: Closed)
3 years ago

I've untagged openldap-2.4.56-2.fc34 from f34.

After the next newrepo's you should be able to build against the next oldest one.

Let us know if you have any issues with it.

F34 builds are working now! Thanks!
I see that eln105 are failing though...
https://koji.fedoraproject.org/koji/taskinfo?taskID=55961962

Is it possible that they have the old openldap-2.4.56-2.eln105 tagged?
Feel free to close the issue if I misunderstood something.

It is possible. I can untag it there too, but not sure if that will break automation. ;(

@sgallagh @jkaluza ^

Go ahead. It should be fine.

Done.

I ran into a odd failure with the latest openldap... the compat-package link was broken and so everything using old openldap was broken.

On looking today I can't seem to see how it's wrong tho... just a heads up there may be some problem with -3 as well.

Yes, it's still broken... see https://koji.fedoraproject.org/koji/taskinfo?taskID=55963913 (which failed the rawhide compose)

I am untagging -3 also until it can get sorted out.

Yes, it's still broken... see https://koji.fedoraproject.org/koji/taskinfo?taskID=55963913 (which failed the rawhide compose)

I am untagging -3 also until it can get sorted out.

I've installed the -3 version on F34 aarch64 but I see the file (symlink) libldap-2.4.so.2 there:

[root@vm ~]# ll /usr/lib64/ | grep libldap
lrwxrwxrwx.  1 root root       18 Nov 20 14:02 libldap-2.4.so.2 -> libldap_r-2.4.so.2
lrwxrwxrwx.  1 root root       23 Nov 20 14:01 libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.11.4
-rwxr-xr-x.  1 root root   403296 Nov 20 14:03 libldap_r-2.4.so.2.11.4

Could you please suggest what can be the issue?

I guess the problem is, up until openldap-2.4.56-1 there isn't a compat package and libldap-2.4.so.2 is provided by openldap-2.4.56-1 but now there is a compat package which is providing libldap-2.4.so.2 but its not provided by the openldap-2.4.56-3 somewhere in the dep chain, we need to update to make it use the compat package instead and that will fix this issue

I guess the problem is, up until openldap-2.4.56-1 there isn't a compat package and libldap-2.4.so.2 is provided by openldap-2.4.56-1 but now there is a compat package which is providing libldap-2.4.so.2 but its not provided by the openldap-2.4.56-3 somewhere in the dep chain, we need to update to make it use the compat package instead and that will fix this issue

Or the -devel rpm, which used to provide libldap-2.4.so.2, its not providing anymore.

Yes, it's still broken... see https://koji.fedoraproject.org/koji/taskinfo?taskID=55963913 (which failed the rawhide compose)

I am untagging -3 also until it can get sorted out.

I've installed the -3 version on F34 aarch64 but I see the file (symlink) libldap-2.4.so.2 there:

[root@vm ~]# ll /usr/lib64/ | grep libldap lrwxrwxrwx. 1 root root 18 Nov 20 14:02 libldap-2.4.so.2 -> libldap_r-2.4.so.2 lrwxrwxrwx. 1 root root 23 Nov 20 14:01 libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.11.4 -rwxr-xr-x. 1 root root 403296 Nov 20 14:03 libldap_r-2.4.so.2.11.4

Could you please suggest what can be the issue?

Try running ldconfig now?

Metadata Update from @mohanboddu:
- Issue tagged with: low-gain, low-trouble, ops
3 years ago

Try running ldconfig now?

[root@vm ~]# rpm -qa | grep openldap
openldap-2.4.56-3.fc34.aarch64
openldap-compat-2.4.56-3.fc34.aarch64
[root@vm ~]# ldconfig -p  | grep libldap
        libldap_r-2.4.so.2 (libc6,AArch64) => /lib64/libldap_r-2.4.so.2

and before it was: 

[root@vm ~]# rpm -qa | grep openldap
openldap-2.4.56-1.fc34.aarch64
[root@vm ~]# ldconfig -p  | grep libldap
        libldap_r-2.4.so.2 (libc6,AArch64) => /lib64/libldap_r-2.4.so.2
        libldap-2.4.so.2 (libc6,AArch64) => /lib64/libldap-2.4.so.2

So if I understand correctly, openldap-compat-2.4.56-3.fc34.aarch64 doesn't provide libldap-2.4.so.2 (libc6,AArch64) => /lib64/libldap-2.4.so.2 in ldconfig but other packages want it.

What we do in our spec file is:

%package compat
Summary: Package providing legacy non-threded libldap
Requires: openldap%{?_isa} = %{version}-%{release}
# since libldap is manually linked from libldap_r, the provides is not generated automatically
%ifarch armv7hl i686
Provides: libldap-2.4.so.%{so_ver}
%else
Provides: libldap-2.4.so.%{so_ver}()(%{__isa_bits}bit)
%endif

%description compat
The openldap-compat package contains non-threaded variant of libldap
which should not be used. Instead, applications should link to libldap_r
which provides thread-safe variant with the very same API.


# provide only libldap_r and symlink libldap to it
rm -f libldap.so
ln -s libldap{_r,}.so
rm -f libldap-*.so.*
ln -s libldap{_r,}-${version}.so.%{so_ver}
popd

%files compat
%{_libdir}/libldap-2.4*.so.*

I am not sure what exactly is wrong here...
https://src.fedoraproject.org/rpms/openldap/blob/master/f/openldap.spec

@kevin can it be that %ldconfig_scriplets doesn't link the compat package libraries properly and this is the issue why it fails here:

https://pagure.io/releng/failed-composes/issue/2036#comment-702565
https://koji.fedoraproject.org/koji/taskinfo?taskID=55963913

I am really not sure why I can see the links in the directory but ldconfig doesn't have them (and the compose fails)

[root@vm ~]# rpm -qa | grep openldap
openldap-2.4.56-3.fc34.aarch64
openldap-compat-2.4.56-3.fc34.aarch64
[root@vm ~]# ll /usr/lib64/ | grep libldap
lrwxrwxrwx.  1 root root       18 Nov 20 14:02 libldap-2.4.so.2 -> libldap_r-2.4.so.2
lrwxrwxrwx.  1 root root       23 Nov 20 14:01 libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.11.4
-rwxr-xr-x.  1 root root   403296 Nov 20 14:03 libldap_r-2.4.so.2.11.4

Note that %ldconfig_scriplets does nothing.

Note that %ldconfig_scriplets does nothing.

Okay... Could you please suggest how it can be fixed?
I am really not sure why manually it works but with compose - it doesn't.

My theory is that ldconfig removes that link, causing everything looking for libldap-2.4.so.2 to fail to work.

ie:

Install a rawhide machine.
Install the openldap-2.4.56-3 and openldap-compat-2.4.56-3 packages
(confirm everyhing is happy and works fine)
run 'ldconfig' as root
(confirm that ldconfig removed this link and everything is broken).

I've not confirmed this theory, but I think thats what is happening.
As to how to fix it... perhaps just copy the _r lib to the old one? or perhaps just work on fixing all the users of that and updating them all at once ( https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ ) or somehow adjust ldconfig to not mess up your manual symlink.

To expand on what @churchyard was saying... %ldconfig_scriptlets does nothing in a package anymore, because ldconfig is triggered when files are landed in ldconfig dirs (ie, instead of every package calling ldconfig after it's installed, there's just one call to ldconfig at the end of the transaction that sets up links for all of them).

I've uploaded a new version which should fix the issue (I hope).
Could you please confirm that it works now?
https://koji.fedoraproject.org/koji/buildinfo?buildID=1645917

Works fine here on my laptop. Thanks!

Great! We can probably close the issue then!
Thank you once again!

And... I guess it's still not happy. ;( 

DEBUG util.py:636:  2020-11-26 20:45:35,742: libldap_r-2.4.so.2, needed by /usr/bin/curl, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/curl, not found
DEBUG util.py:636:  2020-11-26 20:45:35,742: libldap_r-2.4.so.2, needed by /usr/bin/debuginfod-find, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/debuginfod-find, not found
DEBUG util.py:636:  2020-11-26 20:45:35,742: libldap_r-2.4.so.2, needed by /usr/bin/dbxtool, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/dbxtool, not found
DEBUG util.py:636:  2020-11-26 20:45:35,742: libldap_r-2.4.so.2, needed by /usr/bin/dfu-tool, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/dfu-tool, not found
DEBUG util.py:636:  2020-11-26 20:45:35,742: libldap_r-2.4.so.2, needed by /usr/bin/fwupdagent, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/fwupdagent, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/fwupdate, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/fwupdate, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/fwupdmgr, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/fwupdmgr, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/fwupdtool, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/fwupdtool, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/fwupdtpmevlog, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/fwupdtpmevlog, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/dirmngr, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/dirmngr, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/createrepo, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/createrepo, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/createrepo_c, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/createrepo_c, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/mergerepo, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/mergerepo, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/mergerepo_c, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/mergerepo_c, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/reporter-upload, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/reporter-upload, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/modifyrepo, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/modifyrepo, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/ostree, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/ostree, not found
DEBUG util.py:636:  2020-11-26 20:45:35,743: libldap_r-2.4.so.2, needed by /usr/bin/rofiles-fuse, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/rofiles-fuse, not found
DEBUG util.py:636:  2020-11-26 20:45:35,744: libldap_r-2.4.so.2, needed by /usr/bin/modifyrepo_c, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/modifyrepo_c, not found
DEBUG util.py:636:  2020-11-26 20:45:35,744: libldap_r-2.4.so.2, needed by /usr/bin/sqliterepo_c, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/sqliterepo_c, not found
DEBUG util.py:636:  2020-11-26 20:45:35,744: libldap_r-2.4.so.2, needed by /usr/bin/gdb, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/gdb, not found
DEBUG util.py:636:  2020-11-26 20:45:35,744: libldap_r-2.4.so.2, needed by /usr/bin/reporter-bugzilla, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/reporter-bugzilla, not found
DEBUG util.py:636:  2020-11-26 20:45:35,744: libldap_r-2.4.so.2, needed by /usr/bin/rpm-ostree, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/bin/rpm-ostree, not found
DEBUG util.py:636:  2020-11-26 20:45:35,744: libldap_r-2.4.so.2, needed by /usr/sbin/rngd, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/sbin/rngd, not found
DEBUG util.py:636:  2020-11-26 20:45:35,744: libldap_r-2.4.so.2, needed by /usr/sbin/NetworkManager, not found
DEBUG util.py:636:  libldap_r-2.4.so.2, needed by /usr/sbin/NetworkManager, not found
DEBUG util.py:636:  2020-11-26 20:45:35,746: Cleaning up tempdir - /var/tmp/lorax/lorax.73h9sl2d
DEBUG util.py:787:  Child return code was: 1

So this is the new library now?

I am untagging openldap-2.4.56-4.fc34 and running another rawhide.

So this is the new library now?

Yes...

I really don't get it... I've checked ldconfig and actual libs and everything is there.

openldap-2.4.56-4.fc34.x86_64

[root@vm ~]# ldconfig -p | grep libldap
        libldap_r-2.4.so.2 (libc6,x86-64) => /lib64/libldap_r-2.4.so.2
        libldap-2.4.so.2 (libc6,x86-64) => /lib64/libldap-2.4.so.2
[root@vm ~]# ll /usr/lib64/ | grep libldap
-rwxr-xr-x. 1 root root    15232 Nov 26 07:40 libldap-2.4.so.2
lrwxrwxrwx. 1 root root       16 Nov 26 07:40 libldap-2.4.so.2.11.4 -> libldap-2.4.so.2
lrwxrwxrwx. 1 root root       23 Nov 26 07:40 libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.11.4
-rwxr-xr-x. 1 root root   362320 Nov 26 07:40 libldap_r-2.4.so.2.11.4

So the only difference with the old version is a bit different links:

openldap-2.4.56-1.fc34.x86_64

[root@gizmo ~]# ldconfig -p | grep libldap
        libldap_r-2.4.so.2 (libc6,x86-64) => /lib64/libldap_r-2.4.so.2
        libldap-2.4.so.2 (libc6,x86-64) => /lib64/libldap-2.4.so.2
[root@gizmo ~]# ll /usr/lib64/ | grep libldap
lrwxrwxrwx. 1 root root       21 Nov 18 09:10 libldap-2.4.so.2 -> libldap-2.4.so.2.11.4
-rwxr-xr-x. 1 root root   337760 Nov 18 09:11 libldap-2.4.so.2.11.4
lrwxrwxrwx. 1 root root       23 Nov 18 09:10 libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.11.4
-rwxr-xr-x. 1 root root   362416 Nov 18 09:11 libldap_r-2.4.so.2.11.4

Can Koji somehow clean it? I am really confused...

Note that this can be also reproduced in Fedora ELN and internal RH compose with this openldap version. I do not understand what's going on there, because the libraries look correct.

@mohanboddu , @kevin , can you please also untag it from "eln"?

Also, I was looking at the recent builds to see what was going on with the failures but I can't find the failed build (from which you've provided the log).
https://koji.fedoraproject.org/koji/builds?start=100&order=-build_id

Could you please give a link to the logs and the info (arch, other packages, etc) of the failed build?

Maybe something wrong with dependencies but I can't see it on my local env...

My guess is that Koji environment has some additional magic that I am not aware of...
Could you please share the docs that can help me to understand the whole process?
Edited 3 years ago by spichugi

Let me try to prepare reproducer for you locally.

@spichugi :

$ sudo dnf install lorax
$ sudo lorax -p Test -v 1 -r 1 --source https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20201126.n.1/compose/Everything/x86_64/os/ --workdir=./workdir --force ./test-compose

Note that everytime you run this lorax command, it will download those 800 packages again, there is no caching. I think lorax can be configured to do caching somehow but I have never used that.

Using this way, it fails on my laptop the same way as in Koji.

You can then inspect ./workdir and ./test-compose directories for more logs or even the installtree with all the packages installed I believe.

@spichugi , @kevin , @mohanboddu , The issue is in lorax templates:

https://github.com/weldr/lorax/blob/master/share/templates.d/99-generic/runtime-cleanup.tmpl#L267

I have no idea why it's removed from there and what is the process to change lorax templates Fedora uses.

It seems lorax templates contain that line for more than 10 years.

Oh yeah, I totally forgot about that cleaning. ;(

So, I think we need a new lorax with that removed/adjusted. Can you file a lorax bug/pr ?

I have untagged the eln one now too.

@spichugi , @kevin , @mohanboddu , The issue is in lorax templates:

https://github.com/weldr/lorax/blob/master/share/templates.d/99-generic/runtime-cleanup.tmpl#L267

I have no idea why it's removed from there and what is the process to change lorax templates Fedora uses.

Wow, thanks for the investigation!
And for the reproducing steps.

Oh yeah, I totally forgot about that cleaning. ;(

So, I think we need a new lorax with that removed/adjusted. Can you file a lorax bug/pr ?

Sure, I'll file a bug and PR (I'll try to test the change too).

The PR is created:
https://github.com/weldr/lorax/pull/1099

lorax command is successfully executed with this change.
I am not sure how and when it will land in Fedora though...

@jkaluza , @kevin , @mohanboddu , hi

As the lorax is fixed, what will be your suggestion for the next step?

Should openldap-2.4.56-4 be tagged once again?
Or should I bump the version (without any actual code change)?
Edited 3 years ago by spichugi

I've tagged openldap-2.4.56-4.fc34 back in. I guess we can see how the next compose does. :)

We got a compose last night and seems like everything is working now, closing this ticket.

Thanks everyone for their help.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
3 years ago

Login to comment on this ticket.

Metadata
None

ops low-gain low-trouble

None
None
None
None
None
None
Boards 1
Ops Status: Done
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.