Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread William Siegrist
Here are the largest results sets on the master in GB. We currently store 6.8TB 
of total results, going back 14 months, and 1.1TB of archives going back 1 
week. 

1500Apple MountainLion (Leaks)
1018Chromium Mac Release (Tests)
857 Chromium Linux Release (Tests)
532 Chromium Win Release (Tests)
371 Apple MountainLion Debug WK2 (Tests)
324 Apple Lion Debug WK2 (Tests)
299 Chromium Linux Release (Grid Layout)
173 GTK Linux 64-bit Release
171 Chromium Android Release (Tests)
160 EFL Linux 64-bit Debug WK2
158 Apple Lion (Leaks)
145 EFL Linux 64-bit Release
113 EFL Linux 64-bit Debug
105 GTK Linux 32-bit Release
94  GTK Linux 64-bit Debug
94  GTK Linux 64-bit Release WK2 (Tests)
85  EFL Linux 64-bit Release WK2
80  Apple Lion Release WK1 (Tests)
77  Apple Lion Release WK2 (Tests)
60  Apple Lion Debug WK1 (Tests)
60  Apple MountainLion Debug WK1 (Tests)
59  Apple MountainLion Release WK1 (Tests)
53  Qt Linux Release

Archives are already pruning after 1 week. Next week, I'm going to start 
pruning results older than 14 months since we don't have much more space. If 
anyone thinks you need more than 14 months of results, let me know soon and we 
can see what our options are.

-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread Eric Seidel
I'm surprised that chromium mac is 3x the size of Apple Mac... debug
even!  Chromium build output should be much smaller... at least as of
late.

On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.com wrote:
 Here are the largest results sets on the master in GB. We currently store 
 6.8TB of total results, going back 14 months, and 1.1TB of archives going 
 back 1 week.

 1500Apple MountainLion (Leaks)
 1018Chromium Mac Release (Tests)
 857 Chromium Linux Release (Tests)
 532 Chromium Win Release (Tests)
 371 Apple MountainLion Debug WK2 (Tests)
 324 Apple Lion Debug WK2 (Tests)
 299 Chromium Linux Release (Grid Layout)
 173 GTK Linux 64-bit Release
 171 Chromium Android Release (Tests)
 160 EFL Linux 64-bit Debug WK2
 158 Apple Lion (Leaks)
 145 EFL Linux 64-bit Release
 113 EFL Linux 64-bit Debug
 105 GTK Linux 32-bit Release
 94  GTK Linux 64-bit Debug
 94  GTK Linux 64-bit Release WK2 (Tests)
 85  EFL Linux 64-bit Release WK2
 80  Apple Lion Release WK1 (Tests)
 77  Apple Lion Release WK2 (Tests)
 60  Apple Lion Debug WK1 (Tests)
 60  Apple MountainLion Debug WK1 (Tests)
 59  Apple MountainLion Release WK1 (Tests)
 53  Qt Linux Release

 Archives are already pruning after 1 week. Next week, I'm going to start 
 pruning results older than 14 months since we don't have much more space. If 
 anyone thinks you need more than 14 months of results, let me know soon and 
 we can see what our options are.

 -Bill

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread Dirk Pranke
This is the output of the test bots, right? I'm guessing this is due
to (a) us running pixel tests and (b) not checking in the expected
failing baselines. If I ever get back to working on supporting
-failing.png, this could go down *a lot*.

Alternatively, we could just decide to check in the existing failures
as -expected and call it good enough ...

-- Dirk

On Fri, Jan 25, 2013 at 9:35 AM, Eric Seidel e...@webkit.org wrote:
 I'm surprised that chromium mac is 3x the size of Apple Mac... debug
 even!  Chromium build output should be much smaller... at least as of
 late.

 On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.com wrote:
 Here are the largest results sets on the master in GB. We currently store 
 6.8TB of total results, going back 14 months, and 1.1TB of archives going 
 back 1 week.

 1500Apple MountainLion (Leaks)
 1018Chromium Mac Release (Tests)
 857 Chromium Linux Release (Tests)
 532 Chromium Win Release (Tests)
 371 Apple MountainLion Debug WK2 (Tests)
 324 Apple Lion Debug WK2 (Tests)
 299 Chromium Linux Release (Grid Layout)
 173 GTK Linux 64-bit Release
 171 Chromium Android Release (Tests)
 160 EFL Linux 64-bit Debug WK2
 158 Apple Lion (Leaks)
 145 EFL Linux 64-bit Release
 113 EFL Linux 64-bit Debug
 105 GTK Linux 32-bit Release
 94  GTK Linux 64-bit Debug
 94  GTK Linux 64-bit Release WK2 (Tests)
 85  EFL Linux 64-bit Release WK2
 80  Apple Lion Release WK1 (Tests)
 77  Apple Lion Release WK2 (Tests)
 60  Apple Lion Debug WK1 (Tests)
 60  Apple MountainLion Debug WK1 (Tests)
 59  Apple MountainLion Release WK1 (Tests)
 53  Qt Linux Release

 Archives are already pruning after 1 week. Next week, I'm going to start 
 pruning results older than 14 months since we don't have much more space. If 
 anyone thinks you need more than 14 months of results, let me know soon and 
 we can see what our options are.

 -Bill

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread William Siegrist
Yes, I'm referring to the test results that get uploaded to 
http://build.webkit.org/results/, presumably by the test slaves. The 
archives I refer to are http://build.webkit.org/archives/, which I believe 
are just the binaries built by the build slaves.

-Bill


On Jan 25, 2013, at 9:42 AM, Dirk Pranke dpra...@chromium.org wrote:

 This is the output of the test bots, right? I'm guessing this is due
 to (a) us running pixel tests and (b) not checking in the expected
 failing baselines. If I ever get back to working on supporting
 -failing.png, this could go down *a lot*.
 
 Alternatively, we could just decide to check in the existing failures
 as -expected and call it good enough ...
 
 -- Dirk
 
 On Fri, Jan 25, 2013 at 9:35 AM, Eric Seidel e...@webkit.org wrote:
 I'm surprised that chromium mac is 3x the size of Apple Mac... debug
 even!  Chromium build output should be much smaller... at least as of
 late.
 
 On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.com 
 wrote:
 Here are the largest results sets on the master in GB. We currently store 
 6.8TB of total results, going back 14 months, and 1.1TB of archives going 
 back 1 week.
 
 1500Apple MountainLion (Leaks)
 1018Chromium Mac Release (Tests)
 857 Chromium Linux Release (Tests)
 532 Chromium Win Release (Tests)
 371 Apple MountainLion Debug WK2 (Tests)
 324 Apple Lion Debug WK2 (Tests)
 299 Chromium Linux Release (Grid Layout)
 173 GTK Linux 64-bit Release
 171 Chromium Android Release (Tests)
 160 EFL Linux 64-bit Debug WK2
 158 Apple Lion (Leaks)
 145 EFL Linux 64-bit Release
 113 EFL Linux 64-bit Debug
 105 GTK Linux 32-bit Release
 94  GTK Linux 64-bit Debug
 94  GTK Linux 64-bit Release WK2 (Tests)
 85  EFL Linux 64-bit Release WK2
 80  Apple Lion Release WK1 (Tests)
 77  Apple Lion Release WK2 (Tests)
 60  Apple Lion Debug WK1 (Tests)
 60  Apple MountainLion Debug WK1 (Tests)
 59  Apple MountainLion Release WK1 (Tests)
 53  Qt Linux Release
 
 Archives are already pruning after 1 week. Next week, I'm going to start 
 pruning results older than 14 months since we don't have much more space. 
 If anyone thinks you need more than 14 months of results, let me know soon 
 and we can see what our options are.
 
 -Bill
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread Tony Chang
On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.comwrote:

 Here are the largest results sets on the master in GB. We currently store
 6.8TB of total results, going back 14 months, and 1.1TB of archives going
 back 1 week.

 1500Apple MountainLion (Leaks)
 1018Chromium Mac Release (Tests)
 857 Chromium Linux Release (Tests)
 532 Chromium Win Release (Tests)
 371 Apple MountainLion Debug WK2 (Tests)
 324 Apple Lion Debug WK2 (Tests)
 299 Chromium Linux Release (Grid Layout)


The Grid Layout bot no longer exists.  We can delete these archived results.

tony
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] build.webkit.org down

2013-01-23 Thread William Siegrist
build.webkit.org went down over night due to running out of disk space. I'm 
working to bring it back as soon as possible.

-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down

2013-01-23 Thread William Siegrist
build.webkit.org is back up. I reduced the retention of build archives from 2 
weeks to 1 week to regain enough space to get the master running again. I'm 
still waiting on space calculations to figure out what ate up all of the space 
(the server uses 9TB of space currently after deleting 1TB of archives). We had 
over 2TB free last I checked manually, but our server monitor had a typo in its 
config that made the build.webkit.org's space usage report 5x lower than it 
actually was, so I did not get any alarms until it was too late. 

The server might be slow for a while due to the extra CPU and IO load of my 
space calculations.

-Bill



On Jan 23, 2013, at 7:57 AM, William Siegrist wsiegr...@apple.com wrote:

 build.webkit.org went down over night due to running out of disk space. I'm 
 working to bring it back as soon as possible.
 
 -Bill
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread William Siegrist
On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:

 Is something being upgraded right now?
 

No, the config file has a problem in it which is unrelated to our upgrade as 
far as I can tell. I'm trying to track down what happened. 

$ buildbot checkconfig
Unhandled Error
Traceback (most recent call last):
  File /opt/local/bin/buildbot, line 4, in module
runner.run()
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/buildbot/scripts/runner.py,
 line 1350, in run
if not doCheckConfig(so):
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/buildbot/scripts/runner.py,
 line 1071, in doCheckConfig
return cl.load(quiet=quiet)
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/buildbot/scripts/checkconfig.py,
 line 29, in load
self.basedir, self.configFileName)
--- exception caught here ---
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/buildbot/config.py,
 line 144, in loadConfig
exec f in localDict
  File /Volumes/sas/buildbot/webkit/master.cfg, line 886, in module
loadBuilderConfig(c)
  File /Volumes/sas/buildbot/webkit/master.cfg, line 864, in loadBuilderConfig
builder[factory] = factory(*factoryArgs)
exceptions.TypeError: __init__() takes exactly 4 arguments (5 given)
Configuration Errors:
  error while parsing config file: __init__() takes exactly 4 arguments (5 
given) (traceback in logfile)


-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread William Siegrist

On Jun 21, 2012, at 10:54 AM, William Siegrist wsiegr...@apple.com wrote:

 On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:
 
 Is something being upgraded right now?
 
 
 No, the config file has a problem in it which is unrelated to our upgrade as 
 far as I can tell. I'm trying to track down what happened. 
 


Rev 120937 broke it. I updated the working copy to 120936 to get it back up for 
now. 

http://trac.webkit.org/changeset/120937


-Bill


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread Sergio Villar Senin
En 21/06/12 19:54, William Siegrist escribiu:
 On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:
 
 Is something being upgraded right now?

 
 No, the config file has a problem in it which is unrelated to our upgrade as 
 far as I can tell. I'm trying to track down what happened. 
 
 $ buildbot checkconfig

Do we have any tool that allows to check locally changes in the slaves
configuration?

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread Eric Seidel
One can run:
http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/mastercfg_unittest.py

to test the master locally, but that's all I know of.

On Thu, Jun 21, 2012 at 11:15 AM, Sergio Villar Senin
svil...@igalia.com wrote:
 En 21/06/12 19:54, William Siegrist escribiu:
 On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:

 Is something being upgraded right now?


 No, the config file has a problem in it which is unrelated to our upgrade as 
 far as I can tell. I'm trying to track down what happened.

 $ buildbot checkconfig

 Do we have any tool that allows to check locally changes in the slaves
 configuration?

 BR
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread Osztrogonac Csaba

Hi,

In this case we could have avoided the breakage with running this unittest.
Can we make the master somehow run this unittest before restarting itself?

br,
Ossy

Eric Seidel írta:

One can run:
http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/mastercfg_unittest.py

to test the master locally, but that's all I know of.

On Thu, Jun 21, 2012 at 11:15 AM, Sergio Villar Senin
svil...@igalia.com wrote:

En 21/06/12 19:54, William Siegrist escribiu:

On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:


Is something being upgraded right now?


No, the config file has a problem in it which is unrelated to our upgrade as 
far as I can tell. I'm trying to track down what happened.

$ buildbot checkconfig

Do we have any tool that allows to check locally changes in the slaves
configuration?

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread William Siegrist
The server does not run the unittests, but it does normally run `buildbot 
checkconfig`. However, we had to temporarily bypass the checkconfig test during 
restart due to a bug in Buildbot:

http://trac.buildbot.net/ticket/2279

The best thing to do when working on the buildbot config is to have buildbot 
installed on your local machine so you can test the config before committing. 
That avoids the confusion of the reconfig not happening and people thinking the 
automatic reconfig is just broken.

-Bill


On Jun 21, 2012, at 12:28 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:

 Hi,
 
 In this case we could have avoided the breakage with running this unittest.
 Can we make the master somehow run this unittest before restarting itself?
 
 br,
 Ossy
 
 Eric Seidel írta:
 One can run:
 http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/mastercfg_unittest.py
 to test the master locally, but that's all I know of.
 On Thu, Jun 21, 2012 at 11:15 AM, Sergio Villar Senin
 svil...@igalia.com wrote:
 En 21/06/12 19:54, William Siegrist escribiu:
 On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:
 
 Is something being upgraded right now?
 
 No, the config file has a problem in it which is unrelated to our upgrade 
 as far as I can tell. I'm trying to track down what happened.
 
 $ buildbot checkconfig
 Do we have any tool that allows to check locally changes in the slaves
 configuration?
 
 BR
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread Lucas Forschler
I'd like to see a 'test' buildbot up and running that we could use as a staging 
area for trying out new changes before deploying to the production server.  We 
could copy /OpenSource/Tools/BuildSlaveSupport/build.webkit.org-config to 
/OpenSource/Tools/BuildSlaveSupport/test.webkit.org-config, and have a test 
build master that updates and outputs logs somewhere readable (public_html?).  
Then, we could make sure any changes work on the test master before committing 
them to production.

Thoughts?
Lucas


On Jun 21, 2012, at 1:15 PM, William Siegrist wrote:

 The server does not run the unittests, but it does normally run `buildbot 
 checkconfig`. However, we had to temporarily bypass the checkconfig test 
 during restart due to a bug in Buildbot:
 
 http://trac.buildbot.net/ticket/2279
 
 The best thing to do when working on the buildbot config is to have buildbot 
 installed on your local machine so you can test the config before committing. 
 That avoids the confusion of the reconfig not happening and people thinking 
 the automatic reconfig is just broken.
 
 -Bill
 
 
 On Jun 21, 2012, at 12:28 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 In this case we could have avoided the breakage with running this unittest.
 Can we make the master somehow run this unittest before restarting itself?
 
 br,
 Ossy
 
 Eric Seidel írta:
 One can run:
 http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/mastercfg_unittest.py
 to test the master locally, but that's all I know of.
 On Thu, Jun 21, 2012 at 11:15 AM, Sergio Villar Senin
 svil...@igalia.com wrote:
 En 21/06/12 19:54, William Siegrist escribiu:
 On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:
 
 Is something being upgraded right now?
 
 No, the config file has a problem in it which is unrelated to our upgrade 
 as far as I can tell. I'm trying to track down what happened.
 
 $ buildbot checkconfig
 Do we have any tool that allows to check locally changes in the slaves
 configuration?
 
 BR
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread Mark Rowe

On 2012-06-21, at 15:46, Lucas Forschler lforsch...@apple.com wrote:

 I'd like to see a 'test' buildbot up and running that we could use as a 
 staging area for trying out new changes before deploying to the production 
 server.  We could copy 
 /OpenSource/Tools/BuildSlaveSupport/build.webkit.org-config to 
 /OpenSource/Tools/BuildSlaveSupport/test.webkit.org-config, and have a test 
 build master that updates and outputs logs somewhere readable (public_html?). 
  Then, we could make sure any changes work on the test master before 
 committing them to production.

Having a test master seems like a good idea. Doing it by keeping a complete 
second copy of the configuration checked in to SVN seems less than ideal.

- Mark

 On Jun 21, 2012, at 1:15 PM, William Siegrist wrote:
 
 The server does not run the unittests, but it does normally run `buildbot 
 checkconfig`. However, we had to temporarily bypass the checkconfig test 
 during restart due to a bug in Buildbot:
 
 http://trac.buildbot.net/ticket/2279
 
 The best thing to do when working on the buildbot config is to have buildbot 
 installed on your local machine so you can test the config before 
 committing. That avoids the confusion of the reconfig not happening and 
 people thinking the automatic reconfig is just broken.
 
 -Bill
 
 
 On Jun 21, 2012, at 12:28 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 In this case we could have avoided the breakage with running this unittest.
 Can we make the master somehow run this unittest before restarting itself?
 
 br,
 Ossy
 
 Eric Seidel írta:
 One can run:
 http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/mastercfg_unittest.py
 to test the master locally, but that's all I know of.
 On Thu, Jun 21, 2012 at 11:15 AM, Sergio Villar Senin
 svil...@igalia.com wrote:
 En 21/06/12 19:54, William Siegrist escribiu:
 On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:
 
 Is something being upgraded right now?
 
 No, the config file has a problem in it which is unrelated to our 
 upgrade as far as I can tell. I'm trying to track down what happened.
 
 $ buildbot checkconfig
 Do we have any tool that allows to check locally changes in the slaves
 configuration?
 
 BR
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down for upgrade

2012-06-13 Thread Osztrogonac Csaba

Hi,

Sorry for the late response, I didn't have to much time last week.

But fortunately I managed to fix it today, and uploaded the proposed patches:
- Unhide login form on the build.webkit.org - 
https://bugs.webkit.org/show_bug.cgi?id=88981
- Update buildbot master in autoinstaller to match build.webkit.org - 
https://bugs.webkit.org/show_bug.cgi?id=88992
- Add ForceScheduler to build.webkit.org - 
https://bugs.webkit.org/show_bug.cgi?id=88982
- master.cfg cleanup, remove unnecessary workaround - 
https://bugs.webkit.org/show_bug.cgi?id=88994

br,
Ossy

Lucas Forschler írta:

Hi Ossy,

Can you send me the bugzilla link for the ForceScheduler work?

Thanks,
Lucas

On May 31, 2012, at 9:22 AM, Lucas Forschler wrote:


HI Ossy,

I did notice the display order change as well.  I think I am going to open a 
bug to rename all of the Apple bots to prefix them with 'Apple'.  We (at Apple) 
would like to get our bots into a more conforming naming convention.  I realize 
that won't solve the problem with having a specific order for your bots, but it 
will at least get everything grouped together.

I'm slightly opposed to rolling out the natural sorting as you suggest below... 
I think that will be short-lived and when buildbot 0.9.x is available, we may 
not have this option.  I think we should be forward thinking here and try not 
to work around this.  I can be convinced to make the change if there is 
additional support for rolling out the natural sorting.

Thanks for looking into the ForceScheduler.  Hopefully we can get that up and 
running quickly.

So far it appears we don't have any bots stuck in trigger mode.  Please let me 
know if you see any.  I am hoping that issue is now solved for good.

Thanks,
Lucas




On May 31, 2012, at 3:32 AM, Osztrogonac Csaba wrote:


Lucas Forschler írta:

to 0.8.6p1
Will be back online when complete.
Lucas

Hi All,

Unfortunately there are too annoying bugs introduced
with upgrading build master to 0.8.6p1 :

Problem 1
--
Builders are alphabetically ordered on http://build.webkit.org/waterfall
instead of the given order in our config.json.

http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
Builders are no longer displayed in the order they were configured. This was 
never
intended behavior, and will become impossible in the distributed architecture 
planned
for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, 
but with
numeric segments sorted numerically.

I think the new alphabetical order is so confusing. For example Apple's Lion 
bots
are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I know
that we can see category=AppleMac, category=Qt, ... , but the order of the bots
in a given category is important for us too.  I don't think that an artifical
renaming would be a good solution to get the order what we want. (Because we
would have to rename bots in all scripts, we would have loose the history, ...)

What about if we revert the buildbot-0.8.6p1 change in buildmaster caused this 
bug/feature?
Here is a simple patch to do it:

diff --git a/buildbot-0.8.6p1/buildbot/status/master.py 
b/buildbot-0.8.6p1/buildbot/status/master.py
index e803133..e60ab06 100644
--- a/buildbot-0.8.6p1/buildbot/status/master.py
+++ b/buildbot-0.8.6p1/buildbot/status/master.py
@@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, 
service.MultiService):

   def getBuilderNames(self, categories=None):
   if categories == None:
-return util.naturalSort(self.botmaster.builderNames) # don't let 
them break it
+return self.botmaster.builderNames # don't let them break it

   l = []
   # respect addition order
@@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, 
service.MultiService):
   bldr = self.botmaster.builders[name]
   if bldr.config.category in categories:
   l.append(name)
-return util.naturalSort(l)
+return l

   def getBuilder(self, name):
   

Problem 2
--
There isn't force build possibility anymore.

http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
Forced builds now require that a ForceScheduler be defined in the Buildbot 
configuration.

It can be solved simple with adding ForceScheduler. I'm going
to file a bug report and prepare a patch to fix it soon.

br,
Ossy

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down for upgrade

2012-06-12 Thread Lucas Forschler
Hi Ossy,

Can you send me the bugzilla link for the ForceScheduler work?

Thanks,
Lucas

On May 31, 2012, at 9:22 AM, Lucas Forschler wrote:

 HI Ossy,
 
 I did notice the display order change as well.  I think I am going to open a 
 bug to rename all of the Apple bots to prefix them with 'Apple'.  We (at 
 Apple) would like to get our bots into a more conforming naming convention.  
 I realize that won't solve the problem with having a specific order for your 
 bots, but it will at least get everything grouped together.
 
 I'm slightly opposed to rolling out the natural sorting as you suggest below… 
 I think that will be short-lived and when buildbot 0.9.x is available, we may 
 not have this option.  I think we should be forward thinking here and try not 
 to work around this.  I can be convinced to make the change if there is 
 additional support for rolling out the natural sorting.
 
 Thanks for looking into the ForceScheduler.  Hopefully we can get that up and 
 running quickly.
 
 So far it appears we don't have any bots stuck in trigger mode.  Please let 
 me know if you see any.  I am hoping that issue is now solved for good.
 
 Thanks,
 Lucas
 
 
 
 
 On May 31, 2012, at 3:32 AM, Osztrogonac Csaba wrote:
 
 Lucas Forschler írta:
 to 0.8.6p1
 Will be back online when complete.
 Lucas
 
 Hi All,
 
 Unfortunately there are too annoying bugs introduced
 with upgrading build master to 0.8.6p1 :
 
 Problem 1
 --
 Builders are alphabetically ordered on http://build.webkit.org/waterfall
 instead of the given order in our config.json.
 
 http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
 Builders are no longer displayed in the order they were configured. This 
 was never
 intended behavior, and will become impossible in the distributed 
 architecture planned
 for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, 
 but with
 numeric segments sorted numerically.
 
 I think the new alphabetical order is so confusing. For example Apple's Lion 
 bots
 are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I 
 know
 that we can see category=AppleMac, category=Qt, ... , but the order of the 
 bots
 in a given category is important for us too.  I don't think that an artifical
 renaming would be a good solution to get the order what we want. (Because we
 would have to rename bots in all scripts, we would have loose the history, 
 ...)
 
 What about if we revert the buildbot-0.8.6p1 change in buildmaster caused 
 this bug/feature?
 Here is a simple patch to do it:
 
 diff --git a/buildbot-0.8.6p1/buildbot/status/master.py 
 b/buildbot-0.8.6p1/buildbot/status/master.py
 index e803133..e60ab06 100644
 --- a/buildbot-0.8.6p1/buildbot/status/master.py
 +++ b/buildbot-0.8.6p1/buildbot/status/master.py
 @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, 
 service.MultiService):
 
def getBuilderNames(self, categories=None):
if categories == None:
 -return util.naturalSort(self.botmaster.builderNames) # don't 
 let them break it
 +return self.botmaster.builderNames # don't let them break it
 
l = []
# respect addition order
 @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, 
 service.MultiService):
bldr = self.botmaster.builders[name]
if bldr.config.category in categories:
l.append(name)
 -return util.naturalSort(l)
 +return l
 
def getBuilder(self, name):

 
 Problem 2
 --
 There isn't force build possibility anymore.
 
 http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
 Forced builds now require that a ForceScheduler be defined in the Buildbot 
 configuration.
 
 It can be solved simple with adding ForceScheduler. I'm going
 to file a bug report and prepare a patch to fix it soon.
 
 br,
 Ossy
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down for upgrade

2012-05-31 Thread Osztrogonac Csaba

Lucas Forschler írta:

to 0.8.6p1

Will be back online when complete.
Lucas


Hi All,

Unfortunately there are too annoying bugs introduced
with upgrading build master to 0.8.6p1 :

Problem 1
--
Builders are alphabetically ordered on http://build.webkit.org/waterfall
instead of the given order in our config.json.

http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
Builders are no longer displayed in the order they were configured. This was 
never
intended behavior, and will become impossible in the distributed architecture 
planned
for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, 
but with
numeric segments sorted numerically.

I think the new alphabetical order is so confusing. For example Apple's Lion 
bots
are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I know
that we can see category=AppleMac, category=Qt, ... , but the order of the bots
in a given category is important for us too.  I don't think that an artifical
renaming would be a good solution to get the order what we want. (Because we
would have to rename bots in all scripts, we would have loose the history, ...)

What about if we revert the buildbot-0.8.6p1 change in buildmaster caused this 
bug/feature?
Here is a simple patch to do it:

diff --git a/buildbot-0.8.6p1/buildbot/status/master.py 
b/buildbot-0.8.6p1/buildbot/status/master.py
index e803133..e60ab06 100644
--- a/buildbot-0.8.6p1/buildbot/status/master.py
+++ b/buildbot-0.8.6p1/buildbot/status/master.py
@@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, 
service.MultiService):

 def getBuilderNames(self, categories=None):
 if categories == None:
-return util.naturalSort(self.botmaster.builderNames) # don't let 
them break it
+return self.botmaster.builderNames # don't let them break it

 l = []
 # respect addition order
@@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, 
service.MultiService):
 bldr = self.botmaster.builders[name]
 if bldr.config.category in categories:
 l.append(name)
-return util.naturalSort(l)
+return l

 def getBuilder(self, name):
 

Problem 2
--
There isn't force build possibility anymore.

http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
Forced builds now require that a ForceScheduler be defined in the Buildbot 
configuration.

It can be solved simple with adding ForceScheduler. I'm going
to file a bug report and prepare a patch to fix it soon.

br,
Ossy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down for upgrade

2012-05-31 Thread Lucas Forschler
HI Ossy,

I did notice the display order change as well.  I think I am going to open a 
bug to rename all of the Apple bots to prefix them with 'Apple'.  We (at Apple) 
would like to get our bots into a more conforming naming convention.  I realize 
that won't solve the problem with having a specific order for your bots, but it 
will at least get everything grouped together.

I'm slightly opposed to rolling out the natural sorting as you suggest below… I 
think that will be short-lived and when buildbot 0.9.x is available, we may not 
have this option.  I think we should be forward thinking here and try not to 
work around this.  I can be convinced to make the change if there is additional 
support for rolling out the natural sorting.

Thanks for looking into the ForceScheduler.  Hopefully we can get that up and 
running quickly.

So far it appears we don't have any bots stuck in trigger mode.  Please let me 
know if you see any.  I am hoping that issue is now solved for good.

Thanks,
Lucas




On May 31, 2012, at 3:32 AM, Osztrogonac Csaba wrote:

 Lucas Forschler írta:
 to 0.8.6p1
 Will be back online when complete.
 Lucas
 
 Hi All,
 
 Unfortunately there are too annoying bugs introduced
 with upgrading build master to 0.8.6p1 :
 
 Problem 1
 --
 Builders are alphabetically ordered on http://build.webkit.org/waterfall
 instead of the given order in our config.json.
 
 http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
 Builders are no longer displayed in the order they were configured. This was 
 never
 intended behavior, and will become impossible in the distributed architecture 
 planned
 for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, 
 but with
 numeric segments sorted numerically.
 
 I think the new alphabetical order is so confusing. For example Apple's Lion 
 bots
 are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I 
 know
 that we can see category=AppleMac, category=Qt, ... , but the order of the 
 bots
 in a given category is important for us too.  I don't think that an artifical
 renaming would be a good solution to get the order what we want. (Because we
 would have to rename bots in all scripts, we would have loose the history, 
 ...)
 
 What about if we revert the buildbot-0.8.6p1 change in buildmaster caused 
 this bug/feature?
 Here is a simple patch to do it:
 
 diff --git a/buildbot-0.8.6p1/buildbot/status/master.py 
 b/buildbot-0.8.6p1/buildbot/status/master.py
 index e803133..e60ab06 100644
 --- a/buildbot-0.8.6p1/buildbot/status/master.py
 +++ b/buildbot-0.8.6p1/buildbot/status/master.py
 @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, 
 service.MultiService):
 
 def getBuilderNames(self, categories=None):
 if categories == None:
 -return util.naturalSort(self.botmaster.builderNames) # don't let 
 them break it
 +return self.botmaster.builderNames # don't let them break it
 
 l = []
 # respect addition order
 @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, 
 service.MultiService):
 bldr = self.botmaster.builders[name]
 if bldr.config.category in categories:
 l.append(name)
 -return util.naturalSort(l)
 +return l
 
 def getBuilder(self, name):
 
 
 Problem 2
 --
 There isn't force build possibility anymore.
 
 http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
 Forced builds now require that a ForceScheduler be defined in the Buildbot 
 configuration.
 
 It can be solved simple with adding ForceScheduler. I'm going
 to file a bug report and prepare a patch to fix it soon.
 
 br,
 Ossy
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down for upgrade

2012-05-31 Thread Ryosuke Niwa
On the other hand, this looks like a regression. Can we file a bug against
buildbot and see what they have to say about it?
On May 31, 2012 9:22 AM, Lucas Forschler lforsch...@apple.com wrote:

 HI Ossy,

 I did notice the display order change as well.  I think I am going to open
 a bug to rename all of the Apple bots to prefix them with 'Apple'.  We (at
 Apple) would like to get our bots into a more conforming naming convention.
  I realize that won't solve the problem with having a specific order for
 your bots, but it will at least get everything grouped together.

 I'm slightly opposed to rolling out the natural sorting as you suggest
 below… I think that will be short-lived and when buildbot 0.9.x is
 available, we may not have this option.  I think we should be forward
 thinking here and try not to work around this.  I can be convinced to make
 the change if there is additional support for rolling out the natural
 sorting.

 Thanks for looking into the ForceScheduler.  Hopefully we can get that up
 and running quickly.

 So far it appears we don't have any bots stuck in trigger mode.  Please
 let me know if you see any.  I am hoping that issue is now solved for good.

 Thanks,
 Lucas




 On May 31, 2012, at 3:32 AM, Osztrogonac Csaba wrote:

  Lucas Forschler írta:
  to 0.8.6p1
  Will be back online when complete.
  Lucas
 
  Hi All,
 
  Unfortunately there are too annoying bugs introduced
  with upgrading build master to 0.8.6p1 :
 
  Problem 1
  --
  Builders are alphabetically ordered on http://build.webkit.org/waterfall
  instead of the given order in our config.json.
 
  http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
  Builders are no longer displayed in the order they were configured.
 This was never
  intended behavior, and will become impossible in the distributed
 architecture planned
  for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally:
 lexically, but with
  numeric segments sorted numerically.
 
  I think the new alphabetical order is so confusing. For example Apple's
 Lion bots
  are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots.
 I know
  that we can see category=AppleMac, category=Qt, ... , but the order of
 the bots
  in a given category is important for us too.  I don't think that an
 artifical
  renaming would be a good solution to get the order what we want.
 (Because we
  would have to rename bots in all scripts, we would have loose the
 history, ...)
 
  What about if we revert the buildbot-0.8.6p1 change in buildmaster
 caused this bug/feature?
  Here is a simple patch to do it:
 
  diff --git a/buildbot-0.8.6p1/buildbot/status/master.py
 b/buildbot-0.8.6p1/buildbot/status/master.py
  index e803133..e60ab06 100644
  --- a/buildbot-0.8.6p1/buildbot/status/master.py
  +++ b/buildbot-0.8.6p1/buildbot/status/master.py
  @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin,
 service.MultiService):
 
  def getBuilderNames(self, categories=None):
  if categories == None:
  -return util.naturalSort(self.botmaster.builderNames) #
 don't let them break it
  +return self.botmaster.builderNames # don't let them break it
 
  l = []
  # respect addition order
  @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin,
 service.MultiService):
  bldr = self.botmaster.builders[name]
  if bldr.config.category in categories:
  l.append(name)
  -return util.naturalSort(l)
  +return l
 
  def getBuilder(self, name):
  
 
  Problem 2
  --
  There isn't force build possibility anymore.
 
  http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html
  Forced builds now require that a ForceScheduler be defined in the
 Buildbot configuration.
 
  It can be solved simple with adding ForceScheduler. I'm going
  to file a bug report and prepare a patch to fix it soon.
 
  br,
  Ossy
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] build.webkit.org down for upgrade

2012-05-30 Thread Lucas Forschler
to 0.8.6p1

Will be back online when complete.
Lucas

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] build.webkit.org down for upgrade

2012-05-30 Thread Ryosuke Niwa
Yay! for 0.8.6. Hopefully it fixes the stuck-in-trigger issue :)

- Ryosuke

On Wed, May 30, 2012 at 6:20 PM, Lucas Forschler lforsch...@apple.comwrote:

 to 0.8.6p1

 Will be back online when complete.
 Lucas

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev