Bug 1895872

Getdns scratch build example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=55225811

Flamethrower scratch build example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=55225811

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

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.

*** Bug 1841457 has been marked as a duplicate of this bug. ***

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.

(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?

(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.

(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.

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.

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

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.

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

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

Michal, this is explained in bug 1759510 comment 36.