On Mon, 2015-11-02 at 11:15 -0800, 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_m > aster > > 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. This policy is clearly sensible and necessary, no question about that. But this appears to be an opportunity for improvement as well. Fortunately the breakage looks like it should be straight forward to resolve but that obviously might not always be the case. For my part I wonder if getting advanced notice would have helped because I'm not sure what the process is to properly work through a staging environment and build test process. Going about it the long way could mean a week might not be long enough. There must be a process that doesn't involve having to go through quite a bit of work on my local machine when that sort of infrastructure should be available via the repository and build system or a documented process of steps for building locally. I don't even know what "Use a separate buildsystem tag" means but I guess I need to hunt through the web site documentation for that too. Is there something I can look at to help with this, perhaps even just a description of the mock process to do this locally. Sadly mock isn't something I'm familiar with largely because I haven't needed to be to date. But I also suspect I'm not alone. So can anyone point me to related documentation for this process please and perhaps could we update the policy a little to direct people to those documents. > > 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
