Bug 1536187 - build: glibc has removed legacy rpc headers and rpcgen in Fedora28, use libtirpc
Summary: build: glibc has removed legacy rpc headers and rpcgen in Fedora28, use libtirpc
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: build
Version: 3.13
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On: 1536186 1538723
Blocks: glusterfs-3.13.3
TreeView+ depends on / blocked
 
Reported: 2018-01-18 20:22 UTC by Kaleb KEITHLEY
Modified: 2018-06-20 18:24 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1536186
Environment:
Last Closed: 2018-06-20 18:24:53 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1537184 0 unspecified CLOSED infra: install libtirpc-devel and rpcgen on jenkins hosts 2021-02-22 00:41:40 UTC

Internal Links: 1537184

Description Kaleb KEITHLEY 2018-01-18 20:22:29 UTC
+++ This bug was initially created as a clone of Bug #1536186 +++

Description of problem:

See $Summary. Other Linux distributions are doing the same; some others already have.

Switch to libtirpc(-devel) and unbundled rpcgen packages. For now rpcgen is still provided by the glibc-rpcgen RPM, but rpcsvc-proto's rpcgen subpackage is available now but will not be used until glibc-rpcgen is retired. (note, rpcsvc-proto's rpcgen is just named rpcgen-...rpm. I.e. not rpcsvc-proto-rpcgen.) Right now either one will satisfy the BuildRequires: rpcgen.

Also, when a .spec file has
  BuildRequires: foo-devel
it is not necessary to also have:
  BuildRequires: foo
or even:
  BuildRequires: foo foo-devel

The foo-devel package has a dependency on foo, which will install foo automatically. It's usually also not necessary to have a corresponding
  Requires: foo

as the rpmbuild process will also automatically determine the install-time dependencies.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Worker Ant 2018-01-18 21:02:20 UTC
REVIEW: https://review.gluster.org/19236 (build: glibc has removed rpc headers and rpcgen in Fedora28, use libtirpc) posted (#1) for review on release-3.13 by Kaleb KEITHLEY

Comment 2 Shyamsundar 2018-01-20 00:13:00 UTC
Updated blocks 3.13.2 as we are handling this in the packaging and will get the fix into the code by 3.13.3.

Comment 3 Worker Ant 2018-02-01 13:57:17 UTC
COMMIT: https://review.gluster.org/19236 committed in release-3.13 by "Kaleb KEITHLEY" <kkeithle> with a commit message- build: glibc has removed rpc headers and rpcgen in Fedora28, use libtirpc

Other Linux distributions are doing the same; some have already done
so.

Switch to libtirpc(-devel) and unbundled rpcgen packages. For now
rpcgen is still provided by the glibc-rpcgen RPM, but rpcsvc-proto's
rpcgen subpackage is available now; it will not be used until
glibc-rpcgen is retired. (note, rpcsvc-proto's rpcgen is just named
rpcgen-...rpm. I.e. not rpcsvc-proto-rpcgen-...rpm.) Either one
will satisfy the BuildRequires: rpcgen.

Also, when a .spec file has
  BuildRequires: foo-devel
it is not necessary to also have:
  BuildRequires: foo
or even:
  BuildRequires: foo foo-devel

The foo-devel package has a dependency on foo, which will install foo
automatically. It's usually also not necessary to have a corresponding
  Requires: foo
as the rpmbuild process will also automatically determine the
install-time dependencies.

See also Change-Id: I4a8292de2eddad16137df5998334133fc1e11261
and/or https://review.gluster.org/19311
and Change-Id: I97dc39c7844f44c36fe210aa813480c219e1e415
and/or https://review.gluster.org/#/c/19330/

Change-Id: I86f847dfda0fef83e22c6e8b761342d652a2d9ba
BUG: 1536187
Signed-off-by: Kaleb S. KEITHLEY <kkeithle>

Comment 4 Shyamsundar 2018-06-20 18:24:53 UTC
This bug reported is against a version of Gluster that is no longer maintained (or has been EOL'd). See https://www.gluster.org/release-schedule/ for the versions currently maintained.

As a result this bug is being closed.

If the bug persists on a maintained version of gluster or against the mainline gluster repository, request that it be reopened and the Version field be marked appropriately.


Note You need to log in before you can comment on or make changes to this bug.