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

Re: [Xen-devel] [PATCH v4] OSSTEST: introduce a raisin build test

On Mon, 2015-05-18 at 11:08 +0100, George Dunlap wrote:
> On Wed, May 13, 2015 at 12:48 PM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Wed, 13 May 2015, Ian Campbell wrote:
> >> On Tue, 2015-05-12 at 12:46 +0100, Stefano Stabellini wrote:
> >> > > Would a separate clone of the same raisin version with some sort of
> >> > > "dist" directory transported over be sufficient and supportable? Or are
> >> > > raisin's outputs not in one place and easily transportable?
> >> > >
> >> > > i.e. today build-$ARCH-libvirt picks up the dist.tar.gz files from the
> >> > > corresponding build-$ARCH, unpacks them and asks libvirt to build
> >> > > against that tree.
> >> >
> >> > Moving the dist directory over should work, although I have never tested
> >> > this configuration.
> >>
> >> Would you be willing to support this as a requirement going forward?
> >
> > Yeah, I think it is OK
> >
> >> I assume that it is not also necessary to reclone all the trees for the
> >> preexisting components, just the new ones?
> >
> > Only if the user asks for a components to be built, the corresponding
> > tree is cloned.
> Won't the problem here be disentangling the stuff installed in dist/
> (or whatever it's called) from the things we want to rebuild vs the
> things we want to change?

>From the osstest PoV at least the proposal here only involves building
additional things, not rebuilding anything which came from a previous

e.g. given a build of xen.git now do a build of libvirt.git using those
previously built Xen libs.

But there is still the issue of separating stuff built in Pass-A from
the stuff in Pass-B.

Raisin could presumably have a concept of two dist dirs, dist.base and
dist with the former being r/o. But that sounds to me like the sort of
thing you wouldn't want in Raisin.

Per component dist dirs is similarly surely possible but perhaps not
something raisin wants.

> I.e., ideally if you want to build just xen.git, you want dist/ to
> contain the output of the previous build of seabios, qemut, qemuu, &c,
> but *not* the output of previous xen.git builds (or, ideally, the
> output of previous libvirt, pvgrub, or stubdom builds).  Just tar and
> untarr'ing dist/ after a full build won't accomplish that.
> Would it make sense to do some sort of "save snapshot" functionality
> that would tar up the dist/ before building a particular component,
> such that it could be used later?  Sort of a "stage 2*" for raisin.
> :-)
>  -George
> * Referring to Gentoo.  Not sure the comparison is 100% accurate.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.