{5} Assigned, Active Tickets by Owner (Full Description) (26 matches)
List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.
Almad
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #263 | Use hg archive for Mercurial mode=copy | vc-support | undecided | enhancement | 05/04/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
On mode=copy, Buildbot is using cp -rp for copying source to build, copying whole history of repository. Using hg archive source build would copy only tip, speeding up whole process a lot for bigger repositories. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #276 | mode=copy should not copy unversioned files (and use VC-specific commands) | other | undecided | enhancement | 05/14/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
mode=copy should use VC-specific commands, archieving higher speed and consuming less HDD space. This, however, require change of behavior and not expect to copy unversioned files. See maillist discussion. This ticket should modify tests to add+commit files which are now only touched. Then, ticket for each VC backend should be specified. It's already implemented for hg in #263 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
bhearsum
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #175 | support for custom MailNotifier messages | statusplugins | undecided | enhancement | 01/28/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm thinking this can be implemented as an optional function to pass to MailNotifier?, that would be like buildMessage -- but only deal with formatting (no deferred objects). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #296 | should have a way of running builds after X seconds of idle | buildprocess | undecided | enhancement | 06/04/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Personally, I feel that the Periodic scheduler should behave this way by default. Either way, it's trivial to add this feature to it, or subclass it to an Idle scheduler. I've got code for this, what do people prefer? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #317 | more flexibility for BuildFactory's | buildprocess | undecided | enhancement | 07/17/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Something I'd like to be able to do is split out different sets of operations into different factories. For example, BuildProducingFactory?, BuildUploadingFactory?, TestFactory?, and various others. In many cases it is desirable to combine these operations into a single builder. I'd like to be able to do the following things with a BuildFactory?: * add a step anywhere in BuildFactory?.steps. * add a method that will combine two BuildFactory?'s into one |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #226 | 'buildbot restart' shouldn't fail when buildbot is not running | other | 0.7.9 | defect | 04/03/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm not sure how others feel about this but to me it makes sense for 'buildbot restart' to _always_ end with Buildbot starting (assuming valid configuration, etc.), even if Buildbot isn't running. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #100 | Builder should be able to take a 'env' argument that applies to all BuildSteps | other | 0.7.9 | enhancement | 09/18/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I think it's a fairly common use case that all of a Builder's BuildSteps? require the same environment variables. I propose that the Builder 'setup' should be able to take in a dict of environment variables and pass it along to all BuildSteps? that require/support it (ie. it wouldn't pass it to something like FileDownload?). I'd be happy to code this up myself assuming it is wanted. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
nhemingway
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #99 | Change BuildMaster UI so it can "cancel queued jobs" | buildprocess | 0.7.9 | enhancement | 09/14/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We accidently clicked twice on the buildbot, which means we have two jobs queued up to be handed out to slaves. One is being processed by a slave, and we could stop that job-in-progress by the UI. However, there is no way to stop the 2nd queued job. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
warner
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #68 | is buildbot slave timeout too short? | configuration | 0.7.9 | defect | 07/30/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The buildbot slave default timeout can be too short for us. Sometimes, 5sec isnt always enough, and we get following: % cltbld$ buildbot start /Users/cltbld/macosx-slave1
% ... even though slave started "normally", responds fine to pings from buildbot master, and does handle jobs just fine. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #146 | addLogObserver examples in the manual must be updated | documentation | 0.7.9 | defect | 11/24/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
addLogObserver method now takes three parameters (log name is a new one). Also, for observer to post metrics they must be mentioned in build step's progressMetrics field. buildbot.texinfo is the source of the manual if I'm not mistaken, so I'll try to submit a patch. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #158 | responsibility for usepty option is in the wrong place | other | 0.7.9 | defect | 12/18/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
usepty is an argument to buildbot create-slave. The correct place to configure this is on a per-step basis though (perhaps at the ShellCommand level, but maybe there's a better "thing which runs a child process" central location). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #198 | disposition of std pipes should be notes on the header and keepStdinOpen should default to True | buildprocess | 0.7.9 | defect | 03/08/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This is two issues, but they both arose from the same use and are related: The darcs developers are getting their first buildbot going -- http://darcs.net:8008 -- and they have a problem with some 'make test' (running unit tests written in Perl) halting and eventually timing out when invoked from a buildslave, but not when invoked from the command-line. If the disposition of the std pipes was noted in the header, it would have help us notice the existence of the keepStdinOpen option earlier, and if the default value were True, then there would be one less difference for us to wonder about between the buildslave invocation of make test and the local user interactive invocation of make test. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #210 | FileUpload/FileDownload blow up if 'workdir' is a WithProperties object | other | 0.7.9 | defect | 03/25/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Certain BuildSteps (well, ShellCommand at least, thanks to ticket #43) allow you pass a WithProperties object as workdir. FileUpload and FileDownload do not. Here's my example: workdir = shell.WithProperties("build.%s", "buildnumber")
...
f2 = factory.BuildFactory()
f2.addStep(transfer.FileUpload(
slavesrc="file",
masterdest="uploaded-file",
workdir=workdir,
))
When I run the build in question, the upload step dies with this exception: Traceback from remote host -- Traceback (most recent call last):
File "/usr/local/Intelerad/3rd_Party/python-2.5/lib/python2.5/site-packages/twisted/spread/pb.py", line 847, in _recvMessage
netResult = object.remoteMessageReceived(self, message, netArgs, netKw)
File "/usr/local/Intelerad/3rd_Party/python-2.5/lib/python2.5/site-packages/twisted/spread/flavors.py", line 119, in remoteMessageReceived
state = method(*args, **kw)
File "/home/gward/lib/python/buildbot/slave/bot.py", line 171, in remote_startCommand
d = self.command.doStart()
File "/home/gward/src/buildbot/buildbot/slave/commands.py", line 629, in doStart
d = defer.maybeDeferred(self.start)
--- <exception caught here> ---
File "/usr/local/Intelerad/3rd_Party/python-2.5/lib/python2.5/site-packages/twisted/internet/defer.py", line 107, in maybeDeferred
result = f(*args, **kw)
File "/home/gward/src/buildbot/buildbot/slave/commands.py", line 716, in start
os.path.expanduser(self.filename))
File "/var/tmp/python2.5-intelerad-2.5.1-root/usr/local/Intelerad/3rd_Party/python-2.5/lib/python2.5/posixpath.py", line 60, in join
if b.startswith('/'):
exceptions.AttributeError: Unpersistable instance has no attribute 'startswith'
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #211 | slave notify_on_missing is sending too many messages | other | 0.7.9 | defect | 03/25/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The notify_on_missing= functionality, which is supposed to send email if a buildslave has been offline for too long, doesn't seem to be picking up on reconnects. The slave disconnects at time 0, reconnects at time 5, but the master sends out mail anyways at time 10. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #215 | log the usage of shutil.copytree() instead of a cp subprocess | other | 0.7.9 | defect | 03/26/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
def doCopy(self, res):
# now copy tree to workdir
fromdir = os.path.join(self.builder.basedir, self.srcdir)
todir = os.path.join(self.builder.basedir, self.workdir)
if runtime.platformType != "posix":
self.sendStatus({'header': "Since we're on a non-POSIX platform, we're not going to try to execute cp in a subprocess, but instead
use shutil.copytree(), which will block until it is complete. fromdir: %s, todir: %s\n" % (fromdir, todir)})
shutil.copytree(fromdir, todir)
return defer.succeed(0)
command = ['cp', '-r', '-p', fromdir, todir]
c = ShellCommand(self.builder, command, self.builder.basedir,
sendRC=False, timeout=self.timeout)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #249 | git_buildbot.py does not send merge changesets | vc-support | 0.7.9 | defect | 04/21/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Because merge changesets don't directly affect files, they aren't sent from git_buildbot.py. Attached is a patch that sends a synthetic merge file to make buildbot happy. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10 | Builders should be defined as instances, not as a dictionary | configuration | 0.7.9 | enhancement | 01/29/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The c['builders'] specification is the last one in master.cfg that is defined with a dictionary. I think it would be much clearer if it were defined as an instance. So instead of: b1 = {"name": "svn-hello",
"slavename": "bot1",
"builddir": "svn-hello",
"factory": factory.BuildFactory(steps),
}
c['builders'].append(b1)
you would do: b1 = Builder("svn-hello", "bot1", factory.BuildFactory(steps))
Builders.append(b1)
(assuming that #9 was implemented) Also, the "builddir" argument should go away, and just use the builder name. Having to specify a separate directory is annoying. It might be nice to add a separate "verbose builder name" argument, though, since the normal builder name gets used as a directory name and thus can't have slashes (and really doesn't want to have spaces). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #243 | log the version of the buildbot source code in the slave and master startup | other | 0.7.9 | enhancement | 04/17/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #131 | Exception in a TreeSize command | other | 0.7.9 | defect | 10/30/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The du command completes successfully, but the build step fails with this exception: Traceback (most recent call last):
File "C:\Python\lib\site-packages\twisted\internet\defer.py", line 182, in addCallbacks
self._runCallbacks()
File "C:\Python\lib\site-packages\twisted\internet\defer.py", line 317, in _runCallbacks
self.result = callback(self.result, *args, **kw)
File "C:\Python\lib\site-packages\twisted\internet\defer.py", line 239, in callback
self._startRunCallbacks(result)
File "C:\Python\lib\site-packages\twisted\internet\defer.py", line 304, in _startRunCallbacks
self._runCallbacks()
--- <exception caught here> ---
File "C:\Python\lib\site-packages\twisted\internet\defer.py", line 317, in _runCallbacks
self.result = callback(self.result, *args, **kw)
File "C:\Python\Lib\site-packages\buildbot\process\buildstep.py", line 955, in <lambda>
d.addCallback(lambda res: self.commandComplete(cmd))
File "C:\Python\Lib\site-packages\buildbot\steps\shell.py", line 238, in commandComplete
out = cmd.log.getText()
exceptions.AttributeError: RemoteShellCommand instance has no attribute 'log'
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #101 | Set "revision" property when using computeSourceRevision | other | 0.7.9 | enhancement | 09/19/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It would be useful to be able to retrieve the revision returned by computeSourceRevision in a source checkout step without a specified revision. The following tiny patch simply sets the "revision" property appropriately. The motivation here is that I am using Perforce, which does not properly support the "got_revision" property. It would obviously be preferable to fix the Perforce support to support got_revision, but I have been unable to determine a proper way to do that. I believe that this alternate solution is generally useful, though. --- /root/backup/source.py 2007-09-19 10:29:12.000000000 -0600 +++ source.py 2007-09-19 10:43:41.000000000 -0600 @@ -165,6 +165,7 @@
+ self.setProperty("revision", revision)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #178 | extraRecipients in MailNotifiers should be CC'ed, not in the TO: list | statusplugins | 0.7.9 | enhancement | 01/31/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
As the buildbot sheriff, I am in the extraRecipients list for all of my MailNotifiers?. Because of this, I usually can't tell if I'm being sent the "build failed" email b/c *I* broke the build or just because I'm on the extra recipients list. Thus, I have to manually check which is usually a waste of time. It'd be great if the extra recipients list was CC'ed instead of being on the TO: list. The notifier does appear to merge my name if I was at fault (i.e. it's only in the TO: list once) so this does require some extra smarts if I was actually to blame. I took a look at the code in the MailNotifier? class but I don't understand Deferreds so I wasn't quite sure how to do the change. I could also see a case where not everybody would want to use the CC: list so some extra option might be needed. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #251 | Colour is a presentational attribute, but it's set in many different places | other | 0.7.9 | enhancement | 04/22/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The colour used to present steps is set in many different places, most of which have no other presentational function. Standard practice is to separate presentation from function. The waterfall seems to not depend on the colour set for a step (relying only on CSS) The statuslog is text only so colour is irrelevant (?) The statusgui does seem to depend on the step's colour, but that could be set more simply based on the step's result The debugclient seems to have no function that would involve colour. If I have any of this wrong (wildly wrong?), pls let me know. I have created the attached (diff -u) patch, which seems to work for both of the above clients that use colour and passes all of the tests. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
zooko
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #207 | "offline" should not be red | other | undecided | defect | 03/20/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Red should be reserved for bugs in the source code under test. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #236 | show elapsed time for steps | other | undecided | enhancement | 04/15/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I would like it if there were a convenient way to include elapsed time in the log of steps. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #240 | use setuptools (optionally) to make console_scripts | other | undecided | enhancement | 04/17/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Thu Apr 17 14:02:59 MDT 2008 zooko@zooko.com
* setup: use the console_scripts feature of setuptools for buildbot, darcs_buildbot, and buildbot_service
Also use the find_packages() feature of setuptools instead of an explicit list of packages in setup.py. Also make contrib and contrib/windows be packages (by adding __init__.py files to them) so that they can be imported at run-time by the console scripts.
diff -rN -u old-trunk/contrib/darcs_buildbot.py new-trunk/contrib/darcs_buildbot.py
--- old-trunk/contrib/darcs_buildbot.py 2008-04-17 14:04:21.000000000 -0600
+++ new-trunk/contrib/darcs_buildbot.py 2008-04-17 14:04:21.000000000 -0600
@@ -159,6 +159,9 @@
f.write(lastchange)
f.close()
-if __name__ == '__main__':
+def main():
MASTER = sys.argv[1]
sendChanges(MASTER)
+
+if __name__ == '__main__':
+ main()
diff -rN -u old-trunk/setup.py new-trunk/setup.py
--- old-trunk/setup.py 2008-04-17 14:04:21.000000000 -0600
+++ new-trunk/setup.py 2008-04-17 14:04:21.000000000 -0600
@@ -1,7 +1,6 @@
#! /usr/bin/env python
import sys, os, re
-from distutils.core import setup
from buildbot import version
# Path: twisted!cvstoys!buildbot
@@ -32,11 +31,6 @@
improve.
"""
-scripts = ["bin/buildbot"]
-if sys.platform == "win32":
- scripts.append("contrib/windows/buildbot.bat")
- scripts.append("contrib/windows/buildbot_service.py")
-
testmsgs = []
for f in os.listdir("buildbot/test/mail"):
if f.endswith("~"):
@@ -64,16 +58,6 @@
'Topic :: Software Development :: Testing',
],
- 'packages': ["buildbot",
- "buildbot.status", "buildbot.status.web",
- "buildbot.changes",
- "buildbot.steps",
- "buildbot.process",
- "buildbot.clients",
- "buildbot.slave",
- "buildbot.scripts",
- "buildbot.test",
- ],
'data_files': [("buildbot", ["buildbot/buildbot.png"]),
("buildbot/clients", ["buildbot/clients/debug.glade"]),
("buildbot/status/web",
@@ -85,7 +69,6 @@
("buildbot/test/mail", testmsgs),
("buildbot/test/subdir", ["buildbot/test/subdir/emit.py"]),
],
- 'scripts ': scripts,
'cmdclass': {'install_data': install_data_twisted},
}
@@ -94,9 +77,32 @@
# to the setup args.
import setuptools
except ImportError:
- pass
+ from distutils.core import setup
+ setup_args['scripts'] = ["bin/buildbot"]
+ if sys.platform == "win32":
+ setup_args['scripts'].append("contrib/windows/buildbot.bat")
+ setup_args['scripts'].append("contrib/windows/buildbot_service.py")
+ setup_args['packages'] = ["buildbot",
+ "buildbot.status", "buildbot.status.web",
+ "buildbot.changes",
+ "buildbot.steps",
+ "buildbot.process",
+ "buildbot.clients",
+ "buildbot.slave",
+ "buildbot.scripts",
+ "buildbot.test",
+ ],
else:
+ from setuptools import find_packages, setup
setup_args['install_requires'] = ['twisted >= 2.4.0']
+ setup_args['entry_points'] = {
+ 'console_scripts': [
+ 'buildbot = buildbot.scripts.runner:run',
+ 'buildbot_service = contrib.windows.buildbot_service:HandleCommandLine',
+ 'darcs_buildbot = contrib.darcs_buildbot:main'
+ ]
+ }
+ setup_args['packages'] = find_packages()
setup(**setup_args)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #257 | easy_install buildbot fails on win32 | other | undecided | defect | 04/28/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
When trying to use easy_install to get a win32 buildbot, easy_install reports that it failed to make eggs. C:\Perforce\Branches\epurins\main\Code\source\Integration\Python>c:\Python25\Scripts\easy_install.exe buildbot-0.7.7 Processing buildbot-0.7.7 Running setup.py -q bdist_egg --dist-dir C:\Perforce\Branches\epurins\main\Code\source\Integration\Python\buildbot-0.7.7\egg-dist-tmp-_eobh0 zip_safe flag not set; analyzing archive contents... buildbot.clients.debug: module references __file__ buildbot.scripts.runner: module references __file__ buildbot.status.web.baseweb: module references __file__ buildbot.test.runutils: module references __file__ buildbot.test.test_maildir: module references __file__ buildbot.test.test_mailparse: module references __file__ buildbot.test.test_shell: module references __file__ buildbot.test.test_slavecommand: module references __file__ No eggs found in C:\Perforce\Branches\epurins\main\Code\source\Integration\Python\buildbot-0.7.7\egg-dist-tmp-_eobh0 (setup script problem?) This is using activestate python ActivePython 2.5.1.1 (ActiveState Software Inc.) based on Python 2.5.1 (r251:54863, May 1 2007, 17:47:05) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> setup.py install works ok. Currently, the frontpage makes it seem like easy_install works out of the box, which is not accurate. It would be cool if this were directly added to a win32 wiki section with a workaround, or to get eggs building ok on win32. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[Buildbot Logo]](/trac/chrome/site/header-text-transparent.png)