* Re: librpcsecgss: FTBFS on GNU/kFreeBSD [not found] <20090703133142.14887.33854.reportbug@localhost.localdomain> @ 2013-11-24 5:19 ` Aníbal Monsalve Salazar 2013-11-24 9:09 ` Christoph Hellwig 0 siblings, 1 reply; 17+ messages in thread From: Aníbal Monsalve Salazar @ 2013-11-24 5:19 UTC (permalink / raw) To: linux-nfs On Fri, Jul 03, 2009 at 03:31:42PM +0200, Cyril Brulebois wrote: > Package: librpcsecgss > Version: 0.18-1 > Severity: important > Tags: patch pending > User: glibc-bsd-devel@lists.alioth.debian.org > Usertags: kfreebsd > > Hi, > > please find attached a trivial patch to fix the FTBFS on GNU/kFreeBSD: > [...] I've carried the patch below in Debian for a long time. Please consider merging it. >From dc2b55a7f83d6c505ba79b83089f365bb0c24bf1 Mon Sep 17 00:00:00 2001 From: Cyril Brulebois <kibi@debian.org> Date: Fri, 3 Jul 2009 15:31:42 +0200 Subject: librpcsecgss: FTBFS on GNU/kFreeBSD Fix FTBFS on GNU/kFreeBSD by using getpid() (rather than arc4random()) not only if __linux__ is defined, but also if __GLIBC__ is defined. Signed-off-by: Anibal Monsalve Salazar <anibal@debian.org> --- src/clnt_tcp.c | 2 +- src/clnt_udp.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/clnt_tcp.c b/src/clnt_tcp.c index 4da0d31..f2c3da0 100644 --- a/src/clnt_tcp.c +++ b/src/clnt_tcp.c @@ -225,7 +225,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz) * Initialize call message */ (void)gettimeofday(&now, (struct timezone *)0); -#ifdef __linux__ +#if defined (__linux__) || defined(__GLIBC__) call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec; #else call_msg.rm_xid = arc4random(); diff --git a/src/clnt_udp.c b/src/clnt_udp.c index fc803b2..fe95ed2 100644 --- a/src/clnt_udp.c +++ b/src/clnt_udp.c @@ -153,7 +153,7 @@ clntudp_bufcreate(raddr, program, version, wait, sockp, sendsz, recvsz) cu->cu_total.tv_usec = -1; cu->cu_sendsz = sendsz; cu->cu_recvsz = recvsz; -#ifdef __linux__ +#if defined (__linux__) || defined(__GLIBC__) call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec; #else call_msg.rm_xid = arc4random(); -- 1.8.4.2 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-11-24 5:19 ` librpcsecgss: FTBFS on GNU/kFreeBSD Aníbal Monsalve Salazar @ 2013-11-24 9:09 ` Christoph Hellwig 2013-11-24 13:07 ` Jim Rees 0 siblings, 1 reply; 17+ messages in thread From: Christoph Hellwig @ 2013-11-24 9:09 UTC (permalink / raw) To: linux-nfs On Sun, Nov 24, 2013 at 04:19:04PM +1100, An?bal Monsalve Salazar wrote: > (void)gettimeofday(&now, (struct timezone *)0); > -#ifdef __linux__ > +#if defined (__linux__) || defined(__GLIBC__) > call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec; > #else > call_msg.rm_xid = arc4random(); Using getpid() instead of a random generator seems fairly dangerous. Why don't we use a real RNG/PRNG here? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-11-24 9:09 ` Christoph Hellwig @ 2013-11-24 13:07 ` Jim Rees 2013-11-24 13:29 ` Christoph Hellwig 2013-12-04 13:13 ` Christoph Hellwig 0 siblings, 2 replies; 17+ messages in thread From: Jim Rees @ 2013-11-24 13:07 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-nfs Christoph Hellwig wrote: On Sun, Nov 24, 2013 at 04:19:04PM +1100, An?bal Monsalve Salazar wrote: > (void)gettimeofday(&now, (struct timezone *)0); > -#ifdef __linux__ > +#if defined (__linux__) || defined(__GLIBC__) > call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec; > #else > call_msg.rm_xid = arc4random(); Using getpid() instead of a random generator seems fairly dangerous. Why don't we use a real RNG/PRNG here? Maybe we're just trying to avoid collisions, and don't care if someone can guess xids? But either way, agreed. Also, shouldn't the existence of arc4random() be determined by configure? Isn't that why we use configure, so we don't need fragile ifdefs in the code? Is anyone maintaining this library? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-11-24 13:07 ` Jim Rees @ 2013-11-24 13:29 ` Christoph Hellwig 2013-12-04 13:13 ` Christoph Hellwig 1 sibling, 0 replies; 17+ messages in thread From: Christoph Hellwig @ 2013-11-24 13:29 UTC (permalink / raw) To: Jim Rees; +Cc: Christoph Hellwig, linux-nfs On Sun, Nov 24, 2013 at 08:07:53AM -0500, Jim Rees wrote: > Maybe we're just trying to avoid collisions, and don't care if someone can > guess xids? But either way, agreed. Also, shouldn't the existence of > arc4random() be determined by configure? Isn't that why we use configure, so > we don't need fragile ifdefs in the code? > > Is anyone maintaining this library? No idea. But the easiest would be to just link against libbsd on Linux to get the BSDish arc4random symbol. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-11-24 13:07 ` Jim Rees 2013-11-24 13:29 ` Christoph Hellwig @ 2013-12-04 13:13 ` Christoph Hellwig 2013-12-04 17:14 ` Chuck Lever 2013-12-04 18:24 ` J. Bruce Fields 1 sibling, 2 replies; 17+ messages in thread From: Christoph Hellwig @ 2013-12-04 13:13 UTC (permalink / raw) To: Jim Rees; +Cc: Christoph Hellwig, linux-nfs Btw, looks like librpcsecgss is indeed pretty much unmaintained. The last upstream release is a tarball drop from CITI in 2009 and there doesn't appear to be a source repository of any kind. I think the best idea would be to merge it into the libtirpc repo, as both the heritage and usage of the codebases is the same. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-04 13:13 ` Christoph Hellwig @ 2013-12-04 17:14 ` Chuck Lever 2013-12-04 17:53 ` Trond Myklebust 2013-12-04 18:24 ` J. Bruce Fields 1 sibling, 1 reply; 17+ messages in thread From: Chuck Lever @ 2013-12-04 17:14 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Jim Rees, linux-nfs On Dec 4, 2013, at 8:13 AM, Christoph Hellwig <hch@infradead.org> wrote: > Btw, looks like librpcsecgss is indeed pretty much unmaintained. The > last upstream release is a tarball drop from CITI in 2009 and there > doesn't appear to be a source repository of any kind. > > I think the best idea would be to merge it into the libtirpc repo, > as both the heritage and usage of the codebases is the same. Comparing what's packaged in nfs-utils-lib and what's in libtirpc: it appears libtirpc already has librpcsecgss. I assume librpcsecgss is still required on systems that use glibc's RPC implementation. But for systems that have libtirpc, maybe librpcsecgss is unneeded? Note: the GSS API provided here is not documented, AFAICT, and does not match the de facto standard provided by a modern Solaris libtirpc. I'd like to add the standard API to libtirpc and deprecate (but not remove) the current GSS API. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-04 17:14 ` Chuck Lever @ 2013-12-04 17:53 ` Trond Myklebust 2013-12-04 18:14 ` Chuck Lever 0 siblings, 1 reply; 17+ messages in thread From: Trond Myklebust @ 2013-12-04 17:53 UTC (permalink / raw) To: Lever Charles Edward; +Cc: Christoph Hellwig, Jim Rees, Linux NFS Mailing List On Dec 4, 2013, at 12:14, Chuck Lever <chuck.lever@oracle.com> wrote: > > On Dec 4, 2013, at 8:13 AM, Christoph Hellwig <hch@infradead.org> wrote: > >> Btw, looks like librpcsecgss is indeed pretty much unmaintained. The >> last upstream release is a tarball drop from CITI in 2009 and there >> doesn't appear to be a source repository of any kind. >> >> I think the best idea would be to merge it into the libtirpc repo, >> as both the heritage and usage of the codebases is the same. > > Comparing what's packaged in nfs-utils-lib and what's in libtirpc: it appears libtirpc already has librpcsecgss. It does? AFAICS a freshly cloned copy of libtirpc only contains the prehistoric krb4/DES implementation. I see no GSS library. I thought the reason why we deprecated librpcsecgss was that the MIT Kerberos libraries now have the equivalent hooks. Cheers Trond ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-04 17:53 ` Trond Myklebust @ 2013-12-04 18:14 ` Chuck Lever 2013-12-05 13:23 ` Christoph Hellwig 0 siblings, 1 reply; 17+ messages in thread From: Chuck Lever @ 2013-12-04 18:14 UTC (permalink / raw) To: Trond Myklebust; +Cc: Christoph Hellwig, Jim Rees, Linux NFS Mailing List On Dec 4, 2013, at 12:53 PM, Trond Myklebust <trondmy@gmail.com> wrote: > > On Dec 4, 2013, at 12:14, Chuck Lever <chuck.lever@oracle.com> wrote: > >> >> On Dec 4, 2013, at 8:13 AM, Christoph Hellwig <hch@infradead.org> wrote: >> >>> Btw, looks like librpcsecgss is indeed pretty much unmaintained. The >>> last upstream release is a tarball drop from CITI in 2009 and there >>> doesn't appear to be a source repository of any kind. >>> >>> I think the best idea would be to merge it into the libtirpc repo, >>> as both the heritage and usage of the codebases is the same. >> >> Comparing what's packaged in nfs-utils-lib and what's in libtirpc: it appears libtirpc already has librpcsecgss. > > It does? AFAICS a freshly cloned copy of libtirpc only contains the prehistoric krb4/DES implementation. I see no GSS library. I pulled from: git://git.infradead.org/~steved/libtirpc.git Yes, there's AUTH_DES support in libtirpc, and who knows if our implementation works. But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly the same API. And I'm able to build a working GSS-enabled version of rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. libtirpc applications currently have to link explicitly with libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. I'd like to add support in libtirpc for dynamically loading libgssapi_krb5 when it is needed. Then applications would need only invoke rpc_gss_*() (or the legacy authgss_*() equivalent) to get RPCSECGSS, if libgssapi_krb5 is already installed on their system. > I thought the reason why we deprecated librpcsecgss was that the MIT Kerberos libraries now have the equivalent hooks. My understanding: MIT Kerberos provides libgssapi_krb5. libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-04 18:14 ` Chuck Lever @ 2013-12-05 13:23 ` Christoph Hellwig 2013-12-05 13:41 ` Trond Myklebust 2013-12-05 16:15 ` Jim Rees 0 siblings, 2 replies; 17+ messages in thread From: Christoph Hellwig @ 2013-12-05 13:23 UTC (permalink / raw) To: Chuck Lever Cc: Trond Myklebust, Christoph Hellwig, Jim Rees, Linux NFS Mailing List, An?bal Monsalve Salazar, Steinar H. Gunderson [adding back Anibal, and adding Steinar as tirpc maintainer for Debian] On Wed, Dec 04, 2013 at 01:14:47PM -0500, Chuck Lever wrote: > But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly > the same API. And I'm able to build a working GSS-enabled version of > rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and > tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. > > libtirpc applications currently have to link explicitly with > libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. > MIT Kerberos provides libgssapi_krb5. > > libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. > > librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. So what's actually still using librpcsecgss and libgssglue? There is no rdepends for librpcsecgss on my Debian -stable system, and I couldn't find any obvious user for unstable either. For libgssglue1 -stable has a few consumers: nfs-common libtirpc1 librpcsecgss3 libgssglue-dev libgssapi-krb5-2 libgssapi-krb5-2 seems to have dropped the libgssglue dependency in unstable, but the others still seem to be be around. How does the situation look for Fedora and SuSE? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-05 13:23 ` Christoph Hellwig @ 2013-12-05 13:41 ` Trond Myklebust 2013-12-05 13:43 ` Christoph Hellwig 2013-12-10 6:27 ` NeilBrown 2013-12-05 16:15 ` Jim Rees 1 sibling, 2 replies; 17+ messages in thread From: Trond Myklebust @ 2013-12-05 13:41 UTC (permalink / raw) To: Christoph Hellwig Cc: Lever Charles Edward, Jim Rees, Linux NFS Mailing List, An?bal Monsalve Salazar, Steinar H. Gunderson On Dec 5, 2013, at 8:23, Christoph Hellwig <hch@infradead.org> wrote: > [adding back Anibal, and adding Steinar as tirpc maintainer for Debian] > > On Wed, Dec 04, 2013 at 01:14:47PM -0500, Chuck Lever wrote: >> But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly >> the same API. And I'm able to build a working GSS-enabled version of >> rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and >> tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. >> >> libtirpc applications currently have to link explicitly with >> libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. > > >> MIT Kerberos provides libgssapi_krb5. >> >> libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. >> >> librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. > > So what's actually still using librpcsecgss and libgssglue? > > There is no rdepends for librpcsecgss on my Debian -stable system, > and I couldn't find any obvious user for unstable either. For > libgssglue1 -stable has a few consumers: > > nfs-common > libtirpc1 > librpcsecgss3 > libgssglue-dev > libgssapi-krb5-2 > > libgssapi-krb5-2 seems to have dropped the libgssglue dependency in > unstable, but the others still seem to be be around. I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? > How does the situation look for Fedora and SuSE? Fedora’s nfs-utils RPM lists a dependency on ‘libgssapi_krb5.so.2()(64bit)' and 'libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)', so it uses the gssapi from the MIT kerberos libraries. Not sure about SuSE, but I believe they use MIT kerberos too. Neil Brown would know. Cheers Trond ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-05 13:41 ` Trond Myklebust @ 2013-12-05 13:43 ` Christoph Hellwig 2013-12-05 13:45 ` Trond Myklebust 2013-12-10 6:27 ` NeilBrown 1 sibling, 1 reply; 17+ messages in thread From: Christoph Hellwig @ 2013-12-05 13:43 UTC (permalink / raw) To: Trond Myklebust Cc: Christoph Hellwig, Lever Charles Edward, Jim Rees, Linux NFS Mailing List, An?bal Monsalve Salazar, Steinar H. Gunderson On Thu, Dec 05, 2013 at 08:41:27AM -0500, Trond Myklebust wrote: > > libgssapi-krb5-2 seems to have dropped the libgssglue dependency in > > unstable, but the others still seem to be be around. > > I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? libgssapi-krb5-2 is described as "MIT Kerberos runtime libraries - krb5 GSS-API Mechanism" and depends on libkrb5-3 which is "MIT Kerberos runtime libraries". Nothing Heimdal related in this dependency chain. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-05 13:43 ` Christoph Hellwig @ 2013-12-05 13:45 ` Trond Myklebust 2013-12-05 16:37 ` Steve Dickson 0 siblings, 1 reply; 17+ messages in thread From: Trond Myklebust @ 2013-12-05 13:45 UTC (permalink / raw) To: Christoph Hellwig Cc: Lever Charles Edward, Jim Rees, Linux NFS Mailing List, An?bal Monsalve Salazar, Steinar H. Gunderson On Dec 5, 2013, at 8:43, Christoph Hellwig <hch@infradead.org> wrote: > On Thu, Dec 05, 2013 at 08:41:27AM -0500, Trond Myklebust wrote: >>> libgssapi-krb5-2 seems to have dropped the libgssglue dependency in >>> unstable, but the others still seem to be be around. >> >> I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? > > libgssapi-krb5-2 is described as "MIT Kerberos runtime libraries - krb5 > GSS-API Mechanism" and depends on libkrb5-3 which is "MIT Kerberos > runtime libraries". Nothing Heimdal related in this dependency chain. Then it should be able to drop the CITI librpcsecgss and libgssglue. Cheers Trond ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-05 13:45 ` Trond Myklebust @ 2013-12-05 16:37 ` Steve Dickson 0 siblings, 0 replies; 17+ messages in thread From: Steve Dickson @ 2013-12-05 16:37 UTC (permalink / raw) To: Trond Myklebust, Christoph Hellwig Cc: Lever Charles Edward, Jim Rees, Linux NFS Mailing List, An?bal Monsalve Salazar, Steinar H. Gunderson On 05/12/13 08:45, Trond Myklebust wrote: > > On Dec 5, 2013, at 8:43, Christoph Hellwig <hch@infradead.org> wrote: > >> On Thu, Dec 05, 2013 at 08:41:27AM -0500, Trond Myklebust wrote: >>>> libgssapi-krb5-2 seems to have dropped the libgssglue dependency in >>>> unstable, but the others still seem to be be around. >>> >>> I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? >> >> libgssapi-krb5-2 is described as "MIT Kerberos runtime libraries - krb5 >> GSS-API Mechanism" and depends on libkrb5-3 which is "MIT Kerberos >> runtime libraries". Nothing Heimdal related in this dependency chain. > > Then it should be able to drop the CITI librpcsecgss and libgssglue. I would think so.... librpcsecgss has already been remove from Fedora and I'll do the same for libgssglue once f18 is no longer supported... steved. > > Cheers > Trond-- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-05 13:41 ` Trond Myklebust 2013-12-05 13:43 ` Christoph Hellwig @ 2013-12-10 6:27 ` NeilBrown 1 sibling, 0 replies; 17+ messages in thread From: NeilBrown @ 2013-12-10 6:27 UTC (permalink / raw) To: Trond Myklebust Cc: Christoph Hellwig, Lever Charles Edward, Jim Rees, Linux NFS Mailing List, An?bal Monsalve Salazar, Steinar H. Gunderson [-- Attachment #1: Type: text/plain, Size: 2422 bytes --] On Thu, 5 Dec 2013 08:41:27 -0500 Trond Myklebust <trondmy@gmail.com> wrote: > > On Dec 5, 2013, at 8:23, Christoph Hellwig <hch@infradead.org> wrote: > > > [adding back Anibal, and adding Steinar as tirpc maintainer for Debian] > > > > On Wed, Dec 04, 2013 at 01:14:47PM -0500, Chuck Lever wrote: > >> But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly > >> the same API. And I'm able to build a working GSS-enabled version of > >> rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and > >> tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. > >> > >> libtirpc applications currently have to link explicitly with > >> libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. > > > > > >> MIT Kerberos provides libgssapi_krb5. > >> > >> libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. > >> > >> librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. > > > > So what's actually still using librpcsecgss and libgssglue? > > > > There is no rdepends for librpcsecgss on my Debian -stable system, > > and I couldn't find any obvious user for unstable either. For > > libgssglue1 -stable has a few consumers: > > > > nfs-common > > libtirpc1 > > librpcsecgss3 > > libgssglue-dev > > libgssapi-krb5-2 > > > > libgssapi-krb5-2 seems to have dropped the libgssglue dependency in > > unstable, but the others still seem to be be around. > > I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? > > > How does the situation look for Fedora and SuSE? > > Fedora’s nfs-utils RPM lists a dependency on ‘libgssapi_krb5.so.2()(64bit)' and 'libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)', so it uses the gssapi from the MIT kerberos libraries. > > Not sure about SuSE, but I believe they use MIT kerberos too. Neil Brown would know. openSUSE is actually a bit of a mess right now as we have libtirpc compiled with libgssglue support and that just doesn't work with a modern krb5. I'm glad to see that support is being removed!! (I'm working on getting this fixed, but there are "issues" ;-( ). But while we still seem to package librpcsecgss, nfs-utils doesn't bind against it. It uses libgssapi_krb5 just like Fedora. NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-05 13:23 ` Christoph Hellwig 2013-12-05 13:41 ` Trond Myklebust @ 2013-12-05 16:15 ` Jim Rees 1 sibling, 0 replies; 17+ messages in thread From: Jim Rees @ 2013-12-05 16:15 UTC (permalink / raw) To: Christoph Hellwig Cc: Chuck Lever, Trond Myklebust, Linux NFS Mailing List, An?bal Monsalve Salazar, Steinar H. Gunderson Arch lists the following: librpcsecgss URL : http://www.citi.umich.edu/projects/nfsv4/linux/ Depends On : glibc krb5 libgssglue Required By : nfs-utils libgssglue URL : http://www.citi.umich.edu/projects/nfsv4/linux/ Depends On : glibc Required By : librpcsecgss libtirpc nfs-utils ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-04 13:13 ` Christoph Hellwig 2013-12-04 17:14 ` Chuck Lever @ 2013-12-04 18:24 ` J. Bruce Fields 2013-12-04 18:27 ` Chuck Lever 1 sibling, 1 reply; 17+ messages in thread From: J. Bruce Fields @ 2013-12-04 18:24 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Jim Rees, linux-nfs On Wed, Dec 04, 2013 at 05:13:17AM -0800, Christoph Hellwig wrote: > Btw, looks like librpcsecgss is indeed pretty much unmaintained. The > last upstream release is a tarball drop from CITI in 2009 and there > doesn't appear to be a source repository of any kind. Well, there is this: git://git.linux-nfs.org/projects/kwc/librpcsecgss.git which was probably the source of the tarball? --b. > > I think the best idea would be to merge it into the libtirpc repo, > as both the heritage and usage of the codebases is the same. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: librpcsecgss: FTBFS on GNU/kFreeBSD 2013-12-04 18:24 ` J. Bruce Fields @ 2013-12-04 18:27 ` Chuck Lever 0 siblings, 0 replies; 17+ messages in thread From: Chuck Lever @ 2013-12-04 18:27 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Christoph Hellwig, Jim Rees, linux-nfs On Dec 4, 2013, at 1:24 PM, "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Wed, Dec 04, 2013 at 05:13:17AM -0800, Christoph Hellwig wrote: >> Btw, looks like librpcsecgss is indeed pretty much unmaintained. The >> last upstream release is a tarball drop from CITI in 2009 and there >> doesn't appear to be a source repository of any kind. > > Well, there is this: > > git://git.linux-nfs.org/projects/kwc/librpcsecgss.git > > which was probably the source of the tarball? nfs-utils-lib.spec (Fedora) has this: Source1: http://www.citi.umich.edu/projects/nfsv4/linux/librpcsecgss/%{librpcsecgss}-%{rpcsecgssvers}.tar.gz > --b. > >> >> I think the best idea would be to merge it into the libtirpc repo, >> as both the heritage and usage of the codebases is the same. >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-12-10 6:28 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20090703133142.14887.33854.reportbug@localhost.localdomain>
2013-11-24 5:19 ` librpcsecgss: FTBFS on GNU/kFreeBSD Aníbal Monsalve Salazar
2013-11-24 9:09 ` Christoph Hellwig
2013-11-24 13:07 ` Jim Rees
2013-11-24 13:29 ` Christoph Hellwig
2013-12-04 13:13 ` Christoph Hellwig
2013-12-04 17:14 ` Chuck Lever
2013-12-04 17:53 ` Trond Myklebust
2013-12-04 18:14 ` Chuck Lever
2013-12-05 13:23 ` Christoph Hellwig
2013-12-05 13:41 ` Trond Myklebust
2013-12-05 13:43 ` Christoph Hellwig
2013-12-05 13:45 ` Trond Myklebust
2013-12-05 16:37 ` Steve Dickson
2013-12-10 6:27 ` NeilBrown
2013-12-05 16:15 ` Jim Rees
2013-12-04 18:24 ` J. Bruce Fields
2013-12-04 18:27 ` Chuck Lever
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).