Does testing include a mixture with a master under 3.x? I only ask since I'd guess that a master under 2.x might be sending parameters down as strings rather than unicode.
Anyway, no, I hadn't tried a new worker, because both the same and an earlier buildbot version was working fine on my Win8/10 workers, so I focused more on other environmental differences, and since time was tight, once I identified a workaround, I stopped for the time being. I did misspeak in the last note - the issue was a unicode name for a keyword parameter remote function call, not the function name itself. The actual failure occurs inside twisted while dispatching the remote call from the master. It takes a PB-transmitted dictionary for the arguments, using either apply() or **kwargs against them directly. That fails with a "TypeError: keywords must be strings" under 2.6 but 2.7 is fine. Since the dispatch failure occurs during the dispatch to buildbot-worker, but before it gets any chance to run, I'm not sure that it could change things. Unless the master changes something in how it transmits request arguments that needed a newer worker on the client to identify. Oh, I did also peek at the latest twisted source but didn't see any differences in that path at a quick glance (aside from switching from apply() to **kw) that would seem to be able to resolve this, but that's something else I could test. Or I could just move off of 2.6 which I last updated to in 2009 :-) -- David On Fri, Oct 13, 2017 at 4:17 PM, Craig Rodrigues <rodr...@crodrigues.org> wrote: > Did you try leaving things on Python 2.6, but upgrading the worker to > buidlbot-worker 0.9.12 ? > buildbot-worker is still tested on Python 2.6. > > -- > Craig > > On Fri, Oct 13, 2017 at 1:07 PM, David Bolen <db3l....@gmail.com> wrote: > >> Yes they look to be ok now. Although for future reference, both Windows >> XP and 7 workers did initially break - apparently due to an incompatibility >> when using Python < 2.7 on the worker (I have 2.6 on those machines). The >> master is sending remote methods down using unicode for method names. So >> 2.7+ appears to be a worker requirement in this mixed-mode setup (though I >> doubt any new worker would try to use 2.6). >> >> For now, I've locally modified my version of twisted on each buildbot to >> deal with that, pending time to have them upgraded to 2.7 (or possibly in >> the Win7 case, just go to 3.x). >> >> I'm not sure if that might be the same issue with kloth-win64. >> >> -- David >> >> >> On Fri, Oct 13, 2017 at 3:59 PM, Craig Rodrigues <rodr...@crodrigues.org> >> wrote: >> >>> On Fri, Oct 6, 2017 at 1:46 PM, David Bolen <db3l....@gmail.com> wrote: >>> >>>> >>>> Oh, and I can offer any of my Windows workers for interoperability >>>> testing if you'd like me to temporarily configure them to an >>>> additional master. At least one of them (XP) is probably not worth >>>> the effort of getting to (a) vs. (b). >>>> >>> >>> >>> I don't think I need this right now. >>> If I look at: >>> http://buildbot.python.org/all/#/workers >>> >>> Your windows buildbot workers seem to be working fine with the new >>> buildbot master. >>> >>> This is one buildbot worker kloth-win64 which is not working. >>> I don't know what the problem with that one is. >>> >>> -- >>> Craig >>> >> >> > _______________________________________________ Python-Buildbots mailing list Python-Buildbots@python.org https://mail.python.org/mailman/listinfo/python-buildbots
