Bug 2038095
| Summary: | Please branch and build for epel9 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Jaroslav Škarvada <jskarvad> |
| Component: | libgsasl | Assignee: | Peter Lemenkov <lemenkov> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel9 | CC: | fedoraproject.org, lemenkov, mh, pabelanger, renich, wart |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libgsasl-1.10.0-3.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-04-13 16:14:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2054124, 2054125 | ||
| Bug Blocks: | 2037591 | ||
|
Description
Jaroslav Škarvada
2022-01-07 09:29:26 UTC
libgsasl depends on libidn - which got retired in EL9: https://gitlab.com/redhat/centos-stream/rpms/libidn - either this is being brought to EPEL 9 (I quickly checked and current RAWHIDE builds find in CentOS Stream 9 mock) -> Which would need to become available in EPEL9: #2054125 It also depends on libntlm - which is not yet packaged for CentOS Stream 9 -> #2054124 (In reply to Marcel Haerry from comment #1) > libgsasl depends on libidn - which got retired in EL9: > https://gitlab.com/redhat/centos-stream/rpms/libidn - either this is being > brought to EPEL 9 (I quickly checked and current RAWHIDE builds find in > CentOS Stream 9 mock) -> Which would need to become available in EPEL9: > #2054125 Either brought to EPEL 9 or libgsasl must stop depending on it According to the GNU project libidn2 is API compatbible with libidn (whatever that means). So I tried to build libgsasl with libidn2 as a dependency. This works fine on RAWHIDE. I then tried to chain build libntlm and libgsasl (with libidn2 as a requirement) and libgsasl at least built. I don't know how to test whether it actually still works with libidn2, but looks like the beginning of an alternative path? So instead of depending on libidn (and bring it into EPEL 9 although it was retired for CentOS Stream 9) we could depend on libidn2? And to test, I also chain built libntlm, patched libgsasl (with libidn2 as dep) AND exim and all builds fine. The chain builds in mock were done in centos-stream+epel-9-x86_64 Ah sorry - for libgsasl libidn is only a weak dep and with libidn2 you will have: checking for libidn... no configure: WARNING: GNU Libidn not found. Stringprep disabled. in the build output. So the libidn2 approach is not directly feasible. And just for the record: libgsasl wants `stringprep` from libidn, which was explicitly not implemented in libidn2 https://gitlab.com/libidn/libidn2/-/blob/master/doc/libidn2.texi#L400-409 Meanwhile, I requested branch for libidn in EPEL-9 so we can build it there. *** Bug 2056559 has been marked as a duplicate of this bug. *** libidn will soon be ready in EPEL-9 #2038095 Can we request a branch for EPEL 9 since the remaining blockers are addressed. If you don't want to maintain it in EPEL I can volunteer to maintain the package. I went ahead and requested a branch: https://pagure.io/releng/fedora-scm-requests/issue/43573 As mentioned I am willing to maintain it in EPEL 9 Please let me know if we should do it differently. The branch request got automatically closed, @lemenkov can you open one? Next try with me now being a maintainer of the project: https://pagure.io/releng/fedora-scm-requests/issue/43608 FEDORA-EPEL-2022-f4fa8589b2 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f4fa8589b2 FEDORA-EPEL-2022-f4fa8589b2 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days |