{ "info": { "author": "Anybox SAS", "author_email": "gracinet@anybox.fr", "bugtrack_url": null, "classifiers": [ "Intended Audience :: Developers", "Intended Audience :: System Administrators", "License :: OSI Approved :: GNU Affero General Public License v3 or later (AGPLv3+)", "Topic :: Software Development :: Build Tools", "Topic :: Software Development :: Libraries :: Python Modules", "Topic :: Software Development :: Quality Assurance", "Topic :: Software Development :: Testing" ], "description": "anybox.buildbot.openerp\n=======================\n\n.. contents::\n\nIntroduction\n~~~~~~~~~~~~\n\n``anybox.buildbot.openerp`` aims to be a turnkey buildbot master setup\nfor a bunch of buildout-based OpenERP installations (see\n``anybox.recipe.openerp``).\n\nIt is able to run buildouts against the several postgreSQL versions\nthat can be found in attached slaves.\n\nHaving a new OpenERP generic or custom installation buildbotted\nagainst all the slaves attached to the\nmaster is just a matter of copying the corresponding buildout in the\n``buildouts`` subdirectory of the master and referencing it in\n``buildouts/MANIFEST.cfg``.\n\nAn interesting practice for buildbotting of in-house custom projects\nis to put this subdirectory itself under version control with your\npreferred VCS, and let the developpers push on it.\n\nIt is designed not to be too intrusive to buildbot itself, so that\nbuildbot users can tweak their configuration in the normal buildbot\nway, and even add more builds, possibly not even related to\nOpenERP.\n\nThe real-time scheduling works by polling the remote VCS systems\n(currently for Bazaar and Mercurial only). There is a basic URL\nrewritting capability to ease make this polling efficient.\n\n\nMaster setup\n~~~~~~~~~~~~\n\nThese steps are for a first setup.\n\n1. Install this package in a virtualenv. This will install buildbot as\n well.\n2. Create a master in the standard way (see ``buildbot create-master --help``).\n3. If you are creating a new buildbot master, the file ``master.cfg.sample`` \n included within this package should work out of the box. Just rename it\n ``master.cfg`` and put it in the master directory.\n\n If you are extending an existing buildbot master, add these lines in \n ``master.cfg`` right after the definition of ``BuildMasterConfig``::\n\n from anybox.buildbot.openerp import configure_from_buildouts\n configure_from_buildouts(basedir, BuildmasterConfig)\n\n4. Copy the ``buildouts`` directory included in the source\n distribution in the master or make your own (check\n ``buildouts/MANIFEST.cfg`` for an example on how to do\n that). In previous step, one can actually provide explicit\n locations for buildouts directories.\n5. Put a ``slaves.cfg`` file in the master directory. See the included\n ``slaves.cfg.sample`` for instructions.\n\n\nBuildouts\n~~~~~~~~~\n\nThe buildouts to install and test are stored in the ``buildouts``\ndirectory; they must be declared with appropriated options in the\n``buildouts/MANIFEST.cfg``. The ones included with this package\nare run by _.\n\nAlternatively, one can specify several manifest files, to aggregate from\nseveral sources. http://buildbot.anybox.fr demonstrates this by running:\n\n* the buildouts included in this package\n* the buildouts shipping with `anybox.recipe.openerp `_. These actually play the role of integration tests for the recipe itself.\n* other combinations of OpenERP versions and community addons that are of interest for Anybox.\n\nManifest file format\n~~~~~~~~~~~~~~~~~~~~\nIn this manifest file, each section corresponds to a buildout (or at\nleast a ``BuildFactory`` object).\nOptions are:\n\n * buildout = TYPE SPECIFICATION,\n where TYPE can be ``standalone`` or indicate a VCS (currently\n ``hg`` only is supported).\n For standalone buildouts, SPECIFICATION is a path from the buildmaster\n directory.\n For VCSes, SPECIFICATION takes the form URL BRANCH PATH,\n where PATH is the path from a clone of URL on branch BRANCH to the\n wished buildout configuration. This allows to use configuration\n files with ``extends`` and to track the buildout configuration\n itself, and to reduce duplication. Buildouts from VCSes are always\n updated to the head of the prescribed branch, independently of the\n changes detected by the buildmaster.\n * watch = LINES: a list of VCS locations to watch for changes (all\n occurrences of this buildout will be rebuilt/retested if any change\n in them). If you use a VCS buildout type, you need to register it here also\n to build if the buildout itself has changed in the remote VCS.\n * build-for = LINES: a list of software combinations that this\n buildout should be run against. Takes the form of a software name\n (currently \"postgresql\" only) and a version requirement (see\n included example and docstrings in\n ``anybox.buildout.openerp.version`` for format). See also \"slave\n capabilities\" below.\n * build_requires: build will happen only on slaves meeting the requirements\n (see also \"slaves capabilities\" below)\n Some known use-cases:\n\n + dependencies on additional software or services (LibreOffice server, postgis, functional testing frameworks)\n + access to private source code repositories\n + network topology conditions, such as quick access to real-life database\n dumps.\n * db_template: the template the database will be built with. Intended\n for preload of PostgreSQL extensions, such as postgis, but can be\n used for testing data as well. Should be paired with a conventional\n requirement expressing that the template exists and can be used.\n * bootstrap options: any option of the form ``bootstrap-foo`` will\n give rise to a command-line option ``--foo`` with the same value\n for the bootstrap. Example::\n\n bootstrap-version = 2.1.0\n\n Exceptions: some options, such as ``--eggs`` or ``-c`` can be passed this\n way. They are managed internally by the configurator. The error\n message will tell you.\n\n The ``--version`` option of ``bootstrap.py`` is mean to require a\n ``zc.buildout`` version, the ``bootstrap.py`` script may itself be\n more or less recent. You may specify the major version of\n ``bootstrap.py`` itself in the following way::\n\n bootstrap-type = v2\n\n ..warning :: currently, ``bootstrap-type`` defaults to ``v1``. If it\n does not match the reality, the build **will fail**, because\n command-line options have changed a lot between ``v1``\n and ``v2``.\n\n\nSlave setup\n~~~~~~~~~~~\n\nWe strongly recommend that you install and run the buildslave with its\nown dedicated POSIX user, e.g.::\n\n sudo adduser --system buildslave\n sudo -su buildslave\n cd\n\n(the ``--system`` option forbids direct logins by setting the default\nshell to ``/bin/false``, see ``man adduser``)\n\nBuildbot slave software\n-----------------------\nFor slave software itself, just follow the official buildbot way of doing::\n\n virtualenv buildslaveenv\n buildslaveenv/bin/pip install buildbot-slave\n bin/buildslave create-slave --help\n\nSystem build dependencies\n-------------------------\nThe slave host system must have all build dependencies\nfor the available buildouts to run. Indeed, the required python eggs may have\nto be installed from pypi, and this can trigger some compilations. In\nturn, these usually require build utilities (gcc, make, etc),\nlibraries and headers.\n\nThere are `packages for debian-based systems `_ that install all needed dependencies for OpenERP buildouts.\n\nRegistration and slave capabilities\n-----------------------------------\nHave your slave registered to the master admin, specifying the\navailable versions of PostgreSQL (e.g, 8.4, 9.0), and other\ncapabilities if there are special builds that make use of them.\nSee \"PostgreSQL requirements\" below for details about Postgresql\ncapability properties.\n\nThe best is to provide a\n``slaves.cfg`` fragment (see ``slaves.cfg.sample`` for syntax and\nsupported options).\n\nCapabilities are defined as a ``slaves.cfg`` option, with one line per\ncapability and version pair. Each line ends with additional\n*capability properties*::\n\n [my-slave]\n capability = postgresql 8.4\n postgresql 9.1 port=5433\n\t private-bzr+ssh-access\n\t selenium-server 2.3\n\nCapabilities are used for\n\n * *filtering* : running builds only on those that can take them (see\n ``build-requires`` option)\n * *slave-local conditions*: applying parameters that depend on the\n slave (here the port for PostgreSQL 9.1) through build properties\n and environment variables. Everything is already tuned by\n default for the ``postgresql`` capability, but an advanced user can\n register environment variables mappings in ``master.cfg`` for other\n capabilities.\n * *demultiplication*: this is the ``build-for`` option of ``MANIFEST.cfg``.\n\nThe example above demonstrates how to use that to indicate access to\nsome private repositories, assuming that the master's\n``MANIFEST.cfg`` declares the builds that need this access::\n\n build-requires=private-bzr+ssh-access\n\nIn some cases, it's meaningful to further restrict a buildslave to run\nonly those builds that really need it. This is useful for rare or\nexpensive resources. Sample ``slave.cfg`` extract for that::\n\n [mybuildslave]\n build-only-if-requires=selenium\n\nPostgreSQL requirements and capability declaration\n--------------------------------------------------\n\nYou must of course provide one or several working PostgreSQL\ninstallation (clusters). These are described as *capabilities* in the\nconfiguration file that makes the master know about your slave and how\nto run builds on it.\n\nThe default values assumes a standard PostgreSQL cluster on the\nsame system as the slave, with a PostgreSQL user having the same name\nas the POSIX user running the slave, having database creation rights.\nAssuming the slave POSIX user is ``buildslave``, just do::\n\n sudo -u postgres createuser --createdb --no-createrole \\\n --no-superuser buildslave\n\nAlternatively, you can provide host, port, and password (see\n``slaves.cfg`` file to see how to express in the master configuration).\n\nWARNING: currently, setting user/password is not\nsupported. Only Unix-socket domains will work (see below).\n\nThe default blank value for host on Debian-based distributions will make the\nslave connect to the PostgreSQL cluster through a Unix-domain socket, ie, the\nuser name is the same as the POSIX user running the slave. Default\nPostgreSQL configurations allow such connections without a password (``ident``\nauthentication method in ``pg_hba.conf``).\n\nTo use ``ident`` authentication on secondary or custom compiled\nclusters, we provide additional capability properties:\n\n* The ``bin`` and ``lib`` should point to the executable and library\n directories of the cluster. Otherwise, the build could be run with a\n wrong version of the client libraries.\n* If ``unix_socket_directory`` is set in ``postgresql.conf``, then\n provide it as the ``host`` capability property. Otherwise, the\n ``psql`` executable and the client libraries use the same defaults\n as the server, provided ``bin`` and ``lib`` are correct (see above).\n* you *must* provide the port number if not the default 5432, because\n the port identifies the cluster uniquely, even for Unix-domain sockets\n\nExamples::\n\n # Default cluster of a secondary PostgreSQL from Debian & Ubuntu\n capability postgresql 9.1 port=5433\n\n # Compiled PostgreSQL with --prefix=/opt/postgresql,\n # port set to 5434 and unix_socket_directory unset in postgresql.conf\n capability postgresql 9.2devel bin=/opt/postgresql/bin lib=/opt/postgresql/lib port=5434\n\n # If unix_socket_directory is set to /opt/postgresql/run, add this:\n # ... host=/opt/postgresql/run\n\nCustom builds\n-------------\nThere is a hook to replace the steps that run after the buildout (test\nrun, then log analysis) by custom ones. This is an advanced option, meant\nfor users that are aware of the internals of\n``anybox.buildbot.openerp``, and notably of the properties that it\nsets and uses.\n\nIn the master configuration file, register a callable that\nreturns a list of buildbot steps. Instead of calling\n``configure_from_buildouts``, follow this example::\n\n from anybox.buildbot.openerp.configurator import BuildoutsConfigurator\n configurator = BuildoutsConfigurator(basedir)\n configurator.post_buildout_steps['mycase'] = mycase_callable\n configurator.populate(BuildmasterConfig)\n\nwhere ``mycase_callable`` is typically a function having the same\nsignature as the\n``post_buildout_steps_standard`` method of ``BuildoutsConfigurator``.\nThis means in particular that it can read the options dict, hence\nreact to its own options.\n\nThen, report the ``mycase`` name in ``MANIFEST.cfg``, in the sections\nfor the relevant buildouts::\n\n [mybuildout]\n post-buildout-steps = mycase\n ...\n\nThe standard build is given by the ``standard`` key. You can actually\nchain them by specifying several such keys (one per line) in the\nconfiguration option. Here's a real-life example::\n\n [mybuildout]\n post-buildout-steps = static-analysis\n standard\n doc\n\nCurrently, ``standard`` is the only builtin set of post buildout steps.\n\nTODO: provide more builtin sets of post buildout steps ; refactor the\ndoc in two sections, the first listing them and explaining how to use\nthem in conf, the second explaining how to register custom ones. The\nfirst doc would not require internal knowledge of buildbot or\n``anybox.buildbot.openerp``.\n\nCapability custom environment mappings\n--------------------------------------\n\nAs explained above, the capability system is able to set environment\nvariables depending on the selected buildlsave and capability\nversion. Of course, this is useful if the tests themselves make use\ndirectly or indirectly of them.\n\nThe environment mappings are preset for ``postgresql`` only, here's how to do\nregister some for another capability, from ``master.cfg``. Again,\nthis goes by splitting througth instantiation of a configurator object\ninstead of the ``configure_from_buildouts`` helper function::\n\n abo_conf = BuildoutsConfigurator(basedir)\n abo_conf.add_capability_environ(\n 'rabbitmq',\n dict(version_prop='rabbitmq_version',\n environ={'RMQ_BASE_URI': '%(cap(base_uri):-)s'),\n 'RMQ_BINARY': '%(cap(binary):-)s'),\n 'AMQP_CTL_SUDO': '%(cap(sudo):-TRUE)s'),\n }))\n\n abo_conf.populate(BuildmasterConfig)\n\n\nNow with ``rabbitmq`` capability defined this way on slaves::\n\n rabbitmq 2.8.4 base_uri=amqp://guest:guest@localhost:5672/ binary=rabbitmqctl sudo=True\n\nThis will setup ``RMQ_BASE_URI``, ``RMQ_BINARY`` and ``AMQP_CTL_SUDO``\nto these values.\n\nThe values, in the ``environ`` sub-dict are ``WithProperties``\nstatement, with their entire expressivity ; just notice the\n``cap(option_name)`` added syntax to refer to properties corresponding\nto capability options.\n\nTweaks, optimization and traps\n------------------------------\n\n* eggs and openerp downloads are shared on a per-slave basis. A lock\n system prevents concurrency in buildout runs.\n\n* Windows slaves are currently unsupported : some steps use '/'\n separators in arguments.\n\n* Do *not* start the slave while its virtualenv is \"activated\"; also take\n care that the bin/ directory of the virtualenv *must not* be on the\n POSIX user default PATH. Many build steps are not designed for that,\n and would miss some dependencies. This is notably the case for the\n buildout step.\n\n* If you want to add virtualenv based build factories, such as the\n ones found in http://buildbot.anybox.fr (notably this distribution),\n make sure that the default system python has virtualenv >=1.5. Prior\n versions have hardcoded file names in /tmp, that lead to permission\n errors in case virtualenv is run again with a different system user\n (meaning that any invocation of virtualenv outside the slave will\n break subsequent builds in the slave that need it). In particular,\n note that in Debian 6.0 (Squeeze), python-virtualenv is currently\n 1.4.9, and is absent from squeeze-backports. You'll have to set it\n up manually (install python-pip first).\n\nContribute\n~~~~~~~~~~\nAuthor:\n\n * Georges Racinet (Anybox)\n\nContributors:\n\n * St\u00e9phane Bidoul (Acsone)\n\nThe primary branch is on the launchpad:\n\n * Code repository and bug tracker:\n https://launchpad.net/anybox.buildbot.openerp\n * PyPI page: http://pypi.python.org/pypi/anybox.buildbot.openerp\n\nPlease branch on the launchpad or contact the authors to report any bug or ask\nfor a new feature.\n\n\nUnit tests\n~~~~~~~~~~\n\nTo run unit tests for this package::\n\n pip install nose\n python setup.py nosetests\n\nCurrently, ``python setup.py test`` tries and install nose and run the\n``nose.collector`` test suite but fails in tearDown.\n\nImprovements\n~~~~~~~~~~~~\nSee the included ``TODO.txt`` file and the project on launchpad:\nhttp://launchpad.net/anybox.buildbot.openerp\n\n\n\nChanges\n~~~~~~~\n\n0.9 (2015-05-15)\n----------------\n - Git support (buildbout repo + watch) (several issues on launchpad)\n - launchpad #1201138: simple inheritance system\n - launchpad #1201175: auto watch for VCS buildout itself\n (not what it references)\n - added a 'static-analysis' postbuildout subfactory\n - launchpad #1201099: introduce subfactories for cleaner pluggability\n (post buildout steps, etc)\n - launchpad #1196310: provide a \"post buildout steps\" for functional testing\n - launchpad #1196308: provide a \"post buildout steps\" for nose testing\n - launchpad #1198702: bootstrap options in MANIFEST\n - launchpad #1142994: url rewrites for vcs polling\n - launchpad #1154673: treeStableTimer scheduler parameter now\n configurable on a per-buildout basis\n - launchpad #1281136: subfactory for sphinx doc compilation & upload\n - launchpad #1281137: subfactories for packaging of hg versioned buildouts\n\n0.8.1\n-----\n - launchpad #1130838: build-only-if-requires buildslave option\n - Using the uniform test launcher script provided by anybox.recipe.openerp 1.2\n - launchpad #1086066: detecting unittest2 failures and errors\n - launchpad #1086392: resilience wrt missing remote mercurial\n branches by retrying one branch after the other\n - post download steps for alternative presentation to buildout and\n tests (allow for packaging and testing the packaged)\n - hgtag buildout source to read from a tag expressed in properties\n - quality: flake8 compliance\n\n0.7\n---\n - launchpad #999069: Test run parts of build factories are now customizable.\n - launchpad #1040070: can read several manifest files\n - launchpad #1050842: now standalone buildouts paths are relative to manifest\n directory.\n - db_template buildout option.\n - launchpad #999066: Utility script to find a free port in a range\n - ignore divergences in bzr branch pulls (notably for mirrors)\n\n0.6\n---\n - launchpad #1008985: Now buildouts can be retrieved directly from\n VCSes (currently Mercurial only).\n - launchpad #1004844: dispatching of PostgreSQL versions by\n capability allows to build within a single slave against several of\n them.\n - launchpad #999116: filtering of slaves for a given build factory\n (buildout) by capability.\n - launchpad #1004916: slaves max_builds and notify_on_missing\n parameters now taken into account\n\n0.5\n---\n - using vcs-clear-retry option of OpenERP recipe\n - launchpad #994524: Configuration option \"build-for\" allows to\n specify PosgreSQL version ranges\n - launchpad #998829: New build-category option in MANIFEST.cfg\n\n0.4.4\n-----\n - List of addons to install now can be specified per build factory\n\n0.4.3\n-----\n - Documentation improvements\n\n0.4.2\n-----\n - Documentation improvements\n\n0.4.1\n-----\n - Initial release on pypi", "description_content_type": null, "docs_url": null, "download_url": "UNKNOWN", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "http://pypi.python.org/pypi/anybox.buildbot.openerp", "keywords": null, "license": "Affero GPLv3", "maintainer": null, "maintainer_email": null, "name": "anybox.buildbot.openerp", "package_url": "https://pypi.org/project/anybox.buildbot.openerp/", "platform": "UNKNOWN", "project_url": "https://pypi.org/project/anybox.buildbot.openerp/", "project_urls": { "Download": "UNKNOWN", "Homepage": "http://pypi.python.org/pypi/anybox.buildbot.openerp" }, "release_url": "https://pypi.org/project/anybox.buildbot.openerp/0.9/", "requires_dist": null, "requires_python": null, "summary": "Buildbot setup for buildout based openerp installations", "version": "0.9" }, "last_serial": 3290767, "releases": { "0.4.1": [ { "comment_text": "", "digests": { "md5": "7baa1400ed6063177c324d64a5f39b02", "sha256": "be21b488399a14eafb73f3472822eca38e4998d2a04c15eca961df3ac6d3d051" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.4.1.tar.gz", "has_sig": false, "md5_digest": "7baa1400ed6063177c324d64a5f39b02", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 27554, "upload_time": "2012-05-03T13:33:14", "url": "https://files.pythonhosted.org/packages/23/1c/636f9046a9a26c09880eb15a58329e8ae217f8d327057f1b153e2a42663a/anybox.buildbot.openerp-0.4.1.tar.gz" } ], "0.4.2": [ { "comment_text": "", "digests": { "md5": "d29e6473f88ae01b7e2ff5c58b703ae9", "sha256": "540d6b53d75fac93a222006ac5ec8f2f6fc87990679f79b7a2db06c2ac7fb2b4" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.4.2.tar.gz", "has_sig": false, "md5_digest": "d29e6473f88ae01b7e2ff5c58b703ae9", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 27560, "upload_time": "2012-05-03T13:36:47", "url": "https://files.pythonhosted.org/packages/34/7f/b840c66656324eee69957d96f05e99f9fb01ea0ab13bad9ebe2dad3d7700/anybox.buildbot.openerp-0.4.2.tar.gz" } ], "0.4.3": [ { "comment_text": "", "digests": { "md5": "4a66f7578885bb3905ef2cf57bc772f1", "sha256": "910a86b81e22c96060ca0e64839286cf29184b0324140a05274dadb31448a21c" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.4.3.tar.gz", "has_sig": false, "md5_digest": "4a66f7578885bb3905ef2cf57bc772f1", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 27558, "upload_time": "2012-05-03T13:40:33", "url": "https://files.pythonhosted.org/packages/51/34/6a579a8e3e390c3f28ce68262ec55851eeee409d95b83657edb9f3437bdc/anybox.buildbot.openerp-0.4.3.tar.gz" } ], "0.5": [ { "comment_text": "", "digests": { "md5": "4c4d254a747a1f8e859306c10338a1f8", "sha256": "b9799c2cd8811827ca02ab01c155a2fe03c5e27b07f3f4efec8f99d0387d35c8" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.5.tar.gz", "has_sig": false, "md5_digest": "4c4d254a747a1f8e859306c10338a1f8", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 34735, "upload_time": "2012-05-24T21:16:19", "url": "https://files.pythonhosted.org/packages/00/01/6723bd8e307f6462f20956b3cc00a179f8aacd91951165a00147fc922ebe/anybox.buildbot.openerp-0.5.tar.gz" } ], "0.6": [ { "comment_text": "", "digests": { "md5": "d5edb950e56f6a5b0ea9e3f54e4431d4", "sha256": "01a6432a22d19ec474bcfb00968bde9ae93ea41ae4a03b7800c1e980730a2830" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.6.tar.gz", "has_sig": false, "md5_digest": "d5edb950e56f6a5b0ea9e3f54e4431d4", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 38001, "upload_time": "2012-07-29T15:40:32", "url": "https://files.pythonhosted.org/packages/61/fc/2c7a4e8d64296cc16dd4acb8ddf288a309e4ef7e865754b651b33bbe21d1/anybox.buildbot.openerp-0.6.tar.gz" } ], "0.7": [ { "comment_text": "", "digests": { "md5": "0d5d622ddf750af502b95e7599ad779e", "sha256": "13d1d26e6c1f1402b927f2aee05deffe46497e694ad95fe1be3dfd78006746db" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.7.tar.gz", "has_sig": false, "md5_digest": "0d5d622ddf750af502b95e7599ad779e", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 42337, "upload_time": "2012-10-02T19:55:48", "url": "https://files.pythonhosted.org/packages/84/ae/e86aa48638f123d9bef6dca69d3a3f2832e6d0aa0a90ccd4cbfe94705be7/anybox.buildbot.openerp-0.7.tar.gz" } ], "0.8": [ { "comment_text": "", "digests": { "md5": "92588b105864807b80853c16b9aa9040", "sha256": "1ea322b531fae20d830e44a1b90dd2bd8baab29d980de25be66a5047703d7fea" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.8.tar.gz", "has_sig": false, "md5_digest": "92588b105864807b80853c16b9aa9040", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 48893, "upload_time": "2013-03-02T16:38:17", "url": "https://files.pythonhosted.org/packages/01/0c/a2586071288a68565e03b99a39745412fd1325ef22b3306c6730a3f89e94/anybox.buildbot.openerp-0.8.tar.gz" } ], "0.8.1": [ { "comment_text": "", "digests": { "md5": "8a16d9eabd3ca26435db28edb7cf044b", "sha256": "10a42b88c9385f82418140e849b1e8dbd01d04208d7d27cfbb306df48e7738e0" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.8.1.tar.gz", "has_sig": false, "md5_digest": "8a16d9eabd3ca26435db28edb7cf044b", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 51517, "upload_time": "2013-03-02T17:09:52", "url": "https://files.pythonhosted.org/packages/75/8c/1834b784d97aede3f5f1464ef358564dcd65b008d44d3d6c65ef0d766339/anybox.buildbot.openerp-0.8.1.tar.gz" } ], "0.9": [ { "comment_text": "", "digests": { "md5": "7c04468f4c7bf8d337271d46d6d8f8f8", "sha256": "8c586b93d4aa38e7ce68b897019d39a710b81aecd5a2f317d9af3e8dfb8b1a7d" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.9.tar.gz", "has_sig": false, "md5_digest": "7c04468f4c7bf8d337271d46d6d8f8f8", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 69767, "upload_time": "2014-05-15T18:56:11", "url": "https://files.pythonhosted.org/packages/11/8f/30f64f6e4a98bf86c09b8b6158a08b767c7bea5c59645dd8b1275b2eb690/anybox.buildbot.openerp-0.9.tar.gz" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "7c04468f4c7bf8d337271d46d6d8f8f8", "sha256": "8c586b93d4aa38e7ce68b897019d39a710b81aecd5a2f317d9af3e8dfb8b1a7d" }, "downloads": -1, "filename": "anybox.buildbot.openerp-0.9.tar.gz", "has_sig": false, "md5_digest": "7c04468f4c7bf8d337271d46d6d8f8f8", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 69767, "upload_time": "2014-05-15T18:56:11", "url": "https://files.pythonhosted.org/packages/11/8f/30f64f6e4a98bf86c09b8b6158a08b767c7bea5c59645dd8b1275b2eb690/anybox.buildbot.openerp-0.9.tar.gz" } ] }