bump libtirpc to 1.0.1

From: Peter Rosin <[email protected]>

Hi!

I'd like to bump libtirpc to 1.0.1. However there is an api incompatibility introduced in 0.3.2 which requires a patch to rpcbind, which I took from upstream. The rpcbind patch make rpcbind work with either tirpc 0.3.2 or 1.0.1, so I added that patch first in the series even if it might seem backwards.

Note that I have not tested the rpcbind patch with more than a compile test. I know nothing about rpcbind.

That also goes for the changes to libtirpc patch 0007-Disable-DES-..., which removes DES support, since apparently musl and uclibc do not provide DES. I know nothing about musl and uclibc and have not tested if there are more newfangled DES things that needs to be removed...

Cheers,
Peter

Peter Rosin (2):
rpcbind: backport adjustment to changes in libtirpc 1.0.1
libtirpc: bump to version 1.0.1

 ...able-parts-of-TIRPC-requiring-NIS-support.patch |   14 ++--
 ...0007-Disable-DES-authentification-support.patch |   85 +++++++++++++++++---
 ...d-missing-rwlock_unlocks-in-xprt_register.patch |   63 +++++++++++++++
 package/libtirpc/libtirpc.hash                     |    4 +-
 package/libtirpc/libtirpc.mk                       |    2 +-
 ...ly-Don-t-use-the-xp_auth-pointer-directly.patch |   42 ++++++++++
 6 files changed, 191 insertions(+), 19 deletions(-)
 create mode 100644 package/libtirpc/0008-Add-missing-rwlock_unlocks-in-xprt_register.patch
 create mode 100755 package/rpcbind/0002-handle_reply-Don-t-use-the-xp_auth-pointer-directly.patch

1.7.10.4

From: Peter Rosin <[email protected]>

---
 ...ly-Don-t-use-the-xp_auth-pointer-directly.patch |   42 ++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100755 package/rpcbind/0002-handle_reply-Don-t-use-the-xp_auth-pointer-directly.patch

new file mode 100755
index 0000000..6145514
@@ -0,0 +1,42 @@
+From 9194122389f2a56b1cd1f935e64307e2e963c2da Mon Sep 17 00:00:00 2001
+From: Steve Dickson <[email protected]>
+Date: Mon, 2 Nov 2015 17:05:18 -0500
+Subject: [PATCH] handle_reply: Don't use the xp_auth pointer directly
+
+In the latest libtirpc version to access the xp_auth
+one must use the SVC_XP_AUTH macro. To be backwards
+compatible a couple ifdefs were added to use the
+macro when it exists.
+
+Signed-off-by: Steve Dickson <[email protected]>
+[peda at axentia.se: backport from upstream]
+Signed-off-by: Peter Rosin <[email protected]>
+---
+ src/rpcb_svc_com.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/src/rpcb_svc_com.c b/src/rpcb_svc_com.c
+index 4ae93f1..22d6c84 100644
+--- a/src/rpcb_svc_com.c
++++ b/src/rpcb_svc_com.c
+@@ -1295,10 +1295,17 @@ handle_reply(int fd, SVCXPRT *xprt)
+ 	a.rmt_localvers = fi->versnum;
+ 
+ 	xprt_set_caller(xprt, fi);
++#if defined(SVC_XP_AUTH)
++	SVC_XP_AUTH(xprt) = svc_auth_none;
++#else 
+ 	xprt->xp_auth = &svc_auth_none;
++#endif
+ 	svc_sendreply(xprt, (xdrproc_t) xdr_rmtcall_result, (char *) &a);
++#if !defined(SVC_XP_AUTH)
+ 	SVCAUTH_DESTROY(xprt->xp_auth);
+ 	xprt->xp_auth = NULL;
++#endif
++
+ done:
+ 	if (buffer)
+ 		free(buffer);
+-- 
+2.5.3
+

1.7.10.4

From: Peter Rosin <[email protected]>

Adjust patch 0001 to trivial changes.
Adjust patch 0007 to remove new DES things.
Add patch 0008 directly from upstream to fix a late problem in the 1.0.1 release.

---
 ...able-parts-of-TIRPC-requiring-NIS-support.patch |   14 ++--
 ...0007-Disable-DES-authentification-support.patch |   85 +++++++++++++++++---
 ...d-missing-rwlock_unlocks-in-xprt_register.patch |   63 +++++++++++++++
 package/libtirpc/libtirpc.hash                     |    4 +-
 package/libtirpc/libtirpc.mk                       |    2 +-
 5 files changed, 149 insertions(+), 19 deletions(-)
 create mode 100644 package/libtirpc/0008-Add-missing-rwlock_unlocks-in-xprt_register.patch

index 7f58ab3..e51c5a4 100644
@@ -11,6 +11,8 @@ Signed-off-by: Thomas Petazzoni <[email protected]>
 Signed-off-by: "Yann E. MORIN" <[email protected]>
 [joerg.krause at embedded.rocks: update for 0.3.2]
 Signed-off-by: J?rg Krause <[email protected]>
+[peda at axentia.se: update for 1.0.1]
+Signed-off-by: Peter Rosin <[email protected]>
 ---
  src/Makefile.am | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

@@ -19,23 +21,23 @@ diff --git a/src/Makefile.am b/src/Makefile.am
 index 6cc567a..9834f9a 100644
 --- a/src/Makefile.am
 +++ b/src/Makefile.am
-@@ -51,7 +51,7 @@ libtirpc_la_SOURCES = auth_none.c auth_unix.c authunix_prot.c bindresvport.c cln
-         rpc_callmsg.c rpc_generic.c rpc_soc.c rpcb_clnt.c rpcb_prot.c \
+@@ -24,7 +24,7 @@ libtirpc_la_SOURCES = auth_none.c auth_unix.c authunix_prot.c bindresvport.c cln
          rpcb_st_xdr.c svc.c svc_auth.c svc_dg.c svc_auth_unix.c svc_auth_none.c \
+ 	svc_auth_des.c \
          svc_generic.c svc_raw.c svc_run.c svc_simple.c svc_vc.c getpeereid.c \
 -        auth_time.c auth_des.c authdes_prot.c debug.c
 +        auth_des.c authdes_prot.c debug.c
  
  ## XDR
- libtirpc_la_SOURCES += xdr.c xdr_rec.c xdr_array.c xdr_float.c xdr_mem.c xdr_reference.c xdr_stdio.c
-@@ -68,8 +68,8 @@ if GSS
+ libtirpc_la_SOURCES += xdr.c xdr_rec.c xdr_array.c xdr_float.c xdr_mem.c xdr_reference.c xdr_stdio.c xdr_sizeof.c
+@@ -41,8 +41,8 @@ if GSS
      libtirpc_la_CFLAGS = -DHAVE_RPCSEC_GSS $(GSSAPI_CFLAGS)
  endif
  
 -libtirpc_la_SOURCES += key_call.c key_prot_xdr.c getpublickey.c
--libtirpc_la_SOURCES += netname.c netnamer.c rtime.c
+-libtirpc_la_SOURCES += netname.c netnamer.c rpcdname.c rtime.c
 +#libtirpc_la_SOURCES += key_call.c key_prot_xdr.c getpublickey.c
-+#libtirpc_la_SOURCES += netname.c netnamer.c rtime.c
++#libtirpc_la_SOURCES += netname.c netnamer.c rpcdname.c rtime.c
  
  CLEANFILES	       = cscope.* *~
  DISTCLEANFILES	       = Makefile.in

index f171870..cd65164 100644
@@ -1,4 +1,4 @@
 # From sourceforge's info on download page:
-sha1   af9b74d0c4d1499a7b1a43e396e5b7d62180ea65  libtirpc-0.3.2.tar.bz2
+sha1   8da1636f98b5909c0d587e7534bc1e91f5c1a970  libtirpc-1.0.1.tar.bz2
 # Locally computed
-sha256 2008a379f37f2c5d5a87a568b06707422cc3e4f5da305f7fb71f3f4c6d473ffc  libtirpc-0.3.2.tar.bz2
+sha256 5156974f31be7ccbc8ab1de37c4739af6d9d42c87b1d5caf4835dda75fcbb89e  libtirpc-1.0.1.tar.bz2

index 8f49356..70a31ac 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-LIBTIRPC_VERSION = 0.3.2
+LIBTIRPC_VERSION = 1.0.1
 LIBTIRPC_SOURCE = libtirpc-$(LIBTIRPC_VERSION).tar.bz2
 LIBTIRPC_SITE = http://downloads.sourceforge.net/project/libtirpc/libtirpc/$(LIBTIRPC_VERSION)
 LIBTIRPC_LICENSE = BSD-3c

1.7.10.4

Thomas, Peter,

FYI the new 1.0.1 version of libtirpc contains my patch to remove the calls to atomic operations that were causing a lot of autobuild failures on SPARC (and probably some other lesser-used arches too). Took a bit of negotiation to get the patch into a form they were happy to accept, but we got there in the end.

So when the bump to 1.0.1 goes in we can expect this class of autobuild issues to go away.

regards

Brendan

Dear Brendan Heading,

Excellent, thanks a lot for working on this topic!

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Hi!

What are we waiting for anyway? Anything I can do to move this along?

I thought I had straightened out all question marks?

Cheers,
Peter

Dear Peter Rosin,

We are right now preparing the 2015.11 release, so at this point, no version bump is merged in master. We are merging some of the new features and version bumps in "next" but this tends to happen more slowly than usual since we try to focus a bit our effort on the master branch.

But your patch is not forgotten, it is listed in our patch tracking system at http://patchwork.ozlabs.org/project/buildroot/list/.

Thanks!

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Dear Peter Rosin,

This patch breaks the build of libtirpc, with the following error:

rpc_soc.c:64:24: fatal error: rpcsvc/nis.h: No such file or directory
compilation terminated.
Makefile:749: recipe for target 'libtirpc_la-rpc_soc.lo' failed
make[4]: *** [libtirpc_la-rpc_soc.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
Makefile:552: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
Makefile:413: recipe for target 'all' failed
make[2]: *** [all] Error 2
package/pkg-generic.mk:188: recipe for target '/home/thomas/projets/buildroot/output/build/libtirpc-1.0.1/.stamp_built' failed make[1]: *** [/home/thomas/projets/buildroot/output/build/libtirpc-1.0.1/.stamp_built] Error 2 Makefile:36: recipe for target '_all' failed
make: *** [_all] Error 2

Without this patch applied, it builds fine. The failing configuration is:

BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2015.11-rc1-71-g90d1299.tar.bz2" BR2_TOOLCHAIN_EXTERNAL_GCC_4_7=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_10=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_RPCBIND=y
# BR2_TARGET_ROOTFS_TAR is not set

Can you look into this? Once fixed, maybe you can resend the series, and fix the permission problem in PATCH 1/2 at the same time?

Thanks a lot!

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Hi Thomas,

The toolchain does not match my arch, so I couldn't actually test it, but the fix looked simple enough (the include of rpcsvc/nis.h was added in the same upstream commit that added a new function that I also had to remove, and now I simply killed that include too).

So, there's a good chance this will work better even if I didn't actually test the failing case.

Cheers,
Peter

Dear Peter Rosin,

Just curious, which arch are you running? I think this toolchain is a x86 toolchain, so it should work pretty much on every PC out there. But maybe you're using a different platform?

Best regards,

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

The toolchain is x86_64 it seems, and I have a plain old x86 kernel on the system in question. Yes yes, I could have moved everything over somewhere. But didn't. :-)

Cheers,
Peter

Peter,

Hum, yes, indeed the pre-built Buildroot toolchains are meant to be used on a x86-64 system, my bad. I'll test your new series.

Thanks,

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Dear Peter Rosin,

Thanks for those patches. Is rpcbind the only user of libtirpc that is affected by the API change ?

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

oops, introduced in -> introduced since

Good question...

I think so, but who knows? Personally I would have kept libtirpc compatible (that was a possibility), but upstream decided to make the switch since they didn't know of any users and wanted to get in line with other tirpc implementations. Then this regression in rpcbind was discovered, which was rather close to home...

The changed interface was thought to be only for adding custom authenticators to RPC, something that is thought to be extremely specialized, but the rpcbind use looks like a workaround for problems getting replies out when using libtirpc somewhat strangely (again, I don't know rpcbind and have only had a cursory look at the code). If a package is using libtirpc normally and do no strange things (unlike rpcbind, which probably is quite special) and don't add its own application specific RPC authenticator, it should not be affected. But as I said, who knows?

Fixing breakage in libtirpc users should be straightforward if any come up, and another possibility is to add a patch to revert the final change that removed the old interface. However, that revert is touching core areas in a number of places and is probably not fun to keep around for any length of time. It can be added if needed, is that good enough?

I can only find the upstream discussion in the mail archive at sf, which has a rather sucky interface, sorry.

Cheers,
Peter

https://sourceforge.net/p/libtirpc/mailman/libtirpc-devel/thread/5630F3AA.6050201%40RedHat.com/#msg34576143

So, I grepped for "xp_auth" in the sources of all other packages that sport a dependency on libtirpc (argus, busybox, conntrack-tools, lmbench, ltp-testsuite, nfs-utils, quota and xinetd) and came up empty.

Good enough?

Cheers,
Peter