ltib
[Top][All Lists]
Advanced

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

Re: [Ltib] Buildbot and LTIB


From: Stuart Hughes
Subject: Re: [Ltib] Buildbot and LTIB
Date: Sat, 20 Nov 2010 18:25:04 +0000
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

Hi Peter,

Peter Barada wrote:
> Stuart,
> I'm using buildbot to help with continuous integration testing, and I'm
> running into a problem.
> 
> On the buildslave, I have it do an SVN update of the source, then
> execute "./ltib -b --preconfig config/platform/__platform__/defconfig"
> which works pretty well.
> 
> I've got a few problems I'd like to solve w/o using a hammer:
> 
> 1) If someone updates a patch (but not its corresponding .spec file) it
> look slike a package isn't rebuilt.
> 

That's by design.  The idea is that patch names are unique and once
taken they can never be reused.  This ensures that anything on the GPP
is guaranteed to be immutable.

During development you could argue that you don't need to do this and
it's okay to change patches.  However this can easily go wrong for you
if you lose track of which file named xxxx is the latest etc.

On a practical level, if your workflow needs this, the best suggestion I
have is to ensure that any time you update a patch, you also touch the
referencing .spec file, this will make sure you always get a rebuild.


> 2) I have packages that are left prepped (think kernel + hello_mod), and
> if the .spec/.patch file(s) for a package (kernel in this case) are
> updated, is there any way to force LTIB to remove the package source,
> and then run the %prep/%build steps?

These should not be left prepped unless there has been a package build
failure, or (for the kernel) the leave unpacked option is set.

Again this is by design.  The idea is that once source is unpacked, you
have to assume that someone's valuable changes are in there and so the
only way it gets removed is by a manual "rm -rf".  This is even true for
a ./ltib -m distclean.


> 
> 3) How can I have LTIB forcibly remove rootfs and reinstall all the
> packages(I currently do "sudo rm -rf rootfs; ./ltib -e" on my
> development machine, but the "sudo rm" is what is causing problems as
> the buildslave only allows /opt/ltib/usr/bin/rpm and /usr/bin/rpm to run).

Running:  ./ltib -m clean ; ./ltib

should do this.  The only thing a clean may leave is any artefacts
generated by actually running on the rootfs in NFS mode.


> 
> If I could fix the above, then automating the build process becomes much
> simpler.  I'm using LTIB 9.1.1 (yes its a year old), so if any of this
> is available in a newer version of LTIB, point me to it so I can
> back-port the functionality.

I can't recall (and don't think) any of these behaviours have been changed.

BTW: are you using or have you checked out
bin/autobuild_ltib,mk_buildresults  which is what the autobuilder
posting to this list uses?


> 
> Thanks in advance!
> 

No problem.

Regards, Stuart







reply via email to

[Prev in Thread] Current Thread [Next in Thread]