On Fri, 9 Jan 2015, Ken Dreyer wrote: > On 01/09/2015 03:33 AM, Loic Dachary wrote: > > On 09/01/2015 07:55, David Zafman wrote: > >> > >> We are seeing gitbuilder failures. This is what I saw on one. > >> > >> error: Failed build dependencies: > >> xmlstarlet is needed by ceph-1:0.90-821.g680fe3c.el7.x86_64 > > > > This is because https://github.com/ceph/ceph/pull/3036 was recently merged. > > However, https://github.com/ceph/autobuild-ceph/pull/19 added xmlstarlet > > about a month ago. Maybe some gitbuilder machines were not updated > > accordingly. If I'm not mistaken this is a manual process but I'm not sure > > exactly how to do it myself. > > I'm not entirely sure of the SOP to apply fabfile changes across our > infrastructure, either. Is there a simple "push this fabfile change > everywhere" command for gitbuilder? Not really, but it is high time we established one. At the top of the fabfile all of the targets are defined, so that if you run bin/fab w/o arguments it should run on *all* of them. Unfortunately IIRC it's a bit disruptive as it restarts the autobuild service which will interrupt and restart the current build. But, that list isn't well-maintained, so it doesn't map to the current set of gitbuilders. That's probably pretty easy to fix. Even if we do, though, I think fab isn't super great about skipping targets that are down? Not sure. In any case, the way I've run it in practice is on specific targets taht need updating, like so bin/fab gitbuilder_auto:host=user@foo (or something like that, I forget the exact syntax). Often on a host that isn't in the master list. More frequently the procedure has been: - add a dependency to the fabfile for future builders - manually install the package on the existing ones to avoid the above pain which mostly works but doesn't regularly verify that the fabfile is sufficient and correct. > In the long term we'll want to get to a point where we're building > Ceph's RPM packages using mock [1] instead of rpmbuild so that mock can > resolve these sort of things automatically without having to deal with > installing new BuildRequires by hand. That sounds great, although I wonder if it is slow? We used to do all of our debian builds with pbuilder which does a similar thing, but it is way slow because it reinstalls deps on every run. We moved to doing native dpkg builds because time is of the essence for test builds and use pbuilder only for releases... sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
