CI test build failure (missing libldap_r) on brach 2.0, 1.4.4 and 1.4.3

[Pierre Rogier]

FYI: I cherry picked a fix and got build error when building ldclt:
2022-06-08T12:48:07.9008916Z /usr/bin/ld: cannot find -lldap_r

The build on 2.1 works so I suspect we need to fix the old branches
the same way ...

-- 
--

389 Directory Server Development Team

[Simon Pichugin]

Hi Pierre,
The issue happens if you build older branches on Fedora 36 (where we have
OpenLDAP 2.6).

   - Building 2.1 on F36 (where we have the libldap 2.6) - is okay.
   - And Building 2.0, 1.4.4 and 1.4.3 on F35 should be fine, too, as it
   has libldap_r.

I need to think more about that, but I believe we are in the "dangerous"
territory when we build 389-ds-base with libdap from openldap-2.6, but it
will be used with openldap-2.4.
We shouldn't have issues on Fedora 35, but we may get issues on RHEL 8 or
SUSE if they don't have libldap/libldap_r fix from
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
So we should always build with libldap_r the package that should be used on
the system where we use libldap_r.

We may have the fix backported for the development use, but we should
always retest our fixes on the targeted distribution, IMHO.

Regards,
Simon



On Wed, Jun 8, 2022 at 6:28 AM Pierre Rogier <progier(a)redhat.com&gt; wrote:

>  FYI: I cherry picked a fix and got build error when building ldclt:
>  2022-06-08T12:48:07.9008916Z /usr/bin/ld: cannot find -lldap_r
>
>  The build on 2.1 works so I suspect we need to fix the old branches
>  the same way ...
>
>  --
>  --
>
>  389 Directory Server Development Team
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Pierre Rogier]

HI Simon,

I am speaking about the github actions that are triggered automatically
when committing some code.
Pushing  RHel images in a public domain repository does not seem to be a
great idea 😉, So running these tests on the intended OS/VERSION  is not
really an option...

So either we fix up the build framework in all versions or we add a fixup
phase (in
https://github.com/389ds/389-ds-base/blob/master/.github/workflows/compil...
?) to tweak the vm and copy the missing library if it does not exist)
But  IMHO modifying the configure/makefile to use libldap if libldap_r is
not available is the cleanest solution ...



On Wed, Jun 8, 2022 at 4:42 PM Simon Pichugin <spichugi(a)redhat.com&gt; wrote:

>  Hi Pierre,
>  The issue happens if you build older branches on Fedora 36 (where we have
>  OpenLDAP 2.6).
>
>     - Building 2.1 on F36 (where we have the libldap 2.6) - is okay.
>     - And Building 2.0, 1.4.4 and 1.4.3 on F35 should be fine, too, as it
>     has libldap_r.
>
>  I need to think more about that, but I believe we are in the "dangerous"
>  territory when we build 389-ds-base with libdap from openldap-2.6, but it
>  will be used with openldap-2.4.
>  We shouldn't have issues on Fedora 35, but we may get issues on RHEL 8 or
>  SUSE if they don't have libldap/libldap_r fix from
>  https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
>  So we should always build with libldap_r the package that should be used
>  on the system where we use libldap_r.
>
>  We may have the fix backported for the development use, but we should
>  always retest our fixes on the targeted distribution, IMHO.
>
>  Regards,
>  Simon
>
>
>
>  On Wed, Jun 8, 2022 at 6:28 AM Pierre Rogier <progier(a)redhat.com&gt; wrote:
>
> > FYI: I cherry picked a fix and got build error when building ldclt:
> > 2022-06-08T12:48:07.9008916Z /usr/bin/ld: cannot find -lldap_r
> >
> > The build on 2.1 works so I suspect we need to fix the old branches
> > the same way ...
> >
> > --
> > --
> >
> > 389 Directory Server Development Team
> > _______________________________________________
> > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]...
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 
--

389 Directory Server Development Team

[Simon Pichugin]

Hi Pierre,
Ah, okay, I didn't realize you were talking about Github CI...
It can be more tricky to fix it there as I still think that the cherry-pick
may be a dangerous option because of the reasons described above.
So we may need to find another way.
As you suggested, we may modify the YML with some additional processing.
But also, it may not be worth the hustle as we don't usually run CI on
anything beside master. The rare cases we need it, we can do it manually
and check it on the correct OS (RHEL, SUSE, older Fedora).

I've created an issue so we can track the work when somebody decides to
work on that:
https://github.com/389ds/389-ds-base/issues/5339

Sincerely,
Simon


On Wed, Jun 8, 2022 at 11:29 AM Pierre Rogier <progier(a)redhat.com&gt; wrote:

>  HI Simon,
>
>  I am speaking about the github actions that are triggered automatically
>  when committing some code.
>  Pushing  RHel images in a public domain repository does not seem to be a
>  great idea 😉, So running these tests on the intended OS/VERSION  is not
>  really an option...
>
>  So either we fix up the build framework in all versions or we add a fixup
>  phase (in
>  https://github.com/389ds/389-ds-base/blob/master/.github/workflows/compil...
>  ?) to tweak the vm and copy the missing library if it does not exist)
>  But  IMHO modifying the configure/makefile to use libldap if libldap_r is
>  not available is the cleanest solution ...
>
>
>
>  On Wed, Jun 8, 2022 at 4:42 PM Simon Pichugin <spichugi(a)redhat.com&gt; wrote:
>
> > Hi Pierre,
> > The issue happens if you build older branches on Fedora 36 (where we have
> > OpenLDAP 2.6).
> >
> >    - Building 2.1 on F36 (where we have the libldap 2.6) - is okay.
> >    - And Building 2.0, 1.4.4 and 1.4.3 on F35 should be fine, too, as it
> >    has libldap_r.
> >
> > I need to think more about that, but I believe we are in the "dangerous"
> > territory when we build 389-ds-base with libdap from openldap-2.6, but it
> > will be used with openldap-2.4.
> > We shouldn't have issues on Fedora 35, but we may get issues on RHEL 8 or
> > SUSE if they don't have libldap/libldap_r fix from
> > https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
> > So we should always build with libldap_r the package that should be used
> > on the system where we use libldap_r.
> >
> > We may have the fix backported for the development use, but we should
> > always retest our fixes on the targeted distribution, IMHO.
> >
> > Regards,
> > Simon
> >
> >
> >
> > On Wed, Jun 8, 2022 at 6:28 AM Pierre Rogier <progier(a)redhat.com&gt; wrote:
> >
> >> FYI: I cherry picked a fix and got build error when building ldclt:
> >> 2022-06-08T12:48:07.9008916Z /usr/bin/ld: cannot find -lldap_r
> >>
> >> The build on 2.1 works so I suspect we need to fix the old branches
> >> the same way ...
> >>
> >> --
> >> --
> >>
> >> 389 Directory Server Development Team
> >> _______________________________________________
> >> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> >> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> >> https://lists.fedoraproject.org/archives/list/[e-mail]...
> >> Do not reply to spam on the list, report it:
> >> https://pagure.io/fedora-infrastructure
> >>
> > _______________________________________________
> > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]...
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >
>
>
>  --
>  --
>
>  389 Directory Server Development Team
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>