Re: [PD-dev] buildbot on Macs and from git
At the moment buildbot fails with exceptions.RuntimeError: Couldn't find executable for 'svn' + the same for git I added ~buildbot/.bashrc to hopefully add Fink stuff to buildbot's environment .hc Hmm, didn't work out, and net.sourceforge.buildbot.plist has sw/bin in the path too, and svn is there, so i really don't know... Andras Ok, I was getting some builds from macosx104-i386, but then it disappeared, donno what happened there. macosx104-powerpc seems to be running still tho. Yea the process died somehow. I have restarted it with the command: /sw/bin/buildbot restart /Users/buildbot/macosx104-i386 The output had some complaints: /sw/lib/python2.6/site-packages/twisted/persisted/sob.py:12: DeprecationWarning: the md5 module is deprecated; use hashlib instead import os, md5, sys /sw/lib/python2.6/site-packages/twisted/python/filepath.py:12: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha /sw/lib/python2.6/site-packages/twisted/internet/_sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead import itertools, md5 Following twistd.log until startup finished.. /sw/lib/python2.6/site-packages/buildbot/scripts/logwatcher.py:52: PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. env=os.environ, Removing stale pidfile /Users/buildbot/macosx104-i386/twistd.pid I worked on the pd-master/master.cfg a bit, including changing some of the names to be more consistent. I also got pure-data building from Miller's git. http://128.238.56.50:8010/builders/pure-data%20Linux % 20debian-stable-i386/builds/6 .hc Good! I saw you stared experimenting with a builder for the externals too - do i understand right that at the end we will have every external built separately? I was thinking about breaking them out to a separate master, but then we'd need to duplicate every slave setup, so finally i think they could stay in the main master, and we could have each of their have their own category name, which allows for some selection at the web page. Also note that for the builders, you can define an array with slavenames: instead of a single string slavename, so you can test the same builder on multiple slaves at the same time. At the end they have to broken down to one slave per builder, otherwise the diag output is not easy to understand. Changing descriptionDone values to past tense like compiled may not make sense when the step fails and the output goes like compiled failed. Also there are things like autogen which don't have a proper past tense... :) Another thing i noticed an svn update by itself, i think we shall have the sources explicitly in master.cfg otherwise it will fail where the slave got reset. Also you told before we wanted clobber (tabula rasa) checkout not an update... I saw the make install, make uninstall steps in the output - having these would make much sense, fyi tests can be called with Test() which has some advantages over ShellCommand() like it doesn't make the whole build halt on failure. BTW switching the sources to git is easy, what we have to work out is Git polling. It's built into 0.8.1 but needs to triggered from git for 0.7.12. And then we
Re: [PD-dev] buildbot on Macs and from git
On Sep 16, 2010, at 12:21 PM, András Murányi wrote: At the moment buildbot fails with exceptions.RuntimeError: Couldn't find executable for 'svn' + the same for git I added ~buildbot/.bashrc to hopefully add Fink stuff to buildbot's environment .hc Hmm, didn't work out, and net.sourceforge.buildbot.plist has sw/ bin in the path too, and svn is there, so i really don't know... Andras Ok, I was getting some builds from macosx104-i386, but then it disappeared, donno what happened there. macosx104-powerpc seems to be running still tho. Yea the process died somehow. I have restarted it with the command: /sw/bin/buildbot restart /Users/buildbot/macosx104-i386 The output had some complaints: /sw/lib/python2.6/site-packages/twisted/persisted/sob.py: 12: DeprecationWarning: the md5 module is deprecated; use hashlib instead import os, md5, sys /sw/lib/python2.6/site-packages/twisted/python/ filepath.py:12: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha /sw/lib/python2.6/site-packages/twisted/internet/ _sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead import itertools, md5 Following twistd.log until startup finished.. /sw/lib/python2.6/site-packages/buildbot/scripts/ logwatcher.py:52: PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. env=os.environ, Removing stale pidfile /Users/buildbot/macosx104-i386/twistd.pid I worked on the pd-master/master.cfg a bit, including changing some of the names to be more consistent. I also got pure-data building from Miller's git. http://128.238.56.50:8010/builders/pure-data%20Linux % 20debian-stable-i386/builds/6 .hc Good! I saw you stared experimenting with a builder for the externals too - do i understand right that at the end we will have every external built separately? I was thinking about breaking them out to a separate master, but then we'd need to duplicate every slave setup, so finally i think they could stay in the main master, and we could have each of their have their own category name, which allows for some selection at the web page. Also note that for the builders, you can define an array with slavenames: instead of a single string slavename, so you can test the same builder on multiple slaves at the same time. At the end they have to broken down to one slave per builder, otherwise the diag output is not easy to understand. Changing descriptionDone values to past tense like compiled may not make sense when the step fails and the output goes like compiled failed. Also there are things like autogen which don't have a proper past tense... :) Another thing i noticed an svn update by itself, i think we shall have the sources explicitly in master.cfg otherwise it will fail where the slave got reset. Also you told before we wanted clobber (tabula rasa) checkout not an update... I saw the make install, make uninstall steps in the output - having these would make much sense, fyi tests can be called with Test() which has some advantages over ShellCommand() like it doesn't make the whole build halt on failure. BTW switching the sources to git is easy, what we have to work out is Git polling. It's built into 0.8.1 but needs to triggered from git for 0.7.12. And then we have this thing
[PD-dev] [ pure-data-Bugs-3067959 ] GUI elements with init don't respond
Bugs item #3067959, was opened at 2010-09-16 22:46 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3067959group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Z. Tamás () Assigned to: Hans-Christoph Steiner (eighthave) Summary: GUI elements with init don't respond Initial Comment: Pd version: 0.42.5-extended Windows 7 Professional, Intel Core2 Duo P8600 @ 2.4Ghz built-in sound Saved a patch with some GUI-elements (sliders) having their init-property turned on, so they should have initialized themselves with the previously saved position. Although they do initialized themselves, after reopening the patch, they didn't respond graphically to any interactions. Trying to interact with the objects does change their values, however, their appear to be frozen, so their graphics do not update according to their current value (sometimes they do update, when send the patch-window to the taskbar, and then bring it back...). I found, that this problem occurs, when any of the GUI elements have their init-proprty activated - if no element have this feature, everything works normally. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3067959group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
