Bug 2035143

Summary: Please backport uint32 flag type support
Product: Red Hat Enterprise Linux 8 Reporter: Michel Lind <michel>
Component: gflagsAssignee: Jiri Kucera <jkucera>
Status: CLOSED ERRATA QA Contact: Evgeny Fedin <efedin>
Severity: unspecified Docs Contact: Šárka Jana <sjanderk>
Priority: unspecified    
Version: CentOS StreamCC: bstinson, carl, efedin, jhughes, jkucera, jwboyer, ovasik, sjanderk
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: 8.9   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gflags-2.1.2-8.el8 Doc Type: Enhancement
Doc Text:
.The `gflags` package now supports the `uint32` flag type .The `gflags` package, which implements command-line flags processing, now supports `uint32` as a flag type.
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-11-14 15:52:10 UTC Type: Feature Request
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:    
Bug Blocks: 2035144, 2058363    

Description Michel Lind 2021-12-23 04:33:15 UTC
Description of problem:
gflags added support for uint32 as flag type in https://github.com/gflags/gflags/commit/eaf05340dc9e5367fdd43a9eea0c39a0aec44f16, available starting in v2.2.0 (the version after v2.1.2 that is in RHEL/CentOS 8.x CRB and PowerTools).

This is needed to build fbthrift for EPEL:
https://github.com/facebook/fbthrift/issues/409

which in turn is needed to build https://github.com/facebook/cachelib

Version-Release number of selected component (if applicable):
2.1.2-6.el8

Additional info:
This should be safe, release notes do not indicate any ABI break, in fact, 2.1.2 *restores* ABI compatibility with 2.0 and that was the last time ABI is mentioned
https://github.com/gflags/gflags/releases

Comment 1 Michel Lind 2022-01-12 00:49:46 UTC
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!

Comment 17 Michel Lind 2022-02-24 18:13:09 UTC
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

Comment 18 Michel Lind 2022-02-24 19:48:37 UTC
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.

Comment 20 Jiri Kucera 2022-02-25 18:31:33 UTC
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?

Comment 27 Johnny Hughes 2022-05-13 15:58:56 UTC
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.

Comment 28 Johnny Hughes 2022-05-13 16:00:41 UTC
NOTE:  EPEL needs this fix in CentOS-Stream-8-20220513.n.1 to be able to build items for RHEL8/Stream8.

Comment 29 Michel Lind 2022-05-13 21:20:05 UTC
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!

Comment 30 Michel Lind 2022-05-13 21:28:19 UTC
Since RHEL 8.6 is out now, is it possible to just rebuild ceres-solver now and not downgrade gflags in Stream?

Comment 31 Jiri Kucera 2022-05-13 22:44:40 UTC
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.

Comment 32 Carl George 🤠 2022-05-14 05:15:54 UTC
> 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.

Comment 41 errata-xmlrpc 2023-11-14 15:52:10 UTC
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