Jiri Kucera (or anyone else from Red Hat), any progress on this? Without this we'd have to carry gflags, fbthrift, and cachelib internally, and we'd really rather have them in EPEL / Hyperscale as much as possible, so others can use them too. Thanks!

Only glog and opencv needs rebuilding, it seems. Can this be done in time for RHEL 8.6?

❯ sudo dnf repoquery --disablerepo=\* --enablerepo=baseos-source,appstream-source,powertools-source,extras-source,ha-source,rt-source,resilientstorage-source --whatrequires gflags-devel
CentOS Stream 8 - BaseOS - Source                                                     260 kB/s | 607 kB     00:02
CentOS Stream 8 - AppStream - Source                                                  509 kB/s | 1.2 MB     00:02
CentOS Stream 8 - PowerTools - Source                                                 119 kB/s | 216 kB     00:01
CentOS Stream 8 - Extras - Source                                                     8.1 kB/s |  11 kB     00:01
CentOS Stream 8 - HighAvailability - Source                                            13 kB/s |  18 kB     00:01
CentOS Stream 8 - RT - Source                                                         5.6 kB/s | 7.1 kB     00:01
CentOS Stream 8 - ResilientStorage - Source                                            12 kB/s |  16 kB     00:01
glog-0:0.3.5-3.el8.src
glog-0:0.3.5-4.el8.0.1.src
glog-0:0.3.5-4.el8.src
opencv-0:3.4.6-6.el8.src
opencv-0:3.4.6-7.el8.src

also commented on https://bugzilla.redhat.com/show_bug.cgi?id=2056509 as well - opencv rebuilds fine once ceres-solver (which is unpublished) is bumped and rebuilt.

Hello Michel,

gflags and glog were built in a side tag in RHEL build system, however it looks like that this has been not reflected by CentOS Stream build system, which then became the source of inconsistencies. Unfortunatelly, I must revert gflags back to 2.1.2 in RHEL 8 for the several reasons:
(1) as noted in bz2056509, ceres-solver need to be rebuilt, but there is no time to do this in 8.6 (before rebuild can happen, ceres-solver must be onboarded to the internal CI system, which involves additional paperwork and discussion with QE for which there is no time and capacity now)
(2) some teams which are consuming gflags internally may be negatively affected by the soname bump

Instead of doing an upgrade to 2.2.2, I will rather backport patches with desired features to 2.1.2. Will it work for you?

OK .. I am fixing this issue in CentOS Stream 8 now .. with:

gflags-2.1.2-7.el8
glog-0.3.5-5.el8.0.1 (had to increment to build .. it was initially built against gflags-2.2.2-1.el8)

This will be in compose CentOS-Stream-8-20220513.n.1, which is currently building.

NOTE:  EPEL needs this fix in CentOS-Stream-8-20220513.n.1 to be able to build items for RHEL8/Stream8.

Hi Jiri,

(In reply to Jiri Kucera from comment #20)
> Hello Michel,
> 
> gflags and glog were built in a side tag in RHEL build system, however it
> looks like that this has been not reflected by CentOS Stream build system,
> which then became the source of inconsistencies. Unfortunatelly, I must
> revert gflags back to 2.1.2 in RHEL 8 for the several reasons:
> (1) as noted in bz2056509, ceres-solver need to be rebuilt, but there is no
> time to do this in 8.6 (before rebuild can happen, ceres-solver must be
> onboarded to the internal CI system, which involves additional paperwork and
> discussion with QE for which there is no time and capacity now)
> (2) some teams which are consuming gflags internally may be negatively
> affected by the soname bump
> 
> Instead of doing an upgrade to 2.2.2, I will rather backport patches with
> desired features to 2.1.2. Will it work for you?

Sorry I missed this. The only feature I need is the uint32 flag type, so... that will be OK if that makes it in. Thanks!

Since RHEL 8.6 is out now, is it possible to just rebuild ceres-solver now and not downgrade gflags in Stream?

Hi Michel,

gflags is already downgraded in RHEL 8 for the reason I mentioned earlier (the sad thing is downgrading was not possible without introducing Epoch). Since Epoch is, if I got it well, ignored when comparing package versions in RHEL build system, the reverted gflags, which is now only in RHEL 8.6 CodeReadyBuilder repo, was not propagated to Stream PowerTools, since sync algorithm (or is this done by human?) thinks that the gflags rpm in PowerTools is newer than gflags rpm in CodeReadyBuilder (but this can be fixed at any time and people will start complaining again).

I can either patch gflags with uint32 flag feature or revert the revert and then rebuild ceres-solver. The latter will be better for Stream since there will be no need to rebuild dependent packages. The former will be better for RHEL since there will be no surprises.

> Since RHEL 8.6 is out now, is it possible to just rebuild ceres-solver now and not downgrade gflags in Stream?

> The latter will be better for Stream since there will be no need to rebuild dependent packages.

It's already done, as Johnny pointed out in comment 27.

Whether or not it is decided to backport the uint32 flag commit or upgrade to version 2.2 again, c8s will follow whatever RHEL decides.  It doesn't make a difference for us either way.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (gflags bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:7194