Bug 1724865 - libsigrok missing libtirpc
Summary: libsigrok missing libtirpc
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libsigrok
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Horák
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-28 01:19 UTC by Rob Riggs
Modified: 2019-07-10 03:18 UTC (History)
2 users (show)

Fixed In Version: libsigrok-0.5.1-3.fc31 libsigrok-0.5.1-3.fc30 libsigrok-0.5.1-3.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-10 00:51:29 UTC


Attachments (Terms of Use)
Patch to add tirpc dependency in order to regain VXI support. (1.46 KB, patch)
2019-06-28 01:19 UTC, Rob Riggs
no flags Details | Diff

Description Rob Riggs 2019-06-28 01:19:09 UTC
Created attachment 1585389 [details]
Patch to add tirpc dependency in order to regain VXI support.

Description of problem:
libsigrok is being built without VXI support

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

How reproducible:
Always

Steps to Reproduce:
1. Attempt to use sigrok-cli with any VXI device
2. Review the output of the RPM build process
3. etc.

Actual results:
Does not understand "vxi" as a communication protocol

Expected results:
Understands the "vxi" protocol specifier.

Additional info:
This is broken since the removal of RPC from glibc (Fedora 28).

./configure CPPFLAGS=-I/usr/include/tirpc LDFLAGS=-ltirpc

Patch for spec file attached.

Is there an update to autotools that will find this library when RPC is needed?

Comment 1 Dan Horák 2019-06-28 09:48:11 UTC
I might have something for the libtirpc autodetection in my git clone ...

Comment 2 Fedora Update System 2019-06-28 10:21:00 UTC
FEDORA-2019-f8eeec9679 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f8eeec9679

Comment 3 Fedora Update System 2019-06-28 18:25:48 UTC
libsigrok-0.5.1-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f23af0cef0

Comment 4 Fedora Update System 2019-06-28 21:44:29 UTC
libsigrok-0.5.1-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f8eeec9679

Comment 5 Rob Riggs 2019-06-29 03:30:12 UTC
Yeah... there's a problem with libtirpc that I believe did not exist with glibc RPC.  The device I have apparently only speaks TCP over port 111 (portmap).  That's in direct conflict libtirpc, which says this:

rpcb_clnt.c:
432		/*
433		 * Try UDP only - there are some portmappers out
434		 * there that use UDP only.
435		 */

It then goes on to override the protocol specified by the caller.

Wireshark shows that it is switching to UDP while querying portmapper.

Now... the really stupid thing about all of this is that litirpc has already called GETADDR to negotiated the protocol version with the portmapper over the TCP connection!!  That makes the fallback to UDP completely unnecessary.  It starts the fallback halfway through the conversation with the portmapper, when doing the GETPORT call.

With the following patch to libtirpc, sigrok-cli finally works:

--- libtirpc-1.1.4/src/rpcb_clnt.c.orig	2019-06-28 22:23:02.304547981 -0500
+++ libtirpc-1.1.4/src/rpcb_clnt.c	2019-06-28 22:23:14.505332538 -0500
@@ -429,11 +429,7 @@
 	CLIENT *client = NULL;
 	rpcvers_t pmapvers = 2;
 
-	/*
-	 * Try UDP only - there are some portmappers out
-	 * there that use UDP only.
-	 */
-	if (nconf == NULL || strcmp(nconf->nc_proto, NC_TCP) == 0) {
+	if (nconf == NULL) {
 		struct netconfig *newnconf;
 
 		if ((newnconf = getnetconfigent("udp")) == NULL) {
@@ -442,7 +438,8 @@
 		}
 		client = getclnthandle(hostname, newnconf, tgtaddr);
 		freenetconfigent(newnconf);
-	} else if (strcmp(nconf->nc_proto, NC_UDP) == 0) {
+	} else if (strcmp(nconf->nc_proto, NC_UDP) == 0 ||
+	    strcmp(nconf->nc_proto, NC_TCP) == 0) {
 		if (strcmp(nconf->nc_protofmly, NC_INET) != 0)
 			return NULL;
 		client = getclnthandle(hostname, nconf, tgtaddr);


$ sigrok-cli --driver=siglent-sds:conn=vxi/sds2204x --scan
The following devices were found:
siglent-sds - Siglent SDS2204X 1.2.2.2 R19 with 4 channels: CH1 CH2 CH3 CH4

Comment 6 Dan Horák 2019-06-29 07:10:52 UTC
Rob, could you, please, make a separate bug report against libtirpc for the patch from comment #5? We should get it fixed upstream, thanks.

Comment 7 Rob Riggs 2019-06-29 16:30:00 UTC
I am happy to do so.  https://bugzilla.redhat.com/show_bug.cgi?id=1725329

With that said, has Red Hat considered just forking the GLIBC sunrpc code and adding whatever features it thinks are necessary instead of relying on libtirpc?  I was looking at the two code bases to determine whether there was any commonality or if this fallback behavior was hidden somewhere within GLIBC's implementation.  It does not appear to invoke any such behavior.

It is also apparent that the GLIBC code is cleaner and more modern.  GLIBC's code appears cultivated and cared for.  libtirpc appears to have been forked long ago and looks like an accumulation of hacks over time.  This seems like a step in the wrong direction for maintaining OS quality and stability.  libtirpc doesn't just need bug fixes.  It needs wholesale refactoring.

The behavior I am hitting appears to be some vestigial behavior of an ancient RPC stack.  It has existed from the beginning of libtirpc's repository history.  (I am not up for doing further code archeology.)

As someone who uses RHEL extensively in my professional life, I would hate to see this hackery make its way into Red Hat's enterprise product.  I am disappointed I have to deal with this sort of unnecessary breakage in Fedora.

Comment 8 Dan Horák 2019-06-29 17:11:52 UTC
Per https://fedoraproject.org/wiki/Changes/SunRPCRemoval the switch to libtirpc was initiated by glibc developers for technical reasons.

Comment 9 Rob Riggs 2019-06-29 18:03:25 UTC
Per that wiki page:

"As a result, upstream decided to move Sun RPC support to a separate library, libtirpc, which has been packaged since Fedora 7."

What does "upstream" mean in this regard?  Red Hat?

The rest of the Linux community appears to be using libntirpc (notice the "n"), which is also in much better shape than libtirpc:

https://github.com/CentOS-Storage-SIG/libntirpc/blob/master/README.md

This is also shipped by Fedora.  Please link libsigrok to this RPC library instead.

Comment 10 Rob Riggs 2019-06-29 18:33:01 UTC
Nevermind on libntirpc... it appears to have an incompatible API.

Comment 11 Dan Horák 2019-07-01 07:05:40 UTC
(In reply to Rob Riggs from comment #9)
> Per that wiki page:
> 
> "As a result, upstream decided to move Sun RPC support to a separate
> library, libtirpc, which has been packaged since Fedora 7."
> 
> What does "upstream" mean in this regard?  Red Hat?

glibc upstream I suppose, where Red Hat represents only a minority
 
> The rest of the Linux community appears to be using libntirpc (notice the
> "n"), which is also in much better shape than libtirpc:
> 
> https://github.com/CentOS-Storage-SIG/libntirpc/blob/master/README.md
> 
> This is also shipped by Fedora.  Please link libsigrok to this RPC library
> instead.

shame libntirpc is with incompatible API, it really looks more active, etc

Comment 12 Fedora Update System 2019-07-10 00:51:29 UTC
libsigrok-0.5.1-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2019-07-10 03:18:47 UTC
libsigrok-0.5.1-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.


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