Nightly builds of software you package

[Dmitrijs Ledkovs]

2009/5/6 James Westby <jw+debian at jameswestby.net>:
> On Tue, 2009-05-05 at 22:59 +0100, Dmitrijs Ledkovs wrote:
>> 2009/5/5 James Westby <jw+debian at jameswestby.net>
>>
>
> Great questions, thanks.
>
>> 1) Why are you using dpkg-* commands in stead of bzr builddeb? IMHO
>> bzr builddeb is the best builder of source, binary, other. (I my setup
>> bzr bd is debuild, bzr bd --quick is pdebuild becuase it takes longer
>> to type ;-) )
>
> I hope to, but they are currently incompatible. I hope I will be
> able to fix that this cycle, if the needed changes land in bzr and I
> can implement the bzr-builddeb changes needed.
>
>> 2) Why are you adding changlelog like that? Or is it not adding a new
>> entry? If it does why not use dch with funky flags to force a
>> distribution and a message you want? By doing this you will get all
>> the environmental variables and .devscripts options.
>
> There was a reason, honest :-) I can't quite remember now, but
> calling dch was problematic.
>
> I am going to add support for the environment variables, but did
> that as a quick hack in the meantime.
>
>> 3) Recepies look like a briliant idea!!! I love it.
>
> They were the idea of a certain Mark, perhaps you know him? :-)
>

How about turning recipes into a generic "bzr script" where anything
can be done without prefixing "bzr" and using variables substitutions
for date / version number / etc.

Eg. you start with base branch then can call merge-upstream / merge /
pull (for example with preset options in merge-upstream to pull tip).
Then if you want to call diff to see what has changed (eg so that it
appears in the build log). And finally push branch.

Not sure when push will be needed. But just in case.



bzr build foo.recipe working-dir -- <any other options for bzr-builddeb?>

>
>> 4) We need hooks I think (unless bzrlib provides that somehow) eg so
>> that you can invoke whatever you want in the pre-stage, between
>> merges, before build, after build.
>
> Yeah, the spec for this discussed this need. However, doing this makes
> the result non-deterministic, and gives you arbitrary code execution
> when building a recipe. Therefore it's not implemented in the first cut.
>
> If you have things that need to have this facility then we can add it,
> but we need to have good evidence, and come up with an elegant solution.
>

Examples for hooks: Imagine upstream is using hg for revision. hence I
would want to update hg folder and then use merge-upstream to merge
the folder. Another example I need to do equivalent of "make dist"
before building source/binary. Post - hooks to upload to PPA / local
repository; run lintian, piuparts, sending email notification with
log, broadcasting dbus message for the new notification system, CIA
bot ......

*me stopped dreaming now cause the long time dream of
bzr-ipython-shell is coming back to me, the one that keeps bzr
imported completely in memory such that all commands get executed
superfast without any load-time/lazy load-time think emacsclient*

Maybe this is feature creep already, and maybe I'll have to go back to
bash. But imho calling bzr * is expensive from bash, over running one
instance from plugin.

Can't think of elegant solution though.....

>> Overall looks very nice. I'll try to hack a bit on it when I will have
>> sometime (probably only at the weekend). Any pointer how to access
>> commands from other plugins in bzrlib? never used bzrlib before cause
>> I really think this tool should be using bzr-builddeb.
>
> You shouldn't try and use the Command objects themselves, as they are
> supposed to interact with the UI directly, but you can access the
> functionality by importing from the plugins, e.g.
>
>  from bzrlib.plugins import builddeb
>
> as long as you have loaded plugins first
>
>  from bzrlib.plugin import load_plugins
>  load_plugins()
>
> IIRC.
>
> However, as I said using bzr-builddeb isn't really possible right now,
> but there may be other cool things you can do.

Thanks a lot for the help. Booking my weekend for bzrlib and python-apt fun! =D

>
> Thanks,
>
> James
>
>

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич