Hello, On 11/02/2015 02:15 PM, Adam Williamson wrote: > 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 Boy... I sure wish this policy was pointed out earlier... I had no idea that existed.. I realize ignorances is not an excuse so for that I do apologize.. > 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. To be clear.. I should have waited a week after I sent this mail to bump the version, correct? If so what could the maintainers do during that week to make things smother? steved. 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)". > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
