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=69540 > > 4) > > 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. Folks, this is not okay. This is not the right way to do things. If you aren't reasonably sure that all the library's consumers can be made to work with the new version of the library, *don't put the new version in Rawhide*. Rawhide isn't a dumping ground for random new code and has not been for some time. It is not okay to just break the entire thing and say 'we'll fix it once we've finished the upstream work'. The upstream work needs to happen *before* you break Rawhide. We're doing all this work across several teams to compose and test Rawhide regularly, and it's kind of pointless if people are just going to break the whole thing gratuitously. Please do not do this. Policy: https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master Note that that clearly says "A week in advance, notify maintainers who depend on their package to rebuild when there are abi/api changes that require rebuilds in other packages or offer to do these rebuilds for them." *A WEEK IN ADVANCE*. This bump was submitted to Koji on the *same day* it was notified, 2015-10-30. That is a clear violation of the policy. I would argue the policy also assumes fairly strongly that rebuilds of dependent packages will in fact be possible, but I'd suggest we amend the policy to explicitly state that soname bumps and other incompatible changes should not be done *at all* unless there is a clear plan to make all dependent packages compatible immediately. Also relevant in that text: "Feel free to push out the newest version of packages as long as they do not cause breakage." and " Try not to push a clearly broken build (breaks the default buildroot package set, etc)". -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
