Re: [tahoe-dev] buildbot update

[Ruben Kerkhof]

On Mon, Mar 9, 2009 at 10:51 PM, zooko zo...@zooko.com wrote:
 [adding Cc: Ruben Kerkhof]

 On Mar 9, 2009, at 15:25 PM, Brian Warner wrote:

 Ruben's Fedora box just failed (in the darcs checkout step) with an
 exitcode=-1, which usually means that it's using PTYs when it shouldn't.
 Ruben, could you modify your buildslave's buildbot.tac file to change the
 usePTY=1 line to say usePTY=0 and restart the buildslave?

 Also for the record buildbot v0.7.10 apparently fixes that problem [1], so
 if you upgrade to buildbot v0.7.10 you don't need to change that setting
 (but it wouldn't hurt to change that setting).

 Zooko: the other builders look ok, feel free to promote them.

 Okay, after we see if Ruben's buildbot can also be promoted then I'll do the
 promotions in one batch.


I've just updated the buildbot, and changed the usepty setting to 0.
It's green again.

Regards,

Ruben
___
tahoe-dev mailing list
tahoe-dev@allmydata.org
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] buildbot update

[Zooko O'Whielacronx]

Okay!  Almost all builders have levelled up to Supported status!  Send
more buildbots!  I especially want a buildbot on Arc's rusty dusty
Pentium III, since he reported test failures there (#659) and on
Zandr's NAS device, since there are test failures there (pycryptopp
#17).

The buildbots which graduated to the ranks of Supported are: Eugen
lenny-amd64, zooko yukyuk jauntyish, Ruben Fedora, zooko draco Mac-PPC
10.4, and zooko ootles Mac-amd64 10.4

That leaves poor Dan ArchLinux as the only Unsupported test builder,
and deb-lenny-amd64 and deb-intrepid-amd64 as the two Unsupported deb
builders.

As for the latter, they are successfully building .debs, and I'm
waiting for Brian to decide how he wants those .debs to get uploaded
and added to our apt repository.

As for the former, it is really weird.  zope.interface enters a long recursion:

http://allmydata.org/buildbot/builders/Dan%20ArchLinux/builds/273/steps/test/logs/stdio

  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 1348, in __get__
return implementedBy(cls)
  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 354, in implementedByFallback
spec = Implements(*[implementedBy(c) for c in bases])
  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 343, in implementedByFallback
spec = Implements(*_normalizeargs(spec))
  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 1370, in _normalizeargs
_normalizeargs(v, output)
  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 1370, in _normalizeargs
_normalizeargs(v, output)
  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 1370, in _normalizeargs
_normalizeargs(v, output)
  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 1370, in _normalizeargs
_normalizeargs(v, output)
...
969 more frames like this
...
  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 1370, in _normalizeargs
_normalizeargs(v, output)
  File /usr/lib/python2.6/site-packages/zope/interface/declarations.py,
line 1369, in _normalizeargs
for v in sequence:
TypeError: 'str' object is not iterable

What?  'str' object is not iterable?  Is too!  Examining
declarations.py line 1370 doesn't tell me how that can recurse 973
times:

http://bazaar.launchpad.net/%7Elandscape/zope3/production/annotate/head%3A/src/zope/interface//declarations.py#L1369

It says this:

def _normalizeargs(sequence, output = None):
...
for v in sequence:
_normalizeargs(v, output)

So does this imply that there is a data structure with a loop being
passed?  Or at least a data structure which is more than 973 levels
deep?

Regards,

Zooko

tickets mentioned in this email:
http://allmydata.org/trac/tahoe/ticket/659 # tests fail on rusty dusty server
http://allmydata.org/trac/pycryptopp/ticket/17 # pycryptopp fails
self-tests on ARMv5 architecture
___
tahoe-dev mailing list
tahoe-dev@allmydata.org
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] buildbot update

[Shawn Willden]

On Monday 09 March 2009 03:47:03 pm Brian Warner wrote:
 For this purpose, we might want to upload them to the allmydata prodgrid
 instead.. might be more reliable and less stall-sensitive. I dunno.

If we want to use the prodgrid, is there a way my box can use the production 
helper?  That eliminates the need to worry about having a local Tahoe node 
with the right configuration, and reduces the load on my upstream 
bandwidth -- I'm always trying to avoid competing with my VOIP for the meager 
upstream.

Shawn.
___
tahoe-dev mailing list
tahoe-dev@allmydata.org
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] buildbot update

[Brian Warner]

On Mon, 9 Mar 2009 16:16:04 -0700
Shawn Willden shawn-ta...@willden.org wrote:

 If we want to use the prodgrid, is there a way my box can use the
 production helper? That eliminates the need to worry about having a local
 Tahoe node with the right configuration, and reduces the load on my
 upstream bandwidth -- I'm always trying to avoid competing with my VOIP for
 the meager upstream.

Actually, we can just use a prodnet webapi node. Basically you'll set up a
stub ~buildslave/.tahoe/ , with a node.url and a private/aliases . All the
CLI commands use HTTP on the backend, so they'll just speak to our prodnet
webapi node instead of a local one. You'll get 1x uploads and won't need to
maintain your own prodnet-connected node. (I don't know if the CLI tools can
speak SSL, but we'll find out, and I suppose it wouldn't be the end of the
world if it had to run over unencrypted HTTP).

cheers,
 -Brian
___
tahoe-dev mailing list
tahoe-dev@allmydata.org
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev