Bug 2035143
Summary: | Please backport uint32 flag type support | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Michel Lind <michel> |
Component: | gflags | Assignee: | Jiri Kucera <jkucera> |
Status: | CLOSED ERRATA | QA Contact: | Evgeny Fedin <efedin> |
Severity: | unspecified | Docs Contact: | Šárka Jana <sjanderk> |
Priority: | unspecified | ||
Version: | CentOS Stream | CC: | bstinson, carl, efedin, jhughes, jkucera, jwboyer, ovasik, sjanderk |
Target Milestone: | rc | Keywords: | 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
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 |