Re: [HEADS UP] Upcoming soname change for libtirpc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2015-11-02 at 11:02 +0800, Ian Kent wrote:
> On Sun, 2015-11-01 at 18:48 +0100, Kalev Lember wrote:
> > On 10/30/2015 05:36 PM, Kevin Fenzi wrote:
> > > On Fri, 30 Oct 2015 11:50:48 -0400
> > > Steve Dickson <SteveD@xxxxxxxxxx> wrote:
> > > > 2) find and rebuild all the dependencies?
> > > 
> > > Should be something like: 
> > > 
> > > % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
> > > Last metadata expiration check performed 0:01:17 ago on Fri Oct
> > > 30
> > > 10:34:06 2015.
> > > autofs-1:5.1.1-3.fc23.x86_64
> > > fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
> > > fedfs-utils-server-0:0.10.3-4.fc23.x86_64
> > > libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
> > > nfs-utils-1:1.3.2-10.fc23.x86_64
> > > rpcbind-0:0.2.3-0.2.fc23.x86_64
> > 
> > Now that the libtirpc update is in, I tried to kick off rebuilds
> > for
> > these to make them them installable again in rawhide (they are
> > breaking
> > nightly image composes). Didn't get very far with this though
> > because
> > rpcbind and fedfs-utils are failing to build and are blocking
> > others:
> > 
> > rpcbind (
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=695404)
> > failed with:
> > 
> > src/rpcb_svc_com.c: In function 'handle_reply':
> > src/rpcb_svc_com.c:1277:6: error: 'SVCXPRT {aka struct
> > __rpc_svcxprt}' has no member named 'xp_auth'
> >   xprt->xp_auth = &svc_auth_none;
> > 
> > and fedfs-utils (
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=695402) failed
> > the same way:
> > 
> > gss.c: In function 'fedfsd_get_gss_cred':
> > gss.c:178:23: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no
> > member named 'xp_auth'
> >   auth = rqstp->rq_xprt->xp_auth;
> 
> Steve is aware of this, or will be soon, as it was raised on the
> upstream libtirpc mailing list.
> 
> So we need to wait until rpcbind is updated before we can go further
> with this.
> 
> I had a look at the libtirpc code and the autofs library pre-open
> might
> still be needed. I didn't yet look far enough to see if there's a
> library unload destructor, which may be all that's needed, to resolve
> this. So I need to get around looking further before posting to the
> upstream list.
> 
> In the mean time I have committed a change to autofs to also pre-open
> the new library.

btw, Chuck Lever (fedfs-utils) was also part of that discussion but he
may not have yet realized fedfs-utils is affected too.

Once the change to be made is decided we should be able to fix these
pretty quickly.

I can commit changes to fedfs-utils if Chuck doesn't have time.

> 
> > 
> > -- 
> > Kalev
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux