RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1895872 - libuv-devel is not available for EPEL builds
Summary: libuv-devel is not available for EPEL builds
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libuv
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Zuzana Svetlikova
QA Contact: Jan Houska
URL:
Whiteboard:
: 1841457 (view as bug list)
Depends On: 1759510 1809314
Blocks: 1911092
TreeView+ depends on / blocked
 
Reported: 2020-11-09 10:29 UTC by Petr Menšík
Modified: 2021-05-14 20:13 UTC (History)
22 users (show)

Fixed In Version: libuv-1.40.0-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-04 21:14:22 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Petr Menšík 2020-11-09 10:29:54 UTC 
Description of problem:
I would like to build EPEL8 builds of flamethrower and getdns. They need libuv-devel, which only has historical libuv-devel built. But because newer libuv package is provided, it does not match and fail the build.

libuv-devel should be moved from buildroot to CRB, where it could be used for dependent packages builds.

Version-Release number of selected component (if applicable):
libuv-1.38.0-2.el8

How reproducible:
reliable

Steps to Reproduce:
1. fedpkg clone --anonymous getdns
2. cd getdns
3. fedpkg --release epel8-playground scratch-build

Actual results:
...
DEBUG util.py:636:  Package gcc-c++-8.3.1-5.1.el8.x86_64 is already installed.
DEBUG util.py:636:  Package make-1:4.2.1-10.el8.x86_64 is already installed.
DEBUG util.py:634:  Error: 
DEBUG util.py:634:   Problem: conflicting requests
DEBUG util.py:634:    - nothing provides libuv.so.1 needed by libuv-devel-1:1.23.1-1.el8.i686
DEBUG util.py:634:    - nothing provides libuv(x86-32) = 1:1.23.1-1.el8 needed by libuv-devel-1:1.23.1-1.el8.i686
DEBUG util.py:634:    - nothing provides libuv(x86-64) = 1:1.23.1-1.el8 needed by libuv-devel-1:1.23.1-1.el8.x86_64
DEBUG util.py:636:  (try to add '--skip-broken' to skip uninstallable packages)

Expected results:
libuv-devel with the same version as distributed libuv is available.

Additional info:
Related to bug #1759510 comment #33 and bug #1809314. Some ancient libuv-devel is provided, but does not match updated libuv build shipped for CMake. No modules involved.
Comment 1 Petr Menšík 2020-11-09 13:48:18 UTC 
Getdns scratch build example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=55225811

Flamethrower scratch build example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=55225811
Comment 2 Carl George 🤠 2020-11-10 02:33:17 UTC 
This isn't due to a version mismatch.  The EPEL8 Playground buildroot is based on RHEL8 with the CentOS Linux 8 Devel repo (see the "external repos" listed in the epel8-playground-build tag [0]).  Recreating that locally in a container, libuv-devel installs just fine, pulling in libuv as a dependency.


[root@el8-container:~]# dnf install libuv-devel
Last metadata expiration check: 0:00:22 ago on Tue Nov 10 02:25:56 2020.
Dependencies resolved.
==============================================================================
 Package           Architecture Version                 Repository       Size
==============================================================================
Installing:
 libuv-devel       x86_64       1:1.23.1-1.el8          devel            34 k
Installing dependencies:
 libuv             x86_64       1:1.23.1-1.el8          appstream       134 k

Transaction Summary
==============================================================================
Install  2 Packages

Total download size: 169 k
Installed size: 438 k
Is this ok [y/N]:


I think what is happening is that something is out of sync or corrupt with the EPEL8 Playground buildroot causing libuv to not be installable from the RHEL8 external repo.  I have opened a ticket for releng to investigate [1].

All that said, adding libuv-devel to CRB outright is still a valid request, and this issue should move forward as such.


[0] https://koji.fedoraproject.org/koji/taginfo?tagID=10328
[1] https://pagure.io/releng/issue/9848
Comment 3 Carl George 🤠 2020-11-10 20:55:08 UTC 
Correction, I see the mismatch now.  RHEL 8.3 bumped the libuv to 1.38.0-2.el8.  The CentOS Devel repo still has the rebuild of libuv 1.23.1-1.el8.  The EPEL 8 buildroot only gets access to the latest version of the package, not all versions like in my test.  Once CentOS Linux 8.3 is done being rebuilt, the EPEL 8 buildroot external repos can be synced again and clear this up.
Comment 8 Stephen Gallagher 2020-11-30 13:15:25 UTC 
*** Bug 1841457 has been marked as a duplicate of this bug. ***
Comment 9 Robert Scheck 2020-12-27 12:36:48 UTC 
Cross-filed case 02833143 at the Red Hat customer portal as Red Hat obviously does not seem to care. Speaking for multiple Red Hat customers, this still actively prevents the usage of third-party software such as Guacamole via EPEL.
Comment 10 Simone Caronni 2021-01-06 11:38:01 UTC 
(In reply to Robert Scheck from comment #9)
> Cross-filed case 02833143 at the Red Hat customer portal as Red Hat
> obviously does not seem to care. Speaking for multiple Red Hat customers,
> this still actively prevents the usage of third-party software such as
> Guacamole via EPEL.

Did you get any reply from Redhat?
Comment 11 Josh Boyer 2021-01-06 12:53:49 UTC 
(In reply to Simone Caronni from comment #10)
> (In reply to Robert Scheck from comment #9)
> > Cross-filed case 02833143 at the Red Hat customer portal as Red Hat
> > obviously does not seem to care. Speaking for multiple Red Hat customers,
> > this still actively prevents the usage of third-party software such as
> > Guacamole via EPEL.
> 
> Did you get any reply from Redhat?

Most of Red Hat was on PTO when the case came in.  We are re-evaluating this now.  Thank you for filing the case.
Comment 12 Robert Scheck 2021-01-06 13:06:38 UTC 
(In reply to Josh Boyer from comment #11)
> (In reply to Simone Caronni from comment #10)
> > (In reply to Robert Scheck from comment #9)
> > Did you get any reply from Redhat?
> 
> Most of Red Hat was on PTO when the case came in.  We are re-evaluating this now.  Thank you for filing the case.

Except for the usual flowers of speech the case did not yet move forward. I meanwhile requested the RFE form to also provide formal business justification (if needed). I hope this really moves forward next week, given common PTO should be over then.
Comment 16 Josh Boyer 2021-01-07 18:01:25 UTC 
Thank you again for the patience and provided usecases.  That kind of information is valuable.  We have further evaluated it and it will be available in CentOS Stream relatively soon, and a future RHEL 8 minor release.
Comment 29 Jan Houska 2021-02-08 15:23:13 UTC 
Verified tested

for 

fedpkg-1.40-2.el8.noarch

rpm -qa libuv*
libuv-devel-1.40.0-1.el8.x86_64
libuv-1.40.0-1.el8.x86_64
libuv-static-1.40.0-1.el8.x86_64
libuv-debugsource-1.40.0-1.el8.x86_64
libuv-debuginfo-1.40.0-1.el8.x86_64

on jhouska-1MT-RHEL-8.4.0-20210202.n.0-111226-2021-02-08-15-09

fedpkg clone --anonymous getdns
Failed to set locale, defaulting to C.UTF-8
Cloning into 'getdns'...
remote: Enumerating objects: 272, done.
remote: Counting objects: 100% (272/272), done.
remote: Compressing objects: 100% (268/268), done.
remote: Total 272 (delta 130), reused 2 (delta 0), pack-reused 0
Receiving objects: 100% (272/272), 56.89 KiB | 1.12 MiB/s, done.
Resolving deltas: 100% (130/130), done.
[root@host-10-0-138-49 ~]# cd getdns/
[root@host-10-0-138-49 getdns]# fedpkg  --release epel8-playground scratch-build

Failed to set locale, defaulting to C.UTF-8
Kerberos authentication is used, but you do not have a valid credential.
Please use kinit to get credential with a principal that has realm FEDORAPROJECT.ORG
Could not execute scratch_build: Could not login to https://koji.fedoraproject.org/kojihub
Comment 30 Peter Georg 2021-02-14 11:19:10 UTC 
Seems like there is at least one additional step required to get the libuv-devel into CentOS Stream:

The current compose (CentOS-Stream-8-20210209.n.0) already includes the updated libuv-1.40.0-1.el8.x86_64, but there is no libuv-devel-1.40.0-1.el8.x86_64 in PowerTools.

Probably someone is already working on this step, just posting here to make sure it is not forgotten.
Comment 31 Carl George 🤠 2021-03-04 21:14:22 UTC 
I can see both libuv and libuv-devel available in CS8.

# dnf config-manager --enable powertools
# repoquery -q --nvr libuv libuv-devel
libuv-1.40.0-1.el8
libuv-devel-1.40.0-1.el8
Comment 32 Michal Ambroz 2021-05-12 21:28:05 UTC 
libuv-devel is not available in the s390x

For example here affected build of radare2 - fails on 
https://koji.fedoraproject.org/koji/taskinfo?taskID=67726326
Comment 33 Carl George 🤠 2021-05-14 20:13:11 UTC 
Michal, this is explained in bug 1759510 comment 36.
Note You need to log in before you can comment on or make changes to this bug.