[Buildbot-devel] debug client and cvs tags

Brian Warner warner-buildbot at lothar.com
Thu Aug 4 00:42:30 UTC 2005


> When I try to run the debugclient, I get the following exception.
> 
>     self.context = gobject.main_context_default()
> AttributeError: 'module' object has no attribute 'main_context_default'

This sounds like a PyGTK version issue.. this is probably an attribute that
got added in a later version that whatever you're using. I'm not sure when it
was added, but it works for me (on a debian/sid system) that using the 2.6.2
version of python-gtk. Take a look at the PyGtk site (http://www.pygtk.org/)
and their ChangeLog and see if you can figure out what version you need to
upgrade to.
 
> any ideas to solve this? I am hoping that debug client will allow me
> to simulate a cvs commit to test my buildbot confgiuration.

Also note that with recent versions of buildbot, you can use the 'buildbot
sendchange' command to accomplish the same thing without a GUI library.

> When I specify a release tag, the cvs command seems to include the -D
> as well. This seems to result in not getting any files. i.e
> 
> cvs -d :pserver:chandaka at cvs:/u/cvs -z3 checkout -d test -r MY_TAG -D
> Wed, 27 Jul 2005 09:11:47 -0000 test/src
> 
> Is this the intended behavior? 

It *ought* to be possible to use both -r and -D together: the -r MY_TAG
specifies the branch, and the -D specifies the position along this branch. I
haven't done extensive tests with this, though. I *have* seen problems under
windows with something like this, and I think I put a comment in the source
code about it, but it needs more investigation.

Buildbot puts the -D option in there to avoid last-minute-update version
skew: the timestamp prevents the inclusion of a file committed after the
buildbot has decided to start a build but before the 'cvs co' command has
completed. On VC systems that provide repository-wide transaction numbers
(pretty much everything except CVS), we use those transaction numbers instead
of a timestamp.

I'm not sure why this could cause a problem, unless the timestamp in question
was before that branch was created. It could be that CVS just doesn't know
how to handle it, in which case I'm going to have to seriously rethink the
build-on-branch functionality for CVS trees, because I don't know of any
other way to cleanly specify which set of source files to use for a build of
old branch code.

So yes, it is intended, but it may also be the case that it doesn't work, in
which case I'll revise my intentions :).

hope that helps,
 -Brian





More information about the devel mailing list